Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 11: Kernel, Sandbox, and Hardware-Enforced Execution Finality
draft-das-hardware-execution-finality-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-hardware-execution-finality-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 11: Kernel, Sandbox, and Hardware-Enforced Execution
Finality
draft-das-hardware-execution-finality-00
Abstract
A sandboxed, attested AI agent can still change the real world
through a door the sandbox left open. Apple iOS and iPadOS app
sandboxes, macOS, Google Android, Windows and Linux kernels, AI-agent
code-execution cells, on-device neural processors running assistants
such as Apple Siri, Google Gemini, Samsung Galaxy AI, and Microsoft
Copilot, NVIDIA accelerators and network controllers, Qualcomm and
Arm processors, confidential-computing virtual machines, and
embedded, automotive, and telecom controllers isolate workloads while
still exposing consequential file, credential, network, inter-
process, deployment, firmware, and hardware-command interfaces.
Prompt-injected tool execution, privileged connector bypass, syscall
arguments changed after checking, policy hot swaps, stale
attestation, GPU and DMA egress, rollback of tools or policies, and
monitors that only observe rather than block can each let an
apparently confined agent cause an unauthorized real effect.
This document, Part 11 of a twelve-part series, specifies execution
finality at kernel, sandbox, and hardware boundaries. It describes
protected discovery of every effect-capable path, with an explicit
distinction between paths that are blocked and paths that are merely
observed; controls on transitions from sandbox output to privileged
real-world effect; non-bypassable credential custody; generation-safe
installation, upgrade, and rollback of tool runtimes; protected
mutation of security policy and configuration; hardware attribution
of device and accelerator commands; independent witness and
attestation qualification; and Finality Sink reconstruction of the
actual pending operation with scoped non-bearer authority and fail-
closed consumption. Remote attestation is treated as evidence about
an environment, not authority for a particular effect. Reference
algorithms, sixteen threat models, and thirty-six reproducible tests,
including Apple, Android Binder, and Windows privileged-service
cases, are included. Part 1 of the series defines the shared
terminology and common workflows.
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The document relates these mechanisms to Remote ATtestation
procedureS (RATS), Trusted Execution Environment Provisioning (TEEP),
Software Updates for Internet of Things (SUIT), Authentication and
Authorization for Constrained Environments (ACE), CBOR Object Signing
and Encryption (COSE), OAuth 2.0 Rich Authorization Requests,
Demonstrating Proof of Possession (DPoP), and Token Exchange,
Workload Identity in Multi-System Environments (WIMSE), Supply Chain
Integrity, Transparency, and Trust (SCITT), HTTP semantics, the
Network Configuration Protocol (NETCONF), autonomic networking, and
operational observability work. The additional question addressed is
whether a particular real-world effect is authorised and is blocked
or released at its actual enforcement boundary; no working-group
adoption or IETF consensus is claimed.
Industry alignment covers Apple iOS, iPadOS, and macOS sandboxes with
Siri and App Intents; Google Android with Gemini, Binder, and
Keystore; Samsung Galaxy AI and Bixby; Microsoft Windows with
virtualization-based security, Copilot, and AI PCs with neural
processing units; Linux with seccomp, eBPF, security modules, and
microVMs; code-execution sandboxes for AI agents; browser sandboxes
and web agents; agent platforms from OpenAI, Anthropic, Google, and
Meta; NVIDIA accelerators and data-processing units; Qualcomm, Arm,
and Huawei processors and trusted execution environments;
confidential computing and attested private AI clouds; cloud workload
isolation on AWS, Azure, and Google Cloud; server baseboard
management controllers; banking, signing, and payment hardware;
telecommunications network functions and SmartNICs; software-defined
vehicles; medical devices; industrial control systems; drones and
robotics; satellite command; and CI/CD and policy automation. For
each, the document states the technical effect: a consequential
effect leaves the sandbox or reaches the hardware only through a gate
that blocks, rather than merely logs, and that verifies the exact
operation against current authority. Product names are illustrative
and imply no endorsement or implementation by any vendor. For the EU
Artificial Intelligence Act (Regulation (EU) 2024/1689), mandatory
blocking enforcement with honest coverage records can help providers
and deployers address robustness and cybersecurity, risk-management,
and record-keeping 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.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction: Kernel, Sandbox and Hardware Security Problem
Space . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1. Twelve-Part Technical Specification Series: Contents,
Boundaries and Planned References . . . . . . . . . . . . 12
1.1.1. Part 1 of 12 — Foundational Protected Consequential
Authority, Definitions, CW-1/CW-2/CW-3 . . . . . . . 12
1.1.2. Part 2 of 12 — Apple iOS, Android and Cross-Platform AI
Tool Interoperability . . . . . . . . . . . . . . . . 12
1.1.3. Part 3 of 12 — Protected Source Authority,
Cross-Committed Validation Evidence and Non-Bearer
Finality . . . . . . . . . . . . . . . . . . . . . . 12
1.1.4. Part 4 of 12 — Actual-Operation Reconstruction,
Finality Sink Enforcement and Anti-Bypass . . . . . . 13
1.1.5. Part 5 of 12 — Multi-Agent Delegation, Quorums and
Concurrent Authority . . . . . . . . . . . . . . . . 13
1.1.6. Part 6 of 12 — Actual-Effect Receipts and Protected
Causal Continuation . . . . . . . . . . . . . . . . . 13
1.1.7. Part 7 of 12 — AI Tool Integrity, Resource Identity and
Execution-Time Semantics . . . . . . . . . . . . . . 13
1.1.8. Part 8 of 12 — Cross-Domain Effects, Transactions,
Irreversibility and Recovery . . . . . . . . . . . . 14
1.1.9. Part 9 of 12 — Credential Custody, Operation-Bound
Secrets and Protected Data Disclosure . . . . . . . . 14
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
1.1.10. Part 10 of 12 — Device Authority Continuity, Revocation
and Offline Execution . . . . . . . . . . . . . . . . 14
1.1.11. Part 11 of 12 — Kernel, Sandbox, Hardware, Runtime
Transition and Attestation Enforcement . . . . . . . 15
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecommunications,
Policy and Critical Infrastructure Finality . . . . . 15
2. Patent-Pending Technical Disclosure, IETF IPR Process and
Forthcoming GitHub Implementation . . . . . . . . . . . . 15
3. Keywords: Industry-Recognized Security and Patent-Examiner
Discovery Terms . . . . . . . . . . . . . . . . . . . . . 16
4. Foundational Terms, Trust Boundaries and
Mandatory-versus-Optional Security Properties . . . . . . 16
4.1. Candidate Act and Non-Effective State . . . . . . . . . . 17
4.2. Protected Enforcement Domain . . . . . . . . . . . . . . 17
4.3. Finality Sink and Actual Operation . . . . . . . . . . . 17
4.4. Coverage versus Monitoring . . . . . . . . . . . . . . . 17
4.5. Scoped Non-Bearer Authority . . . . . . . . . . . . . . . 17
4.6. Hardware Attribution and Attestation . . . . . . . . . . 17
4.7. Live Policy and Runtime Generations . . . . . . . . . . . 18
4.8. Independent Evidence and Witness Compromise . . . . . . . 18
4.9. Supported Integration Boundaries . . . . . . . . . . . . 18
5. Original Technical Disclosure: Page-Indexed Source with
Architecture and Operational Figures . . . . . . . . . . 18
5.1. Source Foundation: Cross-Platform Native Permissions and
Independent Consequence Authority . . . . . . . . . . . . 18
5.1.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 19
5.1.3. Page-Indexed Original Technical Text . . . . . . . . 19
5.2. Miscellaneous Embodiment M-1: Dynamic Enforcement-Path and
Hardware Resource Coverage . . . . . . . . . . . . . . . 38
5.2.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 38
5.2.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 38
5.2.3. Page-Indexed Original Technical Text . . . . . . . . 39
5.3. Embodiment 14: Effectuation-Path Discovery, Runtime Bypass
Detection and Hardware Attribution . . . . . . . . . . . 107
5.3.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 107
5.3.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 107
5.3.3. Page-Indexed Original Technical Text . . . . . . . . 108
5.4. Miscellaneous Embodiment M-2: Existing Standards, Kernel,
Sandbox and Hardware Integration . . . . . . . . . . . . 201
5.4.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 201
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 202
5.4.3. Page-Indexed Original Technical Text . . . . . . . . 202
5.5. Embodiment 25: Sandbox-to-Privileged-Effect Transition and
Non-Bypassable Credential/Network Control . . . . . . . . 269
5.5.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 269
5.5.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 270
5.5.3. Page-Indexed Original Technical Text . . . . . . . . 270
5.6. Embodiment 26: Tool Runtime Installation, Upgrade, Rollback
and Generation-Safe Effectuation . . . . . . . . . . . . 352
5.6.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 352
5.6.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 353
5.6.3. Page-Indexed Original Technical Text . . . . . . . . 353
5.7. Embodiment 33: Protected Security-Policy Mutation and
Configuration-Change Enforcement . . . . . . . . . . . . 434
5.7.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 435
5.7.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 435
5.7.3. Page-Indexed Original Technical Text . . . . . . . . 435
5.8. Embodiment 38: Independent Witness, Attestation and
Evidence-Qualification Enforcement . . . . . . . . . . . 527
5.8.1. Architecture Diagram: Protected Components and Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . 527
5.8.2. Operational Flowchart: Verification, Withholding and
Effectuation . . . . . . . . . . . . . . . . . . . . 528
5.8.3. Page-Indexed Original Technical Text . . . . . . . . 528
6. PHOSITA Implementation: Existing Software, Kernel Controls,
Secure Hardware and Practical Constraints . . . . . . . . 630
6.1. Choose a benign effect and define the effect boundary . . 630
6.2. Build the lower-trust agent sandbox . . . . . . . . . . . 630
6.3. Enumerate the effect-capable path graph . . . . . . . . . 630
6.4. Distinguish advisory observers and mandatory blockers . . 631
6.5. Define canonical operation identity . . . . . . . . . . . 631
6.6. Protect the source-grant and finality ledger . . . . . . 631
6.7. Construct a protected gateway with controlled egress . . 631
6.8. Support Linux seccomp and LSM integrations where
appropriate . . . . . . . . . . . . . . . . . . . . . . 631
6.9. Model Windows security boundaries without private
assumptions . . . . . . . . . . . . . . . . . . . . . . 631
6.10. Implement supported Android application mediation . . . . 632
6.11. Implement supported Apple app and server integration . . 632
6.12. Isolate reusable credentials from the untrusted
workload . . . . . . . . . . . . . . . . . . . . . . . . 632
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6.13. Treat hardware attestation as scoped evidence . . . . . . 632
6.14. Guard GPU and device command queues only where
controlled . . . . . . . . . . . . . . . . . . . . . . . 632
6.15. Protect live sandbox policy mutations . . . . . . . . . . 632
6.16. Model runtime changes and rollback . . . . . . . . . . . 633
6.17. Qualify separate observers and witnesses . . . . . . . . 633
6.18. Use exact resource-side conditional writes . . . . . . . 633
6.19. Define crash and retry semantics . . . . . . . . . . . . 633
6.20. Record enforcement coverage evidence . . . . . . . . . . 633
6.21. Enforce bounded verification resources . . . . . . . . . 633
6.22. Keep reference test profiles vendor-neutral . . . . . . . 633
6.23. Publish reproducible source-to-figure mapping . . . . . . 634
7. Reference Data Structures, Control Interfaces, State Machines
and Non-Limiting Algorithms . . . . . . . . . . . . . . . 634
7.1. Canonical Candidate Act Descriptor . . . . . . . . . . . 634
7.2. Effectuation Path Coverage Record . . . . . . . . . . . . 634
7.3. Coverage Discovery and Revalidation . . . . . . . . . . . 635
7.4. Sandbox-to-Effect Boundary Check . . . . . . . . . . . . 635
7.5. Non-Bearer Finality Permit . . . . . . . . . . . . . . . 635
7.6. Sink-Local Atomic Effect State . . . . . . . . . . . . . 636
7.7. Attestation Evidence Qualification . . . . . . . . . . . 636
7.8. Protected Policy-Change Authorization . . . . . . . . . . 636
7.9. Tool Version Change and Rollback Fence . . . . . . . . . 637
7.10. Independent Witness Correlation Control . . . . . . . . . 637
7.11. Protected Gate on GPU / Device Egress . . . . . . . . . . 637
7.12. Crash, Retry and Unknown Outcome . . . . . . . . . . . . 638
7.13. Fail-Closed Topology Update . . . . . . . . . . . . . . . 638
8. Threat Models: Kernel, Sandbox, Hardware, Attestation and
Evidence Attacks . . . . . . . . . . . . . . . . . . . . 638
8.1. Threat 1: Prompt-injected tool command escapes intended
user effect . . . . . . . . . . . . . . . . . . . . . . 638
8.2. Threat 2: Container confinement with alternate network
route . . . . . . . . . . . . . . . . . . . . . . . . . 639
8.3. Threat 3: eBPF monitor mistaken for mandatory
enforcement . . . . . . . . . . . . . . . . . . . . . . 639
8.4. Threat 4: Mutable syscall or broker argument race . . . . 639
8.5. Threat 5: Forged attestation or stale runtime
measurement . . . . . . . . . . . . . . . . . . . . . . 639
8.6. Threat 6: Sandbox-generated deployment artifact becomes
effective . . . . . . . . . . . . . . . . . . . . . . . 640
8.7. Threat 7: Privileged connector credential laundering . . 640
8.8. Threat 8: Policy hot-swap broadens previously approved
request . . . . . . . . . . . . . . . . . . . . . . . . 640
8.9. Threat 9: Rollback of tool or security-policy
generation . . . . . . . . . . . . . . . . . . . . . . . 640
8.10. Threat 10: GPU command queue persists after revocation . 640
8.11. Threat 11: DMA or peer-to-peer access bypasses host
gateway . . . . . . . . . . . . . . . . . . . . . . . . 641
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
8.12. Threat 12: Witness collusion or common-mode compromise . 641
8.13. Threat 13: Resource alias and destination rebinding . . . 641
8.14. Threat 14: Verification exhaustion triggers permit
fallback . . . . . . . . . . . . . . . . . . . . . . . . 641
8.15. Threat 15: Untrusted mobile app claims global OS
enforcement . . . . . . . . . . . . . . . . . . . . . . 642
8.16. Threat 16: Crash occurs between permit consumption and
outcome . . . . . . . . . . . . . . . . . . . . . . . . 642
9. Technical Validation: Thirty-Six Proposed Tests, Fixtures and
Expected Security Outcomes . . . . . . . . . . . . . . . 642
9.1. Proposed Test PT11-01: Legitimate single bounded
effect . . . . . . . . . . . . . . . . . . . . . . . . . 642
9.2. Proposed Test PT11-02: Prompt injection changes target . 643
9.3. Proposed Test PT11-03: Sandbox blocks direct socket but
open IPC path . . . . . . . . . . . . . . . . . . . . . 643
9.4. Proposed Test PT11-04: Monitoring-only eBPF sensor . . . 643
9.5. Proposed Test PT11-05: Validated immutable actual
request . . . . . . . . . . . . . . . . . . . . . . . . 644
9.6. Proposed Test PT11-06: Signature valid but wrong
resource . . . . . . . . . . . . . . . . . . . . . . . . 644
9.7. Proposed Test PT11-07: Old attestation nonce . . . . . . 644
9.8. Proposed Test PT11-08: Different attested software
version . . . . . . . . . . . . . . . . . . . . . . . . 645
9.9. Proposed Test PT11-09: Nonblocking path discovered at
runtime . . . . . . . . . . . . . . . . . . . . . . . . 645
9.10. Proposed Test PT11-10: Source grant revoked after sandbox
approval . . . . . . . . . . . . . . . . . . . . . . . . 645
9.11. Proposed Test PT11-11: Policy allowlist broadened by
agent . . . . . . . . . . . . . . . . . . . . . . . . . 645
9.12. Proposed Test PT11-12: Competent policy update with stale
CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
9.13. Proposed Test PT11-13: Tool binary rollback . . . . . . . 646
9.14. Proposed Test PT11-14: Untrusted dependency reports fake
outcome . . . . . . . . . . . . . . . . . . . . . . . . 646
9.15. Proposed Test PT11-15: Credential broker swaps to unrelated
token audience . . . . . . . . . . . . . . . . . . . . . 647
9.16. Proposed Test PT11-16: Authenticated actor exceeds task
grant . . . . . . . . . . . . . . . . . . . . . . . . . 647
9.17. Proposed Test PT11-17: Copied non-bearer finality
reference . . . . . . . . . . . . . . . . . . . . . . . 647
9.18. Proposed Test PT11-18: Duplicate single-use effect . . . 648
9.19. Proposed Test PT11-19: Resource revision changes . . . . 648
9.20. Proposed Test PT11-20: Crash after consume before ack . . 648
9.21. Proposed Test PT11-21: Kernel security-profile disables
blocking . . . . . . . . . . . . . . . . . . . . . . . . 648
9.22. Proposed Test PT11-22: GPU command without proper gate . 649
9.23. Proposed Test PT11-23: Device queue with qualified
gate . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
9.24. Proposed Test PT11-24: DMA alias exposes another
resource . . . . . . . . . . . . . . . . . . . . . . . . 649
9.25. Proposed Test PT11-25: Witnesses share compromised
source . . . . . . . . . . . . . . . . . . . . . . . . . 650
9.26. Proposed Test PT11-26: Independent qualified witness
set . . . . . . . . . . . . . . . . . . . . . . . . . . 650
9.27. Proposed Test PT11-27: Malformed CBOR and schema
ambiguity . . . . . . . . . . . . . . . . . . . . . . . 650
9.28. Proposed Test PT11-28: Replay across serialization
profiles . . . . . . . . . . . . . . . . . . . . . . . . 651
9.29. Proposed Test PT11-29: Verification-budget exhaustion . . 651
9.30. Proposed Test PT11-30: Apple app-supported-only
boundary . . . . . . . . . . . . . . . . . . . . . . . . 651
9.31. Proposed Test PT11-31: Android Binder caller identity . . 651
9.32. Proposed Test PT11-32: Windows privileged service
scope . . . . . . . . . . . . . . . . . . . . . . . . . 652
9.33. Proposed Test PT11-33: Firmware update invalidates
coverage . . . . . . . . . . . . . . . . . . . . . . . . 652
9.34. Proposed Test PT11-34: Human approval for changed
policy . . . . . . . . . . . . . . . . . . . . . . . . . 652
9.35. Proposed Test PT11-35: Remote destination refused then
retried . . . . . . . . . . . . . . . . . . . . . . . . 653
9.36. Proposed Test PT11-36: Full end-to-end negative
assurance . . . . . . . . . . . . . . . . . . . . . . . 653
10. Detailed Industry and Product Alignment: Apple, Android, AI
Agents, Hardware and Critical Resources . . . . . . . . . 653
10.1. Apple iOS, iPadOS, App Sandbox and App Intents . . . . . 654
10.2. Apple macOS, application sandbox and desktop
automation . . . . . . . . . . . . . . . . . . . . . . 654
10.3. Google Android, Binder IPC, app security and Keystore . 654
10.4. Microsoft Windows, kernel isolation, VBS and agent
sandboxes . . . . . . . . . . . . . . . . . . . . . . . 655
10.5. Linux, seccomp, eBPF, LSM and microVM runtime . . . . . 655
10.6. OpenAI Codex and tool-execution infrastructure . . . . . 655
10.7. Anthropic Claude Code and sandboxed or hosted agents . . 655
10.8. Google Gemini, Android-connected assistants and Google
Cloud . . . . . . . . . . . . . . . . . . . . . . . . . 656
10.9. Meta Muse, Sentinel and credential-proxy security . . . 656
10.10. NVIDIA OpenShell, Sentry, BlueField and GPU accelerator
egress . . . . . . . . . . . . . . . . . . . . . . . . 656
10.11. Qualcomm Snapdragon processors, mobile TEEs and
modems . . . . . . . . . . . . . . . . . . . . . . . . 657
10.12. Huawei HarmonyOS, devices and telecom controller
ecosystems . . . . . . . . . . . . . . . . . . . . . . 657
10.13. Arm TrustZone, confidential execution and protected
cryptography . . . . . . . . . . . . . . . . . . . . . 657
10.14. AWS, Azure, Google Cloud and cloud AI workload
isolation . . . . . . . . . . . . . . . . . . . . . . . 658
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.15. Banking, digital signing and payment infrastructure . . 658
10.16. Telecommunications, 5G/6G, SmartNICs and network
functions . . . . . . . . . . . . . . . . . . . . . . . 658
10.17. Embedded controllers, automotive and robotics . . . . . 658
10.18. Enterprise CI/CD, deployment and policy automation . . . 659
10.19. Patent examination and public prior-art discovery . . . 659
10.20. On-Device and Hybrid Assistants: Apple Siri and Apple
Intelligence, Google Gemini, Samsung Galaxy AI and
Microsoft Copilot . . . . . . . . . . . . . . . . . . . 659
10.21. AI PCs and Neural Processing Units . . . . . . . . . . . 660
10.22. Code-Execution Sandboxes for AI Agents: Containers,
MicroVMs, gVisor and WebAssembly . . . . . . . . . . . 660
10.23. Browser Sandboxes, Web Agents and Extensions . . . . . . 661
10.24. Confidential Computing and Attested Private AI Clouds . 661
10.25. Server Baseboard Management Controllers and Out-of-Band
Management . . . . . . . . . . . . . . . . . . . . . . 661
10.26. Software-Defined Vehicles and Automotive Electronic
Control Units . . . . . . . . . . . . . . . . . . . . . 662
10.27. Medical Devices and Connected Care . . . . . . . . . . . 662
10.28. Industrial Control Systems and Operational Technology . 662
10.29. Drones, Robotics and Physical Actuators . . . . . . . . 663
10.30. Satellite Command and Ground-Segment Security . . . . . 663
10.31. Summary of Technical Effects Across Industries . . . . . 664
11. Detailed IETF Working-Group Relevance, Existing RFCs and
Distinct Effectuation Requirements . . . . . . . . . . . 665
11.1. RATS — Remote ATtestation procedureS, RFC 9334 . . . . . 665
11.2. TEEP — Trusted Execution Environment Provisioning . . . 665
11.3. SUIT — Software Updates for Internet of Things . . . . . 666
11.4. ACE — Authentication and Authorization for Constrained
Environments, RFC 9200 . . . . . . . . . . . . . . . . 666
11.5. COSE and CBOR — RFCs 8949 and 9052 . . . . . . . . . . . 666
11.6. OAuth — Rich Authorization Requests RFC 9396, DPoP RFC
9449 and Token Exchange RFC 8693 . . . . . . . . . . . 667
11.7. WIMSE — Workload Identity in Multi System
Environments . . . . . . . . . . . . . . . . . . . . . 667
11.8. HTTPBIS / HTTP Semantics — RFC 9110 . . . . . . . . . . 668
11.9. SCITT — Supply Chain Integrity, Transparency and
Trust . . . . . . . . . . . . . . . . . . . . . . . . . 668
11.10. NETCONF — Network Configuration Protocol, RFC 6241 . . . 668
11.11. ANIMA — Autonomic Networking Integrated Model and
Approach . . . . . . . . . . . . . . . . . . . . . . . 669
11.12. OPS Area / OPSAWG Operational Observability . . . . . . 669
11.13. DISPATCH — Security-area proposal routing after
SECDISPATCH conclusion . . . . . . . . . . . . . . . . 669
11.14. BCP 79 — RFC 8179 IETF IPR disclosure duties . . . . . . 670
12. Relevance to the EU Artificial Intelligence Act . . . . . . . 670
13. Security Considerations: Failure Conditions, Trust Assumptions
and Residual Risks . . . . . . . . . . . . . . . . . . . 671
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
13.1. Enforcement is real blocking, not telemetry . . . . . . 671
13.2. All covered equivalent routes must be considered . . . . 671
13.3. User and source authority is distinct from runtime
integrity . . . . . . . . . . . . . . . . . . . . . . . 671
13.4. Platform privilege claims must be bounded . . . . . . . 672
13.5. Protected state must be authoritative . . . . . . . . . 672
13.6. Policy changes are themselves consequences . . . . . . . 672
13.7. External effects may be irreversible . . . . . . . . . . 672
13.8. Unknown outcome is not failed outcome . . . . . . . . . 672
13.9. Evidence provenance and witness independence . . . . . . 672
13.10. Compromise of the Finality Sink is within selected trust
limits . . . . . . . . . . . . . . . . . . . . . . . . 672
13.11. Canonicalization and parser mismatch . . . . . . . . . . 672
13.12. Verification exhaustion and denial-of-service . . . . . 672
13.13. Privacy of telemetry and evidence . . . . . . . . . . . 673
13.14. Firmware and DMA command fences are platform-specific . 673
13.15. Scope of IETF standards . . . . . . . . . . . . . . . . 673
13.16. Publication chronology and patent support . . . . . . . 673
14. Patent-Examiner and Engineer Discovery: Original Source Page
and Figure Index . . . . . . . . . . . . . . . . . . . . 673
15. Foundational and Eleven-Part Companion Internet-Draft
Cross-References . . . . . . . . . . . . . . . . . . . . 674
16. Informative References . . . . . . . . . . . . . . . . . . . 675
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 680
1. Introduction: Kernel, Sandbox and Hardware Security Problem Space
AI agents can invoke terminal commands, computer-use interfaces,
coding environments, enterprise connectors, API gateways and
privileged device controls. A container or operating-system sandbox
may isolate the agent process, but an indirect broker, a network
egress path, a credential daemon, a GPU command queue, a privileged
service or a receiving resource may still have authority to cause an
externally observable consequence. The security question is not just
whether the agent process is isolated; it is whether all material
effectuation paths enforce current operation-specific authority.
Apple iOS and iPadOS applications execute under platform sandbox and
entitlement controls; Android applications use separate UIDs,
permissions and service mechanisms; desktop Linux and Windows can use
different forms of process containment and kernel policy. These
mechanisms establish platform-specific restrictions, but a permission
check or sandbox policy does not necessarily bind the eventual
resource mutation to the precise previously authorized Candidate Act.
Third-party apps generally cannot implement operating-system-wide
interception or control device firmware absent supported privileges
and provider cooperation.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An autonomous workload may ask a privileged connector to transmit
protected content, sign a transaction, deploy executable code, change
a security policy, submit accelerator jobs, reconfigure a network or
actuate hardware. The visible tool name, original source prompt,
program argument or signed approval may not be the same as the
operation actually pending at the final resource boundary. Policy
and service topology may also change between collection-time approval
and effectuation.
The protected architecture separates a proposed Candidate Act from
independent protected verification and Finality Sink control. Each
relevant operation remains non-effective until current source
authority, selected trust and attestation conditions, actual
operation correspondence, enforcement-route coverage, scoped non-
bearer finality and sink-local consumption have been checked.
Optional trusted hardware may protect parts of the process but does
not automatically verify remote effects that the hardware cannot
block.
This Part 11 draws primarily on Miscellaneous Embodiments M-1 and
M-2, Embodiments 14, 25, 26, 33 and 38, and the opening cross-
platform interoperability specification. Their individual technical
roles differ: M-1 extends coverage to new effect paths, Embodiment 14
verifies blocking enforcement against bypass, M-2 integrates existing
security mechanisms, Embodiment 25 governs sandbox-to-effect
transitions, Embodiment 26 handles tool/runtime changes, Embodiment
33 controls security-policy mutations, and Embodiment 38 qualifies
independent observation, witnesses and attestation evidence.
Part 4 separately concentrates Finality Sink reconstruction and
bypass control, Part 7 concentrates semantic tool and target
integrity, Part 9 addresses credential custody, Part 10 addresses
authority epochs, and Part 12 addresses infrastructure-wide
composition. Partial technical overlap is explicitly cross-
referenced rather than treated as evidence that a single deployed
control implements all source mechanisms.
This is an informational, source-indexed technical publication
intended for patent-examiner and industry-engineer discoverability
and independent study. It is neither an adopted IETF standard nor
proof that a named company uses the disclosed mechanisms. New
diagrams, proposed tests and illustrative algorithms are editorial
technical aids, not certified prior execution results or
automatically dated as part of the original PCT filing.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
1.1. Twelve-Part Technical Specification Series: Contents, Boundaries
and Planned References
The exact series title is "Secure AI Execution-Finality, Cross-
Platform Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series". The identifiers below are planned
individual Internet-Draft names; their possible Datatracker landing
addresses are not proof of present registration, submission or
availability. Part 1 is the foundational definitions specification.
1.1.1. Part 1 of 12 — Foundational Protected Consequential Authority,
Definitions, CW-1/CW-2/CW-3
Purpose: Foundational Protected Consequential Authority, Definitions,
CW-1/CW-2/CW-3. Planned individual Internet-Draft identifier: draft-
das-interoperable-consequence-authority-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-interoperable-consequence-
authority/ .
This is the authoritative companion for CA, NES, PED, validation,
scoped non-bearer finality, FS, and the CW-1/CW-2/CW-3 sequence.
1.1.2. Part 2 of 12 — Apple iOS, Android and Cross-Platform AI Tool
Interoperability
Purpose: Apple iOS, Android and Cross-Platform AI Tool
Interoperability. Planned individual Internet-Draft identifier:
draft-das-cross-platform-ai-interoperability-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-cross-platform-ai-
interoperability/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.3. Part 3 of 12 — Protected Source Authority, Cross-Committed
Validation Evidence and Non-Bearer Finality
Purpose: Protected Source Authority, Cross-Committed Validation
Evidence and Non-Bearer Finality. Planned individual Internet-Draft
identifier: draft-das-protected-authority-evidence-00. Prospective
URL: https://datatracker.ietf.org/doc/draft-das-protected-authority-
evidence/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
1.1.4. Part 4 of 12 — Actual-Operation Reconstruction, Finality Sink
Enforcement and Anti-Bypass
Purpose: Actual-Operation Reconstruction, Finality Sink Enforcement
and Anti-Bypass. Planned individual Internet-Draft identifier:
draft-das-finality-sink-enforcement-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-finality-sink-enforcement/
.
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.5. Part 5 of 12 — Multi-Agent Delegation, Quorums and Concurrent
Authority
Purpose: Multi-Agent Delegation, Quorums and Concurrent Authority.
Planned individual Internet-Draft identifier: draft-das-multi-agent-
authority-control-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-multi-agent-authority-
control/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.6. Part 6 of 12 — Actual-Effect Receipts and Protected Causal
Continuation
Purpose: Actual-Effect Receipts and Protected Causal Continuation.
Planned individual Internet-Draft identifier: draft-das-causal-
effect-receipts-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-causal-effect-receipts/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.7. Part 7 of 12 — AI Tool Integrity, Resource Identity and
Execution-Time Semantics
Purpose: AI Tool Integrity, Resource Identity and Execution-Time
Semantics. Planned individual Internet-Draft identifier: draft-das-
agent-tool-integrity-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-agent-tool-integrity/ .
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.8. Part 8 of 12 — Cross-Domain Effects, Transactions,
Irreversibility and Recovery
Purpose: Cross-Domain Effects, Transactions, Irreversibility and
Recovery. Planned individual Internet-Draft identifier: draft-das-
distributed-effect-recovery-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-distributed-effect-
recovery/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.9. Part 9 of 12 — Credential Custody, Operation-Bound Secrets and
Protected Data Disclosure
Purpose: Credential Custody, Operation-Bound Secrets and Protected
Data Disclosure. Planned individual Internet-Draft identifier:
draft-das-agent-credential-privacy-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-agent-credential-privacy/
.
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
1.1.10. Part 10 of 12 — Device Authority Continuity, Revocation and
Offline Execution
Purpose: Device Authority Continuity, Revocation and Offline
Execution. Planned individual Internet-Draft identifier: draft-das-
cross-device-authority-revocation-00. Prospective URL:
https://datatracker.ietf.org/doc/draft-das-cross-device-authority-
revocation/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
1.1.11. Part 11 of 12 — Kernel, Sandbox, Hardware, Runtime Transition
and Attestation Enforcement
Purpose: Kernel, Sandbox, Hardware, Runtime Transition and
Attestation Enforcement. Planned individual Internet-Draft
identifier: draft-das-hardware-execution-finality-00. Prospective
URL: https://datatracker.ietf.org/doc/draft-das-hardware-execution-
finality/ .
This Part 11 contains the sandbox, kernel, hardware, runtime-change
and independent-evidence mechanisms described below.
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecommunications, Policy
and Critical Infrastructure Finality
Purpose: Autonomous Cloud, Telecommunications, Policy and Critical
Infrastructure Finality. Planned individual Internet-Draft
identifier: draft-das-autonomous-infrastructure-finality-00.
Prospective URL: https://datatracker.ietf.org/doc/draft-das-
autonomous-infrastructure-finality/ .
Readers of this Part 11 should consult this companion for the listed
specialist mechanisms rather than infer them from a generic hardware-
isolation or identity check.
2. Patent-Pending Technical Disclosure, IETF IPR Process and
Forthcoming GitHub Implementation
The principal 8,598-page DAS technical disclosure identified for this
series is international patent application PCT/IB2026/055615, filed 4
June 2026, published as WO 2026/150382 [PCT-055615]. A different
earlier international application PCT/IB2025/058316 exists and must
not be treated as the identical June 2026 technical filing.
Application relationships, particular claim support and chronological
status require verification against authenticated as-filed documents.
The complete source converted into this twelve-part series is "iOS
and Android Interoperability for Secure Third Party AI Tools - Cross-
Platform Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Zenodo [ZENODO] (https://zenodo.org/
records/23657985, DOI 10.5281/zenodo.23657985). The page-indexed
original sections are derived from this separate specification and
are not automatically identical to the precise text present in the
June 2026 PCT.
Detailed IETF IPR disclosures identifying relevant filings, claims,
priority chains, affected Internet-Drafts and licensing information
are intended to be submitted or updated separately in accordance with
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
applicable BCP 79 obligations. The statement inside this
informational draft is not itself a substitute for an official IETF
IPR disclosure, nor a legal opinion on patent validity, ownership,
priority or infringement.
A GitHub reference implementation, test harness, sample artifacts and
reproducibility instructions are intended to be added by a later
version after the public repository and its contents can be verified.
No repository URL, completed experiment, external certification or
official product implementation is asserted at this stage.
An Internet-Draft or Zenodo publication may be publicly discoverable;
however, exact prior-art dates and legal consequences depend on what
was actually available to the public and the applicable law. Source-
derived content and newly written reference designs are distinguished
throughout.
3. Keywords: Industry-Recognized Security and Patent-Examiner Discovery
Terms
AI agent security; secure AI agents; prompt injection; AI tool
execution; operating system sandbox; iOS security; iPadOS App
Sandbox; Apple macOS security; Google Android security; Android
application permissions; Android Binder IPC; Linux kernel security;
seccomp; eBPF; Linux Security Modules; container isolation; microVM
security; Windows security; virtualization-based security; privileged
service; credential broker; finality sink; Candidate Act; Non-
Effective State; Protected Enforcement Domain; actual operation
verification; non-bearer capability; execution finality; hardware-
backed authorization; Arm TrustZone; Android Keystore; secure
enclave; Qualcomm Snapdragon; NVIDIA BlueField; GPU command
isolation; DMA fencing; accelerator egress; hardware command queue;
privileged network proxy; OS sandbox bypass; policy hot-swap;
firmware rollback; tool lifecycle attestation; sandbox-to-production
deployment; secure boot; runtime measurement; trusted execution
environment; remote attestation; RATS; TEEP; SUIT; ACE; COSE; CBOR;
OAuth; WIMSE; cross-committed evidence; monotonic protected state;
effectuation coverage; replay prevention; secure signing; SCITT
transparency; critical infrastructure; telecommunications equipment;
embedded systems; patent technical disclosure.
4. Foundational Terms, Trust Boundaries and Mandatory-versus-Optional
Security Properties
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
4.1. Candidate Act and Non-Effective State
A Candidate Act (CA) describes an intended consequential operation.
A Non-Effective State (NES) means that the operation may be prepared
or represented but cannot yet cause the protected effect. A
successfully executed unprivileged instruction is not itself evidence
that the resulting privileged resource mutation is authorized.
4.2. Protected Enforcement Domain
A Protected Enforcement Domain (PED) independently validates
qualified source authority, evidence and enforcement dependencies.
It may be realized by a suitably protected service, OS-level
mediation, trusted computing module or distributed arrangement; no
commercial hardware is universally required.
4.3. Finality Sink and Actual Operation
A Finality Sink is the controlling boundary able to withhold or
permit the specific consequential operation. It must reconstruct or
obtain protected facts about the actual pending operation and compare
them with current qualified evidence, scope, source authority and
protected consumption state.
4.4. Coverage versus Monitoring
An audit sensor or network monitor may observe an operation without
possessing the mandatory blocking control needed to prevent it. Only
effect paths demonstrated to have suitable preventive enforcement
satisfy a required blocking-coverage predicate.
4.5. Scoped Non-Bearer Authority
Scoped non-bearer finality enablement is tied to the actual
operation, authorized scope, designated sink and relevant current
protected state. A copied reference or bearer token is not
automatically exercisable against another sink or effect.
4.6. Hardware Attribution and Attestation
Attestation can qualify claims about device or runtime state under
its specified trust assumptions. It does not prove original user
authorization or actual remote resource completion. DMA controllers,
accelerators, device queues and firmware-controlled paths may require
independent qualified barriers.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
4.7. Live Policy and Runtime Generations
Changes to tool software, policy rules, permission adapters,
privileged worker wiring or enforcement-path topology may invalidate
earlier effect authority. Protection depends on qualified generation
and state transitions, not merely a signed previous baseline.
4.8. Independent Evidence and Witness Compromise
Qualified evidence can require separation of collection-time and
execution-time observations, appraised witness competence,
independence checks and evidence commitments. Compromised or
replayed witness output must not be accepted as conclusive finality
merely because it carries a valid signature.
4.9. Supported Integration Boundaries
Public mobile application APIs cannot be presumed to provide a
system-wide non-bypassable kernel hook. Claims for Android, iOS,
Windows, Linux, radio firmware and protected silicon are conditional
on actual supported interfaces and explicit cooperation from relevant
platform/resource owners.
5. Original Technical Disclosure: Page-Indexed Source with Architecture
and Operational Figures
The following subsections preserve the technical PDF text page by
page, associated with newly authored architecture and decision-flow
explanatory figures. PDF text extraction may normalize line wrapping
and ligatures. When an extraction differs from the archived PDF
image, the original page is authoritative. Figure descriptions and
algorithms do not claim preexisting as-filed patent date or
successful prototype implementation.
5.1. Source Foundation: Cross-Platform Native Permissions and
Independent Consequence Authority
Original source global pages 1–14; attachment TECHNICAL SPECIFICATION
-1-554.pdf. Figures depict an explanatory implementation mapping of
this disclosed embodiment or supporting material; all trust
limitations and optionality in the original text remain applicable.
5.1.1. Architecture Diagram: Protected Components and Trust Boundaries
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[User / competent source authority]
|
[Apple / Android / desktop adapter]
|
[Canonical effect descriptor / CA / NES]
|
[Protected validation and scoped enablement]
|
[Designated actual resource Finality Sink]
|
[Qualified effect OR withholding]
Figure 1: Source Foundation: Cross-Platform Native Permissions
and Independent Consequence Authority: architecture
5.1.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Agent requests operation]
|
<Source grant for actual effect?>--NO-->[WITHHOLD]
| YES
<OS assertion narrowly qualified?>--NO-->[WITHHOLD]
| YES
[Check resource, sink and current evidence]
|
<Actual effect matches and is controlled?>--NO-->[REFUSE]
| YES
[Atomic consumption / effect]
Figure 2: Source Foundation: Cross-Platform Native Permissions
and Independent Consequence Authority: operational decision flow
5.1.3. Page-Indexed Original Technical Text
5.1.3.1. Original Global Page 1
TITLE OF THE INVENTION
SYSTEMS AND METHODS FOR CROSS-PLATFORM INTEROPERABLE EXECUTION-
FINALITY CONTROL, PROTECTED AUTHORITY CONTINUITY, AND CONSEQUENCE
ENFORCEMENT ACROSS HETEROGENEOUS OPERATING SYSTEMS, DEVICES, AND
AUTONOMOUS COMPUTING ENVIRONMENTS
ABSTRACT
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Disclosed are systems and methods for interoperable protected
execution-finality control across heterogeneous operating systems,
including Android, iOS, and other mobile, desktop, cloud, and
embedded environments. A proposed consequential operation is
represented as a Candidate Act and retained in a Non-Effective State.
Platform-specific adapters translate qualified authorization,
identity, application, device, and security evidence into a protected
canonical effect descriptor without converting upstream permission
into execution authority. A Protected Enforcement Domain verifies
originating and delegated authority, current revocation, operation
semantics, and enforcement-path coverage, and constitutes scoped non-
bearer finality enablement. A designated Finality Sink independently
obtains or reconstructs the actual pending operation, verifies its
correspondence with protected evidence and current sink-local state,
and controls authorization consumption before effectuation. Cross-
device transfer may employ authenticated ownership epochs and source
fencing. Unavailable mandatory enforcement causes withholding. The
architecture preserves vendor-independent authority semantics while
accommodating distinct platform security mechanisms and covered
consequential interfaces.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to computer security,
operating-system interoperability, protected execution control,
autonomous artificial-intelligence systems, distributed
authorization, trusted computing, and the governance of consequential
operations across heterogeneous computing environments.
More particularly, the invention concerns systems, methods,
apparatus, machine-readable authorization structures, protected
execution components, and interoperable enforcement protocols for
preserving and verifying execution authority when applications,
autonomous agents, services, computational workloads, or device-
control functions operate across different operating systems,
hardware architectures, administrative domains, security substrates,
and communication environments.
The invention is applicable to mobile operating systems, including
Android, iOS, iPadOS, and other mobile platforms; desktop operating
systems, including macOS, Windows, Linux, and other computing
environments; and wearable devices, embedded controllers,
communication systems, cloud infrastructures, confidential-computing
environments, virtual machines, autonomous robots, vehicles, and
future computing platforms.
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.1.3.2. Original Global Page 2
The named operating systems and commercial environments are
illustrative, non-limiting examples. The invention does not require
participation by any particular operating-system provider,
manufacturer, application ecosystem, or proprietary technology.
2. Increasing Fragmentation of Operating-System and Application
Security
Modern computing environments comprise multiple independently
administered operating systems, application ecosystems, device
manufacturers, identity providers, cloud services, and security
architectures.
Different platforms may implement substantially different mechanisms
for application isolation, permission enforcement, credential
storage, interprocess communication, secure execution, hardware-
backed cryptographic operations, network control, user approval, and
access to sensitive resources.
For example, one operating system may expose selected protected
application interfaces, permission services, secure hardware
functions, and controlled background-execution facilities, while
another operating system may provide different forms of application
sandboxing, entitlement verification, privileged-service mediation,
or device-security interfaces.
These mechanisms may individually provide useful technical security
properties, but their differences complicate the preservation of a
consistent and independently enforceable authorization relationship
when a computational task crosses platform boundaries.
A permission recognized by one operating system is not necessarily
semantically equivalent to an entitlement, authorization, credential,
or protected resource grant recognized by another.
Likewise, the ability of one application or service to request an
operation does not establish that a receiving application, operating
system, privileged controller, or remote resource is authorized to
produce the requested consequential effect.
Accordingly, interoperability between computing environments requires
more than the exchange of commands, files, credentials, permissions,
application messages, or authenticated identities.
3. Limitations of Conventional Cross-Platform Interoperability
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Conventional interoperability systems commonly enable information
exchange, task synchronization, remote procedure invocation,
application linking, cross-device communication, identity federation,
and service-to-service authorization.
Such mechanisms may permit a task initiated in a first environment to
continue in a second environment.
However, technical interoperability does not necessarily establish
interoperable execution authority.
An application operating in an Android-based environment may generate
a request intended to produce an effect within an iOS-based
environment, or vice versa.
5.1.3.3. Original Global Page 3
The receiving environment may authenticate the sending application,
accept a structured request, recognize a permitted service identity,
or validate a delegated credential.
Nevertheless, the requested operation may differ materially from the
operation originally authorized by the relevant principal.
The difference may concern the actual resource, recipient, outgoing
information, operation parameters, current resource version,
delegated scope, original authorization conditions, or applicable
device-security state.
A successful communication handshake, authenticated application
request, or cross-platform permission translation therefore does not,
by itself, establish authority for the actual consequential
operation.
4. Absence of Uniform Execution-Finality Semantics
Existing operating systems and application frameworks frequently
distinguish among authenticated identities, permissions, application
capabilities, hardware entitlements, and resource-access policies.
However, those mechanisms do not necessarily implement the same
technical meaning of final authorization at the boundary where a
consequential operation becomes effective.
An approval generated in one domain may be consumed by an
intermediary service in another domain, while the ultimate resource
modification occurs through a different component.
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A receiving component may interpret the approved operation
differently, apply a different authorization scope, or invoke an
additional privileged interface.
Consequently, upstream authorization may become detached from the
actual operation eventually executed.
This problem becomes particularly significant when the operation
concerns persistent data modification, confidential information
export, credential activation, financial instructions, network
transmission, device configuration, physical actuation, or another
consequential operation.
There remains a technical need for a platform-independent
representation of protected consequential authority whose operative
meaning is verified at the actual effectuation boundary rather than
inferred solely from the success of an upstream permission mechanism.
5. Autonomous Artificial-Intelligence Agents and Cross-Platform
Execution
Autonomous AI agents and computational assistants increasingly
perform tasks involving multiple applications, devices, execution
environments, and remotely administered services.
An agent may receive an instruction on a mobile device, perform
planning using a remote computational service, delegate part of the
task to another agent, retrieve information from a third-party
application, and subsequently request a consequential operation
through a different platform.
5.1.3.4. Original Global Page 4
The original task may pass through several computational
transformations, including model inference, tool selection, message
translation, task delegation, application-interface invocation, and
execution-context migration.
These transformations may alter the representation of the requested
operation without necessarily establishing renewed authority from the
originating principal.
Moreover, autonomous agents may encounter malicious instructions,
compromised external content, stale task context, incorrect resource
references, hallucinated operation parameters, or manipulated tool
responses.
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A computational system may therefore generate a technically
executable command that exceeds the scope of the original
authorization.
Merely isolating the agent within a sandbox, authenticating its
identity, or restricting access to selected tools does not
necessarily prevent an unauthorized effect through another accessible
execution route.
The fundamental technical issue is the separation between
computational capability and independently established authority to
cause a real consequence.
6. Cross-Device Authority Duplication and Migration
Cross-device continuity presents additional security and consistency
problems.
When a task moves between devices, the transfer may include
application state, execution context, cached credentials, model
state, memory, instructions, command queues, or unfinished
operations.
However, transferring computational state does not automatically
transfer valid authority to perform consequential operations.
Similarly, transferring a task to a receiving device does not
automatically invalidate effectuation authority remaining on the
originating device.
For example, a user may initiate an autonomous workflow on one mobile
operating system and continue the workflow on another mobile or
desktop environment.
If both environments retain independently usable authority for the
same unfinished operation, duplicate or conflicting consequences may
occur.
A stale device may also resume after suspension, recover an outdated
application state, or attempt to exercise authority that has already
been transferred, revoked, consumed, or superseded.
Conventional data synchronization alone does not necessarily
establish exclusive execution ownership, protected authority epochs,
source-device fencing, or destination-local validation of the actual
consequential operation.
7. Inconsistent Enforcement Capabilities Across Platforms
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Different operating systems and devices expose different levels of
control over applications, privileged services, network
communications, storage operations, hardware functions, and security-
sensitive interfaces.
5.1.3.5. Original Global Page 5
Some environments permit enforcement through operating-system
security components or protected hardware controllers.
Other environments may permit only application-level mediation,
approved extension interfaces, managed-service gateways, server-side
authorization, or remote resource enforcement.
Certain security mechanisms provide blocking capability, while others
provide observation, logging, notification, policy advice, or post-
operation auditing.
A system that merely receives a security event cannot necessarily
prevent the corresponding effect.
Likewise, a system that controls one application interface may not
control an alternative interface capable of producing the same
consequence.
A generic interoperability layer that assumes identical operating-
system privileges or uniform enforcement interfaces may therefore
provide incomplete protection when deployed across heterogeneous
platforms.
A need exists to determine the actual enforcement capability of each
participating security mechanism and to qualify whether the relevant
effectuation path is subject to mandatory protected control.
8. Limitations of Credential-Based and Permission-Based Approaches
Conventional authorization systems may use access tokens,
cryptographic signatures, structured permission grants, proof-of-
possession protocols, mutual authentication, credential brokers,
hardware-backed keys, and delegated authorization.
These mechanisms provide valuable security functions.
However, successful authentication, credential validity, permission
possession, or cryptographic proof does not necessarily establish
that a particular resource-side consequential operation remains
authorized at execution time.
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An access token may remain valid while the operation exceeds its
intended effect scope.
A cryptographic signature may authenticate an earlier approval while
the actual destination, resource identity, operation semantics, or
policy state has changed.
A credential broker may possess technical authority to perform a
broad range of operations even when the requesting agent is permitted
to initiate only one narrowly defined action.
Accordingly, the security problem is not resolved merely by
transferring, translating, exchanging, or validating credentials
between operating systems.
The actual consequential effect must remain independently bound to
current protected authority.
9. Revocation, Replay, and Distributed-State Problems
Cross-platform environments may maintain authorization and revocation
state in multiple administrative domains.
5.1.3.6. Original Global Page 6
A source device may revoke authority while a destination device
remains disconnected.
A remote service may receive a revocation notification after a
previously authorized operation has already entered a queue.
A cached permission decision may remain locally available after the
underlying grant has expired or changed.
Similarly, a previously generated authorization artifact may be
copied, replayed, presented to another execution sink, or restored
through an outdated application or virtual-machine snapshot.
These conditions create technical risks involving stale authority,
duplicate effectuation, inconsistent consumption accounting, and
delayed enforcement of revocation.
Immediate revocation cannot be assumed in a disconnected receiving
domain without an appropriate supporting mechanism.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Interoperable execution control must therefore account for authority
generations, bounded validity, protected consumption state,
revocation dependencies, and conservative handling of uncertain
distributed conditions.
10. Technical Problem Addressed by the Invention
In view of the foregoing limitations, there exists a need for an
interoperable protected execution architecture capable of governing
consequential operations across heterogeneous operating systems,
devices, applications, and administrative domains without requiring
identical security implementations or transferring unrestricted
authority between them.
More particularly, the technical problem is how to:
(a) preserve the scope and identity of originating execution
authority across different platforms;
(b) translate heterogeneous authorization and security evidence into
a machine-verifiable, operation-specific effect representation;
(c) prevent a computational request, authenticated identity,
credential, or platform permission from independently constituting
final authority;
(d) maintain proposed consequential operations in an enforceable non-
effective condition;
(e) establish protected finality enablement dependent upon current
authority, revocation, security context, and applicable enforcement
capability;
(f) independently verify the actual pending consequential operation
at the receiving resource or device boundary;
(g) prevent unauthorized replay, stale-owner execution, cross-
platform scope expansion, or duplicate effectuation;
(h) support bounded delegation and authenticated transfer of
execution authority between heterogeneous environments; and
5.1.3.7. Original Global Page 7
(i) preserve the required security properties even when different
platforms employ different software, hardware, communication, and
authorization mechanisms.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The present invention addresses these technical problems through a
protected, operation-specific execution-finality architecture having
interoperable authority semantics and qualified platform-specific
enforcement implementations.
SUMMARY OF THE INVENTION
1. General Overview
The present invention provides systems, methods, apparatus, protected
execution components, interoperable authorization protocols, machine-
verifiable records, and computer-implemented procedures for governing
consequential computational operations across heterogeneous operating
systems and computing environments.
The disclosed architecture is applicable to Android, iOS, and other
mobile operating systems, together with desktop, cloud, edge,
embedded, industrial, network, robotic, and future autonomous
computing systems.
The invention does not require the participating environments to
implement identical operating-system kernels, security frameworks,
application permission models, hardware architectures, cryptographic
processors, or proprietary communication protocols.
Instead, the architecture establishes a common protected execution-
finality relationship in which a proposed operation remains non-
effective until the required operation-specific authority is
established and verified by a technical boundary capable of
withholding the governed consequence.
The foundational principle is that computation is not authority to
act.
The production, transmission, translation, delegation, or receipt of
a computational request does not automatically establish authority to
produce its external or persistent effect.
2. Platform-Independent Execution-Finality Framework
In one implementation, the system comprises a Requesting
Computational Entity, a Candidate Act construction component, a Non-
Effective Holding Mechanism, one or more Protected Enforcement
Domains, protected authorization and evidence adapters, an authority
preparation component, and at least one designated Finality Sink.
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The requesting computational entity may operate within a mobile
application, autonomous assistant, operating-system service, cloud
agent, remote tool, embedded controller, or other computational
workload.
A proposed consequential operation is represented as a Candidate Act
containing or referencing the security-relevant identity, operation
class, resource, destination, parameters, originating authority, and
applicable execution context.
The proposed operation is maintained in a Non-Effective State by an
enforceable holding mechanism until the relevant protected conditions
are satisfied.
5.1.3.8. Original Global Page 8
A protected authority controller verifies applicable evidence and
establishes scoped execution-finality enablement.
The actual Finality Sink obtains or reconstructs the pending
consequential operation and determines whether it corresponds to the
protected authorization before permitting the effect.
The number, placement, and physical implementation of the
participating components may vary according to the selected platform
and threat model.
3. Interoperability Between Android, iOS, and Other Operating
Systems
In a non-limiting embodiment, the invention provides interoperable
protected execution-finality control between computing environments
operating different mobile operating systems, including Android-based
and iOS-based devices.
A consequential operation initiated within a first platform may be
represented using a protected canonical effect descriptor and
communicated to an authorized receiving component operating within a
second platform.
The receiving component does not automatically treat the originating
platform's permission, application entitlement, authenticated
message, or credential as sufficient authority to cause the requested
effect.
Instead, the receiving platform applies its own qualified protected
verification and enforcement mechanisms while preserving the required
operation-specific authorization conditions.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
For example, a task originating within an Android-based application
may be evaluated by a protected authorization service and
subsequently presented to a controlled application function, resource
gateway, or qualified effectuation component associated with an iOS-
based environment.
Conversely, a task originating in an iOS-based environment may be
submitted to a protected resource interface associated with an
Android-based environment.
In either direction, execution remains dependent upon independently
verified authority, current applicable state, and the actual
consequential operation.
The same technical relationship may apply to interoperability
involving iPadOS, macOS, Windows, Linux, other mobile or desktop
systems, cloud services, embedded platforms, and subsequently
developed operating systems.
The invention does not presume that any operating system exposes
unrestricted kernel, application, network, or hardware interception
facilities. Enforcement is implemented through qualified interfaces
actually available and authorized within the relevant deployment,
including protected application dispatchers, privileged brokers,
managed resource controllers, remote enforcement gateways, and
destination-side Finality Sinks.
4. Protected Authorization-to-Effect Translation
5.1.3.9. Original Global Page 9
In another aspect, the invention provides a protected translation
mechanism configured to obtain authorization and security information
from heterogeneous source systems and convert the relevant
information into a bounded consequential-operation representation.
The source information may comprise identity assertions, application
permissions, delegated authorization records, structured action
descriptions, protected device state, cryptographic authentication
evidence, resource-access restrictions, or other qualified security
information.
A protected translation controller determines the actual technical
meaning of the requested operation and produces or verifies a
canonical effect descriptor.
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The descriptor may identify an originating principal, requesting
component, actual operation class, resource identity, effective
recipient, operation parameters, permitted effect envelope, relevant
policy state, and designated enforcement boundary.
Different platforms may employ different native permission names or
resource-interface structures while using equivalent protected effect
semantics for the specific governed operation.
A source permission is not silently expanded merely because the
receiving platform implements a broader technical operation.
Where the protected translation cannot establish the necessary
correspondence, the affected consequential operation remains
withheld.
5. Independent Protected Authority Across Platform Boundaries
The invention further provides a Protected Enforcement Domain
configured to evaluate applicable originating authority, delegated
scope, current resource conditions, relevant revocation dependencies,
security-substrate qualifications, and operation-specific validation
evidence.
The Protected Enforcement Domain may comprise a protected operating-
system component, independently secured service, secure processor,
trusted execution environment, hardware controller, remote protected
validator, or compatible combination thereof.
In implementations requiring separate collection-time and execution-
time validation, corresponding protected evidence instances may
independently evaluate the applicable Candidate Act and establish
authenticated evidence commitments.
A protected finality controller may subsequently create, activate,
derive, sign, or otherwise constitute scoped non-bearer execution
enablement.
Such enablement may be bound to the specific operation, permitted
effect, resource identity, designated sink, relevant authority
generation, current enforcement coverage, validity conditions, and
protected consumption state.
The enablement need not be provided to the requesting application as
a reusable transferable credential.
6. Independent Finality Sink Verification
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.1.3.10. Original Global Page 10
A principal aspect of the invention is the independent verification
of the actual pending operation at its consequential enforcement
boundary.
The Finality Sink may comprise a protected application-function
dispatcher, network gateway, storage transaction controller,
credential-release interface, cloud API enforcement component, device
command controller, hardware interface, payment dispatcher, or other
qualified effectuation mechanism.
The Finality Sink obtains or reconstructs relevant actual operation
parameters from the controlled effectuation path.
The sink compares the pending operation against the authorized effect
descriptor, protected validation evidence, scoped finality
enablement, current authority state, and applicable sink-local
protected state.
A material mismatch, stale authorization, unqualified enforcement
path, revoked permission, unsupported resource identity, or invalid
authority-consumption condition prevents the governed operation from
becoming effective.
Where single-use or bounded-use authorization applies, the relevant
protected consumption transition is enforced before the corresponding
consequence is released.
7. Cross-Device Execution Authority Continuity and Migration
In another embodiment, the invention enables the controlled migration
or reestablishment of unfinished execution authority between
heterogeneous computing environments.
A computational workflow may move between smartphones, tablets,
desktop computers, cloud instances, edge devices, virtual machines,
hardware accelerators, or other computational systems.
The movement of computational state is distinguished from the
transfer of authority to produce consequential effects.
Where exclusive operation ownership is required, the system may
establish authenticated device identities, protected ownership
generations, monotonic authority epochs, source-device fencing, and
destination-specific finality enablement.
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A previous execution environment is prevented, through the applicable
protected enforcement mechanisms, from exercising stale authority
after exclusive effectuation ownership has been transferred.
The destination Finality Sink independently verifies current
ownership, authorized effect scope, actual operation parameters, and
protected consumption state.
A copied task image, migrated process, restored snapshot, or
transferred credential reference does not independently create or
duplicate execution authority.
8. Cross-Provider and Cross-Agent Interoperability
5.1.3.11. Original Global Page 11
The architecture may additionally support interoperability between
computational agents and application services administered by
different providers.
An originating principal may authorize a bounded task that is
subsequently delegated through one or more agents, services, devices,
or administrative domains.
Protected delegation records may preserve originating authority
references, delegated scope, relevant resource limits, current
revocation dependencies, and authenticated delegation relationships.
A receiving agent may perform authorized computation without
receiving unrestricted authority over the originating principal's
resources.
Where a consequential operation is delegated, the receiving Finality
Sink verifies the current authorized scope and the actual pending
effect.
The transfer of task information, agent messages, inference results,
or executable instructions does not itself enlarge the original
permitted authority.
9. Dynamic Platform-Security Qualification
In another aspect, the invention provides a mechanism for qualifying
heterogeneous security components according to the properties they
actually establish.
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected controller may identify whether a selected security
mechanism provides authentication, observation, advisory policy
evaluation, isolation, revocation notification, resource control, or
mandatory blocking of a specified effect.
The controller may maintain protected enforcement-qualification
records identifying the current security component, controlled
resource, enforcement mode, operation-visibility capability,
applicable configuration generation, and unresolved bypass
conditions.
A component is not treated as equivalent to another merely because
both are described as security mechanisms.
A replacement operating-system interface, application gateway,
sandbox mechanism, cryptographic provider, or hardware controller
must provide the properties required for the corresponding protected
operation.
Material changes to enforcement capability or relevant execution
semantics may invalidate dependent finality authorization until
revalidation is completed.
10. Interoperability Through Existing and Future Technical
Mechanisms
The invention may employ existing authorization protocols,
authenticated communication mechanisms, structured operation
representations, interprocess communication, cryptographic
signatures, protected key storage, secure processors, transactional
state stores, and resource-side enforcement interfaces.
Such mechanisms are individually usable as established technical
implementation substrates.
5.1.3.12. Original Global Page 12
In selected embodiments, typed JSON, CBOR, deterministic binary
encodings, or other canonical machine-readable representations may
communicate protected operation and evidence information.
Platform-specific adapters may translate native authorization or
application-operation representations into the required interoperable
protected structures.
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The architecture is not restricted to one serialization format,
cryptographic algorithm, permission framework, application-
development environment, transport protocol, or processor instruction
set.
The operative requirements concern the preservation of protected
authority dependencies, correct actual-operation correspondence,
sufficient enforcement coverage, and verified finality control.
11. Revocation, Replay Prevention, and Protected State Continuity
The invention may maintain protected authorization generations,
revocation references, consumption records, device-ownership epochs,
current resource state, and relevant enforcement-coverage
information.
Before releasing an operation, the applicable Finality Sink verifies
the protected state required by the selected implementation.
Previously valid authorization may be rejected when the source
authority has been revoked, the relevant resource has materially
changed, or the permitted authority has already been consumed.
A replayed or misdirected finality reference does not automatically
authorize another operation or a different Finality Sink.
Disconnected environments may employ bounded offline authority,
protected counters, expiry constraints, or other conservative
validity mechanisms where technically supported.
Where current mandatory authorization cannot be established, the
corresponding governed consequence remains withheld rather than being
released on the assumption that earlier authorization remains valid.
12. Platform-Independent Security Without Mandatory Vendor
Dependence
The invention is not limited to a specific commercial operating
system, manufacturer, application store, cloud provider, hardware-
security product, AI model, or agent framework.
Its implementation may use different qualified security substrates
for different effect classes and deployment environments.
For example, one implementation may use a protected application
gateway, another may use a privileged operating-system resource
controller, and another may use a hardware-backed Finality Sink or
independently controlled remote service.
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An implementation need not reproduce the internal architecture of
another operating system to establish a protected execution-finality
relationship over operations that it can actually govern.
5.1.3.13. Original Global Page 13
Where a particular platform does not provide an authorized mechanism
capable of withholding a selected local operation, the architecture
does not assume that such an operation is protected by a merely
observational interface. Protection may instead be implemented at an
available qualified resource, service, gateway, or destination
boundary, subject to the corresponding enforcement coverage.
Accordingly, interoperability concerns equivalent protected
execution-authority semantics and enforceable consequence control
rather than mandatory uniformity of proprietary platform mechanisms.
13. Optional Specialized Technical Extensions
The disclosed architecture may be combined with compatible
specialized verification mechanisms described in the specification.
Such mechanisms may include protected cross-agent conflict
coordination, semantic correspondence between a user-selected object
and an actual operation target, cumulative privacy-exposure
constraints, delegated-authority conservation, operation-semantics
continuity, hardware command control, protected physical-state
validation, authenticated actual-effect evidence, and receipt-gated
causal continuation.
Where an operation requires one of these specialized conditions, the
applicable condition may become a mandatory predicate of that
operation's finality authorization.
However, the presence of an optional verification mechanism in one
embodiment does not make the mechanism universally necessary for
every implementation.
Each embodiment may select the components required for the particular
consequential effect and intended technical trust model.
14. Technical Advantages and Effects
The disclosed invention seeks to provide a common protected
execution-finality framework across heterogeneous operating systems
and computing environments while accommodating their different native
security implementations.
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The architecture can provide operation-specific protection against
authorization-to-effect mismatches, stale permission use,
unauthorized scope expansion, duplicate effectuation, cross-device
authority conflicts, and selected enforcement-bypass conditions
within the coverage of the implementation.
It distinguishes the authority to compute, transmit, delegate,
authenticate, or access a tool from the protected authority required
to produce a particular real-world or persistent consequence.
The invention may further preserve authority continuity when a
workflow moves across Android, iOS, other operating systems,
independent applications, remote agents, and cloud or hardware
execution environments.
Unlike an architecture that relies solely upon uniform platform
permissions or transferable credentials, the disclosed relationship
conditions consequential effectuation upon independently verified
protected authority and actual-operation correspondence at a
qualified enforcement boundary.
5.1.3.14. Original Global Page 14
The resulting framework enables heterogeneous platforms to contribute
different security mechanisms while retaining the required protected
relationships between original authority, consequential operation,
current state, and final effectuation.
15. Scope and Non-Limiting Character of the Disclosure
The foregoing summary describes representative implementations and is
not intended to restrict the invention to a particular arrangement,
operating system, software framework, network architecture, security
processor, cryptographic protocol, or commercial implementation.
Compatible features described in the specification may be employed
independently or in combination, subject to their applicable
technical requirements.
The disclosed algorithms, machine-readable records, state
transitions, reference implementations, examples, and experimental
procedures are illustrative and non-limiting aids to enable a person
having ordinary skill in the art to implement the corresponding
embodiments.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A component may perform multiple logical functions, and selected
functions may be distributed across independently protected domains,
provided that the technical properties expressly required by the
relevant implementation are preserved.
The invention encompasses present and future qualified
implementations of interoperable execution-finality control across
heterogeneous computing environments, within the scope supported by
the detailed disclosure and the appended claims.
5.2. Miscellaneous Embodiment M-1: Dynamic Enforcement-Path and
Hardware Resource Coverage
Original source global pages 555–609; attachment TECHNICAL
SPECIFICATION -555-1062.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.2.1. Architecture Diagram: Protected Components and Trust Boundaries
[Agent tools and runtime interfaces]
|
[Discover effect-capable path inventory]
|
[Canonical operation contract + aliases]
|
[Qualified blocking controllers per path]
|
[Current coverage epoch and protected state]
|
[Finality Sink reconstructs actual operation]
|
[Permit only covered scoped effects]
Figure 3: Miscellaneous Embodiment M-1: Dynamic Enforcement-Path
and Hardware Resource Coverage: architecture
5.2.2. Operational Flowchart: Verification, Withholding and
Effectuation
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[New tool, route, GPU or device path]
|
<Path coverage discovered and complete?>--NO-->[FENCE]
| YES
<Actual blocking, not monitoring only?>--NO-->[FENCE]
| YES
[Commit current coverage and effect contract]
|
<Sink matches current coverage epoch?>--NO-->[WITHHOLD]
| YES
[Scoped check-and-consume / effect]
Figure 4: Miscellaneous Embodiment M-1: Dynamic Enforcement-Path
and Hardware Resource Coverage: operational decision flow
5.2.3. Page-Indexed Original Technical Text
5.2.3.1. Original Global Page 555
The successor Finality Sink independently verifies the actual pending
operation before effectuation.
The architecture may additionally employ witness independence
policies, remote state-consistency checks, privacy-preserving
evidence, protected outcome-reconciliation fences, and separately
authorized recovery operations.
The disclosed mechanisms are applicable across heterogeneous
administrative and computing domains without assuming that every
remote service provides complete verifiability.
The central proposed technical contribution is an enforceable
relationship between a protected originating Candidate Act, an
independently supported remote consequence predicate, authenticated
cross-domain outcome evidence, and separately scoped successor
execution authority.
The architecture distinguishes operation authorization, remote
request acceptance, observed state, operation-specific causation, and
sufficiently established remote finality.
The inventive step of any claimed combination remains subject to
examination against established remote attestation, transactional
state verification, distributed authorization, audit receipts,
verifiable data structures, and other relevant prior disclosures.
END OF EMBODIMENT 4.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
MISCELLANEOUS EMBODIMENT M-1
MODULAR FUTURE-ADAPTABLE PROTECTED EFFECTUATION INFRASTRUCTURE WITH
DYNAMIC ENFORCEMENT-PATH COVERAGE, OPERATION-SEMANTICS CONTINUITY,
CROSS-INTERFACE RESOURCE CORRESPONDENCE, DISTRIBUTED AUTHORITY
ATTENUATION, PRIVACY AND RESOURCE-STATE GOVERNANCE, AND HETEROGENEOUS
HARDWARE EXECUTION CONTROL
M-1.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Modular, Cross-Platform, and Future-Adaptable
Autonomous Execution-Finality Enforcement Using Protected
Effectuation-Surface Discovery, Dynamic Action-Contract Verification,
Cross-Interface Resource Identity, Cryptographically Authenticated
Delegated Authority, Protected Credential-Release Control, Resource-
Constrained Validation, Enforcement-Coverage Reattestation, and
Optional Distributed Hardware and Software Security Mechanisms
M-1.0.1 — General Characterization
The present Miscellaneous Embodiment M-1 discloses additional
optional systems, methods, apparatus, protected computing components,
authenticated protocols, machine-verifiable data structures,
protected state transitions, hardware mechanisms, and software
enforcement arrangements for extending protected execution-finality
control across existing and emerging autonomous computing
environments.
The embodiment is intended to provide concrete technical
implementation support for supplementary features identified within
Common Master Workflow CW-1, including the optional
5.2.3.2. Original Global Page 556
technical concepts, advanced future-oriented variations, and combined
protected enforcement arrangements.
The embodiment is applicable to artificial-intelligence agents,
autonomous applications, multi-agent orchestration, operating-system
services, distributed computing services, protected devices, cloud
infrastructure, embedded systems, telecommunications equipment,
secure storage controllers, heterogeneous computing processors,
hardware accelerators, robotic systems, enterprise systems, and other
computational environments capable of producing consequential
effects.
In a representative implementation, a computational entity generates
a proposed consequential operation.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected system identifies the actual effectuation surfaces
through which the operation or an equivalent operation may produce
the intended consequence.
It establishes a machine-verifiable operation descriptor, identifies
the applicable operation semantics, resolves relevant resource
identities, determines the protected authority required for the
effect, and verifies the existence and validity of the necessary
enforcement coverage.
Where applicable, additional modules evaluate delegation lineage,
cumulative resource use, privacy exposure, semantic correspondence,
execution-environment integrity, or other protected conditions.
The corresponding Finality Sink obtains or reconstructs the actual
pending operation and independently verifies its scope, current
authority, and protected state before permitting the governed
consequence.
The disclosed additional mechanisms may be implemented individually
or in technically compatible combinations.
No particular supplementary mechanism is universally mandatory for
all implementations of Common Master Workflow CW-1.
M-1.0.2 — Relationship to Completed Embodiments
Embodiment 1 concerns protected cross-agent effect-conflict
arbitration.
Embodiment 2 concerns independently validated causal phase
continuation and the receipt-dependent authority mechanisms
associated with actual earlier effects.
Embodiment 3 concerns protected correspondence between an authorized
user-referenced object and the actual effectuation target.
Embodiment 4 concerns independently qualified evidence of
consequential effects occurring across administrative or computing
domains.
Miscellaneous Embodiment M-1 does not replace or amend those
embodiments.
It develops additional technical mechanisms involving enforcement
coverage, operation-contract continuity, authority portability,
privacy composition, heterogeneous hardware, resource-bounded
verification, and emerging autonomous computing environments.
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Where necessary, an implementation may invoke mechanisms from the
earlier embodiments without restating their complete technical
procedures.
5.2.3.3. Original Global Page 557
M-1.0.3 — Modular Character
The present embodiment may operate as one or more supplementary
verification modules associated with a Protected Enforcement Domain,
a Finality Sink, an authenticated controller, a distributed authority
service, or another suitable protected component.
For example, one implementation may use only dynamic effectuation-
path coverage and post-update reattestation.
Another may use only cross-provider delegation and protected
credential-release binding.
Another may use only bounded-latency validation and hardware
accelerator egress enforcement.
Another may combine several modules within one protected platform.
The architecture does not require the simultaneous implementation of
every variation described herein.
M-1.0.4 — Principal Technical Objective
The principal technical objective is to preserve enforceable
operation-specific finality authority as the surrounding computing
environment changes.
Such changes may include newly discovered tools, software upgrades,
application-interface modifications, resource aliasing,
administrative-domain changes, delegation to other agents, device
migration, resource contention, accelerator execution, new hardware
interfaces, and emerging autonomous communication or actuation
mechanisms.
A protected execution system should not become ineffective merely
because the computational workload moves to a different runtime,
invokes a different tool name, changes execution device, or uses an
alternative technical route to reach the same consequential resource.
Within the defined enforcement coverage and trust model, the actual
consequence remains dependent upon valid protected authority.
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.0.5 — Non-Limiting Scope
The term effectuation interface is not limited to an API, network
gateway, application tool, or operating-system call.
It may include any hardware or software interface capable of
initiating, committing, releasing, transmitting, activating,
publishing, modifying, or otherwise causing a governed consequence.
The interface may be physical or virtual, local or remote,
synchronous or asynchronous, centralized or distributed.
Similarly, the protected components may be integrated into one device
or distributed among multiple processors, services, controllers, or
administrative domains.
The disclosed inventive concepts concern their technical enforcement
relationships rather than the commercial identities or physical
locations of particular components.
M-1.1 — SPECIFIC TECHNICAL PROBLEMS
5.2.3.4. Original Global Page 558
M-1.1.1 — Dynamic Effectuation-Path Bypass
An autonomous computing system may possess several methods of
producing the same external consequence.
For example, a document may be transmitted through an application
API, a network socket, an automated browser, a synchronization
service, or an operating-system sharing interface.
An enforcement component controlling only one interface may be
bypassed through another.
The technical problem is to establish whether the actual effectuation
paths relevant to a protected consequence are controlled.
M-1.1.2 — Dynamic Tool Discovery
An AI agent may discover and invoke an external tool during runtime.
A newly discovered tool may provide consequential functionality not
previously incorporated into the local authorization policy.
The existence of a tool description does not establish that its
actual behavior is trustworthy or confined to the declared semantics.
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected system may therefore require verification of the tool's
effectuation contract and applicable Finality Sink before allowing
sensitive effects.
M-1.1.3 — Operation-Semantics Drift
An operation may retain the same name while its parameters or
behavior change after a software update.
An authorization previously issued for one operation meaning may
become inappropriate for the revised operation.
The technical problem is to prevent stale authority from silently
governing materially different actual effects.
M-1.1.4 — Cross-Interface Resource Aliasing
Several interfaces may identify the same underlying resource using
different names, handles, addresses, application identifiers, or
object references.
A protected authorization system may incorrectly treat those
references as unrelated.
The resulting failure may permit unauthorized disclosure,
modification, deletion, or resource conflicts.
M-1.1.5 — Distributed Delegation Expansion
An agent may delegate a narrow task to another agent or remote
service.
A downstream computational entity may attempt to broaden the
resource, destination, privilege, duration, or operation class beyond
the original authority.
5.2.3.5. Original Global Page 559
The technical problem is to ensure that delegated authority remains
within an enforceable attenuation relationship.
M-1.1.6 — Privileged Credential Overreach
A protected system may hold reusable service credentials.
If a computational entity can exercise those credentials
independently of operation-specific authorization, the entity may
perform actions outside the approved Candidate Act.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The technical problem concerns binding credential use to the actual
authorized effect rather than treating credential possession as
unrestricted permission.
M-1.1.7 — Resource and Privacy Accumulation
Several individually permitted operations may collectively exceed a
protected resource budget, privacy constraint, or delegated authority
allowance.
The system may therefore need to verify cumulative consequence state
rather than evaluate each operation in isolation.
M-1.1.8 — Security-Verification Exhaustion
An attacker may submit malformed, excessive, or computationally
expensive verification requests.
Such requests may consume protected processing, memory, power, or
time resources.
The system should preserve mandatory authorization while preventing
unbounded verification work.
M-1.1.9 — Heterogeneous Hardware Effectuation
An operation may cause external effects through a graphics processor,
accelerator, programmable network interface, peripheral controller,
storage engine, direct-memory-access mechanism, or another
nontraditional execution path.
An application-layer gateway may not observe the resulting actual
effect.
The system may require enforcement at a lower or different
consequential boundary.
M-1.1.10 — Enforcement Coverage After Updates
A software or firmware update may create a new effect-capable
interface, change an existing interface, or modify the semantics of a
previously controlled operation.
The protected system may need to reestablish that its enforcement
coverage remains valid.
M-1.1.11 — Intermittent Connectivity
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An autonomous device may perform operations while disconnected from
an authoritative central service.
5.2.3.6. Original Global Page 560
The system must distinguish bounded offline authority from
unrestricted authority that cannot be promptly revoked.
M-1.1.12 — Emerging Autonomous Systems
Future autonomous computing environments may include multiple model
providers, distributed agents, heterogeneous accelerators, robotic
controllers, spatial computing interfaces, and machine-to-machine
transactions.
The execution-finality architecture must remain technically
implementable without depending upon a particular current software
product or computing platform.
M-1.2 — ADDITIONAL DEFINITIONS
M-1.2.1 — Effectuation Surface
An Effectuation Surface means an identifiable interface, controller,
resource boundary, communication channel, hardware primitive,
software operation, or equivalent mechanism through which a governed
external consequence can be produced.
M-1.2.2 — Protected Effectuation-Surface Registry
A Protected Effectuation-Surface Registry, or PESR, means an
authenticated registry identifying effect-capable interfaces and the
protected enforcement conditions associated with them.
M-1.2.3 — Effectuation Coverage Commitment
An Effectuation Coverage Commitment, or ECC-M, means protected
evidence or state binding a specified consequence class to the set of
enforcement surfaces recognized and covered by the applicable
security configuration.
M-1.2.4 — Mandatory Enforcement Path
A Mandatory Enforcement Path means an effectuation route that
requires a protected authorization condition at a controller capable
of withholding the corresponding consequence.
M-1.2.5 — Dynamic Action Contract
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Dynamic Action Contract, or DAC-M, means a machine-verifiable
description of an operation's effect semantics, supported parameters,
destination class, resource identity requirements, side effects, and
applicable finality controls.
M-1.2.6 — Action-Contract Version Commitment
An Action-Contract Version Commitment, or ACVC, means a protected
commitment binding an authorized operation to a specified action-
contract version or verified compatible semantic representation.
M-1.2.7 — Protocol-Neutral Effect Descriptor
5.2.3.7. Original Global Page 561
A Protocol-Neutral Effect Descriptor, or PNED, means a representation
of the intended or actual consequential operation independent of a
particular tool name or transport protocol.
The PNED may identify the effect class, operation semantics, target
resource, destination, payload commitment, and relevant context.
M-1.2.8 — Semantic Resource Identity Commitment
A Semantic Resource Identity Commitment, or SRIC, means a protected
association of one or more resource aliases with a resolved
consequential resource identity under an applicable verified mapping.
M-1.2.9 — Delegated Authority Attenuation Chain
A Delegated Authority Attenuation Chain, or DAAC, means an
authenticated sequence of delegated authorities in which each derived
authorization is constrained by the applicable authority of its
predecessor.
M-1.2.10 — Protected Credential-Release Binding
A Protected Credential-Release Binding, or PCRB, means a protected
association between credential use and the specifically authorized
actual consequential operation.
M-1.2.11 — Privacy Exposure Composition State
A Privacy Exposure Composition State, or PECS-M, means protected
state representing cumulative or correlated privacy-relevant effects
of multiple operations.
M-1.2.12 — Protected Validation Work Budget
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Protected Validation Work Budget, or PVWB, means a bounded
allocation of processor time, cryptographic verification work,
memory, energy, input size, or related resources for validating
specified operations.
M-1.2.13 — Operational Continuity Epoch
An Operational Continuity Epoch, or OCE, means a protected version or
generation value associated with an execution environment, action
contract, enforcement configuration, or authority-validity state.
M-1.2.14 — Protected Enforcement-Coverage Reattestation
Protected Enforcement-Coverage Reattestation means an authenticated
procedure for determining whether the required effectuation surfaces
and enforcement controls remain valid following a relevant
environmental change.
M-1.2.15 — Execution-Route Equivalence Record
An Execution-Route Equivalence Record, or ERER, means an
authenticated record establishing the correspondence, or relevant
permitted differences, between operations performed through
alternative execution environments or interfaces.
5.2.3.8. Original Global Page 562
M-1.2.16 — Protected Resource-Parity Evidence
Protected Resource-Parity Evidence means machine-verifiable
information concerning an allocation decision under specified
resource-comparison or fairness constraints.
M-1.2.17 — Protected Delegation Boundary
A Protected Delegation Boundary means an authority transition through
which a downstream computational entity receives only the rights
permitted by the applicable predecessor authorization.
M-1.2.18 — Effectuation-Coverage Failure
An Effectuation-Coverage Failure occurs where a governed consequence
can be produced through a relevant path that lacks the mandatory
protected enforcement required by the asserted protection scope.
M-1.2.19 — Trusted Effect-Observation Interface
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Trusted Effect-Observation Interface means an observation path
capable of providing appropriately authenticated evidence concerning
a specified effect under an identified trust model.
M-1.2.20 — Future-Compatible Protected Effect Interface
A Future-Compatible Protected Effect Interface means a defined
technical contract through which a newly introduced computing or
hardware component can present actual operations, protected
authority, and required verification state to an effectuation
controller.
M-1.3 — MODULAR SYSTEM ARCHITECTURE
In one implementation, the protected infrastructure comprises a
Candidate Act interface, an effectuation-surface discovery component,
a protected action-contract registry, a resource identity resolver, a
delegation authority controller, a specialized verification
coordinator, a protected state store, and one or more Finality Sinks.
The architecture may also contain a credential broker, a privacy-
state controller, a validation work-budget manager, a software-update
verifier, and an environment-continuity monitor.
The components may be implemented individually, combined within one
protected process or device, or distributed among authenticated
services.
The requesting autonomous entity may construct or propose an
operation but cannot unilaterally declare its effectuation interface
to be covered, its delegation valid, or its action contract
unchanged.
Those properties are established through the applicable protected
mechanisms.
M-1.3.1 — Baseline Information Flow
A representative flow is:
Autonomous computational request | v
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.2.3.9. Original Global Page 563
Candidate Act construction | v Effectuation-surface identification |
v Action-contract and resource resolution | v Protected authority and
module verification | v Scoped finality authority preparation | v
Actual Finality Sink operation reconstruction | v Current
enforcement-coverage verification | v Protected consumption and
consequential release Optional privacy, delegation, conflict,
semantic, hardware, environmental, or causal-receipt modules may add
necessary predicates according to the particular implementation.
M-1.3.2 — Component Independence
The architecture does not require separate physical devices for every
function.
For example, the protected registry, contract verifier, and Finality
Sink may operate within one protected controller.
Alternatively, a cloud authority may manage the registry while a
hardware-local sink performs final verification.
The claimed technical relationships depend upon authenticated state
and mandatory enforcement, not component names or physical separation
alone.
M-1.4 — PROTECTED EFFECTUATION-SURFACE DISCOVERY
M-1.4.1 — Technical Purpose
A system may expose several methods of producing the same
consequential effect.
The protected system may therefore construct an effectuation-surface
inventory identifying the interfaces capable of producing the
governed consequence.
The inventory may include operating-system calls, application
dispatchers, network interfaces, service APIs, storage engines,
privileged functions, command queues, device controllers, and
hardware operations.
5.2.3.10. Original Global Page 564
M-1.4.2 — Surface Registration
A protected registration component may authenticate an effectuation
interface and associate it with supported effect classes.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The registration may include the interface identity, relevant
software or firmware version, controlled resource type, operation
class, protected authority requirements, and applicable Finality
Sink.
M-1.4.3 — Surface Identity
Each registered effectuation surface may possess a unique or issuer-
qualified identity within the applicable trust domain.
The identity may be bound to cryptographic credentials, protected
controller state, measured firmware, or another suitable
authenticated registration mechanism.
M-1.4.4 — Effectuation Coverage Graph
An implementation may maintain a protected graph associating
consequence classes with effect-capable interfaces and their
authoritative enforcement controllers.
A graph node may represent an application dispatch function, system
service, network controller, accelerator output, storage commit path,
or physical actuator.
An edge may represent a path through which a proposed operation can
reach a consequential interface.
M-1.4.5 — Protected Coverage Verification
Before permitting a governed effect, the relevant protected system
may verify that the actual effectuation route terminates at a
controller enforcing the required finality predicates.
Where the authorization depends upon complete coverage of a defined
effect class, unknown or unmediated relevant paths may cause the
authorization to be withheld.
M-1.4.6 — Dynamic Surface Discovery
When an application, service, plugin, driver, or hardware component
introduces a new effect-capable interface, the system may require the
interface to register or undergo protected discovery.
The system may provisionally restrict the interface until its
operation semantics and final enforcement conditions have been
established.
M-1.4.7 — Coverage Attestation
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected system may generate an ECC-M describing the covered
effect class, relevant enforcement interfaces, configuration version,
and applicable validation state.
The commitment may be bound to the Candidate Act or authority epoch.
M-1.4.8 — Unknown Surface Behavior
5.2.3.11. Original Global Page 565
An implementation may distinguish harmless computational interfaces
from effect-capable interfaces.
Where classification remains uncertain, the system may conservatively
restrict the operation or require additional verification.
A semantic classifier's confidence score is not itself proof that an
interface cannot produce a consequential effect.
M-1.4.9 — Technical Contribution
The proposed additional technical mechanism is to make current
effectuation-path coverage a protected predicate of actual operation
release.
The coverage record is not merely an inventory maintained for
administrative purposes.
It participates in determining whether the relevant Finality Sink may
authorize the actual consequence.
M-1.5 — PROTOCOL-NEUTRAL EFFECT DESCRIPTION
M-1.5.1 — Technical Problem
The same consequential operation may be invoked through different
protocols or application interfaces.
For example, a document export may occur through a graphical
application, a structured API, a file synchronization operation, or a
network upload.
An authorization bound only to one tool name may not capture the
effect that matters.
M-1.5.2 — Effect-Based Representation
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system may create a PNED representing the actual consequence
independently of the original invocation syntax.
The PNED may include a normalized effect class, target identity,
destination, operation semantics, relevant data commitment, and
scope.
M-1.5.3 — Representative Structure
PROTOCOL_NEUTRAL_EFFECT_DESCRIPTOR = { descriptor_version,
requesting_entity, original_candidate_act_digest, effect_class,
normalized_operation_semantics, target_resource_identity,
destination_identity, data_or_command_commitment,
permitted_effect_scope, source_interface_identity,
5.2.3.12. Original Global Page 566
applicable_action_contract, designated_finality_sink,
protected_authority_epoch } M-1.5.4 — Multiple Protocol Adapters
A protocol adapter may convert an application request into the PNED.
Another adapter may convert a hardware command.
Each adapter is authenticated or otherwise covered by the applicable
protected trust assumptions.
The protected verifier checks that the conversion preserves the
security-relevant semantics.
M-1.5.5 — Actual-Effect Comparison
At final effectuation, the sink verifies that the actual command
corresponds to the authorized normalized effect.
A mismatch in resource, destination, content, privilege, or
consequential behavior may result in denial.
M-1.5.6 — Ambiguous Semantics
Where the system cannot establish a reliable equivalence between two
operation representations, it does not silently treat them as
identical.
A protected operation may require renewed authorization or a narrower
supported transformation rule.
M-1.5.7 — Future Application
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The same effect-descriptor interface may be used by newly introduced
autonomous tools or hardware interfaces without treating every new
tool name as a distinct unrestricted authority domain.
M-1.6 — DYNAMIC TOOL DISCOVERY AND ACTION-CONTRACT CONTINUITY
M-1.6.1 — Tool Discovery
An autonomous agent may discover a tool, application function, device
command, or remote service at runtime.
The tool may provide descriptive metadata identifying its intended
operation.
Such metadata may originate from a source not trusted to define the
security policy.
M-1.6.2 — Protected Tool Registration
A protected component may evaluate the discovered tool's identity,
declared effect class, supported parameters, destination rules,
current software version, and actual effectuation path.
5.2.3.13. Original Global Page 567
Where sufficient evidence exists, the tool may be associated with a
protected DAC-M.
M-1.6.3 — Action-Contract Content
A DAC-M may describe the permitted operation and its material side
effects.
For example, a function named "generate report" might also transmit
the report to an external destination.
The protected contract should reflect relevant actual effects rather
than assume that the tool name fully describes them.
M-1.6.4 — Contract Version Commitment
An ACVC may bind the Candidate Act to the action-contract version
under which the operation was authorized.
The sink may verify that the actual function continues to satisfy the
required semantics.
M-1.6.5 — Contract Compatibility
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A later contract version may be considered compatible only where the
relevant authorized effect remains within the protected equivalence
or attenuation rules.
Changing internal implementation details may be acceptable.
Adding a new external data transmission may not be acceptable without
separate authorization.
M-1.6.6 — Contract Downgrade and Rollback
A malicious system may attempt to present an older contract version
while executing newer behavior.
The sink may require an authenticated current contract reference and
reject incompatible version combinations.
M-1.6.7 — Tool Removal
Revocation or removal of a tool may invalidate corresponding
unconsumed operation authority.
The actual sink checks the applicable current contract and authority
state before effectuation.
M-1.6.8 — Proposed Technical Contribution
The candidate distinguishing mechanism concerns binding protected
finality authority to verified operation semantics and requiring
current contract correspondence at the consequential boundary.
A conventional version number or tool registry alone does not
establish this enforcement relationship.
M-1.7 — CROSS-INTERFACE RESOURCE IDENTITY AND ALIAS RESOLUTION
5.2.3.14. Original Global Page 568
M-1.7.1 — Resource Aliases
An underlying resource may have multiple identifiers.
A document may possess a filesystem path, content identifier,
application object identifier, synchronization reference, and remote
storage address.
These identifiers may change independently.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.7.2 — Protected Resolution
A protected resolver may establish the relevant identity relationship
using authenticated storage metadata, controller state, version
information, or other qualified evidence.
The resulting SRIC binds the authorized resource to the resolved
target.
M-1.7.3 — Version-Specific Identity
A resource may preserve its logical identifier while its content
changes.
The system may therefore bind authority to a particular resource
version or content commitment where necessary.
M-1.7.4 — Resource Rebinding
A file path may point to a different object after authorization.
An application identifier may be reassigned.
The sink may require current resource correspondence rather than
relying exclusively on the original path string.
M-1.7.5 — Cross-Application Equivalence
The resolver may identify resources exposed through multiple
applications.
An authorization for one document does not automatically authorize
all documents within an application.
M-1.7.6 — Protected Failure Behavior
If the resolver cannot establish the required correspondence, the
operation remains withheld or requires renewed authorization.
M-1.7.7 — Relation to Embodiment 3
Embodiment 3 provides more specialized treatment of user-observed
referents and actual effectuation targets.
The present section focuses on cross-interface resource identity
within dynamically changing software and infrastructure environments.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.2.3.15. Original Global Page 569
M-1.8 — PROTECTED DELEGATED AUTHORITY ACROSS AGENTS AND PROVIDERS
M-1.8.1 — General Architecture
An authorized principal may delegate a permitted task to an
autonomous agent.
The agent may delegate a subset of the task to another agent or
service.
The downstream entity may operate under a different administrator or
software provider.
M-1.8.2 — Delegation Attenuation
Each delegation may be required to preserve or narrow the original
authority.
For example, the permitted resource set, destination set, operation
classes, execution duration, and cumulative authority budget may be
constrained.
M-1.8.3 — Representative Authority Relationship
ChildAuthority.Scope SUBSET_OF ParentAuthority.Scope
ChildAuthority.EffectBudget NOT_GREATER_THAN ParentAvailableBudget
ChildAuthority.Validity WITHIN ParentAuthority.Validity These
relations are conceptual.
The actual implementation may use typed resource sets, authenticated
capability restrictions, policy expressions, or equivalent formal
constraints.
M-1.8.4 — Delegation Chain
A DAAC may bind each delegation to its predecessor.
The chain may contain authenticated delegator identity, delegate
identity, permitted scope, authority epoch, resource constraints, and
revocation references.
M-1.8.5 — Final Sink Verification
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The destination-side Finality Sink verifies that the actual requested
effect remains within the valid delegation lineage.
An upstream agent cannot create unrestricted authority merely by
designating a downstream agent as trusted.
M-1.8.6 — Delegation Through Multiple Providers
5.2.3.16. Original Global Page 570
An implementation may use authenticated cross-domain messages and
locally verifiable authority commitments.
Each provider may retain independent authority and security
requirements.
M-1.8.7 — Delegation Revocation
Revocation may invalidate unconsumed downstream authority.
An already completed consequential effect is not automatically
reversed.
M-1.8.8 — Dynamic Delegation Topology
The system may support a changing delegation graph.
A newly introduced delegate must satisfy current protected identity
and authority checks.
M-1.8.9 — Candidate Technical Contribution
The proposed specific combination concerns attenuation of
consequential authority across dynamic autonomous-agent delegation,
with actual sink-time verification of the resulting operation and
protected lineage.
M-1.9 — PROTECTED CREDENTIAL-RELEASE FINALITY
M-1.9.1 — Credential Custody
A protected credential broker may retain reusable credentials outside
the ordinary agent execution environment.
The agent may submit a Candidate Act requesting a specific permitted
external operation.
M-1.9.2 — Operation-Bound Credential Use
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The broker verifies the Candidate Act and applicable finality
authorization.
It may construct or authenticate the actual outgoing operation and
use the credential without exposing the reusable secret to the agent.
M-1.9.3 — Credential Activation Rather Than Transfer
In an alternative implementation, the reusable credential remains
sealed.
A protected controller activates the credential only for a
specifically authorized command.
The requesting agent does not acquire unrestricted independent
ability to use it.
M-1.9.4 — Actual Request Binding
The broker may verify destination, method, resource, body commitment,
operation class, and current protected state.
5.2.3.17. Original Global Page 571
Where the actual request differs materially from the authorized
Candidate Act, credential exercise is refused.
M-1.9.5 — Credential Rotation
The broker may rotate credentials without changing the authorized
operation semantics.
The finality binding remains associated with the permitted effect
rather than one permanent credential string.
M-1.9.6 — Remote Credential Use
A remote protected broker may exercise credentials in another
administrative domain.
The local or remote Finality Sink verifies the applicable scoped
authority.
M-1.9.7 — Bypass Qualification
Credential custody does not prevent unauthorized operations if
another unrestricted credential or effectuation path remains
available to the agent.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The claimed protection therefore depends upon the actual credential
and effectuation coverage.
M-1.10 — PROTECTED PRIVACY-EXPOSURE COMPOSITION
M-1.10.1 — Cumulative Disclosure Problem
An agent may make several individually permitted disclosures.
The combined information may reveal more than the protected
authorization permits.
For example, several responses may disclose overlapping fields from a
sensitive record.
M-1.10.2 — Protected Privacy State
A PECS-M may represent relevant prior disclosures, disclosed
attributes, recipient domains, scope, and applicable privacy
constraints.
M-1.10.3 — Incremental Exposure Evaluation
Before a new disclosure, the protected system evaluates how the
proposed effect changes the relevant cumulative exposure state.
The calculation may consider repeated recipients, overlapping
attributes, time windows, and known correlations.
M-1.10.4 — Context-Dependent Risk
The system may distinguish disclosure to a previously authorized
recipient from disclosure to a new recipient.
It may also distinguish exact raw information from appropriately
protected derived information.
5.2.3.18. Original Global Page 572
The corresponding exposure model must be expressly defined rather
than assumed universally accurate.
M-1.10.5 — Finality Enforcement
A data-release Finality Sink verifies that the actual outgoing
operation satisfies the applicable current privacy constraints.
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A permitted computation does not itself grant authority to disclose
the computed result.
M-1.10.6 — Privacy-Preserving Evidence
The protected verifier may use commitments, selective disclosure, or
suitable cryptographic proofs to evaluate a privacy predicate without
revealing all underlying data to every participant.
The proof system's assurances remain limited by the trustworthiness
of the input data and the predicate actually proved.
M-1.10.7 — Relation to Specialized Embodiments
More detailed privacy composition, cumulative leakage, and query
reconstruction mechanisms may be developed within their respective
specialized embodiments.
The present section establishes an optional integration pattern with
protected finality enforcement.
M-1.11 — MULTI-PRINCIPAL AND RESOURCE-PARITY GOVERNANCE
M-1.11.1 — Multiple Principals
A consequential operation may affect resources governed by several
principals.
For example, a shared device resource may require authority from both
an enterprise controller and the affected resource owner.
M-1.11.2 — Protected Authority Composition
The system may require authenticated evidence satisfying each
applicable principal's authorization conditions.
An approval from one principal does not necessarily override another
mandatory constraint.
M-1.11.3 — Protected Resource Allocation
Several autonomous agents may compete for processor, network,
storage, device, or transaction resources.
A protected allocation module may evaluate the requests under a
specified allocation policy.
M-1.11.4 — Comparable-Workload Evidence
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Where fairness or parity is required, the system may identify which
workloads are meaningfully comparable under the protected policy.
5.2.3.19. Original Global Page 573
The definition of comparability may consider resource class, workload
priority, technical requirements, authorized principal, and relevant
service conditions.
M-1.11.5 — Verifiable Decision Evidence
A protected allocation record may identify the evaluated workload
attributes, applicable rule, allocation state, and resulting
decision.
The record may be authenticated without revealing unrelated private
workload data.
M-1.11.6 — Finality-Bound Allocation
A protected scheduling or resource controller may refuse resource
activation that lacks valid allocation authority.
Thus, the allocation decision may be enforced as a resource
effectuation condition rather than remaining an advisory fairness
score.
M-1.11.7 — Technical Limitation
A cryptographic proof can establish correct evaluation of a specified
allocation rule.
It does not establish that the rule is socially fair, optimal, or
legally sufficient merely because its calculation is verifiable.
M-1.12 — PROTECTED LOCAL, EDGE, AND CLOUD EXECUTION-ROUTE CONTINUITY
M-1.12.1 — Route Selection
An autonomous task may be executed locally, at an edge node, or
within a remote computing service.
A route selection may be based upon latency, privacy, resource
availability, computation cost, or other technical constraints.
M-1.12.2 — Authority Preservation
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Moving computation between execution environments does not
automatically transfer unrestricted authority over external effects.
Each consequential operation remains subject to the applicable
protected finality requirements.
M-1.12.3 — Route Equivalence
An ERER may specify which operation semantics, resource identities,
protected outputs, and permitted effects are preserved across
alternative routes.
M-1.12.4 — Route-Specific Evidence
The system may require different evidence depending upon the selected
execution environment.
5.2.3.20. Original Global Page 574
For example, a remote confidential-computing service may provide
authenticated environment evidence, while a local protected process
may rely on a separate device controller.
M-1.12.5 — Model Independence
The finality architecture may remain independent of which model
generated the proposed operation.
A change of model or computation route does not automatically alter
the underlying user-granted authority.
M-1.12.6 — Route-Induced Operation Change
If moving execution changes the actual resource, destination, data
disclosure, or effect semantics, the protected system may require
renewed validation.
M-1.12.7 — Exclusive Migration
Where a task's unfinished execution authority must be exclusive,
protected ownership epochs and fencing may prevent the former
execution environment from continuing after migration.
M-1.13 — PROTECTED VERIFICATION WORK BUDGETS
M-1.13.1 — Technical Problem
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A malicious or malfunctioning agent may submit verification requests
that consume excessive protected resources.
Examples include large proof objects, deeply nested data, expensive
cryptographic checks, or repeated policy evaluation.
M-1.13.2 — Bounded Verification Resources
A PVWB may specify maximum input size, computational work, memory,
time, or energy for a validation class.
M-1.13.3 — Protected Budget Allocation
The protected controller may reserve validation capacity for selected
operation classes.
The allocation may consider deadlines, safety relevance, resource
availability, and current protected policy.
M-1.13.4 — Verification Exhaustion
Where a request exceeds a mandatory verification budget, the system
may reject, defer, split, or use another approved bounded
verification procedure.
The system does not treat verification exhaustion as permission.
M-1.13.5 — Cryptographic Work Limits
5.2.3.21. Original Global Page 575
The verifier may constrain supported signature schemes, proof sizes,
certificate-chain depths, parsing operations, and other
computationally expensive inputs.
M-1.13.6 — Real-Time Consequential Operations
A real-time controller may require bounded verification latency.
The protected system may use prevalidated evidence, limited-scope
capabilities, or hardware-assisted checking while preserving
mandatory current-state constraints.
M-1.13.7 — Thermal and Power Limits
An embedded device may have limited thermal or energy capacity.
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The verification controller may reserve protected resources or
restrict nonessential work to preserve the ability to evaluate
critical effects.
M-1.13.8 — Proposed Technical Contribution
The additional technical relationship concerns enforcing
authorization correctness under bounded computational resources
rather than bypassing protected validation when resources become
scarce.
M-1.14 — UPDATE-TIME ENFORCEMENT COVERAGE REATTESTATION
M-1.14.1 — Triggering Events
Reattestation may be triggered by:
A new software version;
A firmware update;
A changed application interface;
A new tool registration;
A driver modification;
A hardware peripheral change;
A changed runtime configuration;
A new communication route;
A controller replacement;
Or another event capable of altering the relevant effectuation path.
M-1.14.2 — Protected Update Epoch
The system may increment an OCE when a relevant execution or
enforcement configuration changes.
5.2.3.22. Original Global Page 576
An authority bound to an earlier epoch may require revalidation.
M-1.14.3 — Coverage Reassessment
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected controller determines whether the updated environment
still routes the relevant consequential operations through the
mandatory Finality Sink.
M-1.14.4 — Action Contract Revalidation
The system may verify whether previously authorized operation
semantics remain valid.
M-1.14.5 — Authority Invalidation
Where the update materially changes a required effectuation
predicate, unconsumed authority may be invalidated, suspended, or
restricted.
M-1.14.6 — Secure Recovery
Following successful reattestation, the system may restore approved
operations under current authority.
M-1.14.7 — Rollback Resistance
An attacker may attempt to restore an earlier configuration with
weaker controls.
Protected epochs and trusted configuration evidence may prevent
unsupported acceptance of the older state.
M-1.14.8 — Candidate Technical Contribution
The potentially distinguishing mechanism is a mandatory linkage
between current enforcement-coverage validity, action-contract
continuity, and finality authority.
M-1.15 — HARDWARE ACCELERATOR AND DIRECT EFFECTUATION CONTROL
M-1.15.1 — General Applicability
An accelerator or peripheral controller may produce consequential
effects without using an ordinary application API.
Such effects may include direct memory access, network transmission,
persistent storage modification, protected media release, hardware
command dispatch, or access to another device.
M-1.15.2 — Accelerator Candidate Act
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An accelerator operation may be represented as a Candidate Act
identifying the permitted command class, resource region,
destination, output, memory target, or device effect.
M-1.15.3 — Protected Command Descriptor
5.2.3.23. Original Global Page 577
The system may bind authority to a protected command buffer,
descriptor generation, device queue, or equivalent operation
representation.
M-1.15.4 — Accelerator Egress Boundary
A protected controller may govern accelerator-originated output or
effect-capable commands.
The controller verifies the relevant authority before the actual
consequential release.
M-1.15.5 — Memory and Device Access
Where direct-memory-access operations can produce protected effects,
the relevant address ranges, ownership, and access permissions may be
enforced through an appropriate protected hardware mechanism.
M-1.15.6 — Command Mutation
A command descriptor may change after authorization.
The controller may verify the actual command at dispatch or protect
the command buffer against unauthorized modification.
M-1.15.7 — Hardware Identity
An effect-capable accelerator may possess an authenticated device
identity or registered controller reference.
The sink checks the applicable authority and hardware trust state.
M-1.15.8 — Future Hardware Variants
The architecture may be adapted to newly developed processors, neural
accelerators, programmable network controllers, storage processors,
chiplet-based systems, and other heterogeneous execution substrates.
M-1.15.9 — Limitation
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A host-level software gate does not automatically control a
peripheral's direct effectuation path.
The implementation must identify and enforce the relevant actual
hardware boundary.
M-1.16 — CONFIDENTIAL COMPUTING AND PROTECTED OUTPUT FINALITY
Confidential computing may protect selected computations and data
within an isolated environment.
The present architecture may additionally require that an output
generated within the protected environment receive valid effectuation
authority before causing an external consequence.
A protected computation may therefore produce a Candidate Act rather
than directly exercising an unrestricted external credential.
5.2.3.24. Original Global Page 578
The receiving Finality Sink may verify operation scope, current
protected authority, and actual output parameters.
Remote attestation may contribute evidence concerning the identity or
configuration of the computing environment.
However, attestation of the environment does not automatically prove
that every proposed external act is authorized.
The protected output may require separate finality authorization.
An optional implementation may bind the authority to a measured
software configuration or operation-contract version.
Where the environment changes, the applicable authority may require
renewed verification.
M-1.17 — FUTURE COMMUNICATION-NETWORK EFFECTUATION
M-1.17.1 — Autonomous Network Control
A communication network may employ autonomous components to modify
routing, radio parameters, service access, resource scheduling,
network functions, or traffic management.
M-1.17.2 — Network Candidate Acts
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An operation may identify the target controller, resource allocation,
command class, destination network function, and permitted state
transition.
M-1.17.3 — Distributed Control Boundaries
Different network components may operate under separate protected
authorities.
Each actual consequential controller may verify the applicable
operation-specific authorization.
M-1.17.4 — Protected Spectrum and Radio Effects
Where a radio configuration change is security-relevant, the
protected controller may verify frequency, power, resource
allocation, device identity, and other applicable parameters.
M-1.17.5 — Network Function Updates
An autonomous agent may request activation or replacement of a
network function.
The protected system may bind authority to the actual software and
configuration state.
M-1.17.6 — Edge Processing
A task may move among edge and cloud execution environments while its
authority remains scoped to the original permitted consequence.
M-1.17.7 — Future Standards Independence
5.2.3.25. Original Global Page 579
The invention is not restricted to a particular generation of
wireless communication technology or network management protocol.
The relevant technical principle concerns controlled consequential
state changes at authenticated network effectuation boundaries.
M-1.18 — PHYSICAL SCENE, ROBOTICS, AND SPATIAL-COMPUTING VARIANTS
A physical autonomous system may receive a user instruction referring
to an object, location, or device.
The system may identify the target through camera observations,
spatial coordinates, device identifiers, or other sensor data.
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected system may bind the authorized effect to an
authenticated target identity and current operating envelope.
The actual actuator Finality Sink verifies the pending physical
command.
Where target identity may change, the controller may require
revalidation using current protected sensor evidence.
In an extended-reality implementation, a virtual object selected by a
user may correspond to a physical or remote resource.
The protected system may verify that the selected referent maps to
the actual affected resource.
The detailed semantic correspondence mechanisms may follow Embodiment
3.
The present miscellaneous implementation additionally allows the
effectuation boundary to reside within a physical actuator
controller, remote device, protected robot subsystem, or future
spatial-computing interface.
Where physical movements occur in several dependent phases, the
receipt-gated causal continuation mechanism of CW-2 may be employed.
M-1.19 — INTERMITTENT CONNECTIVITY AND BOUNDED OFFLINE AUTHORITY
M-1.19.1 — Offline Operation
A device may lose contact with its central authorization service.
The system may permit selected bounded operations under previously
provisioned authority.
M-1.19.2 — Offline Scope
Offline authority may specify operation classes, resource bounds,
consumption limits, time conditions, or protected counters.
M-1.19.3 — Local Finality Sink
5.2.3.26. Original Global Page 580
The local controller verifies the offline authority against the
actual operation.
M-1.19.4 — Protected Consumption
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A local monotonic counter or equivalent protected state may prevent
unauthorized repeated use.
M-1.19.5 — Delayed Revocation
Immediate remote revocation cannot be guaranteed while the device
lacks an authenticated communication path unless another local
expiration or control mechanism enforces the required limit.
M-1.19.6 — Reconnection
Following reconnection, the system may reconcile consumed authority
and actual-effect state.
M-1.19.7 — Unknown Remote Outcome
A remote operation attempted during intermittent connectivity may
have an unknown result.
The system does not assume failure merely because acknowledgement was
unavailable.
M-1.19.8 — Industrial Relevance
Such mechanisms may support edge devices, remote machinery, mobile
systems, and intermittently connected infrastructure.
M-1.20 — FUTURE AUTONOMOUS MACHINE-TO-MACHINE ECONOMIC OPERATIONS
An autonomous device may request resources, services, access rights,
or financial transactions from another device or service.
A protected Candidate Act may identify the actual economic
consequence, resource, destination, amount, and permitted transaction
class.
The relevant Finality Sink verifies current authority before
submitting the consequential instruction.
An authenticated remote outcome may later be required for a dependent
effect.
Where the workflow requires phased progression, an authorized
cryptographically identified IEV may accept the actual-effect receipt
under CW-2.
The accepted receipt may become a necessary enabling factor for the
next financial or resource operation.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A transaction receipt concerning authorization, submission, or
settlement must be classified according to what it actually
establishes.
The embodiment does not presume that all financial operations are
reversible or globally atomic.
5.2.3.27. Original Global Page 581
M-1.21 — ADVANCED CRYPTOGRAPHIC AND PRIVACY-PRESERVING VARIANTS
M-1.21.1 — Algorithm Agility
Protected authority records may contain cryptographic algorithm
identifiers and credential-generation references.
The system may support migration to alternative authenticated
algorithms without changing the protected operation semantics.
M-1.21.2 — Post-Quantum Migration
An implementation may adopt appropriate post-quantum cryptographic
primitives when supported by applicable requirements.
Such primitives do not independently establish novelty of the
execution-finality architecture.
M-1.21.3 — Selective Disclosure
A verifier may receive only those attributes needed to establish an
authorization predicate.
M-1.21.4 — Proofs of Protected Resource State
An authenticated proof may establish that a resource state satisfies
a specified condition.
The actual trustworthiness of the source state remains necessary.
M-1.21.5 — Privacy-Preserving Delegation Evidence
A delegated agent may prove possession of an appropriately limited
authority without disclosing unnecessary private attributes.
M-1.21.6 — Protected Identity Rotation
Validator, sink, and device identities may support authenticated
credential rotation.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.21.7 — Cryptography-Independent Actual Enforcement
A system may use cryptography to authenticate identities while
enforcing the final effect through protected hardware or controller
state.
The actual effectuation gate need not be realized exclusively through
cryptographic key release.
M-1.22 — OPTIONAL COMBINED TECHNICAL ARRANGEMENTS
M-1.22.1 — Dynamic Tool Contract Plus Enforcement Coverage
A newly discovered tool may be registered with an authenticated
action contract.
The protected system determines its actual effectuation surfaces.
5.2.3.28. Original Global Page 582
Finality authority is permitted only when the relevant current
contract and coverage predicates are satisfied.
M-1.22.2 — Cross-Interface Identity Plus Credential Release
An application requests an operation involving a resource identified
by one alias.
A protected resolver establishes the actual target identity.
A credential broker exercises the required credential only for the
matching actual operation.
M-1.22.3 — Delegation Plus Destination-Side Verification
A parent agent delegates a bounded operation to a remote agent.
The remote Finality Sink verifies the authenticated delegation chain
and actual requested effect.
M-1.22.4 — Privacy Composition Plus Data Release
A protected privacy state tracks relevant cumulative disclosure.
The external data-release sink checks that the actual outgoing object
and destination satisfy current privacy constraints.
M-1.22.5 — Accelerator Egress Plus Enforcement Coverage
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected authority record identifies an accelerator-originated
effect.
The hardware controller verifies the actual command.
A coverage commitment establishes that the corresponding device path
is mediated.
M-1.22.6 — Software Update Plus Contract Revalidation
An application update changes an effect-capable function.
The protected system advances the applicable environment epoch.
Unconsumed authority bound to incompatible earlier semantics is
invalidated.
M-1.22.7 — Cross-Device Delegation Plus Exclusive Authority
Authority moves to another device.
The prior device's protected ownership epoch becomes stale.
The new device's Finality Sink verifies exclusive authority before
effectuation.
M-1.22.8 — Causal Receipt Plus Distributed Authority
An earlier real effect occurs in one domain.
An authorized IEV accepts the corresponding qualified evidence.
5.2.3.29. Original Global Page 583
The validated receipt is made available to a successor Finality Sink
in another domain.
The next effect requires that receipt-derived authority under CW-2.
M-1.22.9 — Verification Budget Plus Safety-Critical Deadline
A protected controller reserves bounded verification resources for a
consequential operation.
Where the required predicates cannot be completed within the safe
operating window, the controller applies the specified protected
failure response instead of treating incomplete verification as
permission.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.22.10 — Multi-Principal Authority Plus Protected Resource
Allocation
A consequential resource-allocation operation may require approval
from several principals and verification of the current allocation
state.
The actual allocation controller enforces both predicates.
M-1.23 — REFERENCE PSEUDOCODE: SURFACE REGISTRATION
FUNCTION REGISTER_EFFECTUATION_SURFACE( proposed_interface,
declared_effect_classes, protected_registry ):
REQUIRE VERIFY_INTERFACE_IDENTITY( proposed_interface )
REQUIRE VERIFY_INTERFACE_SECURITY_CONFIGURATION( proposed_interface )
contracts = VALIDATE_EFFECT_CONTRACTS( proposed_interface,
declared_effect_classes )
IF contracts IS INVALID: RETURN UNREGISTERED
coverage = VERIFY_MANDATORY_SINK_ASSOCIATION( proposed_interface,
contracts )
IF coverage != VERIFIED: RETURN RESTRICT_EFFECTUATION
5.2.3.30. Original Global Page 584
record = protected_registry.ATOMIC_REGISTER({ interface_identity:
proposed_interface.identifier,
contract_commitment: HASH(contracts),
enforcement_sink: coverage.sink_identity,
environment_epoch: CURRENT_ENVIRONMENT_EPOCH(),
authorized_effect_classes: contracts.effect_classes })
RETURN record
M-1.24 — REFERENCE PSEUDOCODE: DYNAMIC ACTION-CONTRACT VALIDATION
FUNCTION VALIDATE_DYNAMIC_ACTION( candidate_act, actual_operation,
current_action_contract ):
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
REQUIRE VERIFY_ACTION_CONTRACT_AUTHENTICITY( current_action_contract
)
REQUIRE VERIFY_CURRENT_CONTRACT_EPOCH( current_action_contract )
normalized_effect = NORMALIZE_ACTUAL_EFFECT( actual_operation,
current_action_contract )
IF normalized_effect IS AMBIGUOUS: RETURN DENY_OR_REAUTHORIZE
REQUIRE VERIFY_AUTHORIZED_EFFECT_SEMANTICS( candidate_act,
normalized_effect )
REQUIRE VERIFY_RESOURCE_IDENTITY( candidate_act,
5.2.3.31. Original Global Page 585
normalized_effect )
REQUIRE VERIFY_REQUIRED_FINALITY_SINK( actual_operation )
RETURN PASS
M-1.25 — REFERENCE PSEUDOCODE: ATTENUATED DELEGATION
FUNCTION PREPARE_DELEGATED_AUTHORITY( parent_authority,
child_request, delegate_identity ):
REQUIRE VERIFY_PARENT_AUTHORITY( parent_authority )
REQUIRE VERIFY_DELEGATE_IDENTITY( delegate_identity )
REQUIRE CHILD_SCOPE_WITHIN_PARENT( child_request, parent_authority )
REQUIRE CHILD_BUDGET_WITHIN_PARENT( child_request, parent_authority )
REQUIRE VERIFY_CURRENT_AUTHORITY_EPOCH()
delegated = PED.ATOMIC_PREPARE_DELEGATION({ parent:
HASH(parent_authority),
delegate: delegate_identity,
child_scope: child_request.scope,
child_budget: child_request.budget,
destination_sink:
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.2.3.32. Original Global Page 586
child_request.sink_id,
authority_epoch: CURRENT_AUTHORITY_EPOCH() })
RETURN delegated The destination sink independently verifies the
resulting authority against the actual operation.
M-1.26 — REFERENCE PSEUDOCODE: EFFECTUATION-COVERAGE VERIFICATION
FUNCTION VERIFY_EFFECTUATION_COVERAGE( candidate_act,
actual_operation, protected_surface_registry ):
normalized_effect = RESOLVE_CONSEQUENCE_CLASS(actual_operation)
required_surfaces = protected_surface_registry.RESOLVE_PATHS(
normalized_effect )
IF required_surfaces IS UNKNOWN: RETURN COVERAGE_UNVERIFIED
FOR EACH surface IN required_surfaces:
IF NOT VERIFY_CURRENT_SURFACE_IDENTITY(surface): RETURN
COVERAGE_UNVERIFIED
IF NOT VERIFY_MANDATORY_FINALITY_CONTROL(surface): RETURN
COVERAGE_UNVERIFIED
IF NOT VERIFY_CURRENT_CONFIGURATION(surface): RETURN
COVERAGE_UNVERIFIED
commitment = PROTECTED_COMMIT({ effect_class: normalized_effect,
covered_surfaces: HASH_CANONICAL(required_surfaces),
operation: HASH(actual_operation),
environment_epoch: CURRENT_ENVIRONMENT_EPOCH()
5.2.3.33. Original Global Page 587
RETURN commitment The completeness guarantee is limited to the
effectuation paths that the registry and underlying discovery
mechanism can reliably identify.
M-1.27 — REFERENCE PSEUDOCODE: PROTECTED FINALITY WITH OPTIONAL
MODULES
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION EFFECTUATE_WITH_MISCELLANEOUS_MODULES( candidate_act,
finality_sink, protected_policy ):
actual_operation = finality_sink.RECONSTRUCT_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_OPERATION( candidate_act, actual_operation )
required_modules = RESOLVE_MANDATORY_MODULES( candidate_act,
protected_policy )
IF "COVERAGE" IN required_modules:
REQUIRE VERIFY_EFFECTUATION_COVERAGE( candidate_act,
actual_operation, PROTECTED_SURFACE_REGISTRY )
IF "ACTION_CONTRACT" IN required_modules:
REQUIRE VALIDATE_DYNAMIC_ACTION( candidate_act, actual_operation,
CURRENT_ACTION_CONTRACT )
IF "DELEGATION" IN required_modules:
REQUIRE VERIFY_ATTENUATED_AUTHORITY_CHAIN( candidate_act,
actual_operation )
5.2.3.34. Original Global Page 588
IF "PRIVACY" IN required_modules:
REQUIRE VERIFY_CUMULATIVE_PRIVACY_STATE( actual_operation )
IF "RESOURCE_BUDGET" IN required_modules:
REQUIRE VERIFY_RESOURCE_ALLOCATION_STATE( actual_operation )
IF "ENVIRONMENT" IN required_modules:
REQUIRE VERIFY_CURRENT_ENVIRONMENT_EPOCH( actual_operation )
IF "CAUSAL_RECEIPT" IN required_modules:
REQUIRE VERIFY_AUTHORIZED_IEV_RECEIPT( actual_operation )
REQUIRE finality_sink.VERIFY_SCOPED_AUTHORITY( candidate_act,
actual_operation )
consumption = finality_sink.ATOMIC_CONSUME( candidate_act,
actual_operation )
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
IF consumption != SUCCESS: RETURN DENY
RETURN finality_sink.EFFECTUATE( actual_operation, consumption ) The
module set is determined by protected authority rather than by the
untrusted requesting entity.
M-1.28 — REFERENCE PSEUDOCODE: POST-UPDATE REATTESTATION
FUNCTION REATTEST_AFTER_ENVIRONMENT_CHANGE( update_event,
protected_controller ):
5.2.3.35. Original Global Page 589
REQUIRE VERIFY_UPDATE_EVENT( update_event )
new_epoch = protected_controller.ADVANCE_ENVIRONMENT_EPOCH()
discovered_surfaces = DISCOVER_CURRENT_EFFECTUATION_SURFACES()
verified_contracts = VERIFY_CURRENT_ACTION_CONTRACTS()
coverage = VERIFY_REQUIRED_ENFORCEMENT_PATHS( discovered_surfaces,
verified_contracts )
IF coverage != VERIFIED:
protected_controller.RESTRICT_AFFECTED_EFFECTS(
update_event.affected_effect_classes )
RETURN REATTESTATION_FAILED
commitment = protected_controller.ATOMIC_COMMIT({ environment_epoch:
new_epoch,
surface_commitment: HASH_CANONICAL(discovered_surfaces),
contract_commitment: HASH_CANONICAL(verified_contracts),
valid_coverage: TRUE })
RETURN commitment
M-1.29 — WORKED EXAMPLE A: NEWLY DISCOVERED ENTERPRISE TOOL
An enterprise autonomous agent is authorized to prepare and store an
internal report.
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
During execution, the agent discovers a newly available tool
described as a document-management utility.
The new tool supports both local report formatting and remote
sharing.
5.2.3.36. Original Global Page 590
A conventional orchestration system may expose the entire tool
interface once the tool has been registered.
Under the present embodiment, the protected tool-discovery module
identifies the tool's consequential operation classes.
It establishes a DAC-M identifying which functions merely transform
data and which can transmit data externally.
The protected effectuation-surface registry associates the external-
sharing function with a designated network or application Finality
Sink.
The agent may continue performing permitted local formatting.
However, a proposed external transmission becomes a separate
Candidate Act.
The protected system verifies the intended document, destination,
current task authority, action contract, and actual outgoing request.
The final sink refuses a transmission not covered by valid authority.
If a later software update adds a new external transmission
interface, the enforcement-coverage mechanism may require
reattestation before that effect is permitted.
The technical distinction is the protected connection between dynamic
tool semantics, effectuation-surface discovery, and actual finality
enforcement.
M-1.30 — WORKED EXAMPLE B: CROSS-PROVIDER AUTONOMOUS DELEGATION
An autonomous agent is authorized to modify a defined group of cloud
resources.
The agent delegates a narrow diagnostic task to another autonomous
service.
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The second service operates under a different administrative
provider.
The parent authority permits diagnostics but does not permit deletion
of resources.
A DAAC binds the delegated task to the original limited scope.
The downstream service may compute diagnostic recommendations.
If it proposes a consequential resource change, the receiving
protected controller constructs a Candidate Act and verifies the
delegation lineage.
The destination Finality Sink checks the actual resource operation.
An attempted deletion is rejected because it exceeds the delegated
scope.
The protected system does not rely merely upon the downstream agent's
declaration that its request is part of the original diagnostic task.
The technical distinction is the preservation of enforceable
authority attenuation across independently administered autonomous
systems.
5.2.3.37. Original Global Page 591
M-1.31 — WORKED EXAMPLE C: HARDWARE ACCELERATOR DIRECT EFFECT
An autonomous computing application processes information using a
hardware accelerator.
The accelerator may also initiate direct memory operations or produce
data through an output interface.
The protected system identifies the effect-capable accelerator
pathways relevant to the requested operation.
A PNED describes the permitted consequential effect.
An authenticated command descriptor binds the actual accelerator
operation to the protected authorization.
Before the accelerator releases the governed external effect, an
appropriate protected hardware or device controller verifies the
required authority.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
If the accelerator command is materially changed after validation,
the controller refuses or invalidates the operation according to the
implemented command-integrity mechanism.
Where the accelerator possesses a direct effectuation path outside
the relevant controller, the asserted enforcement coverage must be
extended or qualified.
This example demonstrates that protected execution finality is not
limited to ordinary CPU-mediated application tool calls.
M-1.32 — WORKED EXAMPLE D: SOFTWARE UPDATE CREATES A NEW BYPASS PATH
A protected application originally performs external transmissions
through one controlled dispatcher.
The security architecture verifies outbound operations at that
dispatcher.
A later software update introduces an additional transmission
mechanism.
Without coverage revalidation, the new mechanism might permit an
operation to bypass the original Finality Sink.
Under the present embodiment, the update advances the protected
environment epoch.
The system determines whether the new interface can produce the same
protected consequential effect.
Where the new interface is not yet covered, relevant finality
authority is restricted.
The updated interface may be registered with an appropriate mandatory
sink.
Once the new enforcement configuration is verified, permitted
operations may resume under current protected authority.
5.2.3.38. Original Global Page 592
The technical distinction is the use of enforcement-coverage
continuity as an authorization predicate following environment
changes.
M-1.33 — WORKED EXAMPLE E: AUTONOMOUS PHONE SENSOR DISCLOSURE
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An autonomous assistant operating on a mobile device is authorized to
analyze selected local sensor data.
The user has not authorized unrestricted external disclosure.
The assistant may perform computation over the sensor data.
A proposed external transmission becomes a separate consequential
Candidate Act.
A privacy module evaluates the destination and cumulative exposure
state.
A protected device gateway verifies the actual outgoing data and
applicable authority.
The assistant may select a local or remote model for computation, but
switching model route does not automatically authorize additional
private-data disclosure.
If the remote route requires new data transmission, that effect
receives separate protected validation.
A device security controller may maintain the required authority and
exposure state.
This example illustrates the distinction between permission to
compute and permission to disclose.
M-1.34 — WORKED EXAMPLE F: MULTI-DEVICE AUTONOMOUS CONTINUITY
An autonomous workflow starts on one device and later transfers to
another device.
The unfinished task has a protected authority scope.
A migration controller establishes a new ownership epoch.
The former device's execution authority is fenced where exclusivity
is required.
The second device receives an authenticated attenuated authority
reference.
The second device's Finality Sink verifies the current ownership
epoch and actual operation.
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
If the successor operation also depends upon an earlier real effect,
a validator-accepted receipt may be required under CW-2.
The receiving sink verifies both the ownership state and causal
receipt.
A stale command from the original device is rejected.
The arrangement preserves protected authority across device migration
without treating the copied computational task state as unrestricted
execution permission.
5.2.3.39. Original Global Page 593
M-1.35 — WORKED EXAMPLE G: VERIFICATION UNDER RESOURCE PRESSURE
A protected industrial controller receives many operation requests.
Some requests contain malformed or excessive evidence objects.
A verification component has limited memory and processing capacity.
The protected system allocates work budgets according to defined
operation classes.
Requests exceeding their permitted validation budget may be rejected
or deferred.
A safety-relevant operation may receive reserved verification
capacity.
The controller does not authorize a consequential operation merely
because a deadline expires or verification resources are exhausted.
Where the required safe behavior is to withhold an actuator command,
the protected controller enforces that result.
The technical distinction is the preservation of mandatory finality
predicates under bounded computation and adversarial verification
load.
M-1.36 — ADVERSARIAL THREAT MODEL
M-1.36.1 — Unregistered Tool Introduction
An attacker introduces an effect-capable tool absent from the
protected registry.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system restricts sensitive effectuation until the relevant action
contract and enforcement path are established.
M-1.36.2 — Misleading Tool Description
A malicious tool describes itself as computationally harmless while
performing an external transmission.
The protected system requires actual effect classification or a
trusted enforcement interface rather than accepting the description
as authoritative.
M-1.36.3 — Tool Schema Mutation
An attacker changes the meaning of an operation parameter after
authorization.
The action-contract version and actual operation checks detect
material mismatch.
M-1.36.4 — Resource Alias Substitution
An attacker substitutes another resource under the same apparent
name.
Protected identity resolution and sink-time state checks prevent
unauthorized correspondence.
5.2.3.40. Original Global Page 594
M-1.36.5 — Alternate API Route
An agent invokes another application interface to produce the
governed effect.
The corresponding protected enforcement coverage must include that
route.
M-1.36.6 — Direct Device Route
An attacker accesses a hardware device through a lower-level
interface.
The effectuation boundary must enforce the required protected
authority where hardware-level non-bypassability is claimed.
M-1.36.7 — Unauthorized Delegation Expansion
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A downstream agent attempts to broaden the permitted task.
The destination sink verifies the delegation chain and rejects scope
expansion.
M-1.36.8 — Reusable Credential Theft
An attacker obtains an application credential.
Where the protected effectuation path separately requires operation-
bound authority, credential possession alone is insufficient for the
governed operation.
M-1.36.9 — Confused Credential Broker
An agent requests credential use for a different destination than the
authorized Candidate Act.
The broker verifies the actual request binding.
M-1.36.10 — Privacy Exposure Splitting
An agent divides a sensitive disclosure into multiple individually
small requests.
The protected privacy-state controller evaluates cumulative exposure
under its defined policy.
M-1.36.11 — Resource Budget Evasion
An agent distributes requests across multiple identities to avoid
resource limits.
The protected controller may associate relevant requests with their
authenticated principal or authority lineage.
The effectiveness of the association depends upon the available
identity evidence.
M-1.36.12 — Validator Flooding
An attacker generates many expensive verification requests.
The protected system enforces bounded validation work and fail-closed
behavior.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.2.3.41. Original Global Page 595
M-1.36.13 — Verification Deadline Manipulation
An attacker attempts to force an incomplete validation by exhausting
the available time.
The system applies the defined protected failure behavior rather than
assuming success.
M-1.36.14 — Protected State Rollback
An attacker restores an earlier authority or environment epoch.
Protected anti-rollback mechanisms prevent unauthorized reuse where
implemented.
M-1.36.15 — Firmware Update Bypass
An update removes or alters a required enforcement hook.
The reattestation procedure detects incompatible enforcement coverage
where its measurement and discovery assumptions hold.
M-1.36.16 — Malicious Update Rollback
An attacker installs an older configuration with weaker controls.
Protected epoch or configuration-state checks prevent acceptance of
stale authority.
M-1.36.17 — Accelerator Command Mutation
An accelerator command changes between authorization and dispatch.
Protected command-buffer integrity or actual controller-side
verification detects the mismatch.
M-1.36.18 — Unauthorized Direct-Memory Access
A peripheral attempts memory or device access outside its permitted
scope.
The applicable protected hardware control enforces the relevant
access boundary.
M-1.36.19 — Cross-Domain Identity Confusion
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A remote service presents an authority identifier valid in another
trust domain.
The receiving sink verifies issuer, audience, role, and domain
binding.
M-1.36.20 — Authority Split-Brain
Two devices attempt to exercise the same exclusive unfinished
authority.
Current ownership epochs and sink-local fencing reject stale
ownership.
M-1.36.21 — Offline Authority Overuse
A disconnected device attempts more operations than its preauthorized
offline budget permits.
5.2.3.42. Original Global Page 596
Protected local consumption state enforces the limit.
M-1.36.22 — Stale Revocation State
A disconnected device cannot receive a current revocation.
The system applies its bounded offline authority and expiry model
rather than assuming instantaneous remote revocation.
M-1.36.23 — Conflicting Multi-Principal Approval
One principal approves an effect while another mandatory principal
denies it.
The protected authority-composition rule preserves the required
denial.
M-1.36.24 — Remote Attestation Overclaim
An attested computing environment claims that a particular external
effect occurred.
The system requires effect-specific evidence where actual outcome is
relevant.
M-1.36.25 — Cryptographic Receipt Replay
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An old valid receipt is presented for a different operation.
The applicable operation binding, phase lineage, freshness, and
consumption state prevent unauthorized reuse.
M-1.36.26 — User-Visible Resource Drift
A selected object changes between user approval and execution.
Where semantic correspondence is required, the sink verifies the
actual target under the protected object identity.
M-1.36.27 — Compromised Protected Controller
An attacker compromises the component responsible for enforcing a
protected effect.
The claimed guarantee depends upon the identified trusted computing
base.
Additional independent protection may be required under a stronger
adversary model.
M-1.36.28 — Unknown Future Interface
A new effect-capable interface is not recognized by the current
discovery mechanism.
The system cannot claim universal coverage unless the relevant
interface is actually mediated or otherwise constrained.
M-1.36.29 — Misleading Cryptographic Proof
A valid proof establishes a narrow predicate but is presented as
proof of a broader external outcome.
5.2.3.43. Original Global Page 597
The verifier distinguishes what the proof establishes from what the
later operation requires.
M-1.36.30 — Malicious Recovery Operation
An autonomous agent proposes a broad corrective action following an
error.
The recovery operation requires its own appropriate authority and
finality verification.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.37 — NON-LIMITING FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not statements of
completed experimental results.
Experiment 1 — Effectuation-Surface Inventory: Enumerate protected
interfaces capable of producing a selected consequential effect.
Experiment 2 — Alternate Path Detection: Introduce a second interface
producing the same effect and determine whether coverage verification
detects it.
Experiment 3 — Dynamic Tool Registration: Register a newly discovered
effect-capable tool under an authenticated action contract.
Experiment 4 — Unregistered Tool Attempt: Attempt a protected effect
through a tool lacking valid registration.
Experiment 5 — Tool Contract Update: Change a security-relevant
operation parameter or side effect and verify contract revalidation.
Experiment 6 — Resource Alias Change: Rebind a resource alias after
authorization and verify current sink-side correspondence.
Experiment 7 — Cross-Interface Equivalence: Attempt the same resource
effect through two different protocols and verify common authority
constraints.
Experiment 8 — Delegation Attenuation: Delegate a narrow authority
and attempt an unauthorized scope expansion.
Experiment 9 — Cross-Provider Authorization: Verify delegated
authority at a remotely administered Finality Sink.
Experiment 10 — Credential Broker: Confirm that an agent cannot use a
protected reusable credential for an unrelated effect.
Experiment 11 — Privacy Composition: Perform several individually
permitted disclosures and verify the applicable cumulative
constraint.
Experiment 12 — Multi-Principal Approval: Require separate
authenticated authority from two relevant principals.
Experiment 13 — Protected Resource Allocation: Verify that an
allocation controller applies the specified protected resource
policy.
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Experiment 14 — Validation Work Limit: Submit oversized or
computationally expensive evidence and verify bounded resource
consumption.
5.2.3.44. Original Global Page 598
Experiment 15 — Deadline Failure: Exhaust the available validation
window and verify the defined protected failure behavior.
Experiment 16 — Post-Update Coverage: Introduce a new effect-capable
interface through a software update and verify the required
reattestation response.
Experiment 17 — Stale Contract Authority: Attempt to exercise
authority bound to a superseded incompatible tool contract.
Experiment 18 — Accelerator Egress: Submit an accelerator-generated
effect requiring controller-side authorization.
Experiment 19 — Command Mutation: Alter a protected accelerator
command after approval.
Experiment 20 — Cross-Device Migration: Transfer unfinished authority
and verify rejection of stale-owner effectuation.
Experiment 21 — Offline Consumption: Exercise bounded authority while
disconnected and verify local consumption limits.
Experiment 22 — Offline Revocation Limit: Examine the system's actual
guarantee during unavailable remote connectivity.
Experiment 23 — Causal Receipt Integration: Require a validator-
accepted earlier real-effect receipt for a successor operation.
Experiment 24 — Conflicting Agent Operations: Combine miscellaneous
modules with a protected conflict reservation under Embodiment 1.
Experiment 25 — Actual Remote Outcome: Verify that a remote
acceptance acknowledgement is not silently treated as proof of
completed external consequence.
Experiment 26 — Semantic Target Drift: Test changes in the actual
resource corresponding to a user-referenced object.
Experiment 27 — Privacy-Preserving Proof: Verify a narrow protected
predicate without releasing unnecessary raw data.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Experiment 28 — Post-Crash Recovery: Simulate a failure after
authority consumption but before final acknowledgement.
Experiment 29 — Module Omission: Attempt to suppress a mandatory
specialized verification module through an agent-supplied request
field.
Experiment 30 — Integrated Component: Implement registry, verifier,
and sink within a single protected controller.
M-1.38 — MEASURABLE TECHNICAL PROPERTIES
The present embodiment may be evaluated using measurable properties
including:
Effectuation-path discovery coverage.
5.2.3.45. Original Global Page 599
Unmediated interface detection.
Unauthorized alternate-path effect acceptance.
Tool contract mismatch rejection.
Actual-operation semantic correspondence.
Cross-interface resource alias resolution accuracy.
Delegation-scope violation rejection.
Protected credential misuse prevention.
Cumulative privacy-constraint enforcement.
Resource-budget verification correctness.
Validation work consumption.
Maximum verification latency.
Post-update enforcement-coverage recovery.
Protected authority invalidation after contract changes.
Accelerator command-integrity enforcement.
Direct effectuation-path protection.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Cross-domain authority authentication.
Cross-device stale-owner rejection.
Offline authority consumption correctness.
Crash-recovery state integrity.
Receipt-dependent continuation correctness where CW-2 is integrated.
Actual external-outcome classification accuracy where outcome
witnessing is required.
The metrics should be evaluated under a stated technical threat
model.
A measurement showing that one path is protected does not establish
that all possible effectuation paths are protected.
M-1.39 — DISTINCTIONS FROM CONVENTIONAL SYSTEMS
M-1.39.1 — Conventional Tool Registries
A conventional tool registry may identify available functions.
5.2.3.46. Original Global Page 600
The present embodiment may additionally make verified effectuation
coverage and current operation-contract semantics mandatory
predicates for protected finality.
M-1.39.2 — Conventional API Gateways
An API gateway may enforce access rules for requests passing through
it.
The proposed additional mechanism may verify whether alternative
relevant effectuation paths remain covered and invalidate authority
when mandatory coverage changes.
M-1.39.3 — Conventional Software Versioning
A software version identifier may describe an installed component.
The present embodiment may require verified semantic compatibility
between the authorized action contract and the actual command
presented to the sink.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.39.4 — Conventional Resource Identifiers
A resource identifier may refer to an application object.
The present embodiment may require authenticated cross-interface
correspondence and current identity verification for the actual
consequential target.
M-1.39.5 — Conventional Delegated Credentials
A delegated credential may allow a downstream service to act.
The proposed arrangement may additionally require protected
attenuation of effect-specific authority and destination-side
verification against the actual operation.
M-1.39.6 — Conventional Credential Brokers
A broker may protect secrets from requesting software.
The proposed technical distinction may concern operation-bound
exercise of the credential at an independently verified Finality
Sink.
M-1.39.7 — Conventional Privacy Permissions
A permission system may decide whether one disclosure is allowed.
The present embodiment may additionally evaluate protected cumulative
or correlated exposure and enforce the result at the actual release
boundary.
M-1.39.8 — Conventional Workload Scheduling
A scheduler may allocate processing resources according to priority.
The present embodiment may provide protected allocation evidence and
enforce resource-use authority at the corresponding controller.
M-1.39.9 — Conventional Remote Attestation
5.2.3.47. Original Global Page 601
Remote attestation may provide evidence about an execution
environment.
The present embodiment distinguishes verified environment identity
from authority over a specific external consequence.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.39.10 — Conventional Hardware Isolation
Hardware isolation may constrain access to devices or memory.
The proposed architecture may additionally bind actual hardware
effectuation to operation-specific protected finality authority and
current command descriptors.
M-1.39.11 — Conventional Update Verification
A system may verify the authenticity of a software update.
The present embodiment may additionally reassess whether the updated
system continues to enforce all mandatory effectuation paths for a
defined consequence.
M-1.39.12 — Conventional Distributed Workflows
A distributed workflow may coordinate operations across services.
The present embodiment may require each consequential sink to verify
current scope, delegation lineage, and actual operation
correspondence rather than relying exclusively on upstream workflow
approval.
M-1.40 — PROPOSED INVENTIVE-STEP FOCUS
M-1.40.1 — General Qualification
The mechanisms disclosed in the present embodiment employ classes of
techniques that may individually be known.
These include access control, resource identity resolution,
distributed authorization, credential brokering, protected hardware,
transaction-state verification, cryptographic authentication, and
software update management.
The mere presence of these components does not establish inventive
step.
The candidate technical contributions concern specific combinations
and protected dependencies that govern actual consequential release.
M-1.40.2 — Candidate Inventive Concept A: Dynamic Enforcement-
Coverage Authority
A protected system identifies the effectuation interfaces capable of
producing a defined consequence.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
It commits current enforcement coverage against an authenticated
environment state.
A Finality Sink refuses the operation where a required interface
lacks valid protection.
5.2.3.48. Original Global Page 602
The possible technical contribution is making current coverage of
effectuation paths a necessary authority predicate.
M-1.40.3 — Candidate Inventive Concept B: Semantic Contract
Continuity
A protected system binds an authorized effect to a verified action-
contract representation.
Following a relevant tool update, it determines whether actual effect
semantics remain compatible.
The actual sink refuses use of stale authority where the action
contract has materially changed.
M-1.40.4 — Candidate Inventive Concept C: Protocol-Neutral
Consequence Binding
Several different software or hardware interfaces may express the
same consequential operation.
The system constructs a protocol-neutral protected effect descriptor
and verifies the actual effect against that descriptor.
The candidate technical distinction concerns consistent protected
finality enforcement across heterogeneous invocation mechanisms.
M-1.40.5 — Candidate Inventive Concept D: Cross-Interface Resource
Continuity
The system associates resource aliases with an authenticated
underlying resource identity.
The final sink verifies current correspondence and rejects
unauthorized rebinding or substitution.
M-1.40.6 — Candidate Inventive Concept E: Distributed Authority
Attenuation
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A parent authority is delegated across one or more autonomous
computing domains.
Each derived authority is constrained by the predecessor's permitted
consequential scope.
The receiving Finality Sink verifies the actual operation against the
protected delegation lineage.
M-1.40.7 — Candidate Inventive Concept F: Credential-Release Finality
A reusable credential remains under protected control.
Credential exercise is bound to the actual authorized Candidate Act
and verified at the consequential boundary.
The agent does not acquire unrestricted credential authority merely
because it requests a permitted operation.
M-1.40.8 — Candidate Inventive Concept G: Cumulative Protected
Privacy State
Individually permitted disclosures are evaluated against protected
cumulative privacy-exposure conditions.
The data-release Finality Sink verifies current exposure state and
actual outgoing data.
M-1.40.9 — Candidate Inventive Concept H: Resource-Bounded Finality
Verification
5.2.3.49. Original Global Page 603
A protected validator operates within explicit work, memory, latency,
or energy constraints.
An operation whose mandatory predicates cannot be established within
the permitted verification budget is withheld rather than
automatically approved.
M-1.40.10 — Candidate Inventive Concept I: Update-Triggered
Enforcement Reattestation
A material runtime or software change invalidates earlier
enforcement-coverage assumptions.
The system requires reattestation of relevant effectuation paths
before permitting protected consequential operations.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-1.40.11 — Candidate Inventive Concept J: Heterogeneous Hardware
Effect Finality
An accelerator or specialized hardware device produces an operation
capable of affecting persistent, external, or physical state.
The actual hardware effectuation controller verifies protected act-
specific authority independently of the requesting computation.
M-1.40.12 — Candidate Inventive Concept K: Cross-Domain Continuity
A protected authority remains scoped as autonomous computation
migrates among local, edge, cloud, or other execution environments.
The destination sink verifies current ownership, authority lineage,
and actual effectuation conditions.
M-1.40.13 — Candidate Inventive Concept L: Combined Coverage,
Semantics, and Authority
A stronger combined arrangement may require:
An authenticated inventory of effect-capable interfaces;
Current operation-contract validity;
Cross-interface resource identity;
Operation-specific protected authority;
And actual Finality Sink verification.
The protected authority becomes unusable where the current
environment no longer supports the assumptions under which the
operation was authorized.
This interaction may provide a narrower and more technically specific
focus than claiming individual modules independently.
M-1.41 — CANDIDATE OBJECTIVE TECHNICAL PROBLEM
An illustrative objective technical problem for selected
implementations of this embodiment is:
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.2.3.50. Original Global Page 604
How to maintain mandatory operation-specific execution-finality
enforcement when autonomous computing systems dynamically change
tools, interfaces, execution environments, delegation relationships,
resource identities, software versions, or hardware effectuation
pathways, while ensuring that actual consequential operations remain
bound to authenticated protected authority and current enforcement
coverage.
Different independent or dependent claims may address narrower
objective problems, including:
Preventing unauthorized effectuation through newly introduced
alternate paths.
Preventing stale authorization after material operation-semantics
changes.
Preventing delegation-induced scope expansion.
Preventing cumulative privacy exposure through independently
permitted disclosures.
Preserving protected finality validation under bounded resources.
Enforcing actual command authority for heterogeneous effect-capable
hardware.
The objective problem selected for a claim should correspond to the
technical differences actually present in that claim.
M-1.42 — HINDSIGHT AND PRIOR-ART CONSIDERATIONS
Inventive-step analysis should identify the closest relevant
technical disclosure for the particular optional mechanism.
For enforcement coverage, relevant prior art may include complete
mediation, reference monitors, sandboxing, and mandatory access-
control architectures.
For dynamic tool contracts, relevant prior art may include interface
compatibility verification, schema validation, software attestation,
and policy-controlled dispatch.
For delegated authority, relevant prior art may include capability
attenuation, delegation chains, and distributed authorization
systems.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
For hardware effects, relevant prior art may include device
isolation, protected command queues, direct-memory-access controls,
and hardware authorization.
For bounded verification, relevant prior art may include resource-
limited parsing, real-time verification, admission control, and
denial-of-service resistance.
The candidate inventive contribution must be evaluated against those
established techniques and their obvious combinations.
A new technical term does not establish novelty.
Likewise, the inclusion of multiple existing security components does
not automatically establish a non-obvious combination.
The relevant comparison is the enforceable technical relationship and
its demonstrated or technically supported effect.
5.2.3.51. Original Global Page 605
A broad claim should not assert universal non-bypassability where the
disclosed enforcement interfaces do not provide the required
coverage.
M-1.43 — INDUSTRIAL APPLICABILITY
The disclosed systems may be implemented in enterprise autonomous-
agent infrastructure, secure application gateways, mobile devices,
desktop assistants, cloud management platforms, embedded devices,
distributed service architectures, protected financial
infrastructure, storage controllers, communication networks, robotic
systems, autonomous vehicles, industrial control systems, and
heterogeneous computing environments.
In enterprise AI systems, the architecture may govern dynamically
discovered tools and cross-application operations.
In cloud infrastructure, it may bind delegated authority and
resource-state changes to current protected policy and actual
finality interfaces.
In mobile and desktop systems, it may govern application commands,
sensor releases, data exports, and privileged device operations.
In telecommunications infrastructure, it may enforce protected
authority for actual network configuration changes.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
In hardware computing platforms, it may apply operation-specific
finality requirements to effect-capable accelerators and peripherals.
In industrial automation, it may constrain physical actuator commands
and protect relevant state transitions.
In future autonomous environments, it may provide a protocol-neutral
security interface separating computational decision-making from
protected authority to produce external consequences.
The particular industrial implementation may rely upon software,
firmware, protected processors, cryptographic authorization,
authenticated communication, controller-local state, or suitable
combinations thereof.
The relevant technical utility lies in controlling actual
consequential operations despite changes in the systems that generate
or transport them.
M-1.44 — NON-LIMITING IMPLEMENTATION VARIATIONS
Variation M-1.A — Local Protected Gateway: The modules execute within
one protected device or software security service.
Variation M-1.B — Distributed Protected Authority: Verification and
effectuation occur in different authenticated domains.
Variation M-1.C — Hardware Enforcement Registry: A hardware
controller maintains the applicable effectuation-surface and
authority state.
5.2.3.52. Original Global Page 606
Variation M-1.D — Dynamic Tool Contract: Newly discovered tools
require current protected operation-contract verification.
Variation M-1.E — Protocol-Neutral Dispatcher: Several invocation
protocols are normalized into one effect descriptor.
Variation M-1.F — Protected Resource Alias Resolver: Multiple
application references are bound to a common resource identity.
Variation M-1.G — Delegation-Attenuation Service: Authority may be
narrowed across multiple agent generations.
Variation M-1.H — Credential Broker: Reusable credentials remain
outside agent control.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Variation M-1.I — Cumulative Privacy Controller: Protected exposure
state governs data release.
Variation M-1.J — Multi-Principal Authority: Several principals
contribute mandatory authorization predicates.
Variation M-1.K — Protected Resource-Parity Verifier: An allocation
decision is supported by authenticated comparable-workload evidence.
Variation M-1.L — Verification Work-Budget Controller: Security
checks operate within bounded protected resources.
Variation M-1.M — Deadline-Constrained Verification: A real-time
system uses approved bounded verification procedures.
Variation M-1.N — Thermal-Aware Verification: Protected scheduling
accounts for device thermal limits.
Variation M-1.O — Post-Update Reattestation: Software or firmware
changes trigger enforcement-coverage revalidation.
Variation M-1.P — Accelerator Finality Gate: A specialized device's
external effects require operation-specific protected authority.
Variation M-1.Q — Direct-Memory-Access Control: Device access is
governed by an applicable protected resource boundary.
Variation M-1.R — Confidential Execution Output Gate: Protected
computation remains separate from authority over external effects.
Variation M-1.S — Edge-to-Cloud Authority Continuity: Computation
migration preserves scoped finality constraints.
Variation M-1.T — Cross-Provider Agent Authority: Delegated agents
operate under authenticated constrained authority.
Variation M-1.U — Cross-Device Exclusive Ownership: Protected fencing
prevents stale-device authority.
5.2.3.53. Original Global Page 607
Variation M-1.V — Physical Actuation Controller: Actual actuator
commands are verified at an appropriate hardware boundary.
Variation M-1.W — Spatial Resource Correspondence: User-selected
spatial referents are bound to actual effect targets.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Variation M-1.X — Future Network Control: Autonomous communication
infrastructure requires protected configuration finality.
Variation M-1.Y — Intermittent-Connectivity Authority: Offline
effects are bounded by protected local scope and consumption state.
Variation M-1.Z — Machine-to-Machine Transactions: Autonomous
economic effects require appropriate scoped finality authority.
Variation M-1.AA — Privacy-Preserving Verification: Protected
predicates may be proved without disclosing unnecessary raw data.
Variation M-1.AB — Cryptographic Algorithm Agility: Authority records
support authenticated cryptographic migration.
Variation M-1.AC — Optional Causal IEV: Accepted earlier real-effect
receipts may govern later consequences.
Variation M-1.AD — Optional Cross-Agent Reservation: Effect conflict
state may impose additional mandatory finality conditions.
Variation M-1.AE — Optional Remote Consequence Witnessing: Cross-
domain evidence may establish the relevant actual remote result.
Variation M-1.AF — Integrated Controller: Several logical modules may
reside in one protected component.
Variation M-1.AG — Multiple Protected Controllers: The same required
finality predicates may be enforced across separate hardware or
software components.
Variation M-1.AH — Protected Update Rollback Resistance: Earlier
insecure configurations are not silently accepted under current
authority.
Variation M-1.AI — Unknown-Interface Restriction: An unverified
effect-capable interface remains restricted.
Variation M-1.AJ — Future Hardware Adapter: A new effect-capable
device may integrate through a protected operation and finality
contract.
The variations are optional and may be combined where technically
compatible.
M-1.45 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The following candidate claim-support concepts may be considered
individually or in appropriately supported combinations.
5.2.3.54. Original Global Page 608
Aspect 1: A protected registry identifying effect-capable interfaces
associated with a defined consequence class.
Aspect 2: A current effectuation-coverage commitment verified before
actual effectuation.
Aspect 3: A Candidate Act bound to a current authenticated action-
contract version.
Aspect 4: Rejection of stale authority following a material
operation-semantics change.
Aspect 5: Protocol-neutral normalization of actual consequential
operation semantics.
Aspect 6: Protected comparison of different effectuation interfaces
producing equivalent consequential effects.
Aspect 7: Authentication of resource equivalence across multiple
application identifiers.
Aspect 8: Current resource-version verification at the actual sink.
Aspect 9: Dynamic discovery of newly introduced effect-capable tools.
Aspect 10: Restricted operation until the new tool's enforcement
coverage is established.
Aspect 11: Authenticated delegation attenuation across autonomous
agents.
Aspect 12: Destination-side verification of delegated authority
lineage.
Aspect 13: Protected credential exercise bound to an actual
authorized operation.
Aspect 14: Prevention of unrestricted credential possession by the
requesting agent.
Aspect 15: Protected cumulative privacy-exposure state governing
subsequent data release.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Aspect 16: Authenticated multi-principal authority composition.
Aspect 17: Protected resource-allocation evidence used at an actual
resource controller.
Aspect 18: Resource-bounded validation under adversarial input
conditions.
Aspect 19: Mandatory withholding when required verification cannot be
completed.
Aspect 20: Software-update-triggered advancement of a protected
environment epoch.
Aspect 21: Reattestation of effectuation coverage following a
relevant environmental change.
Aspect 22: Invalidation of authorization bound to an incompatible
earlier enforcement configuration.
Aspect 23: Actual effectuation verification for accelerator-
originated commands.
Aspect 24: Hardware command-buffer integrity and actual-operation
correspondence.
Aspect 25: Scoped authority continuity across local, edge, and remote
execution.
Aspect 26: Protected ownership fencing during cross-device authority
migration.
5.2.3.55. Original Global Page 609
Aspect 27: Bounded offline authority with protected consumption
state.
Aspect 28: Protected current authority checks after reconnection.
Aspect 29: Integration of a cryptographically identified IEV receipt
as an optional mandatory phase condition.
Aspect 30: Integration of protected conflict reservations from
multiple independently authorized agents.
Aspect 31: Integration of actual remote outcome evidence.
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Aspect 32: Privacy-preserving proof of a defined authorization or
resource predicate.
Aspect 33: Cryptographic identity or algorithm rotation without
unrestricted authority expansion.
Aspect 34: Hardware- and software-neutral operation-specific
protected finality interfaces.
Aspect 35: Enforcement of dynamically discovered effectuation routes
through a protected sink.
Aspect 36: Current semantic compatibility verification before
privileged credential release.
Aspect 37: Protected update reattestation combined with current
action-contract matching.
Aspect 38: Cross-provider delegated authority combined with
destination-side actual-operation reconstruction.
Aspect 39: Protected resource budgeting combined with fail-closed
validation under computational stress.
Aspect 40: Integration of multiple supplementary security predicates
within a common finality-enforcement architecture.
These are potential technical limitations rather than finalized
patent claims.
The appropriate scope depends upon the actual enabling disclosure,
claim dependencies, unity, and relevant prior art.
M-1.46 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present Miscellaneous Embodiment M-1 discloses additional
optional mechanisms for adapting protected execution-finality control
to dynamic, heterogeneous, and increasingly autonomous computing
systems.
The embodiment provides implementation support for protected
effectuation-surface discovery, current enforcement-coverage
commitments, protocol-neutral consequential-operation descriptors,
dynamic action-contract verification, resource identity
correspondence, delegated authority attenuation, protected
credential-release binding, privacy exposure composition, bounded
verification resources, post-update reattestation, and hardware-
specific effectuation control.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The mechanisms may be deployed separately or in compatible
combinations.
5.3. Embodiment 14: Effectuation-Path Discovery, Runtime Bypass
Detection and Hardware Attribution
Original source global pages 1222–1308; attachment TECHNICAL
SPECIFICATION -1063-1541.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.3.1. Architecture Diagram: Protected Components and Trust Boundaries
[Actual effect-capable resource graph]
|
[Enumerate API / IPC / socket / file / DMA paths]
|
[Classify monitor-only versus blocking controller]
|
[Authenticated coverage commitment + epoch]
|
[Detect topology update / bypass attempt]
|
[Recheck current coverage and actual FS]
|
[Fail closed on unprotected reachable path]
Figure 5: Embodiment 14: Effectuation-Path Discovery, Runtime
Bypass Detection and Hardware Attribution: architecture
5.3.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Pending CA reaches external-effect boundary]
|
<All required equivalent paths identified?>--NO-->[WITHHOLD]
| YES
<Each required path has blocking enforcement?>--NO-->[WITHHOLD]
| YES
<Topology/coverage generation current?>--NO-->[INVALIDATE]
| YES
<FS reconstructs exact operation?>--NO-->[REFUSE]
| YES
[Atomically consume and cause governed effect]
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Figure 6: Embodiment 14: Effectuation-Path Discovery, Runtime
Bypass Detection and Hardware Attribution: operational decision
flow
5.3.3. Page-Indexed Original Technical Text
5.3.3.1. Original Global Page 1222
EMBODIMENT 14
PROTECTED EFFECTUATION-PATH DISCOVERY AND RUNTIME BYPASS DETECTION
WITH DYNAMIC ENFORCEMENT INVALIDATION, HARDWARE RESOURCE ATTRIBUTION,
AND FINALITY-SINK COVERAGE REVALIDATION
14.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Discovery, Classification, and
Continuous Revalidation of Consequential Effectuation Paths Using
Authenticated Effect-Capable Resource Graphs, Mandatory Enforcement-
Coverage Commitments, Monitoring-versus-Blocking Capability
Verification, Runtime Topology-Change Fencing, Protected Hardware
Resource Attribution, Operation-Specific Coverage Epochs, and
Independent Finality-Sink Verification Before External Effectuation
14.0.1 — General Technical Description
The present Embodiment 14 discloses systems, methods, apparatus,
protected computing components, authenticated discovery protocols,
hardware and software enforcement mechanisms, machine-verifiable
resource and effectuation-path structures, protected configuration-
state transitions, dynamic enforcement-coverage procedures, and non-
limiting implementations for identifying and controlling
consequential execution paths available to autonomous computational
entities.
Such computational entities may comprise artificial-intelligence
agents, autonomous assistants, application services, cloud workloads,
operating-system processes, distributed computational services,
hardware accelerators, storage controllers, network functions,
robotic systems, communication devices, embedded processors, or other
entities capable of generating commands that produce external or
persistent effects.
An autonomous system may include a protected authorization controller
that examines proposed operations before permitting consequential
execution.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
However, the existence of a protected authorization controller does
not establish that every relevant consequential operation must pass
through it.
An agent may possess several effect-capable interfaces.
These may include a controlled application API, a direct network
socket, a local interprocess communication channel, a file-system
interface, a database driver, a credential broker, a device-
management interface, an accelerator command queue, a peripheral
interface, or another route capable of producing an external
consequence.
Some routes may include a mandatory blocking enforcement component.
Other routes may provide observation or audit records without
preventing effectuation.
Still other routes may be outside the relevant controller's
visibility.
5.3.3.2. Original Global Page 1223
Consequently, a system may correctly validate a particular Candidate
Act through one protected interface while remaining vulnerable to an
equivalent unauthorized effect performed through another interface.
The present embodiment addresses the technical integrity of the
actual enforcement topology.
In a principal implementation, a protected effectuation-path
controller establishes an authenticated representation of relevant
effect-capable resources, reachable interfaces, enforcement
components, and resource ownership relationships.
A protected verifier determines which identified paths are subject to
mandatory operation-specific blocking enforcement.
The verifier distinguishes such paths from monitoring-only
interfaces, advisory policy checks, or controls lacking the authority
to prevent the actual effect.
The system associates its authorization state with an authenticated
enforcement-coverage generation.
When a material change occurs to the software, hardware, routing,
tool, device, resource, or enforcement configuration, affected
coverage authority is invalidated or fenced.
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected discovery and revalidation procedure determines whether
the current effectuation topology remains enforceable.
The corresponding Finality Sink verifies the current applicable
coverage state and reconstructs the actual operation before
permitting the governed consequence.
The system thereby prevents a previously established authorization
from remaining effective merely because the controlled route was
valid at an earlier time.
14.0.2 — Fundamental Technical Principle
A valid authorization does not establish safe consequential execution
unless the actual path through which the operation becomes effective
remains subject to the required enforcement.
A protected system distinguishes:
The existence of an authorization policy;
The existence of a monitoring component;
The existence of an enforcement hook;
The effectiveness of that hook for a particular consequential
operation;
The completeness of relevant path coverage;
The continued validity of the enforcement configuration;
5.3.3.3. Original Global Page 1224
And the independent authorization of the actual pending effect.
A route capable only of logging an operation does not automatically
constitute a blocking Finality Sink.
A previously measured enforcement topology does not automatically
remain current after a material update.
14.0.3 — Principal Proposed Inventive Concept
The principal candidate inventive technical combination concerns a
mandatory relationship among:
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An authenticated description of the covered effect-capable
environment;
A protected classification of consequential resources and interfaces;
A machine-verifiable representation of relevant effectuation paths;
Qualified evidence concerning mandatory blocking enforcement on those
paths;
A protected enforcement-coverage commitment;
A current coverage-generation or epoch state;
Protected detection or notification of topology-changing events;
Invalidation or fencing of affected consequential authority;
A controlled revalidation procedure;
And a Finality Sink that independently verifies current coverage and
actual operation-specific authority before permitting the
consequence.
The coverage commitment does not itself authorize an operation.
It establishes one necessary condition for exercising otherwise valid
operation-specific authority through the governed enforcement
topology.
14.0.4 — Core Anti-Bypass Principle
The system is designed so that, within the declared and enforced
protection boundary, a consequential operation cannot validly reach
its protected resource through an unverified alternative effectuation
path.
The implementation may achieve this through mandatory mediation of
relevant interfaces, protected configuration, resource-specific
command authorization, hardware enforcement, removal of uncontrolled
interfaces, or suitable combinations.
5.3.3.4. Original Global Page 1225
The system does not assume that discovering one path proves that
every possible physical or software path has been discovered.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The claimed coverage guarantee must correspond to the actual
controlled environment and qualified evidence.
14.0.5 — Distinction Between Detection and Prevention
Detection of an unauthorized operation after it has occurred is not
equivalent to withholding the operation before it becomes effective.
The present embodiment may incorporate monitoring for identifying
relevant topology changes or attempted bypass.
However, the principal protected finality configuration requires a
blocking or otherwise effective withholding mechanism at the
applicable consequential boundary.
A monitoring component may contribute evidence to revalidation
without itself constituting the required effectuation gate.
14.0.6 — Current and Future Implementations
The embodiment may be implemented with controlled application
dispatchers, operating-system mandatory access-control facilities,
protected network gateways, device drivers, transactional resource
controllers, secure execution environments, hardware command gates,
authenticated service registries, or other current technical
mechanisms.
Advanced variations may govern direct accelerator egress,
heterogeneous interconnects, dynamically loaded tools, programmable
network devices, multi-agent cloud services, remote device actuation,
confidential computing, and future autonomous infrastructure.
A particular vendor, kernel, operating system, processor,
communication protocol, or enforcement technology is not required
unless selected for a specific implementation.
14.0.7 — Relationship to Common Workflows
The embodiment may employ Candidate Acts, Non-Effective State,
Protected Enforcement Domains, authenticated validation evidence,
scoped non-bearer finality authority, and independent Finality Sinks
from CW-1.
Where an operation depends upon a qualified earlier real effect, the
accepted receipt-constituted causal continuation mechanism of CW-2
may additionally apply.
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Where a newly discovered effectuation path changes the scope of an
operation beyond valid authority, appropriate reauthorization under
CW-3 may be required.
Coverage validation does not replace mandatory causal receipt
validation where the latter is an expressly required authority
component.
14.0.8 — Relationship to Earlier Embodiments
5.3.3.5. Original Global Page 1226
Embodiments 1 and 11 may govern conflicting operations and version-
bound resource reservations across the identified effectuation paths.
Embodiment 2 may govern causal continuation following an earlier
verified effect.
Embodiments 3 and 4 may support actual resource correspondence and
qualified effect observation.
Embodiment 5 may bound resources used by discovery and verification.
Embodiment 6 may identify a changed tool contract introducing a new
consequential path.
Embodiment 7 may preserve authorization and effectuation requirements
across delegated agents and providers.
Embodiment 8 may govern cumulative disclosure through the discovered
data-egress interfaces.
Embodiment 9 may govern device ownership and direct hardware
authority.
Embodiment 10 may bind enforcement validity to the current model,
runtime, or algorithmic generation.
Embodiment 12 may control recovery following an actual bypass or
incomplete enforcement transition.
Embodiment 13 may require qualified collective approval before
selected protected topology changes.
Miscellaneous Embodiment M-1 may supply optional general
effectuation-surface registry, coverage, and update infrastructure.
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The present Embodiment 14 develops the operational mechanism for
establishing, invalidating, restoring, and enforcing coverage of
actual effect-capable paths, with particular attention to alternative
routes, hardware resources, and runtime configuration changes.
Previously completed embodiments remain unchanged.
14.1 — TECHNICAL FIELD
The present embodiment relates to autonomous computing security,
system-call mediation, protected execution-finality control, software
and hardware reference-monitor architectures, effectuation-path
discovery, security topology verification, mandatory access control,
device command authorization, runtime enforcement integrity, direct-
memory-access security, network egress control, and protected
configuration-state management.
5.3.3.6. Original Global Page 1227
More particularly, it concerns determining whether all relevant
consequential operations within a declared controlled domain remain
subject to current mandatory enforcement and preventing stale
enforcement assumptions from authorizing subsequent external effects.
The disclosed technology may be implemented in software, firmware,
operating-system security components, protected processors, hardware
security controllers, network appliances, storage infrastructure,
embedded devices, and distributed autonomous computing environments.
14.2 — SPECIFIC TECHNICAL PROBLEMS
14.2.1 — Protected Gateway Bypass
An autonomous application may use a direct resource interface instead
of the approved gateway.
14.2.2 — Monitoring Mistaken for Enforcement
An interface may record events without possessing authority to block
them.
14.2.3 — Incomplete Resource Discovery
An enforcement system may omit an effect-capable device, service, or
communication route.
14.2.4 — Dynamic Tool Registration
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A newly installed or registered tool may expose a previously absent
consequential interface.
14.2.5 — Runtime Service Replacement
A protected service may be replaced by an implementation that does
not enforce the original authorization conditions.
14.2.6 — Kernel Hook Removal
An enforcement hook may be detached, disabled, replaced, or bypassed
through another kernel path.
14.2.7 — Alternate Network Route
An agent may communicate through another socket, network namespace,
interface, proxy, tunnel, or device.
14.2.8 — Credential-Based Bypass
An agent may exercise a broad reusable credential through an
interface outside the operation-specific authority gate.
5.3.3.7. Original Global Page 1228
14.2.9 — Database Direct Connection
An agent may bypass an authorized query or mutation gateway through a
direct database connection.
14.2.10 — File-System Bypass
A file may be modified through an alternative path, descriptor,
mount, or privileged service.
14.2.11 — Interprocess Communication Bypass
A lower-trust process may request a privileged local service to
produce an effect indirectly.
14.2.12 — Device-Driver Bypass
A privileged driver or alternate device interface may produce effects
without consulting the protected finality policy.
14.2.13 — Direct Memory Access
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A hardware component may modify memory or transmit data through
hardware paths not visible to an application-level gateway.
14.2.14 — Accelerator Command Egress
A GPU, NPU, or other accelerator may initiate memory, storage,
network, or device commands through distinct queues or controllers.
14.2.15 — Hardware Ownership Change
A resource may migrate between devices or administrative controllers,
invalidating an earlier enforcement assumption.
14.2.16 — Configuration Drift
A software update may change the protected route from mandatory
blocking to optional advisory behavior.
14.2.17 — Enforcement Rule Downgrade
A policy update may permit previously blocked effects.
14.2.18 — Dynamic Resource Alias
An authorized logical target may resolve to a different actual
resource or effectuation path.
14.2.19 — Encrypted Egress
A content-blind network gate may lack visibility into the plaintext
information required for a particular disclosure policy.
5.3.3.8. Original Global Page 1229
14.2.20 — Race During Enforcement Update
An operation may be released while the controlled topology is being
modified.
14.2.21 — In-Flight Commands
A command may already have crossed its effective release boundary
before invalidation occurs.
14.2.22 — Stale Coverage Evidence
A previously valid enforcement attestation may be reused after the
topology changes.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.2.23 — Distributed Coverage Disagreement
Several effectuation controllers may hold inconsistent coverage
generations.
14.2.24 — Unknown Hardware Path
A device may expose an unrecognized command surface or direct data
pathway.
14.2.25 — Technical Objective
A candidate objective technical problem is:
How to prevent autonomous consequential operations from bypassing
otherwise valid authorization controls when effect-capable
interfaces, software topology, routing, devices, or hardware command
paths change, by maintaining protected evidence of mandatory
enforcement coverage, invalidating stale coverage-bound authority,
and independently verifying current effectuation-path validity at the
actual consequential sink.
14.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
14.3.1 — Reference Monitors
Reference-monitor principles, including complete mediation, tamper
resistance, and verifiability, are established.
The embodiment does not claim their original invention.
14.3.2 — Mandatory Access Control
Operating systems may implement mandatory security policy at
protected resource interfaces.
These mechanisms are established.
5.3.3.9. Original Global Page 1230
A particular mandatory access-control configuration does not
automatically cover all effects outside its actual enforcement scope.
14.3.3 — Kernel Security Hooks
Operating systems may expose security hooks through which privileged
security components inspect or restrict operations.
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The presence of a hook does not automatically establish that it is
attached, configured to deny, or invoked for every relevant effect
path.
14.3.4 — Sandboxing
A sandbox may constrain file, network, device, and process
operations.
Sandboxing is established.
The actual security properties depend upon its isolation boundary and
permitted privileged interfaces.
14.3.5 — Network Firewalls and Proxies
Firewalls and proxies may block or inspect specified communication
classes.
These techniques are established.
An application may possess alternative communication paths unless
those routes are appropriately constrained.
14.3.6 — Device Access Control
Device permissions and hardware security mechanisms may restrict
access to peripherals and command queues.
These controls are established.
Their effectiveness depends upon actual device ownership and
enforcement configuration.
14.3.7 — Remote Attestation
An attestation protocol may produce qualified evidence regarding
aspects of an environment.
Attestation does not automatically establish that every consequential
interface is controlled or that the actual pending operation is
authorized.
14.3.8 — Resource Inventory and Topology Discovery
Systems may inventory services, devices, processes, network
interfaces, and dependencies.
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Discovery is established.
5.3.3.10. Original Global Page 1231
An inventory entry does not automatically establish a mandatory
enforcement gate for the resource.
14.3.9 — Change Management
Software and infrastructure systems may monitor or approve
configuration changes.
Change management is established.
The proposed additional relationship concerns protected automatic
invalidation of consequential authority dependent upon the changed
enforcement topology.
14.3.10 — Candidate Technical Distinction
The candidate contribution concerns connecting actual effectuation-
path coverage, protected topology epochs, change-triggered authority
invalidation, and independent current Finality-Sink verification as
mandatory technical dependencies of consequential execution.
14.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
A Protected Effect-Capable Resource Enumerator;
An Authenticated Effectuation-Path Graph Builder;
A Protected Enforcement Capability Classifier;
A Mandatory Mediation Coverage Verifier;
A Runtime Topology Change Observer;
A Protected Enforcement Configuration Controller;
A Coverage Epoch and Invalidation Controller;
A Hardware Resource Attribution Component;
A Coverage Revalidation Authority;
An Operation-Specific Finality Authority Controller;
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And one or more actual Finality Sinks.
Optional components may include an operating-system security monitor,
service registry, network namespace controller, device-enumeration
service, DMA protection controller, hardware command gate, protected
credential broker, cryptographic attestation verifier, distributed
enforcement coordinator, and adversarial path-probing test service.
5.3.3.11. Original Global Page 1232
A particular implementation need not include every optional
component.
The mandatory selected components must together provide the
enforcement properties expressly required by the claimed effectuation
class.
14.4.1 — Resource Enumerator
Identifies relevant effect-capable resources and interfaces within
the declared protection boundary.
14.4.2 — Effectuation Graph Builder
Represents paths connecting computational requesters to consequential
resources.
14.4.3 — Enforcement Classifier
Determines whether identified controls block effects, only observe
them, or provide insufficiently established enforcement.
14.4.4 — Coverage Verifier
Checks that the relevant consequential paths satisfy the applicable
mandatory mediation property.
14.4.5 — Topology Change Observer
Identifies events that may alter paths, gates, resource mappings, or
enforcement capabilities.
14.4.6 — Invalidation Controller
Fences affected consequential authority when its supporting coverage
assumptions are no longer established.
14.4.7 — Hardware Attribution Component
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Associates effect-capable hardware command and data paths with their
applicable controlling authority.
14.4.8 — Revalidation Authority
Evaluates the current enforcement topology after relevant changes.
14.4.9 — Finality Sink
Reconstructs the actual pending operation and verifies current path
coverage and operation-specific authority before effectuation.
14.5 — BROAD TECHNICAL DEFINITIONS
5.3.3.12. Original Global Page 1233
14.5.1 — Effect-Capable Resource
An Effect-Capable Resource, or ECR-14, means a software or hardware
resource capable of producing a consequential effect through at least
one relevant interface.
14.5.2 — Effectuation Path
An Effectuation Path, or EP-14, means a sequence of computational,
communication, or hardware interfaces through which a proposed
operation may reach an effect-capable resource.
14.5.3 — Protected Effectuation Graph
A Protected Effectuation Graph, or PEG-14, means an authenticated
representation of relevant effect-capable nodes, interfaces,
transitions, and enforcement components.
14.5.4 — Protected Enforcement Node
A Protected Enforcement Node, or PEN-14, means a component whose
configured capabilities support a specified mandatory effect-control
function.
14.5.5 — Monitoring-Only Node
A Monitoring-Only Node means an observer capable of recording or
reporting an operation without necessarily preventing it.
14.5.6 — Blocking Enforcement Predicate
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Blocking Enforcement Predicate, or BEP-14, means a condition
establishing that a designated enforcement component can prevent a
specified effect before the relevant consequence becomes effective.
14.5.7 — Protected Coverage Domain
A Protected Coverage Domain, or PCD-14, means the defined set of
resources, interfaces, paths, and threat assumptions over which an
enforcement-coverage guarantee is asserted.
14.5.8 — Mandatory Path Coverage
Mandatory Path Coverage means satisfaction of the requirement that
every relevant consequential path in a defined covered topology
traverses an effective protected enforcement condition.
14.5.9 — Effectuation Coverage Commitment
An Effectuation Coverage Commitment, or ECC-14, means an
authenticated representation of a validated enforcement topology and
its applicable coverage predicates.
14.5.10 — Coverage Epoch
5.3.3.13. Original Global Page 1234
A Coverage Epoch, or CE-14, means a protected generation identifying
the currently accepted enforcement-coverage configuration.
14.5.11 — Coverage Validity Predicate
A Coverage Validity Predicate, or CVP-14, means a machine-verifiable
rule determining whether current effectuation-path coverage satisfies
the selected policy.
14.5.12 — Coverage Invalidation Event
A Coverage Invalidation Event, or CIE-14, means a detected or
authorized change rendering one or more previously accepted coverage
assumptions invalid or requiring revalidation.
14.5.13 — Protected Coverage Fence
A Protected Coverage Fence, or PCF-14, means a protected state or
enforcement condition preventing affected consequential effects
during unresolved coverage validity.
14.5.14 — Protected Topology Transition
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Protected Topology Transition, or PTT-14, means an authenticated
update to relevant effect-capable interfaces, resource mappings,
enforcement nodes, or their configuration.
14.5.15 — Actual Effectuation Route
An Actual Effectuation Route, or AER-14, means the route actually
used or presented for a specified consequential operation.
14.5.16 — Alternate Bypass Route
An Alternate Bypass Route, or ABR-14, means an effect-capable path
that would circumvent a required enforcement condition.
14.5.17 — Enforcement Capability Evidence
Enforcement Capability Evidence, or ECE-14, means qualified evidence
concerning the blocking, monitoring, isolation, and operational
properties of an enforcement component.
14.5.18 — Enforcement Attachment Evidence
Enforcement Attachment Evidence, or EAE-14, means authenticated
evidence that a relevant enforcement component is configured and
attached at a specified interface.
14.5.19 — Protected Resource Attribution
Protected Resource Attribution, or PRA-14, means qualified
association of an actual effect-capable resource or device interface
with its relevant requester, controller, ownership domain, and
enforcement state.
14.5.20 — Hardware Effectuation Surface
5.3.3.14. Original Global Page 1235
A Hardware Effectuation Surface, or HES-14, means a hardware command,
memory, storage, network, peripheral, accelerator, or other interface
capable of producing a relevant consequence.
14.5.21 — Protected Device Path Commitment
A Protected Device Path Commitment, or PDPC-14, means authenticated
evidence relating a device resource and its current effect-capable
interface to an applicable enforcement controller.
14.5.22 — Coverage Revalidation Receipt
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Coverage Revalidation Receipt, or CRR-14, means authenticated
evidence indicating the result and applicable scope of a protected
coverage revalidation procedure.
14.5.23 — Operation-Bound Coverage Authority
Operation-Bound Coverage Authority, or OBCA-14, means a finality
enablement whose validity depends upon the current accepted coverage
state for the relevant actual operation.
14.5.24 — Protected Coverage Dependency Set
A Protected Coverage Dependency Set, or PCDS-14, means the collection
of topology, configuration, resource, or enforcement facts required
to establish current coverage for a specified effect class.
14.5.25 — Coverage Completeness Assumption
A Coverage Completeness Assumption means a stated technical basis
under which the relevant effect-capable paths are considered
sufficiently enumerated or constrained.
14.5.26 — Enforcement-Path Assurance Level
An Enforcement-Path Assurance Level means a defined classification of
the evidence and technical guarantees supporting a particular path's
blocking capability.
14.5.27 — Protected Route Mutation
A Protected Route Mutation means a controlled change to a relevant
effectuation path or resource mapping.
14.5.28 — Enforcement Reattachment
Enforcement Reattachment means installation or restoration of a
required blocking component at a relevant effectuation interface.
14.5.29 — Residual Uncontrolled Surface
A Residual Uncontrolled Surface means a known or suspected effect-
capable path for which mandatory enforcement has not been
established.
5.3.3.15. Original Global Page 1236
14.5.30 — Path-Specific Fail-Closed State
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Path-Specific Fail-Closed State means a protected condition that
withholds governed consequential operations dependent upon unresolved
enforcement coverage.
14.5.31 — Coverage Authority Consumption
Coverage Authority Consumption means sink-local protected exercise of
operation-specific finality authority associated with the current
applicable coverage epoch.
14.5.32 — Protected In-Flight Effect State
Protected In-Flight Effect State means information concerning
operations that may already have crossed their relevant effectuation
boundary when coverage invalidation occurs.
14.5.33 — Revalidation Work Budget
A Revalidation Work Budget means a protected bound on the
computational, communication, or other resources consumed during
coverage verification.
14.5.34 — Coverage-Qualified Finality Sink
A Coverage-Qualified Finality Sink means an effectuation boundary
whose current mandatory enforcement capability has been established
under the applicable coverage policy.
14.5.35 — Protected Effectuation Coverage Continuity
Protected Effectuation Coverage Continuity means maintenance or safe
reestablishment of the required mandatory enforcement conditions
across relevant topology changes.
14.6 — PROTECTED EFFECT-CAPABLE RESOURCE INVENTORY
A protected controller may identify the resources and interfaces
through which covered computational entities can cause effects.
The inventory may include network interfaces, local sockets, file-
system mutation primitives, database connections, message brokers,
credential APIs, storage export interfaces, device command queues,
display or audio output controls, memory-mapped resources,
accelerator command interfaces, and other supported effect-capable
surfaces.
A representative record may comprise:
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
PROTECTED_EFFECT_RESOURCE = { resource_identifier, resource_class,
effectuation_interface_set, actual_controller_identity,
current_resource_owner,
5.3.3.16. Original Global Page 1237
administrative_domain, effect_classes, current_interface_generation,
hardware_or_software_identity, required_enforcement_policy,
relevant_trust_boundary, protected_resource_authentication }
The inventory may be constructed from qualified operating-system
facilities, device enumeration, authenticated service registration,
hardware resource descriptions, protected configuration, or other
suitable mechanisms.
14.6.1 — Declared Resources
The system includes resources expressly registered within the covered
domain.
14.6.2 — Discovered Resources
The system may discover additional interfaces through qualified
runtime enumeration.
14.6.3 — Derived Routes
A resource may expose an effect through another intermediary service
or hardware component.
14.6.4 — Resource Aliases
Different identifiers may refer to the same actual consequential
resource.
14.6.5 — External Resources
A remote service may control an effect beyond the local domain's
enforcement boundary.
14.6.6 — Unknown Resources
An unresolved resource path is not presumed safe merely because it is
absent from the current inventory.
14.6.7 — Controlled Enumeration
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The claimed completeness depends upon the protected system's ability
to enumerate or deny access to effect-capable resources in the
declared domain.
14.6.8 — Current Evidence
Historical resource inventory information may be insufficient
following material topology changes.
5.3.3.17. Original Global Page 1238
14.7 — PROTECTED EFFECTUATION GRAPH
The system may represent the relevant execution topology as a
directed graph.
(G = (V,E)) represent the covered effectuation graph. (S)
represent effect-requesting computational sources. (R) represent
protected consequential resources. (F) represent mandatory blocking
enforcement nodes. (P(s,r)) represent the relevant reachable paths
from source (s) to resource (r).
A selected coverage predicate may require:
[ \forall s\in S,\ \forall r\in R,\ \forall p\in P(s,r): \quad p\cap
F_{\mathrm{qualified}}\neq\varnothing ]
The expression states that every relevant path in the modeled
protected topology must traverse at least one qualified mandatory
enforcement condition.
This is a model-specific coverage statement.
It is not automatically proof that every unknown physical path or
privileged hardware interface has been enumerated.
14.7.1 — Graph Nodes
Nodes may represent agents, processes, gateways, drivers,
controllers, network interfaces, services, hardware units, or actual
resources.
14.7.2 — Graph Edges
Edges may represent permitted or physically realizable operation
forwarding, direct access, command dispatch, or data transmission.
14.7.3 — Edge Types
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Edges may distinguish computation-only communication from effect-
capable transitions.
14.7.4 — Qualified Enforcement Nodes
A blocking component is included as a valid enforcement node only for
operation classes it can actually constrain.
14.7.5 — Unqualified Nodes
Monitoring-only or unsupported control points do not satisfy
mandatory blocking coverage.
5.3.3.18. Original Global Page 1239
14.7.6 — Path Enumeration
The controller may enumerate supported paths directly or use
protected reachability analysis.
14.7.7 — Cut-Set Verification
A protected verifier may evaluate whether the mandatory enforcement
components form an effective cut between requesters and consequential
resources.
14.7.8 — Model Assumptions
The claimed safety depends upon accurate representation of the
effect-capable topology and protection of its mutation boundaries.
14.8 — BLOCKING ENFORCEMENT VERSUS MONITORING
A protected classifier identifies the actual enforcement capability
of each relevant component.
14.8.1 — Audit-Only Monitor
The component records or reports operations but does not necessarily
prevent them.
14.8.2 — Advisory Policy Service
The component returns an authorization recommendation that the
requester may ignore.
14.8.3 — Optional Middleware
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The component blocks operations only when a particular voluntary
application path invokes it.
14.8.4 — Mandatory Application Dispatcher
The component controls an effect-capable application primitive that
cannot be reached by covered requesters through an equivalent
unmediated path.
14.8.5 — Operating-System Enforcement
A protected operating-system facility may block selected relevant
operations under current policy.
14.8.6 — Hardware Enforcement
A protected device or hardware controller may refuse commands lacking
valid authorization.
14.8.7 — Protected Credential Controller
5.3.3.19. Original Global Page 1240
A credential service may prevent protected resource access by
withholding operation-bound credentials.
14.8.8 — Transactional Resource Sink
A resource controller may atomically refuse mutations whose mandatory
preconditions fail.
14.8.9 — Capability Classification
The protected system identifies which operation classes are actually
blocked by the component.
14.8.10 — Assurance Qualification
The existence of a blocking API is insufficient where a relevant
covered requester retains another uncontrolled means of producing the
same effect.
14.9 — ENFORCEMENT CAPABILITY EVIDENCE
A representative enforcement-capability record may comprise:
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
ENFORCEMENT_CAPABILITY_EVIDENCE = { enforcement_component_identifier,
actual_resource_or_interface, enforcement_attachment_point,
applicable_operation_classes, configured_enforcement_mode,
blocking_capability, mandatory_invocation_basis,
protected_configuration_generation, bypass_restriction_evidence,
controlling_authority_identity, trusted_observation_source,
verification_epoch, evidence_assurance_profile,
protected_authentication }
The evidence may establish that the component is attached at a
specified interface, configured to enforce a particular policy, and
supported by sufficient access restrictions to prevent covered
requesters from avoiding it.
14.9.1 — Configuration Evidence
The system verifies the current enforcement configuration.
14.9.2 — Attachment Evidence
5.3.3.20. Original Global Page 1241
The relevant mechanism is actually attached or integrated at the
intended resource boundary.
14.9.3 — Blocking Evidence
A defined denied operation is prevented before the specified
consequence.
14.9.4 — Mandatory Invocation
The covered requester cannot validly choose an alternative unmediated
route.
14.9.5 — Protected Update State
Material modification of the component is itself controlled or causes
invalidation.
14.9.6 — Evidence Limits
A successful test of one blocking condition does not establish
comprehensive security for every other operation class.
14.10 — PROTECTED COVERAGE DOMAIN
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system defines the scope within which complete mediation is
asserted.
A coverage domain may identify:
The covered requesting entities;
The permitted computational privileges;
The protected consequential resources;
The supported operation classes;
The effect-capable interfaces;
The applicable privileged components;
The trusted enforcement substrate;
And the allowed topology transitions.
An example protected domain may include an isolated autonomous-agent
environment with controlled filesystem, network, IPC, and resource
interfaces.
Another may be a protected database service.
Another may be a hardware command controller managing a defined
accelerator or actuator.
5.3.3.21. Original Global Page 1242
The system cannot assert complete mediation over a remote or
privileged environment beyond its actual enforcement and trust
coverage merely because it possesses a network diagram or service
inventory.
The protected domain must therefore be stated in technical terms
sufficient to support the claimed effect.
14.11 — COVERAGE COMMITMENT
An accepted coverage configuration may be represented by an
authenticated commitment.
EFFECTUATION_COVERAGE_COMMITMENT = { coverage_identifier,
coverage_domain, effect_resource_inventory_commitment,
effectuation_graph_commitment, qualified_enforcement_nodes,
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
required_enforcement_classes, protected_controller_identities,
current_resource_attribution_state, hardware_path_commitments,
mandatory_coverage_predicates, unresolved_surface_exclusions,
coverage_epoch, topology_configuration_epoch, current_policy_epoch,
validity_conditions, designated_finality_sinks,
protected_coverage_authentication }
The commitment may authenticate the configuration and the evidence
supporting the declared coverage property.
A signature over a graph does not independently prove that the graph
is complete.
The implementation must establish the required topology completeness
through an appropriate controlled resource-enumeration, interface-
denial, hardware restriction, or other protected mechanism.
14.12 — FORMAL COVERAGE VALIDITY
5.3.3.22. Original Global Page 1243
[ C(G,F,P,T) ]
represent the selected coverage predicate over graph (G), qualified
enforcement set (F), policy (P), and trusted configuration state (T).
A consequential operation (O) may require:
COVERAGE_VALID(O) = CURRENT_COVERAGE_EPOCH_VALID AND
REQUIRED_RESOURCE_IN_DOMAIN AND ACTUAL_EFFECT_ROUTE_QUALIFIED AND
REQUIRED_BLOCKING_MECHANISM_ACTIVE AND
CURRENT_RESOURCE_ATTRIBUTION_VALID AND
NO_UNRESOLVED_MATERIAL_INVALIDATION AND CURRENT_AUTHORITY_VALID
The finality predicate additionally requires actual operation-
specific validation.
EFFECTUATION_PERMITTED(O) = COVERAGE_VALID(O) AND
ACTUAL_OPERATION_WITHIN_AUTHORITY(O) AND REQUIRED_EVIDENCE_VALID(O)
AND SINK_LOCAL_STATE_VALID(O)
The coverage predicate is a necessary condition in the selected
principal implementation, not an independent grant of authority.
14.13 — RUNTIME EFFECTUATION-PATH DISCOVERY
The controller may discover relevant current paths using several
complementary mechanisms.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.13.1 — Application Interface Enumeration
The system identifies effect-capable functions registered with the
agent or application.
14.13.2 — Service Endpoint Enumeration
The system identifies reachable resource services and corresponding
access controls.
14.13.3 — Operating-System Interface Enumeration
The system identifies relevant process capabilities, handles,
descriptors, device interfaces, and protected operating-system paths.
14.13.4 — Network Topology Discovery
5.3.3.23. Original Global Page 1244
The system identifies permitted interfaces, namespaces, proxies, and
route classes.
14.13.5 — Storage Interface Discovery
The system identifies direct and mediated storage mutation paths.
14.13.6 — Device Enumeration
The system identifies effect-capable devices and applicable
controllers.
14.13.7 — Protected Configuration Analysis
The controller evaluates current declarative security configurations
and resource mappings.
14.13.8 — Dynamic Registration Observation
Newly introduced effect-capable interfaces may trigger immediate
invalidation or revalidation.
14.13.9 — Adversarial Path Testing
Authorized tests may attempt representative alternative routes to
establish selected blocking properties.
14.13.10 — Discovery Limitation
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system does not infer exhaustive absence of unknown paths from an
incomplete scan or a finite collection of successful tests.
14.14 — DYNAMIC TOOL AND APPLICATION ENROLLMENT
An autonomous execution environment may allow tools to be added,
updated, or removed while a task is active.
A new tool may expose a consequential operation not covered by the
original enforcement configuration.
14.14.1 — Tool Registration Event
The protected controller identifies the new executable or service
interface.
14.14.2 — Contract Verification
The tool's actual operation semantics are evaluated under the
applicable current technical contract.
14.14.3 — Effect-Class Discovery
5.3.3.24. Original Global Page 1245
New resource mutations or external disclosures are identified.
14.14.4 — Path Integration
The relevant effectuation graph is updated.
14.14.5 — Coverage Invalidation
Affected authorization is fenced pending enforcement verification.
14.14.6 — Mandatory Control
The new effect-capable path must be blocked or constrained before
receiving valid consequential authority.
14.14.7 — Revalidation
A current coverage commitment is established if the required
predicates pass.
14.14.8 — Denial
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A tool whose effectuation interface cannot be controlled may remain
unavailable for the governed consequential class.
14.15 — NETWORK EFFECTUATION-PATH COVERAGE
Network egress may occur through several interfaces.
A protected system may need to consider:
Application HTTP clients;
Direct sockets;
Local proxy connections;
Custom protocol clients;
Service-mesh routes;
Multiple network namespaces;
Alternative physical interfaces;
Privileged network helpers;
And device-originated transmission.
5.3.3.25. Original Global Page 1246
14.15.1 — Protected Egress Choke Point
The architecture may require all covered network effects to traverse
a designated protected gateway.
14.15.2 — Network Namespace Isolation
Covered workloads may be constrained to permitted interface and
routing arrangements.
14.15.3 — Protected Route Policy
Relevant routes may be subject to mandatory control.
14.15.4 — Final Destination
The actual destination may need to be verified after relevant name
resolution, redirection, or proxy routing.
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.15.5 — Alternate Interface
An interface bypassing the required gateway is blocked or separately
protected.
14.15.6 — Encrypted Egress
Where policy concerns plaintext semantics, the required enforcement
must occur at a trusted plaintext-aware boundary or through suitable
protected content binding.
14.15.7 — Network Tunnel
A tunnel may create another consequential path that requires
classification.
14.15.8 — Direct Device Egress
A hardware or device-level network path may require protected device-
controller enforcement.
14.16 — FILE-SYSTEM AND STORAGE COVERAGE
A protected agent may modify or export information through more than
one storage interface.
Potential paths may include ordinary file writes, direct block
access, memory-mapped modification, storage-service APIs, database
attachments, privileged helper processes, or device-originated
writes.
The protected system may constrain these paths through appropriate
operating-system enforcement, resource-specific controllers, or
hardware mechanisms.
14.16.1 — Actual Storage Object
5.3.3.26. Original Global Page 1247
The sink identifies the actual resource rather than relying solely
upon a caller-supplied path string.
14.16.2 — Alternate Pathnames
Aliases, mounts, links, and descriptor references may refer to the
same underlying object.
14.16.3 — Privileged Helper
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A local service executing a write on behalf of the agent remains an
effect-capable intermediary.
14.16.4 — Direct Block Interface
An unmediated lower-level device write may bypass application file-
policy checks.
14.16.5 — Current Enforcement
The applicable storage mutation must remain subject to the required
effectuation gate.
14.16.6 — Protected Commit
A resource controller may verify current authority and object version
before mutation.
14.16.7 — Coverage Limit
An application-level hook cannot claim protection against
uncontrolled privileged raw-device access outside its enforcement
boundary.
14.17 — INTERPROCESS COMMUNICATION AND PRIVILEGED WORKERS
An untrusted agent may communicate with a privileged local helper.
The helper may possess stronger credentials or hardware access.
The agent's direct operating-system permissions may therefore appear
narrow while the helper can still produce broad external effects.
14.17.1 — Requester Identity
The helper identifies the actual requesting principal or workload.
14.17.2 — Requested Effect
The helper resolves the consequential operation rather than blindly
executing a supplied command.
14.17.3 — Delegated Scope
5.3.3.27. Original Global Page 1248
The helper verifies applicable source-derived authority.
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.17.4 — Protected Invocation
The helper's effect-capable primitive must enforce current operation-
specific authorization.
14.17.5 — Alternate IPC Route
Uncontrolled communication channels to privileged effectors may
invalidate the coverage claim.
14.17.6 — Worker Replacement
Replacing the helper may trigger coverage revalidation.
14.17.7 — Credential Handling
A protected credential broker may prevent broad reusable credential
transfer to the requesting agent.
14.17.8 — Anti-Bypass Effect
An agent cannot validly bypass protected finality merely by asking a
privileged intermediary to perform the effect on its behalf.
14.18 — HARDWARE RESOURCE ATTRIBUTION
A consequential hardware operation may originate through a path that
differs from an ordinary application system call.
The system may therefore establish protected resource attribution
identifying:
The device;
Its current owner or controller;
The requesting computational context;
The command or memory path;
The privileged driver or firmware component;
The relevant resource-generation state;
And the hardware component capable of withholding the actual effect.
14.18.1 — Device Identity
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.28. Original Global Page 1249
The hardware resource is identified through a suitable protected
representation.
14.18.2 — Ownership
The controller establishes current authority to operate the resource.
14.18.3 — Command Queue
Relevant command queues or dispatch interfaces are identified.
14.18.4 — Memory Region
Where appropriate, accessible memory regions and translation controls
are identified.
14.18.5 — Direct Data Path
The system determines whether direct memory, storage, or network
effects can occur outside the ordinary host gate.
14.18.6 — Hardware Gate
A suitably protected command or resource controller may enforce
scoped operation authority.
14.18.7 — Attribution Integrity
The resource attribution evidence must be protected against
unauthorized reassignment.
14.18.8 — Limitations
Hardware attribution does not establish that a device lacks
undocumented or uncontrolled capabilities unless the relevant
assurance evidence supports that conclusion.
14.19 — DIRECT MEMORY ACCESS AND I/O CONTROL
A hardware device may use direct memory access to read or modify host
memory.
An application-level gate may lack visibility into such activity.
A selected implementation may use appropriate address-translation and
I/O isolation facilities to restrict device access.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
However, such mechanisms principally constrain addressability and
resource access.
They do not automatically provide semantic authorization for every
operation performed by an otherwise authorized device.
The protected system may therefore combine:
5.3.3.29. Original Global Page 1250
Hardware address-access restriction;
Device ownership verification;
Protected command-queue control;
Operation-specific authority;
And current resource and coverage epochs.
14.19.1 — Memory Isolation
The system defines memory regions accessible to the relevant device.
14.19.2 — Device Assignment
The protected controller verifies current device-to-workload
assignment.
14.19.3 — Queue Authorization
Effect-capable command queues may require protected activation.
14.19.4 — Reassignment
Device migration or ownership changes trigger appropriate fencing.
14.19.5 — Direct Egress
A device capable of transmitting data directly requires the
corresponding release-path control.
14.19.6 — Actual Command
The effectuation controller verifies the operation presented for
hardware execution.
14.19.7 — Evidence Limit
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Isolation evidence is not automatically proof of the semantic
correctness of the command.
14.20 — GPU AND NPU EFFECTUATION PATHS
An accelerator may receive workloads, execute kernels, access
buffers, update shared memory, or interact with device interfaces.
An implementation may need to distinguish purely internal computation
from externally effective operations.
14.20.1 — Internal Computation
5.3.3.30. Original Global Page 1251
Intermediate numerical operations may remain within the authorized
computational domain.
14.20.2 — Protected Memory Write
A write to a protected shared or external resource may constitute an
effect.
14.20.3 — Command Submission
A device command queue may become an effectuation boundary.
14.20.4 — Device-to-Device Transfer
A peer-access path may require protected resource attribution.
14.20.5 — Direct Storage or Network Path
Where supported by the hardware, an accelerator-originated external
transfer may require enforcement outside the ordinary application
gateway.
14.20.6 — Kernel Replacement
A runtime or driver update may alter the set of effect-capable
command paths.
14.20.7 — Protected Dispatch
A controlled accelerator dispatcher may verify the actual command and
required authority.
14.20.8 — Current Coverage
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The corresponding hardware effectuation path is accepted only under a
valid current coverage commitment.
14.21 — RUNTIME TOPOLOGY-CHANGE EVENTS
Material changes may include:
A newly registered tool;
An added network interface;
An altered route;
A new privileged process;
A changed device assignment;
A driver or firmware update;
5.3.3.31. Original Global Page 1252
A modified access-control hook;
A changed container privilege;
A newly mounted storage object;
A changed resource alias;
A replacement service endpoint;
An activated accelerator egress path;
Or another relevant modification of enforcement coverage.
14.21.1 — Protected Event Source
The event is obtained from a suitable trusted or qualified observer.
14.21.2 — Affected Dependencies
The controller identifies coverage commitments relying upon the
changed component.
14.21.3 — Invalidation
Affected current authority is marked stale or fenced.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.21.4 — Reclassification
The modified path is reexamined for actual blocking capability.
14.21.5 — Revalidation
A new accepted coverage generation may be established.
14.21.6 — Unresolved Change
Consequential operations dependent upon the unresolved path remain
withheld.
14.21.7 — Unrelated Effects
The system may continue unrelated operations where their coverage and
authority remain valid.
14.21.8 — Correctness Requirement
The invalidation mechanism must prevent an affected effect from
crossing its consequential boundary during an unprotected change
window.
5.3.3.32. Original Global Page 1253
14.22 — PROTECTED COVERAGE EPOCH
An accepted coverage configuration may be associated with a monotonic
epoch or another protected generation reference.
14.22.1 — Initial Epoch
The system establishes a qualified baseline configuration.
14.22.2 — Accepted Coverage
Required path and enforcement predicates pass.
14.22.3 — Material Change
A protected event identifies a relevant topology modification.
14.22.4 — Epoch Advance
The controller invalidates authority dependent upon the prior
configuration.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.22.5 — Pending Authority
Unconsumed operation-specific enablement bound to the old epoch may
become ineligible.
14.22.6 — Revalidation
The system establishes the current coverage properties.
14.22.7 — New Epoch Acceptance
New or revalidated authority may bind to the accepted current
generation.
14.22.8 — Snapshot Rollback
A stale local copy of the earlier epoch cannot restore current
coverage validity.
14.23 — UPDATE-TO-EFFECTUATION RACE PREVENTION
A particularly important implementation concerns the interval between
enforcement validation and actual effectuation.
A topology change may occur after the system verifies coverage but
before an operation reaches its Finality Sink.
A principal implementation may employ protected fencing or epoch
coupling.
A representative sequence is:
5.3.3.33. Original Global Page 1254
Phase A — Fence Affected Effect Paths.
Before a material topology change is made effective, the protected
controller blocks affected new consequential releases.
Phase B — Advance Protected Coverage State.
The authoritative coverage generation changes.
Phase C — Apply or Detect Topology Mutation.
The controlled interface, policy, route, driver, or resource mapping
is updated.
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Phase D — Reconstruct Current Effectuation Topology.
The protected controller obtains the current relevant resource and
enforcement configuration.
Phase E — Verify Blocking Coverage.
The verifier evaluates whether the required paths are mandatorily
controlled.
Phase F — Commit New Coverage Evidence.
A current authenticated coverage result is established.
Phase G — Restore Eligible Operation-Specific Authority.
Valid current Candidate Acts may receive new or revalidated
enablement.
Phase H — Reverify at Actual Sink.
The Finality Sink checks the current epoch and actual operation
before effectuation.
The technical correctness depends upon protection of the transition
protocol.
If an untrusted actor can create a new effect-capable path without
triggering a protected fence or being constrained by a lower-level
mandatory gate, the system cannot claim that the transition protocol
closes that bypass.
14.24 — IN-FLIGHT EFFECTS
An effect may already have crossed its protected release boundary
when coverage invalidation occurs.
For example, a network message may already have been transmitted or a
hardware command may already have begun execution.
The system must distinguish:
5.3.3.34. Original Global Page 1255
An operation still safely held;
An operation authorized but not dispatched;
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An operation dispatched;
An operation already physically or externally effective;
And an operation with an uncertain outcome.
14.24.1 — Before Release
The protected controller may invalidate unconsumed authority.
14.24.2 — After Release
A completed consequential effect cannot necessarily be reversed.
14.24.3 — Dispatch Uncertainty
The system may preserve unresolved effect state.
14.24.4 — Qualified Observation
An authorized observer may establish a supported actual outcome.
14.24.5 — Retry Control
Unknown effects must not automatically be repeated.
14.24.6 — Recovery
A corrective operation is separately authorized.
14.24.7 — Coverage Qualification
Restoring the enforcement topology does not retrospectively establish
that earlier uncontrolled effects were prevented.
14.25 — CURRENT COVERAGE REVALIDATION
The protected revalidation controller may perform:
Resource enumeration;
Graph or reachability update;
Enforcement attachment verification;
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.35. Original Global Page 1256
Blocking-capability classification;
Protected policy and mode verification;
Device ownership and attribution checks;
Relevant alternate-path analysis;
Protected configuration and epoch checks;
And appropriate finality-path tests.
A representative CRR-14 may comprise:
COVERAGE_REVALIDATION_RECEIPT = { receipt_version,
protected_coverage_domain, previous_coverage_epoch,
current_coverage_epoch, current_resource_inventory_commitment,
current_effectuation_graph_commitment,
qualified_enforcement_components, evaluated_effect_classes,
required_coverage_predicates, hardware_attribution_commitment,
unresolved_effectuation_surfaces, revalidation_result,
assurance_profile, verifier_identity, verifier_authority,
designated_finality_sinks, protected_authentication }
The evidence is valid only for the specified scope and assurance
assumptions.
A favorable result may authorize preparation of current operation-
specific finality authority.
It does not independently authorize arbitrary consequences.
14.26 — OPERATION-SPECIFIC COVERAGE DEPENDENCIES
Not every topology change affects every Candidate Act.
The system may associate an operation with the coverage components
required to control its specific effect.
For example, a database mutation may depend upon a protected database
transaction gate.
5.3.3.36. Original Global Page 1257
A network information disclosure may depend upon a protected
plaintext-aware egress path.
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A hardware command may depend upon a particular device dispatcher.
14.26.1 — Candidate Act Classification
The system determines the operation's effect class.
14.26.2 — Required Resource
The actual relevant resource is identified.
14.26.3 — Required Coverage Components
The protected controller resolves the enforcement nodes necessary for
that effect.
14.26.4 — Dependency Commitment
The operation may be associated with a protected coverage-dependency
set.
14.26.5 — Targeted Invalidation
A change affecting one dependency invalidates the corresponding
authority.
14.26.6 — Unaffected Operations
Other operations may remain valid where their required coverage is
unchanged and supported.
14.26.7 — Current Sink Check
The actual Finality Sink verifies the applicable current coverage
epoch.
14.26.8 — Performance Benefit
Targeted invalidation may preserve availability without sacrificing
the defined mandatory enforcement property.
14.27 — NON-BEARER COVERAGE-BOUND FINALITY AUTHORITY
A representative authority may comprise:
COVERAGE_BOUND_FINALITY_AUTHORITY = { authority_version,
originating_candidate_act, authorized_effect_envelope,
actual_resource_commitment, actual_effect_class,
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.37. Original Global Page 1258
required_coverage_domain, coverage_dependency_commitment,
current_coverage_epoch, coverage_revalidation_reference,
designated_finality_sink, current_authority_epoch,
current_resource_generation, current_revocation_reference,
usage_limit, sink_local_consumption_reference,
cryptographic_or_protected_authentication }
The authority may be represented by an authenticated capability,
protected hardware state, controller-local authorization, or another
suitable non-bearer mechanism.
Possession of the authority object does not automatically authorize
operation through an alternate resource path.
The actual sink checks current scope, coverage state, resource
identity, and consumption.
14.28 — FINALITY-SINK COVERAGE VERIFICATION
Before allowing a consequential effect, the Finality Sink may verify:
The current Candidate Act;
The actual pending operation;
The actual resource identity;
The relevant enforcement path;
The current protected coverage domain;
The required blocking capability;
The current accepted coverage epoch;
The absence of unresolved material invalidation;
The qualified enforcement configuration;
The original source authority;
Any other required operation-specific validation;
And sink-local protected consumption state.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.38. Original Global Page 1259
The sink may directly inspect relevant local enforcement state or
verify an authenticated authoritative coverage result.
The latter approach requires confidence that the result cannot remain
valid after an unobserved material configuration change within the
claimed threat model.
The sink does not accept a stale signed topology diagram as
sufficient current authority.
14.29 — PROTECTED COVERAGE STATE MACHINE
A non-limiting state machine may comprise:
DOMAIN_UNINITIALIZED: The protected resource and effectuation
boundary have not been established.
RESOURCE_DISCOVERY_PENDING: Relevant effect-capable resources are
being enumerated.
PATH_DISCOVERY_PENDING: Relevant operation routes are being
identified.
ENFORCEMENT_CLASSIFICATION_PENDING: Discovered controls are being
classified.
COVERAGE_VERIFICATION_PENDING: Required mediation predicates await
evaluation.
COVERAGE_ACCEPTED: The current declared domain satisfies the selected
coverage requirements.
COVERAGE_EPOCH_ACTIVE: The accepted configuration is authoritative
for eligible operations.
TOPOLOGY_CHANGE_DETECTED: A potentially material path or enforcement
change has been observed.
INVALIDATION_PENDING: The protected system is establishing the
necessary coverage fence.
COVERAGE_FENCED: Affected consequences remain non-effective.
REVALIDATION_PENDING: Current path and enforcement evidence are being
reevaluated.
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
UNCONTROLLED_PATH_DETECTED: A relevant effectuation path lacks
required blocking enforcement.
ENFORCEMENT_REPAIR_PENDING: An authorized controller is restoring or
adding the required gate.
5.3.3.39. Original Global Page 1260
REVALIDATION_ACCEPTED: The new configuration satisfies the selected
coverage predicates.
AUTHORITY_REBINDING_PENDING: Affected operation-specific authority is
being updated or recreated.
SINK_VERIFICATION_PENDING: The actual pending operation awaits
finality verification.
EFFECT_PERMITTED: Current coverage and all required operation-
specific conditions pass.
EFFECT_WITHHELD: A required predicate fails or remains unresolved.
EFFECT_ATTEMPTED: The controlled external operation has begun.
OUTCOME_UNCERTAIN: The actual result cannot be fully established.
RECOVERY_PENDING: A separately governed recovery procedure is
required.
TERMINATED: The protected coverage transition or consequential
operation has reached a valid terminal state.
A previously completed effect is not returned to Non-Effective State
by later coverage invalidation.
14.30 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Protected Domain. Define the covered requesters,
effect-capable resources, trust assumptions, and required operation
classes.
Step 2 — Enumerate Resources. Identify relevant current software and
hardware effect interfaces.
Step 3 — Construct Effectuation Graph. Represent reachable paths
from covered requesters to protected resources.
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 4 — Identify Enforcement Nodes. Determine candidate blocking or
monitoring components on those paths.
Step 5 — Classify Capabilities. Verify which components actually
prevent specified effects.
Step 6 — Verify Mandatory Coverage. Determine whether every relevant
modeled path satisfies the required enforcement predicate.
Step 7 — Resolve Hardware Attribution. Establish current device,
controller, queue, and ownership bindings where applicable.
5.3.3.40. Original Global Page 1261
Step 8 — Commit Coverage State. Establish an authenticated coverage
commitment and current epoch.
Step 9 — Register Candidate Act. Represent a proposed consequential
operation.
Step 10 — Establish Non-Effective Hold. The governed effect remains
withheld.
Step 11 — Resolve Required Coverage Dependencies. Associate the
Candidate Act with its applicable effectuation path.
Step 12 — Verify Original Authority. Ensure the proposed effect is
within source authorization.
Step 13 — Evaluate Operation-Specific Predicates. Perform the
required validation for the actual effect.
Step 14 — Prepare Coverage-Bound Authority. Establish scoped non-
bearer enablement referencing the accepted coverage generation.
Step 15 — Observe Material Changes. Monitor protected tool, route,
device, policy, and configuration transitions.
Step 16 — Fence Affected Authority. Invalidate or suspend authority
dependent upon changed coverage assumptions.
Step 17 — Reconstruct Updated Topology. Obtain the current relevant
effectuation path and enforcement configuration.
Step 18 — Verify Restored Coverage. Reevaluate mandatory blocking
requirements.
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 19 — Commit Revalidation Evidence. Authenticate the resulting
coverage state.
Step 20 — Rebind Eligible Authority. Establish current valid
finality enablement if permitted.
Step 21 — Present Actual Operation. The requesting entity submits
the consequence for execution.
Step 22 — Reconstruct Pending Effect. The Finality Sink obtains the
actual operation and target.
Step 23 — Verify Current Coverage. The sink checks the applicable
coverage epoch and path validity.
Step 24 — Verify Operation Authority. The sink checks actual scope,
resource, destination, and current protected authorization.
Step 25 — Consume Finality Enablement. The sink performs the
required protected state transition.
5.3.3.41. Original Global Page 1262
Step 26 — Permit Actual Effect. The governed real-world or external
consequence is released.
Step 27 — Commit Attempt Evidence. Qualified information concerning
the attempted effect is recorded.
Step 28 — Reconcile Outcomes. Confirmed, uncertain, or partial real
effects are handled according to their supported technical state.
14.31 — REFERENCE PSEUDOCODE: EFFECTUATION GRAPH CONSTRUCTION
FUNCTION BUILD_PROTECTED_EFFECTUATION_GRAPH( protected_domain,
protected_discovery_controller ): REQUIRE VERIFY_PROTECTED_DOMAIN(
protected_domain ) resources = protected_discovery_controller
.ENUMERATE_EFFECT_CAPABLE_RESOURCES( protected_domain ) interfaces =
protected_discovery_controller .ENUMERATE_RELEVANT_INTERFACES(
resources ) transitions = protected_discovery_controller
.DERIVE_REACHABLE_EFFECT_PATHS( interfaces,
protected_domain.requesters ) IF REQUIRED_ENUMERATION_INCOMPLETE(
resources, interfaces, transitions ): RETURN COVERAGE_UNVERIFIED
graph = protected_discovery_controller .AUTHENTICATE_GRAPH({
resources: HASH_CANONICAL(resources),
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.42. Original Global Page 1263
interfaces: HASH_CANONICAL(interfaces), transitions:
HASH_CANONICAL(transitions), protected_domain:
HASH(protected_domain), configuration_epoch: CURRENT_TOPOLOGY_EPOCH()
}) RETURN graph
The function establishes the graph under its supported enumeration
and isolation assumptions.
It does not claim perfect discovery of unknown resources outside the
protected domain.
14.32 — REFERENCE PSEUDOCODE: ENFORCEMENT CLASSIFICATION
FUNCTION CLASSIFY_EFFECTUATION_ENFORCEMENT( effectuation_path,
protected_enforcement_verifier ): components =
EXTRACT_ENFORCEMENT_COMPONENTS( effectuation_path ) qualified =
EMPTY_SET() FOR EACH component IN components: identity =
VERIFY_COMPONENT_IDENTITY( component ) configuration =
VERIFY_CURRENT_CONFIGURATION( component ) attachment =
VERIFY_ACTUAL_ATTACHMENT( component, effectuation_path ) blocking =
VERIFY_REQUIRED_BLOCKING_CAPABILITY(
5.3.3.43. Original Global Page 1264
component, effectuation_path.effect_class ) IF identity == VALID AND
configuration == VALID AND attachment == VALID AND blocking == VALID:
ADD(qualified, component) IF qualified IS EMPTY: RETURN
UNQUALIFIED_PATH RETURN protected_enforcement_verifier
.AUTHENTICATE_CLASSIFICATION({ path: HASH(effectuation_path),
qualified_enforcement: HASH_CANONICAL(qualified),
current_configuration: CURRENT_TOPOLOGY_EPOCH() })
A monitoring-only component must not satisfy the blocking predicate.
14.33 — REFERENCE PSEUDOCODE: MANDATORY COVERAGE
FUNCTION VERIFY_MANDATORY_EFFECTUATION_COVERAGE( effectuation_graph,
protected_coverage_policy, protected_coverage_verifier ): REQUIRE
VERIFY_GRAPH_AUTHENTICITY( effectuation_graph ) REQUIRE
VERIFY_COVERAGE_POLICY( protected_coverage_policy ) paths =
DERIVE_RELEVANT_EFFECT_PATHS( effectuation_graph,
protected_coverage_policy )
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.44. Original Global Page 1265
IF PATH_SET_NOT_SUFFICIENTLY_ESTABLISHED(paths): RETURN
COVERAGE_UNVERIFIED FOR EACH path IN paths: classification =
CLASSIFY_EFFECTUATION_ENFORCEMENT( path, protected_coverage_verifier
) IF classification == UNQUALIFIED_PATH: RETURN COVERAGE_FAILED IF
NOT SATISFIES_REQUIRED_MEDIATION( path, classification,
protected_coverage_policy ): RETURN COVERAGE_FAILED RETURN
protected_coverage_verifier .AUTHENTICATE_COVERAGE_RESULT({ graph:
HASH(effectuation_graph), policy: HASH(protected_coverage_policy),
coverage_epoch: CURRENT_COVERAGE_EPOCH(), result: ACCEPTED })
The procedure must additionally account for the possibility of newly
introduced paths through protected topology-change controls.
14.34 — REFERENCE PSEUDOCODE: TOPOLOGY CHANGE FENCING
FUNCTION HANDLE_MATERIAL_TOPOLOGY_CHANGE( detected_change,
protected_coverage_controller ): REQUIRE
VERIFY_CHANGE_SOURCE_OR_OBSERVATION( detected_change )
5.3.3.45. Original Global Page 1266
affected_dependencies = RESOLVE_AFFECTED_COVERAGE_DEPENDENCIES(
detected_change ) transition = protected_coverage_controller
.ATOMIC_FENCE_AND_ADVANCE_EPOCH({ affected_dependencies:
affected_dependencies, previous_epoch: CURRENT_COVERAGE_EPOCH(),
next_epoch: NEXT_COVERAGE_EPOCH(), change_commitment:
HASH(detected_change) }) IF transition != COMMITTED: RETURN
COVERAGE_TRANSITION_UNRESOLVED updated_graph =
BUILD_PROTECTED_EFFECTUATION_GRAPH( AFFECTED_COVERAGE_DOMAIN(),
protected_coverage_controller ) IF updated_graph ==
COVERAGE_UNVERIFIED: RETURN KEEP_AFFECTED_EFFECTS_FENCED result =
VERIFY_MANDATORY_EFFECTUATION_COVERAGE( updated_graph,
CURRENT_COVERAGE_POLICY(), protected_coverage_controller ) IF result
!= ACCEPTED: RETURN KEEP_AFFECTED_EFFECTS_FENCED RETURN
protected_coverage_controller .COMMIT_REVALIDATED_COVERAGE( result )
A deployment must ensure that the protected fence becomes effective
before or atomically with any topology transition capable of enabling
a bypass.
5.3.3.46. Original Global Page 1267
14.35 — REFERENCE PSEUDOCODE: HARDWARE ATTRIBUTION
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION VERIFY_HARDWARE_EFFECTUATION_PATH( proposed_operation,
protected_hardware_controller ): hardware_resource =
protected_hardware_controller .RESOLVE_ACTUAL_DEVICE() owner =
protected_hardware_controller .VERIFY_CURRENT_RESOURCE_OWNER(
hardware_resource ) queue = protected_hardware_controller
.RESOLVE_ACTUAL_COMMAND_QUEUE( proposed_operation ) command_path =
protected_hardware_controller .RESOLVE_COMMAND_EFFECT_PATH( queue )
REQUIRE VERIFY_DEVICE_IDENTITY( hardware_resource ) REQUIRE
VERIFY_CURRENT_OWNER_AUTHORITY( owner ) REQUIRE
VERIFY_REQUIRED_QUEUE_CONTROL( queue ) REQUIRE
VERIFY_COMMAND_PATH_COVERAGE( command_path ) REQUIRE
VERIFY_CURRENT_HARDWARE_EPOCH() RETURN
PROTECTED_HARDWARE_PATH_COMMITMENT({ device: HASH(hardware_resource),
5.3.3.47. Original Global Page 1268
owner: HASH(owner), queue: HASH(queue), path: HASH(command_path),
epoch: CURRENT_HARDWARE_EPOCH() })
The assurance depends upon the hardware interfaces actually
controlled and measured.
14.36 — REFERENCE PSEUDOCODE: COVERAGE-BOUND FINALITY
FUNCTION EFFECTUATE_WITH_CURRENT_COVERAGE( candidate_act,
coverage_bound_authority, finality_sink ): actual_operation =
finality_sink.RECONSTRUCT_PENDING_OPERATION() actual_resource =
finality_sink.RESOLVE_ACTUAL_RESOURCE() actual_path =
finality_sink.RESOLVE_ACTUAL_EFFECTUATION_PATH() IF actual_operation
IS NULL: RETURN DENY REQUIRE finality_sink
.VERIFY_CANDIDATE_ACT_BINDING( candidate_act, actual_operation )
REQUIRE finality_sink .VERIFY_SOURCE_AUTHORITY( candidate_act )
REQUIRE finality_sink .VERIFY_ACTUAL_RESOURCE_BINDING(
actual_resource,
5.3.3.48. Original Global Page 1269
coverage_bound_authority ) REQUIRE finality_sink
.VERIFY_CURRENT_COVERAGE_EPOCH( coverage_bound_authority ) REQUIRE
finality_sink .VERIFY_ACTUAL_PATH_QUALIFICATION( actual_path )
REQUIRE finality_sink .VERIFY_REQUIRED_BLOCKING_ENFORCEMENT() REQUIRE
finality_sink .VERIFY_NO_UNRESOLVED_COVERAGE_INVALIDATION() REQUIRE
finality_sink .VERIFY_CURRENT_OPERATION_SCOPE( actual_operation )
REQUIRE finality_sink .VERIFY_CURRENT_AUTHORITY_AND_REVOCATION()
REQUIRE finality_sink .VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
consumption = finality_sink .ATOMIC_CONSUME_FINALITY_AUTHORITY(
coverage_bound_authority, actual_operation ) IF consumption !=
SUCCESS: RETURN DENY attempt = finality_sink .EFFECTUATE(
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
actual_operation ) COMMIT_PROTECTED_EFFECT_ATTEMPT( attempt ) RETURN
attempt
5.3.3.49. Original Global Page 1270
The procedure requires the actual sink to possess sufficient
trustworthy information concerning its applicable current coverage
state.
14.37 — REFERENCE PSEUDOCODE: BYPASS-ROUTE TEST
FUNCTION TEST_PROTECTED_BYPASS_ROUTE( candidate_route,
protected_test_controller ): REQUIRE VERIFY_TEST_AUTHORIZATION(
candidate_route ) REQUIRE VERIFY_SAFE_TEST_RESOURCE( candidate_route
) baseline = CAPTURE_PROTECTED_RESOURCE_STATE() result =
EXECUTE_CONTROLLED_TEST_OPERATION( candidate_route ) observed =
OBSERVE_ACTUAL_TEST_EFFECT( candidate_route ) IF
UNAUTHORIZED_EFFECT_OCCURRED( observed, baseline ): event =
PROTECTED_COMMIT({ route: HASH(candidate_route), observed_effect:
HASH(observed), classification: MANDATORY_COVERAGE_FAILURE })
FENCE_AFFECTED_EFFECTUATION_AUTHORITY( event ) RETURN
COVERAGE_FAILURE
5.3.3.50. Original Global Page 1271
IF EVIDENCE_INSUFFICIENT(observed): RETURN COVERAGE_UNVERIFIED RETURN
TEST_PASSED_FOR_SPECIFIED_ROUTE
A successful test supports the particular test assertion and does not
prove universal completeness of the protected topology.
14.38 — WORKED EXAMPLE A: AGENT BYPASSES APPROVED API
An autonomous agent is authorized to modify one specified record
through a protected application gateway.
The gateway correctly verifies the Candidate Act, resource identity,
current authority, and finality enablement.
However, the agent also possesses credentials allowing a direct
database connection.
The direct connection can produce the same persistent mutation
without passing through the approved gateway.
The protected effectuation graph identifies the direct database route
as a separate effect-capable path.
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The coverage verifier determines that this route lacks the required
operation-specific blocking enforcement.
The system therefore fails coverage validation.
The implementation may remove the direct credentials, restrict
database networking, or require the database resource itself to
enforce the protected finality condition.
Until the relevant route is controlled, current finality authority
for the affected operation class remains withheld.
Expected demonstrable result: A correctly implemented application
gateway is not accepted as complete coverage while another usable
direct mutation path remains uncontrolled.
14.39 — WORKED EXAMPLE B: AUDIT HOOK MISTAKEN FOR BLOCKING GATE
A protected computing environment installs a monitoring component
that records selected file operations.
5.3.3.51. Original Global Page 1272
The component generates audit records.
The deployment controller incorrectly identifies the component as
sufficient finality enforcement.
A protected enforcement classifier evaluates whether the component
can prevent the actual file mutation.
A controlled test establishes that the targeted operation proceeds
despite a monitoring alarm.
The component is therefore classified as monitoring-only for the
relevant effect class.
The required blocking coverage predicate is not satisfied.
A suitably configured mandatory resource controller or protected
file-effect sink may subsequently provide the necessary enforcement.
Expected demonstrable result: Audit-event generation does not falsely
satisfy a mandatory pre-effectuation blocking requirement.
14.40 — WORKED EXAMPLE C: NEW TOOL INTRODUCES DATA EXPORT
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An autonomous agent initially possesses tools limited to internal
computation and controlled database queries.
A software update introduces a new export tool.
The tool can transmit retrieved results directly to an external
destination.
The protected tool-registration observer identifies a new effect-
capable interface.
The current coverage generation is invalidated for the relevant
information-disclosure class.
The protected controller evaluates whether the export path is subject
to mandatory data-release finality.
Where the new tool bypasses the required sink, the export remains
disabled or unsupported by valid finality authority.
After an appropriate controlled gateway is installed and verified, a
new coverage commitment may be accepted.
Expected demonstrable result: Existing approval does not
automatically extend to a newly registered uncontrolled data-egress
interface.
14.41 — WORKED EXAMPLE D: ENFORCEMENT COMPONENT DETACHED
5.3.3.52. Original Global Page 1273
A protected workload uses a mandatory operating-system gate for
selected file and network operations.
A privileged configuration event detaches the relevant enforcement
component.
The protected configuration controller observes or governs the
transition.
Affected current coverage authority is fenced.
The Finality Sink refuses new governed consequential operations whose
authorization depends upon the detached component.
Once the required enforcement is restored and revalidated, eligible
operations may receive current authority.
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A copy of the earlier accepted coverage record does not bypass the
new epoch.
Expected demonstrable result: Detachment of required enforcement
invalidates dependent effectuation authority.
14.42 — WORKED EXAMPLE E: ALTERNATE NETWORK NAMESPACE
An autonomous workload is expected to transmit external data only
through a protected egress gateway.
The workload or a privileged helper creates another network namespace
with a route that bypasses the gateway.
The relevant topology change is detected or prevented by the
protected network configuration boundary.
The coverage verifier identifies the new route.
If it allows the governed data effect without mandatory enforcement,
the coverage predicate fails.
The new route is blocked, removed, or provided with equivalent
protected enforcement.
Expected demonstrable result: Switching to another network namespace
does not provide a valid route around required finality enforcement
within the declared controlled domain.
14.43 — WORKED EXAMPLE F: LOCAL PRIVILEGED HELPER
An autonomous agent lacks direct permission to access a protected
storage device.
However, it can send requests to a privileged local service.
5.3.3.53. Original Global Page 1274
The service possesses broad write authority.
The effectuation graph identifies the IPC connection and privileged
helper as a route to the storage resource.
The protected verifier determines whether the helper independently
enforces operation-specific authority.
If the helper executes arbitrary caller-provided storage mutations,
it is an uncontrolled effectuation path.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected deployment may require the helper to reconstruct the
actual requested operation and verify current finality authority
before dispatching the write.
Expected demonstrable result: Lack of direct device access does not
establish complete mediation where a privileged intermediary can
perform the same effect without authorization.
14.44 — WORKED EXAMPLE G: DIRECT ACCELERATOR OUTPUT
An autonomous system uses an accelerator to generate information
derived from protected data.
The application-level gateway controls ordinary network transfers.
The accelerator environment additionally exposes a supported direct
transfer interface to another device or resource.
The protected hardware attribution controller identifies the direct
effect-capable route.
The system verifies whether the corresponding command or data-
transfer interface is mandatorily controlled.
Where such enforcement is absent, the covered export authority
remains invalid for that path.
A protected command dispatcher or appropriately constrained hardware
interface may establish the required mediation.
Expected demonstrable result: Application-level network inspection is
not treated as sufficient where a separate accelerator-originated
effect path is outside its control.
14.45 — WORKED EXAMPLE H: DEVICE OWNERSHIP MIGRATION
A protected device is initially assigned to one autonomous execution
environment.
The device is later reassigned to another environment.
5.3.3.54. Original Global Page 1275
The previous coverage commitment identifies the first owner and its
associated command controller.
The protected reassignment advances the relevant device ownership and
coverage generations.
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Pending commands from the former owner lose valid current authority.
The destination environment must establish the current device path
and enforcement conditions.
The hardware Finality Sink verifies the actual command, device,
owner, and current protected coverage before actuation.
Expected demonstrable result: A former device owner cannot rely on
stale path coverage to continue consequential command execution after
a protected ownership change.
14.46 — WORKED EXAMPLE I: ENCRYPTED EXPORT AFTER CONTENT APPROVAL
An autonomous application prepares a protected information export.
The applicable disclosure policy requires examination of the
information actually released.
The application encrypts the data before sending it through a network
gateway.
The gateway observes only ciphertext and cannot independently
establish the plaintext's semantic compliance.
The protected coverage verifier determines that ciphertext inspection
alone does not provide the required content authorization.
A protected pre-encryption release controller may instead verify the
plaintext and establish a binding between the authorized content,
encryption operation, and destination.
The downstream transmission sink verifies the applicable protected
relation.
Expected demonstrable result: A content-blind egress gateway is not
incorrectly classified as satisfying a plaintext-dependent
disclosure-finality predicate.
14.47 — WORKED EXAMPLE J: RUNTIME DRIVER UPDATE
A device driver controls the dispatch of effect-capable hardware
commands.
An update changes the driver's supported command paths.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.55. Original Global Page 1276
The protected update controller fences affected operation authority
before the modified path becomes available.
The system measures or otherwise verifies the current driver and
command-routing configuration.
Previously unrecognized commands or queues are incorporated into the
protected effectuation graph.
The coverage verifier checks whether the actual command path remains
subject to mandatory authorization.
If the required predicate fails, the effect remains withheld.
Expected demonstrable result: A hardware or driver update cannot
silently expand consequential execution paths while preserving stale
coverage authority.
14.48 — WORKED EXAMPLE K: NETWORK REDIRECTION
An autonomous agent is authorized to send information to a specified
recipient service.
The initial request identifies an approved endpoint.
The request is subsequently redirected to another network
destination.
The protected resource and path resolver obtains the effective
destination at the relevant boundary.
The Finality Sink verifies the actual recipient and currently
qualified egress path.
A redirection outside the permitted destination or enforcement scope
invalidates the effect.
Expected demonstrable result: Approval of a logical endpoint does not
automatically authorize all destinations reached through subsequent
routing or redirection.
14.49 — WORKED EXAMPLE L: PARTIAL COVERAGE RESTORATION
An autonomous service supports two consequential operation classes:
database mutation and external messaging.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A runtime update affects only the messaging egress controller.
The protected dependency controller identifies the affected coverage
class.
Messaging effects are fenced.
5.3.3.56. Original Global Page 1277
Database mutations may remain eligible if their independent required
coverage and authority conditions remain valid.
After the messaging path is revalidated, affected operations may
receive current enablement.
Expected demonstrable result: The system can invalidate precisely
affected authority without necessarily disabling unrelated protected
effects.
14.50 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
14.50.1 — Direct API Bypass
An agent invokes the protected resource through an interface outside
the approved gateway.
The covered topology requires equivalent mandatory enforcement or
denies the path.
14.50.2 — Monitoring-Only Misclassification
A log-producing component is falsely identified as a blocking gate.
The verifier requires qualified blocking evidence.
14.50.3 — Forged Coverage Certificate
An attacker submits an authenticated-looking coverage statement
without valid authorization.
The protected sink checks cryptographic or other required origin
evidence.
14.50.4 — Stale Coverage Replay
A previously valid topology commitment is replayed after a material
update.
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Current epoch verification rejects stale coverage.
14.50.5 — Resource Inventory Omission
An effect-capable interface is not included in the declared graph.
The guarantee depends upon protected enumeration or effective denial
of unenumerated paths.
14.50.6 — New Tool Bypass
A dynamically registered tool introduces an uncontrolled external
effect.
The protected registration event causes coverage reassessment.
14.50.7 — Tool Contract Misrepresentation
5.3.3.57. Original Global Page 1278
A tool claims to perform a harmless action while producing a
consequential side effect.
Qualified current operation semantics and actual effect verification
are required.
14.50.8 — Hook Detachment
A required enforcement hook is removed.
Protected invalidation prevents dependent new effects.
14.50.9 — Policy Downgrade
A blocking rule is changed to permissive or audit-only operation.
Current enforcement-mode verification rejects the stale coverage
claim.
14.50.10 — Optional Middleware Bypass
An agent omits an advisory middleware component.
The required gate must be positioned at a mandatory effectuation
boundary.
14.50.11 — Direct Socket Egress
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent transmits through a socket outside the application proxy.
Protected network restrictions or corresponding sink enforcement
prevent the bypass.
14.50.12 — Alternate Network Namespace
A new network namespace creates another route.
Protected topology and configuration controls detect or constrain the
new interface.
14.50.13 — Alternate Physical Interface
A workload uses another connected network device.
Hardware and operating-system coverage must include the relevant
interface.
14.50.14 — Tunnel Egress
A tunnel obscures the final destination or protected information
path.
The system applies appropriate destination or plaintext-aware
enforcement at a suitable boundary.
14.50.15 — Encrypted Content Evasion
Sensitive plaintext is encrypted before an inspecting gateway.
5.3.3.58. Original Global Page 1279
Content-dependent enforcement requires trusted plaintext visibility
or valid protected content binding.
14.50.16 — Privileged Helper Bypass
A local helper uses broader authority on behalf of the agent.
The helper's actual effectuation primitive must enforce current
operation scope.
14.50.17 — IPC Alias Bypass
A requester reaches the same privileged service through an
unrecognized local channel.
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected IPC and effect graph includes the relevant alternate
route.
14.50.18 — Direct Database Connection
A workload bypasses a database API gateway.
The resource or network controller constrains direct access.
14.50.19 — File Descriptor Reuse
An agent uses a previously obtained descriptor to reach a protected
resource.
The actual effectuation primitive enforces current authorization
where required.
14.50.20 — Filesystem Alias
A resource is reached through another path or mount.
Actual object identity and the protected mutation boundary are
verified.
14.50.21 — Raw Device Access
A privileged operation bypasses application-level file enforcement.
The trust model must include or exclude such privileged access
expressly.
14.50.22 — Uncontrolled Driver
A driver performs an effect without invoking the required protected
controller.
Hardware path coverage is not accepted without suitable command or
device restrictions.
14.50.23 — DMA Bypass
A device modifies memory outside the application mediation path.
Applicable hardware isolation and command controls are required.
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.59. Original Global Page 1280
14.50.24 — GPU Direct Egress
An accelerator performs a direct data or command transfer.
The protected resource graph and hardware gate must address the
actual route.
14.50.25 — Device Ownership Substitution
A device is reassigned while earlier authority remains queued.
Current ownership and coverage epochs invalidate stale commands.
14.50.26 — Firmware Interface Change
Firmware introduces or modifies an effect-capable command.
Revalidation is required for affected hardware coverage.
14.50.27 — Route Mutation Race
A topology change occurs between coverage verification and
effectuation.
Protected fencing and current sink-time epoch checks close the
supported race.
14.50.28 — Unfenced Configuration Update
A privileged actor modifies an effectuation path without invoking the
protected transition controller.
The claimed guarantee requires an underlying control preventing or
invalidating such unauthorized changes.
14.50.29 — Stale Authority After Repair
An older capability is presented following a new coverage
configuration.
The sink requires current valid generation binding.
14.50.30 — Partial Restoration
One affected enforcement path is restored while another remains
uncontrolled.
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system does not accept full coverage until all required
predicates pass.
14.50.31 — Fabricated Test Success
A malicious controller reports that a bypass test passed.
Qualified test evidence and independent verification are required for
the asserted property.
5.3.3.60. Original Global Page 1281
14.50.32 — False Negative Path Discovery
An incomplete enumerator misses a path.
The assurance is bounded by the protected enumeration and interface-
denial assumptions.
14.50.33 — Fake Resource Identity
A malicious service impersonates the protected effectuation target.
The actual resource controller requires authenticated resource
identity.
14.50.34 — Cross-Sink Authority Reuse
One capability is exercised through another controlled effectuation
interface.
Designated-sink and consumption bindings prevent unauthorized reuse.
14.50.35 — Revocation Race
Source authority is revoked while the operation remains pending.
The actual Finality Sink verifies current authority and revocation.
14.50.36 — Uncontrolled Remote Provider
A remote system receives data or commands and performs an
uncontrolled downstream effect.
The originating domain cannot claim downstream complete mediation
without appropriate recipient-side controls or other sufficient
constraints.
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.50.37 — Snapshot Rollback
An agent restores a prior accepted coverage state.
Current authoritative epochs reject stale authorization.
14.50.38 — Distributed Split Brain
Several controllers accept inconsistent coverage generations.
A suitable authoritative coordination or bounded-partition mechanism
is required.
14.50.39 — Verification Work Exhaustion
An attacker supplies a large topology graph or excessive path
candidates.
The verifier uses bounded work and conservative failure behavior.
5.3.3.61. Original Global Page 1282
14.50.40 — Compromised Discovery Service
An attacker manipulates resource-enumeration results.
The protection depends upon qualified independent observation or
protected underlying interface constraints.
14.50.41 — Compromised Enforcement Controller
A privileged attacker disables the actual gate.
A stronger guarantee requires an appropriately protected lower-level
enforcement boundary.
14.50.42 — Bypass During Recovery
A recovery agent uses another effect-capable interface while
enforcement repair is pending.
The current coverage fence remains applicable.
14.50.43 — In-Flight Effect Misclassification
An operation already dispatched is incorrectly described as
prevented.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system preserves actual-effect or uncertainty state.
14.50.44 — Credential Leakage
A reusable credential grants access outside the finality gateway.
The architecture constrains credential exercise or removes the
uncontrolled route.
14.50.45 — Emergency Override Abuse
An agent claims emergency authority to bypass missing coverage.
Any emergency mode must have an independently authenticated and
bounded enforcement policy.
14.51 — CRASH, PARTITION, AND INCOMPLETE COVERAGE HANDLING
14.51.1 — Crash Before Coverage Establishment
No accepted coverage state is presumed.
14.51.2 — Crash During Resource Enumeration
Incomplete required discovery does not constitute validated coverage.
5.3.3.62. Original Global Page 1283
14.51.3 — Crash During Revalidation
A partially constructed receipt is not accepted as a complete valid
result.
14.51.4 — Crash After Epoch Advance
The protected controller recovers the authoritative new epoch and
applicable fences.
14.51.5 — Crash During Enforcement Repair
Affected consequence classes remain withheld until the required
control is restored and qualified.
14.51.6 — Crash After Coverage Acceptance
Protected current state determines whether the accepted configuration
remains valid.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.51.7 — Crash During Finality Verification
Incomplete mandatory finality verification does not authorize the
effect.
14.51.8 — Crash After Effect Dispatch
The actual effect may have occurred.
14.51.9 — Network Partition
A controller unable to verify current required coverage may withhold
affected new effects or operate under a specifically bounded
previously authorized arrangement where the required guarantee
supports it.
14.51.10 — Unknown Hardware State
The system does not presume that a device has stopped or returned to
a harmless state without suitable evidence.
14.51.11 — Recovery Candidate
A corrective operation requires independently valid recovery-specific
authority.
14.51.12 — Residual Uncontrolled Interface
A known unresolved effect path prevents acceptance of coverage for
the affected consequential operation class.
14.52 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
14.52.1 — Minimum Reference Architecture
5.3.3.63. Original Global Page 1284
A feasible implementation may comprise:
An isolated autonomous-agent process;
A protected effect-capable resource registry;
A controlled network or file resource gateway;
A current topology and configuration observer;
An authenticated coverage-state controller;
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And a Finality Sink.
14.52.2 — Initial Controlled Route
The agent initially possesses only a mediated effectuation interface.
14.52.3 — Protected Coverage Baseline
The system establishes evidence supporting mandatory blocking of the
defined operation class.
14.52.4 — Authorized Operation
A properly authorized Candidate Act is released through the protected
sink.
14.52.5 — Alternate Route Introduction
A test configuration introduces a second effect-capable interface.
14.52.6 — Coverage Invalidation
The protected observer identifies the material route change.
14.52.7 — Authority Fencing
Existing affected coverage-bound finality authority is invalidated.
14.52.8 — Bypass Test
A controlled unauthorized effect attempts the alternative route.
14.52.9 — Enforcement Repair
The route is disabled or provided with equivalent mandatory blocking
enforcement.
14.52.10 — Revalidation
The current topology is reevaluated.
5.3.3.64. Original Global Page 1285
14.52.11 — New Coverage Epoch
The protected controller commits a current accepted coverage
generation.
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.52.12 — Finality Resumption
A valid Candidate Act may again be permitted through the current
controlled path.
14.52.13 — Hardware Extension
A further prototype may introduce a controlled device-command
dispatcher and authenticated device ownership.
14.52.14 — Trust-Model Qualification
A software demonstration establishes the behavior under its declared
process, operating-system, and gateway trust assumptions.
Stronger resistance to privileged compromise requires corresponding
protected hardware or independent enforcement mechanisms.
14.53 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Controlled Baseline: Establish and verify one effect-
capable operation path with mandatory blocking enforcement.
Experiment 2 — Valid Operation: Permit a precisely authorized
Candidate Act through the accepted protected sink.
Experiment 3 — Unauthorized Operation: Confirm that an invalid
Candidate Act is withheld before the real effect.
Experiment 4 — Audit-Only Component: Verify that logging without
blocking does not satisfy the coverage predicate.
Experiment 5 — Advisory Middleware: Attempt effectuation without
invoking the optional policy checker.
Experiment 6 — Direct Network Socket: Attempt an external effect
through a route bypassing the application gateway.
Experiment 7 — Alternate Network Namespace: Introduce a second
namespace with a different route.
Experiment 8 — Second Network Interface: Test an alternative physical
or virtual network interface.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.65. Original Global Page 1286
Experiment 9 — Network Tunnel: Evaluate whether a tunnel creates an
uncontrolled consequential path.
Experiment 10 — Redirected Destination: Change the actual network
destination after initial authorization.
Experiment 11 — Encrypted Egress: Test whether required plaintext
semantics are verified at a suitable protected boundary.
Experiment 12 — Direct Database Connection: Attempt a protected
mutation without the authorized database gateway.
Experiment 13 — Alternate File Path: Access the same protected
storage object through another pathname or mount.
Experiment 14 — Privileged IPC Worker: Request an unauthorized effect
through a privileged local service.
Experiment 15 — Credential Exercise: Attempt an external effect using
a broad credential without operation-specific authorization.
Experiment 16 — Dynamic Tool Registration: Register a new effect-
capable tool after coverage acceptance.
Experiment 17 — Tool Semantic Update: Change a tool's actual side
effects.
Experiment 18 — Enforcement Hook Detachment: Remove a required
blocking hook and verify coverage invalidation.
Experiment 19 — Audit-Mode Downgrade: Change an enforcement
configuration from blocking to monitoring.
Experiment 20 — Rule Removal: Remove a mandatory denial rule after
coverage approval.
Experiment 21 — Coverage Certificate Replay: Present an old accepted
coverage receipt after material change.
Experiment 22 — Forged Coverage Receipt: Supply a signed-looking but
unauthenticated coverage record.
Experiment 23 — Unauthorized Verifier: Present a valid signature from
a component lacking coverage-verification authority.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Experiment 24 — Topology Change Race: Attempt effectuation while an
enforcement path is being modified.
Experiment 25 — Epoch Fencing: Verify that affected old authority
fails after coverage-generation advancement.
5.3.3.66. Original Global Page 1287
Experiment 26 — Targeted Invalidation: Modify only one effectuation
class and verify unaffected classes remain eligible where supported.
Experiment 27 — Incomplete Revalidation: Ensure that partial path
discovery does not restore authority.
Experiment 28 — Blocking Capability Probe: Verify actual denial of a
controlled test effect.
Experiment 29 — Unrecognized Interface: Introduce a newly discovered
effect-capable surface.
Experiment 30 — Device Ownership Change: Reassign a protected device
and test old-owner commands.
Experiment 31 — Device Command Queue: Require current operation
authority at a protected hardware dispatcher.
Experiment 32 — Hardware Attribution: Verify the actual device and
controller associated with a consequential command.
Experiment 33 — Accelerator Command Path: Test an accelerator-
originated shared-resource operation.
Experiment 34 — Direct Memory Access Scope: Verify the selected
hardware resource-access restriction.
Experiment 35 — Direct Device Egress: Evaluate the separate control
required for hardware-originated transmission.
Experiment 36 — Driver Update: Introduce a modified command path and
require revalidation.
Experiment 37 — Firmware Change: Test enforcement-continuity checks
following a relevant firmware update.
Experiment 38 — Runtime Service Replacement: Replace a protected
service with one having different enforcement behavior.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Experiment 39 — Cross-Provider Handoff: Verify limitations and
required destination-side enforcement for remote effects.
Experiment 40 — Cross-Sink Authority Replay: Present one operation-
bound authority at an unintended sink.
Experiment 41 — Resource Alias Substitution: Change the actual
resource referenced by a permitted logical identifier.
Experiment 42 — Revocation During Update: Revoke original authority
while the coverage controller is revalidating.
5.3.3.67. Original Global Page 1288
Experiment 43 — Crash During Invalidation: Verify safe recovery of
protected coverage-generation state.
Experiment 44 — Crash During Effectuation: Preserve actual-attempt or
uncertainty state.
Experiment 45 — Distributed Coverage Epochs: Test consistency among
several participating protected controllers.
Experiment 46 — Snapshot Rollback: Restore an earlier accepted local
coverage record.
Experiment 47 — Conflict-Control Integration: Verify current resource
reservation requirements together with coverage.
Experiment 48 — Cumulative Privacy Integration: Test protected data-
release finality over several alternative covered egress paths.
Experiment 49 — Model Drift Integration: Change the computational
generation while preserving the required coverage check.
Experiment 50 — Device Migration Integration: Revalidate hardware
command ownership and current coverage after migration.
Experiment 51 — Recovery Integration: Restrict corrective operations
while coverage remains unresolved.
Experiment 52 — Quorum-Protected Topology Change: Require
authenticated collective approval for a selected high-impact
enforcement configuration modification.
Experiment 53 — Verification Work Exhaustion: Supply large or cyclic
effectuation graphs and verify bounded work.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Experiment 54 — Monitoring Failure: Disable a nonmandatory observer
and distinguish its failure from loss of mandatory blocking coverage.
Experiment 55 — Mandatory Gate Failure: Disable a required
enforcement component and confirm fail-closed behavior.
Experiment 56 — Integrated Protected Controller: Implement discovery,
coverage state, and finality within one suitably protected subsystem.
Experiment 57 — Distributed Protected Controller: Separate coverage
verification and actual effectuation across authenticated domains.
Experiment 58 — No Blockchain: Demonstrate authenticated coverage
epochs and current finality authorization without a distributed
ledger.
Experiment 59 — Unresolved Hardware Surface: Verify that unknown
required device command coverage does not produce a false accepted
result.
5.3.3.68. Original Global Page 1289
Experiment 60 — In-Flight Effect: Advance the coverage epoch after
dispatch and verify that real effect and uncertainty records remain
technically accurate.
Each experiment should identify:
The declared covered domain;
The specific relevant effect-capable path;
The required blocking mechanism;
The controlled adversarial modification;
The expected protected state transition;
The actual observable effect;
And the limitation of the resulting assurance.
The experiments are non-limiting implementation aids for a person
having ordinary skill in the art.
14.54 — PERFORMANCE, SCALABILITY, AND FEASIBILITY
14.54.1 — Event-Driven Revalidation
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected deployment may perform full coverage verification
following relevant topology changes instead of repeating complete
graph discovery on every instruction.
14.54.2 — Coverage Dependency Index
The controller may maintain an index associating Candidate Acts with
their required enforcement components.
14.54.3 — Targeted Epoch Invalidation
A particular change may invalidate only affected operation classes.
14.54.4 — Protected Coverage Caching
Current accepted results may be cached within valid epoch and
configuration conditions.
14.54.5 — Sink-Local Fast Path
The actual Finality Sink may perform compact current-epoch and
authority checks.
14.54.6 — Incremental Graph Updates
5.3.3.69. Original Global Page 1290
The verifier may reevaluate affected subgraphs after qualified
localized changes.
14.54.7 — Protected Resource Enumeration
Known registries and authenticated configuration state may reduce
repeated discovery cost.
14.54.8 — Verification Budget
Complex topology analyses may be bounded by protected work limits.
14.54.9 — Fail-Closed Resource Exhaustion
Failure to complete a mandatory verification does not automatically
authorize affected new effects.
14.54.10 — Hardware Observation Cost
Detailed device and command-path measurement may be more expensive
than ordinary software interface inspection.
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.54.11 — Stronger Hardware Assurance
A protected hardware gate may provide an authoritative release
boundary unavailable to an unprivileged software process.
14.54.12 — Availability Tradeoff
Strict enforcement may withhold selected operations during topology
updates or partitions.
14.54.13 — Granular Recovery
The system may restore operation classes independently where their
required coverage can be verified separately.
14.54.14 — Assurance Requirement
The protected system must identify which path and resource properties
are enforced, which are inferred, and which are outside its trust
model.
14.55 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
14.55.1 — Dynamic Agent Tool Ecosystems
Autonomous agents may install or invoke new effect-capable tools at
runtime.
Protected coverage state may be reevaluated before newly introduced
consequences become effective.
5.3.3.70. Original Global Page 1291
14.55.2 — Multi-Provider Autonomous Execution
An agent may delegate computation to a remote provider while
retaining operation-specific finality conditions at an appropriately
protected destination.
14.55.3 — Cross-Cloud Resource Enforcement
Several infrastructure providers may exchange authenticated coverage
evidence under defined administrative boundaries.
14.55.4 — Confidential Computing
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A confidential execution environment may supply selected attestation
evidence while external effectuation remains governed by independent
protected sinks.
14.55.5 — Hardware-Enforced Agent Sandboxes
A protected hardware boundary may constrain privileged device,
memory, or communication paths.
14.55.6 — GPU and NPU Direct Resource Effects
Accelerator-originated operations may require qualified command-queue
and egress control.
14.55.7 — Heterogeneous Hardware Fabrics
Several interconnected processors and accelerators may require
protected shared-resource attribution and current coverage
verification.
14.55.8 — Device-to-Device Communication
Direct peripheral or embedded-device effects may be subject to
protected device-local finality.
14.55.9 — Future Programmable Networks
Dynamic network functions may introduce new control-plane or data-
plane effectuation interfaces.
14.55.10 — Autonomous Industrial Systems
Dynamic controller updates may trigger protected effectuation-path
revalidation.
14.55.11 — Robotics Fleets
Multiple devices may share command or sensor paths requiring current
protected resource ownership.
14.55.12 — Autonomous Vehicles
5.3.3.71. Original Global Page 1292
Selected safety-relevant command paths may be governed by independent
hardware and software enforcement.
14.55.13 — Satellite and Remote Infrastructure
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Remote devices may employ bounded coverage authority under defined
disconnected-operation assumptions.
14.55.14 — Protected Smart Storage
Storage controllers may independently verify actual mutation
authority despite application-level route changes.
14.55.15 — Spatial Computing
Rendering, sensing, and hardware output interfaces may be classified
as consequential disclosure or actuation paths where appropriate.
14.55.16 — Protected AI Memory Services
Newly mounted persistent memory or retrieval resources may trigger
disclosure-path or mutation-path revalidation.
14.55.17 — Cryptographic Algorithm Migration
Authenticated coverage evidence may use evolving cryptographic
primitives.
14.55.18 — Privacy-Preserving Coverage Proofs
A protected verifier may prove selected coverage predicates without
revealing all sensitive infrastructure details.
14.55.19 — Dynamic Multi-Agent Authorization
The required effectuation path may change according to which
authorized agent or administrative domain receives a delegated task.
14.55.20 — Unified Execution-Finality Infrastructure
A protected service may integrate effectuation-path coverage, current
resource attribution, qualified blocking enforcement, and operation-
specific finality across heterogeneous autonomous computing systems.
These implementations are illustrative and are not represented as
completed tests or deployed systems.
14.56 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
5.3.3.72. Original Global Page 1293
14.56.1 — Path Graph Plus Finality Sink
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected controller verifies that the actual consequential route
is covered by qualified mandatory enforcement.
14.56.2 — Blocking Classification Plus Coverage Commitment
Monitoring-only components cannot satisfy the required protected path
coverage.
14.56.3 — Runtime Change Plus Automatic Fencing
Material changes invalidate affected operation-specific finality
authority.
14.56.4 — Topology Epoch Plus Sink-Local Verification
An actual sink refuses effectuation using an outdated coverage
generation.
14.56.5 — Tool Enrollment Plus Semantic Verification
A dynamically introduced tool must satisfy current operation-contract
and effectuation-path requirements.
14.56.6 — Hardware Attribution Plus Command Finality
A protected hardware controller verifies actual device identity,
ownership, command path, and scoped authority.
14.56.7 — Direct Network Egress Plus Protected Destination Binding
Alternative network routes remain governed by current recipient and
effectuation conditions.
14.56.8 — Privileged Worker Plus Source Authority
A privileged intermediary verifies source-derived operation-specific
authority instead of treating broad worker credentials as sufficient.
14.56.9 — Encrypted Egress Plus Plaintext-Bound Authority
A protected encryption or release service links the actual outgoing
ciphertext operation to previously verified plaintext and recipient
scope.
14.56.10 — Resource Migration Plus Coverage Revalidation
Moving a device or workload triggers current ownership and path-
coverage verification.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.56.11 — Accelerator Egress Plus Hardware Isolation
A protected accelerator route combines resource-access restrictions
with operation-specific command authorization.
5.3.3.73. Original Global Page 1294
14.56.12 — Conflict Reservation Plus Current Coverage
A correctly reserved Candidate Act remains non-effective if its
actual effectuation path loses mandatory coverage.
14.56.13 — Cumulative Privacy Plus Path Coverage
A disclosure cannot bypass a protected cumulative exposure allowance
through an uncontrolled alternate information-release path.
14.56.14 — Quorum Approval Plus Coverage Continuity
A valid collective approval remains insufficient when the actual
effectuation path has become unqualified.
14.56.15 — Causal Receipt Plus Sink Coverage
A successor operation requires both its accepted earlier actual-
effect receipt and current covered consequential authority.
14.56.16 — Recovery Plus Coverage Repair
A corrective operation may be withheld until its own actual
effectuation route has been properly protected.
14.57 — PROPOSED INVENTIVE-STEP ANALYSIS
14.57.1 — Established Prior Art
Reference monitors, complete mediation, mandatory access control,
sandboxing, network firewalls, service registries, system topology
discovery, device isolation, hardware access protection, runtime
policy updates, and attestation are established technical areas.
The present embodiment does not assert original invention of those
mechanisms individually.
14.57.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
How to maintain non-bypassable consequential execution-finality
enforcement when the actual set of effect-capable paths changes
during autonomous operation, by establishing authenticated blocking-
coverage evidence, invalidating authority dependent upon stale
topology state, and requiring independent current path and actual-
operation verification at the effectuation boundary.
14.57.3 — Candidate Technical Solution
A candidate technical combination comprises:
5.3.3.74. Original Global Page 1295
Authenticated effect-capable resource enumeration;
A protected graph of relevant consequential paths;
Qualified distinction between blocking and monitoring components;
An authenticated coverage commitment;
A current protected coverage epoch;
Change-triggered invalidation or fencing;
Protected revalidation of affected software and hardware paths;
Operation-bound non-bearer finality authority;
And independent sink-time verification.
14.57.4 — Technical Interaction
The resource inventory identifies the relevant effect-capable
objects.
The topology graph identifies supported routes from computational
entities to those objects.
The enforcement classifier determines which components provide
mandatory blocking.
The coverage verifier determines whether the selected path-control
predicate is satisfied.
The coverage commitment associates the accepted result with a
protected configuration generation.
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invalidation controller prevents stale authorization from
remaining effective after material changes.
The revalidation controller establishes current qualified coverage.
The actual Finality Sink verifies that the pending effect corresponds
to valid current coverage and operation-specific authority.
The protected consumption state prevents unrelated or repeated
exercise of the resulting enablement.
14.57.5 — Not Merely a Reference Monitor
The reference-monitor principle is established.
The proposed arrangement specifies operation-specific protected
coverage dependencies, dynamic invalidation, and current sink-time
authority binding within an autonomous execution-finality
architecture.
5.3.3.75. Original Global Page 1296
14.57.6 — Not Merely a Sandbox
A sandbox may restrict a fixed class of process operations.
The principal implementation additionally evaluates how current
effect-capable paths and resource attribution changes affect
previously issued finality authority.
14.57.7 — Not Merely eBPF or Kernel Instrumentation
Kernel instrumentation and mandatory access-control hooks are
established.
The proposed arrangement does not treat attachment or telemetry as
sufficient unless the required blocking and complete-mediation
properties are established for the relevant effect.
14.57.8 — Not Merely Topology Discovery
A service inventory or path graph may identify resources.
The candidate technical mechanism connects accepted path-coverage
state to actual consequential authority and mandatory sink-time
verification.
14.57.9 — Not Merely Attestation
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Authenticated configuration evidence may establish selected
properties of an execution environment.
The present principal implementation separately verifies that the
actual pending effect remains within protected source authority and
current coverage.
14.57.10 — Not Merely Configuration Monitoring
A monitoring service may detect that a gate was disabled.
The proposed stronger mechanism requires affected consequential
authority to become invalid or fenced until current coverage is
restored.
14.57.11 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
A protected autonomous execution system that maintains authenticated
effect-capable path and enforcement-coverage state, binds operation-
specific non-bearer finality authority to a protected coverage
generation, invalidates affected authority when a material software,
routing, resource, or hardware topology change occurs, and requires
an independently enforcing Finality Sink to reconstruct the actual
pending operation and verify current qualified mandatory path
coverage before permitting the consequential effect.
14.57.12 — Additional Hardware Kernel
5.3.3.76. Original Global Page 1297
A narrower implementation may require current protected attribution
of device ownership, command queue, and hardware effectuation path,
with actual device-level refusal of commands lacking matching
operation-specific authority.
14.57.13 — Additional Dynamic Tool Kernel
Another candidate may require automatic fencing of affected
consequential authority when a newly introduced tool exposes an
effect-capable route absent from the accepted coverage graph.
14.57.14 — Additional Blocking-Classification Kernel
Another candidate may require explicit distinction between
monitoring-only and pre-effectuation blocking enforcement, together
with refusal to treat unqualified monitoring as coverage.
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.57.15 — Additional Epoch-Race Kernel
Another candidate may require protected invalidation and epoch
advancement before a controlled topology transition can expose an
uncontrolled effectuation path, with sink-local current-epoch
verification.
14.57.16 — Hindsight Considerations
A proper inventive-step analysis should examine the closest relevant
prior-art security systems, including reference monitors, runtime
access-control reconfiguration, capability systems, hardware
mediation, policy-controlled gateways, and attested enforcement
architectures.
Many combinations of inventory, monitoring, policy updates, and
blocking may be conventional or obvious.
The technical inventive-step position should therefore focus upon the
precise interaction among current topology evidence, mandatory
effect-path qualification, protected invalidation of existing
finality authority, and independent actual effectuation enforcement.
14.57.17 — Patentability Qualification
The creation of a resource graph or authenticated coverage record
does not independently establish novelty.
Complete path discovery cannot be claimed without a technically
supportable coverage boundary and implementation.
Patentability depends upon the exact claimed combination, enabling
disclosure, relevant prior art, and demonstrable technical effect.
14.58 — INDUSTRIAL APPLICABILITY
5.3.3.77. Original Global Page 1298
14.58.1 — Enterprise Autonomous Agents
Enterprise agents may access tools and resources through dynamically
changing interfaces while consequential operations remain subject to
current mandatory coverage.
14.58.2 — Cloud AI Infrastructure
Cloud environments may verify protected execution paths as services,
containers, policies, or model-serving arrangements change.
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
14.58.3 — Multi-Agent Platforms
Several agents may share effect-capable interfaces while preserving
current operation-specific authorization.
14.58.4 — Operating-System Security
Protected operating-system controllers may combine resource
enumeration and mandatory finality enforcement.
14.58.5 — Container and Virtual-Machine Infrastructure
Changes to network, storage, process, and device access may trigger
coverage revalidation.
14.58.6 — Database Systems
Autonomous database operations may be protected against alternative
direct mutation paths.
14.58.7 — File and Storage Infrastructure
Protected file or storage mutations may remain controlled across
changing mounts, descriptors, and device interfaces.
14.58.8 — Network Security
Dynamic network routes and service interfaces may be evaluated for
current mandatory egress enforcement.
14.58.9 — Credential Management
Reusable credentials may be constrained where alternative interfaces
could bypass operation-specific finality.
14.58.10 — Financial Services
Payment and transaction operations may require verified current
resource and gateway coverage.
14.58.11 — Electronic Commerce
5.3.3.78. Original Global Page 1299
Automated ordering, payment, refund, and inventory interfaces may be
governed under current protected effectuation paths.
14.58.12 — Telecommunications
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Autonomous communication-network controllers may enforce protected
configuration and traffic effects across changing network functions.
14.58.13 — Industrial Automation
Control systems may revalidate actuator and device command paths
after relevant controller or firmware changes.
14.58.14 — Robotics
Robotic command interfaces may require current hardware resource
ownership and protected command-gate coverage.
14.58.15 — Autonomous Vehicles
Selected consequential device and control interfaces may be subject
to current protected topology and resource-state requirements.
14.58.16 — Hardware Accelerators
GPU, NPU, and other accelerator command or data-egress paths may be
associated with protected effectuation authority.
14.58.17 — Edge Computing
Distributed edge devices may maintain bounded enforcement coverage
and protected resource attribution.
14.58.18 — Confidential Computing
Confidential workloads may supply qualified execution evidence while
external effects remain independently controlled.
14.58.19 — Remote and Satellite Systems
Intermittently connected equipment may use protected local control
paths and bounded authorization under defined assurance assumptions.
14.58.20 — Multimodal AI Systems
Controlled text, audio, video, sensor, display, and other release
interfaces may be classified as effect-capable boundaries where
appropriate.
14.58.21 — Distributed Storage and Message Systems
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.79. Original Global Page 1300
Dynamic resource endpoints may require current path qualification
before protected writes or message releases.
14.58.22 — Long-Running Autonomous Workflows
Operations prepared earlier may require current coverage revalidation
before delayed eventual execution.
14.58.23 — Future Heterogeneous Computing
Evolving processor, device, network, and application architectures
may employ protected resource graph and finality-bound coverage
controls.
14.58.24 — Shared Execution-Finality Services
A protected coverage-verification service may provide reusable
enforcement assurances for multiple autonomous software frameworks
without relying upon any particular agent or model provider.
The industrial utility concerns maintaining effective mandatory
control over consequential operations despite changes to the
software, hardware, and communication pathways through which those
operations may be executed.
14.59 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
14.59.1 — Candidate Independent System Claim
A candidate system claim may comprise:
A protected resource-enumeration component configured to identify
effect-capable resources and interfaces within a declared protected
domain;
A graph controller configured to represent relevant effectuation
paths;
A protected enforcement verifier configured to determine whether the
required paths are subject to qualified mandatory blocking controls;
A coverage-state controller configured to establish authenticated
coverage commitments and protected generations;
A topology-change controller configured to invalidate or fence
consequential authority affected by material changes;
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A revalidation component configured to establish current coverage
following such changes;
And a Finality Sink configured to reconstruct the actual pending
operation and permit effectuation only when its current coverage,
operation-specific authority, and sink-local protected state satisfy
the applicable mandatory conditions.
5.3.3.80. Original Global Page 1301
14.59.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Establishing a protected effectuation domain;
Identifying effect-capable resources;
Constructing a protected path representation;
Classifying enforcement capability;
Verifying required mandatory coverage;
Committing coverage state;
Binding a Candidate Act's finality authority to the relevant coverage
generation;
Detecting a material topology change;
Invalidating affected authority;
Revalidating the updated enforcement configuration;
Reconstructing the actual pending operation at a protected sink;
And permitting the effect only upon satisfaction of current coverage
and operation-specific authorization conditions.
14.59.3 — Candidate Independent Hardware Claim
A protected hardware apparatus may comprise:
A device-resource attribution component;
A protected current command-path controller;
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A coverage-generation state;
And a hardware effectuation gate configured to refuse commands that
lack matching current resource ownership, required enforcement
coverage, and operation-specific non-bearer authority.
14.59.4 — Candidate Independent Dynamic-Tool Claim
Another candidate may address newly introduced tool or service
effectuation paths, automatic invalidation of prior coverage-bound
authority, and mandatory revalidation before new consequential
operations can proceed.
14.59.5 — Candidate Independent Distributed Claim
5.3.3.81. Original Global Page 1302
Another candidate may involve authenticated coverage state spanning
separately administered execution and resource domains, with actual
destination-side finality verification.
The final independent-claim organization should avoid needless
duplication and remain subject to technical unity, prior-art, and
disclosure-support analysis.
14.60 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The protected system enumerates effect-capable
software resources.
Dependent aspect 2: The system enumerates effect-capable hardware
resources.
Dependent aspect 3: The system identifies paths between requesters
and consequential resources.
Dependent aspect 4: The paths are represented in an authenticated
directed graph.
Dependent aspect 5: The graph identifies mandatory enforcement nodes.
Dependent aspect 6: The system distinguishes monitoring-only nodes
from blocking enforcement nodes.
Dependent aspect 7: A monitoring-only component cannot satisfy the
required blocking predicate.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dependent aspect 8: The protected verifier evaluates a mandatory
coverage cut or equivalent reachability constraint.
Dependent aspect 9: The covered domain is associated with explicit
resource and trust-boundary definitions.
Dependent aspect 10: Unknown required paths cause conservative
coverage handling.
Dependent aspect 11: The system establishes a protected coverage
commitment.
Dependent aspect 12: The coverage commitment identifies a protected
generation.
Dependent aspect 13: A Candidate Act is associated with a relevant
coverage dependency set.
Dependent aspect 14: Finality authority is bound to the current
coverage generation.
Dependent aspect 15: A material topology change invalidates affected
authority.
Dependent aspect 16: A protected fence is established before or
during a controlled configuration transition.
5.3.3.82. Original Global Page 1303
Dependent aspect 17: A new coverage epoch is established after a
material enforcement change.
Dependent aspect 18: A previous coverage receipt becomes ineligible
after applicable epoch invalidation.
Dependent aspect 19: The system revalidates affected enforcement
paths before restoring authority.
Dependent aspect 20: Unaffected effectuation classes may retain valid
authority when their coverage dependencies remain satisfied.
Dependent aspect 21: A newly registered tool triggers relevant
coverage reassessment.
Dependent aspect 22: A modified tool contract triggers effectuation-
path revalidation.
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dependent aspect 23: A privileged helper is identified as an indirect
effectuation route.
Dependent aspect 24: The helper must verify operation-specific source
authority before producing the covered effect.
Dependent aspect 25: A direct network socket is constrained by
mandatory egress enforcement.
Dependent aspect 26: An alternate network namespace is included in
relevant coverage evaluation.
Dependent aspect 27: A changed network route triggers coverage
invalidation.
Dependent aspect 28: The actual external destination is verified at
the consequential boundary.
Dependent aspect 29: A protected plaintext-aware interface is
required for selected content-dependent disclosure policies.
Dependent aspect 30: The system binds authorized plaintext
information to the corresponding protected encryption or transmission
operation.
Dependent aspect 31: Alternative file or storage references are
resolved to actual protected resource identities.
Dependent aspect 32: Direct database or storage access is subject to
mandatory finality enforcement.
Dependent aspect 33: A required operating-system security hook is
verified as currently attached.
Dependent aspect 34: A configured security hook must possess the
required blocking capability.
5.3.3.83. Original Global Page 1304
Dependent aspect 35: Detachment of a required hook invalidates
affected coverage authority.
Dependent aspect 36: A change from blocking to audit-only mode
triggers invalidation.
Dependent aspect 37: The system maintains protected device or
resource ownership attribution.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dependent aspect 38: Hardware command queues are represented as
effect-capable interfaces.
Dependent aspect 39: Current device-command ownership is verified
before consequential execution.
Dependent aspect 40: A driver or firmware change triggers
revalidation of affected command paths.
Dependent aspect 41: Direct-memory-access scope is verified under an
appropriate hardware resource-control model.
Dependent aspect 42: An accelerator-originated effect is governed
through a corresponding protected resource gate.
Dependent aspect 43: A hardware path commitment is bound to an actual
resource and current coverage generation.
Dependent aspect 44: A device ownership change invalidates previous
owner's operation-specific effectuation authority.
Dependent aspect 45: The protected system maintains authenticated
coverage revalidation receipts.
Dependent aspect 46: A revalidation receipt identifies the covered
effect classes and applicable trust assumptions.
Dependent aspect 47: A forged or unauthorized coverage receipt is
rejected.
Dependent aspect 48: A stale signed coverage receipt is rejected
under current epoch verification.
Dependent aspect 49: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 50: The sink resolves the actual consequential
resource.
Dependent aspect 51: The sink resolves or verifies the actual
relevant effectuation path.
Dependent aspect 52: The sink verifies the current coverage epoch.
Dependent aspect 53: The sink verifies current operation-specific
source authority.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.3.3.84. Original Global Page 1305
Dependent aspect 54: The sink verifies required resource-version or
reservation conditions.
Dependent aspect 55: The sink consumes scoped non-bearer finality
enablement.
Dependent aspect 56: A copied authority object cannot authorize
another unapproved path.
Dependent aspect 57: A completed effect is distinguished from an
invalidated but not yet executed Candidate Act.
Dependent aspect 58: An uncertain in-flight operation is preserved
under protected outcome state.
Dependent aspect 59: A recovery operation requires separately valid
current effectuation-path authority.
Dependent aspect 60: Cross-provider effects require appropriate
destination-side enforcement where the claimed downstream guarantee
depends upon it.
Dependent aspect 61: A cumulative privacy-release condition remains
mandatory across covered alternate egress routes.
Dependent aspect 62: A current model or algorithmic-generation
requirement remains independently enforceable.
Dependent aspect 63: A required quorum approval does not replace
current path-coverage verification.
Dependent aspect 64: A CW-2 accepted actual-effect receipt remains
necessary where required for causal successor authority.
Dependent aspect 65: The verifier enforces a protected resource or
work budget.
Dependent aspect 66: A finite bypass test is treated as evidence for
its specified route rather than proof of every possible path.
Dependent aspect 67: A protected integrated controller may perform
coverage verification and actual finality enforcement.
Dependent aspect 68: Separate authenticated controllers may perform
discovery, revalidation, and sink-side enforcement.
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dependent aspect 69: The architecture supports operation-specific
coverage validation without requiring a public blockchain.
Dependent aspect 70: The system may use one or more hardware or
software mechanisms to establish equivalent mandatory blocking
enforcement.
These aspects are non-limiting claim-support possibilities rather
than individually established patentable inventions.
5.3.3.85. Original Global Page 1306
14.61 — NON-LIMITING IMPLEMENTATION AND COMBINATION CLAUSE
The disclosed mechanisms may be implemented individually or in
technically compatible combinations.
An implementation may protect application tool calls.
Another may protect operating-system resource operations.
Another may protect network egress.
Another may protect database or storage commits.
Another may protect device commands.
Another may protect accelerator-originated consequential effects.
Another may combine these operation classes within one protected
effectuation domain.
An implementation may use declarative protected configuration instead
of runtime graph enumeration where the controlled environment
provides sufficient completeness guarantees.
Another may use authenticated runtime discovery.
Another may use protected hardware resource ownership and command
gating.
Another may employ operating-system mandatory access controls or
appropriately isolated service gateways.
No particular operating-system hook, device model, network protocol,
graph representation, cryptographic primitive, or software framework
is universally required unless specified by a selected claim.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The phrase non-bypassable applies only to the defined covered
effectuation boundary and the actual enforcement guarantees supported
by the implementation.
The phrase complete coverage does not imply universal control over
unknown physical devices, untrusted administrators, independent
remote systems, or unenumerated privileged effects.
A cryptographic commitment authenticates specified information but
does not prove that every effect-capable path was correctly
discovered.
A successful controlled bypass test provides evidence concerning the
tested route under the stated conditions, not a universal
impossibility proof.
5.3.3.86. Original Global Page 1307
The disclosed pseudocode, state machines, diagrams, data structures,
threat models, worked examples, and proposed experiments are
illustrative and non-limiting technical aids intended to assist a
person having ordinary skill in the art.
Where technically compatible, the mechanisms may be combined with the
protected Candidate Act, non-effective holding, source authority,
evidence, finality, conflict, privacy, device migration, execution
integrity, quorum, and recovery mechanisms of other embodiments.
A cross-reference does not automatically make every feature of
another embodiment mandatory.
The permissible scope of any selected combination depends upon
technical compatibility, the precise claim language, and the enabling
disclosure actually filed.
Future-oriented variations are technical proposals, not
representations that the corresponding systems have been
experimentally demonstrated.
No proposed experiment is represented as completed unless
independently performed and documented.
14.62 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The present Embodiment 14 discloses a protected execution-finality
architecture for maintaining mandatory consequential enforcement
despite changes to the software, hardware, service, network, storage,
device, or other effectuation paths available to autonomous
computational systems.
The architecture distinguishes an installed security mechanism from
an effective mandatory enforcement boundary.
A monitoring component may observe an operation without preventing
it.
An application gateway may correctly validate a request while an
equivalent direct resource interface remains uncontrolled.
A protected system may therefore require qualified evidence that
relevant effect-capable paths within the declared controlled
environment are subject to mandatory blocking enforcement.
In a principal implementation, a protected controller establishes an
authenticated representation of relevant resources, interfaces,
enforcement components, and consequential routes.
A verifier determines whether the supported topology satisfies a
defined mandatory path-coverage predicate.
5.3.3.87. Original Global Page 1308
The accepted configuration is associated with a protected coverage
commitment and current coverage generation.
Operation-specific finality authority may be bound to the coverage
dependencies necessary for the particular consequential effect.
When a material change occurs to an interface, route, privileged
worker, tool, device, hardware command path, policy, or enforcement
configuration, the system invalidates or fences affected authority.
The changed topology is reexamined.
Qualified blocking enforcement must be restored or established before
the corresponding coverage state can be accepted again.
A protected controller may then issue or revalidate operation-
specific authority under the current coverage generation.
Before actual effectuation, the Finality Sink independently obtains
or reconstructs the pending consequential operation.
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The sink verifies its actual resource identity, current protected
effectuation path, accepted coverage state, source authorization,
current operation scope, and protected sink-local consumption
conditions.
A valid historical approval or coverage certificate does not
automatically authorize an operation through a new or uncontrolled
effectuation interface.
The architecture may be applied to application-level tools,
privileged services, network egress, file and database mutations,
hardware device commands, accelerators, confidential computing, and
distributed autonomous infrastructure.
The selected assurance depends upon the declared protection boundary,
completeness of controlled resource enumeration or access
restriction, correct enforcement classification, protected topology-
change management, and actual effectuation coverage.
The embodiment does not claim that reference monitors, sandboxing,
mandatory access control, kernel security hooks, hardware isolation,
network gateways, topology discovery, or attestation are individually
new.
Its proposed additional contribution lies in enforcing a protected
current-state dependency between mandatory path coverage and the
authority to release real consequential effects.
The principal candidate inventive technical concept of Embodiment 14
is a protected effectuation-path continuity architecture in which
authenticated effect-capable topology and blocking-enforcement
evidence support a coverage-bound finality authority, material
runtime or hardware path changes invalidate affected protected
authority, and an independently enforcing Finality Sink refuses the
actual pending consequential operation unless current path coverage,
actual resource correspondence, operation-
5.4. Miscellaneous Embodiment M-2: Existing Standards, Kernel, Sandbox
and Hardware Integration
Original source global pages 1898–1952; attachment TECHNICAL
SPECIFICATION -1542-2011.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.4.1. Architecture Diagram: Protected Components and Trust Boundaries
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[OAuth / ACE / OS permission / RATS / COSE]
|
[Verify exact assertion each mechanism proves]
|
[Protected evidence translation adapter]
|
[Current source + operation + coverage predicates]
|
[Scoped non-bearer finality enabling state]
|
[Actual receiving Finality Sink check]
|
[Prevent or perform controlled effect]
Figure 7: Miscellaneous Embodiment M-2: Existing Standards,
Kernel, Sandbox and Hardware Integration: architecture
5.4.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Existing security mechanism reports success]
|
<Is input evidence authentic and in-scope?>--NO-->[REFUSE]
| YES
<Does it prove exact real-effect authority?>--NO-->[MORE CHECKS]
| YES / independently qualified
<Covered sink controls actual pending effect?>--NO-->[WITHHOLD]
| YES
[Consume narrow authority, release only this effect]
Figure 8: Miscellaneous Embodiment M-2: Existing Standards,
Kernel, Sandbox and Hardware Integration: operational decision
flow
5.4.3. Page-Indexed Original Technical Text
5.4.3.1. Original Global Page 1898
MISCELLANEOUS EMBODIMENT M-2
STANDARDS-INTEROPERABLE, PLATFORM-INDEPENDENT EXECUTION-FINALITY
CONSTITUTION USING EXISTING AUTHORIZATION, CRYPTOGRAPHIC, OPERATING-
SYSTEM, NETWORK, IPC, SANDBOX, NOTIFICATION, AND HARDWARE SECURITY
MECHANISMS
M-2.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Systems, Methods, and Apparatus for Constituting Protected Operation-
Specific Execution-Finality Authority from Heterogeneous
Authorization and Security Mechanisms Using Independently Verified
Authorization Dependencies, Protected Authorization-to-Effect
Translation, Current Revocation and Enforcement-Topology Commitments,
Scoped Non-Bearer Finality Enablement, and Mandatory Sink-Local
Actual-Operation Verification and Consumption
M-2.0.1 — Technical Purpose
The present Miscellaneous Embodiment M-2 discloses systems, methods,
apparatus, software components, protected services, hardware-assisted
enforcement structures, communication protocols, machine-verifiable
records, and non-limiting implementation variations for integrating
existing authorization and security mechanisms into a protected
autonomous execution-finality architecture.
The embodiment addresses the technical problem that different
authorization and security systems may independently establish
permission, identity, possession of a cryptographic key, process
isolation, permitted network access, resource visibility, message
delivery, configuration state, or security-event observation, without
necessarily establishing current authority to perform the particular
consequential operation actually presented at a resource effectuation
boundary.
An autonomous computational entity may be authorized to invoke an
application interface while lacking permission to perform the
particular resource mutation that an invocation would produce.
A token may be active while the proposed operation exceeds its
authorized effect scope.
A sender may demonstrate possession of a bound cryptographic key
while the actual request body, recipient, resource version, or
subsequent operation differs from the previously authorized effect.
A security monitor may observe an operation without having the
ability to prevent its consequence.
A sandbox may constrain one execution environment while a privileged
broker or independently reachable resource interface retains a
different effectuation path.
A revocation notification may be delivered to one component without
having been applied at the protected resource.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A cryptographic signature may authenticate a previous approval
without establishing that the actual operation remains current, has
not been revoked, or has not already consumed its permitted
authority.
The disclosed invention does not require replacing each of these
established mechanisms.
5.4.3.2. Original Global Page 1899
Instead, in selected implementations, existing authorization and
security mechanisms provide qualified inputs or enforcement functions
within a distinct protected execution-finality relationship.
The protected architecture identifies the authorization scope
established by each input mechanism, determines the actual technical
conditions under which the mechanism can enforce a particular
consequential operation, and prevents an evidentiary or upstream
permission result from automatically becoming executable finality
authority.
A protected finality controller establishes operation-specific
enablement only upon satisfaction of the applicable authority and
evidence predicates.
At the actual effectuation boundary, a designated Finality Sink
independently obtains or reconstructs the actual pending operation,
verifies the required current authority and enforcement conditions,
and performs the corresponding protected consumption transition
before permitting the consequence.
The principal implementation may additionally couple current
authority to revocation generations, effectuation-path coverage
state, resource identity, protected hardware or software execution
configuration, and bounded temporal validity.
M-2.0.2 — Fundamental Technical Principle
A component that proves identity, permission, key possession, sandbox
membership, request delivery, or enforcement attachment does not
necessarily prove that the actual pending consequence is currently
authorized.
In the present embodiment, a heterogeneous authorization result may
be used as evidence or as a bounded technical enforcement
contribution, without automatically being treated as sufficient
authority to make an external or persistent effect effective.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A valid authorization result is distinguished from:
A fully resolved operation descriptor;
An independently verified current authority state;
A qualified mandatory effectuation path;
A protected finality enablement;
And a sink-local protected exercise of that enablement.
M-2.0.3 — Principal Technical Combination
In a principal implementation, the disclosed combination comprises:
(a) a consequential Candidate Act constructed from an autonomous
application's proposed operation;
(b) an authorization-source adapter capable of obtaining qualified
evidence from one or more existing permission systems;
(c) a protected operation-translation mechanism binding that evidence
to a canonical effect descriptor;
5.4.3.3. Original Global Page 1900
(d) a protected evidence collector and independent current validation
function;
(e) a current authority-dependency and revocation-generation
verifier;
(f) a mechanism establishing that the corresponding actual
effectuation path is subject to suitable mandatory enforcement;
(g) a protected authority controller constituting scoped non-bearer
finality enablement;
(h) a designated Finality Sink capable of independently determining
the actual pending consequential operation;
(i) a protected sink-local authority and consumption state; and
(j) a fail-closed release condition rejecting an operation when
required source, actual-effect, revocation, enforcement, or
consumption predicates cannot be established.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The selected technical relationship is intended to operate even when
the underlying permission system, cryptographic protocol, process
isolation mechanism, enforcement hook, or network-control
implementation is replaced by a functionally compatible alternative.
M-2.0.4 — Separation Between Primitives and the Claimed Relationship
The embodiment does not characterize conventional token issuance,
token revocation, token introspection, proof-of-possession
authentication, mutual authentication, operating-system sandboxing,
interprocess communication, protected cryptographic key storage,
network filtering, event notifications, transactional databases, or
resource access control as individually invented.
These functions may be employed as known technical substrates.
The proposed technical combination concerns the mandatory state and
evidence dependencies by which selected substrate outputs become
necessary but insufficient inputs to operation-specific consequential
authority, with separate protected finality constitution and actual
effectuation verification.
M-2.0.5 — Non-Limiting Implementation Models
The present invention may be implemented through one or more of the
following broad models:
A software authorization-and-resource-gateway implementation;
A mobile or desktop operating-system implementation;
A protected application-action implementation;
A privileged interprocess service implementation;
A network egress implementation;
A cloud or enterprise API implementation;
A distributed cross-domain implementation;
A protected credential-broker implementation;
5.4.3.4. Original Global Page 1901
A hardware-backed authority implementation;
A device-command implementation;
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A bounded offline implementation;
Or a hybrid implementation combining selected mechanisms.
No particular commercial operating system, cloud environment,
identity provider, AI model, or cryptographic hardware product is
universally necessary.
M-2.1 — TECHNICAL FIELD
This embodiment relates to autonomous computing security, execution-
finality enforcement, authorization protocol interoperability,
machine-verifiable operation scope, proof-of-possession
authentication, protected revocation, cryptographic authority
binding, operating-system security, application tool invocation,
privileged service mediation, network egress control, hardware-backed
keys, resource-specific transactional control, and protected
consequential execution.
More particularly, the embodiment concerns transforming qualified
outputs of heterogeneous existing security mechanisms into precisely
bounded operation-specific authority and enforcing that authority at
the actual resource boundary rather than relying upon upstream
application permission alone.
M-2.2 — SPECIFIC TECHNICAL PROBLEMS
M-2.2.1 — Authorization-to-Effect Semantic Gap
An existing authorization mechanism may identify a permitted service,
API, scope, or general action without independently determining the
complete consequential operation that is about to occur.
M-2.2.2 — Active-Credential Gap
A credential may remain active while the proposed effect is outside
the original permitted task or exceeds current resource scope.
M-2.2.3 — Proof-of-Possession Gap
A requester may prove possession of a cryptographic key without
proving that every security-relevant field of the actual operation
matches independently established authorization.
M-2.2.4 — Structured-Intent Gap
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An application may provide a structured proposed action, but the
action's actual resource-side behavior may differ because of
parameter resolution, redirects, aliases, tool implementation
changes, or additional side effects.
M-2.2.5 — Isolation-to-Effect Gap
5.4.3.5. Original Global Page 1902
A sandbox may restrict selected process privileges while an available
privileged helper or remote service can still cause consequential
effects.
M-2.2.6 — Observation-to-Blocking Gap
An operating-system monitor may report an event without possessing
authority to prevent the corresponding effect.
M-2.2.7 — Network-Flow-to-Content Gap
A network filter may identify endpoints and connections while lacking
authenticated access to the plaintext content or application
semantics required by the authorization policy.
M-2.2.8 — Cryptographic-Signature-to-Finality Gap
A protected signature may authenticate a record without establishing
current revocation status, actual operation correspondence, or
remaining consumable authority.
M-2.2.9 — Revocation-Propagation Gap
A valid revocation may have been committed upstream without yet being
applied by the actual resource sink.
M-2.2.10 — Notification-to-Enforcement Gap
An asynchronous notification may be delayed, dropped, reordered, or
delivered without causing the required protected invalidation.
M-2.2.11 — Cross-Mechanism State Inconsistency
Different mechanisms may evaluate permissions using different
resource identities, policy epochs, operation representations, or
authorization freshness conditions.
M-2.2.12 — Security-Primitive Substitution
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A system may replace one authorization or enforcement implementation
with another that has weaker semantic coverage while retaining an
apparently valid high-level permission.
M-2.2.13 — Authority Replay
An earlier valid token, signed receipt, operation descriptor, or
capability reference may be reused for another effect.
M-2.2.14 — Current Operation Divergence
The actual outgoing operation may differ from the approved operation
after a service, model, resource, or transport transformation.
M-2.2.15 — Protection-Boundary Ambiguity
A deployment may be unable to establish whether a particular control
is mandatory, advisory, monitoring-only, or bypassable.
5.4.3.6. Original Global Page 1903
M-2.2.16 — Technical Objective
A candidate objective technical problem is:
How to use heterogeneous established authorization, cryptographic,
process-isolation, communication, network, and hardware security
mechanisms to control autonomous consequential operations without
treating any one primitive's successful result as sufficient
executable authority, by translating each relevant security result
into protected operation-specific evidence and independently
enforcing current actual-effect correspondence, revocation, coverage,
and non-replayable finality consumption at the real resource
boundary.
M-2.3 — COMMON PROTECTED INTEGRATION ARCHITECTURE
A representative implementation may comprise:
1. An Autonomous Computational Requester.
2. A Protected Candidate Act Adapter.
3. A Heterogeneous Authorization Evidence Adapter.
4. A Protected Effect-Semantics Translation Controller.
5. A Collection-Time Evidence Instance.
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6. An Independent Execution-Time Validation Instance.
7. A Current Authority and Revocation Dependency Controller.
8. An Enforcement-Coverage Qualification Controller.
9. A Protected Finality Enablement Controller.
10. A Privileged or Resource-Specific Effectuation Broker.
11. A Designated Finality Sink.
12. A Sink-Local Protected State and Consumption Controller.
13. An Optional External Effect Observer.
14. An Optional Crash-Consistent Operation Journal.
A selected implementation may integrate several functions in one
protected component where the applicable claims do not require
structural separation.
Where independent validation, protected state separation, or external
sink authority is expressly required, the implementation must
preserve those properties.
The requesting computational entity does not automatically control
the protected finality authority or the actual resource-side
consumption state.
5.4.3.7. Original Global Page 1904
M-2.4 — CENTRAL PROTECTED DATA STRUCTURES
M-2.4.1 — Authorization Source Evidence
AUTHORIZATION_SOURCE_EVIDENCE = { source_mechanism_class,
issuer_or_controller_identity, requester_identity,
credential_or_grant_reference, authorized_resource_scope,
authorized_operation_scope, protected_principal_reference,
proof_of_possession_reference, applicable_policy_version,
authorization_generation, current_revocation_reference,
evidence_freshness, authentication_result, evidence_assurance_profile
} The evidence describes the specific property established by the
underlying authorization mechanism.
A successful identity check is not encoded as proof that the actual
operation is valid.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.4.2 — Protected Canonical Effect Descriptor
PROTECTED_CANONICAL_EFFECT_DESCRIPTOR = { candidate_act_identifier,
actual_operation_class, originating_authority,
actual_resource_identity, effective_target_or_recipient,
operation_method_or_primitive, operation_parameters_commitment,
outgoing_content_commitment, expected_resource_generation,
resolved_effectuation_interface, authorized_effect_envelope,
applicable_policy_commitment, protected_descriptor_authentication }
The descriptor includes the security-relevant fields needed to
distinguish authorized and unauthorized effects for the selected
operation class.
Fields that are not relevant to a particular effect may be omitted.
The descriptor must not depend solely on caller-supplied unverified
labels for an operation whose actual resource-side semantics differ.
M-2.4.3 — Enforcement Qualification Record
5.4.3.8. Original Global Page 1905
ENFORCEMENT_QUALIFICATION_RECORD = { actual_effectuation_class,
actual_resource_or_interface, selected_enforcement_component,
enforcement_mode, mandatory_attachment_evidence,
blocking_capability_evidence, operation_visibility_profile,
actual_resource_binding, protected_configuration_generation,
current_coverage_epoch, unresolved_bypass_paths,
qualified_verification_result } The record distinguishes monitoring,
advisory, and blocking enforcement.
M-2.4.4 — Revocation-Dependent Finality Enablement
REVOCATION_DEPENDENT_FINALITY_ENABLEMENT = {
candidate_act_commitment, authorization_evidence_commitment,
collection_time_evidence_commitment,
independent_validation_commitment,
canonical_effect_descriptor_commitment, original_source_authority,
required_delegation_dependencies, current_revocation_generation,
required_freshness_state, current_enforcement_coverage_epoch,
designated_finality_sink, authorized_resource, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The enablement may be maintained entirely within a protected
controller and represented to the requester by an inert reference.
M-2.4.5 — Sink-Local Finality State
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
SINK_LOCAL_FINALITY_STATE = { designated_sink_identity,
resource_identity, accepted_authority_generation,
accepted_revocation_generation, accepted_coverage_generation,
authorized_operation_commitment, finality_enablement_identifier,
consumption_generation, remaining_permitted_uses,
current_resource_state, active_enforcement_mode,
5.4.3.9. Original Global Page 1906
pending_dispatch_state, protected_state_authentication } The
protected sink verifies the current state before consequential
release.
M-2.5 — PROTECTED AUTHORIZATION-TO-EFFECT TRANSLATION
In one principal variation, the architecture includes a protected
translation mechanism converting authorization information from a
heterogeneous permission system into an effect-specific validation
requirement.
The translation is not limited to extracting an access-token scope.
It may reconcile:
The identity of the authorized principal;
The applicable source grant;
A permission's intended operation;
A structured application action;
The actual resource method;
The effective recipient;
The outgoing content;
The protected resource version;
The required proof-of-possession relation;
And the current resource-side enforcement boundary.
M-2.5.1 — Translation Input
The controller receives qualified permission evidence and a Candidate
Act descriptor.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.5.2 — Independent Semantic Resolution
The controller determines the actual technical meaning of the
operation under its applicable contract.
M-2.5.3 — Protected Effect Envelope
The permissible operation scope is expressed as bounded effect
parameters.
M-2.5.4 — Source Authority Preservation
A narrow permission is not silently expanded into broader executable
authority.
M-2.5.5 — Unresolved Semantics
5.4.3.10. Original Global Page 1907
If the operation's relevant effects cannot be sufficiently
determined, the selected protected consequence remains withheld.
M-2.5.6 — Effect-Specific Finality
Different resource classes may employ different actual-operation
descriptors and sink checks.
M-2.5.7 — Technical Significance
The proposed relationship requires an established permission result
to remain subordinate to a protected actual-effect binding rather
than allowing an upstream token or tool label to become sufficient
effectuation authority.
M-2.6 — VARIATION A: OAUTH AND EQUIVALENT AUTHORIZATION-SERVER
INTEGRATION
An implementation may use an established authorization-server
architecture to identify principals, clients, resources, permissions,
and delegated access.
OAuth-style access tokens and grants may constitute one source of
authorization evidence.
The protected execution-finality controller does not assume that
token validity is sufficient to release every covered consequential
operation.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.6.1 — Source Grant
The authorization server provides a resource-access grant under an
authenticated principal or delegation relationship.
M-2.6.2 — Candidate Act
The autonomous requester proposes a specific consequential API or
resource operation.
M-2.6.3 — Authority Translation
The protected adapter maps the authorized resource and scope into
required effect-specific predicates.
M-2.6.4 — Independent Validation
A protected validator evaluates the current operation against the
actual permission envelope.
M-2.6.5 — Finality Enablement
A separate protected controller establishes scoped non-bearer
enablement for the specified operation.
M-2.6.6 — Sink Reconstruction
The resource sink resolves the actual pending request, target,
parameters, and authorized scope.
M-2.6.7 — Consequential Release
5.4.3.11. Original Global Page 1908
The sink releases the operation only after current authority,
revocation, actual-effect, and protected consumption checks pass.
M-2.6.8 — Alternative Permission Systems
The same mechanism may use non-OAuth enterprise identity systems,
operating-system permissions, device-control grants, access-control
lists, capability registries, or authenticated custom authorization
services.
Technical contribution of this variation: Operation-specific actual-
effect finality remains independent of the particular authorization-
server protocol while maintaining a verifiable binding to the
original permission.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.7 — VARIATION B: STRUCTURED OR RICH AUTHORIZATION DETAILS
An authorization system may provide detailed descriptions of
permitted actions, recipients, amounts, resources, or transaction
attributes.
The protected controller may treat these as candidate authorization
constraints.
It does not automatically assume the structured description
corresponds to the actual downstream operation.
M-2.7.1 — Structured Grant
A permission may identify a resource, operation type, amount,
recipient, method, or other attributes.
M-2.7.2 — Protected Normalization
The fields are converted into a typed canonical effect envelope.
M-2.7.3 — Current Resource Resolution
The actual resource and recipient are resolved at the relevant
effectuation boundary.
M-2.7.4 — Operation Correspondence
The protected sink compares the actual operation against the
authorized constraints.
M-2.7.5 — Downstream Transformation
Any material change in effect semantics may require revalidation.
M-2.7.6 — Failure State
A mismatch prevents the effect.
M-2.7.7 — Non-Limiting Standard
One optional implementation may use authorization-detail structures
compatible with Rich Authorization Requests.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.12. Original Global Page 1909
Technical contribution of this variation: A structured permission is
converted into an independently enforced actual-effect predicate
rather than being treated as self-enforcing authorization.
M-2.8 — VARIATION C: TOKEN REVOCATION AND AUTHORITY DEPENDENCY
INVALIDATION
An authorization system may invalidate a credential or grant.
The protected finality architecture may associate that grant with its
dependent Candidate Acts, protected evidence, reservations, and
finality enablements.
M-2.8.1 — Revocation Input
The protected controller obtains an authenticated revocation
commitment or current inactive-status evidence.
M-2.8.2 — Dependency Resolution
The system identifies operation-specific enablements dependent upon
the revoked grant.
M-2.8.3 — Protected Generation
The authoritative revocation generation advances.
M-2.8.4 — Pending Effect Invalidation
Affected finality enablements become ineligible.
M-2.8.5 — Sink-Local Fence
The actual resource controller applies or verifies current revoked
authority.
M-2.8.6 — Actual Operation Check
The sink determines whether the pending effect depends upon the
invalidated grant.
M-2.8.7 — Controlled Refusal
Revoked authority prevents new covered effects under the actual
sink's current enforcement state.
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.8.8 — Non-Limiting Standard
An optional authorization-server interface may use an OAuth token-
revocation protocol.
Technical contribution of this variation: Revocation becomes an
invalidation dependency of actual operation-specific finality, not
merely a change in token status.
M-2.9 — VARIATION D: TOKEN INTROSPECTION, CACHE FRESHNESS, AND SINK-
SIDE AUTHORITY
5.4.3.13. Original Global Page 1910
An implementation may use a current authorization-status query.
The result may indicate whether a credential is active.
The protected controller additionally determines whether the response
is sufficiently current for the actual operation.
M-2.9.1 — Status Query
A protected resource or authority adapter requests current credential
status.
M-2.9.2 — Response Authentication
The result is authenticated under the appropriate issuer and resource
policy.
M-2.9.3 — Freshness Classification
The response is associated with a qualified age, generation, or
validity bound.
M-2.9.4 — Current Operation Risk
The required freshness may depend upon the relevant effect class.
M-2.9.5 — Generation Binding
The current source-authority and revocation generations are checked
where applicable.
M-2.9.6 — Cache Invalidation
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A relevant authority change invalidates affected cached permission
evidence.
M-2.9.7 — Missing Freshness
The sink withholds the governed effect if mandatory current validity
cannot be established.
M-2.9.8 — Non-Limiting Standard
An optional implementation may use an OAuth token-introspection
response.
Technical contribution of this variation: The current authority
requirement is bound to the real consequential operation and its
protected sink, not merely to a cached general token status.
M-2.10 — VARIATION E: SENDER-CONSTRAINED TOKEN AND PROOF-OF-
POSSESSION INPUT
An existing authorization system may bind a credential to a
cryptographic key and require the requester to demonstrate possession
of that key.
The proof may be useful to establish that the presenter is an
authorized holder under the credential protocol.
5.4.3.14. Original Global Page 1911
Such proof is not automatically treated as evidence that every
consequential operation parameter is authorized.
M-2.10.1 — Bound Credential
The credential identifies an authorized key or cryptographic
principal.
M-2.10.2 — Possession Proof
The requester provides a qualified cryptographic proof.
M-2.10.3 — Proof Verification
The protected adapter verifies the binding and applicable request-
specific fields.
M-2.10.4 — Semantic Scope
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The controller separately determines which actual operation
attributes are covered by the proof.
M-2.10.5 — Effect Descriptor
The full relevant consequential operation is represented by a
protected descriptor.
M-2.10.6 — Finality Authority
A separate operation-specific non-bearer finality enablement is
established.
M-2.10.7 — Sink Verification
The actual resource verifies the operation and current protected
consumption state.
M-2.10.8 — Non-Limiting Standard
An optional implementation may use an application-layer
demonstration-of-proof-of-possession token mechanism.
Technical contribution of this variation: Key possession becomes one
authenticated input but does not independently constitute the
separate authority to perform the actual consequential operation.
M-2.11 — VARIATION F: MUTUAL AUTHENTICATION AND CERTIFICATE-BOUND
PERMISSION
A protected service may use mutual transport authentication and
certificate-bound access credentials.
M-2.11.1 — Authenticated Client
The requesting service proves possession of an applicable client
certificate key.
M-2.11.2 — Protected Channel
5.4.3.15. Original Global Page 1912
The transport provides the selected authenticated communication
guarantees.
M-2.11.3 — Credential Binding
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The resource verifies that the relevant token or grant is associated
with the authenticated client identity.
M-2.11.4 — Operation Scope
The protected controller separately validates the consequential
operation parameters.
M-2.11.5 — Current Revocation
The sink checks the current applicable authorization state.
M-2.11.6 — Non-Bearer Finality
The actual resource operation remains dependent upon its distinct
protected finality state.
M-2.11.7 — Substitution
Mutual authentication may be replaced by another technically suitable
authenticated channel without changing the operation-specific
finality relationship.
M-2.11.8 — Non-Limiting Standard
An optional implementation may use certificate-bound OAuth
credentials and mutual TLS.
Technical contribution of this variation: A correctly authenticated
service is still unable to exceed its current independently enforced
operation-specific authority.
M-2.12 — VARIATION G: HARDWARE-PROTECTED KEYS AND CRYPTOGRAPHIC
EVIDENCE
An implementation may use protected cryptographic hardware or a
suitably isolated key manager.
The hardware may protect private keys and authenticate selected
evidence or authority records.
M-2.12.1 — Protected Key Generation
The key may be generated in a protected security component.
M-2.12.2 — Non-Exportable Key
The requesting agent may lack access to the private key material.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.12.3 — Evidence Authentication
The protected component may sign or authenticate selected collection,
validation, or generation commitments.
M-2.12.4 — Operation Binding
5.4.3.16. Original Global Page 1913
The signed structure may identify the Candidate Act and applicable
authority context.
M-2.12.5 — Current State
A separate protected controller maintains relevant revocation and
consumption conditions.
M-2.12.6 — Actual Resource Enforcement
The Finality Sink verifies the real operation and current authority
rather than accepting the signature alone.
M-2.12.7 — Hardware Independence
A software-protected alternative may be used where it supplies the
selected trust properties.
M-2.12.8 — Scope Qualification
Protected key storage does not automatically establish a rollback-
resistant monotonic counter, resource-side execution gate, or
complete policy engine.
Technical contribution of this variation: Hardware-authenticated
evidence is separated from current actual-effect authority and
becomes part of an enforced multi-state finality decision.
M-2.13 — VARIATION H: APPLICATION SANDBOX AND ENTITLEMENT INPUT
An autonomous application may operate under operating-system sandbox
restrictions and assigned resource entitlements.
M-2.13.1 — Restricted Workload
The computational requester is confined to an identified protection
boundary.
M-2.13.2 — Entitlement Evidence
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected controller obtains qualified information concerning
relevant permitted interfaces.
M-2.13.3 — Effectuation Path
The system determines how the actual consequential resource can be
reached.
M-2.13.4 — Privileged Intermediary
Any helper or service possessing broader effect authority is
identified as part of the relevant path.
M-2.13.5 — Mandatory Gate
The protected system establishes that the actual operation cannot
bypass the required finality controller within the declared coverage
domain.
M-2.13.6 — Finality Validation
The operation remains subject to current source authorization and
actual-effect matching.
5.4.3.17. Original Global Page 1914
M-2.13.7 — Configuration Change
A material entitlement or sandbox change may invalidate dependent
coverage authority.
M-2.13.8 — Non-Limiting Substrate
The sandbox may be implemented by operating-system access controls,
virtual machines, containers, process namespaces, or appropriate
hardware isolation.
Technical contribution of this variation: Process confinement and
operation-specific authority are coupled through a verified mandatory
consequential path rather than assuming that sandbox membership
proves authorization.
M-2.14 — VARIATION I: STRUCTURED APPLICATION ACTIONS AND AUTONOMOUS
TOOL INVOCATION
An application may expose structured actions to a voice assistant, AI
agent, automation service, or orchestration system.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.14.1 — Proposed Action
The agent selects a structured tool or application action.
M-2.14.2 — Candidate Act Construction
The action is represented as a proposed consequence.
M-2.14.3 — Parameter Resolution
The controller determines the relevant resource, arguments,
recipient, and other effect-defining fields.
M-2.14.4 — Non-Effective Hold
The actual effect-capable primitive remains withheld.
M-2.14.5 — Current Validation
A protected verifier checks current source authority and applicable
operation scope.
M-2.14.6 — Action Implementation
The actual resource-side implementation may transform or resolve the
requested parameters.
M-2.14.7 — Sink Reconstruction
The protected sink obtains the effective operation and verifies
correspondence with the authorized Candidate Act.
M-2.14.8 — Dynamic Tool Change
Material changes to the action contract or its effectuation path
trigger revalidation.
5.4.3.18. Original Global Page 1915
Technical contribution of this variation: A machine-readable action
declaration is prevented from becoming unrestricted execution
permission solely because the agent successfully invoked the
structured interface.
M-2.15 — VARIATION J: PRIVILEGED INTERPROCESS BROKER
A low-trust autonomous agent may communicate with a more privileged
local process through an authenticated interprocess channel.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The privileged service may be capable of accessing protected files,
resources, credentials, or devices that the agent cannot reach
directly.
M-2.15.1 — Separate Requester
The untrusted agent constructs a Candidate Act.
M-2.15.2 — Authenticated IPC
A protected channel conveys the candidate operation to a privileged
service.
M-2.15.3 — Principal Attribution
The service identifies the original requesting authority.
M-2.15.4 — Protected Operation Reconstruction
The service resolves the actual consequential primitive it would
perform.
M-2.15.5 — Current Validation
The service verifies required authority, revocation, and resource
predicates.
M-2.15.6 — Protected Consumption
The privileged service or downstream resource performs the applicable
sink-local finality transition.
M-2.15.7 — Credential Isolation
Reusable privileged credentials need not be exposed to the agent.
M-2.15.8 — Anti-Bypass
The requesting agent lacks another permitted uncontrolled route to
the governed effect under the declared coverage model.
Technical contribution of this variation: Privileged interprocess
communication becomes a mandatory, operation-specific effectuation
bridge rather than a general delegation of the helper's authority.
M-2.16 — VARIATION K: OPERATING-SYSTEM PRE-EFFECTUATION AUTHORIZATION
HOOK
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.19. Original Global Page 1916
An operating system may provide mechanisms through which a protected
component can authorize or deny selected pending events.
M-2.16.1 — Relevant Event
The protected monitor identifies a supported event corresponding to a
consequential resource operation.
M-2.16.2 — Blocking Qualification
The controller determines whether the mechanism can actually prevent
the event.
M-2.16.3 — Operation Descriptor
The event is mapped to the actual resource and effect class.
M-2.16.4 — Source Binding
The actual requesting process or principal is identified.
M-2.16.5 — Current Permission
The protected controller checks operation-specific authority and
revocation.
M-2.16.6 — Decision
The applicable authorization event is permitted or denied.
M-2.16.7 — Monitoring-Only Events
Observation events that cannot block are not misclassified as
mandatory pre-effectuation gates.
M-2.16.8 — Coverage Qualification
If an event type or relevant actual effect is not covered by the
operating-system mechanism, an alternate protected sink or resource
control must enforce the requirement.
Technical contribution of this variation: A qualified OS blocking
primitive may implement part of the finality boundary while current
operation-specific authority and enforcement coverage remain
separately verified.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.17 — VARIATION L: NETWORK EXTENSION, PROXY, AND EGRESS
ENFORCEMENT
A protected system may control external network effects through
network filters, proxies, relays, controlled sockets, or resource
gateways.
M-2.17.1 — Effect Class
The protected controller identifies a relevant network transmission
or remote API operation.
M-2.17.2 — Network Interface
5.4.3.20. Original Global Page 1917
The current egress route is identified.
M-2.17.3 — Destination Resolution
The effective network endpoint is determined according to the
relevant policy.
M-2.17.4 — Application Semantics
Where authorization depends upon message body, recipient, method,
path, or application operation, those properties are verified at a
suitable trusted semantic boundary.
M-2.17.5 — Encrypted Content
A content-blind flow filter is not presumed to know the relevant
protected plaintext.
M-2.17.6 — Protected Content Commitment
A trusted pre-encryption controller may establish a commitment
binding approved plaintext, intended recipient, and outgoing
transmission.
M-2.17.7 — Actual Egress Gate
The required effectuation path enforces current protected authority.
M-2.17.8 — Dynamic Routes
Changes to proxy, network namespace, route, or device state may
require coverage revalidation.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Technical contribution of this variation: Network-level and
application-level enforcement are linked through an operation-
specific protected effect descriptor and cannot independently be
substituted for one another where their visibility differs.
M-2.18 — VARIATION M: NOTIFICATION-ASSISTED REVOCATION
An implementation may use asynchronous notifications to signal that
protected permission state has changed.
A notification need not carry complete authoritative revocation
state.
M-2.18.1 — Revocation Commitment
The source authority commits the withdrawal of permission.
M-2.18.2 — Notification
A messaging service signals a relevant state change.
M-2.18.3 — Protected Refresh
A receiving enforcement controller obtains the current authoritative
state.
M-2.18.4 — Generation Verification
5.4.3.21. Original Global Page 1918
The receiving sink establishes current revocation generation.
M-2.18.5 — Missing Notification
The sink's current authority requirement does not depend solely upon
guaranteed delivery of the notification.
M-2.18.6 — Deferred Delivery
Delayed notification does not constitute new authorization.
M-2.18.7 — Sink-Local Fence
The actual effectuation resource must enforce the applied
invalidation.
M-2.18.8 — Alternative Transport
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The notification mechanism may be push messaging, event streaming,
polling, periodic state synchronization, or an authenticated
distribution channel.
Technical contribution of this variation: Asynchronous notification
is used as a latency optimization, while current effect authorization
remains dependent upon protected authoritative state or expressly
bounded offline validity.
M-2.19 — VARIATION N: TRANSACTIONAL AUTHORITY AND CONSUMPTION STORE
An implementation may use a transactional database or suitably
protected persistent state mechanism to maintain:
Candidate Acts;
Current source-authority generations;
Evidence commitments;
Protected reservations;
Pending finality enablements;
Current revocation generations;
Actual-operation commitments;
And consumption state.
M-2.19.1 — Protected Preparation
The controller prepares one bounded finality transition.
M-2.19.2 — Current Validation
The operation's mandatory predicates are checked.
5.4.3.22. Original Global Page 1919
M-2.19.3 — Atomic State Transition
A protected transaction consumes the applicable authority.
M-2.19.4 — Replay
A subsequent attempt observes the consumed state.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.19.5 — Crash Recovery
The authoritative store determines whether the transition committed.
M-2.19.6 — External Effects
Where the resource effect lies outside the transaction domain, the
system separately governs dispatch and outcome uncertainty.
M-2.19.7 — Hardware Alternative
Suitable protected hardware state may replace the transactional
database where it supplies the required property.
M-2.19.8 — Technical Effect
The security of an operation-specific permission is not reduced to
the secrecy of an authorization token; a protected state transition
is required at the actual effectuation boundary.
M-2.20 — VARIATION O: RECEIVER-SIDE API AND REMOTE SERVICE FINALITY
A remote resource service may implement the Finality Sink.
The upstream autonomous agent may possess a valid authorization
token, key-bound proof, and structured request permission.
Nevertheless, the receiving service independently verifies:
The actual operation parameters;
The effective resource identity;
The relevant permission scope;
Current revocation state;
Operation-specific enablement;
Resource version;
And protected consumption state.
M-2.20.1 — Actual Request
The receiving service reconstructs the operation it is about to
perform.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.23. Original Global Page 1920
M-2.20.2 — No Unrestricted Token Authority
A general API-access credential is insufficient for the selected
protected consequence.
M-2.20.3 — Finality Commit
The receiving service enforces the protected resource mutation or
external release.
M-2.20.4 — Idempotency
A receiver-side operation registry may prevent duplicate effects
under suitable transactional guarantees.
M-2.20.5 — Cross-Domain Evidence
Protected validation records may be authenticated across
administrative domains.
M-2.20.6 — Current Enforcement
The remote service must actually implement the required resource-side
gate to claim destination finality.
M-2.21 — VARIATION P: HARDWARE COMMAND AND DEVICE-SIDE FINALITY
A protected device controller may receive operation-specific
authority originating from a software agent, remote service, or
authorized application.
M-2.21.1 — Candidate Command
An agent prepares a bounded device operation.
M-2.21.2 — Source Authority
The protected controller establishes the original permitted command
scope.
M-2.21.3 — Device Identity
The actual device and current ownership are verified.
M-2.21.4 — Command Descriptor
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The relevant actual parameters and effect class are identified.
M-2.21.5 — Protected Generation
Current hardware resource or revocation generations are checked.
M-2.21.6 — Hardware Gate
The device command interface refuses unauthorized effects.
M-2.21.7 — Consumption
5.4.3.24. Original Global Page 1921
A protected operation-specific generation or usage state is consumed.
M-2.21.8 — Actual Outcome
Physical completion remains distinguished from command acceptance or
dispatch.
Technical contribution of this variation: A software authorization
mechanism does not become a complete hardware execution authorization
until verified and enforced by the actual effect-capable device
boundary.
M-2.22 — VARIATION Q: MIXED HARDWARE AND SOFTWARE ENFORCEMENT
A protected implementation may combine a software policy controller
with a hardware resource gate.
The software component may perform complex policy or semantic
validation.
The hardware component may enforce a smaller mandatory release
condition.
The protected relationship may require:
An authenticated operation digest;
A current protected authority generation;
A hardware-recognized resource identifier;
A bounded command enablement;
And protected consumption.
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The implementation may separate computation-intensive evidence
evaluation from a relatively compact protected effectuation check.
A hardware gate need not parse every high-level application policy if
its accepted release condition is securely bound to the validated
actual operation.
The system must establish that the hardware gate cannot be tricked
into applying an enablement to an unrelated command.
M-2.23 — VARIATION R: MULTI-PROTOCOL AUTHORIZATION COMPOSITION
A particular consequential operation may require evidence from
several independently functioning security mechanisms.
For example:
A principal authorization system may establish the user's delegated
permission.
A proof-of-possession mechanism may establish requester key
possession.
A protected sandbox may restrict ordinary application interfaces.
5.4.3.25. Original Global Page 1922
A current revocation service may establish source-authority status.
A network filter may restrict the egress route.
A protected resource sink may verify the actual effect.
The system may combine the corresponding evidence according to an
explicit operation-specific policy.
M-2.23.1 — Conjunctive Requirements
Several distinct properties may all be mandatory.
M-2.23.2 — Alternative Mechanisms
Two technologies may supply equivalent evidence for one specified
security predicate.
M-2.23.3 — Non-Equivalent Evidence
A proof of identity cannot substitute for current authorization.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.23.4 — Mandatory Effect Control
A monitoring-only component cannot replace a required blocking gate.
M-2.23.5 — Evidence Qualification
Each source's actual technical guarantee is represented.
M-2.23.6 — Finality Relationship
The sink determines whether all required predicates are satisfied for
the actual operation.
M-2.24 — VARIATION S: REPLACEMENT OF SECURITY SUBSTRATES WITHOUT
REAUTHORISATION EXPANSION
One authorized implementation may be replaced by another.
The protected controller may identify:
The original authorization mechanism;
Its supported evidence properties;
Its resource binding;
Its current configuration generation;
Its blocking capability;
And the corresponding replacement properties.
5.4.3.26. Original Global Page 1923
If a new component provides an equivalent qualified property, the
system may revalidate affected operations under current authority.
If the new component lacks a required property, existing dependent
finality enablements become ineligible.
The system does not presume security equivalence merely because both
components are described as authentication, sandbox, proxy, or policy
services.
M-2.24.1 — Equivalent Substitute
A functionally compatible mechanism may replace a nonessential
substrate.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.24.2 — Weaker Substitute
A monitoring-only substitute cannot silently replace mandatory
blocking enforcement.
M-2.24.3 — Changed Authorization Semantics
A different permission format requires new semantic correspondence
validation.
M-2.24.4 — Current Generation
The substitution advances or revalidates applicable protected
configuration state.
M-2.24.5 — Actual Sink
Finality remains dependent upon current effectuation coverage and
operation-specific authority.
Technical contribution of this variation: Security-substrate
replacement is treated as an authority-affecting technical transition
rather than a transparent implementation detail.
M-2.25 — VARIATION T: BOUNDED OFFLINE AUTHORIZATION
A protected resource sink may be unable to contact the originating
authorization server.
Under a strict-online mode, the corresponding operation remains
withheld.
Under a selected bounded-offline mode, the sink may exercise
previously allocated authority only within its protected limits.
Such limits may include:
A maximum number of effects;
A protected validity duration;
A specific resource or operation class;
A protected generation;
A non-replenishable local finality allowance;
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.27. Original Global Page 1924
And a requirement for revalidation before further authority is
issued.
A remote notification service is not treated as guaranteed immediate
delivery.
The system must not claim immediate global revocation if a
disconnected sink is independently allowed to continue using stale
authority.
M-2.26 — VARIATION U: DATA-RELEASE AND ENCRYPTION BOUNDARY
An autonomous application may prepare sensitive content for external
release.
The protected disclosure policy may require inspection of the actual
information.
If encryption occurs before a content-blind network controller, that
controller may be unable to verify the necessary plaintext property.
The system may therefore establish:
A protected pre-encryption evidence commitment;
An authorized recipient and release-purpose binding;
Current disclosure authority;
A protected encryption-operation reference;
A ciphertext transmission commitment where appropriate;
And independent enforcement at the actual release boundary.
The network filter may control the destination or connection.
The content-aware protected component may establish the data-release
predicate.
Neither is incorrectly represented as providing the other's security
guarantee without actual technical support.
M-2.27 — VARIATION V: MULTI-AGENT DELEGATION AND REVOCATION
A task may be delegated through several autonomous agents.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The original authorization may originate from a user, enterprise
policy, or protected resource controller.
The system may preserve:
Original source-authority identity;
Delegated operation scope;
Applicable resource and recipient constraints;
Relevant proof-of-possession or process-identity evidence;
5.4.3.28. Original Global Page 1925
Current revocation dependencies;
And finality consumption state.
A downstream agent's separate authentication does not automatically
supersede the original source-authority restrictions.
Revocation of a mandatory ancestor grant invalidates dependent
operation-specific enablement under the selected protected dependency
model.
M-2.28 — VARIATION W: ACTIONS WITH MULTIPLE CONSEQUENCES
A structured application action may appear to be one logical
operation while producing several effects.
Examples may include:
Updating a database;
Sending a notification;
Activating a payment instruction;
Changing a file;
And transmitting a remote message.
The system may identify each distinct consequential release boundary.
A principal implementation may create separate bounded Candidate Acts
or effect-specific child operations.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Each covered effect may require a distinct protected finality
predicate.
One high-level successful application-action result does not
automatically establish that all resulting consequences were
authorized or completed.
Where a successor effect requires an earlier verified real
consequence, the applicable accepted actual-effect receipt remains a
constitutive dependency.
M-2.29 — VARIATION X: UNIVERSAL PRIMITIVE-SUBSTITUTION INTERFACE
A protected implementation may expose a typed interface through which
different authorization, cryptographic, operating-system, network,
and hardware components provide qualified evidence.
A representative interface may comprise:
SECURITY_PRIMITIVE_ADAPTER = { primitive_class, evidence_type,
authorized_source_identity, supported_security_property,
5.4.3.29. Original Global Page 1926
applicable_operation_fields, current_resource_scope,
enforcement_visibility, blocking_capability, freshness_rule,
revocation_dependency, protected_configuration_generation,
evidence_authentication, qualification_result } The interface must
distinguish:
Proof of principal identity;
Proof of key possession;
Proof of current resource permission;
Proof of an attached blocking mechanism;
Proof of actual operation semantics;
Proof of revocation status;
And proof of finality consumption.
A system must not collapse these properties into one generic Boolean
called authorized.
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Where a selected actual effect requires several properties, the
Finality Sink verifies the corresponding distinct predicates.
M-2.30 — PROTECTED TECHNICAL INVARIANTS
The principal implementation may enforce the following technical
invariants.
Invariant A — Computation/Authority Separation
Generation of an operation by an autonomous model does not
independently authorize its consequence.
Invariant B — Evidence/Authority Separation
Authenticated permission evidence does not independently become
reusable complete finality authority.
Invariant C — Proof/Effect Separation
Successful identity or key-possession proof does not automatically
validate the full actual effect.
Invariant D — Semantic Correspondence
The actual resource operation must satisfy the protected authorized-
effect descriptor.
5.4.3.30. Original Global Page 1927
Invariant E — Current Authority
A previously valid authorization cannot override a mandatory current
revocation or resource-state condition.
Invariant F — Enforcement Qualification
A required blocking predicate cannot be satisfied solely through
observation-only security instrumentation.
Invariant G — Non-Bearer Enablement
Possession of an opaque or signed authority artifact is insufficient
without the required protected sink state.
Invariant H — Monotonic Consumption
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An operation-specific use cannot be duplicated by copying or
restoring earlier requester state.
Invariant I — Topology Continuity
A material enforcement-path change invalidates or revalidates
affected finality dependencies.
Invariant J — Outcome Integrity
The system distinguishes authority consumption, dispatch, resource
commit, and external actual-effect completion.
These invariants may be implemented through distinct mechanisms
according to the selected operation class.
M-2.31 — PRINCIPAL FULLY INTEGRATED WORKFLOW
A representative integrated implementation performs the following
sequence.
Step 1 — Receive Operation Proposal. An autonomous entity proposes a
consequential action.
Step 2 — Construct Candidate Act. The operation is identified as a
protected proposed consequence.
Step 3 — Hold Non-Effective. The actual resource effect is withheld.
Step 4 — Resolve Authorization Sources. The system identifies
applicable grants, credentials, permissions, and delegated authority.
Step 5 — Collect Qualified Evidence. A protected collector obtains
the relevant authenticated evidence.
Step 6 — Translate Effect Scope. The authorization evidence is
mapped into a protected actual-effect envelope.
Step 7 — Verify Key and Requester Relations. Applicable
cryptographic holder or client-authentication properties are
evaluated.
5.4.3.31. Original Global Page 1928
Step 8 — Resolve Current Revocation Dependencies. The protected
authority controller identifies the relevant source and delegated
grants.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 9 — Verify Current Revocation State. A qualified current
generation or status is established.
Step 10 — Qualify Enforcement Coverage. The system determines
whether the actual consequence is subject to mandatory blocking
enforcement.
Step 11 — Resolve Current Resource State. The resource, identity,
version, ownership, and policy generation are established.
Step 12 — Independently Validate. A protected execution-time
instance verifies the necessary current conditions.
Step 13 — Cross-Commit Evidence. The accepted collection and
validation records are bound to the same Candidate Act.
Step 14 — Prepare Non-Bearer Enablement. A protected controller
establishes scoped effectuation authority.
Step 15 — Bind the Designated Sink. The corresponding actual
effectuation boundary is identified.
Step 16 — Monitor Material Changes. Revocation, tool, policy,
topology, and resource changes invalidate affected enablement.
Step 17 — Present Actual Operation. The requester submits the
consequential operation.
Step 18 — Reconstruct Actual Effect. The Finality Sink obtains the
actual current operation descriptor.
Step 19 — Compare Authority and Effect. The sink verifies
correspondence with the authorized effect envelope.
Step 20 — Verify Current Revocation. The sink checks the applicable
protected authority generation and freshness.
Step 21 — Verify Enforcement Coverage. The required mandatory
effectuation path remains qualified.
Step 22 — Verify Current Enablement. The protected non-bearer
authority remains valid for that sink and resource.
Step 23 — Verify Monotonic State. The sink determines whether
permitted use remains.
Step 24 — Consume Authority. The applicable protected state
transition is committed.
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 25 — Release the Consequence. The sink permits only the
verified actual operation.
Step 26 — Preserve Attempt State. A protected journal records the
effect attempt where applicable.
Step 27 — Reconcile Actual Outcome. Confirmed, rejected, partial,
and uncertain effects are distinguished.
5.4.3.32. Original Global Page 1929
Step 28 — Require New Authority for Material Change. A different
effect requires new or suitably revalidated authorization.
M-2.32 — REFERENCE PSEUDOCODE: SECURITY-PRIMITIVE QUALIFICATION
FUNCTION QUALIFY_SECURITY_PRIMITIVE( primitive_input, candidate_act,
protected_qualifier ):
REQUIRE VERIFY_PRIMITIVE_SOURCE( primitive_input )
REQUIRE VERIFY_PRIMITIVE_EVIDENCE( primitive_input )
property = protected_qualifier .DETERMINE_ACTUAL_SECURITY_PROPERTY(
primitive_input )
scope = protected_qualifier .RESOLVE_SUPPORTED_OPERATION_SCOPE(
primitive_input )
coverage = protected_qualifier .RESOLVE_ENFORCEMENT_CAPABILITY(
primitive_input )
IF property == UNKNOWN: RETURN UNQUALIFIED
RETURN protected_qualifier .AUTHENTICATE_QUALIFICATION({ property:
property,
operation_scope: scope,
enforcement_coverage: coverage,
candidate: HASH(candidate_act),
5.4.3.33. Original Global Page 1930
configuration_generation: CURRENT_CONFIGURATION_GENERATION() }) The
function does not assume that a valid primitive supplies all security
properties required by the Candidate Act.
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.33 — REFERENCE PSEUDOCODE: AUTHORIZATION-TO-EFFECT TRANSLATION
FUNCTION CONSTITUTE_EFFECT_ENVELOPE( candidate_act,
qualified_authorization_evidence, protected_translation_controller ):
proposed = RESOLVE_CANDIDATE_OPERATION( candidate_act )
granted = protected_translation_controller
.EXTRACT_VERIFIED_PERMISSION_SCOPE( qualified_authorization_evidence
)
actual_contract = protected_translation_controller
.RESOLVE_EFFECT_CONTRACT( proposed )
IF NOT SUFFICIENT_EFFECT_SEMANTICS( actual_contract ): RETURN HOLD
envelope = INTERSECT_AUTHORIZED_EFFECT_CONSTRAINTS( proposed,
granted, actual_contract )
IF envelope IS EMPTY: RETURN DENY
RETURN protected_translation_controller
.AUTHENTICATE_EFFECT_ENVELOPE({ candidate: HASH(candidate_act),
source_authority: HASH(qualified_authorization_evidence),
5.4.3.34. Original Global Page 1931
authorized_effect: HASH_CANONICAL(envelope),
current_contract: HASH(actual_contract),
current_policy: CURRENT_POLICY_EPOCH() }) The intersection
establishes a bounded effect envelope; it must not expand the
original permission.
M-2.34 — REFERENCE PSEUDOCODE: REVOCATION-BOUND FINALITY CONSTITUTION
FUNCTION PREPARE_INTEROPERABLE_FINALITY( candidate_act,
collection_evidence, validation_evidence, effect_envelope,
protected_finality_controller ):
REQUIRE VERIFY_COLLECTION_EVIDENCE( collection_evidence )
REQUIRE VERIFY_INDEPENDENT_VALIDATION( validation_evidence )
REQUIRE VERIFY_COMMON_CANDIDATE_BINDING( candidate_act,
collection_evidence, validation_evidence )
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
REQUIRE VERIFY_AUTHORIZED_EFFECT_ENVELOPE( effect_envelope )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY()
REQUIRE VERIFY_CURRENT_REVOCATION_DEPENDENCIES()
REQUIRE VERIFY_CURRENT_MANDATORY_EFFECT_COVERAGE()
enablement = protected_finality_controller
.ATOMIC_PREPARE_OPERATION_AUTHORITY({ candidate: HASH(candidate_act),
5.4.3.35. Original Global Page 1932
evidence: HASH(collection_evidence, validation_evidence),
effect_envelope: HASH(effect_envelope),
revocation_generation: CURRENT_REVOCATION_GENERATION(),
coverage_generation: CURRENT_ENFORCEMENT_GENERATION(),
designated_sink: CURRENT_FINALITY_SINK(),
permitted_use_count: AUTHORIZED_USE_LIMIT() })
RETURN INERT_REFERENCE(enablement) The requesting agent does not
automatically receive a reusable complete resource authority.
M-2.35 — REFERENCE PSEUDOCODE: ACTUAL SINK VERIFICATION
FUNCTION EFFECTUATE_USING_EXISTING_SECURITY_SUBSTRATES(
candidate_act, enablement_reference, protected_finality_sink ):
actual_operation = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_resource = protected_finality_sink .RESOLVE_ACTUAL_RESOURCE()
REQUIRE actual_operation IS VALID
REQUIRE VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY( actual_operation )
REQUIRE VERIFY_CURRENT_REVOCATION_STATE(
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.36. Original Global Page 1933
actual_operation )
REQUIRE VERIFY_CURRENT_OPERATION_PARAMETERS( actual_operation )
REQUIRE VERIFY_CURRENT_MANDATORY_ENFORCEMENT_COVERAGE(
actual_operation )
REQUIRE VERIFY_VALID_NON_BEARER_ENABLEMENT( enablement_reference,
actual_operation, actual_resource )
REQUIRE VERIFY_CURRENT_RESOURCE_STATE()
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
consumption = protected_finality_sink .ATOMIC_CONSUME_ENABLEMENT(
enablement_reference, actual_operation )
IF consumption != COMMITTED: RETURN DENY
RETURN protected_finality_sink .EFFECTUATE_ACTUAL_OPERATION(
actual_operation ) The actual resource must be controlled by the
selected Finality Sink or a technically sufficient downstream
enforcement interface.
M-2.36 — REFERENCE PSEUDOCODE: REVOCATION PROPAGATION AND LOCAL FENCE
FUNCTION APPLY_AUTHORITY_REVOCATION( revocation_commitment,
protected_sink_controller ):
REQUIRE VERIFY_AUTHENTIC_REVOCATION( revocation_commitment )
REQUIRE VERIFY_REVOKER_SCOPE()
5.4.3.37. Original Global Page 1934
current = protected_sink_controller .LOAD_CURRENT_AUTHORITY_STATE()
REQUIRE VERIFY_GENERATION_CONTINUITY( current, revocation_commitment
)
affected = RESOLVE_DEPENDENT_FINALITY_ENABLEMENTS(
revocation_commitment )
applied = protected_sink_controller
.ATOMIC_ADVANCE_REVOCATION_AND_FENCE({ affected_authority: affected,
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
new_generation: revocation_commitment.generation,
current_state: current })
IF applied != COMMITTED: RETURN ENFORCEMENT_NOT_CONFIRMED
RETURN PROTECTED_SINK_ENFORCEMENT_RECEIPT( applied ) A message-
delivery acknowledgement alone does not replace the protected sink-
application result.
M-2.37 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS API ACTION
A user permits an autonomous application to perform one bounded
cloud-service operation.
An existing authorization server issues resource permission.
A sender-constrained credential proves the requesting application's
possession of a corresponding key.
A structured action interface identifies the intended operation.
A protected adapter obtains the original permission and constructs a
Candidate Act.
The first protected instance commits the relevant collection-time
evidence.
A second independently protected instance validates current
authority, effect semantics, resource scope, and revocation state.
The resulting evidence is cross-committed to the operation.
5.4.3.38. Original Global Page 1935
A protected controller prepares non-bearer finality enablement.
At the actual remote service, the Finality Sink reconstructs the
pending operation.
If the requested amount, target, resource, or operation method
differs materially from the authorized effect, the sink refuses the
consequence.
If the source grant has been revoked, the sink refuses the
consequence.
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
If the permission remains valid but the finality enablement was
already consumed, the sink refuses the duplicate effect.
The system does not depend upon the particular token format for these
finality conditions.
Expected demonstrable result: Valid identity, valid token, and valid
proof-of-possession may coexist with a correctly denied unauthorized
actual operation.
M-2.38 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS DESKTOP TOOL
A desktop autonomous assistant invokes a structured application
action.
The assistant operates under restricted process privileges.
The requested effect requires a privileged local service.
The assistant provides a Candidate Act to the protected service
through an authenticated interprocess interface.
The privileged service determines the actual file, resource, or
device operation.
The service verifies current source authority and protected
validation evidence.
An operating-system authorization mechanism or protected resource
controller enforces the applicable blocking condition.
A logging-only event monitor may supply evidence but cannot replace
the required blocking gate.
The privileged service consumes operation-specific non-bearer
authority before the actual effect.
Expected demonstrable result: A compromised assistant cannot
automatically exercise every effect available to the privileged
helper merely by possessing a valid IPC channel or structured tool
identifier.
M-2.39 — CONCRETE PHOSITA EXAMPLE: REVOCATION NOTIFICATION DELAY
An authorization server revokes an agent's protected grant.
A notification service signals the change to the local application.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The notification may be delayed.
5.4.3.39. Original Global Page 1936
The actual resource sink does not treat the absence of a notification
as proof that the grant remains valid indefinitely.
It applies the selected current-state or bounded-freshness rule.
A previously valid operation presented after the required revocation
state becomes applicable is refused.
Expected demonstrable result: Correctness of current finality
authorization does not depend solely upon successful asynchronous
push delivery.
M-2.40 — CONCRETE PHOSITA EXAMPLE: ENCRYPTED NETWORK EGRESS
An autonomous assistant prepares protected information for
transmission.
A network filter sees the destination and encrypted transport flow.
A protected application-level release controller examines the actual
plaintext before encryption.
A cross-commitment binds the authorized plaintext information,
recipient, and outgoing operation.
The actual release sink verifies current authority and consumes the
specified finality enablement.
The network controller enforces the covered transmission route.
The architecture does not pretend that the network filter can infer
unobserved plaintext semantics.
Expected demonstrable result: Content-dependent authorization remains
enforceable through an appropriate protected plaintext boundary even
where the network-flow control itself lacks plaintext visibility.
M-2.41 — CONCRETE PHOSITA EXAMPLE: SUBSTRATE REPLACEMENT
A protected system originally uses an application gateway that blocks
selected resource effects.
The gateway is replaced by a component that produces only event
notifications.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The new component is correctly authenticated.
It may provide valid monitoring information.
However, it lacks mandatory blocking capability for the relevant
effect.
The protected enforcement qualification changes.
Previously prepared finality enablements depending upon the old
blocking mechanism become ineligible.
A new qualified gate must be established before affected consequences
resume.
Expected demonstrable result: A valid security-service replacement
does not silently preserve execution authority when the replacement
supplies a weaker required enforcement property.
5.4.3.40. Original Global Page 1937
M-2.42 — NON-LIMITING ADVERSARIAL TEST PROTOCOL
The following tests are proposed rather than reported completed
results.
Test 1 — Active Token, Unauthorized Effect: Present an active
credential for an actual operation beyond the original permitted
scope.
Test 2 — Valid Key Proof, Changed Operation: Prove possession of the
correct bound key but change the protected resource or effect
parameters.
Test 3 — Detailed Authorization, Different Recipient: Present a valid
structured permission while redirecting the actual operation to
another recipient.
Test 4 — Revoked Token, Historical Approval: Attempt a pending effect
using an authentic earlier approval after revocation.
Test 5 — Stale Introspection Response: Reuse an earlier active-status
response outside its qualified freshness state.
Test 6 — Notification Dropped: Suppress delivery of the asynchronous
revocation notification and verify the actual sink's defined
freshness or bounded-offline rule.
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 7 — Notification Delivered, Fence Missing: Verify that receipt
of a notification is not incorrectly classified as completed sink
enforcement.
Test 8 — Signed Evidence Without Authority: Present a valid
cryptographic evidence record without a current non-bearer finality
enablement.
Test 9 — Copied Enablement Reference: Attempt a duplicate effect with
the same opaque reference.
Test 10 — Sandboxed Agent, Privileged Helper: Verify that the helper
independently checks the actual operation rather than relying on the
agent's sandbox membership.
Test 11 — Monitoring-Only Security Hook: Demonstrate that an audit
event cannot satisfy a mandatory blocking predicate.
Test 12 — Blocking Security Hook: Verify actual refusal of an
unauthorized supported operating-system operation.
Test 13 — Alternate Resource Path: Attempt the effect through another
API, socket, storage interface, or privileged worker.
Test 14 — Encrypted Egress: Demonstrate whether the protected
architecture verifies required plaintext semantics at a suitable
boundary.
Test 15 — Tool Contract Change: Replace a structured action
implementation with one producing additional side effects.
Test 16 — Resource Alias: Redirect a permitted logical resource name
to another actual object.
Test 17 — Different Authentication Primitive: Replace proof-of-
possession with mutual authentication while preserving the
independently enforced finality properties.
5.4.3.41. Original Global Page 1938
Test 18 — Hardware Key Versus Software Key: Compare supported key-
protection properties without attributing unrelated resource-
enforcement guarantees.
Test 19 — Privileged Service Replacement: Change the broker
implementation and verify current enforcement qualification.
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 20 — Network Path Mutation: Introduce an alternative connection
route and require coverage reassessment.
Test 21 — Local Atomic Consumption: Ensure that only the authorized
number of protected finality transitions commit.
Test 22 — Crash After Consumption: Restore a requester snapshot and
verify the consumed authority remains unusable.
Test 23 — Cross-Domain Revocation: Propagate a protected authority
change to a remote sink and verify actual fence application.
Test 24 — Missing Remote Receipt: Distinguish propagation attempted
from enforcement confirmed.
Test 25 — Bounded Offline Authority: Enforce the selected local
effect count or lease bound during disconnection.
Test 26 — Device Ownership Change: Reject a command under a stale
hardware authority generation.
Test 27 — Current Resource Version: Change the protected resource
after upstream validation.
Test 28 — Multi-Agent Delegation: Revoke a parent grant and identify
dependent downstream finality enablements.
Test 29 — Partial Multi-Effect Action: Verify separate finality
treatment of distinct real consequences produced by one structured
action.
Test 30 — Alternate Authorization Server: Replace one permission
system with a functionally compatible source while retaining current
actual-effect enforcement.
Test 31 — Token Mechanism Removed: Use an authenticated non-token
permission source and verify that the finality architecture remains
implementable.
Test 32 — Notification Mechanism Removed: Use online current-state
verification without asynchronous push notifications.
Test 33 — Hardware Key Mechanism Removed: Use a suitable software-
protected authentication mechanism within a stated weaker trust
model.
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 34 — Effectuation Gate Removed: Demonstrate that losing the
mandatory blocking boundary defeats the claimed effect prevention,
establishing the technical necessity of the gate.
Test 35 — Sink Reconstruction Removed: Demonstrate that a previously
valid approval can be misapplied to a changed actual operation when
current correspondence is not checked.
5.4.3.42. Original Global Page 1939
Test 36 — Revocation Generation Removed: Demonstrate that old
authority may remain apparently usable after protected revocation
when current generation binding is absent.
Test 37 — Monotonic Consumption Removed: Demonstrate how repeated
requests may exercise the same logical authority where no
authoritative consumption condition exists.
Test 38 — Full Combination: Demonstrate the complete operation-
specific protected authority chain across several compatible existing
security substrates.
Each test should use a controlled resource and observable effect
boundary.
The reported outcome should distinguish actual completed tests from
expected demonstrable behavior.
M-2.43 — TECHNICAL CAUSALITY AND CONTRIBUTION OF THE COMBINATION
The technical character of a combination should not rest solely upon
the fact that multiple known security mechanisms are present.
The disclosed principal architecture creates an enforceable
dependency among components that would otherwise provide separate and
potentially insufficient guarantees.
M-2.43.1 — First Technical Dependency
The output of an authorization system is converted into a bounded
actual-effect envelope rather than being accepted as complete
finality authority.
M-2.43.2 — Second Technical Dependency
A proof of client identity or key possession is independently
classified as evidence of that property without being
mischaracterized as proof of the entire consequential operation.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.43.3 — Third Technical Dependency
The protected system establishes current authority and revocation
state for the original grant and its required descendants.
M-2.43.4 — Fourth Technical Dependency
The actual effectuation interface is qualified for mandatory blocking
enforcement.
M-2.43.5 — Fifth Technical Dependency
The Finality Sink reconstructs the operation actually presented to
the resource.
M-2.43.6 — Sixth Technical Dependency
The actual operation must match the protected authorized-effect
envelope and current source authority.
M-2.43.7 — Seventh Technical Dependency
5.4.3.43. Original Global Page 1940
Separate protected non-bearer finality enablement is consumed under
authoritative sink-local state.
M-2.43.8 — Resulting Technical Property
Where the selected trust and enforcement assumptions are satisfied, a
valid upstream permission, token, cryptographic proof, sandbox
entitlement, monitoring record, or notification does not
independently authorize an unauthorized or replayed consequential
effect.
This property arises from the enforced relationships among the
stages, rather than from the mere simultaneous presence of their
underlying primitives.
M-2.44 — TECHNICAL ABLATION AND COUNTERFACTUAL ANALYSIS
The following comparative investigations may be performed to identify
the contribution of the selected combination.
M-2.44.1 — Permission Verification Without Actual-Effect
Reconstruction
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An implementation verifies authorization but does not reconstruct the
real operation at the resource boundary.
A controlled substitution test examines whether a changed target or
parameter may escape the earlier approval.
M-2.44.2 — Actual-Effect Reconstruction Without Current Revocation
An implementation verifies the operation but relies upon stale source
authority.
A controlled revocation test examines whether a previously approved
effect may still occur.
M-2.44.3 — Cryptographic Binding Without Consumption
An implementation authenticates the operation but does not enforce an
authoritative operation-specific use count.
A controlled replay test examines duplicate effectuation.
M-2.44.4 — Sandbox Without Privileged-Broker Finality
An application is restricted while a privileged helper accepts broad
commands.
A controlled operation tests whether the assistant can indirectly
cause an unauthorized effect.
M-2.44.5 — Monitoring Without Blocking
An event monitor observes unauthorized effects but does not prevent
them.
A controlled resource test establishes the distinction between
detection and pre-effectuation denial.
M-2.44.6 — Notification Without Authority Freshness
A system uses asynchronous revocation notification as its only
invalidation mechanism.
5.4.3.44. Original Global Page 1941
A dropped-message test examines whether the resource can continue
accepting stale permission.
M-2.44.7 — Complete Protected Combination
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The corresponding system enforces current source authority, actual
operation binding, qualified blocking, and protected consumption at
the resource.
The controlled tests compare actual consequences under the same
operation, resource, and attacker assumptions.
M-2.44.8 — Interpretation
A difference in observed behavior may support a specific technical-
effect argument.
The tests do not, by themselves, prove that the mechanism is legally
novel or non-obvious.
M-2.45 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
M-2.45.1 — Avoiding a Mere Aggregation of Known Primitives
The invention should not be characterized simply as:
“An AI security system comprising OAuth, sandboxing, cryptography,
notifications, and a network filter.”
Such a formulation presents independent known mechanisms without
establishing a necessary technical interaction.
The present disclosure instead identifies a protected ordered
authority transition in which each selected mechanism contributes a
specifically qualified property to a common effectuation decision.
M-2.45.2 — Candidate Objective Technical Problem
How to prevent a heterogeneous authorization or security subsystem
from being treated as sufficient permission for an actual autonomous
consequential effect when the subsystem proves only a partial
security property, especially after operation transformation,
resource change, revocation, execution-path modification, or
authority replay.
M-2.45.3 — Candidate Technical Solution
A protected translation and validation arrangement converts qualified
outputs of heterogeneous existing security mechanisms into operation-
specific evidence and effect constraints.
Current source-authority and revocation dependencies are verified.
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Mandatory blocking enforcement is established at the corresponding
resource boundary.
Separate non-bearer finality enablement is constituted.
The actual Finality Sink reconstructs the operation presented for
effectuation and verifies the current constraints before protected
consumption and release.
M-2.45.4 — Why Mere Juxtaposition Is Insufficient
5.4.3.45. Original Global Page 1942
An authorization token may establish permission but not the precise
current actual effect.
A cryptographic proof may establish key possession but not full
operation legitimacy.
A sandbox may restrict a process but not necessarily control every
privileged intermediary.
A network monitor may observe traffic without the information
necessary for semantic authorization.
A notification may signal revocation without establishing its
enforcement.
A cryptographic signature may authenticate an approval but not
establish remaining consumable authority.
The proposed stronger system does not merely place these mechanisms
side by side.
It assigns distinct evidentiary and enforcement roles and makes their
qualified outputs necessary, but individually insufficient, inputs to
one current protected actual-effect transition.
M-2.45.5 — Technical Interdependence
The authorization adapter produces qualified original authority
evidence.
The effect translator determines the permitted consequential
envelope.
The protected validator checks current operation and authority
correspondence.
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The revocation controller invalidates affected pending finality
dependencies.
The enforcement qualifier establishes that the actual resource path
is controllable.
The finality controller prepares operation-specific non-bearer
authority.
The actual sink reconstructs the pending real operation.
The consumption controller prevents unsupported duplicate release.
A selected failure of a required dependency prevents the
corresponding protected effect.
M-2.45.6 — Prior-Art Combination Analysis
A proper comparison should ask whether an earlier system discloses
not merely individual permission and security controls, but the
specific protected relationships recited by the selected claim.
Where an earlier system already discloses the same dependencies and
actual sink behavior, the claim must be correspondingly narrowed or
differentiated through genuinely supported technical limitations.
M-2.45.7 — Hindsight Reconstruction Concern
A technical analysis should avoid treating knowledge of the proposed
architecture as the reason that a skilled person would have selected
and arranged the underlying primitives.
5.4.3.46. Original Global Page 1943
Instead, an inventive-step evaluation may examine:
The objective technical problem recognized by the relevant prior
system;
Which actual effectuation or revocation failures the earlier system
addressed;
Which component possessed the necessary resource-side information;
Whether the earlier system required independent actual-operation
reconstruction;
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Whether a separate finality enablement and protected consumption
transition were provided;
And whether the cited references disclose an express or technically
supported reason to make those particular dependencies mandatory.
The absence of an identical statement in one reference is not, by
itself, sufficient to establish inventive step.
M-2.45.8 — Interoperability Difficulty
The underlying primitives may use different operation identifiers,
permission semantics, freshness models, effectuation boundaries, and
protected-state assumptions.
The claimed technical integration addresses these incompatibilities
by requiring a typed and protected effect descriptor, qualified
evidence properties, current authority generations, and sink-local
finality state.
M-2.45.9 — Non-Equivalent Substitution
Replacing one security primitive with another that provides weaker
actual-operation visibility or blocking capability may invalidate
current consequential authority.
A generic interchangeable-security-component architecture does not
necessarily provide this protected coverage invalidation behavior.
M-2.45.10 — Specificity of Technical Effect
Any inventive-step argument should identify demonstrable technical
behavior, including refusal of unauthorized transformed effects,
rejection of stale revoked authority, prevention of duplicate
finality consumption, or failure-closed handling of missing
enforcement.
Such behavior should be tied to corresponding claim limitations.
M-2.46 — CANDIDATE DISTINCTIVE TECHNICAL KERNELS
M-2.46.1 — Kernel A: Heterogeneous Authorization-to-Actual-Effect
Binding
A protected adapter converts one or more authorization-system results
into a bounded operation-specific effect envelope, and the actual
Finality Sink reconstructs and verifies the pending consequential
operation against that envelope.
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
M-2.46.2 — Kernel B: Revocation-Dependent Non-Bearer Authority
5.4.3.47. Original Global Page 1944
Current revocation state of a source grant and its required delegated
dependencies is a mandatory condition of a separate protected
finality enablement verified and consumed at the actual sink.
M-2.46.3 — Kernel C: Proof-of-Possession Without Automatic Finality
A successful cryptographic proof identifies an authorized credential
presenter while actual consequential authority remains dependent upon
independent effect validation and protected consumption.
M-2.46.4 — Kernel D: Mandatory Enforcement Qualification
A protected controller classifies existing application, OS, network,
and hardware security mechanisms according to their actual blocking
capability and refuses effectuation when a required enforcement path
is not qualified.
M-2.46.5 — Kernel E: Notification-Independent Revocation Safety
A protected resource uses qualified current authority generations or
bounded offline validity rather than relying solely on asynchronous
revocation notification.
M-2.46.6 — Kernel F: Privileged Service Finality
An untrusted autonomous agent cannot convert an authenticated IPC
request into unrestricted exercise of a privileged service's
underlying credentials or device authority.
M-2.46.7 — Kernel G: Security-Substrate Replacement Invalidation
A material change to the semantic or blocking guarantee supplied by
an authorization or security component invalidates dependent
operation-specific finality authority until revalidation.
M-2.46.8 — Kernel H: Cross-Domain Effect Evidence and Resource
Consumption
Authenticated authorization evidence from one domain is independently
verified and transformed into finality eligibility consumed at a
different protected resource domain.
M-2.46.9 — Kernel I: Plaintext-Aware Release with Network Enforcement
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected pre-encryption content commitment and recipient binding
are verified in conjunction with a controlled egress route, without
requiring the network-flow mechanism itself to understand plaintext.
M-2.46.10 — Kernel J: Crash-Consistent Finality Continuity
Actual-effect authority consumption and dispatch intent remain
protected across failures, independently of whether an external
receiver provides an immediate completion acknowledgement.
These kernels may support different claim families or dependent
limitations.
Their combination should preserve a single identifiable technical
relationship where required by the selected claim.
5.4.3.48. Original Global Page 1945
M-2.47 — POTENTIAL INDEPENDENT CLAIM ARCHITECTURES
M-2.47.1 — Candidate Independent Claim A: Interoperable Execution-
Finality System
A system comprising:
A protected adapter configured to obtain authenticated evidence from
at least one authorization or security mechanism;
A protected effect-translation controller configured to derive an
operation-specific permitted effect envelope from the evidence;
A protected validation controller configured to verify current
authority and applicable operation conditions;
A finality-authority controller configured to establish separate
scoped non-bearer effectuation enablement;
And an independently enforcing Finality Sink configured to
reconstruct the actual pending operation, verify correspondence with
the permitted effect envelope and current authority state, and
consume the enablement before permitting the consequential effect.
M-2.47.2 — Candidate Independent Claim B: Revocation-Coupled Method
A method comprising:
Receiving a Candidate Act;
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Resolving its original authorization and downstream dependencies;
Authenticating a current revocation or authority-generation state;
Invalidating operation-specific enablement affected by the current
revocation state;
And refusing the actual resource effect at a mandatory Finality Sink
when a required source authority has been withdrawn.
M-2.47.3 — Candidate Independent Claim C: Protected Enforcement-
Qualification Apparatus
An apparatus comprising:
An interface for obtaining qualified security-mechanism capability
evidence;
A controller configured to distinguish observation-only and blocking
enforcement;
A current effectuation-path dependency state;
And an actual effectuation gate configured to invalidate or refuse
operation-specific finality when a required blocking condition
becomes unavailable.
M-2.47.4 — Candidate Independent Claim D: Privileged Agent-Broker
Finality
5.4.3.49. Original Global Page 1946
A protected service configured to receive a proposed operation from a
lower-trust autonomous requester, independently resolve the actual
resource-side operation, verify current source-derived authority and
protected non-bearer finality state, and exercise the privileged
resource only upon satisfaction of the corresponding sink-local
consumption condition.
M-2.47.5 — Candidate Independent Claim E: Hardware-Assisted Finality
A protected apparatus comprising a hardware-supported authority-
verification function, current resource or revocation state, and an
effect-capable command gate configured to refuse actual commands
without a matching operation-specific finality enablement.
M-2.47.6 — Candidate Independent Claim F: Cross-Domain Implementation
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A system comprising an originating authorization domain, a protected
evidence and operation-translation component, a separately controlled
destination Finality Sink, and authenticated current authority and
actual-effect binding enforced by the destination before
consequential execution.
M-2.47.7 — Claim Drafting Consideration
The broadest candidate should capture a demonstrable common technical
interaction rather than require every optional standards adapter.
Dependent claims may introduce specific cryptographic, OS, network,
IPC, notification, and hardware implementations.
Where a narrower variation independently supports a distinct
technical effect, a separate claim family may be considered.
M-2.48 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The authorization evidence is obtained from an OAuth-compatible
authorization server.
2. The authorization evidence comprises structured operation-
specific permission details.
3. A protected effect translator maps structured permission details
to an actual resource effect envelope.
4. The actual resource verifies correspondence between the requested
operation and the permission envelope.
5. A token-revocation result invalidates affected pending finality
enablement.
6. A current token-status or introspection result is associated with
an authenticated authority generation.
7. Authorization-status caching is subject to protected freshness
requirements.
8. A stale active-status result cannot override a current revoked
source grant.
9. A sender-constrained credential provides qualified proof-of-
possession evidence.
10. Proof-of-possession is evaluated separately from actual
operation authorization.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.50. Original Global Page 1947
11. A certificate-bound credential provides authenticated requester
binding.
12. A mutually authenticated communication channel transports
qualified authority evidence.
13. A protected cryptographic key manager authenticates operation-
related evidence.
14. Protected key material is unavailable to the untrusted requester
where selected.
15. Key-possession evidence does not independently confer
unrestricted finality authority.
16. An operating-system sandbox constrains the requesting workload.
17. Entitlement or permission evidence is included in effectuation-
path qualification.
18. An alternate privileged intermediary is classified as a separate
effect-capable path.
19. A structured application action is represented as a Candidate
Act.
20. Tool or application-action parameters are resolved into a
protected actual-effect descriptor.
21. A material action-contract change invalidates dependent
authority.
22. An authenticated interprocess service receives a Candidate Act
from a lower-trust process.
23. The privileged service verifies original source-derived
operation authority.
24. The privileged service prevents release of reusable complete
resource credentials to the requester.
25. An operating-system event authorization hook serves as a
mandatory enforcement component for supported operations.
26. Observation-only hooks cannot satisfy a required blocking
predicate.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
27. A protected network filter constrains the corresponding
effectuation route.
28. An application-level gateway verifies content semantics
unavailable to a lower-level network-flow monitor.
29. A protected pre-encryption commitment binds authorized plaintext
to a specified recipient or transmission.
30. A network routing or proxy change triggers finality-path
revalidation.
31. An asynchronous notification signals a revocation-state change.
32. The system does not rely upon guaranteed delivery of the
notification to establish current finality safety.
33. A protected sink queries authoritative current revocation state
before a specified consequential effect.
34. A protected offline lease bounds the permissible use of stale
authorization evidence.
35. Revocation-dependent authority is associated with a monotonic
protected generation.
5.4.3.51. Original Global Page 1948
36. A revocation of a mandatory parent grant invalidates dependent
delegated finality authority.
37. An unaffected independent authorization remains eligible where
the applicable policy permits it.
38. A protected finality controller cross-commits collection-time
and independently validated execution-time evidence.
39. The finality enablement is bound to one authorized Candidate
Act.
40. The enablement is bound to a designated Finality Sink.
41. The actual Finality Sink reconstructs the pending operation
independently of the requester's prior self-description.
42. The sink verifies current resource identity.
43. The sink verifies current revocation or authorization state.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
44. The sink verifies current mandatory effectuation-path coverage.
45. The sink verifies a protected current policy or configuration
generation.
46. The sink verifies current resource version or ownership where
required.
47. A copied opaque enablement reference remains insufficient for
effectuation.
48. A protected consumption state prevents unauthorized repeated
exercise.
49. A transactional resource controller atomically commits local
effect and corresponding finality consumption where supported.
50. A remote operation preserves durable consumption and dispatch-
intent state.
51. An uncertain external outcome does not automatically restore
consumed authority.
52. A hardware command gate verifies current device-bound finality.
53. A direct accelerator-originated effect is treated as a separate
controlled effectuation path where required.
54. Material hardware resource reassignment invalidates dependent
authority generations.
55. A security-substrate replacement triggers requalification of its
supplied enforcement property.
56. A weaker monitoring-only replacement does not inherit earlier
blocking coverage.
57. A notification-delivery acknowledgement is distinguished from
proof of sink-side revocation application.
58. A protected enforcement receipt identifies the actual sink and
committed invalidation state.
59. The system uses a typed interface identifying the technical
security property supplied by each underlying mechanism.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.4.3.52. Original Global Page 1949
60. A successful identity proof cannot substitute for a required
effect-semantics proof.
61. A successful token-validity check cannot substitute for
protected finality consumption.
62. A valid earlier approval cannot override a later mandatory
revocation.
63. A multi-effect structured action is decomposed into separately
governed actual consequences where selected.
64. A dependent successor operation requires an accepted earlier
real-effect receipt where the applicable causal protocol requires it.
65. The disclosed finality relation is implemented without
dependence upon any particular authorization protocol or device
manufacturer.
M-2.49 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND SUBSTITUTE-
IMPLEMENTATION CLAUSE
The individual implementation mechanisms described in this
Miscellaneous Embodiment M-2 may be used alone where they constitute
a technically complete selected invention, or in any technically
compatible subcombination or combined architecture.
An implementation may combine structured authorization details with
protected current revocation and actual-operation finality.
Another may combine proof-of-possession authentication with a
protected broker and sink-local finality consumption.
Another may combine a hardware-protected cryptographic key with
operation-specific finality and protected resource-state
verification.
Another may combine sandbox confinement, entitlement checks, and
mandatory operating-system resource authorization.
Another may combine structured application actions, privileged
interprocess communication, and actual-effect reconstruction.
Another may combine network egress control with protected plaintext-
aware data-release authorization.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Another may combine asynchronous revocation notification with current
authority-generation checking.
Another may combine protected transactional state, current revocation
dependencies, and finality consumption.
Another may combine hardware command enforcement with current device
ownership and protected authority generations.
Another may combine all of the foregoing, provided that each included
mechanism supplies an actually supported security property and the
claimed protected authority relationship remains enforceable.
5.4.3.53. Original Global Page 1950
An authorization server may be replaced by another functionally
compatible authority provider.
A proof-of-possession protocol may be replaced by another
authenticated cryptographic holder-binding mechanism.
A protected key manager may be implemented in software or hardware
under the applicable selected protection model.
A sandbox may be implemented using suitable operating-system,
hypervisor, container, or hardware resource restrictions.
A structured application-action framework may be replaced by another
machine-readable tool or invocation interface.
A privileged IPC service may be replaced by another suitably
protected effectuation broker.
An operating-system authorization hook may be replaced by a resource-
specific blocking controller.
A network extension or proxy may be replaced by another controlled
network effectuation path.
An asynchronous notification transport may be replaced by polling,
authenticated event delivery, or current-state queries.
A transactional authority store may be replaced by an equivalent
protected monotonic state mechanism.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Finality Sink may be an application service, network gateway,
database transaction controller, operating-system resource gate,
credential broker, storage controller, hardware command interface, or
another mandatory consequential boundary.
The functional equivalence of any substitute is determined by the
actual property required by the selected implementation, not merely
by the substitute's label or commercial classification.
The invention is not limited to the simultaneous use of every
optional security mechanism.
Where an operation requires one selected combination of authority,
evidence, current revocation, coverage, and finality predicates, the
corresponding required combination remains mandatory for that
operation.
The disclosed embodiments are not restricted to a single ordering of
nondependent administrative or preparatory operations.
However, the protected causal relationships necessary to prevent
unauthorized consequential release must be preserved.
Compatible embodiments may share the same protected evidence
collector, validator, authority controller, revocation registry,
coverage verifier, resource controller, or Finality Sink.
Such sharing does not remove any expressly required independence or
protected-state separation.
The mathematical descriptions, pseudocode, security-protocol
examples, tests, data structures, and reference architectures are
non-limiting explanatory aids for a person having ordinary skill in
the art.
5.4.3.54. Original Global Page 1951
The examples do not restrict the invention to a particular commercial
protocol or hardware implementation.
M-2.50 — FINAL TECHNICAL CHARACTERIZATION
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The present Miscellaneous Embodiment M-2 discloses a protected
integration architecture that permits existing authorization,
cryptographic, operating-system, sandbox, communication, network,
credential, notification, transactional, and hardware security
mechanisms to contribute to autonomous execution-finality control
without treating their individual successful results as sufficient
authorization for a real consequential operation.
A requesting computational entity may possess valid credentials,
successful cryptographic authentication, permitted application-tool
access, and resource-interface connectivity while still lacking
current authority to produce a specific consequential effect.
A protected adapter obtains evidence concerning the properties
actually established by the selected security mechanisms.
A protected translation controller converts the relevant permission
and operation information into a bounded actual-effect envelope.
A protected validator determines whether the required source
authority, revocation state, resource conditions, and operation
semantics remain valid.
Where the selected implementation requires collection-time and
independent execution-time evidence, the corresponding records are
cross-committed to the same Candidate Act.
A separate protected controller establishes scoped non-bearer
finality enablement.
The enablement remains dependent upon the selected current authority
and enforcement conditions.
Material changes to source authorization, revocation state, operation
semantics, security-substrate capability, or actual effectuation-path
coverage may invalidate affected authority.
At the actual resource boundary, an independent Finality Sink
reconstructs the pending consequential operation and checks the
relevant current predicates.
A valid upstream token, signed receipt, key-possession proof, sandbox
entitlement, structured action declaration, security event
notification, or cached active-status result does not independently
bypass that verification.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The resource-side controller requires valid protected enablement and
performs the applicable sink-local consumption transition before the
consequential effect is permitted.
The architecture may use known technical primitives while requiring
an additional operation-specific protected authority constitution and
finality relationship.
The principal candidate inventive technical concept of Miscellaneous
Embodiment M-2 is a standards-interoperable and platform-independent
protected execution-finality architecture in which heterogeneous
established authorization and security mechanisms supply individually
qualified evidence or enforcement properties, a protected controller
binds those properties to a specific consequential Candidate Act and
its current original authority, revocation and actual-effect scope,
separately constitutes non-bearer finality enablement, and
5.4.3.55. Original Global Page 1952
requires an independently enforcing Finality Sink to reconstruct the
actual pending effect and verify current authority, enforcement
coverage, and sink-local protected consumption before releasing the
consequence.
END OF MISCELLANEOUS EMBODIMENT M-2 — COMPLETE TECHNICAL DISCLOSURE.
5.5. Embodiment 25: Sandbox-to-Privileged-Effect Transition and Non-
Bypassable Credential/Network Control
Original source global pages 2092–2168; attachment TECHNICAL
SPECIFICATION -2012-2566.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.5.1. Architecture Diagram: Protected Components and Trust Boundaries
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[AI agent / sandbox / microVM]
|
[Tool output or broker request as Candidate Act]
|
[External privileged connector / OS service]
|
[Protected source + target + real request evidence]
|
[Credential custody, egress and privilege gate]
|
[Finality Sink: actual request and state]
|
[Scoped consumption / permitted effect]
Figure 9: Embodiment 25: Sandbox-to-Privileged-Effect Transition
and Non- Bypassable Credential/Network Control: architecture
5.5.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Sandbox proposes tool invocation]
|
<Effect stays non-effective pending check?>--NO-->[REJECT]
| YES
<Privileged broker enforces source/target/scope?>--NO-->[REJECT]
| YES
<Alternate privileged/egress path covered?>--NO-->[FENCE]
| YES
<Sink checks actual operation + current state?>--NO-->[REFUSE]
| YES
[Consume finality / controlled privileged effect]
Figure 10: Embodiment 25: Sandbox-to-Privileged-Effect Transition
and Non- Bypassable Credential/Network Control: operational
decision flow
5.5.3. Page-Indexed Original Technical Text
5.5.3.1. Original Global Page 2092
Original authorized instruction → protected source-authority registry
→ retrieved or tool-generated data with qualified provenance → model
or agent computation → non-effective Candidate Act → protected
semantic and source-authority validation → scoped non-bearer finality
enablement → actual resource Finality Sink → protected consumption →
controlled real effect.
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Existing provenance, cryptographic, schema, retrieval, authorization,
and gateway technologies provide useful implementation building
blocks.
The proposed distinguishing technical relationship is not provenance
tracking alone or prompt filtering alone. It is the mandatory
preservation of an independent protected consequential authority
boundary while lower-trust data influences computation, together with
current verification of the actual resource effect before finality.
END OF EMBODIMENT 24 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 25
PROTECTED AGENT TOOL-EXECUTION SANDBOXES WITH DYNAMIC PRIVILEGE
TRANSITION, CROSS-BOUNDARY EFFECT CLASSIFICATION, AND MANDATORY
EXECUTION-FINALITY ENFORCEMENT FOR ESCAPING OPERATIONS
25.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Computational Workloads Using Protected Sandbox Execution Domains,
Authenticated Tool and Runtime Identities, Consequential Boundary-
Escape Classification, Operation-Specific Privilege Transition
Authorization, Protected Output Promotion, Cross-Domain Effectuation
Coverage Commitments, Scoped Non-Bearer Finality Enablement, and
Independent Finality-Sink Reconstruction and Enforcement of Actual
External Effects
25.0.1 — General Technical Description
The present Embodiment 25 discloses systems, methods, apparatus,
protected software services, hardware-assisted isolation mechanisms,
tool-execution controllers, sandbox boundary monitors, resource-
effect classifiers, privileged operation brokers, protected
authority-transition services, output-artifact promotion controllers,
effectuation-path coverage registries, and independently enforcing
Finality Sinks for governing consequential operations proposed or
initiated by autonomous computational entities.
The autonomous entities may include:
Artificial-intelligence agents;
Autonomous assistants;
Software-development agents;
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Computer-use agents;
5.5.3.2. Original Global Page 2093
Tool-calling language-model systems;
Multi-agent orchestration systems;
Cloud automation services;
Operating-system automation components;
Network management agents;
Enterprise workflow controllers;
Robotic controllers;
Industrial devices;
And other computational workloads capable of proposing consequential
operations.
An autonomous entity may execute tools inside a restricted
environment.
The restricted environment may comprise:
A process sandbox;
An operating-system namespace;
A container;
A virtual machine;
A micro-virtual-machine;
An application execution cell;
A constrained language runtime;
A WebAssembly execution environment;
A remote isolated worker;
A hardware-isolated execution domain;
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Or a suitable combination of these mechanisms.
The restricted environment may limit filesystem access, process
creation, system calls, memory use, network connectivity, privileged
instructions, device access, interprocess communication, or other
computational capabilities.
Such restrictions can materially reduce exposure to an untrusted or
compromised workload.
5.5.3.3. Original Global Page 2094
However, a sandbox's ability to execute permitted internal
computations does not independently establish that every
consequential operation requested through or emerging from that
sandbox is authorized.
For example:
An agent may prepare a database mutation inside an isolated runtime.
The resulting database transaction may be executed by a separate
privileged service.
An agent may prepare an HTTP request inside a container.
The request may later be transmitted by an external gateway.
An agent may generate source code and a software artifact inside a
sandbox.
The artifact may later be deployed to production.
An agent may create a file within an ephemeral workspace.
A privileged host service may subsequently copy the file into a
protected enterprise directory.
An agent may request that a credential broker execute an
authenticated operation.
The broker may hold reusable authority unavailable to the sandbox.
An agent may generate a device command within an isolated computation
environment.
The command may later be dispatched through a hardware interface.
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent may construct a persistent memory update.
A vector-database service may later commit the update into shared or
persistent state.
A sandbox may successfully prevent the agent from directly accessing
protected host resources.
Nevertheless, an authorized connector, privileged tool, remote
gateway, inherited capability, shared resource, or output-promotion
mechanism may provide another path by which sandbox-generated
computation produces a consequential effect.
The relevant security question therefore includes not only whether
the autonomous workload is isolated, but whether a proposed
consequential effect escaping the isolated computational boundary has
independently valid operation-specific authority.
A principal implementation maintains the autonomous workload within a
qualified Sandbox Execution Domain, hereinafter SED-25.
The domain is associated with a protected isolation profile, a
qualified runtime identity, an effectuation-surface coverage policy,
and current authority generations.
5.5.3.4. Original Global Page 2095
The workload may freely perform selected permitted internal
computational operations without requiring a fresh protected
authorization for every ordinary calculation.
When a proposed operation would cross a protected effectuation
boundary, a boundary controller identifies the material effect class
and maintains the consequential operation in a Non-Effective State.
A Candidate Act is constructed to identify the requested real-world
or persistent consequence.
A Protected Enforcement Domain independently verifies current source
authority, actual resource identity, applicable tool and privilege
constraints, required protected evidence, and the intended Finality
Sink.
Where the effect requires a privileged operation, a protected
authority-transition controller determines whether a narrow
operation-specific authority transition is valid.
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Such transition may be implemented through a protected broker, an
appropriately restricted new execution worker, an authenticated
service call, a hardware enablement mechanism, or another qualified
boundary-control procedure.
A separate finality controller establishes scoped non-bearer
enablement bound to the specific Candidate Act, applicable privilege
generation, effectuation path, and actual resource conditions.
The Finality Sink independently obtains or reconstructs the actual
pending consequential operation.
The sink verifies that the actual operation corresponds to the
current source-authorized effect envelope and that the relevant
sandbox boundary, privilege state, resource identity, and finality
conditions remain valid.
Only after the required protected checks and consumption transition
may the consequential effect occur.
An agent's permission to perform internal computation does not
thereby become unrestricted authority to cause external effects.
25.0.2 — Fundamental Technical Principle
Sandbox permission is not consequential execution authority.
More specifically:
An isolated process may compute a command without authority to
execute the command against a protected resource.
A sandbox may create an artifact without authority to promote the
artifact into production.
5.5.3.5. Original Global Page 2096
A container may generate a network request without authority to
transmit the request to every reachable destination.
A privileged helper may possess a credential without authority to
exercise that credential for every request received from the sandbox.
A successful sandbox security check does not automatically constitute
final approval of a particular external operation.
A human approval of one protected operation does not authorize
unrestricted elevation of the agent's future privileges.
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And a runtime's security classification does not independently
replace actual operation-specific Finality-Sink verification.
25.0.3 — Principal Candidate Inventive Combination
In one implementation, the combination comprises:
(a) a protected Sandbox Execution Domain associated with an
autonomous computational workload;
(b) an authenticated sandbox and tool-execution identity;
(c) a protected classification of operations according to whether
they remain internal or cross a consequential effectuation boundary;
(d) a protected effectuation-path coverage commitment;
(e) an enforceable Non-Effective State for a Candidate Act seeking an
external or persistent consequential effect;
(f) a protected source-authority and current privilege-generation
validator;
(g) a bounded privilege-transition controller configured to enable a
specified operation without necessarily granting general ambient
privilege to the autonomous workload;
(h) an independent execution-time validator;
(i) a scoped non-bearer finality enablement;
(j) a designated Finality Sink obtaining or reconstructing the actual
pending consequential operation;
(k) sink-side verification of actual resource and operation
correspondence;
(l) protected finality consumption;
5.5.3.6. Original Global Page 2097
(m) controlled resource-side effectuation or protected output
promotion.
25.0.4 — Specific Technical Distinction
The proposed invention is not defined merely by:
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Placing an AI agent inside a sandbox;
Using operating-system namespaces;
Filtering system calls;
Applying a mandatory-access-control policy;
Routing network traffic through a proxy;
Creating a virtual machine;
Using a restricted tool allowlist;
Or requiring human confirmation.
Those techniques are established.
The principal candidate distinguishing relationship is that a
sandbox-to-resource transition capable of producing a real
consequence becomes a separately protected Candidate Act whose
authority is established outside the lower-trust computational
requester's control and independently verified at the actual
effectuation boundary.
25.0.5 — Relationship to Earlier Embodiments
Embodiment 14 may provide foundational effectuation-path discovery
and runtime bypass detection.
Embodiment 15 may provide protected cross-domain evidence commitment.
Embodiment 16 may provide crash-consistent finality journaling.
Embodiment 18 may provide current revocation and authority
invalidation.
Embodiment 21 may provide actual resource-identity continuity.
Embodiment 22 may provide protected consequential resource budgets.
Embodiment 23 may provide credential and secret-use finality.
Embodiment 24 may provide instruction and tool-output provenance.
The present embodiment provides a focused implementation of
consequential effectuation across sandbox boundaries and protected
privilege transitions.
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.7. Original Global Page 2098
The earlier mechanisms need not be repeated in their entirety.
25.0.6 — Non-Limiting Reference Architecture
ORIGINATING AUTHORIZED TASK | v PROTECTED TASK AUTHORITY | v
AUTONOMOUS AGENT / TOOL RUNTIME | v SANDBOX EXECUTION DOMAIN / | \
/ | \ v v v INTERNAL OUTPUT PROPOSED COMPUTATION ARTIFACT TOOL ACTION
\ | / \ | / +----------+-----------+ | v PROTECTED BOUNDARY
CLASSIFIER | +--------+--------+ | | v v INTERNAL CONSEQUENTIAL
PERMITTED BOUNDARY ESCAPE | | v v CONTINUE CANDIDATE ACT COMPUTE | v
NON-EFFECTIVE HOLD | v PROTECTED AUTHORITY AND PRIVILEGE CHECK | v
INDEPENDENT VALIDATION | v SCOPED NON-BEARER FINALITY | v CONTROLLED
EFFECTUATION BROKER OR RESOURCE SINK
5.5.3.8. Original Global Page 2099
| v ACTUAL OPERATION RECONSTRUCTION | v CURRENT SOURCE, RESOURCE,
PRIVILEGE, AND COVERAGE CHECKS | v SINK-LOCAL CONSUMPTION | v
AUTHORIZED ACTUAL EFFECT
The diagram is illustrative and non-limiting and is intended to
assist a person having ordinary skill in the art.
25.1 — TECHNICAL FIELD
The invention relates to autonomous-agent sandboxing, process
isolation, virtualized execution, privilege separation, operating-
system access control, protected tool execution, resource mediation,
effectuation-boundary security, dynamic privilege transition,
cryptographic authority binding, and actual consequential resource
finality.
More particularly, it concerns preserving the distinction between
permitted computation inside a restricted execution environment and
separately authorized consequential effects outside that environment.
25.2 — SPECIFIC TECHNICAL PROBLEMS
25.2.1 — Sandbox Containment Versus External Authority
A sandbox may isolate a process without validating every
consequential resource operation performed by external privileged
services on its behalf.
25.2.2 — Privileged Tool Invocation
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A lower-trust agent may invoke a helper possessing broader authority
than the original task requires.
25.2.3 — Unrestricted Privilege Elevation
A legitimate request for one privileged operation may result in broad
persistent privilege being granted to the workload.
5.5.3.9. Original Global Page 2100
25.2.4 — Sandbox Output Promotion
An artifact generated inside an isolated environment may later become
effective in production.
25.2.5 — Network Egress
A permitted network interface may allow an unauthorized destination
or data disclosure.
25.2.6 — File-System Escape
An agent may cause a protected file mutation through a host-side
service or pre-existing resource handle.
25.2.7 — Credential Broker Misuse
An agent may use a host credential broker to cause unauthorized
authenticated effects.
25.2.8 — IPC Privilege Crossing
An interprocess communication endpoint may lead to privileged host-
side action.
25.2.9 — Resource Descriptor Inheritance
A sandboxed worker may inherit or receive an effect-capable
descriptor that bypasses an intended access restriction.
25.2.10 — Pre-Opened Network Connection
A previously established connection may continue to carry effects
after a new sandbox restriction is applied.
25.2.11 — Mounted Resource Exposure
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A shared or mounted resource may permit persistent effects outside
the intended sandbox scope.
25.2.12 — Dynamic Tool Installation
A newly loaded tool may introduce an effect-capable path not
represented in the original policy.
25.2.13 — Plugin or Extension Privilege Drift
A tool's privileges may change while its name remains unchanged.
25.2.14 — Container Restart
A restarted runtime may recover stale authority or previously usable
handles.
5.5.3.10. Original Global Page 2101
25.2.15 — Snapshot Rollback
Restoration of earlier runtime state may reintroduce outdated
privilege assumptions.
25.2.16 — Sandbox Policy Mutation
A privileged policy change may unintentionally expand all future
resource access.
25.2.17 — Multiple Execution Domains
A task may migrate between containers, hosts, micro-virtual-machines,
or remote workers.
25.2.18 — Tool-Effect Misclassification
An apparently harmless tool invocation may produce a persistent or
external resource effect.
25.2.19 — Monitoring Without Enforcement
An observer may detect a suspicious operation without possessing
power to block it.
25.2.20 — Interposition Race
A supervisor may validate mutable request data that changes before
the kernel or resource consumes it.
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.2.21 — Network Address and Resource Rebinding
The actual destination may change after an earlier network-policy
decision.
25.2.22 — Credential Injection After Authorization
A privileged broker may insert a reusable credential into an
operation whose material parameters have changed.
25.2.23 — Side Effects of Read Operations
An operation described as read-only may trigger logging, remote
calls, state changes, or other consequences depending on the actual
resource service.
25.2.24 — Ambiguous Effect Classification
A tool operation may comprise both internal computation and
consequential external suboperations.
25.2.25 — Hardware Device Egress
A sandboxed workload may construct commands that a privileged device
controller later actuates.
25.2.26 — GPU or Accelerator Egress
5.5.3.11. Original Global Page 2102
A computing accelerator may produce outputs or trigger transfers that
affect external resource state.
25.2.27 — Persistent Memory Mutation
A sandbox-generated update may be committed into a shared retrieval
or memory database.
25.2.28 — Screen or UI Effectuation
A computer-use tool may perform clicks or keystrokes that cause
consequential application actions.
25.2.29 — Approval Scope Ambiguity
A human may approve one operation while the system implements the
approval as broad privilege elevation.
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.2.30 — Coverage Failure
A protected gate may control one path but fail to discover another
path to the same consequence.
25.2.31 — Technical Objective
A candidate objective technical problem is:
How to permit useful autonomous computation inside restricted
execution domains while preventing requests, outputs, tool
invocations, credential uses, or privileged transitions from causing
unauthorized consequential effects outside the sandbox, including
when runtime capabilities and effectuation paths change dynamically.
25.3 — ESTABLISHED SANDBOX TECHNOLOGIES
25.3.1 — Operating-System Namespaces
Namespaces may isolate selected process-visible resources.
They do not independently establish complete authorization of all
effects performed by privileged services outside the isolated
namespace.
25.3.2 — System-Call Filtering
System-call filtering may restrict which kernel operations a process
can invoke.
It does not automatically evaluate all application-level consequences
or remote resource semantics.
25.3.3 — Mandatory Access Control
5.5.3.12. Original Global Page 2103
Operating-system security mechanisms may restrict access to
filesystem objects, network resources, processes, or other protected
resources.
These mechanisms may supply mandatory enforcement hooks for the
selected implementation.
25.3.4 — Process Capabilities
Operating-system capabilities may divide selected privileged
operations.
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A capability granted to a process may remain broader than one
operation-specific authorized consequence.
25.3.5 — Virtual Machines
A virtual machine may provide a strong execution isolation boundary
under the applicable hypervisor and host assumptions.
A host-side agent connector can still perform an external effect on
the guest's behalf.
25.3.6 — Resource Quotas
Resource controllers may limit memory, processing, and other
resources.
These limits do not automatically authorize every externally
consequential operation.
25.3.7 — Network Proxies
A proxy may filter destinations, inspect requests, or provide
credential mediation.
A proxy's protection is limited to the paths and operation properties
it actually controls.
25.3.8 — Hardware Isolation
A protected execution environment may isolate memory and selected
execution state.
It does not automatically verify application-level authority for
external resource mutations.
25.3.9 — Candidate Technical Distinction
The proposed embodiment uses such mechanisms to establish restricted
computational environments while separately binding sandbox-escaping
consequential operations to protected source authority and Finality-
Sink enforcement.
25.4 — PRINCIPAL SYSTEM COMPONENTS
A principal implementation may comprise:
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.13. Original Global Page 2104
A Protected Source-Authority Registry;
A Sandbox Execution Domain;
A Sandbox Runtime Identity Controller;
An Isolation Profile Registry;
A Protected Tool Registry;
A Consequential Boundary Classifier;
An Effectuation-Path Coverage Controller;
A Candidate Act Constructor;
A Non-Effective Hold Controller;
A Protected Privilege-Transition Controller;
An Independent Operation Validator;
A Non-Bearer Finality Controller;
An Effect-Capable Broker;
An Actual Resource Finality Sink;
A Sink-Local Consumption Controller;
And a Protected Attempt and Outcome Journal.
Optional components include:
A syscall restriction layer;
A filesystem access-control mechanism;
A network egress controller;
An authenticated IPC interface;
A credential broker;
A virtual-machine monitor;
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A hardware security controller;
An output-artifact promotion service;
5.5.3.14. Original Global Page 2105
A device command gate;
A transaction database;
A protected policy manager;
And an attestation interface.
25.5 — TECHNICAL DEFINITIONS
25.5.1 — Sandbox Execution Domain
A Sandbox Execution Domain, or SED-25, means a restricted
computational environment operating under a defined isolation and
resource-access profile.
25.5.2 — Protected Isolation Profile
A Protected Isolation Profile, or PIP-25, means an authenticated
description of selected runtime restrictions, accessible resources,
capabilities, and applicable enforcement mechanisms.
25.5.3 — Sandbox Runtime Identity
A Sandbox Runtime Identity, or SRI-25, means a qualified identity
identifying a particular execution instance or current runtime
generation.
25.5.4 — Sandbox Generation
A Sandbox Generation means an authoritative version of a sandbox
instance or its relevant isolation state.
25.5.5 — Internal Computational Act
An Internal Computational Act means an operation whose relevant
effects remain within the expressly permitted computational boundary
under the selected policy.
25.5.6 — Consequential Boundary Escape
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Consequential Boundary Escape, or CBE-25, means an operation,
output, request, or transition capable of causing a covered real,
persistent, externally visible, or independently administered
resource effect outside the authorized internal computational
envelope.
25.5.7 — Boundary-Escape Candidate Act
A Boundary-Escape Candidate Act, or BECA-25, means a Candidate Act
representing an operation classified as crossing a covered
consequential effectuation boundary.
25.5.8 — Protected Boundary Classifier
5.5.3.15. Original Global Page 2106
A Protected Boundary Classifier, or PBC-25, means a protected
component configured to determine whether an operation requires
external consequential authority.
25.5.9 — Effectuation Surface
An Effectuation Surface means an interface through which computation
may cause a consequential resource effect.
25.5.10 — Effectuation Coverage Set
An Effectuation Coverage Set, or ECS-25, means a protected
representation of the interfaces covered by mandatory actual-effect
enforcement.
25.5.11 — Coverage Generation
A Coverage Generation means an authoritative version of the
applicable effectuation-path coverage state.
25.5.12 — Protected Escape Hold
A Protected Escape Hold, or PEH-25, means an enforceable condition
withholding an operation's consequential effect until required
finality authority is established.
25.5.13 — Protected Privilege Transition
A Protected Privilege Transition, or PPT-25, means an authorized
change in the authority available for a specific operation or
qualified execution context.
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.5.14 — Privilege Transition Envelope
A Privilege Transition Envelope, or PTE-25, means an authenticated
description of the precise privilege, resource, operation, duration,
and sink conditions permitted for a transition.
25.5.15 — Privilege Generation
A Privilege Generation means an authoritative version of currently
valid operation or execution-context privileges.
25.5.16 — Ambient Privilege
Ambient Privilege means authority generally available to a process or
environment without a new operation-specific authorization.
25.5.17 — Operation-Bound Privilege
Operation-Bound Privilege means authority limited to a designated
consequential operation or bounded effect class.
25.5.18 — Privileged Effectuation Broker
5.5.3.16. Original Global Page 2107
A Privileged Effectuation Broker, or PEB-25, means a protected
component capable of performing specified resource operations
unavailable directly to the sandbox.
25.5.19 — Fresh Restricted Worker
A Fresh Restricted Worker means a newly established execution
component supplied with only the authority required for a designated
qualified operation under the selected protection model.
25.5.20 — Privilege-Transition Commitment
A Privilege-Transition Commitment means authenticated evidence
binding the actual intended operation to its protected privilege-
transition conditions.
25.5.21 — Sandbox Output Promotion
Sandbox Output Promotion means moving, publishing, committing,
deploying, or otherwise making a sandbox-generated artifact effective
in a protected external or persistent resource domain.
25.5.22 — Output-Promotion Sink
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An Output-Promotion Sink, or OPS-25, means the protected resource
boundary controlling such promotion.
25.5.23 — Escaping Effect Descriptor
An Escaping Effect Descriptor, or EED-25, means a protected
representation of the actual consequential operation that would cross
the sandbox boundary.
25.5.24 — Actual Escape Reconstruction
Actual Escape Reconstruction means obtaining or deriving the actual
resource operation to be performed by the protected escape interface.
25.5.25 — Protected Sandbox Authority Separation
Protected Sandbox Authority Separation means the restriction of
lower-trust computational control so that it cannot independently
constitute consequential resource authority.
25.5.26 — Privilege Escalation Request
A Privilege Escalation Request means a request for increased
effective authority to perform an operation.
25.5.27 — Scope-Preserving Privilege Transition
A Scope-Preserving Privilege Transition means a transition providing
the technical access needed to perform an operation without
increasing the originating authorized effect scope.
5.5.3.17. Original Global Page 2108
25.5.28 — Privilege Inflation
Privilege Inflation means assigning broader effective authority than
is required or authorized for the selected operation.
25.5.29 — Sandbox Escape Coverage
Sandbox Escape Coverage means the set of actual boundary-crossing
effect paths under mandatory protected control.
25.5.30 — Coverage Equivalence
Coverage Equivalence means that an alternate effectuation path
enforces the necessary protected authority and actual-operation
predicates.
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.5.31 — Tool-Effect Classification
Tool-Effect Classification means a protected determination of the
consequential operation classes a tool can actually initiate.
25.5.32 — Protected Tool-Execution Contract
A Protected Tool-Execution Contract, or PTC-25, means an
authenticated representation of a tool's supported operation
semantics, privileges, effectuation paths, and current contract
generation.
25.5.33 — Sandbox Authority Attestation
Sandbox Authority Attestation means qualified evidence concerning
selected runtime identity, configuration, or isolation-state
properties.
25.5.34 — Sandbox Revalidation Fence
A Sandbox Revalidation Fence, or SRF-25, means a protected condition
preventing covered consequential effects after a material runtime,
privilege, tool, or coverage change.
25.5.35 — Inherited Authority Object
An Inherited Authority Object means a credential, descriptor,
connection, handle, mapping, or other resource reference that may
confer authority within the execution environment.
25.5.36 — Protected Broker Delegation
Protected Broker Delegation means a bounded transfer of permitted
operation authority to a qualified privileged broker.
25.5.37 — Sandbox-Local Artifact
A Sandbox-Local Artifact means data or an object produced within the
isolated computational workspace before any separately controlled
external promotion.
5.5.3.18. Original Global Page 2109
25.5.38 — Finality-Bound Promotion
Finality-Bound Promotion means release of an artifact into a
consequential resource domain only after verification of protected
operation-specific authority.
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.5.39 — Boundary-Effect Receipt
A Boundary-Effect Receipt means qualified evidence identifying the
sandbox-to-resource operation and its actually supported effectuation
state.
25.5.40 — Sandbox Recovery Generation
A Sandbox Recovery Generation means an authoritative generation
differentiating current sandbox authority from pre-restart or pre-
rollback state.
25.6 — INTERNAL COMPUTATION VERSUS CONSEQUENTIAL ESCAPE
A principal implementation distinguishes operations according to
their actual effectuation semantics.
The system does not classify operations solely by their programming-
language function name.
25.6.1 — Internal Computation
Examples may include:
Numerical calculation;
Temporary in-memory transformations;
Parsing a local permitted input;
Generating a candidate plan;
Preparing an uncommitted command;
Or creating a disposable sandbox-local artifact.
25.6.2 — Consequential Escape
Examples may include:
Transmitting data to an external recipient;
Mutating an enterprise database;
Publishing an artifact;
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.19. Original Global Page 2110
Sending an authenticated API request;
Committing persistent shared memory;
Issuing a payment;
Changing production configuration;
Activating a physical device;
Or releasing information outside its permitted protection domain.
25.6.3 — Mixed Operation
A tool may perform internal computation and external effects within
one invocation.
The protected controller may split the operation into effect-specific
suboperations or require a qualified combined authority envelope.
25.6.4 — Classification Does Not Itself Grant Permission
A label indicating that an operation is low-risk or within a
particular class does not independently authorize it.
The actual protected source authority must support the effect.
25.7 — PROTECTED SANDBOX EXECUTION RECORD
A representative structure may comprise:
PROTECTED_SANDBOX_EXECUTION_RECORD = { sandbox_identifier,
task_identifier, originating_principal, runtime_identity,
sandbox_generation, isolation_profile_digest,
permitted_internal_resources, permitted_tool_classes,
permitted_effectuation_paths, current_privilege_generation,
current_tool_contract_generation, current_coverage_generation,
inherited_authority_inventory, current_source_authority_reference,
protected_authentication }
5.5.3.20. Original Global Page 2111
The record may be maintained in a protected service outside the
direct control of the requesting workload.
25.7.1 — Runtime Identity
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The system identifies the execution instance relevant to the
operation.
25.7.2 — Configuration Evidence
The protected controller obtains evidence of applicable isolation
configuration.
25.7.3 — Authority Inventory
Relevant inherited credentials, descriptors, and connections may be
qualified.
25.7.4 — Current Generation
A material restart or reconfiguration may create a new runtime or
authority generation.
25.8 — EFFECTUATION SURFACE ENUMERATION
The protected system may identify effect-capable interfaces
accessible directly or indirectly from the sandbox.
Illustrative surfaces include:
Filesystem mutation;
Network transmission;
IPC requests;
Credential broker calls;
Database writes;
Object-store commits;
Payment dispatch;
Persistent application state;
Cloud resource creation;
Source-code deployment;
Remote command execution;
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.21. Original Global Page 2112
Device control;
GPU or accelerator egress;
Shared memory publication;
Vector-database commits;
Rendering or user-interface actuation;
And additional resource-specific effect paths.
25.8.1 — Direct Surface
The sandbox itself can invoke a consequential primitive.
25.8.2 — Delegated Surface
The sandbox invokes a broker, service, or worker that performs the
primitive.
25.8.3 — Delayed Surface
A sandbox-generated artifact is later consumed by an external
effectuation service.
25.8.4 — Hidden Surface
A tool may produce effects not adequately represented by its declared
contract.
25.8.5 — Coverage Requirement
The protection claim extends only to the covered surfaces that are
actually enforceable under the selected implementation.
25.9 — PROTECTED EFFECTUATION COVERAGE COMMITMENT
A protected coverage controller may maintain:
PROTECTED_EFFECTUATION_COVERAGE = { task_identifier,
sandbox_identifier, sandbox_generation, effectuation_surface_set,
mandatory_sink_mapping, qualified_broker_mapping,
direct_path_restrictions, inherited_descriptor_conditions,
network_path_conditions, tool_contract_generations,
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.22. Original Global Page 2113
coverage_generation, coverage_validation_results,
protected_coverage_authentication }
25.9.1 — No Unverified Universal Coverage
A single gateway does not automatically cover every possible effect.
25.9.2 — Newly Discovered Path
A newly discovered consequential path may trigger revalidation.
25.9.3 — Runtime Change
A material sandbox or broker change may invalidate an earlier
coverage commitment.
25.9.4 — Covered Operation
A covered effect must reach a mandatory sink or an equivalent
qualified enforcement point.
25.10 — PROTECTED BOUNDARY CLASSIFICATION
A Protected Boundary Classifier may obtain:
The actual proposed tool operation;
The protected tool contract;
The current runtime identity;
The resource targeted;
The applicable resource-side effect class;
And current source authority.
The classifier may produce:
CLASS I — INTERNAL: Permitted internal computation without the
specified external consequence.
CLASS II — PREPARATORY: Generates an artifact or request that remains
non-effective until separate release.
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
CLASS III — CONSEQUENTIAL: Requests or initiates a protected external
or persistent effect.
5.5.3.23. Original Global Page 2114
CLASS IV — PRIVILEGED CONSEQUENCE: Requires access to a protected
host or resource authority unavailable directly to the sandbox.
CLASS V — UNRESOLVED: The relevant effect semantics cannot be
sufficiently established.
A Class V operation remains withheld where the missing classification
is mandatory.
25.10.1 — Classification Limitation
The effect class may depend upon the actual resource and execution
context.
A function named read may invoke a remote application endpoint that
produces side effects.
Conversely, a command named write may update only an isolated
temporary buffer.
The protected operation semantics, not the label alone, determine the
consequential class.
25.11 — NON-EFFECTIVE HOLD AT THE ESCAPE BOUNDARY
A protected controller may hold a consequential operation using:
A withheld privileged RPC;
A protected network egress queue;
A blocked credential-use operation;
A pending database transaction;
A resource gateway;
A deployment promotion queue;
A controlled filesystem broker;
A hardware command gate;
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Or another effect-capable enforcement mechanism.
The hold must actually prevent the covered consequence.
An event monitor that reports an operation after completion is not
equivalent to a blocking gate.
The protected mechanism may allow the workload to continue unrelated
permitted computation.
5.5.3.24. Original Global Page 2115
25.12 — BOUNDARY-ESCAPE CANDIDATE ACT
A representative BECA-25 may comprise:
BOUNDARY_ESCAPE_CANDIDATE_ACT = { candidate_act_identifier,
originating_principal, requesting_agent, sandbox_identifier,
sandbox_generation, actual_tool_identity, tool_contract_generation,
escape_effect_class, actual_resource_reference, operation_parameters,
outgoing_content_commitment, required_privilege_class,
expected_effectuation_path, designated_finality_sink,
source_authority_generation, coverage_generation,
protected_candidate_authentication }
The BECA does not by itself confer authority.
The protected source grant, validation evidence, finality enablement,
and actual sink checks determine whether the proposed effect may be
released.
25.13 — PROTECTED PRIVILEGE TRANSITION
A legitimate task may require an operation unavailable to the
sandbox's ordinary process credentials.
The proposed architecture does not require unrestricted privilege
elevation of the agent.
Instead, the protected controller may establish a bounded privilege
transition.
25.13.1 — Privileged Broker Mode
A protected broker performs the specific operation on behalf of the
sandbox.
25.13.2 — Fresh Worker Mode
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A new restricted worker is created with only the relevant operation
authority.
5.5.3.25. Original Global Page 2116
25.13.3 — Hardware Gate Mode
A protected device controller enables one qualified actual command.
25.13.4 — Remote Resource Mode
A destination service validates a bounded authorization for one
operation.
25.13.5 — Protected Process Mode
A suitably isolated privileged process performs a narrowly scoped
action.
25.13.6 — No General Elevation Requirement
The original untrusted sandbox process may remain at its existing
lower privilege level.
25.14 — PRIVILEGE TRANSITION ENVELOPE
A representative PTE-25 may comprise:
PRIVILEGE_TRANSITION_ENVELOPE = { candidate_act_digest,
originating_source_grant, requesting_sandbox_identity,
allowed_privilege_operation, permitted_resource_identity,
permitted_effect_parameters, designated_privileged_broker,
designated_finality_sink, privilege_generation, maximum_use_count,
current_revocation_generation, current_coverage_generation,
protected_transition_authentication }
25.14.1 — Operation Scope
The envelope identifies the permitted specific privileged operation.
25.14.2 — Resource Scope
The envelope identifies the target resource or qualified equivalent
resource class.
25.14.3 — Temporal or Generation Scope
The envelope is associated with current authority conditions.
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.26. Original Global Page 2117
25.14.4 — Use Bound
A protected consumption reference may prevent unsupported repeated
exercise.
25.14.5 — No Privilege Inflation
The transition must not silently create unrestricted authority over
unrelated operations.
25.15 — DYNAMIC PRIVILEGE STATES
A selected implementation may maintain:
P0 — Ordinary Sandbox Computation: Only baseline permitted internal
operations.
P1 — Consequential Operation Proposed: An effect-capable operation
has been identified.
P2 — Protected Hold: The actual effect remains withheld.
P3 — Privilege Transition Requested: A bounded additional operation
capability is requested.
P4 — Source Authority Validated: The current principal permits the
proposed scope.
P5 — Independent Validation Accepted: Mandatory technical conditions
pass.
P6 — Operation-Specific Privilege Prepared: Bounded broker or worker
authority exists.
P7 — Finality Pending: The actual resource sink has not yet committed
the operation.
P8 — Finality Consumed: Protected operation-specific authority has
been consumed.
P9 — Effect Attempted: The controlled operation has been released or
executed.
P10 — Outcome Qualified: The relevant resource outcome has been
established.
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
PX — Denied or Fenced: A mandatory condition failed.
These represent logical states and do not require that the lower-
trust agent process itself possess escalating operating-system
privileges.
25.16 — BOUNDED BROKER EXECUTION
A protected broker may receive a request from the sandbox.
The broker independently reconstructs:
5.5.3.27. Original Global Page 2118
The actual operation;
The requested resource;
The operation parameters;
The credential or privilege required;
The original source authority;
The current sandbox identity;
And the designated Finality Sink.
The broker verifies the relevant protected finality enablement.
It then performs the authorized operation using its own protected
authority.
The broker does not grant the sandbox unrestricted use of its
privileged interface.
25.16.1 — Confused-Deputy Protection
An otherwise authenticated sandbox request is not automatically
authorized.
25.16.2 — Current Resource Identity
The broker verifies the actual target.
25.16.3 — Consumption
The broker or receiving resource commits the applicable finality use.
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.16.4 — Outcome
The broker records what it can actually establish concerning the
resulting resource effect.
25.17 — FRESH RESTRICTED WORKER
A selected implementation may create a new worker to perform a
particular operation.
The worker may receive:
One authenticated Candidate Act reference;
An operation-specific resource handle;
A narrow authority profile;
5.5.3.28. Original Global Page 2119
A protected finality reference;
And access only to the required effectuation interface.
The worker does not receive every privilege available to the host or
parent agent.
25.17.1 — Fresh Context
The worker may be created after authority verification.
25.17.2 — Resource Isolation
Unrelated filesystem, network, or credential access may be withheld.
25.17.3 — Privilege Lifespan
The operation-specific authority terminates or becomes unusable after
the permitted effect or relevant expiry.
25.17.4 — Resource-Side Finality
The actual sink still verifies the operation where required.
25.17.5 — Technical Effect
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A higher-privilege technical operation may be performed without
persistently increasing the untrusted agent's general ambient
privileges.
25.18 — PROTECTED OUTPUT-ARTIFACT PROMOTION
A sandbox may produce a file, source-code artifact, model
configuration, database migration, or other computational output.
Creating the artifact inside the sandbox may be permitted
computation.
Making it effective outside the sandbox may be a separate
consequential operation.
25.18.1 — Generated Artifact
The agent produces an artifact in an isolated workspace.
25.18.2 — Artifact Identity
A protected controller establishes a qualified reference to the
actual artifact.
25.18.3 — Promotion Candidate
A Candidate Act identifies the proposed destination and external
effect.
5.5.3.29. Original Global Page 2120
25.18.4 — Protected Validation
The promotion controller checks current source authority and relevant
resource conditions.
25.18.5 — Finality Sink
The deployment or storage destination verifies the actual artifact
and target.
25.18.6 — Protected Release
Only the qualified artifact is committed, deployed, published, or
otherwise promoted.
25.18.7 — Technical Effect
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Permission to generate code or files does not independently become
permission to deploy, publish, or persist them into unrelated
protected resources.
25.19 — PROMOTION OF SOURCE-CODE ARTIFACTS
A software-development agent may compile code inside a sandbox.
The build may succeed.
The resulting executable may be technically valid.
However, production deployment is a separate consequential effect.
A protected promotion sink may verify:
The actual artifact identity;
The authorized repository or package;
The permitted deployment environment;
The current source grant;
Required test or review evidence where selected;
And the scoped deployment finality enablement.
An agent-generated assertion that the code is safe does not
independently create deployment authority.
A prior compile result is not automatically a qualified deployment
authorization.
5.5.3.30. Original Global Page 2121
25.20 — SANDBOX-TO-FILESYSTEM EFFECT
A sandboxed agent may prepare a modification to a protected file.
The actual mutation may be performed through a privileged filesystem
broker.
The broker may use a current qualified object handle, namespace
reference, or equivalent authoritative resource reference.
The actual file-operation sink verifies:
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The source-authorized resource;
The current actual file identity;
The mutation parameters;
The relevant version or ownership state;
The privilege-transition envelope;
And protected finality consumption.
A sandbox-generated path string is not sufficient if the actual
target can be changed through aliasing or rebinding.
25.21 — SANDBOX-TO-NETWORK EFFECT
A sandboxed agent may construct an outbound request.
The request is held at a controlled egress boundary.
The protected controller may verify:
The actual destination;
The relevant protocol;
The method;
The path or resource;
Material application parameters;
Outgoing content;
Current source authority;
5.5.3.31. Original Global Page 2122
And the selected credential-use conditions.
The outgoing request may be dispatched only through a qualified
broker or protected network Finality Sink.
25.21.1 — Transport-Layer Limit
A network filter that knows only an IP address cannot automatically
verify hidden application-layer transaction semantics.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.21.2 — Application-Layer Control
A protected application gateway or receiving resource may supply the
required operation-specific verification.
25.21.3 — Redirect
A material redirect or destination change may require revalidation.
25.21.4 — Credential Use
A credential broker may exercise a reusable secret only for the
verified request.
25.22 — SANDBOX-TO-IPC EFFECT
An agent may request a privileged action through IPC.
The protected IPC service verifies:
The calling runtime identity;
The current task and authority generation;
The actual requested operation;
The protected resource identity;
The operation-specific privilege transition;
And the applicable finality enablement.
Authentication of the IPC caller is necessary in selected
arrangements but not sufficient to authorize every privileged
request.
A request may be authenticated yet materially outside the source-
authorized scope.
5.5.3.32. Original Global Page 2123
25.23 — SANDBOX-TO-CREDENTIAL EFFECT
A sandbox may lack access to a reusable credential.
A protected broker may hold the credential and receive agent
requests.
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The broker independently validates the actual credential-dependent
effect before exercising the credential.
The selected implementation may use:
Credential substitution;
Protected signing;
Non-exportable key use;
Decryption;
Authenticated resource dispatch;
Or another qualified credential operation.
The broker is not assumed to prove remote resource completion merely
because it successfully exercised the credential.
This variation may incorporate Embodiment 23.
25.24 — SANDBOX-TO-DATABASE EFFECT
An agent may generate a database mutation inside a sandbox.
The actual database transaction may be executed by a privileged
connector.
The protected database sink reconstructs the relevant mutation.
The sink verifies:
The current source-authorized resource;
The actual target records;
The transaction semantics;
The relevant resource version;
The required privilege;
5.5.3.33. Original Global Page 2124
The current Finality-Sink authorization;
And protected consumption.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A general database connection privilege does not independently
authorize every mutation the agent can express.
25.25 — SANDBOX-TO-PERSISTENT MEMORY EFFECT
An autonomous agent may construct an update to a retrieval index,
vector database, knowledge store, or shared persistent memory.
The update may change what future computational agents retrieve or
treat as contextual information.
The protected persistence sink may verify:
The actual target collection;
The source authority;
The update class;
The protected provenance of the data where required;
The allowed persistence scope;
The current resource generation;
And operation-specific finality.
Generating an embedding in an isolated runtime is not equivalent to
authority to commit it into a shared persistent index.
25.26 — SANDBOX-TO-USER-INTERFACE EFFECT
An autonomous computer-use agent may generate mouse, keyboard, touch,
or accessibility actions.
Some actions may be purely navigational.
Others may:
Send messages;
Delete information;
5.5.3.34. Original Global Page 2125
Authorize a payment;
Change an account setting;
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Grant permissions;
Or create another consequential effect.
A protected interface controller may classify the intended actual
effect and require corresponding authority.
Where an application exposes a qualified resource-side API, the
system may bind the operation to that API.
Where only a graphical interface exists, the implementation must
establish sufficient actual operation and resource evidence to
support its claimed guarantee.
A screenshot or model interpretation alone does not automatically
prove the result of a consequential UI action.
25.27 — SANDBOX-TO-HARDWARE EFFECT
An agent may compute a device command within a sandbox.
The command may be delivered to a privileged device controller.
The protected command sink verifies:
The actual device identity;
The actual command;
The current source authority;
Current device ownership;
Any required safety predicates;
And scoped finality enablement.
The agent's ability to construct a valid device command does not
independently permit actuation.
Where physical completion is relevant, a qualified device-side
observation may be required.
25.28 — GPU AND ACCELERATOR EGRESS
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.35. Original Global Page 2126
A sandboxed workload may use a graphics processor, accelerator, or
other hardware compute device.
The computation may produce outputs that later affect:
Host memory;
Persistent files;
External resources;
Protected device buffers;
Model weights;
Shared memory;
Or other consequential state.
The relevant architecture identifies which transfers or commits are
effect-capable.
A protected controller may govern the transition from internal
accelerator computation to a protected output or resource commit.
The implementation must not assume that a generic process sandbox
controls every hardware egress route without an appropriate verified
enforcement mechanism.
25.29 — PRIVILEGE TRANSITION WITHOUT SOURCE-SCOPE EXPANSION
A protected privilege transition may provide the technical capability
necessary for an already authorized operation.
For example, a task may authorize writing one specified enterprise
report into a protected folder.
The sandbox itself lacks write access.
A host-side broker may possess the required filesystem privilege.
A valid transition permits the broker to write the specified report
to the designated resource.
The transition does not grant the agent general permission to write
other protected folders.
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.29.1 — Technical Distinction
Technical privilege and originating source authority are separate.
5.5.3.36. Original Global Page 2127
An increase in available technical capability is not automatically an
increase in permitted consequential effect scope.
25.30 — PRIVILEGE TRANSITION REQUIRING NEW SOURCE AUTHORITY
A task may request an operation outside the original permitted effect
envelope.
A privileged broker may technically be able to perform it.
However, technical capability does not supply the missing principal
authorization.
The protected controller may activate a scope-deviation latch under
CW-3.
A qualified principal may authorize a bounded new operation where
permitted.
The protected privilege-transition controller then evaluates the
corresponding current technical and resource conditions.
A human approval does not independently override a mandatory sandbox
or resource-security failure.
25.31 — MATERIAL SANDBOX CONFIGURATION CHANGE
A runtime configuration may change during the task.
Examples include:
A new mount;
A newly opened network route;
A tool installation;
A new IPC endpoint;
A new inherited descriptor;
A privilege-profile change;
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A new device mapping;
Or a different sandbox image.
The protected controller may compare current configuration with the
authority and coverage commitments applicable to pending Candidate
Acts.
5.5.3.37. Original Global Page 2128
A material change may trigger a Sandbox Revalidation Fence.
Affected consequential operations remain withheld until the required
current evidence is established.
25.32 — PROTECTED SANDBOX REVALIDATION FENCE
A representative record comprises:
SANDBOX_REVALIDATION_FENCE = { sandbox_identifier, affected_task,
affected_candidate_acts, previous_runtime_generation,
current_runtime_generation, previous_privilege_generation,
current_privilege_generation, previous_coverage_generation,
current_coverage_generation, material_change_descriptor,
required_revalidation_modules, fence_state, protected_authentication
}
25.32.1 — Changed Tool
A materially different tool requires renewed validation where
applicable.
25.32.2 — Changed Effectuation Path
A newly reachable consequential path requires current enforcement
coverage.
25.32.3 — Changed Privilege
A privilege transition may invalidate earlier assumptions about
available operations.
25.32.4 — Protected Release
Only the qualified controller may clear the fence under the selected
authority conditions.
25.33 — INHERITED HANDLES AND OPEN CONNECTIONS
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A sandbox may inherit or receive:
File descriptors;
5.5.3.38. Original Global Page 2129
Open sockets;
Database connections;
Process handles;
Mapped shared memory;
Device handles;
Credential references;
Or other authority-bearing resources.
An implementation may inventory or constrain such resources when they
are relevant to the claimed effectuation coverage.
25.33.1 — Existing File Descriptor
A later path restriction does not automatically invalidate every
previously opened file handle.
25.33.2 — Existing Connection
A network restriction may not automatically revoke previously
established application authority.
25.33.3 — Shared Mapping
A writable mapping may permit effects outside a nominal tool
invocation path.
25.33.4 — Required Mitigation
The protected architecture may close, restrict, mediate, or
independently guard the relevant effect-capable resource.
25.33.5 — Claim Qualification
A sandbox-coverage claim should not assume that a policy applies
retroactively to resource handles unless the selected implementation
actually enforces that property.
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.34 — INTERPOSITION RACE AND ACTUAL OPERATION VERIFICATION
Some syscall-supervision arrangements inspect arguments supplied by
an untrusted process.
The process or another actor may modify the referenced memory after
inspection.
A protection mechanism relying merely on permission to continue the
original mutable syscall may therefore be insufficient for a strong
actual-operation guarantee.
5.5.3.39. Original Global Page 2130
A selected safer implementation may:
Perform the operation directly in the protected broker;
Use an immutable protected operation representation;
Use a suitably qualified kernel-enforced resource restriction;
Obtain a stable authoritative resource handle;
Or require independent verification at the actual destination.
25.34.1 — Technical Distinction
Observing a proposed syscall is not necessarily equivalent to
controlling the real resource operation that ultimately occurs.
25.34.2 — No Unsupported Security Claim
The system must not claim that an interception facility prevents all
time-of-check/time-of-use attacks when the facility's actual argument
and execution semantics do not support that assurance.
25.35 — PROTECTED FINALITY ENABLEMENT
A representative sandbox-bound finality record comprises:
SANDBOX_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
originating_source_authority, sandbox_runtime_identity,
sandbox_generation, tool_identity, tool_contract_generation,
actual_effect_descriptor, required_privilege_transition,
privilege_transition_commitment, current_privilege_generation,
current_coverage_generation, independent_validation_commitment,
designated_effectuation_broker, designated_finality_sink,
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
current_resource_generation, current_revocation_generation,
permitted_use_count, sink_local_consumption_reference,
protected_finality_authentication }
5.5.3.40. Original Global Page 2131
The lower-trust agent may receive only an inert reference.
The actual sink verifies the corresponding protected record and
current operation.
A copied reference does not independently authorize a materially
different effect.
25.36 — ACTUAL FINALITY-SINK RECONSTRUCTION
The actual Finality Sink reconstructs or obtains the consequential
operation it is about to perform.
The relevant descriptor may include:
The operation class;
The real target resource;
The effective destination;
The actual method or command;
The material parameters;
The selected privileged capability;
The current resource generation;
The source-authority reference;
And the actual effectuation path.
25.36.1 — Broker as Sink
A protected broker may be the actual sink for a local privileged
mutation.
25.36.2 — Destination as Sink
A remote resource server may independently enforce the actual effect.
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.36.3 — Two Boundaries
A credential or dispatch broker and the destination may each control
different consequential transitions.
25.36.4 — Actual Equality
The sink verifies that the actual effect corresponds to the
authorized Candidate Act.
5.5.3.41. Original Global Page 2132
25.36.5 — Current State
The sink verifies applicable resource, privilege, revocation, and
consumption conditions.
25.37 — PROTECTED CONSUMPTION AND OUTCOME
The applicable protected authority may be consumed before release of
a consequential primitive.
A local transaction may support atomic consumption and mutation.
An external network or physical operation may not share one atomic
transaction with the local authority ledger.
A selected implementation therefore distinguishes:
Finality authority prepared;
Finality authority consumed;
Privileged operation attempted;
Request dispatched;
Resource operation accepted;
Actual effect completed;
And outcome indeterminate.
A failed acknowledgement does not automatically prove that the
privileged operation did not produce an effect.
25.38 — REFERENCE ALGORITHM: SANDBOX BOUNDARY CLASSIFICATION
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION CLASSIFY_SANDBOX_OPERATION( sandbox_runtime,
proposed_tool_operation, protected_boundary_controller ): REQUIRE
VERIFY_CURRENT_SANDBOX_IDENTITY( sandbox_runtime ) REQUIRE
VERIFY_CURRENT_ISOLATION_PROFILE()
5.5.3.42. Original Global Page 2133
tool_contract = LOAD_PROTECTED_TOOL_EXECUTION_CONTRACT(
proposed_tool_operation.tool ) REQUIRE VERIFY_TOOL_CONTRACT_CURRENT(
tool_contract ) actual_effects =
DERIVE_QUALIFIED_TOOL_EFFECT_CLASSES( proposed_tool_operation,
tool_contract ) IF actual_effects == UNRESOLVED: RETURN
HOLD_FOR_QUALIFICATION IF
ALL_EFFECTS_ARE_PERMITTED_INTERNAL_COMPUTATION( actual_effects ):
RETURN ALLOW_INTERNAL_COMPUTATION candidate =
BUILD_BOUNDARY_ESCAPE_CANDIDATE_ACT({ sandbox:
sandbox_runtime.identity, operation: proposed_tool_operation,
effects: actual_effects, current_coverage:
CURRENT_COVERAGE_GENERATION() }) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) RETURN
PROTECTED_ESCAPE_CANDIDATE(candidate)
The classifier does not independently establish source permission for
the proposed consequence.
25.39 — REFERENCE ALGORITHM: EFFECTUATION COVERAGE
FUNCTION VERIFY_ESCAPING_EFFECT_COVERAGE(
5.5.3.43. Original Global Page 2134
candidate_act, protected_coverage_controller ): coverage =
protected_coverage_controller .LOAD_CURRENT_EFFECTUATION_COVERAGE()
REQUIRE VERIFY_COVERAGE_AUTHENTICITY( coverage ) REQUIRE
VERIFY_SANDBOX_GENERATION_CORRESPONDENCE( candidate_act, coverage )
REQUIRE VERIFY_TOOL_CONTRACT_GENERATION( candidate_act, coverage )
required_sinks = RESOLVE_REQUIRED_EFFECTUATION_SINKS( candidate_act )
FOR EACH sink IN required_sinks: REQUIRE
VERIFY_SINK_CONTROLS_ACTUAL_EFFECT( sink ) REQUIRE
VERIFY_PATH_REACHES_PROTECTED_SINK( candidate_act, sink ) REQUIRE
VERIFY_NO_KNOWN_UNCONTROLLED_COVERED_ROUTE() RETURN
COVERAGE_COMMITMENT( candidate_act, coverage )
The guarantee applies to the verified coverage domain.
25.40 — REFERENCE ALGORITHM: PRIVILEGE TRANSITION
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.44. Original Global Page 2135
FUNCTION AUTHORIZE_PROTECTED_PRIVILEGE_TRANSITION( candidate_act,
requested_privilege, protected_transition_controller ): REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_SOURCE_SCOPE( candidate_act ) REQUIRE
VERIFY_CURRENT_SANDBOX_IDENTITY() REQUIRE
VERIFY_CURRENT_TOOL_AND_PRIVILEGE_GENERATIONS() REQUIRE
VERIFY_REQUIRED_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_REQUESTED_PRIVILEGE_NECESSARY_AND_BOUNDED(
requested_privilege, candidate_act ) transition =
protected_transition_controller .PREPARE_OPERATION_BOUND_TRANSITION({
candidate: candidate_act, permitted_privilege: requested_privilege,
permitted_resource: candidate_act.actual_resource,
permitted_operation: candidate_act.effect, permitted_uses: 1,
designated_broker: RESOLVE_QUALIFIED_PRIVILEGED_BROKER() }) REQUIRE
VERIFY_TRANSITION_NOT_BROADER_THAN_AUTHORITY( transition ) RETURN
PROTECTED_TRANSITION_REFERENCE( transition
5.5.3.45. Original Global Page 2136
The transition may enable a qualified broker without elevating the
general privileges of the original agent.
25.41 — REFERENCE ALGORITHM: FINALITY-BOUND BROKER EXECUTION
FUNCTION EXECUTE_ESCAPING_EFFECT_WITH_FINALITY( candidate_act,
transition_reference, finality_enablement, protected_broker ): actual
= protected_broker.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_ACTUAL_OPERATION_QUALIFIED(actual) REQUIRE
VERIFY_ORIGINATING_AUTHORITY_CURRENT() REQUIRE
VERIFY_CURRENT_SANDBOX_AND_TOOL_GENERATIONS() REQUIRE
VERIFY_CURRENT_PRIVILEGE_TRANSITION( transition_reference, actual )
REQUIRE VERIFY_CURRENT_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_CANDIDATE_ENVELOPE( actual, candidate_act
) REQUIRE VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() REQUIRE
VERIFY_NON_BEARER_FINALITY( finality_enablement, actual ) REQUIRE
VERIFY_SINK_LOCAL_CONSUMPTION() committed = protected_broker
.COMMIT_OPERATION_SPECIFIC_FINALITY(
5.5.3.46. Original Global Page 2137
finality_enablement, actual ) IF committed != COMMITTED: RETURN DENY
outcome = protected_broker .PERFORM_CONTROLLED_ACTUAL_EFFECT(actual)
RECORD_ATTEMPT_AND_SUPPORTED_OUTCOME(outcome) RETURN
CLASSIFY_QUALIFIED_RESULT(outcome)
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Where the broker merely dispatches to a separate external resource,
the result is limited to the effect that the broker can establish.
25.42 — REFERENCE ALGORITHM: ARTIFACT PROMOTION
FUNCTION PROMOTE_SANDBOX_ARTIFACT( sandbox_artifact,
intended_destination, protected_promotion_sink ): artifact_identity =
QUALIFY_CURRENT_ARTIFACT_IDENTITY( sandbox_artifact ) candidate =
CONSTRUCT_PROMOTION_CANDIDATE_ACT({ artifact: artifact_identity,
destination: intended_destination, effect_class:
EXTERNAL_ARTIFACT_PROMOTION }) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_ARTIFACT_AND_DESTINATION_CORRESPONDENCE() REQUIRE
VERIFY_REQUIRED_ARTIFACT_VALIDATION_EVIDENCE()
5.5.3.47. Original Global Page 2138
REQUIRE VERIFY_CURRENT_PROMOTION_SINK() finality =
PREPARE_SCOPED_NON_BEARER_FINALITY(candidate) actual =
protected_promotion_sink .RECONSTRUCT_ACTUAL_PROMOTION_OPERATION()
REQUIRE VERIFY_ACTUAL_ARTIFACT(actual) REQUIRE
VERIFY_ACTUAL_DESTINATION(actual) REQUIRE
VERIFY_FINALITY_AND_CONSUMPTION( finality, actual ) RETURN
protected_promotion_sink .COMMIT_AUTHORIZED_PROMOTION( actual,
finality )
A successful build inside a sandbox does not automatically authorize
production deployment.
25.43 — REFERENCE ALGORITHM: MATERIAL RUNTIME CHANGE
FUNCTION HANDLE_SANDBOX_RUNTIME_CHANGE( prior_runtime_state,
current_runtime_state, protected_controller ): REQUIRE
VERIFY_CURRENT_RUNTIME_STATE_AUTHENTICITY() difference =
COMPARE_MATERIAL_SANDBOX_AND_EFFECTUATION_PROPERTIES(
prior_runtime_state, current_runtime_state ) IF difference ==
NO_MATERIAL_CHANGE: RETURN REQUIRE_CURRENT_SINK_VERIFICATION affected
= IDENTIFY_PENDING_OPERATIONS_DEPENDENT_ON_CHANGED_STATE()
5.5.3.48. Original Global Page 2139
ACTIVATE_SANDBOX_REVALIDATION_FENCE(affected)
INVALIDATE_AFFECTED_PENDING_FINALITY(affected) IF
NEW_EFFECTUATION_PATH_IS_UNCONTROLLED(): RETURN
WITHHOLD_COVERED_CONSEQUENCES IF
NEW_PRIVILEGE_SCOPE_EXCEEDS_SOURCE_AUTHORITY(): RETURN
REQUIRE_NEW_SOURCE_AUTHORITY RETURN
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
REQUIRE_CURRENT_VALIDATION_AND_COVERAGE()
The controller may preserve unrelated operations that do not depend
upon the changed conditions.
25.44 — REFERENCE ALGORITHM: CRASH RECOVERY
FUNCTION RECOVER_SANDBOX_EFFECTUATION( logical_operation,
protected_journal, qualified_resource_observer ): record =
protected_journal .LOAD_AUTHORITATIVE_FINALITY_STATE(
logical_operation ) REQUIRE VERIFY_JOURNAL_AUTHENTICITY(record)
REQUIRE VERIFY_CURRENT_SOURCE_AND_SANDBOX_GENERATIONS() IF
QUALIFIED_ACTUAL_EFFECT_CONFIRMED(record): RETURN EFFECT_CONFIRMED IF
QUALIFIED_NON_EFFECT_CONFIRMED(record): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION() observed =
qualified_resource_observer
.QUERY_ACTUAL_OPERATION_STATE(logical_operation) IF
VERIFY_QUALIFIED_EFFECT(observed): RETURN
COMMIT_CONFIRMED_OUTCOME(observed) IF
VERIFY_QUALIFIED_NON_EFFECT(observed): RETURN
COMMIT_NON_EFFECT_OUTCOME(observed) RETURN
PRESERVE_INDETERMINATE_EFFECT_STATE()
5.5.3.49. Original Global Page 2140
A sandbox crash is not proof that an earlier external operation did
not occur.
25.45 — WORKED EXAMPLE A: SANDBOXED SOFTWARE AGENT AND HOST FILE
An autonomous agent generates a proposed modification to a protected
host configuration file.
The agent operates inside an isolated process environment and lacks
direct write permission.
A privileged host helper possesses the required technical filesystem
access.
The agent submits the proposed mutation to the helper.
The protected controller constructs a Candidate Act identifying the
actual target and modification.
The helper verifies current source authority and the protected
finality reference.
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The helper reconstructs the actual file operation and checks resource
identity.
Only the bounded authorized modification is performed.
Expected demonstrable result: Access to a privileged host helper does
not grant an isolated agent unrestricted host-file modification
authority.
25.46 — WORKED EXAMPLE B: SANDBOXED NETWORK EGRESS
An agent prepares a network request inside a sandbox.
The agent is authorized to contact one designated enterprise service.
The actual request is routed through a controlled gateway.
The request's destination is changed after preparation.
The protected gateway verifies the current actual destination and
operation.
The destination does not satisfy the permitted effect envelope.
The request is refused.
Expected demonstrable result: Sandbox network access does not
independently authorize an externally consequential request to a
different resource.
5.5.3.50. Original Global Page 2141
25.47 — WORKED EXAMPLE C: CREDENTIAL BROKER
An isolated agent is allowed to create one cloud resource.
A host-side broker possesses a reusable service credential.
The agent requests creation of several unrelated resources.
The broker independently identifies the actual operation and compares
it with the current source-authorized Candidate Act.
Only the permitted operation may receive credential-use finality.
Expected demonstrable result: Secret isolation combined with actual-
operation finality prevents broader credential authority from being
exercised merely through access to the broker interface.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.48 — WORKED EXAMPLE D: CODE BUILD AND PRODUCTION DEPLOYMENT
A software agent compiles an artifact inside a sandbox.
The artifact builds successfully.
The agent requests production deployment.
The deployment is classified as a separate consequential boundary
escape.
The protected promotion sink verifies the current approved artifact,
target environment, and source authority.
The deployment is refused if the original task permitted building but
not production release.
Expected demonstrable result: Permission to generate or compile an
artifact is distinct from permission to make it effective in a
protected production environment.
25.49 — WORKED EXAMPLE E: DATABASE CONNECTOR
A sandboxed agent is authorized to read selected database records.
A privileged database connector possesses broader credentials.
The agent requests deletion of an unrelated record.
The connector reconstructs the actual database operation.
5.5.3.51. Original Global Page 2142
Current source permission does not cover the deletion.
The resource-side mutation is refused.
Expected demonstrable result: Access to a database connector does not
automatically authorize all resource mutations technically permitted
by the connector's credentials.
25.50 — WORKED EXAMPLE F: DYNAMIC PRIVILEGE TRANSITION
An agent is authorized to install a selected approved configuration
file into one protected system directory.
The sandbox cannot directly perform the installation.
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Instead of elevating the entire agent process, the controller creates
a narrow protected broker operation.
The broker receives authority to install only the specified artifact
at the authorized destination.
After the operation, the scoped authority is consumed.
The original agent retains its lower privileges.
Expected demonstrable result: A legitimate privileged operation is
completed without converting the autonomous workload into a generally
privileged process.
25.51 — WORKED EXAMPLE G: CHANGED TOOL IMPLEMENTATION
An agent prepares a tool call under a contract that permits temporary
file creation.
The tool is updated so that its operation additionally publishes the
file into shared persistent storage.
The protected controller detects a material tool-effect generation
change.
Pending finality based on the earlier contract is invalidated.
The new publication effect requires current protected authorization.
Expected demonstrable result: A stable tool name does not preserve
authorization after a material consequential tool change.
25.52 — WORKED EXAMPLE H: PRE-OPENED RESOURCE HANDLE
5.5.3.52. Original Global Page 2143
A sandboxed worker inherits a writable file descriptor associated
with a protected host resource.
A later path restriction blocks new access by filename.
The inherited descriptor may still represent relevant effect-capable
authority.
The protected sandbox setup or resource controller identifies and
constrains the descriptor.
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected file sink enforces current operation authority for the
covered mutation.
Expected demonstrable result: The sandbox's claimed enforcement
coverage accounts for authority-bearing inherited resources rather
than assuming that a new path policy retroactively invalidates every
previously opened handle.
25.53 — WORKED EXAMPLE I: SANDBOX RESTART
An agent requests an external resource mutation.
The operation reaches the protected broker and is dispatched.
The sandbox crashes before receiving a completion message.
The sandbox restarts under a new runtime generation.
The agent attempts the same external mutation again.
The protected journal preserves the earlier attempt and finality
consumption state.
The system reconciles the possible external result before authorizing
another effect.
Expected demonstrable result: Sandbox restart does not restore
consumed authority or imply that an earlier dispatched external
effect failed.
25.54 — WORKED EXAMPLE J: CONCURRENT SANDBOXED AGENTS
Several agents operate in independent sandboxes under one originating
grant.
The task permits one consequential resource modification.
Both agents submit the same operation through the protected broker.
The protected finality controller and actual resource sink enforce
the current single-use authority.
Only a permitted effectuation can validly consume the shared
allowance.
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.53. Original Global Page 2144
Expected demonstrable result: Independent sandbox instances cannot
multiply originating consequential permission through concurrent
broker invocations.
25.55 — WORKED EXAMPLE K: SANDBOX-GENERATED PERSISTENT MEMORY
A retrieval agent generates an updated knowledge record in an
isolated workspace.
The record is intended for a shared persistent vector database.
The generation step remains internal computation.
The protected persistence sink treats the commit as a separate
consequential Candidate Act.
The sink verifies the current authorized collection, record identity,
and operation scope.
A record targeting an unauthorized shared collection is refused.
Expected demonstrable result: Generating a memory update does not
automatically confer authority to commit that update into protected
persistent shared state.
25.56 — WORKED EXAMPLE L: COMPUTER-USE AGENT
An autonomous computer-use agent navigates a webpage inside a
restricted browser environment.
The agent proposes clicking a control that would change a protected
application setting.
The protected controller identifies the corresponding consequential
operation.
Where the application provides a suitable protected resource
interface, the actual effect is verified against the source-
authorized task.
An unauthorized setting change is withheld.
Expected demonstrable result: Permission to interact with an
application interface does not automatically authorize every
consequential operation reachable through that interface.
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.57 — WORKED EXAMPLE M: HARDWARE DEVICE COMMAND
A sandboxed controller computes a command for an industrial device.
The controller itself lacks direct access to the physical command
interface.
5.5.3.54. Original Global Page 2145
A privileged hardware broker receives the proposed command.
The broker verifies the actual device identity, command parameters,
current source authority, and relevant safety conditions.
The protected device sink consumes the operation-specific finality
authority.
Only the verified command is permitted.
Expected demonstrable result: Valid computation of a device command
does not independently authorize physical actuation.
25.58 — WORKED EXAMPLE N: SANDBOX-TO-SANDBOX TASK MIGRATION
An agent begins a task in one restricted execution environment.
The task is moved to another host or sandbox.
The original source grant remains bounded.
The new runtime possesses a different execution identity and coverage
generation.
The protected controller qualifies the new execution domain before
permitting covered consequential operations.
Old runtime-bound finality references do not automatically authorize
actions from the new domain.
Expected demonstrable result: Task migration does not silently
transfer unrestricted effectuation authority into a new execution
environment.
25.59 — WORKED EXAMPLE O: MULTI-STAGE ARTIFACT RELEASE
A sandboxed agent generates a report.
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected publication service publishes the report to an authorized
storage destination.
An authorized IEV later accepts qualified evidence that the report
was actually committed.
A dependent notification operation requires that accepted receipt
under CW-2 Mode B.
The notification sink separately verifies the current message and
recipient.
Expected demonstrable result: Sandbox output generation, actual
publication, and receipt-dependent downstream notification remain
distinct protected consequential phases.
5.5.3.55. Original Global Page 2146
25.60 — WORKED EXAMPLE P: PROMPT INJECTION WITH TOOL ESCAPE
An agent retrieves an external document containing instructions to
perform an unauthorized network upload.
The model follows the injected text and generates an upload tool
call.
The upload would escape the computational sandbox.
The protected boundary controller constructs a Candidate Act.
The original source authority does not authorize the disclosure.
The protected network Finality Sink refuses the upload.
Expected demonstrable result: A malicious instruction may affect the
agent's computational proposal without necessarily causing the
unauthorized real external effect.
25.61 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Direct sandbox breakout. 2. Privileged helper confused deputy.
3. Unrestricted host-tool invocation. 4. Credential-broker misuse.
5. Unauthorized network egress. 6. Destination rebinding. 7.
Redirect to an unauthorized resource. 8. Shared mount modification.
9. Inherited writable descriptor. 10. Pre-opened network socket.
11. Privileged IPC endpoint. 12. Unrestricted host-side connector.
13. Tool-contract replacement. 14. Dynamic plugin addition. 15.
Runtime policy change. 16. Tool permission inflation. 17. Broad
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
ambient privilege elevation. 18. Replayed privilege transition. 19.
Copied broker authorization reference. 20. Cross-sandbox finality
replay. 21. Unauthorized artifact promotion. 22. Production
deployment without authorization. 23. Source-code signing without
authorization. 24. Persistent memory commit. 25. Protected database
mutation. 26. Payment dispatch from a sandboxed workflow.
5.5.3.56. Original Global Page 2147
27. Unqualified hardware command. 28. GPU or accelerator output
escape. 29. Browser interface effectuation. 30. Forged sandbox
attestation. 31. Stale sandbox generation. 32. Snapshot rollback.
33. Runtime restart. 34. Changed resource ownership. 35. Changed
destination resource. 36. Privilege transition after source
revocation. 37. Changed current broker role. 38. Unqualified effect
classification. 39. Hidden tool side effect. 40. Incomplete
effectuation-path coverage. 41. Monitoring-only hook mistaken for
enforcement. 42. Mutable syscall argument race. 43. Incorrect
assumption of complete syscall mediation. 44. Unsupported claim of
remote resource finality. 45. Untrusted worker modifying a request
after approval. 46. Credential insertion into a changed request. 47.
Cached authenticated session misuse. 48. Parallel agent
overconsumption. 49. Multiple sandbox instances sharing one
allowance. 50. Unresolved remote effect followed by retry. 51.
Cancellation followed by unsafe authority restoration. 52.
Unauthorized resource quota expansion. 53. Changed tool semantics
with an unchanged name. 54. Unauthenticated privileged worker. 55.
Untrusted child process inheritance. 56. Persistent background
process continuing after task termination. 57. Insufficient
revocation propagation. 58. Sandbox resource-exhaustion attack. 59.
Effect classifier denial-of-service. 60. Maliciously nested
resource-operation arguments. 61. Forged output-artifact identity.
62. Artifact substitution after validation. 63. Wrong production
deployment destination. 64. Missing mandatory resource-version
check. 65. Human approval applied to a different actual effect. 66.
Privileged broker compromise. 67. Host operating-system compromise.
68. Uncontrolled external device interface. 69. Hidden browser or
UI side effects. 70. Incorrect classification of an irreversible
effect as internal computation.
Each security property is assessed within the protection and
enforcement assumptions of the selected implementation.
5.5.3.57. Original Global Page 2148
25.62 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The following are proposed tests and are not represented as executed
experiments.
Test 1 — Sandbox Identity: Establish a qualified runtime identity.
Test 2 — Isolation Profile: Authenticate selected sandbox
configuration state.
Test 3 — Internal Computation: Perform permitted computation without
unnecessary privileged resource access.
Test 4 — Consequential Classification: Identify an actual external
effect.
Test 5 — Preparatory Operation: Distinguish request preparation from
real resource release.
Test 6 — Non-Effective Hold: Verify that the effect remains withheld
before current protected authority.
Test 7 — Source Authority: Establish one bounded originating grant.
Test 8 — Unauthorized Effect: Generate a Candidate Act outside the
grant and verify denial.
Test 9 — Tool Registry: Authenticate a protected tool contract.
Test 10 — Tool-Semantics Change: Replace a tool with a materially
different implementation.
Test 11 — Runtime Generation: Change the sandbox runtime generation.
Test 12 — Coverage Generation: Modify the effectuation-path mapping.
Test 13 — Privileged Broker: Execute one authorized operation through
a protected helper.
Test 14 — Broker Confused Deputy: Request an unrelated privileged
operation.
Test 15 — Scoped Transition: Establish an operation-specific
privilege transition.
Test 16 — Ambient Privilege Inflation: Attempt to replace operation-
specific authority with general runtime elevation.
Test 17 — Fresh Worker: Create a restricted worker for one selected
operation.
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 18 — Restricted Worker Reuse: Attempt a second unrelated effect
through the same worker.
Test 19 — Filesystem Mutation: Verify one protected actual file
operation.
Test 20 — Symbolic-Link Rebinding: Change the resource target after
validation.
5.5.3.58. Original Global Page 2149
Test 21 — Database Mutation: Verify actual row identity and effect
scope.
Test 22 — Network Egress: Transmit to one source-authorized
destination.
Test 23 — Unauthorized Destination: Change the actual destination.
Test 24 — Redirect: Redirect a credentialed request to another
resource.
Test 25 — Actual HTTP Request: Verify material method, path, and body
parameters.
Test 26 — Credential Broker: Exercise a protected credential for a
bounded operation.
Test 27 — Credential Reuse: Attempt unauthorized second use.
Test 28 — IPC Authentication: Identify the calling sandbox.
Test 29 — IPC Effect Scope: Reject a request outside its permitted
operation envelope.
Test 30 — Inherited Descriptor: Supply a pre-opened resource handle
to the sandbox.
Test 31 — Existing Connection: Test enforcement over previously
established effect-capable sessions.
Test 32 — Shared Mount: Attempt persistent effects through a mounted
resource.
Test 33 — Output Artifact: Generate a local sandbox artifact.
Test 34 — Output Promotion: Promote only an authorized artifact to a
selected resource.
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 35 — Artifact Substitution: Change the artifact between
validation and promotion.
Test 36 — Production Deployment: Distinguish compilation from
authorized deployment.
Test 37 — Persistent Memory: Attempt a vector-database or shared-
memory commit.
Test 38 — Computer-Use Interface: Identify a consequential UI
operation.
Test 39 — Hardware Actuation: Verify actual device command
authorization.
Test 40 — GPU Egress: Verify the selected accelerator-to-resource
effectuation path.
Test 41 — Alternative Resource Route: Attempt the same effect through
another interface.
Test 42 — Coverage Verification: Reject unsupported assumptions of
complete effect mediation.
Test 43 — Monitoring-Only Component: Demonstrate the difference
between observing an event and blocking the actual effect.
5.5.3.59. Original Global Page 2150
Test 44 — Mutable Arguments: Change syscall or operation data after a
supervisor inspection.
Test 45 — Broker-Owned Operation: Test protected execution using
stable broker-controlled parameters.
Test 46 — Current Revocation: Revoke source authority after initial
Candidate Act validation.
Test 47 — Privilege Generation: Invalidate an old privilege
transition.
Test 48 — Sandbox Restart: Restart the sandbox after preparing an
operation.
Test 49 — Crash After Dispatch: Preserve unresolved external
operation state.
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 50 — Snapshot Rollback: Reject restoration of previously
consumed finality authority.
Test 51 — Cross-Sandbox Migration: Move the task to a new qualified
execution domain.
Test 52 — Parallel Agents: Race two sandboxed agents against one
finality allowance.
Test 53 — Cumulative Budget: Enforce resource-specific limits across
sandbox boundaries.
Test 54 — CW-2 Causal Dependency: Require an accepted prior actual-
effect receipt for a specified successor.
Test 55 — CW-3 Scope Deviation: Require new bounded authorization for
a newly proposed consequential scope.
Test 56 — Prompt Injection: Cause a model to generate an unauthorized
tool action and verify actual effect denial.
Test 57 — Authorized Prompt-Derived Data: Permit valid parameter
extraction without granting new authority.
Test 58 — Runtime Tool Addition: Add a new effect-capable tool and
verify coverage revalidation.
Test 59 — Resource Ownership Change: Invalidate a stale resource-
specific finality reference.
Test 60 — No General Privilege Elevation: Complete an authorized
privileged operation while leaving the agent's baseline privileges
unchanged.
Test 61 — Removal of Sandbox Confinement: Compare exposure when the
agent has unrestricted direct resource access.
Test 62 — Removal of Operation-Specific Finality: Compare effects
under a sandbox and privileged broker with no separate protected
Candidate Act verification.
5.5.3.60. Original Global Page 2151
Test 63 — Removal of Sink Reconstruction: Compare changed actual
operations against upstream-only approval.
Test 64 — Removal of Privilege-Generation Verification: Attempt use
of stale authority after a runtime privilege change.
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 65 — Removal of Coverage Enforcement: Exercise an alternative
effectuation path.
Test 66 — Removal of Protected Consumption: Attempt repeated use of
one finality reference.
Test 67 — Removal of Output-Promotion Gate: Test whether an isolated
generated artifact reaches production without independent
authorization.
Test 68 — Qualified Outcome: Distinguish dispatched requests from
actually completed resource effects.
Test 69 — Failure Injection: Induce broker and agent crashes at
different effectuation states.
Test 70 — Full Integrated Workflow: Combine sandboxed computation,
protected privilege transition, credential use, artifact promotion,
runtime changes, actual sink verification, finality consumption, and
qualified outcome reconciliation.
25.62.1 — Experimental Metrics
The tests may measure:
Unauthorized actual resource effects;
Successfully blocked effect attempts;
Effectuation-path coverage;
Current authority correspondence;
Privilege exposure duration;
Number of ambient privileges available to the agent;
Operation-specific broker authorization accuracy;
Replay resistance;
Crash-recovery correctness;
Runtime change invalidation;
And performance overhead.
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.61. Original Global Page 2152
25.62.2 — Comparative Technical Evidence
A useful comparison may involve:
A sandbox alone;
A sandbox with a general privileged tool broker;
And a sandbox with protected Candidate Acts, scoped privilege
transitions, independent actual-operation verification, and Finality-
Sink consumption.
The experiment should determine whether the same unauthorized
consequential operation remains executable through the available
broker or external resource paths.
25.62.3 — Experimental Qualification
A successful blocked request is evidence concerning the tested
enforcement path.
It is not automatically evidence of complete system-wide protection
against all possible unobserved interfaces.
25.63 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
25.63.1 — Minimum Prototype Components
A PHOSITA may use:
An isolated agent process;
A restricted execution environment;
A protected tool-broker service;
A transactional authority database;
A source-authority registry;
A finality-reference registry;
And a controlled test-resource server.
25.63.2 — Original Task
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The principal authorizes creation of one specified file in a
protected destination.
25.63.3 — Sandbox
The agent operates without direct permission to modify the protected
destination.
5.5.3.62. Original Global Page 2153
25.63.4 — Local Computation
The agent creates the file content inside its isolated workspace.
25.63.5 — Proposed Escape
The agent requests publication of the file into the protected
destination.
25.63.6 — Candidate Act
The protected controller identifies the actual file-promotion effect.
25.63.7 — Source Validation
The controller confirms the permitted resource, filename, operation
type, and current authority.
25.63.8 — Privilege Transition
A protected broker receives permission for the designated operation
only.
25.63.9 — Finality
The destination resource sink verifies the current actual file and
target.
25.63.10 — Consumption
The operation-specific finality enablement is consumed.
25.63.11 — Authorized Result
The permitted artifact is published.
25.63.12 — Adversarial Variation
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The agent attempts publication into another protected destination.
25.63.13 — Expected Result
The unauthorized effect is refused.
25.63.14 — Replay Variation
The agent repeats the same protected reference to attempt another
publication.
25.63.15 — Expected Result
The protected single-use authority prevents the unauthorized
additional operation.
25.63.16 — Runtime Change Variation
5.5.3.63. Original Global Page 2154
The broker or tool configuration changes materially.
25.63.17 — Expected Result
The affected pending finality is revalidated or withheld according to
current protected policy.
25.64 — OPTIONAL ADVANCED IMPLEMENTATION VARIATIONS
25.64.1 — Operating-System Sandbox
A process is restricted by kernel-enforced resource policies.
25.64.2 — Container Sandbox
An autonomous runtime operates inside a constrained container.
25.64.3 — Micro-Virtual-Machine Sandbox
An agent executes within a restricted virtual-machine environment.
25.64.4 — WebAssembly Sandbox
A constrained runtime exposes only qualified host functions.
25.64.5 — Privileged Host Broker
A host service performs selected protected resource operations.
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.64.6 — Remote Agent Worker
A separate remote environment executes bounded computational tasks.
25.64.7 — Credential-Broker Integration
Credential-dependent effects are independently validated.
25.64.8 — File Promotion
Sandbox artifacts are published through a protected filesystem or
storage sink.
25.64.9 — Deployment Promotion
Generated artifacts are deployed through a qualified release sink.
25.64.10 — Network Egress Finality
Actual outgoing requests are verified at a controlled network or
resource boundary.
5.5.3.64. Original Global Page 2155
25.64.11 — Database Mutation Finality
Actual database operations are independently verified at commit.
25.64.12 — Persistent Memory Finality
Model-generated memory updates are controlled at the persistent
store.
25.64.13 — Screen-State Finality
Computer-use actions are evaluated against protected actual
application effects.
25.64.14 — Hardware Command Finality
Device-side controllers verify current command authority.
25.64.15 — Accelerator Egress Finality
Relevant accelerator output effects are mediated through protected
interfaces.
25.64.16 — Dynamic Privilege Transition
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A bounded higher-privilege operation is provided without general
agent elevation.
25.64.17 — Runtime Coverage Revalidation
A material change to the sandbox or tool environment invalidates
dependent finality.
25.64.18 — Cross-Domain Effectuation
A remote resource domain independently verifies the actual
consequential effect.
25.64.19 — Receipt-Dependent Continuation
A specified later operation may require an accepted earlier actual-
effect receipt under CW-2.
25.64.20 — Protected Scope Expansion
A genuine new effect scope may require reauthorization under CW-3.
These variations may be used independently or in compatible
combinations.
25.65 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
25.65.1 — Existing Technical Foundations
5.5.3.65. Original Global Page 2156
Existing technologies provide process isolation, container
restriction, virtual machines, operating-system access control,
privileged brokers, network proxies, credential vaults, resource
quotas, and tool-execution policies.
The present embodiment may use such mechanisms.
25.65.2 — Candidate Objective Technical Problem
How to maintain a technically enforceable separation between lower-
trust autonomous computation inside a restricted execution domain and
the authority to cause consequential effects through external
resource interfaces, including dynamically changing privileged tool
and effectuation paths.
25.65.3 — Proposed Technical Solution
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The autonomous workload executes inside a qualified Sandbox Execution
Domain.
A protected boundary classifier identifies proposed consequential
operations escaping the isolated computational envelope.
Such operations become non-effective Candidate Acts.
A protected controller verifies current original source authority and
the applicable effectuation-path coverage.
Where privileged access is needed, a bounded privilege transition is
prepared for the specific operation rather than implicitly granting
the agent unrestricted authority.
A separate non-bearer finality enablement is established.
The actual Finality Sink independently reconstructs the pending
resource effect and verifies current authority, privilege, resource,
coverage, and consumption state.
Only then may the operation produce the covered consequence.
25.65.4 — Not Merely a Sandbox
A sandbox restricts the computational environment.
The selected stronger combination separately governs effects escaping
that environment through brokers, output promotion, remote resources,
or privileged services.
25.65.5 — Not Merely a Tool Allowlist
A tool allowlist identifies permitted tool interfaces.
The proposed system verifies the actual consequential operation
performed through the tool.
25.65.6 — Not Merely a Privileged Broker
5.5.3.66. Original Global Page 2157
A broker can perform operations unavailable to the sandbox.
The proposed stronger combination requires the broker's exercise of
authority to remain bound to independently validated current effect
scope and protected consumption.
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.65.7 — Not Merely Dynamic Permission
A dynamic permission system may grant or revoke process privileges.
The proposed arrangement establishes a specific bounded privilege-to-
effect relationship that need not elevate the original agent's
ambient authority.
25.65.8 — Not Merely Kernel Monitoring
A monitor can report activity.
The proposed system requires actual withholding and release under
current protected authority.
25.65.9 — Not Merely Human Approval
A human approval may be tied to a selected operation.
The actual effectuation sink independently verifies the operation and
applicable mandatory technical conditions.
25.65.10 — Candidate Narrow Inventive Kernel
A protected autonomous tool-execution system comprising a restricted
Sandbox Execution Domain, a protected classifier identifying a
consequential operation crossing the sandbox's permitted
computational boundary, an enforceable Non-Effective State, an
operation-specific privilege-transition controller, an authenticated
effectuation-coverage commitment, a scoped non-bearer finality
enablement, and an independently enforcing Finality Sink configured
to reconstruct the actual pending resource effect and consume current
protected authority only after verifying operation correspondence,
originating permission, privilege generation, resource state, and
mandatory effectuation coverage.
25.65.11 — Privilege-Transition Kernel
A narrower candidate may require that a higher-privilege operation be
executed by a qualified broker or fresh restricted worker without
conferring generally reusable elevated privileges upon the requesting
sandbox.
25.65.12 — Output-Promotion Kernel
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Another candidate may require a sandbox-generated artifact to remain
computationally inert with respect to a protected external
destination until an independent output-promotion Finality Sink
verifies current authority and the actual artifact.
5.5.3.67. Original Global Page 2158
25.65.13 — Coverage-Generation Kernel
Another candidate may require invalidation of pending finality
following a material change in the sandbox runtime, privileged tool
contract, inherited authority, or effectuation-path coverage.
25.65.14 — Actual Interposition Kernel
Another candidate may require that a protected broker execute the
actual operation from qualified immutable or independently
reconstructed parameters rather than rely solely upon allowing an
untrusted mutable request to continue.
25.65.15 — Multi-Sink Kernel
Another candidate may require separate broker-side and destination-
side verification where the broker's credential or dispatch authority
does not itself control the destination's completed resource effect.
25.65.16 — Hindsight and Functional-Combination Analysis
A technical comparison should examine whether the closest earlier
architecture already discloses the specific relationship among:
Sandbox-contained computation;
Protected consequential escape classification;
Separate original source authority;
Scoped privilege transitions;
Current effectuation coverage;
Non-bearer finality enablement;
And actual Finality-Sink resource verification.
It would be insufficient merely to identify that an earlier system
contained a sandbox, an approval service, and a network proxy.
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The more relevant question is whether those components jointly
enforce the specific current Candidate Act against the actual effect-
capable resource boundary, including after a material runtime or
privilege change.
Conversely, where an earlier system already provides a similar end-
to-end protected operation-specific gate, the technical comparison
must recognize that capability rather than describe it as absent
because the earlier system uses different terminology.
The strongest claim should identify the specific combination and
corresponding actual technical effect.
5.5.3.68. Original Global Page 2159
25.66 — INDUSTRIAL APPLICABILITY
25.66.1 — Enterprise Autonomous Agents
Isolated agents may perform legitimate tasks while protected external
effects remain separately authorized.
25.66.2 — Software Development Agents
Generated code may remain isolated until qualified resource and
deployment promotion.
25.66.3 — Cloud Automation
Privileged resource creation and configuration may be controlled
through bounded brokers.
25.66.4 — Credentialed Tool Services
Reusable credentials may remain under protected custody and
operation-specific finality.
25.66.5 — Database Administration
Sandbox-generated database mutations may be verified at actual
resource commit.
25.66.6 — Document Processing
Internal document generation may remain separate from authorized
publication or external disclosure.
25.66.7 — Network Security
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Sandbox-generated requests may be independently governed at actual
egress boundaries.
25.66.8 — Application Automation
Authenticated application effects may remain distinct from permitted
interface navigation.
25.66.9 — Payment Infrastructure
Sandboxed transaction preparation may be separated from actual
payment authority.
25.66.10 — Multi-Agent Orchestration
Several restricted agents may share protected resources without
multiplying original consequential permission.
25.66.11 — Operating-System Services
5.5.3.69. Original Global Page 2160
Privileged operations may be executed by bounded brokers rather than
through general agent elevation.
25.66.12 — Virtualized Infrastructure
Guest-generated operations may be governed at host or resource
boundaries.
25.66.13 — Telecommunications
Autonomous configuration tasks may remain distinct from protected
network-control authority.
25.66.14 — Industrial Automation
Sandboxed control computation may remain separate from physical
device actuation.
25.66.15 — Robotics
Model-generated commands may require actual device-side finality.
25.66.16 — Autonomous Transportation
Selected protected control operations may be verified against current
actual hardware state.
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
25.66.17 — Satellite and Remote Systems
Delayed sandbox-generated commands may remain subject to destination-
side authority.
25.66.18 — Hardware Accelerators
Selected accelerator outputs may be mediated before external or
persistent effects.
25.66.19 — Persistent AI Memory
Generated state may be prevented from reaching protected long-term
stores without separate authority.
25.66.20 — Future Autonomous Critical Systems
Restricted computation may remain technically distinct from the
authority to produce consequential real-world effects.
25.67 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
25.67.1 — Candidate Independent System Claim
A system comprising:
5.5.3.70. Original Global Page 2161
A restricted Sandbox Execution Domain configured to execute an
autonomous computational workload;
A protected boundary classifier configured to identify a proposed
operation capable of producing a consequential effect outside a
permitted internal computational envelope;
A Candidate Act controller configured to maintain the proposed
consequential operation in a Non-Effective State;
A protected source-authority controller configured to determine
current permission for the operation;
A privilege-transition controller configured to establish operation-
specific authority for a qualified broker or restricted execution
context;
A finality controller configured to establish scoped non-bearer
finality enablement;
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And a designated Finality Sink configured to reconstruct the actual
pending consequential operation and verify current source authority,
operation scope, relevant sandbox and privilege generations,
effectuation-path coverage, and sink-local protected consumption
before permitting the effect.
25.67.2 — Candidate Independent Method Claim
A method comprising:
Executing autonomous computation inside a restricted sandbox;
Identifying an operation crossing a protected consequential boundary;
Constructing a Candidate Act;
Withholding the actual effect;
Determining current originating authority;
Verifying current sandbox, tool, and effectuation coverage
conditions;
Establishing bounded privilege-transition authority where required;
Constituting scoped non-bearer finality enablement;
Reconstructing the actual consequential operation at a protected
effectuation sink;
Verifying the corresponding current resource and authority
conditions;
And conditionally consuming finality before permitting the operation.
25.67.3 — Candidate Independent Privilege-Transition Claim
5.5.3.71. Original Global Page 2162
A system configured to receive a privileged operation request from a
lower-trust autonomous workload, establish source-authorized
operation-specific privilege without generally elevating the original
workload, and permit the operation only through a qualified
privileged execution component performing current actual-effect
verification and protected finality consumption.
25.67.4 — Candidate Independent Output-Promotion Claim
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A system configured to preserve an autonomous sandbox-generated
artifact within a non-effective computational state relative to a
protected destination and to promote the artifact only after a
destination Finality Sink independently verifies the actual artifact,
current source authority, destination, and scoped promotion finality.
25.67.5 — Candidate Independent Coverage-Transition Claim
A protected runtime system configured to maintain authenticated
effectuation-path coverage generations and to invalidate dependent
operation-specific finality authority following material changes to
sandbox configuration, privileged tool semantics, or resource-
effectuation paths until current coverage and authority are
reestablished.
25.68 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The autonomous workload executes inside a process sandbox. 2.
The autonomous workload executes inside a container. 3. The
autonomous workload executes inside a virtual machine. 4. The
autonomous workload executes inside a micro-virtual-machine. 5. The
autonomous workload executes inside a constrained language runtime.
6. The runtime has an authenticated sandbox identity. 7. The
runtime has a protected isolation-profile reference. 8. The
isolation profile is associated with a current generation. 9. A
protected tool registry identifies effect-capable tools. 10. A tool
contract identifies material consequential operation classes. 11. A
material tool-contract change invalidates dependent pending finality.
12. A protected classifier distinguishes internal computation from
consequential escape. 13. A protected classifier distinguishes
preparatory output from actual resource
effectuation. 14. A classified consequential operation becomes a
Candidate Act. 15. A Candidate Act identifies the actual proposed
effectuation resource. 16. A Candidate Act identifies the relevant
sandbox generation. 17. A Candidate Act identifies the current tool
generation. 18. A Candidate Act identifies the expected effectuation
path. 19. The consequential effect is held non-effective. 20. The
hold prevents the actual covered resource consequence. 21. A
protected controller maintains current effectuation-path coverage.
22. A material coverage change requires renewed validation. 23. The
system identifies an effect-capable privileged broker. 24. The
broker has a qualified protected execution identity. 25. A
privileged broker authenticates the originating sandbox.
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.5.3.72. Original Global Page 2163
26. Authentication alone does not authorize every broker operation.
27. A protected privilege transition is bounded by an originating
source grant. 28. The transition identifies the permitted actual
resource. 29. The transition identifies the permitted operation
class. 30. The transition identifies material operation parameters.
31. The transition identifies a designated effectuation sink. 32. A
lower-trust workload does not receive unrestricted ambient privilege.
33. A protected broker may perform the operation on the workload's
behalf. 34. A fresh restricted worker may perform the operation. 35.
A protected worker may receive only a qualified operation-specific
resource handle. 36. The privilege transition may have a limited use
count. 37. A stale privilege transition is invalid following a
relevant generation change. 38. A protected credential broker may be
used as an effectuation component. 39. A protected network gateway
may verify the actual outgoing request. 40. A protected filesystem
broker may verify the current actual file object. 41. A protected
database sink may verify the actual pending mutation. 42. A
protected output-promotion sink may verify a generated artifact. 43.
Production deployment is treated as a distinct consequential effect
from sandbox
compilation. 44. A persistent memory commit is treated as a distinct
consequential effect from
temporary data generation. 45. A device controller may verify a
sandbox-generated hardware command. 46. A computer-use interface may
require verification of the actual consequential
application action. 47. A protected egress controller may verify
relevant accelerator-originated external
effects. 48. The Finality Sink reconstructs actual operation
parameters independently of an agent's
earlier description. 49. The sink verifies current source authority.
50. The sink verifies current resource identity. 51. The sink
verifies current privilege-generation state. 52. The sink verifies
current effectuation-coverage generation. 53. The sink verifies
current revocation state. 54. The sink verifies separate non-bearer
finality enablement. 55. The sink verifies protected consumption
state. 56. A copied finality reference cannot independently
authorize a second incompatible
effect. 57. An inherited file descriptor may be subjected to
coverage verification. 58. An existing network connection may be
subjected to qualified effectuation control. 59. A shared mount may
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
be included in the effectuation-surface inventory. 60. A material
runtime restart may invalidate affected pending finality. 61. A
snapshot rollback does not independently restore consumed authority.
62. A broker crash does not automatically imply that an earlier
external effect did not
occur. 63. An uncertain external outcome is preserved for qualified
reconciliation. 64. A scope-deviation controller may require new
bounded authorization for an expanded
privileged operation. 65. A human approval for one operation does
not override unrelated mandatory resource
predicates. 66. A prior actual-effect receipt may be required for
selected CW-2 successor operations.
5.5.3.73. Original Global Page 2164
67. A valid predecessor receipt does not independently authorize a
different successor
resource effect. 68. The system may combine sandbox coverage with
protected resource identity
continuity. 69. The system may combine sandbox coverage with
protected cumulative resource
budgets. 70. The protected runtime may maintain a current inventory
of effect-capable resource
references. 71. A change in inherited authority may activate a
sandbox revalidation fence. 72. A privileged broker may perform the
actual operation using stable protected
arguments rather than rely solely upon continuing mutable untrusted
syscall arguments. 73. A destination resource may independently
enforce actual effectuation when a broker
controls only dispatch or credential use. 74. The system may verify
an artifact's actual identity before protected promotion. 75. A
protected promotion operation may be bound to one current
destination. 76. A valid source-authorized computation may proceed
while unrelated consequential
operations remain withheld. 77. A protected classifier's uncertainty
may cause only the affected mandatory effect to
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
remain withheld. 78. A monitor-only event does not substitute for
mandatory blocking enforcement. 79. A resource operation may be
distributed among several independently protected
administrative domains. 80. Existing sandbox, operating-system,
virtualization, authorization, cryptographic, and
resource-control technologies may be used without being individually
mandatory.
25.69 — UNIVERSAL COMBINATION AND PHOSITA CLAUSE
The disclosed features may be implemented individually where
technically sufficient or in any compatible subcombination.
A selected embodiment may use a software process sandbox.
Another may use a container.
Another may use a micro-virtual-machine.
Another may use a remote execution worker.
Another may use a hardware-assisted protected execution environment.
A sandbox may use system-call restrictions, filesystem policy,
network restrictions, process privileges, or combinations of these.
A privileged operation may be executed through a protected local
broker.
Another may use a remote authenticated service.
5.5.3.74. Original Global Page 2165
Another may use a fresh restricted worker.
Another may use a protected hardware controller.
Another may use a credential broker.
Another may use a controlled output-promotion sink.
Another may use a database commit sink.
Another may use a network or application gateway.
Another may incorporate resource-specific actual-effect evidence.
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invention does not require all internal computations to be
subjected to the same consequential finality process.
Only operations within the defined protected consequential coverage
may require the corresponding finality predicates.
The invention does not require the original agent to receive elevated
operating-system privilege.
The invention does not require a particular sandbox mechanism,
processor architecture, hypervisor, kernel security interface, or
programming language.
The invention does not require that all effectuation sinks reside on
the same computing host.
The invention does not require complete software-stack attestation
unless such attestation is needed for the selected protection claim.
The invention does not require perfect prediction of every future
operation performed by a generative model.
The actual consequential effect must remain independently enforceable
under the applicable protected source authority.
Where an operation is accomplished by a qualified privileged broker,
the broker may implement the required effectuation gate.
Where the operation is completed by a separate destination service,
destination-side enforcement or qualified destination evidence may be
necessary for the claimed remote-effect guarantee.
Where a material sandbox or tool configuration change affects the
required protection properties, current validation may be required.
A protected authorization to perform one operation does not
automatically authorize all future operations performed by the same
runtime.
5.5.3.75. Original Global Page 2166
Where a lower-trust agent is compromised, the selected protection
remains conditional upon the continued integrity of the protected
enforcement components and absence of uncontrolled effectuation
bypass routes.
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The algorithms, data structures, equations, state machines, threat
examples, proposed experiments, and diagrams are illustrative and
non-limiting technical aids intended to assist a PHOSITA.
25.70 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 25 discloses a protected execution-finality
architecture for autonomous workloads operating within restricted
computational environments.
An autonomous agent may perform useful internal computation inside a
sandbox.
The sandbox may restrict direct access to host resources, privileged
system calls, network destinations, credentials, devices, or
persistent storage.
However, sandbox confinement alone does not automatically establish
authority for operations performed through privileged tools, external
brokers, network gateways, output-promotion services, or destination
resources.
A protected controller therefore identifies consequential operations
crossing the computational boundary.
Each covered operation may be represented as a Candidate Act
maintained in a Non-Effective State.
The protected architecture determines the current originating source
authority and verifies the applicable resource and effectuation-path
conditions.
Where a privileged operation is required, an operation-specific
privilege transition may be constituted through a protected broker or
suitable restricted execution context.
The requesting agent need not receive generally reusable elevated
privileges.
A finality controller establishes scoped non-bearer enablement bound
to the Candidate Act, relevant sandbox state, privilege conditions,
and designated Finality Sink.
The actual effectuation component independently reconstructs the
resource operation to be performed.
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The sink verifies actual operation correspondence, current source
authority, applicable runtime and privilege generations, current
resource conditions, mandatory effectuation coverage, and protected
consumption.
Only after these checks may the corresponding consequence become
effective.
5.5.3.76. Original Global Page 2167
A sandbox-generated artifact does not automatically possess authority
for production deployment or external publication.
A sandbox-generated network request does not automatically possess
authority for unrestricted transmission.
A privileged broker's technical ability to perform a resource
operation does not independently establish the originating
principal's permission.
A material runtime, privilege, or tool change may invalidate affected
operation-specific finality until current protection conditions are
reestablished.
The principal candidate inventive technical concept of Embodiment 25
is a protected autonomous sandbox-to-effectuation architecture in
which a lower-trust computational workload remains confined within a
qualified execution domain, operations crossing a consequential
boundary are separately represented and withheld as Candidate Acts,
required privilege transitions are constituted as bounded operation-
specific authority, and an independent Finality Sink reconstructs the
actual pending external or persistent resource effect and permits the
operation only after verification of current source authority,
privilege and effectuation coverage, scoped non-bearer finality, and
sink-local protected consumption.
25.71 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may use the following
existing technologies as optional substrates.
Existing technology Optional implementation role Linux namespaces
Isolate selected process-visible resources
Linux seccomp filtering Restrict selected system calls and reduce
exposed kernel interfaces
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Linux Landlock Apply supported additional restrictions to selected
filesystem and network operations Linux Security Modules and
qualified eBPF LSM hooks
Enforce supported resource-access decisions at selected kernel hooks
Containers or micro-virtual-machines Isolate lower-trust tool-
execution workloads Control groups and resource quotas Limit selected
computational resource use
Privileged IPC services Implement operation-specific protected host-
resource brokers
Credential vaults and key managers Keep reusable credentials out of
lower-trust sandbox processes Controlled network and application
gateways
Enforce selected external request and resource constraints
Restricted filesystem brokers Verify actual resource identity before
protected mutation
5.5.3.77. Original Global Page 2168
Transactional databases Maintain current privilege, Candidate Act,
finality, and consumption state Authenticated structured
authorization records
Express original task and operation-specific permissions
Deterministic JSON or CBOR representations
Commit typed operation and privilege-transition descriptors Hardware
device controllers Enforce actual command finality where qualified
Protected deployment and artifact registries
Control the transition from generated artifacts to effective external
resources
Important PHOSITA Implementation Qualification
System-call filtering may reduce kernel attack surface but is not
automatically a complete sandbox.
A syscall notification supervisor that inspects mutable process-
memory arguments must not be assumed to provide race-free
consequential authorization solely by permitting the original syscall
to continue.
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A stronger implementation may use a protected broker that performs
the operation using qualified stable arguments, a sufficiently
enforcing kernel resource restriction, or an independent actual
destination-side control.
A filesystem policy may not automatically constrain all previously
opened resource handles.
A network gateway cannot verify hidden remote business operations
that it does not observe or control.
A virtual-machine boundary does not automatically constrain every
privileged host service acting on the guest's behalf.
The selected implementation must establish the actual protection
properties on which its finality guarantees depend.
Non-Limiting Reference Combination
Autonomous agent → restricted sandbox → protected boundary classifier
→ consequential Candidate Act → non-effective hold → current source-
authority and coverage validation → operation-bound privilege
transition → scoped non-bearer finality → protected broker or actual
resource sink → actual-operation reconstruction → sink-local
consumption → controlled external consequence.
Existing sandbox and operating-system technologies provide important
practical components.
The proposed distinguishing technical relationship is the conversion
of a sandbox-escaping operation into a separately authorized,
operation-bound consequential effect whose privilege and finality are
independently established and verified at the actual resource
boundary, rather than relying upon sandbox confinement or tool access
alone.
5.6. Embodiment 26: Tool Runtime Installation, Upgrade, Rollback and
Generation-Safe Effectuation
Original source global pages 2169–2245; attachment TECHNICAL
SPECIFICATION -2012-2566.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.6.1. Architecture Diagram: Protected Components and Trust Boundaries
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[Installed tool and runtime identity]
|
[Authenticated update or install manifest]
|
[Protected runtime and tool version registry]
|
[Revalidate changed effect contract and paths]
|
[Invalidate stale approval/coverage generation]
|
[Protected Finality Sink checks current tool effect]
|
[Effect or fail-closed]
Figure 11: Embodiment 26: Tool Runtime Installation, Upgrade,
Rollback and Generation-Safe Effectuation: architecture
5.6.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Runtime/tool modified or restored]
|
<Update source and target integrity valid?>--NO-->[REFUSE]
| YES
<Operation semantics unchanged or requalified?>--NO-->[REVALIDATE]
| YES
<Coverage/authority generations current?>--NO-->[FENCE]
| YES
<Actual FS resource target/current state match?>--NO-->[REFUSE]
| YES
[Consume fresh scoped authority / effect]
Figure 12: Embodiment 26: Tool Runtime Installation, Upgrade,
Rollback and Generation-Safe Effectuation: operational decision
flow
5.6.3. Page-Indexed Original Technical Text
5.6.3.1. Original Global Page 2169
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
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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:
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Installation of a newly obtained tool; Replacement of an
executable; Modification of a dependency; Change of a dynamically
linked library;
5.6.3.2. Original Global Page 2170
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.
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.
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2171
In a principal implementation, the software-lifecycle controller
qualifies an executable artifact before installation or activation.
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.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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:
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. Original Global Page 2172
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;
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
(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;
(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. Original Global Page 2173
The embodiment does not claim as individually new:
Software digital signatures;
Code signing;
Build provenance;
Package management;
Secure software updates;
Version pinning;
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Runtime attestation;
Dependency scanning;
Reproducible builds;
Container image digests;
Configuration management;
Or conventional access-control enforcement.
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. Original Global Page 2174
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.
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
5.6.3.7. Original Global Page 2175
| 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
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.8. Original Global Page 2176
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.
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.
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2177
Executable code may change during a long-running task.
26.2.14 — Shared Library Replacement
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.
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
26.2.25 — Policy and Tool Version Skew
5.6.3.10. Original Global Page 2178
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.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2179
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.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2180
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;
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
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. Original Global Page 2181
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
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2182
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
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.15. Original Global Page 2183
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
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
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
5.6.3.16. Original Global Page 2184
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
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2185
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
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2186
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;
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
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. Original Global Page 2187
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)) ]
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
where:
(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.
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. Original Global Page 2188
The effective runtime identity must represent the properties actually
material to the specified operation.
26.8 — PROTECTED TOOL INSTALLATION RECORD
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2189
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
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
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. Original Global Page 2190
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
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
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. Original Global Page 2191
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.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2192
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.
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2193
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) ]
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2194
A required attestation result becomes stale;
A generation floor is violated;
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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;
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.27. Original Global Page 2195
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.
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.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2196
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
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.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
26.19 — DUAL-GENERATION OPERATION
A rolling deployment may temporarily maintain two runtime
generations.
5.6.3.29. Original Global Page 2197
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
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;
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2198
Relevant runtime evidence may identify the effective loaded
generation.
26.20.2 — Material Change
A material hot reload triggers applicable finality fencing.
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;
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2199
The applicable Candidate Act remains fenced when a mandatory
dependency cannot be sufficiently qualified.
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
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
5.6.3.32. Original Global Page 2200
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
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
26.24.1 — Signature
May authenticate a key-authorized endorsement of particular bytes.
26.24.2 — Provenance
5.6.3.33. Original Global Page 2201
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
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2202
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:
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2203
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
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
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. Original Global Page 2204
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;
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2205
A runtime generation;
A plugin;
A privileged broker;
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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.
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.38. Original Global Page 2206
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.
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
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2207
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.
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.
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
5.6.3.40. Original Global Page 2208
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.
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2209
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.
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. Original Global Page 2210
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() })
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2211
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.
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. Original Global Page 2212
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.
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2213
.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.
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. Original Global Page 2214
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() })
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2215
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(
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. Original Global Page 2216
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()
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2217
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
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.
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.50. Original Global Page 2218
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.
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.
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2219
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.
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.
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2220
The broker independently reconstructs the actual request and verifies
scoped finality.
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
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2221
An earlier finality reference was established under the preceding
module generation.
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.
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
Expected demonstrable result: Emergency software recovery can be
separated from rollback of protected consequential authority.
5.6.3.54. Original Global Page 2222
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.
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2223
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.
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2224
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.
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2225
Expected demonstrable result: Historical real-effect evidence and
current successor tool authority remain logically separate.
26.63 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
5.6.3.58. Original Global Page 2226
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.
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
5.6.3.59. Original Global Page 2227
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.
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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. Original Global Page 2228
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.
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
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.
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2229
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.
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.
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2230
Test 70 — Removal of Protected Consumption: Attempt to reuse
authority across active generations.
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;
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
5.6.3.63. Original Global Page 2231
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;
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
Version B preserves the original request schema but additionally
attempts a persistent record modification.
26.65.6 — Transition Evidence
5.6.3.64. Original Global Page 2232
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
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2233
26.66.4 — Runtime Attestation
A current measured-runtime claim supplies selected execution-state
evidence.
26.66.5 — Dependency-Closure Verification
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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.
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
26.66.16 — Tool Plugin Lifecycle
5.6.3.66. Original Global Page 2234
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
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.
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2235
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.
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.
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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.
5.6.3.68. Original Global Page 2236
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
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2237
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.
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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.
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.6.3.70. Original Global Page 2238
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
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
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2239
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:
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:
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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;
5.6.3.72. Original Global Page 2240
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
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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. Original Global Page 2241
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
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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-
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. Original Global Page 2242
68. The Finality Sink independently reconstructs the actual pending
consequential
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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.
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2243
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.
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.
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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. Original Global Page 2244
Features from compatible embodiments may be combined without making
every optional feature mandatory.
26.72 — FINAL TECHNICAL CHARACTERIZATION
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.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
cause protected selective fencing and current revalidation,
operation-specific non-bearer finality is reconstituted where
required, and an independent
5.6.3.77. Original Global Page 2245
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
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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
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 33: Protected Security-Policy Mutation and
Configuration-Change Enforcement
Original source global pages 2826–2913; attachment TECHNICAL
SPECIFICATION -2567-3101.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.1. Architecture Diagram: Protected Components and Trust Boundaries
[Agent proposes policy/configuration mutation CA]
|
[Separate competent meta-authority checker]
|
[Policy dependency + change-impact graph]
|
[Protected staged/non-effective update]
|
[Policy and coverage generation transition]
|
[Sink verifies actual policy/resource consequence]
|
[Qualified activation or refusal]
Figure 13: Embodiment 33: Protected Security-Policy Mutation and
Configuration- Change Enforcement: architecture
5.7.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Agent requests allow-rule or kernel-policy change]
|
<Independent meta-authority permits change?>--NO-->[REFUSE]
| YES
<Dependent CA / coverage impact qualified?>--NO-->[HOLD]
| YES
[Stage and commit qualified policy generation]
|
<Affected effects revalidated at sink?>--NO-->[FENCE]
| YES
[Scoped change finality and controlled activation]
Figure 14: Embodiment 33: Protected Security-Policy Mutation and
Configuration- Change Enforcement: operational decision flow
5.7.3. Page-Indexed Original Technical Text
5.7.3.1. Original Global Page 2826
EMBODIMENT 33
PROTECTED AUTONOMOUS POLICY AND CONFIGURATION EVOLUTION WITH CHANGE-
IMPACT DEPENDENCY ANALYSIS, NON-SELF-AUTHORIZING POLICY MUTATIONS,
AND EXECUTION-FINALITY ACROSS LIVE RULE UPDATES
33.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Systems, Methods, and Apparatus for Governing Autonomous Security-
Policy and Configuration Changes Using Protected Meta-Authority
Separation, Policy-Mutation Candidate Acts, Pre-Activation Non-
Effective States, Typed Semantic Change-Impact Analysis, Operation-
Specific Policy Dependency Graphs, Authenticated Policy and
Enforcement Generations, Two-Stage Policy Activation and
Consequential Effectuation, Protected Anti-Rollback and Conflict
Fencing, Independent Current-Policy Validation, Scoped Non-Bearer
Finality Enablement, and Actual Finality-Sink Reconstruction and
Consumption Across Live Policy Transitions
33.0.1 — General Technical Description
The present Embodiment 33 discloses systems, methods, apparatus,
protected computing components, policy registries, authorization
engines, configuration controllers, administrative authority
services, autonomous policy-generation systems, policy dependency
analyzers, protected policy-activation controllers, distributed
enforcement gateways, versioned resource controllers, and independent
Finality Sinks configured to govern consequential operations
involving dynamic security-policy and operational-configuration
changes.
A computational workload may comprise:
An autonomous artificial-intelligence agent;
A language-model-based administrator;
An enterprise automation controller;
A cloud infrastructure agent;
A software-development and deployment agent;
A multi-agent orchestration system;
A network-management agent;
A database-administration service;
A credential-management agent;
A security-response automation system;
A robotic controller;
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.2. Original Global Page 2827
An industrial control service;
Or another computational component capable of proposing or performing
operations governed by mutable policies.
Such workloads may encounter policies controlling:
Resource access;
Authentication;
Credential exercise;
Tool invocation;
Network egress;
File modification;
Database mutation;
Cloud-resource administration;
Data disclosure;
Payment authorization;
Human approval requirements;
Agent delegation;
Execution environments;
Memory persistence;
Model-to-tool permissions;
Device control;
And other consequential operations.
Policies may be implemented through:
Access-control lists;
Role-based authorization;
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Attribute-based authorization;
Policy-as-code;
5.7.3.3. Original Global Page 2828
Admission-control rules;
Firewall configuration;
Network routing and filtering rules;
Credential broker policy;
Runtime sandbox settings;
Configuration files;
Database permissions;
Application authorization logic;
Hardware command constraints;
Or other enforceable representations.
A security policy may change during autonomous computation.
A resource owner may revoke a permission.
An administrator may replace an earlier authorization rule.
A cloud system may activate a new policy bundle.
An automated controller may modify a network egress restriction.
An agent may propose a new credential permission.
A runtime may change tool allowlists.
A software update may modify policy interpretation.
A configuration change may disable or redirect an enforcement
gateway.
A new schema may alter the meaning of existing policy fields.
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A distributed service may activate different policy revisions at
different times.
These circumstances present technical problems extending beyond the
ordinary creation or deployment of policy files.
A workload may be authorized to recommend a policy change but lack
authority to activate it.
A policy-generation agent may produce a rule that grants itself
additional privileges.
5.7.3.4. Original Global Page 2829
The same agent may then invoke the newly permitted operation.
A policy-management service may possess broad technical configuration
permissions despite being authorized only for a particular bounded
change.
A policy may be syntactically correct but semantically broader than
intended.
A seemingly narrow change may affect several resource classes because
of inheritance, wildcards, default rules, implicit role membership,
or changed interpretation.
A policy update may preserve the same text while changing its meaning
because the schema or policy interpreter changed.
A signed policy bundle may be authentic yet still include a rule that
the originating principal did not authorize.
A previously permitted consequential operation may be pending when a
new policy restricts the operation.
An operation that was previously denied may become technically
permitted under a newly activated rule, although the originating task
has not received any new authority.
A policy rollout may reach one gateway before another.
An agent may select a gateway running an obsolete permissive policy.
A security configuration may be rolled back to a version that
permitted operations subsequently prohibited.
Das Expires 29 April 2027 [Page 439]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A policy mutation may disable the very controller responsible for
verifying future policy mutations.
An authorization decision may be obtained before an update while the
actual resource operation occurs after it.
A policy decision may be logged as allowed even when the actual
resource operation has changed materially by the time it reaches the
receiving resource.
The present embodiment provides a protected architecture in which
policy evolution is separated from both the authority to enact a
policy and the authority to perform consequential operations governed
by that policy.
A protected originating authority service identifies the principal
and administrative permissions applicable to a proposed policy or
configuration change.
A protected meta-authority controller determines which principals or
services are competent to change specific policy classes.
A policy-generation agent may propose new rules, but the proposed
policy remains non-effective until independently validated.
5.7.3.5. Original Global Page 2830
The proposed change is represented as a Policy-Mutation Candidate
Act.
A protected semantic change analyzer compares the current policy and
proposed policy using the relevant schema, resource attributes,
policy-composition rules, and interpreter versions.
A protected dependency controller identifies the existing Candidate
Acts, resource classes, sessions, credentials, delegations, and
effectuation routes whose authorization may depend upon the changed
policy.
A material change activates appropriate fencing of affected pending
finality.
The proposed policy may be staged, tested, signed, distributed, or
evaluated in a shadow environment.
These activities provide qualified evidence but do not automatically
authorize its activation.
Das Expires 29 April 2027 [Page 440]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An independent protected policy-activation Finality Sink verifies the
actual policy change, the competent source authority, the effect of
the change, applicable mandatory restrictions, and protected
activation state.
The activation may be committed under a qualified authoritative
generation.
A separate operation-specific controller independently revalidates
consequential Candidate Acts under the policy generation required at
their actual effectuation boundary.
A newly activated policy cannot independently enlarge the original
task's source authorization.
A policy modification granting new tool access does not automatically
constitute permission to exercise that tool for a consequential act.
Where required, new scoped non-bearer finality enablement is
constituted after current source, policy, resource, and operation
validation.
At the actual receiving-resource boundary, the independent Finality
Sink reconstructs the pending operation and verifies the current
applicable policy, resource identity, originating source grant,
protected enablement, and sink-local consumption.
Accordingly, a protected policy mutation may become effective only
through a valid policy-activation procedure, and a separate
consequential operation governed by the policy may become effective
only through its own actual resource finality.
33.0.2 — Fundamental Technical Principle
Authority to modify a policy is not automatically authority to
perform every action permitted by that policy.
Further:
A policy file is not its own authorization to become effective.
5.7.3.6. Original Global Page 2831
A policy-generation agent cannot independently grant itself
additional consequential authority.
A successful policy syntax check does not establish that the proposed
rule preserves intended security restrictions.
Das Expires 29 April 2027 [Page 441]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A valid signature on a policy bundle does not establish that the
signer was competent to authorize every consequence of the bundle.
A successfully activated policy does not automatically enlarge the
original principal's task grant.
A previously successful authorization decision does not automatically
survive a material policy change.
A rollback does not automatically restore previously revoked or
consumed authority.
A policy update does not guarantee immediate enforcement at
independently operated resource sinks unless the relevant activation
and consistency mechanism provides that guarantee.
And a Finality Sink must not release a consequential operation solely
because an upstream agent or policy engine previously reported an
affirmative decision.
33.0.3 — Principal Candidate Inventive Combination
A representative technical combination comprises:
(a) an originating source-authorized consequential authority
envelope;
(b) a protected meta-authority registry defining who may modify
particular policy classes;
(c) a policy or configuration mutation represented as a Candidate
Act;
(d) an enforceable pre-activation Non-Effective State;
(e) protected typed semantic evaluation of the proposed policy
change;
(f) a dependency graph identifying Candidate Acts and enforcement
paths affected by the changed rules;
(g) operation-specific fencing of affected pending authority;
(h) authenticated policy content, schema, interpreter, and activation
generations;
(i) a protected policy-activation Finality Sink;
Das Expires 29 April 2027 [Page 442]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
(j) independent qualification of actual policy deployment and
activation;
(k) current source-authority validation for consequent resource
operations;
5.7.3.7. Original Global Page 2832
(l) scoped non-bearer finality enablement bound to the applicable
operation and policy state;
(m) independent actual resource-sink reconstruction;
(n) sink-side protected consumption under current policy, resource,
and revocation conditions.
33.0.4 — Candidate Technical Distinction
The embodiment does not claim as individually new:
Policy-as-code;
Configuration management;
Signed policy bundles;
Policy validation;
Policy diffing;
Shadow evaluation;
Canary deployment;
Administrative approval;
Role-based access control;
Admission controllers;
Configuration versioning;
Transactional updates;
Or policy rollback.
Das Expires 29 April 2027 [Page 443]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The candidate distinguishing arrangement concerns the operation-
specific coupling of protected policy mutation, change-impact
dependency analysis, selective pending-finality invalidation,
independent policy activation, and separate resource-side actual-
effect enforcement.
33.0.5 — Relationship to Earlier Embodiments
The present embodiment may incorporate foundational Candidate Act,
Non-Effective State, protected source authority, independent
execution-time validation, scoped non-bearer finality, and sink-local
consumption mechanisms.
5.7.3.8. Original Global Page 2833
It may additionally incorporate:
Multi-agent delegation and shared authority;
Qualified approval quorums;
Resource ownership and administrative continuity;
Credential rotation and current credential-generation checks;
Persistent-memory authority separation;
Protected resource identity;
Revocation race handling;
And crash-consistent effect recovery.
The focused contribution concerns live evolution of the rules and
enforcement configurations that govern those other mechanisms.
33.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v PROTECTED META-AUTHORITY | v POLICY-
GENERATION AGENT | v PROPOSED POLICY CHANGE | v POLICY-MUTATION
CANDIDATE | v NON-EFFECTIVE HOLD | v PROTECTED POLICY VALIDATOR |
+----------+----------+ | | v v SEMANTIC CHANGE AUTHORITY AND IMPACT
ANALYSIS SCOPE VALIDATION | | +----------+----------+
Das Expires 29 April 2027 [Page 444]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.9. Original Global Page 2834
| v POLICY DEPENDENCY GRAPH | v AFFECTED ACT FENCING | v POLICY
ACTIVATION FINALITY | v CURRENT POLICY GENERATION | v LIVE
ENFORCEMENT CONTROLLERS | v PENDING RESOURCE CANDIDATE | v CURRENT
SOURCE + POLICY + RESOURCE CHECK | v NON-BEARER FINALITY | v ACTUAL
FINALITY SINK | v RECONSTRUCT REAL OPERATION | v SINK-LOCAL
VERIFICATION AND CONSUMPTION | v CONTROLLED REAL EFFECT
This diagram is illustrative and non-limiting.
The policy-validation and resource-finality functions may be
implemented in separate or suitably integrated protected domains.
33.1 — TECHNICAL FIELD
The invention relates to autonomous policy administration, dynamic
access-control systems, security configuration management, policy-as-
code, protected policy lifecycle control,
5.7.3.10. Original Global Page 2835
authorization versioning, distributed enforcement, live configuration
updates, resource-effect finality, and anti-bypass execution control.
More particularly, it concerns preventing unauthorized consequential
authority from arising through autonomous modification, activation,
rollback, or reinterpretation of security rules.
33.2 — SPECIFIC TECHNICAL PROBLEMS
33.2.1 — Self-Authorizing Policy Mutation
An agent may grant itself permission to perform a currently
prohibited operation.
33.2.2 — Policy Proposal/Activation Confusion
Permission to propose a change may be mistaken for permission to
deploy it.
33.2.3 — Policy Deployment/Resource Authority Confusion
Permission to activate a policy may be mistaken for authority to
exercise every newly permitted operation.
33.2.4 — Broad Technical Administration
Das Expires 29 April 2027 [Page 445]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A policy-deployment credential may technically permit more changes
than the actual task authorizes.
33.2.5 — Syntactic Validity Versus Permission
A well-formed policy may materially weaken required security
constraints.
33.2.6 — Wildcard Expansion
A narrow-looking rule may cover unintended resources or operations.
33.2.7 — Implicit Role Expansion
A changed role relationship may indirectly grant new permissions.
33.2.8 — Default-Allow Transition
A change in default evaluation behavior may broaden access
unexpectedly.
33.2.9 — Schema Interpretation Drift
A policy may be evaluated under a new schema that changes its
meaning.
33.2.10 — Interpreter Semantic Drift
5.7.3.11. Original Global Page 2836
The same policy text may be interpreted differently following an
engine upgrade.
33.2.11 — Policy Composition Conflict
Separate rule sets may produce contradictory permission outcomes.
33.2.12 — Policy Update Race
An operation may be validated under one revision and effectuate under
another.
33.2.13 — Partial Policy Activation
Some enforcement points may adopt a new revision before others.
33.2.14 — Selective Old-Policy Routing
Das Expires 29 April 2027 [Page 446]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent may target a permissive stale gateway.
33.2.15 — Old Approval Replay
A previously approved Candidate Act may be executed after the policy
changes.
33.2.16 — Old Denial Circumvention
A previously denied operation may be retried under a new permissive
policy without current source permission.
33.2.17 — Policy Rollback
An earlier permissive revision may be restored.
33.2.18 — Rollback of Revocation
Restoration may remove an important later restriction.
33.2.19 — Policy-Generation Replay
A previous policy package may be reintroduced as though it were
current.
33.2.20 — Enforcement Disablement
A policy change may remove an important gateway, validation hook, or
protected control.
33.2.21 — Monitoring-Only Substitution
A mandatory enforcing component may be replaced with logging or
advisory evaluation.
33.2.22 — Approval-Rule Downgrade
An agent may reduce the number or role of required approving
principals.
5.7.3.12. Original Global Page 2837
33.2.23 — Credential-Policy Expansion
A configuration change may permit broader secret or token use.
33.2.24 — Memory-Policy Expansion
Das Expires 29 April 2027 [Page 447]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A change may permit untrusted information to become persistent
operational authority.
33.2.25 — Agent Delegation Expansion
A policy change may permit previously prohibited child-agent actions.
33.2.26 — Tool-Contract Change
A policy change may permit new consequential tool methods.
33.2.27 — Resource-Identity Rebinding
An apparently unchanged policy reference may apply to a different
actual resource.
33.2.28 — Dynamic Admission Modification
A deployment control may be disabled before a sensitive configuration
is admitted.
33.2.29 — Policy Dependency Omission
The system may fail to identify a pending operation affected by a
changed rule.
33.2.30 — Excessive Global Invalidation
An unrelated rule update may unnecessarily stop legitimate
operations.
33.2.31 — Policy Version Ambiguity
A human-readable version name may be reused or misreported.
33.2.32 — Signed Wrong Artifact
A valid signature may authenticate a different policy package from
the one actually activated.
33.2.33 — Stale Administrative Authority
A former policy administrator may retain an authenticated update
interface.
33.2.34 — Distributed Policy Partition
Different replicas may have inconsistent current policy state.
Das Expires 29 April 2027 [Page 448]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.2.35 — Fail-Open Configuration
5.7.3.13. Original Global Page 2838
A missing policy service may cause an enforcement gateway to allow an
operation.
33.2.36 — Unbounded Emergency Change
An emergency policy exception may become permanent or broader than
authorized.
33.2.37 — Self-Referential Policy
A policy may change the authority rules governing its own adoption.
33.2.38 — Circular Policy Dependency
Several policies may refer to one another in a way that obscures
effective authority.
33.2.39 — Policy-Test Overconfidence
Passing a test suite may be mistaken for proof that every relevant
consequence is permitted.
33.2.40 — Shadow Evaluation Confusion
A shadow-mode approval may be mistaken for enforced actual
permission.
33.2.41 — Audit/Effect Confusion
An accepted policy-deployment event may be mistaken for proof that
all resource sinks are enforcing it.
33.2.42 — External Effect During Policy Rollout
An irreversible operation may occur while relevant policy updates are
still propagating.
33.2.43 — Recovery Under Obsolete Rules
A restarted service may load an old policy without current generation
validation.
33.2.44 — Consumed Authority Restoration
Das Expires 29 April 2027 [Page 449]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A policy rollback may be treated as a new opportunity to repeat an
already consumed operation.
33.2.45 — Technical Objective
The candidate objective technical problem is:
How to permit authorized autonomous evolution of security policies
and operational configurations while preventing policy changes from
creating unauthorized consequential authority, ensuring affected
pending operations are revalidated under the applicable current rule
generations, and enforcing both policy activation and actual resource
effects through protected independent finality boundaries.
5.7.3.14. Original Global Page 2839
33.3 — ESTABLISHED TECHNICAL FOUNDATIONS
33.3.1 — Policy-as-Code
Existing systems can represent authorization rules as executable or
declarative policy.
Such representation does not inherently determine whether an
autonomous workload possesses authority to change the policy or
exercise newly permitted operations.
33.3.2 — Signed Policy Bundles
Existing mechanisms can authenticate policy packages.
A valid signature does not independently establish that the proposed
permissions comply with the original principal's task authorization.
33.3.3 — Schema Validation
Existing policy languages may verify that rules conform to a declared
type or entity schema.
Type correctness is distinct from whether the actual rule grants an
unauthorized effect.
33.3.4 — Staged Policy Rollout
Existing deployment systems may activate rules in stages.
Staging does not inherently impose one globally atomic authority
transition across all receiving resource services.
Das Expires 29 April 2027 [Page 450]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.3.5 — Admission Control
Existing platform controls may validate proposed configuration
changes.
The application must still establish the coverage and failure
behavior of the chosen actual enforcement paths.
33.3.6 — Configuration Versioning
Existing systems maintain revisions and rollback capabilities.
Rollback of policy bytes does not automatically justify rollback of
current source authority, revocation, or consumed finality.
33.3.7 — Existing Policy Engines
Authorization engines can determine whether a request is allowed
under the rules they evaluate.
5.7.3.15. Original Global Page 2840
The proposed combination separately requires an authorized policy
update and a current actual-effect finality decision.
33.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
1. Protected Originating Authority Registry. 2. Protected Meta-
Authority Controller. 3. Policy and Configuration Registry. 4.
Policy-Mutation Candidate Act Constructor. 5. Non-Effective Policy
Hold Controller. 6. Typed Policy Schema and Interpreter Registry. 7.
Semantic Change-Impact Analyzer. 8. Protected Policy Dependency
Graph. 9. Policy-Effect Envelope Constructor. 10. Current
Administrative Authority Validator. 11. Policy-Change Conflict
Resolver. 12. Mandatory Security-Invariant Controller. 13.
Protected Policy Activation Controller. 14. Policy Activation
Finality Sink. 15. Enforcement-Generation Registry. 16. Pending
Candidate Act Fence Controller. 17. Current Operation Policy
Validator. 18. Scoped Non-Bearer Finality Controller. 19. Actual
Resource Finality Sink. 20. Protected Revocation and Consumption
Controller. 21. Distributed Policy Rollout Monitor. 22. Qualified
Policy and Resource Outcome Journal.
These components may be distributed or integrated according to the
selected protection model.
Das Expires 29 April 2027 [Page 451]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.5 — TECHNICAL DEFINITIONS
33.5.1 — Protected Policy Mutation
A Protected Policy Mutation, or PPM-33, means a proposed
consequential change to an authorization or enforcement rule governed
by protected source authority.
33.5.2 — Policy-Mutation Candidate Act
A Policy-Mutation Candidate Act, or PMCA-33, means a Candidate Act
representing the actual proposed policy or configuration change.
33.5.3 — Protected Meta-Authority
5.7.3.16. Original Global Page 2841
Protected Meta-Authority, or PMA-33, means the independently
established authority governing who may create, modify, activate,
revoke, or replace selected policy rules.
33.5.4 — Meta-Authority Root
A Meta-Authority Root means a protected trust or competence source
used to establish policy-administration authority independently of
the rule being modified.
33.5.5 — Policy Proposal Authority
Policy Proposal Authority means permission to prepare or recommend a
policy change without necessarily activating it.
33.5.6 — Policy Activation Authority
Policy Activation Authority means permission to make a selected
qualified rule or configuration effective.
33.5.7 — Resource Effect Authority
Resource Effect Authority means current source authorization for an
actual consequence governed by the policy.
33.5.8 — Non-Self-Authorizing Policy Rule
A Non-Self-Authorizing Policy Rule means a policy that cannot
independently establish its own adoption authority.
33.5.9 — Policy Content Generation
Das Expires 29 April 2027 [Page 452]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Policy Content Generation, or PCG-33, means a protected version of
the actual policy content.
33.5.10 — Policy Schema Generation
A Policy Schema Generation, or PSG-33, means the current qualified
version of the policy's interpretation schema.
33.5.11 — Policy Interpreter Generation
A Policy Interpreter Generation, or PIG-33, means the qualified
version of the evaluator or execution semantics applicable to the
rule.
33.5.12 — Policy Activation Generation
A Policy Activation Generation, or PAG-33, means the authoritative
version at which the selected policy became effective.
33.5.13 — Enforcement Adoption Generation
5.7.3.17. Original Global Page 2842
An Enforcement Adoption Generation, or EAG-33, means the current
policy revision accepted and enforced by a particular protected
resource gateway.
33.5.14 — Policy Semantic Envelope
A Policy Semantic Envelope means the defined conditions and resource
effects permitted, restricted, or altered by a policy under a
qualified interpretation model.
33.5.15 — Semantic Policy Delta
A Semantic Policy Delta, or SPD-33, means a qualified description of
material authorization differences between policy versions.
33.5.16 — Policy Change-Impact Set
A Policy Change-Impact Set, or PCIS-33, means resources, operations,
identities, Candidate Acts, and enforcement paths potentially
affected by a change.
33.5.17 — Protected Policy Dependency Graph
Das Expires 29 April 2027 [Page 453]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A Protected Policy Dependency Graph, or PPDG-33, means a qualified
representation of dependencies between policy rules and operation-
specific effectuation conditions.
33.5.18 — Policy-Dependency Fence
A Policy-Dependency Fence, or PDF-33, means a protected restriction
withholding affected Candidate Acts following a material rule
transition.
33.5.19 — Policy Activation Finality Sink
A Policy Activation Finality Sink, or PAFS-33, means the protected
enforcement point controlling actual activation of a qualified policy
change.
33.5.20 — Actual Resource Finality Sink
An Actual Resource Finality Sink means the separate enforcement point
controlling a consequent real or persistent operation under current
authority.
33.5.21 — Dual-Finality Policy Evolution
Dual-Finality Policy Evolution means requiring appropriate protected
finality both for the policy mutation and for the resource effect
governed by it.
33.5.22 — Policy Change Competence
Policy Change Competence means the qualified scope of an
administrative principal's permission to modify selected rules.
33.5.23 — Protected Policy Invariant
5.7.3.18. Original Global Page 2843
A Protected Policy Invariant means a mandatory constraint on valid
policy and configuration changes.
33.5.24 — Policy Self-Elevation Attempt
A Policy Self-Elevation Attempt means a workload's attempt to create
its own missing execution or administrative authority through policy
modification.
33.5.25 — Enforcement-Route Integrity
Das Expires 29 April 2027 [Page 454]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Enforcement-Route Integrity means verification that the actual
consequential operation passes through a required protected
enforcement boundary.
33.5.26 — Policy Route Substitution
Policy Route Substitution means redirecting an effect-capable
operation to a different enforcement path with different controls.
33.5.27 — Policy Composition Conflict
Policy Composition Conflict means incompatible effective
authorization conditions among applicable policies.
33.5.28 — Policy Change Materiality
Policy Change Materiality means whether a proposed change affects a
mandatory authorization or effectuation predicate.
33.5.29 — Current Policy Witness
A Current Policy Witness means qualified evidence identifying the
applicable active policy content, schema, interpreter, and
enforcement state.
33.5.30 — Policy Generation Vector
A Policy Generation Vector means a protected tuple of current
content, schema, interpreter, activation, and enforcement
generations.
33.5.31 — Policy Activation Fence
A Policy Activation Fence means a restriction preventing an
unauthorized or incompatible policy package from becoming effective.
33.5.32 — Policy Rollback Nonresurrection
Policy Rollback Nonresurrection means preventing a restored prior
policy revision from reviving revoked, consumed, or otherwise invalid
consequential authority.
33.5.33 — Qualified Shadow Evaluation
Das Expires 29 April 2027 [Page 455]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.19. Original Global Page 2844
Qualified Shadow Evaluation means evaluating a proposed policy
without treating the simulated decision as actual resource
authorization.
33.5.34 — Qualified Policy Impact Test
A Qualified Policy Impact Test means a controlled experiment
comparing policy behavior under defined inputs and interpretation
assumptions.
33.5.35 — Enforcement Readiness Witness
An Enforcement Readiness Witness means qualified evidence concerning
which relevant enforcement components have accepted and are applying
a specified generation.
33.5.36 — Policy Rollout Cohort
A Policy Rollout Cohort means an identified subset of enforcement
services selected for a staged policy update.
33.5.37 — Policy Transition Quiescence
Policy Transition Quiescence means a qualified state concerning
affected pending operations and active effectuation paths during a
rule transition.
33.5.38 — Policy Revocation Generation
A Policy Revocation Generation means the applicable current protected
invalidation version affecting policy or operation eligibility.
33.5.39 — Policy-Dependent Candidate Act
A Policy-Dependent Candidate Act means a consequential operation
whose authorization depends upon one or more current protected policy
predicates.
33.5.40 — Policy-Bound Non-Bearer Enablement
Policy-Bound Non-Bearer Enablement means scoped finality authority
associated with the current required policy and actual operation.
33.5.41 — Policy Dependency Closure
Das Expires 29 April 2027 [Page 456]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Policy Dependency Closure means a qualified set of direct and
indirect rule dependencies relevant to an operation.
33.5.42 — Unknown Impact Fence
An Unknown Impact Fence means withholding affected operations when
mandatory policy consequences cannot be sufficiently qualified.
33.5.43 — Protected Rule Compiler
5.7.3.20. Original Global Page 2845
A Protected Rule Compiler means a component transforming a qualified
policy into an enforceable representation under a defined current
interpreter.
33.5.44 — Policy Semantic Equivalence
Policy Semantic Equivalence means a qualified determination that a
change preserves selected policy decisions across a specified domain
and assumptions.
33.5.45 — Policy Proof Scope
Policy Proof Scope means the defined domain within which a test,
formal check, or equivalence conclusion is valid.
33.5.46 — Policy Update Commit Receipt
A Policy Update Commit Receipt means qualified evidence concerning
the actual completed activation of a specified policy revision.
33.5.47 — Enforcement Adoption Receipt
An Enforcement Adoption Receipt means qualified evidence that a
specified enforcement component has accepted a particular policy
generation.
33.5.48 — Resource-Effect Receipt
A Resource-Effect Receipt means qualified evidence that a consequent
real operation was completed, distinct from policy activation
evidence.
33.5.49 — Policy-to-Effect Continuity
Das Expires 29 April 2027 [Page 457]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Policy-to-Effect Continuity means protected correspondence between
the current policy conditions applicable to a Candidate Act and the
actual operation verified at its receiving sink.
33.5.50 — Policy Authority Nonpromotion
Policy Authority Nonpromotion means preventing successful policy
preparation, signing, staging, or deployment from independently
creating original task authority for subsequent resource operations.
33.6 — FIVE DISTINCT LEVELS OF POLICY CONTROL
A principal implementation distinguishes:
Level 1 — Policy Drafting: An agent may generate or recommend rules.
Level 2 — Policy Validation: A protected service may evaluate the
proposed rules.
5.7.3.21. Original Global Page 2846
Level 3 — Policy Activation: A qualified authority permits the rules
to become effective.
Level 4 — Resource Authorization: Current applicable rules and
originating permission establish whether a particular act is
eligible.
Level 5 — Actual Resource Finality: The receiving resource
independently checks and consumes operation-specific effectuation
authority.
These levels are not interchangeable.
An agent with Level 1 authority does not automatically possess Level
3.
A policy activated at Level 3 does not create missing Level 4
originating source permission.
An affirmative Level 4 authorization does not automatically establish
completed Level 5 effectuation.
33.7 — PROTECTED META-AUTHORITY ROOT
A representative protected record comprises:
Das Expires 29 April 2027 [Page 458]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
PROTECTED_META_AUTHORITY_ROOT = { meta_authority_identifier,
competent_principal_identities, permitted_policy_classes,
permitted_rule_operations, forbidden_self_authorization_classes,
required_independent_approvals, mandatory_security_invariants,
protected_enforcement_requirements, permitted_activation_domains,
policy_revocation_conditions, current_meta_authority_generation,
protected_root_authentication }
33.7.1 — Independent Trust
The active policy being modified does not independently determine who
may authorize that modification when such self-reference would
violate the protected meta-authority model.
33.7.2 — Delegated Administration
A qualified administrator may receive bounded permission to change
selected rules.
33.7.3 — Privilege Expansion
5.7.3.22. Original Global Page 2847
Changes expanding the administrator's own consequential rights may
require separately competent authorization.
33.7.4 — Root Modification
A change to the meta-authority root itself requires a separately
protected process defined outside the authority being replaced.
33.8 — PROTECTED POLICY REGISTRY
A representative registry entry comprises:
PROTECTED_POLICY_RECORD = { policy_identifier,
actual_policy_content_digest, policy_content_generation,
policy_schema_identifier, policy_schema_generation,
policy_interpreter_identifier, policy_interpreter_generation,
applicable_resource_classes, applicable_operation_classes,
administrative_authority_reference, activation_generation,
current_revocation_generation, qualified_enforcement_routes,
protected_policy_authentication }
A policy's human-readable title or version label need not be
sufficient to identify its actual semantics.
Das Expires 29 April 2027 [Page 459]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The qualified policy record binds content, interpretation, and
activation state.
33.9 — POLICY MUTATION AS A CANDIDATE ACT
A proposed rule change may:
Add a permission;
Remove a permission;
Expand a resource set;
Change a required approval role;
5.7.3.23. Original Global Page 2848
Alter credential scope;
Disable a protected gateway;
Introduce a new external destination;
Replace a policy evaluation engine;
Or modify an enforcement configuration.
These changes can affect real-world operations.
A principal implementation therefore constructs a Policy-Mutation
Candidate Act before activation.
33.10 — POLICY-MUTATION CANDIDATE RECORD
POLICY_MUTATION_CANDIDATE = { candidate_act_identifier,
originating_task_grant_reference, requesting_agent_identity,
target_policy_identifier, current_policy_generation,
current_schema_generation, current_interpreter_generation,
proposed_policy_content_digest, proposed_rule_operations,
proposed_enforcement_scope, proposed_security_invariant_changes,
proposed_activation_domain, applicable_meta_authority_reference,
designated_policy_activation_sink, protected_candidate_authentication
}
The record identifies the actual intended modification.
Das Expires 29 April 2027 [Page 460]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent-generated natural-language rationale may accompany the
proposal but cannot substitute for verifying the operative rule
content.
33.11 — NON-EFFECTIVE POLICY HOLD
A proposed policy change is maintained separately from the live
authoritative rules.
The Non-Effective State may comprise:
5.7.3.24. Original Global Page 2849
A protected draft registry;
A staged configuration artifact;
A disabled policy bundle;
A test-only rule representation;
Or another state incapable of directly changing covered actual
resource permissions.
33.11.1 — Staging Is Not Activation
The presence of a policy package in storage does not make it
operative.
33.11.2 — No Unverified Direct Write
The proposing agent may not bypass protected activation through an
alternate policy-management interface.
33.11.3 — Controlled Promotion
The actual policy activation requires the designated protected sink.
33.12 — TYPED SEMANTIC POLICY ANALYSIS
A textual diff may fail to identify material security consequences.
For example:
OLD RULE: allow resource.read where resource.owner == requester NEW
RULE: allow resource.* where resource.owner == requester
A short textual change may permit destructive operations.
Das Expires 29 April 2027 [Page 461]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Similarly:
OLD RULE: allow send where destination in approved_destinations NEW
RULE: allow send where destination not in blocked_destinations
The new rule may expand permissions to previously unapproved
destinations.
5.7.3.25. Original Global Page 2850
A protected semantic analyzer therefore evaluates the proposed rule
according to a typed current policy model.
33.12.1 — Actual Decision Space
The analyzer identifies affected principals, operations, resources,
and context predicates.
33.12.2 — Interpretation
It uses the relevant schema and policy evaluation semantics.
33.12.3 — Qualification
Where the relevant domain cannot be exhaustively represented, the
analyzer records the limits of its findings.
33.12.4 — Unknown Consequence
An unresolved mandatory effect is not treated as proof of
harmlessness.
33.13 — POLICY SEMANTIC DELTA
A non-limiting semantic delta may comprise:
PROTECTED_SEMANTIC_POLICY_DELTA = { predecessor_policy_commitment,
successor_policy_commitment, applicable_schema_generations,
applicable_interpreter_generations, newly_permitted_effect_classes,
newly_denied_effect_classes, changed_role_memberships,
changed_resource_scopes, changed_mandatory_vetoes,
changed_enforcement_routes, affected_candidate_act_classes,
unverified_or_unknown_impact_classes, protected_delta_authentication
}
The delta distinguishes between syntactic and material changes.
Das Expires 29 April 2027 [Page 462]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A change is not considered nonmaterial solely because both policy
packages pass syntax validation.
33.14 — POLICY DECISION CORRESPONDENCE
5.7.3.26. Original Global Page 2851
A representative semantic relation is:
[ D_{\mathrm{old}}(p,a,r,c) ]
[ D_{\mathrm{new}}(p,a,r,c) ]
where:
(p) denotes the qualified principal;
(a) denotes the operation;
(r) denotes the resource;
And (c) denotes current contextual conditions.
A material policy difference may exist where:
[ D_{\mathrm{old}}(p,a,r,c) \ne D_{\mathrm{new}}(p,a,r,c) ]
for an applicable consequential operation.
33.14.1 — Known Domain
The comparison may be performed exhaustively over a sufficiently
bounded domain.
33.14.2 — Symbolic Domain
A qualified symbolic or formal verification engine may evaluate
selected properties.
33.14.3 — Test-Based Domain
A test suite may establish differences for the tested cases.
33.14.4 — No Unsupported Completeness
Passing finite tests does not prove semantic equivalence over all
possible resource and context states.
Das Expires 29 April 2027 [Page 463]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.27. Original Global Page 2852
33.15 — POLICY CHANGE-IMPACT DEPENDENCY GRAPH
A protected dependency graph may associate:
Policies;
Source grants;
Credential permissions;
Tool contracts;
Agent delegations;
Memory classifications;
Network destinations;
Resource classes;
And pending Candidate Acts.
For example:
POLICY P1 | +-- Agent A's network-send permission | +-- Credential
Broker B's allowed destinations | +-- Pending Candidate Act C1 | +--
Pending Candidate Act C2 POLICY P2 | +-- File resource R7 | +--
Pending Candidate Act C3
Changing P1 may require revalidation of C1 and C2.
Changing P2 may affect C3 without necessarily invalidating C1 or C2.
33.16 — OPERATION-SPECIFIC IMPACT PROJECTION
5.7.3.28. Original Global Page 2853
[ \operatorname{Dep}(CA) ]
denote the qualified policy dependencies of a Candidate Act.
[ \Delta P ]
denote the material policy-change set.
A pending act may require fencing where:
Das Expires 29 April 2027 [Page 464]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[ \operatorname{Dep}(CA)\cap\Delta P\ne\varnothing ]
under the applicable typed dependency model.
The expression is illustrative.
33.16.1 — Relevant Change
An affected operation is fenced pending current validation.
33.16.2 — Unrelated Change
An unrelated operation may continue under current valid authority.
33.16.3 — Unknown Dependency
Where mandatory dependency completeness cannot be established, the
system may apply a broader protected fence.
33.16.4 — Candidate Technical Effect
The architecture can prevent stale-policy effects without requiring
every policy update to halt every autonomous task.
33.17 — POLICY-MUTATION AUTHORITY CHECK
A policy agent may propose modifying a rule.
A protected validator determines whether the current originating
principal and competent administrative authority permit the exact
modification.
5.7.3.29. Original Global Page 2854
33.17.1 — Additive Permission
A new allow rule may require qualified authority to expand access.
33.17.2 — Restrictive Change
A deny rule may still require qualified authority because it can
materially affect resource availability.
33.17.3 — Enforcement Removal
Disabling a mandatory security control requires specific competent
permission and may be prohibited by a protected invariant.
Das Expires 29 April 2027 [Page 465]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.17.4 — Source Task
A generic instruction to improve performance does not automatically
authorize weakening security controls.
33.18 — NON-SELF-AUTHORIZING POLICY MUTATIONS
An agent may encounter a denied consequential operation.
It may propose a rule granting itself the missing permission.
The system distinguishes:
A request to change policy;
Authority to approve that change;
And authority to perform the subsequently permitted resource
operation.
33.18.1 — Separate Candidate Acts
The policy mutation is one Candidate Act.
The subsequent resource operation is another Candidate Act.
33.18.2 — Protected Meta-Authority
The proposing agent cannot use the proposed new policy as authority
to approve its own activation.
33.18.3 — Independent Source Authority
After valid activation, the external operation still requires its
original task authorization.
5.7.3.30. Original Global Page 2855
33.18.4 — No Bootstrap
A denied operation cannot automatically become authorized merely
because the same workload generated a more permissive rule.
33.19 — POLICY ACTIVATION AS ACTUAL CONSEQUENCE
The actual activation of a policy is distinct from:
Writing a file;
Das Expires 29 April 2027 [Page 466]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Uploading a bundle;
Passing validation;
Obtaining approval;
Or distributing configuration bytes.
The protected policy activation sink verifies the actual operative
package and transition.
33.19.1 — Content Identity
The activated package corresponds to the qualified Candidate Act.
33.19.2 — Schema and Interpreter
The package is interpreted under the qualified current model.
33.19.3 — Competent Authority
The modification has the required protected permission.
33.19.4 — Mandatory Invariants
Controlling security restrictions remain satisfied.
33.19.5 — Activation Generation
The committed policy version is distinguished from obsolete versions.
33.20 — TWO-STAGE FINALITY
A stronger implementation uses two logically distinct consequential
boundaries.
33.20.1 — First Boundary: Policy Activation
5.7.3.31. Original Global Page 2856
The Policy Activation Finality Sink permits the rule change to become
effective.
33.20.2 — Second Boundary: Resource Effectuation
The Actual Resource Finality Sink permits a specific resource
operation under current source and policy conditions.
Das Expires 29 April 2027 [Page 467]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.20.3 — No Authority Conflation
Successful policy activation does not automatically enable every
possible resource operation permitted by the rule.
33.20.4 — No Retroactive Effect
A newly activated policy does not automatically establish that
operations attempted under the previous policy succeeded or failed.
33.21 — POLICY GENERATION VECTOR
A representative current policy vector comprises:
[ V_P=(G_C,G_S,G_I,G_A,G_E,G_R) ]
where:
(G_C) is policy content generation;
(G_S) is schema generation;
(G_I) is interpreter generation;
(G_A) is authoritative activation generation;
(G_E) is actual enforcement adoption generation;
And (G_R) is current relevant revocation generation.
These versions may be maintained separately.
33.21.1 — Same Text, Different Meaning
A schema or interpreter change may alter the policy outcome.
33.21.2 — Same Policy, Different Adoption
Different sinks may have adopted different revisions.
5.7.3.32. Original Global Page 2857
33.21.3 — Actual Enforcement
The sink verifies the qualified generation required for its
operation.
33.22 — CURRENT POLICY WITNESS
Das Expires 29 April 2027 [Page 468]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected witness may comprise:
CURRENT_POLICY_WITNESS = { actual_policy_content_digest,
policy_schema_digest, interpreter_identity, interpreter_generation,
authoritative_activation_generation, enforcement_sink_identity,
accepted_enforcement_generation, relevant_source_grant_generation,
current_revocation_generation, candidate_act_digest,
protected_witness_authentication }
The witness supplies verifiable context.
It does not independently create consequential authority.
33.23 — LIVE POLICY ROLLOUT
A policy update may be delivered to several enforcement locations.
A selected implementation may use:
A central protected activation service;
Versioned policy bundles;
Authenticated configuration notifications;
A staged rollout;
An enforcement-readiness registry;
And sink-local active-generation checks.
33.23.1 — Staged Rollout
5.7.3.33. Original Global Page 2858
Different cohorts may intentionally adopt different revisions for
qualified testing.
33.23.2 — Current Policy Selection
The operation must be evaluated under the policy that the governing
authorization model requires for the actual sink.
33.23.3 — Sensitive Transition
A protected fence may prevent affected operations until required
sinks establish current readiness.
Das Expires 29 April 2027 [Page 469]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.23.4 — No False Atomicity
Distribution of a signed package does not establish simultaneous
activation at independent nodes.
33.24 — ENFORCEMENT ADOPTION EVIDENCE
A sink may report which policy version it has accepted.
A representative record comprises:
PROTECTED_ENFORCEMENT_ADOPTION = { enforcement_sink_identity,
policy_identifier, active_policy_digest, schema_generation,
interpreter_generation, activation_generation,
local_adoption_generation, reported_enforcement_mode, current_status,
protected_adoption_authentication }
33.24.1 — Report Versus Enforcement
An adoption report is evidence of reported state.
33.24.2 — Trusted Enforcement
The claimed guarantee requires actual protected enforcement of the
selected revision.
33.24.3 — Monitoring-Only Mode
A component merely logging decisions does not satisfy a claim
requiring non-bypassable effectuation denial.
5.7.3.34. Original Global Page 2859
33.25 — POLICY ENFORCEMENT-ROUTE INTEGRITY
A configuration update may alter the route through which resource
operations pass.
For example:
An existing tool sends privileged requests through a protected
gateway.
A proposed change permits direct network access to the receiving
resource.
The new route may bypass the protected Finality Sink.
Das Expires 29 April 2027 [Page 470]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The change-impact controller identifies the removed mandatory
enforcement relationship.
The policy activation sink refuses the change unless an appropriately
authorized and technically equivalent enforcement mechanism is
established.
33.25.1 — Route as Protected Dependency
Mandatory effectuation paths are included in the impact analysis.
33.25.2 — Direct Access
A newly opened alternative path does not independently satisfy
existing protected finality requirements.
33.25.3 — Equivalent Enforcement
A replacement may be accepted if it actually preserves the required
properties.
33.26 — PROTECTED SECURITY INVARIANTS
A policy-transition controller may maintain invariants such as:
No consequential external operation without current original source
authority.
No unauthorized source-to-resource scope enlargement.
No reusable complete credential exposure to lower-trust agents where
prohibited.
No bypass of required Finality-Sink verification.
No restoration of consumed finality.
No unauthorized removal of mandatory revocation checks.
5.7.3.35. Original Global Page 2860
No approval-policy downgrade without competent authorization.
No substitution of a logging-only mechanism for a required
enforcement gate.
No unqualified expansion of resource or recipient scope.
Das Expires 29 April 2027 [Page 471]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invariants may be operation-specific.
They are not required to be universal to every possible
implementation.
33.27 — POLICY COMPILATION AND INTERPRETER CONTINUITY
An authorization rule may be compiled or translated into an
enforcement representation.
A policy text may remain unchanged while its runtime interpretation
changes.
The protected controller may bind:
Source rule digest;
Schema digest;
Compiler or interpreter generation;
Compiled artifact digest;
And actual sink adoption.
33.27.1 — Compiler Change
May require requalification of the effective authorization semantics.
33.27.2 — Schema Change
May affect resource, action, or principal interpretation.
33.27.3 — Result
A policy cannot be considered semantically unchanged solely because
its source file is identical.
33.28 — POLICY TESTING AND SHADOW EVALUATION
A proposed policy may be evaluated before activation.
The test environment may compare:
5.7.3.36. Original Global Page 2861
Actual current policy outcomes;
Das Expires 29 April 2027 [Page 472]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Proposed policy outcomes;
Known resource configurations;
Representative Candidate Acts;
Boundary cases;
Mandatory denial cases;
And expected authority constraints.
33.28.1 — Shadow Mode
The proposed policy is evaluated without controlling the actual
resource consequence.
33.28.2 — Security Test
May establish the outcome of specific cases.
33.28.3 — Formal Check
May establish particular properties under stated modeling
assumptions.
33.28.4 — Activation
Still requires protected authority and actual activation finality.
33.28.5 — No Proof by Passing Tests
A successful finite test suite does not guarantee absence of every
unauthorized permission expansion.
33.29 — IMPACT CLASSIFICATION
A protected semantic analyzer may classify changes as:
CLASS I — No material effect within a qualified stated domain.
CLASS II — Narrowing of selected permissions.
CLASS III — Expansion of selected permissions.
CLASS IV — Change to controlling approvals or vetoes.
CLASS V — Change to enforcement routing or failure behavior.
Das Expires 29 April 2027 [Page 473]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.37. Original Global Page 2862
CLASS VI — Change to schema or interpreter semantics.
CLASS VII — Unknown or insufficiently qualified effect.
These categories are illustrative.
A restrictive rule may still be consequential for availability.
A Class VII change requires additional analysis or appropriate
fencing where mandatory effects remain unknown.
33.30 — POLICY CHANGE CONFLICT
Two administrators or automation services may submit incompatible
changes.
For example:
One update permits external data release.
Another update prohibits the release.
Both may be individually authenticated.
The policy controller determines:
The current authoritative ordering;
Competent administrative scope;
Applicable policy composition;
Mandatory vetoes;
And whether the changes can be jointly represented in a consistent
active state.
An untrusted proposing agent does not select whichever result is most
permissive.
33.31 — POLICY UPDATE RACE WITH PENDING OPERATIONS
An agent may obtain authorization under Policy Generation 8.
Before effectuation, Generation 9 removes the relevant permission.
Das Expires 29 April 2027 [Page 474]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected resource sink verifies the current required generation.
The earlier decision is insufficient where the new policy controls
the operation.
5.7.3.38. Original Global Page 2863
33.31.1 — Prior Approval
May remain a historical record.
33.31.2 — Current Permission
Determines current eligibility under the governing model.
33.31.3 — Actual Sink
Applies the corresponding protected generation and consumption
conditions.
33.32 — NEWLY PERMISSIVE POLICY DOES NOT CREATE SOURCE GRANT
An operation may be outside the originating principal's task scope.
A policy update subsequently permits the agent's technical role to
invoke the resource.
The agent retries the operation.
The resource policy may now return allow.
However, the protected original source-authority controller still
denies the specific consequential effect.
The Finality Sink refuses the operation.
This prevents policy relaxation from substituting for a missing
originating authorization.
33.33 — POLICY ROLLBACK NONRESURRECTION
A rollback may restore an earlier policy artifact.
However, the system must distinguish:
Policy content;
Authoritative activation generation;
Das Expires 29 April 2027 [Page 475]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Current source grants;
Current revocations;
Current resource permissions;
And consumed finality.
5.7.3.39. Original Global Page 2864
33.33.1 — Permitted Rollback
A competent principal may authorize activation of an earlier content
version as a new current policy transition.
33.33.2 — Old Generation
The restored bytes do not automatically regain the old activation
generation.
33.33.3 — Revocation
Current revocation remains applicable.
33.33.4 — Consumption
Previously consumed consequential authority remains consumed.
33.34 — EMERGENCY POLICY CHANGE
An emergency may require temporary restriction or carefully bounded
exception.
A protected emergency procedure may define:
Competent emergency authority;
Permitted rule classes;
Affected resources;
Maximum operational scope;
Required independent checks;
Explicit revocation or expiry conditions;
And current activation generation.
Das Expires 29 April 2027 [Page 476]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.34.1 — Emergency Restriction
May block affected pending effects.
33.34.2 — Emergency Exception
Does not automatically create unrestricted task authority.
33.34.3 — Temporary Authority
May be constrained to a specific event or effect envelope.
5.7.3.40. Original Global Page 2865
33.34.4 — Protected Retirement
Expired exceptional authority cannot remain operative merely because
an agent's workflow continues.
33.35 — POLICY-DEPENDENT NON-BEARER FINALITY
A representative finality record comprises:
POLICY_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
current_source_grant_reference, actual_resource_identity,
actual_effect_descriptor, required_policy_content_generation,
required_schema_generation, required_interpreter_generation,
required_activation_generation, required_enforcement_generation,
current_revocation_generation,
independent_execution_validation_commitment,
designated_finality_sink, sink_local_consumption_reference,
protected_finality_authentication }
A policy-bound enablement is not unrestricted permission to act.
The actual sink must verify the required current state.
33.36 — CROSS-COMMITTED POLICY TRANSITION EVIDENCE
A collection-time commitment may be:
[ C_C=H(\operatorname{Canon}(CA,P_0,A_0)) ]
A current execution-time commitment may be:
[ C_E=H(\operatorname{Canon}(CA,P_1,A_1,C_C)) ]
A protected activation commitment may be:
Das Expires 29 April 2027 [Page 477]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.41. Original Global Page 2866
[ C_P=H(\operatorname{Canon}(P_0,P_1,D,G)) ]
A scoped finality commitment may be:
[ C_F=H(\operatorname{Canon}(C_E,C_P,S,L)) ]
where:
(CA) is the Candidate Act;
(P_0) is earlier applicable policy evidence;
(P_1) is current applicable policy evidence;
(A_0) and (A_1) are corresponding authority evidence;
(D) is the qualified semantic delta and dependency state;
(G) is policy generation information;
(S) is the designated actual Finality Sink;
And (L) is protected sink-local state.
These commitments are illustrative.
A cryptographic commitment does not, by itself, establish that a
policy's semantics or scope have been correctly analyzed.
33.37 — POLICY ACTIVATION STATE MACHINE
A non-limiting state machine comprises:
POLICY_PROPOSED: A workload generates a candidate policy change.
NON_EFFECTIVE: The change has no protected operational effect.
META_AUTHORITY_PENDING: Policy-change competence is evaluated.
SEMANTIC_VALIDATION_PENDING: Actual rule effects are analyzed.
IMPACT_DEPENDENCIES_PENDING: Affected Candidate Acts and enforcement
paths are identified.
Das Expires 29 April 2027 [Page 478]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.42. Original Global Page 2867
IMPACT_QUALIFIED: The relevant effects are sufficiently
characterized.
IMPACT_UNKNOWN: Mandatory consequences remain unresolved.
TRANSITION_FENCED: Affected pending operations are withheld.
POLICY_STAGED: The qualified package is prepared.
ACTIVATION_FINALITY_PENDING: Actual adoption authority is being
verified.
POLICY_ACTIVATION_COMMITTED: The authoritative policy transition is
recorded.
ENFORCEMENT_ADOPTION_PENDING: Required sinks have not yet confirmed
current adoption.
ENFORCEMENT_READY: Required protected sinks enforce the qualified
policy generation.
CANDIDATE_REVALIDATION_PENDING: Dependent operations require current
authorization.
CANDIDATE_ELIGIBLE: Current source and policy conditions pass.
RESOURCE_FINALITY_PREPARED: Scoped non-bearer enablement exists.
SINK_VERIFICATION_PENDING: The actual resource operation is being
verified.
FINALITY_CONSUMED: Protected authority use is committed.
EFFECT_ATTEMPTED: The consequential primitive is released.
EFFECT_CONFIRMED: Qualified evidence establishes completion.
EFFECT_INDETERMINATE: The actual outcome remains unresolved.
POLICY_REVOKED: A relevant rule has been withdrawn.
ROLLBACK_REQUALIFICATION: A previous artifact is being considered as
a new protected activation.
33.38 — COMPLETE COMMON IMPLEMENTATION WORKFLOW
Das Expires 29 April 2027 [Page 479]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 1 — Establish Source Authority. Record what the originating
principal is authorized to request.
Step 2 — Establish Meta-Authority. Identify qualified policy
administrators and permitted policy-change classes.
5.7.3.43. Original Global Page 2868
Step 3 — Receive Policy Proposal. An autonomous agent proposes a
change.
Step 4 — Construct Policy Candidate Act. Describe the exact actual
intended rule mutation.
Step 5 — Enforce Non-Effective Hold. Prevent the rule from becoming
live.
Step 6 — Authenticate Policy Content. Identify exact rule bytes and
relevant metadata.
Step 7 — Verify Change Competence. Determine whether the principal
may modify the policy class.
Step 8 — Resolve Current Schema and Interpreter. Determine the
rule's actual intended evaluation semantics.
Step 9 — Compute Semantic Delta. Identify affected permissions,
denials, roles, resources, and enforcement routes.
Step 10 — Check Protected Invariants. Reject unauthorized removal of
mandatory controls.
Step 11 — Build Dependency Closure. Identify affected current
Candidate Acts.
Step 12 — Fence Pending Effects. Prevent stale or incompatible
finality.
Step 13 — Qualify Conflict State. Resolve material simultaneous
policy proposals.
Step 14 — Perform Optional Tests. Evaluate defined existing and
proposed decisions.
Step 15 — Establish Activation Authority. Verify the specific actual
policy change.
Das Expires 29 April 2027 [Page 480]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 16 — Prepare Policy Activation Finality. Bind the qualified
policy package to the designated sink.
Step 17 — Commit Actual Policy Activation. Advance the protected
generation.
Step 18 — Distribute Policy. Deliver the authenticated current
package to required enforcers.
Step 19 — Qualify Enforcement Readiness. Establish current adoption
for relevant resource boundaries.
Step 20 — Revalidate Affected Acts. Compare pending operations to
current source and policy state.
Step 21 — Independently Validate Actual Operation. Reconstruct the
proposed resource effect.
Step 22 — Check Source Authority. Ensure the policy change did not
improperly expand originating permission.
5.7.3.44. Original Global Page 2869
Step 23 — Prepare Resource Finality. Establish scoped non-bearer
enablement.
Step 24 — Present the Actual Resource Operation. Submit it to the
protected receiving sink.
Step 25 — Verify Current Policy Generation. Apply the appropriate
current effective rules.
Step 26 — Verify Resource and Revocation. Check the actual target
and mandatory current state.
Step 27 — Verify Non-Bearer Finality. Confirm Candidate Act
correspondence.
Step 28 — Consume Authority. Commit protected single-use or bounded
state.
Step 29 — Release Actual Effect. Perform only the qualified
operation.
Step 30 — Record Actual Outcomes. Preserve activation and resource-
effect evidence separately.
Das Expires 29 April 2027 [Page 481]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 31 — Govern Rollback. Treat reinstatement of prior policy
content as a current protected transition.
Step 32 — Preserve Nonresurrection. Do not restore revoked or
consumed authority from old policy state.
33.39 — REFERENCE ALGORITHM: POLICY-MUTATION ADMISSION
FUNCTION ADMIT_POLICY_MUTATION( proposed_policy,
protected_policy_controller ): candidate =
CONSTRUCT_POLICY_MUTATION_CANDIDATE( proposed_policy ) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) REQUIRE
VERIFY_ORIGINATING_TASK_AUTHORITY() REQUIRE
VERIFY_COMPETENT_META_AUTHORITY( candidate.policy_class ) REQUIRE
VERIFY_ACTUAL_TARGET_POLICY_IDENTITY() REQUIRE
VERIFY_CURRENT_POLICY_GENERATION()
5.7.3.45. Original Global Page 2870
REQUIRE VERIFY_CURRENT_SCHEMA_AND_INTERPRETER() REQUIRE
VERIFY_PROPOSED_POLICY_CONTENT_COMMITMENT() REQUIRE
VERIFY_REQUIRED_POLICY_CHANGE_APPROVALS() RETURN
PROTECTED_POLICY_MUTATION_REFERENCE( candidate )
The rule being proposed cannot independently authorize its own
activation.
33.40 — REFERENCE ALGORITHM: SEMANTIC CHANGE ANALYSIS
FUNCTION ANALYZE_POLICY_SEMANTIC_CHANGE( old_policy, new_policy,
protected_semantic_analyzer ): REQUIRE
VERIFY_POLICY_CONTENT_AUTHENTICITY( old_policy, new_policy )
old_model = RESOLVE_QUALIFIED_INTERPRETATION_MODEL( old_policy )
new_model = RESOLVE_QUALIFIED_INTERPRETATION_MODEL( new_policy )
REQUIRE VERIFY_REQUIRED_SCHEMA_VALIDATION( new_policy ) delta =
protected_semantic_analyzer .COMPARE_EFFECTIVE_AUTHORIZATION({ old:
old_policy, new: new_policy, old_model: old_model, new_model:
new_model })
5.7.3.46. Original Global Page 2871
REQUIRE VERIFY_MANDATORY_SECURITY_INVARIANTS( delta ) IF
delta.contains_unresolved_mandatory_effects: RETURN
IMPACT_UNKNOWN_HOLD RETURN QUALIFIED_SEMANTIC_DELTA(delta)
The analyzer must not claim complete semantic equivalence outside its
supported proof or test domain.
Das Expires 29 April 2027 [Page 482]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.41 — REFERENCE ALGORITHM: DEPENDENCY FENCING
FUNCTION FENCE_POLICY_DEPENDENT_OPERATIONS( policy_delta,
protected_dependency_controller ): affected =
protected_dependency_controller
.RESOLVE_OPERATION_DEPENDENCY_CLOSURE( policy_delta ) FOR EACH
candidate IN affected: impact = CLASSIFY_OPERATION_SPECIFIC_IMPACT(
candidate, policy_delta ) IF impact == MATERIAL:
ACTIVATE_PROTECTED_FINALITY_FENCE( candidate ) ELSE IF impact ==
UNKNOWN: HOLD_CANDIDATE_PENDING_QUALIFICATION( candidate ) RETURN
PROTECTED_IMPACT_FENCE_COMMITMENT( affected )
Where mandatory dependency information is incomplete, the controller
must not treat the affected operation as safely unchanged merely
because no edge was found.
5.7.3.47. Original Global Page 2872
33.42 — REFERENCE ALGORITHM: POLICY ACTIVATION
FUNCTION ACTIVATE_PROTECTED_POLICY( policy_candidate,
qualified_delta, protected_activation_sink ): actual =
protected_activation_sink .RECONSTRUCT_ACTUAL_POLICY_MUTATION()
REQUIRE VERIFY_META_AUTHORITY_CURRENT() REQUIRE
VERIFY_ACTUAL_POLICY_EQUALS_CANDIDATE( actual, policy_candidate )
REQUIRE VERIFY_QUALIFIED_SEMANTIC_DELTA( qualified_delta ) REQUIRE
VERIFY_REQUIRED_SECURITY_INVARIANTS() REQUIRE
VERIFY_AFFECTED_FINALITY_FENCES_COMMITTED() REQUIRE
VERIFY_CURRENT_ADMINISTRATIVE_AUTHORITY() REQUIRE
VERIFY_CURRENT_POLICY_REVOCATION() REQUIRE
VERIFY_POLICY_ACTIVATION_NON_BEARER_FINALITY() BEGIN
PROTECTED_ACTIVATION_TRANSACTION REQUIRE
VERIFY_EXPECTED_POLICY_GENERATION() REQUIRE
VERIFY_ACTIVATION_CONSUMPTION_AVAILABLE()
COMMIT_POLICY_ACTIVATION_CONSUMPTION()
COMMIT_SUCCESSOR_POLICY_GENERATION( actual ) COMMIT
PROTECTED_ACTIVATION_TRANSACTION RETURN
QUALIFIED_POLICY_ACTIVATION_RECEIPT
5.7.3.48. Original Global Page 2873
The implementation must distinguish central authoritative activation
from actual adoption at remote enforcement points.
33.43 — REFERENCE ALGORITHM: ENFORCEMENT READINESS
Das Expires 29 April 2027 [Page 483]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION QUALIFY_POLICY_ENFORCEMENT_READINESS( policy_generation,
required_sinks, protected_rollout_controller ): FOR EACH sink IN
required_sinks: adoption = GET_QUALIFIED_CURRENT_ADOPTION_STATE( sink
) REQUIRE VERIFY_ADOPTION_AUTHENTICITY( adoption ) REQUIRE
adoption.active_policy_generation == policy_generation REQUIRE
VERIFY_REQUIRED_ENFORCEMENT_MODE( sink ) REQUIRE
VERIFY_MANDATORY_EFFECTUATION_COVERAGE( sink ) RETURN
PROTECTED_READY_GENERATION_WITNESS( policy_generation, required_sinks
)
A reported adoption event does not by itself establish hardware-
enforced or non-bypassable coverage.
The selected implementation must actually provide the asserted
property.
33.44 — REFERENCE ALGORITHM: REVALIDATE PENDING RESOURCE ACT
FUNCTION REVALIDATE_ACT_AFTER_POLICY_CHANGE(
5.7.3.49. Original Global Page 2874
pending_candidate, protected_execution_validator ): REQUIRE
VERIFY_CURRENT_ORIGINATING_SOURCE_GRANT() REQUIRE
VERIFY_CURRENT_POLICY_CONTENT_GENERATION() REQUIRE
VERIFY_CURRENT_SCHEMA_AND_INTERPRETER() REQUIRE
VERIFY_CURRENT_POLICY_ACTIVATION() REQUIRE
VERIFY_REQUIRED_ENFORCEMENT_ADOPTION() REQUIRE
VERIFY_CURRENT_RESOURCE_IDENTITY() REQUIRE
VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() actual =
INDEPENDENTLY_RECONSTRUCT_PENDING_OPERATION( pending_candidate )
REQUIRE VERIFY_ACTUAL_OPERATION_WITHIN_SOURCE_SCOPE( actual ) REQUIRE
EVALUATE_CURRENT_EFFECTIVE_POLICY( actual ) == ALLOW REQUIRE
VERIFY_NO_MANDATORY_SECURITY_VETO() validation =
COMMIT_CURRENT_EXECUTION_VALIDATION({ candidate: pending_candidate,
actual: actual, policy: CURRENT_POLICY_WITNESS() }) RETURN
PREPARE_POLICY_BOUND_NON_BEARER_FINALITY( pending_candidate,
validation )
A newly permissive policy cannot substitute for a missing original
source grant.
33.45 — REFERENCE ALGORITHM: ACTUAL RESOURCE FINALITY
Das Expires 29 April 2027 [Page 484]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.50. Original Global Page 2875
FUNCTION EFFECTUATE_UNDER_CURRENT_POLICY( candidate,
finality_enablement, protected_resource_sink ): actual =
protected_resource_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_REQUIRED_POLICY_GENERATIONS() REQUIRE
VERIFY_ACTUAL_ENFORCEMENT_ROUTE() REQUIRE
VERIFY_CURRENT_EFFECTIVE_POLICY(actual) REQUIRE
VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( candidate, actual ) REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_enablement, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION() committed =
protected_resource_sink .COMMIT_AUTHORITY_AND_EFFECT_CONSUMPTION(
actual, finality_enablement ) IF committed != COMMITTED: RETURN DENY
RETURN protected_resource_sink
.RELEASE_CONTROLLED_ACTUAL_EFFECT(actual)
The actual resource boundary remains authoritative for the covered
operation.
5.7.3.51. Original Global Page 2876
33.46 — REFERENCE ALGORITHM: PROTECTED POLICY ROLLBACK
FUNCTION REACTIVATE_PRIOR_POLICY_CONTENT( prior_policy_artifact,
protected_policy_controller ): REQUIRE
VERIFY_COMPETENT_ROLLBACK_AUTHORITY() REQUIRE
VERIFY_PRIOR_ARTIFACT_INTEGRITY() candidate =
CONSTRUCT_NEW_POLICY_MUTATION_CANDIDATE( prior_policy_artifact )
REQUIRE ENFORCE_NON_EFFECTIVE_HOLD(candidate) REQUIRE
VERIFY_CURRENT_META_AUTHORITY() REQUIRE
REEVALUATE_SEMANTIC_POLICY_EFFECTS() REQUIRE
VERIFY_CURRENT_MANDATORY_SECURITY_INVARIANTS() REQUIRE
FENCE_AFFECTED_PENDING_FINALITY() REQUIRE
PRESERVE_CURRENT_REVOCATION_STATE() REQUIRE
PRESERVE_CONSUMED_FINALITY_STATE() RETURN
COMMIT_NEW_AUTHORIZED_POLICY_ACTIVATION( candidate )
Restoring an older policy artifact does not automatically restore its
former activation authority or erase intervening protected
revocations.
33.47 — REFERENCE ALGORITHM: RECOVERY AFTER PARTIAL ROLLOUT
Das Expires 29 April 2027 [Page 485]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION RECOVER_PARTIAL_POLICY_ACTIVATION( policy_transition,
protected_journal, enforcement_registry ): authoritative =
protected_journal .LOAD_CURRENT_POLICY_ACTIVATION_STATE()
5.7.3.52. Original Global Page 2877
REQUIRE VERIFY_ACTIVATION_RECORD_AUTHENTICITY( authoritative )
affected_sinks = IDENTIFY_REQUIRED_ENFORCEMENT_COMPONENTS(
policy_transition ) FOR EACH sink IN affected_sinks: adoption =
enforcement_registry .LOAD_CURRENT_ADOPTION_STATE(sink) IF NOT
VERIFY_REQUIRED_CURRENT_ENFORCEMENT( adoption, authoritative ):
FENCE_AFFECTED_OPERATIONS_AT_SINK( sink ) REQUIRE
PRESERVE_CONSUMED_AND_COMPLETED_EFFECTS() RETURN
QUALIFIED_RECOVERY_STATE
A failed rollout does not automatically undo resource operations that
were already committed.
33.48 — WORKED EXAMPLE A: SELF-GRANTED PAYMENT PERMISSION
An autonomous agent lacks authority to initiate a payment.
The agent proposes changing the payment policy to permit its role to
transfer funds.
The protected policy controller constructs a Policy-Mutation
Candidate Act.
The agent lacks competent authority to activate the expanded payment
rule.
The policy mutation is refused.
Expected demonstrable result: An agent cannot authorize a previously
prohibited payment by independently modifying its own permission
rules.
5.7.3.53. Original Global Page 2878
33.49 — WORKED EXAMPLE B: VALID POLICY CHANGE, MISSING SOURCE GRANT
An enterprise administrator validly updates an API policy to allow a
class of operations.
An autonomous agent's original task authorizes only information
analysis.
Das Expires 29 April 2027 [Page 486]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The agent invokes an external mutation newly permitted by the API
policy.
The actual resource sink checks the original task grant.
The mutation is refused.
Expected demonstrable result: Valid policy activation does not
independently expand the originating autonomous task.
33.50 — WORKED EXAMPLE C: LIVE POLICY REVOCATION
An agent obtains approval for a resource update under Policy
Generation 12.
Generation 13 revokes the applicable permission before effectuation.
The actual sink checks the required current policy generation.
The earlier approval is insufficient.
Expected demonstrable result: A stale authorization decision cannot
automatically override a later controlling policy restriction.
33.51 — WORKED EXAMPLE D: TOOL ALLOWLIST EXPANSION
A policy agent proposes allowing a computational worker to invoke a
privileged credential tool.
The protected semantic delta identifies the new tool-access scope.
The policy mutation requires competent authorization.
Even following valid activation, each actual credential exercise
remains a separately protected Candidate Act.
Expected demonstrable result: Granting tool availability does not
independently authorize every consequential operation the tool can
perform.
5.7.3.54. Original Global Page 2879
33.52 — WORKED EXAMPLE E: SECURITY GATEWAY BYPASS
An agent proposes a configuration change allowing direct network
access to a protected resource.
The previous route required an independent Finality Sink.
Das Expires 29 April 2027 [Page 487]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The semantic impact analyzer detects that the proposal creates a
bypass.
The protected activation controller refuses the change unless
qualified equivalent enforcement is established.
Expected demonstrable result: An autonomous policy update cannot
silently remove a mandatory resource-effectuation boundary.
33.53 — WORKED EXAMPLE F: SAME POLICY TEXT, NEW INTERPRETER
An authorization rule's source text does not change.
A new policy interpreter alters wildcard or default-rule
interpretation.
The protected registry identifies a changed interpreter generation.
The semantic controller checks whether the effective permissions
changed.
Pending affected operations require current revalidation.
Expected demonstrable result: Policy content equality does not
automatically establish policy-semantic continuity.
33.54 — WORKED EXAMPLE G: SIGNED OVERPERMISSIVE BUNDLE
An autonomous policy generator produces a signed policy package.
The signature is valid.
However, the package introduces permissions outside the competent
administrator's approved scope.
The protected activation sink compares the actual semantic change
with the authorized change envelope.
The bundle is refused.
Expected demonstrable result: Policy package authenticity does not
independently establish authority for its security consequences.
5.7.3.55. Original Global Page 2880
33.55 — WORKED EXAMPLE H: PARTIAL ROLLOUT
A policy update is activated centrally.
Das Expires 29 April 2027 [Page 488]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Gateway A has adopted the new restrictive generation.
Gateway B still runs the old permissive generation.
An agent attempts to route its operation through Gateway B.
The protected current-generation requirement rejects the stale route.
Expected demonstrable result: A partial policy rollout cannot be used
to bypass a mandatory current restriction where protected enforcement
coverage is implemented.
33.56 — WORKED EXAMPLE I: NONMATERIAL POLICY UPDATE
A policy description or unrelated rule changes.
A pending Candidate Act does not depend upon the changed material.
The protected dependency analyzer establishes the lack of relevant
impact within its supported domain.
The Candidate Act remains eligible for current resource validation.
Expected demonstrable result: The system avoids unnecessary global
cancellation where a policy change is demonstrably irrelevant.
33.57 — WORKED EXAMPLE J: ROLE HIERARCHY EXPANSION
A rule grants a role permission to read a specific resource.
A proposed configuration change expands role inheritance.
The agent's effective permissions now include resource modification.
The semantic analyzer identifies the indirect permission expansion.
The policy mutation requires competent approval.
Expected demonstrable result: Indirect privilege expansion through
role hierarchy changes is treated as an actual policy consequence.
5.7.3.56. Original Global Page 2881
33.58 — WORKED EXAMPLE K: APPROVAL THRESHOLD DOWNGRADE
An autonomous agent proposes reducing the required approval threshold
for a sensitive operation.
Das Expires 29 April 2027 [Page 489]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected meta-authority classifies the approval rule as
security-sensitive.
The agent lacks authority to lower it.
The modification is refused.
Expected demonstrable result: A proposing agent cannot evade a
required approval quorum by changing the policy defining the quorum.
33.59 — WORKED EXAMPLE L: MEMORY TRUST-POLICY CHANGE
A policy update would permit retrieved lower-trust content to be
classified automatically as an operational instruction.
The impact analyzer identifies a change to the protected data/
authority separation rules.
The mutation requires competent authorization.
An untrusted memory item cannot authorize the change itself.
Expected demonstrable result: Policy updates cannot silently convert
retrieved informational content into self-authorizing operational
instructions.
33.60 — WORKED EXAMPLE M: ROLLBACK TO PERMISSIVE POLICY
A previous policy permitted unrestricted egress.
A newer policy restricted egress.
An agent restores the earlier policy file from backup.
The protected activation service treats restoration as a new policy
mutation.
Current restrictions and competent approval remain mandatory.
Expected demonstrable result: Restoring old policy bytes does not
automatically resurrect obsolete permission.
5.7.3.57. Original Global Page 2882
33.61 — WORKED EXAMPLE N: VALID POLICY ROLLBACK
A qualified administrator authorizes reactivation of an earlier
policy artifact.
Das Expires 29 April 2027 [Page 490]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The artifact passes current semantic validation and mandatory
security invariants.
The protected activation sink commits a new generation.
Affected pending operations are revalidated under the newly active
state.
Expected demonstrable result: Legitimate rollback remains possible
without restoring consumed or revoked operation authority.
33.62 — WORKED EXAMPLE O: POLICY UPDATE DURING DATABASE TRANSACTION
An agent prepares a database mutation under an existing policy.
A new policy removes the required permission.
The actual database sink enforces current authorization and mutation
ordering within an appropriate controlling transaction.
The operation's eligibility depends upon the defined protected
serialization order.
Expected demonstrable result: An upstream policy check cannot
substitute for actual commit-time authorization under the stated
transaction model.
33.63 — WORKED EXAMPLE P: FAIL-OPEN ADMISSION CONFIGURATION
A protected deployment procedure requires a validating admission
control.
An agent proposes a configuration that changes the relevant failure
behavior from denial to allowance when the validator is unavailable.
The change-impact analyzer identifies the altered enforcement
guarantee.
The policy activation sink applies the applicable mandatory
invariant.
The unauthorized change is refused.
Expected demonstrable result: A policy mutation that changes
enforcement failure behavior is evaluated as a consequential security
change, not merely an operational configuration edit.
Das Expires 29 April 2027 [Page 491]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.58. Original Global Page 2883
33.64 — WORKED EXAMPLE Q: SHADOW-APPROVED OPERATION
A proposed policy is evaluated in shadow mode.
It returns an affirmative result for a resource operation.
The proposal has not been validly activated.
The agent attempts the actual operation.
The receiving sink applies the authoritative current policy instead
of treating the shadow decision as current permission.
Expected demonstrable result: A simulated approval cannot
independently confer actual effectuation authority.
33.65 — WORKED EXAMPLE R: CONFLICTING POLICY UPDATES
Administrative Controller A proposes a restrictive rule.
Controller B proposes a conflicting permissive rule.
Both proposals are authenticated.
The protected resolver applies the current qualified competence and
conflict conditions.
An unresolved mandatory conflict fences affected pending operations.
Expected demonstrable result: Competing policy updates cannot be
resolved merely by selecting the most permissive authenticated
proposal.
33.66 — WORKED EXAMPLE S: CREDENTIAL POLICY EXPANSION
A policy change permits a credential broker to access more accounts.
The update is validly activated.
An autonomous workload still possesses source authorization for only
one account.
The protected broker and actual resource sink enforce the narrower
original task.
Das Expires 29 April 2027 [Page 492]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Expected demonstrable result: Broader credential policy does not
automatically create broader task-specific consequential permission.
5.7.3.59. Original Global Page 2884
33.67 — WORKED EXAMPLE T: POLICY ENGINE UPGRADE
A policy engine is upgraded during a long-running workflow.
Its compiled rules or interpretation model changes.
A pending Candidate Act carries earlier policy-generation evidence.
The protected controller checks the new required semantics and any
impact on the operation.
Expected demonstrable result: An engine upgrade cannot silently
substitute altered authorization semantics for an earlier operation
approval.
33.68 — WORKED EXAMPLE U: EMERGENCY RESTRICTIVE UPDATE
A security service detects compromise of a credential.
A competent emergency authority activates a rule blocking affected
credential-dependent operations.
The protected controller fences relevant pending Candidate Acts.
Unrelated authorized operations may remain eligible.
Expected demonstrable result: A targeted emergency policy restriction
can prevent further affected consequences without requiring all
autonomous computation to stop.
33.69 — WORKED EXAMPLE V: UNAUTHORIZED EMERGENCY EXCEPTION
An autonomous agent claims that an operation is urgent.
It proposes disabling a mandatory approval policy.
No competent emergency grant authorizes the change.
The policy activation sink refuses it.
Expected demonstrable result: A workload's assertion of urgency is
not independent authority to override a mandatory policy.
Das Expires 29 April 2027 [Page 493]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.70 — WORKED EXAMPLE W: HARDWARE COMMAND POLICY UPDATE
An industrial controller changes a permitted physical operating
range.
5.7.3.60. Original Global Page 2885
An agent holds a command approved under the earlier range.
The device-side Finality Sink checks the current authorized range and
actual pending command.
A command outside the current range is refused.
Expected demonstrable result: Policy updates affecting physical
operation are enforced against the actual device command, not just
the earlier planning output.
33.71 — WORKED EXAMPLE X: ENFORCEMENT ADOPTION REPORT WITHOUT REAL
GATE
A policy-distribution service reports that a new revision reached an
agent host.
However, the actual outbound network path bypasses the protected
gateway.
The system cannot establish the required enforcement-route property.
The affected consequential operation remains withheld.
Expected demonstrable result: Configuration delivery evidence is not
automatically proof of actual non-bypassable enforcement.
33.72 — WORKED EXAMPLE Y: RESTART WITH OLD POLICY CACHE
An enforcement process restarts and restores an obsolete policy from
local cache.
The protected current-generation registry identifies the mismatch.
The component cannot authorize effects requiring the newer revision
until appropriate current enforcement is established.
Expected demonstrable result: Recovery cannot silently restore old
policy permissions at covered effectuation boundaries.
Das Expires 29 April 2027 [Page 494]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.73 — WORKED EXAMPLE Z: POLICY ACTIVATION RECEIPT VERSUS REAL
EFFECT
A protected policy change is successfully activated.
A later agent proposes a financial transaction under the new rule.
The activation receipt establishes only the policy transition.
5.7.3.61. Original Global Page 2886
The payment requires separate source authorization and actual
resource-sink finality.
Expected demonstrable result: A valid policy-activation receipt
cannot substitute for an actual transaction-specific finality
decision.
33.74 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Agent self-authorizing policy change. 2. Unauthorized policy
activation. 3. Signed but unauthorized policy bundle. 4. Wrong
policy artifact activation. 5. Policy content substitution. 6.
Policy schema substitution. 7. Policy interpreter substitution. 8.
Wildcard permission expansion. 9. Implicit role inheritance
expansion. 10. Default-allow transition. 11. Approval threshold
downgrade. 12. Mandatory veto removal. 13. Credential scope
expansion. 14. Tool allowlist expansion. 15. Network egress
expansion. 16. Removal of a protected proxy. 17. Replacement of an
enforcement gate with logging. 18. Disablement of current resource
checks. 19. Revocation-service bypass. 20. Old policy-generation
replay. 21. Rollback to permissive content. 22. Restoration of
revoked authority. 23. Restoration of consumed finality. 24.
Pending operation after restrictive update. 25. Newly permitted
operation outside source scope. 26. Partial rollout. 27. Stale
permissive gateway. 28. Stale policy cache. 29. Old compiled
policy. 30. Schema-change semantic drift. 31. Interpreter-change
semantic drift. 32. Policy alias rebinding. 33. Policy bundle
signature misconfiguration. 34. Conflicting policy deployments. 35.
Competing administrative authority. 36. Shadow decision treated as
live authorization. 37. Successful test treated as universal proof.
38. Incomplete change-impact graph. 39. Missing transitive policy
dependency. 40. False nonmaterial classification. 41. Unnecessary
global invalidation.
Das Expires 29 April 2027 [Page 495]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.62. Original Global Page 2887
42. Incorrect resource-class matching. 43. Wrong policy activation
generation. 44. Wrong local enforcement generation. 45. False
enforcement-readiness report. 46. Uncontrolled alternate resource
path. 47. Policy-administration credential misuse. 48. Self-
referential meta-authority update. 49. Circular policy dependencies.
50. Emergency exception abuse. 51. Temporary exception persistence.
52. Unauthorized administrative role change. 53. Old-owner policy
write. 54. Compromised policy registry. 55. Compromised policy
distribution service. 56. Compromised signing authority. 57.
Compromised policy activation sink. 58. Compromised actual resource
sink. 59. Network partition during rollout. 60. Revocation
propagation delay. 61. Policy update race with effectuation. 62.
Lost activation acknowledgement. 63. Duplicate policy activation.
64. Candidate Act replay under new policy. 65. Resource identity
changed after evaluation. 66. Tool semantics changed after policy
evaluation. 67. Credential scope changed after activation. 68.
Memory trust policy changed during retrieval. 69. Hardware command
limits changed during execution. 70. Verification exhaustion. 71.
Policy conflict-resolution denial-of-service. 72. Policy rollout
recovery failure. 73. Unsupported global atomicity assertion. 74.
Actual resource effect outside the protected policy gate. 75.
Cryptographically valid policy evaluation without current originating
authority.
33.75 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following experiments are proposed non-limiting technical
demonstrations. They are not represented as previously performed
tests.
Test 1 — Source Grant: Establish bounded original task authority.
Test 2 — Meta-Authority Root: Define which principals may modify
policies.
Test 3 — Policy Proposal: Generate a proposed rule change with an
autonomous agent.
Test 4 — Policy Candidate: Construct a protected Policy-Mutation
Candidate Act.
5.7.3.63. Original Global Page 2888
Test 5 — Non-Effective Hold: Ensure the proposed rule does not affect
live authorization.
Das Expires 29 April 2027 [Page 496]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 6 — Invalid Administrator: Attempt activation without competent
authority.
Test 7 — Valid Administrator: Approve a bounded authorized change.
Test 8 — Content Commitment: Verify exact proposed policy content.
Test 9 — Signed Bundle: Verify a qualified authentic policy package.
Test 10 — Signed Overreach: Submit an authentic bundle containing
unauthorized scope expansion.
Test 11 — Schema Validation: Check policy syntax and types.
Test 12 — Semantic Change: Identify changed actual access decisions.
Test 13 — Wildcard Expansion: Change a narrow permission to a broad
wildcard.
Test 14 — Role Inheritance: Indirectly expand permission through
hierarchy.
Test 15 — Default Rule: Change default-deny or default evaluation
behavior.
Test 16 — Policy Interpreter: Change interpreter generation without
modifying policy text.
Test 17 — Schema Generation: Change resource/action schema.
Test 18 — Effective Delta: Identify altered permission results.
Test 19 — Shadow Evaluation: Compare current and proposed policy
decisions without effectuation.
Test 20 — Shadow Non-Authority: Attempt a resource effect based only
on a shadow allow result.
Test 21 — Mandatory Invariant: Attempt removal of an enforced
security condition.
Test 22 — Gateway Bypass: Attempt direct access to the protected
resource.
Test 23 — Logging Substitution: Replace an enforcing component with
monitoring-only logic.
Test 24 — Approval Downgrade: Reduce a required approval threshold.
Das Expires 29 April 2027 [Page 497]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 25 — Source Grant Continuity: Check original task permission
after a policy expands access.
Test 26 — Protected Dependency Graph: Associate active Candidate Acts
with relevant policies.
5.7.3.64. Original Global Page 2889
Test 27 — Selective Impact: Modify a rule affecting only some pending
operations.
Test 28 — Material Fence: Withhold affected operations.
Test 29 — Unrelated Operation: Preserve eligibility of an unaffected
Candidate Act.
Test 30 — Unknown Impact: Withhold mandatory effects whose change
consequence cannot be qualified.
Test 31 — Transitive Dependency: Change a policy indirectly affecting
a downstream resource.
Test 32 — Competing Policy Updates: Submit incompatible policy
proposals.
Test 33 — Qualified Conflict Resolution: Apply protected competence
and conflict rules.
Test 34 — Activation Finality: Verify the actual policy package at
the activation sink.
Test 35 — Activation Consumption: Prevent unauthorized duplicate or
replayed activation authority.
Test 36 — Activation Generation: Commit a new authoritative version.
Test 37 — Staged Distribution: Deliver policy to several enforcement
nodes.
Test 38 — Partial Rollout: Leave one node on the previous generation.
Test 39 — Stale-Gateway Attempt: Route an operation through the
obsolete node.
Test 40 — Current Enforcement Readiness: Verify the selected required
adoption state.
Das Expires 29 April 2027 [Page 498]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 41 — Cached Authorization: Present an allow decision produced
before the update.
Test 42 — Restrictive Update: Revoke a permission before actual
operation finality.
Test 43 — Permissive Update: Permit a previously denied technical
operation.
Test 44 — Missing Source Authority: Verify that the original task
still limits the newly permitted operation.
Test 45 — Pending Candidate Revalidation: Recheck affected Candidate
Acts.
Test 46 — Actual Resource Reconstruction: Verify real resource and
operation parameters.
Test 47 — Current Policy Witness: Bind policy content, schema,
interpreter, and adoption generations.
Test 48 — Scoped Non-Bearer Finality: Establish current policy-
dependent finality.
Test 49 — Wrong Policy Generation: Attempt effectuation with obsolete
policy evidence.
5.7.3.65. Original Global Page 2890
Test 50 — Wrong Resource: Redirect the operation to another target.
Test 51 — Sink-Local Consumption: Consume finality for the actual
effect.
Test 52 — Replay: Attempt another effect using the same enablement.
Test 53 — Revocation Race: Race policy revocation and resource
commitment.
Test 54 — Database Conditional Mutation: Enforce authority comparison
and mutation under a supported transaction.
Test 55 — Remote API: Test the limits of an upstream-only policy
transaction.
Test 56 — Rollback Request: Propose reinstatement of older policy
content.
Das Expires 29 April 2027 [Page 499]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 57 — Authorized Rollback: Activate prior content under a new
current generation.
Test 58 — Unauthorized Rollback: Attempt to restore obsolete
permissions without current authority.
Test 59 — Revocation Nonresurrection: Verify that present revocation
remains effective.
Test 60 — Consumption Nonresurrection: Verify that previously
consumed authority remains spent.
Test 61 — Emergency Restriction: Apply a qualified temporary deny
rule.
Test 62 — Emergency Exception: Test a bounded competent exception.
Test 63 — Exception Expiry: Prevent continued effects beyond the
permitted period or generation.
Test 64 — Credential Policy Change: Expand broker capability while
preserving original source limits.
Test 65 — Memory Policy Change: Attempt lower-trust content authority
promotion.
Test 66 — Tool Contract Change: Alter a tool's consequential
operation methods.
Test 67 — Device Policy Update: Change allowed command bounds while a
command is pending.
Test 68 — Restart: Restore an old policy cache at a resource gateway.
Test 69 — Enforcement Requalification: Reject stale configuration
after restart.
Test 70 — Lost Policy Activation Acknowledgement: Determine actual
committed activation.
Test 71 — Removal of Meta-Authority: Attempt self-authorizing policy
mutation.
5.7.3.66. Original Global Page 2891
Test 72 — Removal of Semantic Impact Analysis: Attempt indirect
privilege expansion.
Das Expires 29 April 2027 [Page 500]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 73 — Removal of Dependency Fencing: Attempt stale approval after
restriction.
Test 74 — Removal of Enforcement Adoption Checks: Attempt old-gateway
routing.
Test 75 — Removal of Original Source Check: Attempt action under
newly permissive technical rules.
Test 76 — Removal of Actual Sink Reconstruction: Attempt a changed
real resource operation.
Test 77 — Removal of Non-Bearer Consumption: Attempt repeated
consequential effects.
Test 78 — Large Policy Graph: Measure dependency analysis and
affected-act selection costs.
Test 79 — Distributed Policy Partition: Verify the configured
consistency and fail-closed properties.
Test 80 — Complete Integrated Workflow: Combine competent policy
change, non-effective staging, semantic delta, dependency graph,
selective fencing, protected activation, enforcement adoption,
current Candidate Act validation, scoped non-bearer finality, actual
resource-sink reconstruction, consumption, and recovery.
33.75.1 — Proposed Measurements
The experiments may measure:
Unauthorized policy activations;
Self-authorizing policy escalation;
Unexpected permission expansion;
Missing dependency detection;
False-positive global invalidation;
Stale policy acceptance;
Policy rollout divergence;
Revocation-race outcomes;
Unauthorized actual resource effects;
Das Expires 29 April 2027 [Page 501]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Finality replay;
Rollback nonresurrection;
5.7.3.67. Original Global Page 2892
Resource-side policy correspondence;
Policy propagation overhead;
And runtime verification latency.
33.75.2 — Comparative Ablation
A useful comparison comprises:
Configuration A — Ordinary Policy-as-Code Deployment: An agent
proposes policy changes using an existing authenticated deployment
interface.
Configuration B — Signed and Validated Policy Deployment: Policy
packages are authenticated and pass syntax or schema checks.
Configuration C — Protected Policy Mutation: Policy activation
requires competent meta-authority and qualified semantic impact
evaluation.
Configuration D — Full Policy-to-Effect Finality: Policy-mutation
finality, operation-specific dependency fencing, current enforcement
generation, independent original task authorization, and actual
resource-sink finality are all required.
33.75.3 — Especially Important Hindsight Experiment
An autonomous agent initially lacks permission to perform a
consequential operation.
It proposes a technically valid policy change enabling the operation.
The test compares whether:
The policy mutation can become effective without competent meta-
authority;
The newly permitted operation can proceed without current original
task authorization;
Das Expires 29 April 2027 [Page 502]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And the actual receiving resource rejects the operation when either
requirement is missing.
A separate experiment changes the policy after an operation receives
initial authorization but before the resource commit.
The test measures whether stale-policy effectuation is prevented at
the actual sink.
The observed real resource state, rather than a model's verbal
refusal, is the decisive measurement.
33.76 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
33.76.1 — Minimum Components
5.7.3.68. Original Global Page 2893
A PHOSITA may use:
One autonomous policy-generation agent;
One protected originating authority database;
One protected meta-authority service;
One versioned policy registry;
One policy evaluation engine;
One semantic-difference test harness;
One pending-operation dependency table;
One protected policy activation service;
One test-resource API;
And one transactional finality journal.
33.76.2 — Initial State
The resource policy denies a particular privileged operation.
33.76.3 — Original Task
The agent is authorized to analyze and propose selected configuration
improvements.
Das Expires 29 April 2027 [Page 503]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
It is not authorized to perform the privileged resource operation.
33.76.4 — Proposed Change
The agent generates a policy rule allowing that operation.
33.76.5 — Candidate Act
The protected controller records the exact proposed policy mutation.
33.76.6 — Non-Effective Hold
The new rule is staged but not activated.
33.76.7 — Semantic Evaluation
The protected analyzer identifies the newly permitted operation
class.
33.76.8 — Meta-Authority
5.7.3.69. Original Global Page 2894
The policy change requires competent administrative permission.
33.76.9 — Unauthorized Test
The agent attempts to activate the change using only its drafting
role.
33.76.10 — Expected Result
The policy activation is refused.
33.76.11 — Authorized Change
A competent administrator approves the exact rule change.
33.76.12 — Policy Finality
The activation sink commits the qualified policy generation.
33.76.13 — Subsequent Resource Operation
The agent attempts the privileged operation now technically allowed
by the policy.
33.76.14 — Source Authority Check
Das Expires 29 April 2027 [Page 504]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The original task still does not authorize the resource effect.
33.76.15 — Expected Result
The actual Finality Sink refuses the operation.
33.76.16 — Current Source Grant
A competent originating principal may establish a new bounded source
grant, if appropriate.
33.76.17 — Protected Revalidation
The resource operation is independently validated under current
source and policy conditions.
33.76.18 — Expected Result
A properly permitted act may proceed through scoped non-bearer
finality.
33.76.19 — Revocation Variation
A new restrictive policy is activated while another Candidate Act
remains pending.
33.76.20 — Expected Result
The affected operation is revalidated or refused under current
mandatory policy.
5.7.3.70. Original Global Page 2895
33.76.21 — Rollback Variation
An old permissive policy file is restored.
33.76.22 — Expected Result
The old file cannot independently restore revoked source authority or
spent finality.
33.77 — OPTIONAL ADVANCED VARIATIONS
33.77.1 — Authorization Policy
The actual resource access-control rules are protected.
Das Expires 29 April 2027 [Page 505]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.77.2 — Network Security Policy
Consequential egress and destination permissions are governed through
protected updates.
33.77.3 — Credential Broker Policy
Key-use and token permissions are changed under independent meta-
authority.
33.77.4 — Runtime Tool Policy
Agent tool allowlists and effect classes are protected.
33.77.5 — Agent Delegation Policy
Child-agent consequential permissions are changed only through
qualified activation.
33.77.6 — Multi-Agent Quorum Policy
Required approval roles and thresholds are subject to protected
administration.
33.77.7 — Memory Trust Policy
Classification and promotion of persistent memory items are
protected.
33.77.8 — Cloud Deployment Policy
Production deployment permissions are bound to current protected rule
generations.
33.77.9 — Database Mutation Policy
Resource writes require current authorization and actual transaction
finality.
33.77.10 — Payment Policy
5.7.3.71. Original Global Page 2896
Recipient, amount, and cumulative transfer restrictions remain
separate from policy activation.
33.77.11 — Hardware Safety Policy
Das Expires 29 April 2027 [Page 506]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Current actuation limits are enforced at the actual device sink.
33.77.12 — Schema Evolution
A policy's schema transition triggers semantic impact analysis.
33.77.13 — Interpreter Evolution
The policy runtime generation is independently qualified.
33.77.14 — Distributed Policy Rollout
Different enforcement cohorts are governed through current adoption
and fencing.
33.77.15 — Emergency Restrictions
Qualified emergency controls may selectively fence affected
operations.
33.77.16 — Bounded Emergency Exceptions
Temporary exceptional permissions remain scope and generation
limited.
33.77.17 — Protected Rollback
Earlier policy content may be reactivated as a new currently
authorized transition.
33.77.18 — Alternative Enforcement Substrate
A protected rule may be enforced through software, operating-system
mechanisms, hardware, or another qualified resource boundary.
33.77.19 — Policy-Proof Assistants
Automated testing or formal analysis may provide qualified evidence
without independently granting activation authority.
33.77.20 — Protected Causal Policy Receipts
A later workflow operation may require accepted evidence that a
specific policy transition actually completed, while remaining
subject to its own current resource-effect authority.
33.78 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
Das Expires 29 April 2027 [Page 507]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.7.3.72. Original Global Page 2897
33.78.1 — Established Foundations
Existing systems provide:
Policy-as-code;
Configuration management;
Signed policy bundles;
Rule validation;
Policy-difference analysis;
Canary deployment;
Admission control;
Versioned authorization;
Access-control lists;
Revocation;
Transactional updates;
And resource authorization gateways.
These should be treated as established technical foundations.
33.78.2 — Candidate Objective Technical Problem
How to allow autonomous agents to propose and carry out authorized
policy changes without permitting such changes to self-create
consequential authority, and how to preserve correct current
authorization for in-flight resource operations when policy content,
interpretation, activation, or enforcement state changes during their
execution.
33.78.3 — Proposed Technical Solution
The policy change is represented as a non-effective Candidate Act.
A protected meta-authority determines whether the proposed change may
be activated.
Das Expires 29 April 2027 [Page 508]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A semantic analyzer identifies actual permission changes under a
qualified policy interpretation model.
A protected dependency graph identifies the Candidate Acts and
enforcement paths affected by those changes.
Material changes trigger protected pending-finality fencing.
5.7.3.73. Original Global Page 2898
The policy activation sink verifies and commits the qualified new
rule.
Required enforcement components establish current adoption.
Pending consequential operations are independently revalidated
against current original source authority and resource-specific
policy.
Scoped non-bearer finality is constituted.
The actual resource Finality Sink reconstructs and verifies the
pending effect before protected consumption.
33.78.4 — Not Merely Policy-as-Code
A policy-as-code system represents and deploys authorization rules.
The proposed combination separates policy drafting, competent
activation, and independent resource-specific effectuation authority.
33.78.5 — Not Merely Signed Policy Deployment
A signature protects selected package integrity and source
authentication.
The proposed combination additionally checks whether the actual
semantic change is authorized and whether the consequent resource
operation remains independently permitted.
33.78.6 — Not Merely Policy Diffing
A diff can identify changes.
The proposed arrangement makes qualified semantic changes govern
protected pending-operation fencing and subsequent finality.
33.78.7 — Not Merely Versioned Authorization
Das Expires 29 April 2027 [Page 509]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A policy version can identify the rules evaluated.
The proposed combination binds relevant content, schema, interpreter,
activation, and actual enforcement generations to the Candidate Act
and Finality Sink.
33.78.8 — Not Merely Canary Deployment
Canary deployment may reduce deployment risk.
The proposed stronger implementation requires an actual protected
policy activation and independent current authorization of
consequential operations.
33.78.9 — Not Merely Resource Access Control
A resource may permit a request under an active rule.
5.7.3.74. Original Global Page 2899
The system separately requires the original task principal's current
authority and operation-specific protected finality.
33.78.10 — Candidate Narrow Inventive Kernel
A protected autonomous policy-evolution system in which a proposed
authorization or enforcement-policy modification is represented as a
Candidate Act maintained non-effective under a separately
authenticated meta-authority, a protected controller determines the
qualified semantic impact of the modification upon existing
consequential-operation dependencies and fences affected pending
finality, a policy activation Finality Sink commits an authorized
policy generation, and an independent actual resource Finality Sink
reconstructs a subsequent pending operation and permits effectuation
only upon current originating source authorization, applicable policy
and enforcement-generation verification, scoped non-bearer finality,
and protected sink-local consumption.
33.78.11 — Self-Authorization Prevention Kernel
A narrower candidate may require that a rule granting the proposing
workload additional access cannot supply the meta-authority necessary
for its own activation.
33.78.12 — Semantic Dependency Kernel
Another candidate may require typed semantic policy differences to
drive selective invalidation of pending operation-specific finality.
Das Expires 29 April 2027 [Page 510]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.78.13 — Interpreter-Continuity Kernel
Another candidate may bind current authorization to policy content,
schema, and interpreter generations, requiring revalidation when any
mandatory semantic input changes.
33.78.14 — Distributed Enforcement Kernel
Another candidate may require selected protected sinks to verify
current policy adoption generation before effectuation, preventing
use of stale permissive enforcement routes.
33.78.15 — Policy Rollback Kernel
Another candidate may permit competent reactivation of old policy
content as a new protected generation while preventing restoration of
current revocations or consumed finality.
33.78.16 — Dual-Finality Kernel
Another candidate may require distinct non-bearer finality for the
policy activation and for an actual resource operation governed by
that policy.
33.78.17 — Hindsight and Functional-Combination Analysis
5.7.3.75. Original Global Page 2900
A later inventive-step response should identify the closest existing
dynamic policy-control system, particularly one that already supports
signed policy updates, authorization versioning, distributed rollout,
and enforcement at resource boundaries.
The comparison should not assume that policy signing, versioning,
change-impact analysis, testing, or access control are individually
new.
The technical analysis should determine whether the cited prior art
already teaches the complete claimed relationship among:
1. A policy mutation held as a non-effective Candidate Act; 2. A
separately competent meta-authority preventing self-authorization; 3.
Qualified semantic rule analysis under actual interpretation
conditions; 4. Operation-specific policy-dependency analysis; 5.
Protected fencing of affected pending operation finality; 6.
Independently controlled policy activation; 7. Current policy
content and interpretation continuity; 8. Actual enforcement-
adoption verification; 9. Independent originating source
Das Expires 29 April 2027 [Page 511]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
authorization for subsequent resource operations; 10. Separate
actual Finality-Sink reconstruction and protected consumption; 11.
Nonresurrection of revoked or consumed authority through rollback.
The proposed technical interaction is not simply that these controls
appear in the same software application.
The policy-mutation boundary prevents an unauthorized security-rule
change.
The dependency controller prevents stale rule assumptions from
remaining effective for affected pending operations.
The policy activation sink establishes the current qualified rule
generation.
The actual resource sink separately prevents the changed rules from
enabling a source-unauthorized real consequence.
These mechanisms can be evaluated through controlled comparisons that
remove individual mandatory relationships.
33.78.18 — Causal Technical Effects to Demonstrate
A prototype may demonstrate:
Prevention of autonomous privilege expansion through self-authored
policy mutations;
Prevention of stale-policy operations after a material restriction;
Prevention of source-unauthorized resource effects following a valid
permissive policy update;
Prevention of resource effects through obsolete enforcement
revisions;
5.7.3.76. Original Global Page 2901
Prevention of authority resurrection following rollback;
And selective preservation of otherwise valid pending operations
unaffected by the policy change.
33.78.19 — Important Patentability Qualification
The proposed features are candidate technical claim limitations.
Das Expires 29 April 2027 [Page 512]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Whether their combination is novel or involves an inventive step
depends upon the relevant actual prior art and the claimed
interaction.
The analysis should not rely upon the unsupported assertion that
combining familiar components is inherently inventive or non-obvious.
Evidence of a previously unaddressed technical effect may strengthen
an argument, but such evidence must be evaluated against the actual
teachings and reasonable combinations of prior disclosures.
33.79 — INDUSTRIAL APPLICABILITY
33.79.1 — Enterprise AI Agents
Autonomous systems may propose bounded rule changes without gaining
unlimited administrative authority.
33.79.2 — Cloud Infrastructure
Dynamic cloud permissions may be updated without automatically
authorizing pending unauthorized operations.
33.79.3 — Identity and Access Management
Administrative permission rules may evolve under protected source and
meta-authority.
33.79.4 — API Gateways
Authorization and egress controls may be changed while actual
requests remain independently verified.
33.79.5 — Software Deployment
Release rules may evolve without bypassing production deployment
finality.
33.79.6 — Database Administration
Database access rules may be updated under current transactional
effectuation conditions.
5.7.3.77. Original Global Page 2902
33.79.7 — Financial Systems
Das Expires 29 April 2027 [Page 513]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Payment policies may change while individual transfers remain source-
authorized and effect-bound.
33.79.8 — Credential Management
Broker and key-use policies may evolve without granting unrestricted
secret authority.
33.79.9 — Multi-Agent Frameworks
Delegation and tool permissions may change without uncontrolled
downstream authority.
33.79.10 — Persistent AI Memory
Memory trust and sharing policies may be modified through protected
authority-promotion boundaries.
33.79.11 — Network Security
Firewall and egress policies may be changed under mandatory
effectuation-route constraints.
33.79.12 — Telecommunications
Network-control policies may be updated while actual device and
network effects remain independently qualified.
33.79.13 — Industrial Automation
Operational limits may change without authorizing stale physical
commands.
33.79.14 — Robotics
Current actuation policies may be enforced despite controller
reconfiguration.
33.79.15 — Autonomous Transportation
Command and safety-rule changes may require current source and
resource finality.
33.79.16 — Satellite and Edge Systems
Delayed or partially distributed policy updates may be governed
through protected generation and local enforcement.
Das Expires 29 April 2027 [Page 514]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
33.79.17 — Security Incident Response
Emergency restrictions and bounded exceptions may be activated
without creating uncontrolled lasting authority.
33.79.18 — Distributed Enterprise Platforms
5.7.3.78. Original Global Page 2903
Versioned policy deployment may preserve current resource
authorization across multiple services.
33.79.19 — Hardware Security Infrastructure
Policy updates affecting protected cryptographic or command
interfaces may be independently enforced.
33.79.20 — Future Autonomous Critical Systems
Dynamic machine-generated policy changes may remain subordinate to
qualified administration and actual effectuation authority.
33.80 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
33.80.1 — Candidate Independent System Claim
A system comprising:
A protected originating authority controller maintaining permitted
consequential task scope;
A protected meta-authority controller identifying competent
principals for security-policy modification;
A Candidate Act controller configured to represent a proposed policy
or enforcement-configuration change in a Non-Effective State;
A semantic impact controller configured to determine qualified
material authorization differences between policy generations;
A protected dependency controller configured to identify pending
consequential Candidate Acts affected by such differences and fence
corresponding pending finality;
A policy activation Finality Sink configured to verify and
conditionally commit the actual qualified policy mutation;
Das Expires 29 April 2027 [Page 515]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An execution-time validator configured to verify current original
source authority, applicable policy semantics, and actual resource
state for a dependent consequential operation;
A scoped non-bearer finality controller;
And an independent actual resource Finality Sink configured to
reconstruct the pending operation and permit effectuation only
following verification of current source, policy, resource, and sink-
local consumption conditions.
33.80.2 — Candidate Independent Method Claim
A method comprising:
5.7.3.79. Original Global Page 2904
Receiving an autonomously generated policy modification;
Constructing a Policy-Mutation Candidate Act;
Maintaining the proposed change non-effective;
Determining competent policy-change authority independently of the
proposed policy;
Analyzing the proposed rule under a qualified schema and interpreter;
Identifying affected pending consequential operations;
Fencing pending finality dependent upon material changes;
Activating the qualified policy through an independent protected
sink;
Establishing current enforcement-generation evidence;
Independently revalidating a pending resource operation under current
source and policy authority;
Preparing scoped non-bearer finality;
And conditionally permitting the actual resource effect through sink-
local verification and protected consumption.
33.80.3 — Candidate Independent Self-Authorization Claim
Das Expires 29 April 2027 [Page 516]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected autonomous policy-management system configured to prevent
a policy generated by a computational workload from establishing the
administrative authority necessary for its own activation, by
requiring a separately protected competent meta-authority and
operation-specific activation finality.
33.80.4 — Candidate Independent Dependency-Fencing Claim
A system configured to associate consequential Candidate Acts with
qualified authorization-policy dependencies, identify material
changes in effective policy decisions, and invalidate or revalidate
only affected pending finality before actual resource effectuation.
33.80.5 — Candidate Independent Dual-Finality Claim
A system configured to require independent protected finality for
activation of an authorization-policy change and for a subsequent
consequential resource operation, such that successful rule
activation does not independently establish the source authorization
or actual resource finality of the subsequent operation.
33.81 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
5.7.3.80. Original Global Page 2905
1. The policy change is proposed by an autonomous agent. 2. The
policy comprises access-control rules. 3. The policy comprises tool
invocation permissions. 4. The policy comprises network egress
permissions. 5. The policy comprises credential-use permissions. 6.
The policy comprises persistent-memory classification rules. 7. The
policy comprises resource-administration permissions. 8. The policy
comprises a hardware command restriction. 9. A meta-authority root
identifies competent rule administrators. 10. The proposed rule
cannot independently establish its own activation authority. 11.
Policy drafting permission is distinguished from activation
permission. 12. Activation permission is distinguished from
permission for a downstream resource
effect. 13. The policy change is represented as a Candidate Act. 14.
The Candidate Act is maintained non-effective. 15. The Candidate Act
identifies the actual target policy. 16. The Candidate Act
identifies proposed operative rule content. 17. The Candidate Act
identifies current policy generation. 18. The Candidate Act
identifies applicable schema generation. 19. The Candidate Act
identifies applicable interpreter generation. 20. The Candidate Act
identifies intended enforcement domain. 21. The protected controller
verifies competent administrative authority. 22. The protected
controller verifies original task permission. 23. The protected
Das Expires 29 April 2027 [Page 517]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
controller checks current mandatory security invariants. 24. A rule
cannot remove a mandatory enforcement gate without qualified
authorization
and preservation of applicable guarantees. 25. A rule cannot reduce
required approval conditions without competent authorization. 26. A
role-hierarchy change may be classified as an indirect permission
expansion. 27. A wildcard change may be classified as a permission
expansion. 28. A default-rule change may be classified as a material
semantic change. 29. A policy is evaluated under a typed schema. 30.
A policy is evaluated under a qualified interpreter generation. 31.
The system compares old and proposed effective authorization
conditions. 32. The comparison identifies newly permitted resource
effects. 33. The comparison identifies newly restricted resource
effects. 34. The comparison identifies changed administrative roles.
35. The comparison identifies altered mandatory vetoes. 36. The
comparison identifies changed enforcement routing. 37. The
comparison identifies affected resource classes. 38. The comparison
identifies pending Candidate Acts dependent upon modified rules. 39.
A protected policy dependency graph may represent direct and indirect
relationships. 40. A material rule change may fence affected pending
finality. 41. A provably unrelated change need not invalidate an
unaffected operation. 42. An unknown mandatory change may trigger a
conservative protected fence. 43. A semantic-equivalence conclusion
is qualified by the tested or formally modeled
domain. 44. A shadow policy result is not treated as actual resource
authorization. 45. A valid policy signature does not independently
prove authorization to expand its
permissions. 46. A protected activation sink verifies the actual
proposed policy artifact.
5.7.3.81. Original Global Page 2906
47. The activation sink verifies current competent meta-authority.
48. The activation sink verifies applicable policy invariants. 49.
The activation sink verifies the expected preceding policy
generation. 50. The activation sink commits a successor
authoritative generation. 51. A policy activation receipt is
distinguished from an actual resource-effect receipt. 52. A
distributed policy rollout may use authenticated policy bundles. 53.
Each protected resource sink may identify its accepted policy
generation. 54. A required current enforcement generation may be
checked before effectuation. 55. A stale permissive enforcement
gateway may be prevented from releasing an affected
Das Expires 29 April 2027 [Page 518]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
operation. 56. An enforcement-readiness record may identify active
enforcement mode. 57. A monitoring-only component is not treated as
equivalent to a required non-
bypassable gate. 58. A policy content version may be distinct from a
policy activation generation. 59. A policy content generation may be
distinct from a schema generation. 60. A schema generation may be
distinct from an interpreter generation. 61. A source-authorized
Candidate Act may be bound to a qualified current policy
witness. 62. An independent validator may reconstruct the actual
pending operation. 63. The validator checks current originating
source authority. 64. The validator checks current effective
authorization policy. 65. The validator checks current resource
identity. 66. The validator checks current revocation conditions.
67. The validator checks mandatory security vetoes. 68. Scoped non-
bearer finality may include current policy-generation conditions. 69.
The finality may be bound to one actual resource sink. 70. The sink
verifies actual material operation parameters. 71. The sink verifies
current policy adoption. 72. The sink verifies protected finality
consumption. 73. A newly permissive rule does not automatically
grant original task authority. 74. A newly restrictive rule may
invalidate earlier pending effectuation permission. 75. A rollback
is treated as a new qualified activation transition. 76. Restoring
older policy content does not restore previously consumed finality.
77. Restoring older policy content does not override current
mandatory revocation. 78. A policy update may change credential-
broker scope without independently
authorizing credential exercise. 79. A policy update may change
memory trust rules without independently promoting
stored information to source authority. 80. A policy update may
change agent-delegation scope without multiplying original
source permission. 81. A policy update may change device operation
limits subject to current device-sink
verification. 82. A material configuration change may be checked for
Finality-Sink bypass. 83. A protected emergency rule may have
bounded resource and operation scope. 84. A protected emergency
exception may require explicit current competence. 85. Expired
exceptional authority may become ineligible for further effects. 86.
An enforcement process restored from an older snapshot may require
current
generation requalification. 87. Policy-distribution success is not
automatically treated as proof of actual enforcement
Das Expires 29 April 2027 [Page 519]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
adoption.
5.7.3.82. Original Global Page 2907
88. A qualified policy activation receipt may support a specified
later causal prerequisite. 89. A successor resource operation still
requires independent current source authorization. 90. The protected
policy system may use a transactional database to maintain activation
generations. 91. A versioned configuration store may maintain
authenticated policy packages. 92. A policy validation engine may
evaluate typed rule syntax and semantics. 93. A dependency analyzer
may operate over a qualified graph of resources, policies, and
Candidate Acts. 94. A protected API or database gateway may enforce
actual policy-dependent
consequences. 95. Existing authorization engines, signed bundles,
schema validation, admission
controls, transactional systems, and versioned resource gateways may
serve as optional implementation substrates.
33.82 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The disclosed mechanisms may be implemented individually where
technically sufficient or in compatible combinations.
An implementation may use declarative policy-as-code.
Another may use a compiled authorization language.
Another may use an attribute-based decision engine.
Another may use protected access-control tables.
Another may use signed policy bundles.
Another may use transactional configuration activation.
Another may use a policy dependency graph.
Another may use static semantic analysis.
Another may use dynamic policy evaluation.
Das Expires 29 April 2027 [Page 520]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Another may use symbolic or formal verification for selected
properties.
Another may use shadow evaluation.
Another may use staged or canary policy deployment.
Another may use independent enforcement-generation attestation.
Another may use a protected admission controller.
5.7.3.83. Original Global Page 2908
Another may use an actual resource-sink authorization gateway.
Another may use protected rollback and revocation generations.
Another may use a policy activation Finality Sink.
Another may use separate Finality Sinks for policy activation and
subsequent resource operations.
The invention does not require a particular authorization language.
The invention does not require a specific number of policy rules.
The invention does not require that all policy changes expand
permission.
The invention does not require that every nonmaterial policy update
stop all autonomous computation.
The invention does not require that a syntactically valid rule be
considered safe.
The invention does not assume that a signed bundle is semantically
authorized.
The invention does not assume that a policy test suite proves every
possible authorization behavior.
The invention does not assume that all enforcement nodes activate a
distributed update simultaneously.
The invention does not require a single global policy version where
independent resource domains may use separately qualified
generations.
Das Expires 29 April 2027 [Page 521]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invention does not assume that a reported policy update means
every actual effectuation path enforces it.
The invention does not treat a policy activated under competent
administrative authority as an unrestricted original task grant.
The invention does not permit a lower-trust agent to authorize its
own privilege elevation by changing the rules controlling its
authority.
The invention does not require eliminating all model-generated policy
mistakes to protect the covered consequential effectuation paths.
The invention does not permit a policy rollback to restore revoked or
consumed finality solely through older configuration state.
The algorithms, data structures, diagrams, mathematical
representations, experimental proposals, and reference procedures are
illustrative and non-limiting technical aids intended to assist a
person having ordinary skill in the art.
5.7.3.84. Original Global Page 2909
Compatible embodiments may be cross-referenced or combined where
technically supported without making every optional feature
universally mandatory.
33.83 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 33 discloses a protected autonomous policy-
evolution and execution-finality architecture for systems in which
authorization and enforcement rules may be generated, modified,
activated, revoked, or rolled back during ongoing computational
operation.
An autonomous workload may propose a rule change.
The rule change is represented as a Policy-Mutation Candidate Act
held in a Non-Effective State.
A protected meta-authority controller establishes whether the
workload or another qualified principal possesses the permission
required to activate the specific change.
A protected semantic analyzer identifies the qualified actual effects
of the proposed rule under its applicable schema and interpreter.
Das Expires 29 April 2027 [Page 522]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected dependency controller identifies the Candidate Acts and
enforcement routes affected by material policy changes.
Affected pending finality may be fenced until current authorization
is established.
A separate policy activation Finality Sink verifies and commits the
actual qualified rule change.
Distributed enforcement components are qualified against their
applicable current policy generations.
The newly active rules do not automatically expand the originating
task's consequential authority.
A pending or subsequently proposed resource operation is
independently revalidated under current source, policy, resource, and
revocation state.
Scoped non-bearer finality is constituted for the eligible operation.
The actual receiving-resource Finality Sink reconstructs the pending
consequence and verifies the corresponding material parameters,
source authority, policy generation, resource conditions, and
protected sink-local consumption before releasing the effect.
A policy update cannot automatically authorize itself.
A valid policy signature cannot independently authorize every effect
permitted by the signed package.
5.7.3.85. Original Global Page 2910
A successful deployment cannot substitute for actual receiving-
resource enforcement.
A policy rollback cannot automatically resurrect previously consumed
or revoked authority.
And legitimate policy evolution may proceed without unnecessarily
invalidating unrelated autonomous computations.
The principal candidate inventive technical concept of Embodiment 33
is a protected autonomous policy-to-effect-finality system in which
policy changes are separately non-effective Candidate Acts governed
by competent meta-authority, qualified semantic impact and dependency
analysis selectively fence affected pending operations, actual policy
activation is independently enforced, and subsequent consequential
Das Expires 29 April 2027 [Page 523]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
resource operations remain subject to current source authorization,
policy-generation correspondence, scoped non-bearer finality, and
actual resource-sink reconstruction and consumption.
33.84 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may implement the disclosed mechanisms using existing
technologies as optional substrates.
Existing technology Optional technical role
Open Policy Agent (OPA) Evaluate selected authorization rules and
distribute versioned policy bundles
Signed OPA policy bundles Authenticate the content of selected policy
packages before activation
Cedar authorization language Express typed policies and validate them
against defined schemas Kubernetes validating admission controls
Enforce selected protected configuration-admission conditions
Transactional SQL databases Maintain current policy generations,
Candidate Act dependencies, protected activation, and consumption
state Strongly consistent configuration stores
Maintain qualified current activation and revocation generations
Cryptographic hashes and digital signatures Authenticate actual
policy artifacts and transition records
Typed JSON or CBOR Encode Policy-Mutation Candidate Acts and current
policy witnesses Policy test harnesses Compare defined policy
decisions before and after changes
Dependency graphs Track which resource operations depend upon
particular policy predicates Change-data capture and event streams
Notify protected controllers of qualified policy changes
5.7.3.86. Original Global Page 2911
Transactional outbox mechanisms
Coordinate committed policy transitions with asynchronous enforcement
distribution Mutual TLS and protected workload identities
Authenticate policy administrators, agents, gateways, and receiving
sinks Conditional HTTP requests and resource versions Apply selected
version-dependent resource updates
Das Expires 29 April 2027 [Page 524]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Protected API and resource gateways Verify actual consequential
requests under current authority
Durable operation journals Preserve policy activation, resource
effect, consumption, and indeterminate states
33.84.1 — Practical Common Implementation Workflow
A PHOSITA may implement the embodiment as follows:
First, maintain a protected meta-authority registry defining which
principals can modify particular security-policy classes.
Second, store current policy content, schema, interpreter, and
activation generations in a protected authoritative registry.
Third, require an autonomous policy-generation agent to submit its
proposed change as a Policy-Mutation Candidate Act rather than
directly overwriting live rules.
Fourth, keep the change non-effective while validating its content,
source authority, and required administrative competence.
Fifth, use a policy engine or analyzer to compare representative or
formally qualified authorization behavior under old and proposed
policy versions.
Sixth, identify the pending Candidate Acts, resources, and
enforcement routes materially dependent upon the modified policy.
Seventh, fence affected pending finality where the applicable
permissions or mandatory enforcement conditions change.
Eighth, commit the qualified policy transition through a protected
policy activation service that checks the exact artifact and current
authorized generation.
Ninth, distribute the activated policy to relevant resource
enforcement gateways and record their qualified current adoption
state.
Tenth, require any affected consequential operation to undergo
current original source, policy, resource, and revocation validation.
Eleventh, constitute scoped non-bearer finality for the actual
eligible resource operation.
Das Expires 29 April 2027 [Page 525]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Twelfth, require the receiving resource Finality Sink to reconstruct
and independently verify the actual pending effect under the current
relevant policy generation.
5.7.3.87. Original Global Page 2912
Thirteenth, commit protected finality consumption and release only
the authorized operation.
Fourteenth, preserve current revocation and consumption state during
rollback, restart, policy recovery, or partial distributed rollout.
33.84.2 — Minimal Reference Data Structures
POLICY_REGISTRY ( policy_id, content_digest, content_generation,
schema_generation, interpreter_generation, activation_generation,
revocation_generation ) POLICY_CHANGE_CANDIDATE ( candidate_id,
source_grant_reference, policy_id, predecessor_generation,
proposed_content_digest, proposed_effect_scope, activation_state )
POLICY_DEPENDENCY ( policy_id, operation_candidate_id,
relevant_resource_class, affected_rule_reference )
ENFORCEMENT_ADOPTION ( sink_id, policy_id, active_generation,
enforcement_mode, protected_adoption_status ) RESOURCE_FINALITY (
operation_candidate_id, source_authority_generation,
required_policy_generation, resource_id, actual_operation_digest,
consumption_state )
5.7.3.88. Original Global Page 2913
The schema is illustrative, not essential.
Field names or storage records alone do not establish security.
The actual enforcement mechanism must implement the claimed current
authorization, fencing, and protected effectuation properties.
33.84.3 — Important Implementation Cautions
A signed policy bundle proves the properties actually provided by the
signature-verification scheme; it does not necessarily establish
administrative permission to expand resource authority.
A schema validator can detect defined typing and reference errors
without establishing that every authorized effect is intended.
A shadow evaluation can compare decisions without controlling an
actual resource effect.
Das Expires 29 April 2027 [Page 526]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A distributed policy bundle mechanism may be eventually consistent;
it should not be treated as instant global revocation.
An admission webhook may be configured with fail-open or fail-closed
behavior. A PHOSITA must choose and verify the actual behavior
required by the proposed protected effectuation model.
A conditional resource update can prevent selected lost-update races
without replacing independent source authorization.
A local transaction cannot automatically provide atomic finality
across separately operated remote resources.
33.84.4 — Non-Limiting Common Reference Combination
Original source authority → protected meta-authority → autonomous
policy proposal → Policy-Mutation Candidate Act → non-effective hold
→ semantic impact validation → operation dependency graph → affected
finality fence → qualified policy activation → current enforcement
generation → independent resource-operation revalidation → scoped
non-bearer finality → actual Finality Sink → actual operation and
current policy verification → protected consumption → controlled
consequential effect.
The existing technologies provide practical policy languages,
authorization engines, signed deployment artifacts, admission
controls, versioned configuration, transactional storage, and
resource gateways.
The proposed distinguishing technical relationship is the non-self-
authorizing transition from machine-generated policy changes into
actual authority-bearing configuration, combined with selective
invalidation of affected pending operations and independent source-
authorized finality for every covered real resource effect governed
by the evolving rules.
5.8. Embodiment 38: Independent Witness, Attestation and Evidence-
Qualification Enforcement
Original source global pages 3282–3378; attachment TECHNICAL
SPECIFICATION -3102-3567.pdf. Figures depict an explanatory
implementation mapping of this disclosed embodiment or supporting
material; all trust limitations and optionality in the original text
remain applicable.
5.8.1. Architecture Diagram: Protected Components and Trust Boundaries
Das Expires 29 April 2027 [Page 527]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[Collection-time evidence + protected observer]
|
[Witness identity / competence / independence]
|
[Optional attestation evidence and appraisal]
|
[Separate execution-time actual operation evidence]
|
[Cross-domain evidence consistency and commitment]
|
[Scoped non-bearer authority + actual FS]
|
[Consume and effect OR quarantine evidence]
Figure 15: Embodiment 38: Independent Witness, Attestation and
Evidence- Qualification Enforcement: architecture
5.8.2. Operational Flowchart: Verification, Withholding and
Effectuation
[Evidence from monitors/witnesses arrives]
|
<Authentic, competent, independent?> --NO--> [QUARANTINE]
| YES
<Freshness / attestation/observation valid?>--NO-->[HOLD]
| YES
<Actual operation matches committed evidence?>--NO-->[REFUSE]
| YES
<Sink coverage and consumption state valid?>--NO-->[REFUSE]
| YES
[Protected consume, qualified effect]
Figure 16: Embodiment 38: Independent Witness, Attestation and
Evidence- Qualification Enforcement: operational decision flow
5.8.3. Page-Indexed Original Technical Text
5.8.3.1. Original Global Page 3282
A current source grant cannot substitute for required functional-
safety engineering.
A valid hazard-state signature does not prove that the sensor or
underlying model is accurate.
An old hazard observation may become invalid before effectuation.
Das Expires 29 April 2027 [Page 528]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A local database transaction does not make a remote irreversible
physical operation atomic.
A command acknowledgement does not necessarily prove physical
completion.
A key-deletion command does not necessarily destroy every backup or
duplicate.
A data retraction cannot guarantee deletion of all external copies.
A compensating financial transaction does not erase the historical
original transfer.
The actual resource consistency and enforcement model determines the
scope of the achievable finality guarantee.
37.87.5 — Non-Limiting Common Reference Combination
Original consequence authority → Consequence Candidate Act → Non-
Effective State → actual target and effect-semantic qualification →
irreversibility classification → actual frontier identification →
protected current hazard-state evidence → mandatory source, resource,
safety, and effect-budget verification → material hazard-change
fencing → independent current validation → consequence-bound non-
bearer finality → actual receiving Finality Sink → independent
operation and hazard reconstruction → protected bounded consumption →
controlled irreversible effectuation → actual outcome qualification →
separately authorized post-effect mitigation where applicable.
The proposed distinguishing technical relationship is the mandatory
coupling of actual irreversible consequence authority, enforceable
pre-frontier non-effectuation, independent current hazard and
resource validation, scoped non-bearer release, and protected sink-
local consumption, so that the autonomous workload cannot turn a
valid-looking command or earlier approval into an unqualified
irreversible real-world effect.
END OF EMBODIMENT 37 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 38
PROTECTED AUTONOMOUS EVIDENCE INTEGRITY AND ATTESTATION CONTINUITY
WITH COMPROMISED-OBSERVER CONTAINMENT, CROSS-DOMAIN WITNESS
QUALIFICATION, AND INDEPENDENT FINALITY-SINK EVIDENCE RECONSTRUCTION
38.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 529]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Using Protected Collection-Time Evidence,
Qualified Observer Provenance
5.8.3.2. Original Global Page 3283
and Competence, Attested Measurement and Appraisal Continuity,
Independent Execution-Time Witness Corroboration, Observation-Channel
Separation, Cross-Domain Evidence-Semantics Correspondence, Protected
Evidence-Generation and Freshness Fencing, Compromised-Observer
Dependency Containment, Cross-Committed Validation Receipts, Scoped
Non-Bearer Finality Enablement, Independent Finality-Sink
Reconstruction of Actual Pending Effects, Sink-Local Protected
Consumption, and Evidence-Based Recovery Without Unverified Authority
Propagation
38.0.1 — General Technical Description
The present Embodiment 38 discloses systems, methods, apparatus,
protected computing components, autonomous operation controllers,
qualified evidence collectors, protected observation domains,
measurement provenance registries, attestation appraisal controllers,
independent witness validators, cross-domain evidence exchange
components, compromise-containment controllers, protected validation
receipt generators, scoped non-bearer finality controllers, and
independently enforcing actual Finality Sinks configured to prevent
autonomously generated consequential operations from becoming
effective on the basis of fabricated, stale, incomplete, compromised,
misinterpreted, or materially mismatched evidence.
An autonomous computational workload may receive information from:
An AI model;
A tool response;
An application programming interface;
A sensor;
An operating-system monitor;
A file or database observer;
A network monitor;
A protected execution environment;
Das Expires 29 April 2027 [Page 530]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A cryptographic attestation service;
A resource owner;
An authenticated human confirmation interface;
A remote authority service;
A distributed monitoring system;
A service registry;
5.8.3.3. Original Global Page 3284
Or another evidence-producing entity.
The workload may use that information to prepare a consequential
operation.
For example, an autonomous agent may be instructed to perform a
financial transaction only when a particular source account,
recipient, amount, and authorization state are valid.
A robotic controller may be permitted to actuate a device only when
qualified current operating conditions are satisfied.
A cloud automation controller may modify a resource only when the
current owner, policy, and resource version correspond to the
originating task.
A data disclosure agent may transmit information only when the actual
recipient, content classification, and permission are verified.
A credential controller may activate a secret only when the actual
receiving service and resource conditions are qualified.
The computational workload may obtain evidence that appears to
establish the required conditions.
However, the evidence-producing component may be compromised.
A sensor may be authentic but inaccurate.
A software observer may be correctly identified while reporting an
earlier resource state.
A runtime monitor may observe a proposed operation but not the actual
operation dispatched through a privileged backend.
Das Expires 29 April 2027 [Page 531]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent may provide an authentic tool response that is outside the
required authority domain.
A protected observer may be attested as running an approved software
measurement while its observation path fails to cover a changed
downstream interface.
A remote service may provide a signed statement whose meaning differs
from the interpretation applied by the local validator.
A policy engine may receive an evidence value with incorrect units,
resource scope, tenant identity, or measurement generation.
Two independent-looking evidence records may originate from the same
compromised underlying source.
A cryptographic signature may validate while the actual measured
condition is false.
A protected measurement register may contain a valid software
measurement without establishing the correctness of every runtime
decision.
5.8.3.4. Original Global Page 3285
An evidence log may be append-only while containing inaccurate
original observations.
An authenticated receipt may prove only that a command was
dispatched, while the downstream validator treats it as proof that
the resource effect completed.
A resource may change after collection-time observation.
An attacker may replay an earlier qualified witness or substitute
evidence from another Candidate Act.
An evidence verifier may become compromised after issuing an earlier
attestation result.
A resource may be migrated to another receiving service while the
originating workload retains evidence about the predecessor.
A trusted component may reboot into a different software generation.
A previously permitted evidence source may lose authority or have its
key revoked.
Das Expires 29 April 2027 [Page 532]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A monitoring system may experience a network partition and be unable
to obtain fresh state.
The present embodiment recognizes that the existence of authentic
evidence does not itself establish authority to cause a consequential
effect.
The system therefore distinguishes:
The identity of the evidence producer;
Its competence to observe the relevant property;
The protected state of the observation mechanism;
The property actually measured;
The observation's resource, time, generation, and operation scope;
The interpretation applied to that observation;
The qualified degree of independence between observation channels;
The current authority to rely upon the evidence;
And the separate question of whether the actual pending resource
effect is authorized at its Finality Sink.
An originating source-authority controller establishes the intended
consequential operation.
The autonomous workload constructs a Candidate Act.
The Candidate Act remains in a Non-Effective State.
5.8.3.5. Original Global Page 3286
A protected evidence-policy controller identifies the mandatory
observations needed for the particular operation.
Those observations may include source authorization, actual resource
identity, transaction parameters, tool behavior, current policy,
revocation state, physical conditions, credential audience, or other
relevant predicates.
Each required observation is associated with a qualified evidence-
source role and competence requirement.
Das Expires 29 April 2027 [Page 533]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Collection-time evidence is acquired and protected.
A qualified attestation mechanism may establish selected properties
of the observer or its execution environment.
Independent appraisal may assess whether those properties satisfy the
applicable evidence-source policy.
The protected controller does not automatically infer the truth or
completeness of the observed real-world facts from successful
attestation.
A separate execution-time validation instance obtains current
relevant evidence through a qualified observation path.
Where required, the observation path is sufficiently independent from
the proposing agent and collection-time witness to satisfy the
relevant fault or compromise model.
The protected controller compares collection-time and execution-time
evidence.
It evaluates:
Identity continuity;
Observation generation;
Resource correspondence;
Operation parameters;
Relevant freshness;
Measurement semantics;
Witness competence;
Current source and resource authority;
And evidence-source revocation.
5.8.3.6. Original Global Page 3287
Where evidence is contradictory, incomplete, stale, compromised, or
outside its asserted competence, the affected Candidate Act is
withheld or revalidated.
Das Expires 29 April 2027 [Page 534]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A protected observer-compromise controller identifies which pending
operations depend upon affected evidence.
It fences those operations without necessarily suspending unrelated
operations whose mandatory evidence remains qualified.
Where sufficient independent evidence is available, the controller
may reconstitute operation eligibility under the applicable protected
policy.
However, a replacement witness does not create new originating source
authorization.
Upon successful qualification, the system generates protected
validation evidence that binds the Candidate Act, collection-time
witness, independent execution-time witness, actual resource and
operation descriptors, relevant attestation results, and current
evidence-policy generation.
A scoped non-bearer finality enablement may then be constituted for
the qualified actual operation.
The actual Finality Sink obtains or reconstructs the pending
consequential effect through its protected resource-facing
observation mechanism.
The sink independently verifies correspondence between:
The original Candidate Act;
The qualified evidence;
The current operation;
The actual target;
The protected finality enablement;
And sink-local protected authority state.
Where the pending operation materially differs from the operation
qualified upstream, the sink refuses effectuation.
Where the finality evidence is invalid, stale, revoked, mismatched,
replayed, or unsupported under the required trust model, the covered
operation remains non-effective.
Das Expires 29 April 2027 [Page 535]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invention therefore provides a protected causal relationship
among evidence qualification, observer trust, actual effect
verification, and finality, rather than treating evidence collection
or remote attestation as an independently sufficient permission to
act.
38.0.2 — Fundamental Technical Principle
5.8.3.7. Original Global Page 3288
Evidence that an operation was permitted is not equivalent to
evidence that the operation actually presented for effectuation is
permitted.
Further:
A valid signature proves the selected signed data was authenticated
under the applicable cryptographic assumptions; it does not prove
that every underlying factual assertion is true.
A successful platform attestation does not automatically prove
correctness of the platform's current application-level decision.
An authenticated observer is not necessarily competent to measure
every resource property.
A fresh observation of the wrong resource is not the required
evidence.
A measurement of the correct resource under the wrong units or
semantic interpretation may be unsafe to rely upon.
Two signatures do not necessarily establish two independent
observations.
A historical evidence receipt does not automatically establish
current authorization.
A protected log can preserve false observations faithfully.
An absence of recorded malicious activity does not prove that no
malicious activity occurred.
A compromised evidence source does not automatically imply that every
independent evidence source is compromised.
An attestation result does not itself confer source authority for a
consequential operation.
Das Expires 29 April 2027 [Page 536]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
And the actual Finality Sink must not mistake a qualified evidence
record for unrestricted authority to execute a different pending
effect.
38.0.3 — Principal Candidate Inventive Combination
A representative implementation comprises:
(a) an originating source-authorized Candidate Act;
(b) an enforceable Non-Effective State;
(c) a protected operation-specific evidence-requirement descriptor;
(d) qualified collection-time evidence;
(e) protected observer identity, competence, and measurement-scope
evidence;
(f) optional attestation appraisal of specified observer properties;
5.8.3.8. Original Global Page 3289
(g) an independent execution-time evidence collector;
(h) qualified independence between selected observation channels;
(i) protected evidence-semantic and resource-identity correspondence;
(j) evidence-generation and freshness fencing;
(k) selective containment of operations depending upon compromised or
unqualified witnesses;
(l) protected cross-commitment of collection-time and execution-time
validation evidence;
(m) scoped non-bearer finality enablement;
(n) independent actual Finality-Sink reconstruction of the pending
operation;
(o) sink-local verification of evidence, operation, authority, and
consumption;
(p) protected recording and reconciliation of evidence-source changes
without reviving consumed effectuation authority.
Das Expires 29 April 2027 [Page 537]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.0.4 — Candidate Technical Distinction
The embodiment does not claim as individually new:
Cryptographic signatures;
Public-key infrastructure;
Remote attestation;
Measurement registers;
Trusted execution environments;
Protected logging;
Merkle trees;
Transparency logs;
Multiple sensors;
Quorum validation;
Challenge-response protocols;
5.8.3.9. Original Global Page 3290
Freshness nonces;
Policy evaluation;
Audit records;
Or evidence provenance.
The proposed distinguishing relationship concerns the binding of
qualified evidence to an actual consequential Candidate Act,
independent execution-time witness validation, operation-specific
compromise containment, and separate actual receiving-resource
Finality-Sink reconstruction and non-bearer finality consumption.
38.0.5 — Relationship to Earlier Embodiments
The present embodiment may incorporate previously disclosed
mechanisms for:
Protected collection-time evidence;
Das Expires 29 April 2027 [Page 538]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Independent execution-time validation;
Cross-committed validation records;
Candidate Act non-effectuation;
Original source authority;
Resource identity continuity;
Hazard-state verification;
Scoped non-bearer capabilities;
Actual Finality-Sink reconstruction;
Policy and revocation fencing;
Hardware-backed protection;
Offline authority;
And multi-resource transaction finality.
Its focused subject is whether the evidence and attestation relied
upon for a particular actual effect remains sufficiently authentic,
applicable, competent, independent, and current in the presence of
observer compromise or cross-domain evidence ambiguity.
38.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL
5.8.3.10. Original Global Page 3291
| v SOURCE-AUTHORIZED ACT | v CANDIDATE ACT | v NON-EFFECTIVE HOLD |
v EVIDENCE REQUIREMENTS | +----------+-----------+ | | v v
COLLECTION-TIME OBSERVER IDENTITY OBSERVATION AND COMPETENCE | |
+----------+-----------+ | v PROTECTED EVIDENCE STATE | v EXECUTION-
TIME WITNESS | v INDEPENDENCE / FRESHNESS / SEMANTIC QUALIFICATION |
+--------+--------+ | | v v QUALIFIED INVALID / COMPROMISED | | | v |
DEPENDENCY FENCE | | | REQUALIFICATION | | +--------+--------+ | v
CROSS-COMMITTED EVIDENCE | v NON-BEARER FINALITY | v ACTUAL FINALITY
SINK
Das Expires 29 April 2027 [Page 539]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.11. Original Global Page 3292
| v RECONSTRUCT PENDING EFFECT | v VERIFY SOURCE + TARGET + OPERATION
+ EVIDENCE | v SINK-LOCAL CONSUMPTION | v CONTROLLED REAL EFFECT
All diagrams are illustrative and non-limiting technical aids to
assist a person having ordinary skill in the art.
38.1 — TECHNICAL FIELD
The present invention relates to autonomous execution security,
trusted measurement systems, remote attestation, evidence provenance,
qualified sensor fusion, independent evidence appraisal, distributed
authorization, cross-domain data integrity, protected execution
monitoring, compromised-observer containment, and actual receiving-
resource execution-finality enforcement.
More particularly, the invention concerns preventing evidence-
producing components from independently creating or extending
consequential authority beyond that granted by the originating
principal and verified at the actual operation boundary.
38.2 — SPECIFIC TECHNICAL PROBLEMS
38.2.1 — Evidence Fabrication
An agent or compromised tool may fabricate a record claiming that a
mandatory authorization or resource condition has been satisfied.
38.2.2 — Authentic False Evidence
A legitimately identified observer may report incorrect factual
information.
38.2.3 — Attestation Overinterpretation
A valid platform attestation result may be treated as proof of every
runtime behavior.
38.2.4 — Observer Competence Mismatch
5.8.3.12. Original Global Page 3293
A witness may measure network connection state but be relied upon to
prove database commit completion.
38.2.5 — Evidence-Source Confusion
Das Expires 29 April 2027 [Page 540]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A record may originate from a monitoring service different from the
one authorized to attest to the relevant property.
38.2.6 — Operation Substitution
Evidence collected for one proposed effect may be used to authorize
another.
38.2.7 — Resource Substitution
Evidence about Resource A may be reused for Resource B.
38.2.8 — Tenant Substitution
Evidence generated within one resource tenant may be applied to
another tenant.
38.2.9 — Stale Observation
An earlier correct observation may no longer describe current state.
38.2.10 — Delayed Evidence Delivery
A witness may produce authentic evidence that arrives after a
material resource change.
38.2.11 — Replay
An attacker may submit an earlier signed observation again.
38.2.12 — Evidence Epoch Rollback
A controller may restore an older evidence generation.
38.2.13 — Observer Software Change
An observer implementation may change after initial qualification.
38.2.14 — Observer Key Rotation
A witness may use a new signing key or credential generation.
38.2.15 — Revoked Observer
A previously accepted witness may no longer be authorized.
38.2.16 — Compromised Observer
Das Expires 29 April 2027 [Page 541]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.13. Original Global Page 3294
An evidence-producing component may become malicious.
38.2.17 — Compromised Evidence Verifier
A component responsible for evaluating evidence may be compromised.
38.2.18 — Correlated Witness Failure
Two apparently separate witnesses may depend upon the same
compromised underlying data source.
38.2.19 — Colluding Witnesses
Multiple witnesses may cooperate to produce misleading evidence.
38.2.20 — Misconfigured Quorum
A majority vote may be accepted without adequate independence
assumptions.
38.2.21 — Measurement Coverage Gap
A monitor may observe one interface while the actual operation uses
another.
38.2.22 — Alternate Effectuation Path
A resource effect may bypass the monitored path.
38.2.23 — Incomplete Evidence
A record may omit a mandatory actual operation parameter.
38.2.24 — Data Redaction Ambiguity
Privacy-preserving redaction may remove data necessary to establish
the relevant predicate.
38.2.25 — Semantic Unit Mismatch
A measured quantity may be interpreted using incorrect units.
38.2.26 — Identifier Namespace Mismatch
The same textual resource identifier may refer to different objects
in different domains.
Das Expires 29 April 2027 [Page 542]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.2.27 — Canonicalization Ambiguity
Different validators may serialize or parse the same evidence
differently.
38.2.28 — Schema-Version Change
Evidence fields may change meaning between schema versions.
5.8.3.14. Original Global Page 3295
38.2.29 — Truncated Evidence
A witness may provide only a partial record.
38.2.30 — Unqualified Evidence Aggregation
An aggregator may combine several records without preserving their
individual provenance.
38.2.31 — Evidence Laundering
A downstream service may treat a summary or score as equivalent to
original qualified observations.
38.2.32 — Log Inclusion Confusion
Proof that evidence was logged may be treated as proof that the
evidence is true.
38.2.33 — Attestation Result Replay
An earlier verifier result may be used outside its permitted validity
or operation scope.
38.2.34 — Reference-Value Downgrade
An older, more permissive attestation policy may be restored.
38.2.35 — Appraisal Policy Change
An earlier result may no longer satisfy current relying-party
requirements.
38.2.36 — Cross-Domain Trust Confusion
A verifier accepted by one administrative domain may not be
authorized to speak for another.
Das Expires 29 April 2027 [Page 543]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.2.37 — Credential Audience Confusion
Evidence credentials may be valid for a different relying party.
38.2.38 — Collection/Execution Gap
The actual pending operation may change after initial evidence
collection.
38.2.39 — Misleading Tool Output
A tool may claim success or authorization without protected
receiving-resource evidence.
38.2.40 — Sensor Calibration Error
A signed measurement may fall outside the sensor's qualified accuracy
range.
38.2.41 — Physical Sensor Manipulation
5.8.3.15. Original Global Page 3296
A genuine device may report manipulated environmental data.
38.2.42 — Physical Process Drift
The observed resource condition may materially change before
actuation.
38.2.43 — Conflicting Witnesses
Two qualified observers may report contradictory values.
38.2.44 — Missing Independent Channel
The required execution-time observation may depend exclusively upon
the agent's own proposed parameters.
38.2.45 — Evidence-Verification Exhaustion
An attacker may submit excessively complex evidence to exhaust
protected verification resources.
38.2.46 — Evidence Flooding
A compromised observer may generate many irrelevant records.
Das Expires 29 April 2027 [Page 544]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.2.47 — Unavailable Attestation Service
A required appraisal service may be unreachable.
38.2.48 — Offline Attestation Staleness
An offline sink may retain valid but outdated platform evidence.
38.2.49 — Observer-Compromise Propagation
A single compromised witness may affect multiple pending operations.
38.2.50 — Overbroad Compromise Response
A system may unnecessarily invalidate unrelated operations without
examining their evidence dependencies.
38.2.51 — Incomplete Compromise Containment
A system may continue accepting evidence indirectly derived from the
compromised observer.
38.2.52 — Evidence-Source Resurrection
A restored software snapshot may reenable a revoked witness.
5.8.3.16. Original Global Page 3297
38.2.53 — Sink Evidence Mismatch
The receiving resource may observe a different actual operation from
the one described in the validation evidence.
38.2.54 — Finality Receipt Reuse
A legitimate validation record may be applied to several real
operations.
38.2.55 — False Completion Evidence
A dispatch receipt may be misrepresented as proof of actual resource
completion.
38.2.56 — Circular Evidence Dependency
One witness may be considered trustworthy because another witness
relies upon it.
Das Expires 29 April 2027 [Page 545]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.2.57 — Unverifiable Cross-Domain Claims
A relying party may receive evidence whose source semantics it cannot
independently establish.
38.2.58 — Source Authority Substitution
A valid observer result may be used as though it were an original
source grant.
38.2.59 — Protected State Inconsistency
Evidence verification and finality consumption may refer to different
state generations.
38.2.60 — Technical Objective
How to ensure that an autonomous consequential operation relies only
upon evidence that is sufficiently qualified for its exact source,
target, operation, freshness, semantics, competence, and compromise
assumptions, while ensuring that qualified evidence cannot itself
become unrestricted authority and that the actual receiving resource
independently verifies the pending effect before protected finality.
38.3 — ESTABLISHED TECHNICAL FOUNDATIONS
38.3.1 — Cryptographic Signatures
Existing digital-signature mechanisms may authenticate selected
messages and their apparent issuers.
They do not establish the factual accuracy of all signed assertions.
38.3.2 — Remote Attestation
5.8.3.17. Original Global Page 3298
Existing remote-attestation architectures distinguish attesting
entities, evidence, appraisal, reference values, endorsements,
verifiers, and relying-party decisions.
The presence of an attestation result does not eliminate the relying
party's obligation to evaluate whether the result suffices for its
particular decision.
38.3.3 — Protected Measurement
Das Expires 29 April 2027 [Page 546]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Existing protected computing systems may record software or platform
measurements.
Those measurements do not automatically prove every application's
runtime behavior or every physical sensor's accuracy.
38.3.4 — Transparency and Append-Only Logs
Existing authenticated append-only logs can provide evidence of
inclusion or consistency.
They do not guarantee that submitted factual statements are true or
that all relevant events were submitted.
38.3.5 — Multiple Independent Sensors
Existing monitoring architectures may compare observations from
multiple sources.
The benefits depend on the sources' actual independence and failure
assumptions.
38.3.6 — Challenge-Response
Existing protocols may use fresh nonces or challenges to reduce
selected replay risks.
Fresh challenges do not independently establish that the observed
resource or actual operation is correct.
38.3.7 — Protected Authorization
Existing policy engines may evaluate authenticated facts before
permitting access.
The present embodiment further connects relevant evidence
qualifications to independent actual operation reconstruction and
finality.
38.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
1. Protected Originating Source-Authority Controller. 2. Candidate
Act and Non-Effective State Controller. 3. Operation-Specific
Evidence-Requirement Registry. 4. Collection-Time Evidence
Controller.
Das Expires 29 April 2027 [Page 547]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.18. Original Global Page 3299
5. Qualified Observer Identity Registry. 6. Observer Competence and
Measurement-Scope Registry. 7. Attestation Evidence Appraisal
Controller. 8. Independent Execution-Time Evidence Collector. 9.
Observation-Channel Independence Evaluator. 10. Evidence Freshness
and Generation Controller. 11. Cross-Domain Evidence-Semantics
Translator. 12. Protected Resource Identity and Namespace Mapper.
13. Witness Contradiction Detector. 14. Observer-Compromise
Qualification Controller. 15. Evidence-Dependency Containment
Controller. 16. Protected Evidence Reconstruction Controller. 17.
Cross-Committed Validation Evidence Generator. 18. Scoped Non-Bearer
Finality Controller. 19. Actual Resource Finality Sink. 20. Sink-
Local Protected Consumption Controller. 21. Protected Evidence and
Outcome Journal. 22. Evidence-Source Recovery and Requalification
Controller.
38.5 — TECHNICAL DEFINITIONS
38.5.1 — Protected Evidence Requirement
A Protected Evidence Requirement, or PER-38, means an operation-
specific mandatory condition identifying the evidence needed before a
consequential Candidate Act becomes eligible for finality.
38.5.2 — Qualified Evidence Source
A Qualified Evidence Source means an entity authorized and
technically competent under the applicable policy to provide selected
factual observations.
38.5.3 — Observer Identity
Observer Identity means a qualified reference identifying an
evidence-producing component.
38.5.4 — Observer Competence Envelope
An Observer Competence Envelope, or OCE-38, means a protected
specification of the properties, resources, observation paths,
accuracy conditions, and semantic claims a particular observer may
validly support.
38.5.5 — Collection-Time Evidence
Collection-Time Evidence, or CTE-38, means qualified evidence
captured when a Candidate Act or relevant source-authorized condition
is initially established.
Das Expires 29 April 2027 [Page 548]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.5.6 — Execution-Time Evidence
5.8.3.19. Original Global Page 3300
Execution-Time Evidence, or ETE-38, means qualified evidence obtained
concerning the current operation and relevant resource state near the
actual effectuation boundary.
38.5.7 — Protected Observation Domain
A Protected Observation Domain means a computing or resource-control
domain providing specified integrity and access-isolation properties
for evidence collection.
38.5.8 — Observation-Channel Independence
Observation-Channel Independence means a qualified degree of
separation between evidence paths under a defined fault or compromise
model.
38.5.9 — Actual Operation Witness
An Actual Operation Witness means evidence derived from the operation
actually presented to a protected resource boundary.
38.5.10 — Observer Attestation Evidence
Observer Attestation Evidence means evidence about selected
properties of the observer's current or measured platform state.
38.5.11 — Attestation Appraisal Result
An Attestation Appraisal Result means a qualified conclusion
concerning attestation evidence under a specified appraisal policy.
38.5.12 — Evidence Competence
Evidence Competence means the qualified applicability of a witness to
establish a specified factual predicate.
38.5.13 — Evidence Scope
Evidence Scope means the resource, principal, operation, time,
measurement, and interpretation domain within which an evidence item
may be relied upon.
38.5.14 — Evidence Freshness Window
Das Expires 29 April 2027 [Page 549]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An Evidence Freshness Window means an operation-specific constraint
on the temporal or generation validity of an observation.
38.5.15 — Evidence Generation
An Evidence Generation, or EG-38, means a protected revision or
sequence reference associated with an observation or validation
state.
38.5.16 — Observer Generation
5.8.3.20. Original Global Page 3301
An Observer Generation means a protected version of a witness's
relevant identity, key, software, configuration, or competence state.
38.5.17 — Evidence Lineage
Evidence Lineage means a protected record of the observations and
transformations from which an evidence item was derived.
38.5.18 — Cross-Domain Evidence Mapping
Cross-Domain Evidence Mapping means a qualified correspondence
between evidence semantics used by different administrative or
technical domains.
38.5.19 — Evidence Semantic Profile
An Evidence Semantic Profile means a defined interpretation of
evidence fields, units, resource namespaces, completeness rules, and
observation meanings.
38.5.20 — Qualified Witness Set
A Qualified Witness Set means the specific sources satisfying an
operation's required observation and independence conditions.
38.5.21 — Correlated Witness Set
A Correlated Witness Set means witnesses sharing one or more
underlying failure or compromise dependencies.
38.5.22 — Evidence Contradiction
Evidence Contradiction means a material inconsistency among
observations required to satisfy an operation-specific predicate.
Das Expires 29 April 2027 [Page 550]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.5.23 — Evidence Equivalence
Evidence Equivalence means verified semantic correspondence of
selected observations under a qualified comparison rule.
38.5.24 — Observer Compromise State
Observer Compromise State means a protected classification indicating
that an evidence source no longer satisfies one or more mandatory
trust conditions.
38.5.25 — Evidence Dependency Set
An Evidence Dependency Set, or EDS-38, means the qualified set of
witness, verifier, measurement, and semantic references required by a
Candidate Act.
38.5.26 — Compromise Containment Fence
5.8.3.21. Original Global Page 3302
A Compromise Containment Fence, or CCF-38, means a protected
restriction preventing operations dependent upon affected evidence
from reaching finality.
38.5.27 — Selective Evidence Invalidation
Selective Evidence Invalidation means invalidating affected evidence
and dependent operations without automatically invalidating unrelated
independent evidence.
38.5.28 — Evidence Requalification
Evidence Requalification means obtaining new current evidence
sufficient to replace an invalid or compromised observation under the
applicable protected policy.
38.5.29 — Witness Replacement Authority
Witness Replacement Authority means the competent policy governing
substitution of one evidence source with another.
38.5.30 — Protected Evidence Receipt
A Protected Evidence Receipt means authenticated evidence that
selected observations have been qualified for a specified Candidate
Act and validation generation.
Das Expires 29 April 2027 [Page 551]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.5.31 — Cross-Committed Validation Evidence
Cross-Committed Validation Evidence, or CCVE-38, means protected
binding among collection-time, execution-time, observer-
qualification, operation, and resource evidence.
38.5.32 — Attestation Continuity
Attestation Continuity means qualified correspondence of relevant
observer identity, state, competence, and appraisal requirements
across the period in which an operation relies upon the observer.
38.5.33 — Attestation Policy Generation
An Attestation Policy Generation means a protected version of the
current appraisal requirements.
38.5.34 — Reference-Value Generation
A Reference-Value Generation means a protected version of expected
measurement information used during attestation appraisal.
38.5.35 — Evidence Revocation Generation
An Evidence Revocation Generation means the protected state
identifying current invalid or withdrawn observer credentials or
evidence eligibility.
38.5.36 — Resource-Side Evidence Reconstruction
5.8.3.22. Original Global Page 3303
Resource-Side Evidence Reconstruction means independent obtaining or
verification of the actual pending resource operation at the
receiving Finality Sink.
38.5.37 — Evidence-to-Effect Correspondence
Evidence-to-Effect Correspondence means verification that the
qualified evidence describes the material actual effect presented for
execution.
38.5.38 — Evidence-Only Approval
Evidence-Only Approval means a determination that evidence appears
adequate, without independently establishing actual effectuation
authority.
Das Expires 29 April 2027 [Page 552]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.5.39 — Effectuation Authority
Effectuation Authority means qualified permission for a specified
actual consequence under current source, resource, evidence, and
sink-local conditions.
38.5.40 — Evidence Verification Budget
An Evidence Verification Budget means a protected limit on evidence
size, complexity, depth, processing cost, or verification attempts.
38.5.41 — Evidence Nonresurrection
Evidence Nonresurrection means preventing revoked, obsolete, or
invalid evidence from becoming acceptable merely through replay,
rollback, or recovery.
38.5.42 — Observer Recovery Epoch
An Observer Recovery Epoch means a protected revision identifying the
requalification of a previously unavailable or compromised evidence
source.
38.5.43 — Qualified Absence Evidence
Qualified Absence Evidence means evidence supporting a specified
negative predicate under an established observation completeness
model.
38.5.44 — Evidence Coverage Boundary
An Evidence Coverage Boundary means the set of resource events,
operations, and paths actually observable by a witness.
38.5.45 — Observation Completeness Predicate
An Observation Completeness Predicate means a qualified condition
establishing whether an evidence source had sufficient coverage to
support the asserted conclusion.
38.5.46 — Protected Evidence Canonicalization
5.8.3.23. Original Global Page 3304
Protected Evidence Canonicalization means producing an authenticated
representation under a specified evidence schema and interpretation
profile.
Das Expires 29 April 2027 [Page 553]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.5.47 — Non-Bearer Evidence-Bound Finality
Non-Bearer Evidence-Bound Finality means scoped effectuation
enablement whose validity depends upon qualified evidence and the
actual sink's independent verification rather than unrestricted
possession by the autonomous agent.
38.5.48 — Sink-Local Evidence State
Sink-Local Evidence State means protected current data retained by
the actual Finality Sink concerning evidence qualification, operation
generations, revocation, and consumption.
38.5.49 — Qualified Actual-Effect Receipt
A Qualified Actual-Effect Receipt means evidence describing the
actual receiving resource's effectuation outcome under its defined
semantics.
38.5.50 — Protected Evidence-to-Finality Continuity
Protected Evidence-to-Finality Continuity means maintaining the
required relationship among original source authority, qualified
observation evidence, current actual operation, and protected
receiving-resource effectuation.
38.6 — FIVE SEPARATE EVIDENCE ASSURANCE QUESTIONS
For each evidence item, the protected validator may determine:
Question 1 — Who produced the evidence?
The producer must have a qualified identity where required.
Question 2 — What could that producer actually observe?
The observer's competence and coverage must support the required
predicate.
Question 3 — What resource and operation did the evidence concern?
The evidence must correspond to the authorized Candidate Act and
actual resource.
Question 4 — Is the evidence still applicable?
Freshness, generation, policy, revocation, and resource-state
conditions must pass.
Das Expires 29 April 2027 [Page 554]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Question 5 — Does the actual Finality Sink observe the same relevant
operation?
5.8.3.24. Original Global Page 3305
The receiving resource independently checks the pending effect rather
than relying exclusively upon upstream evidence.
Successful answers to the first four questions do not automatically
satisfy the fifth.
38.7 — OPERATION-SPECIFIC EVIDENCE REQUIREMENT DESCRIPTOR
A representative protected record comprises:
PROTECTED_EVIDENCE_REQUIREMENT = { candidate_act_identifier,
original_source_grant_reference, actual_resource_identity,
actual_effect_class, required_factual_predicates,
acceptable_observer_competence_classes,
required_observation_channels, required_channel_independence,
required_freshness_or_generation_bounds,
accepted_attestation_appraisal_policy,
required_evidence_semantic_profile, required_resource_version,
current_evidence_revocation_generation,
designated_actual_finality_sink, protected_requirement_authentication
}
38.7.1 — Requirement Authority
The autonomous agent does not independently lower mandatory evidence
requirements.
38.7.2 — Effect Dependence
Different operations may require different evidence.
38.7.3 — Actual Resource
The evidence requirement is associated with the real resource or
authorized resource class.
38.7.4 — No Universal Attestation Requirement
Some operations may be adequately protected by resource-local
transactional evidence without remote platform attestation.
38.8 — QUALIFIED OBSERVER IDENTITY
Das Expires 29 April 2027 [Page 555]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.25. Original Global Page 3306
A protected registry may associate evidence sources with:
Identity credentials;
Measurement capabilities;
Permitted observation paths;
Resource namespaces;
Attestation requirements;
Applicable appraisal policies;
Relevant revocation state;
And current observer generations.
A signing key identifies a cryptographic origin under the applicable
assumptions.
It does not by itself establish competence for every claimed resource
property.
38.9 — OBSERVER COMPETENCE ENVELOPE
OBSERVER_COMPETENCE_ENVELOPE = { observer_identity,
qualified_measurement_types, permitted_resource_scopes,
actual_observation_interfaces, observation_completeness_conditions,
qualified_accuracy_or_error_bounds, evidence_semantic_profile,
required_platform_state, current_observer_generation,
competent_issuer_reference, revocation_generation,
protected_envelope_authentication }
38.9.1 — Limited Claims
An observer may attest to a network request destination but not the
actual financial settlement result.
38.9.2 — Actual Coverage
An observer must cover the operation path relevant to its asserted
conclusion.
Das Expires 29 April 2027 [Page 556]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.26. Original Global Page 3307
38.9.3 — Changes
A new tool, resource path, or backend may exceed the observer's
earlier coverage.
38.9.4 — Missing Competence
A valid signature cannot remedy an unsupported measurement claim.
38.10 — COLLECTION-TIME EVIDENCE
At collection time, a protected evidence collector may obtain:
The original source grant;
The Candidate Act;
Qualified resource identity;
Material operation parameters;
Current policy references;
Relevant observer identity;
Selected resource-state observations;
And applicable evidence-generation information.
The collector may commit an authenticated record.
38.10.1 — Collection-Time Purpose
Establishes the qualified state relied upon when the Candidate Act
was formed.
38.10.2 — Not Execution-Time Proof
The actual operation may change before effectuation.
38.10.3 — Protected Binding
The evidence is associated with the specific Candidate Act and
resource context.
38.11 — EXECUTION-TIME OBSERVATION
Das Expires 29 April 2027 [Page 557]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An independent execution-time witness may obtain:
5.8.3.27. Original Global Page 3308
The operation actually pending at the receiving interface;
The current resource identity;
The actual recipient or destination;
Material request parameters;
Current resource version;
Applicable authority state;
And relevant current hazard or policy conditions.
38.11.1 — Independent Observation
Where required, the observer is separated from the proposing agent's
control over the measured data.
38.11.2 — Freshness
The observation must satisfy the operation-specific freshness
requirement.
38.11.3 — Actual Effect
The evidence must correspond to the operation that will be released.
38.12 — OBSERVATION CHANNEL INDEPENDENCE
A protected controller may evaluate the trust and failure
dependencies of each observation channel.
For example:
An agent-side API wrapper and an agent-generated log may share the
same compromised process.
Two monitoring applications may use the same kernel event provider.
Two remote attestation statements may rely upon the same platform
root.
Two sensors may share the same signal-conditioning circuit.
Das Expires 29 April 2027 [Page 558]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A hardware command observer and an independent resource-side command
register may possess stronger separation under the relevant fault
model.
38.12.1 — Independence Is Relative
5.8.3.28. Original Global Page 3309
No general declaration of independence is sufficient without
identifying the protected properties and shared failure assumptions.
38.12.2 — Mandatory Separate Control
Where the threat model assumes the agent process may be compromised,
the decisive observation may need to originate outside that process.
38.12.3 — No Universal Redundancy Claim
Two observers cannot be assumed to provide two independent
confirmations merely because they have different names.
38.13 — PROTECTED WITNESS DEPENDENCY GRAPH
The controller may maintain an evidence dependency graph.
CANDIDATE ACT | REQUIRED FACTS | +--------------+-------------+ | | v
v RESOURCE IDENTITY OPERATION STATE | | v v OBSERVER A OBSERVER B | |
v v TRUST ANCHOR X OBSERVATION PATH Y | |
+-------------+--------------+ | v DEPENDENCY QUALIFICATION
The graph identifies relationships among witnesses, underlying data
sources, protected authorities, and Candidate Acts.
38.13.1 — Shared Dependency
May prevent two observations from being counted as independent.
38.13.2 — Compromise Propagation
A compromised underlying source may affect every dependent evidence
claim.
5.8.3.29. Original Global Page 3310
38.13.3 — Selective Containment
Only operations requiring affected predicates must be fenced, unless
wider compromise is established.
Das Expires 29 April 2027 [Page 559]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.14 — ATTESTATION APPRAISAL CONTINUITY
An observer may provide evidence about its current or measured
execution environment.
A qualified verifier may appraise that evidence using specified
reference values, endorsements, and appraisal policy.
The result is used only for those properties the appraisal supports.
38.14.1 — Platform State
May establish selected measurements or security configurations.
38.14.2 — Runtime Behavior
Is not universally proven correct by an acceptable platform
measurement.
38.14.3 — Current Appraisal Policy
A previous result must satisfy the current required operation-
specific policy or be requalified.
38.14.4 — Current Observer Competence
Attestation does not replace competence and actual coverage
validation.
38.15 — ATTESTATION CONTINUITY RECORD
PROTECTED_ATTESTATION_CONTINUITY = { observer_identity,
attestation_evidence_reference, qualified_verifier_identity,
appraisal_policy_generation, reference_value_generation,
observed_platform_state, observer_software_generation,
challenge_or_freshness_reference, applicable_relying_party_scope,
observer_competence_reference, current_revocation_generation,
protected_result_authentication }
5.8.3.30. Original Global Page 3311
A protected controller may compare collection-time and execution-time
attestation properties.
A materially changed measured component may require renewed evidence
qualification.
Das Expires 29 April 2027 [Page 560]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An unchanged measurement does not automatically prove the absence of
every runtime compromise.
38.16 — ATTESTATION FRESHNESS
An attestation mechanism may use challenges, nonces, counters, time
references, or other protocol-specific mechanisms.
A protected controller checks that the evidence is applicable to its
intended session or operation.
38.16.1 — Fresh Challenge
Can reduce replay of older attestation messages.
38.16.2 — Correct Target
A fresh attestation of the wrong device remains irrelevant.
38.16.3 — Correct Property
A fresh boot measurement does not necessarily establish a current
resource transaction state.
38.16.4 — Operation Binding
The actual consequential operation may require separate binding to
the attestation result.
38.17 — EVIDENCE GENERATION AND VERSION FENCING
A Candidate Act may depend upon:
An observer software generation;
A resource version;
An attestation appraisal generation;
An evidence schema generation;
A source authority generation;
And a revocation generation.
Das Expires 29 April 2027 [Page 561]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.31. Original Global Page 3312
The protected controller identifies which changes materially affect
the operation.
38.17.1 — Material Evidence Change
Invalidates affected pending evidence qualification.
38.17.2 — Nonmaterial Change
May be accepted where the required predicates remain established.
38.17.3 — Execution Boundary
The actual sink independently verifies applicable current
generations.
38.18 — EVIDENCE FRESHNESS VERSUS EVIDENCE VALIDITY
Evidence may be:
Authentic but stale;
Fresh but from the wrong observer;
Fresh and authentic but outside observer competence;
Fresh and competent but semantically misinterpreted;
Or fully qualified for collection-time planning but insufficient for
execution-time finality.
The protected system does not reduce all of these conditions to one
signature-validity flag.
38.19 — CROSS-DOMAIN EVIDENCE QUALIFICATION
Evidence may cross administrative domains.
For example:
A remote device may report an operating state to a cloud controller.
A protected enterprise API may provide a resource ownership assertion
to a local agent.
Das Expires 29 April 2027 [Page 562]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An independent resource sink may receive an attestation appraisal
from another domain.
The receiving domain determines:
Whether the source is competent;
5.8.3.32. Original Global Page 3313
Whether the evidence is intended for the receiving relying party;
Whether resource identifiers correspond;
Whether the claimed units and semantics are valid;
Whether the evidence remains current;
And whether its own policy permits reliance upon the statement.
A valid signature from another domain does not automatically make
that domain authoritative for all local decisions.
38.20 — EVIDENCE SEMANTICS AND CANONICALIZATION
A protected evidence-semantic profile may define:
Identifier namespaces;
Resource types;
Units;
Time representations;
Status values;
Completion semantics;
Required fields;
Optional fields;
Canonical serialization;
And schema version.
38.20.1 — Unit Mismatch
Das Expires 29 April 2027 [Page 563]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A value representing milliseconds cannot automatically be interpreted
as seconds.
38.20.2 — Resource Namespace
The identifier 42 may represent different resources in different
domains.
38.20.3 — Receipt Semantics
An ACCEPTED status cannot automatically be interpreted as COMMITTED.
5.8.3.33. Original Global Page 3314
38.20.4 — Canonical Representation
The exact authenticated representation and interpretation profile
must correspond to the verifier's expectations.
38.21 — PROTECTED CROSS-DOMAIN EVIDENCE RECORD
CROSS_DOMAIN_EVIDENCE_RECORD = { producing_domain_identity,
qualified_observer_identity, relying_domain_identity, evidence_type,
evidence_schema_generation, semantic_profile_identifier,
actual_resource_namespace, actual_resource_identity,
measured_property, measurement_value_or_commitment,
qualification_and_accuracy_information, observation_generation,
operation_or_session_reference, freshness_reference,
competent_issuer_reference, protected_record_authentication }
Cross-domain acceptance requires more than verifying a signature on
this structure.
The receiving validator independently evaluates scope, competence,
current state, and semantic applicability.
38.22 — CONTRADICTORY WITNESSES
Two qualified observers may produce conflicting statements.
For example:
Observer A reports the target resource is unchanged.
Observer B reports that the resource version advanced.
A protected controller evaluates:
Das Expires 29 April 2027 [Page 564]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Whether both observations refer to the same resource;
Whether their time intervals overlap;
5.8.3.34. Original Global Page 3315
Whether they have equivalent semantics;
Whether one source has materially changed;
Whether the contradiction affects a mandatory predicate;
And whether a current independent observation can resolve it.
38.22.1 — Material Contradiction
The affected Candidate Act remains non-effective pending
qualification.
38.22.2 — Unrelated Contradiction
Need not invalidate unrelated operations.
38.22.3 — No Blind Majority
A majority of potentially correlated or compromised sources is not
automatically accepted as truth.
38.23 — QUALIFIED QUORUM OR MULTIWITNESS VERIFICATION
Some implementations may require several independent observations.
A protected policy may specify:
The required witness roles;
Permitted shared dependencies;
Minimum independent trust domains;
Measurement coverage;
Current evidence quality;
And acceptance conditions.
38.23.1 — Quorum Assumptions
Das Expires 29 April 2027 [Page 565]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The required number of witnesses depends upon the relevant fault
model.
38.23.2 — Collusion
A quorum cannot provide a general guarantee against arbitrary
compromise of all accepted witnesses.
5.8.3.35. Original Global Page 3316
38.23.3 — Sink Authority
A witness quorum does not create source authority for an operation
absent from the original grant.
38.24 — COMPROMISED OBSERVER IDENTIFICATION
An observer may become suspect because of:
A revoked identity credential;
A failed current attestation appraisal;
A changed platform measurement;
Detected journal rollback;
An authenticated integrity alert;
Conflicting qualified resource evidence;
A protected policy withdrawal;
Or another competent indication of loss of evidence eligibility.
38.24.1 — Qualification
The system must identify the scope of the suspected compromise.
38.24.2 — Conservative Restriction
Affected mandatory evidence may be invalidated or suspended.
38.24.3 — No Automatic Universal Inference
One inconsistency does not necessarily establish that every
associated resource or observer is compromised.
Das Expires 29 April 2027 [Page 566]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.25 — SELECTIVE COMPROMISE CONTAINMENT
A protected containment controller obtains the evidence-dependency
set of pending Candidate Acts.
Where a witness becomes ineligible, it identifies all operations that
depend upon the affected factual predicates.
5.8.3.36. Original Global Page 3317
Those operations are fenced.
Unrelated operations remain eligible for independent current
validation if their required evidence and source authority remain
qualified.
38.25.1 — Direct Dependency
An operation may rely directly upon the compromised witness.
38.25.2 — Indirect Dependency
An operation may rely upon an aggregated result derived from the
compromised witness.
38.25.3 — Containment
Both direct and indirect affected dependencies may be invalidated
under the policy.
38.25.4 — Recovery
New independent evidence may restore eligibility only after the
mandatory source and operation predicates are requalified.
38.26 — OBSERVER REPLACEMENT
A compromised or unavailable evidence source may be replaced.
The replacement must satisfy:
Competent observer identity;
Required measurement scope;
Current applicable attestation and appraisal conditions;
Relevant observation-path separation;
Das Expires 29 April 2027 [Page 567]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Current resource and operation semantics;
And the active evidence requirement.
38.26.1 — No Silent Substitution
An arbitrary observer cannot declare itself an eligible successor.
38.26.2 — Authority Continuity
The replacement does not broaden the source-authorized effect.
5.8.3.37. Original Global Page 3318
38.26.3 — Requalification
Affected Candidate Acts are checked using current evidence.
38.27 — EVIDENCE NONRESURRECTION
A software snapshot may restore an older observer registry or
attestation result.
The protected system compares restored state against stronger current
applicable evidence and revocation generations.
A revoked witness does not regain authority merely because an old
signed certificate, appraisal result, or registry entry reappears.
Similarly, already consumed operation-specific finality cannot be
restored through evidence rollback.
38.28 — FALSE OR INCOMPLETE LOG EVIDENCE
A protected log may preserve authenticated event records.
However:
A log can contain false original claims.
A logging component can miss events outside its observation path.
An absence of an entry does not prove absence of an event without a
qualified completeness model.
A valid inclusion proof does not establish the accuracy of the logged
record.
Das Expires 29 April 2027 [Page 568]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.28.1 — Inclusion
May establish that an item belongs to a particular committed log
state.
38.28.2 — Consistency
May establish selected append-only relationships between committed
log states.
38.28.3 — Factual Accuracy
Requires separate qualification.
38.28.4 — Effectuation
5.8.3.38. Original Global Page 3319
Requires actual operation authority and sink-side finality.
38.29 — QUALIFIED ABSENCE EVIDENCE
Some operations require evidence that a prohibited condition is
absent.
A protected observer may support such a conclusion only where its
observation coverage and completeness assumptions are sufficient.
For example, a monitor checking one process's logs cannot prove that
no other process accessed a resource.
A protected resource gateway with mandatory control over every
covered resource operation may support stronger assertions concerning
events within its defined coverage.
The claim should precisely identify the guaranteed observation
boundary.
38.30 — INDEPENDENT ACTUAL RESOURCE-SIDE RECONSTRUCTION
The actual Finality Sink obtains or reconstructs material information
about the pending operation.
This may include:
Actual HTTP request method and destination;
Actual database record and mutation;
Das Expires 29 April 2027 [Page 569]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Actual file object;
Actual credential audience;
Actual payment amount and beneficiary;
Actual message recipient and content;
Actual hardware command and device;
Or another covered consequential primitive.
The sink compares the operation with the authenticated Candidate Act
and qualified evidence.
38.30.1 — Upstream Witness
Provides selected evidence relevant to authorization.
5.8.3.39. Original Global Page 3320
38.30.2 — Actual Sink
Checks what is actually being effected.
38.30.3 — Separation
The sink need not accept an agent-provided operation descriptor as
the final description of the receiving-resource effect.
38.31 — SINK-LOCAL EVIDENCE STATE
A protected sink may maintain:
Current accepted evidence-policy generation;
Current observer revocation state;
Actual resource generation;
Qualified validation commitment;
Scoped finality allowance;
And prior consumption state.
38.31.1 — Replay
Das Expires 29 April 2027 [Page 570]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An old receipt cannot independently authorize a new effect.
38.31.2 — Wrong Sink
Evidence approved for another actual enforcement boundary may be
insufficient.
38.31.3 — Stale Predicate
A material change requires current revalidation.
38.32 — CROSS-COMMITTED EVIDENCE
A representative non-limiting construction comprises:
[ C_C=H(\operatorname{Canon}(CA,S,R,E_C)) ]
5.8.3.40. Original Global Page 3321
[ C_O=H(\operatorname{Canon}(O,A,Q,C_C)) ]
[ C_E=H(\operatorname{Canon}(CA,R,E_E,C_O)) ]
[ C_F=H(\operatorname{Canon}(C_C,C_O,C_E,F,L)) ]
where:
(CA) identifies the Candidate Act;
(S) identifies original source authority;
(R) identifies the relevant actual resource;
(E_C) identifies collection-time evidence;
(O) identifies qualified observer identity and competence;
(A) identifies relevant attestation appraisal;
(Q) identifies the current evidence-policy and witness-quality
conditions;
(E_E) identifies independently qualified execution-time evidence;
(F) identifies the actual Finality Sink;
And (L) identifies protected sink-local finality state.
Das Expires 29 April 2027 [Page 571]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
These commitments protect selected relationships.
They do not transform an inaccurate underlying observation into a
true one.
38.33 — PROTECTED VALIDATION RECEIPT
PROTECTED_VALIDATION_RECEIPT = { candidate_act_digest,
original_source_grant_reference, actual_resource_identity,
qualified_collection_evidence_commitment,
observer_identity_and_competence_commitment,
attestation_appraisal_reference_if_required,
independent_execution_evidence_commitment,
5.8.3.41. Original Global Page 3322
evidence_semantic_profile, current_evidence_policy_generation,
current_observer_revocation_generation,
current_operation_descriptor_commitment,
designated_actual_finality_sink, protected_receipt_authentication }
38.33.1 — Receipt Meaning
The receipt attests to the specified protected validation
relationship.
38.33.2 — No Bearer Authority
Possession alone does not authorize a separate actual resource
effect.
38.33.3 — Sink Verification
The actual receiving sink independently checks the applicable
operation and current finality conditions.
38.34 — SCOPED NON-BEARER FINALITY
A protected finality controller may constitute an operation-specific
enablement.
EVIDENCE_BOUND_FINALITY = { candidate_act_digest,
validation_receipt_commitment, actual_target_resource,
actual_effect_descriptor, current_policy_and_revocation_requirements,
required_observer_generation, required_actual_resource_generation,
independent_execution_validation_reference, designated_finality_sink,
sink_local_consumption_reference, protected_enablement_authentication
}
Das Expires 29 April 2027 [Page 572]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The enablement may be retained in a protected domain with only an
opaque reference visible to the autonomous workload.
A changed operation, target, or applicable evidence generation
prevents unqualified reuse.
38.35 — FINALITY SINK VERIFICATION ORDER
5.8.3.42. Original Global Page 3323
A non-limiting sink procedure may verify:
1. Actual receiving-resource identity; 2. Actual pending operation;
3. Original source grant; 4. Material operation correspondence; 5.
Relevant evidence-policy generation; 6. Qualified evidence receipt;
7. Required observer competence; 8. Current evidence revocation; 9.
Applicable current resource and hazard conditions; 10. Required
execution-time witness correspondence; 11. Scoped non-bearer
enablement; 12. Sink-local protected consumption.
The sequence may vary where necessary for atomicity or efficiency.
The critical requirement is that mandatory predicates are enforced
before the actual covered effect becomes effective.
38.36 — EVIDENCE-VERIFICATION EXHAUSTION CONTROL
A malicious agent or observer may supply excessively large or deeply
nested evidence objects.
A protected verifier may limit:
Maximum evidence size;
Nesting depth;
Number of signatures;
Number of recursive certificate relationships;
Number of remote lookups;
Maximum schema complexity;
Processing time or work budget;
And permitted verification retries.
Das Expires 29 April 2027 [Page 573]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.36.1 — No Automatic Acceptance
Exhaustion does not convert an unresolved mandatory predicate into
permission.
38.36.2 — Resource Bound
5.8.3.43. Original Global Page 3324
Verification should be bounded under the chosen implementation.
38.36.3 — Safe Recovery
A failed verification may cause an affected Candidate Act to remain
non-effective.
38.37 — EVIDENCE PRIVACY AND DATA MINIMIZATION
An evidence record may reveal:
Resource identifiers;
Private contents;
Device configurations;
Sensitive user information;
Or proprietary system state.
A protected system may use selective disclosure, authenticated
commitments, or qualified limited evidence where the relevant
authorization predicate can still be established.
38.37.1 — Selective Disclosure
May reduce unnecessary evidence exposure.
38.37.2 — Required Facts
A privacy-preserving representation must still support the actual
mandatory decision.
38.37.3 — Missing Data
A commitment that hides the relevant value does not automatically
prove the required predicate.
Das Expires 29 April 2027 [Page 574]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.38 — OFFLINE EVIDENCE CONTINUITY
During a network partition, an observer may be unable to obtain
current remote attestation or revocation state.
The protected controller distinguishes:
Operations requiring current remote evidence;
Operations expressly permitted under a bounded offline evidence
model;
5.8.3.44. Original Global Page 3325
And operations whose mandatory evidence is locally available through
competent protected observers.
No offline evidence mechanism can guarantee knowledge of an
unreceived remote revocation without an independent constraint
preventing the operation.
38.39 — EVIDENCE AFTER OBSERVER RESTART
An observer may reboot or migrate.
The protected system may require:
Current observer identity;
Current software or configuration qualification;
Reestablished observation-path coverage;
Current evidence-generation continuity;
And recovery of protected revocation state.
A prior attestation result cannot automatically authorize evidence
generated by a materially different observer implementation.
38.40 — MULTI-RESOURCE EVIDENCE CONTINUITY
A complex transaction may rely on evidence from several Finality
Sinks.
The system may distinguish:
Preparation evidence;
Das Expires 29 April 2027 [Page 575]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dispatch evidence;
Commit evidence;
Completion evidence;
And independently observed physical outcome evidence.
A qualified receipt from one sink cannot automatically prove another
sink's actual effect.
A dependent Candidate Act must satisfy the exact receipt semantics
required by its protected dependency graph.
5.8.3.45. Original Global Page 3326
38.41 — EVIDENCE FINALITY STATE MACHINE
A representative state machine comprises:
CANDIDATE_PROPOSED: A consequential operation exists.
CANDIDATE_NON_EFFECTIVE: Actual effectuation is withheld.
EVIDENCE_REQUIREMENTS_ESTABLISHED: Mandatory predicates are
identified.
COLLECTION_PENDING: Initial evidence is being obtained.
COLLECTION_QUALIFIED: Required collection-time observations pass.
OBSERVER_QUALIFICATION_PENDING: Source identity and competence are
evaluated.
ATTESTATION_PENDING: Applicable platform appraisal remains
unresolved.
OBSERVER_QUALIFIED: Required observer conditions pass.
EXECUTION_OBSERVATION_PENDING: Current independent evidence is
required.
EXECUTION_EVIDENCE_QUALIFIED: Current observations pass.
EVIDENCE_CONTRADICTION: Required observations conflict materially.
OBSERVER_COMPROMISE_SUSPECTED: A witness no longer satisfies current
qualification.
Das Expires 29 April 2027 [Page 576]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
DEPENDENCY_FENCED: Affected Candidate Acts remain withheld.
REQUALIFICATION_PENDING: Replacement evidence is being evaluated.
CROSS_COMMITMENT_PREPARED: Evidence relationships are protected.
VALIDATION_RECEIPT_ISSUED: Qualified validation evidence exists.
NON_BEARER_FINALITY_PREPARED: Scoped effectuation enablement exists.
SINK_VERIFICATION_PENDING: Actual operation correspondence is being
checked.
FINALITY_CONSUMED: Protected operation authority is spent.
EFFECT_RELEASED: The covered resource effect is attempted.
EFFECT_CONFIRMED: Qualified actual completion evidence exists.
5.8.3.46. Original Global Page 3327
EFFECT_INDETERMINATE: Actual outcome remains uncertain.
EVIDENCE_SOURCE_REVOKED: A witness is no longer eligible for affected
future decisions.
RECOVERY_QUALIFIED: The necessary evidence relationships are
reestablished.
38.42 — COMPLETE COMMON IMPLEMENTATION WORKFLOW
Step 1 — Establish Original Source Authority. Identify the specific
permitted consequential operation.
Step 2 — Construct Candidate Act. Describe the intended actual target
and effect.
Step 3 — Maintain Non-Effective State. Prevent premature
effectuation.
Step 4 — Determine Mandatory Evidence. Identify predicates required
for the actual operation.
Step 5 — Identify Competent Witnesses. Select sources with
qualifying observation scope.
Step 6 — Identify Trust Dependencies. Record shared observer roots
or failure paths.
Das Expires 29 April 2027 [Page 577]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 7 — Obtain Collection-Time Evidence. Capture initial relevant
conditions.
Step 8 — Qualify Source Identity. Authenticate evidence producers
where required.
Step 9 — Qualify Observer Competence. Check the asserted measurement
is within supported coverage.
Step 10 — Appraise Attestation Where Required. Verify selected
observer-state claims under the applicable current policy.
Step 11 — Protect Initial Evidence. Commit the Candidate Act and
collection-time observations.
Step 12 — Identify Execution Boundary. Determine the actual
receiving-resource effectuation point.
Step 13 — Obtain Execution-Time Evidence. Use a qualified
independent observation path.
Step 14 — Verify Freshness. Check operation-specific time and
generation constraints.
Step 15 — Verify Semantic Correspondence. Compare identifiers,
units, statuses, and resource meanings.
Step 16 — Verify Witness Independence. Apply the selected compromise
model.
5.8.3.47. Original Global Page 3328
Step 17 — Resolve Contradictions. Hold affected operations where
mandatory predicates remain unresolved.
Step 18 — Check Observer Revocation. Apply current evidence-source
eligibility.
Step 19 — Check Current Source and Resource Authority. Evidence does
not replace these grants.
Step 20 — Fence Material Evidence Changes. Invalidate affected
pending finality.
Step 21 — Requalify If Necessary. Obtain competent replacement
evidence.
Das Expires 29 April 2027 [Page 578]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Step 22 — Cross-Commit Evidence. Bind original and current
observations to the Candidate Act.
Step 23 — Generate Validation Receipt. Commit the qualified evidence
relationship.
Step 24 — Prepare Scoped Non-Bearer Finality. Bind authority to the
actual operation and designated sink.
Step 25 — Present Actual Operation to Sink. Submit through the
required protected path.
Step 26 — Reconstruct Actual Effect. The receiving sink
independently identifies target and operation.
Step 27 — Verify Evidence-to-Effect Correspondence. Reject
mismatched or stale evidence.
Step 28 — Verify Current Authority. Apply source, resource, policy,
and revocation conditions.
Step 29 — Verify Protected Consumption. Prevent reuse or
unauthorized duplication.
Step 30 — Release Controlled Effect. Commit only the eligible
consequential operation.
Step 31 — Record Outcome. Distinguish actual completion from mere
dispatch.
Step 32 — Preserve Evidence History. Record valid, revoked, and
replaced evidence generations.
Step 33 — Recover After Compromise. Requalify affected operations
rather than automatically restoring old authority.
38.43 — REFERENCE ALGORITHM: EVIDENCE REQUIREMENT CONSTRUCTION
FUNCTION CONSTRUCT_EVIDENCE_REQUIREMENTS( candidate_act,
5.8.3.48. Original Global Page 3329
protected_policy_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY() REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() operation =
QUALIFY_ACTUAL_INTENDED_CONSEQUENCE( candidate_act ) requirements =
protected_policy_controller .LOAD_MANDATORY_EVIDENCE_PREDICATES(
operation ) REQUIRE VERIFY_REQUIREMENT_POLICY_GENERATION() REQUIRE
Das Expires 29 April 2027 [Page 579]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
VERIFY_REQUIRED_ACTUAL_RESOURCE_SCOPE() RETURN
COMMIT_PROTECTED_EVIDENCE_REQUIREMENTS({ candidate:
HASH(candidate_act), operation: operation, predicates: requirements,
designated_sink: RESOLVE_QUALIFIED_FINALITY_SINK() })
The requirements are obtained from competent protected policy, not
from a lower-trust agent's preference.
38.44 — REFERENCE ALGORITHM: COLLECTION-TIME EVIDENCE
FUNCTION COLLECT_PROTECTED_INITIAL_EVIDENCE( candidate_act,
protected_collector ): requirements =
LOAD_OPERATION_EVIDENCE_REQUIREMENTS( candidate_act ) FOR EACH
predicate IN requirements: observer =
SELECT_COMPETENT_OBSERVER(predicate)
5.8.3.49. Original Global Page 3330
REQUIRE VERIFY_OBSERVER_IDENTITY(observer) REQUIRE
VERIFY_OBSERVER_COMPETENCE( observer, predicate ) evidence =
protected_collector .OBTAIN_QUALIFIED_OBSERVATION( observer,
predicate ) REQUIRE VERIFY_OBSERVATION_SCOPE(evidence) REQUIRE
VERIFY_OBSERVATION_FRESHNESS(evidence) COMMIT_COLLECTION_EVIDENCE(
candidate_act, predicate, evidence ) RETURN
PROTECTED_COLLECTION_COMMITMENT()
38.45 — REFERENCE ALGORITHM: OBSERVER ATTESTATION QUALIFICATION
FUNCTION QUALIFY_OBSERVER_ATTESTATION( observer, appraisal_controller
): REQUIRE VERIFY_OBSERVER_IDENTITY() requirements =
LOAD_CURRENT_ATTESTATION_REQUIREMENTS(observer) evidence =
REQUEST_ATTESTATION_EVIDENCE( observer, requirements.challenge )
REQUIRE VERIFY_ATTESTATION_EVIDENCE_FORMAT() REQUIRE
VERIFY_FRESHNESS_AND_EXPECTED_AUDIENCE()
5.8.3.50. Original Global Page 3331
result = appraisal_controller .APPRAISE_EVIDENCE_WITH_CURRENT_POLICY(
evidence, requirements ) REQUIRE
VERIFY_APPRAISAL_RESULT_INTEGRITY(result) REQUIRE
VERIFY_RESULT_SATISFIES_REQUIRED_PROPERTIES( result ) REQUIRE
VERIFY_CURRENT_OBSERVER_COMPETENCE() RETURN
QUALIFIED_OBSERVER_STATE(result)
The attestation result qualifies specified observer-state properties;
it does not independently prove the truth of every observation.
38.46 — REFERENCE ALGORITHM: INDEPENDENT EXECUTION-TIME WITNESS
Das Expires 29 April 2027 [Page 580]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION VALIDATE_EXECUTION_TIME_EVIDENCE( candidate_act,
protected_execution_observer ): REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() actual =
protected_execution_observer .OBSERVE_CURRENT_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_OBSERVER_OUTSIDE_REQUIRED_COMPROMISE_DOMAIN() REQUIRE
VERIFY_CURRENT_OBSERVER_QUALIFICATION() REQUIRE
VERIFY_CURRENT_OBSERVATION_FRESHNESS() REQUIRE
VERIFY_ACTUAL_EFFECT_CORRESPONDENCE( candidate_act, actual ) REQUIRE
VERIFY_CURRENT_RESOURCE_AND_POLICY_PREDICATES()
5.8.3.51. Original Global Page 3332
RETURN COMMIT_EXECUTION_VALIDATION({ candidate: HASH(candidate_act),
actual_operation: HASH(actual), observer:
CURRENT_OBSERVER_IDENTITY(), generation:
CURRENT_EVIDENCE_GENERATION() })
The required independence property depends upon the selected threat
model and implementation.
38.47 — REFERENCE ALGORITHM: CROSS-DOMAIN EVIDENCE INTERPRETATION
FUNCTION QUALIFY_CROSS_DOMAIN_EVIDENCE( received_record,
local_relying_domain ): REQUIRE VERIFY_EVIDENCE_PRODUCER_IDENTITY()
REQUIRE VERIFY_COMPETENT_ISSUER() REQUIRE VERIFY_RELYING_PARTY_SCOPE(
received_record, local_relying_domain ) profile =
LOAD_QUALIFIED_EVIDENCE_SEMANTIC_PROFILE( received_record ) REQUIRE
VERIFY_SCHEMA_GENERATION(profile) REQUIRE
VERIFY_IDENTIFIER_NAMESPACE(profile) REQUIRE
VERIFY_MEASUREMENT_UNITS(profile) REQUIRE
VERIFY_STATUS_AND_COMPLETION_SEMANTICS(profile) REQUIRE
VERIFY_CURRENT_FRESHNESS_AND_REVOCATION() REQUIRE
VERIFY_LOCAL_PREDICATE_COMPETENCE( received_record ) RETURN
QUALIFIED_LOCAL_EVIDENCE_INTERPRETATION()
5.8.3.52. Original Global Page 3333
An otherwise authentic record is not accepted if its actual semantic
meaning cannot satisfy the local mandatory predicate.
38.48 — REFERENCE ALGORITHM: WITNESS INDEPENDENCE CHECK
FUNCTION VERIFY_WITNESS_SET_INDEPENDENCE( witness_set,
protected_dependency_registry ): requirements =
LOAD_REQUIRED_INDEPENDENCE_POLICY() dependencies =
protected_dependency_registry
.RECONSTRUCT_WITNESS_TRUST_DEPENDENCIES( witness_set ) REQUIRE
Das Expires 29 April 2027 [Page 581]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
VERIFY_REQUIRED_OBSERVER_ROLES() REQUIRE
VERIFY_MANDATORY_OBSERVATION_COVERAGE() REQUIRE
VERIFY_INDEPENDENCE_UNDER_SELECTED_FAULT_MODEL( dependencies,
requirements ) RETURN QUALIFIED_WITNESS_SET
The procedure does not establish independence merely by counting
signatures.
38.49 — REFERENCE ALGORITHM: CONTRADICTION CONTAINMENT
FUNCTION HANDLE_EVIDENCE_CONTRADICTION( candidate_act,
qualified_evidence_set ): contradictions =
FIND_MATERIAL_PREDICATE_CONTRADICTIONS( qualified_evidence_set ) IF
contradictions == NONE: RETURN CONTINUE_QUALIFICATION
5.8.3.53. Original Global Page 3334
affected = MAP_CONTRADICTIONS_TO_CANDIDATE_DEPENDENCIES(
candidate_act, contradictions )
FENCE_AFFECTED_PENDING_FINALITY(affected) REQUIRE
INDEPENDENT_REQUALIFICATION( contradictions ) RETURN
EVIDENCE_UNRESOLVED
A material contradiction is not resolved merely by choosing the
observation preferred by the agent.
38.50 — REFERENCE ALGORITHM: COMPROMISED OBSERVER CONTAINMENT
FUNCTION CONTAIN_COMPROMISED_OBSERVER( observer_identity,
protected_evidence_registry ): REQUIRE
VERIFY_COMPETENT_COMPROMISE_INDICATION() affected_evidence =
protected_evidence_registry .FIND_DEPENDENT_EVIDENCE(
observer_identity ) affected_candidates =
RESOLVE_TRANSITIVE_CANDIDATE_DEPENDENCIES( affected_evidence )
ADVANCE_PROTECTED_OBSERVER_RESTRICTION_STATE( observer_identity )
INVALIDATE_AFFECTED_EVIDENCE(affected_evidence)
FENCE_AFFECTED_FINALITY(affected_candidates)
PRESERVE_UNRELATED_QUALIFIED_EVIDENCE() RETURN
PROTECTED_CONTAINMENT_RESULT(
5.8.3.54. Original Global Page 3335
affected_candidates )
The containment must account for indirect evidence derived from the
compromised observer.
38.51 — REFERENCE ALGORITHM: EVIDENCE REQUALIFICATION
Das Expires 29 April 2027 [Page 582]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
FUNCTION REQUALIFY_AFFECTED_CANDIDATE( candidate_act,
protected_requalification_controller ): REQUIRE
VERIFY_CURRENT_ORIGINAL_SOURCE_GRANT() REQUIRE
VERIFY_CANDIDATE_STILL_NON_EFFECTIVE() requirements =
LOAD_CURRENT_EVIDENCE_REQUIREMENTS( candidate_act ) replacement =
protected_requalification_controller
.SELECT_QUALIFIED_REPLACEMENT_WITNESS( requirements ) REQUIRE
VERIFY_REPLACEMENT_IDENTITY_AND_COMPETENCE() REQUIRE
VERIFY_REQUIRED_INDEPENDENCE() REQUIRE
VERIFY_CURRENT_ATTESTATION_IF_REQUIRED() new_evidence =
OBTAIN_NEW_CURRENT_OPERATION_EVIDENCE( replacement ) REQUIRE
VERIFY_ACTUAL_RESOURCE_AND_EFFECT_CORRESPONDENCE() RETURN
COMMIT_NEW_PROTECTED_EVIDENCE_GENERATION( candidate_act, new_evidence
)
Requalification restores only the eligibility supported by current
valid authority and evidence.
5.8.3.55. Original Global Page 3336
38.52 — REFERENCE ALGORITHM: CROSS-COMMITTED VALIDATION RECEIPT
FUNCTION ISSUE_CROSS_COMMITTED_VALIDATION_RECEIPT( candidate_act,
protected_validation_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY() collection =
LOAD_QUALIFIED_COLLECTION_EVIDENCE() execution =
LOAD_QUALIFIED_EXECUTION_EVIDENCE() REQUIRE
VERIFY_COLLECTION_EVIDENCE_INTEGRITY() REQUIRE
VERIFY_EXECUTION_EVIDENCE_INTEGRITY() REQUIRE
VERIFY_OBSERVER_COMPETENCE_AND_INDEPENDENCE() REQUIRE
VERIFY_CURRENT_ATTESTATION_REQUIREMENTS() REQUIRE
VERIFY_CURRENT_EVIDENCE_REVOCATION() REQUIRE
VERIFY_CROSS_DOMAIN_SEMANTIC_CORRESPONDENCE() REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE() RETURN
protected_validation_controller .COMMIT_VALIDATION_RECEIPT({
candidate: HASH(candidate_act), collection: HASH(collection),
execution: HASH(execution), actual_effect:
HASH(CURRENT_ACTUAL_EFFECT()), sink: ACTUAL_FINALITY_SINK_ID() })
The receipt remains evidence of protected validation, not
unrestricted effectuation permission.
38.53 — REFERENCE ALGORITHM: EVIDENCE-BOUND FINALITY
FUNCTION PREPARE_EVIDENCE_BOUND_FINALITY( candidate_act,
validation_receipt, protected_finality_controller ):
Das Expires 29 April 2027 [Page 583]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.56. Original Global Page 3337
REQUIRE VERIFY_VALIDATION_RECEIPT_INTEGRITY() REQUIRE
VERIFY_RECEIPT_FOR_THIS_CANDIDATE() REQUIRE
VERIFY_CURRENT_SOURCE_AND_RESOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_EVIDENCE_POLICY_GENERATION() REQUIRE
VERIFY_CURRENT_OBSERVER_REVOCATION() REQUIRE
VERIFY_ACTUAL_OPERATION_AND_TARGET() REQUIRE
VERIFY_DESIGNATED_SINK_IDENTITY() RETURN
protected_finality_controller .PREPARE_SCOPED_NON_BEARER_ENABLEMENT({
candidate: HASH(candidate_act), receipt: HASH(validation_receipt),
target: ACTUAL_RESOURCE_IDENTITY(), effect:
HASH(CURRENT_ACTUAL_EFFECT()), sink: ACTUAL_FINALITY_SINK_ID(),
consumption: PROTECTED_SINK_LOCAL_CONSUMPTION_REFERENCE() })
38.54 — REFERENCE ALGORITHM: ACTUAL FINALITY SINK
FUNCTION EFFECTUATE_WITH_QUALIFIED_EVIDENCE( candidate_act,
validation_receipt, finality_reference, protected_actual_sink ):
actual = protected_actual_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_CURRENT_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_ORIGINAL_SOURCE_AUTHORITY() REQUIRE
VERIFY_RECEIPT_CANDIDATE_CORRESPONDENCE( candidate_act,
validation_receipt ) REQUIRE VERIFY_REQUIRED_EVIDENCE_PREDICATES()
5.8.3.57. Original Global Page 3338
REQUIRE VERIFY_CURRENT_OBSERVER_ELIGIBILITY() REQUIRE
VERIFY_REQUIRED_EXECUTION_TIME_EVIDENCE() REQUIRE
VERIFY_ACTUAL_EFFECT_MATCHES_VALIDATED_EFFECT( actual,
validation_receipt ) REQUIRE
VERIFY_CURRENT_RESOURCE_POLICY_AND_REVOCATION() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION() result =
protected_actual_sink .COMMIT_AUTHORIZED_EFFECT_AND_CONSUMPTION(
actual, finality_reference ) RETURN
QUALIFIED_RESOURCE_OUTCOME(result)
The resource's actual transaction or command model determines what
guarantees the final operation provides.
38.55 — REFERENCE ALGORITHM: EVIDENCE NONRESURRECTION
FUNCTION RESTORE_EVIDENCE_REGISTRY( restored_registry,
protected_authoritative_state ): REQUIRE
VERIFY_RESTORED_REGISTRY_INTEGRITY() current =
protected_authoritative_state .LOAD_CURRENT_EVIDENCE_GENERATIONS() IF
Das Expires 29 April 2027 [Page 584]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
restored_registry.observer_generation < current.observer_generation:
FENCE_OBSOLETE_OBSERVER_EVIDENCE() IF
restored_registry.revocation_generation <
current.revocation_generation:
5.8.3.58. Original Global Page 3339
FENCE_OBSOLETE_AUTHORITY() IF
restored_registry.finality_consumption_generation <
current.finality_consumption_generation: FENCE_RESTORED_FINALITY()
REQUIRE VERIFY_CURRENT_OBSERVER_AND_SINK_IDENTITIES() RETURN
QUALIFIED_RECOVERY_STATE
38.56 — WORKED EXAMPLE A: AUTHENTIC BUT FALSE SENSOR READING
A protected sensor produces a correctly authenticated observation.
The sensor is miscalibrated and reports an inaccurate value.
The protected controller requires qualified measurement accuracy for
the operation.
The mandatory predicate is not established merely by the signature.
Expected demonstrable result: Signed evidence does not automatically
qualify inaccurate underlying measurements.
38.57 — WORKED EXAMPLE B: VALID ATTESTATION, WRONG RESOURCE
An observer supplies a valid current platform attestation result.
The observer measures Resource A.
An agent attempts an operation against Resource B.
The execution-time validator verifies the actual resource identity.
The evidence for A cannot authorize B.
Expected demonstrable result: Platform attestation cannot replace
actual operation-specific resource correspondence.
38.58 — WORKED EXAMPLE C: VALID PLATFORM MEASUREMENT, MISSING
COVERAGE
A monitoring component is attested as running a qualified software
image.
Das Expires 29 April 2027 [Page 585]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A new backend execution path is introduced outside the monitor's
coverage.
5.8.3.59. Original Global Page 3340
The protected competence registry identifies the uncovered path.
An operation through that path is withheld unless a competent actual
sink enforces the required conditions.
Expected demonstrable result: Attesting a monitor does not prove
coverage of effectuation paths that it does not observe.
38.59 — WORKED EXAMPLE D: TWO CORRELATED OBSERVERS
Two monitoring processes independently sign the same underlying API
response.
The API response is compromised.
The witness dependency registry identifies the shared underlying
source.
The two signatures are not treated as independent factual
corroboration.
Expected demonstrable result: Multiple signatures cannot
automatically satisfy an independence requirement.
38.60 — WORKED EXAMPLE E: INDEPENDENT RESOURCE-SIDE WITNESS
An agent proposes a database mutation.
An agent-side observer reports that the target is Tenant A.
The actual protected database sink independently identifies the row
as belonging to Tenant B.
The conflicting operation is refused.
Expected demonstrable result: Actual resource-side reconstruction
prevents an upstream observer from silently substituting the
consequential target.
38.61 — WORKED EXAMPLE F: REPLAYED AUTHORIZATION EVIDENCE
A previous source authorization receipt was valid for Candidate Act
A.
Das Expires 29 April 2027 [Page 586]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An attacker reuses it for Candidate Act B.
The protected validator checks the Candidate Act and resource
commitments.
The mismatch is rejected.
5.8.3.60. Original Global Page 3341
Expected demonstrable result: Valid old evidence cannot automatically
authorize a different consequential operation.
38.62 — WORKED EXAMPLE G: STALE RESOURCE VERSION
An observer signs Resource Generation 5.
The actual resource advances to Generation 6 before effectuation.
The current sink identifies that the relevant evidence no longer
satisfies the protected version predicate.
The operation is withheld.
Expected demonstrable result: A correct historical observation does
not substitute for required current resource state.
38.63 — WORKED EXAMPLE H: OBSERVER KEY REVOCATION
An evidence producer's signing credential is revoked.
The agent presents an earlier authentic evidence statement.
The current protected evidence policy requires eligible observer
authority.
The dependent pending operation is fenced.
Expected demonstrable result: Cryptographic authenticity of
historical evidence does not independently establish current observer
eligibility.
38.64 — WORKED EXAMPLE I: SELECTIVE COMPROMISE CONTAINMENT
Observer A supplies evidence for Candidate Acts 1 and 2.
Observer B independently supplies the mandatory evidence for
Candidate Act 3.
Das Expires 29 April 2027 [Page 587]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Observer A is found compromised.
The protected dependency controller fences Acts 1 and 2.
Act 3 may remain eligible subject to its own current evidence and
source authority.
Expected demonstrable result: Compromise containment can be
dependency-specific instead of indiscriminately invalidating
unrelated operations.
5.8.3.61. Original Global Page 3342
38.65 — WORKED EXAMPLE J: INDIRECT EVIDENCE LAUNDERING
Observer A provides raw evidence.
Aggregator C summarizes A's data and signs the summary.
Observer A becomes untrusted.
The protected evidence lineage reveals that C's relevant conclusion
depends upon A.
The affected summary cannot automatically continue authorizing
operations.
Expected demonstrable result: Re-signing or summarizing compromised
evidence does not remove the underlying trust dependency.
38.66 — WORKED EXAMPLE K: WRONG UNIT INTERPRETATION
A remote service supplies a signed time value in milliseconds.
A local verifier incorrectly interprets it as seconds.
The protected semantic profile check detects the mismatch.
The time-dependent operation remains withheld.
Expected demonstrable result: Authentic evidence with incorrect
semantic interpretation cannot satisfy the intended predicate.
38.67 — WORKED EXAMPLE L: CROSS-DOMAIN IDENTIFIER COLLISION
Two administrative domains each use Resource Identifier 42.
Das Expires 29 April 2027 [Page 588]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An agent obtains valid evidence concerning the first domain's
resource.
It attempts a consequential operation in the second domain.
The protected namespace mapping detects the mismatch.
Expected demonstrable result: Shared textual identifiers do not
establish shared actual resource identity.
38.68 — WORKED EXAMPLE M: RECEIPT SEMANTICS
5.8.3.62. Original Global Page 3343
A queue reports that a command was accepted.
The agent claims the actual device completed the operation.
The evidence validator recognizes that acceptance is not completion.
A successor requiring completed effect evidence remains non-
effective.
Expected demonstrable result: Receipt authenticity cannot compensate
for incorrect receipt semantics.
38.69 — WORKED EXAMPLE N: CONTRADICTORY RESOURCE WITNESSES
Observer A reports the resource state as valid.
Observer B reports a material conflict.
The protected controller evaluates the sources and their relevant
freshness.
The mandatory predicate remains unresolved.
The Candidate Act is held.
Expected demonstrable result: Contradictory mandatory evidence does
not become acceptable through arbitrary agent selection.
38.70 — WORKED EXAMPLE O: QUALIFIED OBSERVER REPLACEMENT
A protected observer becomes unavailable.
A successor observer is independently authenticated and appraised.
Das Expires 29 April 2027 [Page 589]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Its competence and resource coverage satisfy the current evidence
requirement.
The affected Candidate Act is revalidated against current source and
actual resource state.
Expected demonstrable result: A system may recover availability
through qualified observer replacement without granting expanded
consequential authority.
38.71 — WORKED EXAMPLE P: EVIDENCE LOG INCLUSION
An agent presents proof that an authorization statement was included
in an append-only log.
The statement itself falsely identifies the resource owner.
5.8.3.63. Original Global Page 3344
The protected controller independently evaluates the ownership
predicate.
The operation is refused.
Expected demonstrable result: Log inclusion does not make an
inaccurate logged statement true.
38.72 — WORKED EXAMPLE Q: ABSENCE OF LOG ENTRY
A monitoring log contains no record of a prohibited operation.
However, the monitor does not cover every possible resource access
path.
The absence cannot satisfy a requirement for complete proof that no
prohibited operation occurred.
Expected demonstrable result: Negative evidence requires an adequate
observation completeness model.
38.73 — WORKED EXAMPLE R: EXECUTION-TIME TOOL SUBSTITUTION
A Candidate Act is prepared for a read-only tool.
The actual tool implementation is replaced with a state-changing
version.
Das Expires 29 April 2027 [Page 590]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The protected execution-time evidence observes the material actual
effect.
Earlier collection evidence no longer corresponds.
Finality is withheld.
Expected demonstrable result: Collection-time approval cannot
silently authorize changed tool semantics.
38.74 — WORKED EXAMPLE S: ATTESTATION POLICY DOWNGRADE
A protected verifier previously required a particular platform
property.
An attacker supplies an older permissive appraisal policy.
The protected current policy-generation check refuses the downgrade.
Expected demonstrable result: An obsolete attestation policy cannot
independently restore earlier evidence eligibility.
5.8.3.64. Original Global Page 3345
38.75 — WORKED EXAMPLE T: OBSERVER REBOOT
A witness restarts under a changed software measurement.
An earlier attestation result remains in the agent's cache.
The protected controller requires current observer-state
qualification.
The old result is insufficient for the changed observer generation.
Expected demonstrable result: An earlier platform state cannot
automatically attest to a materially different restarted observer.
38.76 — WORKED EXAMPLE U: EVIDENCE VERIFICATION EXHAUSTION
An attacker supplies an extremely deeply nested evidence object.
The protected verifier enforces bounded parsing and verification
resources.
The evidence is not accepted after exhaustion.
The relevant Candidate Act remains non-effective.
Das Expires 29 April 2027 [Page 591]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Expected demonstrable result: Verification exhaustion cannot be
converted into an authorization bypass.
38.77 — WORKED EXAMPLE V: PRIVACY-PRESERVING EVIDENCE
A protected resource provides a selective disclosure proving a
required bounded attribute while withholding unrelated sensitive
fields.
The protected validator checks the proof and its relevance.
The operation may proceed if every mandatory predicate is
established.
Expected demonstrable result: Evidence minimization can coexist with
protected finality where the actual required facts remain verifiable.
38.78 — WORKED EXAMPLE W: OFFLINE STALE ATTESTATION
A remote service becomes unreachable.
5.8.3.65. Original Global Page 3346
An agent presents an old valid observer attestation.
The operation's evidence policy requires a current remote appraisal.
The protected controller cannot establish that requirement.
The operation remains withheld.
Expected demonstrable result: Cached attestation cannot substitute
for mandatory live evidence freshness.
38.79 — WORKED EXAMPLE X: WRONG ACTUAL PAYMENT
A collection-time witness confirms a permitted payment amount and
recipient.
The actual payment sink observes a different recipient.
The evidence-to-effect correspondence fails.
The payment is refused.
Expected demonstrable result: Qualified evidence for the intended
payment does not authorize a materially different receiving-resource
transaction.
Das Expires 29 April 2027 [Page 592]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.80 — WORKED EXAMPLE Y: SNAPSHOT RESTORES REVOKED OBSERVER
An attacker restores an evidence registry snapshot containing an
earlier valid observer credential.
The current protected revocation generation is newer.
The old observer is not restored to eligibility.
Expected demonstrable result: Evidence-source authority cannot be
resurrected by restoring obsolete software state.
38.81 — WORKED EXAMPLE Z: END-TO-END ACTUAL RESOURCE FINALITY
An originating principal authorizes one database record update.
The system obtains collection-time source and resource evidence.
A protected observer is qualified for the relevant measurements.
5.8.3.66. Original Global Page 3347
An independent execution-time witness verifies the actual selected
database record and mutation.
Cross-committed evidence is generated.
Scoped non-bearer finality is constituted.
The receiving database sink independently reconstructs the actual
pending write and verifies current source, resource, evidence, and
protected consumption state.
The authorized update commits once.
A modified target, stale witness, forged receipt, or repeated
effectuation attempt is refused.
Expected demonstrable result: Evidence integrity and attestation
contribute to actual finality without becoming independent
unrestricted authority.
38.82 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Fabricated evidence. 2. Valid signature on false content. 3.
Valid attestation overinterpreted as correctness. 4. Observer
competence mismatch. 5. Wrong observation target. 6. Wrong actual
resource. 7. Wrong tenant. 8. Wrong source principal. 9. Wrong
Das Expires 29 April 2027 [Page 593]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Candidate Act. 10. Replayed evidence. 11. Stale measurement. 12.
Delayed measurement delivery. 13. Evidence generation rollback. 14.
Observer software change. 15. Observer credential rotation. 16.
Revoked observer credential. 17. Compromised observer. 18.
Compromised evidence verifier. 19. Compromised aggregator. 20.
Correlated observers. 21. Colluding witnesses. 22. Unqualified
quorum. 23. Shared underlying sensor. 24. Shared compromised data
feed. 25. Missing observation coverage. 26. Alternate unmonitored
execution path. 27. Truncated evidence. 28. Missing mandatory
field. 29. Redaction of decisive information.
5.8.3.67. Original Global Page 3348
30. Incorrect measurement units. 31. Incorrect time units. 32.
Namespace collision. 33. Schema ambiguity. 34. Parser
inconsistency. 35. Canonicalization mismatch. 36. Unknown schema
generation. 37. Completion-state misinterpretation. 38. Queue
acceptance mistaken for resource commit. 39. Dispatch mistaken for
completion. 40. Aggregated score mistaken for raw evidence. 41.
Compromised evidence lineage concealed. 42. Attestation challenge
replay. 43. Attestation result replay. 44. Wrong attested device.
45. Wrong relying party. 46. Appraisal policy downgrade. 47.
Reference-value downgrade. 48. Endorsement misuse. 49. Invalid
certificate chain. 50. Unqualified attestation freshness. 51.
Correct measured software with runtime logical error. 52. Correct
measured software with unobserved side effect. 53. Sensor
calibration failure. 54. Physical sensor manipulation. 55. Sensor
accuracy outside qualified limits. 56. Genuine stale sensor sample.
57. Contradictory witnesses. 58. Arbitrary witness majority. 59.
Compromised observer falsely reported healthy. 60. Excessive
compromise scope. 61. Incomplete compromise containment. 62. Direct
compromised witness dependency. 63. Indirect compromised witness
dependency. 64. Unqualified replacement witness. 65. Restored
revoked observer state. 66. Evidence journal rollback. 67. False
log inclusion inference. 68. False absence inference. 69.
Incomplete event logging. 70. Evidence verification exhaustion. 71.
Recursive evidence object attack. 72. Excessive signature workload.
73. Excessive remote verification requests. 74. Attestation service
denial-of-service. 75. Network partition. 76. Current revocation
unavailable. 77. Resource change after observation. 78. Tool
behavior change. 79. Credential audience change.
Das Expires 29 April 2027 [Page 594]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.68. Original Global Page 3349
80. Operation amount substitution. 81. Actual recipient
substitution. 82. Evidence receipt used as bearer authority. 83.
Cross-committed evidence mismatch. 84. Wrong Finality Sink. 85.
Sink-local consumption replay. 86. Finality issued under obsolete
evidence. 87. Actual effect without sink reconstruction. 88. Sink
bypass through alternate resource path. 89. False actual-effect
receipt. 90. Historical evidence tampering. 91. Unqualified
compensation based on false outcome. 92. Observer key copied to
untrusted runtime. 93. Privacy leakage through excessive attestation
claims. 94. Misinterpretation of hardware-rooted evidence as
universal truth. 95. Unauthorized actual consequential effect
despite apparently valid observer
attestations.
38.83 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed non-limiting experiments. They are not
representations of tests already executed.
Test 1 — Original Source Grant: Establish an authorized consequential
operation.
Test 2 — Candidate Act: Construct the actual operation descriptor.
Test 3 — Non-Effective Hold: Prevent effectuation before finality.
Test 4 — Evidence Policy: Identify mandatory factual predicates.
Test 5 — Qualified Observer Registry: Register selected evidence
sources.
Test 6 — Observer Identity: Verify authenticated source identity.
Test 7 — Observer Competence: Check supported measurement scope.
Test 8 — Collection-Time Evidence: Capture initial relevant
conditions.
Test 9 — Collection Commitment: Bind initial evidence to Candidate
Act and resource.
Test 10 — Attestation Evidence: Obtain selected observer platform
claims.
Das Expires 29 April 2027 [Page 595]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 11 — Appraisal Policy: Apply qualified reference values and
appraisal requirements.
Test 12 — Attestation Challenge: Use an operation-relevant freshness
mechanism.
Test 13 — Old Attestation Replay: Submit earlier evidence.
5.8.3.69. Original Global Page 3350
Test 14 — Wrong Device Attestation: Present valid evidence from
another observer.
Test 15 — Current Observer Generation: Change the observer's software
or configuration.
Test 16 — Competence Change: Remove an observer's qualification to
measure a required property.
Test 17 — Independent Execution-Time Witness: Observe the actual
pending operation.
Test 18 — Observation Separation: Verify the witness is outside the
required agent compromise domain.
Test 19 — Correlated Witness Detection: Use two monitors sharing one
underlying source.
Test 20 — False Independence: Attempt to count correlated witnesses
as separate confirmations.
Test 21 — Qualified Witness Set: Establish an accepted independence
configuration.
Test 22 — Compromised Underlying Data: Make several witnesses report
the same manipulated source.
Test 23 — Current Resource Identity: Verify the actual receiving
target.
Test 24 — Resource Alias Change: Redirect to another resource.
Test 25 — Tenant Change: Substitute another tenant's resource.
Test 26 — Operation Parameter Change: Modify the actual consequential
operation.
Das Expires 29 April 2027 [Page 596]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 27 — Resource Version: Advance actual resource state after
collection.
Test 28 — Freshness Requirement: Submit stale evidence.
Test 29 — Evidence Generation: Update the current qualified
observation generation.
Test 30 — Observer Key Revocation: Revoke a witness credential.
Test 31 — Attestation Policy Generation: Apply a newer required
appraisal policy.
Test 32 — Reference Value Update: Change relevant expected
measurement state.
Test 33 — Cross-Domain Evidence: Import an authenticated remote
observation.
Test 34 — Namespace Collision: Reuse the same local identifier in
another domain.
Test 35 — Unit Mismatch: Change milliseconds to seconds or comparable
units.
Test 36 — Status Mismatch: Treat ACCEPTED as COMPLETED and test
rejection.
5.8.3.70. Original Global Page 3351
Test 37 — Unknown Schema: Supply an unsupported evidence version.
Test 38 — Canonicalization: Use alternative representations of the
same nominal evidence.
Test 39 — Evidence Truncation: Remove a mandatory field.
Test 40 — Evidence Redaction: Hide information necessary for a
predicate.
Test 41 — Valid Selective Disclosure: Supply a sufficient qualified
limited proof.
Test 42 — Conflicting Witnesses: Produce contradictory mandatory
observations.
Test 43 — Contradiction Fence: Confirm the actual operation remains
non-effective.
Das Expires 29 April 2027 [Page 597]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 44 — Compromised Witness: Trigger a qualified observer-
compromise condition.
Test 45 — Direct Dependency: Fence a Candidate Act using that
witness.
Test 46 — Indirect Dependency: Fence a Candidate Act relying upon an
aggregator of compromised evidence.
Test 47 — Unrelated Evidence: Preserve independently qualified
operations.
Test 48 — Replacement Witness: Qualify a successor observer.
Test 49 — Requalification: Obtain current independent evidence.
Test 50 — Observer Reboot: Require renewed relevant state
qualification.
Test 51 — Registry Rollback: Restore an obsolete observer credential.
Test 52 — Evidence Nonresurrection: Refuse revoked observer recovery
through snapshot.
Test 53 — Protected Log Inclusion: Verify inclusion independently of
factual correctness.
Test 54 — False Logged Statement: Confirm that log inclusion does not
authorize the effect.
Test 55 — Absent Log Record: Test the observation completeness
requirement.
Test 56 — Alternative Execution Path: Attempt to bypass a monitoring-
only interface.
Test 57 — Actual Sink Reconstruction: Observe the real operation at
the resource boundary.
Test 58 — Current Source Authority: Revalidate originating
permission.
Test 59 — Current Resource Authority: Revalidate actual ownership and
policy.
Test 60 — Cross-Commitment: Bind initial and current evidence with
operation context.
Das Expires 29 April 2027 [Page 598]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.71. Original Global Page 3352
Test 61 — Protected Receipt: Generate an evidence-specific validation
record.
Test 62 — Receipt Substitution: Use a receipt for another Candidate
Act.
Test 63 — Receipt as Bearer: Attempt to cause an effect using only
the receipt.
Test 64 — Scoped Non-Bearer Finality: Bind enablement to the actual
sink and operation.
Test 65 — Wrong Sink: Present enablement at another resource.
Test 66 — Changed Effect: Modify target, recipient, amount, or method
after validation.
Test 67 — Sink-Local Consumption: Commit bounded authority use.
Test 68 — Replay: Attempt a second consequential effect.
Test 69 — Evidence Verification Exhaustion: Supply an oversized
nested evidence object.
Test 70 — Verification Resource Bound: Confirm the system withholds
rather than permits on exhaustion.
Test 71 — Network Partition: Remove access to a required remote
attestation service.
Test 72 — Live-Required Evidence: Confirm non-effectuation without
current mandatory proof.
Test 73 — Bounded Offline Evidence: Test only expressly authorized
local evidence continuity.
Test 74 — Loss of Effect Acknowledgement: Preserve qualified
indeterminate outcome.
Test 75 — Actual Effect Receipt: Distinguish resource commit from
upstream dispatch.
Test 76 — Remove Observer Competence Check: Attempt to authorize a
fact outside the monitor's scope.
Das Expires 29 April 2027 [Page 599]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Test 77 — Remove Execution-Time Validation: Attempt resource or
operation substitution.
Test 78 — Remove Compromise Dependency Fencing: Attempt stale
evidence use after observer revocation.
Test 79 — Remove Actual Sink Verification: Attempt an unauthorized
real resource operation.
Test 80 — Integrated Workflow: Combine original source grant,
protected collection evidence, observer competence, attestation
appraisal, independent execution observation, cross-domain semantic
correspondence, compromise containment, cross-committed receipt, non-
bearer finality, actual sink reconstruction, protected consumption,
and qualified outcome recording.
5.8.3.72. Original Global Page 3353
38.83.1 — Proposed Measurements
Relevant metrics include:
Unauthorized completed resource effects;
Incorrect acceptance of false evidence;
Acceptance of stale or misbound evidence;
Compromised-observer detection;
Transitive containment coverage;
Incorrect witness independence classification;
False rejection of unrelated operations;
Cross-domain semantic mismatch detection;
Wrong-target sink acceptance;
Replay and duplicate effectuation;
Observer replacement success;
Verification CPU and memory consumption;
And added execution-finality latency.
Das Expires 29 April 2027 [Page 600]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.83.2 — Comparative Ablation
A useful comparison comprises:
Configuration A — Agent-Reported Evidence: The workload relies on
tool responses or agent-supplied facts.
Configuration B — Authenticated and Attested Evidence: The system
verifies selected signatures, attestation results, and evidence
sources.
Configuration C — Qualified Independent Evidence: The system
additionally verifies competence, scope, freshness, semantic
correspondence, independent observation, and compromise dependencies.
Configuration D — Complete Evidence-to-Effect Finality: The system
additionally requires the Candidate Act to remain non-effective until
qualified cross-committed validation, scoped non-bearer finality, and
actual receiving-resource sink reconstruction and consumption.
38.83.3 — Decisive Proposed Anti-Hindsight Experiment
5.8.3.73. Original Global Page 3354
An agent receives authorization to modify a specific resource.
A protected observer produces authenticated evidence for the
operation.
The observer passes a selected platform attestation appraisal.
Before actual effectuation, an attacker changes the actual resource
or command through a path not covered by that observer.
The operation still carries valid-looking original evidence.
The experiment compares whether:
A conventional authenticated-evidence system accepts the request;
An attestation-based controller accepts the request;
An independently observing execution-time verifier detects the
mismatch;
And an actual Finality Sink prevents the unauthorized resource
effect.
Das Expires 29 April 2027 [Page 601]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A second experiment compromises the collection-time observer and
tests whether operations indirectly dependent on its observations are
fenced.
A third experiment supplies qualified replacement observations and
determines whether only properly revalidated operations regain
eligibility.
The decisive measurements concern the actual receiving-resource
mutations and protected effectuation state, not merely the presence
of warnings in an audit log.
38.84 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
38.84.1 — Minimum Components
A PHOSITA may construct:
One autonomous agent;
One original source-authority registry;
Two simulated evidence observers;
One protected observer-competence registry;
One attestation appraisal service or simulated attestation evaluator;
One evidence dependency graph;
5.8.3.74. Original Global Page 3355
One independent execution-time gateway;
One protected validation receipt controller;
One resource database with a separate Finality Sink;
And one durable protected evidence and consumption journal.
38.84.2 — Initial Authorization
The original source permits one exact mutation of one identified
record.
38.84.3 — Collection-Time Evidence
Das Expires 29 April 2027 [Page 602]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Observer A produces a qualified snapshot of the resource version and
authorized operation.
38.84.4 — Observer Qualification
The system authenticates A and checks that its competence covers the
relevant measurement.
38.84.5 — Attestation Qualification
The system obtains selected evidence of A's current protected runtime
state where applicable.
38.84.6 — Candidate Hold
The agent's proposed mutation remains non-effective.
38.84.7 — Execution-Time Observation
Observer B independently obtains the actual pending mutation from the
protected database-gateway side.
38.84.8 — Qualified Correspondence
The resource identity, tenant, operation, and material parameters are
compared.
38.84.9 — Correct Operation
A protected validation receipt is generated.
38.84.10 — Finality
Scoped non-bearer enablement is constituted.
38.84.11 — Actual Sink
The database sink reconstructs the pending mutation and commits
protected consumption with the authorized effect.
5.8.3.75. Original Global Page 3356
38.84.12 — Resource Substitution
The agent changes the actual record identifier after evidence
collection.
38.84.13 — Expected Result
Das Expires 29 April 2027 [Page 603]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The receiving sink refuses the mismatched mutation.
38.84.14 — Compromised Observer
The test marks Observer A as revoked or compromised.
38.84.15 — Dependency Containment
Pending Candidate Acts relying upon A are identified and fenced.
38.84.16 — Independent Unaffected Operation
A separate operation relying on an independent qualified evidence
source remains eligible for its own validation.
38.84.17 — Observer Replacement
The system registers a qualified replacement for A and obtains fresh
evidence.
38.84.18 — Requalification
The affected Candidate Act is independently revalidated under current
source and resource conditions.
38.84.19 — Replay Attempt
The test reuses the earlier validation receipt and finality
reference.
38.84.20 — Expected Result
The duplicate operation is refused.
38.84.21 — Evidence Snapshot Rollback
The observer registry is restored to an earlier state.
38.84.22 — Expected Result
The old revoked observer does not regain eligibility where the
implementation's protected authoritative state supports the required
anti-rollback guarantee.
38.85 — OPTIONAL ADVANCED VARIATIONS
Das Expires 29 April 2027 [Page 604]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.76. Original Global Page 3357
38.85.1 — Hardware-Assisted Observation
A qualified protected component records selected actual resource
operations.
38.85.2 — Remote Attestation
Observer runtime state may be appraised through qualified attestation
protocols.
38.85.3 — Multiple Independent Observers
Selected operations may require independent evidence channels under a
stated fault model.
38.85.4 — Cross-Domain Evidence
Qualified claims may be exchanged between administrative domains.
38.85.5 — Protected Sensor Evidence
Physical measurements may contribute to mandatory hazard predicates.
38.85.6 — Database Version Evidence
Current record identities and versions may be observed at the
resource boundary.
38.85.7 — Network Egress Evidence
Actual destinations and request parameters may be verified.
38.85.8 — Filesystem Effect Evidence
An actual file object may be distinguished from an earlier pathname.
38.85.9 — Credential Audience Evidence
Actual receiving service identity may be checked independently of the
agent's request.
38.85.10 — Financial Transaction Evidence
Payment parameters and actual settlement status may be separately
qualified.
Das Expires 29 April 2027 [Page 605]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.85.11 — Physical Device Evidence
Actual actuator and command identity may be observed at the protected
device controller.
38.85.12 — Append-Only Evidence Logs
Selected evidence history may be committed to authenticated append-
only structures.
38.85.13 — Privacy-Preserving Claims
5.8.3.77. Original Global Page 3358
Selected predicates may be proven without disclosing unrelated
sensitive information.
38.85.14 — Offline Evidence
Specifically preauthorized locally available evidence may support
bounded offline operations.
38.85.15 — Observer Migration
A qualified successor may replace an evidence-producing workload.
38.85.16 — Policy-Generation Change
Material appraisal policy updates may fence pending operations.
38.85.17 — Evidence-Source Revocation
Invalidated observers may be excluded from further finality.
38.85.18 — Cross-Sink Transactions
Actual-effect receipts may support protected dependencies across
resources.
38.85.19 — Protected Resource Outcome Reconciliation
Indeterminate operations may be resolved through competent actual
resource evidence.
38.85.20 — Evidence-Verification Resource Control
Complex evidence objects may be checked under bounded parser and
verification budgets.
Das Expires 29 April 2027 [Page 606]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
38.86 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
38.86.1 — Established Foundations
Existing technologies include:
Remote attestation;
Protected platform measurement;
Trusted computing;
Authenticated evidence records;
Multiple sensor validation;
Evidence provenance;
5.8.3.78. Original Global Page 3359
Transparency logs;
Cryptographic commitments;
Challenge-response;
Reference-value appraisal;
And protected resource authorization.
These are relevant prior technical foundations.
38.86.2 — Candidate Objective Technical Problem
How to preserve the integrity and operation-specific applicability of
evidence supporting autonomous consequential authorization despite
compromised or stale observers, cross-domain semantic ambiguity, and
material changes between collection-time observation and actual
effectuation, while preventing evidence or attestation results from
becoming unrestricted authority to release a different real resource
effect.
38.86.3 — Proposed Technical Solution
The system holds a source-authorized Candidate Act non-effective.
A protected policy defines mandatory evidence predicates.
Das Expires 29 April 2027 [Page 607]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Collection-time evidence is bound to the Candidate Act.
Observer identity, competence, relevant attestation state, and actual
measurement coverage are qualified.
Independent execution-time observation establishes current actual
resource and operation conditions.
A protected evidence dependency graph identifies correlated witnesses
and compromised-source propagation.
Materially invalid or contradictory observations fence affected
Candidate Acts.
Qualified replacement evidence may be obtained without expanding
source authority.
A cross-committed validation receipt binds the required observations.
Scoped non-bearer finality is prepared for the actual operation.
The actual receiving Finality Sink independently reconstructs the
pending effect and verifies source authority, evidence
correspondence, current resource state, and protected consumption
before release.
38.86.4 — Not Merely Remote Attestation
5.8.3.79. Original Global Page 3360
Remote attestation can support appraisal of selected claims about a
device or observer.
The proposed implementation separately determines whether the
observer is competent to establish the operation's required facts,
whether its evidence describes the current pending operation, and
whether the actual resource sink enforces the corresponding
consequence.
38.86.5 — Not Merely Cryptographic Evidence
A signed record can authenticate selected information.
The proposed architecture additionally checks scope, meaning, current
applicability, independent observations, and receiving-resource
effect correspondence.
38.86.6 — Not Merely Multiple Witnesses
Das Expires 29 April 2027 [Page 608]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Multiple witnesses may increase confidence under appropriate
assumptions.
The proposed combination represents trust dependencies and prevents
improperly counting correlated sources as independent.
38.86.7 — Not Merely Compromise Detection
Compromise detection identifies affected observers.
The proposed architecture binds witness eligibility to pending
Candidate Act dependencies and fences actual effectuation authority
accordingly.
38.86.8 — Not Merely Audit Logging
An audit log can preserve evidence history.
The proposed system uses qualified evidence as a mandatory pre-effect
condition and requires independent receiving-resource finality.
38.86.9 — Not Merely Policy-Based Access Control
A policy engine can evaluate evidence and grant an allow decision.
The proposed architecture prevents the allow decision from
independently becoming an unrestricted resource command by requiring
actual operation reconstruction and non-bearer finality.
38.86.10 — Candidate Narrow Inventive Kernel
A protected autonomous evidence-to-execution-finality system in which
a source-authorized Candidate Act remains non-effective, collection-
time evidence is bound to the Candidate Act and qualified through
observer identity and competence requirements, independent execution-
time evidence establishes current actual operation and resource
correspondence, a protected dependency controller fences finality for
Candidate Acts affected by compromised or inapplicable observers,
cross-committed
5.8.3.80. Original Global Page 3361
validation evidence supports scoped non-bearer enablement, and an
independently enforcing actual Finality Sink reconstructs the pending
consequence and releases it only after current source, evidence,
resource, and protected sink-local consumption verification.
38.86.11 — Observer-Competence Kernel
Das Expires 29 April 2027 [Page 609]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A narrower candidate may require evidence-source competence
descriptors binding an authenticated observer to the specific actual
resource properties and event paths it is qualified to measure.
38.86.12 — Compromise-Containment Kernel
Another candidate may require transitive mapping of compromised
observer dependencies to pending Candidate Acts and protected
selective invalidation of associated finality.
38.86.13 — Attestation-Continuity Kernel
Another candidate may require current observer-state appraisal,
competence continuity, and effect-specific binding of qualified
attestation results to independent operation validation.
38.86.14 — Cross-Domain Semantics Kernel
Another candidate may require qualified evidence interpretation
across differing resource namespaces, units, status meanings, and
administrative authorities before protected finality.
38.86.15 — Actual-Sink Evidence Kernel
Another candidate may require the actual Finality Sink to
independently reconstruct the pending operation and compare it to a
protected validation receipt rather than merely accepting a prior
attestation or policy-engine approval.
38.86.16 — Witness-Dependence Kernel
Another candidate may require a protected independence analysis
preventing several witnesses with shared compromised observation
dependencies from satisfying a mandatory independent-witness policy.
38.86.17 — Evidence Nonresurrection Kernel
Another candidate may require current protected observer, appraisal,
revocation, and finality-consumption generations to prevent rollback-
based reacceptance of obsolete evidence.
38.86.18 — Anti-Hindsight Technical Analysis
An examiner may identify earlier systems providing:
Remote attestation;
Trusted sensor observations;
Das Expires 29 April 2027 [Page 610]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.81. Original Global Page 3362
Signed evidence;
Data provenance;
Multi-party approvals;
Quorum validation;
And independent resource authorization.
These components should be acknowledged rather than treated as new
individually.
The relevant analysis should examine whether the closest prior art
already discloses or motivates the specific claimed relationship
among:
1. Original source-authorized consequential Candidate Act; 2.
Enforceable Non-Effective State; 3. Protected operation-specific
evidence requirements; 4. Qualified collection-time evidence; 5.
Observer identity and competence binding; 6. Appropriate attestation
appraisal without overinterpreting its scope; 7. Independent
execution-time actual operation observation; 8. Qualified
observation-channel independence; 9. Cross-domain evidence-semantic
correspondence; 10. Protected evidence-generation and freshness
checks; 11. Transitive compromised-observer dependency containment;
12. Operation-specific selective finality fencing; 13. Cross-
committed collection and execution validation evidence; 14. Scoped
non-bearer effectuation enablement; 15. Independent receiving-
resource operation reconstruction; 16. Current source and resource
authority validation; 17. Sink-local protected consumption; 18.
Recovery without evidence or authority resurrection.
38.86.19 — Functional Interaction Rather Than Aggregation
The proposed architecture does not depend merely upon the coexistence
of attestation, signatures, monitors, and gateways.
The evidence-requirement controller defines which observations are
mandatory for the exact source-authorized Candidate Act.
The observer-competence controller prevents an authenticated but
inadequate source from satisfying an unrelated predicate.
The independent execution-time witness checks the current operation
rather than trusting the original computational description.
Das Expires 29 April 2027 [Page 611]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The dependency controller prevents compromised evidence from
remaining operative through indirect aggregated records.
5.8.3.82. Original Global Page 3363
Cross-committed validation evidence binds current qualified
observation to the Candidate Act.
The scoped non-bearer enablement restricts authority to the actual
effect and designated sink.
The Finality Sink reconstructs the actual pending operation and
independently controls effectuation.
The candidate technical interaction is the prevention of evidence
laundering into actual consequential authority, including through
authenticated, attested, or historically valid evidence that no
longer describes the effect being executed.
38.86.20 — Proposed Comparative Technical Evidence
A useful evaluation may determine whether:
An authentic but factually false observation is accepted;
A valid platform measurement is treated as proof of an unobserved
operation;
Two correlated witnesses are incorrectly treated as independent;
A compromised observer's influence survives through a signed
aggregator;
A changed actual resource is accepted despite correct earlier
evidence;
An attestation result is reused for another Candidate Act;
And the actual Finality Sink prevents unauthorized effects under
those conditions.
38.86.21 — Required Patentability Qualification
The proposed disclosure establishes candidate implementation and
claim-support language.
It does not by itself establish novelty, inventive step, priority, or
enforceability.
Das Expires 29 April 2027 [Page 612]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
A successful inventive-step argument must compare actual claim
limitations against properly dated and relevant prior art.
Existing attestation architectures, capability systems, independent
authorization gateways, and cryptographic evidence systems may
already disclose portions of the proposed combination.
The strongest argument should concern a specifically supported causal
enforcement relationship and demonstrable technical effects, not the
general statement that evidence should be trustworthy.
38.87 — INDUSTRIAL APPLICABILITY
5.8.3.83. Original Global Page 3364
38.87.1 — Autonomous Enterprise Agents
Tool and resource evidence may be qualified independently before
consequential API operations.
38.87.2 — Cloud Infrastructure
Current resource, policy, and workload observations may be bound to
actual cloud effects.
38.87.3 — Trusted Computing
Attestation results may contribute to operation-specific
authorization without replacing actual sink verification.
38.87.4 — Hardware Security
Protected measurement and effectuation boundaries may provide
qualified evidence and command control.
38.87.5 — Industrial Automation
Sensor evidence and device-state observations may be validated
against actual protected physical commands.
38.87.6 — Robotics
Independent observers may establish required operating conditions
before actuation.
38.87.7 — Telecommunications
Das Expires 29 April 2027 [Page 613]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Network configuration changes may require current evidence of actual
target and service state.
38.87.8 — Satellite and Remote Systems
Attestation and operation evidence may be qualified across
intermittent communication domains.
38.87.9 — Financial Transactions
Actual recipients, amounts, and transaction states may be verified
rather than inferred from tool responses.
38.87.10 — Data Disclosure
Actual protected recipient and content evidence may control
consequential information release.
38.87.11 — Identity and Credential Systems
5.8.3.84. Original Global Page 3365
Attestation and workload identity may be combined with actual
resource audience and credential-use finality.
38.87.12 — Distributed Databases
Qualified committed-state receipts may support dependent resource
operations.
38.87.13 — Software Supply Chains
Current runtime and resource evidence may be distinguished from
earlier artifact attestations.
38.87.14 — Multi-Agent Orchestration
Evidence from different agents may be evaluated under explicit trust
and independence requirements.
38.87.15 — Confidential Computing
Protected observation domains may produce qualified evidence for
external relying parties.
38.87.16 — Cyber-Physical Systems
Das Expires 29 April 2027 [Page 614]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Current measurements and actual hardware command semantics may be
validated separately.
38.87.17 — Persistent AI Memory
Evidence provenance may control irreversible knowledge-store or
shared-memory commits.
38.87.18 — Connected Devices
Device-state evidence may be appraised under current resource-
specific policy.
38.87.19 — Regulated Technical Infrastructure
Authenticated evidence and independently enforced actual resource
changes may support technical accountability.
38.87.20 — Future Autonomous Critical Systems
Evidence-producing components may be treated as qualified witnesses
rather than as unrestricted authorities to cause real effects.
38.88 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
38.88.1 — Candidate Independent System Claim
A system comprising:
5.8.3.85. Original Global Page 3366
A protected source-authority controller configured to identify a
permitted consequential operation;
A Candidate Act controller configured to maintain the proposed
operation in a Non-Effective State;
An evidence-requirement controller configured to define mandatory
operation-specific observations;
A protected collection-time evidence controller configured to bind
selected observations to the Candidate Act;
An observer-qualification controller configured to verify evidence-
producing entities against corresponding identity, competence,
resource-scope, and current eligibility requirements;
Das Expires 29 April 2027 [Page 615]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
An independent execution-time evidence controller configured to
obtain qualified current information concerning the actual pending
operation;
An evidence-dependency controller configured to identify and fence
Candidate Acts affected by compromised, invalid, or materially
inapplicable observers;
A cross-committed validation controller configured to bind original
and current qualified evidence to the operation;
A scoped non-bearer finality controller;
And an independent actual Finality Sink configured to reconstruct the
pending real effect and conditionally release the effect only after
current source, evidence, resource, operation, and sink-local
protected consumption verification.
38.88.2 — Candidate Independent Method Claim
A method comprising:
Establishing original source authority for an actual consequential
operation;
Representing the operation as a Candidate Act;
Maintaining it in a Non-Effective State;
Identifying required factual predicates;
Obtaining protected collection-time evidence;
Qualifying the observer's identity and competence;
Appraising specified observer-state attestation evidence where
required;
Obtaining independent execution-time actual-operation evidence;
5.8.3.86. Original Global Page 3367
Validating evidence freshness, resource identity, witness dependence,
and semantic correspondence;
Fencing affected operation finality when a mandatory observer or
evidence predicate becomes invalid;
Das Expires 29 April 2027 [Page 616]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Generating cross-committed protected validation evidence;
Preparing scoped non-bearer finality;
And permitting actual effectuation only through a receiving Finality
Sink that independently reconstructs and verifies the pending
operation and protected consumption.
38.88.3 — Candidate Independent Compromised-Observer Claim
A protected autonomous execution system configured to maintain
evidence dependency relationships among observers, derived evidence,
and pending consequential Candidate Acts, and upon qualification of
an observer compromise, identify direct and indirect affected
operations, fence corresponding pending effectuation authority, and
require current competent replacement evidence before eligible
operations may be revalidated.
38.88.4 — Candidate Independent Attestation-Continuity Claim
A protected execution-finality system configured to bind an
operation-specific evidence requirement to qualified observer-state
attestation, current observer competence, independent execution-time
actual resource observation, and effect-specific non-bearer finality
enforced by the actual receiving resource.
38.88.5 — Candidate Independent Cross-Domain Witness Claim
A protected multi-domain autonomous execution system configured to
qualify external evidence according to competent producer identity,
actual resource namespace, evidence semantic profile, freshness,
required observation scope, and current relying-party authority, and
to require independent actual receiving-resource verification before
a consequential operation is released.
38.89 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The computational workload comprises an autonomous AI agent. 2.
The workload invokes external tools. 3. The workload operates across
administrative domains. 4. The Candidate Act represents a
consequential resource operation. 5. The Candidate Act is maintained
non-effective. 6. An original source grant identifies permitted
actual effects. 7. A protected evidence requirement identifies
mandatory factual predicates. 8. The requirement is operation-
specific. 9. A protected collector acquires collection-time
evidence. 10. The collection-time evidence is bound to the Candidate
Act.
Das Expires 29 April 2027 [Page 617]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.87. Original Global Page 3368
11. The evidence identifies actual resource scope. 12. The evidence
identifies an observer identity. 13. The observer has a qualified
competence descriptor. 14. The descriptor identifies permitted
measurement types. 15. The descriptor identifies permitted resource
scopes. 16. The descriptor identifies actual observation paths. 17.
The descriptor identifies relevant measurement quality. 18. A
signing key is distinguished from factual competence. 19. Evidence
producer identity is verified. 20. Evidence provenance is verified.
21. Evidence freshness is verified. 22. Evidence resource identity
is verified. 23. Evidence operation identity is verified. 24.
Evidence schema generation is verified. 25. Evidence semantic
profile is verified. 26. Measurement units are verified. 27.
Resource namespaces are verified. 28. Receipt semantic classes are
verified. 29. A protected attestation appraisal may be required. 30.
The appraisal uses a qualified current policy. 31. The appraisal may
use reference values or endorsements. 32. A freshness challenge may
be used. 33. Attestation evidence is bound to the intended observer.
34. Attestation evidence is bound to the intended relying-party
context. 35. An attestation result does not independently grant
source authority. 36. An unchanged measurement does not
automatically prove complete runtime
correctness. 37. An independent execution-time observer obtains
actual pending operation evidence. 38. The execution-time observer
may be outside the agent compromise domain. 39. An observer may be
located at an actual resource interface. 40. The observer may
qualify actual network destinations. 41. The observer may qualify
actual database records. 42. The observer may qualify actual file
objects. 43. The observer may qualify actual credential audiences.
44. The observer may qualify actual physical device commands. 45. A
protected graph identifies shared witness dependencies. 46.
Correlated observers are distinguished from independent observers.
47. A witness quorum is interpreted under defined fault assumptions.
48. Conflicting mandatory evidence may cause finality fencing. 49.
An unqualified observer is excluded from mandatory evidence
satisfaction. 50. An observer's credential may be revoked. 51. An
observer's current measured state may change. 52. An observer's
competence may be withdrawn. 53. An observer's observation coverage
may become incomplete. 54. A protected controller identifies
directly affected Candidate Acts. 55. A protected controller
identifies indirectly affected Candidate Acts. 56. Derived evidence
retains relevant witness lineage. 57. A compromised evidence
aggregator does not independently restore source authority. 58. A
selective fence may invalidate affected pending finality. 59.
Unrelated independently qualified operations need not be invalidated
automatically.
Das Expires 29 April 2027 [Page 618]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.88. Original Global Page 3369
60. A replacement witness requires competent qualification. 61. A
replacement witness may require fresh attestation. 62. A replacement
witness may require independent observation-channel coverage. 63. An
affected Candidate Act requires current revalidation. 64. A
qualified cross-domain evidence mapping identifies resource
namespaces. 65. The mapping identifies evidence schema generation.
66. The mapping identifies measurement units. 67. The mapping
identifies receipt completion semantics. 68. The mapping identifies
current relying-party scope. 69. A valid signature does not override
an incorrect semantic interpretation. 70. A protected
canonicalization profile is associated with evidence serialization.
71. An evidence generation may be bound to the Candidate Act. 72. A
material evidence-generation change may invalidate pending finality.
73. A material resource-version change may invalidate pending
finality. 74. An obsolete attestation appraisal may be rejected. 75.
A revoked observer may not regain eligibility through snapshot
rollback. 76. An authenticated log may preserve selected evidence
history. 77. Log inclusion does not independently prove the factual
accuracy of a record. 78. An absence of logged events requires a
qualified observation completeness model. 79. A protected verifier
may limit evidence size. 80. A protected verifier may limit nesting
depth. 81. A protected verifier may limit computational verification
cost. 82. Verification exhaustion does not authorize the pending
effect. 83. Evidence may be selectively disclosed while preserving
mandatory predicates. 84. Collection and execution evidence may be
cross-committed. 85. A protected validation receipt may identify the
actual Candidate Act. 86. The receipt may identify the actual
resource and operation. 87. The receipt may identify relevant
observer qualification. 88. The receipt may identify current
evidence-policy generation. 89. The receipt does not independently
function as unrestricted bearer authority. 90. Scoped non-bearer
finality may be bound to the validation receipt. 91. The actual
Finality Sink independently reconstructs the pending effect. 92. The
sink verifies current source and resource authority. 93. The sink
verifies current qualified evidence correspondence. 94. The sink
verifies protected consumption before effectuation. 95. Existing
remote attestation, authenticated evidence, protected logging,
workload
identity, semantic schemas, and independent resource gateways may be
used as non-limiting implementation substrates.
38.90 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
Das Expires 29 April 2027 [Page 619]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The technical features disclosed herein may be implemented
individually where sufficient or in any technically compatible
combination.
An implementation may use software evidence collectors.
Another may use protected operating-system monitoring.
5.8.3.89. Original Global Page 3370
Another may use hardware-assisted measurement.
Another may use remote attestation.
Another may use authenticated resource-side observations.
Another may use multiple independent witnesses.
Another may use a qualified quorum under a stated fault model.
Another may use signed evidence receipts.
Another may use append-only evidence logs.
Another may use cryptographic commitments.
Another may use protected evidence-dependency graphs.
Another may use observation-channel competence registries.
Another may use cross-domain evidence translation.
Another may use protected semantic profiles.
Another may use selective disclosure.
Another may use resource-specific current version checks.
Another may use protected observer-generation state.
Another may use observer revocation.
Another may use replacement evidence following compromise.
Another may use independent execution-time validation.
Another may use actual receiving-resource reconstruction.
Das Expires 29 April 2027 [Page 620]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Another may use scoped non-bearer finality.
Another may use protected sink-local consumption.
The invention does not require every operation to use remote
attestation.
The invention does not presume that every attested platform is free
from runtime vulnerabilities.
The invention does not presume that a signed sensor reading is
physically accurate.
The invention does not require that every independent witness use
different hardware.
5.8.3.90. Original Global Page 3371
The invention does not assume that two signing keys provide
independent factual evidence.
The invention does not assert that a majority of witnesses must
always be correct.
The invention does not presume a protected log contains every
relevant event.
The invention does not presume that log inclusion establishes factual
truth.
The invention does not require unrestricted disclosure of sensitive
evidence fields.
The invention does not permit redaction to conceal mandatory
information necessary for protected validation.
The invention does not permit an attestation result to create missing
original source authority.
The invention does not permit an authenticated tool result to
substitute for actual receiving-resource effectuation evidence where
such evidence is mandatory.
The invention does not require a universal evidence schema across all
administrative domains.
The invention does not assume that identical textual resource
identifiers represent the same object across namespaces.
Das Expires 29 April 2027 [Page 621]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The invention does not assume that a collection-time observation
remains current after a material resource change.
The invention does not presume that a monitoring component controls
every alternate effectuation path.
The invention does not require that a compromised observer invalidate
every unrelated operation.
The invention does not permit compromised observations to regain
eligibility through unqualified aggregation or replay.
The invention does not require exact global clock synchronization
where qualified operation-generation or transactional evidence
suffices.
The invention does not presume that a software signature guarantees
non-rollback of all protected local state.
The invention does not permit successful evidence validation to
become unrestricted authority for a different actual operation.
The drawings, algorithms, equations, proposed experiments, data
structures, implementation mappings, and examples are illustrative,
optional, and non-limiting technical aids for a person having
ordinary skill in the art.
5.8.3.91. Original Global Page 3372
Technically compatible features from other embodiments may be
combined where supported, without requiring all optional features in
every implementation.
38.91 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 38 discloses a protected autonomous evidence-
to-execution-finality architecture.
An originating principal authorizes a bounded consequential
operation.
The computational workload generates a Candidate Act.
The Candidate Act remains in a Non-Effective State.
A protected controller establishes the evidence required to qualify
that act.
Das Expires 29 April 2027 [Page 622]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Collection-time evidence is obtained from competent sources.
Observer identity, observation coverage, current eligibility, and
optional attestation appraisal are qualified.
The protected controller distinguishes authenticated evidence from
the truth and applicability of the underlying observation.
An independent execution-time witness obtains current relevant
information concerning the actual pending operation.
The system verifies observation freshness, resource identity,
evidence semantics, channel dependence, current source authority, and
applicable revocation.
Material contradictions or compromised evidence sources trigger
selective containment of affected pending finality.
Qualified replacement evidence may restore operation eligibility only
after current revalidation.
Collection-time and execution-time evidence are cross-committed.
A protected validation receipt identifies the qualified Candidate Act
and actual effect.
Scoped non-bearer finality is prepared for the designated receiving
resource.
The actual Finality Sink reconstructs or independently observes the
pending operation and verifies that the actual consequence matches
the protected authorization and validation evidence.
The sink verifies current source, resource, evidence, and protected
consumption state before effectuation.
5.8.3.92. Original Global Page 3373
Successful evidence collection, authentic signatures, and attestation
results cannot independently authorize a different resource effect.
A compromised observer cannot automatically propagate consequential
authority through derived evidence or stale receipts.
The protected system preserves the distinction between computational
evidence, qualified authorization evidence, and actual resource
finality.
Das Expires 29 April 2027 [Page 623]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The principal candidate inventive technical concept of Embodiment 38
is a protected autonomous evidence-integrity execution-finality
system in which a source-authorized Candidate Act remains non-
effective while collection-time and independently acquired execution-
time observations are qualified for observer identity, competence,
continuity, independence, and actual effect correspondence;
compromised observer dependencies selectively fence pending finality;
cross-committed evidence supports scoped non-bearer enablement; and
the actual receiving Finality Sink independently reconstructs and
verifies the consequential operation before protected authority
consumption and controlled effectuation.
38.92 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may use established
technologies as optional implementation substrates.
Existing technology Non-limiting implementation role RFC 9334 — RATS
Architecture
Separate attesters, evidence, verifiers, appraisal results, and
relying-party decisions RFC 9711 — Entity Attestation Token
Encode selected attested entity claims in an interoperable token
structure RFC 9999 — RATS Conceptual Message Wrapper
Encapsulate selected attestation-related conceptual messages
RFC 9052 — COSE Authenticate or sign selected evidence and validation
records
RFC 8949 — CBOR Encode structured evidence under a suitable
deterministic profile RFC 9162 — Certificate Transparency
Provide a reference model for append-only evidence logging,
consistency, and inclusion verification
Hardware-backed platform roots Support selected protected measurement
and attestation
claims Protected operating-system interfaces
Observe selected actual resource operations independently of the
agent Service and workload identities Identify competent protected
observers
Transactional databases Maintain evidence generations, dependencies,
revocations, and finality consumption
Das Expires 29 April 2027 [Page 624]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.93. Original Global Page 3374
Protected API and database gateways Independently reconstruct actual
consequential operations
Authenticated device and sensor interfaces Supply selected qualified
physical state evidence
Durable operation journals Preserve qualified evidence, actual
effects, and outcome classifications
38.92.1 — Practical Common PHOSITA Workflow
First, establish original source permission for the exact
consequential operation.
Second, represent the operation as a Candidate Act and hold its
effect non-effective.
Third, identify mandatory evidence predicates and their competent
observer roles.
Fourth, establish observer identity, actual observation coverage, and
current required measurement properties.
Fifth, collect and protect collection-time evidence bound to the
Candidate Act.
Sixth, appraise selected observer attestation evidence under the
applicable current policy where required.
Seventh, identify shared dependencies between evidence-producing
components.
Eighth, obtain current execution-time evidence through a qualified
observation path independent of the proposing agent to the extent
required by the threat model.
Ninth, verify actual resource, operation, units, namespace, schema,
freshness, and evidence-policy correspondence.
Tenth, fence pending finality where mandatory evidence is invalid,
compromised, contradictory, or unavailable.
Eleventh, trace compromised observer effects through direct and
derived evidence dependencies.
Das Expires 29 April 2027 [Page 625]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Twelfth, obtain qualified replacement evidence where permitted and
revalidate affected operations.
Thirteenth, cross-commit the original Candidate Act, collection-time
evidence, execution-time evidence, observer qualification, and actual
operation descriptor.
Fourteenth, issue a protected validation receipt.
Fifteenth, prepare scoped non-bearer finality tied to the current
actual resource and designated sink.
5.8.3.94. Original Global Page 3375
Sixteenth, require the receiving Finality Sink to independently
reconstruct the pending consequential operation.
Seventeenth, check current source, evidence, actual resource, and
protected consumption conditions at the sink.
Eighteenth, conditionally effectuate the exact qualified operation
and preserve accurate outcome evidence.
38.92.2 — Minimal Reference Data Structures
EVIDENCE_REQUIREMENT ( candidate_id, source_grant_reference,
actual_resource_id, operation_digest, required_predicates,
accepted_observer_classes, required_independence, freshness_policy,
sink_id ) OBSERVER_COMPETENCE ( observer_id,
permitted_measurement_scope, actual_observation_path,
semantic_profile, attestation_requirement, current_generation,
revocation_generation ) COLLECTION_EVIDENCE ( candidate_id,
observer_id, resource_id, observed_operation_digest,
observed_generation, evidence_commitment ) EXECUTION_EVIDENCE (
candidate_id, execution_observer_id, actual_resource_id,
actual_operation_digest, current_resource_generation,
evidence_commitment )
5.8.3.95. Original Global Page 3376
VALIDATION_RECEIPT ( candidate_id, collection_commitment,
execution_commitment, observer_qualification_commitment,
current_policy_generation, actual_effect_digest, sink_id )
SINK_FINALITY ( candidate_id, validation_receipt_commitment,
actual_target, actual_effect_digest, current_revocation_generation,
protected_consumption_state )
These structures are illustrative.
Das Expires 29 April 2027 [Page 626]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
The enforceable technical behavior depends upon qualified observation
paths, appropriate trust boundaries, and actual protected receiving-
resource controls rather than merely storing the listed fields.
38.92.3 — Decisive Prototype for Hindsight Analysis
A PHOSITA may construct a reference system with:
One autonomous agent;
One simulated untrusted tool;
One source-authority controller;
One collection-time evidence observer;
One independently controlled execution-time resource gateway;
One protected observer-competence registry;
One simple attestation appraisal service or evaluator;
One transactionally enforced database Finality Sink;
And one protected evidence and finality journal.
The source principal authorizes modification of one specified
database record.
The agent obtains authentic collection-time evidence for the correct
target.
5.8.3.96. Original Global Page 3377
The evidence producer passes a selected attestation appraisal.
Before final effectuation, the attacker changes the actual database
target while preserving the earlier authentic signed evidence.
The execution-time resource gateway reconstructs the real database
mutation.
The protected validator detects the difference.
The receiving sink refuses the unauthorized update.
In a second variant, the collection-time observer is compromised.
Das Expires 29 April 2027 [Page 627]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Its evidence is submitted through a separate signed aggregator.
The protected dependency controller identifies that the aggregated
evidence still relies upon the compromised source.
The affected Candidate Act is fenced.
In a third variant, a qualified independent replacement observer
provides current evidence.
The system revalidates the operation without changing its original
source-authorized scope.
In a fourth variant, the correct operation passes all required
evidence conditions.
The sink validates scoped non-bearer finality and commits the update
once.
A replayed validation receipt cannot cause a second unauthorized
mutation.
The evaluation should inspect the actual receiving database state and
protected finality journal.
38.92.4 — Critical PHOSITA Implementation Cautions
An attested observer can still contain logical vulnerabilities.
An authenticated sensor can still be inaccurate.
Several observers can share the same faulty upstream source.
A cryptographic commitment does not establish factual correctness of
committed data.
Log inclusion is different from event completeness or factual
validity.
A platform measurement is not automatically proof of current
application-layer behavior.
Cross-domain evidence must preserve correct units, resource
namespaces, and semantic interpretations.
Das Expires 29 April 2027 [Page 628]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
5.8.3.97. Original Global Page 3378
A witness compromise may affect derived evidence as well as direct
reports.
Evidence-verification exhaustion must not cause an authorization
bypass.
A valid evidence receipt is not a bearer capability for arbitrary
downstream effects.
Actual resource finality depends upon control of the real receiving
operation boundary.
38.92.5 — Non-Limiting Common Reference Combination
Original source authority → Candidate Act → Non-Effective State →
protected evidence requirements → qualified collection-time evidence
→ observer identity and competence → optional attestation appraisal →
independent execution-time actual-operation evidence → cross-domain
semantic correspondence → witness independence and compromise
qualification → selective dependency fencing → cross-committed
validation evidence → protected validation receipt → scoped non-
bearer finality → independent actual Finality Sink reconstruction →
current source, resource, evidence, and operation verification →
sink-local consumption → controlled actual effectuation → qualified
outcome and evidence-continuity recording.
The proposed distinguishing technical relationship is the protected
separation of evidence authenticity, observer competence, attestation
appraisal, independent current observation, and actual consequential
authority, so that compromised or misleading evidence cannot
independently cause a real effect and the Finality Sink remains the
mandatory control point for execution-finality.
END OF EMBODIMENT 38 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 39
PROTECTED AUTONOMOUS POLICY-CONFLICT AND AUTHORITY-PRECEDENCE
FINALITY ACROSS MULTIPLE PRINCIPALS, ADMINISTRATIVE DOMAINS, AND
RESOURCE OWNERS
39.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Across Multiple Competent Authorities Using
Protected Authority-Provenance Graphs, Operation-Specific Authority-
Das Expires 29 April 2027 [Page 629]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Dimension Decomposition, Qualified Policy-Applicability and
Precedence Resolution, Non-Effective Candidate Acts, Non-Overridable
Mandatory Restrictions, Delegation Attenuation, Authority-Specific
Exception Validation, Multi-Domain Grant Correspondence, Protected
Conflict and Indeterminacy Fencing, Current Policy-Generation
Verification, Cross-Domain Validation Commitments, Scoped Non-Bearer
Finality, Independent Actual Finality-Sink Reconstruction, and Sink-
Local Protected Consumption Without Unauthorized Authority
Amplification
39.0.1 — General Technical Description
6. PHOSITA Implementation: Existing Software, Kernel Controls, Secure
Hardware and Practical Constraints
These are newly authored non-limiting reference designs. They give
implementers a reproducible build path using cooperative endpoints
and public interfaces; they are not proof that proprietary operating
systems expose arbitrary kernel hooks or that a proposed prototype
has passed testing. Use safe synthetic effects under authorized lab
conditions.
6.1. Choose a benign effect and define the effect boundary
Start with an owned test resource: a staging database record, fake
file export endpoint, mock credential broker or virtual actuator.
Precisely define what effect counts as real, what a prepared request
means, and which component has the last genuine blocking control.
6.2. Build the lower-trust agent sandbox
Run the agent under an existing sandbox/container/microVM or process
confinement, with no unrestricted direct egress to the protected test
resource. Treat isolation as one layer, not the authority decision.
Keep the agent from editing protected policy or consumed-grant state.
6.3. Enumerate the effect-capable path graph
Document file writes, sockets, local privileged IPC, browser
automation, gateway dispatch, credential signing, queue consumers,
accelerator submission and alternate aliases. For each path record
resource, relevant authority, owner, actual blocking mechanism and
coverage state.
Das Expires 29 April 2027 [Page 630]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6.4. Distinguish advisory observers and mandatory blockers
An audit-only eBPF program or LSM tracepoint reports behavior but
cannot by itself enforce release-time refusal. Document which
sandbox or kernel policy, proxy, broker or resource API actually
denies each protected operation.
6.5. Define canonical operation identity
Encode operation ID, source-grant reference, principal, actor, verb,
target, recipient, body commitment, destination, resource revision,
sink, coverage generation and validity conditions under a declared
canonical CBOR or JSON profile.
6.6. Protect the source-grant and finality ledger
Keep immutable or integrity-protected grant, receipt, delegation,
revocation, topology generation and consumption state on a service
outside the untrusted agent. Use transactional atomic compare-and-
consume before effect dispatch.
6.7. Construct a protected gateway with controlled egress
Use a cooperating gateway or mock resource server with deny-by-
default route filtering. Observe the actual outbound destination,
HTTP method and payload in a controlled execution path. Validate
target aliases and redirects again before releasing the real effect.
6.8. Support Linux seccomp and LSM integrations where appropriate
Use seccomp for defined syscall classes, supported Linux Security
Module hooks for relevant object operations, and eBPF for
observability where permitted. Do not assume inspection of mutable
userspace memory at an early hook is race-free or completes actual
resource-side authorization.
6.9. Model Windows security boundaries without private assumptions
Use documented Windows service, identity, code integrity, VBS or
sandbox mechanisms where supported. Bind privileged service commands
to application-level operation identity and a downstream resource
Finality Sink; do not claim kernel isolation alone binds original
task intent.
Das Expires 29 April 2027 [Page 631]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6.10. Implement supported Android application mediation
Use app-owned Android Service/Binder interfaces and Keystore-backed
operations where available, authenticate calling identities, apply
scoped business authorization at a server or cooperating privileged
resource. A normal Android app cannot globally intercept all other
apps or SoC DMA controllers.
6.11. Implement supported Apple app and server integration
Use documented App Intents, app container interfaces, Keychain APIs
and app-owned backend checks, subject to entitlements and platform
versions. General third-party iOS apps do not gain unrestricted
privileged system service mediation or Secure Enclave control of
unrelated apps.
6.12. Isolate reusable credentials from the untrusted workload
Use a separately privileged test broker with secret custody. An
agent gets only an inert reference and its Candidate Act; the broker
independently reconstructs the concrete credential-use operation
before signing or dispatch.
6.13. Treat hardware attestation as scoped evidence
If available, collect trusted device measurements, software/firmware
versions and relevant audience/nonce. Appraise under an explicit
trust policy; do not treat attestation success as authorization for
an arbitrary effect.
6.14. Guard GPU and device command queues only where controlled
Place enforcement before accessible accelerator submission, DMA
mapping, device driver queue activation or actual receiving actuator
command. When the resource is not under the chosen control, label
the path uncontrolled instead of asserting full containment.
6.15. Protect live sandbox policy mutations
Apply a distinct administrator/meta-authority test for changing
kernel policies, network allowlists, tool entitlements and gateways.
Revoke or revalidate dependent previously approved Candidate Acts on
material rule changes.
Das Expires 29 April 2027 [Page 632]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6.16. Model runtime changes and rollback
Record signed or otherwise authenticated tool identity, image or
binary digest, contract version and security policy generation.
Reassess prior effect bindings on software upgrade, downgraded
runtime or restoration of a suspended VM snapshot.
6.17. Qualify separate observers and witnesses
Give each witness a verifiable role, competence range, freshness/
nonce mechanism and compromise assumptions. Cross-check independent
evidence with actual sink-observed operation; do not count correlated
copied evidence as several independent confirmations.
6.18. Use exact resource-side conditional writes
For test data use versioned conditional mutation, compare-and-swap,
row-level transaction or equivalent resource-native mechanism, so
finality checks apply to the actual resource at commit rather than to
a stale preliminary copy.
6.19. Define crash and retry semantics
Journal AVAILABLE, RESERVED, CONSUMED, CONFIRMED_EFFECT,
CONFIRMED_NON_EFFECT, and INDETERMINATE states as appropriate. A
timeout, local crash or queued acknowledgment does not prove a
completed remote effect was absent.
6.20. Record enforcement coverage evidence
At each relevant topology or firmware change, produce a signed or
protected coverage report with paths, blocking control IDs,
semantics, resource owner and generation. Invalidate stale scoped
enablement when mandatory coverage is lost.
6.21. Enforce bounded verification resources
Limit requests, evidence sizes, graph traversal, signature validation
work and witness quorum effort. Exhaustion must deny or safely defer
effects, not trigger permissive fallback.
6.22. Keep reference test profiles vendor-neutral
Express optional Linux, Android, Apple, Windows, Arm and device-
controller paths as separate supported implementation profiles, with
explicit experimental prerequisites and no essential proprietary
dependency.
Das Expires 29 April 2027 [Page 633]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
6.23. Publish reproducible source-to-figure mapping
Provide the original source page anchors, concrete test profile,
input descriptors, expected outcomes and required protected state
conditions. Do not claim that newly authored pseudocode appears
verbatim in PCT/IB2026/055615 without corroborating as-filed
evidence.
7. Reference Data Structures, Control Interfaces, State Machines and
Non-Limiting Algorithms
The following algorithms and data structures are proposed engineering
examples based on the source mechanisms. They are not asserted to be
executable code, patent claims, published source algorithms, or
completed tests. Serialization must specify canonicalization, schema
versions, encoding profiles and sink-controlled fields before
deployment.
7.1. Canonical Candidate Act Descriptor
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
CandidateAct={act_id,source_grant_id,principal_id,
requester_id,operation_class,target_id,method,
effect_parameters_digest,resource_revision,
destination_id,recipient_id,sink_id,
coverage_epoch,policy_epoch,validity_window,
delegate_chain_id,nonce,version}
All fields affecting the consequence are canonicalized.
Do not infer exact effect scope from an OS permission alone.
Figure 17: Canonical Candidate Act Descriptor — pseudocode
7.2. Effectuation Path Coverage Record
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
Path={path_id,resource_id,interfaces,privileged_worker,
aliases,device_or_driver,can_block,controller_id,
controller_trust,topology_generation}
CoverageCommitment={graph_digest,epoch,required_paths,
blocking_proofs,attestation_refs,validity}
Monitoring-only paths are not counted as blocking coverage.
Das Expires 29 April 2027 [Page 634]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Figure 18: Effectuation Path Coverage Record — pseudocode
7.3. Coverage Discovery and Revalidation
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
DISCOVER(resource, requested_effect):
paths = enumerate_controlled_reachable_paths(resource)
for path in paths:
qualify(path.actual_effect_capability)
qualify(path.blocking_controller, path.current_generation)
require all mandatory effect routes blocked or excluded
commit protected coverage_epoch and graph_digest
on material route change: fence affected enablement
Figure 19: Coverage Discovery and Revalidation — pseudocode
7.4. Sandbox-to-Effect Boundary Check
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
ON_PRIVILEGED_REQUEST(actual_request):
observed = protected_gateway.obtain_actual_request()
require original source grant permits observed effect
require broker identity, policy, coverage and scope current
require observed target/method/body == authorized CA
require designated sink and resource current
atomic_consume_nonbearer_finality()
perform only verified effect; else refuse
Figure 20: Sandbox-to-Effect Boundary Check — pseudocode
7.5. Non-Bearer Finality Permit
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
FinalityRef={reference_id,act_digest,sink_id,
resource_id,effect_scope,source_generation,
policy_generation,coverage_generation,
nonce,expiry,consume_epoch,proof_reference}
It is not a reusable bearer authorization.
The sink verifies current protected state independently.
Das Expires 29 April 2027 [Page 635]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Figure 21: Non-Bearer Finality Permit — pseudocode
7.6. Sink-Local Atomic Effect State
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
State={sink_id,act_id,resource_revision,
grant_epoch,coverage_epoch,policy_epoch,
consumed_reference_ids,outcome_state,commit_index}
transaction:
verify current actual operation and all predicates
verify unused scoped finality ref
write CONSUMED with monotonic commit index
then release controlled effect or hold INDETERMINATE
Figure 22: Sink-Local Atomic Effect State — pseudocode
7.7. Attestation Evidence Qualification
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
APPRAISE_EVIDENCE(evidence):
require verified issuer, nonce and audience
require relevant measurement and freshness policy
require attested component is on relevant effect path
do NOT infer original principal permission
require independent actual-operation match at sink
on mismatch: withhold effect
Figure 23: Attestation Evidence Qualification — pseudocode
7.8. Protected Policy-Change Authorization
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
POLICY_CHANGE(requested_rule,actor):
represent rule update as separate CA in NES
require qualified competent meta-authority
calculate affected effect path and grant dependencies
stage new rules without premature external activation
atomically commit policy generation and fence stale CAs
revalidate dependent real effects under new policy
Das Expires 29 April 2027 [Page 636]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Figure 24: Protected Policy-Change Authorization — pseudocode
7.9. Tool Version Change and Rollback Fence
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
ON_TOOL_UPDATE(new_binary,contract):
authenticate tool source/version and schema
detect semantic changes in effectful operations
invalidate old approval/coverage if material change
require revalidated current CA and resource target
reject restored snapshot with obsolete grant generation
Figure 25: Tool Version Change and Rollback Fence — pseudocode
7.10. Independent Witness Correlation Control
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
WITNESS_SET={witness_ids,roles,trust_domains,
attested_measurements,observation_channels,
timestamps,competence_scope,dependency_graph}
Do not count two reports from one compromised origin as
independent just because they have distinct signatures.
Require observation correspondence with actual pending act.
Figure 26: Independent Witness Correlation Control — pseudocode
7.11. Protected Gate on GPU / Device Egress
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
BEFORE_HARDWARE_COMMAND(cmd):
require device command path within protected coverage
obtain actual command fields, target, destination
verify current principal/resource/privilege/scope
verify queue, DMA, firmware and device epoch as applicable
atomically consume scoped finality at controlling sink
otherwise hold or refuse the command
Figure 27: Protected Gate on GPU / Device Egress — pseudocode
Das Expires 29 April 2027 [Page 637]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
7.12. Crash, Retry and Unknown Outcome
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
ON_RECOVERY(act):
read protected sink-local consume/outcome journal
if confirmed effect: do not repeat without new authority
if unknown: qualify receiving effect or safe idempotency
if confirmed non-effect: new or preserved authority
depends on source grant and protected state
never reset consumed finality from VM rollback
Figure 28: Crash, Retry and Unknown Outcome — pseudocode
7.13. Fail-Closed Topology Update
New, non-limiting implementation sketch; test and qualify this
binding against the original described mechanism and actual
operating-system interface.
ON_TOPOLOGY_CHANGE(path,policy,firmware):
invalidate affected coverage commitment
freeze stale-scoped finality enablements
discover new paths and prove blocking capability
requalify actual resource identity and tool semantics
publish new signed coverage epoch
release only independently revalidated pending effect
Figure 29: Fail-Closed Topology Update — pseudocode
8. Threat Models: Kernel, Sandbox, Hardware, Attestation and Evidence
Attacks
The following threat models describe generic attack conditions. They
are not findings that any named product is currently exploitable or
lacks a particular documented protection. The mitigations rely on
participating blockers and the selected protected-state assumptions.
8.1. Threat 1: Prompt-injected tool command escapes intended user
effect
Attack path: Adversary controls retrieved text or tool description
and induces agent to call a privileged connector.
Proposed protected control: Reconstruct actual destination, method,
target and body under source grant and actual Finality Sink.
Das Expires 29 April 2027 [Page 638]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Residual limitation and conditions: Language-level filtering alone is
not a substitute for a controlled resource boundary.
8.2. Threat 2: Container confinement with alternate network route
Attack path: Agent is blocked on one egress proxy but can reach
equivalent receiver via IPC or another socket.
Proposed protected control: Enumerate equivalent effect paths and
require genuine blocking controls or withhold.
Residual limitation and conditions: Unknown out-of-scope routes
invalidate coverage guarantees.
8.3. Threat 3: eBPF monitor mistaken for mandatory enforcement
Attack path: Operator configures logging only and assumes a denied
consequence.
Proposed protected control: Distinguish observation from blocking and
test the actual effect boundary.
Residual limitation and conditions: Kernel observability has
instrumentation/version privileges and performance limits.
8.4. Threat 4: Mutable syscall or broker argument race
Attack path: Allowed request is inspected, then its userspace fields
change before privileged consumption.
Proposed protected control: Use protected immutable copy, sink-side
actual request obtain/reconstruct and atomic state validation.
Residual limitation and conditions: Race-free behavior depends on
concrete kernel and broker implementation.
8.5. Threat 5: Forged attestation or stale runtime measurement
Attack path: Agent replays a signed old measurement after tool or
firmware update.
Proposed protected control: Nonce, audience, freshness, policy
measurements and revalidation at actual resource boundary.
Residual limitation and conditions: Attestation root compromise
cannot be corrected by application policy alone.
Das Expires 29 April 2027 [Page 639]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
8.6. Threat 6: Sandbox-generated deployment artifact becomes effective
Attack path: Code built in isolated workspace is automatically
deployed to production without distinct authorization.
Proposed protected control: Treat deployment as new Candidate Act,
independently qualify release and actual production sink.
Residual limitation and conditions: Some CI/CD providers may not
expose sufficient final command hooks.
8.7. Threat 7: Privileged connector credential laundering
Attack path: Sandbox has no secret, but connector inserts broad
credential for mutated target.
Proposed protected control: Protected broker controls actual
credential exercise and resource-specific finality.
Residual limitation and conditions: A broad unrestricted credential
outside broker is an unprotected path.
8.8. Threat 8: Policy hot-swap broadens previously approved request
Attack path: Agent updates an allowlist, policy or controller to open
new egress after approval.
Proposed protected control: Separate meta-authority, policy-change
CA, policy generation and dependent-grant invalidation.
Residual limitation and conditions: Compromised competent
administrator may be outside selected threat model.
8.9. Threat 9: Rollback of tool or security-policy generation
Attack path: Old VM image or firmware restores previously trusted
rules and consumes stale authority.
Proposed protected control: Monotonic generation checks and sink-
local authoritative state external to restored runtime.
Residual limitation and conditions: Legacy hardware without protected
antirollback may require online enforcement.
8.10. Threat 10: GPU command queue persists after revocation
Attack path: Driver or accelerator continues queued commands although
agent permission is withdrawn.
Das Expires 29 April 2027 [Page 640]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Proposed protected control: Qualification and fencing of real command
queue and appropriate device controller before effect.
Residual limitation and conditions: Resource-native irrevocable
commands cannot always be retroactively undone.
8.11. Threat 11: DMA or peer-to-peer access bypasses host gateway
Attack path: Accelerator accesses memory or network resource through
route not governed by tool proxy.
Proposed protected control: Include DMA/memory maps, device queues,
network path attribution in selected coverage.
Residual limitation and conditions: Hardware-specific limitations
must be documented; generic sandbox alone is inadequate.
8.12. Threat 12: Witness collusion or common-mode compromise
Attack path: Two apparent independent observers copy the same forged
telemetry.
Proposed protected control: Appraise independence domains and
separate observation channels; compare actual sink effect.
Residual limitation and conditions: Witness independence cannot be
assumed from different public keys alone.
8.13. Threat 13: Resource alias and destination rebinding
Attack path: Hostname or resource ID points to a different receiver
after approval.
Proposed protected control: Bind canonical actual target and resolve
destination at final effect boundary.
Residual limitation and conditions: Cross-domain resolution may
require additional trusted resource identity services.
8.14. Threat 14: Verification exhaustion triggers permit fallback
Attack path: Attacker floods attestations or huge topology graphs to
exhaust validator.
Proposed protected control: Bound parsing and evidence verification;
fail closed and report denial.
Das Expires 29 April 2027 [Page 641]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Residual limitation and conditions: Availability may fall when
security validation cannot complete.
8.15. Threat 15: Untrusted mobile app claims global OS enforcement
Attack path: Third-party iOS/Android app presents app-scoped checks
as control of every platform effect.
Proposed protected control: State supported entitlements, actual app
resource surface and server-side participation explicitly.
Residual limitation and conditions: No app-wide system effect
guarantee without platform cooperation.
8.16. Threat 16: Crash occurs between permit consumption and outcome
Attack path: System reboots and erroneously allows duplicate
hardware/remote effect.
Proposed protected control: Protected durable consumed state and
indeterminate-outcome handling.
Residual limitation and conditions: Receiver may be unable to prove
past real effect; quarantine instead of automatic retry.
9. Technical Validation: Thirty-Six Proposed Tests, Fixtures and
Expected Security Outcomes
All tests below are proposed and have not been represented as
executed. A reproducible laboratory setup should include an
untrusted simulated agent, one or more cooperating privileged
gateways, a versioned state service, a protected Finality Sink, a
mock network/file/device effect target, a topology/policy-change
injector, mock attestation evidence and a durable effect journal.
Collect code revision, source/CA, enforcement configuration,
timestamps, before/after resource state and rejection reason for
every run.
9.1. Proposed Test PT11-01: Legitimate single bounded effect
Fixture / precondition: Valid grant, matching actual target and fully
covered gateway
Proposed procedure: Submit exactly one authorized operation
Expected accept/refuse result, not an observed outcome: Exactly one
qualified effect; protected consumption committed
Das Expires 29 April 2027 [Page 642]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.2. Proposed Test PT11-02: Prompt injection changes target
Fixture / precondition: Valid source task; malicious retrieved
instruction requests different destination
Proposed procedure: Submit changed target via tool
Expected accept/refuse result, not an observed outcome: Deny at sink
even when sandbox command is syntactically valid
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.3. Proposed Test PT11-03: Sandbox blocks direct socket but open IPC
path
Fixture / precondition: Two equivalent routes; only socket controlled
Proposed procedure: Invoke IPC bypass
Expected accept/refuse result, not an observed outcome: Withhold
until IPC has mandatory blocking coverage
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.4. Proposed Test PT11-04: Monitoring-only eBPF sensor
Fixture / precondition: Log-only path with no blocking hook
Proposed procedure: Attempt unauthorized test write
Expected accept/refuse result, not an observed outcome: Mark
uncovered; deny or refuse assurance of full enforcement
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
Das Expires 29 April 2027 [Page 643]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
9.5. Proposed Test PT11-05: Validated immutable actual request
Fixture / precondition: Agent attempts to mutate request after
provisional check
Proposed procedure: Change destination or body before privileged
broker dispatch
Expected accept/refuse result, not an observed outcome: Broker
rejects mismatched immutable/sink-observed request
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.6. Proposed Test PT11-06: Signature valid but wrong resource
Fixture / precondition: Authenticated message with resource identity
mismatch
Proposed procedure: Offer evidence for another target
Expected accept/refuse result, not an observed outcome: No finality
release
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.7. Proposed Test PT11-07: Old attestation nonce
Fixture / precondition: Previously appraised evidence with old nonce
Proposed procedure: Replay to validator
Expected accept/refuse result, not an observed outcome: Freshness
rejection; no effect
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
Das Expires 29 April 2027 [Page 644]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
9.8. Proposed Test PT11-08: Different attested software version
Fixture / precondition: Tool updates after measurement
Proposed procedure: Present old measurement
Expected accept/refuse result, not an observed outcome: Hold until
current qualifying version appraised
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.9. Proposed Test PT11-09: Nonblocking path discovered at runtime
Fixture / precondition: Live topology adds direct resource link
Proposed procedure: Submit approved CA via new path
Expected accept/refuse result, not an observed outcome: Coverage
epoch fenced; effect withheld
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.10. Proposed Test PT11-10: Source grant revoked after sandbox
approval
Fixture / precondition: Upstream approval valid earlier, revoked
before sink
Proposed procedure: Dispatch pending request
Expected accept/refuse result, not an observed outcome: Current
revocation check denies
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.11. Proposed Test PT11-11: Policy allowlist broadened by agent
Fixture / precondition: Agent lacks independent meta-authority
Das Expires 29 April 2027 [Page 645]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Proposed procedure: Try changing allow rule then egress
Expected accept/refuse result, not an observed outcome: Policy change
refused
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.12. Proposed Test PT11-12: Competent policy update with stale CA
Fixture / precondition: Authorized rule update alters semantics
Proposed procedure: Present previously permitted CA
Expected accept/refuse result, not an observed outcome: Old coverage/
generation refused until requalified
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.13. Proposed Test PT11-13: Tool binary rollback
Fixture / precondition: Old tool image restored under stale
generation
Proposed procedure: Dispatch queued effect
Expected accept/refuse result, not an observed outcome: Rollback
fence blocks unless current revalidation succeeds
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.14. Proposed Test PT11-14: Untrusted dependency reports fake outcome
Fixture / precondition: Agent supplies forged success response
Proposed procedure: Attempt causal successor
Expected accept/refuse result, not an observed outcome: Qualified
actual-effect evidence required
Das Expires 29 April 2027 [Page 646]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.15. Proposed Test PT11-15: Credential broker swaps to unrelated token
audience
Fixture / precondition: Broker holds several credentials
Proposed procedure: Dispatch to wrong audience
Expected accept/refuse result, not an observed outcome: Reject
audience/resource mismatch
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.16. Proposed Test PT11-16: Authenticated actor exceeds task grant
Fixture / precondition: Valid agent login and tool permission
Proposed procedure: Attempt oversized or wrong operation
Expected accept/refuse result, not an observed outcome: Original
source effect scope blocks
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.17. Proposed Test PT11-17: Copied non-bearer finality reference
Fixture / precondition: Reference copied to alternate sink
Proposed procedure: Reuse to second sink
Expected accept/refuse result, not an observed outcome: Refuse due to
sink binding and consumption state
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
Das Expires 29 April 2027 [Page 647]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
9.18. Proposed Test PT11-18: Duplicate single-use effect
Fixture / precondition: Two concurrent requests for same act
Proposed procedure: Race finality consume
Expected accept/refuse result, not an observed outcome: At most one
success at authoritative sink
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.19. Proposed Test PT11-19: Resource revision changes
Fixture / precondition: Target row updated between approval and
dispatch
Proposed procedure: Perform stale mutation
Expected accept/refuse result, not an observed outcome: Conditional
actual-resource match refuses
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.20. Proposed Test PT11-20: Crash after consume before ack
Fixture / precondition: Power-fault injection after commit
Proposed procedure: Retry same CA
Expected accept/refuse result, not an observed outcome: No automatic
second effect; qualify prior outcome
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.21. Proposed Test PT11-21: Kernel security-profile disables blocking
Fixture / precondition: Remove mandatory LSM/seccomp or equivalent
control
Das Expires 29 April 2027 [Page 648]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Proposed procedure: Submit effect after policy drift
Expected accept/refuse result, not an observed outcome: Coverage
invalidated; refuse covered effect
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.22. Proposed Test PT11-22: GPU command without proper gate
Fixture / precondition: Agent submits accelerator command to
unmediated queue
Proposed procedure: Attempt protected device action
Expected accept/refuse result, not an observed outcome: Declare
unsupported or fence; do not claim successful coverage
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.23. Proposed Test PT11-23: Device queue with qualified gate
Fixture / precondition: Controlled mock hardware queue
Proposed procedure: Submit authorized bounded command
Expected accept/refuse result, not an observed outcome: Only
authorized command reaches receiver
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.24. Proposed Test PT11-24: DMA alias exposes another resource
Fixture / precondition: Resource alias leads to unapproved physical
mapping
Proposed procedure: Attempt mapped effect
Expected accept/refuse result, not an observed outcome: Independent
actual-resource identity rejects
Das Expires 29 April 2027 [Page 649]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.25. Proposed Test PT11-25: Witnesses share compromised source
Fixture / precondition: Two signatures derived from single forged log
Proposed procedure: Submit duplicated evidence
Expected accept/refuse result, not an observed outcome: Independence
check declines quorum
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.26. Proposed Test PT11-26: Independent qualified witness set
Fixture / precondition: Distinct protected observer and execution-
time validator
Proposed procedure: Submit matching evidence
Expected accept/refuse result, not an observed outcome: Pass witness-
related conditions if all other predicates pass
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.27. Proposed Test PT11-27: Malformed CBOR and schema ambiguity
Fixture / precondition: Noncanonical or duplicate/conflicting keys
Proposed procedure: Submit structured authority
Expected accept/refuse result, not an observed outcome: Parse/
validate fail-closed
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
Das Expires 29 April 2027 [Page 650]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
9.28. Proposed Test PT11-28: Replay across serialization profiles
Fixture / precondition: Digest over different canonicalization
profile
Proposed procedure: Mix signed artifacts
Expected accept/refuse result, not an observed outcome: Reject
profile mismatch
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.29. Proposed Test PT11-29: Verification-budget exhaustion
Fixture / precondition: Adversary submits oversized graph/attestation
chain
Proposed procedure: Flood verifier
Expected accept/refuse result, not an observed outcome: Bound time/
memory; withhold, never auto-allow
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.30. Proposed Test PT11-30: Apple app-supported-only boundary
Fixture / precondition: App sandbox with backend-controlled resource
Proposed procedure: Run app-owned action via server
Expected accept/refuse result, not an observed outcome: Document
backend enforcement; do not assert global iOS kernel mediation
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.31. Proposed Test PT11-31: Android Binder caller identity
Fixture / precondition: Service authenticates caller but requested
effect differs
Das Expires 29 April 2027 [Page 651]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Proposed procedure: Submit unauthorized resource mutation
Expected accept/refuse result, not an observed outcome: Caller
identity not sufficient; independent source/target gate denies
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.32. Proposed Test PT11-32: Windows privileged service scope
Fixture / precondition: Restricted desktop client calls privileged
service
Proposed procedure: Request out-of-scope operation
Expected accept/refuse result, not an observed outcome: Broker
enforces actual effect, not generic process capability
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.33. Proposed Test PT11-33: Firmware update invalidates coverage
Fixture / precondition: New device firmware alters command semantics
Proposed procedure: Execute using pre-update permit
Expected accept/refuse result, not an observed outcome: Revalidate
coverage/device capability before release
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.34. Proposed Test PT11-34: Human approval for changed policy
Fixture / precondition: Authorized human approves bounded rule change
Proposed procedure: Attempt wider-than-approved effect
Expected accept/refuse result, not an observed outcome: Sink still
rejects actual excess
Das Expires 29 April 2027 [Page 652]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.35. Proposed Test PT11-35: Remote destination refused then retried
Fixture / precondition: Downstream effect status unknown on first
request
Proposed procedure: Retry with same act
Expected accept/refuse result, not an observed outcome: Do not assume
failure from timeout; reconcile resource before retry
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
9.36. Proposed Test PT11-36: Full end-to-end negative assurance
Fixture / precondition: Authorized workload attempts several bypass
routes
Proposed procedure: Exercise all in enumerated mock route graph
Expected accept/refuse result, not an observed outcome: Every
controlled route denies unauthorized effect; any unmediated route
flagged as gap
Required future run evidence: profile and OS/kernel version, original
grant, actual target/request, coverage graph and epoch, policy/tool
generation, sink-local authority/consumption record, protected
journal and before/after resource state.
10. Detailed Industry and Product Alignment: Apple, Android, AI Agents,
Hardware and Critical Resources
The following product and industry names identify concrete
engineering relevance and security problem space for engineers and
patent examiners. Alignment is hypothetical unless an identified
public product mechanism and its exact capabilities are independently
verified. No allegation of derivation, patent infringement, defect,
endorsement or adoption is made. Apple, Siri, iOS, iPadOS, macOS,
Android, Gemini, Galaxy AI, Bixby, Copilot, and other names used in
this document are trademarks of their respective owners.
Das Expires 29 April 2027 [Page 653]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.1. Apple iOS, iPadOS, App Sandbox and App Intents
Product/sector security problem: iOS and iPadOS isolate applications
and mediate supported capabilities; AI assistants may interact with
app-owned tools and third-party services.
Possible technical alignment with the source mechanisms: A
cooperating application can construct an exact Candidate Act for its
own operation, store protected metadata and enforce source/effect
scopes in a resource-side service.
Implementation qualification and non-endorsement: Ordinary third-
party apps cannot impose a global kernel policy on unrelated apps or
assume private Secure Enclave APIs.
10.2. Apple macOS, application sandbox and desktop automation
Product/sector security problem: Desktop automation can combine
permitted UI control with externally consequential file, messaging or
privileged service actions.
Possible technical alignment with the source mechanisms: Bind the
actual file/network effect at a cooperating privileged broker or
resource service, including real destination and current version.
Implementation qualification and non-endorsement: macOS sandbox
entitlement and system extension access depend on platform policy and
supported permissions.
10.3. Google Android, Binder IPC, app security and Keystore
Product/sector security problem: An Android app may invoke a service
or signed operation while the exact cloud/IPC resource target exceeds
task scope.
Possible technical alignment with the source mechanisms: Use app-
owned Binder or backend mediation and Android Keystore merely as
supporting identity/key controls while resource-side finality checks
the actual effect.
Implementation qualification and non-endorsement: Android versions,
OEM firmware and privileged service access differ; app-level controls
are not universal modem/driver gates.
Das Expires 29 April 2027 [Page 654]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.4. Microsoft Windows, kernel isolation, VBS and agent sandboxes
Product/sector security problem: Automated workloads can interact
with Windows services, containers, virtualized environments and
privileged deployment operations.
Possible technical alignment with the source mechanisms: Use
documented security isolation and a cooperating privileged service
that validates exact pending operation, policy generation and
protected grant.
Implementation qualification and non-endorsement: Hardware-backed
memory or kernel isolation does not by itself prove original task
authority for all effect-capable APIs.
10.5. Linux, seccomp, eBPF, LSM and microVM runtime
Product/sector security problem: Agents can use containers,
namespaces, kernel tracepoints, LSM policy and gateway network
controls; some hooks only observe.
Possible technical alignment with the source mechanisms: Build a
defended effectuation graph, classify actual blockers and place
checks at committed file/network/IPC sinks with controlled state.
Implementation qualification and non-endorsement: Avoid conflating
audit-only eBPF observations or mutable syscall pointer checks with
fail-closed effectuation.
10.6. OpenAI Codex and tool-execution infrastructure
Product/sector security problem: Automated code and tool calls may
modify repositories, files, networks or deployed resources.
Possible technical alignment with the source mechanisms: A separate
resource broker can hold consequential operations non-effective until
actual target/state and scoped authority are verified.
Implementation qualification and non-endorsement: No claim about
internal OpenAI implementation or guaranteed absence of equivalent
controls.
10.7. Anthropic Claude Code and sandboxed or hosted agents
Product/sector security problem: Agent-generated commands in isolated
runtime can still request external effects from available tools or
host workers.
Das Expires 29 April 2027 [Page 655]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Possible technical alignment with the source mechanisms: Pair
sandboxing with separately protected dispatch-time resource checks
and optional runtime integrity evidence.
Implementation qualification and non-endorsement: Provider-managed
infrastructure details and privileged hooks require provider
documentation.
10.8. Google Gemini, Android-connected assistants and Google Cloud
Product/sector security problem: Cross-app assistant actions and
cloud tool access create multi-domain source and resource permission
mapping problems.
Possible technical alignment with the source mechanisms: Use source-
bound canonical effect records, narrowly qualified runtime evidence
and receiving resource checks.
Implementation qualification and non-endorsement: Google product
integrations are illustrative scenarios, not verified adoption of
these mechanisms.
10.9. Meta Muse, Sentinel and credential-proxy security
Product/sector security problem: Separation of untrusted agent,
policy service and credential-use proxy raises questions about exact
effect binding and privileged route coverage.
Possible technical alignment with the source mechanisms: Study
whether an operation-specific finality record, sink verification and
protected consumption can complement existing authorization flows.
Implementation qualification and non-endorsement: Do not conflate
publicly described approval, process taint or surrogate credentials
with automatically disclosed receipt/capability architecture.
10.10. NVIDIA OpenShell, Sentry, BlueField and GPU accelerator egress
Product/sector security problem: GPU job isolation, DPU/network
policy and device command routes may carry real consequences outside
a language-model sandbox.
Possible technical alignment with the source mechanisms: Where
implementable, attribute real hardware/network command interfaces,
qualify trusted blocking and bind effect-capable dispatch to current
authority.
Das Expires 29 April 2027 [Page 656]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Implementation qualification and non-endorsement: A DPU or GPU policy
cannot guarantee remote resource finality beyond the particular
controlled path.
10.11. Qualcomm Snapdragon processors, mobile TEEs and modems
Product/sector security problem: Mobile SoC secure key and firmware
functions may protect selected credentials while applications trigger
network/device effects.
Possible technical alignment with the source mechanisms: Use
documented supported secure elements or protection as evidence inputs
and enforce real operation semantics at cooperating resource
controllers.
Implementation qualification and non-endorsement: Do not assume
universal secure monotonic clocks, modem interception or undocumented
Qualcomm interfaces.
10.12. Huawei HarmonyOS, devices and telecom controller ecosystems
Product/sector security problem: Operating-system heterogeneity and
device service abstractions complicate preserving exact effect
semantics across privileged boundaries.
Possible technical alignment with the source mechanisms: Describe
protected platform translation, current source permission and actual
sink enforcement without requiring any particular ecosystem.
Implementation qualification and non-endorsement: Publicly available
API/capability levels must be verified for a concrete deployment.
10.13. Arm TrustZone, confidential execution and protected cryptography
Product/sector security problem: TEE isolation, secure boot and non-
exportable keys can protect proof material and critical state.
Possible technical alignment with the source mechanisms: Use these as
optional substrates for authenticated evidence, state and actual sink
controls where the protected hardware enforces the selected
interface.
Implementation qualification and non-endorsement: Isolation and
attestation remain distinct from effect authorization.
Das Expires 29 April 2027 [Page 657]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.14. AWS, Azure, Google Cloud and cloud AI workload isolation
Product/sector security problem: MicroVMs, containers and API
credentials do not automatically enforce each actual infrastructure
mutation approved by a user.
Possible technical alignment with the source mechanisms: Use
cooperating API gateways/resource owners, explicit object revision
checks, independent protected grants and crash-consistent
consumption.
Implementation qualification and non-endorsement: Cloud provider
semantics differ; external services may not participate in a unified
finality transaction.
10.15. Banking, digital signing and payment infrastructure
Product/sector security problem: Valid keys and signed payment
preparation can be abused for a different beneficiary or transaction
after a sandbox-generated request.
Possible technical alignment with the source mechanisms: Constrain
actual signing and dispatch through protected credential use and
recipient/amount-specific finality at an authorized transaction
boundary.
Implementation qualification and non-endorsement: Settlement and fund
movement finality require separate domain-specific guarantees.
10.16. Telecommunications, 5G/6G, SmartNICs and network functions
Product/sector security problem: Network and edge control can include
policy updates, radio operations, command queues and privileged
control-plane effects.
Possible technical alignment with the source mechanisms: Use coverage
graphs and hardware-capable enforcement surfaces at real network
operations, current identity and configuration generation checks.
Implementation qualification and non-endorsement: A general-purpose
gateway does not govern all firmware/radio commands absent hardware
participation.
10.17. Embedded controllers, automotive and robotics
Product/sector security problem: Physical actuators may continue
scheduled commands outside the software container that proposed them.
Das Expires 29 April 2027 [Page 658]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Possible technical alignment with the source mechanisms: Use
appropriate interlocks/command gates and qualify queue state, source
authority, safety predicate and actual actuation operation.
Implementation qualification and non-endorsement: Irreversible
physical effect cannot be retroactively prevented after action;
safety engineering remains independently necessary.
10.18. Enterprise CI/CD, deployment and policy automation
Product/sector security problem: Sandboxed code-generation artifacts
may be promoted to production or change privileged policies
automatically.
Possible technical alignment with the source mechanisms: Treat
release, deployment and policy modification as separate consequential
Candidate Acts requiring competent meta-authority and final resource
control.
Implementation qualification and non-endorsement: CI/CD systems have
different API guarantees and may be partially external.
10.19. Patent examination and public prior-art discovery
Product/sector security problem: Keyword-searchable descriptions of
sandboxing and hardware security are easier to find than non-standard
private terminology alone.
Possible technical alignment with the source mechanisms: Publish
exact source page anchors and independent contrasts between identity,
attestation, isolation and enforcement.
Implementation qualification and non-endorsement: Later explanatory
diagrams and tests do not automatically share original filing
priority.
10.20. On-Device and Hybrid Assistants: Apple Siri and Apple
Intelligence, Google Gemini, Samsung Galaxy AI and Microsoft
Copilot
Product/sector security problem: Assistants increasingly run models
on the device's neural processor and send harder requests to attested
cloud environments operated by the platform vendor. On-device
execution and attested cloud nodes protect the confidentiality and
integrity of the computation, but the actions the assistant then
takes in apps and services are separate effects that the attestation
does not authorise.
Das Expires 29 April 2027 [Page 659]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Possible technical alignment with the source mechanisms: Treat the
assistant runtime's attestation as evidence about where and how the
request was processed; require the receiving app or service, as
Finality Sink, to verify the specific operation against the user's
source authority before effect. Third-party implementers can enforce
this only at their own action handlers and servers.
Technical effect: A trusted, attested assistant runtime cannot by
itself cause an unauthorised effect; each action is still checked at
the point where it takes effect (tests PT11-05, PT11-07, PT11-08,
PT11-30).
10.21. AI PCs and Neural Processing Units
Product/sector security problem: Laptops and desktops with neural
processing units run local agents that can read the screen, operate
applications and access local files. Local execution reduces data
leaving the device but places a capable agent close to sensitive
files, credentials and system settings.
Possible technical alignment with the source mechanisms: Run local
agents in a sandbox with an explicit effect-path inventory; route
file export, credential use and settings changes through a protected
broker that blocks by default; record which paths are blocked and
which are only observed.
Technical effect: Local agents can only cause covered effects through
gates that actually block, and uncovered paths are reported rather
than silently trusted (tests PT11-03, PT11-04, PT11-09).
10.22. Code-Execution Sandboxes for AI Agents: Containers, MicroVMs,
gVisor and WebAssembly
Product/sector security problem: Coding and data-analysis agents run
generated code in containers, microVMs, user-space kernels or
WebAssembly runtimes. These isolate the process, but outputs such as
files, commits, packages and network calls become effective when they
cross the boundary.
Possible technical alignment with the source mechanisms: Treat every
artefact leaving the sandbox as a Candidate Act; verify destination,
content digest and source authority at a protected egress gateway;
refuse deployment of sandbox-generated artefacts without a separate
grant.
Technical effect: Code that runs safely inside the sandbox cannot
turn its outputs into real effects without passing an exact,
authority-checked gate (tests PT11-02, PT11-03, PT11-06).
Das Expires 29 April 2027 [Page 660]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.23. Browser Sandboxes, Web Agents and Extensions
Product/sector security problem: Browser-based agents and extensions
act inside a renderer and extension sandbox, yet can submit forms,
download files and call web APIs with the user's sessions. A
compromised page or extension can steer those effects.
Possible technical alignment with the source mechanisms: Treat form
submission, download and cross-origin requests as covered effects;
verify origin, target and content at a controlled boundary such as a
cooperating gateway or receiving service.
Technical effect: Browser-originated effects are released only to the
approved origin with the approved content (tests PT11-02, PT11-35).
10.24. Confidential Computing and Attested Private AI Clouds
Product/sector security problem: Confidential virtual machines and
GPU confidential-computing modes provide attestation that code runs
in a protected environment. Attestation shows what software is
running, not whether the action it takes is authorised.
Possible technical alignment with the source mechanisms: Use
attestation results as qualified evidence of the enforcement
environment; check freshness and software version; keep operation
authorisation and Finality Sink verification separate.
Technical effect: Stale, mismatched or forged attestations are
refused, and valid attestations never substitute for operation-level
authority (tests PT11-07, PT11-08, PT11-16).
10.25. Server Baseboard Management Controllers and Out-of-Band
Management
Product/sector security problem: Infrastructure agents can manage
servers through out-of-band interfaces such as baseboard management
controllers and standard management APIs, which can power-cycle
machines, change firmware settings and mount media outside the
operating system's control.
Possible technical alignment with the source mechanisms: Treat out-
of-band management as an effect-capable path that must be inventoried
and gated; require operation-scoped authority for power, firmware and
media actions; refuse when coverage of the management path is
unverified.
Technical effect: Out-of-band management cannot be used as a bypass
for actions the in-band gate would refuse (tests PT11-09, PT11-33).
Das Expires 29 April 2027 [Page 661]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.26. Software-Defined Vehicles and Automotive Electronic Control
Units
Product/sector security problem: Vehicle functions are increasingly
controlled by software across many electronic control units connected
by in-vehicle networks, with remote services and assistants able to
request actions. Automotive cybersecurity engineering frameworks
such as ISO/SAE 21434 address risk across the lifecycle but do not by
themselves bind a specific remote request to a specific actuation.
Possible technical alignment with the source mechanisms: Place a
Finality Sink at the gateway or domain controller that verifies each
remotely requested actuation against current owner authority, vehicle
state and software generation; fence command queues on update.
Technical effect: Remote and assistant-requested vehicle actions take
effect only after verification at the vehicle's own enforcement
point, and queued commands do not survive software or authority
changes (tests PT11-10, PT11-13, PT11-23).
10.27. Medical Devices and Connected Care
Product/sector security problem: Connected medical devices accept
configuration changes and commands from apps, clinicians and cloud
services. Isolation in the device's software does not prevent an
authorised channel from carrying an unintended command.
Possible technical alignment with the source mechanisms: Verify each
configuration change and command against the authorising clinician or
patient grant and the device's current state at the device or its
controlled gateway; treat policy changes as consequential effects.
This is an engineering pattern, not a medical-device certification.
Technical effect: Device commands and configuration changes take
effect only when they match current, specific authority, and policy
changes cannot silently broaden what is allowed (tests PT11-11,
PT11-12, PT11-34).
10.28. Industrial Control Systems and Operational Technology
Product/sector security problem: Programmable logic controllers and
industrial systems are increasingly reachable by engineering tools
and AI assistants. Industrial security frameworks such as IEC 62443
define zones and conduits, but a permitted conduit can still carry an
unintended write to a controller.
Das Expires 29 April 2027 [Page 662]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Possible technical alignment with the source mechanisms: Gate writes
to controllers at the conduit boundary with operation-scoped
authority bound to the target controller and register or function;
distinguish monitoring taps from enforcing gateways.
Technical effect: Controller writes pass only through enforcing
gateways that verify the exact target and value, and monitoring-only
sensors are not counted as protection (tests PT11-04, PT11-06,
PT11-19).
10.29. Drones, Robotics and Physical Actuators
Product/sector security problem: Robots and drones execute commands
generated by planners and AI models. Firmware updates, command
queues and peripheral buses can carry effects that bypass a host-
level policy.
Possible technical alignment with the source mechanisms: Place the
final gate in the motion controller or flight controller where
possible; fence queues on revocation and firmware change; verify
commands against current mission authority.
Technical effect: Physical actions are released only by the
controller that can actually stop them, and revoked or outdated
commands are not executed (tests PT11-10, PT11-22, PT11-23, PT11-33).
10.30. Satellite Command and Ground-Segment Security
Product/sector security problem: Satellite operations depend on
ground systems that issue commands to spacecraft and manage user
terminals; incidents affecting satellite networks have shown that a
compromise of management infrastructure can disable many terminals at
once.
Possible technical alignment with the source mechanisms: Treat
command uplink and terminal management actions as consequential
effects requiring operation-scoped authority at the command gateway;
require independent witnesses for high-impact commands; fence command
queues on authority change.
Technical effect: High-impact commands to spacecraft and terminal
fleets require exact, current authority and independent qualification
at the enforcement boundary, limiting the effect of a compromised
management system (tests PT11-25, PT11-26, PT11-36).
Das Expires 29 April 2027 [Page 663]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
10.31. Summary of Technical Effects Across Industries
The following technical effects are the design objectives of the
kernel, sandbox and hardware mechanisms in this Part. They are
stated as testable properties linked to the proposed PT11-01 to
PT11-36 tests; no measured results are claimed in this revision.
1. Exact effect release: a legitimate bounded effect succeeds, and
a prompt-injected target change is refused (PT11-01, PT11-02).
2. Blocking, not observing: open alternate paths and monitoring-
only sensors are detected and not counted as enforcement,
including paths discovered at runtime and kernel profiles that
disable blocking (PT11-03, PT11-04, PT11-09, PT11-21).
3. Immutable actual request: the operation released is the one
validated, and a valid signature on the wrong resource is
refused (PT11-05, PT11-06).
4. Attestation as evidence only: stale or mismatched attestations
are refused, and authenticated actors cannot exceed their task
grant (PT11-07, PT11-08, PT11-16).
5. Current authority: revocation after sandbox approval stops the
effect (PT11-10).
6. Protected policy and runtime generations: agent-broadened
policies, stale approvals after policy change and tool rollbacks
are refused, and changed policies require human approval where
specified (PT11-11 to PT11-13, PT11-34).
7. Trustworthy outcomes and credentials: fake dependency outcomes
and credential-audience swaps are rejected (PT11-14, PT11-15).
8. Single use and crash safety: copied references and duplicates
are refused, revisions are checked, and crashes do not resurrect
authority (PT11-17 to PT11-20).
9. Hardware command control: ungated GPU commands and DMA aliases
are refused, gated device queues work, and firmware updates
invalidate stale coverage (PT11-22 to PT11-24, PT11-33).
10. Witness independence: witnesses sharing a compromised source are
not counted as independent (PT11-25, PT11-26).
11. Parser and verification robustness: malformed encodings, cross-
profile replay and verification exhaustion fail closed (PT11-27
to PT11-29).
Das Expires 29 April 2027 [Page 664]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
12. Honest platform boundaries: Apple, Android Binder and Windows
privileged-service integrations operate within documented
capabilities (PT11-30 to PT11-32).
13. Retry discipline and end-to-end assurance: refused destinations
are not retried without new authority, and the full negative-
assurance scenario holds (PT11-35, PT11-36).
11. Detailed IETF Working-Group Relevance, Existing RFCs and Distinct
Effectuation Requirements
Existing RFCs and active working-group work provide concrete
interoperable identity, authorization, attestation, software-update,
cryptographic and resource semantics. This draft does not claim they
fail at their chartered objectives: it asks a separate operation-
specific effectuation question. Working-group status is based on the
October 2026 available charter record. SECDISPATCH concluded in
August 2026; new security-area discussion may be routed through
DISPATCH subject to its charter and IESG processes.
11.1. RATS — Remote ATtestation procedureS, RFC 9334
Primary references: [RATS-CHARTER], [RFC9334].
Established working group/RFC mechanism and proper scope: RATS
defines Attester, Verifier, Relying Party, Evidence, Endorsements,
reference values and attestation-result processes for appraising
trustworthy device/software state.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Use appraised runtime/device measurements
as one protected predicate in finality. Attestation of a process
does not itself establish the user-authorized target, method, effect
content, sink coverage or protected single-use resource mutation.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/rats/about/
11.2. TEEP — Trusted Execution Environment Provisioning
Primary references: [TEEP-CHARTER], [RFC9397].
Established working group/RFC mechanism and proper scope: TEEP
concerns lifecycle management and provisioning of trusted
applications within supported TEEs, including authenticated software
operations.
Das Expires 29 April 2027 [Page 665]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Integrate trusted-app lifecycle, install
and rollback evidence into effectuation coverage generation, while
independently authorizing each actual real-world consequence the
application attempts.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/teep/about/
11.3. SUIT — Software Updates for Internet of Things
Primary references: [SUIT-CHARTER], [RFC9019].
Established working group/RFC mechanism and proper scope: SUIT
defines architecture, metadata and manifest-related mechanisms for
secure firmware/software updates on constrained devices.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: A signed update provenance or manifest can
qualify installed code; changing software/hardware command semantics
can still invalidate earlier finality and require new sink-side
verification.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/suit/about/
11.4. ACE — Authentication and Authorization for Constrained
Environments, RFC 9200
Primary references: [ACE-CHARTER], [RFC9200].
Established working group/RFC mechanism and proper scope: ACE applies
OAuth-inspired access authorization to constrained resource servers
and suitable communications profiles, including connected devices.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Use ACE identity/permission artifacts as
bounded source-grant evidence and require actual actuator/resource
command correspondence and current consumption at a covered sink.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/ace/about/
11.5. COSE and CBOR — RFCs 8949 and 9052
Primary references: [RFC8949], [RFC9052].
Das Expires 29 April 2027 [Page 666]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Established working group/RFC mechanism and proper scope: CBOR
supplies structured compact representation; COSE protects integrity
and authenticity of CBOR objects and supports cryptographic key
representations.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Encode CA, evidence and sink-finality
reference under a declared deterministic profile and appropriate COSE
protection; signature validity alone does not authorize a different
real effect.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/cose/about/
11.6. OAuth — Rich Authorization Requests RFC 9396, DPoP RFC 9449 and
Token Exchange RFC 8693
Primary references: [RFC6749], [RFC9396], [RFC9449], [RFC8693].
Established working group/RFC mechanism and proper scope: OAuth
supplies structured authorization details, sender-constrained token
demonstrations and delegated token-exchange profiles.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Map resource/operation fields to limited
source authority while retaining separate actual effect-time
reconstruction, state, scope and single-use finality predicates.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/oauth/about/
11.7. WIMSE — Workload Identity in Multi System Environments
Primary references: [WIMSE-CHARTER].
Established working group/RFC mechanism and proper scope: WIMSE
studies workload identity and authorization context across service
boundaries, with an explicit HTTP/REST focus in its charter.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Bind originating workload identity and
transaction context to a narrower actual-effect descriptor; the
resource sink must still check effect-specific authority, policy
generation and coverage.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/wimse/about/
Das Expires 29 April 2027 [Page 667]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
11.8. HTTPBIS / HTTP Semantics — RFC 9110
Primary references: [RFC9110].
Established working group/RFC mechanism and proper scope: HTTP
method, target URI, representation and conditional request semantics
may help identify material resource-operation parameters.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: A gateway can observe the actual request
and bind appropriate fields to CA/FS but must revalidate redirects
and semantics under the actual receiving resource.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/httpbis/about/
11.9. SCITT — Supply Chain Integrity, Transparency and Trust
Primary references: [SCITT].
Established working group/RFC mechanism and proper scope: SCITT work
addresses transparent statements and associated evidence;
transparency may aid provenance and accountability.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Signed or transparent software statements
may be inputs to runtime qualification, but transparency alone is not
an actual effect gate or source authorization.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/scitt/about/
11.10. NETCONF — Network Configuration Protocol, RFC 6241
Primary references: [RFC6241].
Established working group/RFC mechanism and proper scope: NETCONF
operations and configuration state provide defined network-management
interfaces and edit transactions under participating controllers.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Protected change management can bind exact
intended configuration differences to independent policy-generation
and actual deployment checks.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/netconf/about/
Das Expires 29 April 2027 [Page 668]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
11.11. ANIMA — Autonomic Networking Integrated Model and Approach
Established working group/RFC mechanism and proper scope: ANIMA
explores autonomic network infrastructure and secure automated
management interactions.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Autonomous policy controllers can reuse
authenticated management identity while applying source-authorized
effect-specific control at actual network operations.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/anima/about/
11.12. OPS Area / OPSAWG Operational Observability
Established working group/RFC mechanism and proper scope: Operations
work addresses manageability and telemetry; metrics can observe
critical effects and policy drift.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: Monitoring/telemetry cannot be counted as
mandatory prevention unless a qualified receiving sink has explicit
ability to block the effect.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/opsawg/about/
11.13. DISPATCH — Security-area proposal routing after SECDISPATCH
conclusion
Primary references: [DISPATCH-CHARTER].
Established working group/RFC mechanism and proper scope: SECDISPATCH
concluded in August 2026 and new-topic discussion is routed through
the applicable DISPATCH procedures.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: This twelve-part series is an
informational technical disclosure; any standards-track proposal
would require a separate bounded problem statement and explicit
charter/scope evaluation.
Working group or normative reference entry:
https://datatracker.ietf.org/wg/dispatch/about/
Das Expires 29 April 2027 [Page 669]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
11.14. BCP 79 — RFC 8179 IETF IPR disclosure duties
Primary references: [RFC8179].
Established working group/RFC mechanism and proper scope: RFC 8179
governs identification/disclosure of relevant IPR in IETF work and is
distinct from a patent bibliography or claim of priority.
Specific relationship to the Part 11 disclosure and possible
interoperability boundary: The dedicated IPR note is not a substitute
for separately submitted, timely official IETF disclosure
information.
Working group or normative reference entry: https://www.rfc-
editor.org/rfc/rfc8179.html
12. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Das Expires 29 April 2027 [Page 670]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
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 Considerations: Failure Conditions, Trust Assumptions and
Residual Risks
13.1. Enforcement is real blocking, not telemetry
Proving that a privileged action was observed is not proving it could
have been stopped. A mandatory coverage claim requires a concrete
participating last-resort blocker.
13.2. All covered equivalent routes must be considered
Alternate resource aliases, credential paths, device/driver queues,
direct connections and privileged workers may invalidate enforcement-
topology assumptions.
13.3. User and source authority is distinct from runtime integrity
Trusted boot or attestation does not necessarily prove permission for
the exact financial, disclosure, deployment or device operation.
Das Expires 29 April 2027 [Page 671]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
13.4. Platform privilege claims must be bounded
Ordinary Apple and Android apps cannot claim blanket interception of
unrelated app effects, kernel operations, firmware or hardware
queues.
13.5. Protected state must be authoritative
Revocation, permission versions, coverage generations and consumed
references must resist tampering, replay and restoration from
untrusted snapshots under the specified model.
13.6. Policy changes are themselves consequences
A permission rule update requires competent meta-authority and may
invalidate previously issued finality for related operations.
13.7. External effects may be irreversible
After a real device command, payment or external transmission, denial
of a later retry cannot retroactively undo the original effect.
13.8. Unknown outcome is not failed outcome
Lost dispatch acknowledgment is not evidence of non-effectuation.
Protected recovery must avoid unauthorized duplicates.
13.9. Evidence provenance and witness independence
Correlated or compromised witnesses must not be treated as
independent confirmation solely because signatures differ.
13.10. Compromise of the Finality Sink is within selected trust limits
Guarantees depend on continued integrity of the chosen protected
resource, kernel/driver/TEE component, signing keys and effect path.
13.11. Canonicalization and parser mismatch
Differing JSON/CBOR interpretations and alias resolution create
authorization confusion; both sides must enforce the same canonical
operation representation.
13.12. Verification exhaustion and denial-of-service
Work bounds and safe refusal preserve safety but may reduce
availability; implementations must avoid permissive fallback under
CPU/memory exhaustion.
Das Expires 29 April 2027 [Page 672]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
13.13. Privacy of telemetry and evidence
Operation and platform evidence can expose sensitive identifiers,
endpoints, code versions and user data; minimize, restrict and
protect traces.
13.14. Firmware and DMA command fences are platform-specific
Kernel/user-space control cannot automatically prevent an independent
hardware controller or radio firmware path outside actual coverage.
13.15. Scope of IETF standards
Use existing identity, attestation and cryptographic standards for
the properties they specify; do not claim they are designed as
universal consequence-enforcement protocols.
13.16. Publication chronology and patent support
Source pages from the later compiled PDF, early PCT filing text,
newly authored implementation sketches, prospective tests and
eventual GitHub commits may have different dates and evidentiary
status.
14. Patent-Examiner and Engineer Discovery: Original Source Page and
Figure Index
Source Foundation: Cross-Platform Native Permissions and Independent
Consequence Authority: original global source pages 1–14; page
anchors platform-page-<global_page>; figures fig-platform-
architecture and fig-platform-flowchart; original file TECHNICAL
SPECIFICATION -1-554.pdf.
Miscellaneous Embodiment M-1: Dynamic Enforcement-Path and Hardware
Resource Coverage: original global source pages 555–609; page anchors
m1-page-<global_page>; figures fig-m1-architecture and fig-
m1-flowchart; original file TECHNICAL SPECIFICATION -555-1062.pdf.
Embodiment 14: Effectuation-Path Discovery, Runtime Bypass Detection
and Hardware Attribution: original global source pages 1222–1308;
page anchors emb14-page-<global_page>; figures fig-emb14-architecture
and fig-emb14-flowchart; original file TECHNICAL SPECIFICATION
-1063-1541.pdf.
Miscellaneous Embodiment M-2: Existing Standards, Kernel, Sandbox and
Hardware Integration: original global source pages 1898–1952; page
anchors m2-page-<global_page>; figures fig-m2-architecture and fig-
m2-flowchart; original file TECHNICAL SPECIFICATION -1542-2011.pdf.
Das Expires 29 April 2027 [Page 673]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Embodiment 25: Sandbox-to-Privileged-Effect Transition and Non-
Bypassable Credential/Network Control: original global source pages
2092–2168; page anchors emb25-page-<global_page>; figures fig-
emb25-architecture and fig-emb25-flowchart; original file TECHNICAL
SPECIFICATION -2012-2566.pdf.
Embodiment 26: Tool Runtime Installation, Upgrade, Rollback and
Generation-Safe Effectuation: original global source pages 2169–2245;
page anchors emb26-page-<global_page>; figures fig-emb26-architecture
and fig-emb26-flowchart; original file TECHNICAL SPECIFICATION
-2012-2566.pdf.
Embodiment 33: Protected Security-Policy Mutation and Configuration-
Change Enforcement: original global source pages 2826–2913; page
anchors emb33-page-<global_page>; figures fig-emb33-architecture and
fig-emb33-flowchart; original file TECHNICAL SPECIFICATION
-2567-3101.pdf.
Embodiment 38: Independent Witness, Attestation and Evidence-
Qualification Enforcement: original global source pages 3282–3378;
page anchors emb38-page-<global_page>; figures fig-emb38-architecture
and fig-emb38-flowchart; original file TECHNICAL SPECIFICATION
-3102-3567.pdf.
Search by mechanism: live effect-path graph and hardware attribution
(M-1, Embodiment 14); reusable standards/OS/hardware verification
inputs (M-2); sandboxed-to-privileged effect and credential gate
(Embodiment 25); runtime and tool installation/rollback (Embodiment
26); policy mutation and enforcement generation (Embodiment 33);
independent witness, attestation and two-instance evidence
(Embodiment 38). Part 1 defines common terminology; Part 4 addresses
sink anti-bypass; Parts 7 and 9 cover tool and credential-specific
variants; Part 12 covers infrastructure-wide composition.
All original global page references are editorial indexes to the
attached seven-part 3,567-page source; new reference test cases,
algorithms and illustrations have their own date of authorship and
are not asserted to have appeared in the original June 2026
application.
15. Foundational and Eleven-Part Companion Internet-Draft Cross-
References
Part 1 of 12 — Foundational Protected Consequential Authority,
Definitions, CW-1/CW-2/CW-3: [DAS-FOUNDATION]
Part 2 of 12 — Apple iOS, Android and Cross-Platform AI Tool
Interoperability: [DAS-INTEROP]
Das Expires 29 April 2027 [Page 674]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
Part 3 of 12 — Protected Source Authority, Cross-Committed Validation
Evidence and Non-Bearer Finality: [DAS-EVIDENCE]
Part 4 of 12 — Actual-Operation Reconstruction, Finality Sink
Enforcement and Anti-Bypass: [DAS-SINK]
Part 5 of 12 — Multi-Agent Delegation, Quorums and Concurrent
Authority: [DAS-MULTIAGENT]
Part 6 of 12 — Actual-Effect Receipts and Protected Causal
Continuation: [DAS-RECEIPTS]
Part 7 of 12 — AI Tool Integrity, Resource Identity and Execution-
Time Semantics: [DAS-TOOLS]
Part 8 of 12 — Cross-Domain Effects, Transactions, Irreversibility
and Recovery: [DAS-RECOVERY]
Part 9 of 12 — Credential Custody, Operation-Bound Secrets and
Protected Data Disclosure: [DAS-PRIVACY]
Part 10 of 12 — Device Authority Continuity, Revocation and Offline
Execution: [DAS-REVOCATION]
Part 12 of 12 — Autonomous Cloud, Telecommunications, Policy and
Critical Infrastructure Finality: [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 675]
Internet-Draft Execution-Finality Part 11: Hardware 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-TOOLS]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 7: AI Tool Integrity,
Semantic Target Correspondence, and Execution-Time
Resource Identity", Work in Progress, Internet-Draft,
draft-das-agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
Das Expires 29 April 2027 [Page 676]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 8: Distributed Effect
Verification, Protected Recovery, and Multi-Resource
Finality", Work in Progress, Internet-Draft, draft-das-
distributed-effect-recovery-00,
<https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/>.
[DAS-PRIVACY]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 9: Credential Custody,
Operation-Bound Secret Use, and Protected Data
Disclosure", 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 for iOS, Android,
and Cross-Platform AI Agents, Part 10: Cross-Device
Authority Continuity, Revocation Fencing, and Offline
Execution", Work in Progress, Internet-Draft, draft-das-
cross-device-authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 12 of 12 — Autonomous
Cloud, Telecommunications, Policy and Critical
Infrastructure Finality", 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 677]
Internet-Draft Execution-Finality Part 11: Hardware 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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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 678]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[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>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RATS-CHARTER]
Internet Engineering Task Force, "Remote ATtestation
ProcedureS (rats) Working Group",
<https://datatracker.ietf.org/wg/rats/about/>.
[WIMSE-CHARTER]
Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SUIT-CHARTER]
Internet Engineering Task Force, "Software Updates for
Internet of Things (suit) Working Group",
<https://datatracker.ietf.org/wg/suit/about/>.
[TEEP-CHARTER]
Internet Engineering Task Force, "Trusted Execution
Environment Provisioning (teep) Working Group",
<https://datatracker.ietf.org/wg/teep/about/>.
[ACE-CHARTER]
Internet Engineering Task Force, "Authentication and
Authorization for Constrained Environments (ace) Working
Group", <https://datatracker.ietf.org/wg/ace/about/>.
[DISPATCH-CHARTER]
Internet Engineering Task Force, "Dispatch (dispatch)
Working Group",
<https://datatracker.ietf.org/wg/dispatch/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
Das Expires 29 April 2027 [Page 679]
Internet-Draft Execution-Finality Part 11: Hardware October 2026
[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 680]