Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 2: Secure iOS and Android AI Tool Interoperability
draft-das-cross-platform-ai-interoperability-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-cross-platform-ai-interoperability-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 2: Secure iOS and Android AI Tool Interoperability
draft-das-cross-platform-ai-interoperability-00
Abstract
AI assistants and third-party AI tools now act across the Apple and
Google ecosystems. Apple Siri invokes app actions through App
Intents and Shortcuts, Google Gemini acts through Android intents and
app integrations, and agents from many vendors reach the same
accounts from iOS, iPadOS, macOS, Android, Windows, Linux, cloud
APIs, and connected devices. Each hop crosses a different
permission, sandbox, credential, identity, and hardware trust model.
A prompt-injected, replayed, or redirected tool call can then export
a file, send a payment, change data, or operate a device in a way
that differs from what the user approved, and app permissions,
Keychain or Android Keystore credentials, and OAuth tokens do not by
themselves prove that the executed operation matches the approved
one.
This document, Part 2 of a twelve-part series, specifies how to carry
authority across platforms without letting a platform permission
become final authority. Platform-specific adapters for iOS and
Android translate qualified app, user, device, and key evidence into
a protected canonical effect descriptor; the AI tool's proposed
action remains non-effective; operation-scoped, non-bearer
authorization resists replay and redirection; and the receiving
Finality Sink independently reconstructs the actual pending
operation, checks resource identity, aliases, and redirects, fences
stale devices after cross-device handoff, and fails closed on any
mismatch. Reference data models, pseudocode, a state machine, six
threat models, and twenty reproducible validation tests 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 2: iOS/Android October 2026
The document relates these mechanisms to OAuth 2.0 Rich Authorization
Requests and Demonstrating Proof of Possession (DPoP); Workload
Identity in Multi-System Environments (WIMSE); Remote ATtestation
procedureS (RATS); CBOR Object Signing and Encryption (COSE);
Authentication and Authorization for Constrained Environments (ACE);
Supply Chain Integrity, Transparency, and Trust (SCITT); and HTTP
redirection and conditional requests. It identifies discussion
points for these groups and for Security Area dispatch, without
claiming working-group adoption or IETF consensus.
Industry alignment covers Apple iOS, iPadOS, and macOS with Siri, App
Intents, and Shortcuts; Google Android with Intents, Binder, and
Android Keystore; Google Gemini; Samsung Bixby; Microsoft Windows and
Azure agent governance; agent platforms from OpenAI, Anthropic, and
Meta; NVIDIA, Qualcomm, Arm, and Huawei hardware; and payments,
telecommunications, and robotics. Product names are illustrative and
imply no endorsement or implementation by any vendor. For the EU
Artificial Intelligence Act (Regulation (EU) 2024/1689), operation-
level evidence and fail-closed cross-platform enforcement can help
providers and deployers address risk-management, record-keeping,
human-oversight, and robustness and cybersecurity requirements where
those obligations apply; this is a technical mapping, not a
conformity claim or legal advice.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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: Part 2, Mobile Security Problem Space, and
Twelve-Part Series . . . . . . . . . . . . . . . . . . . 6
1.1. Complete Series Directory, Planned Names, and
Cross-References . . . . . . . . . . . . . . . . . . . . 7
1.1.1. Part 1 of 12:
draft-das-interoperable-consequence-authority . . . . 8
1.1.2. Part 2 of 12:
draft-das-cross-platform-ai-interoperability . . . . 8
1.1.3. Part 3 of 12:
draft-das-protected-authority-evidence . . . . . . . 8
1.1.4. Part 4 of 12: draft-das-finality-sink-enforcement . . 8
1.1.5. Part 5 of 12:
draft-das-multi-agent-authority-control . . . . . . . 9
1.1.6. Part 6 of 12: draft-das-causal-effect-receipts . . . 9
1.1.7. Part 7 of 12: draft-das-agent-tool-integrity . . . . 9
1.1.8. Part 8 of 12:
draft-das-distributed-effect-recovery . . . . . . . . 9
1.1.9. Part 9 of 12: draft-das-agent-credential-privacy . . 10
1.1.10. Part 10 of 12:
draft-das-cross-device-authority-revocation . . . . . 10
1.1.11. Part 11 of 12:
draft-das-hardware-execution-finality . . . . . . . . 10
1.1.12. Part 12 of 12:
draft-das-autonomous-infrastructure-finality . . . . 11
2. Intellectual Property Rights, Foundational Filing, and
Forthcoming GitHub Reference Implementation . . . . . . . 11
3. Keywords and Search Discovery Index . . . . . . . . . . . . . 12
4. Scope, Traceability, and Relationship to the Original
Disclosure . . . . . . . . . . . . . . . . . . . . . . . 13
5. Local Terminology with Foundational Reference . . . . . . . . 13
6. Cross-Platform Authority Translation and Consequence
Enforcement . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Protected Trust Boundaries and the Cross-Platform
Translation Path . . . . . . . . . . . . . . . . . . . . 14
6.2. Per-Operation Interoperability Decision Flow . . . . . . 15
6.3. Cross-Platform Acceptance and Refusal Conditions . . . . 16
7. PHOSITA Implementation Using Existing Software,
Operating-System Security, and Standard Protocols . . . . 17
7.1. Apple iOS / iPadOS / macOS Adapter . . . . . . . . . . . 17
7.2. Android Adapter, Intents, Binder, Keystore . . . . . . . 18
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
7.3. Protected Gateway and Credential Custody . . . . . . . . 18
7.4. Canonicalization and Semantic Equality . . . . . . . . . 18
7.5. Database and Protected Consumption . . . . . . . . . . . 18
7.6. Cross-Device and Runtime Migration . . . . . . . . . . . 19
7.7. Actual Resource Identity Enforcement . . . . . . . . . . 19
7.8. Effectuation Coverage and Limits . . . . . . . . . . . . 19
7.9. Logs and Evidence . . . . . . . . . . . . . . . . . . . . 19
7.10. Recovery and Failure Semantics . . . . . . . . . . . . . 19
8. Reference Interfaces, Data Models, Algorithms, and State
Transitions . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Illustrative Candidate Act and Canonical Effect
Descriptor . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Protected Platform Translation and Qualification
Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 20
8.3. Receiver Finality Sink Independent Dispatch Pseudocode . 21
8.4. Source-Fenced Device Ownership Transition Pseudocode . . 21
8.5. Protected Identity Binding and Redirect Handling . . . . 21
8.6. Reference State Machine and Failure Semantics . . . . . . 22
9. Source-Grounded Interoperability Embodiments and Supplementary
Technical Disclosures . . . . . . . . . . . . . . . . . . 22
9.1. Original Cross-Platform Invention: Interoperability,
Authority Continuity and Platform Evidence . . . . . . . 22
9.1.1. Architecture Diagram and Protected Components . . . . 22
9.1.2. Operational Flowchart and Fail-Closed Branches . . . 23
9.1.3. Page-Indexed Source-Derived Technical Detail . . . . 23
9.2. Miscellaneous Embodiment M-1: Modular Enforcement Coverage
and Cross-Interface Portability . . . . . . . . . . . . . 42
9.2.1. Architecture Diagram and Protected Components . . . . 42
9.2.2. Operational Flowchart and Fail-Closed Branches . . . 42
9.2.3. Page-Indexed Source-Derived Technical Detail . . . . 42
9.3. Miscellaneous Embodiment M-2: Standards-Interoperable
Platform-Independent Finality Constitution . . . . . . . 110
9.3.1. Architecture Diagram and Protected Components . . . . 110
9.3.2. Operational Flowchart and Fail-Closed Branches . . . 111
9.3.3. Page-Indexed Source-Derived Technical Detail . . . . 111
9.4. Embodiment 9: Cross-Device Authority Ownership and Source
Fencing . . . . . . . . . . . . . . . . . . . . . . . . . 178
9.4.1. Architecture Diagram and Protected Components . . . . 178
9.4.2. Operational Flowchart and Fail-Closed Branches . . . 179
9.4.3. Page-Indexed Source-Derived Technical Detail . . . . 179
9.5. Embodiment 21: Cross-Platform Resource Identity and Alias
Resolution . . . . . . . . . . . . . . . . . . . . . . . 250
9.5.1. Architecture Diagram and Protected Components . . . . 250
9.5.2. Operational Flowchart and Fail-Closed Branches . . . 250
9.5.3. Page-Indexed Source-Derived Technical Detail . . . . 251
9.6. Embodiment 27: Cross-Domain Agent Handoff and
Non-Resurrectable In-Flight Effects . . . . . . . . . . . 338
9.6.1. Architecture Diagram and Protected Components . . . . 338
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.6.2. Operational Flowchart and Fail-Closed Branches . . . 338
9.6.3. Page-Indexed Source-Derived Technical Detail . . . . 339
10. Threat Models and Security Assumptions . . . . . . . . . . . 414
10.1. TM-1: Prompt Injection into AI Agent Tool Selection . . 414
10.2. TM-2: Replay, Clone and Stale Authority . . . . . . . . 415
10.3. TM-3: Bypass through Alternative Effectuation Paths . . 415
10.4. TM-4: Forged, Stale or Mismatched Evidence . . . . . . . 416
10.5. TM-5: Scope Escalation during OS Translation . . . . . . 416
10.6. TM-6: Compromised Connector, Device or Infrastructure . 416
11. Proposed Technical Validation Plan: Twenty Reproducible
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 417
11.1. T01: Authorized iOS-to-Android API operation . . . . . . 417
11.2. T02: Prompt injection recipient substitution . . . . . . 417
11.3. T03: Platform permission to effect-scope confusion . . . 418
11.4. T04: Replay finality reference . . . . . . . . . . . . . 418
11.5. T05: Content-hash mutation after approval . . . . . . . 418
11.6. T06: Direct socket bypass . . . . . . . . . . . . . . . 419
11.7. T07: Expired platform evidence . . . . . . . . . . . . . 419
11.8. T08: Old device owner after handoff . . . . . . . . . . 419
11.9. T09: Cross-platform privilege amplification . . . . . . 419
11.10. T10: Redirect to alternate host . . . . . . . . . . . . 420
11.11. T11: Symlink or resource alias swap . . . . . . . . . . 420
11.12. T12: Clone/rollback of destination runtime . . . . . . . 420
11.13. T13: Compromised source agent token misuse . . . . . . . 421
11.14. T14: Unattestable privileged connector . . . . . . . . . 421
11.15. T15: CW-3 scope-deviation reapproval . . . . . . . . . . 421
11.16. T16: Missing effectuation-path coverage . . . . . . . . 422
11.17. T17: Out-of-order causal continuation . . . . . . . . . 422
11.18. T18: Crash after protected consumption . . . . . . . . . 422
11.19. T19: Partitioned device migration . . . . . . . . . . . 423
11.20. T20: Correct valid multi-platform deployment . . . . . . 423
12. Detailed Industry and Product Alignment: Engineering Problem,
Integration Surface, and Limitations . . . . . . . . . . 423
12.1. Apple iOS, iPadOS, macOS, Siri, App Intents,
Shortcuts . . . . . . . . . . . . . . . . . . . . . . . 424
12.2. Google Android, Android Keystore, Intents and Binder . . 424
12.3. Microsoft Windows, Azure, agent governance and enterprise
connectors . . . . . . . . . . . . . . . . . . . . . . 424
12.4. Google Gemini, Google Cloud and cross-application
orchestration . . . . . . . . . . . . . . . . . . . . . 425
12.5. OpenAI Agents SDK, Responses API, Codex and computer
use . . . . . . . . . . . . . . . . . . . . . . . . . . 425
12.6. Anthropic Claude and Claude Code / Managed Agents . . . 425
12.7. Meta Muse/Sentinel and autonomous agent egress
security . . . . . . . . . . . . . . . . . . . . . . . 425
12.8. NVIDIA OpenShell / Sentry, accelerated and DPU
enforcement . . . . . . . . . . . . . . . . . . . . . . 426
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
12.9. Qualcomm Snapdragon, Arm TrustZone, Huawei mobile
platforms . . . . . . . . . . . . . . . . . . . . . . . 426
12.10. Banking, payments, wallets and financial transaction
APIs . . . . . . . . . . . . . . . . . . . . . . . . . 426
12.11. Telecommunications, 5G/6G, edge devices and IoT . . . . 427
12.12. Robotics, vehicles, industrial automation and connected
devices . . . . . . . . . . . . . . . . . . . . . . . . 427
12.13. Samsung Bixby, Amazon Alexa, and Assistant-to-App Handoff
Across Ecosystems . . . . . . . . . . . . . . . . . . . 427
13. Detailed Relevance to IETF Working Groups, RFCs, and Standards
Interoperability . . . . . . . . . . . . . . . . . . . . 428
13.1. OAuth WG: Rich Authorization, Sender Constraints and Agent
Delegation . . . . . . . . . . . . . . . . . . . . . . . 428
13.2. WIMSE WG: Workload Identity in Multi-System
Environments . . . . . . . . . . . . . . . . . . . . . . 428
13.3. RATS WG: Remote Attestation and Evidence Appraisal . . . 429
13.4. COSE WG and CBOR: Signed and Interoperable Protected
Objects . . . . . . . . . . . . . . . . . . . . . . . . 429
13.5. ACE WG: Constrained Authorization for Mobile/Embedded
Resources . . . . . . . . . . . . . . . . . . . . . . . 429
13.6. SCITT WG: Signed Statements and Transparency for Supply
Chain Context . . . . . . . . . . . . . . . . . . . . . 430
13.7. HTTP / HTTPBIS: Request Identity, Conditional Operations
and Redirection . . . . . . . . . . . . . . . . . . . . 430
13.8. Security Area / SEC-DISPATCH and Cross-WG Review . . . . 431
14. Relevance to the EU Artificial Intelligence Act . . . . . . . 431
15. Security, Privacy, Deployment, and IANA Considerations . . . 432
15.1. Trust Boundaries . . . . . . . . . . . . . . . . . . . . 432
15.2. Freshness and Revocation . . . . . . . . . . . . . . . . 432
15.3. Data and Credential Privacy . . . . . . . . . . . . . . 433
15.4. Canonicalization and Ambiguity . . . . . . . . . . . . . 433
15.5. Crash Consistency and External Effects . . . . . . . . . 433
15.6. Denial of Service and Availability . . . . . . . . . . . 433
15.7. IANA Considerations . . . . . . . . . . . . . . . . . . 433
16. Source Coverage and Discoverability Cross-Index . . . . . . . 433
17. Cross-Reference Resolution and Submission Notice . . . . . . 435
18. Informative References and Planned Companion Documents . . . 435
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 439
1. Introduction: Part 2, Mobile Security Problem Space, and Twelve-Part
Series
This Part 2 is a long-form public technical disclosure addressed to
patent examiners, Apple iOS and Android engineers, mobile operating-
system implementers, security researchers and autonomous-agent
developers. Its primary objectives are technical accessibility,
accurate provenance and search discoverability, and engineering
examination. The document is not represented as an adopted IETF
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
standard, an IETF WG deliverable, a granted patent, or a claim of
implementation by a named commercial product.
The practical security gap is not simply how to send an Android
Intent to an iOS application, or how an AI model invokes an
application action. It is how the original principal authorizes the
ACTUAL consequence after platform-specific permissions, user
approval, delegated service identity, account scopes, credential
custody, filesystem names, URLs, hardware state and resource versions
have changed along the path. A cross-platform API bridge may
faithfully transmit instructions while failing to enforce the
operation actually performed at the receiving resource. A privileged
connector may authenticate successfully while acting outside the
source grant.
The source invention states that platform-specific adapters may
translate qualified permissions, identity, application, device and
security evidence into a protected canonical effect descriptor
without converting an upstream platform permission into final
authority. The receiving Finality Sink independently obtains or
reconstructs the pending operation and verifies actual resource/
effect correspondence, current authority and protected consumption
conditions. Qualified cross-device transfers additionally may
require current owner epochs and source-device fences. Unavailable
mandatory controls cause withholding, not default acceptance.
This Part 2 uses Part 1 for authoritative CA, NES, PED, evidence,
scoped enablement, Finality Sink and CW-1/CW-2/CW-3 terminology, but
provides local explanations wherever they are necessary for
independent reading. Platform-specific adapters and actual receiving
effectuation remain its main topic; the companion parts develop
specialized evidence, hardware, delegation, recovery and revocation
details without redefining the common principles.
For related definitions, see the foundational companion specification
referenced as DAS-FOUNDATION. For authority and protected evidence
see DAS-EVIDENCE; for sink verification see DAS-SINK; for tool and
alias security see DAS-TOOLS; for source fencing and migration see
DAS-MIGRATION. These are prospective series cross-references;
official status and version numbers must be verified before
submission.
1.1. Complete Series Directory, Planned Names, and Cross-References
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
1.1.1. Part 1 of 12: draft-das-interoperable-consequence-authority
Foundational definitions, shared trust model, CW-1 protected
effectuation, CW-2 receipt-based causal continuation, and CW-3 scope-
deviation reauthorization. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-interoperable-consequence-
authority/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.2. Part 2 of 12: draft-das-cross-platform-ai-interoperability
This document: heterogeneous iOS, Android, desktop and cloud source-
evidence adapters, canonical effect descriptors, device crossing and
actual receiving effects. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-cross-platform-ai-
interoperability/ . This address is not asserted to be active until
the individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.3. Part 3 of 12: draft-das-protected-authority-evidence
Source authority, protected evidence, independent validation, and
scoped non-bearer enablement. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-protected-authority-
evidence/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.4. Part 4 of 12: draft-das-finality-sink-enforcement
Reconstruction of actual pending operations, sink-local checks and
anti-bypass enforcement. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-finality-sink-enforcement/
. This address is not asserted to be active until the individual
draft is accepted and listed by Datatracker.
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.5. Part 5 of 12: draft-das-multi-agent-authority-control
Reference: [DAS-MULTIAGENT].
Multi-agent delegation, source lineage, reservations and conflict
arbitration. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-multi-agent-authority-
control/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.6. Part 6 of 12: draft-das-causal-effect-receipts
Reference: [DAS-RECEIPTS].
Actual-effect evidence, dependent phase eligibility and source-
authorized causal continuation. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-causal-effect-receipts/ .
This address is not asserted to be active until the individual draft
is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.7. Part 7 of 12: draft-das-agent-tool-integrity
Tool semantics, redirects, resource identity, software and runtime
integrity. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-agent-tool-integrity/ .
This address is not asserted to be active until the individual draft
is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.8. Part 8 of 12: draft-das-distributed-effect-recovery
Reference: [DAS-RECOVERY].
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Remote effects, indeterminate outcomes, multi-resource transactions
and bounded recovery. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-distributed-effect-
recovery/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.9. Part 9 of 12: draft-das-agent-credential-privacy
Reference: [DAS-PRIVACY].
Protected credentials, disclosure control, signing-key use and
privacy release. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-agent-credential-privacy/
. This address is not asserted to be active until the individual
draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.10. Part 10 of 12: draft-das-cross-device-authority-revocation
Cross-device authority migration, ownership epochs, source fences,
revocation and offline conditions. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-cross-device-authority-
revocation/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.11. Part 11 of 12: draft-das-hardware-execution-finality
Reference: [DAS-HARDWARE].
Kernel/sandbox/hardware enforcement, protected egress and device
commands. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-hardware-execution-
finality/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
1.1.12. Part 12 of 12: draft-das-autonomous-infrastructure-finality
Reference: [DAS-INFRA].
Cloud/telecom/critical-resource governance, resource budgets and
protected effect control. Proposed Datatracker address:
https://datatracker.ietf.org/doc/draft-das-autonomous-infrastructure-
finality/ . This address is not asserted to be active until the
individual draft is accepted and listed by Datatracker.
Series name: Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part Technical
Specification Series.
2. Intellectual Property Rights, Foundational Filing, and Forthcoming
GitHub Reference Implementation
The principal underlying 8,598-page international technical
disclosure is PCT/IB2026/055615, filed on 4 June 2026 and published
as WO 2026/150382 [PCT]. This must not be conflated with separate
earlier PCT/IB2025/058316 or with the 3,567-page technical
specification used as the immediate source for this series. Detailed
application-by-application relationships, Indian filing references,
relevant claims and priority analysis require independent
verification against the as-filed records.
Detailed draft-specific disclosures and any corresponding licensing
declarations are intended to be filed or updated separately through
the applicable IETF IPR disclosure process under BCP 79, including
[IPR]. This paragraph is not itself the IETF IPR registry
disclosure, does not establish essentiality to a standard, and does
not express a licensing commitment. No patent grant or infringement
determination is asserted.
A public GitHub reference implementation, example source code, test
harnesses, evidence formats and reproducibility instructions are
planned for a later revision. No repository URL, release date,
working demonstration or successful test result is asserted before a
verifiable release exists. New example algorithms and proposed tests
in this Part 2 are expressly identified as editorial implementation
aids, not historical experimental results from the original filing.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The full source document is Sangam Kumar Das, "iOS and Android
Interoperability for Secure Third Party AI Tools - Cross-Platform
Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Zenodo record [ZENODO]
(https://zenodo.org/records/23657985), DOI https://doi.org/10.5281/
zenodo.23657985. Publication dates and public accessibility must be
established from actual versioned repository or publication records,
not inferred from planned documents. A later Internet-Draft cannot
retroactively establish the filing date or content of an earlier
patent application.
3. Keywords and Search Discovery Index
* Apple iOS security; iPadOS app security; macOS application
sandbox; Apple App Intents; Shortcuts; third-party AI tool
interoperability; secure mobile assistants; application extensions
* Google Android security; Android intents; Binder IPC; Android
permission model; Android Keystore; Android app sandbox; Android-
to-iOS interoperability; Android-to-cloud AI agent
* AI agent security; cross-platform AI execution; prompt injection;
tool-call authorization; prompt-injection-induced file export;
unauthorized API call; agent browser and computer use; agent
egress security
* Cross-application authorization; OAuth rich authorization
requests; OAuth DPoP; workload identity; WIMSE; RATS attestation;
COSE cryptography; CBOR serialization; ACE constrained
authorization; SCITT attestations; HTTP conditional requests
* Protected canonical effect descriptor; Candidate Act; Non-
Effective State; Protected Enforcement Domain; Finality Sink;
scoped non-bearer finality authority; effectuation boundary;
actual-operation reconstruction; platform adapter; source grant;
revocation epoch; source fencing
* Credential abuse; stale platform permission; resource redirect;
hostname rebound; filename alias; recipient substitution; token
replay; persistent mutation; privileged broker; alternative
execution path; credential release; protected source-authority
continuity
* Microsoft Windows and Azure AI; Google Gemini; OpenAI agent
tooling; Anthropic Claude; Meta Muse/Sentinel; NVIDIA
accelerators; Qualcomm Snapdragon; Huawei mobile hardware; Arm
security; financial API; payments; telecom; robotics; IoT security
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
* Patent examiner; publicly accessible technical disclosure;
embodiment 9 device ownership; embodiment 21 alias resolution;
embodiment 27 workload handoff; miscellaneous embodiment M-1;
miscellaneous embodiment M-2; CW-1 CW-2 CW-3
4. Scope, Traceability, and Relationship to the Original Disclosure
This Part 2 assembles the primary cross-platform invention disclosure
from original global pages 1-14 and detailed source material from M-1
(555-609), M-2 (1898-1952), Embodiment 9 (860-925), Embodiment 21
(1758-1829), and Embodiment 27 (2246-2317). These global ranges are
presented as source-based technical extracts and remain labeled by
page. They contain optional non-limiting mechanisms that cannot all
be presumed mandatory simultaneously. Inclusion here does not
transfer a mechanism away from other companion drafts: related
documents will cross-reference the corresponding primary procedures.
This document distinguishes (1) source-derived technical disclosure
and its page-indexed extracts, (2) editorial explanatory system
models and engineering interface examples, and (3) proposed
validation tests. No unstated production implementation, verified
vendor integration, approved RFC extension, or successful
experimental result should be inferred from editorial models. The
full 3,567-page source and any original patent application must be
consulted for exact provenance.
5. Local Terminology with Foundational Reference
Candidate Act (CA): A particular proposed consequential operation
describing its intended actual effect; representation of an act does
not itself authorize execution.
Non-Effective State (NES): An enforceable stage where the governed
operation is prevented from producing the consequential effect.
Protected Enforcement Domain (PED): A sufficiently independent and
protected validator/authority controller under the applicable trust
model, not automatically synonymous with a sandbox.
Canonical Effect Descriptor (CED): An interoperable, protected
representation of security-relevant actual-effect semantics across
differing platform interfaces, including target, recipient, operation
class, parameters and identity lineage.
Platform Evidence Adapter: A platform-specific collector or validator
translating only qualified security properties into a protected
effect descriptor and indicating the provenance, scope and freshness
of each property.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Scoped Non-Bearer Finality: Operation/sink/state-qualified enablement
that is not an unrestricted transferable credential; the destination
sink remains responsible for checking the actual operation and state.
Finality Sink (FS): The effective resource boundary where the actual
pending operation is obtained or independently reconstructed and
current evidence/authority/consumption checks occur.
Ownership Epoch: A protected generation for determining which device,
domain or resource owner may presently exercise finality for a
bounded consequential scope.
Source Fence: An enforcement measure preventing the prior holder from
causing a governed effect after a qualified authority transfer.
Actual Resource Identity: The verified final object or destination
receiving a consequence, rather than solely the workload-supplied
alias, URL, path or name.
Non-bypassability: A conditional guarantee that governed effect-
capable routes are controlled or excluded within the declared
topology; no blanket claim across inaccessible hardware or unrelated
external systems.
The fuller terminology, evidence requirements and common workflows
are defined in Part 1. See DAS-FOUNDATION in the reference list;
this Part 2 does not silently redefine or weaken those conditions.
6. Cross-Platform Authority Translation and Consequence Enforcement
6.1. Protected Trust Boundaries and the Cross-Platform Translation Path
The original source may be an iOS App Intent, a third-party app
extension, an Android Intent or Binder service, a desktop
application, an automation gateway, or an AI agent calling a remotely
hosted service. These entry surfaces vary in permission semantics
and privilege. The proposed act is first described as a CA and held
in NES. Native platform credentials, authentication, user consent,
entitlements, device integrity and resource scope contribute bounded
evidence through protected adapters; none becomes unconditional final
effect permission.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The translation stage resolves relevant source principal, delegated
authority, requesting workload, actual operation class, source and
destination resource identity, recipient, protected outgoing
information commitment, relevant device generation, and enforcement
topology. Any required evidence absent, stale, unsupported or
semantically incompatible with the receiving effect remains a ground
for withholding.
[User / competent principal / source grant]
|
+---------------+-----------------+
| | |
[iOS App Intents] [Android app IPC] [Desktop/cloud agent]
| | |
+---------------+-----------------+
|
[Candidate Act: hold in NES]
|
[Platform-specific protected adapters]
identity / entitlement / scope
device state / resource / revocation
|
[Canonical Effect Descriptor]
|
[PED authority validator]
| |
insufficient qualified
| |
[WITHHOLD] [Scoped non-bearer
finality enablement]
|
[Receiving Finality Sink]
reconstruct ACTUAL act
check evidence + epoch
check sink-local state
|
pass / failure
| |
[Consume+effect] [WITHHOLD]
Figure 1: Figure 1: Cross-Platform Protected Effect Architecture
6.2. Per-Operation Interoperability Decision Flow
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[Request arrives from platform/agent]
|
[Construct CA; freeze effect envelope]
|
[Hold operation in NES]
|
<Qualified source grant?>---NO-->[WITHHOLD]
|YES
<Platform adapter evidence valid?>-NO-->[WITHHOLD]
|YES
<Resource identity and alias current?>-NO-->[REVALIDATE/STOP]
|YES
<Delegated scope/epoch current?>---NO-->[WITHHOLD]
|YES
[Constitute scoped finality]
|
[Receiving sink sees actual act]
|
<Actual act == committed envelope?>-NO-->[WITHHOLD]
|YES
<Sink local state valid + unused?>-NO-->[WITHHOLD]
|YES
[Atomic finality consumption]
|
[Permit controlled consequence]
Figure 2: Figure 2: iOS/Android-to-Resource Decision Flowchart
6.3. Cross-Platform Acceptance and Refusal Conditions
* An authenticated Android Intent recipient is not necessarily
authorized to carry out every requested persistent operation;
source grant and actual target remain independently assessed.
* An iOS App Intent exposure or system permission does not
automatically confer a third-party agent unrestricted authority to
disclose protected files or issue irreversible requests.
* A translated permission MUST NOT be silently broadened to a more
permissive capability merely because the destination application
or device has wider native privileges, within the proposed
implementation model.
* If destination integrity cannot be qualified at the strength
required by the selected effect, local application authentication
alone is insufficient.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
* A cross-device task handoff is not proof that the old device has
lost residual effect-capable queues, credential handles or command
paths.
* Domain acceptance, HTTP response codes and network dispatch are
not proof of a qualified actual external effect unless required
receiver-specific evidence establishes it.
* The source claim of a resource identifier is not always the actual
final target after symlink resolution, cloud alias translation,
URL redirection or DNS rebinding.
* Where a direct mobile-app integration cannot control other
privileged effect paths, describe the enforcement guarantee as
limited to the controlled service/API or receiving sink.
7. PHOSITA Implementation Using Existing Software, Operating-System
Security, and Standard Protocols
The following is new engineering implementation guidance based on
source-described components; it is not a claim that the original
patent filing included a particular open-source project, specific
interface schema, or completed test. A person having ordinary skill
in mobile and distributed security can construct an independently
controlled service-level reference prototype using mature languages,
cryptographic libraries, transactional storage, web APIs, and
platform API bridges. Equivalent solutions may use other components
without changing the protected trust relationship.
7.1. Apple iOS / iPadOS / macOS Adapter
Implement an app-facing request preparation component through
authorized app actions, App Intents, application extensions or a
companion app where available. Use ordinary consent, Keychain
credentials, app sandbox and permitted inter-application interfaces
only within their documented boundaries. Construct an effect
descriptor and send it to a remote protected gateway for current
authorization and sink-side enforcement. A third-party iOS app
generally cannot impose a kernel-wide mandatory gate on all other
apps or private system services. For real resource finality, use
cooperation by the controlled server, provider API, or authorized
privileged enforcement component.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
7.2. Android Adapter, Intents, Binder, Keystore
An Android reference app can receive or create Intents, invoke
Android IPC/Binder where permitted, and use Android Keystore-backed
cryptographic operations for suitable keys. Translate exported-
component caller identity, request class, granted Android permissions
and current endpoint constraints into evidence with explicit
assurance levels. Android permissions or a successful Binder
transaction are not in themselves proof of final resource-side
permission. Avoid assuming an ordinary app can intercept every other
app or system service.
7.3. Protected Gateway and Credential Custody
Use a separately administered service or resource gateway containing
source-grant storage, a parser/canonicalizer, a bounded operation
validator, a credential custodian, a transactionally protected state
store and an egress or resource-side Finality Sink. Keep reusable
OAuth/API credentials unavailable to the untrusted agent. Dispatch
only the reconstructed approved operation following sink-local
protected consumption.
7.4. Canonicalization and Semantic Equality
Define an explicit versioned descriptor schema. Apply deterministic
serialization (canonical CBOR or explicit JSON canonicalization
profile), Unicode rules, URL/resource normalization rules, a
protected identity-resolution step, and a security-reviewed
comparison. Do not hash an untrusted textual request in lieu of
observing the actual resource operation. Bind the descriptor to the
authorization context, effect class, source identity, target
identity, resource version and relevant epochs.
7.5. Database and Protected Consumption
Use a transactional database with serializable or equivalent atomic
compare-and-set behavior to store scope, epoch, sink binding, one-use
state, recovery generations, and proof of consumed authority. Reject
replay before effect. In ambiguous external dispatch, do not
automatically reopen consumed authority. Use receiver-supported
idempotency or qualified outcome evidence where available.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
7.6. Cross-Device and Runtime Migration
Exchange only qualified task context and bounded authority
references. Commit an ownership generation, establish effective
source fencing, and only then enable the qualified destination where
the selected strict transfer model requires that ordering. For
disconnected devices, prohibit strict transfer where fencing cannot
be established, or operate under separately authorized bounded leases
and clearly stated partition assumptions.
7.7. Actual Resource Identity Enforcement
Resolve and verify the final resource using server-side object
identifiers, version/ETag checks, actual socket destination and
endpoint policy, or authoritative filesystem object identity as
applicable. If a redirect, alias, ownership update or late resource
rebind changes the effect, revalidate or withhold the governed
consequence.
7.8. Effectuation Coverage and Limits
Enumerate effect-capable routes for the governed consequence: SDK
APIs, HTTPS network requests, IPC, files, background jobs, credential
brokers, privileged workers, queues and device interfaces.
Demonstrate that the controlled interface is truly mandatory. A
policy log or eBPF observer that cannot block an effect does not
alone establish non-bypassability.
7.9. Logs and Evidence
Record immutable or integrity-protected correlation identifiers,
effective descriptor commitments, validator decisions, protected
epoch, Finality Sink consumption state, outcome class and relevant
timestamps. Preserve privacy boundaries: logs should not expose
credentials or unnecessarily copy sensitive request content.
7.10. Recovery and Failure Semantics
On timeout distinguish never-sent, accepted, dispatched, effect-
confirmed and outcome-indeterminate states. Commit local state
before permitting the governed effect as required by the selected
consistency design. A local process crash does not undo a completed
remote operation; retries require updated authority, idempotency
support, or qualified effect/outcome evidence.
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
8. Reference Interfaces, Data Models, Algorithms, and State Transitions
The following named example messages and pseudocode are newly
authored non-normative engineering aids. They illustrate one
realizable composition of mechanisms described in the source. They
are not asserted to be an existing registered IETF wire format or a
field-for-field quotation of the source patent disclosure.
8.1. Illustrative Candidate Act and Canonical Effect Descriptor
CandidateAct = {
schema_version, operation_id, source_principal,
requesting_workload, source_grant_reference,
source_device_id, source_owner_epoch,
operation_class, native_platform, native_action,
canonical_effect: {
final_resource_id, effective_recipient,
method_or_primitive, material_parameters_digest,
output_content_commitment, resource_version,
permitted_effect_envelope, designated_sink
},
evidence_references[], delegated_lineage[],
revocation_generation, expiry, nonce,
source_policy_generation, required_coverage_id
}
Figure 3: Illustrative Candidate Act and Canonical Effect Descriptor
(illustrative, not a normative wire protocol)
8.2. Protected Platform Translation and Qualification Pseudocode
translate_and_hold(native_request, platform_evidence):
ca := parse_to_candidate_act(native_request)
keep_non_effective(ca)
require authenticated_original_source_grant(ca)
require provenance_of_platform_evidence(platform_evidence)
require evidence_fresh_for_effect(platform_evidence, ca)
descriptor := normalize_and_resolve_actual_effect(ca)
require descriptor.valid AND no_scope_expansion(descriptor)
require current_revocation_and_ownership_epochs(ca)
require protected_effectuation_coverage(descriptor)
return protected_cross_committed_descriptor(ca, descriptor)
any failed require => REFUSE without effect
Figure 4: Protected Platform Translation and Qualification Pseudocode
(illustrative, not a normative wire protocol)
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
8.3. Receiver Finality Sink Independent Dispatch Pseudocode
receive_at_sink(finality_reference, prepared_operation):
actual := observe_or_reconstruct(prepared_operation)
require validate_protected_evidence(finality_reference)
require designated_sink_match(finality_reference, self)
require actual_effect_equivalence(actual, committed_descriptor)
require resource_binding_and_owner_epoch_current(actual)
require current_scope_and_revocation(actual)
begin protected transaction
require unconsumed_and_valid(finality_reference)
mark_consumed(finality_reference, actual.effect_id)
commit protected transaction
perform_only_prepared_effect(actual)
record qualified_result_or_indeterminate_status()
any failed require => WITHHOLD (never silently retry)
Figure 5: Receiver Finality Sink Independent Dispatch Pseudocode
(illustrative, not a normative wire protocol)
8.4. Source-Fenced Device Ownership Transition Pseudocode
migrate(source, destination, candidate_set):
authenticate(source, destination, ownership_authority)
freeze_new_source_effect_authority(candidate_set)
account_for_inflight_commands_and_ambiguous_effects()
commit current ownership epoch E+1
install effective source fence for affected sinks
require source_fence_evidence_or_authorized_bounded_lease()
verify destination security and permitted resource scope
create destination-specific scoped non-bearer finality
on destination actual operation: verify E+1 and sink state
deny older epoch and cloned-instance replay
Figure 6: Source-Fenced Device Ownership Transition Pseudocode
(illustrative, not a normative wire protocol)
8.5. Protected Identity Binding and Redirect Handling
bind_resource(logical_reference, authorized_descriptor):
resolved := authenticated_resolution(logical_reference)
require resolved.actual_identity == authorized_resource_identity
require valid_owner_and_binding_generation(resolved)
if redirect_or_rebinding_occurs:
suspend_effect(); requalify_actual_resource()
require sink_observes_same_actual_target(resolved)
return resolved
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Figure 7: Protected Identity Binding and Redirect Handling
(illustrative, not a normative wire protocol)
8.6. Reference State Machine and Failure Semantics
CA_CREATED -> HELD_NES -> EVIDENCE_QUALIFIED
| |
v v
REFUSED AUTHORITY_PREPARED
|
SINK_PRESENTED
/ \
MISMATCH MATCH
| |
WITHHOLD CONSUMED
|
DISPATCHED
/ | \
EFFECT NO-EFFECT UNKNOWN
| | |
RECEIPT REFUSED QUARANTINED
Figure 8: Figure 3: Protected Cross-Platform State Transitions
Quarantined or unknown outcomes are not reclassified as safe failures
without qualified receiving-resource evidence. A privileged source
controller must not resume a consumed enablement solely because the
application restarts, the network times out, or a snapshot is
restored.
9. Source-Grounded Interoperability Embodiments and Supplementary
Technical Disclosures
9.1. Original Cross-Platform Invention: Interoperability, Authority
Continuity and Platform Evidence
Technical source: original global pages 1-14. The following source
reproduction is a detailed disclosure index preserving original
ordering, technical optionality and independently identified page
boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.1.1. Architecture Diagram and Protected Components
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[iOS/Android/native app] -> [Qualified adapter] -> [CED] -> [PED]
[Source grant + current platform evidence] |
v
[Receiving FS]
[actual effect/state check]
Figure 9: Original Cross-Platform Invention: Interoperability,
Authority Continuity and Platform Evidence — Architecture
9.1.2. Operational Flowchart and Fail-Closed Branches
[Native operation proposed] -> [CA/NES]
|
<Source/effect equivalence?> --NO--> [Withhold]
|YES
[Validate current evidence / epochs]
|
[FS sees actual pending operation]
|
<Same authorized effect?> --NO--> [Withhold]
|YES
[Consume / effect]
Figure 10: Original Cross-Platform Invention: Interoperability,
Authority Continuity and Platform Evidence — Decision Flow
9.1.3. Page-Indexed Source-Derived Technical Detail
9.1.3.1. Source page 1 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.2. Source page 2 of the original technical specification
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
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.3. Source page 3 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.4. Source page 4 of the original technical specification
The original task may pass through several computational
transformations, including model inference, tool selection, message
translation, task delegation, application-interface invocation, and
execution-context migration.
These transformations may alter the representation of the requested
operation without necessarily establishing renewed authority from the
originating principal.
Moreover, autonomous agents may encounter malicious instructions,
compromised external content, stale task context, incorrect resource
references, hallucinated operation parameters, or manipulated tool
responses.
A computational system may therefore generate a technically
executable command that exceeds the scope of the original
authorization.
Merely isolating the agent within a sandbox, authenticating its
identity, or restricting access to selected tools does not
necessarily prevent an unauthorized effect through another accessible
execution route.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
Different operating systems and devices expose different levels of
control over applications, privileged services, network
communications, storage operations, hardware functions, and security-
sensitive interfaces.
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.1.3.5. Source page 5 of the original technical specification
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.
An access token may remain valid while the operation exceeds its
intended effect scope.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.6. Source page 6 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.1.3.7. Source page 7 of the original technical specification
(i) preserve the required security properties even when different
platforms employ different software, hardware, communication, and
authorization mechanisms.
The present invention addresses these technical problems through a
protected, operation-specific execution-finality architecture having
interoperable authority semantics and qualified platform-specific
enforcement implementations.
SUMMARY OF THE INVENTION
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The proposed operation is maintained in a Non-Effective State by an
enforceable holding mechanism until the relevant protected conditions
are satisfied.
9.1.3.8. Source page 8 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.1.3.9. Source page 9 of the original technical specification
In another aspect, the invention provides a protected translation
mechanism configured to obtain authorization and security information
from heterogeneous source systems and convert the relevant
information into a bounded consequential-operation representation.
The source information may comprise identity assertions, application
permissions, delegated authorization records, structured action
descriptions, protected device state, cryptographic authentication
evidence, resource-access restrictions, or other qualified security
information.
A protected translation controller determines the actual technical
meaning of the requested operation and produces or verifies a
canonical effect descriptor.
The descriptor may identify an originating principal, requesting
component, actual operation class, resource identity, effective
recipient, operation parameters, permitted effect envelope, relevant
policy state, and designated enforcement boundary.
Different platforms may employ different native permission names or
resource-interface structures while using equivalent protected effect
semantics for the specific governed operation.
A source permission is not silently expanded merely because the
receiving platform implements a broader technical operation.
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.1.3.10. Source page 10 of the original technical specification
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.
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.1.3.11. Source page 11 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.12. Source page 12 of the original technical specification
In selected embodiments, typed JSON, CBOR, deterministic binary
encodings, or other canonical machine-readable representations may
communicate protected operation and evidence information.
Platform-specific adapters may translate native authorization or
application-operation representations into the required interoperable
protected structures.
The architecture is not restricted to one serialization format,
cryptographic algorithm, permission framework, application-
development environment, transport protocol, or processor instruction
set.
The operative requirements concern the preservation of protected
authority dependencies, correct actual-operation correspondence,
sufficient enforcement coverage, and verified finality control.
11. Revocation, Replay Prevention, and Protected State Continuity
The invention may maintain protected authorization generations,
revocation references, consumption records, device-ownership epochs,
current resource state, and relevant enforcement-coverage
information.
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
9.1.3.13. Source page 13 of the original technical specification
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.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.1.3.14. Source page 14 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2. Miscellaneous Embodiment M-1: Modular Enforcement Coverage and
Cross-Interface Portability
Technical source: original global pages 555-609. The following
source reproduction is a detailed disclosure index preserving
original ordering, technical optionality and independently identified
page boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.2.1. Architecture Diagram and Protected Components
[Tool / API / IPC / egress / hardware effect path]
|
[Coverage discovery]
|
[Operation semantics + resource aliases]
|
[Credential / delegated scope / evidence]
|
[Finality Sink]
Figure 11: Miscellaneous Embodiment M-1: Modular Enforcement
Coverage and Cross- Interface Portability — Architecture
9.2.2. Operational Flowchart and Fail-Closed Branches
[Discover effect routes]
|
<Coverage complete?> --NO--> [Fence/refuse]
|YES
[Qualify semantic/resource identity]
|
<Current authority valid?> --NO--> [Withhold]
|YES
[Sink verify + consume / effect]
Figure 12: Miscellaneous Embodiment M-1: Modular Enforcement
Coverage and Cross- Interface Portability — Decision Flow
9.2.3. Page-Indexed Source-Derived Technical Detail
9.2.3.1. Source page 555 of the original technical specification
The successor Finality Sink independently verifies the actual pending
operation before effectuation.
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.2. Source page 556 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
Where necessary, an implementation may invoke mechanisms from the
earlier embodiments without restating their complete technical
procedures.
9.2.3.3. Source page 557 of the original technical specification
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.
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
M-1.1 — SPECIFIC TECHNICAL PROBLEMS
9.2.3.4. Source page 558 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.5. Source page 559 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
An autonomous device may perform operations while disconnected from
an authoritative central service.
9.2.3.6. Source page 560 of the original technical specification
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.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.7. Source page 561 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.8. Source page 562 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.9. Source page 563 of the original technical specification
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.
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.10. Source page 564 of the original technical specification
M-1.4.2 — Surface Registration
A protected registration component may authenticate an effectuation
interface and associate it with supported effect classes.
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
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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
9.2.3.11. Source page 565 of the original technical specification
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.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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,
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.12. Source page 566 of the original technical specification
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
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.
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.13. Source page 567 of the original technical specification
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
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.
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.14. Source page 568 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.15. Source page 569 of the original technical specification
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.
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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
9.2.3.16. Source page 570 of the original technical specification
An implementation may use authenticated cross-domain messages and
locally verifiable authority commitments.
Each provider may retain independent authority and security
requirements.
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.17. Source page 571 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.18. Source page 572 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
Where fairness or parity is required, the system may identify which
workloads are meaningfully comparable under the protected policy.
9.2.3.19. Source page 573 of the original technical specification
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
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
M-1.12.4 — Route-Specific Evidence
The system may require different evidence depending upon the selected
execution environment.
9.2.3.20. Source page 574 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.21. Source page 575 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.22. Source page 576 of the original technical specification
An authority bound to an earlier epoch may require revalidation.
M-1.14.3 — Coverage Reassessment
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.
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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
9.2.3.23. Source page 577 of the original technical specification
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.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.24. Source page 578 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.25. Source page 579 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.26. Source page 580 of the original technical specification
The local controller verifies the offline authority against the
actual operation.
M-1.19.4 — Protected Consumption
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
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
9.2.3.27. Source page 581 of the original technical specification
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.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected system determines its actual effectuation surfaces.
9.2.3.28. Source page 582 of the original technical specification
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
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.
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.29. Source page 583 of the original technical specification
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.
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 ):
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.30. Source page 584 of the original technical specification
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 ):
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,
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.31. Source page 585 of the original technical specification
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:
9.2.3.32. Source page 586 of the original technical specification
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 ):
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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()
9.2.3.33. Source page 587 of the original technical specification
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
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:
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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 )
9.2.3.34. Source page 588 of the original technical specification
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 )
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 ):
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.35. Source page 589 of the original technical specification
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.
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.
9.2.3.36. Source page 590 of the original technical specification
A conventional orchestration system may expose the entire tool
interface once the tool has been registered.
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.37. Source page 591 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.38. Source page 592 of the original technical specification
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
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.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.3.39. Source page 593 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.40. Source page 594 of the original technical specification
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
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.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.41. Source page 595 of the original technical specification
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.
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
M-1.36.21 — Offline Authority Overuse
A disconnected device attempts more operations than its preauthorized
offline budget permits.
9.2.3.42. Source page 596 of the original technical specification
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
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
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.43. Source page 597 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
Experiment 14 — Validation Work Limit: Submit oversized or
computationally expensive evidence and verify bounded resource
consumption.
9.2.3.44. Source page 598 of the original technical specification
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.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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:
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Effectuation-path discovery coverage.
9.2.3.45. Source page 599 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.46. Source page 600 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.47. Source page 601 of the original technical specification
Remote attestation may provide evidence about an execution
environment.
The present embodiment distinguishes verified environment identity
from authority over a specific external consequence.
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.
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
It commits current enforcement coverage against an authenticated
environment state.
A Finality Sink refuses the operation where a required interface
lacks valid protection.
9.2.3.48. Source page 602 of the original technical specification
The possible technical contribution is making current coverage of
effectuation paths a necessary authority predicate.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
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.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
9.2.3.49. Source page 603 of the original technical specification
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.
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
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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:
9.2.3.50. Source page 604 of the original technical specification
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.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The relevant comparison is the enforceable technical relationship and
its demonstrated or technically supported effect.
9.2.3.51. Source page 605 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.52. Source page 606 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.53. Source page 607 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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
The following candidate claim-support concepts may be considered
individually or in appropriately supported combinations.
9.2.3.54. Source page 608 of the original technical specification
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.
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
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.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
9.2.3.55. Source page 609 of the original technical specification
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.
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.
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
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.
The mechanisms may be deployed separately or in compatible
combinations.
9.3. Miscellaneous Embodiment M-2: Standards-Interoperable Platform-
Independent Finality Constitution
Technical source: original global pages 1898-1952. The following
source reproduction is a detailed disclosure index preserving
original ordering, technical optionality and independently identified
page boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.3.1. Architecture Diagram and Protected Components
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[OAuth / IPC / Sandbox / COSE / OS / Hardware]
|
[Protected evidence adapters]
|
[Authorization-to-effect translation]
|
[Current revocation + topology evidence]
|
[Non-bearer finality]
|
[Actual effect FS]
Figure 13: Miscellaneous Embodiment M-2: Standards-Interoperable
Platform- Independent Finality Constitution — Architecture
9.3.2. Operational Flowchart and Fail-Closed Branches
[Native authorization evidence collected]
|
<Establishes required property?>--NO-->[Stop]
|YES
[Translate exact operation semantics]
|
<Current revocation/coverage?>--NO-->[Stop]
|YES
[FS reconstruct + compare actual act]
|
<Protected sink consumption valid?>--NO-->[Stop]
|YES
[Effect]
Figure 14: Miscellaneous Embodiment M-2: Standards-Interoperable
Platform- Independent Finality Constitution — Decision Flow
9.3.3. Page-Indexed Source-Derived Technical Detail
9.3.3.1. Source page 1898 of the original technical specification
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 111]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 112]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.2. Source page 1899 of the original technical specification
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 113]
Internet-Draft Execution-Finality Part 2: iOS/Android 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;
9.3.3.3. Source page 1900 of the original technical specification
(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 114]
Internet-Draft Execution-Finality Part 2: iOS/Android 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;
9.3.3.4. Source page 1901 of the original technical specification
A hardware-backed authority implementation;
A device-command implementation;
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 116]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.5. Source page 1902 of the original technical specification
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 117]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.6. Source page 1903 of the original technical specification
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 118]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.7. Source page 1904 of the original technical specification
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 119]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.8. Source page 1905 of the original technical specification
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 120]
Internet-Draft Execution-Finality Part 2: iOS/Android 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,
9.3.3.9. Source page 1906 of the original technical specification
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 121]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.10. Source page 1907 of the original technical specification
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 122]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.11. Source page 1908 of the original technical specification
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 123]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 124]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.12. Source page 1909 of the original technical specification
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 125]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.13. Source page 1910 of the original technical specification
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 126]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.14. Source page 1911 of the original technical specification
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 127]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.15. Source page 1912 of the original technical specification
The transport provides the selected authenticated communication
guarantees.
M-2.11.3 — Credential Binding
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 129]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.16. Source page 1913 of the original technical specification
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 130]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.17. Source page 1914 of the original technical specification
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 131]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.18. Source page 1915 of the original technical specification
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 132]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 133]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.19. Source page 1916 of the original technical specification
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 134]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.20. Source page 1917 of the original technical specification
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 135]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.21. Source page 1918 of the original technical specification
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 136]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.22. Source page 1919 of the original technical specification
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 137]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 138]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.23. Source page 1920 of the original technical specification
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 139]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.24. Source page 1921 of the original technical specification
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 140]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.25. Source page 1922 of the original technical specification
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 141]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.26. Source page 1923 of the original technical specification
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 142]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 143]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.27. Source page 1924 of the original technical specification
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 144]
Internet-Draft Execution-Finality Part 2: iOS/Android 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;
9.3.3.28. Source page 1925 of the original technical specification
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 145]
Internet-Draft Execution-Finality Part 2: iOS/Android 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,
9.3.3.29. Source page 1926 of the original technical specification
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 146]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.30. Source page 1927 of the original technical specification
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 147]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.31. Source page 1928 of the original technical specification
Step 8 — Resolve Current Revocation Dependencies. The protected
authority controller identifies the relevant source and delegated
grants.
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 149]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.32. Source page 1929 of the original technical specification
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),
9.3.3.33. Source page 1930 of the original technical specification
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 150]
Internet-Draft Execution-Finality Part 2: iOS/Android 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),
9.3.3.34. Source page 1931 of the original technical specification
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 151]
Internet-Draft Execution-Finality Part 2: iOS/Android 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),
9.3.3.35. Source page 1932 of the original technical specification
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 152]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.36. Source page 1933 of the original technical specification
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()
9.3.3.37. Source page 1934 of the original technical specification
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 153]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.38. Source page 1935 of the original technical specification
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 154]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 155]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The notification may be delayed.
9.3.3.39. Source page 1936 of the original technical specification
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 156]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.40. Source page 1937 of the original technical specification
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 157]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.41. Source page 1938 of the original technical specification
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 158]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 159]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.42. Source page 1939 of the original technical specification
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 160]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.43. Source page 1940 of the original technical specification
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 161]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.44. Source page 1941 of the original technical specification
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 162]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 163]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.45. Source page 1942 of the original technical specification
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 164]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.46. Source page 1943 of the original technical specification
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 165]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 166]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
M-2.46.2 — Kernel B: Revocation-Dependent Non-Bearer Authority
9.3.3.47. Source page 1944 of the original technical specification
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 167]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.48. Source page 1945 of the original technical specification
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 168]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.49. Source page 1946 of the original technical specification
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 169]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 170]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.50. Source page 1947 of the original technical specification
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 171]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.51. Source page 1948 of the original technical specification
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 172]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 173]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.3.3.52. Source page 1949 of the original technical specification
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 174]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.53. Source page 1950 of the original technical specification
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 175]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
9.3.3.54. Source page 1951 of the original technical specification
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 176]
Internet-Draft Execution-Finality Part 2: iOS/Android 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 177]
Internet-Draft Execution-Finality Part 2: iOS/Android 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
9.3.3.55. Source page 1952 of the original technical specification
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.
9.4. Embodiment 9: Cross-Device Authority Ownership and Source Fencing
Technical source: original global pages 860-925. The following
source reproduction is a detailed disclosure index preserving
original ordering, technical optionality and independently identified
page boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.4.1. Architecture Diagram and Protected Components
[Source device / pending CA]---[Ownership authority]
| | epoch E+1
[Source fence] [Destination device]
| |
[Old effect denied] [Destination FS]
|
[Actual act]
Figure 15: Embodiment 9: Cross-Device Authority Ownership and
Source Fencing — Architecture
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.2. Operational Flowchart and Fail-Closed Branches
[Freeze source new effect authority]
|
[Commit current ownership epoch]
|
<Source fence effective?>--NO-->[Withhold strict move]
|YES
[Qualify destination + permit scope]
|
<Epoch and actual act current?>--NO-->[Reject]
|YES
[Destination sink consume/effect]
Figure 16: Embodiment 9: Cross-Device Authority Ownership and
Source Fencing — Decision Flow
9.4.3. Page-Indexed Source-Derived Technical Detail
9.4.3.1. Source page 860 of the original technical specification
EMBODIMENT 9
PROTECTED CROSS-DEVICE EXECUTION-AUTHORITY OWNERSHIP WITH HARDWARE-
EPOCH FENCING, NON-BEARER MIGRATION ENABLEMENT, DEVICE-LOCAL FINALITY
ENFORCEMENT, AND VERIFIED TRANSFER OF EFFECTUATION CONTROL
9.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Exclusive and Bounded Execution-
Authority Migration Across Devices, Virtualized Environments,
Hardware Accelerators, and Autonomous Computing Systems Using
Authenticated Device Ownership, Monotonic Authority Epochs, Protected
Source-Device Fencing, Destination-Specific Non-Bearer Finality
Enablement, Command-Queue and Memory-State Isolation, and Independent
Verification of Actual Consequential Operations at Device Finality
Sinks
9.0.1 — General Technical Description
The present Embodiment 9 discloses systems, methods, apparatus,
protected computing components, authenticated device-control
protocols, machine-verifiable authority structures, protected
hardware and software state transitions, and non-limiting
implementations for transferring or reestablishing execution
authority among independently operating computing environments.
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The environments may comprise autonomous-agent runtimes, mobile
devices, desktop systems, embedded controllers, cloud instances,
virtual machines, confidential-computing environments, graphics
processors, neural accelerators, programmable hardware devices,
storage controllers, communication equipment, robotic platforms, or
other effect-capable computational systems.
A computational task may move from a first execution environment to a
second execution environment.
The task may be transferred because of device replacement, workload
migration, fault recovery, resource scheduling, network changes,
software upgrades, energy management, hardware reassignment, or
another operational condition.
The movement of computational state does not automatically establish
that the destination possesses valid authority to cause consequential
external effects.
Similarly, copying a task image, memory snapshot, execution context,
credential reference, command queue, or software process does not
automatically revoke the effectuation capabilities remaining in the
original environment.
A protected system therefore distinguishes:
The transfer of computational information;
The transfer of workload execution context;
9.4.3.2. Source page 861 of the original technical specification
The transfer of access to underlying hardware resources;
The transfer of authority to initiate consequential operations;
The transfer of exclusive ownership of an unfinished consequential
operation;
And the actual activation of a controlled effect at the destination.
These transitions may occur at different times and through different
technical interfaces.
The present embodiment establishes protected relationships among
them.
9.0.2 — Fundamental Technical Principle
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Possession of a copied or migrated computational state is not
authority to produce a consequential effect, and earlier possession
of execution authority is not permission to continue after exclusive
authority has been validly transferred.
A device may continue computing, retaining memory, or generating
commands after it loses authority over a protected consequence.
However, its commands remain non-effective at the governed boundaries
unless current protected authority exists.
Where exclusive authority has moved to another execution environment,
the previous owner must not be able to cause a further controlled
effect using stale credentials, cached permissions, command
descriptors, or earlier ownership assertions.
9.0.3 — Principal Proposed Inventive Concept
The principal proposed technical contribution concerns an ordered,
protected transition linking:
An identified unfinished Candidate Act;
The currently authorized effectuation owner;
A cryptographically or otherwise securely authenticated execution
environment;
An authoritative ownership epoch or equivalent protected generation;
A verified transfer and source-fencing condition;
Destination-specific protected finality authority;
Actual pending-operation reconstruction at a receiving device
Finality Sink;
And protected ownership-state consumption before consequential
effectuation.
A transfer is not complete merely because an authority registry
designates a new owner.
9.4.3.3. Source page 862 of the original technical specification
A stronger implementation requires the relevant source and
destination effectuation paths to enforce the committed ownership
transition.
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Before destination activation, the system establishes the required
conditions for preventing unauthorized source continuation.
The destination Finality Sink independently verifies the current
ownership and operation-specific authority before enabling the
governed consequence.
9.0.4 — Distinction from Generic Distributed Locking
Distributed locks, leases, fencing tokens, and monotonic ownership
generations are established techniques.
The present embodiment may employ such techniques.
The proposed additional relationship concerns their combination with
operation-specific protected finality authority, verified actual
effectuation paths, hardware or software command custody, device-
state transitions, and source/destination enforcement.
A fencing number alone does not establish that an actual pending
command is authorized.
A device identity certificate alone does not establish current
ownership.
A software process migration alone does not prevent an earlier
hardware queue from completing an already accepted command.
These separate technical conditions may be addressed in the disclosed
architecture.
9.0.5 — Exclusive and Nonexclusive Modes
A principal embodiment concerns exclusive authority migration.
Only the current valid owner may initiate the specified governed
consequential effect through the relevant protected paths.
An optional bounded multi-owner mode may permit expressly authorized
simultaneous operation by several devices.
In such a mode, the authority is partitioned by operation, resource,
effect budget, or another protected condition.
The existence of the optional multi-owner mode does not eliminate the
exclusive-ownership guarantees required by an implementation
expressly operating in exclusive mode.
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.0.6 — Physical and Logical Deployment
The protected ownership controller may reside within:
A secure processor;
9.4.3.4. Source page 863 of the original technical specification
An operating-system security controller;
A protected hypervisor;
A remote authority service;
A hardware security appliance;
A storage or accelerator controller;
A trusted device-management service;
A protected embedded processor;
Or another suitable authenticated component.
The Finality Sink may reside at the destination application,
operating system, network, storage, device, actuator, accelerator, or
other consequential boundary.
The components may be integrated or distributed.
Their physical positioning may vary, provided the claimed mandatory
authority relationship is actually enforced.
9.0.7 — Relationship to Existing Embodiments
Embodiment 1 may provide conflict arbitration between independently
authorized operations.
Embodiment 2 may provide cryptographically identified Interim
Effectuation Validators and receipt-constituted authority for
causally dependent real-effect phases.
Embodiment 3 may provide protected correspondence between an
authorized referent and the actual resource affected.
Embodiment 4 may provide qualified evidence concerning real external
outcomes.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Embodiment 5 may govern resource allocation among competing
assistants or workloads.
Embodiment 6 may verify whether changed action semantics remain
within the authorized effect envelope.
Embodiment 7 governs cross-provider delegation and authority
attenuation, including both concurrent delegation and task transfer.
Embodiment 8 governs cumulative information disclosure across
applications and agents.
Miscellaneous Embodiment M-1 may provide dynamic enforcement
coverage, hardware effectuation, and environmental reattestation.
9.4.3.5. Source page 864 of the original technical specification
The present embodiment concentrates specifically on exclusive device-
level ownership, the safety of the transfer boundary, hardware and
memory custody, and the inability of stale owners to produce
additional governed effects.
No preceding embodiment requires modification.
9.1 — TECHNICAL FIELD
The embodiment relates to protected autonomous execution, device
authority management, distributed ownership, secure workload
migration, cryptographic device identity, protected hypervisor
control, hardware command authorization, device-memory isolation,
direct-memory-access control, protected resource reallocation, fault
recovery, and non-bypassable execution-finality enforcement.
It also relates to maintaining the integrity of consequential control
during transitions between physical and virtual execution
environments.
The systems may be implemented in current computing infrastructure
and adapted to future autonomous, heterogeneous, distributed, and
hardware-accelerated systems.
9.2 — SPECIFIC TECHNICAL PROBLEMS
9.2.1 — Migrated Task Retains Old Authority
A workload may move to another device while the former environment
retains valid-looking credentials or cached execution permissions.
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.2 — Split-Brain Effectuation
Two execution environments may each believe they are the current
owner of the same unfinished consequential operation.
9.2.3 — Stale Lease Holder
A device may pause, lose connectivity, or miss a lease expiration.
When execution resumes, it may attempt to exercise authority that has
already transferred.
9.2.4 — Unfenced Command Queue
A device may have submitted commands into a queue before losing
ownership.
The queue may later dispatch the commands after the ownership
transition.
9.2.5 — Hardware Work Already In Flight
9.4.3.6. Source page 865 of the original technical specification
A peripheral may continue executing a command independently of the
process that submitted it.
Suspending or terminating the process does not necessarily prevent
the pending hardware effect.
9.2.6 — Device Memory Retention
A reassigned device may retain memory containing another tenant's
information, command descriptors, or protected authority material.
9.2.7 — Direct-Memory-Access Bypass
An assigned device may retain access to memory or other resources
beyond its currently authorized ownership.
9.2.8 — Peer-to-Peer Hardware Transfers
One device may communicate directly with another through a route not
passing through the ordinary host application enforcement interface.
9.2.9 — Secret-Key Retention
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A source environment may retain usable cryptographic keys after
transferring its task.
9.2.10 — Snapshot Cloning
A virtual machine or execution environment may be cloned into several
instances containing apparently equivalent credentials and authority
state.
9.2.11 — Device Identity Replacement
A physical device may be replaced or repaired while retaining an old
logical identifier.
A new device's authority must not be inferred solely from the reused
identifier.
9.2.12 — Authority Registry Lag
A local device may act on stale ownership information because the
authoritative registry has changed.
9.2.13 — Unavailable Authority Service
A device may become disconnected during migration, leaving ownership
uncertain.
9.2.14 — Hardware Reset Ambiguity
A controller may report a reset even though some external command
effects have already occurred.
9.4.3.7. Source page 866 of the original technical specification
9.2.15 — Retried Consequential Commands
A migrated task may retry an operation whose earlier execution status
is uncertain.
9.2.16 — Cross-Device Resource Rebinding
An operation may refer to a device-specific resource identifier that
points to a different physical target after migration.
9.2.17 — Firmware and Driver Variation
The destination may implement different operation semantics or
hardware capabilities.
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.2.18 — Safety During Physical Actuation
A device authority transfer may occur while a physical operation is
in progress.
Abruptly disabling an actuator may itself create a safety hazard.
9.2.19 — Technical Objective
A candidate objective technical problem is:
How to transfer or reestablish exclusive operation-specific execution
authority across heterogeneous computing environments while ensuring
that stale source environments, cloned workloads, retained
credentials, uncompleted hardware commands, and alternative device
interfaces cannot produce unauthorized additional consequential
effects through the protected effectuation paths.
9.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
9.3.1 — Conventional Process Migration
Process migration transfers computational state.
It does not necessarily control every external effect-capable
resource associated with the process.
9.3.2 — Conventional Virtual-Machine Migration
Virtual-machine migration can transfer processor, memory, and
selected device state.
The transfer alone does not establish independent operation-specific
finality authority at every consequential resource.
9.3.3 — Conventional Distributed Locks
A lock may coordinate which actor is intended to access a shared
resource.
9.4.3.8. Source page 867 of the original technical specification
The actor may nevertheless continue executing after the lock becomes
stale unless the affected resource enforces the required ownership
constraints.
9.3.4 — Conventional Fencing Tokens
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Monotonic fencing tokens can prevent stale holders from performing
certain mutations at a resource that checks those tokens.
This is established prior art.
The proposed combination extends the protected ownership relationship
to actual Candidate Acts, destination-specific finality authority,
device command state, and hardware effectuation controls.
9.3.5 — Conventional Sender-Constrained Credentials
A credential may be bound to a particular cryptographic sender.
Such binding can limit token replay by another party.
It does not automatically establish that the bound device remains the
current exclusive owner of a specific real-world effect.
9.3.6 — Conventional Hardware Attestation
Hardware attestation may provide evidence of device or software
identity and configuration.
Attestation alone does not establish operation-specific authority or
guarantee that the source device has been fenced.
9.3.7 — Conventional Memory Isolation
Memory-protection mechanisms can restrict device or process access.
They do not automatically determine which autonomous Candidate Act is
authorized to modify an external resource.
9.3.8 — Conventional Device Reset
Reset mechanisms may clear selected controller states.
The guarantees of a reset depend on the particular hardware,
firmware, memory regions, and supported reset operation.
9.3.9 — Conventional Resource Reassignment
A device may be reassigned between workloads.
Reassignment does not automatically establish that earlier authority,
pending commands, or retained sensitive state have been invalidated.
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.9. Source page 868 of the original technical specification
9.3.10 — Conventional Audit Records
An authenticated migration log may describe the intended owner
transition.
It does not independently prevent stale physical commands from
becoming effective.
9.4 — PRINCIPAL PROTECTED ARCHITECTURE
A representative implementation comprises:
An Originating Execution Environment;
A Destination Execution Environment;
A Protected Ownership Authority;
An authenticated Device Identity Registry;
A Protected Migration Coordinator;
A Source Finality Fence;
A Destination Finality Authority Controller;
One or more Device Finality Sinks;
A Protected Hardware Command-State Controller;
And an authoritative Ownership and Consumption State Store.
Optional components may include protected memory-isolation
controllers, key-management services, device-reset controllers, peer-
to-peer transfer controls, hardware attestation services, resource-
alias resolvers, and qualified outcome observers.
The components may be implemented within a common administrative
system or across independent protected domains.
9.4.1 — Originating Execution Environment
The source may contain active computation and previously valid
operation-specific authority.
9.4.2 — Destination Execution Environment
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination may receive the task state but initially lack
authority to produce protected external effects.
9.4.3 — Ownership Authority
9.4.3.10. Source page 869 of the original technical specification
A protected authority establishes the current owner of a defined
unfinished consequential operation or effectuation resource.
9.4.4 — Source Fence
The source fence prevents further unauthorized governed effects
following the applicable committed ownership transition.
9.4.5 — Destination Authority Controller
The destination controller prepares non-bearer operation-specific
finality enablement under the current ownership state.
9.4.6 — Destination Finality Sink
The destination sink reconstructs or obtains the actual pending
operation and verifies current authority before release.
9.4.7 — Hardware State Controller
The hardware controller may supervise command queues, device access,
memory mappings, interrupts, and outstanding work requiring migration
protection.
9.5 — TECHNICAL DEFINITIONS
9.5.1 — Protected Effectuation Owner
A Protected Effectuation Owner, or PEO-9, means an authenticated
entity currently permitted to initiate a defined governed
consequential operation under the applicable protected ownership
state.
9.5.2 — Device Ownership Authority Record
A Device Ownership Authority Record, or DOAR, means protected state
binding a defined effectuation scope to an authorized execution
owner.
9.5.3 — Authority Ownership Epoch
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An Authority Ownership Epoch, or AOE-9, means a protected generation
identifying the validity of ownership authority.
9.5.4 — Exclusive Effectuation Ownership
Exclusive Effectuation Ownership means that the relevant governed
effect may be initiated only under one valid current ownership
relationship during the applicable protected interval.
9.5.5 — Protected Source Fence
9.4.3.11. Source page 870 of the original technical specification
A Protected Source Fence, or PSF, means a mandatory enforcement
condition preventing stale source-owned operations from producing the
governed consequence after the applicable authority transition.
9.5.6 — Destination Activation Condition
A Destination Activation Condition, or DAC-9, means a protected
predicate that must be satisfied before the destination may exercise
migrated effectuation authority.
9.5.7 — Protected Migration State
Protected Migration State, or PMS-9, means authenticated state
describing the preparation, ownership, fencing, activation, and
reconciliation stages of an authority migration.
9.5.8 — Migration Authority Receipt
A Migration Authority Receipt, or MAR, means authenticated evidence
concerning a specified ownership transition.
A MAR is not automatically proof that every in-flight external effect
has completed.
9.5.9 — Source-Fencing Evidence
Source-Fencing Evidence, or SFE, means qualified protected
information establishing that specified source effectuation paths
have entered the required restricted state.
9.5.10 — Destination Effectuation Enablement
Destination Effectuation Enablement, or DEE, means non-bearer
protected authority permitting the destination to perform a defined
actual consequential operation.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.11 — Device Finality Sink
A Device Finality Sink, or DFS-9, means a controlled device,
software, hardware, network, storage, or actuator boundary enforcing
current operation-specific ownership and finality authority.
9.5.12 — Hardware Command Custody
Hardware Command Custody means protected control of the submission,
acceptance, dispatch, completion, cancellation, or fencing of effect-
capable hardware commands.
9.5.13 — In-Flight Effect Record
An In-Flight Effect Record, or IER-9, means protected information
identifying a command or consequential operation that may already
have crossed a relevant dispatch boundary.
9.5.14 — Protected Device Memory Custody
9.4.3.12. Source page 871 of the original technical specification
Protected Device Memory Custody means the authorized control of
device-associated memory, buffers, command descriptors, or sensitive
state during resource ownership.
9.5.15 — Reassignment Sanitization Evidence
Reassignment Sanitization Evidence, or RSE, means qualified
information supporting the state of device memory, keys, mappings, or
execution context after a reassignment procedure.
9.5.16 — Protected Device Identity
Protected Device Identity means an authenticated identity associated
with the relevant physical or virtual device and its applicable trust
configuration.
9.5.17 — Device Identity Generation
A Device Identity Generation means a protected identity version
distinguishing current device enrollment from older enrollment or
replacement state.
9.5.18 — Protected Command Generation
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A Protected Command Generation means an authenticated generation
associated with effect-capable command descriptors or dispatch
queues.
9.5.19 — Protected Ownership Barrier
A Protected Ownership Barrier means a verified transition preventing
an invalid combination of old-owner and new-owner effectuation
authority from becoming effective.
9.5.20 — Device Resource Rebinding
Device Resource Rebinding means an authenticated association between
the originally authorized logical resource and the destination's
actual physical or virtual resource.
9.5.21 — Protected Key Custody Transition
Protected Key Custody Transition means a protected operation
restricting, invalidating, deriving, reauthorizing, or activating
cryptographic material associated with a migrated effect.
9.5.22 — Migration-Replay Constraint
A Migration-Replay Constraint means a protected requirement
preventing unauthorized reuse of previously valid migration or
effectuation authority.
9.5.23 — Destination Readiness Evidence
Destination Readiness Evidence means authenticated information
supporting the destination's ability to enforce the required
effectuation controls.
9.5.24 — Device Enforcement-Coverage Commitment
9.4.3.13. Source page 872 of the original technical specification
A Device Enforcement-Coverage Commitment, or DECC, means protected
evidence associating a governed effect with the relevant software and
hardware effectuation paths.
9.5.25 — Protected Authority Recovery State
Protected Authority Recovery State means authenticated state
preserving the correct ownership and effectuation restrictions after
a crash, reset, partition, or failed migration.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.26 — Stale Owner
A Stale Owner means an execution entity whose earlier authority has
become invalid under current protected ownership state.
9.5.27 — Protected Fencing Domain
A Protected Fencing Domain means a defined collection of
consequential sinks whose coordinated enforcement is required for a
specified ownership-transfer guarantee.
9.5.28 — Bounded Resource Sublease
A Bounded Resource Sublease means a protected allowance permitting a
defined subset of resource or effectuation operations without
transferring unrestricted ownership.
9.5.29 — Pending-Operation Continuity Commitment
A Pending-Operation Continuity Commitment means a protected
association between the pre-migration Candidate Act and the actual
operation proposed after migration.
9.5.30 — Non-Effective Destination State
Non-Effective Destination State means a destination condition in
which received computational state cannot yet cause the governed
external effect.
9.6 — PROTECTED ORIGINAL OWNERSHIP
An unfinished Candidate Act may be associated with the current source
execution environment.
The protected ownership record identifies the relevant principal,
task, operation, effectuation resource, source identity, and
authority generation.
A representative record may comprise:
DEVICE_OWNERSHIP_AUTHORITY_RECORD = { record_version,
originating_candidate_act, authorized_effect_envelope,
current_owner_identity,
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.14. Source page 873 of the original technical specification
owner_device_identity, owner_device_generation, ownership_epoch,
permitted_resource_scope, designated_finality_sinks,
current_consumption_state, allowed_migration_policy,
revocation_reference, protected_record_authentication }
The record may be retained in protected hardware state, an
authoritative service, a transactional protected database, or another
suitable controlled mechanism.
A workload's self-declared owner identity is not sufficient.
The relevant Finality Sink verifies current ownership through
authenticated protected state.
9.7 — DEVICE IDENTITY AND ENROLLMENT
9.7.1 — Physical Device Identity
A protected device may possess an authenticated identity associated
with hardware keys, protected certificates, or equivalent trust
material.
9.7.2 — Virtual Device Identity
A virtual device may possess a protected identity bound to its
current execution environment and device-assignment state.
9.7.3 — Workload Identity
The computational workload may possess a distinct identity from the
device executing it.
9.7.4 — Finality-Sink Identity
The effectuation controller may possess an identity separate from the
requesting workload.
9.7.5 — Current Enrollment
A device identity is associated with a current protected enrollment
generation.
9.7.6 — Device Replacement
A replacement physical device may require re-enrollment rather than
automatically inheriting the old device's authority.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.7.7 — Attestation
9.4.3.15. Source page 874 of the original technical specification
Protected attestation evidence may assist in determining the device's
configuration.
9.7.8 — Attestation Limitation
A valid attestation does not independently prove exclusive authority
to produce a particular consequential effect.
9.7.9 — Key Rotation
Device identity credentials may be rotated without granting broader
effectuation authority.
9.7.10 — Compromised Identity
A compromised device credential may require current authorization
revocation and protection at the actual controlled sink.
9.8 — OWNERSHIP EPOCHS
A principal implementation uses an authoritative ownership
generation.
Each exclusive transfer creates a new generation or an equivalent
unambiguous protected ownership transition.
Conceptually:
OwnershipEpoch[n+1] > OwnershipEpoch[n]
The strict ordering must be established within the relevant authority
namespace.
An epoch may be a monotonic integer, a protected version, a
transaction-generation identifier, or an equivalent authenticated
state representation.
9.8.1 — Epoch Source
The epoch is issued or committed by an authorized protected ownership
controller.
9.8.2 — Epoch Scope
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The epoch applies to the defined authority, resource, or effectuation
domain.
9.8.3 — Epoch Freshness
An operation is not authorized solely because it carries some
previously valid epoch.
9.8.4 — Current State
The sink determines whether the presented ownership state is current
and applicable.
9.4.3.16. Source page 875 of the original technical specification
9.8.5 — Stale Epoch Rejection
An old owner presenting an invalid earlier epoch is rejected.
9.8.6 — Reboot Persistence
Where required, the controller retains sufficient protected state to
prevent rollback of accepted ownership generations.
9.8.7 — Epoch Wraparound
A finite numeric epoch may require protected exhaustion or re-
enrollment handling.
9.8.8 — Global Ordering Qualification
Separate devices maintaining independent counters do not
automatically establish one globally ordered ownership history.
A stronger implementation requires an authoritative ordering
relationship for the affected protected domain.
9.9 — MIGRATION PREPARATION
Before authority transfers, the destination may receive a prepared
computational context.
The destination remains non-effective for the governed consequence.
9.9.1 — Authenticate Destination
The protected system verifies destination identity.
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.9.2 — Check Destination Eligibility
The destination must be technically eligible to perform the specified
operation.
9.9.3 — Verify Resource Compatibility
The current destination resources must support the permitted effect.
9.9.4 — Verify Action Semantics
Different firmware, software, or hardware behavior may require
effect-compatibility evaluation.
9.9.5 — Verify Finality-Sink Coverage
The destination must possess suitable controls over relevant
effectuation paths.
9.4.3.17. Source page 876 of the original technical specification
9.9.6 — Prepare Computational State
The task context may be copied or reconstructed without activating
protected consequential authority.
9.9.7 — Protect Secrets
Reusable source credentials need not be copied into the destination's
ordinary computational environment.
9.9.8 — Record Pending Effects
The source identifies known in-flight consequential operations
requiring settlement, cancellation, or continued accounting.
9.9.9 — Establish Destination Readiness
An authenticated readiness record identifies the supported
destination configuration and enforcement capabilities.
9.9.10 — No Premature Activation
The destination does not become effective merely because the task
state has arrived.
9.10 — SOURCE-DEVICE FENCING
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The source fence may operate at one or more relevant boundaries.
9.10.1 — Application Dispatch Fence
A protected dispatcher refuses new consequential commands from a
stale source.
9.10.2 — Operating-System Fence
A protected operating-system component prevents the stale workload
from exercising specified privileged operations.
9.10.3 — Network Fence
A controlled network interface rejects source-originated
transmissions lacking current finality authority.
9.10.4 — Storage Fence
A storage controller rejects stale source writes or commits.
9.10.5 — Accelerator Fence
9.4.3.18. Source page 877 of the original technical specification
An accelerator dispatcher rejects unauthorized command submission or
activation.
9.10.6 — Hardware Actuator Fence
A protected actuator controller refuses stale-owner commands.
9.10.7 — Credential-Use Fence
A credential broker refuses reusable credential exercise on behalf of
a stale owner.
9.10.8 — Memory-Access Fence
A protected resource controller restricts stale device memory access
where applicable.
9.10.9 — Multiple Paths
Where the effect can arise through several interfaces, the required
paths must be covered.
9.10.10 — Fencing Evidence
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The controller may authenticate the state of relevant source fences.
9.10.11 — Fence Failure
A migration requiring exclusive enforcement must not treat a failed
mandatory source-fencing operation as successful merely because the
destination is ready.
9.11 — COMMAND-QUEUE CUSTODY
A critical technical problem arises where commands have been prepared
or queued before the source loses authority.
The system distinguishes:
A command generated but not submitted;
A command submitted but not accepted;
A command accepted by a controlled device;
A command dispatched for execution;
A command that has already caused a real effect;
And a command whose outcome remains uncertain.
9.11.1 — Queued but Unaccepted Commands
9.4.3.19. Source page 878 of the original technical specification
The protected dispatcher may invalidate unaccepted stale command
descriptors.
9.11.2 — Accepted but Undispatched Commands
A protected hardware queue may support cancellation, generation
checking, or equivalent dispatch-time authority verification.
9.11.3 — Already Dispatched Commands
A command may already be executing and may not be safely cancellable.
The system must determine the corresponding effectuation and recovery
semantics.
9.11.4 — Command Descriptor Binding
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A protected command descriptor may include the Candidate Act
reference, owner identity, authority epoch, effect scope, and sink
identity.
9.11.5 — Dispatch-Time Check
The protected controller verifies current authority when the command
reaches the consequential dispatch boundary.
9.11.6 — Queue Generation
The controller may associate accepted commands with a protected
command generation.
9.11.7 — Queue Flush
Where supported, the controller may flush or invalidate pending
commands before destination activation.
9.11.8 — Completion Drain
The controller may wait for outstanding commands to complete or reach
a defined safe state.
9.11.9 — Unknown Queue State
Where a mandatory queue cannot establish safe fencing or completion,
destination activation may remain withheld or be limited to a safe
recovery procedure.
9.11.10 — Technical Distinction
A software-level ownership update does not automatically revoke an
effect-capable command already held by independent hardware.
9.12 — DESTINATION ACTIVATION BARRIER
9.4.3.20. Source page 879 of the original technical specification
The destination activation condition may require:
Verified destination identity;
Current source authority;
Committed ownership transition;
Required source-fencing evidence;
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Valid destination enforcement coverage;
Resolved or explicitly governed in-flight effects;
Current operation semantics;
And valid destination-specific scoped finality enablement.
The exact combination depends upon the protected effect class and
migration protocol.
9.12.1 — Protected Ordering
A principal strict-exclusive implementation may require:
PREPARE_DESTINATION -> ESTABLISH_SOURCE_FENCES ->
RESOLVE_REQUIRED_IN_FLIGHT_STATE -> COMMIT_OWNERSHIP_TRANSITION ->
ACTIVATE_DESTINATION_AUTHORITY -> VERIFY_ACTUAL_EFFECT_AT_SINK
The listed ordering is an illustrative safe migration procedure.
Equivalent protected protocols may be used where they preserve the
required safety properties.
9.12.2 — Commit Barrier
The ownership transition is committed through an authoritative
protected state mechanism.
9.12.3 — Source Acknowledgements
Where required, the protected controller obtains qualified
acknowledgement from the relevant source sinks.
9.4.3.21. Source page 880 of the original technical specification
9.12.4 — Destination Non-Effective State
The destination remains unable to perform the governed effect until
the activation barrier passes.
9.12.5 — Partial Transfer
If only some effectuation paths can be safely transferred, the
protected controller may authorize a restricted subset rather than
assert full migration.
9.12.6 — Barrier Limitation
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A barrier that records only software intent does not establish
physical safety where unresolved hardware commands can still produce
effects.
9.13 — NON-BEARER DESTINATION ENABLEMENT
A destination-specific protected enablement may comprise:
DESTINATION_EFFECTUATION_ENABLEMENT = { enablement_version,
original_candidate_act_reference,
original_effect_envelope_commitment, destination_owner_identity,
destination_device_identity, destination_device_generation,
current_ownership_epoch, source_fencing_commitment,
required_command_state_commitment, actual_resource_identity,
permitted_operation_scope, designated_finality_sink,
operation_count_or_budget, current_revocation_reference,
protected_consumption_reference,
cryptographic_or_protected_authentication }
The enablement may be represented by a signed capability, protected
key activation, device-local state, secure command authorization,
hardware register condition, or equivalent non-bearer mechanism.
An exported copy does not automatically permit a different device or
sink to exercise it.
The requesting workload may retain a computational representation of
the task without possessing unrestricted effectuation authority.
9.4.3.22. Source page 881 of the original technical specification
9.14 — DESTINATION FINALITY-SINK VERIFICATION
The destination Finality Sink independently obtains or reconstructs
the actual pending operation.
The sink verifies:
The identity of the current authorized device or workload;
The current protected ownership epoch;
The actual resource being affected;
The applicable Candidate Act;
The permitted operation parameters;
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The current source-fencing and migration state where mandatory;
The destination enablement;
The current revocation state;
And protected consumption conditions.
The sink refuses effectuation if any mandatory predicate is absent,
stale, invalid, replayed, or mismatched.
The sink's role is not merely to confirm that the workload is running
on a trusted device.
It must verify authority over the particular effect being presented
at its controlled boundary.
9.15 — PREVENTING STALE AUTHORITY THROUGH OLD CREDENTIALS
9.15.1 — Reusable Credential Separation
A reusable credential may remain outside ordinary workload memory.
9.15.2 — Source Credential Invalidation
After a committed exclusive transfer, the source's protected
credential broker may refuse further use for the governed effect.
9.15.3 — Destination Credential Activation
A destination broker may use or derive the necessary credential
material only after current ownership verification.
9.4.3.23. Source page 882 of the original technical specification
9.15.4 — Scope Preservation
The credential-use operation remains bound to the original permitted
consequence.
9.15.5 — Non-Exportable Keys
Protected key material may remain non-exportable and be replaced by
newly authorized destination-bound material.
9.15.6 — Secret Copy Limitation
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Deleting a known copy of a secret does not prove that no additional
copy exists in untrusted memory.
9.15.7 — External Service Enforcement
Where an external service independently accepts old reusable
credentials, migration safety may require credential rotation,
service-side authority checks, or another effective restriction.
9.15.8 — Protected Release
The destination may exercise credentials through a protected
operation gateway rather than transferring reusable secrets to the
agent.
9.16 — DEVICE MEMORY OWNERSHIP AND SANITIZATION
Device memory may contain data, command buffers, intermediate
results, protected descriptors, or other state associated with a
previous owner.
9.16.1 — Protected Memory Classification
The controller identifies memory regions relevant to sensitive state
or effectuation authority.
9.16.2 — Reassignment Preparation
The device enters an appropriate restricted state before
reassignment.
9.16.3 — Device Reset
A supported device reset may clear selected internal state.
The implementation must account for the actual guarantees of the
reset mechanism.
9.16.4 — Memory Scrubbing
Selected memory regions may be overwritten or otherwise sanitized
where technically effective.
9.4.3.24. Source page 883 of the original technical specification
9.16.5 — Cryptographic Erasure
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A memory region protected by suitably implemented encryption may
become inaccessible after relevant decryption key destruction.
This guarantee depends upon the encryption, key storage, and hardware
assumptions.
9.16.6 — Protected Mapping Revocation
Old memory mappings may be invalidated.
9.16.7 — Command Buffer Disposal
Stale effect-capable command descriptors may be removed, invalidated,
or fenced.
9.16.8 — Sensitive State Custody
The destination may receive only the task state required for
continued authorized computation.
9.16.9 — Sanitization Evidence
The protected controller may authenticate the reset, erasure, or
mapping transition under the supported hardware assurance model.
9.16.10 — No Universal Zeroization Assumption
A successful software memory-clearing call does not prove elimination
of every copy or remanent hardware state.
9.17 — DIRECT-MEMORY-ACCESS AND DEVICE ISOLATION
A hardware device may access system memory independently of the
requesting application.
The protected system may employ an appropriate memory or device
access controller to constrain such access.
9.17.1 — Authorized Address Regions
The device receives access only to the memory regions permitted by
the current protected assignment.
9.17.2 — Reassignment
Old mappings are invalidated before the corresponding memory is
exposed to the new owner.
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.17.3 — Address-Translation State
9.4.3.25. Source page 884 of the original technical specification
The implementation may require suitable invalidation of cached
translation or permission state.
9.17.4 — Pending DMA Operations
Outstanding transfers may need to drain, abort, or be otherwise
accounted for.
9.17.5 — Device Grouping
Hardware isolation granularity may be coarser than one logical
device.
The reassignment procedure must respect the actual hardware isolation
boundary.
9.17.6 — Unsafe Configuration
An implementation operating without required hardware isolation
cannot claim the same protections as one enforcing protected memory-
access boundaries.
9.17.7 — Finality Relationship
Memory isolation assists in preventing unauthorized access but does
not replace verification of operation-specific authority at the
relevant consequential sink.
9.18 — PEER-TO-PEER DEVICE EFFECTS
Two devices may exchange data or effect-capable commands without
every transfer passing through the primary host application.
A protected system must identify whether such a path is relevant to
the claimed authority boundary.
9.18.1 — Device-to-Device Memory Transfer
A protected controller may restrict peer-memory access to currently
authorized devices.
9.18.2 — Peer Command Submission
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An effect-capable peer command may require corresponding protected
authority.
9.18.3 — Interconnect Isolation
The actual hardware interconnect may impose constraints different
from ordinary processor memory isolation.
9.18.4 — Device Reassignment
The system may invalidate old peer mappings and associated command
authority.
9.4.3.26. Source page 885 of the original technical specification
9.18.5 — Control Coverage
Where peer-to-peer operations can bypass the intended Finality Sink,
additional mediation or an explicitly narrower enforcement guarantee
is required.
9.18.6 — Future Hardware
The same principles may apply to advanced accelerator interconnects,
chiplet fabrics, programmable devices, and other shared hardware
communication systems.
9.19 — DEVICE RESOURCE IDENTITY
Migration may change the physical or virtual identifier associated
with the affected resource.
9.19.1 — Logical Resource
The Candidate Act may identify a logical resource.
9.19.2 — Actual Physical Resource
The destination sink may control a specific physical device, storage
object, endpoint, or actuator.
9.19.3 — Protected Correspondence
A protected resolver verifies that the actual resource corresponds to
the originally authorized resource.
9.19.4 — Resource Version
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The resource may have changed since the original authorization.
9.19.5 — Device Replacement
A replacement device may implement different operating limits or
semantics.
9.19.6 — Effect Compatibility
The actual operation after migration must remain within the
applicable authorized effect envelope.
9.19.7 — Failure
Unknown or incompatible resource correspondence causes withholding or
separately authorized recovery.
9.4.3.27. Source page 886 of the original technical specification
9.20 — SNAPSHOT AND CLONE RESISTANCE
9.20.1 — Snapshot Creation
A workload state may be captured before migration.
9.20.2 — Authority State Separation
Operation-specific effectuation authority may remain external to the
copyable snapshot.
9.20.3 — Clone Creation
Several execution instances may be created from the same snapshot.
9.20.4 — Current Ownership Requirement
Each clone must independently establish applicable current authority
before consequential effectuation.
9.20.5 — Duplicate Credentials
A copied credential cannot independently authorize an operation if
the protected sink requires current ownership and scope.
9.20.6 — Protected Counter State
Consumption counters or epochs used for authority must not be
unsafely restored by copying ordinary virtual-machine memory.
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.20.7 — Destination Rebinding
A new execution instance may require authenticated rebinding to a
particular protected sink.
9.20.8 — Existing Real Effects
A snapshot taken before an external effect cannot be replayed as if
the earlier effect never occurred.
9.20.9 — Optional Causal Receipt
Where continuation depends upon an earlier real effect, the
applicable CW-2 receipt condition remains mandatory.
9.21 — CURRENT AUTHORITY ACROSS NETWORK PARTITIONS
9.21.1 — Partition Scenario
The source becomes disconnected from the ownership authority.
9.4.3.28. Source page 887 of the original technical specification
9.21.2 — Stale Local Knowledge
The source may not know that ownership has transferred.
9.21.3 — Resource-Sink Enforcement
Where a protected sink has authoritative current state, stale
operations are rejected.
9.21.4 — Offline Resource
Where the sink itself is disconnected, immediate remote revocation
cannot be assumed.
9.21.5 — Bounded Leases
The system may use limited-duration or limited-operation authority
under explicit offline assumptions.
9.21.6 — Exclusive Transfer
If both source and destination can independently effectuate the same
resource without authoritative fencing, strict exclusive ownership
cannot be guaranteed.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.21.7 — Safe Restriction
The protected system may withhold destination activation until the
necessary source-fencing condition can be established.
9.21.8 — Safety Versus Availability
A system may prioritize strict exclusivity over uninterrupted
operation when authoritative state is unavailable.
9.21.9 — Deferred Recovery
After reconnection, protected ownership and effectuation state are
reconciled.
9.22 — DEVICE FAILURE AND RECOVERY
9.22.1 — Source Failure Before Migration
The protected system determines the current source ownership and in-
flight effects.
9.22.2 — Failure During Destination Preparation
The destination remains non-effective unless valid activation
authority exists.
9.22.3 — Failure During Source Fencing
9.4.3.29. Source page 888 of the original technical specification
The system must determine whether the required fences actually became
effective.
9.22.4 — Failure After Ownership Commit
The destination may recover current authority from protected state.
9.22.5 — Destination Failure Before Effectuation
The operation may be reassigned through another valid protected
transition.
9.22.6 — Destination Failure After Dispatch
The actual effect outcome may be uncertain.
9.22.7 — Duplicate Prevention
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A retry requires appropriate current authority and effect-specific
replay checks.
9.22.8 — Protected Recovery Record
The controller may maintain an authenticated state identifying the
last known ownership and effectuation transitions.
9.22.9 — New Recovery Candidate Act
Corrective actions capable of producing additional real effects
require valid protected authority.
9.23 — PHYSICAL ACTUATION DURING MIGRATION
A hardware-controlled physical effect may already be in progress when
ownership changes.
Examples include a mechanical movement, electrical switching
operation, industrial command, or vehicle-control action.
9.23.1 — Safe Operating State
The controller identifies the relevant safe state or operating
envelope.
9.23.2 — In-Progress Operation
The system distinguishes an operation already producing a physical
effect from an unexecuted queued command.
9.23.3 — Immediate Revocation Limits
A physical command may not be safely interrupted instantaneously.
9.4.3.30. Source page 889 of the original technical specification
9.23.4 — Controlled Completion
The protected controller may allow completion of an already
authorized bounded physical phase under a defined safety rule.
9.23.5 — Successor Authority
The destination's new commands remain subject to current ownership
and actual operation verification.
9.23.6 — Transition Interlock
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A hardware interlock may prevent simultaneous conflicting commands
from the source and destination.
9.23.7 — Safety Priority
The architecture may include separately authenticated emergency-
control authority.
Such an emergency mode does not constitute an unrestricted bypass of
normal finality constraints.
9.23.8 — Actual Outcome
The result of an in-progress physical operation may require qualified
observation before a dependent successor action is permitted.
9.24 — REPRESENTATIVE PROTECTED MIGRATION RECORD
PROTECTED_MIGRATION_RECORD = { record_version,
original_candidate_act, permitted_effect_envelope,
migration_identifier, source_device_identity,
source_device_generation, destination_device_identity,
destination_device_generation, previous_ownership_epoch,
proposed_ownership_epoch, current_resource_identity,
source_fencing_scope, source_fencing_evidence,
in_flight_effect_references, command_queue_state,
relevant_memory_custody_state, destination_readiness_evidence,
current_action_contract,
9.4.3.31. Source page 890 of the original technical specification
required_finality_sinks, source_authority_status,
destination_activation_status, protected_migration_authentication }
A protected implementation may divide this information among
authenticated records.
The record does not automatically prove physical completion of all
effects mentioned in it.
Each assurance depends upon the source and quality of the
corresponding evidence.
9.25 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Identify Unfinished Candidate Act.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected controller identifies the operation whose consequential
authority may move.
Step 2 — Obtain Current Ownership State.
The controller verifies the currently authorized execution owner and
applicable epoch.
Step 3 — Authenticate Destination.
The proposed receiving environment establishes its protected
identity.
Step 4 — Verify Destination Capabilities.
The controller evaluates relevant hardware, software, operation
semantics, and finality-enforcement capabilities.
Step 5 — Prepare Destination Context.
Computational state may be transferred into a non-effective
destination environment.
Step 6 — Identify Source Effectuation Paths.
The controller identifies the relevant application, network, storage,
hardware, and other effect-capable paths.
Step 7 — Identify In-Flight Operations.
Relevant accepted or already dispatched commands are classified.
Step 8 — Prepare Source Fences.
The system establishes the controls required to prevent stale source
continuation.
9.4.3.32. Source page 891 of the original technical specification
Step 9 — Resolve Hardware Command State.
Pending commands are cancelled, drained, continued under a bounded
rule, or recorded as unresolved.
Step 10 — Restrict Source Credentials.
Reusable credential paths are revoked or otherwise constrained where
required.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Step 11 — Protect Memory and Device State.
Relevant mappings, buffers, and sensitive state are secured according
to the selected hardware assurance model.
Step 12 — Verify Source-Fencing Conditions.
The controller obtains qualified protected evidence for mandatory
effectuation paths.
Step 13 — Commit Ownership Transition.
The authoritative controller advances the protected ownership
generation.
Step 14 — Prepare Destination Enablement.
A destination-specific non-bearer effectuation authority is created
or activated.
Step 15 — Verify Current Resource Binding.
The destination's actual resources are compared with the originally
authorized effect.
Step 16 — Present Actual Operation.
The destination workload proposes its consequential command.
Step 17 — Reconstruct Actual Pending Operation.
The destination Finality Sink obtains the operation at its controlled
boundary.
Step 18 — Verify Current Ownership.
The sink checks the current owner identity and authoritative epoch.
Step 19 — Verify Scoped Authority.
The sink checks the Candidate Act, effect envelope, destination
enablement, and current protected state.
Step 20 — Verify Relevant Fencing or Migration State.
Required ownership-barrier conditions are established.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.33. Source page 892 of the original technical specification
Step 21 — Atomically Reserve or Consume Authority.
The sink performs the applicable protected authority transition.
Step 22 — Permit Consequential Effect.
The real operation is enabled only under the valid protected
conditions.
Step 23 — Record Effectuation State.
The system commits appropriate attempt and consumption evidence.
Step 24 — Reconcile Actual Outcomes.
Where required, qualified effect evidence establishes what actually
occurred.
Step 25 — Complete or Recover.
Remaining operations proceed only under current protected authority.
9.26 — REFERENCE PSEUDOCODE: DESTINATION PREPARATION
FUNCTION PREPARE_AUTHORITY_MIGRATION( candidate_act, source_device,
destination_device, ownership_controller ): REQUIRE
VERIFY_CURRENT_CANDIDATE_ACT( candidate_act ) REQUIRE
VERIFY_SOURCE_DEVICE_IDENTITY( source_device ) REQUIRE
VERIFY_CURRENT_SOURCE_OWNERSHIP( source_device, candidate_act )
REQUIRE VERIFY_DESTINATION_DEVICE_IDENTITY( destination_device )
REQUIRE VERIFY_DESTINATION_EFFECT_COMPATIBILITY( destination_device,
9.4.3.34. Source page 893 of the original technical specification
candidate_act ) REQUIRE VERIFY_DESTINATION_FINALITY_COVERAGE(
destination_device, candidate_act ) context =
PREPARE_NON_EFFECTIVE_CONTEXT( candidate_act, destination_device )
pending_effects = CLASSIFY_IN_FLIGHT_EFFECTS( source_device,
candidate_act ) prepared = ownership_controller
.ATOMIC_PREPARE_MIGRATION({ candidate_act: HASH(candidate_act),
source: source_device.identity, destination:
destination_device.identity, previous_epoch:
CURRENT_OWNERSHIP_EPOCH(), prepared_context: HASH(context),
pending_effects: HASH(pending_effects), destination_activation:
DISABLED }) RETURN prepared
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.27 — REFERENCE PSEUDOCODE: SOURCE FENCING
FUNCTION FENCE_SOURCE_EFFECTUATION( prepared_migration,
source_controller ):
9.4.3.35. Source page 894 of the original technical specification
REQUIRE VERIFY_PREPARED_MIGRATION( prepared_migration )
required_sinks = RESOLVE_REQUIRED_SOURCE_SINKS( prepared_migration )
FOR EACH sink IN required_sinks: REQUIRE
sink.VERIFY_CONTROLLER_IDENTITY() fence_result =
sink.ESTABLISH_FENCE({ candidate_act:
prepared_migration.candidate_act, source_owner:
prepared_migration.source, next_epoch:
prepared_migration.proposed_epoch }) IF fence_result != VERIFIED:
RETURN SOURCE_FENCING_INCOMPLETE queue_result =
RESOLVE_REQUIRED_COMMAND_QUEUES( prepared_migration ) IF queue_result
NOT IN ACCEPTABLE_STATES: RETURN PENDING_HARDWARE_UNRESOLVED evidence
= source_controller .AUTHENTICATE_FENCING_STATE({ required_sinks:
HASH(required_sinks), queue_state: HASH(queue_result), migration:
HASH(prepared_migration) }) RETURN evidence
The result is valid only for the effectuation paths and hardware
conditions actually covered.
9.4.3.36. Source page 895 of the original technical specification
9.28 — REFERENCE PSEUDOCODE: OWNERSHIP COMMIT
FUNCTION COMMIT_EXCLUSIVE_MIGRATION( prepared_migration,
fencing_evidence, protected_ownership_controller ): REQUIRE
VERIFY_PREPARED_MIGRATION( prepared_migration ) REQUIRE
VERIFY_SOURCE_FENCING_EVIDENCE( fencing_evidence ) REQUIRE
VERIFY_DESTINATION_READINESS( prepared_migration.destination )
REQUIRE VERIFY_REQUIRED_IN_FLIGHT_STATE( prepared_migration )
committed = protected_ownership_controller
.ATOMIC_COMPARE_AND_TRANSFER({ authority:
prepared_migration.candidate_act, expected_owner:
prepared_migration.source, expected_epoch:
prepared_migration.previous_epoch, new_owner:
prepared_migration.destination, new_epoch:
NEXT_AUTHORITATIVE_EPOCH(), source_fencing: HASH(fencing_evidence) })
IF committed != COMMITTED: RETURN MIGRATION_UNRESOLVED RETURN
PROTECTED_MIGRATION_RECEIPT( committed )
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.37. Source page 896 of the original technical specification
9.29 — REFERENCE PSEUDOCODE: DESTINATION FINALITY
FUNCTION EFFECTUATE_AFTER_DEVICE_MIGRATION( candidate_act,
migration_reference, destination_finality_sink ): actual_operation =
destination_finality_sink .RECONSTRUCT_PENDING_OPERATION() IF
actual_operation IS NULL: RETURN DENY migration =
RESOLVE_PROTECTED_MIGRATION( migration_reference ) REQUIRE
VERIFY_MIGRATION_AUTHENTICITY( migration ) REQUIRE
destination_finality_sink .VERIFY_CURRENT_DESTINATION_IDENTITY()
REQUIRE destination_finality_sink .VERIFY_CURRENT_OWNERSHIP_EPOCH(
migration ) REQUIRE destination_finality_sink
.VERIFY_SOURCE_FENCING_CONDITIONS( migration ) REQUIRE
destination_finality_sink .VERIFY_ACTUAL_RESOURCE_BINDING(
actual_operation, candidate_act ) REQUIRE destination_finality_sink
.VERIFY_EFFECT_SCOPE( actual_operation, candidate_act ) REQUIRE
destination_finality_sink
9.4.3.38. Source page 897 of the original technical specification
.VERIFY_CURRENT_ACTION_CONTRACT() REQUIRE destination_finality_sink
.VERIFY_NON_BEARER_ENABLEMENT( migration, actual_operation ) REQUIRE
destination_finality_sink .VERIFY_REVOCATION_AND_CONSUMPTION()
consumption = destination_finality_sink
.ATOMIC_CONSUME_FINALITY_AUTHORITY( actual_operation, migration ) IF
consumption != SUCCESS: RETURN DENY RETURN destination_finality_sink
.EFFECTUATE( actual_operation, consumption )
9.30 — REFERENCE PSEUDOCODE: STALE OWNER REJECTION
FUNCTION VERIFY_EFFECTUATION_OWNER( presented_owner, presented_epoch,
actual_operation, protected_sink ): current = protected_sink
.LOAD_AUTHORITATIVE_OWNERSHIP( actual_operation.resource_identity )
REQUIRE VERIFY_PROTECTED_STATE( current ) IF presented_owner !=
current.owner_identity: RETURN DENY_STALE_OR_WRONG_OWNER IF
presented_epoch != current.epoch: RETURN DENY_INVALID_EPOCH
9.4.3.39. Source page 898 of the original technical specification
REQUIRE VERIFY_OPERATION_SCOPE( actual_operation, current.authority )
REQUIRE VERIFY_CURRENT_SINK_STATE() RETURN PASS
A simple local comparison against an obsolete cache does not
establish current ownership where the trust model requires
authoritative synchronization.
9.31 — REFERENCE PSEUDOCODE: HARDWARE REASSIGNMENT
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
FUNCTION REASSIGN_EFFECT_CAPABLE_DEVICE( device, previous_owner,
next_owner, protected_device_controller ): REQUIRE
VERIFY_DEVICE_IDENTITY(device) REQUIRE VERIFY_CURRENT_ASSIGNMENT(
device, previous_owner ) REQUIRE BLOCK_NEW_SOURCE_COMMANDS(device)
REQUIRE RESOLVE_OUTSTANDING_DEVICE_COMMANDS( device ) REQUIRE
INVALIDATE_OLD_MEMORY_MAPPINGS( device ) REQUIRE
INVALIDATE_REQUIRED_PEER_ACCESS( device ) sanitization =
PERFORM_SUPPORTED_DEVICE_SANITIZATION( device ) IF sanitization NOT
SUFFICIENT_FOR_POLICY: RETURN REASSIGNMENT_DENIED
9.4.3.40. Source page 899 of the original technical specification
new_assignment = protected_device_controller
.ATOMIC_COMMIT_ASSIGNMENT({ device: device.identity, previous_owner:
previous_owner.identity, next_owner: next_owner.identity,
new_generation: NEXT_DEVICE_GENERATION(), sanitization:
HASH(sanitization) }) REQUIRE VERIFY_NEW_ASSIGNMENT_ISOLATION(
new_assignment ) RETURN new_assignment
The actual completeness of sanitization must be supported by the
device's known technical guarantees.
9.32 — WORKED EXAMPLE A: MIGRATING AN AUTONOMOUS AGENT BETWEEN
DEVICES
An autonomous assistant prepares a consequential file modification on
a first device.
The task must migrate to a second device before the modification
occurs.
The original Candidate Act identifies the permitted file and
operation.
The destination receives the computational task context.
However, its protected Finality Sink remains unable to perform the
modification.
The ownership controller establishes that the first device is the
current owner.
The protected system fences the first device's relevant file-
modification and credential-use paths.
The controller commits a new ownership epoch naming the destination.
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The second device receives operation-specific non-bearer finality
enablement.
9.4.3.41. Source page 900 of the original technical specification
Before executing the file modification, the destination Finality Sink
verifies the current owner, epoch, actual file identity, and
operation parameters.
A delayed operation from the first device is rejected at the
protected controlled resource.
The migration of task memory therefore does not become an
uncontrolled duplication of effectuation authority.
9.33 — WORKED EXAMPLE B: SUSPENDED VIRTUAL MACHINE RESUMES AFTER
AUTHORITY TRANSFER
A virtual machine is authorized to issue a defined storage operation.
The virtual machine pauses for an extended period.
During the pause, the task moves to another execution environment.
An authoritative ownership transition establishes a new owner.
The original virtual machine later resumes from its suspended state.
Its memory contains an earlier ownership reference.
The virtual machine attempts to perform the storage operation.
The storage Finality Sink obtains the actual pending write.
It verifies the current protected ownership state.
Because the resumed virtual machine presents stale authority, the
operation is refused.
The safety condition is enforced at the affected resource rather than
depending upon the stale virtual machine voluntarily recognizing its
loss of ownership.
9.34 — WORKED EXAMPLE C: ACCELERATOR COMMAND QUEUE DURING MIGRATION
A protected autonomous workload uses a hardware accelerator.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Before migration, it submits several commands into an accelerator
queue.
The ownership controller proposes transferring execution to another
device.
The source-fencing controller blocks new source submissions.
It identifies commands still pending in the hardware queue.
9.4.3.42. Source page 901 of the original technical specification
Commands that have not been dispatched may be cancelled or
invalidated under the supported controller mechanism.
Commands already executing are classified according to their possible
external effects.
Where required, the protected system drains or accounts for those
commands before activating equivalent destination authority.
The destination's command dispatcher verifies the new ownership
generation and actual command scope.
This example addresses the gap between changing software ownership
and controlling commands already held by hardware.
9.35 — WORKED EXAMPLE D: DEVICE MEMORY REASSIGNMENT
A device with dedicated memory is assigned to an autonomous workload.
The device stores intermediate data and command descriptors.
The device is later reassigned to another workload.
The protected controller prevents new old-owner commands and resolves
outstanding work.
It invalidates applicable memory mappings.
It performs the supported reset, clearing, cryptographic erasure, or
other sanitization procedure required by the protected policy.
The controller records qualified sanitization evidence.
Only then is the device made available to the new owner under current
protected assignment state.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The new workload does not acquire authority to read or execute old-
owner protected state merely because it now controls the device.
The guarantee depends upon the particular hardware's actual isolation
and sanitization properties.
9.36 — WORKED EXAMPLE E: OFFLINE AUTONOMOUS DEVICE
A remote autonomous device has a bounded authorization to perform
selected operations.
Communication with the central ownership service becomes unavailable.
9.4.3.43. Source page 902 of the original technical specification
The device continues only within the authority allowed by its
protected offline lease.
A second device is proposed as the new owner.
Where strict exclusivity is required, the central system must not
assume that the disconnected source has stopped acting merely because
an ownership record has changed.
The new owner's activation may be withheld until the necessary
fencing or lease-expiration conditions are satisfied.
Alternatively, authority may be partitioned into nonoverlapping
bounded effect sets where such operation is expressly permitted.
The example illustrates the tradeoff between availability and
exclusive effectuation safety.
9.37 — WORKED EXAMPLE F: MIGRATED DEVICE CONTROLS A PHYSICAL ACTUATOR
An autonomous controller prepares a physical movement command.
The task transfers to another protected processor while the actuator
remains attached to a shared hardware controller.
The protected actuator interface identifies the current ownership
epoch.
The source processor is fenced from issuing further valid commands.
The destination controller obtains the current operation envelope.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Before the actual command is accepted, the actuator Finality Sink
verifies the destination identity, ownership, physical target,
command parameters, and applicable safety state.
A stale processor's delayed movement command is rejected.
Where a previous physical movement was already underway, the
protected system accounts for that actual operation and applies the
relevant safe transition or bounded-completion policy.
It does not assume the movement was reversed by the ownership
transfer.
9.38 — WORKED EXAMPLE G: SNAPSHOT-CLONED AUTONOMOUS WORKLOAD
A protected workload is captured in a snapshot.
Two execution instances are created from the snapshot.
9.4.3.44. Source page 903 of the original technical specification
Both possess the same task instructions and computational context.
The protected effectuation authority is maintained separately from
the copyable workload state.
Only one instance is designated as the current owner for the relevant
exclusive operation.
The nonowner instance may perform permitted computation but cannot
exercise valid finality authority at the protected effectuation
boundary.
An attempt to reuse an earlier authority reference is rejected
according to current ownership and consumption state.
This example distinguishes identical computational state from valid
consequential authority.
9.39 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
9.39.1 — Stale Owner Replay
An earlier execution owner attempts to use an old authorization after
ownership transfer.
The sink verifies current protected ownership state.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.39.2 — Cloned Workload Authority
An attacker clones a workload containing old authority references.
Copying the workload does not create valid additional effectuation
ownership.
9.39.3 — Stale Source Credential
The source retains a reusable credential.
The protected credential-exercise path rejects unauthorized stale-
owner use.
9.39.4 — False Ownership Epoch
An attacker invents a larger-looking epoch value.
The sink requires authoritative protected state and valid
authentication.
9.39.5 — Epoch Rollback
An attacker restores earlier ownership state.
Protected monotonic state or authoritative verification rejects
invalid rollback.
9.39.6 — Epoch Namespace Confusion
9.4.3.45. Source page 904 of the original technical specification
An epoch from one resource or ownership namespace is presented for
another.
The sink verifies the required authority and resource binding.
9.39.7 — Migration Receipt Forgery
An attacker fabricates a completed-migration record.
The controller verifies the issuing authority and required state.
9.39.8 — Destination Identity Forgery
An attacker claims to be the authorized receiving device.
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination identity must satisfy the protected enrollment and
proof requirements.
9.39.9 — Device Replacement Substitution
An unauthorized physical replacement presents an old logical device
name.
The system verifies current protected device identity and generation.
9.39.10 — Source-Fence Omission
A migration controller activates the destination without fencing a
required source path.
The protected activation barrier refuses the unsupported transition.
9.39.11 — Queued Command Replay
A stale command remains in a device queue after migration.
The command controller verifies current authority at the relevant
dispatch boundary.
9.39.12 — Delayed Hardware Execution
A previously accepted command executes after the ownership
transition.
The system requires appropriate in-flight handling and does not
assume retrospective prevention.
9.39.13 — Command Descriptor Mutation
A command buffer changes after authorization.
The controller verifies protected command integrity or the actual
operation before consequential dispatch.
9.39.14 — Direct-Memory-Access Persistence
9.4.3.46. Source page 905 of the original technical specification
A stale device retains access to memory through old mappings.
The protected reassignment procedure invalidates required mappings
and translation state.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.39.15 — Peer-to-Peer Bypass
An accelerator communicates with another device through a route that
avoids the host application gate.
Relevant peer paths must be controlled within the asserted security
coverage.
9.39.16 — Device Memory Remanence
A new owner attempts to recover previous-owner information from
retained device memory.
The system applies the required isolation and sanitization
mechanisms.
9.39.17 — Secret Extraction
A stale workload attempts to use or export old cryptographic
material.
Protected key custody and external sink authority limit the governed
effects.
9.39.18 — Snapshot Counter Rollback
An attacker restores an earlier consumption counter from a workload
snapshot.
Authoritative protected consumption state prevents unauthorized
reuse.
9.39.19 — Split-Brain Device Ownership
Two devices simultaneously claim exclusive authority.
The relevant resource sinks enforce the same authoritative ownership
relationship.
9.39.20 — Network Partition
A disconnected source continues relying upon stale local authority.
The selected lease and fencing model determines which operations
remain valid.
9.39.21 — False Lease Expiry Assumption
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The controller assumes that a timed-out owner has physically stopped
executing.
The protected system requires suitable resource-level enforcement
before asserting strict exclusivity.
9.39.22 — Unauthorized Migration
9.4.3.47. Source page 906 of the original technical specification
A workload attempts to move itself to a more privileged device
without valid transfer authority.
The ownership controller rejects the unsupported migration.
9.39.23 — Privileged Destination Escalation
A destination possesses broader native device permissions than the
source.
The actual operation remains limited to the originating authorized
effect envelope.
9.39.24 — Resource Rebinding Attack
A migrated operation is redirected to a different physical target.
The destination sink verifies current resource correspondence.
9.39.25 — Firmware Semantic Change
A device command changes meaning after firmware modification.
Current operation-contract verification identifies relevant
incompatibility.
9.39.26 — Device Reset Overclaim
A reset procedure is treated as proof that all memory and command
state disappeared.
The system relies only upon the reset's supported guarantees.
9.39.27 — Interrupted Migration Commit
A failure occurs during the authority transition.
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Protected recovery logic determines authoritative ownership before
effectuation resumes.
9.39.28 — Duplicate External Command
Both source and destination attempt the same consequential operation.
Sink-local consumption and current ownership checks prevent
unauthorized duplicate exercise.
9.39.29 — Unknown Effect Outcome
A source command may have caused an effect before the transfer.
The system preserves uncertainty and requires suitable reconciliation
before unsafe repetition.
9.39.30 — False Source-Fencing Evidence
9.4.3.48. Source page 907 of the original technical specification
An untrusted source process reports that it has stopped.
The stronger protocol requires qualified evidence from the relevant
protected control boundary.
9.39.31 — Bypass Through Uncovered Network Interface
The stale device uses another transmission interface.
The protected coverage must include relevant alternate egress paths.
9.39.32 — Bypass Through Uncovered Storage Interface
A stale workload writes directly through a lower-level storage path.
The storage Finality Sink or equivalent protected controller must
enforce ownership.
9.39.33 — Bypass Through Accelerator Egress
A device produces external effects without host-dispatch mediation.
Relevant hardware effectuation controls are required.
9.39.34 — Compromised Ownership Controller
An attacker controls the authority issuing ownership state.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The assurance depends upon the selected controller trust model and
any independent protections.
9.39.35 — Compromised Finality Sink
An attacker compromises the actual controlled resource interface.
A stronger guarantee requires an additional independently enforcing
boundary or a narrower trust claim.
9.39.36 — Verification Exhaustion
An attacker submits excessive migration or hardware-state evidence.
The protected verifier imposes suitable bounded resource checks.
9.39.37 — Emergency Override Abuse
A workload attempts to label an unauthorized effect as an emergency
command.
The protected system requires authenticated emergency authority and a
defined bounded operating mode.
9.4.3.49. Source page 908 of the original technical specification
9.39.38 — Revocation After Transfer
The original principal revokes the unfinished operation after
ownership changes.
The destination sink verifies current applicable revocation state.
9.39.39 — New Hardware Interface After Update
A software or firmware update introduces a new effect-capable route.
The relevant coverage state is revalidated.
9.39.40 — Malicious Recovery Action
An agent proposes an additional consequence to repair a failed
migration.
The recovery Candidate Act requires its own valid effectuation
authority.
9.40 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The following experiments are proposed and are not statements of
completed testing.
Experiment 1 — Basic Exclusive Transfer: Transfer a protected
unfinished operation between two simulated devices.
Experiment 2 — Source-Fencing Verification: Confirm that the original
device cannot effectuate after committed transfer.
Experiment 3 — Destination Activation Barrier: Attempt destination
effectuation before required source fencing is established.
Experiment 4 — Stale Owner Epoch: Present an earlier valid ownership
generation to the actual resource sink.
Experiment 5 — Forged Epoch: Present an unauthenticated larger epoch
value.
Experiment 6 — Snapshot Cloning: Start multiple instances from one
computational snapshot and verify exclusive effectuation.
Experiment 7 — Suspended Process Resume: Resume a paused source after
destination ownership is established.
Experiment 8 — Device Identity Change: Replace the destination
identity and verify binding failure.
Experiment 9 — Protected Credential Reuse: Attempt stale source
credential exercise.
9.4.3.50. Source page 909 of the original technical specification
Experiment 10 — Non-Exportable Destination Authority: Verify that a
copied authority reference is unusable at an unintended device.
Experiment 11 — Queue Submission Fence: Block new source commands
after migration preparation.
Experiment 12 — Pending Queue Cancellation: Invalidate undispatched
commands through a supported controller.
Experiment 13 — Already Dispatched Command: Examine safe recovery
when a command cannot be cancelled.
Experiment 14 — Command Generation: Reject stale queued descriptors
with an earlier protected generation.
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Experiment 15 — Device Memory Reassignment: Reassign a device
following the required memory-state procedure.
Experiment 16 — Memory Mapping Invalidation: Verify that old device
mappings are no longer valid.
Experiment 17 — Outstanding DMA: Simulate a transfer pending at the
time of reassignment.
Experiment 18 — Peer-to-Peer Device Access: Test whether an alternate
device path bypasses the selected protected controller.
Experiment 19 — Protected Key Rotation: Activate destination-bound
key material while restricting old source use.
Experiment 20 — Storage Resource Identity: Verify the actual
destination resource against the authorized logical object.
Experiment 21 — Firmware Semantic Change: Test rejection when the
actual destination command meaning changes.
Experiment 22 — Network Partition: Disconnect the source during
proposed ownership transfer.
Experiment 23 — Offline Bounded Lease: Exercise only authorized
offline operations while disconnected.
Experiment 24 — Split-Brain Simulation: Cause two devices to claim
current exclusive ownership.
Experiment 25 — Crash Before Commit: Recover an unfinished prepared
migration.
Experiment 26 — Crash After Commit: Recover authoritative ownership
after the transfer has completed.
9.4.3.51. Source page 910 of the original technical specification
Experiment 27 — Crash After Effect Dispatch: Preserve uncertain or
completed external effect state.
Experiment 28 — Ownership Rollback: Restore a stale ownership
database or snapshot.
Experiment 29 — Concurrent Migration Attempt: Submit two competing
destination transfers.
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Experiment 30 — Shared Resource Sink: Verify that source and
destination use one authoritative current owner at the controlled
resource.
Experiment 31 — Device Sanitization Evidence: Evaluate supported
reset, clearing, or cryptographic-erasure evidence.
Experiment 32 — Direct Hardware Command: Attempt stale-owner
effectuation through a device-level interface.
Experiment 33 — Physical Actuator Migration: Transfer control without
permitting simultaneous conflicting commands.
Experiment 34 — Cross-Provider Destination: Verify migrated authority
at an independently administered protected sink.
Experiment 35 — Causal Receipt Integration: Require a validated prior
real-effect receipt before a post-migration successor phase.
Experiment 36 — Effect-Conflict Integration: Test ownership migration
alongside protected cross-agent effect reservations.
Experiment 37 — Current Contract Verification: Verify actual
destination operation semantics following a software update.
Experiment 38 — Protected Verification Work: Bound the cost of
processing malformed or excessive migration evidence.
Experiment 39 — Single-Component Prototype: Implement the ownership
authority and finality controller within one protected environment.
Experiment 40 — Distributed Hardware Prototype: Place source,
destination, ownership controller, and affected sink in distinct
environments.
Experiment 41 — Delayed Network Message: Deliver an old command after
the newer ownership state has been committed.
Experiment 42 — Reassignment Without Sanitization: Confirm that the
protected controller refuses assignment when mandatory hardware
assurance is missing.
Experiment 43 — Post-Update New Device Route: Introduce another
effect-capable hardware interface and verify coverage reassessment.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.52. Source page 911 of the original technical specification
Experiment 44 — No Blockchain: Demonstrate protected device
ownership, migration, and finality verification using ordinary
authenticated state.
9.41 — PRESENT-DAY FEASIBILITY
9.41.1 — Minimum Software Prototype
A reference implementation may use two isolated worker processes
representing separate execution devices.
An authoritative ownership controller maintains the current owner and
protected epoch.
A controlled storage or network resource acts as the Finality Sink.
The workers prepare equivalent consequential requests.
The controller transfers ownership from the first worker to the
second.
The resource sink rejects the first worker's later request and
accepts the second worker's authorized operation.
9.41.2 — Intermediate Virtualized Prototype
A stronger reference implementation may use distinct virtualized
environments with separately authenticated identities.
A protected controller maintains non-copyable authority state outside
the virtual-machine snapshot.
9.41.3 — Hardware-Backed Prototype
A further implementation may use a supported device assignment
mechanism, memory isolation, protected command dispatcher, and
authenticated device controller.
9.41.4 — Command-Queue Prototype
A test controller may model queued, accepted, dispatched, and
completed commands.
The migration protocol may verify different handling requirements for
each stage.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.41.5 — Cryptographic Authentication
Device identities, migration records, and enablement objects may use
established cryptographic authentication mechanisms.
9.41.6 — Protected State Storage
9.4.3.53. Source page 912 of the original technical specification
Current ownership and consumption state may use a transactional
database, protected hardware counter, or suitable authoritative state
service.
9.41.7 — Performance Planning
The system may perform costly device readiness and source-fencing
checks during migration rather than during every ordinary
computation.
A current destination sink may use compact protected state for
frequent operation checks.
9.41.8 — Hardware Limits
The protection achievable for real devices depends upon supported
isolation, reset, memory, and command-control primitives.
9.41.9 — Failure-Mode Testing
A prototype should deliberately test paused workers, delayed
messages, partial transfers, old credentials, and unknown effect
outcomes.
9.41.10 — Experimental Qualification
The disclosed experiments describe methods for testing feasibility.
They do not represent measured results until actually implemented and
recorded.
9.42 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
9.42.1 — Cross-Accelerator Autonomous Migration
A task may move among heterogeneous accelerator devices.
Protected ownership state may prevent the old accelerator from
issuing further controlled effects after the transfer.
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.42.2 — Chiplet-Level Authority Domains
Different chiplets or protected compute partitions may possess
separate effectuation identities and authorization state.
9.42.3 — Programmable Hardware Finality
Reconfigurable hardware may implement operation-specific authority
checks at a protected command boundary.
9.42.4 — Confidential Virtual-Machine Migration
9.4.3.54. Source page 913 of the original technical specification
A confidential workload may transfer while its consequential
authority remains bound to the current protected ownership and
destination sink.
9.42.5 — Cross-Cloud Device Transfer
A workload may migrate between independently administered compute
environments without transferring unrestricted source credentials.
9.42.6 — Edge-to-Cloud Authority Continuity
A mobile or embedded task may move to a remote environment while
preserving operation-specific restrictions.
9.42.7 — Autonomous Vehicle Controller Replacement
A protected vehicle subsystem may transfer selected control authority
between redundant controllers under an appropriate safe operating
policy.
9.42.8 — Robotic Actuator Ownership
Several robotic processors may coordinate exclusive access to a
protected actuator.
9.42.9 — Satellite and Remote Device Migration
Intermittently connected devices may use bounded leases and verified
activation rules where immediate global fencing is unavailable.
9.42.10 — Distributed Sensor Ownership
Protected sensors may be reassigned while previous-owner access to
sensitive observations is constrained.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.42.11 — Smart Storage Authority
Storage devices may enforce current ownership epochs and operation-
specific authorization before persistent commits.
9.42.12 — Programmable Network Devices
Network hardware may enforce protected authority over consequential
forwarding or configuration operations.
9.42.13 — Multi-Device Autonomous Tasks
A task may use several devices concurrently under explicitly
partitioned operation authority rather than unrestricted duplicated
ownership.
9.42.14 — Protected Energy-Aware Migration
9.4.3.55. Source page 914 of the original technical specification
An autonomous workload may migrate in response to power or thermal
conditions while retaining the required finality controls.
9.42.15 — Future Secure Interconnects
Protected identity and ownership information may be enforced across
emerging hardware interconnects.
9.42.16 — Privacy-Preserving Migration Evidence
A verifier may establish selected device readiness or ownership
predicates without revealing unnecessary workload contents.
9.42.17 — Cryptographic Algorithm Agility
Device and migration evidence may support appropriately authenticated
cryptographic transitions.
9.42.18 — Automatic Safe Recovery
A protected system may select a verified recovery environment after
source failure while maintaining operation-specific finality
authority.
9.42.19 — Protected Physical-State Continuity
A controller may combine ownership transfer with qualified evidence
of current physical actuator state.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.42.20 — Unified Device Finality Infrastructure
A protected execution-finality layer may coordinate device identity,
authority ownership, command dispatch, resource custody, and actual
consequential release across heterogeneous computing infrastructure.
9.43 — OPTIONAL INVENTIVE TECHNICAL COMBINATIONS
9.43.1 — Source-Fenced Destination Finality
The destination Finality Sink requires valid source-fencing evidence
and current ownership before releasing the migrated effect.
9.43.2 — Ownership Epoch Plus Actual Operation Reconstruction
The sink verifies the actual pending operation against the current
authenticated ownership generation.
9.43.3 — Non-Bearer Authority Plus Device Identity
9.4.3.56. Source page 915 of the original technical specification
The migrated effect authority is bound to the authorized receiving
device, protected resource, and designated sink.
9.43.4 — Command Queue Plus Ownership Barrier
Accepted or undispatched hardware commands are appropriately resolved
before new destination authority becomes effective.
9.43.5 — Memory Reassignment Plus Finality Control
A device assignment transition includes both protected memory custody
and operation-specific authority verification.
9.43.6 — Hardware Isolation Plus Credential Release
A protected controller verifies current device assignment and
finality authority before activating privileged credentials.
9.43.7 — Migration Plus Causal Real-Effect Receipt
A successor operation requires both valid migrated ownership and an
accepted prior-effect receipt under CW-2.
9.43.8 — Migration Plus Cross-Device Resource Identity
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination sink verifies that the actual physical resource
corresponds to the originally authorized target.
9.43.9 — Migration Plus Contract Evolution
Current destination software or firmware behavior must remain
compatible with the authorized effect.
9.43.10 — Migration Plus Conflict Arbitration
A migrated operation remains subject to applicable protected
reservations established for other concurrent agents.
9.43.11 — Migration Plus Cumulative Privacy
A transferred task retains relevant protected disclosure state rather
than receiving a fresh unrestricted privacy allowance.
9.43.12 — Migration Plus Resource Allocation
The destination requires valid resource-grant authority where the
task consumes controlled computational or device resources.
9.4.3.57. Source page 916 of the original technical specification
9.44 — PROPOSED INVENTIVE-STEP ANALYSIS
9.44.1 — Established Technical Foundations
Distributed locks, fencing tokens, secure device identity, virtual-
machine migration, memory isolation, device reset, and hardware
command synchronization are established technical mechanisms.
Their individual use does not establish novelty.
9.44.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to preserve exclusive authority over a consequential operation
during migration between independently executing environments while
preventing stale source commands, cloned computational state,
retained credentials, and unresolved hardware execution from causing
unauthorized effects after the protected ownership transition.
9.44.3 — Candidate Combined Technical Solution
A candidate technical combination comprises:
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Protected identification of the unfinished Candidate Act;
Authenticated current owner identity;
An authoritative protected ownership epoch;
Verified source-device effectuation fencing;
Qualified treatment of in-flight hardware commands;
A committed exclusive ownership transition;
Destination-bound non-bearer finality enablement;
And independent actual-operation verification at the receiving
Finality Sink.
9.44.4 — Principal Technical Interaction
The original Candidate Act defines the permitted consequence.
The ownership controller establishes which environment may exercise
the corresponding authority.
The source-fencing controller restricts stale effectuation paths.
The command-state controller handles pending hardware operations.
9.4.3.58. Source page 917 of the original technical specification
The protected migration state records the valid ownership transition.
The destination enablement binds the effect to the receiving
environment.
The Finality Sink verifies the actual pending operation and current
protected ownership before release.
These relationships govern different failure modes of the same
consequential authority transition.
9.44.5 — Why Task Migration Alone Is Insufficient
A migrated task may carry computational state without invalidating
old resource commands.
The proposed architecture separates computation migration from
protected authority transfer and actual effectuation.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.44.6 — Why Epochs Alone Are Insufficient
An ownership epoch may indicate which owner should be current.
If the relevant effectuation sink does not check the authoritative
state, an old command may still be accepted.
9.44.7 — Why Device Identity Alone Is Insufficient
A valid device identity establishes identity under the selected
authentication mechanism.
It does not independently establish current operation-specific
authority.
9.44.8 — Why Memory Isolation Alone Is Insufficient
Memory isolation may restrict unauthorized memory access.
It does not automatically verify the actual external operation or
transaction requested by an authorized device.
9.44.9 — Why Source-Fencing Evidence Must Be Qualified
A record asserting that the source was disabled may be inaccurate or
incomplete if relevant hardware commands or alternate paths remain
uncontrolled.
The claimed barrier must be supported by the actual enforcement
architecture.
9.44.10 — Candidate Narrow Technical Kernel
A potentially significant claim kernel is:
A protected authority-migration system that binds an unfinished
consequential operation to an authoritative owner generation,
requires verified fencing of specified
9.4.3.59. Source page 918 of the original technical specification
source effectuation paths and appropriate disposition of relevant
pending hardware commands, commits destination ownership, and enables
the actual destination consequence only through a Finality Sink that
independently verifies the current owner, operation scope, protected
migration state, and non-bearer finality authority.
9.44.11 — Additional Narrow Kernel
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An additional candidate may require protected device-memory and
command-state custody during resource reassignment, combined with
destination-specific finality activation.
9.44.12 — Additional Cross-Domain Kernel
Another candidate may require an authenticated transfer between
administrative domains, with operation-specific scope preserved and
enforced at the destination's protected hardware or software sink.
9.44.13 — Hindsight Considerations
An inventive-step assessment should examine whether relevant prior
art already teaches the claimed combination of fencing, hardware
state control, protected authority transfer, and sink-specific
finality enforcement.
A combination of known mechanisms may be obvious where each performs
its customary expected function without a further technical
relationship.
The strongest argument should identify a particular state dependency
or effectuation guarantee not supplied by the closest prior art.
9.44.14 — Patentability Qualification
The terminology and number of technical variations do not themselves
establish novelty.
The scope of any eventual claim depends upon the actual limitations,
enabling support, and prior-art examination.
9.45 — INDUSTRIAL APPLICABILITY
9.45.1 — Cloud Workload Migration
Protected workload authority may move among cloud execution nodes
while stale instances remain unable to perform governed resource
effects.
9.45.2 — Virtual-Machine Migration
A virtual machine may move between hosts while protected effectuation
authority remains separate from copyable computational state.
9.45.3 — Containerized Autonomous Agents
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.60. Source page 919 of the original technical specification
An agent runtime may be replaced or rescheduled while the actual
protected resource sink enforces current ownership.
9.45.4 — Hardware Accelerator Sharing
Accelerator devices may be reassigned among workloads under protected
command, memory, and authority transitions.
9.45.5 — Neural Processing Infrastructure
Autonomous model workloads may move among neural accelerators while
maintaining bounded authority over shared effect-capable resources.
9.45.6 — Mobile Devices
An assistant may transfer an unfinished task between devices without
automatically duplicating external execution authority.
9.45.7 — Desktop Computing
Protected operations may survive process replacement or session
migration without permitting stale process execution.
9.45.8 — Enterprise Storage
Storage controllers may enforce current owner generations before
persistent modification.
9.45.9 — Network Infrastructure
Protected network functions may transfer control authority among
devices while avoiding stale configuration commands.
9.45.10 — Financial Systems
A transaction-preparation task may migrate without authorizing
duplicate payment or settlement instructions.
9.45.11 — Industrial Automation
Protected actuator ownership may change between controllers while
source and destination commands remain subject to appropriate
hardware interlocks.
9.45.12 — Autonomous Robotics
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Robotic devices may transfer command authority under bounded
physical-effect and current-state constraints.
9.45.13 — Autonomous Vehicles
9.4.3.61. Source page 920 of the original technical specification
Redundant computing controllers may coordinate authority ownership
over selected consequential functions.
9.45.14 — Medical and Laboratory Devices
Protected instruments may maintain operation-specific authority when
execution control transfers between eligible controllers, subject to
applicable safety requirements.
9.45.15 — Telecommunications Equipment
Protected control-plane operations may be reassigned among network
controllers without uncontrolled duplicate effectuation.
9.45.16 — Remote and Satellite Systems
Intermittently connected devices may employ bounded ownership leases
and conservative transfer conditions.
9.45.17 — Confidential Computing
A protected workload may migrate between confidential environments
while requiring separate authorization for external consequential
effects.
9.45.18 — Edge Computing
Autonomous tasks may move among edge nodes according to resource,
energy, or availability requirements while preserving valid finality
constraints.
9.45.19 — Secure Multi-Tenant Hardware
Device assignment may incorporate protected memory, command, and
current ownership state.
9.45.20 — Future Heterogeneous Computing
The architecture may operate across processors, accelerators,
programmable hardware, chiplet systems, and future execution devices.
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The industrial utility concerns preserving controlled consequential
authority as computation and device resources move between execution
environments.
9.46 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
9.46.1 — Candidate Independent System Claim
A candidate system claim may concern a protected execution-authority
migration system comprising:
9.4.3.62. Source page 921 of the original technical specification
An authoritative ownership controller configured to maintain current
owner identity and ownership-generation state for an unfinished
consequential operation;
A protected source-fencing component configured to prevent stale
source-owned operations from producing the governed consequence
through specified effectuation paths;
A migration controller configured to authenticate a destination and
commit an ownership transition subject to the required fencing and
operation-state conditions;
A destination-specific protected authority component configured to
establish non-bearer operation-bound enablement;
And a destination Finality Sink configured to reconstruct the actual
pending operation, verify current ownership and scoped authority, and
permit effectuation only when the required conditions are satisfied.
9.46.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Establishing current ownership of an unfinished Candidate Act;
Authenticating a destination;
Preparing non-effective destination context;
Identifying and restricting relevant source effectuation paths;
Resolving required pending command state;
Committing an authoritative owner-generation transition;
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Activating destination-bound authority;
And independently verifying the actual consequential operation at the
destination sink before release.
9.46.3 — Candidate Independent Hardware Apparatus Claim
A hardware apparatus may include protected assignment state, a
command authorization interface, a current ownership-generation
reference, and a controlled effectuation primitive.
The apparatus may refuse commands from stale owners and require
operation-specific protected finality authority.
9.46.4 — Candidate Device Reassignment Claim
Another candidate may concern protected device reassignment requiring
appropriate command-state disposition, memory-access revocation,
supported sanitization evidence, and destination effectuation
activation.
9.4.3.63. Source page 922 of the original technical specification
9.46.5 — Candidate Cross-Domain Migration Claim
A further candidate may require protected exclusive authority
transfer between independently administered devices, with source-
derived effect constraints preserved and destination-side finality
enforcement.
These candidates may overlap and should be structured according to
unity, original disclosure support, and relevant prior art.
9.47 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The original consequential operation is
represented by a protected Candidate Act.
Dependent aspect 2: The current effectuation owner possesses an
authenticated device identity.
Dependent aspect 3: The current ownership state includes a protected
monotonic generation.
Dependent aspect 4: The destination is authenticated before authority
migration.
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Dependent aspect 5: Destination task context is prepared in a non-
effective state.
Dependent aspect 6: The system verifies destination operation and
resource compatibility.
Dependent aspect 7: Relevant source effectuation paths are identified
before ownership transfer.
Dependent aspect 8: A source application dispatcher is fenced.
Dependent aspect 9: A source network effectuation path is fenced.
Dependent aspect 10: A source storage effectuation path is fenced.
Dependent aspect 11: A source hardware command dispatcher is fenced.
Dependent aspect 12: A protected source credential broker refuses
stale-owner credential use.
Dependent aspect 13: Required source-fencing evidence is
authenticated.
Dependent aspect 14: The system identifies accepted but undispatched
device commands.
Dependent aspect 15: Pending commands are cancelled or invalidated
under a supported controller procedure.
Dependent aspect 16: Already dispatched commands are accounted for
according to their actual-effect state.
9.4.3.64. Source page 923 of the original technical specification
Dependent aspect 17: A protected command generation is bound to the
authority epoch.
Dependent aspect 18: The destination activation barrier verifies
required in-flight command state.
Dependent aspect 19: The ownership transition is committed under
authoritative protected state.
Dependent aspect 20: Destination finality authority is bound to the
new ownership generation.
Dependent aspect 21: Destination authority is bound to an
authenticated device identity.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Dependent aspect 22: Destination authority is bound to a designated
Finality Sink.
Dependent aspect 23: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 24: The sink verifies the actual operation against
the originating authorized effect envelope.
Dependent aspect 25: The sink verifies current resource identity.
Dependent aspect 26: The sink verifies current software or firmware
operation semantics.
Dependent aspect 27: The sink verifies current protected revocation
state.
Dependent aspect 28: Protected finality authority is atomically
consumed.
Dependent aspect 29: Previously consumed authority is rejected upon
replay.
Dependent aspect 30: A stale owner is rejected based upon current
protected ownership state.
Dependent aspect 31: The protected ownership generation is rollback
resistant under the selected trust model.
Dependent aspect 32: Device memory mappings associated with the
previous owner are invalidated.
Dependent aspect 33: Outstanding direct-memory-access operations are
appropriately resolved.
Dependent aspect 34: Peer-to-peer device paths are included in the
protected reassignment procedure where required.
Dependent aspect 35: Device reassignment includes supported memory or
sensitive-state sanitization.
Dependent aspect 36: A protected cryptographic key custody transition
accompanies authority migration.
9.4.3.65. Source page 924 of the original technical specification
Dependent aspect 37: A virtual-machine snapshot excludes
independently exercisable finality authority.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Dependent aspect 38: A cloned workload requires independent current
ownership verification.
Dependent aspect 39: A disconnected device operates only within a
protected bounded lease where permitted.
Dependent aspect 40: Strict destination activation is withheld when
mandatory source-fencing conditions cannot be established.
Dependent aspect 41: The system distinguishes exclusive migration
from authorized concurrent subleases.
Dependent aspect 42: A physical actuator transfer incorporates a
protected operating-state or safety interlock.
Dependent aspect 43: A qualified actual-effect receipt is required
for a successor phase where CW-2 applies.
Dependent aspect 44: Protected conflict arbitration remains
applicable following migration.
Dependent aspect 45: Cumulative privacy or resource budgets remain
associated with the migrated task.
Dependent aspect 46: A software or firmware update triggers
enforcement-coverage reattestation.
Dependent aspect 47: An authenticated migration receipt is
distinguished from evidence of actual completed external effects.
Dependent aspect 48: The ownership, fencing, and finality functions
may be integrated into one protected component.
Dependent aspect 49: The ownership, fencing, and finality functions
may be distributed among separate authenticated devices.
Dependent aspect 50: The architecture does not require blockchain
technology or a public distributed ledger.
The listed aspects are potential technical limitations rather than
finalized claims.
9.48 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present Embodiment 9 discloses a protected architecture for
transferring exclusive or otherwise bounded execution authority among
physical devices, virtual machines, protected
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.4.3.66. Source page 925 of the original technical specification
processors, autonomous runtimes, accelerators, hardware controllers,
and distributed computing environments.
An originating computational entity may possess valid authority to
perform a defined consequential operation.
The computation may subsequently move to another execution
environment.
The transfer of task state does not automatically transfer operation-
specific effectuation authority.
Likewise, copying a task or moving its execution does not
automatically invalidate effect-capable commands, credentials, or
resource access remaining in the original environment.
The present embodiment therefore establishes authenticated current
ownership, protected ownership generations, source-device fencing,
relevant hardware command-state control, and destination-specific
finality enablement.
A destination may receive computational context while remaining non-
effective with respect to the governed consequence.
Before activating exclusive destination authority, the system
establishes the required protected ownership transition and source-
fencing conditions.
The protected system may identify pending hardware commands, memory
mappings, reusable credentials, device assignments, and alternative
effectuation paths relevant to the migration.
The destination Finality Sink independently reconstructs or obtains
the actual operation presented for effectuation.
It verifies the current authorized owner, applicable epoch, actual
resource, permitted effect envelope, destination-specific enablement,
revocation state, and protected consumption conditions.
An earlier owner cannot validly exercise stale authority through the
covered controlled sink.
A cloned workload cannot create additional effectuation authority
merely by copying computational state.
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A privileged destination does not automatically acquire permission to
exceed the originating authorized consequence.
A protected ownership receipt does not automatically establish the
outcome of every previously dispatched hardware command.
Device reset, memory sanitization, cryptographic identity,
distributed fencing, and hardware isolation remain individually
established techniques with specific operational limitations.
9.5. Embodiment 21: Cross-Platform Resource Identity and Alias
Resolution
Technical source: original global pages 1758-1829. The following
source reproduction is a detailed disclosure index preserving
original ordering, technical optionality and independently identified
page boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.5.1. Architecture Diagram and Protected Components
[Source-authenticated logical reference]
|
[Protected namespace / alias lineage]
|
[Owner and resource binding generation]
|
[Reconstructed actual target at sink]
|
[Protected effect or withholding]
Figure 17: Embodiment 21: Cross-Platform Resource Identity and
Alias Resolution — Architecture
9.5.2. Operational Flowchart and Fail-Closed Branches
[Resolve logical resource]
|
<Trusted final identity?>--NO-->[Refuse]
|YES
<Redirect/rebind/version changed?>--YES-->[Revalidate]
|NO
[Compare actual sink resource identity]
|
<Authorized match?>--NO-->[Withhold]
|YES
[Consume/effect]
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Figure 18: Embodiment 21: Cross-Platform Resource Identity and
Alias Resolution — Decision Flow
9.5.3. Page-Indexed Source-Derived Technical Detail
9.5.3.1. Source page 1758 of the original technical specification
END OF EMBODIMENT 20 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 21
PROTECTED RESOURCE-IDENTITY AND ALIAS-RESOLUTION EXECUTION FINALITY
ACROSS DYNAMIC NAMESPACES, REDIRECTS, CROSS-DOMAIN RESOURCE
REBINDING, AND INDEPENDENT ACTUAL-RESOURCE ENFORCEMENT
21.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Using Protected Logical-to-Physical Resource
Identity Resolution, Authenticated Namespace and Alias-Lineage
Evidence, Current Resource-Binding Generations, Cross-Domain Redirect
and Ownership Verification, Scoped Non-Bearer Finality Enablement,
and Independent Finality-Sink Reconstruction and Verification of the
Actual Effected Resource
21.0.1 — General Technical Description
The present Embodiment 21 discloses systems, methods, apparatus,
protected computing components, resource-identity verification
protocols, authenticated namespace-resolution structures, alias-
lineage evidence mechanisms, protected resource-reference registries,
cross-domain authorization interfaces, software and hardware
resource-enforcement controllers, and non-limiting implementations
for controlling consequential operations directed toward resources
whose identifiers, locations, names, aliases, bindings, ownership, or
representation may change.
The embodiment applies to autonomous artificial-intelligence agents,
autonomous assistants, operating-system services, application
controllers, cloud services, distributed storage, databases, network
gateways, multi-agent systems, hardware controllers, remote devices,
telecommunications infrastructure, robotic systems, and other
computational entities capable of proposing or initiating
consequential resource operations.
An autonomous computational entity may receive permission to perform
an operation involving a particular resource.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The resource may initially be identified by:
A filename;
A filesystem path;
A symbolic link;
A database record identifier;
An object-storage key;
A document identifier;
A uniform resource identifier;
A network hostname;
9.5.3.2. Source page 1759 of the original technical specification
A service-discovery name;
An application-level alias;
A user-visible object label;
A device identifier;
A virtual resource reference;
A hardware address;
Or another logical or physical resource representation.
The initial representation may not uniquely establish the resource
that will actually receive the consequential operation.
A file path may resolve through a symbolic link.
A symbolic link may be changed.
A file may be renamed.
A directory may be remounted.
A storage object may be replaced while retaining its name.
A database alias may refer to a different underlying record.
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A web request may be redirected to a different endpoint.
A service-discovery entry may change between authorization and
execution.
A domain name may resolve to different network addresses.
A cloud resource may be reassigned or recreated.
An application may substitute a different object behind an apparently
unchanged interface reference.
A device identifier may be reused after ownership or hardware
replacement.
A distributed system may migrate a resource from one administrative
domain to another.
Some changes may preserve the resource identity intended by the
originating principal.
Other changes may substitute a materially different resource and
thereby invalidate the earlier authorization.
The distinction cannot always be determined by comparing textual
identifiers.
Two different names may identify the same underlying resource.
The same name may identify different resources at different times.
9.5.3.3. Source page 1760 of the original technical specification
Two resources may contain identical data without possessing the same
ownership, authority, or legal resource identity.
A stable identifier may be authentic but no longer represent a
resource the principal remains authorized to modify.
A content digest may verify selected bytes without establishing that
the bytes belong to the originally authorized resource or recipient.
A network address may identify a transport endpoint without
independently identifying the application resource that will perform
the actual effect.
The present embodiment addresses these conditions by separating:
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The original authorized resource referent;
The submitted logical resource representation;
The authenticated resolution process;
The actual effect-capable resource identity;
The current namespace and ownership conditions;
The protected resource-binding evidence;
And the authority required for the actual resource operation.
In a principal implementation, an autonomous requester constructs a
Candidate Act specifying a permitted resource operation.
The operation is maintained in a Non-Effective State.
A protected resource-identity controller establishes a machine-
verifiable relationship between the original authorized referent and
one or more qualified current resource representations.
The system may obtain authenticated evidence from an authoritative
resource resolver, operating-system resource controller, database
service, storage service, device controller, or suitably protected
cross-domain identity registry.
The evidence may identify the actual resource, its relevant
generation, the permissible alias relationship, and applicable
ownership or authorization conditions.
A protected validation instance determines whether the resolved
resource remains within the original authorized effect envelope.
A protected finality controller establishes scoped non-bearer
finality enablement bound to the appropriate resource-identity
evidence and current authority.
At the actual effectuation boundary, the Finality Sink independently
obtains or reconstructs the actual resource object or effect target
presented to it.
The sink verifies that the actual target corresponds to the protected
authorized resource identity under the applicable resolution policy.
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.4. Source page 1761 of the original technical specification
The sink additionally verifies current source authority, relevant
namespace or resource generations, operation parameters, and sink-
local protected consumption state.
A materially different resource cannot acquire valid consequential
authority merely because it inherits the same filename, hostname,
object key, alias, document label, or untrusted identifier.
21.0.2 — Fundamental Technical Principle
An authorization to operate on a logical resource reference is not
automatically authorization to operate on every resource to which
that reference may subsequently resolve.
Similarly:
A change of resource name does not necessarily mean the underlying
resource has changed.
A stable resource name does not necessarily mean the underlying
resource remains the same.
A successful name resolution does not independently establish current
resource authorization.
An authentic redirect does not automatically confer authority over a
new target.
And a cryptographic identity of resource content does not necessarily
establish the ownership or effectuation identity of the resource.
The final consequential operation must be verified against the actual
target under the selected protected resource-identity model.
21.0.3 — Principal Candidate Inventive Combination
In one principal implementation, the disclosed combination comprises:
(a) a Candidate Act identifying an intended consequential resource
operation;
(b) an enforceable Non-Effective State;
(c) a protected originating-resource referent associated with the
original source authority;
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
(d) an authenticated resource-resolution or alias-lineage evidence
structure;
(e) a protected resource-identity correspondence predicate;
(f) one or more current namespace, binding, resource, or ownership
generations;
(g) an independent execution-time validation component;
(h) a protected controller establishing scoped non-bearer finality
enablement;
(i) a designated Finality Sink capable of independently obtaining or
reconstructing the actual target resource;
(j) a sink-side comparison between the actual target and the
protected authorized resource correspondence;
(k) current source-authority and resource-state verification;
9.5.3.5. Source page 1762 of the original technical specification
(l) sink-local protected consumption before consequential
effectuation.
The principal combination is designed to distinguish permissible
resource rebinding from unauthorized target substitution.
21.0.4 — Specific Technical Contribution
The proposed contribution is not the independent invention of:
Filesystem path resolution;
Symbolic-link handling;
HTTP redirects;
Resource identifiers;
Object versioning;
Cryptographic hashing;
Database transactions;
Or access-control lists.
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Those are established mechanisms.
The candidate distinguishing relationship concerns the use of
qualified resource-resolution evidence as a necessary part of
operation-specific finality authority, together with independent
verification of the actual resolved resource at the effectuation
boundary.
21.0.5 — Non-Limiting Implementation Arrangements
The invention may be implemented through:
An operating-system resource service;
A protected filesystem dispatcher;
A database transaction controller;
A storage gateway;
An application API resource server;
A network or service-mesh gateway;
A credential broker;
A remote protected resource authority;
9.5.3.6. Source page 1763 of the original technical specification
A virtual-machine resource controller;
A hardware command interface;
Or a suitably protected combination of these components.
No particular operating system, service provider, storage protocol,
or hardware vendor is universally necessary.
21.1 — TECHNICAL FIELD
The present embodiment relates to autonomous resource authorization,
execution-finality control, filesystem and object identity, namespace
resolution, distributed resource naming, cloud storage, network
redirection, cross-domain identity, resource ownership, protected
alias graphs, time-of-check/time-of-use security, cryptographic
evidence, conditional resource mutation, and resource-side
consequential enforcement.
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
More particularly, the invention concerns ensuring that permission
granted in relation to an originally identified resource remains
correctly and enforceably associated with the actual resource
receiving a consequential operation, despite changes in names,
aliases, namespaces, redirects, or resource representations.
21.2 — SPECIFIC TECHNICAL PROBLEMS
21.2.1 — Alias Substitution
A logical resource alias may be altered to point toward another
resource.
21.2.2 — Symbolic-Link Replacement
A filesystem symbolic link may change after an agent obtains
permission for the original target.
21.2.3 — Hard-Link Ambiguity
Several filesystem names may identify one underlying object,
requiring differentiation between name-level and object-level
authority.
21.2.4 — Directory Rebinding
A directory path may be reassigned, moved, replaced, or remounted.
21.2.5 — Mount-Namespace Change
The same apparent path may identify different resources in distinct
namespace environments.
21.2.6 — File Rename
A file may be renamed without necessarily changing its underlying
resource identity.
21.2.7 — Resource Deletion and Recreation
9.5.3.7. Source page 1764 of the original technical specification
A resource name may be reused after deletion.
21.2.8 — File Identifier Reuse
A filesystem object identifier may be reused after an earlier object
is removed.
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.2.9 — Database Alias Change
An application may map one logical customer or account reference to a
different database record.
21.2.10 — Database Record Replacement
A database key may remain the same while the record's ownership,
version, or authorized meaning changes.
21.2.11 — Object-Storage Key Reuse
An object key may identify a different stored version at a later
time.
21.2.12 — Cross-Tenant Resource Confusion
An identifier that is unique within one tenant may not be unique
across all tenants.
21.2.13 — Redirected HTTP Request
An authorized network request may be redirected to a different
target.
21.2.14 — Redirect Chain Mutation
A redirect chain may change after initial validation.
21.2.15 — Network Address Rebinding
A hostname may resolve to different addresses between approval and
transmission.
21.2.16 — Transport Identity Versus Resource Identity
A valid transport endpoint may serve multiple logical resources with
different authorization conditions.
21.2.17 — Service Discovery Replacement
A service-discovery name may resolve to a different service instance.
21.2.18 — Load Balancer Reconfiguration
Traffic may be routed to another backend whose resource identity or
authority properties differ.
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.2.19 — Cross-Provider Migration
A resource may migrate between independently administered providers.
21.2.20 — Ownership Change
9.5.3.8. Source page 1765 of the original technical specification
The same resource may change owner or access authority.
21.2.21 — Device Replacement
An authorized device reference may subsequently refer to different
hardware.
21.2.22 — Virtual Device Rebinding
A virtual device identifier may be remapped to another physical
interface.
21.2.23 — Displayed Object Substitution
A user-visible label may remain unchanged while its underlying target
changes.
21.2.24 — Ambiguous Canonicalization
Two components may canonicalize paths, URLs, resource keys, or
structured identifiers differently.
21.2.25 — Unicode and Case-Folding Differences
Different normalization or case-comparison rules may produce mistaken
identity correspondence.
21.2.26 — Percent-Encoding Ambiguity
Different URL interpretation layers may disagree about encoded
delimiters, path segments, or reserved characters.
21.2.27 — Alias Loop
A resource-resolution chain may contain cycles or excessive
indirection.
21.2.28 — Unauthenticated Resolution
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An untrusted component may claim that two resource references
identify the same actual object.
21.2.29 — Stale Resolution Cache
An old resolution result may continue to be used after an
authoritative binding changes.
21.2.30 — Incomplete Target Observation
A gateway may observe the outgoing transport request without
establishing the destination resource's internal identity.
21.2.31 — Resource-State Race
The target may change between resolution validation and actual
effectuation.
21.2.32 — Technical Objective
A candidate objective technical problem is:
9.5.3.9. Source page 1766 of the original technical specification
How to maintain protected correspondence between an originally
authorized resource referent and the actual resource receiving a
consequential operation when resource names, aliases, locations,
namespaces, redirects, ownership, or binding generations may change,
while allowing verified legitimate resource continuity and preventing
unauthorized target substitution at the final effectuation boundary.
21.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
21.3.1 — Filesystem Path Resolution
Existing operating systems resolve paths to filesystem objects.
Some provide restricted resolution interfaces and object handles.
These are established mechanisms.
They do not, by themselves, determine whether a particular autonomous
task remains authorized to mutate the resolved object under its
original task-specific authority.
21.3.2 — Namespace Isolation
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Existing operating systems support distinct resource namespaces and
associated access restrictions.
Such mechanisms are established.
The present embodiment may additionally require current binding of
source authority to the actual resource identity and namespace
generation.
21.3.3 — URI Normalization
Existing protocols specify parsing and comparison rules for resource
identifiers.
Canonicalization may reduce representational ambiguity.
It does not establish that two different resources are equivalent for
authorization purposes.
21.3.4 — DNS and Service Discovery
Existing resolution systems associate names with network addresses or
services.
They may support authenticated information under particular
configurations.
Name-to-address resolution does not inherently prove the identity of
the application-level resource receiving a protected consequential
effect.
21.3.5 — HTTP Redirects
Existing application protocols permit requests to be redirected.
A redirect response may affect the target or request semantics.
An earlier authorization for one protected resource does not
necessarily authorize a changed destination.
9.5.3.10. Source page 1767 of the original technical specification
21.3.6 — Object Versions
Existing storage systems may provide object versions, generation
identifiers, and conditional mutations.
These are established techniques.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The proposed architecture may use them as evidence within a broader
original-authority-to-actual-resource relationship.
21.3.7 — Cryptographic Hashing
Existing hashes may bind content or structured resource descriptors.
A hash does not automatically establish ownership, location,
permission, or resource identity.
21.3.8 — Conditional Requests
Existing protocols may reject updates when resource versions no
longer match.
These are established.
The present embodiment may combine current resource conditions with
protected original referent identity and finality authority.
21.3.9 — Candidate Technical Distinction
The proposed stronger system connects qualified resource resolution
and current binding evidence to the operation-specific authority
consumed at the actual resource sink.
21.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
A Requesting Computational Entity;
A Candidate Act Constructor;
A Protected Original Resource Referent Registry;
A Resource Namespace Qualification Controller;
An Authenticated Alias Resolution Controller;
A Protected Resource-Identity Correspondence Validator;
A Resource Binding and Generation Registry;
An Optional Cross-Domain Resource Identity Verifier;
A Current Ownership and Source-Authority Controller;
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An Independent Execution-Time Resource Validator;
9.5.3.11. Source page 1768 of the original technical specification
A Finality Enablement Controller;
An Actual Resource Finality Sink;
And a Sink-Local Consumption and Resource-State Controller.
Optional components include:
A filesystem object-handle resolver;
A database versioning service;
An object-storage version registry;
A network destination verifier;
A service-discovery adapter;
A protected resource migration controller;
A device ownership register;
A cryptographic evidence store;
A protected resource audit journal;
And an authorized scope-deviation controller.
21.4.1 — Requesting Entity
Proposes the consequential operation but does not automatically
control the authoritative resource-binding state.
21.4.2 — Original Referent Registry
Maintains the selected authorized resource reference and its
authority context.
21.4.3 — Namespace Controller
Identifies the relevant resolution environment.
21.4.4 — Alias Controller
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Obtains and qualifies resource-reference transformations.
21.4.5 — Correspondence Validator
Determines whether the resolved resource remains within the original
permitted target set.
21.4.6 — Finality Controller
Establishes scoped authority bound to the qualified resource identity
and current technical state.
21.4.7 — Finality Sink
9.5.3.12. Source page 1769 of the original technical specification
Obtains or reconstructs the actual resource targeted by the pending
effect.
21.4.8 — Protected Consumption Controller
Prevents unsupported reuse of operation-specific authority.
21.5 — TECHNICAL DEFINITIONS
21.5.1 — Original Authorized Resource Referent
An Original Authorized Resource Referent, or OARR-21, means the
resource referent established under the originating source authority.
21.5.2 — Logical Resource Reference
A Logical Resource Reference means a path, URL, alias, identifier,
label, symbolic name, application object name, or other
representation used to designate a resource.
21.5.3 — Actual Effect Target
An Actual Effect Target, or AET-21, means the resource object,
endpoint, command destination, or effect-capable entity actually
receiving the selected consequential operation.
21.5.4 — Protected Resource Identity
A Protected Resource Identity, or PRI-21, means an authenticated
representation of resource identity sufficient for the selected
actual-operation authorization predicate.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.5.5 — Resource Identity Continuity
Resource Identity Continuity means a validated relationship
establishing that the currently resolved resource remains the
originally authorized resource or another expressly permitted
equivalent target.
21.5.6 — Protected Alias Lineage
Protected Alias Lineage, or PAL-21, means authenticated evidence
identifying a sequence of relevant transformations between resource
references.
21.5.7 — Resource Binding Generation
A Resource Binding Generation, or RBG-21, means an authoritative
version or generation associated with a relevant name-to-resource
binding.
21.5.8 — Namespace Generation
A Namespace Generation, or NSG-21, means an authoritative version
associated with the applicable namespace or namespace mapping state.
21.5.9 — Protected Resource-Resolution Commitment
A Protected Resource-Resolution Commitment, or PRRC-21, means an
authenticated commitment to the relevant resource-resolution evidence
and resulting target.
9.5.3.13. Source page 1770 of the original technical specification
21.5.10 — Authorized Resource Equivalence
Authorized Resource Equivalence means a protected policy relation
identifying when two resource representations or targets may be
treated as equivalent for the specific operation.
21.5.11 — Resource Equivalence Predicate
A Resource Equivalence Predicate, or REP-21, means a machine-
verifiable condition evaluating permitted correspondence between an
original referent and the actual effect target.
21.5.12 — Resource Rebinding Event
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A Resource Rebinding Event means a relevant change to a resource
name, alias, identity association, location, ownership, or target
mapping.
21.5.13 — Material Rebinding
A Material Rebinding means a change affecting required resource
identity, source authorization, operation semantics, ownership, or
effectuation conditions.
21.5.14 — Harmless Alias Change
A Harmless Alias Change means a reference change that preserves the
required authorized-resource correspondence under the current
protected equivalence policy.
21.5.15 — Target Substitution
Target Substitution means replacement of the originally authorized
actual resource with a materially different target not established as
permitted.
21.5.16 — Protected Resolver
A Protected Resolver means a component authorized and technically
capable of establishing a specified resource-resolution property
under the selected trust model.
21.5.17 — Resolver Qualification
Resolver Qualification means a determination of the precise identity,
authenticity, current-state, or observation property supplied by a
resource resolver.
21.5.18 — Authenticated Resolution Edge
An Authenticated Resolution Edge means a protected record concerning
a transformation from one resource representation to another.
21.5.19 — Protected Resolution Graph
A Protected Resolution Graph, or PRG-21, means an authenticated
representation of relevant resource aliases, references, resolution
edges, and their validity conditions.
21.5.20 — Namespace-Specific Identity
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.14. Source page 1771 of the original technical specification
Namespace-Specific Identity means a resource identity whose
uniqueness or meaning is limited to a defined namespace.
21.5.21 — Cross-Domain Resource Identity
Cross-Domain Resource Identity means a resource identity qualified
across two or more independently administered domains.
21.5.22 — Resource Migration Continuity
Resource Migration Continuity means authenticated evidence that a
relocated resource satisfies a selected protected continuity
condition.
21.5.23 — Ownership Continuity
Ownership Continuity means a verified relationship establishing that
current authority remains applicable despite a resource ownership or
administration transition.
21.5.24 — Actual Resource Reconstruction
Actual Resource Reconstruction means obtaining or deriving the
resource identity actually presented to the effect-capable boundary.
21.5.25 — Protected Target-Finality Binding
Protected Target-Finality Binding, or PTFB-21, means a protected
relationship binding a Candidate Act and its scoped finality
authority to the permitted actual resource identity.
21.5.26 — Resource Revalidation Fence
A Resource Revalidation Fence, or RRF-21, means a condition
preventing effectuation when required resource correspondence has
become stale, changed, or uncertain.
21.5.27 — Binding Epoch
A Binding Epoch means a protected generation distinguishing current
binding authority from superseded resource mappings.
21.5.28 — Resource Identity Evidence Class
A Resource Identity Evidence Class means a characterization of what a
given identifier or observation can actually prove.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.5.29 — Content Identity
Content Identity means correspondence of selected content bytes or
data structure under a defined equivalence model.
21.5.30 — Object Identity
Object Identity means correspondence of an underlying resource object
rather than merely its name or content.
9.5.3.15. Source page 1772 of the original technical specification
21.5.31 — Authority Identity
Authority Identity means the principal, owner, tenancy, or protected
domain whose permission governs the resource.
21.5.32 — Endpoint Identity
Endpoint Identity means an identified network or service termination
point under the applicable authentication mechanism.
21.5.33 — Consequential Resource Identity
Consequential Resource Identity means the identity properties
necessary to determine whether a specific real effect is authorized.
21.5.34 — Resource Reference Ambiguity
Resource Reference Ambiguity means inability to establish one
permitted actual target under the applicable identity policy.
21.5.35 — Resource Identity Freshness
Resource Identity Freshness means current validity of the required
binding, namespace, ownership, and resource-state evidence.
21.5.36 — Resource-Specific Finality Authority
Resource-Specific Finality Authority means scoped non-bearer
authority restricted to an identified actual resource or permitted
equivalence class.
21.5.37 — Resource Substitution Attack
A Resource Substitution Attack means changing or manipulating a
resource reference so that an operation authorized for one target is
applied to another.
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.5.38 — Resource Identity Commitment Chain
A Resource Identity Commitment Chain means authenticated evidence
connecting the original authorized referent, intermediate qualified
resolutions, and actual target.
21.5.39 — Protected Resource Generation
A Protected Resource Generation means an authoritative state value
differentiating relevant resource versions, recreation events,
ownership transitions, or other material changes.
21.5.40 — Qualified Resource Effect Receipt
A Qualified Resource Effect Receipt means authenticated evidence
identifying the actual resource and supported consequential result
produced by an earlier operation.
21.6 — RESOURCE IDENTITY IS MULTIDIMENSIONAL
9.5.3.16. Source page 1773 of the original technical specification
A central implementation principle is that resource identity may
consist of several independently relevant properties.
A non-limiting resource identity tuple may be expressed as:
[ RI=(D,N,O,V,A,E) ]
where:
(D) denotes the relevant administrative or resource domain;
(N) denotes the namespace or resolution context;
(O) denotes the underlying object or resource identity;
(V) denotes the relevant resource version;
(A) denotes current ownership or source-authority state;
And (E) denotes an applicable binding or authority generation.
Not every operation requires every field.
The protected controller selects the fields that materially affect
the operation's authority.
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
For example:
A file-content read may require object identity and applicable
version.
A deletion may require actual current object identity, directory
authority, and relevant current ownership.
A remote payment may require account identity, receiving institution,
and current recipient scope.
A physical device command may require hardware identity, ownership,
command parameters, and protected operating state.
21.6.1 — Identity Versus Content
Two files containing identical bytes are not necessarily the same
authorized file.
21.6.2 — Identity Versus Name
One file may possess several names.
21.6.3 — Identity Versus Location
A resource may move while retaining an authenticated logical
identity.
21.6.4 — Identity Versus Ownership
A resource may retain its identifier while its authorized principal
changes.
9.5.3.17. Source page 1774 of the original technical specification
21.6.5 — Identity Versus Version
A logical resource may remain the same while its mutable content
changes.
The source authorization and effect type determine whether such
version changes are permitted.
21.7 — PROTECTED ORIGINAL RESOURCE REFERENT
When the original principal authorizes an operation, the system may
establish an OARR-21.
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A representative structure comprises:
ORIGINAL_AUTHORIZED_RESOURCE_REFERENT = { candidate_act_identifier,
originating_principal, original_grant_reference,
original_logical_resource, qualified_original_resource_identity,
original_namespace, original_resource_domain,
authorized_operation_class, authorized_effect_envelope,
permitted_alias_transformations, permitted_resource_equivalence,
required_resource_version, required_ownership_conditions,
current_authority_generation, designated_finality_sink,
protected_authentication } 21.7.1 — Original Source
The referent is established from qualified source authorization and
resource evidence.
21.7.2 — Agent-Supplied Names
An agent may supply the requested name or path.
However, the agent's unverified statement does not independently
establish the authoritative underlying resource identity.
21.7.3 — Permissible Transformations
The original authorization may expressly permit certain renames,
migrations, aliases, or other equivalent references.
21.7.4 — Disallowed Transformations
A material change outside the permitted equivalence relation requires
new validation or authorization.
9.5.3.18. Source page 1775 of the original technical specification
21.8 — RESOURCE-RESOLUTION EVIDENCE
The protected controller may obtain resource-resolution evidence
from:
A trusted filesystem operation;
An authenticated storage service;
A protected database lookup;
A current service registry;
An authenticated device controller;
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A qualified namespace resolver;
Or another technically sufficient resource authority.
A representative record may comprise:
PROTECTED_RESOURCE_RESOLUTION_EVIDENCE = {
original_resource_referent, submitted_resource_reference,
authoritative_resolver_identity, resolver_observation_class,
relevant_namespace_identity, resolution_path_commitment,
resulting_actual_resource_identity, resource_version,
binding_generation, ownership_generation, resolution_conditions,
current_authentication } 21.8.1 — Evidence Qualification
A resolver is trusted only for the property it can establish.
21.8.2 — No Automatic Cross-Domain Trust
A resolver from one administrative domain does not automatically
possess authority to establish another domain's protected resource
identity.
21.8.3 — Current Resolution
A historical resolution may be insufficient when the relevant binding
can change.
21.8.4 — Protected Commitment
The relevant result may be cryptographically authenticated or
preserved within protected state.
21.9 — AUTHENTICATED ALIAS LINEAGE
9.5.3.19. Source page 1776 of the original technical specification
One original resource may be referenced through multiple aliases.
A representative alias chain may be:
AUTHORIZED REFERENT | v LOGICAL DOCUMENT NAME | v APPLICATION
RESOURCE ID | v STORAGE OBJECT ID | v CURRENT VERSIONED OBJECT | v
ACTUAL FINALITY SINK Each relevant transformation may be associated
with authenticated evidence.
21.9.1 — Alias Edge
An alias edge identifies the source and destination reference.
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.9.2 — Resolver Identity
The controller identifies which component established the
relationship.
21.9.3 — Binding Generation
The relationship is associated with current state.
21.9.4 — Scope
The relationship may be valid only for one domain, resource type, or
operation class.
21.9.5 — Equivalence
The protected policy determines whether the transformation preserves
relevant authorization.
21.9.6 — Unknown Edge
A required unauthenticated or unresolved transformation causes the
relevant correspondence predicate to fail.
21.10 — PROTECTED ALIAS RESOLUTION GRAPH
The protected system may construct a resource-resolution graph.
A representative structure comprises:
9.5.3.20. Source page 1777 of the original technical specification
PROTECTED_ALIAS_RESOLUTION_GRAPH = { graph_identifier,
originating_candidate_act, original_resource_identity,
known_alias_nodes, authenticated_resolution_edges,
resolver_identity_registry, relevant_namespace_generations,
relevant_binding_generations, current_equivalence_policy,
actual_target_reference, protected_graph_authentication } A node may
identify a logical reference, resource object, namespace-specific
identity, or versioned target.
An edge identifies a qualified relationship.
21.10.1 — Graph Cycle
A detected alias cycle may be rejected or handled according to a
bounded resolution policy.
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.10.2 — Excessive Resolution Depth
The verifier may enforce a maximum traversal depth.
21.10.3 — Ambiguous Targets
If several actual targets remain possible and the source authority
permits only one, the operation remains withheld.
21.10.4 — Permitted Alias Set
A source authorization may expressly permit several equivalent target
representations.
21.10.5 — Protected Graph Change
A material resolution-graph change may invalidate existing operation-
specific authority.
21.11 — PROTECTED RESOURCE-EQUIVALENCE PREDICATE
A non-limiting resource correspondence relation may be:
[ \operatorname{Corresponds}(R_o,R_a,C) ]
where:
(R_o) is the originally authorized resource;
(R_a) is the actual resource identified at the sink;
9.5.3.21. Source page 1778 of the original technical specification
And (C) comprises current source-authority, namespace, ownership,
version, and operation context.
The predicate returns one of:
MATCH: The actual target is established as permitted.
MISMATCH: The actual target is established as outside the authorized
resource envelope.
INDETERMINATE: The evidence is insufficient.
21.11.1 — Exact Identity Mode
The system requires the same underlying protected object identity.
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.11.2 — Version-Bound Mode
The system requires a specified version or permitted version range.
21.11.3 — Logical Continuity Mode
The system permits a resource migration or rename while preserving
established authorized logical identity.
21.11.4 — Equivalent Target Set
The original source may authorize a defined set of resources.
21.11.5 — No Implicit Equivalence
Equal filenames, IP addresses, object hashes, or visual labels do not
independently establish equivalence.
21.12 — MATERIAL AND NON-MATERIAL REBINDING
A principal implementation distinguishes benign alias changes from
material target substitutions.
21.12.1 — Non-Material Rename
A resource may be renamed while retaining a verified underlying
identity and permitted ownership.
21.12.2 — Material Target Replacement
An alias may begin resolving to an unrelated resource.
21.12.3 — Ownership Change
The actual resource may remain the same while current permission
changes.
21.12.4 — Content Replacement
An authorization may or may not permit new content versions of the
same logical resource.
21.12.5 — Provider Migration
9.5.3.22. Source page 1779 of the original technical specification
A resource may migrate to another service while preserving an
authenticated permitted identity relationship.
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.12.6 — Protected Classification
The system evaluates the change according to current source authority
and resource-specific semantics.
A change is not automatically harmless merely because the textual
resource name remains unchanged.
21.13 — FILESYSTEM IMPLEMENTATION
A PHOSITA may implement a filesystem-specific variation using current
object-handling mechanisms.
The protected system may establish the actual filesystem object
through a controlled open operation.
Where supported, the controller may use:
Directory-relative operations;
Restricted path resolution;
Object handles;
Current filesystem object identifiers;
Mount and namespace information;
And resource-version or generation evidence.
21.13.1 — Path-Only Authorization
A pathname alone may be insufficient for a strong object-identity
guarantee.
21.13.2 — Descriptor-Based Control
An opened object handle may provide a stronger connection to the
resource actually accessed.
21.13.3 — Relevant Generation
A filesystem object identifier should be combined with additional
identity or generation evidence where reuse is possible.
21.13.4 — Authorized Root
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A protected resource operation may be restricted to a designated
directory or namespace.
21.13.5 — Symbolic-Link Rules
The implementation may restrict or explicitly qualify symbolic-link
traversal.
9.5.3.23. Source page 1780 of the original technical specification
21.13.6 — Object-Specific Finality
The final operation is verified against the actual controlled object
rather than an untrusted earlier path string.
21.14 — SYMBOLIC-LINK REBINDING VARIATION
An agent receives authority to modify a particular file.
The relevant path contains a symbolic link.
After initial validation, the link is changed to point toward a
different file.
The protected Finality Sink does not assume that the original path
string still identifies the authorized object.
It resolves or retains the actual resource identity using a
technically appropriate controlled operation.
The actual target is compared with the permitted resource identity.
If the link points to an unauthorized object, the effect is refused.
21.14.1 — Candidate Technical Effect
The operation-specific authority remains bound to the authorized
resource rather than to a mutable untrusted path.
21.15 — FILE RENAME WITHOUT FALSE DENIAL
A file is authorized under one name.
The file is subsequently renamed.
A protected resolver establishes that the current target remains the
same underlying authorized object under the selected identity model.
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The current ownership and resource conditions remain valid.
The operation may proceed under the original authority where the
policy permits name-independent object identity.
21.15.1 — Technical Distinction
The architecture does not simply reject every path change.
It distinguishes a verified permitted rename from an unauthorized
target substitution.
21.16 — DELETION AND RECREATION
A resource is deleted.
9.5.3.24. Source page 1781 of the original technical specification
A new resource is created under the same name.
The new resource may possess different ownership, content, identity,
or resource-generation state.
A prior authorization for the deleted resource does not automatically
authorize the newly created resource.
The protected resource-generation condition distinguishes the new
object.
The actual sink rejects the stale operation where the original
authority requires the earlier object identity.
21.17 — MOUNT AND NAMESPACE CHANGE
A resource path may be interpreted under different mount or process
namespaces.
A protected implementation may identify:
The relevant namespace;
The protected root;
The actual mounted resource;
The required object identity;
And the applicable namespace generation.
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.17.1 — Multiple Namespaces
The same textual path may identify different resources.
21.17.2 — Remount
A mount change may alter the actual object reached by a path.
21.17.3 — Current Coverage
The resource sink verifies the actual resource under the current
protected namespace.
21.17.4 — Unauthorized Substitution
A path redirected into an unrelated namespace does not inherit
original permission.
21.18 — DATABASE RESOURCE IDENTITY
A database application may identify a record by an application-level
key.
For example:
CUSTOMER_ALIAS = "ACCOUNT-ALPHA" The alias may map to a protected
internal resource identifier.
9.5.3.25. Source page 1782 of the original technical specification
The protected controller may establish:
Tenant identity;
Internal record identity;
Resource version;
Authorized operation;
Current ownership;
And source-authority state.
At commit time, the actual database sink verifies the record and
current resource state.
21.18.1 — Record Replacement
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A reused account label must not automatically identify the same
protected record.
21.18.2 — Cross-Tenant Alias
Identical customer labels from different tenants must not become
equivalent without qualified authorization.
21.18.3 — Transactional Check
A supported conditional mutation may verify the current object
identity and version within the resource transaction.
21.18.4 — Candidate Technical Interaction
The originating logical referent is bound to a current authoritative
database record through a protected finality relationship.
21.19 — OBJECT STORAGE RESOURCE IDENTITY
An object-storage system may expose resources through bucket, key,
object ID, version, generation, or similar references.
A selected operation may be authorized for:
A specific immutable object version;
The current version of a permitted logical object;
Or a bounded set of object generations.
The protected identity predicate determines which relation is
required.
21.19.1 — Key Reuse
An object key may be reused.
9.5.3.26. Source page 1783 of the original technical specification
21.19.2 — Version-Bound Effect
A selected operation may require one specified version.
21.19.3 — Current-Object Effect
Another authorized operation may permit the current version under
protected conditions.
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.19.4 — Ownership
The resource's current tenancy and owner remain relevant.
21.19.5 — Sink Enforcement
The resource-side API or gateway verifies the actual object operation
before effectuation.
21.20 — URL AND HTTP RESOURCE IDENTITY
An autonomous agent may be authorized to interact with a selected
network resource.
The intended resource may be represented by a URI.
However, the URI's text does not automatically establish every
property of the actual receiving resource.
The protected controller may consider:
URI scheme;
Authority;
Effective port;
Query semantics;
Actual method;
Request body;
Authenticated service identity;
Resource version;
And relevant redirect behavior.
21.20.1 — URI Parsing
The implementation uses a defined parser and comparison policy.
9.5.3.27. Source page 1784 of the original technical specification
21.20.2 — Canonical Representation
The policy determines which normalization operations are permitted.
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.20.3 — Reserved Characters
Encoded delimiters and reserved characters must not be normalized in
a manner that changes protected resource semantics.
21.20.4 — Resource Authority
A URL permitted for one resource does not automatically authorize
arbitrary services at the same network address.
21.20.5 — Current Effect
The actual outgoing or receiving resource request is independently
verified.
21.21 — REDIRECT CHAIN VERIFICATION
An HTTP or equivalent network operation may follow one or more
redirects.
A principal implementation may treat redirects as resource-resolution
edges.
A non-limiting chain is:
AUTHORIZED RESOURCE A | v REDIRECT TARGET B | v REDIRECT TARGET C | v
ACTUAL RESOURCE D 21.21.1 — Authenticated Redirect Source
The system determines what properties the redirect source can
establish.
21.21.2 — Target Policy
The resulting target must remain within the authorized envelope or
undergo appropriate reauthorization.
21.21.3 — Method and Payload
The implementation determines whether the redirect changes relevant
request semantics.
21.21.4 — Cross-Origin Change
9.5.3.28. Source page 1785 of the original technical specification
A redirect to another origin may require new authorization or an
expressly permitted equivalence relation.
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.21.5 — Final Destination
The actual effectuation sink verifies the resource that will perform
the protected consequence.
21.21.6 — Redirect Limit
The implementation may restrict loops and excessive redirect depth.
21.22 — NETWORK NAME RESOLUTION
A hostname may resolve to one or several network addresses.
The selected protected policy may require validation of:
The intended service identity;
The permitted hostname;
The actual destination address;
The transport protocol;
The target port;
Relevant address-class restrictions;
And the application resource being invoked.
21.22.1 — DNS Evidence
A resolver response supplies name-to-address information under its
actual security guarantees.
21.22.2 — Service Authentication
Authenticated transport may separately establish selected server-
identity properties.
21.22.3 — Application Resource Identity
The receiving application may expose different resources under the
same server identity.
21.22.4 — Actual Effect
A network connection alone does not prove the application operation's
intended resource effect.
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.22.5 — Rebinding
A material resolution change requires the applicable current
protected verification.
21.23 — NETWORK REBINDING ATTACK
9.5.3.29. Source page 1786 of the original technical specification
An agent receives permission to transmit information to an authorized
service.
The system initially resolves the service name to a permitted
endpoint.
Before transmission, a different address is returned.
The protected network controller verifies the current resolution and
applicable destination conditions.
If the new endpoint lies outside the permitted effectuation envelope,
the transmission is refused.
Where the underlying operation requires verification of the
application recipient, the content-aware protected service must
establish that condition separately.
21.23.1 — Technical Effect
A historical permissible DNS response cannot independently authorize
all later destinations associated with the same textual name.
21.24 — SERVICE DISCOVERY AND PROXY REBINDING
A protected service may be reached through a discovery registry,
internal proxy, or routing layer.
The protected resource controller may maintain:
Original logical service identity;
Current service registry generation;
Permitted receiving service class;
Actual backend resource identity where required;
And current effectuation-path coverage.
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A change in backend identity may be harmless when the new backend is
an authenticated equivalent resource instance.
Another change may introduce an unauthorized service or weaker
resource-side enforcement.
The system must distinguish these cases.
21.24.1 — Load-Balanced Resources
Several physical instances may serve one permitted logical resource.
The source authority may permit the entire qualified service class.
21.24.2 — Different Resource Semantics
A different backend cannot inherit permission where the resulting
actual effect is materially different.
9.5.3.30. Source page 1787 of the original technical specification
21.24.3 — Current Gate
The actual receiving service or qualified gateway verifies the
required operation.
21.25 — CROSS-DOMAIN RESOURCE MIGRATION
A resource may move from one administrative domain to another.
A protected migration-continuity process may establish:
The original resource identity;
The source domain;
The destination domain;
A qualified migration event;
The resulting resource identity;
Applicable ownership transfer;
Current source and destination authority;
And current effectuation policy.
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.25.1 — Migration Evidence
A protected source and destination service may authenticate relevant
correspondence.
21.25.2 — New Ownership
The destination authority must support the proposed resource
operation.
21.25.3 — Resource Version
The migrated resource's permitted version or state is verified.
21.25.4 — No Automatic Permission Portability
A migration receipt does not independently confer unrestricted rights
in the destination domain.
21.25.5 — Actual Sink
The destination Finality Sink independently verifies the actual
target and current authority.
21.26 — RESOURCE OWNERSHIP TRANSFER
A resource may remain technically identifiable while its authorized
controller changes.
For example:
9.5.3.31. Source page 1788 of the original technical specification
A document may be transferred to another enterprise account.
A device may be reassigned to another owner.
A cloud resource may move into another administrative project.
An earlier permission may no longer apply.
The protected resource identity record may therefore include current
ownership or control generation.
The sink checks the applicable current owner and source-authority
relationship.
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A valid old identity commitment does not override an authoritative
ownership change.
21.27 — DEVICE AND HARDWARE RESOURCE IDENTITY
A hardware command may be addressed to a logical device identifier.
A protected device registry may resolve the identifier to a specific
current controller or physical device.
The actual command sink may verify:
Hardware or protected device identity;
Current ownership;
Current command target;
Current resource generation;
Applicable safety constraints;
And operation-specific finality authority.
21.27.1 — Device Replacement
A replacement device cannot automatically inherit every earlier
actuation permission.
21.27.2 — Device Migration
A permitted migration may preserve bounded logical authority under
current verification.
21.27.3 — Virtual Interface
A virtual device reference may be mapped to a current physical
endpoint.
21.27.4 — Actual Command
The protected hardware sink verifies the actual command destination.
9.5.3.32. Source page 1789 of the original technical specification
21.28 — CONTENT HASHES AND IDENTITY LIMITATIONS
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A cryptographic digest may establish correspondence of selected
content bytes under the applicable algorithm and encoding.
It does not automatically establish:
Resource ownership;
Current source permission;
Storage location;
Resource tenancy;
Receiving service identity;
Or permissible consequential operation scope.
21.28.1 — Equal Content, Different Authority
Two resources may contain the same information but belong to
different principals.
21.28.2 — Same Logical Resource, New Content
A legitimate mutable document may acquire new bytes while retaining
its authorized logical identity.
21.28.3 — Required Identity Model
The protected system determines whether content equality, object
identity, version identity, or a combination is required.
21.28.4 — Candidate Technical Interaction
Content commitments may contribute evidence but do not independently
replace resource-side authority verification.
21.29 — CANONICALIZATION AND RESOURCE IDENTITY
The system may represent resource-identity evidence using a
deterministic structured encoding.
A representative commitment is:
[ C_R=H(\operatorname{Canon}(R,N,B,V,A)) ]
where:
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
(R) denotes the relevant resource identifier;
(N) denotes its namespace;
9.5.3.33. Source page 1790 of the original technical specification
(B) denotes current binding evidence;
(V) denotes applicable version state;
And (A) denotes current authority information.
21.29.1 — Deterministic Representation
The encoding must avoid inconsistent interpretation of the protected
fields.
21.29.2 — Typed Resource Identifiers
Filesystem paths, URLs, database keys, and hardware identifiers need
not share one ambiguous string-comparison rule.
21.29.3 — Numeric Representation
Relevant numeric fields use unambiguous typed semantics.
21.29.4 — Unicode Processing
The protocol defines applicable text normalization without silently
changing resource identity.
21.29.5 — Case Sensitivity
The relevant resource provider's comparison semantics must be
considered.
21.29.6 — No Semantic Proof from Canonicalization Alone
Canonical encoding establishes repeatable representation, not factual
or authorization equivalence.
21.30 — RESOURCE IDENTITY FRESHNESS
Resource-resolution evidence may become stale.
A selected implementation may require:
Current binding generation;
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Current namespace generation;
Current resource version;
Current ownership state;
A bounded evidence age;
Or a current authoritative resource handle.
21.30.1 — Stable Binding
A selected resource relation may remain valid over several operations
under explicitly permitted conditions.
9.5.3.34. Source page 1791 of the original technical specification
21.30.2 — Rapidly Mutable Binding
Another relation may require fresh validation immediately before
effectuation.
21.30.3 — Protected Epoch
A material binding change may advance an authoritative generation.
21.30.4 — Sink Verification
The actual Finality Sink verifies the applicable current state.
21.31 — PROTECTED RESOURCE REVALIDATION FENCE
A Resource Revalidation Fence may be activated when:
An authoritative alias changes;
A resource is replaced;
A resource namespace changes materially;
A version becomes invalid;
Ownership is transferred;
A required resolver becomes unavailable;
A redirect changes the permitted actual target;
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Or another mandatory identity predicate cannot be established.
The fence may prevent:
A storage commit;
A file deletion;
A remote transmission;
A payment;
A device command;
Or another covered consequential effect.
The requesting agent cannot clear the fence through a self-generated
statement that the resource remains equivalent.
The protected controller requires the relevant qualified
correspondence evidence or new source authorization.
9.5.3.35. Source page 1792 of the original technical specification
21.32 — ALIAS REBINDING AND SOURCE AUTHORITY
A resource-reference change may be:
A permitted equivalent alias;
An unauthorized target substitution;
Or an unresolved identity condition.
21.32.1 — Permitted Change
The resource identity and current authority satisfy the original
equivalence predicate.
21.32.2 — Unauthorized Change
The resulting actual target lies outside permitted scope.
21.32.3 — Unresolved Change
Required evidence cannot establish correspondence.
21.32.4 — New Authorization
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A permitted principal may establish new scope for an otherwise
eligible target change.
21.32.5 — Mandatory Protection
New discretionary authorization does not override another required
safety, ownership, or actual-operation predicate.
21.33 — AUTHORITY BOUND TO A RESOURCE EQUIVALENCE CLASS
A selected source authorization may define a bounded set of
equivalent resource targets.
For example:
A particular logical storage object may be served by several
authenticated replicas.
A selected database record may migrate within a permitted service
domain.
A protected device may be reachable through two approved
communication paths.
The equivalence class may be represented as:
AUTHORIZED_RESOURCE_CLASS = { source_authority,
logical_resource_identity, permitted_resource_instances,
qualified_equivalence_rules, current_resource_generations,
permitted_domains, required_ownership_state,
9.5.3.36. Source page 1793 of the original technical specification
authorized_effect_class, protected_authentication } The actual sink
verifies that the current target belongs to the authorized class.
The agent cannot enlarge the class by adding an alias.
21.34 — MULTI-ALIAS RESOLUTION AND AMBIGUITY
A logical reference may resolve to several candidates.
The system may require:
One unambiguous actual target;
A bounded permitted set;
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Or a specific conditional selection rule.
A name resolving to multiple possible targets does not automatically
authorize all of them.
21.34.1 — One-Target Authorization
Only the designated actual resource is permitted.
21.34.2 — Authorized Group
A bounded group of resources may be allowed.
21.34.3 — Ambiguous Resolution
The operation is withheld when required target identity cannot be
established.
21.34.4 — Qualified Selection
A protected resolver may select the target according to a permitted
rule.
21.34.5 — Actual Verification
The Finality Sink checks the selected actual target.
21.35 — ORIGINAL RESOURCE IDENTITY VERSUS CURRENT TARGET
The system distinguishes:
The resource the user or source originally intended;
The name the agent supplied;
The resource a resolver selected;
The resource the application prepared to access;
9.5.3.37. Source page 1794 of the original technical specification
And the resource the Finality Sink actually affects.
A principal implementation binds the original authorization to the
actual effect target through qualified protected evidence.
21.35.1 — No Sole Reliance on Requester
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The agent's reported resource identity is not sufficient where the
actual operation may differ.
21.35.2 — No Sole Reliance on Old Resolution
Historical correspondence is not automatically current.
21.35.3 — No Sole Reliance on Transport Endpoint
A permitted network endpoint does not independently identify the
internal resource.
21.35.4 — Resource-Specific Release
The actual consequential target must satisfy the appropriate
protected predicate.
21.36 — PROTECTED FINALITY ENABLEMENT
A representative resource-bound finality structure may comprise:
RESOURCE_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
original_authorized_resource_commitment, authorized_effect_envelope,
qualified_resolution_evidence_digest,
resource_equivalence_policy_digest,
permitted_actual_resource_identity, current_namespace_generation,
current_binding_generation, current_resource_generation,
current_ownership_generation, current_source_authority_generation,
designated_finality_sink, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The requesting agent may receive only an inert handle or reference.
The actual Finality Sink must verify the corresponding protected
authority.
A copy of the reference does not independently permit operation on
another target.
21.37 — INDEPENDENT ACTUAL RESOURCE RECONSTRUCTION
The actual Finality Sink obtains or reconstructs the resource that
would receive the effect.
9.5.3.38. Source page 1795 of the original technical specification
The method depends upon the resource substrate.
21.37.1 — Filesystem
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The controlled file operation may expose the actual object handle or
authoritative resource metadata.
21.37.2 — Database
The controlled mutation identifies the actual record, tenant,
version, and transaction state.
21.37.3 — Object Storage
The controlled operation identifies the actual bucket, key, version
or generation, and relevant ownership.
21.37.4 — Network
The controlled gateway identifies the actual outgoing or receiving
request and the resource properties it can genuinely observe.
21.37.5 — Hardware
The command controller identifies the actual device and command
target.
21.37.6 — Cross-Domain Resource
A destination-side resource controller may be required to establish
the actual internal target.
21.37.7 — Technical Limitation
A gateway that only observes a transport request cannot claim to have
verified a remote service's hidden internal resource state without
adequate destination-side evidence or control.
21.38 — SINK-TIME CORRESPONDENCE
The Finality Sink verifies:
The protected Candidate Act;
The original authorized resource reference;
The qualified resolution evidence;
The actual target resource;
Current source authority;
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Current namespace and binding state;
Current resource version;
Current ownership conditions;
9.5.3.39. Source page 1796 of the original technical specification
The permitted operation parameters;
Applicable protected finality enablement;
And sink-local protected consumption state.
A representative predicate may comprise:
SOURCE_AUTHORITY_CURRENT AND ORIGINAL_REFERENT_VALID AND
RESOURCE_RESOLUTION_QUALIFIED AND ACTUAL_TARGET_CORRESPONDS AND
CURRENT_NAMESPACE_VALID AND CURRENT_BINDING_VALID AND
CURRENT_RESOURCE_STATE_VALID AND CURRENT_OWNERSHIP_AUTHORITY_VALID
AND ACTUAL_EFFECT_WITHIN_ENVELOPE AND FINALITY_ENABLEMENT_VALID AND
CONSUMPTION_AVAILABLE A required failure prevents the corresponding
consequential release.
21.39 — PROTECTED CONSUMPTION AND RESOURCE MUTATION
A selected implementation may atomically consume finality authority
and perform a supported local resource mutation.
For example, a protected transactional database may:
Lock or conditionally read the actual record;
Verify current resource identity;
Verify the source-authority and binding generations;
Verify finality eligibility;
Consume the permitted authority;
Apply the actual mutation;
And commit the corresponding protected state.
The transaction semantics must support the asserted concurrency and
atomicity guarantees.
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Where the effect is external, the system separately governs durable
dispatch and uncertain outcome.
21.40 — REFERENCE DATA STRUCTURE: RESOURCE IDENTITY COMMITMENT
PROTECTED_RESOURCE_IDENTITY_COMMITMENT = { protocol_version,
candidate_act_id, originating_principal,
9.5.3.40. Source page 1797 of the original technical specification
source_grant_reference, original_resource_reference,
original_resource_identity, resource_namespace,
qualified_resolver_identity, alias_lineage_commitment,
actual_resource_identity, permitted_equivalence_class,
resource_version, binding_epoch, namespace_epoch, ownership_epoch,
current_authority_epoch, effect_descriptor_commitment,
designated_finality_sink, protected_authentication } Fields may be
omitted when they are not relevant to the selected resource class.
The necessary identity properties must still be sufficiently
represented for the actual effect authorization.
21.41 — REFERENCE ALGORITHM: QUALIFIED RESOURCE RESOLUTION
FUNCTION QUALIFY_RESOURCE_RESOLUTION( original_referent,
submitted_reference, protected_resolver ):
REQUIRE VERIFY_ORIGINAL_REFERENT( original_referent )
REQUIRE VERIFY_RESOLVER_AUTHORITY( protected_resolver )
result = protected_resolver .RESOLVE_CURRENT_RESOURCE(
submitted_reference )
IF result.status != RESOLVED: RETURN RESOURCE_IDENTITY_INDETERMINATE
REQUIRE VERIFY_RESOLVER_EVIDENCE( result )
REQUIRE VERIFY_RELEVANT_NAMESPACE(
9.5.3.41. Source page 1798 of the original technical specification
result )
REQUIRE VERIFY_BINDING_GENERATION( result )
REQUIRE VERIFY_RESOURCE_VERSION( result )
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
REQUIRE VERIFY_CURRENT_OWNERSHIP_CONDITIONS( result )
correspondence = PROTECTED_RESOURCE_EQUIVALENCE_CHECK(
original_referent, result.actual_resource, CURRENT_AUTHORITY_POLICY()
)
IF correspondence == MISMATCH: RETURN DENY_RESOURCE_SUBSTITUTION
IF correspondence == INDETERMINATE: RETURN HOLD_RESOURCE_REVALIDATION
RETURN AUTHENTICATED_RESOURCE_RESOLUTION({ original:
HASH(original_referent),
resolved_resource: HASH(result.actual_resource),
alias_lineage: HASH(result.alias_evidence),
binding_generation: result.binding_generation,
resource_generation: result.resource_generation,
ownership_generation: result.ownership_generation }) The algorithm
depends upon a resolver capable of supplying the asserted evidence.
21.42 — REFERENCE ALGORITHM: RESOURCE IDENTITY CONTINUITY
9.5.3.42. Source page 1799 of the original technical specification
FUNCTION VERIFY_RESOURCE_IDENTITY_CONTINUITY( original_authority,
resolution_evidence, actual_target,
protected_correspondence_controller ):
REQUIRE VERIFY_SOURCE_AUTHORITY( original_authority )
REQUIRE VERIFY_RESOLUTION_EVIDENCE( resolution_evidence )
REQUIRE VERIFY_ACTUAL_TARGET_EVIDENCE( actual_target )
policy = protected_correspondence_controller
.LOAD_AUTHORIZED_EQUIVALENCE_POLICY( original_authority )
REQUIRE VERIFY_EQUIVALENCE_POLICY_AUTHENTICITY( policy )
identity_result = protected_correspondence_controller
.COMPARE_IDENTITY_PROPERTIES({ original_resource:
original_authority.resource,
resolved_resource: resolution_evidence.resource,
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
actual_resource: actual_target,
required_properties: policy.required_identity_fields })
IF identity_result == MISMATCH: RETURN DENY
IF identity_result == UNKNOWN: RETURN HOLD
REQUIRE VERIFY_CURRENT_BINDING_AND_OWNERSHIP()
9.5.3.43. Source page 1800 of the original technical specification
RETURN RESOURCE_CONTINUITY_ACCEPTED The correspondence may be exact
or may use an expressly permitted equivalent-resource relation.
21.43 — REFERENCE ALGORITHM: REBINDING DETECTION
FUNCTION HANDLE_RESOURCE_REBINDING( candidate_act,
previous_resolution, current_resolution, protected_controller ):
REQUIRE VERIFY_PREVIOUS_RESOLUTION( previous_resolution )
REQUIRE VERIFY_CURRENT_RESOLUTION( current_resolution )
delta = COMPARE_MATERIAL_RESOURCE_BINDINGS( previous_resolution,
current_resolution )
IF delta == NO_MATERIAL_CHANGE: RETURN
REQUIRE_CURRENT_SINK_VERIFICATION
IF PROVE_PERMITTED_RESOURCE_CONTINUITY( candidate_act,
current_resolution ): RETURN REVALIDATE_FINALITY_BINDING
INVALIDATE_AFFECTED_FINALITY_ENABLEMENT( candidate_act )
IF delta == UNAUTHORIZED_TARGET_CHANGE: RETURN DENY
RETURN REQUIRE_NEW_QUALIFIED_RESOLUTION Where a changed target
requires expanded source authority, the corresponding protected
reauthorization process may be invoked.
21.44 — REFERENCE ALGORITHM: ACTUAL SINK FINALITY
FUNCTION EFFECTUATE_RESOURCE_BOUND_CANDIDATE( candidate_act,
resource_resolution_commitment,
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.44. Source page 1801 of the original technical specification
finality_enablement, protected_finality_sink ):
actual = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_target = protected_finality_sink
.IDENTIFY_ACTUAL_RESOURCE_TARGET( actual )
REQUIRE actual_target IS QUALIFIED
REQUIRE VERIFY_SOURCE_AUTHORITY_CURRENT()
REQUIRE VERIFY_ORIGINAL_RESOURCE_REFERENT( candidate_act )
REQUIRE VERIFY_RESOURCE_RESOLUTION_COMMITMENT(
resource_resolution_commitment )
REQUIRE VERIFY_CURRENT_NAMESPACE_AND_BINDING()
REQUIRE VERIFY_CURRENT_RESOURCE_IDENTITY( actual_target )
REQUIRE VERIFY_RESOURCE_CORRESPONDENCE( candidate_act,
resource_resolution_commitment, actual_target )
REQUIRE VERIFY_CURRENT_OWNERSHIP_AND_RESOURCE_STATE()
REQUIRE VERIFY_ACTUAL_OPERATION_EFFECT_ENVELOPE( actual )
REQUIRE VERIFY_CURRENT_NON_BEARER_FINALITY( finality_enablement,
actual, actual_target )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION()
committed = protected_finality_sink .COMMIT_RESOURCE_BOUND_FINALITY(
9.5.3.45. Source page 1802 of the original technical specification
actual, actual_target, finality_enablement )
IF committed != SUCCESS: RETURN DENY
RETURN protected_finality_sink .RELEASE_ACTUAL_RESOURCE_EFFECT(
actual, actual_target ) Where the sink's consumption transition and
actual resource mutation cannot be committed in one transaction, the
implementation separately governs dispatch and outcome
reconciliation.
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.45 — REFERENCE ALGORITHM: PROTECTED ALIAS GRAPH VERIFICATION
FUNCTION VERIFY_PROTECTED_ALIAS_GRAPH( original_resource,
proposed_resolution_graph, protected_graph_verifier ):
REQUIRE VERIFY_GRAPH_AUTHENTICITY( proposed_resolution_graph )
REQUIRE VERIFY_GRAPH_STARTS_AT_ORIGINAL( proposed_resolution_graph,
original_resource )
REQUIRE GRAPH_SIZE_WITHIN_VALIDATION_BUDGET()
visited = EMPTY_SET
FOR EACH edge IN REQUIRED_RESOLUTION_PATH:
IF edge IN visited: RETURN REJECT_RESOLUTION_CYCLE
visited.ADD(edge)
REQUIRE VERIFY_EDGE_RESOLVER_IDENTITY( edge )
REQUIRE VERIFY_EDGE_CURRENT_GENERATION( edge )
9.5.3.46. Source page 1803 of the original technical specification
REQUIRE VERIFY_EDGE_SCOPE( edge )
REQUIRE VERIFY_AUTHORIZED_RESOURCE_TRANSFORMATION( edge )
resolved = GET_FINAL_RESOLVED_RESOURCE()
RETURN AUTHENTICATED_RESOLUTION_RESULT( resolved,
HASH_CANONICAL(proposed_resolution_graph) ) The resolution graph may
use a tree, chain, registry lookup, or another bounded representation
rather than a full general-purpose graph.
21.46 — WORKED EXAMPLE A: SYMBOLIC-LINK TARGET SUBSTITUTION
An autonomous agent is authorized to modify a designated project
document.
The agent refers to the document through a symbolic link.
The original protected resolution identifies Resource A.
Before actual mutation, the symbolic link is changed to Resource B.
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected Finality Sink obtains the current actual file object.
The current object is not equivalent to Resource A under the original
authorization.
The mutation is denied.
Expected demonstrable result: A valid earlier file-path authorization
cannot be redirected toward a different actual object merely by
changing an intermediate symbolic link.
21.47 — WORKED EXAMPLE B: PERMITTED FILE RENAME
An agent is authorized to update one specific document.
The document is renamed within the permitted workspace.
The protected resolver establishes that the underlying object
identity remains the same under a current permitted ownership and
identity relation.
The sink verifies the operation against the actual object.
The authorized mutation may proceed without unnecessarily requiring
new discretionary permission.
9.5.3.47. Source page 1804 of the original technical specification
Expected demonstrable result: The system distinguishes valid resource
continuity from an unauthorized resource substitution.
21.48 — WORKED EXAMPLE C: SAME FILENAME, NEW RESOURCE
An authorized file is deleted.
A new file is created under the same path.
The newly created object has a different protected resource
generation.
The agent presents an older finality reference.
The sink observes that the actual object no longer matches the
original authorized identity.
The stale operation is refused.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected demonstrable result: Reuse of a logical resource name does
not automatically preserve historical object-specific finality
authority.
21.49 — WORKED EXAMPLE D: DATABASE ALIAS REBINDING
An agent is permitted to update the record associated with a
specified customer.
An application-level alias initially resolves to one authorized
database record.
The alias is changed to a different tenant's record.
The actual database sink reconstructs the target row, tenant, and
current record identity.
The protected identity predicate fails.
The update is rejected.
Expected demonstrable result: Cross-tenant resource substitution is
prevented even when the same application-level alias is submitted.
21.50 — WORKED EXAMPLE E: HTTP REDIRECT TO AN UNAUTHORIZED
DESTINATION
An agent receives permission to upload a protected document to a
designated service.
The initially permitted endpoint returns a redirect to another
service.
The protected network or application gateway evaluates the new target
against the original effect envelope.
The new destination is not within the authorized recipient class.
The transmission is withheld.
9.5.3.48. Source page 1805 of the original technical specification
Expected demonstrable result: An earlier valid endpoint authorization
does not independently permit redirection of protected content to an
unrelated destination.
21.51 — WORKED EXAMPLE F: AUTHORIZED SERVICE RELOCATION
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An enterprise service migrates to another qualified backend.
The original authorization permits the authenticated logical service
identity and current qualified replacement instances.
The protected resolver verifies the current backend belongs to the
permitted service class.
The receiving Finality Sink verifies the actual resource operation
and current source authority.
The operation may proceed without assuming that every backend address
change is unauthorized.
Expected demonstrable result: A legitimate service relocation can
preserve bounded authorization through explicit protected equivalence
rather than unconditional acceptance or blanket denial.
21.52 — WORKED EXAMPLE G: DNS REBINDING
An agent requests an authorized external API operation.
The initial hostname resolution identifies an allowed address.
A later resolution identifies a prohibited destination.
The protected controller evaluates the actual pending network
destination and relevant resource identity conditions.
The old approved result does not override the current mismatch.
The effect is refused.
Expected demonstrable result: Historical name resolution is
insufficient to authorize a newly substituted network target.
21.53 — WORKED EXAMPLE H: OBJECT STORAGE VERSION CHANGE
An agent is permitted to delete one specific versioned object.
The storage key later identifies a newer object version.
The protected delete operation is bound to the original version.
The receiving storage sink verifies current version identity.
The stale delete is rejected.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected demonstrable result: A valid logical object key does not
override an explicitly version-bound finality condition.
9.5.3.49. Source page 1806 of the original technical specification
21.54 — WORKED EXAMPLE I: RESOURCE OWNERSHIP TRANSFER
A cloud resource is originally controlled by one authorized
principal.
The resource is later transferred to another administrative owner.
The previous agent retains a historically valid resource reference.
The actual sink verifies current ownership and source authorization.
The historical resource identity does not establish current
authority.
The operation is refused.
Expected demonstrable result: Object-identity continuity does not
independently override current resource ownership.
21.55 — WORKED EXAMPLE J: HARDWARE DEVICE REPLACEMENT
An autonomous controller is authorized to operate a particular
device.
The device is replaced with different hardware under the same logical
device label.
The protected resource registry identifies a new hardware or
authority generation.
The actual device command sink verifies the current target identity.
The old command authorization cannot automatically actuate the
replacement device.
Expected demonstrable result: A reused logical device label does not
create unrestricted hardware command authority.
21.56 — WORKED EXAMPLE K: USER-VISIBLE OBJECT SUBSTITUTION
A user selects a document in an application interface.
The application later remaps the displayed label to another document.
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected interface evidence may identify the original selected
object.
The actual resource sink reconstructs the file or document being
modified.
The original referent and actual resource do not correspond.
The operation is refused.
Expected demonstrable result: A user-visible selection remains
protected against an unauthorized underlying resource substitution.
21.57 — WORKED EXAMPLE L: CROSS-DOMAIN RESOURCE MIGRATION
9.5.3.50. Source page 1807 of the original technical specification
An enterprise document is migrated to a new storage domain.
The source and destination resource authorities provide qualified
migration identity evidence.
The original permission allows a bounded migration with continuing
ownership conditions.
The destination sink verifies the actual migrated object and current
operation scope.
The authorized operation may proceed where the protected
correspondence is established.
Expected demonstrable result: Legitimate cross-domain continuity is
supported without treating any claimed migration or redirect as
sufficient authority.
21.58 — WORKED EXAMPLE M: IDENTICAL CONTENT, DIFFERENT OWNER
Two resources contain identical bytes.
An agent possesses authority to disclose Resource A.
The agent attempts to disclose Resource B based only on a matching
content digest.
The protected resource controller verifies current object identity
and ownership.
Resource B is not authorized.
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The disclosure is denied.
Expected demonstrable result: Content equality is not silently
promoted into resource-ownership or disclosure authority.
21.59 — WORKED EXAMPLE N: SERVICE ALIAS COLLISION
Two administrative tenants use the same short logical service name.
A requester is authorized to invoke a service within Tenant A.
The request is inadvertently resolved within Tenant B.
The protected resource identity includes the applicable tenant or
domain.
The actual sink verifies the current target and source authority.
The mismatched operation is denied.
Expected demonstrable result: Namespace-local identifier equality
does not authorize cross-tenant effects.
21.60 — WORKED EXAMPLE O: ASYNCHRONOUS OPERATION AFTER REBINDING
An autonomous agent prepares a delayed resource mutation.
9.5.3.51. Source page 1808 of the original technical specification
The corresponding resource alias is later changed.
The job queue still contains the earlier logical reference.
When the delayed task reaches the actual sink, the controller
reconstructs current resource identity and binding state.
If the actual resource differs materially from the original
authorized target, the operation remains withheld.
Expected demonstrable result: Queueing an operation does not freeze
unlimited permission over future targets associated with a mutable
name.
21.61 — WORKED EXAMPLE P: MULTI-AGENT RESOURCE REBINDING
Agent A prepares an authorized operation on Resource X.
Agent B independently changes a shared alias to Resource Y.
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Agent A later attempts effectuation.
The protected resource controller checks the actual target and
current alias-binding generation.
The previous authority cannot be applied to Resource Y unless the
source authorization expressly permits that equivalence.
Expected demonstrable result: Resource-binding races among agents
cannot silently redirect operation-specific finality authority.
21.62 — WORKED EXAMPLE Q: REDIRECTED PAYMENT DESTINATION
An autonomous financial application prepares payment to an authorized
destination.
An intermediate application service changes an account alias or
downstream payment recipient.
The actual payment Finality Sink independently determines the
effective destination account.
The destination does not satisfy the original protected payment
authority.
The operation is refused.
Expected demonstrable result: A payment-target alias cannot
substitute another actual beneficiary without the required current
authorization.
21.63 — WORKED EXAMPLE R: PRIVILEGED RESOURCE BROKER
An untrusted agent requests access to a file using an alias.
A privileged broker possesses the actual file-access authority.
9.5.3.52. Source page 1809 of the original technical specification
The broker independently resolves the resource, validates current
source scope, and obtains the corresponding object handle.
The broker performs only the permitted operation.
The agent never receives unrestricted authority to choose another
privileged target.
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected demonstrable result: Privileged resource-access capability
remains restricted to a protected actual resource identity despite
untrusted alias input.
21.64 — PROTECTED STATE MACHINE
A non-limiting state machine comprises:
REFERENT_AUTHORIZED: The original source-authorized resource referent
is established.
CANDIDATE_PREPARED: A consequential Candidate Act exists.
NON_EFFECTIVE: The proposed effect remains withheld.
RESOLUTION_PENDING: Current actual target identity is unresolved.
RESOLUTION_EVIDENCE_AVAILABLE: Qualified resolution information has
been obtained.
ALIAS_LINEAGE_VERIFIED: Required alias transformations are
authenticated.
RESOURCE_CORRESPONDENCE_PENDING: Equivalence remains unverified.
RESOURCE_MATCHED: The actual target satisfies the protected identity
predicate.
RESOURCE_MISMATCHED: The target lies outside permitted scope.
RESOURCE_AMBIGUOUS: The target cannot be sufficiently identified.
REBINDING_DETECTED: A relevant resource mapping has changed.
REVALIDATION_REQUIRED: Current resolution and authority must be
reestablished.
AUTHORITY_PREPARED: Scoped non-bearer finality enablement exists.
SINK_VERIFICATION_PENDING: The actual resource operation awaits
verification.
FINALITY_REJECTED: A mandatory predicate fails.
FINALITY_CONSUMED: The permitted use has been committed.
EFFECT_ATTEMPTED: The controlled operation has been released or
attempted.
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
EFFECT_CONFIRMED: Qualified evidence establishes the supported real
result.
EFFECT_INDETERMINATE: The actual external outcome remains unresolved.
RECOVERY_PENDING: Further authorized reconciliation is required.
9.5.3.53. Source page 1810 of the original technical specification
TERMINATED: The operation reaches a valid protected terminal
condition.
21.65 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Receive Source Authority. Establish the original principal
and permitted resource operation.
Step 2 — Establish Original Referent. Create a protected OARR-21.
Step 3 — Construct Candidate Act. Identify the intended consequential
operation.
Step 4 — Hold Non-Effective. Prevent premature resource
effectuation.
Step 5 — Identify Namespace. Determine the relevant resource-
resolution context.
Step 6 — Resolve Logical Reference. Obtain qualified current
resource-resolution evidence.
Step 7 — Authenticate Resolver. Verify the source and supported
evidence properties.
Step 8 — Establish Alias Lineage. Identify relevant transformations.
Step 9 — Verify Binding Generations. Check current resource and
namespace state.
Step 10 — Verify Ownership. Establish current applicable source
authority.
Step 11 — Evaluate Equivalence. Determine whether the actual target
remains within the original authorized resource envelope.
Step 12 — Apply Required Modules. Evaluate additional relevant CW-1
technical predicates.
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Step 13 — Collect Protected Evidence. Commit required resource-
resolution and authority evidence.
Step 14 — Independently Validate. Evaluate current execution-time
correspondence.
Step 15 — Prepare Finality Authority. Establish resource-specific
non-bearer enablement.
Step 16 — Present Actual Operation. Submit the pending resource
effect to its designated sink.
Step 17 — Reconstruct Actual Target. Obtain the resource actually
targeted by the controlled effectuation primitive.
Step 18 — Verify Current Binding. Check current resource identity,
namespace, version, and ownership conditions.
Step 19 — Verify Source Authority. Ensure current permission applies
to the actual target.
Step 20 — Verify Operation Scope. Confirm that the effect itself
remains permitted.
Step 21 — Verify Finality Authority. Match the enablement to the
actual target and sink.
Step 22 — Verify Consumption. Determine whether the protected use
remains available.
Step 23 — Commit Consumption. Perform the appropriate protected
transition.
9.5.3.54. Source page 1811 of the original technical specification
Step 24 — Release Actual Consequence. Permit the specified
operation.
Step 25 — Observe Result. Obtain qualified actual-effect evidence
where required.
Step 26 — Record Actual Resource. Preserve the resource identity
actually affected.
Step 27 — Govern Continuation. Apply optional causal-receipt and
scope-deviation procedures where relevant.
21.66 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
1. Symbolic-link target substitution.
2. Hard-link object ambiguity.
3. Parent-directory replacement.
4. Mount-namespace manipulation.
5. Directory remount after authorization.
6. File deletion and recreation.
7. Reuse of a filesystem object identifier.
8. Resource rename during a pending operation.
9. Stale open-path resolution.
10. Database alias collision.
11. Cross-tenant record substitution.
12. Reassignment of an application record identifier.
13. Object-storage key reuse.
14. Object version mismatch.
15. Redirect to an unauthorized destination.
16. Multi-hop redirect manipulation.
17. Cross-origin redirect without new authority.
18. Request-method change across redirects.
19. DNS rebinding.
20. Network destination address substitution.
21. Service-discovery registry manipulation.
22. Load-balancer backend replacement.
9.5.3.55. Source page 1812 of the original technical specification
23. Proxy-routing policy change.
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
24. Service identity versus application-resource confusion.
25. Cross-provider resource migration forgery.
26. Resource ownership transfer after approval.
27. Device replacement under a reused label.
28. Virtual device-to-physical-device rebinding.
29. Resource identity evidence replay.
30. Resolver identity impersonation.
31. Resolver authorized for the wrong resource domain.
32. Resource-binding generation rollback.
33. Namespace generation rollback.
34. Unicode normalization ambiguity.
35. Case-folding mismatch.
36. Percent-encoding interpretation mismatch.
37. Duplicate structured-data field ambiguity.
38. Resource alias loops.
39. Excessive alias-resolution depth.
40. Multiple possible actual targets.
41. Content digest falsely treated as ownership proof.
42. Stale resource-version evidence.
43. Revoked source authority following successful resolution.
44. Concurrent resource rebinding by another agent.
45. Delayed queued operation using an old binding.
46. Snapshot rollback restoring stale resource authority.
47. Cross-sink reuse of one resource-bound finality reference.
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
48. Unauthorized copied finality enablement.
49. An uncontrolled alternate resource access interface.
50. A remote gateway lacking actual destination-resource visibility.
9.5.3.56. Source page 1813 of the original technical specification
51. A compromised protected resource resolver.
52. A compromised Finality Sink.
53. A malicious resource-migration assertion.
54. Replayed prior actual-effect receipt for a different resource.
55. Authorization to disclose one object applied to another object
with identical bytes.
56. Resource reassignment during a hardware command.
57. Race between resource checking and commit.
58. Race between receipt acceptance and successor target rebinding.
59. Denial-of-service through expensive alias graphs.
60. Failure to distinguish harmless rename from malicious
replacement.
Each case must be evaluated against the specified protected resource
substrate and actual effectuation-path guarantees.
21.67 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed tests rather than reported completed
experiments.
Test 1 — Original Resource Authorization: Establish protected
authority for one identified resource.
Test 2 — Exact Identity Correspondence: Verify an unchanged actual
target.
Test 3 — Alias Resolution: Resolve a permitted alias to the correct
object.
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 4 — Symbolic-Link Substitution: Change the target before
effectuation.
Test 5 — Permitted Rename: Preserve valid identity continuity after a
rename.
Test 6 — Delete/Recreate: Replace a file using the same name.
Test 7 — Mount Change: Remount an alternative resource under the
original path.
Test 8 — Namespace Separation: Submit identical path strings from
different namespace contexts.
Test 9 — Hard-Link Equivalence: Verify object correspondence through
multiple names.
Test 10 — Object Identifier Reuse: Test a simulated resource
identifier reused after deletion.
Test 11 — Database Alias: Resolve a permitted application alias to
its internal record.
Test 12 — Cross-Tenant Alias: Substitute a same-named record from
another tenant.
Test 13 — Resource Version Change: Modify a database record before
final mutation.
9.5.3.57. Source page 1814 of the original technical specification
Test 14 — Object-Storage Version: Change the current object version
after authorization.
Test 15 — Redirect: Redirect an authorized request to another
resource.
Test 16 — Redirect Chain: Introduce multiple redirect hops.
Test 17 — Redirect Loop: Reject an unbounded or cyclic resolution.
Test 18 — Cross-Origin Redirect: Test a target outside the permitted
origin or recipient class.
Test 19 — Request Semantics: Alter method or protected payload across
a redirect.
Test 20 — DNS Rebinding: Change the resolved network destination.
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 21 — Service Authentication: Distinguish network address from
authenticated service identity.
Test 22 — Application Resource Identity: Use one service endpoint
exposing several differently authorized resources.
Test 23 — Service Discovery: Replace a backend mapping.
Test 24 — Valid Backend Migration: Accept an authenticated permitted
replacement instance.
Test 25 — Invalid Backend Migration: Reject a replacement outside the
authorized equivalence class.
Test 26 — Cross-Domain Resource Migration: Verify qualified migration
continuity.
Test 27 — Forged Migration Record: Reject an unauthorized migration
assertion.
Test 28 — Resource Ownership Transfer: Revoke or revalidate authority
following current ownership change.
Test 29 — Hardware Device Replacement: Reuse a logical device name
for another device.
Test 30 — Virtual Device Rebinding: Redirect a virtual device
reference to another physical target.
Test 31 — Unicode Resource Names: Test equivalent-looking but
distinct identifiers.
Test 32 — Case-Folding: Test resource systems with different
comparison semantics.
Test 33 — Percent-Encoding: Test security-relevant URL interpretation
differences.
Test 34 — Canonical Structured Encoding: Ensure equivalent protected
descriptors produce the expected deterministic representation.
Test 35 — Ambiguous Structured Data: Reject duplicate or conflicting
security-relevant fields.
Test 36 — Alias Graph Cycle: Verify bounded rejection of circular
references.
Test 37 — Alias Graph Depth: Bound resource-verification computation.
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 38 — Multiple Targets: Refuse an unqualified ambiguous resource.
9.5.3.58. Source page 1815 of the original technical specification
Test 39 — Permitted Target Set: Accept a qualified member of an
expressly authorized resource class.
Test 40 — Replayed Resolution Evidence: Reject obsolete resource-
binding generations.
Test 41 — Forged Resolver Identity: Reject evidence from an
unauthorized resolver.
Test 42 — Resolver Scope: Reject an otherwise authentic resolver
asserting identity outside its authorized domain.
Test 43 — Actual Sink Reconstruction: Verify the resource actually
targeted by the final operation.
Test 44 — Changed Target After Approval: Replace the resource after
finality preparation.
Test 45 — Source Authority Revocation: Revoke resource access after
successful identity resolution.
Test 46 — Protected Consumption: Attempt repeated use of one
resource-bound finality reference.
Test 47 — Cross-Sink Replay: Present one finality reference to
another resource sink.
Test 48 — Concurrent Agents: Race two agents against a mutable alias.
Test 49 — Resource Reservation: Test version or ownership consistency
during resource commit.
Test 50 — Delayed Workflow: Queue a mutation before resource
rebinding.
Test 51 — Content Equality: Compare identical bytes from differently
owned resources.
Test 52 — Privacy Release: Attempt disclosure of a substituted
protected document.
Test 53 — Payment Recipient: Substitute the actual payment account
behind an alias.
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 54 — Device Command: Change the actual device target between
preparation and release.
Test 55 — Incomplete Sink Coverage: Attempt the effect through
another uncontrolled API.
Test 56 — Remote Resource Visibility: Demonstrate which identity
properties a gateway can and cannot verify.
Test 57 — Crash Recovery: Restore authority state after an actual
mutation attempt.
Test 58 — Snapshot Rollback: Prevent reuse of obsolete resource-
generation and consumption state.
Test 59 — Actual Effect Receipt: Verify that a receipt identifies the
resource actually affected.
Test 60 — CW-2 Continuation: Require an accepted receipt for the
correct predecessor resource and effect.
Test 61 — CW-3 Scope Change: Classify a target substitution as a
protected scope deviation.
9.5.3.59. Source page 1816 of the original technical specification
Test 62 — Authorized Rebinding: Permit a genuine target change only
after valid new authorization where required.
Test 63 — Full End-to-End Test: Validate original referent, resource
resolution, correspondence, current authority, actual sink,
consumption, and outcome.
Test 64 — Ablation Without Sink Identity Check: Remove actual target
correspondence and compare unauthorized substitution acceptance.
Test 65 — Ablation Without Binding Generation: Remove current
generation checks and evaluate stale-resource reuse.
Test 66 — Ablation Without Protected Equivalence: Replace qualified
identity continuity with string-based resource-name comparison.
Test 67 — Cross-Domain Stress Test: Combine migration, ownership
changes, redirects, and concurrent resource mutations.
Test 68 — Adversarial Resolver Exhaustion: Test bounded parsing,
recursion depth, and verification work.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The results should distinguish simulated target identity, verified
resource-side state, attempted effectuation, and actual effect
completion.
21.68 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
21.68.1 — Minimum Reference Implementation
A practical prototype may comprise:
An autonomous software requester;
A protected authorization and resource-identity service;
A controlled resource resolver;
A transactional resource database;
And a resource-specific Finality Sink.
21.68.2 — Initial Configuration
The protected system authorizes one resource mutation.
The resource has a logical alias and an authoritative internal
identity.
21.68.3 — Candidate Act
The requester prepares an operation naming the logical resource.
21.68.4 — Protected Resolution
The resource resolver obtains the current underlying object identity
and generation.
9.5.3.60. Source page 1817 of the original technical specification
21.68.5 — Finality Preparation
The protected controller commits qualified resolution evidence and
prepares operation-specific non-bearer authority.
21.68.6 — Target Rebinding
The experiment changes the logical alias before actual mutation.
21.68.7 — Sink-Time Verification
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The sink determines the actual target and compares it with the
protected authorized resource identity.
21.68.8 — Protected Denial
An unauthorized substitution is refused.
21.68.9 — Equivalent Resource Test
A permitted resource rename or authorized equivalent alias is
introduced.
The system verifies continuity according to the selected policy.
21.68.10 — Consumption Test
The same finality reference is exercised twice.
The protected resource state must prevent unsupported repeated use.
21.68.11 — Prototype Limitation
A software-only reference prototype does not automatically establish
protection against compromise of its operating-system kernel or
another privileged component controlling all relevant state.
21.69 — PERFORMANCE AND IMPLEMENTATION ENGINEERING
21.69.1 — Resolution Caching
The system may cache qualified identity evidence subject to
appropriate freshness and binding-generation conditions.
21.69.2 — Resolver Work Budget
Alias graphs and nested references may be subject to bounded
verification costs.
21.69.3 — Namespace Partitioning
Different resource classes may employ different identity registries.
21.69.4 — Local Resource Optimization
9.5.3.61. Source page 1818 of the original technical specification
A protected file or database object handle may reduce repeated name
resolution where supported.
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.69.5 — Remote Resource Verification
Cross-domain identity evidence may require authenticated
communication with the resource owner.
21.69.6 — Version Validation
Conditional resource operations may reduce certain resource-state
races.
21.69.7 — Independent Sink Enforcement
Resource-side verification may add computation or latency before
consequential release.
21.69.8 — No Universal Identity Oracle
A system cannot assume one global authority can accurately identify
every external resource.
21.69.9 — Dynamic Equivalence
Legitimate migration may require protected equivalence-policy
updates.
21.69.10 — Fail-Closed Uncertainty
An unresolved mandatory target identity prevents the covered effect.
21.69.11 — Availability Tradeoff
A system may prioritize safe withholding over uncertain target
release.
21.69.12 — Hardware Limitations
Hardware identity evidence establishes only its supported properties
and does not automatically prove application-level authorization.
21.70 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
21.70.1 — Established Building Blocks
Resource naming, filesystem object handles, version identifiers, path
restrictions, cryptographic signatures, conditional requests,
distributed resource registries, and service authentication are
established technical mechanisms.
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The disclosed embodiment does not claim their individual invention.
21.70.2 — Candidate Objective Technical Problem
How to prevent operation-specific authority granted for an originally
identified resource from being misapplied to a materially different
actual resource following alias, namespace, redirect, migration, or
ownership changes, while allowing permitted resource identity
continuity to be verified and enforced at the actual consequential
resource boundary.
9.5.3.62. Source page 1819 of the original technical specification
21.70.3 — Proposed Technical Solution
A protected original resource referent is associated with a Candidate
Act.
Qualified resolution evidence establishes the relationship between
logical references and permitted actual resource identities.
Relevant namespace, binding, version, and ownership conditions are
maintained.
A protected controller establishes scoped non-bearer finality
enablement.
The actual Finality Sink independently reconstructs the pending
target and verifies the protected resource correspondence under
current authority.
The sink consumes operation-specific authority before permitting the
effect.
21.70.4 — Not Merely Path Normalization
Path normalization changes the representation of a resource path.
It does not necessarily establish the identity, ownership, or current
authorization of the actual target.
21.70.5 — Not Merely Symbolic-Link Protection
Restricted path traversal can prevent selected filesystem attacks.
The proposed system additionally binds the resolved actual resource
to originating task-specific finality authority and protected
consumption.
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.70.6 — Not Merely DNS Security
Authenticated name resolution may establish selected name-to-address
relationships.
It does not necessarily establish the actual application resource or
permitted consequential operation.
21.70.7 — Not Merely Conditional HTTP Requests
Conditional resource updates may verify a representation version.
The proposed broader relationship additionally maintains protected
continuity between the original authorized referent and the actual
resource operation.
21.70.8 — Not Merely Cryptographic Hashing
A content digest does not independently establish resource
authorization, namespace identity, or ownership.
21.70.9 — Not Merely Resource Migration
A resource migration can change location.
The selected stronger implementation requires qualified migration
continuity and current destination-side authority before
effectuation.
9.5.3.63. Source page 1820 of the original technical specification
21.70.10 — Candidate Narrow Inventive Kernel
A protected resource-identity execution-finality system in which an
original authorized resource referent is bound to a Candidate Act, a
protected controller obtains qualified current alias or namespace-
resolution evidence establishing a permissible resource identity
relationship, a scoped non-bearer finality enablement is bound to
that relationship and its applicable generations, and an
independently enforcing Finality Sink reconstructs the actual target
resource and permits the consequential operation only upon
verification of current resource correspondence, source authority,
effect scope, and sink-local protected consumption.
21.70.11 — Alias Rebinding Kernel
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A narrower candidate may require protected detection of a material
binding-generation change and invalidation of pending resource-
specific finality authority.
21.70.12 — Cross-Domain Kernel
Another candidate may require authenticated resource migration
correspondence verified by the destination Finality Sink.
21.70.13 — Dynamic Equivalence Kernel
Another candidate may require a protected distinction between benign
resource renaming and unauthorized target substitution.
21.70.14 — Actual Resource Handle Kernel
Another candidate may require the sink to resolve the actual resource
through a protected handle or equivalent authoritative resource
reference, rather than rely solely on a previously submitted textual
name.
21.70.15 — Multi-Namespace Kernel
Another candidate may require namespace identity and current resource
ownership as mandatory authority predicates.
21.70.16 — Hindsight Analysis
An inventive-step analysis should determine whether an earlier system
discloses the complete ordered relationship among original source-
authorized resource identity, protected current resolution evidence,
operation-specific finality authority, and actual resource-side
verification.
A mere collection of known resource-resolution techniques is
insufficient to establish the proposed stronger relationship.
At the same time, the mere absence of one named component from a
single earlier disclosure does not establish inventive step.
The evaluation should identify the closest prior systems, their
actual resource-control boundaries, the technical problem remaining
in those systems, and whether the asserted combination would have
been motivated by the prior disclosures rather than reconstructed
using later knowledge of the proposed invention.
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.64. Source page 1821 of the original technical specification
21.71 — INDUSTRIAL APPLICABILITY
21.71.1 — Autonomous File Management
Resource identity continuity may be enforced despite path changes and
symbolic links.
21.71.2 — Cloud Storage
Object versions and actual storage resources may be bound to
operation-specific authority.
21.71.3 — Distributed Databases
Application aliases may be verified against actual database records
and tenant identity.
21.71.4 — Enterprise Document Systems
User-visible documents may remain bound to actual authorized resource
identities.
21.71.5 — Financial Systems
Account aliases may be verified against actual payment destinations.
21.71.6 — Electronic Commerce
Merchant and resource references may be checked against actual
transaction targets.
21.71.7 — Network Security
Destination rebinding may be subject to current protected effect
authorization.
21.71.8 — Cloud Administration
Changing service and resource identifiers may require current
finality revalidation.
21.71.9 — Multi-Agent Systems
Concurrent agents may be prevented from redirecting one another's
authorized resource effects.
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.71.10 — Distributed Storage Migration
Resource movement may preserve valid authorization under qualified
migration continuity.
21.71.11 — Operating Systems
Filesystem and protected process services may verify actual resource
identities.
21.71.12 — Credential Brokering
A credential may be exercised only for a protected actual resource.
21.71.13 — Telecommunications
9.5.3.65. Source page 1822 of the original technical specification
Logical network resources may be verified against actual configured
infrastructure.
21.71.14 — Industrial Automation
Device aliases may be bound to the actual controlled equipment.
21.71.15 — Robotics
Actuator commands may verify current physical device identity.
21.71.16 — Autonomous Transportation
Selected control commands may remain bound to authorized actual
devices and resource ownership.
21.71.17 — Edge Computing
Resource identifiers may remain valid across approved local and
remote placements.
21.71.18 — Hardware Accelerators
Effect-capable device references may be constrained to authorized
actual command targets.
21.71.19 — Protected Information Disclosure
Actual data objects and recipients may be verified independently of
mutable names.
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
21.71.20 — Future Autonomous Critical Systems
Dynamic resource naming may remain subordinate to current protected
consequential authority.
21.72 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
21.72.1 — Candidate Independent System Claim
A system comprising:
A protected authorization controller configured to maintain an
original authorized resource referent associated with a consequential
Candidate Act;
A protected resource-resolution component configured to obtain
qualified evidence concerning an actual resource corresponding to a
submitted logical reference;
A correspondence validator configured to evaluate the actual resource
against the original authorized referent under applicable identity
and current-binding conditions;
A finality controller configured to establish scoped non-bearer
enablement bound to the permitted resource identity;
And an independent Finality Sink configured to reconstruct the actual
pending consequential operation and actual target resource, verify
current resource correspondence and source authority, and consume the
operation-specific finality enablement before permitting the effect.
9.5.3.66. Source page 1823 of the original technical specification
21.72.2 — Candidate Independent Method Claim
A method comprising:
Receiving a proposed consequential operation concerning a resource;
Constructing a Candidate Act;
Maintaining the effect non-effective;
Establishing an original authorized resource referent;
Obtaining qualified current resource-resolution evidence;
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Verifying the correspondence between the original resource referent
and the permitted actual target;
Establishing scoped non-bearer finality authority;
Independently reconstructing the actual target at a resource Finality
Sink;
Verifying current resource identity, binding, source authority, and
protected consumption;
And permitting effectuation only upon satisfaction of the required
predicates.
21.72.3 — Candidate Independent Rebinding Claim
Another candidate may require protected detection of a material
resource-binding change and invalidation of dependent finality
enablement until updated correspondence is established.
21.72.4 — Candidate Independent Cross-Domain Claim
Another candidate may require authenticated resource migration
evidence connecting original and destination resource identities,
with independent destination-side actual-resource verification.
21.72.5 — Candidate Independent Hardware Claim
Another candidate may require a protected device-command sink to
verify current logical-to-physical device correspondence and
operation-specific authority before hardware actuation.
21.73 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The original referent includes a logical resource name.
2. The original referent includes a qualified underlying object
identity.
3. The original referent includes the originating resource domain.
4. The original referent includes namespace identity.
5. The original referent includes a resource-generation reference.
6. The original referent includes current source-authority state.
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.67. Source page 1824 of the original technical specification
7. A protected resolver authenticates a name-to-resource mapping.
8. The resolver possesses a defined observation or authority role.
9. A protected resolution record includes a current binding
generation.
10. A protected resolution record includes a resource version.
11. A protected resolution record includes an ownership generation.
12. The system distinguishes content identity from object identity.
13. The system distinguishes object identity from current resource
authorization.
14. A content digest alone is insufficient where current ownership
is required.
15. A permitted resource rename preserves finality eligibility under
a qualified identity-continuity rule.
16. Replacement of an actual resource invalidates incompatible
earlier authority.
17. Deletion and recreation under the same name is identified
through current generation or object-identity evidence.
18. A filesystem resource is resolved using a protected object
handle.
19. A filesystem path is resolved relative to a qualified protected
directory.
20. A symbolic-link traversal is prohibited or qualified according
to the selected resource policy.
21. A mount or namespace change causes identity revalidation.
22. A database record identity is qualified by tenant or resource
domain.
23. A database mutation verifies an expected resource version.
24. An object-storage operation verifies a specified object version
where required.
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
25. An object key reuse does not automatically preserve historical
object-specific authority.
26. A URL is parsed under defined resource semantics.
27. A protected request verifies current destination identity.
28. A redirect creates a resource-resolution edge requiring
qualification.
29. A cross-origin redirect requires applicable current
authorization.
30. A redirect chain is bounded by a protected traversal policy.
31. A method or request-body change across a redirect is subject to
effect-scope verification.
32. A current network destination is compared with the original
permitted envelope.
9.5.3.68. Source page 1825 of the original technical specification
33. A DNS resolution result does not independently establish current
application-resource identity.
34. An authenticated service identity is verified where required.
35. A service-discovery change may invalidate dependent finality
authority.
36. A load-balanced backend may be accepted as part of a permitted
authenticated service class.
37. A cross-domain migration requires qualified source and
destination correspondence.
38. A migration receipt does not independently grant unrestricted
destination-resource authority.
39. A resource ownership change invalidates incompatible historical
permission.
40. A logical device identifier is bound to a current actual device.
41. A device replacement causes current identity or authority-
generation verification.
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
42. A protected equivalence class defines permitted alternative
actual targets.
43. An untrusted requester cannot enlarge the equivalence class.
44. A protected alias graph identifies authenticated resource-
reference transformations.
45. An alias graph is rejected when a required edge lacks qualified
evidence.
46. Alias traversal is subject to bounded verification depth.
47. A cyclic alias graph does not independently authorize a resource
effect.
48. An ambiguous required resource identity causes the effect to
remain withheld.
49. Resource identity commitments employ a deterministic typed
encoding.
50. The protected encoding distinguishes resource domains and
namespaces.
51. The encoding handles relevant numerical and textual ambiguity
under a defined protocol.
52. An earlier resolution commitment becomes invalid following a
material binding change.
53. A protected resource fence prevents effectuation pending
required revalidation.
54. The Finality Sink reconstructs the actual resource independently
of the agent's original label.
55. The Finality Sink verifies current original source authority.
56. The Finality Sink verifies current namespace identity.
57. The Finality Sink verifies current resource ownership.
58. The Finality Sink verifies current version or generation state.
59. The Finality Sink verifies the actual operation parameters.
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.69. Source page 1826 of the original technical specification
60. The Finality Sink verifies the operation-specific resource
equivalence predicate.
61. The Finality Sink verifies a separate non-bearer finality
enablement.
62. The Finality Sink verifies protected sink-local consumption
state.
63. A copied finality reference cannot independently authorize a
different resource.
64. A cross-sink finality reference is rejected when its designated
resource or sink does not correspond.
65. A transactional resource controller may atomically commit
protected consumption and local resource mutation.
66. An external resource operation maintains an appropriate durable
attempt state.
67. An uncertain remote outcome is not automatically treated as
failed effectuation.
68. A completed actual-effect receipt identifies the resource
actually affected.
69. A CW-2 successor may require a qualified receipt concerning the
specified predecessor resource.
70. A CW-3 protected deviation latch may be activated following
unauthorized resource rebinding.
71. A qualified harmless alias change may be resolved under existing
authorization.
72. A materially new resource target may require new scoped source
authorization.
73. A human scope approval does not override an unrelated mandatory
security condition.
74. Protected resource identity continuity may be preserved across
authorized agent handoff.
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
75. Protected resource generations may fence stale devices or
controllers.
76. A resource migration may preserve bounded authority without
granting unrelated effect scope.
77. A gateway lacking sufficient actual-resource visibility must
employ a qualified destination-side controller where required.
78. Resource resolution and actual finality may be performed in
separate protected domains.
79. The implementation may employ a hardware-backed resource
identity register.
80. The system may use existing filesystem, database, network,
storage, and hardware components while preserving the selected
protected authority-to-resource relationship.
21.74 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The features disclosed in Embodiment 21 may be implemented separately
where technically sufficient or in any compatible subcombination.
9.5.3.70. Source page 1827 of the original technical specification
A filesystem implementation may use protected object handles,
namespace evidence, and sink-local finality.
A database implementation may use tenant-qualified object identity
and transactional resource versions.
An object-storage implementation may use object identifiers, version
references, and protected mutation gateways.
A network implementation may use destination, redirect, and
authenticated resource-service evidence.
A distributed service implementation may use qualified resource
migration and provider-specific identity assertions.
A hardware implementation may use protected device identity and
command enablement.
A multi-agent implementation may use protected binding generations to
prevent concurrent target substitution.
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
An implementation may combine resource-identity continuity with
current source revocation, cumulative resource constraints, conflict
reservations, or other required modules.
The invention does not universally require a filesystem.
It does not universally require network name resolution.
It does not universally require a graph representation.
It does not universally require cryptographic signatures when an
equivalent protected state mechanism supplies the required trust
property.
It does not universally require physical separation of resource
resolver and Finality Sink unless such separation is required by a
selected claimed implementation.
It does not universally require exact object identity where the
original source authority expressly permits an authenticated
equivalent-resource class.
It does not automatically permit all aliases, resource versions, or
migrated resources.
The applicable equivalence relationship remains bounded by original
source authority and current protected operation semantics.
Where a CW-2 receipt-dependent successor is required, a resource-
identity verification result does not replace the mandatory accepted
prior actual-effect receipt.
Where CW-3 applies, a material unauthorized rebinding may be treated
as a scope deviation requiring protected adjudication or new
authorization.
Where a resource operation has already completed, later name changes
do not retroactively alter the historical fact of the actual affected
resource.
The equations, data structures, algorithms, pseudocode, proposed
tests, examples, and illustrations are non-limiting technical aids
intended to assist a person having ordinary skill in the art.
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.5.3.71. Source page 1828 of the original technical specification
The architecture may be implemented using present or future
equivalent computing substrates provided that the required protected
resource identity, actual operation correspondence, and finality
enforcement properties remain satisfied.
21.75 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 21 discloses a protected execution-finality
architecture for consequential operations involving resources whose
names, aliases, locations, namespaces, bindings, ownership, or
representations may change before actual effectuation.
A computational entity may propose an operation against a logical
resource reference.
The original source authority establishes an authorized resource
referent and bounded consequential scope.
A protected resource-identity system may obtain qualified evidence
connecting the original referent to one or more current resource
representations.
The system distinguishes resource names from actual object identity,
content identity, ownership, namespace identity, resource version,
and current authority.
Authenticated alias-lineage evidence and protected resource-binding
generations may establish whether an actual target remains equivalent
to the originally authorized resource.
A material target change may invalidate pending authority.
A harmless verified rename or migration may preserve eligibility
where the original authorization permits that continuity.
A protected validation component verifies the current resource
identity relationship.
A separate authority controller establishes scoped non-bearer
finality enablement bound to the required resource-identity
conditions.
At the consequential boundary, the Finality Sink independently
reconstructs the actual pending operation and target resource.
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The sink verifies current source authority, resource correspondence,
relevant namespace and ownership generations, actual operation
semantics, and sink-local protected consumption state.
A valid path, hostname, alias, object key, application label, content
digest, or earlier signed resolution does not independently authorize
a materially different actual resource.
The disclosed arrangements may use existing filesystem APIs,
conditional resource updates, authenticated service communication,
object-version registries, cryptographic commitments, database
transactions, and protected device controllers.
The principal candidate inventive technical concept of Embodiment 21
is a protected autonomous resource-identity execution-finality system
in which the original source-authorized resource referent and a
qualified current resolution relationship are bound to operation-
specific non-bearer finality authority, and an independently
enforcing Finality Sink reconstructs the actual pending resource
target and refuses consequential execution unless
9.5.3.72. Source page 1829 of the original technical specification
that target satisfies the current protected resource-equivalence,
authority, effect-scope, and sink-local consumption predicates.
21.76 — SHORT IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may use the following existing technical mechanisms as
optional building blocks.
Existing technology Optional technical role Filesystem object handles
and restricted path-resolution APIs
Bind an actual file operation to a qualified filesystem target
Filesystem namespace and mount controls Qualify the resource-
resolution environment Database primary keys and transaction versions
Establish current record identity and prevent selected stale
mutations Object-storage generation or version identifiers Bind an
effect to the intended stored object version
URI parsing and normalization Reduce representational ambiguity under
defined resource semantics DNS and authenticated network
communication
Establish selected name, endpoint, and service properties
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
HTTP redirects and conditional requests Identify changed request
targets and enforce supported resource conditions Digital signatures
and MACs Authenticate protected resource-resolution evidence
Deterministic JSON or CBOR encoding Produce consistent resource-
identity commitments OAuth or equivalent authorization infrastructure
Establish original principal and permitted resource scope
Transactional databases Maintain binding generations, finality state,
and protected consumption
Privileged resource brokers Prevent untrusted agents from exercising
uncontrolled resource authority Protected hardware identity registers
Verify current device or command-target identity
9.6. Embodiment 27: Cross-Domain Agent Handoff and Non-Resurrectable
In-Flight Effects
Technical source: original global pages 2246-2317. The following
source reproduction is a detailed disclosure index preserving
original ordering, technical optionality and independently identified
page boundaries. Architecture and workflow figures are editorial
explanatory views; the original page text controls where a
simplification would lose a qualification.
9.6.1. Architecture Diagram and Protected Components
[Origin agent / CA / inflight effect]
|
[Protected handoff coordinator]
/ \
[Source fence] [Authority lineage+epoch]
| |
[Old act denied] [Destination runtime]
|
[Destination effect FS]
Figure 19: Embodiment 27: Cross-Domain Agent Handoff and Non-
Resurrectable In- Flight Effects — Architecture
9.6.2. Operational Flowchart and Fail-Closed Branches
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[Freeze source and record inflight effects]
|
<Indeterminate remote effect?>--YES-->[Quarantine]
|NO
[Commit authority handoff + source fence]
|
<Destination valid/epoch current?>--NO-->[Stop]
|YES
[Sink reconstruct actual target and consume]
|
[Permit destination effect]
Figure 20: Embodiment 27: Cross-Domain Agent Handoff and Non-
Resurrectable In- Flight Effects — Decision Flow
9.6.3. Page-Indexed Source-Derived Technical Detail
9.6.3.1. Source page 2246 of the original technical specification
The proposed distinguishing technical relationship is the
preservation of operation-specific consequential authority across
changes in the software actually performing an operation, with
lifecycle-dependent finality fencing and actual resource-side
verification rather than reliance upon software provenance,
installation approval, or runtime attestation alone.
END OF EMBODIMENT 26 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 27
PROTECTED DISTRIBUTED AGENT HANDOFF AND WORKLOAD MIGRATION WITH
SOURCE-AUTHORITY CONTINUITY, CROSS-DOMAIN FINALITY TRANSFER, AND NON-
RESURRECTABLE IN-FLIGHT EFFECTS
27.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous Workload
Migration and Cross-Domain Agent Handoff Using Protected Source-
Authority Lineage, Operation-Specific Migration Fencing, Destination
Execution-Domain Qualification, Monotonic Effectuation-Ownership
Generations, Cross-Committed Handoff Evidence, Non-Bearer Finality
Reconstitution, Independent Resource-Sink Reconstruction, and
Qualified Reconciliation of Completed, Pending, and Indeterminate
Consequential Effects
27.0.1 — General Technical Description
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The present Embodiment 27 discloses systems, methods, apparatus,
protected computing components, workload migration controllers,
distributed authorization mechanisms, cross-domain attestation
services, protected delegation structures, execution-ownership
registries, effectuation fences, resource-specific operation ledgers,
and independently enforcing Finality Sinks for governing
consequential operations performed by autonomous computational
entities across different execution environments or administrative
domains.
The autonomous computational entities may include artificial-
intelligence agents, autonomous assistants, multi-agent coordinators,
cloud services, software-development agents, remote workflow workers,
enterprise automation systems, device controllers, robotic
controllers, telecommunications systems, industrial systems, or other
computational workloads capable of proposing or initiating
consequential operations.
An autonomous workload may move between:
Processes; Containers; Virtual machines; Micro-virtual-
machines; Physical hosts; Cloud regions; Edge devices;
Administrative domains; Security principals;
9.6.3.2. Source page 2247 of the original technical specification
Protected execution environments; Remote service providers; Or
different autonomous agents participating in a shared workflow.
Such movement may occur because of:
Load balancing;
Task delegation;
Failover;
Resource exhaustion;
Software updates;
Infrastructure maintenance;
Network connectivity changes;
Security-policy changes;
Worker replacement;
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Recovery from failure;
Or ordinary distributed-workflow orchestration.
A workload may carry computational context including:
Task instructions;
Intermediate reasoning outputs;
Tool results;
Data references;
Conversation context;
Checkpoints;
Partial computations;
Proposed tool calls;
Execution plans;
And identifiers of previously attempted operations.
9.6.3.3. Source page 2248 of the original technical specification
However, the ability to transfer or reconstruct computational context
does not independently establish permission to perform consequential
external operations.
A source agent may have prepared a Candidate Act whose effectuation
has not yet occurred.
A source agent may possess a local permission that does not apply in
the destination domain.
A previously valid credential may remain usable at the source despite
withdrawal of authority.
An operation may have been dispatched before migration but not yet
acknowledged.
A recipient service may have completed a financial, database,
network, storage, or physical effect while the migrating workflow
remains unaware of that completion.
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A checkpoint may record that an operation is pending while a remote
resource has actually committed the operation.
The destination may attempt to execute the same operation again.
Alternatively, both source and destination agents may continue
executing simultaneously after a network partition.
A source agent may remain active after its coordination lease
expires.
A destination agent may possess a new task lease while the old source
retains previously issued capability material.
A distributed authorization service may transfer a token without
verifying whether the actual pending resource operation matches the
authorized effect.
A remote execution environment may be authenticated or attested
without possessing valid source authority for the particular
consequential action.
These conditions create a technical risk that a computational handoff
will be mistaken for a valid transfer of consequential execution
authority.
The present embodiment addresses the risk through an architecture in
which computational task continuity, source-authority continuity,
execution ownership, resource-effect state, and actual finality
authority are maintained as distinct protected properties.
In a principal implementation, an originating source-authority
controller maintains an authenticated record of the task's permitted
consequential effect envelope.
A source execution domain may hold a Candidate Act in a Non-Effective
State.
Before a protected migration, a migration controller identifies
pending Candidate Acts, relevant authority and resource dependencies,
current Finality-Sink consumption state, and any effects that may
already have been dispatched.
9.6.3.4. Source page 2249 of the original technical specification
A protected migration fence prevents the source from obtaining
additional affected finality authority after the relevant authority
transition.
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A destination execution domain is separately qualified using current
identity, permission, and applicable environment evidence.
A protected ownership-generation controller establishes which
qualified execution domain may currently request finality for the
selected Candidate Acts.
The migration controller does not merely copy earlier bearer
credentials or previously issued non-bearer finality artifacts.
Instead, the destination receives an authenticated handoff reference,
protected source-authority lineage, qualified task state, and
permitted operation references.
The destination independently validates the actual pending effect
against the current originating authority and destination-specific
enforcement conditions.
Where required, a new scoped non-bearer finality enablement is
constituted for the destination's authorized operation.
The actual Finality Sink verifies the current effectuation ownership
generation, operation scope, current resource state, protected source
authority, and sink-local consumption state before permitting the
consequential effect.
Previously completed effects remain completed.
Previously consumed finality remains consumed.
In-flight effects remain subject to qualified reconciliation.
Unresolved effects are not automatically converted into unused
authority.
A stale source worker cannot validly release a new covered effect
merely because it retains an old checkpoint, token, lease, or
finality reference.
27.0.2 — Fundamental Technical Principle
Transfer of computational state is not transfer of consequential
execution authority.
Further:
Task ownership is not identical to resource-effect authority.
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A scheduler's leadership election is not necessarily a resource-side
finality decision.
A lease expiry does not prove that the previous holder has stopped
executing.
Authentication of a destination agent does not establish permission
for every resource operation.
9.6.3.5. Source page 2250 of the original technical specification
A transferred access token is not automatically operation-specific
non-bearer finality.
A completed source-side dispatch is not proof of completed remote
effect.
Absence of an acknowledgement is not proof of non-effect.
A recovered checkpoint is not an authoritative resource-state record.
And a new execution owner cannot legitimately resurrect finality
already consumed by an earlier owner.
27.0.3 — Principal Candidate Inventive Combination
A principal implementation comprises:
(a) a protected originating source-authority record;
(b) at least one source execution domain;
(c) at least one candidate destination execution domain;
(d) a Candidate Act identifying a proposed consequential operation;
(e) a protected migration dependency and actual-effect state
registry;
(f) a current effectuation-ownership generation;
(g) a source-domain finality fence;
(h) a qualified destination identity and authority validator;
(i) an authenticated cross-domain handoff commitment;
(j) an independent execution-time validator;
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
(k) a destination-specific scoped non-bearer finality enablement;
(l) a designated actual Finality Sink;
(m) sink-side verification of current ownership generation, source
authorization, actual operation, and protected consumption;
(n) an outcome-reconciliation mechanism preserving previously
completed, dispatched, consumed, and indeterminate effects.
27.0.4 — Candidate Technical Contribution
The present embodiment does not claim as individually new:
9.6.3.6. Source page 2251 of the original technical specification
Workload migration;
Distributed task queues;
Leader election;
Distributed leases;
Consensus algorithms;
Checkpoints;
OAuth token exchange;
Remote attestation;
Authenticated IPC;
Distributed transaction logs;
Idempotency keys;
Conditional updates;
Or distributed resource fencing.
The candidate contribution concerns the operation-specific
integration of protected source-authority continuity, migration
fencing, destination finality reconstitution, actual resource-side
enforcement, and prevention of already dispatched or consumed effects
from being reauthorized merely through task migration.
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.0.5 — Relationship to Earlier Embodiments
Embodiment 7 may provide bounded delegation attenuation.
Embodiment 9 may provide protected resource ownership migration and
fencing.
Embodiment 12 may provide autonomous recovery and compensation.
Embodiment 14 may provide effectuation-path coverage.
Embodiment 15 may provide cross-committed protected evidence.
Embodiment 16 may provide crash-consistent finality journaling.
Embodiment 17 may provide time and lease uncertainty controls.
Embodiment 18 may provide revocation-dependent authority
invalidation.
Embodiment 21 may provide resource-identity continuity.
9.6.3.7. Source page 2252 of the original technical specification
Embodiment 22 may provide cumulative consequence budgets.
Embodiment 23 may provide credential-use finality.
Embodiment 26 may provide tool and runtime generation continuity.
The present Embodiment 27 concentrates on distributed ownership of a
consequential Candidate Act across execution domains, including
actual effectuation under migration, failover, and split-brain
conditions.
27.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v PROTECTED SOURCE AUTHORITY | v GLOBAL TASK
/ ACT REGISTRY | +---------+---------+ | | v v SOURCE DOMAIN A
DESTINATION DOMAIN B | | AGENT / WORKER A AGENT / WORKER B | | v |
CANDIDATE ACT | | | v | SOURCE FINALITY STATE | | | v | MIGRATION
REQUEST | | | v | PROTECTED MIGRATION FENCE | | |
+---------+---------+ | v AUTHENTICATED HANDOFF | v DESTINATION
QUALIFICATION | v CURRENT OWNERSHIP GENERATION | v
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.6.3.8. Source page 2253 of the original technical specification
ACTUAL EFFECT RECONCILIATION | v DESTINATION-SPECIFIC VALIDATION | v
NON-BEARER FINALITY RECONSTITUTION | v ACTUAL FINALITY SINK |
+---------+---------+ | | v v CURRENT OWNER ACTUAL RESOURCE &
AUTHORITY OPERATION | | +---------+---------+ | v SINK-LOCAL
CONSUMPTION | v CONTROLLED REAL EFFECT
This diagram and all subsequent examples are non-limiting technical
aids for a PHOSITA.
27.1 — TECHNICAL FIELD
The invention relates to distributed autonomous-agent execution,
cross-domain workload migration, protected delegation, authenticated
handoff, resource-effect fencing, distributed authority transfer,
task ownership generations, fault-tolerant resource operations,
destination execution qualification, and independent consequential
execution finality.
More particularly, it concerns preventing duplicate, stale,
unauthorized, or resurrected consequential effects during or
following migration of an autonomous computational workload.
27.2 — SPECIFIC TECHNICAL PROBLEMS
27.2.1 — Computation/Authority Confusion
A transferred computational checkpoint may be treated as proof of
valid authority.
27.2.2 — Source/Destination Dual Execution
9.6.3.9. Source page 2254 of the original technical specification
Both old and new workers may execute the same consequential task.
27.2.3 — Stale Source Authority
The original worker may retain a credential or finality reference
after reassignment.
27.2.4 — Lease Expiry Ambiguity
An expired lease does not guarantee termination of an old worker.
27.2.5 — Split-Brain Execution
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Network partitions may cause both domains to believe they are
responsible for the task.
27.2.6 — Pending Candidate Duplication
The same Candidate Act may be reconstructed as two independent
operations.
27.2.7 — Consumed Authority Resurrection
Restored state may describe previously consumed permission as unused.
27.2.8 — Uncertain External Completion
An effect may be completed without a corresponding acknowledgement.
27.2.9 — Cross-Domain Credential Leakage
Migration may expose unrestricted reusable credentials to a new
domain.
27.2.10 — Excessive Delegation
A destination may obtain greater resource authority than the source
principal possessed.
27.2.11 — Missing Authority Lineage
The destination may not be able to establish the originating source
grant.
27.2.12 — Weak Destination Qualification
A destination may be authenticated but insufficiently protected for
the selected consequential operation.
27.2.13 — Changed Resource Identity
The new domain may resolve a logical resource identifier differently.
27.2.14 — Changed Tool Semantics
The destination may use a different tool implementation.
9.6.3.10. Source page 2255 of the original technical specification
27.2.15 — Changed Runtime Privileges
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination may possess different system or resource privileges.
27.2.16 — Changed Administrative Policy
The destination may be subject to different authorization
requirements.
27.2.17 — Missing Migration Fence
The source may continue generating new effect-capable requests.
27.2.18 — Fence Without Sink Enforcement
A coordinator may mark the source as revoked while the actual
resource continues accepting its operations.
27.2.19 — Late Source Request
An old request may reach the resource after destination authority
becomes current.
27.2.20 — Wrong Ownership Generation
A stale operation may carry a valid but obsolete execution-owner
record.
27.2.21 — Replayed Handoff
An earlier migration certificate may be replayed.
27.2.22 — Migration Rollback
Restoration of a prior checkpoint may restore obsolete owner state.
27.2.23 — Partial Migration
Some task components may migrate while other components remain active
at the source.
27.2.24 — Multi-Resource Operations
A task may have completed some resource effects while others remain
pending.
27.2.25 — Asynchronous Resource Providers
Several resource services may have different outcome and consistency
models.
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.2.26 — Lost Handoff Acknowledgement
The migration coordinator may be unable to establish whether the
destination activated.
27.2.27 — Clock Skew
9.6.3.11. Source page 2256 of the original technical specification
Time-based ownership or lease rules may disagree across domains.
27.2.28 — Recovery After Destination Failure
The new execution owner may fail before completing the migrated
operation.
27.2.29 — Task Cancellation During Migration
Source authority may be revoked while transfer is pending.
27.2.30 — Technical Objective
A candidate objective technical problem is:
How to transfer or continue autonomous computation across execution
domains without duplicating, enlarging, or resurrecting operation-
specific consequential authority, including when source and
destination workers overlap, coordination messages are delayed, and
previous resource effects may have occurred without reliable
acknowledgement.
27.3 — ESTABLISHED TECHNIQUES AND LIMITATIONS
27.3.1 — Distributed Leases
Existing lease mechanisms can coordinate which worker is considered
active.
A lease alone does not necessarily prevent an old worker from
accessing a resource after ownership changes.
27.3.2 — Leader Election
Existing leader-election algorithms coordinate leadership under
defined failure and consistency assumptions.
Leadership selection is not automatically authorization of a specific
resource mutation.
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.3.3 — Distributed Fencing Tokens
Existing fencing mechanisms can reject requests bearing obsolete
generations or epochs when the receiving resource enforces the token.
The present embodiment may employ such mechanisms without claiming
them individually.
27.3.4 — Token Exchange
Existing authorization protocols can support delegated cross-service
credentials.
9.6.3.12. Source page 2257 of the original technical specification
The resulting token is not necessarily bound to one actual
consequential Candidate Act or protected sink-local consumption
event.
27.3.5 — Remote Attestation
Existing attestation mechanisms can provide evidence of selected
destination execution properties.
They do not automatically grant current source permission for a
particular resource effect.
27.3.6 — Transaction Logs
Existing durable logs can preserve operation state.
A local log does not necessarily prove the outcome at a remote
independent resource.
27.3.7 — Idempotency
Existing idempotency mechanisms can prevent certain repeated logical
operations at a supporting resource.
They do not necessarily constrain unrelated resource effects or prove
valid source authority.
27.3.8 — Candidate Technical Distinction
The proposed stronger combination connects these established
mechanisms to the original source-authorized Candidate Act, separate
non-bearer finality, and actual resource-sink enforcement.
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.4 — PRINCIPAL SYSTEM COMPONENTS
A representative implementation comprises:
1. A Protected Originating Authority Registry. 2. A Source Agent
Execution Domain. 3. A Candidate Destination Execution Domain. 4. A
Protected Candidate Act Registry. 5. A Migration Dependency
Controller. 6. A Source Finality-Fencing Controller. 7. A
Destination Identity and Attestation Validator. 8. A Protected
Cross-Domain Handoff Service. 9. A Monotonic Effectuation-Ownership
Registry. 10. A Protected In-Flight Operation Journal. 11. A
Qualified Resource-Outcome Reconciliation Service. 12. An
Independent Destination Execution-Time Validator. 13. A Non-Bearer
Finality Reconstitution Controller. 14. A Protected Credential or
Privilege Broker. 15. One or more Actual Finality Sinks.
9.6.3.13. Source page 2258 of the original technical specification
16. A Sink-Local Ownership and Consumption Controller. 17. A
Protected Cumulative Effect-State Registry. 18. A Recovery and
Failover Coordinator.
These components may reside in separate administrative domains or be
combined within a sufficiently protected computing infrastructure.
27.5 — TECHNICAL DEFINITIONS
27.5.1 — Protected Autonomous Handoff
A Protected Autonomous Handoff, or PAH-27, means a controlled
transition of computational work or authority-relevant task state
between qualified execution entities.
27.5.2 — Source Execution Domain
A Source Execution Domain, or SED-27, means the domain currently
holding or previously holding a relevant task execution role.
27.5.3 — Destination Execution Domain
A Destination Execution Domain, or DED-27, means a domain proposed to
receive computational work or acquire bounded authority to initiate
selected consequential operations.
27.5.4 — Protected Source-Authority Continuity
Protected Source-Authority Continuity means preservation of current
originating permission and its limitations across task migration.
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.5.5 — Computational Handoff State
Computational Handoff State means task data, checkpoints,
intermediate outputs, or proposed operations transferred for
continuing computation.
27.5.6 — Consequential Authority State
Consequential Authority State means protected permission and
consumption information governing actual resource effects.
27.5.7 — Effectuation Ownership
Effectuation Ownership means a protected designation identifying the
execution domain permitted to request current finality for specified
Candidate Acts.
27.5.8 — Effectuation Ownership Generation
9.6.3.14. Source page 2259 of the original technical specification
An Effectuation Ownership Generation, or EOG-27, means a monotonic
protected version distinguishing current operation authority
ownership from obsolete ownership state.
27.5.9 — Protected Migration Fence
A Protected Migration Fence, or PMF-27, means a control preventing
the source domain from exercising affected superseded effectuation
authority.
27.5.10 — Destination Qualification
Destination Qualification means verification of the properties
required for a destination to perform a specified operation.
27.5.11 — Qualified Destination Attestation
Qualified Destination Attestation means authenticated evidence of
selected destination runtime or security state accepted under an
applicable appraisal policy.
27.5.12 — Protected Handoff Commitment
A Protected Handoff Commitment, or PHC-27, means authenticated
evidence binding source, destination, Candidate Acts, task scope,
generations, and relevant protected state.
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.5.13 — Handoff Generation
A Handoff Generation means a current protected version of a
particular task or operation transfer.
27.5.14 — Source Finality Invalidation
Source Finality Invalidation means invalidation of affected previous
source-domain finality authority under current protected enforcement.
27.5.15 — Destination Finality Reconstitution
Destination Finality Reconstitution means preparation of new
operation-specific non-bearer authority after destination
qualification and current validation.
27.5.16 — In-Flight Consequential Operation
An In-Flight Consequential Operation means a resource operation that
may have entered a consequential release process without a fully
qualified terminal result.
27.5.17 — Qualified Effect Completion
Qualified Effect Completion means supported evidence that the
specified actual resource consequence completed.
27.5.18 — Qualified Non-Effect
9.6.3.15. Source page 2260 of the original technical specification
Qualified Non-Effect means supported evidence that the specified
resource operation did not produce the relevant effect under the
applicable resource consistency assumptions.
27.5.19 — Indeterminate Effect State
An Indeterminate Effect State means insufficient qualified evidence
to determine whether a particular consequential effect occurred.
27.5.20 — Non-Resurrectable Finality
Non-Resurrectable Finality means previously consumed or invalidated
finality cannot become valid merely through migration, checkpoint
replay, rollback, or ownership reassignment.
27.5.21 — Cross-Domain Ownership Fence
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A Cross-Domain Ownership Fence means an operation-specific resource-
enforced rejection of obsolete effectuation ownership generations.
27.5.22 — Stale Worker
A Stale Worker means an agent or process retaining earlier execution
state or permissions after its relevant ownership authority becomes
obsolete.
27.5.23 — Destination-Bound Enablement
Destination-Bound Enablement means operation-specific non-bearer
finality associated with a qualified destination and current
ownership state.
27.5.24 — Handoff Lineage
Handoff Lineage means a protected succession of source and
destination execution domains for a specified task or Candidate Act.
27.5.25 — Protected Pending-Act Inventory
A Protected Pending-Act Inventory means a record of relevant
Candidate Acts and their authoritative effectuation states at a
migration boundary.
27.5.26 — Effectuation-Sink Continuity
Effectuation-Sink Continuity means preservation of the designated
actual resource-enforcement requirements across migration.
27.5.27 — Cross-Domain Source Grant
A Cross-Domain Source Grant means a bounded original authorization
that a qualified destination may evaluate or derive permitted
operation authority from.
27.5.28 — Migration Scope Attenuation
9.6.3.16. Source page 2261 of the original technical specification
Migration Scope Attenuation means reducing or bounding destination
authority relative to the applicable original or prior delegated
grant.
27.5.29 — Protected Owner Activation
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Protected Owner Activation means establishing a new destination's
current eligibility to obtain operation-specific finality.
27.5.30 — Split-Brain Resource Effect
A Split-Brain Resource Effect means a conflicting or duplicate
consequential operation attempted by multiple execution domains
believing themselves authorized.
27.5.31 — Resource-Side Fencing Epoch
A Resource-Side Fencing Epoch means a current protected resource-
accepted generation used to reject superseded effectuation requests.
27.5.32 — Destination Resource-Identity Correspondence
Destination Resource-Identity Correspondence means verification that
the resource reached from the destination is the authorized real
resource.
27.5.33 — Cross-Domain Effect Receipt
A Cross-Domain Effect Receipt means qualified evidence concerning a
resource operation performed in one domain and relevant to another.
27.5.34 — Protected Recovery Assignment
Protected Recovery Assignment means a current bounded grant assigning
responsibility for unresolved task continuation without independently
recreating prior effect authority.
27.5.35 — Migration-Dependent Finality Predicate
A Migration-Dependent Finality Predicate means a mandatory condition
linking actual effectuation to current handoff, ownership, and
qualified destination state.
27.5.36 — Protected Authority Conservation
Protected Authority Conservation means preventing the same original
consequential allowance from appearing as independent reusable
authority across overlapping execution domains.
27.5.37 — Source Retirement
Source Retirement means making obsolete source-domain execution
authority incapable of authorizing further covered effects.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.5.38 — Protected Handoff Quarantine
9.6.3.17. Source page 2262 of the original technical specification
Protected Handoff Quarantine means withholding affected consequential
authority while current ownership or actual outcome remains
unresolved.
27.5.39 — Bounded Cross-Domain Delegation
Bounded Cross-Domain Delegation means an authenticated delegation
limited by source grant, destination identity, permissible resource
effects, and current generations.
27.5.40 — Actual Operation Reconstruction
Actual Operation Reconstruction means independently obtaining the
material resource operation presented at the actual effectuation
boundary.
27.6 — FIVE SEPARATE STATES OF A MIGRATING WORKLOAD
A principal implementation distinguishes:
First — Computational Context: Information required to continue a
task.
Second — Original Source Authority: The principal's current
permission for consequential effects.
Third — Execution Ownership: Which qualified domain may seek
protected effectuation for a selected Candidate Act.
Fourth — Resource-Effect State: What operations were reserved,
prepared, dispatched, attempted, completed, or left unresolved.
Fifth — Finality Authority: Which specific actual operation may
currently become effective under protected sink verification.
These states may have different owners and different consistency
requirements.
The transfer of computational context may be accomplished before the
destination acquires consequential execution authority.
The original source grant may remain unchanged while execution
ownership changes.
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A previously completed resource effect remains completed even after
all computational context has migrated.
A previously consumed finality enablement remains consumed after
migration.
27.6.1 — Principal Technical Result
Migration cannot independently convert a past computational state
into new present consequential authority.
9.6.3.18. Source page 2263 of the original technical specification
27.7 — PROTECTED ORIGINATING SOURCE-AUTHORITY RECORD
A representative record comprises:
PROTECTED_ORIGINATING_AUTHORITY = { task_identifier,
originating_principal, source_grant_identifier,
permitted_effect_classes, permitted_resources, permitted_recipients,
cumulative_effect_limits, permitted_delegation_scope,
permitted_migration_domains, applicable_destination_requirements,
current_source_authority_generation, current_revocation_generation,
protected_authentication }
The original grant may permit migration without authorizing every
destination to perform every operation.
For example:
A principal may authorize an agent to prepare a financial report in
several regions.
The same grant may restrict actual disclosure to one permitted
storage service or recipient.
Migration to another region does not automatically alter the allowed
disclosure destination.
27.8 — PROTECTED PENDING-ACT INVENTORY
Before a migration, a protected controller may identify relevant
Candidate Acts.
A representative record comprises:
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
PROTECTED_PENDING_ACT_INVENTORY = { task_identifier,
source_domain_identifier, current_ownership_generation,
candidate_act_references, candidate_act_operation_digests,
prepared_finality_references, consumed_finality_references,
dispatched_operation_references,
9.6.3.19. Source page 2264 of the original technical specification
confirmed_effect_references, indeterminate_operation_references,
current_resource_generations, cumulative_budget_state_reference,
journal_generation, protected_authentication }
27.8.1 — Unissued Authority
A proposed but not yet authorized operation may be transferred as an
inert Candidate Act.
27.8.2 — Prepared Authority
A prepared enablement may require invalidation and reconstitution.
27.8.3 — Consumed Authority
The consumption state must remain authoritative.
27.8.4 — Dispatched Effect
The operation may require resource-side outcome reconciliation.
27.8.5 — Completed Effect
An accepted actual-effect receipt may accompany the task without
granting new duplicate execution authority.
27.9 — MIGRATION TRIGGER AND CLASSIFICATION
A migration may be classified as:
PLANNED: A coordinated administrative or scheduling handoff.
FAILOVER: A replacement after source loss or failure.
SECURITY-DRIVEN: A migration following revocation, compromise
indication, or policy change.
LOAD-DRIVEN: A move to balance execution capacity.
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
RESOURCE-DRIVEN: A move required to access another authorized
computing environment.
PARTIAL: Only selected task branches move.
9.6.3.20. Source page 2265 of the original technical specification
CROSS-ADMINISTRATIVE: Source and destination have different protected
authority infrastructures.
DISCONNECTED: The source or destination may lack reliable continuous
network access.
The migration type may affect which current evidence and transition
sequence are required.
A failover following source loss may not obtain a reliable source
shutdown acknowledgement.
The system therefore cannot universally depend upon cooperative
source termination.
27.10 — MONOTONIC EFFECTUATION OWNERSHIP
A principal implementation associates relevant Candidate Acts with a
protected ownership generation.
A simplified relation is:
[ EOG_{n+1}>EOG_n ]
where a new protected owner assignment advances the applicable
authority generation.
The receiving resource or an equivalent protected enforcement
controller rejects requests bearing a superseded ownership
generation.
27.10.1 — Not Merely a Timestamp
An ownership generation may be maintained independently of wall-clock
time.
27.10.2 — Protected Assignment
The generation is assigned through an appropriately authoritative
mechanism.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.10.3 — Operation Binding
The generation is associated with a particular task, Candidate Act,
resource, or defined protected scope.
27.10.4 — Sink Verification
The actual resource sink must enforce the relevant current
generation.
27.10.5 — Technical Limitation
9.6.3.21. Source page 2266 of the original technical specification
A generation value carried only in an agent's log does not prevent a
stale worker from acting through an unprotected alternative resource
interface.
27.11 — OWNERSHIP TRANSITION AND SOURCE FENCING
A principal source-to-destination transition may comprise:
1. Identify the affected task and Candidate Acts. 2. Establish
their current authoritative resource-effect state. 3. Activate a
source finality fence. 4. Prevent new affected source-domain
finality issuance. 5. Advance or prepare the protected ownership
generation. 6. Ensure the actual affected sinks reject obsolete
generations. 7. Qualify the destination. 8. Reconcile unresolved
in-flight effects. 9. Validate the destination's current
consequential scope. 10. Constitute new destination-specific
finality where permitted. 11. Permit destination-controlled
effectuation. 12. Preserve the protected handoff and outcome
evidence.
The sequence may employ atomic or staged coordination according to
the available enforcement primitives.
The invariant is that incompatible old and new authority must not
simultaneously permit duplicate effects at the actual resource
boundary.
27.12 — LEASE VERSUS RESOURCE FENCE
A distributed lease can help determine which worker should act.
However, consider a source worker that:
Obtains a lease;
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Pauses for an extended interval;
Loses the lease;
And later resumes execution.
The coordinator may have assigned a new worker.
The old worker may not yet know its lease expired.
If the old worker directly accesses a resource that does not verify
current ownership, it may still produce an effect.
9.6.3.22. Source page 2267 of the original technical specification
A principal implementation therefore couples lease coordination with
a resource-enforced fencing epoch or equivalent operation-specific
actual sink authorization.
27.12.1 — Lease
Coordinates expected execution ownership.
27.12.2 — Resource Fence
Determines whether the actual resource accepts an operation from the
current owner.
27.12.3 — Finality
Additionally verifies source-authorized operation scope and protected
consumption.
27.12.4 — Candidate Distinction
The claimed combination may require all relevant conditions instead
of relying upon leadership alone.
27.13 — CROSS-DOMAIN HANDOFF COMMITMENT
A representative protected record comprises:
PROTECTED_HANDOFF_COMMITMENT = { handoff_identifier,
originating_task_identifier, original_source_grant_digest,
source_domain_identity, destination_domain_identity,
predecessor_ownership_generation, successor_ownership_generation,
affected_candidate_act_digests, current_resource_binding_commitments,
protected_pending_effect_state_commitment,
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
required_destination_qualification, permitted_delegated_effect_scope,
source_fence_commitment, handoff_generation,
current_revocation_generation, protected_handoff_authentication }
The commitment provides a protected relationship among the source,
destination, task scope, and current authority transition.
It does not automatically constitute a reusable bearer credential.
9.6.3.23. Source page 2268 of the original technical specification
A destination may receive an opaque handoff reference while protected
authorities retain the operative state.
27.14 — CROSS-COMMITTED HANDOFF EVIDENCE
A protected source instance may commit selected migration evidence.
A separate destination validator may independently evaluate the
current source grant and destination execution context.
A non-limiting representation is:
[ C_S=H(\operatorname{Canon}(CA,S,E_s,J)) ]
[ C_D=H(\operatorname{Canon}(CA,D,E_d,C_S)) ]
[ C_H=H(\operatorname{Canon}(C_S,C_D,G,F,R)) ]
where:
(CA) denotes the Candidate Act;
(S) denotes qualified source identity;
(E_s) denotes source-side protected evidence;
(J) denotes relevant pending-operation journal state;
(D) denotes destination identity;
(E_d) denotes independently qualified destination evidence;
(G) denotes the protected ownership generation;
(F) denotes fencing state;
And (R) denotes current source and resource authority references.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
These commitments are illustrative.
Cryptographic commitment does not independently prove the correctness
of unqualified underlying evidence.
9.6.3.24. Source page 2269 of the original technical specification
27.15 — DESTINATION EXECUTION QUALIFICATION
Before receiving consequential authority, the destination may be
required to establish:
Its authenticated execution identity;
The current source-grant scope it is permitted to exercise;
The relevant runtime or tool identity;
Its actual resource access;
Current applicable security controls;
Current revocation state;
Required credential handling;
Effectuation-path coverage;
And the designated receiving Finality Sink.
27.15.1 — Authentication
Establishes the destination's qualified identity.
27.15.2 — Attestation
May establish selected execution-state properties.
27.15.3 — Authorization
Determines whether the destination may perform the specified effect.
27.15.4 — Current Finality
Determines whether the actual pending resource operation is eligible
for release.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A valid attestation result cannot substitute for missing source
authorization.
27.16 — CROSS-DOMAIN AUTHORITY ATTENUATION
The destination's consequential scope may be equal to or narrower
than the current originating grant, according to authorized
delegation conditions.
For example:
9.6.3.25. Source page 2270 of the original technical specification
The originating principal authorizes a task to use a bounded set of
documents.
The source domain delegates a subset to the destination.
The destination may process the subset.
It may not use the handoff to access other documents outside its
delegated resource scope.
27.16.1 — Independent Source Grant
The destination may verify original permission through a qualified
source service.
27.16.2 — Delegated Scope
A protected delegation record identifies bounded downstream
authority.
27.16.3 — No Unauthorized Inflation
The destination cannot expand the permitted resource effect merely by
receiving more task context.
27.16.4 — New Scope
A genuine expansion may require new qualified source authorization.
27.17 — DESTINATION-BOUND FINALITY RECONSTITUTION
A destination may not reuse the source's previously prepared non-
bearer enablement as though it were an unrestricted transferable
token.
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected controller may instead establish a new enablement
associated with:
The current Candidate Act;
The current original source grant;
The qualified destination identity;
The current ownership generation;
The designated actual resource;
The accepted operation effect descriptor;
The required protected evidence;
And the current sink-local consumption state.
9.6.3.26. Source page 2271 of the original technical specification
A representative structure comprises:
DESTINATION_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
original_source_authority_reference, cross_domain_handoff_commitment,
source_execution_domain, qualified_destination_domain,
current_effectuation_ownership_generation, operation_effect_envelope,
current_resource_identity, current_tool_runtime_generation,
required_independent_validation_commitment,
current_revocation_generation, designated_finality_sink,
permitted_use_count, sink_local_consumption_reference,
protected_finality_authentication }
An inert reference may be provided to the destination agent.
The actual sink verifies the record and current protected state.
27.18 — FINALITY CONSERVATION ACROSS MIGRATION
A principal invariant is that migration cannot increase the number of
permitted protected effects.
For a logical operation (O), a selected resource may enforce:
[ \operatorname{ValidEffectCount}(O)\leq A(O) ]
where (A(O)) is the current number of source-authorized effect
opportunities for that operation under the selected policy.
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
For a single-use operation:
[ A(O)=1 ]
The enforcement may use a shared authoritative operation ledger or a
resource-local consumption record.
27.18.1 — Multiple Workers
9.6.3.27. Source page 2272 of the original technical specification
Several execution domains may propose the same operation.
27.18.2 — Shared Logical Identity
They must not automatically become distinct authorized real effects.
27.18.3 — Existing Consumed Effect
A completed or consumed operation remains represented in
authoritative state.
27.18.4 — New Distinct Effect
A genuinely new resource effect requires its own valid authority.
27.19 — PENDING VERSUS DISPATCHED OPERATIONS
A principal implementation distinguishes at least four stages.
Stage A — Proposed but Not Authorized: The Candidate Act is inert and
may be migrated for fresh validation.
Stage B — Finality Prepared but Not Consumed: The old enablement may
be invalidated, and a new one prepared where permitted.
Stage C — Finality Consumed or Effect Dispatched: The operation
requires protection against duplicate consequence and may require
outcome reconciliation.
Stage D — Qualified Actual Effect Completed: The effect is historical
fact and cannot be reauthorized as a new identical effect merely
through migration.
The destination's next action depends upon the authoritative stage.
27.20 — INDETERMINATE EFFECT QUARANTINE
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A source operation may remain unresolved when the task migrates.
The protected controller may establish:
MIGRATION_EFFECT_QUARANTINE = { candidate_act_identifier,
logical_operation_identifier, source_execution_domain,
source_ownership_generation, finality_consumption_state,
known_dispatch_state, last_qualified_resource_evidence,
9.6.3.28. Source page 2273 of the original technical specification
current_reconciliation_policy, current_resource_generation,
quarantine_generation, protected_authentication }
A quarantined effect may prevent the destination from issuing an
incompatible new operation.
The destination may continue unrelated computational tasks.
It may also perform unrelated authorized consequences whose safety
does not depend upon resolution of the quarantined operation.
27.20.1 — Qualified Completion
The controller records the completed effect.
27.20.2 — Qualified Non-Effect
The controller applies the permitted release or retry semantics.
27.20.3 — Persistent Uncertainty
Authority remains conservatively controlled under the applicable
policy.
27.21 — RESOURCE-SIDE EXACT-OPERATION VERIFICATION
The actual Finality Sink may obtain:
The current logical operation identifier;
The actual resource target;
The operation method;
Material operation parameters;
The current effectuation owner;
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The current ownership generation;
Original source authority;
Applicable delegated permission;
And protected consumption state.
9.6.3.29. Source page 2274 of the original technical specification
A source agent presenting an old but otherwise well-formed request is
denied when its ownership generation is no longer accepted.
A destination agent presenting the current generation is still denied
when the actual resource effect is outside original permission.
Thus, current ownership and actual operation authorization are
distinct mandatory predicates.
27.22 — CROSS-RESOURCE MIGRATION
A migrated workflow may affect several independent resource systems.
For example:
A database service;
A payment service;
An object store;
And a notification service.
Each resource may have different operation IDs and outcome
guarantees.
A protected migration controller maintains a per-resource operation-
state inventory.
27.22.1 — Completed Resource
A completed effect remains recorded.
27.22.2 — Pending Resource
The operation may require fresh destination finality.
27.22.3 — Indeterminate Resource
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The corresponding operation remains subject to reconciliation.
27.22.4 — No Global Atomicity Presumption
A protected task handoff does not imply that independent resources
participate in one distributed atomic transaction.
27.23 — PARTIAL WORKFLOW MIGRATION
An autonomous workflow may comprise several branches.
9.6.3.30. Source page 2275 of the original technical specification
Only one branch may migrate.
The protected controller may maintain separate ownership state for:
Individual Candidate Acts;
Workstream branches;
Specific resource grants;
Or another defined protected unit of delegation.
The original task authority remains bounded.
27.23.1 — Unmigrated Branch
May continue under current valid source ownership.
27.23.2 — Migrated Branch
Receives new applicable ownership and finality state.
27.23.3 — Shared Budget
Shared cumulative authority must not be counted twice.
27.23.4 — Shared Causal Dependency
A downstream operation may require qualified completion of an earlier
branch effect.
27.24 — MIGRATION DURING SOURCE REVOCATION
The originating principal may revoke a task while migration is
pending.
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The protected controller checks current source authority before
allowing destination finality.
An old handoff commitment does not independently override a newer
valid revocation state.
The source and destination may both be fenced from additional
affected effects.
Already completed effects remain recorded.
Unresolved in-flight operations require qualified reconciliation.
27.25 — MIGRATION OF CREDENTIAL-DEPENDENT TASKS
9.6.3.31. Source page 2276 of the original technical specification
A source agent may have access to a protected credential broker.
The destination may operate in a different administrative domain.
The migration protocol need not transfer the reusable secret.
Instead, a qualified destination may obtain a scoped reference to an
authorized credential-use service.
The credential-use sink independently verifies:
Current source grant;
Destination identity;
Actual resource request;
Current credential state;
Current ownership generation;
And operation-specific finality.
The transfer of a computational task does not necessarily require
transfer of raw credential custody.
27.26 — MIGRATION OF HARDWARE-CONTROL TASKS
A source controller may prepare a command for a protected device.
Before actuation, the control task migrates to another controller.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination obtains the computational state.
The actual device-side sink verifies current control ownership and
operation-specific command authority.
An old source controller retaining network connectivity cannot
validly issue another command under a superseded generation.
If a previous command may already have actuated the device, the
destination requires qualified physical or controller-side state
before deciding on a further command.
27.27 — MIGRATION OF FINANCIAL WORKFLOWS
A payment task may move between workers after a timeout.
9.6.3.32. Source page 2277 of the original technical specification
The original operation may already have reached the payment
processor.
The protected system preserves:
The logical payment identifier;
The source-authorized account and recipient;
The permitted amount;
The protected finality-consumption record;
And the qualified payment outcome state.
The destination does not automatically initiate a second transfer.
Where the payment processor supports an appropriate stable
transaction identifier and qualified status lookup, the controller
may reconcile the existing operation.
Otherwise, uncertainty remains a constraint upon further
effectuation.
27.28 — MIGRATION OF INFORMATION-DISCLOSURE WORKFLOWS
A source agent may begin transmitting protected information.
The task then migrates.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination must not assume that the earlier transmission failed
merely because the source lost connectivity.
The protected disclosure controller may preserve:
The actual recipient;
The information classes;
The confirmed transmitted portions;
The indeterminate portions;
And the remaining permitted disclosure allowance.
The destination may continue only under qualified current source
authority and cumulative disclosure constraints.
Previously transmitted information cannot be made undisclosed merely
by rolling back task state.
9.6.3.33. Source page 2278 of the original technical specification
27.29 — TEMPORAL LEASES AND CLOCK UNCERTAINTY
A migration controller may use leases or time-bounded delegations.
Different domains may have different clocks.
A selected implementation may avoid relying upon local wall-clock
agreement as the sole proof of current effectuation ownership.
The actual sink may check an authoritative ownership generation.
Where time-dependent predicates are required, the implementation may
apply protected uncertainty bounds.
27.29.1 — Lease Coordination
Useful for scheduling and availability.
27.29.2 — Ownership Epoch
Useful for rejecting old execution-domain authority.
27.29.3 — Protected Finality
Required for the actual consequential operation where selected.
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The three functions remain distinct.
27.30 — DISCONNECTED DESTINATION
A destination may temporarily lose access to the central authority
service.
A selected implementation may:
Withhold consequential operations requiring current online authority;
Allow bounded offline operations under expressly preallocated current
authority;
Use a qualified local protected resource controller;
Or defer unresolved operations until connectivity returns.
27.30.1 — No Unrestricted Offline Continuation
A cached handoff record does not automatically establish unlimited
future authority.
9.6.3.34. Source page 2279 of the original technical specification
27.30.2 — Bounded Allocation
Any offline authority must be limited according to the selected
originating grant.
27.30.3 — Local Effectuation Control
A protected local Finality Sink may enforce permitted operations.
27.30.4 — Reconciliation
Offline effects must be reconciled under the applicable protected
accounting model.
27.31 — SPLIT-BRAIN EXECUTION
A network partition may leave both source and destination
operational.
Each may believe it currently owns the task.
The protected resource does not rely upon those beliefs.
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
It verifies the applicable authoritative current ownership generation
or equivalent protected operation state.
27.31.1 — Stale Source
Its superseded generation is rejected.
27.31.2 — Current Destination
Its current generation establishes only ownership eligibility, not
full resource-effect authority.
27.31.3 — Resource Authorization
The sink separately verifies the actual permitted consequence.
27.31.4 — Consistency Limitation
A resource that cannot enforce current ownership or equivalent
operation-specific finality cannot provide the same guarantee merely
through an external coordinator.
27.32 — DESTINATION FAILURE AFTER ACTIVATION
A destination may become the current execution owner and then fail.
The original source does not automatically regain authority.
9.6.3.35. Source page 2280 of the original technical specification
A recovery controller may establish a new protected owner generation.
The recovery assignment may select:
The prior source;
A third execution domain;
Or a recovered instance of the destination.
Any new execution owner remains subject to actual-effect
reconciliation and current source authorization.
27.32.1 — No Implicit Reversion
Ownership does not silently revert to an older generation.
27.32.2 — New Recovery Generation
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A protected successor generation may be constituted.
27.32.3 — Old Outcome
Previously dispatched effects remain independently accounted for.
27.33 — HANDOFF REPLAY AND MIGRATION ROLLBACK
A malicious or failed component may replay an old handoff
certificate.
The protected registry verifies:
Current handoff generation;
Actual destination identity;
Current source authority;
Current ownership epoch;
And current protected operation state.
An old handoff record cannot independently restore authority.
A restored checkpoint may provide computational context but cannot
overwrite more recent protected sink-local consumption or revocation
state.
9.6.3.36. Source page 2281 of the original technical specification
27.34 — AUTHORITY CONTINUITY UNDER TOOL CHANGES
The destination may use a different tool implementation.
A current destination validation instance may verify:
The actual tool identity;
Its relevant effect semantics;
The permitted resource;
Current privilege conditions;
And the original Candidate Act's authorized effect envelope.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A destination tool's broader technical capabilities do not enlarge
the original source grant.
Where the tool changes the actual effect, new validation or
authorization may be required.
This variation may incorporate Embodiment 26.
27.35 — PROTECTED CROSS-DOMAIN OUTCOME RECEIPTS
A completed effect may be supported by a qualified resource receipt.
The receipt may identify:
The logical operation;
The actual resource;
The source execution domain;
The ownership generation;
The real effect;
The resource transaction identifier;
And the qualified observation status.
27.35.1 — Historical Evidence
The receipt may remain useful after migration.
27.35.2 — No Duplicate Permission
9.6.3.37. Source page 2282 of the original technical specification
A receipt showing completion does not authorize executing the same
operation again.
27.35.3 — CW-2 Integration
Where a successor requires an IEV-accepted actual-effect receipt, the
requisite validation remains applicable after handoff.
27.35.4 — Receiving-Domain Evidence
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination may rely upon authenticated qualified evidence
without assuming that an ordinary source-agent success message proves
completion.
27.36 — REFERENCE ALGORITHM: PREPARE HANDOFF
FUNCTION PREPARE_PROTECTED_HANDOFF( task, source_domain,
destination_domain, protected_migration_controller ): REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY(task) REQUIRE
VERIFY_SOURCE_EXECUTION_IDENTITY( source_domain ) REQUIRE
VERIFY_DESTINATION_MIGRATION_ELIGIBILITY( destination_domain )
inventory = protected_migration_controller
.LOAD_AUTHORITATIVE_PENDING_ACT_INVENTORY(task) REQUIRE
VERIFY_INVENTORY_AUTHENTICITY(inventory) REQUIRE
CLASSIFY_EACH_RELEVANT_OPERATION_STATE( inventory ) affected =
IDENTIFY_AUTHORITY_DEPENDENCIES(inventory) fence =
protected_migration_controller .COMMIT_SOURCE_EFFECTUATION_FENCE({
task: task, source: source_domain, affected: affected,
expected_owner_generation:
9.6.3.38. Source page 2283 of the original technical specification
CURRENT_OWNERSHIP_GENERATION(task) }) IF fence != COMMITTED: RETURN
DENY_HANDOFF RETURN PROTECTED_MIGRATION_PREPARATION({ inventory:
inventory, source_fence: fence, destination: destination_domain })
The actual protected resource sinks must enforce the fence where
required by the selected guarantee.
27.37 — REFERENCE ALGORITHM: QUALIFY DESTINATION
FUNCTION QUALIFY_DESTINATION_FOR_EFFECT( destination, candidate_act,
protected_destination_validator ): REQUIRE
VERIFY_DESTINATION_IDENTITY(destination) REQUIRE
VERIFY_CURRENT_ORIGINAL_SOURCE_GRANT( candidate_act ) evidence =
protected_destination_validator .OBTAIN_REQUIRED_EXECUTION_EVIDENCE(
destination ) REQUIRE VERIFY_EVIDENCE_AUTHENTICITY(evidence) REQUIRE
VERIFY_REQUIRED_DESTINATION_PROPERTIES( evidence, candidate_act )
REQUIRE VERIFY_CURRENT_TOOL_AND_RUNTIME_SCOPE() REQUIRE
VERIFY_DESTINATION_RESOURCE_ACCESS_SCOPE() REQUIRE
VERIFY_CURRENT_EFFECTUATION_PATH_COVERAGE() REQUIRE
VERIFY_DESTINATION_DELEGATION_ATTENUATION()
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.6.3.39. Source page 2284 of the original technical specification
RETURN PROTECTED_DESTINATION_QUALIFICATION({ destination:
destination, candidate: HASH(candidate_act), evidence:
HASH(evidence), current_source_generation:
CURRENT_SOURCE_GENERATION() })
Authentication and attestation are inputs to, rather than substitutes
for, operation-specific source authorization.
27.38 — REFERENCE ALGORITHM: COMMIT OWNERSHIP TRANSFER
FUNCTION COMMIT_EFFECTUATION_OWNERSHIP_TRANSFER( task, source,
destination, prepared_handoff, protected_owner_registry ): REQUIRE
VERIFY_PREPARED_HANDOFF( prepared_handoff ) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY(task) REQUIRE
VERIFY_SOURCE_FENCE_EFFECTIVE( prepared_handoff ) REQUIRE
VERIFY_DESTINATION_QUALIFIED(destination) REQUIRE
VERIFY_REQUIRED_SINK_FENCING_SUPPORT() previous =
CURRENT_OWNERSHIP_GENERATION(task) next = protected_owner_registry
.ATOMIC_ADVANCE_OWNERSHIP({ task: task, expected_previous_generation:
previous, previous_owner: source, next_owner: destination,
affected_candidate_set: prepared_handoff.affected_candidates }) IF
next != COMMITTED: RETURN DENY_TRANSFER
9.6.3.40. Source page 2285 of the original technical specification
REQUIRE VERIFY_RESOURCE_SINKS_APPLY_CURRENT_FENCE( next ) RETURN
PROTECTED_HANDOFF_COMMITMENT(next)
Where independent sinks cannot be updated atomically, the transition
must maintain a safe staged or fail-closed state until their required
fencing conditions are established.
27.39 — REFERENCE ALGORITHM: RECONCILE IN-FLIGHT EFFECT
FUNCTION RECONCILE_MIGRATED_OPERATION( logical_operation,
protected_effect_journal, qualified_resource_observer ): state =
protected_effect_journal .LOAD_AUTHORITATIVE_OPERATION_STATE(
logical_operation ) REQUIRE VERIFY_STATE_AUTHENTICITY(state) IF
QUALIFIED_EFFECT_COMPLETED(state): RETURN
PRESERVE_COMPLETED_EFFECT(state) IF
QUALIFIED_NON_EFFECT_ESTABLISHED(state): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION() IF
EFFECT_MAY_HAVE_BEEN_DISPATCHED(state): observed =
qualified_resource_observer .QUERY_ACTUAL_RESOURCE_OPERATION(
logical_operation ) IF VERIFY_QUALIFIED_COMPLETION(observed): RETURN
COMMIT_COMPLETED_EFFECT(observed) IF
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
VERIFY_QUALIFIED_NON_EFFECT(observed): RETURN
COMMIT_NON_EFFECT(observed) RETURN PRESERVE_INDETERMINATE_STATE()
RETURN ELIGIBLE_FOR_CURRENT_AUTHORITY_REVALIDATION
A network timeout or worker loss alone does not establish qualified
non-effect.
9.6.3.41. Source page 2286 of the original technical specification
27.40 — REFERENCE ALGORITHM: DESTINATION FINALITY
FUNCTION CONSTITUTE_DESTINATION_FINALITY( candidate_act, destination,
handoff_reference, protected_finality_controller ): REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY( candidate_act ) REQUIRE
VERIFY_CURRENT_HANDOFF_GENERATION( handoff_reference ) REQUIRE
VERIFY_DESTINATION_IS_CURRENT_OWNER( destination, candidate_act )
REQUIRE VERIFY_DESTINATION_QUALIFICATION() REQUIRE
VERIFY_SOURCE_AUTHORITY_ATTENUATION() REQUIRE
VERIFY_PRIOR_OPERATION_STATE_ELIGIBLE() REQUIRE
VERIFY_NO_UNRESOLVED_INCOMPATIBLE_EFFECT() REQUIRE
VERIFY_CURRENT_RESOURCE_IDENTITY() validation =
INDEPENDENTLY_VALIDATE_CURRENT_OPERATION( candidate_act, destination
) REQUIRE validation == ACCEPTED RETURN protected_finality_controller
.PREPARE_SCOPED_NON_BEARER_FINALITY({ candidate: HASH(candidate_act),
destination: destination, ownership_generation:
CURRENT_OWNERSHIP_GENERATION(), validation: HASH(validation),
designated_sink: RESOLVE_ACTUAL_RESOURCE_SINK(),
current_consumption_reference:
9.6.3.42. Source page 2287 of the original technical specification
LOAD_AUTHORITATIVE_CONSUMPTION_STATE() })
The destination does not acquire unlimited reusable authority through
this operation.
27.41 — REFERENCE ALGORITHM: RESOURCE-SINK FENCING
FUNCTION EFFECTUATE_MIGRATED_ACT( candidate_act,
destination_finality, protected_finality_sink ): actual =
protected_finality_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_OPERATION_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_SOURCE_SCOPE( actual ) REQUIRE
VERIFY_CURRENT_EFFECTUATION_OWNER( actual ) REQUIRE
VERIFY_CURRENT_RESOURCE_FENCING_EPOCH( actual ) REQUIRE
VERIFY_DESTINATION_QUALIFICATION() REQUIRE
VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() REQUIRE
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
VERIFY_DESTINATION_BOUND_NON_BEARER_FINALITY( destination_finality,
actual ) REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE( actual )
committed = protected_finality_sink
.COMMIT_PROTECTED_OPERATION_CONSUMPTION({ logical_operation:
actual.logical_id, finality: destination_finality,
9.6.3.43. Source page 2288 of the original technical specification
current_owner_generation: CURRENT_OWNERSHIP_GENERATION() }) IF
committed != COMMITTED: RETURN DENY RETURN protected_finality_sink
.RELEASE_ACTUAL_CONSEQUENCE(actual)
For external resources without shared atomic state, the
implementation must use suitable controlled dispatch, receiver-side
deduplication where supported, and qualified outcome reconciliation.
27.42 — REFERENCE ALGORITHM: REJECT STALE SOURCE
FUNCTION VERIFY_STALE_SOURCE_REJECTION( incoming_operation,
protected_resource_sink ): presented_generation =
incoming_operation.ownership_generation authoritative_generation =
protected_resource_sink .LOAD_CURRENT_ACCEPTED_GENERATION(
incoming_operation.logical_operation_id ) IF presented_generation !=
authoritative_generation: RETURN DENY_STALE_OWNER REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE() REQUIRE
VERIFY_PROTECTED_FINALITY_AND_CONSUMPTION() RETURN
ELIGIBLE_FOR_CONTROLLED_EFFECTUATION
The actual receiving resource must enforce the generation relation or
an equivalent authoritative predicate.
27.43 — REFERENCE ALGORITHM: FAILOVER RECOVERY
9.6.3.44. Source page 2289 of the original technical specification
FUNCTION RECOVER_AFTER_DESTINATION_FAILURE( task, failed_destination,
replacement_destination, protected_recovery_controller ): REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY(task) REQUIRE
VERIFY_FAILURE_OR_REASSIGNMENT_AUTHORITY() inventory =
LOAD_CURRENT_AUTHORITATIVE_EFFECT_INVENTORY(task) REQUIRE
CLASSIFY_COMPLETED_AND_UNRESOLVED_EFFECTS( inventory ) REQUIRE
FENCE_FAILED_DESTINATION_FOR_NEW_EFFECTS() REQUIRE
VERIFY_RESOURCE_SIDE_FENCING_SUPPORT() REQUIRE
QUALIFY_REPLACEMENT_DESTINATION( replacement_destination )
next_generation = ATOMIC_ADVANCE_EFFECTUATION_OWNER( task,
replacement_destination ) REQUIRE
VERIFY_NEW_GENERATION_AT_REQUIRED_SINKS() RETURN
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
PREPARE_REPLACEMENT_HANDOFF({ task: task, generation:
next_generation, unresolved_effects: inventory.unresolved })
Recovery does not automatically repeat previously dispatched
operations.
27.44 — WORKED EXAMPLE A: MIGRATING DATABASE AGENT
An autonomous agent operates on Server A.
The agent is permitted to update one designated database record.
Before the actual update, the task moves to Server B.
9.6.3.45. Source page 2290 of the original technical specification
The protected controller advances the relevant ownership generation.
Server A retains an old Candidate Act and attempts the database
mutation.
The database sink rejects the superseded generation.
Server B obtains current authority and independently verifies the
actual record and mutation.
Expected demonstrable result: An old execution instance cannot
duplicate or override a migrated operation through a stale authority
reference.
27.45 — WORKED EXAMPLE B: PAYMENT ACKNOWLEDGEMENT LOST
Server A initiates a qualified payment.
The payment processor completes the transfer.
Server A loses connectivity before receiving confirmation.
The task migrates to Server B.
Server B receives the payment instructions but not a success
acknowledgement.
The protected journal records the prior finality consumption and
dispatch.
Server B obtains qualified resource outcome evidence before deciding
whether any new payment is required.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected demonstrable result: Migration does not automatically
authorize a second payment when the first may already have occurred.
27.46 — WORKED EXAMPLE C: SPLIT-BRAIN WORKERS
Two execution domains both believe they own an autonomous task.
The original source authority permits one consequential resource
operation.
Each domain attempts the operation.
The actual resource sink accepts only the valid current ownership
generation and protected unused finality state.
An obsolete owner is refused even if it retains an earlier valid
coordination lease.
9.6.3.46. Source page 2291 of the original technical specification
Expected demonstrable result: Split-brain scheduling does not
necessarily produce split-brain resource effects when current
ownership and consumption are enforced at the actual resource.
27.47 — WORKED EXAMPLE D: LEASE EXPIRY WITHOUT SOURCE TERMINATION
Agent A obtains a time-limited coordination lease.
Agent A pauses.
The lease expires.
Agent B obtains a new lease.
Agent A resumes and attempts a resource mutation.
The sink verifies the current resource-side ownership generation
rather than assuming the earlier lease remains sufficient.
Agent A's request is rejected.
Expected demonstrable result: Lease expiry combined with sink-side
fencing prevents a stale worker from exercising obsolete
consequential authority.
27.48 — WORKED EXAMPLE E: CROSS-REGION CLOUD AGENT
An agent begins a task in Cloud Region A.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The workload migrates to Region B.
Region B has different service identities and resource endpoints.
The protected destination validator qualifies the new environment and
actual resource mapping.
The original source-authorized effect envelope remains unchanged.
A new destination-bound finality enablement is established for the
permitted operation.
Expected demonstrable result: Moving computation between cloud
regions does not automatically broaden the task's external resource
permissions.
27.49 — WORKED EXAMPLE F: CREDENTIAL WITHOUT SECRET TRANSFER
9.6.3.47. Source page 2292 of the original technical specification
An agent uses a credential broker in Domain A.
The task migrates to Domain B.
The reusable credential remains in protected custody.
Domain B receives a bounded authorization reference and current
handoff evidence.
The credential broker independently verifies the destination and
actual resource operation before exercising the credential.
Expected demonstrable result: Task migration can preserve legitimate
credential-dependent work without exposing reusable complete
authority to the destination agent.
27.50 — WORKED EXAMPLE G: INDUSTRIAL CONTROLLER FAILOVER
Controller A prepares a device actuation.
Controller A becomes unreachable.
Controller B takes over.
The device-side controller maintains the current accepted
effectuation-ownership generation.
Controller A later resumes and attempts to issue the old command.
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The device sink refuses obsolete authority.
Controller B verifies actual device state before issuing a permitted
further command.
Expected demonstrable result: Control failover does not automatically
permit duplicate physical actuation.
27.51 — WORKED EXAMPLE H: PARTIAL DATA EXPORT
An agent begins an authorized data export.
A subset of data is confirmed transmitted.
Another segment's outcome remains uncertain.
The task migrates.
The protected disclosure ledger preserves the confirmed and
indeterminate portions.
The new agent cannot assume the entire original disclosure allowance
remains unused.
9.6.3.48. Source page 2293 of the original technical specification
Expected demonstrable result: Partial migration preserves cumulative
actual disclosure state.
27.52 — WORKED EXAMPLE I: DESTINATION TOOL CHANGE
An agent migrates from a worker using Tool Version 3 to a worker
using Tool Version 4.
The new tool interprets one operation parameter differently.
The destination's tool-effect qualification identifies the
difference.
The original Candidate Act is not blindly executed.
The operation is revalidated against current actual resource
semantics.
Expected demonstrable result: Migration does not conceal an
unauthorized consequential change introduced by the destination tool
implementation.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.53 — WORKED EXAMPLE J: TASK CHECKPOINT ROLLBACK
A source agent takes a checkpoint before completing a resource
operation.
The operation later completes.
The task is migrated using the older checkpoint.
The destination observes that the checkpoint does not contain the
completion.
However, the protected resource journal records the actual effect.
The destination cannot restore the operation's previously consumed
authority.
Expected demonstrable result: An older computational checkpoint does
not override newer authoritative real-effect state.
27.54 — WORKED EXAMPLE K: PARTIAL BRANCH MIGRATION
An autonomous workflow comprises three agents.
Only Agent B moves to another domain.
The original task has a shared resource budget.
The protected allocation controller transfers only B's qualified
unused bounded authority.
9.6.3.49. Source page 2294 of the original technical specification
Agents A and C retain their separate current allocations.
All actual resource sinks enforce current corresponding finality.
Expected demonstrable result: Partial workflow migration does not
duplicate cumulative authority shared with branches that remain at
the source.
27.55 — WORKED EXAMPLE L: ORIGINATING AUTHORITY REVOKED DURING
HANDOFF
The originating principal revokes a task while its migration is being
prepared.
The migration controller rechecks current source authority.
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The destination is qualified as a computing environment but lacks
valid permission for further protected effects.
No new destination finality is established.
Previously completed effects remain historical.
Expected demonstrable result: A previously prepared handoff cannot
override a newer valid source-authority revocation.
27.56 — WORKED EXAMPLE M: FAILED DESTINATION ACTIVATION
The migration coordinator sends task context and handoff evidence to
the destination.
The destination crashes before protected ownership activation
completes.
The controller cannot assume that the destination became an effective
owner.
It checks current authoritative ownership and resource-fence state.
A replacement destination may receive a newly established generation.
Expected demonstrable result: A lost handoff acknowledgement does not
create ambiguous independent authority for two destinations.
27.57 — WORKED EXAMPLE N: REPLAYED HANDOFF CERTIFICATE
An attacker replays an old authenticated handoff record.
The record correctly identifies a prior source and destination.
9.6.3.50. Source page 2295 of the original technical specification
However, its ownership generation is obsolete.
The protected owner registry and Finality Sink reject the old
generation.
Expected demonstrable result: Authenticity of historical handoff
evidence does not independently establish current effectuation
authority.
27.58 — WORKED EXAMPLE O: REMOTE TOOL WITH HIDDEN SIDE EFFECT
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A migrating agent invokes a remote tool through a new execution
domain.
The local request appears identical.
However, the remote service's actual effect semantics have changed.
The destination-side resource controller verifies the real operation
where supported.
The source grant does not automatically authorize the new side
effect.
Expected demonstrable result: Cross-domain continuity of a tool API
does not guarantee continuity of permissible consequential effects.
27.59 — WORKED EXAMPLE P: OFFLINE EDGE AGENT
An edge agent receives a bounded allocation for selected commands.
It becomes disconnected from the central service.
The task is reassigned elsewhere.
The edge resource sink maintains a local protected allowance and
fencing rule.
The permitted offline operation scope is limited to what can actually
be enforced under that local protection model.
The edge agent cannot claim unlimited current central authority from
an old checkpoint.
Expected demonstrable result: Offline continuation remains bounded
rather than creating unrestricted parallel effectuation permission.
27.60 — WORKED EXAMPLE Q: CAUSAL WORKFLOW CONTINUATION
Agent A publishes a file.
9.6.3.51. Source page 2296 of the original technical specification
A qualified resource receipt establishes actual publication.
The task migrates to Agent B.
A successor notification under CW-2 Mode B requires an IEV-accepted
publication receipt.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Agent B verifies the accepted predecessor evidence and separately
obtains current notification finality.
Expected demonstrable result: Real-effect causal continuity can
survive workload migration without merging historical completion
evidence with new execution authority.
27.61 — WORKED EXAMPLE R: PAYMENT AND NOTIFICATION CROSS-DOMAIN
WORKFLOW
A task comprises a payment followed by a customer notification.
The payment may have completed in Domain A.
The notification stage migrates to Domain B.
The payment's protected actual-effect receipt is preserved.
Domain B does not repeat the payment.
It performs the notification only after the applicable causal receipt
and notification authority predicates are satisfied.
Expected demonstrable result: Cross-domain workflow continuation
preserves effect-specific authority and qualified actual-effect
dependencies.
27.62 — WORKED EXAMPLE S: THREE-DOMAIN RECOVERY CHAIN
A task moves from Domain A to Domain B.
Domain B fails.
Domain C becomes the current owner.
The protected ownership generations advance monotonically.
Domain A and Domain B retain obsolete operation references.
The actual resource sink accepts only current qualified operation
authority associated with Domain C.
9.6.3.52. Source page 2297 of the original technical specification
Any previously dispatched effect is reconciled before incompatible
new effectuation.
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected demonstrable result: Repeated migration does not produce
cumulative duplicate execution rights.
27.63 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Replayed task checkpoint. 2. Replayed handoff certificate. 3.
Stale source worker. 4. Split-brain execution. 5. Duplicate owner
activation. 6. Lease expiry ambiguity. 7. Clock skew. 8. Forged
destination identity. 9. Unqualified destination attestation. 10.
Expired destination evidence. 11. Excessive delegated scope. 12.
Cross-domain credential leakage. 13. Reused source bearer token. 14.
Source finality reference replay. 15. Cross-domain non-bearer
reference misuse. 16. Ownership-generation rollback. 17. Journal
rollback. 18. Consumed authority resurrection. 19. Lost remote
acknowledgement. 20. Duplicate payment. 21. Duplicate storage
commit. 22. Duplicate database mutation. 23. Duplicate hardware
actuation. 24. Incomplete resource-side fencing. 25. Coordinator-
only fencing. 26. Uncontrolled alternate resource path. 27. Delayed
source request. 28. Late destination request from an obsolete
generation. 29. Old resource mapping. 30. New destination with
broader tool privileges. 31. Different tool semantics. 32.
Inconsistent source and destination policy. 33. Revocation during
migration. 34. Invalid source grant lineage. 35. Missing parent
delegation record. 36. Excessive destination authority. 37. Shared
cumulative budget duplication. 38. Partial branch migration
conflict. 39. Incompatible concurrent operations. 40. Resource-side
state not transferred. 41. Incomplete effect inventory.
9.6.3.53. Source page 2298 of the original technical specification
42. False completed-effect receipt. 43. False non-effect evidence.
44. Unqualified local success message. 45. Handoff acknowledgement
loss. 46. Destination activation race. 47. Destination failure
after ownership transfer. 48. Old owner recovery without new
assignment. 49. Unsafe automatic failback. 50. Time-of-check/time-
of-use change. 51. Unauthorized device after migration. 52. New
privileged connector. 53. Changed credential issuer. 54. Cached
authenticated session misuse. 55. Offline agent authority overrun.
56. Long-lived disconnected worker. 57. Monotonic epoch overflow or
incorrect reuse. 58. Distributed ledger inconsistency. 59.
Protected journal compromise. 60. Actual resource sink compromise.
61. Excessive handoff verification load. 62. Denial-of-service
during reconciliation. 63. Incorrect assumption of global exactly-
once effects. 64. Incomplete resource transaction identifiers. 65.
Same logical operation represented under different IDs. 66.
Compensation mistaken for original effect reversal. 67. Migration
treated as new source permission. 68. Attestation treated as
authorization. 69. Resource lease treated as actual finality. 70.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Independent remote effect executed outside verified coverage.
The claimed protection must be evaluated within the actual integrity,
consistency, and resource-enforcement assumptions of the selected
implementation.
27.64 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed, non-limiting experiments and are not
represented as completed tests.
Test 1 — Source Authority: Establish one originating consequential
task grant.
Test 2 — Source Candidate Act: Prepare a protected operation in
Domain A.
Test 3 — Non-Effective State: Verify that the proposed effect remains
withheld.
Test 4 — Pending Inventory: Enumerate current Candidate Acts and
authoritative operation states.
Test 5 — Destination Identity: Authenticate Domain B.
9.6.3.54. Source page 2299 of the original technical specification
Test 6 — Destination Qualification: Verify required execution
properties.
Test 7 — Handoff Commitment: Generate protected source/destination
evidence.
Test 8 — Source Fence: Prevent new affected source finality issuance.
Test 9 — Resource Fence: Reject a stale source operation at the
actual resource.
Test 10 — Ownership Generation: Advance the protected effectuation
owner.
Test 11 — Old Generation: Attempt effectuation using superseded
ownership state.
Test 12 — Current Generation: Verify ownership eligibility for the
destination.
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 13 — Source Scope: Ensure destination permission does not exceed
original authority.
Test 14 — Delegation Attenuation: Transfer only bounded effect scope.
Test 15 — Destination Finality: Constitute new destination-bound non-
bearer enablement.
Test 16 — Source Finality Replay: Reuse a source-specific reference
at the destination.
Test 17 — Destination Resource Identity: Verify the actual target
resource.
Test 18 — Destination Tool Identity: Verify actual execution
semantics.
Test 19 — Actual Sink Reconstruction: Compare Candidate Act with
actual pending effect.
Test 20 — Sink-Local Consumption: Consume the permitted operation
authority.
Test 21 — Duplicate Operation: Attempt a second effect under the same
logical operation identity.
Test 22 — Lease Expiry: Pause the original worker beyond its
coordination lease.
Test 23 — Stale Worker Resumption: Resume the old worker after new
ownership activation.
Test 24 — Split-Brain: Simultaneously run both workers.
Test 25 — Partitioned Coordinator: Deny reliance on stale local
leadership beliefs.
Test 26 — Source Dispatch Before Migration: Dispatch an effect before
the handoff.
Test 27 — Lost Acknowledgement: Suppress the remote success response.
Test 28 — Outcome Reconciliation: Obtain qualified actual-effect
evidence.
Test 29 — Indeterminate Effect: Preserve current uncertainty.
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.6.3.55. Source page 2300 of the original technical specification
Test 30 — No Automatic Retry: Prevent incompatible new effect under
unresolved state.
Test 31 — Qualified Non-Effect: Establish resource-supported non-
consumption.
Test 32 — Authorized Retry: Exercise any supported retry procedure
under current authority.
Test 33 — Consumed Authority: Preserve consumption after migration.
Test 34 — Completed Payment: Transfer the task without repeating a
completed payment.
Test 35 — Completed Data Release: Preserve actual disclosure
accounting.
Test 36 — Partial Resource Effect: Maintain confirmed and unresolved
portions.
Test 37 — Multi-Resource Task: Migrate with different resource
operation states.
Test 38 — Shared Budget: Prevent duplicated authority among branches.
Test 39 — Partial Branch Migration: Move one branch without changing
others.
Test 40 — Source Revocation: Revoke originating permission during
migration.
Test 41 — Destination Revocation: Revoke destination eligibility
after qualification.
Test 42 — Tool Change: Change destination operation semantics.
Test 43 — Credential Broker: Use credential-dependent finality
without exporting raw reusable secrets.
Test 44 — Cross-Region Migration: Verify resource mappings after
relocation.
Test 45 — Resource Ownership Change: Reject stale resource bindings.
Test 46 — Destination Failure: Fail the new owner after activation.
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 47 — Third Owner: Establish a new protected recovery assignment.
Test 48 — No Automatic Failback: Reject an old source resuming
without current ownership.
Test 49 — Handoff Replay: Replay an old signed migration record.
Test 50 — Checkpoint Rollback: Restore old computational state but
preserve current consumed authority.
Test 51 — Ownership Rollback: Attempt to decrease the protected
accepted epoch.
Test 52 — Clock Skew: Exercise lease and generation rules with
differing local clocks.
9.6.3.56. Source page 2301 of the original technical specification
Test 53 — Offline Edge: Test bounded local authority under
disconnection.
Test 54 — Local Resource Sink: Verify offline protected finality
where supported.
Test 55 — CW-2 Receipt: Preserve a predecessor qualified actual-
effect receipt across migration.
Test 56 — CW-3 Scope Expansion: Require valid new source authority
for expanded destination scope.
Test 57 — Hardware Command: Reject obsolete device-control ownership.
Test 58 — Database Operation: Enforce resource-side logical operation
identity.
Test 59 — Object Storage: Reconcile a completed object creation after
timeout.
Test 60 — Network Disclosure: Prevent duplicate or excessive data
release after migration.
Test 61 — Removal of Source Fence: Compare old-worker behavior
without migration fencing.
Test 62 — Removal of Sink Epoch: Test whether a stale worker can act
despite coordinator reassignment.
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Test 63 — Removal of Destination Qualification: Test unjustified
authority migration.
Test 64 — Removal of Source Lineage: Test erroneous scope expansion.
Test 65 — Removal of Non-Bearer Reconstitution: Attempt use of copied
source authorization.
Test 66 — Removal of Effect Reconciliation: Measure duplicate
resource effects after lost acknowledgement.
Test 67 — Removal of Sink Consumption: Test duplicate authority
through several execution domains.
Test 68 — Removal of Resource Identity Verification: Test
effectuation against a different destination target.
Test 69 — Concurrent Migration: Race two destination candidates for
current ownership.
Test 70 — Handoff Denial-of-Service: Bound verification and
reconciliation workload.
Test 71 — Long-Running Task: Perform repeated controlled migrations.
Test 72 — Three-Domain Chain: Migrate A to B to C with current
generation checks.
Test 73 — Multiple Sinks: Verify resource-specific current ownership
and effect states.
9.6.3.57. Source page 2302 of the original technical specification
Test 74 — End-to-End Crash Injection: Interrupt migration at each
protected state transition.
Test 75 — Full Integrated Workflow: Combine source authorization,
Candidate Act, source fence, destination attestation, ownership
transfer, in-flight reconciliation, finality reconstitution, actual
sink reconstruction, and qualified outcome evidence.
27.64.1 — Required Measurements
The experiments may measure:
Unauthorized actual effects;
Duplicate completed resource mutations;
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Stale-worker rejection;
Ownership-generation correctness;
Resource-side fencing accuracy;
Destination authority inflation;
Effect reconciliation accuracy;
Consumed authority resurrection;
Time-to-recover;
Migration-induced unavailability;
And protected validation overhead.
27.64.2 — Comparative Evaluation
A useful comparison comprises:
Configuration A: Task checkpoint and ordinary worker reassignment.
Configuration B: Worker reassignment with leases and coordination
fencing.
Configuration C: Worker reassignment with protected source-authority
continuity, resource-enforced ownership fencing, destination
qualification, operation-specific non-bearer finality reconstitution,
and in-flight actual-effect reconciliation.
The tests may determine whether an old worker or newly migrated agent
can cause an unauthorized duplicate or changed real resource effect.
9.6.3.58. Source page 2303 of the original technical specification
27.65 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
27.65.1 — Minimum Components
A practical reference prototype may comprise:
Two isolated agent workers;
A protected source-authority service;
A transactional ownership registry;
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A durable operation journal;
A protected finality controller;
And a receiving test-resource API.
27.65.2 — Original Task
The originating principal permits one protected database mutation.
27.65.3 — Source Worker
Worker A constructs the Candidate Act.
27.65.4 — Source Authority
The operation is associated with a current source grant.
27.65.5 — Migration
The coordinator prepares transfer to Worker B.
27.65.6 — Source Fence
The protected resource owner generation advances.
27.65.7 — Destination Qualification
Worker B is authenticated and qualified.
27.65.8 — Finality Reconstitution
Worker B receives current operation-specific authority.
27.65.9 — Actual Resource Check
The receiving test API validates the current owner generation and
logical operation state.
9.6.3.59. Source page 2304 of the original technical specification
27.65.10 — Stale Worker
Worker A submits its old request.
27.65.11 — Expected Result
Worker A's request is rejected.
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.65.12 — Destination Effect
Worker B submits the current authorized request.
27.65.13 — Expected Result
The permitted mutation occurs once under the test resource's
authoritative consistency and consumption assumptions.
27.65.14 — Network Failure
The success response is suppressed.
27.65.15 — Recovery
Worker B restarts.
The controller queries the authoritative test-resource state.
27.65.16 — Expected Result
A completed mutation is not repeated as a new effect merely because
the response was lost.
27.65.17 — Next Migration
The task moves to Worker C.
27.65.18 — Expected Result
Earlier consumed authority remains consumed.
27.65.19 — Technical Qualification
The demonstration establishes a resource-specific guarantee for the
tested Finality Sink.
It does not prove universal exactly-once execution for independently
operated external systems lacking compatible enforcement or
reconciliation.
27.66 — OPTIONAL ADVANCED VARIATIONS
9.6.3.60. Source page 2305 of the original technical specification
27.66.1 — Planned Migration
The source cooperatively transfers a bounded task.
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.66.2 — Failure-Based Migration
A replacement is established without reliable source shutdown.
27.66.3 — Resource-Side Ownership Epoch
A sink rejects requests from obsolete execution owners.
27.66.4 — Destination Remote Attestation
A qualified attestation result supplies selected execution-state
evidence.
27.66.5 — Token-Exchange-Assisted Delegation
A cross-domain authorization service issues a suitably scoped
destination credential.
27.66.6 — No Raw Secret Transfer
Reusable credential custody remains with a protected broker.
27.66.7 — Candidate-Specific Ownership
Different Candidate Acts may have different current execution owners.
27.66.8 — Branch-Specific Migration
Only selected workflow branches move.
27.66.9 — Global Task-Level Fence
A broad safety transition fences all affected consequential task
operations.
27.66.10 — Resource-Specific Fence
Individual resource sinks enforce corresponding ownership
generations.
27.66.11 — Offline Bounded Authority
A local qualified sink enforces an expressly preallocated scope.
27.66.12 — Migration Quarantine
Unresolved effects remain unavailable for incompatible new
effectuation.
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.66.13 — Qualified Outcome Receipt
9.6.3.61. Source page 2306 of the original technical specification
A resource provides authenticated effect-completion evidence.
27.66.14 — Protected Rollback
Computational rollback does not restore consumed finality.
27.66.15 — Multi-Generation Recovery
Each subsequent migration advances current protected ownership state.
27.66.16 — Current Tool Validation
The destination qualifies its actual tool runtime.
27.66.17 — Cumulative Resource Budgets
Shared grants remain conserved across migration.
27.66.18 — Device-Control Failover
Hardware sinks verify current controller ownership and command scope.
27.66.19 — Payment-Reconciliation Migration
A destination reconciles qualified financial effects before new
dispatch.
27.66.20 — Receipt-Dependent Workflow Continuation
An accepted predecessor actual-effect receipt remains applicable
under a separately authorized successor.
These variations are illustrative and may be implemented
independently or in compatible combinations.
27.67 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
27.67.1 — Existing Foundations
Existing systems provide workload migration, distributed leases,
leader election, fencing tokens, transactional state, token exchange,
remote attestation, durable journals, and selected idempotency
mechanisms.
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
The embodiment may use these foundations without claiming their
separate invention.
27.67.2 — Candidate Objective Technical Problem
How to continue a consequential autonomous task across execution
domains while preventing duplication or resurrection of operation-
specific authority, notwithstanding
9.6.3.62. Source page 2307 of the original technical specification
split-brain workers, stale credentials, changes in destination
execution environment, and uncertainty over resource effects
initiated before migration.
27.67.3 — Proposed Technical Solution
A protected source-authority record remains authoritative across
migration.
Candidate Acts are associated with operation-specific execution-
ownership and consumption state.
A source finality fence prevents further affected old-owner
authority.
A protected ownership-generation controller advances the accepted
execution owner.
The destination is independently qualified.
In-flight resource operations are classified and reconciled.
A new destination-bound non-bearer finality enablement is constituted
where permitted.
The actual Finality Sink reconstructs and verifies the real pending
effect against current source authority, ownership generation,
resource state, and protected consumption before release.
27.67.4 — Not Merely Workload Migration
A workflow migration mechanism may transfer code, data, or
checkpoints.
The proposed system separately controls permission for actual
consequential operations.
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.67.5 — Not Merely Leader Election
Leader election may determine which worker is designated active.
The actual resource must still enforce current effectuation
eligibility.
27.67.6 — Not Merely a Lease
An expired lease does not necessarily stop an old worker.
The proposed stronger combination includes resource-enforced current
ownership and operation-specific finality.
27.67.7 — Not Merely a Fencing Token
A fencing token can reject stale operations.
The proposed combination additionally verifies original source-
authorized effect scope, destination qualification, and non-
resurrected protected consumption.
9.6.3.63. Source page 2308 of the original technical specification
27.67.8 — Not Merely Token Exchange
An exchanged token may delegate access to another service.
The proposed system additionally binds the destination's actual
Candidate Act and sink-local finality to the current original
authority.
27.67.9 — Not Merely Remote Attestation
Attestation may establish selected properties of an execution
environment.
The proposed system requires current consequential operation
authorization independently of attestation.
27.67.10 — Not Merely Checkpoint Recovery
A checkpoint restores computational state.
The proposed system preserves the independent authoritative state of
effects already consumed or dispatched.
27.67.11 — Candidate Narrow Inventive Kernel
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A protected distributed autonomous execution-finality system in which
a consequential Candidate Act is associated with an originating
source-authority record and a current protected effectuation-
ownership generation, migration activates a source-domain finality
fence and establishes independently qualified destination authority,
previously dispatched or consumed effects are reconciled without
automatic authority restoration, destination-specific scoped non-
bearer finality is constituted, and an actual Finality Sink
reconstructs the pending consequential operation and permits the
effect only after verifying current ownership, source-authorized
scope, resource state, and sink-local protected consumption.
27.67.12 — In-Flight Effect Kernel
A narrower candidate may require classification of prepared,
consumed, dispatched, completed, and indeterminate effects before
destination finality reconstitution.
27.67.13 — Source-to-Destination Fence Kernel
Another candidate may require current resource-enforced source
invalidation before destination finality becomes effective.
27.67.14 — Multi-Generation Kernel
Another candidate may require repeated handoffs using monotonic
protected ownership generations and conserved finality consumption
across all prior owners.
27.67.15 — Credential-Custody Kernel
9.6.3.64. Source page 2309 of the original technical specification
Another candidate may permit cross-domain task migration without
transferring reusable credential material, while preserving actual
operation-specific broker authority.
27.67.16 — Hardware-Failover Kernel
Another candidate may require device-side ownership fencing and
qualified prior-actuation state before permitting a replacement
controller to perform a further physical effect.
27.67.17 — Hindsight and Functional-Combination Analysis
The inventive-step comparison should examine the closest earlier
distributed workflow, authorization, and resource-fencing
disclosures.
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
It should recognize that leases, epochs, fencing tokens, distributed
logs, idempotency, and token exchange are established techniques.
The distinguishing technical argument should not rely merely upon
using those familiar primitives together.
The stronger candidate argument concerns whether an earlier reference
or technically motivated combination already teaches:
Operation-specific Candidate Act authority;
Mandatory source-domain finality fencing;
Qualification of a different destination enforcement domain;
Preservation of historical actual-effect and consumption state;
Reconstitution of non-bearer finality under current source
permission;
And independent actual resource-sink verification of current
ownership and actual effect semantics.
A useful proposed comparative test intentionally creates a stale
worker and an uncertain previously dispatched effect, then measures
whether the resource accepts any unauthorized duplicate or changed
consequence.
Any asserted surprising or non-obvious technical effect should be
tied to evidence and the actual specific claim limitations rather
than presumed from terminology.
27.68 — INDUSTRIAL APPLICABILITY
27.68.1 — Multi-Agent Orchestration
Autonomous tasks may move between agents while protected resource
authority remains bounded.
9.6.3.65. Source page 2310 of the original technical specification
27.68.2 — Cloud Workload Failover
Cloud workers may recover without duplicating protected external
effects.
27.68.3 — Enterprise Workflow Automation
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Long-running tasks may migrate between administrative domains.
27.68.4 — Financial Processing
Payment effects may be reconciled across worker failover.
27.68.5 — Database Services
Actual database mutations may be protected against stale-worker
duplication.
27.68.6 — Object Storage
Resource creation or publication may remain bound to current
operation authority.
27.68.7 — Confidential Data Processing
Information-disclosure effects may remain conserved across task
migration.
27.68.8 — Edge Computing
Bounded offline work may be governed with local protected authority.
27.68.9 — Distributed API Infrastructure
Service-to-service delegation may remain operation-specific.
27.68.10 — Software Deployment
Deployment operations may continue across worker replacement without
duplicate releases.
27.68.11 — Telecommunications
Control-plane operations may be protected during controller failover.
27.68.12 — Network Management
Stale network controllers may be fenced from protected configuration
effects.
27.68.13 — Industrial Automation
Device-control ownership may move between controllers without
unauthorized repeated commands.
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
27.68.14 — Robotics
9.6.3.66. Source page 2311 of the original technical specification
Physical actuation authority may remain bounded across processing-
unit changes.
27.68.15 — Autonomous Transportation
Control tasks may change processors while preserving current actual-
command permission.
27.68.16 — Satellite Systems
Delayed communication and handoff may preserve bounded effectuation
state.
27.68.17 — Remote Device Administration
Administrative tasks may be reassigned under protected current
resource authority.
27.68.18 — Confidential Computing
Destination attestation may contribute to qualified cross-domain
operation authority.
27.68.19 — Persistent Autonomous Workflows
Long-running processes may recover or migrate without restoring
consumed finality.
27.68.20 — Future Autonomous Critical Systems
Execution ownership and actual consequential authority may remain
technically distinct across distributed environments.
27.69 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
27.69.1 — Candidate Independent System Claim
A system comprising:
A protected originating authority controller configured to maintain
an authenticated consequential source grant;
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
A Candidate Act controller configured to associate a pending
consequential operation with current execution ownership and
authoritative actual-effect state;
A migration controller configured to establish a protected source-
domain finality fence;
A destination qualification controller configured to verify a
successor execution domain;
An ownership-generation controller configured to assign current
protected effectuation ownership;
A protected outcome controller configured to preserve previously
consumed, dispatched, completed, and unresolved effect state;
9.6.3.67. Source page 2312 of the original technical specification
A finality controller configured to establish destination-specific
scoped non-bearer finality enablement;
And an independent Finality Sink configured to reconstruct the actual
pending resource operation and permit the effect only following
verification of current source authority, protected ownership
generation, operation correspondence, and sink-local protected
consumption.
27.69.2 — Candidate Independent Method Claim
A method comprising:
Receiving a request to migrate an autonomous computational task;
Identifying current consequential Candidate Acts;
Classifying their protected actual-effect states;
Establishing a source finality fence;
Qualifying a destination execution domain;
Advancing a protected effectuation-ownership generation;
Reassessing current originating authority;
Reconciling previously dispatched operations;
Constituting destination-bound non-bearer finality;
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Reconstructing an actual pending resource operation at a Finality
Sink;
And permitting effectuation only upon verification of current
ownership, source-authorized scope, actual resource state, and
protected consumption.
27.69.3 — Candidate Independent Failover Claim
A protected failover system configured to prevent a stale autonomous
worker from causing a protected resource effect after reassignment by
requiring current resource-enforced ownership generation and
operation-specific finality, including where the stale worker retains
a valid historical execution lease or checkpoint.
27.69.4 — Candidate Independent Outcome-Reconciliation Claim
A distributed autonomous recovery system configured to classify an
operation as prepared, consumed, dispatched, completed, or
indeterminate before transferring additional effectuation authority,
and to prevent an unresolved previously dispatched operation from
automatically becoming a new independent executable effect following
migration.
27.69.5 — Candidate Independent Cross-Domain Delegation Claim
9.6.3.68. Source page 2313 of the original technical specification
A system configured to transfer an autonomous task into a separately
qualified execution domain while preserving bounded original source
authorization, avoiding unrestricted reusable credential transfer,
and requiring independently constituted destination-specific non-
bearer finality at the actual consequential resource sink.
27.70 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The source domain comprises an autonomous AI agent. 2. The
destination comprises another autonomous AI agent. 3. The source and
destination execute in separate processes. 4. The source and
destination execute in separate containers. 5. The source and
destination execute on separate physical hosts. 6. The source and
destination execute in different cloud regions. 7. The source and
destination are controlled by different administrative authorities.
8. The originating source grant is maintained separately from task
checkpoints. 9. A Candidate Act is identified before migration. 10.
The Candidate Act identifies an actual consequential resource. 11.
The Candidate Act is maintained non-effective. 12. A protected
pending-act inventory identifies current operation states. 13. The
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
inventory distinguishes prepared from consumed finality. 14. The
inventory distinguishes dispatched from confirmed completed effects.
15. The inventory identifies indeterminate external outcomes. 16. A
protected migration fence prevents additional old-source authority.
17. The source fence is associated with a current ownership
generation. 18. The actual resource sink verifies the current
ownership generation. 19. A stale source request is denied. 20. An
expired coordination lease does not independently establish safe
resource
ownership transfer. 21. A protected owner registry advances
ownership monotonically. 22. A destination is authenticated before
receiving current operation authority. 23. A destination may be
qualified using runtime attestation. 24. An attestation result does
not independently constitute source permission. 25. A protected
handoff commitment identifies the source and destination. 26. The
handoff commitment identifies relevant Candidate Acts. 27. The
handoff commitment identifies current protected source authority. 28.
The handoff commitment includes current ownership-generation
information. 29. The handoff commitment is authenticated. 30. An
obsolete handoff reference is rejected. 31. A destination may
receive a bounded delegation. 32. Destination authority cannot
exceed the applicable originating grant. 33. A destination-specific
non-bearer finality enablement is established. 34. The destination
does not automatically reuse the source's finality enablement. 35.
The finality enablement is bound to current destination identity. 36.
The finality enablement is bound to the actual designated sink. 37.
The finality enablement is bound to a current ownership generation.
38. The finality enablement identifies the Candidate Act. 39. The
finality enablement is associated with current validation evidence.
40. The sink reconstructs the actual pending resource operation.
9.6.3.69. Source page 2314 of the original technical specification
41. The sink verifies the current source-authorized resource. 42.
The sink verifies actual operation parameters. 43. The sink verifies
current revocation state. 44. The sink verifies sink-local protected
consumption. 45. A previously consumed source operation cannot be
recreated through migration. 46. A completed external effect is
preserved in the protected journal. 47. A dispatched operation with
unknown outcome is not automatically treated as
unperformed. 48. An indeterminate operation may be quarantined. 49.
Qualified resource evidence may establish actual effect completion.
50. Qualified non-effect evidence may permit an authorized
resolution. 51. A destination may continue unrelated operations
while an incompatible effect is
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
quarantined. 52. Multiple execution domains may share one bounded
original effect allowance without
duplicating the allowance. 53. A source and destination may coexist
during a protected migration. 54. A stale execution domain may be
fenced through resource-local state. 55. A partial workflow branch
may migrate independently. 56. A shared resource budget may remain
conserved across branches. 57. A cross-domain credential broker may
retain reusable secrets in protected custody. 58. An operation-
specific credential-use authorization may be established for the
destination. 59. The destination may have a different tool runtime
requiring current qualification. 60. A change in actual resource
mapping may require current resource-identity validation. 61. A
protected lifecycle generation may bind destination execution
eligibility. 62. A protected device controller may enforce current
control ownership. 63. A physical actuation may require current
device state evidence. 64. A financial operation may use a stable
logical transaction identifier. 65. A remote resource may support
idempotent same-logical-operation retry. 66. An idempotency
mechanism does not independently replace source authorization. 67. A
checkpoint rollback does not restore previously consumed finality.
68. A migration rollback does not automatically restore earlier
ownership state. 69. A destination failure may trigger a new
protected owner generation. 70. The prior source does not regain
authority merely because the destination fails. 71. A protected
source revocation invalidates affected destination finality. 72. A
bounded offline allocation may be enforced by a qualified local sink.
73. Temporal lease uncertainty may be handled separately from
monotonic resource
fencing. 74. A qualified prior-effect receipt may be preserved
across migration. 75. Where CW-2 applies, a successor operation may
require an accepted prior actual-
effect receipt. 76. Where CW-3 applies, a migration-induced
expansion of the authorized effect scope
may require a new source grant. 77. A resource-side effectuation
path must support the required ownership and finality
predicates. 78. A protected journal may preserve attempted and
completed effects across repeated
migrations. 79. The system may maintain three or more sequential
ownership generations without
reuse of superseded effectuation authority.
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
9.6.3.70. Source page 2315 of the original technical specification
80. Existing leases, conditional transactions, remote attestation,
token exchange, durable
journals, and resource-fencing mechanisms may be used as optional
implementation substrates.
27.71 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The mechanisms disclosed in the present embodiment may be implemented
individually where technically sufficient or in any compatible
combination.
A selected embodiment may use cooperative planned migration.
Another may perform failover after source loss.
Another may use protected distributed ownership epochs.
Another may use resource-side fencing tokens.
Another may use current source-authority checks.
Another may employ bounded token exchange.
Another may retain reusable credentials in a protected broker.
Another may qualify the destination through remote attestation.
Another may preserve operation state in a transactional database.
Another may use a durable message journal.
Another may maintain per-resource qualified completion receipts.
Another may perform recovery through an independent resource-
observation channel.
Another may govern device-control migration.
Another may govern payment-service failover.
Another may preserve protected data-disclosure budgets.
Another may operate through bounded offline authority.
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Another may incorporate protected tool-generation continuity.
Another may use an accepted actual-effect receipt to enable a causal
successor operation.
The invention does not require that all agents use the same
programming language, model provider, cloud infrastructure,
administrative domain, or orchestration framework.
9.6.3.71. Source page 2316 of the original technical specification
The invention does not require the source and destination to share
unrestricted credentials.
The invention does not require every task migration to transfer all
of the original task's consequential authority.
The invention does not require that all distributed external resource
services share one global atomic transaction.
The invention does not rely solely upon lease expiry to prove source
termination.
The invention does not assume that a successful task checkpoint
represents the authoritative state of external resource effects.
The invention does not universally guarantee exactly-once completed
effects at independent remote services lacking sufficient operation
identity, deduplication, authoritative finality enforcement, or
outcome evidence.
Where a protected source and destination operate concurrently, the
selected resource-side enforcement must establish the current
acceptable authority under the applicable consistency model.
Where the destination cannot verify a mandatory current source or
resource predicate, the corresponding protected consequence remains
withheld.
Where a remote operation's outcome remains indeterminate, the
controller must preserve the applicable protected uncertainty or use
another authorized recovery mechanism rather than assume non-effect.
The equations, data structures, algorithms, examples, state machines,
diagrams, and proposed experiments are illustrative and non-limiting
technical aids intended to assist a PHOSITA.
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Compatible mechanisms from the earlier embodiments may be combined
without requiring every optional feature to be present in all
implementations.
27.72 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 27 discloses a protected distributed
autonomous execution-finality architecture in which computational
work may migrate across execution domains without automatically
transferring unrestricted consequential authority.
An originating source-authority service maintains the current
permitted resource-effect envelope.
Candidate Acts are associated with protected operation-specific
ownership and resource-effect state.
A migration controller identifies the pending operations and their
actual known states.
9.6.3.72. Source page 2317 of the original technical specification
A protected source finality fence prevents continued exercise of
superseded operation authority.
A destination execution domain is independently qualified.
A protected ownership-generation controller establishes current
destination eligibility.
Previously consumed, dispatched, completed, and indeterminate effects
remain represented in protected state.
A destination does not automatically treat an unacknowledged source
operation as unperformed.
Where permissible, new destination-bound scoped non-bearer finality
is constituted following current independent validation.
At the actual resource boundary, the Finality Sink reconstructs the
pending consequential operation and verifies current source
authorization, ownership generation, resource identity, operation
correspondence, and protected consumption.
A stale worker may retain computational state, a historical lease, an
old task token, or a former finality reference.
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Such possession does not independently establish current
consequential execution authority.
A destination may continue legitimate operations but may not recreate
resource effects already consumed or completed.
The architecture may use established distributed coordination, token-
exchange, attestation, transactional storage, and resource-fencing
mechanisms.
The principal candidate inventive technical concept of Embodiment 27
is a protected distributed autonomous execution-finality system in
which operation-specific source authority is preserved across
workload migration through source-domain fencing, qualified
destination handoff, monotonic effectuation-ownership generations,
independent reconciliation of in-flight real effects, destination-
specific non-bearer finality reconstitution, and actual Finality-Sink
verification preventing stale or duplicate consequential effects.
27.73 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may implement the disclosed mechanisms using selected
existing components.
Existing technology Optional technical role
Kubernetes Lease objects Coordinate which worker should currently
perform a task
10. Threat Models and Security Assumptions
These six analytical threat models are editorial security analyses
grounded in the described attack and failure classes. They do not
imply a formally verified security proof or complete prevention
outside the defined effectuation coverage. Each lists attacker
ability, protected assets, failure chain, security control, evidence
requirements, residual limitations and a proposed verification test.
10.1. TM-1: Prompt Injection into AI Agent Tool Selection
Adversary capability and attack sequence: Attacker controls a
retrieved page, document, tool response or lower-trust instruction
that steers the AI agent to export a document or select a different
recipient.
Security assets: Protected user grant; actual recipient; sensitive
resource.
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Proposed prevention/detection controls: Treat candidate from model as
untrusted; capture authorized effect envelope independent of
retrieved instruction; observe real network/file release at sink.
Residual risk and model limitations: An attacker might exploit a
direct path not covered by the sink or induce the competent human
principal to issue a new scope grant.
Relevant proposed technical tests: T02,T05,T17.
10.2. TM-2: Replay, Clone and Stale Authority
Adversary capability and attack sequence: Attacker reuses a scoped
reference, restores app snapshot, duplicates task onto another device
or replays previously valid cross-platform evidence.
Security assets: Single-use authority; protected epoch; original task
identity.
Proposed prevention/detection controls: Bind to unique
operation/sink/epoch; verify current sink-local consumption
atomically; deny duplicate activation and stale owner.
Residual risk and model limitations: Real-world effect duplication
may still occur if remote service has no idempotency and effect
outcome is unknown.
Relevant proposed technical tests: T04,T08,T12.
10.3. TM-3: Bypass through Alternative Effectuation Paths
Adversary capability and attack sequence: Attacker moves from
approved tool API to direct network socket, privileged connector,
share sheet, IPC or alternate cloud endpoint.
Security assets: Enforcement topology; actual covered consequence.
Proposed prevention/detection controls: Enumerate and fence actual
effect-capable interfaces; enforce policy at downstream controlled
effect resource rather than solely tool selection.
Residual risk and model limitations: Ordinary mobile third-party apps
cannot control kernel-wide paths; claims must be limited to
cooperating receivers and controlled gateways.
Relevant proposed technical tests: T06,T11,T16.
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
10.4. TM-4: Forged, Stale or Mismatched Evidence
Adversary capability and attack sequence: Attacker supplies fake
platform entitlement, revoked token, substituted signed descriptor,
manipulated identity/alias, or corrupted policy generation.
Security assets: Evidence provenance, freshness, original authority
and actual resource binding.
Proposed prevention/detection controls: Require integrity, issuer,
freshness, revocation generation and actual operation correspondence;
avoid equating possession proof with consent.
Residual risk and model limitations: A fully compromised evidence
issuer or hardware trust root remains outside the guarantee unless
separately qualified.
Relevant proposed technical tests: T03,T07,T10.
10.5. TM-5: Scope Escalation during OS Translation
Adversary capability and attack sequence: Valid broad platform
permission is transformed into a payment, data export, irreversible
API operation or excessive file access beyond the original purpose.
Security assets: Source-authorized scope; resource identity; content
and recipient commitments.
Proposed prevention/detection controls: Explicit effect-descriptor
semantics; no broadening during mapping; current user/delegated
grant; require separate scoped reauthorization under CW-3.
Residual risk and model limitations: Ambiguous source purpose must be
clarified or withheld rather than guessed.
Relevant proposed technical tests: T01,T09,T15.
10.6. TM-6: Compromised Connector, Device or Infrastructure
Adversary capability and attack sequence: Attacker compromises agent
runtime, container, cloud connector, destination service, Android IPC
peer, endpoint resolver or portions of the enforcement stack.
Security assets: Protected finality keys, protected sink state,
policy/epoch integrity, actual target.
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Proposed prevention/detection controls: Separate critical decision
path; protect state and trusted references; enforce actual-operation
comparison, service authentication and revocation freshness.
Residual risk and model limitations: Compromise of final controlled
sink or undefined hardware trust assumption can defeat guarantees;
fail-closed availability may cause denial of service.
Relevant proposed technical tests: T13,T14,T18,T20.
11. Proposed Technical Validation Plan: Twenty Reproducible Tests
The tests below are PROPOSED and are not reported as executed or
passed. Acceptance of a request and successful effectuation are
different expected outcomes. Every implementation must record build
version, source grant, exact CA/descriptor bytes or commitments,
policy versions, protected epoch, sink-local state, evidence
references and receiver-observed outcome before claiming a test
result.
11.1. T01: Authorized iOS-to-Android API operation
Preconditions and fixture: Valid source grant, native adapter
evidence and exact receiver target.
Stimulus/procedure: Authorized precise operation presented at
cooperating receiving sink.
Expected result (not an observed result): ALLOW after sink-local
consumption; one matching effect.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.2. T02: Prompt injection recipient substitution
Preconditions and fixture: Untrusted fetched content suggests
attacker destination.
Stimulus/procedure: Agent proposes outgoing content to substituted
recipient.
Expected result (not an observed result): WITHHOLD; original grant
not silently broadened.
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.3. T03: Platform permission to effect-scope confusion
Preconditions and fixture: Native app has broad file permission but
narrow source grant.
Stimulus/procedure: Attempt to export entire directory rather than
one approved file.
Expected result (not an observed result): WITHHOLD; source permission
not treated as full finality.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.4. T04: Replay finality reference
Preconditions and fixture: Previously consumed operation reference.
Stimulus/procedure: Replay same ref at receiver.
Expected result (not an observed result): WITHHOLD; consumption state
unchanged except audit.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.5. T05: Content-hash mutation after approval
Preconditions and fixture: Prepared approved content commitment.
Stimulus/procedure: Change outgoing payload before dispatch.
Expected result (not an observed result): WITHHOLD; actual payload
mismatch.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
11.6. T06: Direct socket bypass
Preconditions and fixture: Gateway tool policy present; alternate
direct egress exists.
Stimulus/procedure: Attempt same transfer via direct network path.
Expected result (not an observed result): Refuse or accurately report
uncovered path; never claim mandatory enforcement if bypass succeeds.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.7. T07: Expired platform evidence
Preconditions and fixture: Old signed adapter evidence with new
pending request.
Stimulus/procedure: Invoke effect with expired evidence.
Expected result (not an observed result): WITHHOLD or revalidate
before any effect.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.8. T08: Old device owner after handoff
Preconditions and fixture: Epoch E owner, migration to E+1.
Stimulus/procedure: Source sends stale prepared act.
Expected result (not an observed result): WITHHOLD by effective
source fence.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.9. T09: Cross-platform privilege amplification
Preconditions and fixture: Destination native permission exceeds
original grant.
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Stimulus/procedure: Translate narrower app authority to broader
receiver action.
Expected result (not an observed result): WITHHOLD or attenuate to
original effect.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.10. T10: Redirect to alternate host
Preconditions and fixture: Authorized URL, server redirects to
different ownership.
Stimulus/procedure: Attempt effect after redirect.
Expected result (not an observed result): WITHHOLD pending newly
qualified actual target.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.11. T11: Symlink or resource alias swap
Preconditions and fixture: Authorized filesystem target has mutable
symlink.
Stimulus/procedure: Resolve to different protected resource during
send.
Expected result (not an observed result): WITHHOLD or re-verify
actual resource binding.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.12. T12: Clone/rollback of destination runtime
Preconditions and fixture: Same authority copied into two concurrent
runtimes.
Stimulus/procedure: Both race to consume same reference.
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Expected result (not an observed result): At most one authorized
effect under committed shared sink state.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.13. T13: Compromised source agent token misuse
Preconditions and fixture: Agent obtains unrelated valid credential.
Stimulus/procedure: Attempt out-of-scope financial API request.
Expected result (not an observed result): WITHHOLD by original
authorization and sink actual-operation check.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.14. T14: Unattestable privileged connector
Preconditions and fixture: Untrusted connector lacks required
integrity attestation.
Stimulus/procedure: Request requiring elevated assurance.
Expected result (not an observed result): WITHHOLD; fail closed
rather than pretending attestation exists.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.15. T15: CW-3 scope-deviation reapproval
Preconditions and fixture: Original grant narrow; competent principal
issues bounded delta.
Stimulus/procedure: Request changed parameters after reauthorization.
Expected result (not an observed result): ALLOW only newly bounded
exact operation and current sink validation.
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.16. T16: Missing effectuation-path coverage
Preconditions and fixture: New background job provides alternate
mutation route.
Stimulus/procedure: Request through newly introduced tool.
Expected result (not an observed result): WITHHOLD covered class
until topology revalidated.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.17. T17: Out-of-order causal continuation
Preconditions and fixture: Successor requires qualified earlier
effect receipt.
Stimulus/procedure: Successor arrives with only enqueue ACK.
Expected result (not an observed result): WITHHOLD until accepted
actual-effect evidence per CW-2.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.18. T18: Crash after protected consumption
Preconditions and fixture: Sink marks consumed, dispatcher crashes
before ACK.
Stimulus/procedure: Agent retries using same enablement.
Expected result (not an observed result): WITHHOLD replay; reconcile
receiver outcome before authorized new action.
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.19. T19: Partitioned device migration
Preconditions and fixture: Old device offline and no effective source
fence.
Stimulus/procedure: Activate replacement owner under strict
exclusive-transfer mode.
Expected result (not an observed result): WITHHOLD unless separately
authorized bounded-lease condition applies.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
11.20. T20: Correct valid multi-platform deployment
Preconditions and fixture: Fresh grants, current versions, end-to-end
controlled sink.
Stimulus/procedure: Perform one authorized file export followed by
receipt validation.
Expected result (not an observed result): ALLOW one effect; preserve
evidence and no duplicate from retry.
Evidence to collect: source grant and CED commitment, protected
validation decision, actual receiving operation, sink-local finality
transition, error or outcome record. Fail the test if unauthorized
effect occurs even when the controller reports denial.
12. Detailed Industry and Product Alignment: Engineering Problem,
Integration Surface, and Limitations
References to named platforms or products identify engineering
problem classes, deployment possibilities and public integration
surfaces. They do not prove existing implementations of the complete
disclosed mechanism, product conformance, endorsement, collaboration,
derivation or infringement. Commercial names are illustrative;
vendor-neutral protected protocols and actual receiving-resource
enforcement remain the principal subject. Apple, Siri, iOS, iPadOS,
macOS, Android, Gemini, Bixby, Copilot, Alexa, and other names used
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
in this document are trademarks of their respective owners.
12.1. Apple iOS, iPadOS, macOS, Siri, App Intents, Shortcuts
Industry-specific security problem: AI tools can request an app
action or content sharing while entitlement and app sandbox semantics
vary from destination resource authority.
Illustrative technical implementation alignment: App Intents /
approved app extension or service API prepares bounded act, remote
protected gateway validates user source grant, receiving resource
verifies actual recipient and payload.
Limit and independent-verification qualification: No third-party iOS
app is presumed able to impose system-wide kernel hooks or force
unrelated provider services to participate.
12.2. Google Android, Android Keystore, Intents and Binder
Industry-specific security problem: Exported components, intent
forwarding and binder-mediated services provide opportunities for
permission confusion and confused deputies.
Illustrative technical implementation alignment: Android adapter
collects qualified caller, permission and secure-key evidence, binds
operation descriptor and delegates final enforcement to cooperating
service/sink.
Limit and independent-verification qualification: Android app
permissions or Keystore possession alone do not establish the actual
effect authorization.
12.3. Microsoft Windows, Azure, agent governance and enterprise
connectors
Industry-specific security problem: Long-running agents access
services across Windows/cloud identities, privilege boundaries and
delegation chains.
Illustrative technical implementation alignment: Protected gateway
enforces exact object/method/recipient for file, network and admin
operations; existing workload identity can contribute source
evidence.
Limit and independent-verification qualification: A named Microsoft
security feature does not imply implementation of receipt/capability/
sink consumption.
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
12.4. Google Gemini, Google Cloud and cross-application orchestration
Industry-specific security problem: AI planning and cloud application
calls may be separated from account resource ownership and permission
changes.
Illustrative technical implementation alignment: Constitute platform-
neutral act descriptors from tool calls; use authenticated server-
side resource identity and current source scope at receiving sink.
Limit and independent-verification qualification: No assumption that
Gemini or Google Cloud provides the specific proposed finality
semantics.
12.5. OpenAI Agents SDK, Responses API, Codex and computer use
Industry-specific security problem: LLM-generated API, browser,
filesystem and delegated tool calls may contain injected or mistaken
external actions.
Illustrative technical implementation alignment: Treat generated
action as CA; protected broker performs source/effect validation and
controlled dispatch to actual resource.
Limit and independent-verification qualification: No claim about
OpenAI product architecture, internal training, patents or adoption.
12.6. Anthropic Claude and Claude Code / Managed Agents
Industry-specific security problem: Sandboxes and approved tools may
not capture every actual credential-dependent or externally
irreversible consequence.
Illustrative technical implementation alignment: Combine runtime
isolation with downstream operation-scoped protected gateway, current
permission and independent sink checking.
Limit and independent-verification qualification: No claim that the
named products implement particular non-bearer evidence or sink
consumption methods.
12.7. Meta Muse/Sentinel and autonomous agent egress security
Industry-specific security problem: Sandboxing, request policy and
credential brokerage interact with real API destinations and tool
calls.
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Illustrative technical implementation alignment: Compare published
privilege separation and egress controls with source-authority-to-
actual-effect finality requirements.
Limit and independent-verification qualification: Do not equate
policy approval or token substitution to a verified separate finality
capability without evidence.
12.8. NVIDIA OpenShell / Sentry, accelerated and DPU enforcement
Industry-specific security problem: Agent process isolation and
hardware I/O routing may control some but not all consequential
paths.
Illustrative technical implementation alignment: Protected
accelerator/network gates may serve as possible receiving enforcement
substrates when exact operation identity and required protected state
can be verified.
Limit and independent-verification qualification: No universal
requirement for NVIDIA hardware, SmartNICs or accelerators, and no
assumed specific product implementation.
12.9. Qualcomm Snapdragon, Arm TrustZone, Huawei mobile platforms
Industry-specific security problem: Heterogeneous mobile hardware
offers varied key custody, trusted execution and firmware controls.
Illustrative technical implementation alignment: Use available secure
key or device evidence where accessible and qualified; application
gateway enforces resource consequence.
Limit and independent-verification qualification: Physical key
security is neither synonymous with user-grant scope nor proof of
final external effect.
12.10. Banking, payments, wallets and financial transaction APIs
Industry-specific security problem: A successful account
authentication can differ from consent to the exact beneficiary,
amount, currency and irreversible transfer.
Illustrative technical implementation alignment: Bind source-approved
payment effect descriptor and verify actual submitted transaction at
payment-resource sink.
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Limit and independent-verification qualification: Settlement may
occur after dispatch and may not support rollback; outcome receipts
and ambiguity handling are separate.
12.11. Telecommunications, 5G/6G, edge devices and IoT
Industry-specific security problem: Cross-domain orchestration
changes routing, subscriber state and edge configuration through
distributed controllers.
Illustrative technical implementation alignment: Translate operator
source scope to current resource policy, use protected edge
controller and resource-specific sink checks.
Limit and independent-verification qualification: Offline partitions
and proprietary hardware impose explicit feasibility limits.
12.12. Robotics, vehicles, industrial automation and connected devices
Industry-specific security problem: Agent commands may trigger
physical acts beyond current safety, owner and device state.
Illustrative technical implementation alignment: Controlled actuator
interface verifies source permission, current epoch, effect class and
physical interlock before committing command.
Limit and independent-verification qualification: Software-only
proxies cannot guarantee physical actuation safety if alternate
actuator controls remain available.
12.13. Samsung Bixby, Amazon Alexa, and Assistant-to-App Handoff Across
Ecosystems
Industry-specific security problem: system and voice assistants,
including Samsung Bixby on Galaxy devices and Amazon Alexa on
connected devices, convert a spoken or typed request into actions in
third-party apps and services; the assistant, the platform action
framework and the receiving service each hold part of the authority,
and injected content read by the assistant can steer the resulting
action.
Illustrative technical implementation alignment: the assistant-
generated action is treated as a Candidate Act; the user request,
invoking assistant, target app and material parameters are bound into
protected evidence; and the receiving app or backend, acting as
Finality Sink, reconstructs the actual pending operation before
effect.
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Limit and independent-verification qualification: third-party
implementers can enforce only at interfaces they control, such as
their own action handlers and server APIs; private assistant or
operating-system internals are not assumed to be available, and a
confirmation dialog protects only if it is bound to the exact final
parameters.
13. Detailed Relevance to IETF Working Groups, RFCs, and Standards
Interoperability
These mappings identify genuine engineering interfaces and
complementarity, not work-group endorsement, chair approval, official
adoption, or a claim that existing RFCs are defective. A security
component may meet its own documented requirements while not
addressing a distinct end-to-end resource-effect semantic. Any
normative use of an RFC would require compatible profiles and a
separately defined interoperability specification. Working-group
charters should be rechecked immediately prior to filing.
13.1. OAuth WG: Rich Authorization, Sender Constraints and Agent
Delegation
Primary references: [RFC6749], [OAUTH-RAR], [OAUTH-DPOP].
Existing work: OAuth work involves delegated access and complex
automated-agent authorization. RFC 9396 Rich Authorization Requests
can convey structured permissions; RFC 9449 DPoP sender-constrains
OAuth tokens, and token exchange is relevant across administrative
domains.
Part 2 relevance, possible interface and distinction: Map source
grant to authorization details, bind operation-specific effect
envelope; DPoP alone should not be described as signing every body
field or proving the actual external effect.
Working-group information: https://datatracker.ietf.org/wg/oauth/
about/ . Relevant existing RFCs or draft families: RFC 9396; RFC
9449; RFC 8693.
13.2. WIMSE WG: Workload Identity in Multi-System Environments
Primary references: [WIMSE-CHARTER].
Existing work: WIMSE addresses workload-to-workload identity,
delegated calls, runtime context and multi-hop HTTP services. It can
carry qualified workload and source lineage to the platform adapter.
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Part 2 relevance, possible interface and distinction: Workload
identity provides evidence of caller/context, while independently
verified actual-operation finality is a separate condition; do not
presume WIMSE tokens replace sink-local consumption.
Working-group information: https://datatracker.ietf.org/wg/wimse/
about/ . Relevant existing RFCs or draft families: WIMSE
architecture; workload identity/HTTP signature drafts.
13.3. RATS WG: Remote Attestation and Evidence Appraisal
Primary references: [RATS].
Existing work: RFC 9334 gives attesters, verifiers, relying parties
and attestation results. Protected device or sandbox evidence may
help establish that the intended adapter or resource enforcement code
is present.
Part 2 relevance, possible interface and distinction: Attestation
describes properties of a platform or component, not necessarily the
exact consented resource effect. Treat it as one bounded predicate
in source/sink validation.
Working-group information: https://datatracker.ietf.org/wg/rats/
about/ . Relevant existing RFCs or draft families: RFC 9334; RATS
evidence/appraisal work.
13.4. COSE WG and CBOR: Signed and Interoperable Protected Objects
Primary references: [COSE], [CBOR].
Existing work: COSE RFC 9052 with CBOR RFC 8949 provides portable
message signing/MAC/encryption and serialization useful for effect-
descriptor commitments and evidence records.
Part 2 relevance, possible interface and distinction: Specify schema,
canonical encoding, signature trust anchors and semantic equality
separately; a valid COSE signature cannot alone prove current
authorization or actual effect.
Working-group information: https://datatracker.ietf.org/wg/cose/
about/ . Relevant existing RFCs or draft families: RFC 9052; RFC
8949.
13.5. ACE WG: Constrained Authorization for Mobile/Embedded Resources
Primary references: [ACE].
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Existing work: ACE framework and profiles address constrained
endpoints and OAuth-related authorization over constrained protocols,
often CoAP/OSCORE.
Part 2 relevance, possible interface and distinction: Bounded
delegated permission and actual actuator/resource effects remain
separate; a constrained Finality Sink must have adequate state and
blocking ability.
Working-group information: https://datatracker.ietf.org/wg/ace/about/
. Relevant existing RFCs or draft families: RFC 9200 ACE-OAuth;
OSCORE profiles.
13.6. SCITT WG: Signed Statements and Transparency for Supply Chain
Context
Primary references: [SCITT-CHARTER].
Existing work: SCITT supports integrity/accountability for signed
software supply-chain statements; signed provenance of approved
enforcement software may contribute evidence when relevant.
Part 2 relevance, possible interface and distinction: Do not treat a
transparency receipt as the receiving-resource actual-effect receipt
or a replacement for local finality state. Supply-chain identity is
a supporting property, not finality itself.
Working-group information: https://datatracker.ietf.org/wg/scitt/
about/ . Relevant existing RFCs or draft families: SCITT architecture
and transparency statements.
13.7. HTTP / HTTPBIS: Request Identity, Conditional Operations and
Redirection
Primary references: [HTTP].
Existing work: RFC 9110 defines HTTP methods, resources, conditional
request handling and redirection semantics that matter to actual
request and target verification.
Part 2 relevance, possible interface and distinction: Capture final
effective URI, authority, method, conditional version/ETag and
committed payload where material; redirects require effect-target
requalification, not only authorized original URL.
Working-group information: https://datatracker.ietf.org/wg/httpbis/
about/ . Relevant existing RFCs or draft families: RFC 9110; RFC
9111; RFC 9112.
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
13.8. Security Area / SEC-DISPATCH and Cross-WG Review
Existing work: New security requirements spanning authorization,
evidence, workload identity, attestation and operation effects may
not belong wholly to one narrowly scoped working group.
Part 2 relevance, possible interface and distinction: Document
bounded interoperability requirements, unresolved registries, trust
and timing assumptions, privacy and DoS; seek technical review
without asserting new WG charter status.
Working-group information:
https://datatracker.ietf.org/wg/secdispatch/about/ . Relevant
existing RFCs or draft families: BCP 79 / RFC 8179; relevant
security-area reviews.
14. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 2: iOS/Android 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.
15. Security, Privacy, Deployment, and IANA Considerations
15.1. Trust Boundaries
The untrusted agent runtime, native app, system permission service,
protected validator, credential broker and actual resource interface
can belong to different administrative principals. An asserted
control is meaningful only for effect paths under the actual control
of the specified protected sink.
15.2. Freshness and Revocation
Evidence freshness, resource-binding epochs, source-authority
revocation and destination ownership must be checked at the point and
strength required by the actual effect. Network partitions can
prevent instant revocation across independently managed resources.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
15.3. Data and Credential Privacy
Canonical effect descriptors and logs may reveal sensitive
recipients, resources and content digests. Minimize exposure,
encrypt relevant records, separate reusable credentials from
untrusted agents, and evaluate traffic analysis or digest-leakage
risks.
15.4. Canonicalization and Ambiguity
Mismatched JSON, CBOR, Unicode, URL normalization, cloud aliases,
filesystem links and effective recipient resolution may produce
equivocation. Define versioned exact comparison rules and fail
closed on ambiguous material differences.
15.5. Crash Consistency and External Effects
Local protected consumption does not imply the remote effect
completed, and a remote effect may complete without a valid
acknowledgment. Describe idempotency capabilities and qualified
outcome evidence before retries or compensation.
15.6. Denial of Service and Availability
An attacker can exploit expensive verification, unavailable
attestation or a partition to withhold benign operations. Define
resource budgets and safe bounded failure policies without allowing
load pressure to silently bypass protected authorization.
15.7. IANA Considerations
This illustrative informational draft does not request new IANA
assignments. If a future interoperability profile defines media
types, registries, protocol elements or errors, that revision must
state the appropriate registration requirements.
16. Source Coverage and Discoverability Cross-Index
Original Cross-Platform Invention: Interoperability, Authority
Continuity and Platform Evidence: global source pages 1-14;
searchable technical detail anchor cross-platform-original-detail;
architecture figure fig-cross-platform-original-arch; operational
figure fig-cross-platform-original-flow. Primary technology areas:
cross-platform permission/effect distinction; real receiving resource
identity; current source authority; fail-closed qualified finality.
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
Miscellaneous Embodiment M-1: Modular Enforcement Coverage and Cross-
Interface Portability: global source pages 555-609; searchable
technical detail anchor misc-m1-detail; architecture figure fig-misc-
m1-arch; operational figure fig-misc-m1-flow. Primary technology
areas: cross-platform permission/effect distinction; real receiving
resource identity; current source authority; fail-closed qualified
finality.
Miscellaneous Embodiment M-2: Standards-Interoperable Platform-
Independent Finality Constitution: global source pages 1898-1952;
searchable technical detail anchor misc-m2-detail; architecture
figure fig-misc-m2-arch; operational figure fig-misc-m2-flow.
Primary technology areas: cross-platform permission/effect
distinction; real receiving resource identity; current source
authority; fail-closed qualified finality.
Embodiment 9: Cross-Device Authority Ownership and Source Fencing:
global source pages 860-925; searchable technical detail anchor
emb9-detail; architecture figure fig-emb9-arch; operational figure
fig-emb9-flow. Primary technology areas: cross-platform permission/
effect distinction; real receiving resource identity; current source
authority; fail-closed qualified finality.
Embodiment 21: Cross-Platform Resource Identity and Alias Resolution:
global source pages 1758-1829; searchable technical detail anchor
emb21-detail; architecture figure fig-emb21-arch; operational figure
fig-emb21-flow. Primary technology areas: cross-platform permission/
effect distinction; real receiving resource identity; current source
authority; fail-closed qualified finality.
Embodiment 27: Cross-Domain Agent Handoff and Non-Resurrectable In-
Flight Effects: global source pages 2246-2317; searchable technical
detail anchor emb27-detail; architecture figure fig-emb27-arch;
operational figure fig-emb27-flow. Primary technology areas: cross-
platform permission/effect distinction; real receiving resource
identity; current source authority; fail-closed qualified finality.
The authoritative complete source remains the 3,567-page Zenodo
technical specification. Source page inclusion in Part 2 does not
itself prove that a distinct claim was present in the 8,598-page PCT/
IB2026/055615 on its filing date. Priority and prior-art effect
require separate original-filing/date examination.
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
17. Cross-Reference Resolution and Submission Notice
The following internal references are included for future inter-
document navigability; their target document slugs remain PLANNED
individual Internet-Draft names and their public Datatracker
availability must be verified separately.
Relevant companion reference: [DAS-FOUNDATION]
Relevant companion reference: [DAS-EVIDENCE]
Relevant companion reference: [DAS-SINK]
Relevant companion reference: [DAS-TOOLS]
Relevant companion reference: [DAS-MIGRATION]
18. Informative References and Planned Companion Documents
[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-EVIDENCE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 3 of 12: Source
authority, protected evidence, independent validation, and
scoped non-bearer enablement", 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, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 4 of 12:
Reconstruction of actual pending operations, sink-local
checks and anti-bypass enforcement", Work in Progress,
Internet-Draft, draft-das-finality-sink-enforcement-00,
<https://datatracker.ietf.org/doc/draft-das-finality-sink-
enforcement/>.
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[DAS-MULTIAGENT]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 5 of 12: Multi-agent
delegation, source lineage, reservations and conflict
arbitration", Work in Progress, Internet-Draft, draft-das-
multi-agent-authority-control-00,
<https://datatracker.ietf.org/doc/draft-das-multi-agent-
authority-control/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 6 of 12: Actual-
effect evidence, dependent phase eligibility and source-
authorized 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, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 7 of 12: Tool
semantics, redirects, resource identity, software and
runtime integrity", Work in Progress, Internet-Draft,
draft-das-agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 8 of 12: Remote
effects, indeterminate outcomes, multi-resource
transactions and bounded recovery", Work in Progress,
Internet-Draft, draft-das-distributed-effect-recovery-00,
<https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/>.
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[DAS-PRIVACY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 9 of 12: Protected
credentials, disclosure control, signing-key use and
privacy release", Work in Progress, Internet-Draft, draft-
das-agent-credential-privacy-00,
<https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/>.
[DAS-MIGRATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 10 of 12: Cross-
device authority migration, ownership epochs, source
fences, revocation and offline conditions", Work in
Progress, Internet-Draft, draft-das-cross-device-
authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 11 of 12:
Kernel/sandbox/hardware enforcement, protected egress and
device commands", Work in Progress, Internet-Draft, draft-
das-hardware-execution-finality-00,
<https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 12 of 12:
Cloud/telecom/critical-resource governance, resource
budgets and protected effect control", 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>.
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[PCT] Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[IPR] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[OAUTH-RAR]
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[OAUTH-DPOP]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RATS] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[ACE] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 2: iOS/Android October 2026
[WIMSE-CHARTER]
Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT-CHARTER]
Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 439]