Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 5: Multi-Agent Delegation, Conflict Arbitration, and Quorum Authority
draft-das-multi-agent-authority-control-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-multi-agent-authority-control-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 5: Multi-Agent Delegation, Conflict Arbitration, and Quorum
Authority
draft-das-multi-agent-authority-control-00
Abstract
Each AI agent can hold a valid permission and the group can still do
something nobody authorized. When Apple Siri hands a task to an app
through App Intents, Google Gemini delegates to Android apps and
cloud agents, or an orchestrator dispatches sub-agents across iOS,
iPadOS, macOS, Android, Windows, Linux, cloud APIs, and connected
devices, authority is copied, narrowed, widened, and combined along
the way. Prompt-injection-driven delegation, confused-deputy
escalation, replayed agent approvals, conflicting writes to the same
resource, duplicated payments, stale reservations, overspent shared
budgets, colluding or non-independent evaluator quorums, and a final
tool call detached from its originating authority are typical
results.
This document, Part 5 of a twelve-part series, specifies multi-agent
control for execution finality. It describes protected arbitration
of conflicting effects across agents using effect footprints and
atomic reservations; cryptographic delegation lineage across
providers with transitive scope attenuation, so that a sub-agent can
never receive more authority than its parent; version-bound
concurrency checks; authenticated quorum membership with operation-
bound approval certificates and separation of duties; budgets
conserved across branches of a delegation tree; revocation that
reaches every descendant; and independent Finality Sink verification
of the actual resource effect. Reference algorithms, ten threat
models, and twenty-four reproducible positive and negative tests,
including an iOS and Android cooperating-receiver case, are included.
Part 1 of the series defines the shared terminology and common
workflows.
The document relates these mechanisms to OAuth 2.0 Rich Authorization
Requests, Resource Indicators, Token Exchange, Demonstrating Proof of
Possession (DPoP), and current security best practice; the Grant
Negotiation and Authorization Protocol (GNAP); Workload Identity in
Multi-System Environments (WIMSE) and its agent-delegation
discussions; Remote ATtestation procedureS (RATS); CBOR Object
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Signing and Encryption (COSE); Supply Chain Integrity, Transparency,
and Trust (SCITT); Authentication and Authorization for Constrained
Environments (ACE); and HTTP conditional requests. These are treated
as qualified inputs rather than final authority, without claiming
working-group adoption or IETF consensus.
Industry alignment covers Apple iOS, iPadOS, and macOS with Siri,
Shortcuts, and App Intents; Google Android with Gemini, Binder, and
intents; Samsung Bixby and Microsoft Copilot; Microsoft Windows and
Azure agent orchestration; agent platforms from OpenAI, Anthropic,
Google Cloud, and Meta; NVIDIA, Qualcomm, Arm, and Huawei hardware;
banking and payments; enterprise SaaS, procurement, and inventory;
robotics; and telecommunications. Product names are illustrative and
imply no endorsement or implementation by any vendor. For the EU
Artificial Intelligence Act (Regulation (EU) 2024/1689), traceable
delegation lineage, bounded authority, and quorum-based approval can
help providers and deployers address human-oversight, record-keeping,
risk-management, and robustness and cybersecurity requirements where
those obligations apply; this is a technical mapping, not a
conformity claim or legal advice.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Table of Contents
1. Introduction: Multi-Agent Security Problem Space and
Twelve-Part Technical Series . . . . . . . . . . . . . . 8
1.1. Complete Twelve-Part Series Directory, Companion Scope and
Cross-Reference Plan . . . . . . . . . . . . . . . . . . 9
1.1.1. Part 1 of 12 — Foundational Definitions, Trust Model
and CW-1/CW-2/CW-3 Common Workflows . . . . . . . . . 9
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and
Cross-Platform AI Tool Interoperability . . . . . . . 10
1.1.3. Part 3 of 12 — Protected Authorization, Cross-Committed
Validation Evidence and Scoped Finality . . . . . . . 10
1.1.4. Part 4 of 12 — Finality Sink Enforcement,
Actual-Operation Reconstruction and Anti-Bypass
Security . . . . . . . . . . . . . . . . . . . . . . 10
1.1.5. Part 5 of 12 — Multi-Agent Security, Delegation,
Conflict Arbitration and Quorum Authority . . . . . . 10
1.1.6. Part 6 of 12 — Verified Actual-Effect Receipts and
Secure Causal Workflow Continuation . . . . . . . . . 11
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity . . . . . . . . . . 11
1.1.8. Part 8 of 12 — Distributed Autonomous Effects,
Multi-Resource Transactions and Recovery . . . . . . 11
1.1.9. Part 9 of 12 — Protected Agent Credential Custody, API
Authorization and Data Privacy . . . . . . . . . . . 11
1.1.10. Part 10 of 12 — Cross-Device Authority Continuity,
Revocation Fencing and Offline Authorization . . . . 12
1.1.11. Part 11 of 12 — Hardware-Assisted, Kernel and Sandbox
Finality Enforcement . . . . . . . . . . . . . . . . 12
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecom and Critical
Infrastructure Resource Security . . . . . . . . . . 12
2. IPR Disclosure Status, Principal PCT Mothership, Zenodo Source
and Planned GitHub Reference . . . . . . . . . . . . . . 12
3. Keywords and Patent Examiner / Industry Engineer Discovery
Terminology . . . . . . . . . . . . . . . . . . . . . . . 13
4. Additional Multi-Agent Terminology and Foundational
Dependencies . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Protected Cross-Agent Effect-Conflict Arbitration
(PCECA) . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Effect footprint . . . . . . . . . . . . . . . . . . . . 14
4.3. Protected conflict reservation . . . . . . . . . . . . . 14
4.4. Delegation authority lineage . . . . . . . . . . . . . . 14
4.5. Effect-semantic attenuation . . . . . . . . . . . . . . . 14
4.6. Protected quorum configuration epoch . . . . . . . . . . 14
4.7. Operation-bound quorum certificate . . . . . . . . . . . 15
4.8. Independent evaluation quorum . . . . . . . . . . . . . . 15
4.9. Branch-conserved authority budget . . . . . . . . . . . . 15
4.10. Sink-local protected consumption . . . . . . . . . . . . 15
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
4.11. Candidate Act / NES / PED / Finality Sink . . . . . . . . 15
5. Multi-Agent Trust Model, Invariants and Actual Resource
Boundary . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Security Invariant 1 . . . . . . . . . . . . . . . . . . 17
5.2. Security Invariant 2 . . . . . . . . . . . . . . . . . . 17
5.3. Security Invariant 3 . . . . . . . . . . . . . . . . . . 17
5.4. Security Invariant 4 . . . . . . . . . . . . . . . . . . 17
5.5. Security Invariant 5 . . . . . . . . . . . . . . . . . . 18
5.6. Security Invariant 6 . . . . . . . . . . . . . . . . . . 18
5.7. Security Invariant 7 . . . . . . . . . . . . . . . . . . 18
5.8. Security Invariant 8 . . . . . . . . . . . . . . . . . . 18
5.9. Security Invariant 9 . . . . . . . . . . . . . . . . . . 18
5.10. Security Invariant 10 . . . . . . . . . . . . . . . . . . 18
5.11. Security Invariant 11 . . . . . . . . . . . . . . . . . . 18
5.12. Security Invariant 12 . . . . . . . . . . . . . . . . . . 18
5.13. Security Invariant 13 . . . . . . . . . . . . . . . . . . 18
5.14. Security Invariant 14 . . . . . . . . . . . . . . . . . . 19
6. PHOSITA Implementation Guidance Using Available Software,
Interfaces and Protected State . . . . . . . . . . . . . 19
6.1. Identify governed effects and explicit deployment
scope . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Agent registration and source grant custody . . . . . . . 19
6.3. Canonical Candidate Act and effect footprint . . . . . . 19
6.4. Delegation graph representation . . . . . . . . . . . . . 19
6.5. Capability and token integration . . . . . . . . . . . . 19
6.6. Conflict footprints and reservation manager . . . . . . . 20
6.7. Database and transactional state . . . . . . . . . . . . 20
6.8. Independent evaluator eligibility and collusion
assumptions . . . . . . . . . . . . . . . . . . . . . . 20
6.9. Approval certificate handling . . . . . . . . . . . . . . 20
6.10. Branch budget accounting . . . . . . . . . . . . . . . . 20
6.11. Resource-side finality sink . . . . . . . . . . . . . . . 20
6.12. Apple iOS/iPadOS integration constraints . . . . . . . . 21
6.13. Android integration constraints . . . . . . . . . . . . . 21
6.14. Cloud, SaaS and containerized agents . . . . . . . . . . 21
6.15. Quorum failure and asynchronous decisions . . . . . . . . 21
6.16. Crash, retry and outcome handling . . . . . . . . . . . . 21
6.17. Development and reproducibility . . . . . . . . . . . . . 21
6.18. Trust, security and feasibility disclosures . . . . . . . 22
7. Reference Interfaces, State Models and Illustrative Algorithms
for Multi-Agent Finality . . . . . . . . . . . . . . . . 22
7.1. Canonical Multi-Agent Candidate Act . . . . . . . . . . . 22
7.2. Effect Footprint and Protected Conflict Reservation . . . 22
7.3. Cross-Provider Delegation Edge . . . . . . . . . . . . . 23
7.4. Transitive Delegation Validation and Budget
Conservation . . . . . . . . . . . . . . . . . . . . . . 23
7.5. Authenticated Quorum Certificate and Membership . . . . . 24
7.6. Independent Evaluation and Shared Input Failure . . . . . 24
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.7. Finality Sink: Joint Validation and Consumption . . . . . 24
7.8. Concurrency Collision and Version-Based Refusal . . . . . 25
7.9. Protected Revocation Across Delegation Descendants . . . 25
7.10. Replay, Retries and Uncertain Effect Outcome . . . . . . 25
8. Detailed Page-Indexed Original Embodiments: Primary Technical
Disclosure . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Embodiment 1: Protected Cross-Agent Effect-Conflict
Arbitration and Atomic Effect Reservations . . . . . . . 26
8.1.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 26
8.1.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 27
8.1.3. Original Global Page-Indexed Technical Description . 28
8.2. Embodiment 7: Cross-Provider Delegation Lineage and
Effect-Semantic Scope Attenuation . . . . . . . . . . . . 85
8.2.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 85
8.2.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 86
8.2.3. Original Global Page-Indexed Technical Description . 86
8.3. Embodiment 11: Concurrent Resource-Version and Semantic
Conflict Finality . . . . . . . . . . . . . . . . . . . . 164
8.3.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 164
8.3.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 165
8.3.3. Original Global Page-Indexed Technical Description . 165
8.4. Embodiment 13: Protected Multi-Agent Quorum Membership and
Operation-Bound Consensus . . . . . . . . . . . . . . . . 240
8.4.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 240
8.4.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 241
8.4.3. Original Global Page-Indexed Technical Description . 241
8.5. Embodiment 28: Nested Multi-Agent Tool Chains and
Branch-Conserved Effect Budgets . . . . . . . . . . . . . 327
8.5.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 327
8.5.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 328
8.5.3. Original Global Page-Indexed Technical Description . 328
8.6. Embodiment 29: Independent Evaluation Quorums and
Conflict-Aware Approval Finality . . . . . . . . . . . . 412
8.6.1. Protected Components and Trust-Relationship
Architecture Diagram . . . . . . . . . . . . . . . . 412
8.6.2. Actual-Operation, Decision and Fail-Closed
Flowchart . . . . . . . . . . . . . . . . . . . . . . 413
8.6.3. Original Global Page-Indexed Technical Description . 413
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
9. Detailed Threat Model: Multi-Agent Attackers, Trust Boundaries
and Residual Risks . . . . . . . . . . . . . . . . . . . 499
9.1. Threat Model 1: Prompt Injection and Agent-to-Agent Command
Laundering . . . . . . . . . . . . . . . . . . . . . . . 499
9.2. Threat Model 2: Confused Deputy and Delegation Scope
Escalation . . . . . . . . . . . . . . . . . . . . . . . 500
9.3. Threat Model 3: Replay of Approval or Quorum
Certificates . . . . . . . . . . . . . . . . . . . . . . 500
9.4. Threat Model 4: Concurrent Effects and Time-of-Check/
Time-of-Use . . . . . . . . . . . . . . . . . . . . . . 500
9.5. Threat Model 5: Sybil, Colluding or Shared-Input Evaluator
Quorum . . . . . . . . . . . . . . . . . . . . . . . . . 501
9.6. Threat Model 6: Conflicting Votes, Veto Suppression and
Policy Epoch Drift . . . . . . . . . . . . . . . . . . . 501
9.7. Threat Model 7: Delegation Graph Cycles and Amplified
Resource Budgets . . . . . . . . . . . . . . . . . . . . 502
9.8. Threat Model 8: Forged Effect Footprint, Resource Rebinding
and Canonicalization . . . . . . . . . . . . . . . . . . 502
9.9. Threat Model 9: Revocation During Asynchronous Quorum and
Chain Execution . . . . . . . . . . . . . . . . . . . . 502
9.10. Threat Model 10: Compromised Infrastructure and
Verification Exhaustion . . . . . . . . . . . . . . . . 503
10. Reproducible Reference Validation Plan: Twenty-Four Proposed
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 503
10.1. MA01 — Basic independently authorized single agent . . . 503
10.2. MA02 — Conflicting authorized concurrent writes . . . . 504
10.3. MA03 — Concurrent non-conflicting operations . . . . . . 504
10.4. MA04 — Conflicting cross-resource semantic effects . . . 505
10.5. MA05 — Stale resource-version reservation . . . . . . . 505
10.6. MA06 — Delegation increases effect scope . . . . . . . . 506
10.7. MA07 — Authenticated narrowed delegation . . . . . . . . 506
10.8. MA08 — Delegation graph cycle and forged parent . . . . 506
10.9. MA09 — Cross-provider receiving resource mismatch . . . 507
10.10. MA10 — Revocation between delegation and dispatch . . . 507
10.11. MA11 — Branch-conserved budget overspend . . . . . . . . 508
10.12. MA12 — Intermediate tool causes undeclared effect . . . 508
10.13. MA13 — Valid role-qualified quorum certificate . . . . . 508
10.14. MA14 — Quorum mixed-candidate signatures . . . . . . . . 509
10.15. MA15 — Stale membership epoch . . . . . . . . . . . . . 509
10.16. MA16 — Mandatory veto despite majority . . . . . . . . . 510
10.17. MA17 — Sybil quorum identities . . . . . . . . . . . . . 510
10.18. MA18 — Shared poisoned evaluator evidence . . . . . . . 510
10.19. MA19 — Replayed quorum certificate . . . . . . . . . . . 511
10.20. MA20 — Actual operation altered post-vote . . . . . . . 511
10.21. MA21 — Unreachable mandatory validator . . . . . . . . . 512
10.22. MA22 — Partition with incompatible reservations . . . . 512
10.23. MA23 — Crash between consumption and receiver
acknowledgement . . . . . . . . . . . . . . . . . . . . 512
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
10.24. MA24 — iOS/Android cooperating receiver integration . . 513
11. Detailed Industry and Product Alignment: Multi-Agent Security
Problems and Integration Boundaries . . . . . . . . . . . 513
11.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents . . . 514
11.2. Apple macOS, Desktop AI Agents and App Sandboxing . . . 514
11.3. Google Android, Gemini, Binder and Intents . . . . . . . 514
11.4. Microsoft Windows, Azure and Agent Orchestration . . . . 514
11.5. OpenAI Agents SDK, Responses API, Codex and Tool
Calling . . . . . . . . . . . . . . . . . . . . . . . . 515
11.6. Anthropic Claude, Claude Code and Managed Agents . . . . 515
11.7. Google Cloud Agent Platforms and Enterprise APIs . . . . 515
11.8. Meta Muse/Sentinel and Isolated Agent Security . . . . . 516
11.9. NVIDIA OpenShell, BlueField, Sentry and Accelerator
Security . . . . . . . . . . . . . . . . . . . . . . . 516
11.10. Qualcomm Snapdragon, Arm and Trusted Device
Controllers . . . . . . . . . . . . . . . . . . . . . . 516
11.11. Huawei Mobile Platforms and Telecommunications
Devices . . . . . . . . . . . . . . . . . . . . . . . . 516
11.12. Financial Institutions, Payments and Banking
Automation . . . . . . . . . . . . . . . . . . . . . . 517
11.13. Enterprise SaaS, CRM, ERP, Procurement and
Inventories . . . . . . . . . . . . . . . . . . . . . . 517
11.14. Robotics, Industrial Controllers and Physical Safety . . 517
11.15. Telecommunications, Network Management and Edge
Computing . . . . . . . . . . . . . . . . . . . . . . . 517
11.16. Voice and System Assistants as Delegating Agents: Apple
Siri, Google Gemini, Samsung Bixby, Microsoft Copilot, and
Amazon Alexa . . . . . . . . . . . . . . . . . . . . . 518
12. Detailed IETF Working-Group, RFC and Internet-Draft Relevance
for Agent Delegation and Quorums . . . . . . . . . . . . 518
12.1. OAuth 2.0: Rich Authorization, Resource Indicators, Token
Exchange and DPoP . . . . . . . . . . . . . . . . . . . 518
12.2. WIMSE: Workload Identity and Agent Delegation
Discussions . . . . . . . . . . . . . . . . . . . . . . 519
12.3. GNAP Specifications: Fine-Grained Grant Negotiation . . 519
12.4. COSE and CBOR: Authenticated Delegation and Quorum
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 520
12.5. RATS: Evidence, Verifiers and Trust Assessment . . . . . 520
12.6. SCITT: Signed Statements and Transparent Provenance . . 521
12.7. ACE: Authorization for Constrained Environments . . . . 521
12.8. HTTPBIS: Conditional Requests and Resource Version
Semantics . . . . . . . . . . . . . . . . . . . . . . . 521
12.9. SEC-DISPATCH and Security Area: Cross-Working-Group
Problem Framing . . . . . . . . . . . . . . . . . . . . 522
13. Relevance to the EU Artificial Intelligence Act . . . . . . . 522
14. Security, Privacy, Robustness, Availability and Deployment
Considerations . . . . . . . . . . . . . . . . . . . . . 523
14.1. Quorum membership and operator collusion . . . . . . . . 523
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
14.2. Operation integrity and semantic canonicalization . . . 524
14.3. Propagation and revocation freshness . . . . . . . . . . 524
14.4. Conflict reservation integrity and crash consistency . . 524
14.5. Privacy of delegation/approval chains . . . . . . . . . 524
14.6. Verification exhaustion and denial of service . . . . . 524
14.7. Separate source authority from token validity . . . . . 524
14.8. Physical and remote effect limits . . . . . . . . . . . 524
14.9. Test reporting and non-standard status . . . . . . . . . 524
15. Source Traceability, Examiner Discovery and Figure Location
Index . . . . . . . . . . . . . . . . . . . . . . . . . . 525
16. Explicit Cross-References to Part 1 and the Eleven Companion
Drafts . . . . . . . . . . . . . . . . . . . . . . . . . 526
17. Informative References . . . . . . . . . . . . . . . . . . . 526
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 530
1. Introduction: Multi-Agent Security Problem Space and Twelve-Part
Technical Series
An agent can have valid permission to change a database record while
another valid agent independently changes the same record, creating
an unauthorized combined consequence. An apparently independent set
of AI evaluators may in fact be controlled by one compromised service
or influenced by the same poisoned retrieved material. A delegated
tool can retain legitimate computing capability after its originating
authority has narrowed or expired. Consequently, tool access,
approved subtask, workload authentication, voting and consensus are
not by themselves sufficient proofs of current authority to produce a
particular external effect.
This Part 5 addresses six complementary mechanisms in the underlying
technical disclosure: (i) protected cross-agent effect-conflict
arbitration (Embodiment 1), (ii) cross-provider delegated authority
and attenuation (Embodiment 7), (iii) version-bound concurrent-effect
reservations (Embodiment 11), (iv) operation-bound authenticated
quorums (Embodiment 13), (v) transitive delegation and branch budget
conservation across nested tool chains (Embodiment 28), and (vi)
independent evaluator and consensus authorization with conflict-aware
veto semantics (Embodiment 29). A coherent implementation may select
compatible modules without imposing every optional mechanism on every
operation.
The main security requirement is that distinct protections remain
distinct: authentication identifies a participant; delegation may
convey bounded authority; a quorum may establish that eligible
members approved a canonical proposal; a conflict reservation may
establish current compatibility; and a Finality Sink determines
whether the actual pending effect can be released under current
source authority, evidence, applicable resource state and sink-local
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
consumption. Each property must be established at the right
boundary. A successful predecessor operation, or an apparently valid
majority, does not automatically authorize a different recipient,
amount, resource, or device command.
The intended readership includes patent examiners, operating-system
engineers, Apple iOS and Android app/security developers, cloud and
SaaS agent developers, enterprise authorization designers, financial
transaction engineers and security reviewers. Discoverability and
faithful public technical disclosure, rather than an assertion of
IETF standards adoption, are the primary goals. Source passages are
distinguished from separately authored non-normative reference
algorithms and proposed tests.
This document references the full public 3,567-page technical
specification while including page-indexed primary source text for
the six selected embodiments. Each selected embodiment receives its
own protected architecture diagram and operational decision
flowchart. Any new interpretations, formats, laboratory assertions
and diagrams in this edition require comparison with the as-filed
patent records before any claim of earlier priority.
1.1. Complete Twelve-Part Series Directory, Companion Scope and Cross-
Reference Plan
The following are planned individual Internet-Draft identifiers.
Their URLs are reference patterns, NOT assertions that each document
has been registered or published by IETF Datatracker. Part 1 is the
authoritative terminological foundation; each other part maintains a
unique technical focus and cross-references companion mechanisms.
1.1.1. Part 1 of 12 — Foundational Definitions, Trust Model and CW-1/
CW-2/CW-3 Common Workflows
Identifier: draft-das-interoperable-consequence-authority; proposed
future Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
interoperable-consequence-authority/ .
FOUNDATIONAL: defines Candidate Act (CA), Non-Effective State (NES),
Protected Enforcement Domain (PED), protected validation evidence,
scoped non-bearer finality enablement, Finality Sink, and CW-1/CW-2/
CW-3.
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and Cross-Platform AI
Tool Interoperability
Identifier: draft-das-cross-platform-ai-interoperability; proposed
future Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
cross-platform-ai-interoperability/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.3. Part 3 of 12 — Protected Authorization, Cross-Committed
Validation Evidence and Scoped Finality
Identifier: draft-das-protected-authority-evidence; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
protected-authority-evidence/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.4. Part 4 of 12 — Finality Sink Enforcement, Actual-Operation
Reconstruction and Anti-Bypass Security
Identifier: draft-das-finality-sink-enforcement; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-finality-
sink-enforcement/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.5. Part 5 of 12 — Multi-Agent Security, Delegation, Conflict
Arbitration and Quorum Authority
Identifier: draft-das-multi-agent-authority-control; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-multi-
agent-authority-control/ .
THIS PART: multi-agent conflicts, trusted delegation graphs,
protected resource reservations, quorum integrity, independent
decision participants and actual-effect finality.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.1.6. Part 6 of 12 — Verified Actual-Effect Receipts and Secure Causal
Workflow Continuation
Identifier: draft-das-causal-effect-receipts; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-causal-
effect-receipts/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity
Identifier: draft-das-agent-tool-integrity; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-agent-
tool-integrity/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.8. Part 8 of 12 — Distributed Autonomous Effects, Multi-Resource
Transactions and Recovery
Identifier: draft-das-distributed-effect-recovery; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
distributed-effect-recovery/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.9. Part 9 of 12 — Protected Agent Credential Custody, API
Authorization and Data Privacy
Identifier: draft-das-agent-credential-privacy; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.1.10. Part 10 of 12 — Cross-Device Authority Continuity, Revocation
Fencing and Offline Authorization
Identifier: draft-das-cross-device-authority-revocation; proposed
future Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
cross-device-authority-revocation/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.11. Part 11 of 12 — Hardware-Assisted, Kernel and Sandbox Finality
Enforcement
Identifier: draft-das-hardware-execution-finality; proposed future
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecom and Critical
Infrastructure Resource Security
Identifier: draft-das-autonomous-infrastructure-finality; proposed
future Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
autonomous-infrastructure-finality/ .
Companion relation: Part 5 uses this part when the relevant source-
protected interdependence arises; a reference does not import every
optional implementation feature.
2. IPR Disclosure Status, Principal PCT Mothership, Zenodo Source and
Planned GitHub Reference
Principal project PCT technical disclosure: PCT/IB2026/055615, filed
4 June 2026 (reported length: 8,598 pages), published as WO
2026/150382 [PCT-055615]. The earlier PCT/IB2025/058316 is a
separate application, not the 8,598-page June 2026 principal
disclosure. This Part 5 and its examples must not be presumed
identical to the June filing without an as-filed comparison.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Public source for this twelve-part series: "iOS and Android
Interoperability for Secure Third Party AI Tools - Cross-Platform
Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Zenodo record https://zenodo.org/
records/23657985, DOI 10.5281/zenodo.23657985 [ZENODO]. The source
underlies the detailed numbered embodiments reproduced as page-
indexed technical text in this part.
Detailed relevant IETF IPR disclosures, including verified patent
application numbers, priority relationships, potentially relevant
claims and applicable licensing declarations, will be submitted or
updated separately through the formal IETF IPR disclosure process.
This paragraph is NOT itself the formal BCP 79 disclosure and does
not postpone any applicable timely disclosure duties under [RFC8179].
A GitHub implementation reference, deterministic test fixtures,
sample delegation graphs, quorum membership configurations, protected
reservation store and executable negative test harness are intended
to be added in a subsequent revision. No repository URL, successful
test run or implementation completion is asserted here. Additional
later Indian/PCT filings will be identified in verified IPR
declarations rather than guessed in this technical document.
The source publication date, distinct Internet-Draft submission
dates, patent filing dates, and the first public disclosure dates of
subsequently written figures, test plans and algorithms are separate
facts. Publication alone does not guarantee legal prior-art effect
for every passage or any particular filing date.
3. Keywords and Patent Examiner / Industry Engineer Discovery
Terminology
AI agent security; multi-agent systems; Apple iOS AI assistants;
Android autonomous agents; cross-application authorization; delegated
AI tools; cross-provider agent handoff; agent tool calling; agent-to-
agent delegation; A2A; agent orchestration; confused deputy; prompt
injection; authorization escalation; execution-finality; protected
source authority; Candidate Act; Non-Effective State; Protected
Enforcement Domain; Finality Sink; effect-footprint conflict; atomic
reservations; concurrent resource version; stale ETag; multiple agent
approvals; quorum authentication; quorum certificate; byzantine fault
tolerance; independent evaluators; separation of duties; collusion;
threshold signature; scope attenuation; delegation chain; nested
agent delegation; revocation; resource identity; replay resistance;
branch-conserved budget; capability security; OAuth 2.0; OAuth token
exchange; Rich Authorization Requests; WIMSE; GNAP; RATS; SCITT;
COSE; CBOR; enterprise AI infrastructure; cloud API authorization;
payment security; robotics; telecommunications; secure automation;
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
hardware security.
Terms in this index describe actual technical subjects, potential
deployment environments, or verified existing standards; they are not
certifications that any named commercial platform currently
implements the proposed mechanisms.
4. Additional Multi-Agent Terminology and Foundational Dependencies
4.1. Protected Cross-Agent Effect-Conflict Arbitration (PCECA)
Protected analysis and enforcement of the effect interference between
individually authorized Candidate Acts, rather than only local
identity or tool permission.
4.2. Effect footprint
Machine-verifiable description of the resource set, operation class,
parameters, state dependencies and potential external consequences of
a Candidate Act.
4.3. Protected conflict reservation
Operation-bound protected allocation or synchronization state
qualifying whether a proposed effect may coexist with other currently
reserved or actual effects.
4.4. Delegation authority lineage
Authenticated provenance of the original authority grant and each
bounded delegation transition across agents, provider domains or
tools.
4.5. Effect-semantic attenuation
Restriction of delegated authority to a permitted subset of original
consequential operation semantics; successful task handoff does not
enlarge grant scope.
4.6. Protected quorum configuration epoch
Authenticated membership and role generation determining which
approvals count for an operation-specific quorum decision.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
4.7. Operation-bound quorum certificate
Evidence that a valid threshold of eligible decision participants
approved the same canonical Candidate Act and correct authority
generation.
4.8. Independent evaluation quorum
Set of appropriately qualified, distinct evaluation actors whose
outputs are checked under independence/separation-of-duties
conditions.
4.9. Branch-conserved authority budget
Protected invariant that delegated branches cannot collectively spend
more consequential authority or resource quota than the available
root grant.
4.10. Sink-local protected consumption
Atomic or otherwise protected record by which a resource Finality
Sink prevents replay or duplicate use of scoped finality authority.
4.11. Candidate Act / NES / PED / Finality Sink
The foundational types and trust-boundary semantics are defined in
Part 1 and are intentionally not redefined inconsistently here.
5. Multi-Agent Trust Model, Invariants and Actual Resource Boundary
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[Human or competent source principal]
|
[Bounded source authority]
|
[Root CA / NES]
|
[Protected delegation DAG]-----[Revocation / budgets]
| | |
[Agent A] [Agent B] [Nested tools] |
| | | |
[Proposed operation footprints]---+
|
[Independent protected PED]
| | |
[Conflict/locks] [Quorum] [Current source]
+-----------+----------+
|
[Scoped finality enablement]
|
[Finality Sink: actual effect]
|
[Version + scope + consume]
/ \
[Release effect] [Withhold]
Figure 1: Part 5 Common Agent Delegation, Conflict and Finality
Architecture
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[Agent/tool proposes consequential operation]
|
[Construct CA]
|
[Hold in NES]
|
<Source lineage & attenuated scope valid?>--NO-->[REFUSE]
|YES
<Quorum needed: current and independent?>--NO-->[REFUSE]
|YES
<No outstanding forbidden conflict?>----NO-->[WAIT/FENCE]
|YES
<Reservation/version/budget current?>--NO-->[REVALIDATE]
|YES
[Sink observes/reconstructs actual operation]
|
<Exact effect + revocation + finality match?>--NO-->[REFUSE]
|YES
[Atomic sink-local consumption]
|
[Release governed effect]
Figure 2: Part 5 Cross-Agent Actual-Effect Decision Path
5.1. Security Invariant 1
Every governed consequential operation is represented as its own
Candidate Act and remains non-effective pending applicable authority
and sink checks.
5.2. Security Invariant 2
Two individually authorized acts do not become jointly compatible
merely because their source grants are individually valid.
5.3. Security Invariant 3
Conflict arbitration and operation-specific source authorization are
separate predicates; neither substitutes for the other.
5.4. Security Invariant 4
Delegated authority never expands merely through a new agent, new
provider, tool hop or a more privileged execution domain.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
5.5. Security Invariant 5
Delegation lineage is authenticated and tied to the actual
permissible effect, receiver, delegation generation and revocation
state.
5.6. Security Invariant 6
Parallel branches do not create extra authority or duplicate resource
budget; shared consumable state is coordinated protectively.
5.7. Security Invariant 7
Quorum certificates bind to the same operation-specific semantics and
current eligible participant set, not a mutable high-level intent.
5.8. Security Invariant 8
An evaluator controlled by the same principal or dependence source
may not automatically count as an independent approval.
5.9. Security Invariant 9
Veto and conflict resolution must follow authenticated policy and
cannot be overridden by an unrelated majority.
5.10. Security Invariant 10
An actual Finality Sink independently reconstructs the pending effect
and verifies protected evidence, scoped enablement, current resource
versions, quorum/reservation conditions and sink-local state.
5.11. Security Invariant 11
Permission to schedule, propose, compute or approve does not
independently authorize the final consequential effect.
5.12. Security Invariant 12
Rollback, stale quorum epochs, revoked delegated authority or
exhausted reservations cause withholding under mandatory predicates.
5.13. Security Invariant 13
On missing mandatory protected evidence, ambiguous semantic
equivalence, timeouts or unavailable current revocation, the covered
effect remains withheld according to its approved failure policy.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
5.14. Security Invariant 14
No system can promise control of a remote or alternate effect
interface that its qualified Finality Sink cannot actually prevent.
6. PHOSITA Implementation Guidance Using Available Software, Interfaces
and Protected State
6.1. Identify governed effects and explicit deployment scope
Select effects for which an independently administered resource can
refuse execution: e.g., an enterprise API mutation, inventory debit,
protected file export or credentialed payment. Map all paths that
can reach that effect. Mark third-party apps or operating-system
paths beyond control explicitly; no universal kernel interception is
implied.
6.2. Agent registration and source grant custody
Give each agent a stable workload identity while separately
maintaining the authorizing principal and specific operation grant.
Use protected service-to-service channels, separate credential
custody, authenticating providers and per-resource policy. Root task
context should not be confused with unrestricted privilege.
6.3. Canonical Candidate Act and effect footprint
Represent the actual recipient, resource identity, operation, amount
or payload commitment, version predicate, authority-root identifier,
delegation graph and expected side effect. Define deterministic
canonicalization and reject ambiguous resource aliases.
6.4. Delegation graph representation
Maintain signed or MAC-protected edges binding delegator, delegate,
issuer, audience, allowed effects, validity interval, source root,
role, revocation generation and affected quotas. Evaluate complete
chains and cycles under explicit policy. Do not equate cryptographic
delegation verification with authorization of all future effects.
6.5. Capability and token integration
Use existing OAuth 2.0 RAR (RFC 9396), resource indicators (RFC
8707), token exchange (RFC 8693) and DPoP (RFC 9449) where they fit.
The finality reference is not merely a bearer token; receiving
resource validation remains mandatory. Alternative non-OAuth
mechanisms are possible.
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
6.6. Conflict footprints and reservation manager
Use resource IDs, effect classes, expected versions, available
balances, accounting quotas and semantic conflicts to build a
protected compatibility graph. Under an appropriate isolation level,
reserve or fence mutually exclusive effects and bind the reservation
to the exact pending act and current resource version.
6.7. Database and transactional state
A transactional SQL database with unique operation IDs, serializable
reservations and conditional compare-and-swap updates can prototype
sink consumption. For distributed resources, provide explicit
authoritative ownership or partition-safe lease rules; do not claim
universal cross-provider atomicity.
6.8. Independent evaluator eligibility and collusion assumptions
Provide authenticated participant membership, immutable role
assignments, current quorum epoch and policy rules for independent
decision sources. Check that a threshold signature proves threshold
participation only; its signers do not automatically prove
independence of reasoning or substantive correctness.
6.9. Approval certificate handling
An approval certificate should commit to canonical act hash,
authorized resource class, recipient, effect envelope, participant
membership epoch, eligible roles, threshold, veto state, source grant
and expiration. Any material operation change requires appropriate
renewed approval.
6.10. Branch budget accounting
Track delegation root, branch lineage, cumulative spend and
outstanding reservations. Use an authoritative ledger or strongly
coordinated partition-specific allocations so branches do not
multiply quota through concurrent execution.
6.11. Resource-side finality sink
At the last preventable effectuation interface, reconstruct the
actual queued operation from trusted resource-side fields, verify
binding to authority root, delegated scope, accepted quorum, conflict
reservation and protected local consumption; then atomically consume
as appropriate before releasing the effect.
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
6.12. Apple iOS/iPadOS integration constraints
Use publicly supported app-to-service interfaces, App Intents,
authorized app extensions, app-specific Keychain/Secure Enclave
functions where available and cooperating destination services. An
ordinary third-party app cannot enforce every other app activity or
intercept arbitrary privileged system operations.
6.13. Android integration constraints
Use Android intent receivers, Binder identity/permissions, Keystore,
app-specific services and protected destination gateways. System-
wide mediation, private drivers or OEM permission services require
corresponding privilege and cooperation; do not assume access for
normal third-party apps.
6.14. Cloud, SaaS and containerized agents
Host validators, authority registries and policy stores outside
lower-trust containers. Terminate privileged tool calls in a
mandatory broker/resource server and separate trace logs from
effective authority. Enforce service credential use only after
operation-level verification.
6.15. Quorum failure and asynchronous decisions
Define explicit states for PROPOSED, PENDING, QUORUM_READY, RESERVED,
RELEASED, REFUSED, REVOKED and INDETERMINATE. Partial voting or
network partitions must not produce a fail-open effect, and no quorum
result substitutes for final receiving resource checks.
6.16. Crash, retry and outcome handling
Preserve durable protected spend/reservation and operation identity;
distinguish successful dispatch from independently confirmed remote
completion. After uncertain outcome, reconcile rather than blindly
retrying or restoring spent authority.
6.17. Development and reproducibility
Publish source version, fixtures, deterministic identity and key
material (test-only), validated schema, policy examples, emitted
protected logs, source-page mapping and failing/positive test
observations after actual execution. Sensitive keys and private user
data must never appear in public fixtures.
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
6.18. Trust, security and feasibility disclosures
List attacker and administrator capabilities, compromised keys,
shared evaluator failure modes, external uncontrolled resources,
timing requirements, and recovery limits. A competent engineer can
implement a cooperating gateway prototype without falsely claiming
universal enforcement inside every mobile operating system.
7. Reference Interfaces, State Models and Illustrative Algorithms for
Multi-Agent Finality
The following schemas and pseudocode are newly authored, non-
normative reference designs to assist a person having ordinary skill
in the art. They must not be represented as verbatim text from the
June 4, 2026 PCT, a formal registered protocol, or successful
implementation results. Deployments must select serialization,
cryptographic profiles, transaction semantics and trust boundaries
explicitly.
7.1. Canonical Multi-Agent Candidate Act
CandidateAct = {
version, ca_id, authority_root, requesting_agent,
source_principal, effect_class, resource_id,
recipient, method, parameters_commitment,
protected_source_grant, delegation_graph_hash,
quorum_policy_id, quorum_epoch, conflict_footprint,
resource_version, branch_budget_id,
designated_sink, revocation_generation, expires_at
}
STATE: PROPOSED -> NES -> VALIDATED -> [RESERVED] ->
CONSUMED -> EFFECT; any failed predicate -> WITHHELD
Figure 3: Canonical Multi-Agent Candidate Act — illustrative
reference structure
7.2. Effect Footprint and Protected Conflict Reservation
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
EffectFootprint = {
resource_keys[], semantic_write_set[],
read_versions[], exclusive_effect_classes[],
shared_budget_keys[], expected_outcome_predicates[]
}
reserve(act):
require current_source_grant(act)
require no_incompatible_committed_or_reserved_effect(act)
require atomic_compare_versions(act.resource_versions)
token = transactional_reserve(act.id, fingerprint(act))
return protected_bind(token, act.id, sink_id, epoch)
ON conflict_or_stale_resource: WITHHOLD_OR_REVALIDATE
Figure 4: Effect Footprint and Protected Conflict Reservation —
illustrative reference structure
7.3. Cross-Provider Delegation Edge
DelegationEdge = {
edge_id, root_grant_id, delegator, delegate,
delegator_domain, delegate_domain, audience,
source_scope, attenuated_effect_scope,
bounds, parent_edge_commitment,
revocation_generation, expiration,
authenticated_issuer_proof
}
validate_edge(e,parent):
require authentic(e) and parent_current(parent)
require e.attenuated_effect_scope subset_of parent.effect_scope
require e.issuer == parent.current_delegate
return current_revocation(e)
Figure 5: Cross-Provider Delegation Edge — illustrative reference
structure
7.4. Transitive Delegation Validation and Budget Conservation
validate_chain(candidate, edges, ledger):
scope = root_grant(candidate.authority_root).effect_scope
for e in verified_acyclic_path(edges):
require valid_source_relation(e) and current(e)
scope = intersection(scope, e.attenuated_effect_scope)
require candidate.actual_effect subset_of scope
require ledger.total_reserved_and_spent(root) <= root.limit
return authorized_scope(scope)
ON cycle, invalid lineage or over-budget: REFUSE
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Figure 6: Transitive Delegation Validation and Budget Conservation —
illustrative reference structure
7.5. Authenticated Quorum Certificate and Membership
QuorumCertificate = {
candidate_digest, quorum_policy_id, membership_epoch,
voters[], roles[], independent_group_identifiers[],
threshold_rule, veto_state, decision_digest,
source_authority_generation, expiry, signature_evidence
}
verify_quorum(q,candidate):
require digest(candidate) == q.candidate_digest
require q.membership_epoch == protected_current_epoch()
require distinct_and_eligible(q.voters,q.roles)
require separation_of_duties(q) and threshold_satisfied(q)
require mandatory_veto_state_valid(q)
return ACCEPTED
Figure 7: Authenticated Quorum Certificate and Membership —
illustrative reference structure
7.6. Independent Evaluation and Shared Input Failure
evaluate_independence(votes,policy):
for evaluator in votes:
require authenticated_evaluator_identity(evaluator)
require eligible_role_and_current_membership(evaluator)
record provenance and declared dependencies
require independence_policy_satisfied(votes)
require no_forbidden_conflict_or_veto(votes,policy)
if same_shared_poisoned_input and policy_requires_independence:
require additional independent evidence source
return QUALIFIED_QUORUM_OR_WITHHOLD
Figure 8: Independent Evaluation and Shared Input Failure —
illustrative reference structure
7.7. Finality Sink: Joint Validation and Consumption
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
finality_sink_verify(actual_pending,sink):
act = sink.read_or_reconstruct(actual_pending)
ca = protected_lookup_matching_CA(act)
require ca.in_NES and current_source_authority(ca)
require validated_delegation_lineage(ca)
require current_quorum_when_required(ca)
require current_conflict_reservation(ca,act)
require exact_effect_and_resource_version_match(ca,act)
require budget_available_and_revocation_current(ca)
require current_scoped_nonbearer_enablement(ca,sink)
atomically_consume_sink_local_once(ca.id,sink.id)
return PERMIT_ONLY_ACTUAL_EFFECT
ON any_failure: WITHHOLD
Figure 9: Finality Sink: Joint Validation and Consumption —
illustrative reference structure
7.8. Concurrency Collision and Version-Based Refusal
agent_A: reserve(write account X at version 17)
agent_B: reserve(write account X at version 17)
atomic conflict/version arbitration:
if A accepted and changes version to 18:
B cannot execute under stale version 17
elif B accepted first:
A cannot execute under stale version 17
always validate actual resource state at sink
NO assumption of global atomicity across unrelated services
Figure 10: Concurrency Collision and Version-Based Refusal —
illustrative reference structure
7.9. Protected Revocation Across Delegation Descendants
revoke(root_or_edge, new_generation):
authenticate_authorized_revocation()
protected_commit_monotonic_revocation_generation()
discover_affected_descendant_edges_and_candidate_acts()
invalidate_unspent_effect_enablings()
propagate or require current revocation lookup at sink
if fresh predicate cannot be satisfied: WITHHOLD
DO NOT claim completed remote effects are undone
Figure 11: Protected Revocation Across Delegation Descendants —
illustrative reference structure
7.10. Replay, Retries and Uncertain Effect Outcome
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
on_timeout(operation):
state = protected_sink_consumption_lookup(operation.id)
if state == CONSUMED_OR_INDETERMINATE:
seek_receiver_qualified_effect_evidence()
do_not_blindly_reissue_as_new_authorized_effect()
if genuine fresh source authority and receiver idempotency:
construct_separately_qualified retry Candidate Act
else:
WITHHOLD and escalate for authorized reconciliation
Figure 12: Replay, Retries and Uncertain Effect Outcome —
illustrative reference structure
8. Detailed Page-Indexed Original Embodiments: Primary Technical
Disclosure
Each following unit contains substantial text extracted from the
specific original pages of the supplied 3,567-page PDF, a source-
page-to-section anchor, and a separately authored architecture
diagram and decision flowchart. These extracts may include
typographic ligature artifacts of PDF text extraction; the full
original Zenodo PDF remains authoritative. Text from other
embodiments is not silently recharacterized as Part 5 source. The
diagrams do not assert that later drawing details existed verbatim in
the earlier PCT filing.
8.1. Embodiment 1: Protected Cross-Agent Effect-Conflict Arbitration
and Atomic Effect Reservations
Original specification global pages 248-294 (inclusive). Source
file: TECHNICAL SPECIFICATION -1-554.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.1.1. Protected Components and Trust-Relationship Architecture Diagram
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[Independently authorized Agents A / B / C]
|
[Distinct Candidate Acts]
|
[Authenticated effect footprints]
|
[Protected conflict compatibility graph]
|
[Atomic resource reservations]
|
[Source authority + scoped finality]
|
[Actual-operation reconstructing Finality Sink]
|
[Consume reservation / permit effect]
Figure 13: Embodiment 1: Protected Cross-Agent Effect-Conflict
Arbitration and Atomic Effect Reservations — source-based
architecture
8.1.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Two agents propose competing effects]
|
<Individual authority valid?>--NO-->[WITHHOLD]
|YES
[Compare verified effect footprints]
|
<Mutually compatible effects?>--NO-->[FENCE / SERIALIZE]
|YES
[Create protected reservation]
|
<Reservation and versions still current?>--NO-->[REVALIDATE]
|YES
[Sink reconstructs actual effect]
|
<Exact scope, conflict and state match?>--NO-->[REFUSE]
|YES
[Consume and release effect]
Figure 14: Embodiment 1: Protected Cross-Agent Effect-Conflict
Arbitration and Atomic Effect Reservations — technical flowchart
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.1.3. Original Global Page-Indexed Technical Description
8.1.3.1. Source page 248 of the original specification
END OF SUPPLEMENTARY TECHNICAL DISCLOSURE CW-IMP-1.
EMBODIMENT 1
PROTECTED CROSS-AGENT EFFECT-CONFLICT ARBITRATION WITH ATOMIC EFFECT
RESERVATIONS, CROSS-DOMAIN OPERATION CORRESPONDENCE, SINK-BOUND
FENCING, AND INDEPENDENT CONSEQUENCE-STATE RECONCILIATION
1.0 — TITLE AND GENERAL CHARACTERIZATION
Systems and Methods for Protected Cross-Agent Effect-Conflict
Arbitration Using Independently Verified Operation Footprints, Atomic
Effect Reservations, Sink-Bound Execution Fencing, and Consequence-
Aware State Reconciliation Across Heterogeneous Autonomous Computing
Domains
1.0.1 — Nature of the Embodiment
The present embodiment discloses systems, methods, apparatus,
protected execution components, cryptographic authorization
structures, state-transition mechanisms, and computer-executable
procedures for governing interactions among multiple independently
operating computational entities whose proposed actions may
individually possess valid execution authority but may produce
mutually incompatible, inconsistent, duplicative, or otherwise
impermissible combined consequences.
The computational entities may comprise autonomous artificial-
intelligence agents, on-device assistants, application agents,
operating-system services, cloud-hosted agents, robotic controllers,
enterprise automation components, delegated tools, distributed
workflow participants, or other effect-capable computing processes.
In one non-limiting implementation, a Protected Cross-Agent Effect-
Conflict Arbitration mechanism, hereinafter also referred to as
PCECA, determines whether multiple Candidate Acts may become
consequentially effective under a protected set of shared-resource,
dependency, authority, and effect-interference constraints.
The mechanism operates independently of the subjective reasoning,
planning, or approval assertions produced by the participating
agents.
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The present embodiment is based on the recognition that separately
valid authorizations do not necessarily compose into a valid joint
execution.
More particularly, two or more Candidate Acts may each satisfy
individual identity, scope, purpose, destination, and authorization
predicates while nevertheless producing an impermissible combined
state when executed concurrently or in a particular order.
The proposed architecture introduces a protected effect-interference
evaluation and reservation mechanism that binds an operation's
concurrency authorization to the actual consequential operation
presented at an applicable Finality Sink.
8.1.3.2. Source page 249 of the original specification
The architecture may employ the Protected Enforcement Domain,
Candidate Act Descriptor, Extended Verification Module Interface,
Scoped Finality Authority, and Finality Sink described in Common
Master Workflow CW-1.
Where such components are employed, the present embodiment adds
specific protected conflict-state formation, effect-footprint
reconciliation, reservation, ordering, fencing, and completion
mechanisms.
These additional mechanisms are described below.
1.0.2 — Central Technical Principle
In this embodiment:
Individual execution authorization does not establish authority for
an operation to execute concurrently with, or in an incompatible
order relative to, another independently authorized operation.
A consequential operation may therefore require satisfaction of both:
1. Its applicable individual execution-authority predicates; and
2. Its protected cross-operation effect-compatibility predicates.
A valid individual authorization does not override an unresolved
mandatory conflict constraint.
Conversely, a valid conflict reservation does not substitute for the
individual execution authorization required for the operation.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The two classes of authorization may be separately generated,
cryptographically bound, jointly verified, or represented within a
combined protected finality object.
1.1 — TECHNICAL FIELD
The embodiment relates to secure autonomous computing, artificial-
intelligence agent governance, distributed execution control,
protected operating-system services, cryptographic capability
enforcement, hardware-isolated execution domains, multi-agent
orchestration, distributed consistency, cross-application operation
mediation, protected state coordination, and irreversible-effect
control.
More particularly, the embodiment concerns the prevention of
inconsistent combined effects caused by concurrently operating
computational entities, including entities that individually possess
valid authorization but lack a common trustworthy execution-state
coordinator.
The disclosed architecture may operate in heterogeneous computing
environments comprising mobile devices, desktop systems, embedded
devices, cloud services, autonomous machines, enterprise systems,
wearable devices, communications infrastructure, storage controllers,
and distributed applications.
No particular operating system, computing-device manufacturer, agent
framework, secure processor, network protocol, or commercial service
is required.
8.1.3.3. Source page 250 of the original specification
1.2 — SPECIFIC TECHNICAL PROBLEM
1.2.1 — Individually Authorized but Jointly Incompatible Operations
A first autonomous agent may be authorized to modify a resource.
A second autonomous agent may independently be authorized to
transmit, consume, delete, settle, display, actuate upon, or
otherwise use that resource.
Each agent may satisfy its individual authorization conditions.
Nevertheless, executing both operations without suitable coordination
may produce an incorrect or unsafe consequence.
For example:
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• A first agent updates a financial instruction while a second
transmits an earlier instruction.
• A first agent modifies a document while a second distributes an
obsolete representation.
• Two agents independently initiate purchases against the same
limited authorized expenditure.
• Two agents concurrently change different device settings whose
combined physical effect violates a protected operating constraint.
• A remote agent acts on a resource while a local agent performs an
incompatible action against an alias of that resource.
• A resumed agent executes an operation after another agent has
already completed a mutually exclusive operation.
• An agent initiates a supposedly harmless sub-operation that
invalidates the assumptions supporting another pending operation.
The technical problem is therefore not limited to simultaneous writes
against the same database record.
It includes incompatible consequential operations spanning different
applications, interfaces, resources, effectuation sinks, and
administrative domains.
1.2.2 — Limitations of Ordinary Permission Checks
An application-permission system may determine that Agent A has
permission to modify a file and Agent B has permission to transmit
that file.
Such a determination does not necessarily verify that the transmitted
file corresponds to the correct protected version after Agent A
modifies it.
Similarly, an authorization system may approve two separate
expenditure operations without evaluating whether their combined
execution exceeds an independently enforced aggregate authority
constraint.
8.1.3.4. Source page 251 of the original specification
Traditional operation authorization therefore may fail to express
cross-operation consistency requirements.
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.2.3 — Limitations of Conventional Concurrency Mechanisms
Conventional concurrency-control mechanisms include mutexes, read/
write locks, optimistic concurrency control, database transactions,
isolation levels, distributed leases, compare-and-swap operations,
resource-version validation, consensus protocols, and fencing tokens.
These mechanisms may provide effective consistency guarantees when
the relevant operations and resources are represented within their
controlled transaction domain.
They do not, by their mere existence, establish end-to-end control
over all consequential operations initiated by heterogeneous agents
through independently controlled applications.
For example, a software coordinator may hold a lock on a local
resource while a separately privileged execution path continues to
perform an external operation without presenting the lock or an
associated authorization to the actual effectuation boundary.
Similarly, a model-level agent coordinator may determine an execution
order, but another agent may bypass the coordinator through a
different application function, service endpoint, extension, or
device interface.
The relevant technical challenge includes ensuring that an identified
conflict constraint is enforceable at the component that actually
permits the corresponding consequence.
1.2.4 — Limitations of Purely Advisory Conflict Resolution
Some multi-agent systems exchange messages describing proposed
actions, negotiate schedules, or request reconsideration of
conflicting plans.
Such techniques may improve coordination.
However, a decision that is merely communicated to an agent does not
necessarily prevent that agent, another process, or a delegated
component from performing an incompatible operation.
The present embodiment therefore distinguishes:
Conflict detection from protected conflict-state enforcement at the
actual effectuation boundary.
1.2.5 — Technical Objective
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The objective is to provide an implementable architecture in which:
1. Proposed effect-capable operations are represented through
machine-verifiable descriptions of their possible consequences;
2. Potential interference among operations is evaluated using
protected, versioned state;
3. The system determines whether operations may proceed
concurrently, must be ordered, require additional validation, or must
be withheld;
8.1.3.5. Source page 252 of the original specification
4. An applicable protected reservation is committed before the
corresponding effectuation authority becomes usable;
5. The reservation is bound to the specific authorized operation and
relevant effectuation boundary;
6. The Finality Sink verifies the actual pending operation against
the valid reservation and protected authorization;
7. Stale, replayed, incompatible, or superseded operation attempts
are rejected;
8. Protected conflict state is advanced according to verifiable
operation outcomes;
9. Uncertain outcomes do not incorrectly release conflicting
authority; and
10. The architecture remains applicable to separately administered
execution domains where the necessary protected cooperation and
enforcement interfaces are available.
1.3 — COMMON WORKFLOW INCORPORATION
The present embodiment may incorporate Common Master Workflow CW-1.
In particular, the following common phases may be employed:
• CW-1.6.1 — Request receipt and origin identification;
• CW-1.6.2 — Candidate Act construction;
• CW-1.6.3 — Non-effective hold establishment;
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• CW-1.6.4 — Evidence collection;
• CW-1.6.5 — Extension-module selection;
• CW-1.6.6 — Baseline protected authorization;
• CW-1.6.7 — Specialized module verification;
• CW-1.6.8 — Composite predicate construction;
• CW-1.6.9 — Protected-state commitment;
• CW-1.6.10 — Validation evidence commitment;
• CW-1.6.11 — Scoped Finality Authority construction;
• CW-1.6.13 — Finality Sink reconstruction;
• CW-1.6.14 — Sink-time revalidation and consumption control;
• CW-1.6.15 — Controlled effectuation;
• CW-1.6.16 — Outcome classification.
8.1.3.6. Source page 253 of the original specification
The present embodiment specifically extends Shared Module C — Multi-
Agent, Distributed Authority, and Conflict Governance.
The general architecture disclosed in CW-1 does not replace the
specific effect-interference representation, reservation protocol,
protected ordering procedure, sink-fencing mechanism, or consequence-
reconciliation process described herein.
The present embodiment may operate without the optional Interim
Effectuation Validator.
Where stronger phased-outcome assurance is required, the optional IEV
may participate as described subsequently.
1.4 — ADDITIONAL TECHNICAL DEFINITIONS
The following terms are provided for the specific operation of this
embodiment.
1.4.1 — Protected Effect Footprint (PEF)
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Protected Effect Footprint is a machine-verifiable representation
of the resources, state elements, effect domains, external
consequences, or protected invariants that may be observed, modified,
consumed, transmitted, invalidated, or otherwise affected by a
Candidate Act.
A PEF may comprise a typed effect description rather than a simple
read/write resource list.
1.4.2 — Effect Domain
An Effect Domain is an identified technical domain within which a
defined class of consequential state or behavior is controlled.
Examples include a protected file object, a payment authorization
budget, a storage namespace, a communication destination, a device
actuator, a bounded service transaction, or an aggregate
authorization constraint.
An Effect Domain need not correspond to one application or physical
device.
1.4.3 — Effect-Interference Graph (EIG)
An Effect-Interference Graph is a graph or equivalent machine-
verifiable dependency structure representing relationships among
Candidate Acts, their Protected Effect Footprints, and protected
effect constraints.
An EIG may comprise directed edges, undirected edges, hyperedges,
typed dependencies, resource-version constraints, or equivalent
structures.
1.4.4 — Protected Effect-Conflict Reservation (PECR)
A Protected Effect-Conflict Reservation is an authenticated
protected-state commitment that reserves the permission to perform a
specified operation, or a specified compatible group of operations,
subject to an identified conflict-state version and permitted
execution constraints.
A PECR does not by itself authorize an otherwise unauthorized
Candidate Act.
8.1.3.7. Source page 254 of the original specification
1.4.5 — Protected Graph-Fencing Commitment (PGFC)
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Protected Graph-Fencing Commitment is a cryptographically bound
representation of the conflict-state version, applicable effect
reservation, resource ownership or reservation epoch, Candidate Act,
and corresponding authorized effectuation conditions.
It may be incorporated into a Scoped Finality Authority or presented
as separately authenticated evidence.
1.4.6 — Effect-Equivalence Class
An Effect-Equivalence Class identifies resources or operation targets
that must be considered together for conflict analysis because they
represent the same underlying protected object, overlapping authority
scope, shared consequential state, or a defined invariant spanning
multiple objects.
Membership in such a class requires an authenticated mapping or
sufficiently trusted identification procedure.
1.4.7 — Conflict-Relevant Outcome
A Conflict-Relevant Outcome is an actual effectuation result that may
change the compatibility, ordering, reservation, or authority
conditions applicable to another Candidate Act.
1.4.8 — Protected Arbitration State (PAS)
Protected Arbitration State represents the authenticated current
state maintained by the conflict-arbitration mechanism.
PAS may include active reservations, conflict-graph version, effect-
domain state, authority ownership, unresolved attempts, consumed
reservations, effect-version commitments, and recovery
classifications.
1.4.9 — Effect-Interference Constraint
An Effect-Interference Constraint is a technical predicate
determining whether a combination or ordering of Candidate Acts is
permitted.
An Effect-Interference Constraint may be expressed over resource
states, operation semantics, aggregate authority bounds, dependency
relationships, or effect-domain versions.
1.5 — DETAILED SYSTEM ARCHITECTURE
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
In one non-limiting implementation, the PCECA architecture includes
the following cooperating components.
1.5.1 — Agent-Side Candidate Act Producers
A plurality of independently operating agents produces Candidate
Acts.
The agents may have separate identities, execution environments,
software owners, application permissions, model providers, operating-
system contexts, or user-delegated authorities.
8.1.3.8. Source page 255 of the original specification
The architecture does not assume that participating agents exchange
their complete plans or private model states.
Each agent may submit only the information necessary to construct or
validate its Candidate Act and corresponding effect footprint.
1.5.2 — Effect Footprint Construction Engine
An Effect Footprint Construction Engine, or EFCE, obtains a Candidate
Act Descriptor and constructs the corresponding PEF.
The EFCE may derive the footprint from:
• A trusted application-operation schema;
• A protected dispatcher;
• A verified interface contract;
• An authenticated resource map;
• Independently observed operation arguments;
• Protected controller metadata;
• A signed service-operation manifest;
• A trusted resource-state resolver;
• A module-specific semantic-effect mapping.
A footprint asserted by an untrusted agent is not automatically
accepted as a complete description of the actual operation.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
In one implementation, the EFCE verifies the supplied footprint
against an authenticated operation schema and independently observed
resource identities.
Where the footprint cannot be bounded with sufficient confidence, the
system may conservatively classify the operation as interfering with
a broader effect domain or may withhold effectuation.
1.5.3 — Effect-Equivalence Resolution Component
An Effect-Equivalence Resolution Component, or EERC, determines
whether separately described resources or operation targets must be
considered equivalent or overlapping for protected conflict
evaluation.
For example, the same document may be accessible through a file-
provider interface, a document-management service, a synchronized
storage representation, and a cloud API.
The EERC may map such references into an authenticated protected
effect identity where suitable mapping evidence exists.
The EERC may employ resource-owner attestations, canonical object
identifiers, registered alias mappings, authenticated version
references, or protected namespace identifiers.
8.1.3.9. Source page 256 of the original specification
The EERC does not assume that an arbitrary similarity score or model-
generated interpretation is sufficient to prove resource identity.
Where identity cannot be reliably established, the system may retain
separate domains, use conservative overlap classification, or refuse
an operation whose required safety guarantee depends upon that
identity.
1.5.4 — Protected Effect-Interference Graph Engine
The Protected Effect-Interference Graph Engine, or PEIGE, constructs
and updates the EIG.
The graph may represent:
• Shared mutable resources;
• Read-after-write dependencies;
• Write-after-read invalidation;
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• Mutually exclusive consequences;
• Aggregate authority constraints;
• Ordered prerequisite effects;
• Resource-version incompatibilities;
• Physical actuation constraints;
• Duplicate external-effect hazards;
• Cross-application semantic incompatibilities.
The graph is evaluated within, or under authenticated control of, a
protected arbitration domain.
A graph-construction process may use untrusted hints, but mandatory
safety decisions rely upon authenticated or conservatively bounded
conflict information.
1.5.5 — Protected Arbitration Coordinator
A Protected Arbitration Coordinator, or PAC, determines an admissible
execution relationship among pending Candidate Acts.
The PAC may classify operations as:
• Concurrently compatible;
• Compatible only in a specified order;
• Mutually exclusive;
• Dependent upon an earlier verified outcome;
• Requiring renewed authorization;
8.1.3.10. Source page 257 of the original specification
• Incompatible under a protected aggregate constraint;
• Insufficiently specified for safe execution.
The PAC may be implemented within one protected domain or distributed
among cooperating protected domains.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where distributed coordination is employed, the participating domains
use an appropriate authenticated agreement or reservation protocol
consistent with the required safety properties.
1.5.6 — Atomic Reservation Manager
An Atomic Reservation Manager, or ARM, creates and commits PECRs.
The ARM may employ protected compare-and-swap operations, monotonic
state versions, transactional storage, authenticated state-machine
replication, or another mechanism providing the required atomicity.
For independently administered effect domains, the ARM may coordinate
reservations through authenticated domain-local participants.
A reservation is not considered globally committed until the
necessary participating effect domains have completed the prescribed
protected commitment procedure.
1.5.7 — Sink-Bound Fencing Verifier
A Sink-Bound Fencing Verifier checks the validity of a PGFC at the
actual operation-effectuation boundary.
The verifier may be integrated with the Finality Sink, protected
controller, or another component that can prevent effectuation.
The verifier checks whether:
• The reservation corresponds to the actual pending operation;
• The reservation is valid under the current protected conflict
state;
• The relevant effect-domain epoch has not been superseded;
• The operation matches its authorized effect footprint;
• The requested effect is not already consumed or prohibited;
• The required execution order or prerequisite state remains
satisfied.
A stale agent-side belief that a reservation remains valid does not
substitute for this verification.
1.5.8 — Protected Conflict-State Reconciliation Component
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Protected Conflict-State Reconciliation Component, or PCSRC,
updates the protected arbitration state using suitable evidence of
actual operation outcomes.
8.1.3.11. Source page 258 of the original specification
The PCSRC may consume a protected effect receipt, authenticated
controller completion record, verified resource-state transition, or
other sufficiently trustworthy observation.
Where the actual result remains uncertain, the component maintains a
conservative unresolved state instead of automatically releasing a
reservation whose premature release could enable an incompatible
second effect.
1.6 — PROTECTED EFFECT FOOTPRINT CONSTRUCTION
1.6.1 — Need for Effect-Centric Representation
An ordinary action descriptor may identify the requested operation as
a message send, storage write, payment request, or application-
function invocation.
For cross-agent conflict governance, the operation may need a more
detailed representation of its effects.
For example, a message-send operation may consume a communication
quota, disclose a document version, or depend upon a contact
identity.
A payment operation may consume an aggregate authorized spending
allowance even if the transactions target different external
merchants.
Therefore, the present embodiment may construct a typed effect
footprint that identifies both directly affected resources and
relevant shared constraints.
1.6.2 — Representative PEF Structure
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
PROTECTED_EFFECT_FOOTPRINT = { footprint_version, candidate_act_id,
operation_semantics_id, requesting_principal_commitment,
effect_domain_ids[], resource_alias_commitments[],
observed_resource_versions[], read_dependencies[],
modification_targets[], consumption_targets[], disclosure_targets[],
aggregate_constraint_references[], prerequisite_effects[],
possible_external_effect_classes[], declared_idempotency_properties,
supported_compensation_properties, destination_commitment,
protected_observation_sources[], canonicalization_profile,
coverage_manifest_reference, authentication }
8.1.3.12. Source page 259 of the original specification
The fields are non-limiting.
Not every operation requires all fields.
The PEF may use cryptographic commitments to sensitive resource
identifiers instead of exposing those identifiers to unrelated
participating agents.
However, commitments intended to identify equal resources must employ
a suitable common comparison construction.
Two unrelated salted hashes cannot automatically be treated as
comparable identifiers.
Where privacy-preserving equality testing is required, the
participating domains may use authenticated pseudonymization,
protected comparison services, or another explicitly implemented
private equality protocol.
1.6.3 — Typed Effect Operations
A PEF may assign one or more typed operations to a resource or effect
domain.
Representative operation types include:
READ: The operation observes a state without modifying that state.
WRITE: The operation changes a resource state.
CONSUME: The operation consumes bounded authority, quota, inventory,
credit, capacity, or another finite protected resource.
EXPORT: The operation discloses a resource to a destination or
external participant.
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
TRANSFORM: The operation generates a derived resource or
representation.
INVALIDATE: The operation revokes, deletes, supersedes, or
invalidates existing state.
ACTUATE: The operation produces an externally consequential control
effect.
COMMIT: The operation makes a previously prepared state transition
effective.
RESERVE: The operation reserves a protected resource or execution
slot.
RELEASE: The operation releases a previously reserved resource or
authority, subject to protected validation.
An operation may have multiple effect types.
For example, sending a document may simultaneously constitute READ,
EXPORT, CONSUME, and COMMIT effects.
1.6.4 — Effect Footprint Authentication
In one implementation, the EFCE creates a canonicalized footprint
digest:
PEF_DIGEST = H(DOMAIN_SEPARATOR || CANONICAL(PEF))
8.1.3.13. Source page 260 of the original specification
The canonical representation binds the operation semantics,
applicable resource mapping, and effect-domain interpretation.
The footprint digest may be incorporated into the CAD, EVE, PECR, and
SFA.
An effect footprint that changes between protected reservation and
effectuation must be revalidated unless the change is expressly
within an approved scope.
1.7 — EFFECT-INTERFERENCE GRAPH CONSTRUCTION
1.7.1 — Graph Representation
In one non-limiting implementation, the EIG is represented as:
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
G = (V, E, H, S)
• V represents Candidate Act nodes;
• E represents pairwise effect-interference relationships;
• H represents multi-operation constraints or hyperedges;
• S represents protected resource, reservation, and effect-state
information.
A graph node may contain an authenticated reference to the
corresponding PEF, CAD, authority state, and proposed effectuation
domain.
An edge may encode a dependency, conflict, required order, or
invalidation relationship.
A hyperedge may encode constraints involving more than two
operations.
1.7.2 — Pairwise Conflict Evaluation
Two Candidate Acts may conflict when their PEFs overlap on a
protected resource or effect domain and their effects cannot safely
coexist under the applicable semantics.
Representative conflicts include:
• WRITE versus incompatible WRITE;
• READ dependent upon a version changed by WRITE;
• EXPORT of a version invalidated by another operation;
• CONSUME operations exceeding a shared bounded quantity;
• ACTUATE operations whose combined physical effect is prohibited;
• COMMIT operations referencing mutually exclusive transaction
states.
Not every overlap constitutes a conflict.
8.1.3.14. Source page 261 of the original specification
For example, two read-only operations may be compatible.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Two commutative modifications may also be compatible if their
operation semantics and applicable constraints establish a permitted
combined effect.
The system does not presume commutativity merely because two agents
claim that their actions are harmless.
1.7.3 — Aggregate and Higher-Order Conflicts
Some conflicts cannot be represented adequately by pairwise resource
overlap.
For example, three separate authorized payments may each satisfy a
permitted individual amount threshold while their combined amount
exceeds a protected daily spending limit.
The EIG may therefore include aggregate constraint nodes or
hyperedges.
In one implementation, an aggregate constraint is expressed as:
SUM(RESERVED_CONSUMPTION + CONFIRMED_CONSUMPTION) <=
AUTHORIZED_CAPACITY
where the sum is evaluated over the applicable protected authority
window and resource domain.
The actual arithmetic, reservation accounting, and treatment of
pending or uncertain transactions are defined by the effect-domain
controller.
An unknown transaction outcome must not automatically restore its
reserved consumption allowance.
1.7.4 — Semantic Effect Compatibility
An operation can interfere with another even when the operations do
not modify the same raw data object.
For example, changing an account's designated recipient and
transmitting a payment instruction are associated through the meaning
of the recipient reference.
In one implementation, a registered technical effect contract
identifies the relevant relationship.
The contract may specify:
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• Inputs;
• Resulting state mutations;
• Preconditions;
• Invalidated dependencies;
• Commutativity properties;
• External effect categories;
8.1.3.15. Source page 262 of the original specification
• Protected invariant references.
The contract is not accepted as trustworthy merely because it is
generated by a language model.
Its relevant semantics may be supplied by an authenticated
application owner, verified service interface, protected controller,
tested implementation contract, or equivalent trusted source.
A machine-learning classifier may assist in identifying potential
conflicts but is not the sole source of authority for a mandatory
safety property unless the particular embodiment expressly provides
an appropriate verified decision mechanism.
1.7.5 — Conservative Handling of Unknown Footprints
If a PEF omits effect information necessary for a required safety
decision, the PAC may classify the operation as UNKNOWN.
An UNKNOWN classification may result in:
1. Expanded effect-domain reservation;
2. Request for additional verified operation evidence;
3. Restricted execution under a more conservative policy;
4. Denial of the proposed operation;
5. Deferral pending trusted state reconciliation.
The requesting agent cannot convert UNKNOWN into compatible merely by
submitting a new unverified description.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.8 — PROTECTED CONFLICT ARBITRATION PROTOCOL
1.8.1 — Arbitration Initialization
Upon construction of a Candidate Act, the PED invokes the applicable
conflict-governance module.
The module receives:
• Authenticated CAD;
• Verified PEF;
• Current protected arbitration state;
• Relevant active reservations;
• Relevant effect-domain versions;
• Applicable aggregate constraints;
• Existing operation dependencies.
8.1.3.16. Source page 263 of the original specification
The PAC determines whether the proposed Candidate Act can proceed
without violating the current protected conflict state.
1.8.2 — Conflict Classification
In one implementation, the PAC returns one of the following
classifications.
Classification Meaning
PARALLEL_COMPATIBLE Concurrent execution is permitted under verified
t i t ORDER_REQUIRED Execution is permitted only after a specified
predecessor condition EXCLUSIVE_RESERVATION_REQU IRED
The operation requires protected exclusion of incompatible effects
ADDITIONAL_VALIDATION_REQU IRED
More trustworthy evidence is needed AGGREGATE_CONSTRAINT_EXCE EDED
Combined effect exceeds an authorized bound
EFFECT_OUTCOME_DEPENDENT Decision depends upon a preceding
operation's observed
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
t CONFLICT_UNRESOLVED The required safe relationship cannot currently
be
t bli h d PROHIBITED The proposed effect violates an applicable
protected i i t
Classification is not solely based upon the type of application or
identity of the agent.
It depends upon the actual effect descriptions, authority
constraints, and protected state.
1.8.3 — Determination of a Permitted Order
Where a conflict is resolvable through ordering, the PAC may
determine a permissible execution sequence.
An ordering decision may specify:
• Predecessor Candidate Act;
• Required predecessor outcome;
• Required resource version;
• Permitted successor operation;
• Reservation expiry conditions;
• Protected state version;
• Whether revalidation is required.
An operation may be deferred rather than denied where a permitted
future sequence exists.
Where no acceptable ordering exists, the operation is withheld.
1.8.4 — Atomic Reservation Creation
8.1.3.17. Source page 264 of the original specification
The ARM constructs a PECR associated with the Candidate Act and the
applicable protected conflict state.
In one implementation:
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
PROTECTED_EFFECT_CONFLICT_RESERVATION = { reservation_id,
candidate_act_digest, protected_effect_footprint_digest,
effect_domain_ids[], affected_resource_commitments[],
arbitration_graph_version, reservation_epoch,
required_predecessor_state[], permitted_execution_constraints[],
designated_sink_commitments[], aggregate_resource_debits[],
reservation_status, expiration_or_fencing_conditions,
protected_authentication } The ARM validates that the corresponding
reservation can be committed atomically against the relevant
protected state.
If another operation changes a conflicting reservation or resource
state during commitment, the ARM retries against a newly observed
state, defers the operation, or rejects the request according to
policy.
It does not blindly commit against an obsolete graph version.
1.8.5 — Protected Graph-Fencing Commitment
Upon successful reservation, the system derives or commits the PGFC.
The PGFC binds the authorized operation to the relevant conflict
state and reservation.
A representative commitment may be:
PGFC = AUTH_PROTECT(H(CAD || PEF || PECR || GRAPH_VERSION ||
SINK_ID || AUTHORITY_EPOCH))
where AUTH_PROTECT represents an appropriate protected signing,
message-authentication, sealed-handle, or equivalent operation.
The expression is illustrative and does not require use of a
particular cryptographic algorithm.
The PGFC may be included in an App-Scoped Fractional Capability,
Execution Handle, or other SFA.
The PGFC does not replace that authority.
Instead, it establishes an additional effect-compatibility condition
that must be satisfied before the corresponding consequential
operation can proceed.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.1.3.18. Source page 265 of the original specification
1.9 — SINK-BOUND EFFECT FENCING
1.9.1 — Enforcement at the Actual Boundary
The PAC may authorize an execution order, but the ordering decision
provides limited security unless the actual effectuation mechanism
enforces it.
Accordingly, the designated Finality Sink or its controlling
protected component verifies the PGFC before permitting effectuation.
The FS obtains the actual pending operation through an appropriate
trusted observation or reconstruction procedure.
The FS checks the actual operation against:
1. The individual Scoped Finality Authority;
2. The Candidate Act Descriptor;
3. The Protected Effect Footprint;
4. The committed PECR;
5. The applicable conflict-state version;
6. The current protected fencing or reservation epoch;
7. The relevant predecessor and dependency conditions;
8. The required effect-domain constraints.
The FS refuses the operation if any mandatory condition is
unsatisfied.
1.9.2 — Stale-Agent Protection
An agent may become temporarily suspended after receiving
authorization.
During suspension, another authorized operation may change the
relevant protected resource or reservation state.
When the original agent resumes, its previously obtained PGFC may no
longer satisfy the current protected conditions.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The FS detects this condition and refuses the stale operation.
In one implementation, the protected controller maintains a monotonic
reservation epoch for each relevant effect domain.
An attempt associated with a superseded epoch is rejected.
In another implementation, the FS verifies an authenticated conflict-
state version and the current reservation record rather than relying
solely upon a scalar fencing number.
8.1.3.19. Source page 266 of the original specification
The particular mechanism depends upon the resource and enforcement
substrate.
1.9.3 — Operation-Specific Reservation Matching
The PGFC cannot be used to authorize an unrelated operation.
For example, a reservation for modifying document version V1 does not
authorize transmission of V1, modification of an unrelated document,
or modification of V2 unless such scope was independently permitted.
Where a reservation covers a bounded group of compatible operations,
the group and applicable resource scope are expressly represented.
A broad software permission is not treated as a substitute for the
relevant protected reservation.
1.9.4 — Reservation Consumption
A reservation may be:
• Consumed at the controlled effectuation boundary;
• Retained during a bounded operation;
• Advanced following a verified state transition;
• Superseded by a newer protected reservation;
• Released after confirmed absence of effect;
• Held pending reconciliation of an uncertain outcome.
A reservation cannot be safely reused merely because an untrusted
requester reports that the earlier attempt failed.
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
For a single-use consequential act, protected reservation consumption
and individual finality-capability consumption may be coordinated
atomically where required by the implementation.
1.10 — MULTI-DOMAIN RESERVATION AND COORDINATION
1.10.1 — Independent Administrative Domains
The present embodiment may operate where Candidate Acts affect
resources administered by separate applications, protected services,
devices, or organizations.
No assumption is made that every application exposes its complete
internal state to other applications.
Instead, each participating domain may expose a limited authenticated
effect-control interface.
Such an interface may support:
• Operation-footprint attestation;
8.1.3.20. Source page 267 of the original specification
• Resource-equivalence resolution;
• Reservation preparation;
• Protected reservation commitment;
• Current fencing-epoch verification;
• Actual-operation validation;
• Effect-outcome evidence;
• Reservation release or reconciliation.
The interface may be implemented using authenticated service
messages, protected IPC, secure controller calls, or equivalent
mechanisms.
1.10.2 — Reservation Preparation Across Domains
Where one Candidate Act requires protected reservations in multiple
effect domains, a coordinator may submit an authenticated
reservation-preparation request to each relevant domain.
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Each domain validates:
• The proposed operation;
• The affected resource;
• Applicable local authority constraints;
• Local reservation state;
• Requested reservation version;
• Relevant fencing conditions.
A domain that cannot safely reserve its applicable effect refuses
preparation.
A successful preparation result is not, by itself, final
authorization to produce the external effect.
1.10.3 — Coordinated Reservation Commitment
In one implementation, the system uses an authenticated transactional
reservation protocol.
The coordinator collects protected preparation records from the
required domains.
The coordinator then establishes a durable commit decision according
to an agreed protocol.
Participating domains commit the corresponding reservations and
expose the committed state to their respective Finality Sinks.
No required sink permits effectuation merely because it received a
tentative preparation response.
Where a replicated coordinator is used, its agreement protocol must
provide the consistency properties needed for safe reservation
ownership.
8.1.3.21. Source page 268 of the original specification
Where a single protected coordinator is used, its failure recovery
must preserve durable reservation and decision state.
1.10.4 — Deadlock Prevention
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
When a Candidate Act requires reservations across multiple domains,
the system may establish a deterministic order for reservation
requests.
For example, domains may be ordered by authenticated canonical
identifiers.
The system may also use bounded retries, protected abort decisions,
or equivalent established deadlock-management techniques.
An implementation requiring strict global consistency must not treat
a timed-out reservation as automatically safe to reassign where its
associated effect may already have occurred.
1.10.5 — Network Partition Handling
A network partition may prevent communication between the coordinator
and a relevant effect domain.
If the required protected commitment or current fencing state cannot
be established, the affected operation may remain withheld.
The system does not assume that all isolated domains can continue
independently while simultaneously preserving an exclusive global
execution invariant.
Where a domain possesses a previously committed, bounded reservation
and can prove the reservation remains valid under the applicable
failure model, local execution may be permitted according to the
specifically disclosed protocol.
Otherwise, availability may be sacrificed to preserve the required
execution safety condition.
1.10.6 — Participation and Enforcement Limits
A non-participating external service cannot be assumed to enforce a
PGFC merely because a local coordinator generated one.
For end-to-end protection across administrative domains, the
applicable service must either:
• Enforce the protected reservation at a trusted effectuation
boundary;
• Operate through a gateway that exclusively controls the relevant
effect;
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• Provide an appropriately trusted remote enforcement interface; or
• Participate in another technically sufficient enforcement
arrangement.
Without such control, the system can govern only the effectuation
paths actually mediated by its participating components.
This limitation applies to claims of cross-domain non-bypassability.
8.1.3.22. Source page 269 of the original specification
1.11 — INDEPENDENT EFFECT-STATE RECONCILIATION
1.11.1 — Distinguishing Permission from Outcome
Successful reservation and Finality Sink validation establish that an
operation was permitted under the applicable protected conditions.
They do not necessarily establish that the requested effect occurred.
For example, an authorized remote service invocation may be
transmitted successfully while the remote service subsequently fails,
partially commits, or completes without returning an acknowledgement.
The protected conflict state must therefore distinguish reservation
status from actual effect status.
1.11.2 — Conflict-Relevant Outcome Classification
The PCSRC may classify outcomes as:
• NO_EFFECT_CONFIRMED;
• EFFECT_CONFIRMED;
• PARTIAL_EFFECT_CONFIRMED;
• EFFECT_OUTCOME_UNKNOWN;
• EFFECT_MISMATCH_CONFIRMED;
• RECOVERY_PENDING.
These classifications correspond to the common outcome model
disclosed in CW-1.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The classification may be based upon an authenticated effect receipt,
independently observed resource version, trusted transaction
completion record, or equivalent evidence.
1.11.3 — Release After Confirmed No Effect
If trustworthy evidence establishes that the operation did not
produce its governed consequence, the protected coordinator may
release the associated conflict reservation.
The release is committed against the current protected arbitration
state.
The system may then authorize another previously conflicting
operation.
1.11.4 — Advance After Confirmed Effect
If trustworthy evidence establishes that the operation produced the
corresponding authorized consequence, the protected coordinator
updates the relevant effect-domain state.
The update may include:
• New resource version;
8.1.3.23. Source page 270 of the original specification
• Consumed capacity;
• Completed operation identifier;
• Superseded dependency;
• Updated aggregate constraint;
• Released or transformed reservations;
• New conflict-graph version.
Other pending operations are reevaluated against the updated
protected state where required.
1.11.5 — Handling Unknown Outcomes
An uncertain outcome may require preservation of a conflict
reservation or a protected unresolved-effect marker.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system does not automatically release the affected reservation
because a timeout elapsed.
A pending conflicting operation may be deferred until the relevant
external effect is reconciled.
Where only a subset of resources is affected by the uncertainty,
unrelated operations may remain executable.
Thus, uncertainty containment may be scoped to the actual affected
effect domains rather than causing unnecessary system-wide denial.
1.11.6 — Optional Interim Effectuation Validator
In a higher-assurance implementation, an IEV may validate the prior
effect receipt and determine whether a subsequent conflicting or
dependent operation may proceed.
The IEV may verify that the observed outcome satisfies the expected
state transition.
A successful IEV decision may authorize preparation of a new conflict
reservation or continuation authority.
However, the IEV is not mandatory for every implementation of PCECA.
Where an authenticated resource controller itself provides sufficient
protected outcome state, the coordinator may use that state directly.
1.12 — COMPLETE OPERATIONAL WORKFLOW
The following steps illustrate one non-limiting implementation.
Step 1 — Receive Candidate Acts
Two or more independently operating agents submit proposed effect-
capable operations.
Each operation is represented as a Candidate Act and associated CAD.
8.1.3.24. Source page 271 of the original specification
Step 2 — Establish Non-Effective Holding
The applicable controlled execution path maintains each Candidate Act
in a non-effective state before the required authorization and
reservation conditions are satisfied.
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 3 — Acquire Trusted Operation Evidence
The system obtains relevant application, resource, operation-schema,
authority, and current-state evidence.
Step 4 — Construct Protected Effect Footprints
The EFCE constructs a PEF for each Candidate Act.
The PEF identifies the effect domains and potential consequential
state changes.
Step 5 — Resolve Protected Resource Equivalence
The EERC determines whether the footprints overlap through common
resources, authenticated aliases, aggregate constraints, or shared
consequential states.
Step 6 — Construct or Update the Effect-Interference Graph
The PEIGE constructs a protected representation of potential
interference among the Candidate Acts and existing pending
operations.
Step 7 — Classify Conflicts
The PAC determines whether the operations are concurrently
compatible, require ordering, require exclusion, depend upon a prior
outcome, or cannot currently be authorized safely.
Step 8 — Establish Protected Reservation
For an admissible operation, the ARM commits a PECR against the
current protected arbitration state.
Step 9 — Bind Conflict Reservation to Finality Authority
The protected authorization mechanism generates or commits a PGFC and
binds the reservation to the applicable SFA.
Step 10 — Present Actual Operation at Finality Sink
The actual effect-capable operation reaches the designated Finality
Sink.
The sink obtains or reconstructs its relevant operative parameters.
Step 11 — Independently Verify Current Conflict State
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Finality Sink verifies both individual execution authority and
the current protected conflict-reservation predicates.
Step 12 — Refuse or Permit Effectuation
8.1.3.25. Source page 272 of the original specification
If mandatory predicates fail, the operation remains withheld.
If the predicates succeed, the controlled operation may cross the
designated Effectuation Boundary.
Step 13 — Obtain Conflict-Relevant Outcome Evidence
Where necessary, the system obtains protected evidence indicating
whether the operation occurred, partially occurred, or remains
unresolved.
Step 14 — Reconcile Protected Arbitration State
The PCSRC updates resource versions, reservations, dependency state,
and completed or uncertain effect records.
Step 15 — Reevaluate Waiting Operations
Pending Candidate Acts whose compatibility depended upon the earlier
operation are reevaluated.
A new protected reservation may be issued if the updated state
permits effectuation.
Step 16 — Finalize
The relevant Candidate Act is completed, denied, deferred, or placed
into an appropriate recovery state.
The system retains the required protected state to prevent duplicate
or conflicting subsequent execution.
1.13 — NON-LIMITING PSEUDOCODE
1.13.1 — Conflict Footprint Construction
FUNCTION BUILD_PROTECTED_EFFECT_FOOTPRINT( candidate_act,
trusted_operation_schema, observed_resources, protected_context ):
REQUIRE VALIDATE_CANDIDATE_ACT(candidate_act)
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
REQUIRE VERIFY_SCHEMA_AUTHENTICITY( trusted_operation_schema )
actual_semantics = RESOLVE_OPERATION_SEMANTICS( candidate_act,
trusted_operation_schema )
resource_set = RESOLVE_AUTHENTICATED_RESOURCES(
8.1.3.26. Source page 273 of the original specification
candidate_act, observed_resources )
effect_domains = MAP_TO_EFFECT_DOMAINS( resource_set,
actual_semantics, protected_context )
IF REQUIRED_EFFECT_INFORMATION_UNAVAILABLE: RETURN FOOTPRINT_UNKNOWN
footprint = CANONICALIZE({ candidate_act_id:
candidate_act.identifier,
operation_semantics: actual_semantics,
resource_commitments: COMMIT_RESOURCES(resource_set),
effect_domains: effect_domains,
state_dependencies: IDENTIFY_STATE_DEPENDENCIES(),
effect_types: CLASSIFY_EFFECT_TYPES(),
aggregate_constraints: RESOLVE_AGGREGATE_CONSTRAINTS(),
schema_version: trusted_operation_schema.version })
RETURN AUTHENTICATE_FOOTPRINT(footprint) 1.13.2 — Protected Conflict
Evaluation and Reservation
FUNCTION PROTECTED_CONFLICT_ARBITRATION( candidate_act,
protected_effect_footprint, current_arbitration_state ):
REQUIRE VERIFY_CAD(candidate_act)
REQUIRE VERIFY_PROTECTED_FOOTPRINT( protected_effect_footprint
8.1.3.27. Source page 274 of the original specification
state = PAC.LOAD_AUTHENTICATED_STATE()
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
graph = UPDATE_INTERFERENCE_GRAPH( state.graph,
protected_effect_footprint, state.active_reservations,
state.unresolved_effects )
decision = EVALUATE_CONFLICT_CONSTRAINTS( candidate_act, graph, state
)
IF decision == PROHIBITED: RETURN DENY
IF decision == CONFLICT_UNRESOLVED: RETURN DEFER
IF decision == ORDER_REQUIRED: RETURN WAIT_FOR_PREDECESSOR
reservation = PREPARE_EFFECT_RESERVATION( candidate_act,
protected_effect_footprint, graph.version, decision )
committed = PAC.COMPARE_AND_COMMIT( expected_state_version =
state.version, new_reservation = reservation, required_state_changes
= decision.protected_changes )
IF committed == RETRY_REQUIRED: CONTINUE
IF committed != SUCCESS: RETURN DENY_OR_DEFER
pgfc = PAC.CREATE_GRAPH_FENCING_COMMITMENT( candidate_act,
reservation, protected_effect_footprint,
8.1.3.28. Source page 275 of the original specification
committed.new_state_version )
RETURN { decision: RESERVED, reservation: reservation, pgfc: pgfc }
1.13.3 — Sink-Side Conflict Verification
FUNCTION SINK_VERIFY_CONFLICT_AUTHORITY( candidate_act,
scoped_finality_authority, protected_graph_fencing_commitment,
actual_pending_operation ):
REQUIRE SINK.VERIFY_INDIVIDUAL_AUTHORITY( scoped_finality_authority,
actual_pending_operation )
actual_footprint = SINK.RESOLVE_ACTUAL_EFFECTS(
actual_pending_operation )
IF actual_footprint IS UNKNOWN: RETURN DENY_OR_DEFER
REQUIRE VERIFY_FOOTPRINT_CORRESPONDENCE( actual_footprint,
protected_graph_fencing_commitment )
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
current_state = LOAD_CURRENT_PROTECTED_CONFLICT_STATE()
REQUIRE VERIFY_RESERVATION_ACTIVE(
protected_graph_fencing_commitment, current_state )
REQUIRE VERIFY_CURRENT_FENCING_EPOCH(
protected_graph_fencing_commitment, current_state )
REQUIRE VERIFY_REQUIRED_PREDECESSORS(
protected_graph_fencing_commitment, current_state )
REQUIRE VERIFY_AGGREGATE_CONSTRAINTS(
8.1.3.29. Source page 276 of the original specification
actual_footprint, current_state )
consumption = ATOMIC_RESERVE_OR_CONSUME_AUTHORITY(
scoped_finality_authority, protected_graph_fencing_commitment,
actual_pending_operation )
IF consumption != SUCCESS: RETURN DENY
RETURN PERMIT_SPECIFIC_EFFECTUATION 1.13.4 — Protected Outcome
Reconciliation
FUNCTION RECONCILE_CONFLICT_STATE( candidate_act_id, reservation_id,
observed_outcome_evidence ):
state = PAC.LOAD_AUTHENTICATED_STATE()
outcome = VERIFY_AND_CLASSIFY_OUTCOME( observed_outcome_evidence )
IF outcome == NO_EFFECT_CONFIRMED:
RETURN PAC.ATOMICALLY_UPDATE( release_reservation = reservation_id,
mark_attempt = NO_EFFECT_CONFIRMED )
IF outcome == EFFECT_CONFIRMED:
RETURN PAC.ATOMICALLY_UPDATE( consume_reservation = reservation_id,
advance_resource_versions = TRUE, update_aggregate_constraints =
TRUE, reevaluate_waiting_operations = TRUE )
IF outcome == PARTIAL_EFFECT_CONFIRMED:
RETURN PAC.ATOMICALLY_UPDATE( preserve_affected_reservations = TRUE,
mark_partial_effect = TRUE, require_reconciliation = TRUE )
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.1.3.30. Source page 277 of the original specification
IF outcome == EFFECT_OUTCOME_UNKNOWN:
RETURN PAC.ATOMICALLY_UPDATE( preserve_conflict_fence = TRUE,
mark_unresolved = TRUE, prohibit_unsafe_reassignment = TRUE )
RETURN DENY_UNVERIFIED_STATE_TRANSITION 1.13.5 — Algorithmic Scope
The pseudocode is non-limiting.
A PHOSITA may replace particular data structures or transaction
mechanisms with technically equivalent implementations that preserve
the stated protected reservation, sink-verification, and outcome-
reconciliation properties.
The use of conventional cryptographic hashes, atomic storage
operations, or fencing counters individually is not represented as
the inventive contribution.
The potential inventive subject matter lies in the specific
coordinated technical arrangement and the additional enforceable
properties established by that arrangement.
1.14 — WORKED EXAMPLE A: CONCURRENT DOCUMENT MODIFICATION AND
TRANSMISSION
1.14.1 — System Configuration
A first agent, Agent A, is authorized to revise Document D.
A second agent, Agent B, is independently authorized to transmit an
approved version of Document D to Recipient R.
The agents execute through separate applications.
The document is accessible through a local storage interface and a
synchronized document-service interface.
The system includes a protected resource identity resolver, a
conflict coordinator, and controlled storage and transmission
effectuation boundaries.
1.14.2 — Candidate Acts
Agent A submits:
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
CA-A: action = MODIFY_DOCUMENT resource = Document D observed_version
= V7 intended_result = V8 sink = STORAGE_COMMIT_SINK Agent B submits:
8.1.3.31. Source page 278 of the original specification
CA-B: action = TRANSMIT_DOCUMENT resource = Document D
authorized_version = V7 destination = Recipient R sink =
NETWORK_SEND_SINK Both Candidate Acts may satisfy their respective
individual authorization predicates.
1.14.3 — Protected Footprint Formation
The EFCE constructs:
PEF-A: effect_domain = DOCUMENT_D effect_type = WRITE input_version =
V7
PEF-B: effect_domain = DOCUMENT_D effect_type = READ + EXPORT
required_version = V7 The resource identity resolver verifies that
the local document and synchronized representation refer to the same
protected document identity for the applicable operation.
1.14.4 — Conflict Detection
The PAC recognizes that CA-A and CA-B may interfere because CA-A
changes the version on which CA-B depends.
The precise decision depends upon the authorized semantics.
If the user expressly authorized transmission of the immutable V7
snapshot, the system may permit transmission from that authenticated
snapshot.
If the transmission was authorized to send the current finalized
document, the system may require CA-A to complete first and CA-B to
obtain authorization for the resulting V8 object.
Thus, conflict arbitration is based on actual authorized semantics
rather than blanket rejection of every read/write overlap.
1.14.5 — Protected Reservation
In the second case, the PAC records:
CA-A: reservation = EXCLUSIVE_MODIFICATION required_input_version =
V7
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
CA-B: state = WAITING required_predecessor = CA-A required_outcome =
VERIFIED_COMMIT CA-A receives a reservation bound to the expected
storage operation.
8.1.3.32. Source page 279 of the original specification
CA-B does not receive effectuation authority for transmission until
its required conditions are satisfied.
1.14.6 — Sink Enforcement
The storage Finality Sink verifies CA-A's capability and protected
reservation.
It commits the permitted document modification.
The protected resource controller records the resulting document
version.
CA-B is then reevaluated under its own authorization conditions.
The transmission sink independently verifies the selected document
object and authorized destination before permitting the actual send.
1.14.7 — Failure Scenario
Suppose Agent A completes its modification but crashes before
reporting success.
The PAC does not assume the modification failed.
Instead, the protected outcome-reconciliation component examines
trustworthy storage-state evidence.
If the modification to V8 is confirmed, the protected conflict state
advances accordingly.
If the result remains uncertain, the dependent transmission remains
withheld until the required condition can be established.
1.14.8 — Technical Effect
The example demonstrates how protected conflict reservations and
Finality Sink verification may prevent inconsistent cross-application
effects even when both agents individually possess valid
authorization.
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
It also demonstrates how the architecture distinguishes a known
resource version from an unverified statement of task completion.
1.15 — WORKED EXAMPLE B: MULTIPLE AUTHORIZED PURCHASE AGENTS
1.15.1 — Scenario
A user authorizes autonomous purchasing agents to perform individual
purchases within a total protected expenditure allowance of 10,000
currency units.
Agent A proposes a purchase costing 6,000 units.
Agent B proposes a purchase costing 5,000 units.
Each purchase is individually below the total allowance.
However, the aggregate proposed consumption is 11,000 units.
8.1.3.33. Source page 280 of the original specification
1.15.2 — Aggregate Effect Domain
Both purchases are associated with a shared protected expenditure
domain.
Their footprints include:
PEF-A: type = CONSUME amount = 6000 domain =
AUTHORIZED_EXPENDITURE_POOL
PEF-B: type = CONSUME amount = 5000 domain =
AUTHORIZED_EXPENDITURE_POOL The protected coordinator evaluates
confirmed consumption, active reservations, and unresolved
consumption attempts against the applicable allowance.
1.15.3 — Protected Arbitration
If neither purchase has occurred, the PAC may reserve authority for
one of the operations according to an authenticated policy.
The remaining operation is withheld if its reservation would exceed
the protected allowance.
A later agent cannot bypass the aggregate constraint by presenting
its individual purchase authorization without the applicable current
reservation.
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.15.4 — Sink-Side Enforcement
The payment-related effectuation boundary verifies:
• The actual pending payment amount;
• The applicable recipient or merchant constraints;
• The individual payment authority;
• The protected expenditure reservation;
• The current consumption state.
Only the authorized operation is permitted to proceed.
1.15.5 — Ambiguous External Outcome
Suppose the first payment instruction is submitted but the external
payment service does not return a conclusive acknowledgement.
The system does not immediately restore the reserved 6,000 units.
Instead, the attempt remains unresolved until sufficient evidence
establishes the actual outcome.
The second purchase therefore cannot rely on an assumed absence of
the first payment.
8.1.3.34. Source page 281 of the original specification
1.15.6 — Technical Effect
The example illustrates protected aggregate effect constraints across
otherwise independently authorized agents.
Ordinary quota reservation is known technology; the present example
provides a concrete implementation context for the claimed
combination of protected effect-footprint coordination, scoped per-
act authority, actual sink verification, and conservative external-
outcome reconciliation.
1.16 — WORKED EXAMPLE C: CROSS-DEVICE AUTONOMOUS OPERATION CONFLICT
In one non-limiting implementation, two computing devices operate
agents under a shared protected user authority.
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Device A prepares a consequential operation while Device B
independently prepares an incompatible operation against the same
authenticated resource domain.
The devices may possess different operating systems, applications,
protected execution environments, or network connections.
The conflict coordinator establishes protected reservation ownership
according to an authenticated reservation protocol.
Device A receives a valid reservation for an operation under
reservation epoch E1.
Before Device A effectuates, the reservation may be revoked or
superseded according to the protected protocol, and Device B may
receive a new reservation under E2.
Device A subsequently resumes and attempts its earlier operation
using E1.
The applicable effectuation boundary verifies the current protected
fencing or ownership state and refuses the stale operation.
This example assumes that the effectuation boundary can verify
authoritative reservation state or enforce a previously committed
safe offline authorization bound.
Where that assumption cannot be satisfied during disconnection, the
system withholds the affected operation rather than assuming that
exclusive authority remains valid.
The example demonstrates application of PCECA to distributed device
authority while preserving the distinction between reservation
ownership and actual execution permission.
1.17 — ADVERSARIAL THREAT MODEL
The embodiment may be evaluated against the following representative
threats.
Threat Proposed enforcement response
Agent submits an incomplete effect footprint Verify against trusted
operation semantics or classify
ti l Agent lies about resource identity Resolve through authenticated
resource mapping
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.1.3.35. Source page 282 of the original specification
Two agents race to reserve the same protected effect domain Atomic
protected reservation commitment
Agent uses a stale reservation after
Sink-side epoch or protected-state fencing Agent substitutes
operation arguments after
Actual-operation reconstruction and footprint
i t h j ti Agent attempts an alternate effectuation path Enforcement
only through covered and verified
i k Agent replays an earlier reservation Protected consumption and
freshness verification Coordinator crashes after tentative
Durable reservation-state recovery Remote operation completes without
k l d t
Unknown-outcome classification and reconciliation Two effect domains
disagree about
Authenticated agreement and committed reservation
t t Agent splits one conflicting operation into fragments
Aggregate effect-domain evaluation or separately governed fragments
Application update changes operation
Revalidate authenticated effect contract and f t i t Compromised
model falsely claims no
Model assertion does not replace protected
bit ti Stale snapshot restores earlier authority Protected rollback-
resistant state and sink fencing Reservation expires during delayed
Sink refuses superseded authority Independent external service
ignores
Guarantee limited to actual protected enforcement
The listed threats are illustrative.
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Protection against a fully compromised operating-system kernel,
malicious firmware, compromised secure processor, or non-
participating external service requires corresponding trust-boundary
assumptions and enforcement mechanisms.
1.18 — CRASH CONSISTENCY AND PROTECTED RESERVATION RECOVERY
1.18.1 — Failure Before Reservation Commitment
If a coordinator crashes before a required reservation is committed,
no final effectuation authority is issued on the basis of the
incomplete reservation.
The affected Candidate Act may be reconstructed or retried under a
new protected state version.
1.18.2 — Failure After Reservation Commitment but Before Effectuation
A committed reservation may remain pending.
Recovery determines whether effectuation had started and whether the
associated authority was consumed.
The recovered state does not automatically assume successful or
unsuccessful effectuation.
1.18.3 — Failure After Effectuation Attempt
If the operation was dispatched before a crash, protected recovery
must account for the possibility that the consequence occurred.
8.1.3.36. Source page 283 of the original specification
The system may consult a trusted completion record, protected
resource version, idempotency reference, or independent effect
observer.
Until the required result can be established, conflicting operations
may remain fenced.
1.18.4 — Partial Multi-Domain Effectuation
A distributed operation may produce an effect in one domain before
another domain completes its corresponding operation.
The present embodiment does not assume that an externally
irreversible effect can always be atomically undone.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Instead, the system may:
• Record the verified partial result;
• Preserve unresolved conflict constraints;
• Prevent unauthorized subsequent phases;
• Require a separately authorized recovery operation;
• Invoke the optional IEV or another protected recovery validator.
Where true all-or-nothing behavior is required, the underlying
effectuation systems must provide an appropriate atomic commit
facility or an equivalent enforceable mechanism.
1.18.5 — Safe Reservation Reclamation
A reservation may be reclaimed when protected evidence establishes
that its effectuation authority is no longer capable of producing an
unauthorized effect.
Mere passage of time is not sufficient where a delayed or suspended
executor can still present an old authorization to a non-fencing
effectuation target.
Where appropriate, reclamation includes advancing a protected fencing
epoch and ensuring that the relevant sink rejects superseded
authority.
1.19 — NON-LIMITING HARDWARE AND SOFTWARE IMPLEMENTATIONS
1.19.1 — Protected Local Operating-System Implementation
In one implementation, the PAC and ARM execute within a privileged
protected system service cooperating with an independently protected
authority component.
The application-function dispatcher, storage controller, network
gateway, or other effectuation boundary verifies the corresponding
protected conflict authority.
Ordinary agents cannot modify the protected reservation state.
1.19.2 — Hardware-Isolated Implementation
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.1.3.37. Source page 284 of the original specification
In another implementation, protected reservation keys, counters, and
authority commitments reside within a secure coprocessor, trusted
execution environment, secure element, or equivalent hardware-
isolated component.
The effectuation subsystem verifies the applicable authorization
through a protected interface.
Hardware isolation is employed to reduce the ability of compromised
application or operating-system software to forge or modify protected
conflict state.
The degree of resistance to privileged software compromise depends
upon the particular hardware trust boundary and the paths that the
protected controller actually governs.
1.19.3 — Distributed Service Implementation
In another implementation, the PAC operates through a replicated
protected service with authenticated domain-local reservation
participants.
The participating Finality Sinks obtain verifiable conflict-state
commitments before performing the governed effects.
The implementation may use a conventional consensus or transactional
protocol for state replication.
Such protocols are supporting mechanisms rather than necessarily
inventive components by themselves.
1.19.4 — Controller-Integrated Implementation
In another implementation, a storage controller, network controller,
payment gateway, actuator controller, or other protected effectuation
subsystem performs both the conflict-reservation verification and the
actual effectuation.
The separate Finality Gate and Finality Sink roles may be integrated
within the same protected controller.
1.19.5 — Privacy-Preserving Cross-Domain Implementation
In another implementation, cooperating domains exchange authenticated
commitments to protected effect identities rather than complete
resource contents.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A trusted equality-resolution protocol determines whether relevant
effect domains overlap.
The protocol may avoid exposing unrelated private source records
while still identifying conflicts necessary for the corresponding
enforcement decision.
The construction must preserve the correctness of relevant equality
and overlap decisions under its stated cryptographic and trust
assumptions.
1.20 — REFERENCE IMPLEMENTATION PLAN FOR PHOSITA
The following non-limiting prototype may be implemented using
generally available engineering components.
8.1.3.38. Source page 285 of the original specification
1.20.1 — Prototype Components
A representative prototype may include:
1. Two independent AI-agent processes;
2. Two application-facing effectuation gateways;
3. A Candidate Act descriptor generator;
4. A typed operation-schema registry;
5. An Effect Footprint Construction Engine;
6. A protected or experimentally simulated arbitration service;
7. A versioned conflict-state database;
8. An Atomic Reservation Manager;
9. A capability issuer and verifier;
10. A sink-side fencing component;
11. A controlled resource store;
12. An effect-observation service;
13. A fault-injection test harness.
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The prototype may initially employ software-isolated services to test
protocol logic.
Hardware-backed implementation may subsequently replace selected
components without changing the defined message and state-transition
requirements.
1.20.2 — Representative Storage Schema
The prototype may maintain relational tables or equivalent key-value
structures.
Candidate Acts
candidate_act_id requester_id cad_digest footprint_digest
action_class status designated_sink Effect Domains
effect_domain_id resource_equivalence_id current_version
current_fencing_epoch
8.1.3.39. Source page 286 of the original specification
constraint_version Conflict Reservations
reservation_id candidate_act_id effect_domain_id reservation_version
reservation_epoch reservation_state required_predecessor
consumption_reference Effect Attempts
attempt_id candidate_act_id reservation_id sink_id effectuation_state
observed_outcome observation_evidence_digest The schema is
illustrative.
The necessary concurrency properties depend upon the chosen storage
and protected-state implementation.
1.20.3 — Prototype Execution
Two agents operate concurrently against protected test resources.
Each proposed operation is intercepted and converted into a CAD and
PEF.
The arbitration service constructs an EIG and attempts to create
protected reservations.
The effectuation gateways refuse operations lacking valid
reservations or individual authority.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The fault-injection harness introduces delays, concurrent
submissions, stale state, process termination, transport failures,
resource substitutions, and lost acknowledgements.
The observed execution trace is compared against the required
conflict and authorization invariants.
1.21 — NON-LIMITING EXPERIMENTAL VALIDATION
The following experiments are proposed feasibility tests and do not
represent completed experimental results.
Experiment 1 — Concurrent Incompatible Modification
Objective: Determine whether two concurrently authorized agents can
produce conflicting modifications to the same protected resource.
Procedure: Submit incompatible operations concurrently, vary their
relative arrival times, and inspect committed protected state and
actual sink events.
8.1.3.40. Source page 287 of the original specification
Expected security property: No pair of effectuation events violates
the defined protected serialization or compatibility constraint.
Experiment 2 — Cross-Application Resource Alias Conflict
Objective: Determine whether operations targeting different
application aliases of the same protected resource are classified
consistently.
Procedure: Register an authenticated resource-equivalence mapping and
submit operations through distinct application interfaces.
Expected security property: The relevant conflicting operations are
subjected to the same protected effect-domain constraint.
Experiment 3 — Stale Reservation Replay
Objective: Test whether an agent suspended under an old reservation
can act after a newer reservation becomes authoritative.
Procedure: Suspend Agent A, supersede its reservation under the
applicable protected protocol, then resume Agent A.
Expected security property: The Finality Sink rejects the stale
operation.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 4 — Aggregate Consumption Control
Objective: Test enforcement of a shared protected consumption limit
across independent agents.
Procedure: Issue individually valid operations whose combined
consumption exceeds the configured allowance.
Expected security property: The protected reservation and sink-
enforcement sequence prevents excess authorized consumption within
the stated test model.
Experiment 5 — Unknown Remote Effect Outcome
Objective: Test whether missing acknowledgement causes premature
release of conflicting authority.
Procedure: Permit an effectuation attempt, simulate successful
external completion while suppressing its acknowledgement, and submit
a conflicting operation.
Expected security property: The unresolved attempt remains
appropriately fenced until sufficient outcome evidence is obtained.
Experiment 6 — Coordinator Failure
Objective: Test protected reservation recovery following process
termination.
Procedure: Crash the coordinator at selected stages before and after
reservation commitment.
Expected security property: Recovery reconstructs a valid protected
state and does not expose an independently usable unauthorized
reservation.
8.1.3.41. Source page 288 of the original specification
Experiment 7 — Operation Payload Substitution
Objective: Test binding of protected conflict authority to the actual
effect.
Procedure: Authorize one operation and replace its resource,
destination, amount, or operation semantics before sink verification.
Expected security property: The Finality Sink rejects any materially
different operation outside the permitted scope.
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 8 — Compatible Parallelism
Objective: Test that the architecture does not unnecessarily
serialize all agent operations.
Procedure: Execute operations with verified disjoint effect domains
or explicitly permitted commutative semantics.
Expected technical property: Compatible operations proceed
concurrently while required protected constraints remain satisfied.
Experiment 9 — Network Partition
Objective: Test exclusive reservation safety across disconnected
effect domains.
Procedure: Partition communication between the coordinator and
selected domains while introducing competing operations.
Expected security property: No protected sink accepts a reservation
that violates the defined exclusive ownership or fencing invariant.
Experiment 10 — Unauthorized Alternate Execution Route
Objective: Evaluate the coverage of an implementation's designated
effectuation boundaries.
Procedure: Attempt to produce a conflicting effect through a
secondary interface.
Expected security property: Within the stated enforcement coverage,
the secondary route cannot bypass mandatory conflict reservation
verification.
A path outside the implementation's actual protected coverage must be
documented as a limitation rather than misreported as a successful
security test.
1.22 — TECHNICAL EFFECTS AND MEASURABLE ADVANTAGES
The disclosed mechanism is intended to provide one or more of the
following technical effects.
1.22.1 — Cross-Agent Consistency
The system may prevent combinations of independently authorized
operations from violating explicitly represented protected effect
constraints.
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
1.22.2 — Enforcement Independent of Agent Cooperation
8.1.3.42. Source page 289 of the original specification
The system may prevent an incompatible operation from becoming
effective through a controlled Finality Sink even when the requesting
agent ignores advisory coordination messages.
1.22.3 — Reduced Stale-Execution Risk
The system may reject operations whose protected reservations have
been superseded between authorization and effectuation.
1.22.4 — Cross-Application Effect Identity
The system may identify interference involving resources exposed
through different applications or service interfaces where suitable
authenticated equivalence information is available.
1.22.5 — Consequence-Aware Conflict-State Updates
The system may avoid prematurely releasing protected reservations
following ambiguous or partially completed external effects.
1.22.6 — Preservation of Permitted Parallelism
The architecture may allow independently verified compatible
operations to proceed concurrently instead of serializing all agent
actions by default.
1.22.7 — Modular Integration
The mechanism may be integrated with existing protected execution-
finality systems without requiring redesign of unrelated semantic,
privacy, model-integrity, or application-authority components.
1.22.8 — Independent Auditability
Authenticated reservation, effectuation, and outcome-state
commitments may provide evidence concerning the enforced relationship
among independently executed Candidate Acts.
Actual achievement of these effects should be verified under defined
implementations and test conditions rather than presumed solely from
the architectural description.
1.23 — TECHNICAL DISTINCTIONS FROM ESTABLISHED MECHANISMS
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The present embodiment does not characterize ordinary database
transactions, locking, optimistic concurrency control, fencing
tokens, semantic conflict detection, capability authorization, or AI-
agent orchestration individually as newly invented techniques.
Those mechanisms form part of the relevant technological background.
The particular proposed technical distinction concerns an arrangement
in which:
1. An independently authorized Candidate Act is represented through
a verified or conservatively bounded effect footprint;
2. The footprint is evaluated against protected conflict state
spanning the relevant effect domains;
8.1.3.43. Source page 290 of the original specification
3. A protected reservation is committed for the operation;
4. The reservation is bound to the operation's scoped execution
authority;
5. The actual pending operation is independently checked at its
designated effectuation boundary;
6. The effectuation boundary verifies the currently applicable
reservation and fencing state;
7. Protected arbitration state is reconciled according to the actual
effect status rather than solely agent-reported success; and
8. Uncertain consequential outcomes preserve appropriate conflict
constraints until safely resolved.
Whether the full arrangement, or a narrower combination of its
features, involves an inventive step over the closest prior art
requires examination of the actual prior disclosures, their
permissible combinations, and the technical effects established by
the claimed arrangement.
The specification does not presume that use of multiple known
components automatically supplies an inventive step.
1.24 — IMPLEMENTATION ALTERNATIVES AND DESIGN VARIANTS
The following alternatives are non-limiting.
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Variant A — Single Protected Coordinator
All relevant effect domains participate through one protected
arbitration service.
Variant B — Distributed Protected Coordinator
Multiple protected authority services coordinate authenticated
reservation state.
Variant C — Integrated Sink Arbitration
The Finality Sink itself performs or participates in protected
effect-conflict evaluation.
Variant D — Separate Graph and Reservation Components
Graph construction and protected reservation commitment occur in
distinct authenticated components.
Variant E — Hardware-Rooted Arbitration
Protected reservation state and applicable authentication material
are maintained in a hardware-isolated domain.
Variant F — Remote Protected Arbitration
Conflict state is evaluated remotely while local Finality Sinks
independently verify the applicable authority before effectuation.
8.1.3.44. Source page 291 of the original specification
Variant G — Operation-Schema-Based Footprints
Effect footprints are generated from authenticated deterministic
application schemas.
Variant H — Controller-Observed Footprints
Effect footprints are obtained from actual operation parameters at a
controlled effectuation boundary.
Variant I — Conservative Unknown-Effect Handling
Operations lacking sufficient trustworthy footprint information are
treated as broadly conflicting or withheld.
Variant J — Protected Aggregate Constraints
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Multi-operation constraints are evaluated through authenticated
aggregate resource state or hypergraph relationships.
Variant K — Single-Use Conflict Reservations
Each reservation is consumed by one specific effectuation attempt.
Variant L — Bounded Compatible Reservation Group
One protected reservation governs a strictly defined group of
compatible sub-operations.
Variant M — Optional Independent Outcome Verification
A protected effect observer verifies completion before conflict-state
advancement.
Variant N — Optional IEV Integration
An Interim Effectuation Validator independently determines
continuation eligibility after a prior phase.
Variant O — No IEV Implementation
The protected coordinator reconciles conflicts using independently
trustworthy local sink or resource-controller state without an
additional IEV.
Variant P — Privacy-Preserving Effect Identity
Sensitive resource identifiers are replaced by authenticated
commitments or protected comparison results.
Variant Q — Protected Offline Reservation
A device receives a narrowly bounded offline reservation whose
effectuation constraints remain enforceable locally without reliance
on unavailable current remote state.
Variant R — Multi-Principal Arbitration
8.1.3.45. Source page 292 of the original specification
Conflict evaluation additionally enforces constraints associated with
multiple independently authorized principals.
Variant S — Physical Actuation Conflict Governance
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The effect domains represent actuators, physical resources, bounded
operating envelopes, or real-world control constraints.
Variant T — Software-Assisted Reference Implementation
The protocol is implemented using isolated services for feasibility
evaluation, with hardware-rooted protection added where the claimed
security model requires it.
The alternatives may be combined where their technical conditions are
compatible.
The embodiments are not limited to a particular graph representation,
cryptographic primitive, database implementation, consensus
mechanism, hardware provider, application framework, or operating
system.
1.25 — RELATIONSHIP TO OPTIONAL PHASED EFFECTUATION
The present embodiment may be combined with the optional phased-
effectuation architecture described in Embodiment 2.
In such a combination, an initial protected reservation may authorize
only a bounded first consequential phase.
Following the first phase, a PER or equivalent authenticated effect
record may be supplied to the IEV.
The IEV independently verifies whether the actual outcome satisfies
the conditions required for the next phase.
A subsequent PECR and scoped finality authority may be generated for
the next phase.
An earlier conflict reservation does not authorize unlimited later
effects.
Where the first-phase outcome is unknown, conflicting continuation
operations remain withheld according to the applicable protected
state.
This optional combination may provide stronger protection for multi-
step workflows whose later operations depend upon the actual results
of earlier operations.
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
However, the PCECA mechanism is independently implementable without
requiring a separate IEV where trustworthy conflict-relevant state
can be obtained through the applicable protected execution and
effectuation infrastructure.
1.26 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
The embodiment provides technical disclosure supporting consideration
of claim limitations directed to one or more of the following:
8.1.3.46. Source page 293 of the original specification
1. Construction of a machine-verifiable effect footprint for an
independently authorized Candidate Act;
2. Authentication or protected derivation of effect-domain
relationships;
3. Generation of a protected effect-interference graph;
4. Evaluation of pairwise and higher-order effect constraints;
5. Protected conflict-reservation commitment;
6. Binding of a committed reservation to a scoped non-bearer
execution authority;
7. Sink-local reconstruction of actual pending operation parameters;
8. Sink-local verification of current protected conflict-state
validity;
9. Rejection of stale or superseded reservation authority;
10. Independent protection of aggregate resource-consumption
constraints;
11. Protected conflict-state reconciliation using actual-effect
evidence;
12. Preservation of conflict fences during ambiguous outcome states;
13. Authenticated cross-domain reservation coordination;
14. Protected resource-alias and effect-equivalence resolution;
15. Optional independently validated phased continuation;
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
16. Fail-closed handling of mandatory conflict predicates;
17. Protected rollback-resistant reservation state;
18. Distributed or hardware-isolated implementation variants.
The existence of disclosure support for a feature does not, by
itself, establish that the feature is patentable.
Claim drafting should identify the specific combination responsible
for the asserted technical improvement and should account for
established concurrency-control, cryptographic authorization, and
protected execution techniques.
1.27 — INDUSTRIAL APPLICABILITY
The disclosed architecture may be applied in systems where
independently operating computational agents perform consequential
operations over shared resources, overlapping authority domains, or
interacting effectuation boundaries.
Illustrative fields include:
• Autonomous AI assistant platforms;
8.1.3.47. Source page 294 of the original specification
• Mobile and desktop operating systems;
• Multi-agent enterprise applications;
• Financial transaction automation;
• Distributed storage and document services;
• Autonomous software-development systems;
• Industrial automation;
• Robotics and vehicle systems;
• Cloud and edge orchestration;
• Communications platforms;
• Digital commerce services;
• Protected device-management infrastructure;
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
• Multi-provider AI execution environments.
The technical mechanism is applicable independently of whether any
particular jurisdiction requires third-party platform
interoperability.
Its practical adoption depends upon integration with the relevant
protected state, application-operation, and effectuation boundaries.
1.28 — NON-LIMITING SUMMARY OF THE EMBODIMENT
The present embodiment provides a protected cross-agent effect-
conflict arbitration architecture in which independently authorized
Candidate Acts are evaluated for consequential interference before
the relevant operations are permitted to become effective.
A Protected Effect Footprint identifies the effect domains, resource
relationships, operation semantics, and protected constraints
associated with a Candidate Act.
A protected arbitration mechanism constructs or updates an Effect-
Interference Graph and determines whether the Candidate Act may
proceed concurrently, must be ordered, requires exclusive
reservation, depends upon an earlier effect, or must be withheld.
For an admissible operation, a Protected Effect-Conflict Reservation
is committed against authenticated conflict state.
A Protected Graph-Fencing Commitment binds the reservation to the
specific Candidate Act, its effect footprint, protected state
version, and designated effectuation boundary.
The applicable Finality Sink independently verifies the actual
pending operation and its current reservation authority before
permitting the corresponding consequential effect.
8.2. Embodiment 7: Cross-Provider Delegation Lineage and Effect-
Semantic Scope Attenuation
Original specification global pages 723-786 (inclusive). Source
file: TECHNICAL SPECIFICATION -555-1062.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.2.1. Protected Components and Trust-Relationship Architecture Diagram
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[Original principal / source grant]
|
[Agent A / Provider 1]
| signed bounded delegation
[Agent B / Provider 2]
| attenuated authority
[Agent C / Device or tool]
|
[Protected delegation lineage]
|
[Destination authority and revocation]
|
[Destination Finality Sink / actual effect]
Figure 15: Embodiment 7: Cross-Provider Delegation Lineage and
Effect-Semantic Scope Attenuation — source-based architecture
8.2.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Move task to delegate/provider]
|
<Authenticated origin and delegate?>--NO-->[REFUSE]
|YES
<Delegated effect subset of parent?>--NO-->[REFUSE]
|YES
<Current revocation and scope?>--NO-->[WITHHOLD]
|YES
[Form destination-scoped finality]
|
<Sink actual operation within lineage?>--NO-->[REFUSE]
|YES
[Protected consume, release]
Figure 16: Embodiment 7: Cross-Provider Delegation Lineage and
Effect-Semantic Scope Attenuation — technical flowchart
8.2.3. Original Global Page-Indexed Technical Description
8.2.3.1. Source page 723 of the original specification
The novelty and inventive step of particular claimed combinations
remain subject to the relevant prior-art examination.
END OF EMBODIMENT 6 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 7
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
PROTECTED CROSS-PROVIDER AUTONOMOUS AGENT AUTHORITY CONTINUITY WITH
CRYPTOGRAPHIC DELEGATION LINEAGE, EFFECT-BOUND AUTHORITY ATTENUATION,
DOMAIN-LOCAL FINALITY ENFORCEMENT, IDENTITY REBINDING, AND NON-
BYPASSABLE CONSUMPTION CONTROL
7.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Maintaining Protected Execution-Finality
Authority Across Independently Administered Autonomous Agents,
Applications, Devices, and Computing Domains Using Cryptographically
Authenticated Delegation Lineage, Effect-Semantic Scope Attenuation,
Destination-Side Actual-Operation Reconstruction, Protected Authority
Ownership and Consumption, Revocation Continuity, and Non-Bearer
Cross-Domain Execution Enablement
7.0.1 — General Technical Description
The present embodiment discloses systems, methods, apparatus,
protected computing components, authenticated authority-transfer
protocols, machine-verifiable delegation structures, protected state
transitions, cryptographic identity mechanisms, domain-local
enforcement controllers, and non-limiting implementations for
maintaining the continuity of operation-specific execution authority
as an autonomous task passes among independently administered
computational entities.
The computational entities may comprise artificial-intelligence
assistants, autonomous agents, application services, distributed task
executors, tool providers, operating-system processes, embedded
systems, cloud services, edge devices, hardware controllers, or other
computational entities capable of initiating consequential
operations.
A task may originate under authority established for an initial
computational entity and subsequently be delegated, subdivided,
transferred, migrated, or collaboratively executed by one or more
other entities.
The participating entities may operate within a common administrative
domain or across separate providers, devices, security environments,
execution runtimes, or trust jurisdictions.
The present architecture distinguishes the ability to receive and
compute a delegated task from the protected authority required to
produce consequential effects on behalf of the original principal.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A downstream agent may receive information describing the task
without receiving unrestricted access to the originating principal's
credentials, resources, or execution rights.
Where the downstream agent proposes a consequential operation, the
receiving domain independently evaluates the applicable source
authority, delegation lineage, permitted effect envelope, local
security constraints, current revocation state, and actual pending
operation.
A designated destination Finality Sink permits the operation only
after the relevant protected authorization conditions have been
established.
8.2.3.2. Source page 724 of the original specification
7.0.2 — Fundamental Technical Principle
The principal technical principle is:
Moving an autonomous task across an agent, provider, device, or
administrative boundary does not enlarge the authority originally
available to produce consequential effects.
A downstream entity may perform computation, planning, or analysis
independently.
However, an operation that produces a governed external consequence
must remain within the permissible authority derived from the
original or otherwise validly amended authorization.
An authenticated delegation does not, by itself, authorize every
action the receiving agent can technically perform.
An authenticated receiving provider does not automatically become a
universal authority for the original user's resources.
Likewise, moving computation to a more privileged environment does
not automatically increase the permitted consequential scope.
7.0.3 — Principal Proposed Inventive Concept
The proposed technical contribution concerns the protected
relationship among:
The original authorized effect envelope;
A verifiable source-authority identity;
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
One or more authenticated delegation transitions;
Protected effect-specific authority attenuation;
The receiving domain's independent authorization requirements;
Destination-specific authority formation;
Actual operation reconstruction at the receiving Finality Sink;
And protected consumption, revocation, and ownership state.
In a principal implementation, each cross-domain authority transition
is bound to the identity of the delegating entity, the authenticated
receiving entity, the permitted consequential scope, the originating
authority, and the relevant downstream enforcement conditions.
The destination Finality Sink independently verifies the actual
operation against that authority lineage.
The sink does not permit an operation merely because it receives an
apparently valid delegation message or a reusable credential.
7.0.4 — Difference Between Task Transfer and Authority Transfer
A task description may be transferred without any authority to
produce an external effect.
8.2.3.3. Source page 725 of the original specification
A computational result may be returned without granting authority
over a resource.
A narrow delegated authority may permit a particular effect at a
destination sink.
An exclusive authority migration may transfer the right to perform an
unfinished effect from one device or domain to another while fencing
the previous owner.
These arrangements are technically distinct.
The present embodiment supports each arrangement without treating
every task handoff as an unrestricted transfer of the originating
principal's authority.
7.0.5 — Relationship to Existing Common Workflows
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The embodiment may incorporate Candidate Acts, Non-Effective State,
Protected Enforcement Domains, scoped non-bearer finality authority,
actual-operation reconstruction, and Finality Sink mechanisms from
Common Master Workflow CW-1.
Where a successor operation depends upon a required earlier real
effect, the optional causal receipt mechanism of CW-2 may apply.
Where a proposed delegation or downstream operation departs from the
authorized task scope, the optional scope-revalidation mechanisms of
CW-3 may apply.
The present embodiment does not make an Interim Effectuation
Validator mandatory for every delegated operation.
Instead, the principal focus is the protected continuity and non-
expansion of authority across administrative boundaries.
7.0.6 — Relationship to Completed Embodiments
Embodiment 1 may govern protected conflicts among concurrently
operating delegated agents.
Embodiment 2 may govern causally dependent real-effect phases.
Embodiment 3 may govern correspondence between originally authorized
resource references and actual downstream targets.
Embodiment 4 may govern independently supported evidence concerning
external consequences.
Embodiment 5 may govern protected shared-resource allocations among
independently administered agents.
Embodiment 6 may govern action-contract evolution where a receiving
provider executes a different tool or software version.
Miscellaneous Embodiment M-1 may supply additional effectuation-path
coverage and cross-interface resource correspondence mechanisms.
The present embodiment develops the cross-provider authority-
continuity mechanisms without requiring amendment of the earlier
embodiments.
8.2.3.4. Source page 726 of the original specification
7.1 — TECHNICAL FIELD
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The present embodiment relates to autonomous-agent security,
distributed authorization, protected execution-finality control,
cryptographic workload identity, delegated capability security,
cross-domain task orchestration, authenticated service communication,
multi-party computing, protected credential custody, device
migration, distributed state consistency, and mandatory
consequential-boundary enforcement.
More particularly, the embodiment concerns the technical preservation
of permitted consequential authority when an autonomous task crosses
one or more administrative or computing boundaries.
The architecture may be implemented in presently available
distributed computing infrastructure and extended to future
autonomous agent ecosystems, heterogeneous devices, confidential
computing environments, industrial systems, and machine-to-machine
operation networks.
No particular provider, model, operating system, communication
protocol, cryptographic algorithm, or commercial service is
essential.
7.2 — SPECIFIC TECHNICAL PROBLEMS
7.2.1 — Authority Expansion During Delegation
An agent may receive authorization to perform a narrow operation.
The agent may then invoke a downstream service possessing broader
permissions.
Without protected lineage verification, the downstream service may
perform an effect that exceeds the original authorization.
The existence of broader technical capability at the destination does
not establish that the original user authorized its exercise.
7.2.2 — Credential Laundering
A privileged intermediary may use its own broad credentials to
execute an operation for a less privileged requesting agent.
If the destination checks only the intermediary's identity, the
original authority limitation may be lost.
The system therefore requires operation-specific authorization
continuity rather than treating a privileged intermediary's identity
as sufficient authority.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.2.3 — Identity Discontinuity
An original agent, downstream agent, and destination controller may
possess unrelated identities.
A request may pass across several identity namespaces.
Without protected mappings, the final controller may be unable to
establish which original principal authorized the actual effect.
8.2.3.5. Source page 727 of the original specification
7.2.4 — Delegation Chain Truncation
An intermediate agent may forward only the latest authorization
reference and omit earlier restrictions.
The destination may incorrectly interpret the remaining reference as
unrestricted authority.
7.2.5 — Authorization Scope Translation
Different providers may describe operations, resources, or privileges
using different schemas.
A narrow source permission may be translated into a broader
destination permission.
For example, permission to read one document may be mapped to
permission to access an entire storage repository.
7.2.6 — Untrusted Tool Invocation
A downstream agent may invoke a tool with side effects that were not
contemplated by the original authorization.
The destination must evaluate the actual effect rather than relying
exclusively upon the delegated task description.
7.2.7 — Multi-Hop Delegation
A task may pass through several intermediaries.
An authority limitation may be lost, transformed, or relaxed at any
transition.
The system must preserve a verifiable relationship to the applicable
originating authority.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.2.8 — Concurrent Delegation
An originating agent may delegate different branches of a task to
multiple agents.
Each branch may be independently permitted while their combined
effects violate a common budget, resource constraint, or exclusivity
condition.
7.2.9 — Stale Authority After Revocation
The original principal may revoke authorization after a delegation
has been issued.
A downstream agent may attempt to use cached authority after
revocation.
7.2.10 — Migration Without Fencing
An unfinished task may move from one provider to another.
The previous execution environment may retain authority and continue
operating.
This may produce duplicate or conflicting consequential effects.
7.2.11 — Replay Across Providers
8.2.3.6. Source page 728 of the original specification
An authenticated delegation object may be copied and presented to
another provider, sink, resource, or operation.
Authentication alone does not ensure that the recipient or use is
authorized.
7.2.12 — Incomplete Cross-Domain Observation
An originating domain may receive a message stating that a downstream
operation succeeded.
The message may establish request acceptance without proving the
intended remote consequence.
7.2.13 — Unilateral Remote Enforcement Assumptions
A source system may issue a restricted authority object to a
destination that does not enforce its restrictions.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A cryptographic restriction has limited effect if the destination can
produce the same consequence through an unrestricted path.
7.2.14 — Cross-Domain Availability and Partitions
An authority registry or revocation service may become unavailable.
The system must define which operations may continue under bounded
offline authority and which must be withheld.
7.2.15 — Objective Technical Problem
An illustrative objective technical problem is:
How to maintain operation-specific, non-expanding execution authority
when autonomous tasks are delegated, transferred, or migrated among
independently administered computational entities, such that each
consequential operation remains bound to authenticated source
authority and current protected state and is independently verified
against the actual pending effect at the destination Finality Sink.
7.3 — CONVENTIONAL TECHNIQUES AND THEIR LIMITATIONS
7.3.1 — Conventional Service Authentication
A service-authentication protocol may establish the identity of a
downstream service.
Authentication does not automatically establish that the service is
permitted to exercise the original principal's authority for a
particular consequential operation.
7.3.2 — Conventional Delegated Access Tokens
Delegated access-token systems can convey authorization information
and restricted scopes.
They are established technology.
8.2.3.7. Source page 729 of the original specification
The proposed stronger implementation may additionally require
protected source-authority lineage, actual effect-semantic
attenuation, destination-specific finality binding, and independent
sink-local operation verification.
7.3.3 — Conventional Token Exchange
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A system may exchange one authorization token for another intended
for a different audience.
This mechanism is established.
However, token exchange alone does not guarantee that the
destination's actual effect remains a subset of the original
authorized consequence.
7.3.4 — Sender-Constrained Credentials
A credential may be bound to a particular sender, key, or
authenticated channel.
This can reduce unauthorized credential replay.
Such sender constraints do not automatically establish effect-
specific authorization, complete delegation lineage, or actual
operation correspondence.
7.3.5 — Conventional Capability Attenuation
Capability systems may support derivation of narrower authorities.
Such attenuation is established.
The present embodiment's candidate contribution must therefore focus
upon specific additional technical relationships, including cross-
domain effect-semantic correspondence, independent destination-sink
reconstruction, protected consumption, and ownership continuity.
7.3.6 — Conventional Workflow Orchestration
A workflow engine may forward tasks among agents and services.
A task dependency or orchestration instruction does not necessarily
prevent a receiving service from producing unauthorized effects
through its broader privileges.
7.3.7 — Conventional Service Meshes
A service mesh may authenticate workloads, encrypt communications,
and apply network policies.
Such mechanisms can form part of the present implementation.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
However, service-to-service authentication does not necessarily
verify the originating principal's permitted effect at the ultimate
consequential boundary.
7.3.8 — Conventional Audit Logs
A log may record delegation and execution events.
A completed audit trail does not necessarily prevent an unauthorized
consequential operation.
8.2.3.8. Source page 730 of the original specification
7.3.9 — Conventional Distributed Transactions
Distributed transaction protocols may coordinate state transitions
among participating systems.
They do not automatically establish that each participating
autonomous agent possessed the appropriate originating user
authority.
7.3.10 — Conventional Task Migration
A computing task may move between devices or service providers.
Copying task state does not necessarily transfer protected authority
safely or invalidate a former owner's authority.
7.4 — PRINCIPAL PROPOSED INVENTIVE KERNEL
A principal implementation comprises:
An originating authorized Candidate Act or effect envelope;
An authenticated source-authority commitment;
A protected delegation event associating a permitted successor entity
with a narrower or otherwise non-expanded consequential scope;
A cryptographically verifiable delegation-lineage representation;
An authenticated receiving-domain verification procedure;
A destination-specific protected finality authorization;
A Finality Sink that independently obtains or reconstructs the actual
pending operation;
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
And protected consumption or ownership state preventing unauthorized
replay, expansion, or stale continuation.
The receiving-domain Finality Sink evaluates the actual operation
under both the applicable source-derived constraints and its own
mandatory local constraints.
A downstream entity does not gain greater authority merely because it
possesses broader native credentials or a more privileged execution
environment.
The system may support one or more delegation hops.
Each additional hop preserves a verifiable relationship to the
applicable originating authority.
7.5 — BROAD TECHNICAL DEFINITIONS
7.5.1 — Originating Authority Domain
An Originating Authority Domain, or OAD, means a protected
administrative or technical domain in which the relevant original
consequential authority is established.
8.2.3.9. Source page 731 of the original specification
7.5.2 — Receiving Execution Domain
A Receiving Execution Domain, or RED-7, means a domain that receives
a task, delegated operation, or authority request from another
domain.
7.5.3 — Originating Effect Envelope
An Originating Effect Envelope, or OEE, means a protected
representation of the consequences permitted by the originating
authority.
7.5.4 — Cross-Domain Authority Continuity
Cross-Domain Authority Continuity means preservation of the
applicable original authorization restrictions throughout one or more
task transfers, delegation events, or execution migrations.
7.5.5 — Protected Authority Lineage
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Protected Authority Lineage, or PAL-7, means an authenticated
relationship among an original authority and one or more derived,
delegated, or migrated authorities.
7.5.6 — Delegation Transition Record
A Delegation Transition Record, or DTR, means a protected
representation of an authority transition from a delegating entity to
a receiving entity.
7.5.7 — Authority Attenuation Predicate
An Authority Attenuation Predicate, or AAP, means a machine-
verifiable condition establishing that a downstream authority does
not exceed its permitted predecessor authority.
7.5.8 — Cross-Domain Authority Continuity Record
A Cross-Domain Authority Continuity Record, or CACR, means an
authenticated record binding the originating authority, delegation
lineage, receiving domain, permitted effects, and relevant protected
state.
7.5.9 — Destination Finality Authorization
Destination Finality Authorization, or DFA, means scoped authority
recognized by the receiving Finality Sink and applicable to a
specified actual consequential operation.
7.5.10 — Domain-Local Finality Sink
A Domain-Local Finality Sink, or DLFS, means a protected effectuation
boundary within a receiving domain that independently verifies the
actual pending operation under applicable source-derived and local
authority constraints.
7.5.11 — Provider-Neutral Effect Descriptor
A Provider-Neutral Effect Descriptor, or PNED-7, means a machine-
verifiable representation of the consequential operation that does
not depend upon the specific commercial identity or native API syntax
of a provider.
8.2.3.10. Source page 732 of the original specification
7.5.12 — Protected Identity Rebinding
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Protected Identity Rebinding means an authenticated procedure
associating the original authority and receiving entity's identity
without permitting unauthorized expansion of authority.
7.5.13 — Source-Authority Commitment
A Source-Authority Commitment, or SAC, means a protected reference
binding the original permitted effect, authority origin, relevant
identity, and current validity state.
7.5.14 — Delegation Generation
A Delegation Generation means an identified transition depth, epoch,
or sequence position in an authenticated authority lineage.
7.5.15 — Delegation Depth Limit
A Delegation Depth Limit means a protected constraint restricting the
permitted number or structure of downstream delegation transitions.
7.5.16 — Delegated Effect Budget
A Delegated Effect Budget, or DEB, means a protected bound on the
quantity, cost, count, duration, or other resource measure of
consequential effects that may be performed under a delegated
authority.
7.5.17 — Shared Delegation Budget State
Shared Delegation Budget State, or SDBS, means authoritative
protected state accounting for consumption across multiple
delegations derived from a common permitted budget.
7.5.18 — Authority Ownership Epoch
An Authority Ownership Epoch, or AOE, means a protected generation
identifying the current owner or authorized execution location of an
exclusive unfinished authority.
7.5.19 — Protected Delegation Fence
A Protected Delegation Fence, or PDF-7, means a protected constraint
preventing unauthorized use of stale, transferred, revoked, or
superseded authority.
7.5.20 — Cross-Domain Authority Lease
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Cross-Domain Authority Lease, or CDAL, means a bounded
authorization permitting a receiving entity to exercise a defined
scope under specified validity, consumption, and revocation
conditions.
7.5.21 — Non-Bearer Delegation Enablement
Non-Bearer Delegation Enablement means an authority mechanism whose
valid exercise depends upon authenticated recipient identity,
designated sink, protected state, or other binding conditions beyond
possession of an object.
8.2.3.11. Source page 733 of the original specification
7.5.22 — Protected Recipient Binding
Protected Recipient Binding means an authenticated association
between delegated authority and the permitted receiving agent,
execution environment, service, or domain.
7.5.23 — Protected Sink Binding
Protected Sink Binding means an authenticated association between
delegated authority and the Finality Sink permitted to exercise it.
7.5.24 — Cross-Domain Effect Correspondence
Cross-Domain Effect Correspondence means a verified relationship
between the consequential operation described in the originating
domain and the actual operation performed in the receiving domain.
7.5.25 — Destination Contract Commitment
A Destination Contract Commitment, or DCC, means a protected binding
to the relevant current operation semantics of the receiving domain.
7.5.26 — Delegation Consumption Reference
A Delegation Consumption Reference, or DCR, means a protected
reference controlling single-use or bounded exercise of delegated
authority.
7.5.27 — Protected Delegation Acceptance
Protected Delegation Acceptance means authenticated acceptance of a
specified delegated authority and its technical restrictions by an
authorized receiving component.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.5.28 — Delegation Continuity Verification
Delegation Continuity Verification means checking the source
authority, delegation chain, recipient identity, current scope,
destination operation, and relevant protected state.
7.5.29 — Cross-Domain Revocation Reference
A Cross-Domain Revocation Reference, or CDRR, means a protected
identity or state reference used to determine whether relevant
originating or derived authority remains valid.
7.5.30 — Outcome Reconciliation Fence
An Outcome Reconciliation Fence means protected state preventing
unsafe retry or continuation while the status of an earlier
consequential operation remains uncertain.
7.5.31 — Protected Delegation Challenge
A Protected Delegation Challenge means an authenticated verification
request seeking proof that a particular downstream effect remains
within its source-derived authority.
7.5.32 — Cross-Domain Authority Equivalence
8.2.3.12. Source page 734 of the original specification
Cross-Domain Authority Equivalence means satisfaction of a defined
protected relation between authority representations used in
different administrative or technical domains.
7.5.33 — Authority Laundering
Authority Laundering means an unauthorized attempt to cause a
downstream component to exercise its broader native privileges for a
consequential operation exceeding the applicable source-derived
authority.
7.5.34 — Protected Task Continuation
Protected Task Continuation means continuation of a task by another
computational entity without enlarging the permitted consequential
authority.
7.5.35 — Domain-Local Policy Intersection
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Domain-Local Policy Intersection means the effective authority
resulting from satisfaction of both applicable source-derived
restrictions and mandatory receiving-domain constraints.
7.6 — PROTECTED SYSTEM ARCHITECTURE
A representative implementation comprises an originating authority
controller, a protected delegation service, a cryptographic identity
registry, a provider-neutral effect descriptor generator, an
authenticated lineage store, a receiving-domain verification service,
a destination authority controller, and one or more Domain-Local
Finality Sinks.
The system may additionally comprise a credential broker, a protected
budget controller, an exclusive-ownership controller, a revocation
service, an action-contract verifier, and an actual-outcome
observation component.
7.6.1 — Originating Authority Controller
The originating controller establishes the original permitted effect
envelope.
It may authenticate the initial principal and verify applicable task
authority.
7.6.2 — Delegation Controller
The delegation controller evaluates whether the proposed downstream
authority is within the source authority.
It produces an authenticated DTR or equivalent protected transition
state.
7.6.3 — Identity Service
The identity service establishes authenticated identities for the
relevant agents, services, devices, and protected controllers.
7.6.4 — Authority Lineage Store
The lineage store maintains or references the authenticated
relationship among source authority and downstream delegations.
8.2.3.13. Source page 735 of the original specification
It may reside in one protected component or several cooperating
domains.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.6.5 — Receiving-Domain Verifier
The receiving-domain verifier authenticates the delegation evidence
and evaluates its applicability under the destination's trust and
authorization rules.
7.6.6 — Destination Authority Controller
The destination authority controller creates, activates, or validates
scoped local finality authority.
It does not automatically convert every source authorization into
unrestricted destination privileges.
7.6.7 — Destination Finality Sink
The DLFS reconstructs the actual pending operation and verifies the
permitted source-derived and local authorization conditions.
7.6.8 — Protected Consumption Controller
The consumption controller maintains the state necessary to prevent
unauthorized repeated or concurrent exercise of delegated authority.
7.6.9 — Revocation Controller
The revocation controller maintains applicable current authorization
epochs, invalidation state, or bounded lease validity.
7.6.10 — Integrated and Distributed Forms
The listed components may exist within a single protected service,
hardware controller, or distributed cross-domain arrangement.
Their physical separation is not universally required.
Their protected enforcement responsibilities remain applicable
according to the selected implementation.
7.7 — ORIGINATING AUTHORITY ESTABLISHMENT
7.7.1 — Original Principal
An originating principal may authorize a computational entity to
perform a defined task.
The principal may be a user, enterprise, device controller, protected
service, or another valid authority source.
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.7.2 — Original Candidate Act
The permitted consequential operation is represented as a Candidate
Act or equivalent protected operation descriptor.
8.2.3.14. Source page 736 of the original specification
7.7.3 — Effect Envelope
The OEE identifies permitted effects, resources, destinations,
quantities, privileges, time conditions, and other applicable bounds.
7.7.4 — Protected Identity
The originating authority is bound to an authenticated identity or
trust-domain reference.
7.7.5 — Source-Authority Commitment
The protected controller commits the original authority and relevant
current-state references.
7.7.6 — Delegation Permission
The original authority may expressly permit or prohibit downstream
delegation.
A task may be computationally transferable even where authority to
execute its effects is not delegable.
7.7.7 — Delegation Constraints
The authority may restrict delegate classes, permitted domains,
delegation depth, allowable operations, and shared effect budgets.
7.7.8 — Original Authority Without Delegation
Where delegation is not permitted, a receiving agent may be permitted
to perform unprivileged computation but does not receive authority
for the consequential operation.
7.8 — CRYPTOGRAPHIC IDENTITY AND CROSS-DOMAIN TRUST
7.8.1 — Domain Identities
Each relevant protected domain may possess an authenticated
identifier within its trust infrastructure.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.8.2 — Agent Identities
A computational agent may possess a cryptographically verifiable
identity associated with its operating domain.
7.8.3 — Service Identities
An application service or protected tool may possess a distinct
service identity.
7.8.4 — Finality Sink Identities
A DLFS may possess a verifiable identity bound to its resource or
effect class.
7.8.5 — Domain Trust Relationships
8.2.3.15. Source page 737 of the original specification
Different domains may rely upon different credential issuers or trust
anchors.
The receiving domain must establish a valid trust relationship for
the specific authority accepted.
7.8.6 — No Universal Global Identity Assumption
The architecture does not require every autonomous agent worldwide to
possess an identifier issued by one universal authority.
Issuer-qualified identities, authenticated trust mappings, and scoped
recognition rules may be used.
7.8.7 — Recipient Proof of Possession
Where appropriate, the receiving entity may prove possession of
credentials associated with the designated delegation recipient.
7.8.8 — Protected Identity Rebinding
The source-domain identity may be linked to a destination-domain
identity through an authenticated transition.
This rebinding does not change the permitted effect scope.
7.8.9 — Identity Rotation
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Receiving agents and protected controllers may rotate credentials
through valid authenticated state transitions.
7.8.10 — Identity Revocation
Revoked identities are rejected according to the applicable protected
revocation and lease rules.
7.8.11 — Identity Does Not Confer Universal Authority
A validly authenticated agent may be ineligible to perform a
particular consequential operation.
The destination sink must separately verify authorization.
7.9 — PROVIDER-NEUTRAL EFFECT DESCRIPTION
7.9.1 — Technical Purpose
Different providers may describe equivalent consequential operations
through different application interfaces or schemas.
The present embodiment may establish an effect-oriented
representation independent of the original syntax.
7.9.2 — Representative Structure
PROVIDER_NEUTRAL_EFFECT_DESCRIPTOR = { descriptor_version,
8.2.3.16. Source page 738 of the original specification
original_candidate_act_reference, originating_principal_reference,
consequence_class, operation_semantics, target_resource_identity,
destination_identity, permitted_data_scope,
permitted_privilege_scope, quantitative_effect_limits,
temporal_scope, applicable_dependency_conditions,
required_finality_sink_class, canonicalization_profile,
protected_descriptor_authentication } 7.9.3 — Destination Translation
The receiving domain maps the protected effect descriptor to its
actual local operation interface.
7.9.4 — Resource Equivalence
Where a destination resource identifier differs from the source
reference, the system may require an authenticated resource-
equivalence relation.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.9.5 — Semantic Narrowing
A receiving domain may implement a narrower effect than the source
authority permits.
Such narrowing may be acceptable where mandatory functional and
safety requirements remain satisfied.
7.9.6 — Semantic Expansion
A destination operation exceeding source authority cannot be accepted
as merely an alternative API representation.
7.9.7 — Unknown Correspondence
Where the effect translation cannot be established with sufficient
assurance, the destination refuses or restricts the consequential
operation.
7.9.8 — Relation to Embodiment 6
The destination's current action semantics may be verified according
to Embodiment 6 where a tool version or implementation contract
affects the actual consequence.
7.10 — AUTHORITY ATTENUATION
7.10.1 — General Principle
A delegated authority is not permitted to exceed the applicable
source authority.
8.2.3.17. Source page 739 of the original specification
7.10.2 — Resource Attenuation
The delegated authority may permit fewer resources than the original
authority.
7.10.3 — Destination Attenuation
The delegated authority may permit a narrower destination set.
7.10.4 — Operation Attenuation
The delegated authority may permit fewer consequential operation
types.
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.10.5 — Quantitative Attenuation
The delegation may impose a smaller monetary, data, resource, time,
or effect-count budget.
7.10.6 — Temporal Attenuation
The delegation may have a shorter validity period.
7.10.7 — Principal Attenuation
The authority may be limited to a particular delegate identity, role,
or receiving domain.
7.10.8 — Hardware Attenuation
The authority may be limited to a designated protected device,
controller, or resource class.
7.10.9 — Transitive Attenuation
Each downstream delegation may be required to preserve the
restrictions of all relevant predecessor authorities.
7.10.10 — Non-Expansion Predicate
A representative relationship is:
ChildEffectScope SUBSET_OF ParentPermittedEffectScope
ChildResourceScope SUBSET_OF ParentPermittedResourceScope
ChildDestinationScope SUBSET_OF ParentPermittedDestinationScope
ChildEffectBudget WITHIN ParentAvailableEffectBudget
8.2.3.18. Source page 740 of the original specification
ChildValidity WITHIN ParentValidity
ChildDelegationRights WITHIN ParentDelegationRights The precise
comparison depends upon authenticated resource identities and effect
semantics.
A mere equality check between differently formatted permission
strings is not sufficient where their meanings differ.
7.11 — PROTECTED DELEGATION TRANSITION RECORD
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A representative DTR may comprise:
DELEGATION_TRANSITION_RECORD = { protocol_version,
originating_authority_commitment, parent_authority_reference,
delegator_identity, delegate_identity, source_domain_identity,
destination_domain_identity, delegation_generation,
permitted_effect_envelope, permitted_resource_scope,
permitted_destination_scope, quantitative_limits,
delegation_depth_remaining, applicable_expiration_conditions,
authorized_successor_sinks, current_authority_epoch,
revocation_reference, consumption_reference,
parent_transition_commitment, protected_delegation_authentication }
The DTR may be represented as a signed record, protected non-
exportable state, authenticated capability reference, or equivalent
machine-verifiable structure.
A downstream agent may transport the DTR without acquiring authority
to change its protected scope.
The destination may require additional proof of possession, current
revocation verification, and sink-specific binding before enabling a
real effect.
7.12 — CRYPTOGRAPHIC DELEGATION LINEAGE
8.2.3.19. Source page 741 of the original specification
7.12.1 — Root Authority Commitment
The originating controller authenticates the initial permitted
authority.
7.12.2 — First Delegation
The first DTR binds the original authority to the first downstream
recipient and attenuated effect scope.
7.12.3 — Additional Delegations
Each additional DTR references its immediate predecessor and
applicable protected origin.
7.12.4 — Cryptographic Authentication
Each transition is authenticated by the appropriate authorized
delegator or protected delegation service.
7.12.5 — Domain Separation
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The cryptographic representation may distinguish the purpose of an
authority commitment from ordinary signed data.
7.12.6 — Canonical Representation
Security-relevant fields are encoded under an unambiguous
canonicalization profile.
7.12.7 — Lineage Verification
The destination verifies the relevant authority chain and each
mandatory attenuation relationship.
7.12.8 — Truncated Lineage
An incomplete delegation chain is not assumed valid merely because
its final record is signed.
7.12.9 — Authenticated Compression
A protected system may use compact commitments or validated summaries
of earlier delegations where the necessary authority relationships
remain independently verifiable.
7.12.10 — No Blockchain Requirement
The authenticated lineage may be maintained through conventional
protected signatures, commitments, registries, and controller-local
state.
It does not require a blockchain, mining, public ledger, or
distributed token economy.
7.13 — DESTINATION-DOMAIN AUTHORITY INTERSECTION
7.13.1 — Source Authority
8.2.3.20. Source page 742 of the original specification
The source-derived authority establishes the maximum effects
permitted through the delegation.
7.13.2 — Destination Local Policy
The receiving domain may impose additional restrictions.
7.13.3 — Effective Authority
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The effective permitted operation must satisfy both sets of
applicable restrictions.
Conceptually:
EffectiveAuthority = SourceDerivedPermittedEffects INTERSECT
DestinationLocallyPermittedEffects 7.13.4 — No Destination Privilege
Inflation
A receiving provider's broader administrative privileges do not
enlarge the source-derived authorization.
7.13.5 — No Source Override of Destination Safety
A source-domain authorization does not override mandatory local
security or safety constraints.
7.13.6 — Conflicting Policies
Where the policies cannot be simultaneously satisfied, the operation
is withheld.
7.13.7 — Protected Policy Versions
The destination may bind its decision to current local policy and
authority epochs.
7.13.8 — Auditability
A protected result may identify which constraints limited or
prevented the requested operation without disclosing unnecessary
confidential policy details.
7.14 — DESTINATION FINALITY AUTHORIZATION
After verifying source authority and local policy, a protected
destination controller may create or activate a DFA.
The DFA may be a scoped non-bearer capability, protected state
reference, authenticated command authorization, hardware-controlled
enablement, or equivalent mechanism.
The DFA is bound to the actual intended effect.
It may identify:
The authenticated receiving principal;
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.21. Source page 743 of the original specification
The valid source authority;
The current delegation lineage;
The destination resource;
The consequential operation;
The designated Finality Sink;
The current policy epoch;
The permitted effect quantity;
And the applicable consumption conditions.
A DFA does not authorize unrelated operations merely because they are
technically executable using the same destination service
credentials.
7.15 — DOMAIN-LOCAL FINALITY SINK
The receiving DLFS obtains or reconstructs the actual pending
operation.
The sink verifies the relevant source-derived authority and
destination-local authorization.
It may compare the actual target, resource identity, recipient,
operation parameters, data scope, privilege, current contract, and
consumption state.
The sink refuses effectuation if the actual operation exceeds the
permitted delegated scope.
7.15.1 — Direct Effect Verification
The sink verifies the immediate actual consequential operation.
7.15.2 — Local Resource Identity
The sink verifies that the local resource corresponds to the
authorized target.
7.15.3 — Delegation-Lineage Verification
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The sink verifies the applicable authenticated chain or a trusted
validated representation thereof.
7.15.4 — Local Policy Verification
The sink verifies current destination-specific restrictions.
7.15.5 — Current Authority Verification
The sink verifies applicable revocation, lease, and epoch state.
7.15.6 — Consumption
The sink atomically reserves or consumes the required operation-
specific authority.
8.2.3.22. Source page 744 of the original specification
7.15.7 — Credential Use
Where a reusable credential is necessary, a protected broker may
exercise it only for the verified operation.
7.15.8 — Non-Bypassability
The governed actual effect must pass through a controlled sink or
equivalent mandatory enforcement mechanism within the specified
threat model.
7.16 — NON-BEARER AUTHORITY ACROSS PROVIDERS
7.16.1 — General Principle
A copied authority object does not automatically confer the ability
to perform its associated consequence.
7.16.2 — Recipient Binding
The authority may require authentication of the designated receiving
agent or service.
7.16.3 — Sink Binding
The authority may require exercise at a particular protected
destination sink.
7.16.4 — Operation Binding
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The authority may be valid only for a specified Candidate Act or
bounded operation class.
7.16.5 — Protected State Binding
The authority may depend upon current counters, epochs, leases,
reservations, or consumption state.
7.16.6 — Proof of Possession
A recipient may be required to authenticate possession of the
corresponding protected cryptographic credentials.
7.16.7 — Protected Key Release
A destination controller may withhold the key or credential material
necessary for effectuation until the authority has been verified.
7.16.8 — Protected Command State
A destination controller may use a protected register or command
queue to enforce the authority.
7.16.9 — No Universal Bearer Grant
The delegation reference may be transported across domains without
becoming a general-purpose credential usable at arbitrary services.
8.2.3.23. Source page 745 of the original specification
7.17 — MULTI-HOP DELEGATION
A task may pass from an originating agent to a second agent, then to
a third agent or specialized service.
At each hop, an authorized delegation controller may create a further
attenuated DTR.
A principal implementation verifies that each derived authority
remains within the applicable predecessor authority.
The destination Finality Sink may verify the full lineage or an
authorized protected summary sufficient to establish the required
restrictions.
7.17.1 — Delegation Depth
A parent authority may limit the number of downstream delegations.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.17.2 — Delegation Type
A parent may permit computational delegation but prohibit
consequential authority delegation.
7.17.3 — Privilege Separation
A downstream entity may perform analysis without acquiring the
ability to effectuate a protected resource modification.
7.17.4 — Lineage Continuity
A newly issued downstream authority may retain an authenticated
reference to the originating authority.
7.17.5 — No Intermediate Enlargement
A valid intermediate signature does not permit the intermediary to
expand the original effect scope.
7.17.6 — Domain-Specific Contract Mapping
Each hop may use different local operation descriptions.
The protected system evaluates semantic attenuation rather than
relying solely upon textual scope equality.
7.17.7 — Chain-Length Constraints
The verifier may impose bounded chain length and parsing work to
prevent verification exhaustion.
7.17.8 — Delegation Cycles
An implementation may detect or restrict cyclic delegation
relationships that could cause unsupported repeated authority
issuance.
8.2.3.24. Source page 746 of the original specification
7.18 — CONCURRENT DELEGATION AND SHARED BUDGETS
7.18.1 — Multiple Delegated Branches
An originating task may authorize several parallel downstream agents.
7.18.2 — Independent Branch Scopes
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Each agent may receive a distinct permitted effect subset.
7.18.3 — Shared Global Limits
The original authority may impose a cumulative monetary, data, time,
operation-count, or resource budget.
7.18.4 — Protected Shared Accounting
A protected budget controller may account for consumption across
branches.
7.18.5 — Atomic Reservation
Each consequential branch may reserve part of the shared budget
before effectuation.
7.18.6 — Duplicate Spending
Two agents must not independently consume the same exclusive budget
allocation.
7.18.7 — Distributed Consistency
Where the budget is shared across domains, the implementation may use
an authoritative coordinator, bounded suballocations, distributed
locking, fencing, or another appropriate consistency protocol.
7.18.8 — Offline Branches
A disconnected branch may operate only within a valid bounded
suballocation where immediate shared-state verification is
unavailable.
7.18.9 — Conflict Governance
Where the branches produce incompatible real effects, Embodiment 1
may provide additional protected conflict arbitration.
7.18.10 — Distinction from Exclusive Migration
Concurrent delegation may intentionally allow multiple simultaneously
valid child authorities.
Exclusive authority migration instead requires the previous owner to
be fenced.
The two modes must not be conflated.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.25. Source page 747 of the original specification
7.19 — EXCLUSIVE AUTHORITY MIGRATION
7.19.1 — Migration Request
An existing task may need to continue on another device, provider, or
execution environment.
7.19.2 — Current Ownership
A protected ownership record identifies the current authority holder.
7.19.3 — Migration Preparation
The destination authenticates itself and verifies eligibility to
receive the bounded unfinished authority.
7.19.4 — Ownership Epoch Transition
A protected authority controller advances the ownership epoch or
commits another equivalent exclusive transfer state.
7.19.5 — Previous-Owner Fencing
The former execution environment's authority becomes stale under the
required Finality Sinks.
7.19.6 — Destination Activation
The destination receives or activates the corresponding scoped
authority only under the committed transfer conditions.
7.19.7 — Atomicity Qualification
A transfer may require an authoritative ownership service or suitable
distributed fencing protocol.
A local cryptographic message alone does not establish globally
atomic ownership transfer where separate sinks can act independently.
7.19.8 — Network Partition
Where the former owner cannot receive immediate revocation, the
architecture must rely upon bounded leases, destination-side fencing,
authoritative epoch checks, or other effective controls.
7.19.9 — In-Flight Consequences
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An effect completed before migration remains an actual effect.
The system reconciles pending attempts rather than assuming they were
undone.
7.19.10 — Protected Migration Receipt
The controller may authenticate a transfer record identifying the
previous owner, new owner, affected authority, current epoch, and
designated sinks.
8.2.3.26. Source page 748 of the original specification
This receipt is an ownership-control record rather than proof that
every external effect has completed.
7.20 — REVOCATION CONTINUITY
7.20.1 — Root Revocation
The originating authority may be revoked under applicable policy.
7.20.2 — Derived Authority Invalidation
Unconsumed child authorities may become invalid according to their
authenticated relationship with the revoked source.
7.20.3 — Current State Verification
The destination Finality Sink verifies current applicable revocation
state where required.
7.20.4 — Bounded Leases
A delegation may remain valid only for a bounded duration or
operation count.
7.20.5 — Offline Limitations
A receiving domain without access to current revocation information
cannot guarantee immediate global revocation unless appropriate local
expiry or independent control mechanisms exist.
7.20.6 — Protected Revocation Epoch
A current revocation epoch may invalidate authority associated with
earlier generations.
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.20.7 — Partial Revocation
An originating authority may narrow permitted resources or
destinations without revoking every remaining operation.
7.20.8 — Revoked Intermediary
Revocation of an intermediary may affect descendant authorities
according to the specified source-delegation policy.
7.20.9 — Completed Effects
Revocation does not retroactively reverse already completed external
consequences.
7.20.10 — Recovery
A subsequent corrective effect requires its own applicable protected
authorization.
7.21 — AUTHORITY CONTINUITY DURING SOFTWARE AND TOOL CHANGES
8.2.3.27. Source page 749 of the original specification
A delegated task may encounter different implementations of the
intended operation in receiving domains.
An originating service may use one API while the destination uses
another.
The protected system may translate the source effect descriptor into
a destination-specific operation contract.
Where action semantics remain within the permitted source effect
envelope, continuation may be authorized.
Where the destination tool introduces additional effects, the
receiving Finality Sink may withhold the expanded operation.
A changed destination tool does not automatically expand the original
authority.
The effect-compatibility mechanisms of Embodiment 6 may be applied.
Likewise, a receiving service's broader native capability does not
justify using additional privileges outside the delegated authority.
7.22 — PHYSICAL POSITIONING AND ENFORCEMENT TOPOLOGIES
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.22.1 — Originating Protected Gateway
An originating gateway may construct the delegation authority and
restrict what is transmitted to the receiving domain.
7.22.2 — Destination Protected Gateway
A destination gateway may verify lineage and enforce operation-
specific authority before using local credentials.
7.22.3 — Destination Hardware Controller
A hardware controller may verify scoped cross-domain authority before
accepting a real device command.
7.22.4 — Integrated Receiving Service
The receiving agent and DLFS may reside in one protected computing
platform with separated authority state.
7.22.5 — Independent Authority Appliance
A physically separate security device may authenticate delegated
authority and control a destination effectuation primitive.
7.22.6 — Remote Authority Verifier
A remote protected verifier may evaluate lineage evidence while the
local DLFS enforces the actual operation.
8.2.3.28. Source page 750 of the original specification
7.22.7 — Confidential Execution Environment
A receiving computation may execute within a protected environment.
The corresponding external effects remain subject to destination
finality authority.
7.22.8 — Multi-Device Delegation
Authority may pass among independently administered devices while
retaining source-derived restrictions.
7.22.9 — Single Protected Component
Several logical identity, delegation, validation, and effectuation
functions may reside within one protected device.
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.22.10 — Non-Bypassability Qualification
A destination service that retains an unrestricted alternative
effectuation path cannot automatically be treated as providing full
protected enforcement of the delegated authority.
7.23 — COMPLETE PRINCIPAL OPERATIONAL WORKFLOW
Step 1 — Receive Original Task
An originating autonomous entity receives a task from a valid
authority source.
Step 2 — Construct Original Candidate Act
The system identifies the intended consequential effects.
Step 3 — Establish Originating Effect Envelope
The protected controller records the permitted resource, destination,
privilege, quantity, and task scope.
Step 4 — Establish Source Authority Commitment
The originating authority is authenticated and associated with
current protected state.
Step 5 — Propose Delegation
The originating agent identifies a prospective receiving agent or
service.
Step 6 — Authenticate Delegate Identity
The receiving entity proves the required identity or eligibility.
Step 7 — Verify Delegation Permission
The protected system determines whether delegation is permitted.
8.2.3.29. Source page 751 of the original specification
Step 8 — Construct Narrowed Effect Scope
The proposed child authority is compared with the source envelope.
Step 9 — Verify Attenuation
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protected controller confirms that the child authority does not
exceed the source-derived scope.
Step 10 — Reserve Applicable Shared Budget
Where necessary, the system reserves a bounded portion of the source
authority's quantitative limits.
Step 11 — Create Delegation Transition
An authenticated DTR is committed.
Step 12 — Deliver Delegated Task
The receiving entity obtains the task description and applicable
protected delegation references.
Step 13 — Verify Receiving-Domain Trust
The destination authenticates the source and relevant delegation
lineage.
Step 14 — Apply Destination Local Policy
The receiving controller determines the locally permitted subset.
Step 15 — Resolve Destination Operation Semantics
The source effect descriptor is mapped to the actual destination
operation.
Step 16 — Prepare Destination Finality Authority
The destination establishes a scoped DFA.
Step 17 — Hold Consequential Effect
The actual operation remains non-effective where applicable.
Step 18 — Reconstruct Actual Operation
The DLFS obtains the operation presented for effectuation.
Step 19 — Verify Full Authority Continuity
The sink verifies source scope, delegation lineage, current
authority, local policy, actual operation, and consumption state.
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 20 — Atomically Consume or Reserve Authority
The sink performs the protected resource or effect authorization
transition.
8.2.3.30. Source page 752 of the original specification
Step 21 — Perform Actual Consequential Effect
The operation is permitted within the verified scope.
Step 22 — Record Attempt
A protected effectuation-attempt reference is committed.
Step 23 — Obtain Outcome Evidence Where Required
A qualified observation source may establish the resulting actual
effect.
Step 24 — Optional Causal Continuation
If a later phase requires a validated prior-effect receipt, CW-2 may
establish the corresponding continuation authority.
Step 25 — Complete, Delegate Further, or Recover
The system continues only under the applicable protected authority.
7.24 — REFERENCE PSEUDOCODE: ORIGINAL AUTHORITY
FUNCTION ESTABLISH_ORIGINATING_AUTHORITY( principal, original_task,
originating_PED ):
REQUIRE originating_PED .VERIFY_PRINCIPAL_AUTHORITY(principal)
original_candidate = CONSTRUCT_CANDIDATE_ACT( original_task )
envelope = DERIVE_AUTHORIZED_EFFECT_ENVELOPE( principal,
original_candidate )
REQUIRE VERIFY_EFFECT_ENVELOPE(envelope)
source_authority = originating_PED .ATOMIC_COMMIT({ principal:
AUTHENTICATED_REFERENCE(principal),
candidate_act: HASH(original_candidate),
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.31. Source page 753 of the original specification
effect_envelope: HASH(envelope),
delegation_policy: CURRENT_DELEGATION_POLICY(),
authority_epoch: CURRENT_AUTHORITY_EPOCH(),
source_authority_reference: NEW_PROTECTED_REFERENCE() })
IF source_authority != COMMITTED: RETURN DENY
RETURN source_authority
7.25 — REFERENCE PSEUDOCODE: ATTENUATED DELEGATION
FUNCTION CREATE_PROTECTED_DELEGATION( parent_authority,
receiving_entity, proposed_child_scope, delegation_controller ):
REQUIRE VERIFY_PARENT_AUTHORITY( parent_authority )
REQUIRE VERIFY_RECEIVING_ENTITY_IDENTITY( receiving_entity )
REQUIRE VERIFY_DELEGATION_PERMITTED( parent_authority,
receiving_entity )
REQUIRE VERIFY_EFFECT_SCOPE_ATTENUATION( proposed_child_scope,
parent_authority )
REQUIRE VERIFY_RESOURCE_SCOPE_ATTENUATION( proposed_child_scope,
parent_authority )
REQUIRE VERIFY_DESTINATION_SCOPE_ATTENUATION(
8.2.3.32. Source page 754 of the original specification
proposed_child_scope, parent_authority )
REQUIRE VERIFY_DELEGATION_DEPTH( parent_authority )
REQUIRE VERIFY_CURRENT_REVOCATION_STATE( parent_authority )
reservation = delegation_controller .ATOMIC_RESERVE_CHILD_AUTHORITY(
parent_authority, proposed_child_scope )
IF reservation != COMMITTED: RETURN DENY
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
transition = delegation_controller .AUTHENTICATE_TRANSITION({ parent:
HASH(parent_authority),
delegate: receiving_entity.identity,
child_scope: HASH(proposed_child_scope),
reservation: reservation.reference,
delegation_generation: NEXT_DELEGATION_GENERATION(),
authority_epoch: CURRENT_AUTHORITY_EPOCH(),
revocation_reference: parent_authority.revocation_reference })
RETURN transition This algorithm is illustrative.
The required attenuation predicate may include additional resource,
quantitative, or environmental constraints.
8.2.3.33. Source page 755 of the original specification
7.26 — REFERENCE PSEUDOCODE: LINEAGE VERIFICATION
FUNCTION VERIFY_DELEGATION_LINEAGE( origin_authority,
delegation_chain, destination_operation ):
REQUIRE VERIFY_ORIGIN_AUTHORITY( origin_authority )
current_scope = EXTRACT_EFFECT_SCOPE( origin_authority )
current_authority = origin_authority
FOR EACH transition IN delegation_chain:
REQUIRE VERIFY_DELEGATOR_AUTHENTICATION( transition )
REQUIRE VERIFY_PARENT_LINK( transition, current_authority )
REQUIRE VERIFY_CURRENT_TRANSITION_VALIDITY( transition )
REQUIRE VERIFY_ATTENUATION( transition.child_scope, current_scope )
REQUIRE VERIFY_DELEGATION_PERMISSION( current_authority, transition )
current_scope = transition.child_scope current_authority = transition
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
REQUIRE VERIFY_DESTINATION_WITHIN_SCOPE( destination_operation,
current_scope )
8.2.3.34. Source page 756 of the original specification
RETURN PROTECTED_LINEAGE_ACCEPTANCE({ origin: HASH(origin_authority),
final_transition: HASH(current_authority),
effective_scope: HASH(current_scope),
destination_operation: HASH(destination_operation) }) An
authenticated but incomplete lineage is not automatically accepted.
7.27 — REFERENCE PSEUDOCODE: DESTINATION FINALITY SINK
FUNCTION EFFECTUATE_CROSS_DOMAIN_OPERATION( candidate_act,
delegation_reference, destination_finality_sink ):
actual_operation = destination_finality_sink
.RECONSTRUCT_PENDING_OPERATION()
IF actual_operation IS NULL: RETURN DENY
lineage = RESOLVE_AUTHENTICATED_DELEGATION( delegation_reference )
REQUIRE VERIFY_DELEGATION_LINEAGE( lineage.origin_authority,
lineage.transitions, actual_operation )
REQUIRE destination_finality_sink .VERIFY_CURRENT_DELEGATE_IDENTITY()
REQUIRE destination_finality_sink .VERIFY_SOURCE_EFFECT_SCOPE(
lineage, actual_operation )
REQUIRE destination_finality_sink .VERIFY_LOCAL_POLICY(
8.2.3.35. Source page 757 of the original specification
actual_operation )
REQUIRE destination_finality_sink
.VERIFY_DESTINATION_ACTION_CONTRACT()
REQUIRE destination_finality_sink .VERIFY_CURRENT_REVOCATION_STATE()
REQUIRE destination_finality_sink .VERIFY_SINK_BOUND_AUTHORITY()
REQUIRE destination_finality_sink .VERIFY_SHARED_BUDGET_IF_REQUIRED()
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
REQUIRE destination_finality_sink
.VERIFY_OWNERSHIP_EPOCH_IF_REQUIRED()
consumption = destination_finality_sink .ATOMIC_CONSUME_AUTHORITY(
delegation_reference, actual_operation )
IF consumption != SUCCESS: RETURN DENY
RETURN destination_finality_sink.EFFECTUATE( actual_operation,
consumption )
7.28 — REFERENCE PSEUDOCODE: EXCLUSIVE AUTHORITY MIGRATION
FUNCTION MIGRATE_EXCLUSIVE_AUTHORITY( current_owner,
destination_owner, unfinished_authority,
protected_ownership_controller ):
REQUIRE VERIFY_CURRENT_OWNER( current_owner, unfinished_authority )
REQUIRE VERIFY_DESTINATION_IDENTITY( destination_owner )
REQUIRE VERIFY_MIGRATION_PERMITTED(
8.2.3.36. Source page 758 of the original specification
unfinished_authority )
REQUIRE VERIFY_CURRENT_AUTHORITY_STATE()
prepared = protected_ownership_controller .PREPARE_TRANSFER({
previous_owner: current_owner.identity,
destination_owner: destination_owner.identity,
authority: HASH(unfinished_authority),
expected_epoch: CURRENT_OWNERSHIP_EPOCH() })
IF prepared != PREPARED: RETURN DENY
committed = protected_ownership_controller
.ATOMIC_ADVANCE_OWNER_AND_EPOCH( prepared )
IF committed != COMMITTED: RETURN MIGRATION_UNRESOLVED
REQUIRE VERIFY_PREVIOUS_OWNER_FENCED( committed )
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
RETURN PROTECTED_DESTINATION_ACTIVATION( committed, destination_owner
) The actual ability to fence a former owner depends upon the
relevant Finality Sinks checking authoritative ownership state or
suitable bounded leases.
7.29 — REFERENCE PSEUDOCODE: SHARED BUDGET CONSUMPTION
FUNCTION RESERVE_DELEGATED_EFFECT_BUDGET( originating_budget,
child_authority, requested_effect_quantity,
protected_budget_controller ):
8.2.3.37. Source page 759 of the original specification
REQUIRE VERIFY_CHILD_AUTHORITY( child_authority )
REQUIRE VERIFY_PARENT_BUDGET_BINDING( originating_budget,
child_authority )
REQUIRE requested_effect_quantity WITHIN
child_authority.remaining_allowance
reservation = protected_budget_controller .ATOMIC_RESERVE({
root_budget: originating_budget.identifier,
child_authority: HASH(child_authority),
requested_quantity: requested_effect_quantity,
current_epoch: CURRENT_BUDGET_EPOCH() })
IF reservation != COMMITTED: RETURN DENY
RETURN reservation.protected_reference Where a domain cannot reach
the authoritative budget controller, new reservations may be withheld
or restricted to a valid preallocated offline budget.
7.30 — BASIC WORKED EXAMPLE: TWO AGENTS FROM DIFFERENT PROVIDERS
7.30.1 — Original Task
A user authorizes an autonomous assistant to analyze a particular
document and prepare a summary.
The authorized effect envelope permits reading that document and
returning the summary to the user's designated environment.
It does not permit external publication or unrelated file access.
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.30.2 — Proposed Delegation
The first assistant delegates the summarization computation to
another assistant operating under a separate provider.
7.30.3 — Protected Authority
8.2.3.38. Source page 760 of the original specification
The originating controller constructs a delegation permitting access
only to the specified document content needed for the task.
The delegate receives no unrestricted access to the user's storage
account.
7.30.4 — Receiving Domain
The second assistant authenticates its identity.
Its domain verifies the delegated authority.
7.30.5 — Computation
The second assistant prepares a summary.
7.30.6 — Consequential Operation
The second assistant attempts to write or transmit the result.
The destination Finality Sink verifies the applicable permitted
destination and data scope.
7.30.7 — Unauthorized Attempt
If the downstream assistant attempts to publish the document to an
unrelated external service, the actual outgoing operation exceeds the
delegated effect envelope.
The corresponding controlled sink refuses the effect.
7.30.8 — Technical Distinction
The first assistant's decision to delegate the task does not transfer
unrestricted authority over the user's document or destinations.
The receiving domain must independently enforce the bounded
consequential scope.
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.31 — WORKED EXAMPLE: THREE-HOP CLOUD RESOURCE OPERATION
A user authorizes an agent to inspect a specified cloud resource.
The first agent delegates inspection to a diagnostic service.
The diagnostic service delegates a narrow metadata query to another
computational worker.
Each delegation has an authenticated identity and a source-derived
authority reference.
The final worker proposes a consequential service API call.
The destination controller reconstructs the actual operation.
It verifies the complete lineage or a suitably protected validated
summary.
The permitted operation is limited to the specified inspection scope.
8.2.3.39. Source page 761 of the original specification
If the final worker attempts to delete, modify, or export unrelated
resources, the Finality Sink refuses the operation.
A valid downstream worker identity and locally available broad cloud
credential do not override the source-derived restriction.
7.32 — WORKED EXAMPLE: CREDENTIAL BROKER PREVENTS AUTHORITY
LAUNDERING
An enterprise agent is authorized to update one specified record.
The agent delegates the update to a remote automation service.
The remote service possesses a reusable credential permitting
modification of many records.
The protected credential broker receives the delegated authority and
proposed operation.
It verifies the originating record identity and permitted mutation.
The broker obtains the actual outgoing request.
It exercises the reusable credential only for the authorized record
and operation.
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An attempt to modify an unrelated record is rejected.
The agent does not receive the reusable credential.
The technical contribution concerns operation-bound protected
authority at the actual credential-exercise boundary, not merely
storing credentials in a separate service.
7.33 — WORKED EXAMPLE: CROSS-DEVICE EXCLUSIVE MIGRATION
An autonomous assistant begins preparing a protected device
configuration change on one computing device.
Before the final effect occurs, the task moves to another device.
The authority is intended to be exclusive.
A protected ownership controller verifies the migration and advances
the authority ownership epoch.
The former device's authority becomes stale.
The destination device receives an authenticated scoped continuation
reference.
Its Finality Sink verifies the current ownership epoch and actual
pending configuration change.
A delayed command from the former device is rejected.
The protection depends upon the relevant effectuation controllers
checking the authoritative epoch or equivalent fencing mechanism.
8.2.3.40. Source page 762 of the original specification
7.34 — WORKED EXAMPLE: CONCURRENT AGENTS WITH SHARED EFFECT BUDGET
An authorized task permits up to a specified total number of external
service operations.
The originating assistant delegates different portions of the task to
several agents.
Each agent receives its own bounded authority.
A shared protected budget controller maintains the aggregate
permitted effect count.
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Each destination Finality Sink requires a valid budget reservation
before performing the corresponding operation.
Two agents cannot independently spend the same remaining budget where
the controller provides the required atomic reservation.
If a branch becomes disconnected, its permitted operation count may
be limited to an explicitly preallocated offline sub-budget.
This preserves the distinction between concurrent delegation and
exclusive task migration.
7.35 — WORKED EXAMPLE: CROSS-PROVIDER TOOL CONTRACT CHANGE
An originating agent delegates a permitted file-conversion operation.
The receiving provider uses a tool that performs the conversion.
After delegation, the receiving tool is updated to include an
additional external upload.
The receiving domain evaluates the current tool semantics.
The original delegated envelope permits conversion but not external
upload.
The current operation is therefore incompatible with the existing
delegated authority.
The receiving Finality Sink may permit a separately controlled local
conversion while withholding the external upload.
Where the effects cannot be separated, the combined operation is
refused.
The example combines cross-domain authority attenuation with the
effect-compatibility mechanisms of Embodiment 6.
7.36 — WORKED EXAMPLE: REMOTE REAL-EFFECT RECEIPT AND NEXT PHASE
An original agent delegates a bounded storage operation to another
domain.
The receiving Finality Sink verifies the delegated authority and
permits the real storage effect.
A qualified observation component obtains evidence concerning the
actual committed storage state.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.41. Source page 763 of the original specification
Where the workflow requires receipt-gated continuation, an authorized
cryptographically identified IEV validates the prior-effect evidence.
The resulting accepted receipt constitutes a necessary enabling
factor for a later protected consequential phase under CW-2.
The originating domain may retrieve the accepted receipt or verify
authoritative protected receipt state.
The next Finality Sink independently verifies the causal continuation
condition.
A simple message from the downstream agent stating that the storage
operation succeeded is not a substitute for required accepted effect
evidence.
7.37 — WORKED EXAMPLE: FUTURE DEVICE-TO-DEVICE AUTONOMOUS OPERATION
Two autonomous devices belonging to different administrative domains
cooperate on a bounded physical task.
A first device possesses valid authority for a defined operation.
It delegates a limited actuation task to another device.
The receiving device authenticates the delegation and evaluates its
local safety constraints.
The actual actuator Finality Sink verifies the pending movement,
physical target, current authority, and permitted operating envelope.
If the delegated instruction exceeds the original physical scope or
local safety conditions, the movement remains disabled.
The architecture does not require the devices to use the same AI
model, operating system, or processor.
It does require appropriate control of the actual physical
consequence.
7.38 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
7.38.1 — Forged Origin Authority
An attacker creates an apparent root authorization without valid
protected authentication.
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The receiving domain rejects the unsupported origin.
7.38.2 — Forged Delegate Identity
An attacker claims to be an authorized downstream agent.
The protected system requires authenticated identity evidence.
7.38.3 — Unauthorized Delegation
8.2.3.42. Source page 764 of the original specification
An agent delegates consequential authority despite lacking permission
to delegate.
The protected delegation controller rejects the transition.
7.38.4 — Authority Scope Expansion
An intermediary attempts to issue broader rights than it received.
The attenuation verifier rejects the child authority.
7.38.5 — Credential Laundering
A privileged destination service attempts to exercise broad
credentials for a narrower source request.
The destination Finality Sink or credential broker enforces source-
derived effect limits.
7.38.6 — Lineage Truncation
An intermediary removes earlier restrictions from the transmitted
authorization.
The protected verifier rejects incomplete lineage.
7.38.7 — Parent Substitution
A child authority is falsely associated with a different parent.
Authenticated parent-link verification detects the mismatch.
7.38.8 — Delegation Replay
A valid delegation record is reused for an unrelated operation.
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The sink verifies scope, recipient, and consumption conditions.
7.38.9 — Recipient Substitution
A delegation intended for one receiving entity is presented by
another.
Protected recipient binding rejects unauthorized use.
7.38.10 — Sink Substitution
An authority intended for one destination sink is presented to
another.
The sink verifies its permitted audience or authority scope.
7.38.11 — Resource Alias Manipulation
A downstream provider maps a permitted source resource to a different
local resource.
Protected cross-domain resource correspondence rejects the mismatch.
7.38.12 — Tool Semantics Expansion
8.2.3.43. Source page 765 of the original specification
A receiving provider invokes a tool with broader side effects than
the original permitted envelope.
The destination's actual effect verification rejects unauthorized
expansion.
7.38.13 — Excessive Delegation Depth
An agent attempts to delegate beyond the permitted depth.
The protected verifier rejects the additional transition.
7.38.14 — Delegation Cycle
Agents circulate authority through repeated delegation to obscure its
origin or create additional execution opportunities.
The system checks protected lineage and applicable cycle or depth
constraints.
7.38.15 — Shared Budget Double Spending
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Two delegated agents attempt to consume the same remaining effect
budget.
Atomic protected accounting prevents unauthorized duplicate
reservation.
7.38.16 — Child Identity Multiplication
A principal creates several child agents to evade a common delegated
budget.
Protected aggregation and source-authority references maintain the
applicable shared constraints.
7.38.17 — Exclusive Migration Replay
A previous owner attempts to use authority after migration.
Current ownership epoch verification rejects stale use.
7.38.18 — Split-Brain Ownership
Two devices believe they hold exclusive authority.
The relevant protected sinks use authoritative fencing or bounded
leases.
7.38.19 — Revoked Root Authority
A descendant attempts to act after applicable source revocation.
Current revocation or lease-state verification rejects invalid
continuation.
7.38.20 — Revoked Intermediate Authority
A downstream agent attempts to rely upon an invalidated intermediate
delegation.
The protected lineage verifier applies the current delegation-
validity rules.
7.38.21 — Stale Revocation Cache
8.2.3.44. Source page 766 of the original specification
The receiving domain relies upon outdated revocation state.
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system enforces the applicable freshness or bounded offline
rules.
7.38.22 — Direct Effectuation Bypass
A downstream agent invokes an unmediated API or device interface.
The claimed protected architecture requires equivalent enforcement
for the governed path.
7.38.23 — Confused Destination Policy
A receiving service treats valid source authority as permission to
override local safety policy.
The destination authority intersection preserves mandatory local
restrictions.
7.38.24 — Remote Identity Collusion
Several downstream components cooperate to fabricate valid-looking
internal messages.
The protection depends upon independent authority checks, protected
keys, and actual effectuation enforcement under the selected threat
model.
7.38.25 — Compromised Destination Provider
A receiving provider deliberately ignores the delegated restrictions.
Cryptographic evidence alone cannot prevent effects through
interfaces fully controlled by the compromised provider unless
additional independently enforced controls exist.
7.38.26 — Fabricated Completion Receipt
A downstream agent reports a successful external effect that did not
occur.
Where outcome proof is required, the system uses appropriately
qualified evidence rather than an unsupported agent report.
7.38.27 — Lost Acknowledgement
A real downstream operation occurs but the response is lost.
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system preserves unresolved state and avoids unsafe automatic
duplicate execution.
7.38.28 — Authority Expiry During Execution
A delegation expires while an operation remains pending.
The applicable sink-time validity rules determine whether release
remains permitted.
7.38.29 — Canonicalization Mismatch
Different domains interpret authorization fields differently.
8.2.3.45. Source page 767 of the original specification
The protected protocol requires unambiguous typed representations or
rejects unsupported translations.
7.38.30 — Verification Exhaustion
An attacker submits an excessively long or malformed delegation
chain.
The verifier enforces bounded parsing, chain depth, and cryptographic
verification work.
7.38.31 — Confidentiality Leakage
A delegation object exposes unnecessary information about the
originating principal or task.
The system may use minimized claims, protected references, or
selective disclosure where technically suitable.
7.38.32 — Policy Downgrade
A receiving domain attempts to apply a weaker authorization policy.
The destination controller verifies current mandatory policy
versions.
7.38.33 — Stale Software Contract
A delegated operation executes under changed tool semantics.
The destination verifies current effect compatibility where required.
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.38.34 — Unrestricted Recovery
A downstream agent attempts a broad corrective effect following a
failure.
The recovery operation requires its own applicable source-derived and
local authorization.
7.38.35 — Uncontrolled Alternative Provider
An agent moves the task to another provider to evade an existing
protected sink.
The new destination must satisfy equivalent authority restrictions
for the governed consequential effects.
7.39 — CRASH CONSISTENCY AND FAILURE RECOVERY
7.39.1 — Crash Before Delegation Commitment
No valid downstream authority is presumed to exist.
7.39.2 — Crash After Delegation Commitment
The protected transition may be recovered from authoritative state.
7.39.3 — Crash During Shared Budget Reservation
8.2.3.46. Source page 768 of the original specification
The protected controller recovers the reservation state and prevents
duplicate allocation.
7.39.4 — Crash After Destination Authority Preparation
The destination checks whether the prepared authority was activated,
consumed, or invalidated.
7.39.5 — Crash After Actual Effectuation
The actual external effect is reconciled independently of the local
crash.
7.39.6 — Migration Preparation Failure
The source may retain authority unless a protected committed transfer
has superseded it.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.39.7 — Migration Commitment Failure
The system must determine authoritative ownership before allowing
either side to proceed under an exclusivity requirement.
7.39.8 — Partition After Migration
The former owner is constrained through fencing, authoritative epoch
checks, or bounded leases.
7.39.9 — Unknown Remote Effect
The system preserves uncertain outcome state.
7.39.10 — Recovery Candidate Act
A new consequential corrective operation requires valid source-
derived and destination-local authorization.
7.40 — PRESENT-DAY REFERENCE IMPLEMENTATION
7.40.1 — Minimum Prototype Components
A prototype may comprise:
An originating agent process;
A protected source-authority service;
A first destination agent process;
A second destination agent process;
An authenticated delegation registry;
A destination effectuation gateway;
A protected credential broker;
8.2.3.47. Source page 769 of the original specification
And a protected consumption-state store.
7.40.2 — Example Protected Resource
The controlled consequential resource may be a test database, file
store, or external request endpoint.
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.40.3 — Original Authority
The source service permits modification of one specific test record.
7.40.4 — Delegation
The source agent issues a narrow delegated authority to a second
agent.
7.40.5 — Further Delegation
The second agent delegates a still narrower operation to a third
agent.
7.40.6 — Lineage Verification
The destination verifies the authenticated parent-child authority
relationships.
7.40.7 — Sink Enforcement
The final gateway checks the actual pending database or service
operation.
7.40.8 — Scope-Expansion Test
The downstream agent attempts an unauthorized resource modification.
The gateway rejects it.
7.40.9 — Replay Test
The agent reuses a consumed delegation authorization.
The gateway rejects the unauthorized second effect.
7.40.10 — Migration Test
The prototype advances an ownership epoch and verifies rejection of
the old owner's subsequent command.
7.40.11 — Prototype Trust Model
A software prototype can demonstrate the protocol under a defined
protected-service trust model.
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
It does not independently establish security against compromise of
every privileged operating-system component or an uncooperative
destination provider.
7.40.12 — Hardware Extension
8.2.3.48. Source page 770 of the original specification
A stronger implementation may use hardware-protected keys, protected
counters, isolated verification, or destination-side device command
enforcement.
7.41 — NON-LIMITING PROPOSED EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — One-Hop Delegation: Create a source-derived narrow
authority and verify its destination enforcement.
Experiment 2 — Two-Hop Delegation: Verify attenuation across two
authenticated transitions.
Experiment 3 — Multi-Hop Delegation: Verify a longer bounded
delegation lineage.
Experiment 4 — Forged Origin: Present an unauthorized source-
authority commitment.
Experiment 5 — Forged Delegate: Copy a permitted delegate identifier
without valid credentials.
Experiment 6 — Unauthorized Delegation: Attempt delegation where the
parent authority prohibits it.
Experiment 7 — Scope Expansion: Issue a child authority broader than
the parent.
Experiment 8 — Resource Expansion: Delegate authority over an
unauthorized additional resource.
Experiment 9 — Destination Expansion: Redirect an authorized
operation to another destination.
Experiment 10 — Lineage Truncation: Remove an earlier delegation
record and test rejection.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 11 — Parent Substitution: Associate a child delegation
with an unrelated parent.
Experiment 12 — Delegation Replay: Reuse a valid consumed operation
authorization.
Experiment 13 — Recipient Binding: Present a delegated authority
through another receiving identity.
Experiment 14 — Sink Binding: Present a valid authority to an
unintended Finality Sink.
Experiment 15 — Credential Laundering: Attempt an unauthorized effect
using a privileged destination credential.
Experiment 16 — Cross-API Translation: Translate one authorized
effect into a destination-specific operation and verify semantic
attenuation.
Experiment 17 — Resource Alias Change: Substitute the destination's
actual resource mapping.
Experiment 18 — Shared Budget: Execute parallel delegated operations
under one protected cumulative budget.
Experiment 19 — Concurrent Budget Race: Attempt duplicate reservation
of the same remaining budget.
8.2.3.49. Source page 771 of the original specification
Experiment 20 — Concurrent Independent Branches: Verify permitted
parallel operation without unnecessary exclusive ownership.
Experiment 21 — Exclusive Migration: Transfer unfinished authority
and fence the previous owner.
Experiment 22 — Migration Partition: Disconnect the previous owner
during the transfer and evaluate fencing guarantees.
Experiment 23 — Root Revocation: Revoke the originating authority and
test subsequent descendant operations.
Experiment 24 — Intermediate Revocation: Revoke a delegated entity
and apply the specified descendant-validity rules.
Experiment 25 — Offline Lease: Verify bounded operation while the
destination lacks connectivity to the authority registry.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 26 — Stale Revocation Data: Attempt an operation using
outdated authority state.
Experiment 27 — Cross-Provider Tool Update: Change destination
operation semantics and test current effect compatibility.
Experiment 28 — Alternate Effectuation Path: Attempt the same
operation through another covered destination interface.
Experiment 29 — Direct Hardware Path: Evaluate whether an actual
hardware controller enforces delegated authority.
Experiment 30 — Cryptographic Key Rotation: Rotate a receiving
entity's identity credentials and verify continuity.
Experiment 31 — Large Delegation Chain: Test protected verification-
work limits.
Experiment 32 — Crash During Delegation: Simulate failure before and
after protected transition commitment.
Experiment 33 — Unknown Remote Outcome: Lose acknowledgement after
the possible external effect and verify uncertainty handling.
Experiment 34 — Causal Receipt Integration: Require an authorized IEV
receipt for a dependent next phase.
Experiment 35 — Integrated Domain: Implement source and destination
authority functions within one protected controller.
Experiment 36 — Physically Separate Domains: Implement originating
and receiving controllers on distinct devices.
Experiment 37 — Privacy-Minimized Delegation: Verify required
authority without revealing unnecessary originating-principal
information.
Experiment 38 — Local Policy Intersection: Apply stricter destination
rules without expanding source authority.
8.2.3.50. Source page 772 of the original specification
Experiment 39 — Multi-Provider Effect Conflict: Integrate protected
reservations from Embodiment 1.
Experiment 40 — No Blockchain: Implement cross-domain authority
lineage, revocation, consumption, and finality verification without a
distributed ledger.
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.42 — FEASIBILITY, LATENCY, AND TECHNICAL IMPLEMENTATION
7.42.1 — Present Feasibility
The disclosed system may be implemented using established
cryptographic signatures, authenticated service identities, protected
state, scoped authorization, transactional resource control, and
service-to-service communication.
The principal implementation challenge concerns integrating source-
derived authority with destination-side actual-effect enforcement.
7.42.2 — Protected Delegation Records
A compact authenticated record may represent each authority
transition.
7.42.3 — Lineage Verification
A verifier may evaluate each required delegation transition using
protected trust anchors and deterministic scope comparisons.
7.42.4 — Caching
Verified lineage results may be cached within their valid authority
and revocation epochs.
7.42.5 — Destination Enforcement
A controlled API or resource gateway may verify a scoped DFA before
exercising privileged credentials.
7.42.6 — Shared Budget Consistency
A transactional controller may maintain authoritative consumption
state.
Distributed variants may require suitable consistency or bounded-
suballocation mechanisms.
7.42.7 — Exclusive Ownership
An authoritative ownership service or hardware-supported fencing
mechanism may enforce task migration.
7.42.8 — Verification Latency
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Cryptographic identity verification and lineage checking introduce
processing costs.
The system may use compact validated references, cached protected
results, and local sink-state checks where compatible with security
requirements.
8.2.3.51. Source page 773 of the original specification
No universal latency figure is asserted.
7.42.9 — Offline Limitations
A disconnected receiving device cannot guarantee immediate awareness
of remote revocation without an appropriate supporting mechanism.
7.42.10 — Enforcement Completeness
The system cannot guarantee restrictions against a destination
provider that can freely bypass the relevant Finality Sink.
Such a deployment requires additional technical controls or a
correspondingly narrower threat model.
7.42.11 — Industrial Practicality
The architecture can be prototyped through present-day protected
service gateways and extended toward hardware-backed or distributed
enforcement as required.
7.43 — OPTIONAL ADVANCED FUTURE-ORIENTED TECHNICAL CONCEPTS
7.43.1 — Autonomous Agent Interoperability Networks
Future agents may dynamically exchange tasks across independently
administered provider ecosystems.
A protected authority-continuity protocol may permit such exchanges
without transferring unrestricted user credentials.
7.43.2 — Decentralized Agent Discovery
Agents may discover other computational services without relying upon
one centralized provider.
The protected system may authenticate each receiving domain and
establish a limited trust relationship for the specific operation.
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.43.3 — Cross-Model Authority Independence
An agent may switch underlying computational models.
The authorized consequential scope may remain unchanged even where
the computational implementation changes.
7.43.4 — Confidential Cross-Domain Delegation
A delegation may require proof of limited authority while concealing
unnecessary personal or commercial information.
Suitable selective disclosure or privacy-preserving proof techniques
may be applied.
7.43.5 — Hardware-Backed Inter-Device Identity
8.2.3.52. Source page 774 of the original specification
Independent devices may possess protected cryptographic identities
used for delegation and finality authorization.
7.43.6 — Distributed Autonomous Robotics
Several autonomous robots may cooperate on a shared task while each
protects its own physical effectuation boundary.
7.43.7 — Cross-Cloud Workload Continuity
Autonomous tasks may migrate between independent cloud execution
environments while maintaining source-derived authority and ownership
fencing.
7.43.8 — Edge-to-Satellite Task Execution
A protected task may involve devices with long communication delays.
The architecture may use bounded authority leases, authenticated
effect descriptors, and conservative revocation assumptions.
7.43.9 — Autonomous Communication Networks
Distributed network-management agents may delegate limited network-
control operations among protected domains.
7.43.10 — Machine-to-Machine Economic Operations
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Autonomous devices may delegate constrained resource purchases,
service access, or transaction execution.
The destination sink verifies the actual transaction against source-
derived authority.
7.43.11 — Multi-Principal Delegation
A consequential operation may require authority from several
originating principals.
The receiving sink may verify the required combined authority.
7.43.12 — Threshold-Controlled Delegation
Several authorized controllers may be required to approve specified
authority transfers.
7.43.13 — Dynamic Contract Rebinding
A receiving service may change its execution contract while a
delegated task is pending.
The protected system may require renewed effect-compatibility
evidence.
7.43.14 — Post-Quantum Identity Migration
The cryptographic authentication mechanisms may migrate to suitable
future algorithms without changing the underlying source-authority
attenuation requirements.
8.2.3.53. Source page 775 of the original specification
7.43.15 — Protected Agent Memory Transfer
An agent may transfer task memory or context to another provider.
Transfer of computational state does not independently transfer
broader execution authority.
7.43.16 — Effect-Bound Distributed Compute Accelerators
A delegated task may execute on heterogeneous accelerator
infrastructure while controlled external effects remain subject to
destination finality authorization.
7.43.17 — Long-Duration Autonomous Workflows
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A task may persist across several software updates and administrative
changes.
The protected authority state may be refreshed or revalidated under
explicit continuity rules.
7.43.18 — Automatic Constrained Replanning
An agent may propose an alternative method for completing a task.
The new consequential operations must remain within valid effect
authority or obtain appropriate new authorization.
7.43.19 — Privacy-Preserving Authority Audit
A verifier may establish that a destination effect was within
authenticated delegated scope without receiving unrelated task data.
7.43.20 — Future Protected Agent Execution Infrastructure
A computing platform may provide authority continuity and finality
enforcement as an independent shared infrastructure layer used by
multiple agent implementations.
7.44 — OPTIONAL INVENTIVE COMBINATIONS
7.44.1 — Lineage-Bound Destination Finality
An actual destination effect requires both a valid source-authority
lineage and current sink-local authorization.
7.44.2 — Delegation Plus Effect-Semantic Translation
A provider-neutral effect descriptor is translated into destination-
specific operation semantics and verified at the actual sink.
7.44.3 — Delegation Plus Credential Release
A protected credential broker exercises broad native credentials only
for a source-authorized effect.
7.44.4 — Delegation Plus Shared Budget
8.2.3.54. Source page 776 of the original specification
Multiple concurrent descendants draw from one authoritative
cumulative effect budget.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.44.5 — Delegation Plus Exclusive Migration
A protected controller distinguishes parallel delegated authority
from exclusive authority transfer and applies appropriate fencing.
7.44.6 — Delegation Plus Contract Evolution
A receiving provider's current tool semantics must remain within the
original delegated effect envelope.
7.44.7 — Delegation Plus Cross-Agent Arbitration
Independently delegated agents must satisfy applicable protected
conflict-reservation conditions.
7.44.8 — Delegation Plus Causal Receipts
A successor effect requires both valid delegation authority and an
IEV-accepted actual predecessor-effect receipt.
7.44.9 — Delegation Plus Privacy Composition
A downstream data disclosure must satisfy source-derived authority
and current cumulative privacy-exposure constraints.
7.44.10 — Delegation Plus Hardware Finality
A protected device controller verifies the authenticated authority
lineage before performing a real hardware command.
7.44.11 — Delegation Plus Dynamic Path Coverage
A protected system verifies that newly introduced destination
interfaces remain subject to mandatory finality control.
7.44.12 — Delegation Plus Revocation Epoch
A destination sink verifies current source and local revocation state
before permitting actual effectuation.
7.45 — DISTINCTION FROM CONVENTIONAL SYSTEMS AND INVENTIVE-STEP FOCUS
7.45.1 — Not Merely Authentication
Authenticating two cooperating agents does not establish what real-
world effects their cooperation is authorized to produce.
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The proposed system binds authority to the actual consequential
operation.
8.2.3.55. Source page 777 of the original specification
7.45.2 — Not Merely Token Forwarding
A delegated token may carry permission scopes.
The stronger proposed implementation requires current source-
authority lineage, protected effect-semantic attenuation,
destination-specific authority, and actual sink verification.
7.45.3 — Not Merely Token Exchange
Exchanging one credential for another does not automatically
establish that destination operations remain within the original
effect envelope.
The disclosed system may require protected source-to-destination
effect correspondence.
7.45.4 — Not Merely Capability Attenuation
Capability attenuation is established technology.
The candidate distinctive arrangement may combine such attenuation
with multi-domain actual-operation reconstruction, protected shared
consumption, and destination-local finality enforcement.
7.45.5 — Not Merely Workflow Orchestration
An orchestrator may assign work to multiple agents.
The proposed architecture requires actual protected finality
authorization for governed effects.
7.45.6 — Not Merely Credential Isolation
A credential broker may prevent a receiving agent from seeing
secrets.
The disclosed system may additionally prevent the broker from
exercising those secrets for effects outside the source-derived
authorization.
7.45.7 — Not Merely Distributed Logging
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A signed delegation log may establish an authorization history.
The present principal implementation makes current validated
authority a necessary condition for the actual consequential release.
7.45.8 — Not Merely Task Migration
A transferred task state does not automatically establish exclusive
authority ownership.
The proposed migration variant requires protected ownership
transition and stale-owner fencing.
7.45.9 — Candidate Objective Technical Problem
An illustrative objective technical problem is:
How to prevent unauthorized consequential authority expansion,
replay, duplication, or laundering as autonomous computational tasks
cross independent provider and device
8.2.3.56. Source page 778 of the original specification
boundaries, while preserving legitimate narrow delegation and task
continuity through authenticated source lineage, effect-semantic
attenuation, current protected state, and independent destination
Finality-Sink enforcement.
7.45.10 — Candidate Technical Solution
A candidate solution includes authenticated original effect
authority, protected delegation transitions, verified attenuation,
receiving-domain identity and policy checks, operation-bound
destination finality authority, actual pending-operation
reconstruction, and protected consumption or ownership state.
7.45.11 — Principal Technical Interaction
The source authority establishes the maximum permitted consequence.
The delegation lineage records the permissible transfer.
The receiving domain applies local technical restrictions.
The destination controller generates or verifies scoped authority for
the actual operation.
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Finality Sink enforces the resulting constraints before
effectuation.
The consumption or fencing state prevents unsupported repeated
exercise.
These functions perform different technical roles while maintaining
one protected authority relationship.
7.45.12 — Stronger Narrow Claim Focus
A narrower claim may require the destination Finality Sink to verify
an authenticated source-authority lineage and a current destination-
specific non-bearer finality enablement against the reconstructed
actual pending effect, with protected consumption.
7.45.13 — Additional Narrow Claim Focus
Another narrower claim may require effect-semantic attenuation across
heterogeneous source and destination operation contracts.
7.45.14 — Additional Ownership Claim Focus
Another implementation may require atomic exclusive authority
migration and current sink-local fencing of prior owners.
7.45.15 — Prior-Art Qualification
Distributed authorization, capability attenuation, token exchange,
sender-constrained credentials, workload identity, zero-trust access,
and distributed fencing are established technical fields.
The novelty and inventive step of any particular claim depend upon
its precise protected relationships and relevant prior disclosures.
8.2.3.57. Source page 779 of the original specification
A broad assertion that authority should not expand across agents is
not, by itself, sufficient to establish a patentable invention.
7.45.16 — Hindsight Considerations
An assessment of inventive step should identify whether a person
having ordinary skill in the art would have been led by the relevant
prior art to combine the particular source-lineage verification,
effect-specific attenuation, destination-side operation
reconstruction, non-bearer enablement, and protected consumption
mechanisms in the claimed way.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The relevant technical differences must be supported by actual
implementation details.
7.46 — INDUSTRIAL APPLICABILITY
7.46.1 — Enterprise Multi-Agent Workflows
Several autonomous assistants may cooperate across service boundaries
while retaining source-derived authority restrictions.
7.46.2 — Cross-Provider AI Platforms
Independent agent platforms may exchange bounded tasks without
transferring unrestricted user credentials.
7.46.3 — Cloud Infrastructure
Resource-management agents may delegate narrowly scoped cloud
operations to independently administered services.
7.46.4 — Financial Infrastructure
Autonomous financial workflows may preserve transaction amount,
recipient, and authority limits across delegated services.
7.46.5 — Storage and Data Management
An agent may delegate a bounded storage operation without granting
the receiving service unrestricted access to an entire account.
7.46.6 — Mobile and Desktop Assistants
A device assistant may transfer computational tasks to remote
services while maintaining local protected authority over sensitive
external effects.
7.46.7 — Telecommunications
Distributed network-management agents may delegate limited control-
plane operations among administrative domains.
7.46.8 — Industrial Robotics
8.2.3.58. Source page 780 of the original specification
Autonomous machines may delegate bounded physical operations subject
to destination-local safety enforcement.
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
7.46.9 — Edge Computing
A task may migrate among edge and cloud environments while retaining
valid effect-specific authorization.
7.46.10 — Secure Hardware Systems
Protected device controllers may authenticate delegated authority
before executing privileged hardware commands.
7.46.11 — Confidential Computing
A confidential workload may compute within an isolated environment
while its consequential outputs remain subject to protected
destination authorization.
7.46.12 — Autonomous Machine-to-Machine Services
Devices may delegate limited service requests, resource commitments,
and other real effects without transferring unrestricted authority.
7.46.13 — Long-Running Autonomous Tasks
A task may persist through several agent replacements or software
updates while maintaining authenticated authority lineage and current
protected validity.
7.46.14 — Future Distributed Agent Infrastructure
A common execution-finality service may provide protected delegated
authority across heterogeneous autonomous providers, devices, and
execution environments.
The industrial utility concerns the secure preservation of
consequential authorization despite changes in computational
identity, location, or administrative control.
7.47 — ADDITIONAL OPTIONAL IMPLEMENTATION VARIATIONS
Variation 7.A — Single-Hop Delegation: One originating agent
delegates a bounded consequential operation to one receiving agent.
Variation 7.B — Multi-Hop Delegation: Several authenticated
attenuation transitions precede final effectuation.
Variation 7.C — Cross-Provider Delegation: Participating agents
operate under different administrative providers.
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Variation 7.D — Cross-Device Delegation: Authority is transferred or
attenuated across physical devices.
Variation 7.E — Cross-Cloud Delegation: Independently administered
infrastructure domains exchange operation-bound authority.
8.2.3.59. Source page 781 of the original specification
Variation 7.F — Provider-Neutral Effect Binding: Authority is
represented according to the intended consequence rather than one
native API syntax.
Variation 7.G — Authenticated Lineage: The destination verifies the
originating authority and relevant delegation chain.
Variation 7.H — Protected Scope Attenuation: Child authority is
constrained by predecessor effect limits.
Variation 7.I — Protected Recipient Binding: The delegate must
authenticate as the designated receiving entity.
Variation 7.J — Protected Sink Binding: Delegated authority is
accepted only at an authorized effectuation boundary.
Variation 7.K — Non-Bearer Continuity: Transporting the authority
object does not independently confer unrestricted execution
permission.
Variation 7.L — Destination Policy Intersection: Local restrictions
remain effective alongside source-derived constraints.
Variation 7.M — Protected Credential Broker: Destination credentials
are used only for verified authorized effects.
Variation 7.N — Multi-Agent Parallel Delegation: Several child
authorities may coexist where the parent permits concurrent
execution.
Variation 7.O — Shared Effect Budget: Descendant operations consume
an authenticated common limit.
Variation 7.P — Atomic Budget Reservation: Concurrent agents cannot
independently spend one exclusive remaining allowance.
Variation 7.Q — Delegation Depth Limit: The source restricts further
authority delegation.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Variation 7.R — Delegation Cycle Detection: Unsupported cyclic
lineage is rejected.
Variation 7.S — Protected Root Revocation: Source revocation
constrains applicable descendant authority.
Variation 7.T — Delegation-Specific Revocation: One child authority
may be invalidated independently of other permitted branches.
Variation 7.U — Bounded Offline Lease: A disconnected delegate acts
only within its protected local allowance.
Variation 7.V — Exclusive Migration: An unfinished authorization
changes owners through a protected transition.
Variation 7.W — Stale-Owner Fencing: Superseded execution
environments cannot validly reuse migrated authority.
Variation 7.X — Cross-Domain Identity Rebinding: Authorized
identities are mapped across authenticated trust domains.
8.2.3.60. Source page 782 of the original specification
Variation 7.Y — Contract Evolution Verification: Receiving-domain
operation semantics are verified under current action contracts.
Variation 7.Z — Cross-Interface Resource Resolution: The actual
destination resource is matched to the permitted source target.
Variation 7.AA — Protected Actual-Operation Reconstruction: The
destination sink independently obtains the effectuation command.
Variation 7.AB — Protected Authority Consumption: Single-use or
bounded delegated authority is atomically consumed.
Variation 7.AC — Cross-Domain Effect Observation: Qualified external
evidence supports actual outcome classification.
Variation 7.AD — Optional Causal Receipt: A validated prior-effect
receipt enables a protected later phase.
Variation 7.AE — Cross-Agent Conflict Arbitration: Delegated effects
satisfy required protected conflict reservations.
Variation 7.AF — Multi-Principal Authorization: Several originating
authorities may be required for one consequence.
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Variation 7.AG — Threshold Authorization: A defined protected quorum
authorizes selected delegated effects.
Variation 7.AH — Privacy-Minimized Delegation: Authority verification
uses restricted disclosure of sensitive information.
Variation 7.AI — Confidential Computing Integration: Protected
computation and destination finality remain distinct.
Variation 7.AJ — Hardware Finality Integration: Device controllers
verify delegated authority for physical operations.
Variation 7.AK — Network Egress Finality: Actual cross-domain
transmissions require scoped authorization.
Variation 7.AL — Storage Commit Finality: Destination storage
mutations require current valid lineage.
Variation 7.AM — Financial Transaction Finality: Actual payment
instructions remain within original transaction scope.
Variation 7.AN — Resource Allocation Integration: Delegated
computation uses protected shared-resource grants where applicable.
Variation 7.AO — Dynamic Effectuation-Path Coverage: Newly introduced
destination interfaces require suitable finality enforcement.
Variation 7.AP — Integrated Protected Controller: Identity,
delegation, validation, and effectuation functions coexist within one
protected component.
8.2.3.61. Source page 783 of the original specification
Variation 7.AQ — Physically Separate Controllers: Source and
destination verification functions reside on different devices.
Variation 7.AR — Remote Authority Verifier: A destination may obtain
authenticated lineage validation from a protected remote authority
service.
Variation 7.AS — Delegation Proof Compression: Compact authenticated
evidence represents relevant predecessor authority relationships.
Variation 7.AT — Cryptographic Algorithm Agility: Identity and
authority authentication may migrate among suitable cryptographic
mechanisms.
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Variation 7.AU — No Blockchain Requirement: Protected authority
lineage and state are maintained without a distributed ledger.
Variation 7.AV — Future Autonomous Agent Interoperability: The
protocol may be adapted to emerging agent communication and tool
interfaces.
These variations may be implemented separately or in technically
compatible combinations.
7.48 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
A candidate independent system claim may concern a protected cross-
domain authority-continuity system comprising:
An originating protected authority component configured to establish
an operation-specific permitted effect envelope;
A delegation controller configured to authenticate a delegation
transition and verify that the resulting child effect authority does
not exceed the originating authority;
A receiving-domain verifier configured to authenticate a source-
authority lineage and apply current receiving-domain constraints;
A destination authority component configured to establish scoped
finality authority for a permitted downstream operation;
And a destination Finality Sink configured to reconstruct the actual
pending operation, verify the source-derived scope and applicable
current protected state, and permit the operation only when the
required authorization conditions are satisfied.
A corresponding independent method claim may recite establishing
original authority, authenticating a delegate, constructing
attenuated authority, verifying lineage at the destination, preparing
destination-specific finality authorization, reconstructing the
actual operation, and controlling the consequential effect through
protected consumption.
A separate candidate independent claim may focus on exclusive cross-
domain authority migration with stale-owner fencing.
Another may focus on protected shared-budget consumption across
concurrent delegated agent branches.
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.62. Source page 784 of the original specification
Another may focus on non-bearer delegation enablement through a
destination-controlled credential or hardware effectuation interface.
The proper claim structure depends upon unity, original disclosure
support, and relevant prior art.
7.49 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The originating authority is represented by a
protected effect envelope.
Dependent aspect 2: The originating authority is cryptographically
authenticated.
Dependent aspect 3: Each receiving agent possesses an enrolled
cryptographic identity.
Dependent aspect 4: A delegation transition is bound to both
delegator and delegate identities.
Dependent aspect 5: Each transition references an authenticated
predecessor authority.
Dependent aspect 6: A child authority is verified to remain within
the predecessor effect scope.
Dependent aspect 7: Delegation scope is expressed in a provider-
neutral effect descriptor.
Dependent aspect 8: The destination translates source effect
semantics to a local operation contract.
Dependent aspect 9: The destination verifies the translated actual
effect against the originating envelope.
Dependent aspect 10: The receiving domain applies mandatory local
authorization constraints.
Dependent aspect 11: A destination Finality Sink reconstructs the
actual pending operation.
Dependent aspect 12: A delegation reference is bound to the
designated destination sink.
Dependent aspect 13: A delegation reference is bound to the
authenticated recipient identity.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 14: The destination requires a non-bearer scoped
finality enablement.
Dependent aspect 15: A protected credential broker exercises
credentials only for the permitted actual operation.
Dependent aspect 16: A delegation chain comprises multiple
authenticated attenuated transitions.
Dependent aspect 17: The chain has a protected maximum delegation
depth.
Dependent aspect 18: The system rejects incomplete or inconsistent
authority lineage.
Dependent aspect 19: A root authority may be revoked under protected
current state.
Dependent aspect 20: Revocation affects relevant descendant authority
under an explicit protected policy.
Dependent aspect 21: Delegated authority expires under a bounded
lease.
Dependent aspect 22: An offline delegate is restricted to a
preallocated resource or effect budget.
8.2.3.63. Source page 785 of the original specification
Dependent aspect 23: Multiple child authorities share one protected
parent budget.
Dependent aspect 24: Resource or effect budget consumption is
atomically reserved.
Dependent aspect 25: An exclusive authority is transferred under a
protected ownership epoch.
Dependent aspect 26: The previous execution owner is fenced following
a committed migration.
Dependent aspect 27: A receiving Finality Sink verifies current
ownership state.
Dependent aspect 28: Delegated authority is protected against replay
and cross-sink substitution.
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 29: A destination's changed action contract triggers
effect-compatibility revalidation.
Dependent aspect 30: An actual resource alias is resolved to the
authorized source target.
Dependent aspect 31: A delegated storage operation is controlled at a
storage commit sink.
Dependent aspect 32: A delegated network operation is controlled at a
network egress sink.
Dependent aspect 33: A delegated financial operation is controlled at
a transaction sink.
Dependent aspect 34: A delegated physical operation is controlled at
a hardware actuator sink.
Dependent aspect 35: The system uses a protected remote authority
verifier.
Dependent aspect 36: A validated lineage may be represented by a
compact authenticated proof or commitment.
Dependent aspect 37: A delegated workflow employs an optional IEV-
accepted actual-effect receipt for later causal continuation.
Dependent aspect 38: Concurrent delegated operations are checked
against protected effect-conflict reservations.
Dependent aspect 39: Delegation verification uses privacy-minimized
identity or attribute evidence.
Dependent aspect 40: All required authority and finality functions
may be integrated into one protected component or distributed across
authenticated domains while preserving mandatory operation-bound
enforcement.
The foregoing aspects are technical claim-support possibilities, not
finalized claims or guarantees of patentability.
7.50 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present Embodiment 7 discloses an architecture for preserving
protected consequential authority when autonomous tasks are
delegated, transferred, migrated, or collaboratively executed across
independently administered agents, devices, services, or computing
providers.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.2.3.64. Source page 786 of the original specification
An original principal or protected authority domain establishes a
permitted consequential effect envelope.
An originating computational entity may propose delegating a part of
the authorized task.
The protected delegation controller authenticates the proposed
recipient and verifies that the permitted downstream effect does not
exceed the source-derived authority.
An authenticated delegation transition binds the relevant source
authority, recipient identity, effect scope, resource constraints,
and protected state.
Additional delegation transitions may preserve the required authority
lineage across multiple hops.
A receiving domain independently verifies the applicable lineage and
its own mandatory security constraints.
The destination authority controller establishes scoped authorization
for the permitted operation.
The destination Finality Sink obtains or reconstructs the actual
pending consequential operation.
It verifies the source-derived authority, receiving-domain policy,
actual operation semantics, relevant resource identity, current
revocation state, and applicable consumption or ownership conditions.
Only then may the protected consequential effect be permitted.
The architecture may prevent a downstream agent from acquiring
additional consequential authority solely because it operates under a
more privileged provider, has access to broad native credentials, or
can invoke a different application interface.
The system may support both concurrent delegated branches and
exclusive task migration.
Concurrent branches may share authoritative cumulative effect
budgets.
Exclusive migration may require protected ownership transitions and
stale-owner fencing.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
These arrangements are not treated as interchangeable.
The architecture may also support bounded offline delegation,
cryptographic identity rotation, privacy-minimized verification,
current action-contract validation, cross-domain actual outcome
evidence, hardware finality control, and optional receipt-gated
causal continuation.
The protected components may be physically separate or integrated.
The system does not require a universal global agent identity
service, one commercial provider, a specific token format, or a
blockchain.
Its guarantees depend upon authenticated authority, correct effect-
semantic correspondence, current protected state, and actual
enforcement by the relevant consequential boundary.
An authenticated task message is not necessarily an execution
authorization.
A valid receiving service identity is not unrestricted source
authority.
A signed delegation object is not automatically a non-bypassable
capability.
8.3. Embodiment 11: Concurrent Resource-Version and Semantic Conflict
Finality
Original specification global pages 994-1062 (inclusive). Source
file: TECHNICAL SPECIFICATION -555-1062.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.3.1. Protected Components and Trust-Relationship Architecture Diagram
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[Concurrent agents / transactions]
|
[Resource read versions + operation semantics]
|
[Protected version/reservation controller]
|
[Conflict graph / dependency fences]
|
[Scoped non-bearer operation authority]
|
[Receiving actual Finality Sink]
|
[Fresh version check + consume-or-refuse]
Figure 17: Embodiment 11: Concurrent Resource-Version and
Semantic Conflict Finality — source-based architecture
8.3.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Two requests read same resource version]
|
[Prepare conditional reservations]
|
<Resource versions unchanged?>--NO-->[INVALIDATE]
|YES
<Semantic constraints compatible?>--NO-->[FENCE]
|YES
[Reconstruct actual pending resource op]
|
<Reservation/state/enablement current?>--NO-->[REFUSE]
|YES
[Atomic consume + effect]
Figure 18: Embodiment 11: Concurrent Resource-Version and
Semantic Conflict Finality — technical flowchart
8.3.3. Original Global Page-Indexed Technical Description
8.3.3.1. Source page 994 of the original specification
Where compatible continuation is established, a protected controller
may prepare a current scoped non-bearer finality enablement.
The requesting agent may continue performing computational work.
However, its ability to compute does not independently grant
authority to produce the corresponding external effect.
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Finality Sink independently reconstructs the actual operation
presented for effectuation.
It verifies the applicable Candidate Act, current execution-
generation state, protected drift evidence, operation-specific
authority, actual target, current revocation state, and sink-local
consumption conditions.
Only when the required predicates pass may the real consequential
effect be permitted.
The architecture may support exact execution-generation measurements,
approved compatibility sets, algorithmic logic fingerprints,
protected model-adapter state, runtime attestation, statistical drift
triggers, and combinations thereof.
The use of any particular fingerprint, cryptographic primitive,
hardware environment, or statistical detector is optional unless
required by a selected claim.
The architecture does not assert that a software signature proves
complete behavioral equivalence.
It does not assert that statistical monitoring can detect every
unsafe model output.
It does not assert that an authenticated remote model declaration
necessarily proves the actual executed computation.
It does not treat an earlier valid approval as an unrestricted
permanent right to produce consequential operations under changed
execution conditions.
Instead, the proposed protection arises from maintaining a current
verified relationship among the authorized computation, the execution
generation actually activated, and the operation actually presented
for external effectuation.
The principal candidate inventive technical contribution of
Embodiment 10 is a protected execution-finality system in which an
authenticated approved computational baseline is compared with
qualified measurements of the actual activated model or algorithm
generation, material drift causes protected revalidation or fencing
of consequential authority, and an independently enforcing Finality
Sink refuses the actual pending external operation unless current
generation-bound, operation-specific, non-bearer finality
authorization is valid.
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Its novelty, inventive step, unity, and appropriate claim scope
remain subject to examination against relevant prior art and the
enabling technical disclosure actually filed.
END OF EMBODIMENT 10 — COMPLETE TECHNICAL DISCLOSURE.
8.3.3.2. Source page 995 of the original specification
EMBODIMENT 11
PROTECTED CONCURRENT-EFFECT RECONCILIATION WITH VERSION-BOUND
RESERVATIONS, SEMANTIC CONFLICT VALIDATION, ACTUAL-OPERATION
RECONSTRUCTION, AND NON-BYPASSABLE FINALITY-SINK COMMIT CONTROL
11.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Concurrent Autonomous Execution
Using Authenticated Resource-Version Snapshots, Operation-Specific
Effect Footprints, Version-Bound Protected Reservations, Semantic
Conflict Dependencies, Monotonic Reservation Generations,
Effectuation-Time State Reconstruction, Independent Finality-Sink
Validation, Atomic Authority Consumption, and Controlled
Reconciliation of Distributed or Partially Completed Consequential
Operations
11.0.1 — General Technical Description
The present Embodiment 11 discloses systems, methods, apparatus,
protected computing components, authenticated reservation protocols,
machine-verifiable conflict representations, protected state
transitions, cryptographic and non-cryptographic authority
mechanisms, and non-limiting implementations for governing concurrent
consequential operations proposed by autonomous computational
entities.
Such entities may include artificial-intelligence agents, autonomous
assistants, application services, cloud workloads, distributed
schedulers, database clients, operating-system components, network
controllers, transaction processors, hardware accelerators, robotic
systems, or other computational entities capable of causing
persistent or externally observable effects.
Two or more computational entities may independently generate
Candidate Acts that affect overlapping resources, depend upon related
resource versions, consume shared budgets, or impose mutually
incompatible real-world consequences.
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An operation may be valid when initially evaluated but become invalid
before actual effectuation because another operation changes the
relevant resource, predicate, reservation, authorization, or external
state.
For example, two agents may inspect the same inventory state and
independently propose allocating its remaining quantity.
Each proposal may satisfy the authorization conditions when
considered against the originally observed state.
Nevertheless, permitting both operations without suitable protected
concurrency control may exceed the authorized inventory allocation.
In another example, one agent may approve a transaction using a
resource version that becomes stale after another agent commits a
conflicting modification.
8.3.3.3. Source page 996 of the original specification
The system must distinguish the fact that an operation was previously
valid from the fact that it remains valid at the actual effectuation
boundary.
The present embodiment therefore establishes protected version-
dependent authority.
In a principal implementation, an authorized controller identifies
the relevant read dependencies, intended write effects, resource
versions, and conflict predicates of a Candidate Act.
It establishes a protected reservation bound to those conditions.
Before consequential effectuation, a Finality Sink independently
reconstructs the actual pending operation and verifies that the
reservation, relevant versions, current constraints, and operation-
specific authority remain valid.
Where a conflict or stale dependency is detected, the operation
remains non-effective until a suitable protected reconciliation,
revalidation, or reauthorization procedure has succeeded.
11.0.2 — Fundamental Technical Principle
A previously valid reservation, approval, or resource observation
does not independently authorize a consequential operation after the
resource or conflict-relevant state on which that approval depended
has changed.
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A computational entity may generate or prepare an operation under an
earlier state.
However, actual authority to perform the operation must satisfy the
applicable current protected state at the moment of the governed
effectuation transition.
The system distinguishes computation, planning, provisional
reservation, commitment authorization, and actual real-world
effectuation.
11.0.3 — Principal Proposed Inventive Concept
The proposed inventive technical relationship comprises:
An authenticated Candidate Act representing a specified consequential
operation;
A protected description of relevant resource versions and read/write
dependencies;
A defined conflict predicate associated with the operation's expected
consequential footprint;
An operation-specific protected reservation;
Protected version, ownership, and reservation state;
A current conflict-validation or reconciliation procedure;
A scoped non-bearer finality enablement;
8.3.3.4. Source page 997 of the original specification
Independent reconstruction of the actual pending operation at its
Finality Sink;
And protected consumption or commitment of the valid reservation as a
necessary condition for releasing the corresponding effect.
The operation is not permitted merely because its initial
authorization and reservation were valid.
Its protected effectuation authority depends upon current consistency
between the approved operation, actual pending operation, relevant
resource versions, and applicable conflict state.
11.0.4 — Distinction from Embodiment 1
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Embodiment 1 may establish general conflict governance among
concurrent autonomous effects, including priority, reservations,
incompatible operations, and protected arbitration.
The present Embodiment 11 develops the narrower technical problem of
preserving operation-specific finality correctness after the
underlying state changes between approval and effectuation.
It focuses particularly on:
Read-version dependencies;
Multi-resource predicates;
Stale snapshots;
Reservation invalidation;
Phantom and write-skew conditions;
Reservation-to-effectuation transitions;
Atomic operation and authority consumption;
Cross-sink consistency limits;
Retry safety;
And reconciliation following partial or uncertain real effects.
The embodiment can operate as an implementation of protected conflict
governance or as a separately deployable version-bound finality-
control mechanism.
It does not require alteration of Embodiment 1.
11.0.5 — Present and Future Implementations
8.3.3.5. Source page 998 of the original specification
The disclosed architecture may be implemented through present-day
protected database gateways, transactional storage, conditional
resource interfaces, authenticated reservation services, independent
application dispatchers, network command controllers, credential
brokers, and suitable hardware effectuation boundaries.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Advanced variations may apply to multi-provider autonomous agents,
distributed infrastructure, financial workflows, accelerator resource
management, programmable networks, industrial devices, autonomous
robotic systems, and future heterogeneous computing platforms.
No particular commercial database, cloud provider, agent framework,
processor, cryptographic algorithm, or network protocol is mandatory.
11.0.6 — Relationship to Common Master Workflows
The embodiment may incorporate Candidate Acts, Non-Effective State,
Protected Enforcement Domains, scoped non-bearer finality authority,
and Finality Sinks from Common Master Workflow CW-1.
Where a successor consequential phase must depend upon a proven
earlier real effect, the receipt-constituted causal continuation
procedure of CW-2 may be applied.
Such a receipt remains a necessary enabling input for the
corresponding successor phase.
A version-bound reservation receipt does not automatically establish
that a previous real-world effect occurred.
Optional scope reauthorization from CW-3 may apply where
reconciliation requires a materially changed operation.
11.0.7 — Relationship to Earlier Embodiments
Embodiment 2 may govern real-effect causal dependencies.
Embodiment 3 may verify current correspondence between authorized and
actual resources.
Embodiment 4 may provide qualified evidence concerning remote
effects.
Embodiment 5 may govern bounded shared-resource allocations.
Embodiment 6 may verify changes in current operation semantics.
Embodiment 7 may preserve authority across independently administered
agents.
Embodiment 8 may provide cumulative privacy constraints that must be
reserved or consumed consistently.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Embodiment 9 may govern exclusive device ownership and stale-owner
fencing.
Embodiment 10 may provide current computational-generation
revalidation.
8.3.3.6. Source page 999 of the original specification
Miscellaneous Embodiment M-1 may provide additional enforcement-path
and protected-state mechanisms.
These relationships are optional and non-limiting unless required by
the selected technical implementation.
11.1 — TECHNICAL FIELD
The present embodiment relates to autonomous computing security,
optimistic and pessimistic concurrency control, protected resource
reservations, distributed state management, transactional
consistency, machine-verifiable effect dependencies, secure service
coordination, cryptographic authority, hardware effectuation control,
and execution-finality enforcement.
More particularly, it relates to verifying that a consequential
operation proposed under a previously observed state remains
authorized and technically valid when its actual effect is about to
occur.
The relevant controlled effects may include database mutations, file
commits, network configuration changes, payment instructions,
resource allocations, credential activations, data publications,
hardware commands, or physical actuation.
11.2 — SPECIFIC TECHNICAL PROBLEMS
11.2.1 — Approval-to-Effectuation Race
A Candidate Act may receive initial approval while another operation
subsequently modifies the relevant resource.
A valid earlier approval cannot automatically establish current
consistency.
11.2.2 — Stale Snapshot
An agent may construct an operation using a resource snapshot that is
no longer current.
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.2.3 — Lost Update
Two operations may independently calculate modifications from the
same earlier value.
Without suitable enforcement, one may overwrite the other's effect.
11.2.4 — Write Skew
Two operations may update different resources after observing a
shared condition.
8.3.3.7. Source page 1000 of the original specification
The resulting combined state may violate an invariant despite each
individual resource update appearing nonconflicting.
11.2.5 — Phantom Dependency
An operation may depend upon the absence or number of resources
satisfying a predicate.
Another operation may insert or remove a matching resource.
A check limited to known individual resource versions may fail to
detect the changed predicate.
11.2.6 — Concurrent Allocation
Several agents may reserve or consume the same finite quantity.
11.2.7 — Reservation Reuse
A valid reservation may be copied or replayed for another
consequential operation.
11.2.8 — Resource-Alias Change
A resource identifier may refer to a different actual object when the
operation reaches the Finality Sink.
11.2.9 — Multi-Resource Invariant
An operation may require a consistency relationship across several
resources.
11.2.10 — Stale Reservation After Policy Update
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The applicable protected authorization or conflict policy may change
after reservation.
11.2.11 — Concurrent Revocation
A principal may revoke the operation while it remains queued.
11.2.12 — Cross-Domain Version Disagreement
Two receiving domains may hold inconsistent copies of the same
resource state.
11.2.13 — Partial Distributed Commit
One external effect may complete while another participating effect
fails.
11.2.14 — Unknown External Outcome
The initiating system may lose acknowledgement after a possible real
effect.
11.2.15 — Unsafe Retry
8.3.3.8. Source page 1001 of the original specification
An agent may retry an operation whose earlier effect may already have
occurred.
11.2.16 — Conflict Reconciliation Scope Expansion
A reconciliation algorithm may modify the proposed operation to
resolve a conflict.
The altered effect may exceed the original authorization.
11.2.17 — Conflicting Physical Operations
Two controllers may attempt incompatible commands on a shared
physical resource.
11.2.18 — Distributed Lease Expiry
A reservation lease may expire while the earlier holder remains
active.
11.2.19 — Alternate-Path Bypass
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An agent may use a different interface that does not enforce the
protected reservation.
11.2.20 — Technical Objective
A candidate objective technical problem is:
How to prevent a previously authorized autonomous operation from
producing a stale, conflicting, duplicated, or otherwise
impermissible consequence after changes to resource versions, shared
predicates, reservations, or protected authority state, by binding
execution permission to operation-specific current consistency
conditions and independently enforcing those conditions at the actual
consequential sink.
11.3 — ESTABLISHED CONCURRENCY TECHNIQUES AND LIMITATIONS
11.3.1 — Conditional Requests
A resource server may condition a state-changing request upon a
current resource version.
This is established technology.
The embodiment may use such a conditional operation as a concrete
effectuation mechanism.
11.3.2 — Optimistic Concurrency Control
An operation may read a version, perform computation, and validate
that version before committing.
Such methods are established.
8.3.3.9. Source page 1002 of the original specification
The proposed extension concerns the binding of validated concurrency
state to independently verifiable, operation-specific consequential
authority at the actual release sink.
11.3.3 — Pessimistic Locking
A system may lock resources before modifying them.
Locking is an established mechanism and may be used in certain
implementations.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A lock does not automatically establish the original principal's
authority to perform every possible mutation.
11.3.4 — Serializable Transactions
A database may enforce a serializable outcome for committed database
transactions.
This is established.
Its guarantee applies within the relevant transaction and isolation
model.
It does not automatically include independent external effects such
as emails, payments, actuator movements, or operations at
nonparticipating services.
11.3.5 — Distributed Transactions
A distributed transaction protocol may coordinate commit decisions
among participating resources.
Such techniques are established.
The present embodiment may incorporate them where the participants
and their effectuation interfaces support the required guarantees.
11.3.6 — Idempotency Keys
An operation identifier may assist in recognizing repeated requests.
Idempotency mechanisms are established.
A key alone does not ensure that every external recipient implements
equivalent duplicate suppression or that the actual operation still
satisfies current authorization.
11.3.7 — Fencing Tokens
Monotonic fencing mechanisms may prevent stale resource owners from
committing further modifications at participating sinks.
This is established.
8.3.3.10. Source page 1003 of the original specification
The proposed architecture may additionally bind the fencing state to
the Candidate Act and its actual effect.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.3.8 — Sagas and Compensation
Distributed workflows may use compensating operations after partial
completion.
Such techniques are established.
A compensation is a new real effect and may not perfectly reverse the
original consequence.
11.3.9 — Candidate Distinction
The relevant inventive-step analysis should therefore focus upon the
specific combination of protected operation scope, version
dependencies, conflict reservation, current authority, actual-effect
reconstruction, and Finality-Sink consumption—not upon the isolated
existence of locking, transactions, or version numbers.
11.4 — PRINCIPAL PROTECTED ARCHITECTURE
A representative system comprises a Candidate Act Constructor, a
Protected Resource-State Observer, an Effect-Footprint Resolver, a
Conflict-Dependency Verifier, a Protected Reservation Controller, a
Version and Predicate Registry, a Current Authority Controller, a
Reconciliation Controller, and one or more Finality Sinks.
Optional components may include a shared-budget service,
authenticated resource-alias resolver, distributed coordinator,
credential broker, database commit controller, hardware command
controller, protected outcome observer, and recovery-state manager.
The components may be integrated into one protected domain or
distributed across authenticated administrative environments.
11.4.1 — Candidate Act Constructor
The constructor identifies the proposed actual effect and its
permitted operation scope.
11.4.2 — Resource-State Observer
The observer obtains qualified resource identities, versions, and
applicable predicates.
11.4.3 — Effect-Footprint Resolver
The resolver identifies which resources or invariants may be affected
by the operation.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.4.4 — Conflict-Dependency Verifier
The verifier evaluates the relevant read/write and semantic conflict
conditions.
8.3.3.11. Source page 1004 of the original specification
11.4.5 — Protected Reservation Controller
The controller reserves or restricts the applicable effectuation
authority against current protected state.
11.4.6 — Reconciliation Controller
The controller handles stale or conflicting operations according to
defined protected procedures.
11.4.7 — Finality Sink
The sink independently verifies current actual-operation conditions
before permitting the governed effect.
11.5 — BROAD TECHNICAL DEFINITIONS
11.5.1 — Version-Bound Candidate Act
A Version-Bound Candidate Act, or VBCA, means a Candidate Act
associated with one or more resource-version or protected-state
preconditions.
11.5.2 — Protected Resource Version
A Protected Resource Version, or PRV-11, means an authenticated or
authoritative representation identifying a particular relevant state
generation of a resource.
11.5.3 — Resource Dependency Snapshot
A Resource Dependency Snapshot, or RDS-11, means a representation of
the resource identities, versions, and predicates relied upon when an
operation is prepared.
11.5.4 — Effect Footprint
An Effect Footprint, or EFP-11, means a machine-verifiable
description of the resources, operations, quantities, destinations,
or state invariants that may be affected by a Candidate Act.
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.5.5 — Protected Read Dependency
A Protected Read Dependency means a resource value, version, or
predicate whose correctness is required by the proposed consequential
operation.
11.5.6 — Protected Write Dependency
A Protected Write Dependency means a resource or state element
intended to be modified by the consequential operation.
8.3.3.12. Source page 1005 of the original specification
11.5.7 — Predicate Dependency
A Predicate Dependency means a defined condition over a set or class
of resources that must remain valid for the operation.
11.5.8 — Semantic Conflict Predicate
A Semantic Conflict Predicate, or SCP-11, means a machine-verifiable
rule determining whether the combined effects of relevant operations
violate a protected constraint.
11.5.9 — Version-Bound Protected Reservation
A Version-Bound Protected Reservation, or VBPR, means protected state
associating a particular Candidate Act with specified versions,
effect scope, resource conditions, and reservation-generation state.
11.5.10 — Reservation Generation
A Reservation Generation, or RG-11, means a protected generation or
fencing value associated with a reservation's validity.
11.5.11 — Protected Conflict State
Protected Conflict State, or PCS-11, means authenticated current
information concerning reservations, committed changes, pending
effects, and other relevant conflict conditions.
11.5.12 — Protected Commit Eligibility
Protected Commit Eligibility means satisfaction of all defined
conditions required for a governed consequential operation to proceed
from reservation to actual effectuation.
11.5.13 — Effectuation-Time Version Verification
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Effectuation-Time Version Verification means checking the relevant
current resource versions or predicates at the actual consequential
boundary.
11.5.14 — Current Conflict Reconciliation
Current Conflict Reconciliation means evaluating and resolving a
stale, overlapping, or incompatible effect condition before new
effectuation authority is established.
11.5.15 — Protected Rebase
A Protected Rebase means recomputing a proposed operation against a
newer qualified state while preserving the applicable original
authorization limits.
11.5.16 — Reconciliation Authority
Reconciliation Authority means authenticated permission to execute a
defined conflict-resolution procedure.
8.3.3.13. Source page 1006 of the original specification
11.5.17 — Operation-Specific Commit Capability
An Operation-Specific Commit Capability, or OSCC, means scoped non-
bearer enablement for the actual consequential operation under
current protected resource and reservation conditions.
11.5.18 — Reservation Consumption Record
A Reservation Consumption Record, or RCR-11, means protected state
establishing whether a particular reservation has been exercised or
otherwise resolved.
11.5.19 — Protected Effect Commit Record
A Protected Effect Commit Record, or PECR-11, means authenticated
information concerning the protected commitment or attempted
effectuation of a particular operation.
11.5.20 — External Outcome Uncertainty
External Outcome Uncertainty means a condition in which the protected
system cannot determine whether a particular external consequence
actually occurred.
11.5.21 — Protected Retry Fence
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Protected Retry Fence means a condition preventing unsafe repeated
effectuation while a prior attempt remains unresolved.
11.5.22 — Protected Conflict Graph
A Protected Conflict Graph, or PCG-11, means a representation of
relevant dependencies or incompatibilities among Candidate Acts and
resource-state conditions.
11.5.23 — Protected Reservation Expiry
Protected Reservation Expiry means a defined transition rendering a
reservation ineligible for further effectuation under its prior
authority.
11.5.24 — Resource Correspondence Commitment
A Resource Correspondence Commitment means protected evidence
associating an authorized resource referent with the actual resource
presented at the Finality Sink.
11.5.25 — Multi-Resource Effect Envelope
A Multi-Resource Effect Envelope means a protected description of
several resource effects or invariants required by one Candidate Act.
11.5.26 — Protected Partial-Effect State
Protected Partial-Effect State means authenticated information
identifying consequential components known or potentially known to
have occurred in a multi-effect operation.
8.3.3.14. Source page 1007 of the original specification
11.5.27 — Conditional Effectuation Sink
A Conditional Effectuation Sink means a Finality Sink capable of
enforcing the applicable version, reservation, authority, and actual-
operation preconditions before releasing its controlled effect.
11.5.28 — Authorized Commutativity Predicate
An Authorized Commutativity Predicate means a defined rule
establishing when particular operations may be performed in different
orders without violating protected correctness conditions.
11.5.29 — Conflict-Dependent Finality Authority
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Conflict-Dependent Finality Authority means protected operation-
specific authority valid only while the required current conflict and
resource-state predicates are satisfied.
11.5.30 — Protected Reconciliation Receipt
A Protected Reconciliation Receipt, or PRR-11, means authenticated
evidence of a defined reconciliation decision and its protected state
inputs.
The receipt does not independently prove a real external effect
unless separately qualified to establish that property.
11.6 — PROTECTED RESOURCE-VERSION REPRESENTATION
A protected resource-version record may include:
PROTECTED_RESOURCE_VERSION = { resource_identifier,
resource_identity_generation, authoritative_version,
relevant_predicate_generation, resource_type,
current_owner_or_controller, permitted_mutation_classes,
applicable_authority_epoch, protected_state_authentication }
A particular resource may use a monotonic generation, transaction
sequence, authenticated object version, or other authoritative
representation.
A version must refer to the resource state relevant to the operation.
An arbitrary timestamp is not necessarily a sufficient version.
8.3.3.15. Source page 1008 of the original specification
Likewise, a cached client-side identifier may not establish current
authority unless the actual sink can verify it against authoritative
state.
11.7 — PROTECTED EFFECT FOOTPRINT
The EFP-11 may identify the direct and relevant indirect effects of a
Candidate Act.
A representative structure is:
EFFECT_FOOTPRINT = { candidate_act_reference, read_resource_set,
write_resource_set, predicate_dependencies,
target_resource_identities, expected_resource_versions,
proposed_mutation_descriptors, quantitative_effect_bounds,
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
required_global_invariants, declared_external_effects,
current_operation_contract, effectuation_sink_references,
protected_footprint_authentication }
The effect footprint may be exact for a well-defined transaction.
For a dynamic workflow, it may be conservatively approximated.
Where a previously unknown effect is introduced, the system may
require renewed validation.
A footprint that omits an effect-capable path cannot automatically
establish the absence of conflicts involving that path.
11.8 — READ-SET AND WRITE-SET VALIDATION
11.8.1 — Read Dependencies
A Candidate Act may rely upon one or more resources having specified
values or versions.
11.8.2 — Write Dependencies
The operation may modify one or more resources.
11.8.3 — Read-Write Conflict
8.3.3.16. Source page 1009 of the original specification
A concurrent operation may modify a value upon which the Candidate
Act relied.
11.8.4 — Write-Write Conflict
Two operations may attempt incompatible modifications of the same
resource.
11.8.5 — Read-Read Compatibility
Two operations that only read the same immutable or appropriately
versioned resource may not conflict.
11.8.6 — Predicate Conflict
An operation may alter the truth of a predicate used by another
operation even without modifying an explicitly named resource in the
earlier read set.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.8.7 — Application-Specific Invariants
The conflict verifier may enforce invariants involving counts,
totals, exclusive ownership, allocation limits, or relational
conditions.
11.8.8 — Actual-Operation Verification
The Finality Sink verifies that the real pending mutation corresponds
to the footprint and current authority.
11.9 — FORMAL CONFLICT MODEL
represent a Candidate Act.
represent the operation's protected read dependencies.
represent its proposed write or consequential effect dependencies.
8.3.3.17. Source page 1010 of the original specification
represent applicable predicates or invariants.
represent the authenticated version state relied upon by CA_i.
Two operations may have a relevant potential conflict when:
W_i INTERSECTS R_j
W_j INTERSECTS R_i
W_i INTERSECTS W_j
or when their combined actual effects violate a specified predicate:
NOT PRESERVES_INVARIANT( EFFECT_i, EFFECT_j, P )
An intersection does not automatically establish that the operations
must be rejected.
The protected system may evaluate whether the operations commute, may
be serialized safely, or may be reconciled under a defined technical
rule.
The permitted conclusion depends upon the actual resource semantics.
11.10 — SEMANTIC COMMUTATIVITY
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Some operations may affect the same resource without producing an
invalid outcome.
For example, two independent increments may be combinable if the
protected resource supports an authorized atomic addition and the
cumulative bound remains valid.
However, two overwrites based upon stale independent reads may not be
safely combined.
A protected commutativity predicate may identify a class of
operations whose ordering does not change the relevant authorized
outcome.
8.3.3.18. Source page 1011 of the original specification
11.10.1 — Exact Commutativity
Two operations may satisfy a defined equivalence relationship when
executed in either order.
11.10.2 — Conditional Commutativity
Two operations may commute only while a shared limit or other
protected condition remains satisfied.
11.10.3 — Noncommutative Operations
A conflict may require ordering, revalidation, or denial.
11.10.4 — Protected Evidence
A compatible operation class may be authenticated through the
relevant operation contract.
11.10.5 — No Unrestricted Merge
The system does not assume that arbitrary operations are safe to
merge simply because they access the same resource type.
11.11 — VERSION-BOUND PROTECTED RESERVATION
A representative VBPR may comprise:
VERSION_BOUND_PROTECTED_RESERVATION = { reservation_identifier,
candidate_act_commitment, original_authority_reference,
effect_footprint_commitment, relevant_read_versions,
intended_write_scope, protected_predicate_commitments,
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
reservation_generation, reservation_owner,
resource_identity_commitments, conflict_policy_epoch,
reserved_quantity_or_budget, validity_conditions,
designated_finality_sinks, current_revocation_reference,
consumption_reference, protected_reservation_authentication }
The reservation may be committed within the relevant Protected
Enforcement Domain.
8.3.3.19. Source page 1012 of the original specification
The reservation does not itself perform the governed external effect.
It makes the operation conditionally eligible for later effectuation.
The actual Finality Sink determines whether the reservation remains
valid when presented.
11.12 — RESERVATION MODES
11.12.1 — Exclusive Reservation
One operation may reserve exclusive authority over a defined effect
or resource.
11.12.2 — Shared Read Reservation
Multiple operations may obtain compatible read reservations.
11.12.3 — Bounded Quantity Reservation
An operation may reserve a specified amount of a finite shared
resource.
11.12.4 — Predicate Reservation
An operation may reserve a protected condition, such as a permitted
total count.
11.12.5 — Optimistic Reservation
The operation may be prepared without exclusive resource locking,
provided current consistency is verified before commit.
11.12.6 — Pessimistic Reservation
The controller may hold a protected resource lock or equivalent
restriction.
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.12.7 — Multi-Resource Reservation
Several resources may participate in a protected reservation under an
appropriate consistency mechanism.
11.12.8 — Escrow-Style Allocation
A shared total may be partitioned into bounded reservations for
independently operating domains.
11.12.9 — Lease-Based Reservation
A reservation may expire under specified protected time or generation
conditions.
11.12.10 — No Universal Mode Requirement
8.3.3.20. Source page 1013 of the original specification
The selected reservation method depends upon the operation's effect
class, trust model, required consistency, and resource capabilities.
11.13 — AUTHORITY AND RESERVATION SEPARATION
The architecture distinguishes authorization to propose an operation
from reservation of the resources required to perform it.
An initial principal may authorize the agent to purchase a specified
quantity of goods.
A resource controller may determine whether the requested quantity is
currently available.
A protected reservation may temporarily allocate the relevant
quantity.
Nevertheless, the actual purchase or inventory mutation remains a
separate consequential operation.
The Finality Sink must verify both the original task authority and
the current protected reservation before permitting the real effect.
A reservation for one operation cannot automatically be reused to
perform an unrelated operation against the same resource.
11.14 — CURRENT VERSION AND POLICY EPOCHS
11.14.1 — Resource Epoch
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The resource state may advance as operations commit.
11.14.2 — Reservation Epoch
A reservation may be associated with the protected generation at
which it was established.
11.14.3 — Policy Epoch
Current conflict and authorization rules may have a protected
version.
11.14.4 — Authority Epoch
The original principal's authority may be revoked or amended.
11.14.5 — Resource Identity Generation
A resource alias may be rebound to another actual object.
8.3.3.21. Source page 1014 of the original specification
11.14.6 — Sink-Time Check
The sink verifies the required combination of current epochs.
11.14.7 — Stale Evidence
A previous favorable verification result does not bypass current
mandatory epoch checks.
11.14.8 — Monotonic State
Where required, protected state prevents unsafe rollback to earlier
permissive generations.
11.15 — PRE-COMMIT CONSISTENCY VALIDATION
Before establishing finality authority, a protected verifier
evaluates:
The Candidate Act's original authorization;
Current relevant resource versions;
The operation's declared read dependencies;
The actual intended write effects;
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Applicable predicate and shared-budget conditions;
Current reservations held by other operations;
Relevant policy and authority epochs;
And the ability of the intended sink to enforce the corresponding
conditional effect.
A successful initial check may produce an authenticated validation
decision.
However, where resource state can change before effectuation, the
protocol must provide suitable atomic reservation, current version
checking, or another mechanism preventing the validation result from
becoming stale.
A signed validation record that does not bind current protected state
is insufficient for the stronger consistency guarantee.
11.16 — FINALITY-SINK COMMIT VALIDATION
At the actual consequential boundary, the Finality Sink obtains or
reconstructs the pending operation.
8.3.3.22. Source page 1015 of the original specification
The sink verifies that the operation corresponds to the approved
Candidate Act and effect footprint.
It checks the applicable current resource state.
It validates the reservation and relevant conflict constraints.
It confirms that the scoped finality authority is valid for the
particular operation and sink.
Where the protected design uses optimistic concurrency, the sink may
execute a conditional mutation atomically with its version check.
Where the sink cannot atomically verify and commit the resource
mutation, an appropriately stronger upstream or downstream
enforcement protocol may be required.
11.16.1 — Actual Target
The sink resolves the real affected resource rather than trusting
only an upstream resource label.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.16.2 — Actual Mutation
The sink verifies the effective operation parameters.
11.16.3 — Current Version
The sink checks the relevant authoritative state.
11.16.4 — Reservation Validity
The reservation must be current and applicable.
11.16.5 — Conflicting Reservation
The sink checks relevant protected conflict state.
11.16.6 — Protected Consumption
The applicable authority is reserved or consumed under a protected
transition.
11.16.7 — Effectuation
The real effect is permitted only after the mandatory predicates
pass.
11.17 — ATOMIC AUTHORITY CONSUMPTION AND MUTATION
A particularly useful implementation places the authorization-
consumption state and governed resource mutation within one suitable
transactional boundary.
8.3.3.23. Source page 1016 of the original specification
The transaction may verify the current resource version, applicable
conflict predicate, operation identity, and remaining authority
before committing.
Where the conditions pass, the resource mutation and consumption
state are committed together.
Where they fail, the governed mutation does not occur under that
transaction.
Conceptually:
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
ATOMIC { VERIFY_CURRENT_RESOURCE_VERSION VERIFY_CURRENT_RESERVATION
VERIFY_OPERATION_SCOPE VERIFY_CURRENT_AUTHORITY CONSUME_AUTHORITY
COMMIT_RESOURCE_MUTATION }
This example assumes that the transactional system can actually cover
the listed state.
Where consumption and effectuation occur in separate systems, the
system must not claim the same atomicity merely because both steps
are executed in sequence.
A separate protected reconciliation mechanism may be required.
11.18 — MULTI-RESOURCE CONSISTENCY
An operation may require changes to several resource objects.
For example, a protected allocation may simultaneously reduce one
inventory balance and increase a corresponding committed allocation.
If both changes occur within one authoritative transactional resource
domain, an appropriate transaction may preserve the required
invariant.
If the resources reside in separate domains, an additional
coordination procedure may be necessary.
11.18.1 — Shared Transaction Domain
A suitable transaction manager may verify and commit several
dependent mutations.
11.18.2 — Distributed Participating Resources
Participating sinks may support a protected prepare and commit
protocol.
11.18.3 — Nonparticipating External Resource
8.3.3.24. Source page 1017 of the original specification
A remote service may lack the primitives required for atomic
coordination.
11.18.4 — Consistency Classification
The protected controller identifies the achievable consistency
guarantee for the actual group of effects.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.18.5 — Partial Completion
A partially completed external sequence is represented as real state
rather than automatically treated as rolled back.
11.18.6 — Reconciliation
The controller may schedule separately authorized corrective
operations.
11.19 — CROSS-SINK COMMIT MODES
11.19.1 — Single-Sink Atomic Mode
One protected Finality Sink controls the entire relevant effect and
reservation state.
11.19.2 — Coordinated Transactional Mode
Several sinks implement compatible prepare/commit procedures with
appropriate durable state.
11.19.3 — Reservation-Escrow Mode
A protected controller allocates nonoverlapping bounded resources to
separate effectuation domains.
11.19.4 — Sequential Causal Mode
One effect occurs first, and a successor operation requires qualified
evidence of the earlier real effect.
Where applicable, the CW-2 receipt-constituted continuation mechanism
may govern that dependency.
11.19.5 — Compensating Workflow Mode
The system applies separately authorized corrective effects after
partial completion.
11.19.6 — No Universal Atomicity
A set of independent remote external effects does not become globally
atomic merely because a local controller records a common transaction
identifier.
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.25. Source page 1018 of the original specification
11.20 — PROTECTED RECONCILIATION
When a reservation becomes stale or conflicting, the system may
perform a protected reconciliation procedure.
The reconciliation controller determines whether the original
Candidate Act can still be performed without expanding its authorized
effect.
11.20.1 — Revalidation
The original operation may be reevaluated against current state.
11.20.2 — Protected Rebase
Operation parameters may be recomputed from the current resource
version.
11.20.3 — Safe Reordering
The system may select another valid order for compatible operations.
11.20.4 — Scope-Preserving Reduction
An operation may be narrowed where the applicable original
authorization permits that change.
11.20.5 — Reservation Reallocation
An invalid reservation may be replaced through a new protected state
transition.
11.20.6 — Explicit Reauthorization
A materially changed effect may require renewed authority from the
applicable principal.
11.20.7 — Denial
Where no suitable safe reconciliation exists, the operation remains
withheld.
11.20.8 — New Authority Binding
A reconciled operation receives current operation-specific protected
finality authority.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.20.9 — No Silent Expansion
Conflict resolution is not an independent source of unrestricted
authority.
8.3.3.26. Source page 1019 of the original specification
11.21 — RECONCILIATION EVIDENCE
A representative protected reconciliation record may include:
PROTECTED_RECONCILIATION_RECORD = { original_candidate_act,
original_effect_footprint, original_resource_versions,
detected_conflict, current_resource_versions,
selected_reconciliation_procedure, reconciled_operation_commitment,
scope_preservation_result, updated_reservation_reference,
current_policy_epoch, verifier_identity, verifier_authority,
protected_record_authentication }
The record may support a later finality decision.
It does not replace sink-time validation where another concurrent
change could occur after reconciliation.
11.22 — PARTIAL EFFECTS AND UNCERTAIN OUTCOMES
An operation involving several real-world effects may partially
complete.
For example, an externally visible notification may be transmitted
before a related database update fails.
The system must distinguish:
No effect having occurred;
An effect having been prepared;
An effect having been dispatched;
An effect known to have completed;
An effect known not to have completed;
And an effect whose outcome remains uncertain.
An authenticated local dispatch record does not necessarily prove
remote completion.
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.27. Source page 1020 of the original specification
An earlier version reservation does not itself prove that a
particular external effect occurred.
Where a successor phase depends upon the earlier real effect, the
applicable validated actual-effect receipt may be required under CW-
2.
Where a prior effect remains uncertain, the controller may maintain a
retry fence until the necessary reconciliation occurs.
11.23 — IDEMPOTENCY AND RETRY CONTROL
11.23.1 — Stable Operation Identity
The Candidate Act may have a protected operation identifier.
11.23.2 — Retry Identity
A permitted retry may reference the original operation and earlier
attempt state.
11.23.3 — Parameter Binding
The retry identity may be bound to the originally authorized
operation parameters.
11.23.4 — Duplicate-Suppressing Sink
A participating sink may recognize a repeated operation identifier
and avoid additional effectuation.
11.23.5 — Changed Operation
A retry with materially changed parameters may require a new
Candidate Act or reauthorization.
11.23.6 — Unknown Outcome
The controller does not automatically retry an effect whose
completion remains uncertain.
11.23.7 — External Service Qualification
The duplicate-suppression guarantee depends upon the actual receiving
service's behavior.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.23.8 — Protected Retry Authority
A retry may require current version validity, relevant reservation
state, and applicable effectuation authority.
8.3.3.28. Source page 1021 of the original specification
11.24 — CONFLICT-DEPENDENT FINALITY AUTHORITY
A representative operation-specific enablement may comprise:
CONFLICT_DEPENDENT_FINALITY_AUTHORITY = { candidate_act_reference,
authorized_effect_envelope, effect_footprint_commitment,
expected_resource_versions, predicate_validation_commitment,
protected_reservation_reference, reservation_generation,
designated_finality_sink, current_resource_identity,
current_conflict_policy_epoch, current_authority_epoch,
reconciliation_reference_if_any, operation_identity,
consumption_reference, protected_authority_authentication }
The authority may be cryptographically authenticated or maintained in
protected controller-local state.
It is non-bearer where its exercise requires valid identity,
operation, sink, resource, and current protected state.
A copied authority object does not automatically permit a different
effect.
A previously valid reservation is not automatically sufficient after
current resource versions change.
11.25 — PROTECTED CONFLICT STATE MACHINE
A non-limiting state machine may comprise:
PROPOSED: A Candidate Act has been generated.
RESOURCE_OBSERVATION_PENDING: Required resource-state evidence has
not yet been obtained.
SNAPSHOT_ESTABLISHED: Relevant resource versions and predicates have
been recorded.
FOOTPRINT_PENDING: The operation's relevant effect dependencies are
being determined.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.29. Source page 1022 of the original specification
CONFLICT_VALIDATION_PENDING: The protected controller evaluates
current resource and conflict conditions.
CONFLICT_DETECTED: The proposed effect is incompatible with current
protected constraints.
RESERVATION_PENDING: A protected reservation transition has been
requested.
RESERVED: A valid version-bound reservation exists.
RESERVATION_STALE: The relevant versions or predicates no longer
satisfy the reservation.
RECONCILIATION_PENDING: A protected reconciliation procedure is
underway.
RECONCILED: A valid updated operation and protected reservation
exist.
AUTHORITY_PREPARED: Scoped finality authority is ready.
SINK_VALIDATION_PENDING: The actual pending operation awaits finality
verification.
COMMIT_ELIGIBLE: Current mandatory predicates pass.
EFFECT_ATTEMPTED: The consequential operation has been initiated.
EFFECT_CONFIRMED: Suitable evidence establishes the defined real-
effect outcome.
EFFECT_UNCERTAIN: The actual result remains unresolved.
AUTHORITY_CONSUMED: The relevant protected authority has been
consumed.
RECOVERY_PENDING: A separate corrective or retry procedure is
required.
TERMINATED: The operation has completed, been denied, or been validly
abandoned.
The state transitions may be implemented through protected software,
hardware registers, authenticated transaction records, or equivalent
technical mechanisms.
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.26 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Original Authority. The principal or applicable
protected controller authorizes a specified consequential task.
Step 2 — Construct Candidate Act. The requesting computational entity
proposes an operation.
Step 3 — Hold Operation Non-Effective. The actual effect remains
withheld.
8.3.3.30. Source page 1023 of the original specification
Step 4 — Resolve Actual Resource Referents. The controller
identifies affected resources.
Step 5 — Obtain Qualified Current Snapshot. Relevant resource
versions and predicates are collected.
Step 6 — Derive Effect Footprint. The system identifies read, write,
quantity, and invariant dependencies.
Step 7 — Verify Initial Authorization. The operation must remain
within the permitted effect envelope.
Step 8 — Evaluate Conflicts. The protected conflict verifier checks
current relevant reservations and resource state.
Step 9 — Select Reservation Mode. The system chooses the applicable
exclusive, shared, bounded, optimistic, or other valid reservation
procedure.
Step 10 — Commit Version-Bound Reservation. The protected controller
atomically records the necessary reservation conditions.
Step 11 — Prepare Scoped Finality Authority. A non-bearer operation-
specific enablement is established.
Step 12 — Detect Relevant State Changes. The system monitors or
verifies current versions, predicates, and authority epochs.
Step 13 — Present Actual Operation. The requester submits the
effect-capable operation.
Step 14 — Reconstruct Actual Pending Effect. The Finality Sink
independently determines the operation actually presented.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 15 — Verify Resource Correspondence. The actual targets are
checked against the authorized resource identities.
Step 16 — Verify Current Versions. The sink checks the applicable
authoritative state.
Step 17 — Verify Reservation. The reservation must still apply to
the actual operation.
Step 18 — Verify Conflict Predicates. Relevant protected invariants
must remain satisfied.
Step 19 — Verify Authority. The sink checks current operation-
specific authorization and revocation.
Step 20 — Commit or Withhold. The protected resource controller
either performs the effect under the required conditions or refuses
it.
Step 21 — Consume Authority. The applicable operation-specific
permission is atomically or otherwise safely accounted for.
Step 22 — Record Attempt State. The system commits appropriate
effectuation evidence.
8.3.3.31. Source page 1024 of the original specification
Step 23 — Reconcile Outcomes. Confirmed, failed, partial, or unknown
results are handled according to protected state.
Step 24 — Revalidate if Stale. A stale operation may undergo
controlled reconciliation.
Step 25 — Govern Successor Operations. Dependent further effects
require their own current authority and any applicable real-effect
receipts.
11.27 — REFERENCE PSEUDOCODE: EFFECT FOOTPRINT CONSTRUCTION
FUNCTION CONSTRUCT_PROTECTED_EFFECT_FOOTPRINT( candidate_act,
protected_resource_observer ): REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) REQUIRE
VERIFY_ORIGINAL_AUTHORITY(candidate_act) resources =
RESOLVE_ACTUAL_RESOURCE_REFERENTS( candidate_act ) snapshot =
protected_resource_observer
.OBSERVE_AUTHORITY_RELEVANT_STATE(resources) IF
REQUIRED_SNAPSHOT_INCOMPLETE(snapshot): RETURN HOLD read_dependencies
= DERIVE_REQUIRED_READ_SET( candidate_act, snapshot )
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
write_dependencies = DERIVE_REQUIRED_WRITE_SET( candidate_act )
predicate_dependencies = DERIVE_REQUIRED_PREDICATES( candidate_act,
snapshot ) footprint = PROTECTED_COMMIT({ candidate:
HASH(candidate_act), resource_identities:
8.3.3.32. Source page 1025 of the original specification
HASH_CANONICAL(resources), snapshot: HASH(snapshot), read_set:
HASH_CANONICAL(read_dependencies), write_set:
HASH_CANONICAL(write_dependencies), predicates:
HASH_CANONICAL(predicate_dependencies), policy_epoch:
CURRENT_POLICY_EPOCH() }) RETURN footprint
The footprint must include the dependency properties required by the
claimed consistency guarantee.
11.28 — REFERENCE PSEUDOCODE: VERSION-BOUND RESERVATION
FUNCTION RESERVE_CONCURRENT_EFFECT( candidate_act, effect_footprint,
protected_reservation_controller ): REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) REQUIRE
VERIFY_EFFECT_FOOTPRINT(effect_footprint) current_state =
protected_reservation_controller .LOAD_AUTHORITATIVE_RESOURCE_STATE(
effect_footprint.resources ) REQUIRE VERIFY_READ_DEPENDENCIES(
effect_footprint, current_state ) REQUIRE
VERIFY_PREDICATE_DEPENDENCIES( effect_footprint, current_state )
8.3.3.33. Source page 1026 of the original specification
REQUIRE VERIFY_CURRENT_AUTHORITY( candidate_act ) reservation =
protected_reservation_controller .ATOMIC_VALIDATE_AND_RESERVE({
candidate: HASH(candidate_act), effect_footprint:
HASH(effect_footprint), expected_state:
current_state.version_commitment, current_conflict_state:
CURRENT_CONFLICT_STATE(), reservation_generation:
NEXT_RESERVATION_GENERATION(), effect_bounds:
AUTHORIZED_EFFECT_BOUNDS(candidate_act) }) IF reservation !=
COMMITTED: RETURN CONFLICT_OR_STALE_STATE RETURN
reservation.protected_reference
The atomicity of this function must be supplied by an authoritative
protected state mechanism.
11.29 — REFERENCE PSEUDOCODE: CURRENT CONFLICT VALIDATION
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
FUNCTION VERIFY_CURRENT_CONFLICT_ELIGIBILITY( candidate_act,
reservation, actual_operation, protected_conflict_verifier ): REQUIRE
VERIFY_RESERVATION_AUTHENTICITY( reservation ) REQUIRE
VERIFY_RESERVATION_CANDIDATE_BINDING( reservation,
8.3.3.34. Source page 1027 of the original specification
candidate_act ) REQUIRE VERIFY_ACTUAL_OPERATION_FOOTPRINT(
actual_operation, reservation ) current = protected_conflict_verifier
.OBSERVE_CURRENT_RELEVANT_STATE( reservation.resources ) IF NOT
REQUIRED_VERSIONS_VALID( reservation, current ): RETURN
REVALIDATION_REQUIRED IF NOT REQUIRED_PREDICATES_VALID( reservation,
current ): RETURN CONFLICT IF NOT SHARED_LIMITS_VALID( reservation,
current ): RETURN CONFLICT IF NOT CURRENT_AUTHORITY_VALID(
candidate_act ): RETURN DENY RETURN PROTECTED_COMMIT_ELIGIBLE
11.30 — REFERENCE PSEUDOCODE: ACTUAL FINALITY-SINK COMMIT
FUNCTION EFFECTUATE_VERSION_BOUND_OPERATION( candidate_act,
finality_authority, protected_finality_sink ): actual_operation =
protected_finality_sink .RECONSTRUCT_PENDING_OPERATION() IF
actual_operation IS NULL:
8.3.3.35. Source page 1028 of the original specification
RETURN DENY REQUIRE protected_finality_sink
.VERIFY_ACTUAL_RESOURCE_IDENTITIES( actual_operation ) REQUIRE
protected_finality_sink .VERIFY_CANDIDATE_ACT_BINDING( candidate_act,
actual_operation ) REQUIRE protected_finality_sink
.VERIFY_CURRENT_VERSION_PRECONDITIONS( finality_authority ) REQUIRE
protected_finality_sink .VERIFY_CURRENT_RESERVATION(
finality_authority ) REQUIRE protected_finality_sink
.VERIFY_CURRENT_CONFLICT_PREDICATES( actual_operation ) REQUIRE
protected_finality_sink .VERIFY_CURRENT_AUTHORITY_AND_REVOCATION()
REQUIRE protected_finality_sink .VERIFY_OPERATION_SPECIFIC_SCOPE(
actual_operation, finality_authority ) result =
protected_finality_sink .ATOMIC_CONDITIONAL_EFFECT_AND_CONSUME({
actual_operation: actual_operation, finality_authority:
finality_authority, expected_resource_state:
finality_authority.expected_versions, reservation:
finality_authority.reservation_reference })
8.3.3.36. Source page 1029 of the original specification
IF result == CONDITION_FAILED: RETURN HOLD_FOR_RECONCILIATION IF
result == COMMITTED: RETURN EFFECT_COMMITTED RETURN
EFFECT_OUTCOME_UNCERTAIN
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The atomic function assumes one supporting controlled transaction
domain.
Where the external effect and protected consumption cannot be
committed together, a different explicitly defined effectuation and
reconciliation protocol is required.
11.31 — REFERENCE PSEUDOCODE: PROTECTED REBASE
FUNCTION REBASE_STALE_CANDIDATE( original_candidate,
stale_reservation, current_resource_state,
protected_reconciliation_controller ): REQUIRE
VERIFY_ORIGINAL_CANDIDATE_ACT( original_candidate ) REQUIRE
VERIFY_STALE_RESERVATION( stale_reservation ) REQUIRE
VERIFY_CURRENT_RESOURCE_STATE( current_resource_state )
proposed_rebase = RECOMPUTE_OPERATION( original_candidate,
current_resource_state ) IF NOT WITHIN_ORIGINAL_AUTHORIZED_SCOPE(
proposed_rebase, original_candidate ): RETURN
REQUIRE_NEW_AUTHORIZATION IF NOT VERIFY_CURRENT_OPERATION_SEMANTICS(
proposed_rebase
8.3.3.37. Source page 1030 of the original specification
): RETURN HOLD updated_footprint = CONSTRUCT_UPDATED_FOOTPRINT(
proposed_rebase, current_resource_state ) new_reservation =
protected_reconciliation_controller .ATOMIC_REVALIDATE_AND_RESERVE(
updated_footprint ) IF new_reservation != COMMITTED: RETURN CONFLICT
RETURN PROTECTED_RECONCILED_AUTHORITY({ original:
HASH(original_candidate), rebased: HASH(proposed_rebase),
reservation: new_reservation.reference })
A rebase does not independently authorize an enlarged or different
consequential objective.
11.32 — REFERENCE PSEUDOCODE: DISTRIBUTED EFFECT RECONCILIATION
FUNCTION RECONCILE_PARTIAL_EFFECTS( workflow_reference,
protected_recovery_controller ): REQUIRE VERIFY_WORKFLOW_AUTHORITY(
workflow_reference ) known_effects = QUERY_QUALIFIED_EFFECT_EVIDENCE(
workflow_reference ) unresolved = IDENTIFY_UNRESOLVED_EFFECTS(
workflow_reference, known_effects )
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.38. Source page 1031 of the original specification
IF unresolved NOT EMPTY: ESTABLISH_RETRY_FENCE(unresolved)
actual_state = DERIVE_SUPPORTED_CURRENT_STATE( known_effects,
unresolved ) IF actual_state IS INSUFFICIENT: RETURN RECOVERY_PENDING
recovery_plan = CONSTRUCT_CANDIDATE_RECOVERY_PLAN( actual_state,
workflow_reference ) REQUIRE VERIFY_RECOVERY_SCOPE_AND_AUTHORITY(
recovery_plan ) RETURN SUBMIT_NEW_PROTECTED_RECOVERY_CANDIDATES(
recovery_plan )
An unresolved remote effect is not automatically presumed to have
failed.
11.33 — WORKED EXAMPLE A: TWO AGENTS MODIFY ONE DOCUMENT
Two autonomous agents independently read version 12 of a protected
document.
Agent A proposes replacing one paragraph.
Agent B proposes replacing another paragraph.
The protected system identifies the affected document version and
corresponding effect footprints.
Where the storage system supports independent nonconflicting
subresource modifications, a protected verifier may determine that
the operations can be applied under an appropriate safe order.
Alternatively, where whole-document replacement is required, the
first successful commit may advance the document version to 13.
The second operation's version-12 precondition then fails.
The Finality Sink refuses the stale write.
8.3.3.39. Source page 1032 of the original specification
A protected reconciliation controller may reconstruct the intended
change against version 13 and determine whether the altered operation
remains within the original authority.
If so, a new reservation may be established.
Otherwise, renewed authorization is required.
The system does not silently overwrite the first agent's completed
effect.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.34 — WORKED EXAMPLE B: CONCURRENT INVENTORY ALLOCATION
A protected inventory service reports that six units remain
available.
Two autonomous agents independently request allocation of four units.
Each request appears individually acceptable against the initially
observed quantity.
The protected reservation controller uses authoritative available and
reserved quantity state.
The first valid reservation reduces the remaining allocatable
allowance.
The second reservation cannot allocate another four units without
exceeding the protected limit.
The second Candidate Act is withheld or subjected to an authorized
narrower allocation procedure.
The actual inventory commit sink verifies the current reservation and
quantity before permitting the mutation.
This prevents separate initial approvals from producing an invalid
cumulative allocation under the defined consistency model.
11.35 — WORKED EXAMPLE C: WRITE-SKEW CONFLICT
A protected service requires at least one of two designated
controllers to remain active.
Agent A observes both controllers active and proposes disabling
controller A.
Agent B observes the same original state and proposes disabling
controller B.
Each update affects a different resource.
Ordinary per-object version checks may permit both updates.
8.3.3.40. Source page 1033 of the original specification
However, their combined result violates the global protected
availability invariant.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system represents the requirement as a protected predicate
dependency.
A protected transaction or reservation controller evaluates the
relevant shared condition.
Only a safe combination of operations may commit.
The rejected Candidate Act remains non-effective until current state
and authorization allow an alternative.
This example demonstrates why tracking only direct write-write
overlap may be insufficient.
11.36 — WORKED EXAMPLE D: PHANTOM DEPENDENCY
An autonomous agent is authorized to create a new active processing
job only if fewer than a defined number of jobs are active.
The agent reads the currently active job set and proposes creation.
Another agent simultaneously creates a job satisfying the same
active-job predicate.
The original operation may become invalid even though none of the
earlier listed jobs changed version.
A protected predicate reservation or suitable serializable
transaction accounts for the relevant set-level condition.
The actual job-creation Finality Sink verifies the current predicate
or protected reservation before committing the new job.
The system avoids treating an unchanged collection of previously
observed objects as proof that the relevant aggregate condition
remains valid.
11.37 — WORKED EXAMPLE E: FINANCIAL COMMIT AFTER BALANCE CHANGE
An autonomous financial service is authorized to initiate a bounded
transfer subject to available-funds conditions.
The service verifies the account's available balance and prepares the
operation.
Another authorized transaction reduces the balance before the
transfer reaches its actual controlled commit boundary.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.41. Source page 1034 of the original specification
The earlier approval remains a historical authorization event.
The protected transaction Finality Sink verifies the current balance
or authoritative reserved funds state.
If the required condition no longer holds, the operation is withheld.
A new authorization or protected reallocation may be required where
the proposed adjustment materially changes the approved effect.
The system does not infer transaction validity merely from a stale
balance snapshot.
11.38 — WORKED EXAMPLE F: DUPLICATE REMOTE PAYMENT REQUEST
A protected payment operation is dispatched to a remote service.
The response is lost.
The initiating agent cannot determine whether the payment occurred.
A naive retry may create another payment.
The protected system preserves the operation identifier, relevant
reservation, attempt state, and uncertainty.
Where the destination supports authoritative duplicate suppression,
the controller may query or retry using the same properly bound
operation identity.
Where the destination does not support adequate idempotency or
outcome verification, the system does not claim that repeating the
request is safe.
A protected retry fence prevents automatic duplicate effectuation
while the outcome remains unresolved.
A separately authorized recovery process may be required.
11.39 — WORKED EXAMPLE G: MULTI-DOMAIN RESOURCE COMMIT
An autonomous workflow must reserve a storage object in one domain
and activate a service in another.
The first domain may commit its storage reservation while the second
domain becomes unavailable.
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A local record of intended global success does not make the two
external effects atomic.
8.3.3.42. Source page 1035 of the original specification
The protected system records which effects are completed, which are
pending, and which remain uncertain.
Where the participant domains support a suitable coordinated
transaction, the workflow may use it.
Otherwise, the controller may apply a staged release and
reconciliation procedure.
A later service activation may require its own current authorization
and, where specified, an accepted receipt proving the earlier real
storage effect.
The embodiment thus distinguishes version-bound reservation from
actual cross-domain causal completion.
11.40 — WORKED EXAMPLE H: CONFLICTING HARDWARE COMMANDS
Two autonomous controllers prepare commands affecting a shared
industrial actuator.
One proposes movement in one direction.
Another proposes an incompatible movement.
Each command may have been valid under an earlier observed actuator
state.
The protected controller establishes the applicable resource
ownership, current physical-state representation, and conflict
constraints.
A hardware Finality Sink verifies the actual pending command and
current protected authority before actuation.
If another command has already changed the operating state, the later
stale command is rejected or requires updated current-state
authorization.
Where the earlier physical command is already in progress, the system
accounts for that real effect rather than assuming that cancellation
reverses the actuator's movement.
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.41 — WORKED EXAMPLE I: AGENT RESERVATION AFTER TOOL UPDATE
An autonomous agent receives approval to perform a bounded storage
mutation using a known application operation.
A protected reservation is established under the original operation
semantics.
Before effectuation, the application tool is updated to create an
additional external effect.
8.3.3.43. Source page 1036 of the original specification
The resource versions may remain unchanged.
Nevertheless, the current operation footprint no longer corresponds
to the approved reservation.
The protected semantic compatibility verifier identifies the
difference.
The actual Finality Sink refuses the expanded operation under the
earlier authority.
The system may permit a narrower separately controlled effect or
require renewed authorization.
This combines current operation semantics with version-bound
finality.
11.42 — WORKED EXAMPLE J: CONCURRENT PRIVACY DISCLOSURE
Two autonomous applications each propose releasing a different
protected information fragment.
Each proposal is individually within its local disclosure scope.
However, their combined release would violate a shared cumulative
exposure condition.
The protected system treats the remaining permissible disclosure
allowance as shared conflict-relevant state.
An atomic reservation procedure prevents both operations from
independently consuming the same remaining allowance.
The actual data-release Finality Sink verifies the content,
recipient, and protected exposure reservation.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
This demonstrates that the reservation may protect an information-
disclosure invariant rather than a conventional stored object.
11.43 — WORKED EXAMPLE K: CROSS-DEVICE STALE RESERVATION
An unfinished Candidate Act has a valid reservation on a first
device.
The workload migrates to another protected environment.
The earlier device loses exclusive effectuation ownership.
The destination receives computational context but does not
automatically inherit unrestricted authority.
8.3.3.44. Source page 1037 of the original specification
The protected ownership state advances.
The destination Finality Sink verifies the current device identity,
ownership epoch, actual resource, and reservation.
A delayed command from the old device is rejected.
Where the reservation must be migrated, a protected controller
establishes a valid operation-specific continuity relationship.
This combines Embodiment 9 ownership fencing with the version-bound
reservation requirements of the present embodiment.
11.44 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
11.44.1 — Stale Snapshot Attack
An agent presents an operation prepared against an obsolete resource
version.
The sink verifies current authoritative state.
11.44.2 — Lost Update
Two agents attempt to overwrite the same resource based upon earlier
reads.
Protected conditional effectuation or transaction control prevents an
unauthorized overwrite.
11.44.3 — Write Skew
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Two operations affect distinct objects but violate a shared
invariant.
The protected predicate model includes the relevant cross-object
condition.
11.44.4 — Phantom Insertion
An attacker inserts a new matching object after the original
predicate check.
The protected controller verifies the relevant set-level condition.
11.44.5 — Reservation Double Spending
Two requests attempt to consume the same resource allowance.
The authoritative reservation controller prevents duplicate
allocation.
11.44.6 — Reservation Replay
An attacker copies a valid reservation reference.
8.3.3.45. Source page 1038 of the original specification
The sink verifies operation, identity, generation, and consumption
state.
11.44.7 — Cross-Resource Reservation Use
A reservation for one resource is presented for another.
Protected resource binding rejects the mismatch.
11.44.8 — Reservation Generation Forgery
An attacker invents a newer-looking reservation generation.
The controller requires authenticated authoritative state.
11.44.9 — Reservation Rollback
A previous permissive reservation state is restored.
Protected generation and consumption state reject invalid
restoration.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.44.10 — Reservation Expiry Evasion
A stale reservation is exercised after its validity conditions
expire.
The sink verifies current expiry and authority rules.
11.44.11 — Conflict-Policy Downgrade
An operation attempts to use earlier permissive conflict rules.
Current protected policy state is checked.
11.44.12 — Authority Revocation Race
A principal revokes an operation while it remains pending.
Current authority is verified before effectuation.
11.44.13 — Resource Alias Substitution
A previously approved logical identifier resolves to a different
actual object.
The sink verifies current protected resource correspondence.
11.44.14 — Incomplete Effect Footprint
An agent omits a relevant side effect from its declared operation.
The controlled effectuation boundary requires qualified current
operation information and suitable coverage.
8.3.3.46. Source page 1039 of the original specification
11.44.15 — Hidden Predicate Dependency
An operation relies upon a shared invariant that is absent from its
resource read set.
The supported protected conflict model must include the necessary
predicate.
11.44.16 — False Commutativity Claim
An agent declares two operations compatible when their combination
violates a constraint.
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Commutativity must be established under an authorized technical rule.
11.44.17 — Forged Validation Receipt
An attacker creates a signed-looking conflict approval record.
The sink verifies authenticated issuer identity and authority.
11.44.18 — Unauthorized Verifier
A genuine component without the relevant validation role approves a
conflicting effect.
The Finality Sink checks verifier authorization.
11.44.19 — Stale Validation Evidence
An earlier valid conflict decision is replayed after another
operation changes resource state.
Current version or protected reservation checks reject the stale
evidence.
11.44.20 — Check-to-Commit Race
A resource changes between validation and actual mutation.
The relevant controlled transaction or reservation protocol must
close this race.
11.44.21 — Direct Resource Bypass
An agent invokes an unmediated resource API.
The claimed protected coverage requires equivalent enforcement at the
actual effectuation interface.
11.44.22 — Credential Laundering
A privileged intermediary exercises broad credentials for a
conflicting or unauthorized operation.
The controlled credential or resource sink verifies the operation-
specific scope.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.47. Source page 1040 of the original specification
11.44.23 — Cross-Domain Split Brain
Two domains each believe they hold valid exclusive reservation
authority.
The system requires appropriate authoritative fencing or bounded
partitioning for the claimed guarantee.
11.44.24 — Network Partition
A stale reservation holder cannot reach current state.
The system restricts its operations according to the selected offline
consistency model.
11.44.25 — Partial Distributed Commit
One external effect completes while another fails.
Protected reconciliation preserves the actual partial state.
11.44.26 — Unknown Remote Effect
An acknowledgement is lost after possible external execution.
The protected retry fence prevents unsupported repeated effectuation.
11.44.27 — Duplicate Operation Identifier
An attacker uses another operation's identifier.
The sink verifies the corresponding content and authority binding.
11.44.28 — Idempotency Parameter Change
An earlier operation identifier is reused with different effect
parameters.
The receiving controller rejects unsupported parameter substitution.
11.44.29 — Rebase Scope Expansion
A reconciliation algorithm changes the operation into a broader
effect.
The protected controller requires proper new authority.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.44.30 — Rebase Against Stale State
A reconciled operation is prepared against another outdated version.
Current state must again be verified.
11.44.31 — Compensation Overreach
8.3.3.48. Source page 1041 of the original specification
A recovery operation attempts effects beyond those needed or
authorized for correction.
The recovery Candidate Act requires independent valid authority.
11.44.32 — Resource Version Wraparound
A finite version identifier returns to an earlier value.
The protected versioning scheme must prevent unsafe ambiguity where
relevant.
11.44.33 — Parser Canonicalization Conflict
Different controllers interpret the same mutation descriptor
differently.
Protected typed representations or canonicalization requirements
prevent unsupported equivalence claims.
11.44.34 — Queue Reordering
A dispatcher changes the order of effect-capable commands.
The protected system enforces ordering dependencies where material.
11.44.35 — Concurrent Resource Exhaustion
An attacker generates large numbers of reservations to deny access to
legitimate operations.
The protected system may enforce authenticated quotas and reservation
limits.
11.44.36 — Verification Exhaustion
A complex conflict graph overwhelms the verifier.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Mandatory validation uses bounded work and conservative failure
behavior.
11.44.37 — Hardware Command Already Dispatched
A controller revokes a reservation after a physical command has
begun.
The system preserves the actual effect state and applies appropriate
recovery rules.
11.44.38 — Compromised Reservation Controller
An attacker manipulates authoritative reservation state.
The assurance depends upon the selected protected controller trust
model.
11.44.39 — Compromised Finality Sink
An attacker bypasses the actual resource enforcement component.
8.3.3.49. Source page 1042 of the original specification
A stronger guarantee requires an independently protected effectuation
boundary.
11.44.40 — Software Update Introduces New Conflict Path
A tool update creates a new resource side effect.
The protected system requires current effect-footprint and
enforcement-coverage verification.
11.45 — FAILURE, CRASH, AND RECOVERY HANDLING
11.45.1 — Crash Before Reservation
No new valid reservation is presumed.
11.45.2 — Crash During Reservation
Authoritative protected state determines whether the reservation
committed.
11.45.3 — Crash After Reservation
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The reservation may be recovered or safely expired according to its
protected validity conditions.
11.45.4 — Crash During Finality Verification
Incomplete mandatory verification does not authorize the actual
effect.
11.45.5 — Crash During Atomic Resource Commit
The resource's authoritative transaction or recovery state determines
whether the mutation committed.
11.45.6 — Crash After Local Effect
A committed effect remains real.
11.45.7 — Crash After External Dispatch
The remote result may be uncertain.
11.45.8 — Retry Protection
The system preserves a protected operation identity and retry fence
where required.
11.45.9 — Expired Reservation
A previously valid reservation may require renewed validation before
reuse.
8.3.3.50. Source page 1043 of the original specification
11.45.10 — Protected Recovery Candidate
A corrective operation may be proposed under separate current
authority.
11.45.11 — Cross-Domain State Reconciliation
Participating domains may exchange qualified state evidence to
determine what actually occurred.
11.45.12 — No Automatic External Rollback
A local transaction rollback does not undo an external message,
payment, or physical action already completed.
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.46 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
11.46.1 — Minimum Prototype
A feasible reference implementation may use two independent simulated
agents, a transactional resource store, an authenticated reservation
controller, and a protected Finality Sink.
11.46.2 — Resource Model
The resource may be a finite inventory quantity or a versioned
document.
11.46.3 — Candidate Construction
Each agent proposes a mutation based upon the same resource version.
11.46.4 — Reservation State
The controller establishes operation-specific protected reservations.
11.46.5 — Concurrent Conflict
The prototype deliberately introduces a conflicting second operation.
11.46.6 — Commit Boundary
The sink verifies the current resource version and protected
reservation before the actual mutation.
11.46.7 — Rejection
An invalid stale operation is withheld.
11.46.8 — Reconciliation
8.3.3.51. Source page 1044 of the original specification
The rejected operation may undergo authorized recomputation against
current state.
11.46.9 — Consumption
The sink records consumption of the valid authority.
11.46.10 — Replay Test
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The same consumed authority is presented again and rejected where
single-use behavior is required.
11.46.11 — Extended Distributed Prototype
A further implementation may use two independent controlled resource
services and a protected coordinator.
11.46.12 — External-Effect Simulation
The prototype may model an irreversible remote effect with uncertain
acknowledgements.
11.46.13 — Hardware Extension
A device controller may verify resource ownership, command
generation, and current operation-specific authority.
11.46.14 — Trust Model
A software prototype demonstrates the mechanism under its stated
trusted-resource-controller assumptions.
It does not automatically establish resistance to unrestricted
privileged bypass.
11.47 — FEASIBILITY AND PERFORMANCE ENGINEERING
11.47.1 — Optimistic Fast Path
Nonconflicting operations may proceed through compact current-version
checks without long-lived exclusive locking.
11.47.2 — Pessimistic High-Risk Path
Selected operations may require stronger reservations where conflicts
are expensive or irreversible.
11.47.3 — Compact Version Commitments
Protected resource versions may be represented through authenticated
identifiers or transactional state references.
8.3.3.52. Source page 1045 of the original specification
11.47.4 — Incremental Conflict Graph
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system may update only dependencies affected by recent resource
changes.
11.47.5 — Predicate Indexing
Relevant resource predicates may be indexed or maintained as
protected aggregate state.
11.47.6 — Reservation Expiry
Reservations may have bounded validity to avoid indefinite resource
blocking.
11.47.7 — Starvation Controls
The controller may apply defined fairness, priority, backoff, or
admission policies.
11.47.8 — Deadlock Handling
A pessimistic reservation implementation may require ordered
acquisition, deadlock detection, or bounded abort procedures.
11.47.9 — Retry Budgets
Repeated failed reconciliations may be bounded to avoid resource
exhaustion.
11.47.10 — Atomicity Scope
The implementation must state which resource and authority
transitions occur in one genuinely atomic domain.
11.47.11 — Remote Outcome Limits
A protected protocol cannot guarantee global atomicity for
uncontrolled external systems.
11.47.12 — Practical Assurance
The claimed consistency property must be matched to the actual
protected resource interfaces, isolation model, and failure
assumptions.
11.48 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not representations of
completed measurements.
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 1 — Valid Single Operation: Permit one authorized version-
matched mutation.
Experiment 2 — Lost Update: Prepare two modifications from the same
earlier version and verify stale-write rejection.
8.3.3.53. Source page 1046 of the original specification
Experiment 3 — Concurrent Reservation: Attempt to reserve the same
finite quantity from two agents.
Experiment 4 — Write Skew: Verify enforcement of a global invariant
involving distinct resources.
Experiment 5 — Phantom Dependency: Insert a new resource after a
predicate snapshot.
Experiment 6 — Shared Read Compatibility: Permit compatible read-only
operations.
Experiment 7 — Conditional Commutativity: Evaluate operations that
can be safely reordered under defined constraints.
Experiment 8 — Noncommutative Conflict: Reject an unsupported
operation combination.
Experiment 9 — Forged Reservation: Present an unauthenticated
reservation record.
Experiment 10 — Reservation Replay: Reuse a consumed reservation.
Experiment 11 — Cross-Resource Replay: Apply one resource's
reservation to another resource.
Experiment 12 — Stale Policy: Attempt effectuation under an obsolete
conflict-policy epoch.
Experiment 13 — Revoked Authority: Revoke the Candidate Act before
finality.
Experiment 14 — Resource Alias Change: Redirect the actual operation
to a different underlying resource.
Experiment 15 — Mutation Substitution: Change the outgoing mutation
after reservation.
Experiment 16 — Check-to-Commit Race: Modify the resource between
preliminary validation and actual release.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 17 — Single-Transaction Commit: Atomically commit the
resource mutation and authority consumption.
Experiment 18 — Independent-State Limitation: Demonstrate the
difference between sequential and genuinely atomic cross-service
operations.
Experiment 19 — Protected Rebase: Recompute a stale mutation against
the current resource version.
Experiment 20 — Rebase Scope Expansion: Attempt a conflict resolution
that exceeds original task authority.
Experiment 21 — Reservation Generation Rollback: Restore stale
protected reservation state.
8.3.3.54. Source page 1047 of the original specification
Experiment 22 — Expired Reservation: Attempt effectuation after
mandatory reservation expiry.
Experiment 23 — Shared Quantity Budget: Test several simultaneous
allocations.
Experiment 24 — Distributed Escrow: Partition a bounded quantity
across separate domains.
Experiment 25 — Cross-Sink Commit: Simulate participating
transactional resource controllers.
Experiment 26 — Partial External Effect: Complete one effect while
another fails.
Experiment 27 — Unknown Acknowledgement: Lose an external response
after possible effectuation.
Experiment 28 — Unsafe Retry: Attempt a duplicate real effect while
the earlier outcome remains unknown.
Experiment 29 — Idempotent Retry: Use a destination-supported,
parameter-bound duplicate-suppression mechanism.
Experiment 30 — Causal Continuation: Require a valid CW-2 prior-
effect receipt for a dependent successor phase.
Experiment 31 — Protected Conflict Arbiter: Combine the present
version checks with Embodiment 1 arbitration.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 32 — Cross-Agent Delegation: Verify version-bound scope
across independently administered agents.
Experiment 33 — Device Migration: Preserve reservation state while
transferring exclusive device ownership.
Experiment 34 — Privacy Budget Conflict: Test concurrent disclosures
against one cumulative exposure constraint.
Experiment 35 — Tool Semantic Change: Add a previously unreserved
side effect through a tool update.
Experiment 36 — Current Execution Generation: Verify the effect under
the applicable Embodiment 10 drift conditions.
Experiment 37 — Alternate API: Attempt resource mutation through
another covered interface.
Experiment 38 — Direct Hardware Effect: Test protected reservation
enforcement at a device command sink.
8.3.3.55. Source page 1048 of the original specification
Experiment 39 — Conflict Graph Exhaustion: Supply excessive
dependencies and verify bounded operation.
Experiment 40 — Crash Before Commit: Recover the protected
reservation without claiming a real effect.
Experiment 41 — Crash After Commit: Recover committed authority and
resource state.
Experiment 42 — Resource Partition: Simulate an unavailable
authoritative version service.
Experiment 43 — One-Component Implementation: Combine reservation and
finality enforcement in one protected resource controller.
Experiment 44 — Distributed Implementation: Separate the reservation
authority and destination sink across authenticated domains.
Experiment 45 — No Blockchain: Demonstrate authenticated reservation,
current-version verification, and protected consumption without a
distributed ledger.
The tests may be adapted to the applicable hardware, software,
consistency, or communication environment.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected results should be stated in terms of observable protected
state transitions and actual controlled effectuation.
11.49 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
11.49.1 — Multi-Agent Autonomous Transaction Networks
Several agents may initiate related resource operations across
separate platforms.
The protected system may maintain operation-specific reservations and
current finality checks.
11.49.2 — Cross-Provider Resource Coordination
Independent providers may exchange bounded authority and conflict-
state evidence while enforcing their respective actual resource
boundaries.
11.49.3 — Dynamic Autonomous Workflows
A task may change its execution plan while retaining source-derived
authority and current resource-version requirements.
11.49.4 — Long-Running Agent Memory
An agent's persistent memory may contain old resource observations.
8.3.3.56. Source page 1049 of the original specification
Those observations do not independently establish current
effectuation authority.
11.49.5 — Autonomous Financial Services
Agents may coordinate limited financial operations against current
balance, reservation, and transaction state.
11.49.6 — Distributed Storage Finality
Storage services may enforce operation-specific version and conflict
predicates across heterogeneous execution clients.
11.49.7 — Programmable Network Resources
Autonomous network controllers may reserve and commit configuration
changes under version-bound authority.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.49.8 — Edge and Cloud Coordination
Resource state may be partitioned among edge nodes using bounded
reservation allowances.
11.49.9 — Robotics Fleet Coordination
Several robots may reserve physical operating spaces or shared
actuators under protected resource and command-state constraints.
11.49.10 — Autonomous Vehicle Infrastructure
Different computing controllers may coordinate selected shared-effect
resources under appropriate protected state and safety rules.
11.49.11 — Accelerator Resource Arbitration
Hardware accelerators may enforce operation-specific reservations
before protected memory, command, or external-output effects.
11.49.12 — Hardware-Local Conditional Commit
A device controller may verify a protected resource generation and
effect-specific enablement before accepting a consequential command.
11.49.13 — Distributed Sensor Configuration
Several agents may propose modifications to a shared sensor or
communication configuration.
11.49.14 — Privacy Budget Composition
Shared disclosure allowances may be protected by atomic reservations
and actual release verification.
8.3.3.57. Source page 1050 of the original specification
11.49.15 — Shared Energy and Resource Budgets
Autonomous systems may reserve bounded energy, time, memory, or
device capacity under current protected accounting.
11.49.16 — Intermittently Connected Systems
Remote devices may use protected suballocations when immediate
shared-state checks are unavailable.
11.49.17 — Confidential Computing
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Protected environments may prepare operations while their actual
effects remain governed by independent current resource-state
validation.
11.49.18 — Privacy-Preserving Conflict Evidence
A verifier may establish selected conflict or capacity predicates
without revealing all resource details.
11.49.19 — Dynamic Enforcement-Path Updates
Newly introduced effect-capable interfaces may require current
reservation and sink coverage reattestation.
11.49.20 — Unified Autonomous Finality Infrastructure
A protected service may provide resource-version observation,
conflict reservation, actual-effect validation, and reconciliation
across diverse computing environments.
11.50 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
11.50.1 — Version-Bound Reservation Plus Actual Finality
The actual sink requires both current resource-version validity and
scoped operation authority.
11.50.2 — Predicate Conflict Plus Atomic Effectuation
A shared invariant is verified within a suitable protected commit
boundary.
11.50.3 — Conflict Graph Plus Non-Bearer Enablement
The protected reservation and conflict relationships form necessary
inputs to a scoped finality capability.
11.50.4 — Commutativity Plus Protected Release
8.3.3.58. Source page 1051 of the original specification
Compatible operations may proceed concurrently under an authenticated
commutativity predicate.
11.50.5 — Protected Rebase Plus Scope Reauthorization
A stale operation may be recomputed without automatically expanding
original authority.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.50.6 — Distributed Escrow Plus Destination Finality
A remote domain may consume only its protected bounded resource
allocation.
11.50.7 — External Outcome Evidence Plus Retry Fence
Uncertain remote effectuation prevents unsupported automatic
repetition.
11.50.8 — Causal Receipt Plus Reservation
A successor phase may require both an accepted earlier real-effect
receipt and current version-bound resource authority.
11.50.9 — Cross-Device Ownership Plus Version Authority
A current device owner must also satisfy the relevant resource
version and conflict predicates.
11.50.10 — Execution Drift Plus Conflict Revalidation
A changed tool or algorithm may require recomputation of the approved
effect footprint.
11.50.11 — Privacy Composition Plus Atomic Exposure Reservation
A shared privacy disclosure allowance is governed through protected
concurrent state.
11.50.12 — Hardware Command Versioning Plus Finality
A hardware command sink checks both current device authority and
relevant resource-state conditions.
11.51 — PROPOSED INVENTIVE-STEP ANALYSIS
11.51.1 — Established Prior Art
Conditional requests, optimistic concurrency control, locks,
serializable transactions, predicate locking, distributed commit
protocols, fencing tokens, idempotency controls, and compensating
workflows are established mechanisms.
The embodiment does not assert invention of those individual
techniques.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.59. Source page 1052 of the original specification
11.51.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to prevent an autonomous operation approved under an earlier
resource state from producing an invalid consequential effect after
intervening concurrent changes, by binding protected effectuation
authority to resource versions, semantic conflict dependencies,
operation-specific reservations, and independent verification of the
actual pending effect at the controlled sink.
11.51.3 — Candidate Technical Solution
The proposed arrangement may comprise:
An authenticated Candidate Act;
Protected resource-version and predicate evidence;
A machine-verifiable effect footprint;
A version-bound reservation;
Protected conflict and current-authority state;
Scoped non-bearer finality authority;
An independent actual-operation Finality Sink;
And protected commitment, consumption, or reconciliation.
11.51.4 — Technical Interaction
The Candidate Act identifies the originally authorized consequence.
The resource snapshot describes the state assumed during preparation.
The effect footprint identifies the resources and invariants relevant
to the operation.
The reservation controller establishes protected conditional
eligibility.
The conflict verifier determines whether competing effects remain
compatible.
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Finality Sink reconstructs the actual pending operation.
The controlled resource interface verifies current conditions and
performs the governed effect only under valid authority.
The protected consumption state prevents unsupported replay or
duplicate exercise.
11.51.5 — Not Merely a Version Check
8.3.3.60. Source page 1053 of the original specification
An ordinary version check may determine whether a stored resource
changed.
The stronger candidate arrangement additionally binds the exact
consequential operation, conflict footprint, protected reservation,
authorized effect scope, and finality consumption state.
11.51.6 — Not Merely a Database Transaction
A database transaction may establish consistency within a
participating database.
The proposed architecture may additionally govern an autonomous
Candidate Act, source-derived authority, external effectuation paths,
and outcome reconciliation.
11.51.7 — Not Merely a Resource Lock
A resource lock does not independently establish permission to
perform an arbitrary effect on the locked object.
The Finality Sink verifies current operation-specific authorization.
11.51.8 — Not Merely a Conflict Detector
A conflict detector may identify an incompatible pair of operations.
The present candidate arrangement prevents the governed actual effect
from occurring until the applicable protected consistency and
authority conditions pass.
11.51.9 — Not Merely a Signed Reservation
A signed reservation can be stale, replayed, or mismatched to the
actual operation.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The sink independently verifies current state and consumption.
11.51.10 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
A protected autonomous concurrent-effect system in which a Candidate
Act is bound to authenticated resource-version and semantic effect-
dependency state, a protected controller commits a version-bound
reservation, and a Finality Sink independently reconstructs the
actual pending consequential operation and atomically or otherwise
appropriately verifies current versions, conflict predicates, scoped
non-bearer authority, and reservation-consumption state before
permitting the real effect.
11.51.11 — Additional Predicate-Oriented Kernel
A narrower combination may require protected set-level or multi-
resource predicate dependencies whose validity must be established at
the effectuation boundary rather than relying solely upon direct
target-object versions.
8.3.3.61. Source page 1054 of the original specification
11.51.12 — Additional Distributed Kernel
Another candidate may require bounded cross-domain reservation state
combined with destination-specific finality authority and explicit
handling of partially completed or uncertain remote effects.
11.51.13 — Additional Hardware Kernel
A hardware-oriented implementation may require current version and
conflict-state verification before a protected device controller
permits an effect-capable command.
11.51.14 — Hindsight Considerations
A proper inventive-step evaluation should identify whether the
closest prior-art systems already disclose or render obvious the
claimed relationship among operation-specific authority, version-
dependent reservations, actual-effect reconstruction, protected
consumption, and cross-boundary reconciliation.
Merely placing an established authorization check before an
established transaction check may be an obvious design choice where
no further technical interaction is shown.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A stronger claim should specify the state dependencies and controlled
effectuation behavior responsible for a demonstrable technical
result.
11.51.15 — Patentability Qualification
A claimed technical combination must be supported by sufficient
implementation detail.
The number of disclosed variations does not itself establish novelty
or inventive step.
11.52 — INDUSTRIAL APPLICABILITY
11.52.1 — Enterprise Autonomous Agents
Multiple agents may concurrently modify enterprise resources while
actual effects remain subject to current versions and protected
reservations.
11.52.2 — Cloud Resource Management
Autonomous cloud services may allocate or modify shared computing
resources under authoritative conflict state.
11.52.3 — Database Systems
Database mutations may be bound to source authority, resource
versions, and actual transactional commits.
11.52.4 — File and Document Platforms
8.3.3.62. Source page 1055 of the original specification
Concurrent document changes may avoid unauthorized stale overwrites.
11.52.5 — Financial Transactions
Protected payment and account operations may verify current balances,
reservations, and authorization before effectuation.
11.52.6 — Inventory and Supply Chains
Several agents may reserve finite goods or logistics capacity under
authoritative shared accounting.
11.52.7 — Electronic Commerce
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Automated ordering or allocation services may use version-bound
commitments to avoid unsupported duplicate or conflicting effects.
11.52.8 — Storage Infrastructure
Protected storage controllers may enforce current object generations
and scoped mutation authority.
11.52.9 — Multi-Agent Scheduling
Several autonomous schedulers may reserve shared resources without
exceeding defined constraints.
11.52.10 — Distributed Service Orchestration
Cross-domain workflows may distinguish prepared reservations from
completed external effects.
11.52.11 — Telecommunications
Autonomous network controllers may coordinate changes to shared
network configuration under protected version and conflict
predicates.
11.52.12 — Industrial Automation
Several controllers may propose actions affecting common machinery or
control state.
11.52.13 — Robotics
Multiple robots may reserve shared tools, actuator resources, or
workspaces under protected authority.
11.52.14 — Autonomous Transportation
Distributed controllers may coordinate selected shared operational
resources under appropriate safety and consistency rules.
8.3.3.63. Source page 1056 of the original specification
11.52.15 — Hardware Accelerators
Accelerator command and resource allocation may be governed by
current protected reservation state.
11.52.16 — Edge Computing
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Distributed edge devices may use bounded resource suballocations when
disconnected from shared authority.
11.52.17 — Confidential Computing
Protected computation may produce candidate resource operations
subject to separate current-state finality checks.
11.52.18 — Data Privacy Infrastructure
Concurrent disclosures may consume shared protected privacy
allowances through atomic reservation.
11.52.19 — Long-Running Autonomous Workflows
Operations prepared earlier may require current effect and resource
revalidation before eventual execution.
11.52.20 — Future Heterogeneous Autonomous Systems
The architecture may be applied to evolving autonomous devices,
shared resources, distributed applications, and effect-capable
hardware interfaces.
The industrial utility concerns preventing stale or conflicting
consequences while allowing legitimate concurrent computation and
controlled effectuation.
11.53 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
11.53.1 — Candidate Independent System Claim
A candidate system claim may comprise:
A protected resource-state observer configured to obtain relevant
authoritative versions and predicates;
An effect-footprint controller configured to associate a Candidate
Act with read, write, or semantic conflict dependencies;
A reservation controller configured to establish protected operation-
specific version-bound reservation state;
8.3.3.64. Source page 1057 of the original specification
A conflict or reconciliation verifier configured to determine current
compatibility;
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A protected authority controller configured to establish scoped
finality enablement;
And a Finality Sink configured to reconstruct the actual pending
operation, verify current resource and conflict state, and permit
effectuation only upon satisfaction of the required protected
predicates.
11.53.2 — Candidate Independent Method Claim
A method may comprise:
Constructing a Candidate Act;
Establishing relevant resource-version dependencies;
Determining an effect footprint;
Committing a protected reservation;
Obtaining the actual operation at the consequential sink;
Verifying current versions, predicates, reservation, and authority;
And controlling the actual effect through a protected commit or
consumption transition.
11.53.3 — Candidate Independent Multi-Resource Claim
Another candidate may require evaluation of protected multi-resource
predicates or shared invariants, even where the operations have no
direct write-write overlap.
11.53.4 — Candidate Distributed Finality Claim
Another candidate may concern protected coordination of reservations
across independently administered sinks together with explicit
handling of partial or uncertain external effects.
11.53.5 — Candidate Hardware Apparatus Claim
A controlled device apparatus may enforce current resource-version
and operation-specific authority before accepting an effect-capable
hardware command.
These claim candidates may overlap.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Their final structure should be selected according to the claimed
common inventive concept, prior-art position, and actual enabling
disclosure.
11.54 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
8.3.3.65. Source page 1058 of the original specification
Dependent aspect 1: The Candidate Act includes a protected resource-
version reference.
Dependent aspect 2: The system identifies an authenticated actual
resource.
Dependent aspect 3: The operation includes a protected read
dependency.
Dependent aspect 4: The operation includes a protected write
dependency.
Dependent aspect 5: The operation includes a protected predicate
dependency.
Dependent aspect 6: The operation's effect footprint identifies
several resources.
Dependent aspect 7: A protected semantic conflict graph represents
relevant dependencies among operations.
Dependent aspect 8: A reservation is bound to an authoritative
resource version.
Dependent aspect 9: A reservation includes a protected generation.
Dependent aspect 10: A reservation is bound to the originating
Candidate Act.
Dependent aspect 11: A reservation is bound to a designated Finality
Sink.
Dependent aspect 12: A reservation includes a quantitative resource
allowance.
Dependent aspect 13: Several concurrent agents consume one
authoritative bounded allowance.
Dependent aspect 14: Protected reservation state is committed
atomically.
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 15: A stale version causes reservation invalidation
or required revalidation.
Dependent aspect 16: A change to a predicate-relevant resource
triggers conflict reevaluation.
Dependent aspect 17: A protected global invariant prevents write-skew
effects.
Dependent aspect 18: The system detects a relevant phantom
dependency.
Dependent aspect 19: An authorized commutativity rule permits
compatible operations.
Dependent aspect 20: Noncommutative operations are serialized,
reconciled, or withheld.
Dependent aspect 21: The system supports protected optimistic
concurrency.
Dependent aspect 22: The system supports protected exclusive
reservations.
Dependent aspect 23: A reservation is subject to a current protected
lease or expiry condition.
8.3.3.66. Source page 1059 of the original specification
Dependent aspect 24: A protected reconciliation controller recomputes
an operation against current state.
Dependent aspect 25: A reconciled operation remains within the
original authorized effect envelope.
Dependent aspect 26: A materially expanded reconciled operation
requires new authorization.
Dependent aspect 27: An authenticated verifier produces a protected
conflict or reconciliation decision.
Dependent aspect 28: The verifier possesses an enrolled cryptographic
identity and appropriate authorization role.
Dependent aspect 29: The Finality Sink reconstructs the actual
pending operation.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 30: The sink checks current actual resource
identity.
Dependent aspect 31: The sink checks current resource versions.
Dependent aspect 32: The sink checks protected predicate validity.
Dependent aspect 33: The sink checks current reservation state.
Dependent aspect 34: The sink checks current authority and
revocation.
Dependent aspect 35: The sink checks an operation-specific non-bearer
finality enablement.
Dependent aspect 36: Resource mutation and protected authority
consumption occur within a common atomic transaction where supported.
Dependent aspect 37: A distributed implementation uses bounded
reservation suballocations.
Dependent aspect 38: A participating multi-sink implementation uses a
protected prepare and commit procedure.
Dependent aspect 39: A partial external effect is represented in
protected recovery state.
Dependent aspect 40: An uncertain remote outcome establishes a
protected retry fence.
Dependent aspect 41: A repeat request uses an operation identifier
bound to the original effect parameters.
Dependent aspect 42: A recovered operation requires current protected
authority.
Dependent aspect 43: A successor phase requires an accepted earlier
real-effect receipt where CW-2 applies.
8.3.3.67. Source page 1060 of the original specification
Dependent aspect 44: Protected cross-agent delegation restrictions
remain valid during reconciliation.
Dependent aspect 45: Current computational-generation authority is
verified when required.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 46: Current action-contract semantics are verified
when required.
Dependent aspect 47: Current device ownership is verified where the
operation migrates between execution environments.
Dependent aspect 48: A cumulative privacy-exposure allowance is
represented by protected conflict-relevant state.
Dependent aspect 49: A hardware controller verifies the current
reservation before accepting an effect-capable command.
Dependent aspect 50: Alternative effectuation interfaces are included
in required protected coverage.
Dependent aspect 51: The architecture supports one integrated
protected component or several authenticated distributed components.
Dependent aspect 52: The protected state does not require a
blockchain or public ledger.
These aspects are illustrative technical claim-support possibilities
rather than finalized claims or separate patentability conclusions.
11.55 — NON-LIMITING IMPLEMENTATION AND COMBINATION CLAUSE
The described resource-version, reservation, conflict,
reconciliation, effectuation, and protected authority mechanisms may
be employed separately or in technically compatible combinations.
An implementation may use exact object-version equality.
Another may require serializable multi-resource state.
Another may employ a bounded reservation over shared quantities.
Another may use an authenticated predicate over a set of resources.
Another may permit certain commutative operations to execute
concurrently.
Another may employ stricter exclusive ownership.
Another may perform conflict verification entirely within one
protected storage controller.
Another may distribute qualified conflict evidence across several
protected domains.
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.3.3.68. Source page 1061 of the original specification
Where the actual controlled effect requires more than one resource
domain, the implementation must use an appropriate coordination or
reconciliation protocol consistent with the claimed guarantee.
The disclosed pseudocode, state machines, data structures,
experiments, algorithms, figures, examples, and specific
implementation sequences are illustrative and non-limiting.
They are intended to assist a person having ordinary skill in the art
in understanding and implementing the technical mechanisms.
No illustrative pseudocode function name, programming language,
database isolation mechanism, cryptographic construction, vendor,
processor, or service architecture is universally essential unless
expressly required by a selected claim.
The terms reservation, receipt, commitment, capability, and finality
are used according to their specified technical roles.
A reservation is not automatically evidence of an actual completed
effect.
A cryptographically authenticated record is not automatically
sufficient consequential authority.
A protected compatibility decision is not unrestricted permission to
modify the operation.
A historical approval is not automatically current effectuation
authority.
No proposed feasibility experiment is represented as performed unless
independently tested and documented.
Future-oriented examples are illustrative technical implementations
whose claim scope requires adequate corresponding enabling
disclosure.
11.56 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
The present Embodiment 11 discloses a protected execution-finality
architecture for governing consequential operations proposed
concurrently by autonomous computing entities.
A Candidate Act may be initially authorized and may satisfy the
resource conditions observed during its preparation.
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
However, another operation may subsequently change a relevant
resource version, aggregate predicate, reservation, authority state,
or effectuation condition.
The earlier approval does not necessarily remain sufficient to
authorize the actual consequence.
8.3.3.69. Source page 1062 of the original specification
The disclosed system identifies relevant resource and effect
dependencies and establishes a protected representation of the state
upon which a particular operation relies.
A protected controller may commit a version-bound reservation
associated with the original Candidate Act, permitted effect
envelope, current resource conditions, and applicable conflict rules.
The requesting computational entity may continue internal computation
and preparation while the actual external operation remains non-
effective.
Before effectuation, an independent Finality Sink reconstructs or
obtains the actual pending operation.
The sink verifies the resource identity, relevant current versions,
protected predicates, reservation, operation scope, revocation state,
and applicable consumption conditions.
Where the operation remains valid, the corresponding controlled
resource effect may be committed.
Where a relevant state change or conflict invalidates the operation,
the effect is withheld pending valid reconciliation or
reauthorization.
A protected reconciliation procedure may rebase, reorder, narrow, or
otherwise adjust an operation under expressly defined technical
conditions.
It does not automatically acquire authority to expand the original
permitted consequence.
For distributed workflows, the architecture distinguishes a reserved
resource, a prepared operation, a local committed effect, an actual
remote effect, and an uncertain external outcome.
A protected record of intended commit does not automatically make
several independent real-world consequences atomic.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where an earlier actual effect is a necessary condition for a later
phase, the corresponding CW-2 accepted receipt may constitute
required successor execution authority.
The disclosed system may be implemented using appropriate current
transactional, cryptographic, protected software, firmware, or
hardware mechanisms.
Its guarantees depend upon the relevant resource consistency model,
authoritative reservation state, current protected authorization,
actual effectuation-path coverage, and qualified treatment of partial
or uncertain outcomes.
The embodiment does not claim the invention of ordinary optimistic
concurrency, locking, serializable transactions, fencing tokens, or
idempotency techniques individually.
The proposed contribution lies in the defined enforcement
relationship between such selected mechanisms and actual operation-
specific execution authority.
8.4. Embodiment 13: Protected Multi-Agent Quorum Membership and
Operation-Bound Consensus
Original specification global pages 1140-1220 (inclusive). Source
file: TECHNICAL SPECIFICATION -1063-1541.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.4.1. Protected Components and Trust-Relationship Architecture Diagram
[Originating principal / Candidate Act]
|
[Authenticated eligible quorum membership]
| | |
[Role A] [Role B] [Role C]
+--------+--------+
| approved act hash
[Quorum certificate + epoch]
|
[Source scope / revocation / protected evidence]
|
[Scoped non-bearer finality]
|
[Finality Sink actual-operation check]
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Figure 19: Embodiment 13: Protected Multi-Agent Quorum Membership
and Operation- Bound Consensus — source-based architecture
8.4.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Policy requires collective approval]
|
<Source grant permits proposed act?>--NO-->[REFUSE]
|YES
[Solicit authenticated eligible votes]
|
<Current quorum/membership threshold?>--NO-->[WAIT]
|YES
<All votes same exact act / no veto?>--NO-->[REFUSE]
|YES
[Bind quorum certificate to CA]
|
<Sink actual act/quorum/epoch valid?>--NO-->[REFUSE]
|YES
[Consume and execute]
Figure 20: Embodiment 13: Protected Multi-Agent Quorum Membership
and Operation- Bound Consensus — technical flowchart
8.4.3. Original Global Page-Indexed Technical Description
8.4.3.1. Source page 1140 of the original specification
Novelty, inventive step, claim unity, and permissible claim breadth
remain subject to relevant prior-art examination and the enabling
disclosure actually filed.
END OF EMBODIMENT 12 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 13
PROTECTED MULTI-AGENT CONSENSUS, QUORUM INTEGRITY, AND NON-DELEGABLE
EXECUTION-FINALITY AUTHORITY WITH AUTHENTICATED PARTICIPANT
MEMBERSHIP, OPERATION-BOUND APPROVAL CERTIFICATES, BYZANTINE-
RESILIENT DECISION STATE, AND INDEPENDENT ACTUAL-EFFECT ENFORCEMENT
13.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Systems and Methods for Protected Consequential-Operation
Authorization Across Autonomous Computational Participants Using
Authenticated Quorum Membership, Canonical Operation Commitments,
Fault-Tolerant Approval Evidence, Protected Quorum-Configuration
Epochs, Conflict-Safe Decision Certificates, Scoped Non-Bearer
Finality Enablement, and Independent Finality-Sink Reconstruction and
Verification of Actual Consequential Effects
13.0.1 — General Technical Description
The present Embodiment 13 discloses systems, methods, apparatus,
protected computing components, authenticated multi-party decision
protocols, cryptographic and non-cryptographic approval mechanisms,
machine-verifiable quorum configurations, protected state
transitions, independent execution-authority controls, and non-
limiting implementations for governing consequential operations
requiring approval by multiple computational participants.
The participants may comprise autonomous artificial-intelligence
agents, independent software services, protected decision modules,
hardware controllers, human-authorized approval interfaces,
distributed administrative authorities, machine-verification
components, or combinations thereof.
A requesting computational entity may propose an operation affecting
a protected resource, financial system, communication infrastructure,
database, operating environment, physical device, confidential
information domain, or other effect-capable system.
An applicable policy may require agreement or approval from a defined
set of independent authorized participants before the consequential
operation can proceed.
The approval may take the form of several authenticated endorsements,
a threshold signature, a quorum certificate, a fault-tolerant
consensus decision, a protected multi-role approval record, or
another defined collective authorization representation.
However, agreement among computational participants does not
automatically establish authority to produce every consequential
operation.
8.4.3.2. Source page 1141 of the original specification
For example, several agents may agree upon a proposed payment while
lacking valid authority from the account owner.
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A quorum may approve one transaction but its certificate may later be
presented for another transaction.
A previously valid approval may become stale after resource
modification, authority revocation, quorum membership changes, or
prior consumption.
A quorum may agree upon a high-level intention while the actual
downstream operation differs from the approved proposal.
The present embodiment therefore distinguishes collective
computational agreement from protected consequential execution
authority.
In a principal implementation, an originating authority specifies the
effect envelope and applicable quorum policy.
A proposed Candidate Act is represented in a canonical, operation-
specific form.
Authorized quorum participants evaluate and authenticate the relevant
proposal according to their assigned roles.
A protected quorum verification component establishes whether the
required approval conditions have been satisfied under the current
authenticated membership and configuration state.
The resulting approval evidence is associated with the precise
Candidate Act, relevant resource, effect scope, authority epoch, and
designated Finality Sink.
A separate protected controller may establish scoped non-bearer
finality enablement.
Before the real-world consequence occurs, the Finality Sink
independently obtains or reconstructs the actual pending operation.
It verifies the collective-approval evidence, original source
authority, current policy and quorum state, operation correspondence,
and sink-local protected consumption conditions.
Only after all mandatory predicates pass may the governed consequence
become effective.
13.0.2 — Fundamental Technical Principle
Agreement among agents is not automatically authority to act.
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system distinguishes:
Agreement that a proposed action is desirable;
Agreement that a proposal has been correctly represented;
8.4.3.3. Source page 1142 of the original specification
Agreement that particular technical conditions are satisfied;
Approval by authorized participants;
Source authority for the intended effect;
Current authority over the affected resource;
And permission to release the actual consequential operation.
A collective decision may be valid under its consensus protocol while
being insufficient to authorize an external effect.
A quorum certificate therefore may constitute one required
authorization input without replacing other mandatory protected
finality conditions.
13.0.3 — Principal Proposed Inventive Concept
The principal candidate inventive combination concerns a mandatory
protected relationship among:
An originating consequential authorization;
A precisely bound Candidate Act;
An authenticated quorum-membership configuration;
Individual participant authorization roles;
A defined quorum acceptance rule;
Authenticated operation-specific quorum evidence;
Protected current configuration, policy, and resource-state
generations;
A scoped non-bearer finality enablement;
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
And a Finality Sink independently verifying the actual pending
consequence before effectuation.
A valid quorum approval does not itself grant unrestricted ability to
actuate the protected resource.
The quorum may approve only the effect represented by the
corresponding protected operation commitment.
The actual sink independently checks that the presented effect falls
within the committed authorized scope.
13.0.4 — Distinction Between Consensus and Authorization
8.4.3.4. Source page 1143 of the original specification
Consensus may establish agreement upon a value, ordering, record, or
replicated decision under specified fault assumptions.
Authorization determines whether an entity or operation has
permission to cause a particular effect.
Those properties are technically distinct.
The present embodiment may employ existing consensus protocols as one
component of a protected authorization workflow.
A consensus result is not treated as inherently sufficient
consequential authority.
13.0.5 — Independent Validation and Fault Tolerance
In some implementations, participating approvers independently verify
particular aspects of a proposed operation.
In other implementations, participants may endorse a result produced
by a designated verifier.
The protection must distinguish those assurance levels.
A valid cryptographic quorum certificate establishes only the
properties supported by the applied protocol and its assumptions.
It does not automatically prove that all participants independently
reconstructed the actual effect or that the proposal is factually
correct.
13.0.6 — Quorum Types
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The embodiment may employ:
Fixed-member approval quorums;
Role-constrained quorums;
Weighted approval quorums;
Byzantine fault-tolerant consensus;
Threshold cryptographic approval;
Sequential multi-role approval;
Independent-domain approval;
Dynamic membership configurations;
Or technically compatible combinations.
8.4.3.5. Source page 1144 of the original specification
No particular quorum formulation is universally mandatory unless
expressly required by a selected implementation or claim.
13.0.7 — Physical and Logical Deployment
The quorum participants and effectuation controllers may reside in
separate processes, secure execution environments, devices, cloud
domains, or hardware modules.
They may alternatively be integrated into a protected appliance
having internally separated authorization roles.
The assurance that decisions are independent depends upon the actual
participant trust and failure domains.
Several processes controlled by the same compromised authority are
not automatically independent merely because each possesses a
separate software identifier.
13.0.8 — Relationship to Common Workflows
The embodiment may employ the Candidate Act, Non-Effective State,
Protected Enforcement Domain, scoped non-bearer finality authority,
actual-operation reconstruction, and Finality Sink mechanisms of CW-
1.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
It may use the receipt-constituted causal continuation mechanism of
CW-2 where a later consequential phase requires verified evidence of
a specified earlier real effect.
It may use reauthorization mechanisms of CW-3 where the approved
operation changes beyond its permitted scope.
A quorum certificate is not automatically an Interim Effectuation
Validator receipt.
The two forms of evidence serve different technical purposes unless a
selected protocol expressly combines their qualifying requirements.
13.0.9 — Relationship to Earlier Embodiments
Embodiment 1 may govern conflicts between Candidate Acts approved by
different quorums.
Embodiment 2 may govern successor operations requiring accepted
earlier actual-effect receipts.
Embodiment 3 may verify correspondence between the approved referent
and the actual affected resource.
Embodiment 4 may provide independently qualified observations of
real-world effects.
Embodiment 5 may allocate computing resources among quorum
participants.
Embodiment 6 may verify current tool or action semantics.
8.4.3.6. Source page 1145 of the original specification
Embodiment 7 may govern delegation and authority attenuation among
participating agents or providers.
Embodiment 8 may maintain cumulative privacy constraints on
information released through quorum-controlled operations.
Embodiment 9 may preserve exclusive device effectuation ownership.
Embodiment 10 may ensure the current validity of participating model,
algorithm, or execution generations.
Embodiment 11 may enforce protected version-bound reservations and
concurrent-effect consistency.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Embodiment 12 may govern non-replayable recovery of incomplete or
uncertain collective operations.
Miscellaneous Embodiment M-1 may supply additional coverage and
protected-state modules.
The present embodiment develops quorum integrity, decision
provenance, participant independence, membership continuity, and
separation of collective approval from actual consequential execution
authority.
The previously completed embodiments remain unchanged.
13.1 — TECHNICAL FIELD
The invention relates to autonomous computing security, multi-party
authorization, distributed consensus, Byzantine fault tolerance,
threshold cryptography, protected quorum membership, authenticated
decision certificates, machine-verifiable authority, distributed
resource control, and non-bypassable execution-finality enforcement.
It further relates to controlling consequential operations approved
by multiple computational entities while preserving original source
authority, actual-operation correspondence, and current protected
consumption state.
The architecture may be implemented within software, firmware,
cryptographic security controllers, confidential-computing
environments, hardware security modules, operating-system
controllers, distributed services, network equipment, and other
effect-capable computing infrastructure.
13.2 — SPECIFIC TECHNICAL PROBLEMS
13.2.1 — Collective Agreement Without Source Authority
8.4.3.7. Source page 1146 of the original specification
Several agents may approve an effect that none has authority to
perform.
13.2.2 — Quorum Approval of an Ambiguous Proposal
Different participants may interpret the same natural-language or
partially specified request differently.
13.2.3 — Proposal Substitution After Approval
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A requesting agent may replace the proposed operation after
collecting approvals.
13.2.4 — Approval of One Resource, Effect on Another
A valid approval may be redirected toward a different resource or
recipient.
13.2.5 — Multiple Identities Under One Controller
A malicious entity may register several apparent approvers to satisfy
a numerical threshold.
13.2.6 — Compromised Participant
One or more approving agents may behave arbitrarily, lie, withhold
messages, or endorse conflicting proposals.
13.2.7 — Colluding Participants
Several participants may cooperate to approve a prohibited effect.
13.2.8 — Stale Membership
A removed or suspended approver may continue producing apparently
valid approval messages.
13.2.9 — Quorum Configuration Change
An operation may receive partial approval while the authorized
participant set is being reconfigured.
13.2.10 — Conflicting Quorum Certificates
Different participant subsets may produce purportedly valid approvals
for incompatible operations.
13.2.11 — Equivocating Leader
A coordinator may present different proposal contents to different
participants.
13.2.12 — Certificate Replay
A previously valid approval may be reused for another consequential
attempt.
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.8. Source page 1147 of the original specification
13.2.13 — Authority Revocation
The original principal may revoke or narrow the authorized effect
after quorum approval.
13.2.14 — Resource State Change
The protected resource may change before the actual operation is
presented.
13.2.15 — Tool or Algorithm Change
The downstream execution semantics may no longer match the approved
proposal.
13.2.16 — Threshold Signature Misinterpretation
A valid aggregate signature may be incorrectly treated as proof of
individual participant behavior or approval-role composition.
13.2.17 — Insufficient Role Diversity
A numerical quorum may satisfy its threshold while omitting a
mandatory security, resource-owner, or safety-approval role.
13.2.18 — Consensus on Invalid Data
A majority may agree upon a statement that is false or unsupported.
13.2.19 — Distributed Network Partition
Different participants may operate under inconsistent membership or
decision state.
13.2.20 — Quorum Certificate Accepted by Wrong Sink
An approval intended for one effectuation interface may be exercised
at another.
13.2.21 — Threshold-Key Compromise
Cryptographic key shares may be stolen, duplicated, or misused.
13.2.22 — Insufficient Quorum Availability
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A safe operation may be delayed because required participants are
offline.
13.2.23 — Partial External Effect
A downstream effect may have occurred even though the quorum
coordinator reports a failed workflow.
13.2.24 — Multiple Finality Attempts
An approved operation may be submitted repeatedly to several effect-
capable interfaces.
8.4.3.9. Source page 1148 of the original specification
13.2.25 — Technical Objective
A candidate objective technical problem is:
How to permit consequential operations requiring collective
authorization while preventing forged, stale, ambiguous, conflicting,
improperly constituted, or replayed quorum approvals from becoming
unrestricted external execution authority, by binding authenticated
quorum evidence to precisely specified Candidate Acts and
independently enforcing current source authority and actual effect
correspondence at the Finality Sink.
13.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
13.3.1 — Majority Voting
Collective approval by a majority is an established decision
technique.
The present embodiment does not claim the invention of majority
voting.
13.3.2 — Multi-Signature Approval
Several authorized participants may sign a common operation.
Multisignature schemes are established.
A collection of signatures does not automatically prove current
resource authority or valid downstream execution.
13.3.3 — Threshold Cryptography
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A threshold cryptographic protocol may produce a valid group
signature when a sufficient number of participants cooperate.
This is established technology.
The resulting signature authenticates the designated signing
operation under the applicable security assumptions.
It does not automatically establish that every signer independently
verified each factual or operational predicate.
13.3.4 — Byzantine Fault-Tolerant Consensus
Byzantine fault-tolerant state-machine replication and consensus are
established research areas.
The present embodiment may use an appropriate protocol but does not
claim its basic fault-tolerant agreement mechanism.
8.4.3.10. Source page 1149 of the original specification
13.3.5 — Quorum Certificates
A distributed system may use authenticated certificates to establish
a consensus or approval state.
Such certificates are established mechanisms.
The proposed additional relationship concerns operation-bound source
authority and independent actual-effect finality.
13.3.6 — Leader-Based Coordination
A leader or coordinator may collect approvals.
A leader is not automatically entitled to replace the approved
operation or independently activate the effect.
13.3.7 — Distributed Membership Services
Authenticated membership and configuration generation are established
distributed-system techniques.
The proposed arrangement may bind configuration validity directly to
protected consequential authorization.
13.3.8 — Cryptographic Attestation
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A participant may provide attestation evidence concerning its
identity or execution environment.
Attestation does not automatically establish the correctness of its
approval decision.
13.3.9 — Role-Based Access Control
Different approval roles may possess different permissions.
Role-based authorization is established.
The proposed architecture may require these roles to be satisfied by
the actual authenticated quorum certificate and maintained through
effectuation.
13.3.10 — Conventional Transaction Finality
A system may consider a distributed decision committed after its
consensus conditions pass.
That decision does not automatically prove that a distinct external
physical, financial, or communication effect has occurred.
13.3.11 — Candidate Technical Distinction
8.4.3.11. Source page 1150 of the original specification
The principal candidate distinction is a protected mandatory
dependency between the precise original Candidate Act, a currently
valid quorum decision, an independently enforceable finality
capability, and the actual pending operation reconstructed at the
external effectuation boundary.
13.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative system comprises:
A Source Authority Controller;
A Candidate Act Constructor;
A Canonical Effect Descriptor Builder;
A Protected Quorum Membership Registry;
An Authenticated Participant Identity Service;
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Participant Role and Independence Verifier;
A Protected Proposal Distributor;
A Quorum Approval or Consensus Controller;
A Quorum Certificate Verifier;
A Protected Decision State Controller;
A Conflict and Equivocation Detector;
A Finality Authority Controller;
And one or more independent Execution Finality Sinks.
Optional components may include:
A threshold cryptographic key controller;
A hardware security module;
An authenticated policy-verification service;
A protected resource-version controller;
An independent actual-effect observer;
A cross-domain membership coordinator;
8.4.3.12. Source page 1151 of the original specification
A protected reconfiguration service;
And a recovery-state manager.
The components may reside within one protected computing environment
or across several authenticated devices and administrative domains.
13.4.1 — Source Authority Controller
Establishes who has authorized the proposed consequential effect.
13.4.2 — Candidate Act Constructor
Represents the specific operation requiring collective approval.
13.4.3 — Canonical Descriptor Builder
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Produces a machine-verifiable representation of the proposed
operation.
13.4.4 — Membership Registry
Identifies valid quorum participants and their current authorization
roles.
13.4.5 — Approval Controller
Collects or verifies participant approvals under a defined quorum
rule.
13.4.6 — Conflict Controller
Detects or constrains incompatible decisions according to the
selected consistency model.
13.4.7 — Finality Authority Controller
Establishes scoped non-bearer operation-specific enablement after the
required conditions pass.
13.4.8 — Finality Sink
Independently verifies the actual pending consequence, approval
evidence, and current protected state before effectuation.
13.5 — BROAD TECHNICAL DEFINITIONS
13.5.1 — Quorum-Governed Candidate Act
A Quorum-Governed Candidate Act, or QGCA, means a proposed
consequential operation requiring an authenticated collective
approval condition.
8.4.3.13. Source page 1152 of the original specification
13.5.2 — Protected Quorum Policy
A Protected Quorum Policy, or PQP-13, means an authenticated rule
defining the participants, roles, thresholds, dependencies, and other
conditions necessary for a valid collective decision.
13.5.3 — Authorized Quorum Participant
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An Authorized Quorum Participant, or AQP, means an authenticated
entity currently enrolled to exercise a specified approval or
verification role.
13.5.4 — Quorum Membership Epoch
A Quorum Membership Epoch, or QME, means a protected generation
identifying the applicable quorum membership and configuration state.
13.5.5 — Participant Identity Commitment
A Participant Identity Commitment means authenticated evidence
binding a participant's identity to its relevant approval role and
enrollment state.
13.5.6 — Protected Participant Role
A Protected Participant Role means a defined approval, validation,
resource-owner, security, safety, or other function assigned under
the quorum policy.
13.5.7 — Participant Independence Class
A Participant Independence Class, or PIC-13, means a protected
classification of participants according to the administrative,
cryptographic, execution, or failure-domain independence required by
a selected policy.
13.5.8 — Canonical Quorum Proposal
A Canonical Quorum Proposal, or CQP, means a machine-verifiable
representation of the consequential operation submitted for
collective approval.
13.5.9 — Quorum Proposal Digest
A Quorum Proposal Digest, or QPD, means a cryptographic commitment to
the canonical proposal.
13.5.10 — Authenticated Participant Approval
An Authenticated Participant Approval, or APA, means qualified
evidence that an authorized participant approved a specified proposal
under its applicable role and configuration.
13.5.11 — Quorum Approval Certificate
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.14. Source page 1153 of the original specification
A Quorum Approval Certificate, or QAC, means authenticated evidence
establishing satisfaction of the selected collective approval rule.
13.5.12 — Protected Approval State
Protected Approval State, or PAS-13, means authoritative state
identifying relevant proposal approvals, rejected decisions,
generations, and consumption conditions.
13.5.13 — Quorum Decision Epoch
A Quorum Decision Epoch, or QDE, means a protected generation
associated with a particular collective decision.
13.5.14 — Quorum Configuration Commitment
A Quorum Configuration Commitment, or QCC, means a protected
reference identifying the authorized membership, roles, and quorum
rule.
13.5.15 — Quorum Role Satisfaction
Quorum Role Satisfaction means fulfillment of required approval-role
conditions under the applicable policy.
13.5.16 — Quorum Independence Satisfaction
Quorum Independence Satisfaction means fulfillment of required
participant or failure-domain independence conditions.
13.5.17 — Protected Equivocation Evidence
Protected Equivocation Evidence, or PEE-13, means authenticated
evidence that a relevant participant or coordinator issued
incompatible statements under conditions where doing so violates the
applicable protocol.
13.5.18 — Conflicting Quorum Decision
A Conflicting Quorum Decision means an authenticated or purported
collective approval incompatible with another decision according to
the selected resource, operation, or consensus rules.
13.5.19 — Protected Decision Reservation
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Protected Decision Reservation, or PDR-13, means protected state
reserving the right to execute a specified quorum-approved operation
under current authority and conflict conditions.
13.5.20 — Quorum-Bound Finality Authority
8.4.3.15. Source page 1154 of the original specification
Quorum-Bound Finality Authority, or QBFA, means scoped non-bearer
consequential authority dependent upon valid current quorum evidence
and other required protected finality predicates.
13.5.21 — Quorum Finality Sink
A Quorum Finality Sink, or QFS, means a controlled consequential
interface configured to withhold a governed operation unless the
applicable quorum and independent effectuation conditions are
satisfied.
13.5.22 — Actual Quorum-Governed Effect Descriptor
An Actual Quorum-Governed Effect Descriptor, or AQED, means a
machine-verifiable representation of the consequential operation
actually presented to the controlled sink.
13.5.23 — Protected Quorum Consumption Record
A Protected Quorum Consumption Record, or PQCR, means authoritative
state identifying whether a quorum-bound finality authority has been
used, expired, revoked, or otherwise resolved.
13.5.24 — Quorum Certificate Freshness
Quorum Certificate Freshness means satisfaction of the current
applicability conditions associated with approval epochs, membership,
resource versions, and authority state.
13.5.25 — Protected Quorum Reconfiguration
Protected Quorum Reconfiguration means an authorized change to
membership or approval policy that preserves the required safety
conditions.
13.5.26 — Quorum Continuity Evidence
Quorum Continuity Evidence means authenticated information supporting
acceptance of a decision across a permitted membership or
configuration transition.
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.5.27 — Quorum Availability State
Quorum Availability State means protected information concerning
whether the required participants or approval conditions are
currently obtainable.
13.5.28 — Protected Quorum Recovery State
Protected Quorum Recovery State means authenticated state governing
incomplete, conflicting, stale, or interrupted quorum decisions.
13.5.29 — Non-Delegable Finality Condition
8.4.3.16. Source page 1155 of the original specification
A Non-Delegable Finality Condition means a requirement under which
the final consequential release must be verified by the designated
protected sink and cannot be satisfied merely by possession or
forwarding of an upstream approval artifact.
13.5.30 — Qualified Quorum Evidence
Qualified Quorum Evidence means authenticated collective-approval
evidence whose participants, policy, operation binding, current
membership, and verification properties are sufficient for the
particular quorum predicate being asserted.
13.6 — ORIGINAL SOURCE AUTHORITY
Before quorum approval, the system identifies the authority under
which the consequential operation is proposed.
The source authority may originate from an authenticated principal,
resource owner, administrative controller, authorized device,
protected policy, or other valid authority source.
A quorum of computational participants cannot automatically enlarge
that authority.
For example, if an agent is authorized to modify one specified
database record, a quorum decision cannot independently authorize
modification of every record in the database.
A source authority record may include:
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
SOURCE_EFFECT_AUTHORITY = { originating_principal, authorized_task,
permitted_effect_classes, permitted_resources, permitted_recipients,
permitted_quantitative_bounds, applicable_safety_constraints,
quorum_policy_reference, designated_finality_sinks, authority_epoch,
revocation_reference, protected_authentication }
The Finality Sink may require this original source authority
separately from the quorum certificate.
Where a quorum is itself legally or administratively designated as
the originating authorizing principal, that designation must be
represented by an independently established protected authority rule.
8.4.3.17. Source page 1156 of the original specification
A majority vote alone is not presumed to create authority over
resources outside the participants' legitimate scope.
13.7 — CANONICAL OPERATION REPRESENTATION
A central implementation problem is ensuring that different quorum
participants approve the same consequential operation.
An ambiguous natural-language description may not be sufficient.
A representative canonical operation descriptor may comprise:
CANONICAL_QUORUM_PROPOSAL = { proposal_version,
original_candidate_act, originating_authority_reference,
operation_type, actual_resource_identity, resource_version_or_state,
requested_effect_parameters, permitted_effect_bounds,
intended_recipient_or_destination, required_external_side_effects,
applicable_operation_contract, relevant_read_and_write_dependencies,
quorum_policy_reference, membership_epoch, current_authority_epoch,
designated_finality_sink, validity_conditions, proposal_nonce,
canonical_encoding_identifier }
The required fields depend upon the actual consequential operation.
13.7.1 — Canonicalization Rule
All participants and protected sinks use a defined representation of
security-relevant fields.
13.7.2 — Typed Data
Operation parameters may be represented in unambiguous typed form.
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.7.3 — Resource Identity
The actual intended target is identified under an authenticated
namespace or equivalent protected binding.
8.4.3.18. Source page 1157 of the original specification
13.7.4 — Side Effects
Relevant downstream effects are included or bounded by the approved
descriptor.
13.7.5 — Version Binding
Current resource or contract generations may be included where
necessary.
13.7.6 — Proposal Hash
A collision-resistant digest may commit the canonical descriptor.
13.7.7 — Semantic Limits
A digest proves equality of committed bytes under the cryptographic
assumptions.
It does not independently establish that those bytes accurately
describe the actual real-world effect.
13.7.8 — Actual Sink Verification
The Finality Sink reconstructs or obtains the actual operation and
compares it with the committed authorization.
13.8 — PROTECTED QUORUM MEMBERSHIP
The quorum policy identifies the participants currently entitled to
contribute approval.
13.8.1 — Participant Enrollment
Each participant may be enrolled through an authenticated
administrative or protected governance procedure.
13.8.2 — Cryptographic Identity
A participant may possess an individual signing or authentication
identity.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.8.3 — Authorized Role
The membership record identifies the approval role or roles currently
assigned to the participant.
13.8.4 — Administrative Independence
A policy may require approval from independently administered
domains.
13.8.5 — Hardware Independence
8.4.3.19. Source page 1158 of the original specification
A policy may require participants to operate on separately protected
devices.
13.8.6 — Common-Control Identification
Where several nominal participant identities are known to share one
controller, the protected policy may count them according to the
defined independence rule.
13.8.7 — Enrollment Generation
The membership record includes a protected generation.
13.8.8 — Removal
A revoked participant cannot validly approve new operations under
superseded membership state.
13.8.9 — Replacement
A replacement participant requires valid enrollment rather than
merely receiving the former participant's display name.
13.8.10 — Independence Limit
The system cannot guarantee identification of every concealed common-
control relationship without appropriate supporting identity or
administrative evidence.
13.9 — REPRESENTATIVE QUORUM POLICY
A protected quorum policy may comprise:
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
PROTECTED_QUORUM_POLICY = { quorum_policy_id,
protected_policy_version, originating_authority_reference,
eligible_participant_set, participant_identity_generations,
permitted_participant_roles, participant_independence_classes,
minimum_approval_count, required_role_counts,
approval_weights_if_any, mandatory_independent_domains,
Byzantine_fault_assumptions_if_applicable,
consensus_protocol_if_applicable, canonical_proposal_format,
approval_validity_window, membership_epoch, reconfiguration_rules,
8.4.3.20. Source page 1159 of the original specification
conflicting_decision_policy, designated_finality_sinks,
current_revocation_reference, protected_policy_authentication }
An implementation may use a simple fixed threshold or a more complex
role and independence predicate.
A valid quorum must satisfy the actual current policy rather than
only a numerical count declared by the requesting agent.
13.10 — QUORUM MATHEMATICAL CONDITIONS
N represent the enrolled participant set. Q represent a
participating approval subset. P represent the protected quorum
policy. O represent the canonical proposed operation.
A generic quorum validity condition may be expressed as:
QUORUM_VALID(Q, O, P) = AUTHENTICATED_MEMBERSHIP(Q, P) AND
DISTINCT_PARTICIPANTS_VALID(Q, P) AND REQUIRED_THRESHOLD_SATISFIED(Q,
P) AND REQUIRED_ROLES_SATISFIED(Q, P) AND
REQUIRED_INDEPENDENCE_SATISFIED(Q, P) AND
ALL_COUNTED_APPROVALS_BIND_TO(O) AND CURRENT_POLICY_EPOCH_VALID(P)
13.10.1 — Fixed Threshold Example
A policy may require at least three authorized approvals from five
enrolled participants.
This is an approval threshold, not automatically a Byzantine
consensus protocol.
13.10.2 — Role-Constrained Example
A policy may require two operational approvals and one independent
security-role approval.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Three operational signatures alone do not satisfy that policy.
13.10.3 — Weighted Approval
A policy may use authenticated approval weights.
8.4.3.21. Source page 1160 of the original specification
Such weights must be protected against unauthorized modification or
identity multiplication.
13.10.4 — Byzantine Fault-Tolerant Example
In a conventional fixed-membership Byzantine fault-tolerant setting
with N = 3f + 1 replicas and quorums of 2f + 1, two such quorums
intersect in at least f + 1 replicas.
Under the assumption that at most f replicas are Byzantine, the
intersection includes at least one correct replica.
However, the corresponding safety guarantee also depends upon the
specified consensus protocol and its correct replica locking, voting,
and state-transition rules.
13.10.5 — Dynamic Membership Qualification
The preceding fixed-membership intersection reasoning cannot
automatically be applied unchanged when the participant set changes.
An implementation must establish an appropriate safe reconfiguration
relationship.
13.10.6 — Policy Truthfulness
Even a correctly formed quorum cannot guarantee that the approved
proposal is factually valid if the participants' evidence or
validation logic is wrong.
13.11 — PARTICIPANT-SPECIFIC VERIFICATION
A quorum participant may evaluate selected predicates before
approving a proposal.
13.11.1 — Source Authority Verification
A participant may verify that the originating principal authorized
the relevant operation class.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.11.2 — Resource Verification
A participant may verify target identity and resource correspondence.
13.11.3 — Operation Semantics
A participant may verify the expected effect of the proposed command.
13.11.4 — Security Policy
A participant may evaluate current protected security requirements.
13.11.5 — Budget or Resource Limit
A participant may verify available authority or permitted
quantitative bounds.
8.4.3.22. Source page 1161 of the original specification
13.11.6 — Safety Constraint
A participant may verify a defined physical or operational safety
condition.
13.11.7 — Independent Observation
A participant may obtain evidence through an observation channel
separate from the proposing agent.
13.11.8 — Approval Scope
The resulting approval is bound to the specific predicates and
operation actually evaluated.
13.11.9 — Verification Evidence
The participant may authenticate a reference to the evidence
supporting its decision.
13.11.10 — Qualification
A system may not claim independent verification by each signer when
the protocol only establishes that each signer agreed to sign an
externally supplied digest.
13.12 — AUTHENTICATED PARTICIPANT APPROVAL
A representative individual approval may comprise:
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
AUTHENTICATED_PARTICIPANT_APPROVAL = { participant_identity,
participant_identity_generation, participant_role,
participant_independence_class, quorum_policy_commitment,
canonical_proposal_digest, verified_predicate_set,
verification_evidence_references, membership_epoch, decision_epoch,
approval_nonce, approval_expiry_conditions,
authenticated_signature_or_protected_approval }
The approval may be generated through a protected signing service,
hardware security module, authenticated application component, or
equivalent mechanism.
A participant's signature is not assumed to grant new resource
authority beyond its approved role.
8.4.3.23. Source page 1162 of the original specification
Where a participant approves only a subset of predicates, the quorum
policy must determine whether the aggregate evidence is sufficient
for the intended operation.
13.13 — QUORUM CERTIFICATE CONSTRUCTION
A quorum certificate may be formed after the applicable approval rule
has been satisfied.
A representative QAC may comprise:
QUORUM_APPROVAL_CERTIFICATE = { certificate_version,
canonical_proposal_digest, original_candidate_act_reference,
originating_authority_reference, quorum_policy_commitment,
membership_epoch, decision_epoch, authenticated_approval_evidence,
participant_set_commitment_if_supported, satisfied_role_predicates,
satisfied_independence_predicates,
protected_conflict_state_reference, approved_effect_envelope,
designated_finality_sink, current_authority_epoch,
certificate_validity_conditions,
cryptographic_or_protected_authentication }
A certificate may contain multiple participant signatures or a
threshold cryptographic result.
It may also reference separate protected records needed to establish
participant identities and roles.
A certificate does not automatically establish that the approved
effect has occurred.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.14 — INDIVIDUAL SIGNATURES VERSUS THRESHOLD SIGNATURES
13.14.1 — Individual Approval Signatures
Each participant may sign the canonical proposal digest.
The certificate verifier may inspect the signer identities and their
assigned roles.
13.14.2 — Aggregate Signature
8.4.3.24. Source page 1163 of the original specification
A cryptographic aggregation mechanism may reduce the size of the
approval evidence.
The supported signer-attribution properties depend upon the chosen
protocol.
13.14.3 — Threshold Signature
A threshold scheme may permit a group signature after a sufficient
number of enrolled participants cooperate.
13.14.4 — Group Signature Meaning
Successful verification establishes validity under the group public
key and applicable protocol security assumptions.
13.14.5 — Signer Accountability
A conventional threshold group signature does not necessarily reveal
the exact participating signer subset.
If the application requires such knowledge, additional authenticated
protocol evidence must be maintained.
13.14.6 — Role Requirements
A simple threshold signature does not automatically prove that a
required security-role participant joined the signing process.
The role predicate must be enforced through the signing policy, key
structure, or separately authenticated evidence.
13.14.7 — Independent Verification
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Threshold cooperation does not automatically prove that each signer
independently verified resource authority, current state, or the
actual operation semantics.
13.14.8 — Nonce Management
Threshold signing protocols requiring one-time nonce material must
enforce the corresponding nonce-generation and non-reuse
requirements.
13.14.9 — Key Share Custody
Private key shares may be protected by secure software, hardware
security modules, or other appropriate trusted mechanisms.
13.14.10 — Non-Limiting Cryptography
No particular threshold-signature algorithm is universally required.
8.4.3.25. Source page 1164 of the original specification
13.15 — BYZANTINE PARTICIPANT HANDLING
A participant may behave arbitrarily within the selected fault model.
For example, it may approve conflicting proposals, issue false status
claims, refuse to respond, or supply malformed cryptographic data.
The protected system may employ an established Byzantine fault-
tolerant protocol when agreement or replicated decision safety is
required.
13.15.1 — Fault Bound
The protected configuration specifies the supported maximum number or
weight of faulty participants.
13.15.2 — Authentication
Messages are authenticated under the applicable protocol.
13.15.3 — Proposal Binding
A participant's approval is tied to a specified canonical proposal.
13.15.4 — View or Round State
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The consensus protocol may maintain protected round, view, or phase
identifiers.
13.15.5 — Conflicting Votes
Relevant conflicting signed statements may be retained as
equivocation evidence.
13.15.6 — Invalid Shares
Malformed threshold contributions are rejected according to the
cryptographic protocol.
13.15.7 — Unavailable Participants
A quorum may be unable to complete while required participants are
unavailable.
13.15.8 — Safety and Liveness
The implementation must distinguish safety guarantees from progress
guarantees.
13.15.9 — No Honest-Majority Assumption by Default
A system cannot claim Byzantine fault tolerance merely because
several agents independently produce similar answers.
13.15.10 — External Authority
8.4.3.26. Source page 1165 of the original specification
Even valid Byzantine-resilient agreement does not replace
authorization by the applicable resource authority.
13.16 — PROTECTED QUORUM DECISION STATE
A protected decision record may comprise:
PROTECTED_QUORUM_DECISION_STATE = { decision_identifier,
canonical_proposal_digest, source_authority_reference,
quorum_policy_reference, membership_epoch, current_decision_epoch,
approval_certificate_reference, accepted_decision_status,
protected_conflict_reservations, approved_effect_envelope,
current_resource_versions, designated_finality_sinks,
current_revocation_state, current_consumption_state,
protected_state_authentication }
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The record may be retained in a protected local store, a
transactional service, a replicated state machine, or another
authoritative mechanism.
A replicated decision log is not automatically an external
effectuation log.
The actual resource controller remains responsible for the governed
consequential operation.
13.17 — CONFLICTING PROPOSALS
Two quorum-approved operations may be individually valid but mutually
incompatible.
For example, different groups may approve conflicting changes to a
shared resource.
The system may use protected conflict arbitration, resource-version
reservations, and current Finality-Sink checks.
13.17.1 — Proposal Identity
Each proposed operation has a distinct protected identity.
13.17.2 — Resource Dependencies
8.4.3.27. Source page 1166 of the original specification
The protected controller identifies relevant shared resources and
invariants.
13.17.3 — Conflict Predicate
The system evaluates whether the combined operations remain
permissible.
13.17.4 — Exclusive Decision State
Where the policy allows only one operation, protected decision state
enforces exclusivity.
13.17.5 — Multiple Certificates
The existence of multiple apparently valid approval certificates does
not automatically permit multiple conflicting effects.
13.17.6 — Sink-Level State
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The actual resource sink verifies current reservation and consumption
state.
13.17.7 — Recovery
If one external effect has already occurred, subsequent conflict
resolution is governed by the applicable actual-effect evidence and
recovery procedure.
13.18 — EQUIVOCATION AND PROPOSAL SUBSTITUTION
A coordinator may send different proposal versions to different
participants.
A malicious participant may approve conflicting operations within one
decision context.
The protected system may prevent or detect such behavior through
canonical digests, signed round identifiers, authenticated decision
state, or an appropriate consensus protocol.
13.18.1 — Common Proposal Reference
Approvals counted toward one certificate must correspond to the same
protected operation.
13.18.2 — Proposal Version
The canonical operation includes an authenticated version or
equivalent unique identity.
13.18.3 — Conflicting Endorsements
Relevant contradictory statements may be recorded as protected
equivocation evidence.
13.18.4 — Revoked Participant
8.4.3.28. Source page 1167 of the original specification
A participant's new approval becomes invalid after its membership or
authority is revoked according to the applicable effective
transition.
13.18.5 — Certificate Validation
The verifier rejects a purported certificate assembled from approvals
for different proposal digests.
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.18.6 — Sink Verification
The Finality Sink independently checks the actual operation rather
than trusting the coordinator's description.
13.19 — MEMBERSHIP RECONFIGURATION
The authorized participant set may change during an active task.
The system may add, remove, replace, or suspend approvers.
A protected reconfiguration procedure establishes which configuration
is authoritative for a particular decision.
13.19.1 — Current Membership
The protected registry identifies the currently valid participant
set.
13.19.2 — New Configuration
A proposed membership update is represented as an authenticated
configuration change.
13.19.3 — Authorization
The update requires permission from the applicable governance
authority.
13.19.4 — Safe Transition
The procedure preserves the consistency guarantees required by the
selected quorum protocol.
13.19.5 — Joint or Bridged Approval
Where required, old and new configurations may participate in a
protected transition.
13.19.6 — Threshold Key Rotation
A changed threshold-signing group may require appropriate key-share
refresh or new group-key enrollment.
8.4.3.29. Source page 1168 of the original specification
13.19.7 — Old Certificate
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An earlier certificate may remain valid only under its specified
policy and current applicability conditions.
13.19.8 — Stale Member
A removed participant cannot approve new operations under invalid old
membership state.
13.19.9 — In-Flight Proposal
An operation receiving partial approval during reconfiguration is
handled according to a defined protected continuity policy.
13.19.10 — No Automatic Safety
Overlapping membership sets alone do not establish that every
dynamic-quorum protocol preserves safety.
The actual decision and reconfiguration rules must satisfy the
claimed properties.
13.20 — ROLE-CONSTRAINED QUORUMS
A quorum policy may require different forms of approval.
For example:
A resource-owner approval;
A security-policy approval;
An operational or functional approval;
And a protected safety validation.
A simple numerical threshold may be insufficient.
The protected verifier may evaluate the role distribution of the
actual authenticated approvals.
The system may additionally require approvals from independent
administrative or hardware domains.
An approval from a participant possessing several roles may count
according to the actual policy.
The policy may prevent one participant from satisfying otherwise
independent mandatory roles.
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.30. Source page 1169 of the original specification
No particular number or role combination is universally required.
The essential requirement is that the actual quorum evidence
satisfies the authenticated applicable rule.
13.21 — QUORUM APPROVAL IS NOT UNRESTRICTED DELEGATION
An approved Candidate Act may be associated with a single designated
effectuation operation.
The requesting agent may receive a reference to the quorum
certificate.
However, the certificate does not automatically authorize unrelated
actions.
The participant quorum may authorize one bounded mutation without
granting a reusable administrative credential.
A downstream agent may relay the certificate while lacking
independent authority to change the approved target.
A compromised coordinator may possess all approval records but remain
unable to exercise the protected finality primitive unless its
current operation satisfies the remaining mandatory conditions.
This separation may be enforced by a protected credential broker,
transaction controller, device command controller, or another
effectuation sink.
13.22 — QUORUM-BOUND NON-BEARER FINALITY AUTHORITY
A representative QBFA may comprise:
QUORUM_BOUND_FINALITY_AUTHORITY = { finality_authority_version,
originating_candidate_act, authorized_effect_envelope,
canonical_proposal_digest, valid_quorum_certificate_reference,
applicable_quorum_policy, membership_epoch, decision_epoch,
current_source_authority_epoch, actual_resource_identity,
current_resource_version_or_reservation, designated_finality_sink,
operation_count_or_budget, protected_conflict_state_reference,
8.4.3.31. Source page 1170 of the original specification
revocation_reference, sink_local_consumption_reference,
cryptographic_or_protected_authentication }
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The authority may be represented by a protected capability, a
finality-controller state reference, a credential-release condition,
or another protected enabling mechanism.
The authority is non-bearer where possession of the object alone is
insufficient.
The actual sink must verify the relevant current identity, operation,
resource, scope, and consumption predicates.
13.23 — ACTUAL-OPERATION FINALITY VERIFICATION
The Finality Sink obtains or reconstructs the real pending operation.
The source may be a network message, database mutation, file commit,
payment request, credential activation, device command, or other
effect-capable operation.
The sink verifies:
The original authorized Candidate Act;
The canonical approved proposal;
The current valid quorum certificate;
The current quorum policy and membership state;
The applicable source authority;
The actual operation type;
The actual resource and recipient;
The actual relevant parameters;
Current resource and conflict conditions;
Protected revocation state;
And sink-local finality consumption.
A quorum certificate approving one transaction cannot validly be
substituted for a different actual transaction.
A certificate issued under an obsolete configuration is not
automatically sufficient.
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.32. Source page 1171 of the original specification
A valid consensus decision cannot override an independently mandatory
resource or safety constraint.
The sink permits the real effect only when the selected required
predicates pass.
13.24 — PROTECTED SINGLE-USE AND REPLAY CONTROL
A collective approval may be valid for one bounded consequential
operation.
13.24.1 — Operation Identity
The approved operation possesses an authenticated unique identity.
13.24.2 — Certificate Binding
The quorum certificate is bound to that operation.
13.24.3 — Designated Sink
The authority identifies its permitted effectuation boundary.
13.24.4 — Consumption State
The sink maintains protected information concerning prior exercise of
the authority.
13.24.5 — Duplicate Submission
A repeated request is evaluated under the applicable original
operation identity and idempotency rules.
13.24.6 — Multi-Sink Protection
Where the effect can occur through several sinks, the relevant
consumption or reservation state must prevent unauthorized
duplication across those paths.
13.24.7 — Snapshot Rollback
A copied agent state cannot restore already consumed authority.
13.24.8 — External Outcome
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A consumed local authority does not automatically establish whether a
remote effect completed.
The system distinguishes protected release from qualified actual-
effect completion.
8.4.3.33. Source page 1172 of the original specification
13.25 — PROTECTED QUORUM DECISION STATE MACHINE
A non-limiting state machine may comprise:
SOURCE_AUTHORITY_PENDING: The originating consequential authority has
not been established.
PROPOSAL_PREPARED: A Candidate Act has been constructed.
PROPOSAL_CANONICALIZED: The protected operation descriptor is
available.
MEMBERSHIP_PENDING: The applicable current participant configuration
remains unresolved.
QUORUM_OPEN: Authorized participants may evaluate the proposal.
APPROVALS_PENDING: Required authenticated endorsements have not yet
been collected.
APPROVAL_REJECTED: A mandatory participant or policy condition fails.
QUORUM_POLICY_SATISFIED: The required collective approval rule is
fulfilled.
CERTIFICATE_PREPARED: Valid quorum evidence is available.
CONFIGURATION_REVALIDATION_PENDING: A membership or policy change
requires current validation.
CONFLICT_VALIDATION_PENDING: Applicable resource and decision
conflicts are being checked.
FINALITY_AUTHORITY_PENDING: Scoped operation-specific enablement is
being established.
FINALITY_AUTHORITY_PREPARED: Protected non-bearer authority exists.
SINK_VERIFICATION_PENDING: The actual operation awaits finality
verification.
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
EFFECT_PERMITTED: All mandatory consequential authority predicates
pass.
EFFECT_WITHHELD: One or more required conditions fail.
EFFECT_ATTEMPTED: The controlled consequence has been initiated.
EFFECT_CONFIRMED: Qualified evidence establishes the specified real
effect.
OUTCOME_UNCERTAIN: The actual external outcome remains unresolved.
AUTHORITY_CONSUMED: The applicable finality enablement has been
consumed.
8.4.3.34. Source page 1173 of the original specification
RECOVERY_PENDING: A separately governed recovery procedure is
required.
TERMINATED: The protected operation has completed or been validly
abandoned.
The protected state machine may be implemented using one
authoritative controller or an appropriate distributed state
mechanism.
13.26 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Source Authority.
The protected system verifies the origin and scope of the
consequential request.
Step 2 — Construct Candidate Act.
A proposed real-world or external operation is represented as a
distinct Candidate Act.
Step 3 — Hold Actual Effect Non-Effective.
The proposed consequence remains withheld at the protected
effectuation path.
Step 4 — Resolve Actual Intended Resource.
The system identifies the authorized target and operation parameters.
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 5 — Create Canonical Proposal.
The relevant operation is represented in a machine-verifiable form.
Step 6 — Commit Proposal Digest.
A protected commitment binds the exact proposal.
Step 7 — Load Current Quorum Policy.
The authorized participant set and approval rules are obtained.
Step 8 — Verify Participant Enrollment.
The protected registry validates current identities, roles, and
membership generation.
Step 9 — Distribute Proposal.
The canonical proposal or its authenticated representation is
supplied to authorized participants.
Step 10 — Perform Required Independent Checks.
8.4.3.35. Source page 1174 of the original specification
Participants perform the validations required by their roles.
Step 11 — Authenticate Individual Approvals.
Approvals are bound to the proposal digest and current policy.
Step 12 — Evaluate Quorum Rule.
The verifier checks threshold, role, independence, and other required
predicates.
Step 13 — Resolve Conflicting Decisions.
Where necessary, the protected system applies the relevant consensus
or conflict rules.
Step 14 — Construct Quorum Certificate.
Valid collective approval evidence is committed.
Step 15 — Verify Current Membership and Authority.
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The controller ensures the certificate remains applicable.
Step 16 — Check Current Resource State.
Version, reservation, and effect-conflict conditions are evaluated
where required.
Step 17 — Establish Scoped Finality Authority.
The protected controller prepares an operation-bound non-bearer
enablement.
Step 18 — Present Actual Consequential Operation.
The requester submits the real command or effect request.
Step 19 — Reconstruct Actual Operation.
The Finality Sink independently identifies the pending effect.
Step 20 — Verify Certificate Binding.
The actual operation is compared with the approved canonical
proposal.
Step 21 — Verify Current Protected Authority.
Source authority, quorum policy, and revocation state are checked.
Step 22 — Verify Sink-Local State.
Current operation identity, reservation, and consumption conditions
are established.
8.4.3.36. Source page 1175 of the original specification
Step 23 — Consume or Reserve Finality Authority.
The applicable protected authority transition occurs.
Step 24 — Permit Actual Effect.
The sink releases the consequential operation.
Step 25 — Commit Attempt Evidence.
Qualified protected evidence of effectuation is recorded.
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 26 — Observe Outcome if Required.
An authorized effect observer may determine the actual result.
Step 27 — Govern Dependent Operations.
A later consequential phase requires its own valid authorization and
any mandatory accepted prior-effect receipt.
13.27 — REFERENCE PSEUDOCODE: CANONICAL PROPOSAL
FUNCTION CONSTRUCT_QUORUM_PROPOSAL( candidate_act, source_authority,
protected_proposal_controller ): REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) REQUIRE VERIFY_SOURCE_AUTHORITY(
source_authority, candidate_act ) actual_resource =
RESOLVE_AUTHORIZED_RESOURCE( candidate_act ) effect_descriptor =
DERIVE_CANONICAL_EFFECT_DESCRIPTOR( candidate_act, actual_resource )
REQUIRE VERIFY_EFFECT_WITHIN_SOURCE_AUTHORITY( effect_descriptor,
source_authority
8.4.3.37. Source page 1176 of the original specification
) policy = LOAD_CURRENT_QUORUM_POLICY( candidate_act ) REQUIRE
VERIFY_QUORUM_POLICY_AUTHENTICITY(policy) proposal =
protected_proposal_controller .ATOMIC_COMMIT({ candidate_act:
HASH(candidate_act), source_authority: HASH(source_authority),
canonical_effect: HASH_CANONICAL(effect_descriptor), quorum_policy:
HASH(policy), membership_epoch: policy.membership_epoch,
designated_sink: candidate_act.finality_sink, proposal_nonce:
NEW_PROTECTED_PROPOSAL_NONCE() }) RETURN proposal
The canonicalization process must represent the security-relevant
actual effect properties required by the selected implementation.
13.28 — REFERENCE PSEUDOCODE: PARTICIPANT APPROVAL
FUNCTION APPROVE_CANONICAL_PROPOSAL( canonical_proposal,
participant_controller ): REQUIRE VERIFY_CANONICAL_PROPOSAL(
canonical_proposal ) REQUIRE VERIFY_CURRENT_PARTICIPANT_ENROLLMENT(
8.4.3.38. Source page 1177 of the original specification
participant_controller.identity ) REQUIRE VERIFY_PARTICIPANT_ROLE(
participant_controller.identity, canonical_proposal.policy ) REQUIRE
VERIFY_CURRENT_MEMBERSHIP_EPOCH( canonical_proposal ) REQUIRE
VERIFY_SOURCE_AUTHORITY_IF_REQUIRED( canonical_proposal )
required_checks = RESOLVE_ROLE_REQUIRED_CHECKS(
participant_controller.role, canonical_proposal ) evidence =
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
participant_controller .PERFORM_REQUIRED_VERIFICATION(
canonical_proposal, required_checks ) IF NOT
REQUIRED_CHECKS_PASS(evidence): RETURN REJECT approval =
participant_controller .AUTHENTICATE_APPROVAL({ proposal_digest:
canonical_proposal.digest, policy_commitment:
canonical_proposal.policy_commitment, membership_epoch:
canonical_proposal.membership_epoch, participant_identity:
participant_controller.identity, participant_role:
participant_controller.role, verified_evidence: HASH(evidence) })
8.4.3.39. Source page 1178 of the original specification
RETURN approval
A participant's approval assurance is limited to the predicates and
evidence it actually verifies.
13.29 — REFERENCE PSEUDOCODE: QUORUM VERIFICATION
FUNCTION VERIFY_QUORUM_CERTIFICATE( proposal, supplied_approvals,
protected_quorum_verifier ): REQUIRE
VERIFY_PROPOSAL_AUTHENTICITY(proposal) policy =
LOAD_AUTHORITATIVE_QUORUM_POLICY( proposal.quorum_policy_reference )
REQUIRE VERIFY_CURRENT_POLICY_APPLICABILITY( policy, proposal )
valid_approvals = EMPTY_SET() FOR EACH approval IN
supplied_approvals: IF NOT VERIFY_PARTICIPANT_SIGNATURE( approval ):
CONTINUE IF NOT VERIFY_APPROVAL_PROPOSAL_BINDING( approval, proposal
): CONTINUE IF NOT VERIFY_MEMBERSHIP_AND_ROLE( approval, policy ):
CONTINUE ADD_IF_DISTINCT_AND_ELIGIBLE( valid_approvals, approval )
8.4.3.40. Source page 1179 of the original specification
REQUIRE VERIFY_THRESHOLD( valid_approvals, policy ) REQUIRE
VERIFY_REQUIRED_ROLE_COVERAGE( valid_approvals, policy ) REQUIRE
VERIFY_REQUIRED_INDEPENDENCE( valid_approvals, policy ) REQUIRE
VERIFY_RELEVANT_CONFLICT_SAFETY( proposal, policy ) certificate =
protected_quorum_verifier .AUTHENTICATE_CERTIFICATE({ proposal:
proposal.digest, policy: HASH(policy), approved_evidence:
HASH_CANONICAL(valid_approvals), decision_epoch:
CURRENT_DECISION_EPOCH(), certificate_scope: proposal.effect_scope })
RETURN certificate
Where a threshold-signature mechanism is used, the certificate
verifier must separately establish any mandatory signer-role or
signer-attribution properties not provided by the aggregate signature
alone.
13.30 — REFERENCE PSEUDOCODE: MEMBERSHIP RECONFIGURATION
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
FUNCTION RECONFIGURE_PROTECTED_QUORUM( old_configuration,
8.4.3.41. Source page 1180 of the original specification
proposed_configuration, protected_membership_controller ): REQUIRE
VERIFY_CURRENT_CONFIGURATION( old_configuration ) REQUIRE
VERIFY_RECONFIGURATION_AUTHORITY( proposed_configuration ) REQUIRE
VERIFY_PROPOSED_MEMBERSHIP_IDENTITIES( proposed_configuration )
REQUIRE VERIFY_RECONFIGURATION_SAFETY_POLICY( old_configuration,
proposed_configuration ) transition = protected_membership_controller
.PREPARE_CONFIGURATION_TRANSITION({ old_configuration:
HASH(old_configuration), proposed_configuration:
HASH(proposed_configuration), affected_pending_decisions:
RESOLVE_AFFECTED_PENDING_DECISIONS(), required_continuity_evidence:
DERIVE_REQUIRED_RECONFIGURATION_EVIDENCE() }) REQUIRE
VERIFY_REQUIRED_TRANSITION_APPROVALS( transition ) committed =
protected_membership_controller .ATOMIC_COMMIT_CONFIGURATION({
expected_old_epoch: old_configuration.epoch, new_configuration:
proposed_configuration, new_epoch: NEXT_PROTECTED_MEMBERSHIP_EPOCH(),
8.4.3.42. Source page 1181 of the original specification
transition_evidence: HASH(transition) }) IF committed != COMMITTED:
RETURN RECONFIGURATION_UNRESOLVED
INVALIDATE_INAPPLICABLE_OLD_APPROVALS() RETURN committed
The concrete transition protocol must preserve the claimed quorum
safety properties under its actual fault and network assumptions.
13.31 — REFERENCE PSEUDOCODE: FINALITY AUTHORITY PREPARATION
FUNCTION PREPARE_QUORUM_FINALITY_AUTHORITY( candidate_act,
quorum_certificate, protected_authority_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY( candidate_act ) REQUIRE
VERIFY_VALID_QUORUM_CERTIFICATE( quorum_certificate ) REQUIRE
VERIFY_CERTIFICATE_CANDIDATE_BINDING( quorum_certificate,
candidate_act ) REQUIRE VERIFY_CURRENT_MEMBERSHIP_APPLICABILITY(
quorum_certificate ) REQUIRE
VERIFY_CURRENT_RESOURCE_AND_CONFLICT_STATE( candidate_act ) REQUIRE
VERIFY_CURRENT_REVOCATION_STATE( candidate_act ) authority =
protected_authority_controller .ATOMIC_PREPARE_FINALITY({
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.43. Source page 1182 of the original specification
candidate_act: HASH(candidate_act), approved_proposal:
quorum_certificate.proposal_digest, certificate:
HASH(quorum_certificate), source_authority:
HASH(CURRENT_SOURCE_AUTHORITY()), resource:
RESOLVE_ACTUAL_AUTHORIZED_RESOURCE(), designated_sink:
candidate_act.finality_sink, usage_limit: AUTHORIZED_EFFECT_COUNT(),
authority_epoch: CURRENT_AUTHORITY_EPOCH() }) RETURN authority
The quorum certificate is necessary where the selected policy
requires it, but it does not replace the other current finality
predicates.
13.32 — REFERENCE PSEUDOCODE: ACTUAL-EFFECT FINALITY SINK
FUNCTION EFFECTUATE_QUORUM_GOVERNED_OPERATION( candidate_act,
quorum_certificate, finality_authority, quorum_finality_sink ):
actual_operation = quorum_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION() IF actual_operation IS NULL:
RETURN DENY REQUIRE quorum_finality_sink
.VERIFY_CURRENT_SOURCE_AUTHORITY( candidate_act )
8.4.3.44. Source page 1183 of the original specification
REQUIRE quorum_finality_sink .VERIFY_QUORUM_CERTIFICATE(
quorum_certificate ) REQUIRE quorum_finality_sink
.VERIFY_CURRENT_MEMBERSHIP_POLICY( quorum_certificate ) REQUIRE
quorum_finality_sink .VERIFY_ACTUAL_OPERATION_CORRESPONDENCE(
actual_operation, quorum_certificate ) REQUIRE quorum_finality_sink
.VERIFY_ACTUAL_TARGET_AND_RECIPIENT( actual_operation ) REQUIRE
quorum_finality_sink .VERIFY_CURRENT_RESOURCE_AND_CONFLICT_STATE()
REQUIRE quorum_finality_sink .VERIFY_CURRENT_FINALITY_AUTHORITY(
finality_authority ) REQUIRE quorum_finality_sink
.VERIFY_REVOCATION_AND_CONSUMPTION() consumption =
quorum_finality_sink .ATOMIC_CONSUME_FINALITY_AUTHORITY(
finality_authority, actual_operation ) IF consumption != SUCCESS:
RETURN DENY attempt = quorum_finality_sink .EFFECTUATE(
actual_operation, consumption )
COMMIT_PROTECTED_EFFECT_ATTEMPT(attempt) RETURN attempt
8.4.3.45. Source page 1184 of the original specification
Where the governed external operation is not atomic with local
authority consumption, the selected protocol must preserve
uncertainty and employ appropriate recovery semantics.
13.33 — REFERENCE PSEUDOCODE: CONFLICTING CERTIFICATES
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
FUNCTION HANDLE_CONFLICTING_QUORUM_CERTIFICATES( certificate_a,
certificate_b, protected_conflict_controller ): REQUIRE
VERIFY_CERTIFICATE_AUTHENTICITY( certificate_a ) REQUIRE
VERIFY_CERTIFICATE_AUTHENTICITY( certificate_b ) IF NOT
OPERATIONS_CONFLICT( certificate_a, certificate_b ): RETURN
SEPARATELY_EVALUATE_CURRENT_FINALITY evidence = PROTECTED_COMMIT({
certificate_a: HASH(certificate_a), certificate_b:
HASH(certificate_b), conflicting_effects:
DERIVE_CONFLICT_FOOTPRINT(), applicable_membership_epochs:
EXTRACT_MEMBERSHIP_EPOCHS(), current_resource_state:
HASH(OBSERVE_CURRENT_RESOURCE_STATE()) })
protected_conflict_controller .FENCE_AFFECTED_FINALITY_AUTHORITY(
evidence ) RETURN REQUIRE_AUTHORIZED_CONFLICT_RESOLUTION
8.4.3.46. Source page 1185 of the original specification
The protocol must not assume that the later or numerically larger
certificate is automatically valid.
13.34 — WORKED EXAMPLE A: THREE-AGENT APPROVAL FOR ONE TRANSACTION
An autonomous workflow includes five enrolled approval participants.
The protected policy requires three authenticated approvals.
A requesting agent proposes one bounded transaction.
The original source authority identifies the account, maximum amount,
recipient, and designated transaction sink.
A canonical proposal binds the precise transaction details.
Three authorized participants approve the same proposal digest.
The protected quorum verifier checks current membership and threshold
validity.
A valid approval certificate is committed.
The transaction controller prepares scoped non-bearer finality
authority.
Before execution, the payment Finality Sink reconstructs the actual
payment request.
The sink verifies the source authority, quorum certificate, amount,
account, recipient, current resource state, and single-use
consumption.
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A valid quorum approval is therefore a necessary but not universally
sufficient condition for the actual transaction.
Expected demonstrable result: Only the precisely approved and
independently authorized transaction becomes effective.
13.35 — WORKED EXAMPLE B: QUORUM APPROVES AN UNAUTHORIZED EFFECT
Several autonomous agents agree to modify a protected resource.
Their approval certificate satisfies the numerical quorum threshold.
However, the original principal authorized only a different resource.
The protected Finality Sink obtains the actual pending operation.
8.4.3.47. Source page 1186 of the original specification
It verifies the original source authority separately from the quorum
certificate.
The actual resource lies outside the permitted effect envelope.
The sink refuses effectuation.
Expected demonstrable result: A mathematically valid quorum does not
enlarge the originating principal's authority.
13.36 — WORKED EXAMPLE C: PROPOSAL SUBSTITUTION AFTER APPROVAL
A quorum approves a bounded database mutation.
The requesting agent subsequently changes the mutation amount or
target field.
The earlier approval certificate remains cryptographically valid for
the original proposal digest.
At effectuation, the database Finality Sink reconstructs the actual
pending mutation.
The actual operation does not correspond to the approved canonical
descriptor.
The sink rejects the request.
Expected demonstrable result: A quorum certificate for one Candidate
Act cannot authorize a materially different effect.
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.37 — WORKED EXAMPLE D: ONE ENTITY CONTROLS SEVERAL APPARENT AGENTS
A malicious controller creates several agent processes with distinct
names.
The protected policy requires approvals from independently
administered participant domains.
The processes attempt to satisfy the approval threshold by presenting
their separate software identities.
The membership verifier checks enrolled participant identities and
applicable independence classes.
Where the identities do not satisfy the required independent-domain
policy, they are not counted as separate qualifying approvals.
The operation remains withheld.
8.4.3.48. Source page 1187 of the original specification
Expected demonstrable result: Increasing the number of software
processes does not automatically satisfy a protected participant-
independence condition.
13.38 — WORKED EXAMPLE E: REQUIRED SECURITY ROLE OMITTED
A quorum policy requires two operational approvals and one
independent security-role approval.
Three operational participants approve the proposal.
A simple three-of-five numerical threshold would appear satisfied.
However, the protected policy requires a distinct approval-role
distribution.
The quorum verifier rejects the certificate because the security role
is absent.
The Finality Sink does not receive valid finality enablement.
Expected demonstrable result: Numerical vote count cannot replace a
required protected role predicate.
13.39 — WORKED EXAMPLE F: MALICIOUS COORDINATOR SENDS DIFFERENT
PROPOSALS
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A coordinator presents one operation to some approvers and a
different operation to others.
The participants produce signatures over distinct canonical proposal
digests.
The coordinator attempts to combine the signatures into one approval
certificate.
The quorum verifier requires the counted approvals to refer to the
same protected proposal.
The mismatched certificate is rejected.
Where the selected consensus protocol supports equivocation
detection, the conflicting statements may be retained as
authenticated evidence.
Expected demonstrable result: Approval fragments for different
consequential operations cannot be combined into a valid certificate
for an unspecified third operation.
13.40 — WORKED EXAMPLE G: MEMBERSHIP CHANGE DURING APPROVAL
An operation receives partial approvals from a quorum configuration.
8.4.3.49. Source page 1188 of the original specification
Before the threshold is satisfied, one participant is removed and the
protected membership epoch advances.
The coordinator attempts to complete the certificate using the
removed participant's old approval.
The protected verifier applies the current configuration and the
defined transition policy.
If the old approval is no longer valid for the pending decision, it
is rejected.
The operation may require fresh approval or a valid reconfiguration-
continuity procedure.
Expected demonstrable result: Old membership evidence cannot
automatically authorize future effectuation following a protected
configuration change.
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.41 — WORKED EXAMPLE H: THRESHOLD SIGNATURE WITHOUT REQUIRED ROLE
EVIDENCE
A group of cryptographic participants cooperatively produces a valid
threshold signature.
The application policy separately requires that a particular safety
role participate or approve the specified operation.
The resulting group signature verifies under the configured public
key.
However, the signature representation alone does not establish the
required participant-role history.
The protected verifier checks additional authenticated role evidence
or a properly enforced role-constrained signing configuration.
If that evidence is absent, the quorum policy is not satisfied.
Expected demonstrable result: Cryptographic validity is not
misrepresented as proof of an application-specific signer-role
property.
13.42 — WORKED EXAMPLE I: CONFLICTING APPROVALS FOR A SHARED RESOURCE
Two different quorums approve incompatible changes to the same
protected resource.
Both certificates may satisfy their respective approval policies.
However, the operations conflict under the current resource-state
constraints.
8.4.3.50. Source page 1189 of the original specification
The protected reservation controller determines which operation
remains eligible or whether further arbitration is required.
The actual resource Finality Sink checks current reservation and
effect state before commit.
A valid but conflicting second operation is withheld.
Expected demonstrable result: Two approvals do not automatically
permit two incompatible consequential effects.
13.43 — WORKED EXAMPLE J: CROSS-PROVIDER AUTONOMOUS AGENTS
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Several independently administered agents participate in an
authenticated approval workflow.
The originating authority permits a bounded operation on a specified
protected resource.
Participants approve a canonical effect descriptor under the current
policy.
The resulting quorum certificate is transferred to a remote execution
domain.
The receiving domain independently verifies source authority,
applicable policy, certificate authenticity, and actual operation
correspondence.
The receiving Finality Sink prevents effectuation if the operation
has changed or valid authority is missing.
Expected demonstrable result: Cross-provider quorum evidence does not
become an unrestricted portable bearer permission.
13.44 — WORKED EXAMPLE K: QUORUM-APPROVED INDUSTRIAL COMMAND
A protected industrial controller requires approval from several
designated control roles before a consequential machine operation.
The participants approve a specified command envelope.
The actual actuator controller obtains the pending device command.
It verifies the current command target, operating parameters, safety
constraints, quorum certificate, and protected consumption state.
A command differing from the approved physical operation is withheld.
Where a prior command is already executing, the system separately
accounts for its real physical state.
8.4.3.51. Source page 1190 of the original specification
Expected demonstrable result: Collective approval of a command
proposal does not bypass current protected physical-effect
validation.
13.45 — WORKED EXAMPLE L: REPLAYED QUORUM APPROVAL
A quorum approves one bounded external operation.
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Finality Sink verifies the certificate and consumes the
corresponding finality authority.
The requesting agent later presents the same certificate and attempts
the same effect again.
The protected sink checks current consumption state.
Where the approved effect is single-use, the repeated operation is
rejected.
A valid earlier signature does not resurrect consumed consequential
authority.
Expected demonstrable result: Approval replay does not produce
duplicate effects through the governed sink.
13.46 — WORKED EXAMPLE M: QUORUM DECISION FOLLOWED BY UNCERTAIN
REMOTE EFFECT
A quorum approves a transaction, and the Finality Sink dispatches the
corresponding operation.
The receiving service may have processed the command, but the
acknowledgement is lost.
The quorum certificate remains valid evidence of the approval
decision.
It does not establish the completed external result.
The system retains protected attempt and uncertainty state.
A new quorum decision does not automatically authorize another
equivalent transaction.
Recovery proceeds under the protected outcome and retry conditions of
the applicable recovery protocol.
Expected demonstrable result: Collective decision finality is
distinguished from actual remote-effect completion.
13.47 — WORKED EXAMPLE N: QUORUM APPROVAL WITH A CHANGED EXECUTION
MODEL
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.52. Source page 1191 of the original specification
Several agents approve a consequential operation.
Before effectuation, the requesting execution system changes its
model or action-selection algorithm.
The relevant protected policy requires current execution-generation
continuity.
The Finality Sink verifies both the quorum certificate and the
applicable current model or algorithmic authorization.
The earlier quorum decision does not override the execution-drift
condition.
Expected demonstrable result: Quorum approval cannot bypass an
independently mandatory activated-generation verification
requirement.
13.48 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
13.48.1 — Forged Participant Identity
An attacker impersonates an enrolled approver.
The protected system requires current authenticated participant
identity.
13.48.2 — Sybil Membership
One controller creates multiple apparent agents.
The quorum verifier enforces the applicable membership and
independence rules.
13.48.3 — Forged Approval Signature
An attacker constructs an invalid cryptographic approval.
The verifier rejects it.
13.48.4 — Genuine Signature, Wrong Role
A valid signer attempts to satisfy a role it does not possess.
The protected policy requires correct role attribution.
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.48.5 — Removed Participant
An earlier participant attempts approval after valid removal.
Current membership state prevents invalid new endorsements.
13.48.6 — Expired Identity Generation
8.4.3.53. Source page 1192 of the original specification
A participant uses an outdated identity credential.
The verifier checks current enrollment generation.
13.48.7 — Compromised Key Share
An attacker obtains one threshold-signing share.
The selected scheme's compromise threshold and role controls
determine the supported security.
13.48.8 — Threshold Key Recovery Attack
A signing implementation reuses prohibited nonce material.
The system must employ a correct cryptographic protocol and required
state protections.
13.48.9 — Coordinator Equivocation
A coordinator distributes conflicting proposals.
Canonical proposal binding and appropriate equivocation handling
constrain the attack.
13.48.10 — Mixed-Proposal Certificate
Signatures for several operations are combined into one purported
approval.
The certificate verifier requires one consistent operation
commitment.
13.48.11 — Resource Substitution
An approved operation is redirected to another actual resource.
The sink verifies current target correspondence.
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.48.12 — Recipient Substitution
A valid approval is used with another payment or disclosure
recipient.
The actual recipient binding rejects the mismatch.
13.48.13 — Amount Substitution
The requested quantity, payment amount, or other effect parameter
changes.
The Finality Sink verifies current operation scope.
13.48.14 — Semantic Ambiguity
Different participants interpret a high-level operation differently.
8.4.3.54. Source page 1193 of the original specification
The protected protocol requires a suitably precise canonical effect
descriptor.
13.48.15 — Canonicalization Inconsistency
Different services parse the same representation differently.
The implementation uses supported typed or canonical security-
relevant fields.
13.48.16 — False Quorum Count
A malicious coordinator claims enough approvals without supplying
valid evidence.
The protected verifier independently evaluates quorum satisfaction.
13.48.17 — Double Counting
One participant approval is counted more than once.
Distinct qualified participant identities are enforced.
13.48.18 — Role Double Counting
One participant is counted across roles where the policy requires
independence.
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The role and independence predicate detects the violation.
13.48.19 — Weighted Vote Manipulation
An attacker changes participant approval weights.
Protected current policy authentication prevents unauthorized
reweighting.
13.48.20 — Membership Rollback
An old permissive participant configuration is restored.
Protected membership epochs and current authoritative state reject
invalid rollback.
13.48.21 — Unsafe Reconfiguration
A dynamic membership update permits conflicting decisions under two
configurations.
The transition must satisfy the actual consensus or decision-safety
requirements.
13.48.22 — Conflicting Quorum Certificates
Two certificates approve incompatible effects.
Protected conflict state and sink-time verification prevent
unauthorized simultaneous effectuation.
8.4.3.55. Source page 1194 of the original specification
13.48.23 — Byzantine Participant Collusion
Several participants intentionally endorse a prohibited operation.
The guarantee depends upon the selected fault bound and independent
source-authority checks.
13.48.24 — Consensus on False Evidence
A quorum agrees upon an incorrect claim about resource state.
The independent resource or Finality-Sink verifier checks the
required current actual conditions.
13.48.25 — Stale Certificate Replay
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A historical certificate is presented after policy or authority
change.
Current epochs and revocation state are verified.
13.48.26 — Cross-Sink Certificate Replay
One certificate is presented at a different effectuation interface.
Designated-sink and operation bindings prevent unauthorized use.
13.48.27 — Double Effectuation
The same certificate is presented several times.
Protected consumption state prevents unauthorized repeated exercise.
13.48.28 — Distributed Consumption Split Brain
Separate sinks accept the same authority without shared state.
The implementation requires appropriate authoritative consumption or
bounded partitioning for its claimed guarantee.
13.48.29 — Revoked Source Authority
The originating principal revokes permission after quorum approval.
The Finality Sink verifies current source authority.
13.48.30 — Resource-Version Drift
The actual resource changes before commit.
Current version or reservation checks prevent stale effectuation.
8.4.3.56. Source page 1195 of the original specification
13.48.31 — Tool Contract Change
The downstream effect semantics change after quorum approval.
The protected system verifies current operation compatibility.
13.48.32 — Model or Runtime Replacement
The requesting computational generation changes.
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Applicable current execution-state requirements remain mandatory.
13.48.33 — Network Partition
Different participant groups possess inconsistent information.
Safety and liveness remain bounded by the selected quorum protocol
and network assumptions.
13.48.34 — Unavailable Participant
An authorized approver refuses to participate.
The system may withhold effectuation rather than invent an approval.
13.48.35 — Threshold Signing Denial of Service
A participant supplies invalid cryptographic shares or withholds
participation.
The signing controller handles abort, attribution, and recovery
according to the supported cryptographic protocol.
13.48.36 — Forged Quorum Certificate
An attacker presents a syntactically plausible certificate lacking
valid cryptographic or protected authentication.
The verifier rejects it.
13.48.37 — Unauthorized Certificate Issuer
A genuine signing authority issues a certificate outside its
permitted quorum role.
The protected verifier checks authorization and scope.
13.48.38 — Cryptographic Downgrade
An attacker attempts to use an unapproved signing or certificate-
validation algorithm.
Current protected cryptographic policy determines validity.
8.4.3.57. Source page 1196 of the original specification
13.48.39 — Quorum Proof Exhaustion
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An attacker submits excessive or malformed approval evidence.
The protected verifier enforces bounded work.
13.48.40 — Alternate Effectuation Interface
A requester invokes an effect-capable API outside the controlled
sink.
The claimed non-bypassability requires appropriate enforcement
coverage.
13.48.41 — Compromised Coordinator
The coordinator is malicious.
The actual protected authority cannot depend solely upon its self-
reported approval status.
13.48.42 — Compromised Finality Sink
The affected resource controller is compromised.
The claimed guarantee requires an appropriately trusted remaining
enforcement boundary.
13.48.43 — False External Completion Claim
A quorum claims an operation completed when only approval occurred.
The system requires qualified actual-effect evidence for completion-
dependent authority.
13.48.44 — Unauthorized Recovery Vote
Participants approve a correction outside the applicable recovery
envelope.
Independent recovery-specific authority remains mandatory.
13.48.45 — Emergency Override Abuse
A requester labels an operation as urgent to bypass quorum
restrictions.
Emergency authority must be separately authenticated and bounded
under a defined policy.
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.49 — CRASH, PARTITION, AND RECOVERY HANDLING
13.49.1 — Crash Before Proposal
No valid quorum-approved Candidate Act is presumed.
8.4.3.58. Source page 1197 of the original specification
13.49.2 — Crash During Approval Collection
The controller recovers authenticated approvals and current
configuration state.
13.49.3 — Crash During Threshold Signing
Nonce and signing-round state must be handled according to the
selected cryptographic protocol.
13.49.4 — Crash After Certificate Construction
The certificate may remain valid only within its protected
applicability conditions.
13.49.5 — Crash During Membership Change
Authoritative configuration state determines which participant set is
valid.
13.49.6 — Crash During Finality Preparation
The controller determines whether operation-specific authority
actually committed.
13.49.7 — Crash After Finality Consumption
The consumed authority cannot automatically be exercised again.
13.49.8 — Crash After External Dispatch
The actual effect may have occurred.
13.49.9 — Unknown Completion
Qualified outcome evidence or protected retry controls are required
before another effect attempt.
13.49.10 — Network Partition
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The system applies the selected protocol's safety and availability
rules rather than assuming that every isolated group may execute
independently.
13.49.11 — Revocation During Partition
An offline sink may lack current revocation state.
Strict current-authority guarantees require suitable bounded leases,
authoritative reachability, or another effective restriction.
13.49.12 — Recovery Candidate Act
Any corrective external operation requires its own valid current
authority.
8.4.3.59. Source page 1198 of the original specification
13.50 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
13.50.1 — Minimum Architecture
A feasible reference implementation may comprise five authenticated
participant processes, a protected membership registry, a canonical
operation builder, a quorum verifier, an authoritative consumption-
state service, and a controlled resource gateway.
13.50.2 — Original Authority
The prototype establishes permission to modify one specified resource
under defined quantitative limits.
13.50.3 — Quorum Policy
Three distinct enrolled participants are required to approve a
proposed mutation.
13.50.4 — Canonical Proposal
The exact resource, mutation, validity generation, and designated
gateway are committed.
13.50.5 — Participant Approval
Each participant authenticates its approval of the same proposal
digest.
13.50.6 — Certificate Construction
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The verifier constructs or validates a collective-approval
certificate.
13.50.7 — Protected Finality Enablement
A controller establishes operation-bound finality authority.
13.50.8 — Actual Resource Gateway
The gateway reconstructs the actual requested mutation.
13.50.9 — Valid Operation
The approved operation is committed under current resource and
authority conditions.
13.50.10 — Content Substitution
A different mutation under the same certificate is rejected.
13.50.11 — Certificate Replay
Repeated use of consumed authority is rejected.
8.4.3.60. Source page 1199 of the original specification
13.50.12 — Membership Update
A participant is removed, and approval validity is reevaluated.
13.50.13 — Role-Constrained Extension
The policy requires an additional independent security-role approval.
13.50.14 — Threshold Signature Extension
The implementation may replace individual signatures with a suitable
threshold-signing scheme, retaining additional evidence needed for
role verification.
13.50.15 — Byzantine Consensus Extension
A separately configured replicated decision service may demonstrate
appropriate conflict-safe agreement under the selected fault model.
13.50.16 — Hardware Extension
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The finality controller may be implemented in a protected storage,
network, credential, or actuator interface.
13.50.17 — Trust-Model Qualification
A software-only prototype demonstrates the mechanism under its stated
trusted-gateway and identity assumptions.
It does not automatically prove resistance to complete compromise of
every privileged component.
13.51 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Valid Source Authority: Verify approval and finality
of one precisely authorized operation.
Experiment 2 — Insufficient Votes: Submit fewer than the required
number of approvals.
Experiment 3 — Valid Numerical Quorum: Confirm satisfaction of the
current fixed threshold.
Experiment 4 — Missing Mandatory Role: Supply enough votes while
omitting a required approval role.
Experiment 5 — Participant Identity Forgery: Present a forged
enrolled identity.
8.4.3.61. Source page 1200 of the original specification
Experiment 6 — Duplicate Identity: Attempt to count one participant
several times.
Experiment 7 — Common-Control Participants: Test a defined
participant-independence policy.
Experiment 8 — Wrong Membership Epoch: Present approvals under an
invalid older configuration.
Experiment 9 — Participant Removal: Revoke a signer before a new
decision.
Experiment 10 — Membership Reconfiguration: Apply an authorized safe
configuration transition.
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 11 — Pending Proposal During Reconfiguration: Evaluate
partial approval continuity.
Experiment 12 — Signed-Looking Forgery: Present a syntactically
plausible but unauthenticated certificate.
Experiment 13 — Genuine Wrong-Role Signature: Use an authentic
participant without the required role.
Experiment 14 — Proposal Digest Substitution: Change the actual
proposal after collecting approvals.
Experiment 15 — Canonicalization Ambiguity: Test divergent
interpretations of structured operation fields.
Experiment 16 — Resource Substitution: Redirect an approved mutation
to a different resource.
Experiment 17 — Recipient Substitution: Change the actual recipient
after quorum approval.
Experiment 18 — Amount Modification: Alter the quantity or payment
amount.
Experiment 19 — Source Authority Missing: Produce a valid quorum
certificate without valid originating resource authority.
Experiment 20 — Quorum Certificate Replay: Attempt a second
effectuation under consumed authority.
Experiment 21 — Cross-Sink Replay: Present one certificate at another
effectuation interface.
Experiment 22 — Threshold Group Signature: Verify valid threshold
signing under the selected cryptographic scheme.
Experiment 23 — Threshold Role Attribution: Test whether additional
evidence establishes required signer roles.
8.4.3.62. Source page 1201 of the original specification
Experiment 24 — Nonce Reuse Protection: Validate the applicable
threshold-signing nonce handling.
Experiment 25 — Invalid Signature Share: Simulate malformed threshold
contributions.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Experiment 26 — Missing Participant: Test safe withholding when
quorum cannot be obtained.
Experiment 27 — Equivocating Coordinator: Send different canonical
proposals to different approvers.
Experiment 28 — Conflicting Participant Votes: Collect authenticated
incompatible votes within one relevant decision context.
Experiment 29 — Conflicting Quorum Certificates: Test protected
conflict handling.
Experiment 30 — Resource Version Change: Modify the resource after
quorum approval.
Experiment 31 — Authority Revocation: Revoke source permission before
actual effectuation.
Experiment 32 — Quorum Policy Update: Change required roles or
thresholds before finality.
Experiment 33 — Concurrent Approval Workflows: Approve two resource-
overlapping Candidate Acts.
Experiment 34 — Protected Reservation Integration: Test version-bound
reservation consumption with quorum approval.
Experiment 35 — Byzantine Participant Simulation: Introduce faulty
participants under a stated fault model.
Experiment 36 — Network Partition: Test safety and availability
within the selected distributed protocol.
Experiment 37 — Coordinator Crash: Recover partial approval
collection without fabricating a valid certificate.
Experiment 38 — Crash After Certificate Creation: Verify current
state after restart.
Experiment 39 — Crash After Finality Consumption: Prevent
unauthorized repeated effectuation.
Experiment 40 — Unknown External Outcome: Distinguish quorum approval
from real remote completion.
Experiment 41 — Causal Receipt Integration: Require an accepted CW-2
actual-effect receipt for a dependent successor operation.
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.63. Source page 1202 of the original specification
Experiment 42 — Cross-Provider Quorum: Authenticate participants
across separate administrative domains.
Experiment 43 — Model Generation Change: Verify current execution
authority following an applicable model replacement.
Experiment 44 — Tool Semantic Change: Reject a downstream operation
with additional unapproved side effects.
Experiment 45 — Device Ownership Change: Verify current destination
effectuation authority following migration.
Experiment 46 — Privacy-Constrained Approval: Confirm that quorum
approval does not bypass a mandatory cumulative disclosure limit.
Experiment 47 — Credential Broker Enforcement: Require quorum-bound
scoped credential activation.
Experiment 48 — Direct Hardware Effect: Verify collective approval at
a protected hardware command sink.
Experiment 49 — Approval Verification Exhaustion: Bound processing of
excessive certificate evidence.
Experiment 50 — Membership Rollback: Restore a superseded participant
configuration.
Experiment 51 — Dynamic Role Update: Modify an approval role under
authenticated configuration control.
Experiment 52 — Distributed Consumption: Exercise one authority
through multiple participating controlled sinks.
Experiment 53 — Uncontrolled Bypass Demonstration: Identify the
limits of a deployment lacking mandatory coverage.
Experiment 54 — Integrated Protected Controller: Place approval
verification and finality in one protected device.
Experiment 55 — Independent Finality Controller: Separate the quorum
decision service and actual effectuation sink.
Experiment 56 — No Blockchain: Demonstrate current protected quorum
authority and sink-local consumption without a blockchain.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Each experiment should define the claimed property, participant trust
model, exact effectuation boundary, manipulated condition, and
observable expected result.
13.52 — FEASIBILITY AND PERFORMANCE ENGINEERING
8.4.3.64. Source page 1203 of the original specification
13.52.1 — Approval Latency
Quorum collection may add communication and computation latency.
13.52.2 — Protected Fast Path
Approved certificate verification may be performed using compact
cryptographic evidence and current protected state.
13.52.3 — Threshold Cryptography
Threshold signatures may reduce certificate size under suitable
schemes but introduce signing-protocol and key-management
requirements.
13.52.4 — Individual Signature Evidence
Individual signatures may support direct participant attribution at
the cost of larger certificates.
13.52.5 — Membership Caching
Authenticated membership configuration may be cached within protected
validity and update conditions.
13.52.6 — Configuration Freshness
A cached configuration must not be treated as permanently current.
13.52.7 — Role Verification
Role predicates may be evaluated through a protected policy engine.
13.52.8 — Independence Evidence
An implementation may use authenticated administrative or hardware-
domain enrollment information.
13.52.9 — Resource Conflict State
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Version-bound reservations may reduce invalid concurrent
effectuation.
13.52.10 — Certificate Revocation
Revoked or superseded approval authority must be reflected in the
applicable current protected state.
13.52.11 — Distributed Availability
Insufficient reachable quorum members may prevent progress.
8.4.3.65. Source page 1204 of the original specification
The implementation must not silently lower required approval
conditions.
13.52.12 — Bounded Validation
Malformed or excessive certificate data may be processed under
protected resource limits.
13.52.13 — Independent Sink Work
Frequent effectuation paths may use compact current-state
verification without repeating all distributed voting steps.
13.52.14 — Assurance Scope
The implementation must separately specify consensus safety,
cryptographic unforgeability, participant independence, source
authorization, and finality-enforcement guarantees.
These are distinct technical properties.
13.53 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
13.53.1 — Multi-Provider Autonomous Agent Quorums
Independently administered agents may participate in operation-
specific protected authorization.
13.53.2 — Multi-Model Decision Committees
Several different computational models may contribute bounded
approvals while finality remains independently controlled.
13.53.3 — Hardware-Enforced Approval Roles
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Protected processors or hardware security modules may enforce signer
identity and role-specific authorization.
13.53.4 — Confidential Approval Computation
Participants may perform selected protected verification without
revealing all underlying sensitive inputs to every participant.
13.53.5 — Privacy-Preserving Quorum Proofs
Cryptographic proofs may establish selected approval predicates
without exposing unnecessary participant or proposal information.
13.53.6 — Dynamic Quorum Reconfiguration
Membership may change while maintaining the required protected safety
conditions.
8.4.3.66. Source page 1205 of the original specification
13.53.7 — Cross-Cloud Quorum Authority
Administrative domains may cooperatively approve operations without
delegating unrestricted effectuation credentials.
13.53.8 — On-Device and Remote Agent Coordination
Local and remote agents may supply different approval roles under a
common protected source authority.
13.53.9 — Autonomous Financial Operations
Selected financial effects may require operation-bound approvals from
independently authorized participants.
13.53.10 — Industrial Safety Committees
Protected computational and hardware participants may jointly approve
specified physical commands.
13.53.11 — Robotic Fleet Operations
Several devices may authorize shared-resource operations while actual
actuator sinks enforce current protected scope.
13.53.12 — Autonomous Vehicle Infrastructure
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Selected high-impact configuration or control operations may require
collective approval under an appropriate safety authority.
13.53.13 — Programmable Networks
Quorum decisions may approve specified network-control changes, with
independent enforcement at the actual device or network resource.
13.53.14 — Satellite and Remote Systems
Intermittently connected participants may use bounded preauthorized
procedures where current quorum availability is limited.
13.53.15 — Future Hardware Interconnects
Protected effectuation authority may govern commands initiated by
interconnected accelerators or other heterogeneous devices.
13.53.16 — Post-Quantum Cryptographic Migration
Collective approval authentication may evolve to suitable future
cryptographic constructions without changing the underlying finality-
control relationship.
8.4.3.67. Source page 1206 of the original specification
13.53.17 — Long-Duration Autonomous Governance
Quorum policies may remain applicable across agent replacement, model
updates, and task continuation.
13.53.18 — Recovery-Specific Quorums
Distinct participant sets may be authorized to approve bounded
recovery Candidate Acts.
13.53.19 — Dynamic Risk-Based Approval
An authenticated policy may require different approval conditions for
defined operation risk classes.
13.53.20 — Unified Quorum-Finality Infrastructure
A protected service may provide current membership verification,
canonical proposal commitment, collective decision evidence, and
effectuation-time finality enforcement across heterogeneous
autonomous systems.
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
These are non-limiting proposed technical variations.
13.54 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
13.54.1 — Canonical Proposal Plus Actual Sink Reconstruction
The actual Finality Sink verifies that the effect presented for
execution corresponds to the exact collectively approved operation.
13.54.2 — Quorum Certificate Plus Source Authority
A valid collective decision cannot authorize effects outside the
originating principal's permitted scope.
13.54.3 — Role-Constrained Quorum Plus Non-Bearer Finality
The protected system verifies required role participation and then
creates a sink-bound single-use enablement.
13.54.4 — Participant Independence Plus Membership Attestation
Quorum validity depends upon qualified identity and required
independence evidence.
13.54.5 — Dynamic Membership Plus Finality Epoch
A membership change alters the applicability of pending approvals and
downstream authority.
8.4.3.68. Source page 1207 of the original specification
13.54.6 — Byzantine Agreement Plus Resource Conflict Control
Consensus-approved operations remain subject to current resource
reservations and conflict invariants.
13.54.7 — Threshold Cryptography Plus Role Evidence
A threshold signature is supplemented by authenticated evidence
establishing application-specific signer roles where required.
13.54.8 — Quorum Approval Plus Current Algorithm Generation
A protected operation requires valid collective approval and current
applicable computational-generation authority.
13.54.9 — Quorum Approval Plus Device Ownership
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A quorum-approved hardware operation remains dependent upon current
authorized device ownership.
13.54.10 — Quorum Approval Plus Privacy State
A valid collective decision cannot bypass mandatory cumulative
information-release restrictions.
13.54.11 — Quorum Approval Plus Causal Receipt
A successor operation requires both a valid quorum decision and the
accepted actual-effect receipt of an earlier mandatory causal phase.
13.54.12 — Quorum Approval Plus Recovery Finality
A corrective operation requires qualified earlier-effect evidence,
bounded recovery authority, and current collective approval where the
recovery policy specifies it.
13.54.13 — Cross-Domain Quorum Plus Destination Enforcement
Collective decisions may be formed across administrative domains
while the receiving Finality Sink independently verifies the actual
pending effect.
13.54.14 — Quorum Certificate Plus Atomic Consumption
A valid approval certificate may authorize only a defined number of
consequential operations under protected consumption state.
13.55 — PROPOSED INVENTIVE-STEP ANALYSIS
13.55.1 — Established Prior Art
8.4.3.69. Source page 1208 of the original specification
Majority voting, multi-party authorization, threshold signatures,
Byzantine fault-tolerant consensus, quorum certificates, participant
enrollment, cryptographic identity, and distributed state-machine
replication are established technical areas.
The embodiment does not claim these mechanisms individually.
13.55.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
How to prevent collective approvals generated by autonomous
computational participants from being forged, misapplied, replayed,
or treated as unrestricted consequential authority when membership,
resource state, policy, or the actual pending operation changes, by
binding qualified quorum evidence to an authorized Candidate Act and
independently enforcing current operation-specific authority at the
actual Finality Sink.
13.55.3 — Candidate Technical Solution
A candidate combination comprises:
An authenticated originating source authority;
A canonical consequential Candidate Act;
A protected current quorum policy and membership state;
Authenticated participant approvals;
A qualified collective approval certificate;
Protected decision and conflict state;
A scoped non-bearer finality enablement;
And independent actual-operation reconstruction and current authority
verification at the Finality Sink.
13.55.4 — Technical Interaction
The originating authority establishes permissible effects.
The canonical proposal identifies the exact consequential operation.
The membership service establishes who may participate in the
relevant approval.
The quorum verifier establishes whether the required participants and
roles approved the same operation.
The protected decision controller maintains current certificate and
conflict state.
8.4.3.70. Source page 1209 of the original specification
The finality authority controller establishes operation-specific
protected enablement.
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The actual Finality Sink reconstructs the pending consequence and
checks its correspondence with the collective approval and current
source authority.
The sink-local consumption state prevents unauthorized replay.
Each mechanism addresses a distinct cause of improperly exercised
collective authority.
13.55.5 — Not Merely Consensus
Consensus may establish agreement upon a proposal.
The principal implementation additionally requires source authority
and current actual-effect correspondence before consequence release.
13.55.6 — Not Merely Threshold Signing
A threshold signature may prove cooperation sufficient to
authenticate a message.
The present candidate arrangement additionally establishes the
application-specific approval conditions, current operation scope,
and protected finality state.
13.55.7 — Not Merely Multi-Agent Voting
A voting result may be recorded in an orchestration system.
The stronger implementation prevents governed external effectuation
unless the actual sink verifies the required approval and authority
conditions.
13.55.8 — Not Merely Role-Based Access
Participant role assignments may determine who can approve.
The proposed architecture binds those roles to the precise approved
operation and independent consequential enforcement.
13.55.9 — Not Merely a Signed Quorum Certificate
A certificate may be cryptographically valid while referring to an
obsolete configuration, different operation, revoked source
authority, or consumed approval.
The actual sink verifies current applicability.
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.55.10 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
A protected multi-agent consequential authorization system in which
an originating Candidate Act is committed to a canonical operation
descriptor, authenticated quorum
8.4.3.71. Source page 1210 of the original specification
participants approve that descriptor under a protected membership and
role policy, a current quorum certificate supports creation of scoped
non-bearer finality authority, and a Finality Sink independently
reconstructs the actual pending operation and refuses effectuation
unless the certificate, source authority, current configuration,
operation binding, and sink-local consumption predicates remain
valid.
13.55.11 — Additional Role-Oriented Kernel
A narrower implementation may require authenticated role and
administrative-independence conditions that cannot be established
merely by a threshold signature without appropriate additional
evidence.
13.55.12 — Additional Reconfiguration Kernel
Another candidate may require protected quorum-configuration
transitions that invalidate or reconcile pending operation-specific
finality authority according to current membership state.
13.55.13 — Additional Hardware Kernel
Another candidate may require quorum-bound operation-specific
enablement verified directly by a protected hardware or device
command sink.
13.55.14 — Additional Cross-Domain Kernel
Another candidate may require authenticated multi-domain quorum
evidence combined with independent destination-side source authority,
operation, and consumption checks.
13.55.15 — Hindsight Considerations
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A proper inventive-step analysis must identify whether prior systems
already teach the combination of collective approval, precisely
scoped authorization, protected certificate state, resource-bound
execution, and independent downstream enforcement.
Known multisignature wallets, protected distributed-control systems,
transaction authorization gateways, and policy-enforcing multi-party
systems may be highly relevant.
Merely adding a standard policy check after an established quorum
approval may be obvious.
A stronger claim should identify the particular technical dependency,
non-replayable state transition, operation-specific binding, or
distinct enforcement property not supplied by the closest prior art.
13.55.16 — Patentability Qualification
The use of new terminology does not establish novelty.
A claimed system must be technically enabled for the stated
participant, network, fault, and effectuation assumptions.
8.4.3.72. Source page 1211 of the original specification
It must not claim universal Byzantine safety without a specified
valid protocol or universal factual correctness merely because a
threshold of agents agreed.
13.56 — INDUSTRIAL APPLICABILITY
13.56.1 — Enterprise Autonomous Agents
Several enterprise agents may approve consequential operations while
protected resource gateways enforce actual effect scope.
13.56.2 — Cloud Infrastructure
Distributed service components may collectively approve bounded
resource-management changes.
13.56.3 — Cross-Provider AI Operations
Independently administered autonomous systems may contribute
qualified approvals without receiving unrestricted execution
credentials.
13.56.4 — Financial Systems
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Selected financial operations may require authenticated multiple-
party approval and independent transaction finality.
13.56.5 — Payment Infrastructure
A controlled payment sink may verify current source authority,
collective approval, actual recipient, amount, and consumption state.
13.56.6 — Database Administration
Multiple authorized participants may approve protected database
mutations.
13.56.7 — File and Document Systems
Sensitive publication or modification operations may require
collective approval tied to the actual file version and content.
13.56.8 — Software Deployment
Autonomous deployment controllers may require multi-role approval
before actual production changes.
13.56.9 — Identity and Credential Management
Credential issuance, release, or revocation may be subject to quorum-
bound authority.
8.4.3.73. Source page 1212 of the original specification
13.56.10 — Network Infrastructure
Several control participants may approve specified protected network
configuration changes.
13.56.11 — Telecommunications
Distributed operational controllers may authorize consequential
changes under protected membership and sink enforcement.
13.56.12 — Industrial Automation
Selected physical commands may require authenticated collective
approval and independent actuator-level validation.
13.56.13 — Robotics
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Multiple controllers or authorized approval services may govern
shared robotic effects.
13.56.14 — Autonomous Transportation
Consequential infrastructure or control changes may require
independent approvals under the selected safety policy.
13.56.15 — Distributed Storage
Storage mutation or administration may require current collective
approval and protected object-version checks.
13.56.16 — Confidential Computing
Protected approval evidence may be generated within or across
confidential execution environments.
13.56.17 — Hardware Accelerators
Controlled accelerator-resource or command operations may be governed
by quorum-bound enablement.
13.56.18 — Edge Computing
Protected authority may coordinate operations across several
independently administered edge nodes.
13.56.19 — Remote and Satellite Infrastructure
Selected consequential operations may be constrained by current or
bounded collective authorization under appropriate connectivity
assumptions.
13.56.20 — Future Autonomous Systems
8.4.3.74. Source page 1213 of the original specification
Dynamic collections of agents, models, protected devices, and service
authorities may provide collective approval while remaining unable to
bypass actual operation-specific finality enforcement.
The industrial utility concerns ensuring that collective
computational approval and actual consequential authority remain
technically distinct and correctly bound.
13.57 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
13.57.1 — Candidate Independent System Claim
A candidate system claim may concern:
A protected source-authority controller configured to establish
permitted consequential effect scope;
A canonical proposal controller configured to commit a Candidate Act
to a machine-verifiable effect descriptor;
A protected quorum-membership controller configured to establish
current authorized participants and applicable roles;
A quorum verification component configured to verify operation-
specific collective approval evidence;
A finality-authority component configured to establish scoped non-
bearer authority dependent upon the collective approval and other
protected conditions;
And a Finality Sink configured to independently reconstruct the
actual pending operation and prevent its effectuation unless the
required source authority, quorum evidence, current configuration,
operation correspondence, and consumption predicates are satisfied.
13.57.2 — Candidate Independent Method Claim
A candidate method may comprise:
Obtaining source authority;
Constructing a consequential Candidate Act;
Canonicalizing its effect descriptor;
Establishing current quorum membership and approval policy;
Collecting authenticated approvals bound to that descriptor;
Verifying the required quorum and role conditions;
8.4.3.75. Source page 1214 of the original specification
Preparing scoped finality enablement;
Reconstructing the actual pending operation at a protected sink;
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Verifying current source authority, certificate validity, and effect
correspondence;
And conditionally enabling the real effect through protected
consumption state.
13.57.3 — Candidate Independent Cross-Domain Claim
Another candidate may govern authenticated approvals from
independently administered participants while requiring current
destination-side actual-effect verification.
13.57.4 — Candidate Independent Membership-Transition Claim
Another candidate may concern protecting operation-bound finality
during authenticated quorum membership changes, with invalidation or
reconciliation of pending approvals under the current configuration.
13.57.5 — Candidate Independent Hardware Apparatus Claim
A protected hardware or device apparatus may verify a current
operation-bound quorum certificate and scoped authority before
permitting a consequential command.
These are claim architectures for later evaluation rather than
finalized patent claims.
13.58 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The originating operation is represented as an
authenticated Candidate Act.
Dependent aspect 2: The effect is held in Non-Effective State pending
current quorum authorization.
Dependent aspect 3: The Candidate Act is represented by a canonical
typed effect descriptor.
Dependent aspect 4: A cryptographic digest binds the exact proposal.
Dependent aspect 5: The proposal includes current resource identity.
Dependent aspect 6: The proposal includes an authorized effect
envelope.
Dependent aspect 7: The proposal includes the designated Finality
Sink.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 8: The quorum configuration is authenticated.
Dependent aspect 9: Each participant possesses a protected identity.
8.4.3.76. Source page 1215 of the original specification
Dependent aspect 10: Participant enrollment includes a protected
generation.
Dependent aspect 11: The quorum policy specifies a minimum number of
approvals.
Dependent aspect 12: The policy additionally requires specified
approval roles.
Dependent aspect 13: The policy requires authenticated participant
independence.
Dependent aspect 14: Common-control identities are counted according
to a protected independence policy.
Dependent aspect 15: The policy uses protected weighted approvals.
Dependent aspect 16: Individual approvals are bound to the same
canonical proposal digest.
Dependent aspect 17: A participant approval identifies the applicable
membership epoch.
Dependent aspect 18: A participant approval identifies its authorized
role.
Dependent aspect 19: A participant approval references qualified
technical validation evidence.
Dependent aspect 20: The protected verifier independently counts
distinct eligible participants.
Dependent aspect 21: The protected verifier evaluates required
approval-role composition.
Dependent aspect 22: The verifier checks independence classes.
Dependent aspect 23: A quorum certificate is formed from multiple
authenticated individual approvals.
Dependent aspect 24: A quorum certificate is formed using an
appropriate threshold signature.
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 25: A threshold signature is supplemented with
authenticated signer-role evidence where required.
Dependent aspect 26: Threshold signing uses protected participant key
shares.
Dependent aspect 27: The selected signing scheme enforces its
required nonce-generation and non-reuse rules.
Dependent aspect 28: A Byzantine fault-tolerant consensus protocol
governs the collective decision.
Dependent aspect 29: The protocol maintains authenticated decision or
view generations.
Dependent aspect 30: Protected equivocation evidence identifies
incompatible participant statements.
8.4.3.77. Source page 1216 of the original specification
Dependent aspect 31: Quorum membership may change through an
authenticated reconfiguration protocol.
Dependent aspect 32: Pending certificates are evaluated for
applicability across configuration transitions.
Dependent aspect 33: A removed participant cannot issue valid new
approvals under superseded authority.
Dependent aspect 34: The protected system detects conflicting quorum-
approved operations.
Dependent aspect 35: Current resource reservations prevent
incompatible effects.
Dependent aspect 36: The quorum certificate is bound to the
originating source authority.
Dependent aspect 37: Quorum approval cannot independently expand the
original effect envelope.
Dependent aspect 38: The quorum decision is associated with current
authority and policy epochs.
Dependent aspect 39: The quorum certificate is bound to an actual
resource identity.
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 40: The quorum certificate is bound to an actual
recipient or destination.
Dependent aspect 41: The quorum certificate is bound to current
operation semantics.
Dependent aspect 42: A protected controller prepares non-bearer
finality authority.
Dependent aspect 43: The finality authority is restricted to a
designated sink.
Dependent aspect 44: The finality authority includes protected usage
or quantitative limits.
Dependent aspect 45: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 46: The sink compares the actual operation with the
canonical approved descriptor.
Dependent aspect 47: The sink verifies current original source
authority.
Dependent aspect 48: The sink verifies current applicable quorum
membership and policy.
Dependent aspect 49: The sink verifies current resource versions or
protected reservations.
Dependent aspect 50: The sink verifies current authority revocation.
Dependent aspect 51: The sink consumes operation-specific protected
finality authority.
Dependent aspect 52: A consumed approval cannot authorize a new
unrelated effect.
8.4.3.78. Source page 1217 of the original specification
Dependent aspect 53: A copied approval certificate cannot authorize a
different sink.
Dependent aspect 54: Cross-provider approvals are independently
verified by the receiving protected effectuation domain.
Dependent aspect 55: A current device-ownership condition remains
mandatory where applicable.
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Dependent aspect 56: A current algorithm or model-generation
condition remains mandatory where applicable.
Dependent aspect 57: A cumulative privacy condition remains mandatory
where applicable.
Dependent aspect 58: A successor operation requires an accepted prior
actual-effect receipt where the applicable CW-2 causal protocol
requires it.
Dependent aspect 59: A quorum-approved corrective effect remains
subject to independent recovery-specific authority.
Dependent aspect 60: The approval and finality functions may be
implemented within one protected apparatus.
Dependent aspect 61: The approval and finality functions may be
implemented in physically distinct authenticated domains.
Dependent aspect 62: A hardware command controller directly verifies
protected quorum-bound finality authority.
Dependent aspect 63: Excessive or malformed approval evidence is
subject to bounded verification work.
Dependent aspect 64: The architecture operates without requiring a
blockchain or public distributed ledger.
These aspects provide non-limiting technical support for later claim
drafting and do not constitute independent findings of patentability.
13.59 — NON-LIMITING TECHNICAL EFFECTS AND ASSURANCE BOUNDARIES
13.59.1 — Operation-Specific Collective Authorization
A collective decision may be bound to the exact consequential
operation approved.
13.59.2 — Prevention of Approval Substitution
The actual sink may reject an operation differing from the canonical
proposal.
8.4.3.79. Source page 1218 of the original specification
13.59.3 — Current Membership Enforcement
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Stale participant configurations may be excluded according to current
protected membership rules.
13.59.4 — Role and Independence Protection
Required approval roles and qualified independent participants may be
verified rather than inferred from numerical vote count alone.
13.59.5 — Byzantine Fault Tolerance
Where an appropriate consensus protocol is used, it may provide its
specified safety or progress properties under the applicable fault
and network assumptions.
13.59.6 — Replay Prevention
Protected finality consumption may prevent unauthorized repeated
exercise of an earlier valid approval.
13.59.7 — Resource-State Continuity
Current resource versions and reservations may prevent approved but
stale operations from effectuation.
13.59.8 — Cross-Domain Enforcement
Remote participants may provide authenticated approvals while the
destination maintains independent consequential control.
13.59.9 — Separation of Consensus and Real Effects
The architecture distinguishes a finalized decision from evidence
that the corresponding external effect occurred.
13.59.10 — Source Authority Preservation
A quorum cannot automatically grant permissions beyond its
legitimately authorized governance scope.
13.59.11 — Cryptographic Limitation
A threshold signature does not independently prove every
application's participant-role or verification predicate.
13.59.12 — Fault-Model Limitation
Security against arbitrary collusion cannot be guaranteed without
sufficient protected assumptions and enforcement.
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.4.3.80. Source page 1219 of the original specification
13.59.13 — Coverage Limitation
A protected quorum verifier cannot prevent bypass through effect-
capable paths outside its mandatory finality coverage.
13.59.14 — Implementation Assurance
The claimed technical properties must correspond to the actual
cryptographic protocol, membership mechanism, resource control, and
Finality-Sink enforcement architecture.
13.60 — UNIVERSAL NON-LIMITING COMBINATION AND PHOSITA IMPLEMENTATION
CLAUSE
The mechanisms disclosed herein may be implemented independently or
in technically compatible combinations.
An implementation may use a fixed quorum with individually verifiable
participant signatures.
Another may employ a role-constrained threshold approval policy.
Another may use an established Byzantine fault-tolerant consensus
protocol.
Another may combine protected quorum evidence with hardware-based
finality.
Another may use independent administrative participant domains.
Another may place approval verification and effectuation controls
within one protected appliance.
Another may distribute them across separately administered protected
systems.
An approval quorum need not be a Byzantine consensus protocol where
only a bounded multi-party approval condition is required.
A valid threshold signature need not imply the identity or role of
every actual signing participant unless the implementation provides
corresponding authenticated evidence.
A consensus decision does not automatically establish source
authority, actual operation correctness, external completion, or
irreversible real-world effect.
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Unless expressly required by a selected claim, no particular
consensus protocol, participant count, cryptographic primitive,
quorum threshold, processor, cloud provider, administrative topology,
or signing algorithm is universally necessary.
The illustrative algorithms, pseudocode, data structures, state
machines, diagrams, experiments, worked examples, and deployment
variations are non-limiting technical aids intended to assist a
person having ordinary skill in the art.
8.4.3.81. Source page 1220 of the original specification
The mechanisms may be combined with the applicable conflict, causal
receipt, resource verification, privacy, migration, runtime
integrity, and protected recovery provisions of other embodiments
where technically compatible.
A cross-reference to another embodiment does not automatically make
every feature of that embodiment mandatory.
The scope of a particular claimed combination remains dependent upon
its actual limitations and enabling disclosure.
Any future-oriented example is a proposed technical variation rather
than a claim of completed experimentation.
13.61 — FINAL TECHNICAL SUMMARY AND PROPOSED INVENTIVE-STEP
CHARACTERIZATION
The present Embodiment 13 discloses a protected architecture for
governing consequential operations requiring agreement or approval
from several autonomous or otherwise computationally represented
participants.
The requesting system may generate a Candidate Act describing a
proposed effect upon a protected resource.
An originating authority establishes the permissible effect scope.
A protected controller represents the proposed operation in
canonical, machine-verifiable form.
The applicable quorum policy identifies current authorized
participants, roles, independence requirements, approval thresholds,
and other relevant conditions.
Participants may evaluate designated aspects of the proposal and
provide authenticated operation-bound approvals.
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A protected verifier determines whether the selected collective
authorization conditions are satisfied.
The resulting certificate may comprise individual signatures,
suitable threshold cryptographic approval, an authenticated consensus
decision, or another technically valid representation.
The certificate may be associated with current protected membership,
decision, conflict, resource, and authority state.
A protected controller may prepare scoped non-bearer finality
enablement for the particular approved Candidate Act.
The requesting agent may possess or relay the approval certificate
without independently obtaining unrestricted permission to produce
the external effect.
8.5. Embodiment 28: Nested Multi-Agent Tool Chains and Branch-Conserved
Effect Budgets
Original specification global pages 2318-2397 (inclusive). Source
file: TECHNICAL SPECIFICATION -2012-2566.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.5.1. Protected Components and Trust-Relationship Architecture Diagram
[Root source authority + budget]
|
[Authenticated delegation DAG]
/
[Agent 1] [Agent 2]
| |
[Tool A] [Agent 3]
| |
[Intermediate effect isolation]
\ /
[Shared branch spend/reservation ledger]
|
[Terminal Finality Sink]
|
[Actual-operation scope + consume]
Figure 21: Embodiment 28: Nested Multi-Agent Tool Chains and
Branch-Conserved Effect Budgets — source-based architecture
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Delegate across nested tool chain]
|
<Every parent edge authentic?>--NO-->[REFUSE]
|YES
<Transitive scope only attenuates?>--NO-->[REFUSE]
|YES
<Branch quota / spending conserved?>--NO-->[REFUSE]
|YES
<Intermediate effects separately authorized?>--NO-->[WITHHOLD]
|YES
[Terminal sink reconstructs actual effect]
|
<Current source + sink state valid?>--NO-->[REFUSE]
|YES
[Consume / effect]
Figure 22: Embodiment 28: Nested Multi-Agent Tool Chains and
Branch-Conserved Effect Budgets — technical flowchart
8.5.3. Original Global Page-Indexed Technical Description
8.5.3.1. Source page 2318 of the original specification
Prevent conflicting modifications to selected authoritative
coordination records
Kubernetes resourceVersion conditional updates
Transactional SQL databases Maintain source-authority, ownership
epochs, operation journals, and protected consumption state
Distributed coordination services Establish current owner generations
under appropriate consistency assumptions
RFC 8693 OAuth Token Exchange Support bounded identity and delegation
transitions between services RFC 9334 remote attestation architecture
Supply evidence concerning selected destination execution properties
Mutual TLS and authenticated IPC Authenticate source, destination,
broker, and protected service channels Versioned or conditional
resource APIs Verify selected current resource-state conditions
Resource-enforced fencing tokens Reject operations from obsolete
execution owners
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Receiver-side idempotency support Prevent selected duplicate same-
logical-operation effects Durable event or operation journals
Preserve dispatch, consumption, and unresolved states Hardware-
protected resource controllers Enforce selected actual device
operations
Qualified resource transaction APIs Reconcile payments, storage
commits, and other external effects
Non-Limiting Reference Implementation
Source agent → protected Candidate Act → authoritative effect-state
inventory → source finality fence → qualified destination → monotonic
ownership-generation transition → in-flight actual-effect
reconciliation → destination-specific non-bearer finality → actual
Finality Sink → current-owner and actual-operation verification →
sink-local consumption → controlled consequential effect.
A possible reference prototype uses two isolated workers, a
transactional ownership database, a protected operation journal, and
a resource API enforcing current ownership epochs and logical
operation consumption.
The existing technologies provide implementation substrates.
The proposed distinguishing technical relationship is the
preservation of original operation-specific consequential authority
and actual resource-effect state across migration, with resource-
enforced rejection of stale ownership and independent destination
finality rather than treating a task lease, checkpoint, exchanged
token, or recovered worker identity as sufficient authorization.
END OF EMBODIMENT 27 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 28
8.5.3.2. Source page 2319 of the original specification
PROTECTED MULTI-AGENT TOOL AND RESOURCE INVOCATION CHAINS WITH
TRANSITIVE AUTHORITY ATTENUATION, INTERMEDIATE EFFECT ISOLATION, AND
END-TO-END FINALITY ACROSS NESTED AGENT DELEGATIONS
28.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Consequential
Operations Across Autonomous Multi-Agent Delegation Chains Using
Protected Originating Authority Roots, Authenticated Delegation-Graph
Commitments, Transitive Scope Attenuation, Branch-Conserved Effect
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Budgets, Intermediate Candidate Act Isolation, Current Delegation and
Revocation Validation, Scoped Non-Bearer Finality Enablement, and
Independent Resource-Sink Reconstruction and Consumption of Actual
Consequential Effects
28.0.1 — General Technical Description
The present Embodiment 28 discloses systems, methods, apparatus,
protected software components, authenticated delegation registries,
distributed computational orchestration services, protected
authority-graph controllers, intermediate resource-effect
classifiers, bounded privilege delegation mechanisms, cross-domain
validation services, and actual Finality Sinks for governing
autonomous consequential operations occurring through multiple
agents, tools, workers, services, and administrative domains.
An autonomous computational task may involve an originating principal
and one or more intermediate computational agents.
A first agent may delegate information retrieval to a second agent.
The second agent may delegate document interpretation to a third
agent.
The third agent may use an external tool or privileged service.
The tool may invoke another tool, credential broker, database
service, cloud interface, payment service, file operation, device
controller, or other effect-capable resource.
The original task may therefore be processed through multiple
computational and administrative boundaries before a consequential
operation occurs.
Such delegation may be useful for distributing work, specializing
computational functions, reducing latency, increasing resource
availability, or separating tool capabilities.
However, each intermediate component may possess different technical
capabilities, permissions, identities, security properties, and
execution conditions.
An intermediate agent may have permission to analyze a document
without having authority to publish it.
A document-analysis agent may possess access to financial information
without having authority to initiate a financial transaction.
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.3.3. Source page 2320 of the original specification
A privileged tool may possess a reusable credential granting broader
access than the originating task permits.
A downstream agent may receive authenticated instructions from an
upstream agent that lacks authority to grant the requested
permission.
A delegation may be repeated through several agents until the
original principal's restrictions are absent from the downstream
computational context.
A task may branch into several agents, each interpreting the same
original authority as an independent allowance.
A delegated operation may be cancelled or revoked while a downstream
agent continues processing.
An intermediate agent may report success even though the real
resource operation has not occurred.
A downstream resource may accept an authenticated request without
independently verifying the actual source-authorized consequential
effect.
An agent may receive legitimate informational results that contain
instructions to perform unauthorized further actions.
A workflow may contain cycles, repeated delegation, multiple parent
agents, or dynamically generated branches that obscure the original
permission chain.
These conditions create a technical need to distinguish:
Computational delegation;
Delegation of task context;
Delegation of informational access;
Delegation of technical tool capability;
Delegation of source-authorized consequential scope;
Actual operation-specific finality authority;
And the completed real resource effect.
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A principal implementation establishes a protected originating
authority root identifying the permissible consequential scope of an
autonomous task.
A protected delegation controller creates authenticated relationships
between the originating authority and each authorized downstream
agent, tool, or execution domain.
8.5.3.4. Source page 2321 of the original specification
Each delegation identifies the subset of authority actually
allocated, the applicable resource and operation constraints, the
permitted delegation depth or class, current authorization
generations, and any shared effect budget.
The controller maintains a protected delegation graph, which may be a
chain, tree, directed acyclic graph, or another qualified structure.
Where multiple delegation paths converge, a protected rule determines
how valid authority is derived without allowing unauthorized
permission aggregation.
A downstream agent may use the received computational task
description to perform ordinary internal computation.
However, the agent does not obtain unconditional authority to perform
every tool invocation requested by an upstream agent.
When any intermediate operation would cause a covered real or
persistent effect, a Candidate Act is constructed for that operation
and maintained in a Non-Effective State.
The protected controller independently establishes whether the actual
operation falls within the originating authority and each mandatory
intermediate delegation constraint.
A protected validation instance obtains current source, delegation,
resource, and revocation evidence.
Where required, a protected cross-commitment relates the originating
grant, applicable delegation path, intermediate evidence, and actual
Candidate Act.
A finality controller establishes scoped non-bearer enablement bound
to the consequential operation and designated Finality Sink.
At the effectuation boundary, the Finality Sink independently
reconstructs the actual pending resource operation.
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The sink verifies the originating source-authorized effect scope,
relevant delegation constraints, current generations, resource
identity, applicable shared budget, and protected operation-specific
finality.
Only after successful protected consumption may the actual
consequence be released.
The presence of multiple agents, additional tool calls, authenticated
messages, or delegated access tokens does not independently enlarge
the original consequential authority.
28.0.2 — Fundamental Technical Principle
Authority cannot be created merely by passing a task through
additional computational agents.
Further:
8.5.3.5. Source page 2322 of the original specification
An authenticated agent message is not necessarily a new originating
source grant.
A valid delegation to perform analysis is not permission to execute
every operation suggested by the analysis.
A delegated tool-access credential is not automatically authority to
perform every effect the tool can technically produce.
A downstream agent's confidence in a proposed action is not protected
authorization.
A valid intermediary approval does not automatically override
restrictions imposed by the originating principal.
The division of a task into several branches does not multiply shared
consequential budgets.
A source-authorized operation does not automatically authorize an
unrelated intermediate effect.
And an apparently valid delegation path does not replace actual
resource-side verification and protected consumption.
28.0.3 — Principal Candidate Inventive Combination
A representative technical combination comprises:
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
(a) a protected originating consequential authority root;
(b) a plurality of autonomous computational agents or tool services;
(c) an authenticated delegation graph connecting agents and relevant
authority sources;
(d) protected transitive authority attenuation for each applicable
delegation;
(e) an operation-specific dependency between the delegated task and
its consequential effect envelope;
(f) protected shared effect-budget or use-count accounting across
parallel branches;
(g) classification of intermediate tool invocations according to
whether they remain computational or produce consequential effects;
(h) enforceable Non-Effective States for covered consequential
Candidate Acts;
(i) an independent validator that resolves current originating,
intermediate, and destination-specific authority;
(j) a protected cross-commitment binding a relevant delegation path
to actual operation evidence;
(k) scoped non-bearer finality enablement;
8.5.3.6. Source page 2323 of the original specification
(l) a designated independent actual Finality Sink;
(m) sink-side actual resource and operation reconstruction;
(n) protected consumption that prevents delegated branches from
exercising authority beyond the original permitted scope.
28.0.4 — Candidate Technical Distinction
The invention does not claim as individually new:
Hierarchical access control;
Delegation certificates;
Token exchange;
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Cryptographic signatures;
Distributed agent orchestration;
Task graphs;
API authorization;
Role-based access control;
Capability systems;
Workflow engines;
Distributed locks;
Or transactional resource budgets.
The candidate distinguishing arrangement concerns the technical
preservation and enforcement of original consequential authority
across a dynamically constructed multi-agent delegation graph,
including mandatory actual-effect verification at each covered
consequential sink and protected conservation of shared authority
across concurrent branches.
28.0.5 — Focus of this Embodiment
This embodiment provides focused dependent-claim implementation
support for:
Nested agent delegation;
Transitive scope attenuation;
8.5.3.7. Source page 2324 of the original specification
Cross-agent authority provenance;
Tool and resource invocation chains;
Delegation graph integrity;
Multi-parent authority resolution;
Parallel branch accounting;
Intermediate-effect isolation;
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Current chain revocation;
Delegated credential use;
Cross-domain handoffs;
And independent end-to-end Finality-Sink verification.
The embodiment may incorporate foundational Candidate Act, Non-
Effective State, Protected Enforcement Domain, protected validation,
non-bearer finality, and sink-local state mechanisms without
restating every earlier foundational disclosure.
28.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v PROTECTED AUTHORITY ROOT | v AGENT A / \ /
\ v v AGENT B AGENT C | | v v TOOL D AGENT E | | v v RESOURCE R1 TOOL
F | v RESOURCE R2 PROTECTED DELEGATION GRAPH | v
8.5.3.8. Source page 2325 of the original specification
TRANSITIVE AUTHORITY ATTENUATION | v SHARED BUDGET AND USE
ACCOUNTING | v INTERMEDIATE EFFECT CLASSIFIER | v CANDIDATE ACT /
NES | v INDEPENDENT CURRENT CHAIN VALIDATION | v NON-BEARER FINALITY
ENABLEMENT | v ACTUAL FINALITY SINK | v ACTUAL OPERATION
RECONSTRUCTION | v SOURCE + DELEGATION + RESOURCE CHECK | v SINK-
LOCAL CONSUMPTION | v CONTROLLED REAL EFFECT
The diagram is illustrative and non-limiting.
The number of agents, branches, tools, resource sinks, and
administrative domains may vary.
A single computational agent may produce several consequential
Candidate Acts.
Several agents may participate in preparing one Candidate Act.
The applicable security properties are derived from protected source
authority and actual finality, not from the number of agents shown.
28.1 — TECHNICAL FIELD
The invention relates to autonomous multi-agent systems, distributed
tool invocation, delegated authority management, agent-to-agent
communication, operation-specific access
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.3.9. Source page 2326 of the original specification
control, cross-domain authorization, protected workflow execution,
cryptographic provenance, shared resource budgets, and independent
resource-effectuation finality.
More particularly, it concerns preventing authority inflation,
confused-deputy behavior, unauthorized intermediate side effects, and
duplicate consequential operations within nested or branching
autonomous agent workflows.
28.2 — SPECIFIC TECHNICAL PROBLEMS
28.2.1 — Transitive Authority Inflation
A downstream agent may receive broader authority than the originating
principal intended.
28.2.2 — Intermediate Agent Confused Deputy
A privileged intermediary may exercise its technical resources for an
unauthorized lower-trust request.
28.2.3 — Delegation Scope Loss
Original resource restrictions may be omitted during repeated
handoffs.
28.2.4 — Message Authentication Confusion
An authenticated upstream message may be mistaken for valid
originating authorization.
28.2.5 — Tool Credential Inflation
A tool may possess reusable credentials broader than the delegated
operation.
28.2.6 — Agent Branch Duplication
Several downstream branches may each treat a shared allowance as
independently available.
28.2.7 — Multi-Agent Budget Race
Concurrent agents may attempt to consume the same authority before
another branch's result is visible.
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.2.8 — Authority Aggregation at a Join
A downstream agent may incorrectly combine separate partial grants to
obtain a broader permission.
28.2.9 — Delegation Cycle
An operation may be delegated repeatedly through cyclic graph paths.
8.5.3.10. Source page 2327 of the original specification
28.2.10 — Delegation Depth Abuse
An agent may delegate through many levels to evade original controls.
28.2.11 — Unknown Child Agent
A downstream execution identity may not satisfy the original
delegation policy.
28.2.12 — Unauthorized Re-Delegation
An agent may delegate authority it was only permitted to exercise
itself.
28.2.13 — Cross-Tenant Delegation
An operation may cross administrative or tenant boundaries without
valid source permission.
28.2.14 — Delegated Tool Schema Change
A downstream tool may introduce a new effect while preserving a
familiar interface.
28.2.15 — Delegated Recipient Change
A child agent may select a different resource or payment recipient.
28.2.16 — Prompt-Injection Laundering
Lower-trust data may be repeated as apparently authoritative
instructions through several agents.
28.2.17 — False Parent Approval
A child agent may assert that an upstream principal approved an
operation.
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.2.18 — Intermediate Consequential Side Effect
A supposedly analytical subtask may invoke a tool that modifies
persistent state.
28.2.19 — Hidden Credential Activation
An intermediate tool may exercise a credential before end-to-end
authorization.
28.2.20 — Inadequate Finality at Intermediate Sinks
A workflow may verify only its final outcome while permitting
unauthorized intermediate effects.
28.2.21 — Stale Parent Delegation
A child may continue executing after the parent grant changes.
8.5.3.11. Source page 2328 of the original specification
28.2.22 — Revocation Propagation Delay
A descendant may use historical authorization after an ancestor is
revoked.
28.2.23 — Delegation Graph Substitution
An agent may replace one ancestor, parent, or path record with
another.
28.2.24 — Delegation Replay
A valid historical delegation may be reused for another task.
28.2.25 — Cross-Branch Capability Reuse
A capability prepared for one branch may be presented through
another.
28.2.26 — Source-Authority/Identity Confusion
A technical workload identity may be mistaken for original principal
permission.
28.2.27 — Unauthorized Join Operation
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Several independently permitted informational subtasks may be
combined into an unauthorized consequential act.
28.2.28 — Branch Cancellation
An abandoned branch may retain unused operation authority.
28.2.29 — Agent Failure During Consumption
A child may fail after dispatching an operation but before returning
its result.
28.2.30 — Multi-Resource Atomicity Assumption
A workflow may incorrectly treat independent resource operations as
one atomic transaction.
28.2.31 — Technical Objective
A candidate objective technical problem is:
How to allow autonomous agents and tools to recursively delegate and
distribute computation while preventing any intermediate or final
consequential effect from exceeding the originating authority,
duplicating shared effect allowances, or bypassing mandatory current
resource-side finality despite dynamic, branching, and cross-domain
delegation.
28.3 — ESTABLISHED TECHNOLOGIES AND THEIR LIMITATIONS
8.5.3.12. Source page 2329 of the original specification
28.3.1 — Agent-to-Agent Communication
Existing agent communication protocols can exchange tasks, messages,
results, and authentication information.
They do not universally define a resource-specific protected finality
mechanism for all downstream consequences.
28.3.2 — OAuth Token Exchange
Token exchange can produce credentials supporting delegated service
access and can represent selected actor relationships.
It does not inherently establish a durable one-time relationship
between a specific Candidate Act and an actual downstream resource
mutation.
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.3.3 — Rich Authorization Requests
Structured authorization data can express detailed permissions for
selected resources and actions.
The present implementation may use such data as a source grant.
A structured authorization description alone does not guarantee that
every actual downstream effect matches it after multiple agent
transformations.
28.3.4 — Workload Identity
Workload identity systems may authenticate service instances or other
computational entities.
Authenticating a child agent does not independently establish that
the child may perform all operations requested by its parent.
28.3.5 — Role-Based Access Control
Roles can constrain available resources and functions.
A role may still be broader than a particular originating task-
specific Candidate Act.
28.3.6 — Capability Delegation
Existing capability systems may attenuate, bind, or delegate
permissions.
The candidate additional relationship concerns the protected actual
effectuation boundary, current original source authority, branch
accounting, and separate sink-local finality.
28.3.7 — Workflow Graphs
Workflow engines can represent dependent and parallel tasks.
8.5.3.13. Source page 2330 of the original specification
A computational dependency is not necessarily a resource-effect
authorization dependency.
28.3.8 — Transactional Counters
Existing transactional counters can prevent certain forms of
overspending.
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The present architecture may associate shared counters with protected
delegation-chain authority and actual resource effects.
28.3.9 — Technical Distinction
The proposed architecture combines qualified delegation paths with
independent operation-specific resource finality, rather than
treating successful intermediate authentication or tool invocation as
sufficient authority.
28.4 — PRINCIPAL SYSTEM COMPONENTS
A representative implementation comprises:
A Protected Originating Authority Registry;
A Delegation Graph Controller;
An Agent and Tool Identity Registry;
A Protected Delegation Scope Validator;
A Delegation Attenuation Controller;
A Multi-Parent Authority Resolver;
A Delegation Cycle and Depth Controller;
A Protected Branch Allocation Ledger;
An Intermediate Effect Classifier;
A Candidate Act Constructor;
A Non-Effective State Controller;
A Current Source and Delegation Validator;
A Cross-Committed Authority Evidence Controller;
A Scoped Non-Bearer Finality Controller;
A Protected Tool and Credential Broker;
8.5.3.14. Source page 2331 of the original specification
One or more Actual Finality Sinks;
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Sink-Local Consumption Controller;
A Current Revocation Controller;
And a Qualified Outcome and Recovery Journal.
These components may be distributed or integrated according to the
claimed protection properties.
28.5 — TECHNICAL DEFINITIONS
28.5.1 — Protected Originating Authority Root
A Protected Originating Authority Root, or POAR-28, means a protected
record identifying the original principal and the consequential
effect scope from which valid downstream authority must be derived.
28.5.2 — Delegation Graph
A Delegation Graph, or DG-28, means a representation of authenticated
computational or authority-related relationships among agents, tools,
and services.
28.5.3 — Delegation Edge
A Delegation Edge means a protected relationship by which one
qualified entity assigns a bounded task, permission, or authority
role to another.
28.5.4 — Delegation Path
A Delegation Path means an ordered sequence of authenticated
delegation edges connecting an originating authority or authorized
parent to a downstream entity.
28.5.5 — Effective Delegated Authority
Effective Delegated Authority, or EDA-28, means the consequential
effect scope validly available to a downstream entity after
application of required originating and intermediate restrictions.
28.5.6 — Transitive Authority Attenuation
Transitive Authority Attenuation, or TAA-28, means deriving
downstream permission without unauthorized enlargement beyond the
applicable upstream authority.
28.5.7 — Computational Delegation
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.3.15. Source page 2332 of the original specification
Computational Delegation means transfer of work, data, or processing
responsibility without necessarily transferring authority for
consequential effects.
28.5.8 — Consequential Delegation
Consequential Delegation means an authorized bounded allocation of
permission to perform one or more defined real or persistent effects.
28.5.9 — Delegation Role
A Delegation Role means the protected classification of whether a
downstream entity may process data, propose an operation, further
delegate authority, or request effectuation.
28.5.10 — Delegation Generation
A Delegation Generation means an authoritative version of a
particular delegation or relevant delegation graph state.
28.5.11 — Delegation Graph Commitment
A Delegation Graph Commitment, or DGC-28, means an authenticated
representation of selected graph nodes, edges, permissions, and
generations.
28.5.12 — Delegation Chain Witness
A Delegation Chain Witness, or DCW-28, means a qualified record
identifying the source and intermediate delegation constraints
applicable to a specified Candidate Act.
28.5.13 — Intermediate Consequential Effect
An Intermediate Consequential Effect means a real or persistent
resource operation occurring before the workflow's nominal final
outcome.
28.5.14 — Intermediate Effect Candidate
An Intermediate Effect Candidate, or IEC-28, means a Candidate Act
representing such an intermediate consequence.
28.5.15 — Branch-Conserved Authority
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Branch-Conserved Authority, or BCA-28, means a protected rule
preventing independently executing branches from collectively
exceeding a shared originating allowance.
28.5.16 — Branch Allocation
A Branch Allocation means an authoritative assignment of a bounded
portion of shared authority to a specified branch.
28.5.17 — Delegated Effect Budget
8.5.3.16. Source page 2333 of the original specification
A Delegated Effect Budget means a protected limit governing permitted
actual consequential effects across specified descendants.
28.5.18 — Shared Ancestor Budget
A Shared Ancestor Budget means an effect limit applicable
collectively to multiple downstream paths derived from an originating
grant.
28.5.19 — Delegation Join
A Delegation Join means a graph operation in which information or
authority references from multiple parent paths are combined.
28.5.20 — Qualified Join Rule
A Qualified Join Rule means a protected rule specifying whether the
downstream operation must satisfy an intersection, an independent
authorization, or another expressly permitted relationship among
predecessor grants.
28.5.21 — Authority Union Prohibition
Authority Union Prohibition means a default condition preventing
independent partial grants from being combined into broader
consequential permission without an authorized composition rule.
28.5.22 — Delegation Cycle
A Delegation Cycle means a sequence of delegation edges returning to
a previously encountered authority node or defined task-authority
state.
28.5.23 — Delegation Depth Limit
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Delegation Depth Limit means a protected upper bound upon permitted
authority-bearing delegation hops.
28.5.24 — Delegation Fan-Out Limit
A Delegation Fan-Out Limit means a protected upper bound on selected
child delegations or concurrent branch allocations.
28.5.25 — Delegation-Aware Candidate Act
A Delegation-Aware Candidate Act, or DACA-28, means a Candidate Act
associated with a protected originating authority and applicable
delegation-chain witness.
28.5.26 — Delegation-Bound Non-Bearer Enablement
Delegation-Bound Non-Bearer Enablement means scoped finality
authority requiring protected verification of a relevant delegation
relationship rather than mere presentation of a portable token.
8.5.3.17. Source page 2334 of the original specification
28.5.27 — Actual-Effect Delegation Equality
Actual-Effect Delegation Equality means protected correspondence
between a source-authorized consequential effect, applicable
delegated constraints, and the actual operation presented at the
sink.
28.5.28 — Authority-Laundering Attempt
An Authority-Laundering Attempt means an attempt to transform
insufficient source permission into apparently valid downstream
authority through one or more computational or delegation steps.
28.5.29 — Tool-Capability Confusion
Tool-Capability Confusion means treating a tool's technical ability
to perform an operation as proof that the operation is permitted
under the originating task.
28.5.30 — Protected Child Registration
Protected Child Registration means authenticated creation of a
downstream agent or tool relationship under bounded delegation
conditions.
28.5.31 — Ancestor Revocation Dependency
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An Ancestor Revocation Dependency means a condition under which a
relevant revoked parent or originating grant invalidates affected
descendant authority.
28.5.32 — Descendant Authority Fence
A Descendant Authority Fence means a protected restriction preventing
further affected consequential effects after an invalidating
delegation change.
28.5.33 — Intermediate Effect Receipt
An Intermediate Effect Receipt means qualified evidence concerning an
actual earlier operation performed within the delegation workflow.
28.5.34 — Computational Result Record
A Computational Result Record means data or a result returned by a
child agent without necessarily constituting an actual consequential-
effect receipt.
28.5.35 — Protected Chain Validation
Protected Chain Validation means independently verifying the
applicable original and intermediate authority relationships of a
Candidate Act.
28.5.36 — Protected Chain Truncation
8.5.3.18. Source page 2335 of the original specification
Protected Chain Truncation means a failure or unauthorized
transformation that removes a required upstream delegation
constraint.
28.5.37 — Shared Authority Conservation
Shared Authority Conservation means preventing duplicated expenditure
of a common original consequential allowance across distinct child
agents or branches.
28.5.38 — Delegation-Bound Resource Sink
A Delegation-Bound Resource Sink means an actual Finality Sink
configured to enforce relevant chain-authority and operation-specific
conditions.
28.5.39 — Transitive Source-Authority Correspondence
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Transitive Source-Authority Correspondence means verified consistency
between the actual operation and each required original or
intermediate constraint.
28.5.40 — Delegation-Graph Recovery Generation
A Delegation-Graph Recovery Generation means a protected current
version distinguishing valid recovered graph authority from stale
checkpoints or earlier graph state.
28.6 — FIVE SEPARATE LAYERS OF MULTI-AGENT AUTHORITY
A principal implementation distinguishes five layers.
28.6.1 — Source Permission
The original principal authorizes defined consequential effects.
28.6.2 — Delegation Permission
An intermediary may be authorized to delegate selected work or
selected bounded authority.
28.6.3 — Tool Access
A downstream agent may be technically permitted to invoke a
particular service.
28.6.4 — Operation-Specific Finality
A protected controller establishes current authority for a particular
actual consequential operation.
28.6.5 — Resource Completion
The real receiving resource performs the effect, with its outcome
qualified according to the selected assurance model.
8.5.3.19. Source page 2336 of the original specification
An agent may possess one layer without possessing all other layers.
For example, an agent authorized to invoke a payment-administration
tool may lack permission to initiate a particular transfer.
Similarly, an agent permitted to propose a file modification may lack
authority to commit the modification into a protected resource.
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.7 — PROTECTED ORIGINATING AUTHORITY ROOT
A representative record comprises:
PROTECTED_ORIGINATING_AUTHORITY_ROOT = { originating_task_identifier,
originating_principal, authorized_operation_classes,
authorized_resource_classes, permitted_resources,
permitted_recipients, authorized_effect_parameters,
cumulative_effect_budget, allowed_delegation_roles,
allowed_delegation_depth, allowed_branching_scope,
permitted_execution_domains, required_validation_modules,
current_authority_generation, current_revocation_generation,
protected_root_authentication }
The root may express permissions through typed resource and operation
descriptors.
It need not disclose every computational subtask in advance.
A downstream agent may choose a method of computation within a
permitted workflow.
However, actual consequential effects remain governed by the current
source-authorized envelope.
28.8 — PROTECTED DELEGATION EDGE
A representative protected edge comprises:
PROTECTED_DELEGATION_EDGE = { delegation_identifier,
8.5.3.20. Source page 2337 of the original specification
originating_root_reference, parent_agent_identity,
child_agent_identity, parent_delegation_reference,
parent_authority_generation, allocated_task_scope,
permitted_operation_classes, permitted_resource_scope,
permitted_data_scope, permitted_redelegation,
delegated_effect_budget, designated_execution_domain,
delegation_generation, current_revocation_reference,
protected_edge_authentication }
28.8.1 — Parent Identity
The edge identifies the qualified delegating entity.
28.8.2 — Child Identity
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The edge identifies the qualified receiving entity.
28.8.3 — Authority Attenuation
The child may receive only a permissible subset or other authorized
derivation from the parent's effective scope.
28.8.4 — Re-Delegation
Authority to perform a function is not automatically authority to
delegate that function onward.
28.8.5 — Current State
A historically authentic edge may no longer confer current permission
after revocation or material scope change.
28.9 — TRANSITIVE AUTHORITY ATTENUATION
In a simple chain:
[ A \rightarrow B \rightarrow C \rightarrow D ]
8.5.3.21. Source page 2338 of the original specification
the effective permission of D may be expressed as:
[ P_D=P_A\cap P_{A\to B}\cap P_{B\to C}\cap P_{C\to D} ]
where the permissions are represented within a qualified compatible
authorization model.
The expression illustrates restriction across a delegation path.
It is not limited to literal set intersection where complex
conditions require typed policy evaluation.
28.9.1 — Resource Scope
A child cannot expand from one permitted file to every file merely by
passing through additional agents.
28.9.2 — Operation Scope
Permission to read does not independently become permission to
delete.
28.9.3 — Recipient Scope
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Permission to communicate with one recipient does not independently
permit another recipient.
28.9.4 — Cumulative Scope
A child cannot create a larger shared spending allowance.
28.9.5 — Authority Expansion
A valid separately authenticated new source grant may establish
additional authority.
Such authority is not created merely by the intermediary's delegation
act.
28.10 — DELEGATION GRAPH COMMITMENT
A protected controller may commit the delegation relationships
applicable to a particular Candidate Act.
A non-limiting relation comprises:
[ C_G=H(\operatorname{Canon}(R,E,G,V)) ]
8.5.3.22. Source page 2339 of the original specification
(R) denotes the originating authority root;
(E) denotes selected delegation edges;
(G) denotes current relevant graph generations;
And (V) denotes applicable validation predicates.
The commitment may be authenticated using a protected signature,
message-authentication mechanism, or authoritative registry.
28.10.1 — Path Commitment
The graph witness identifies the permitted path.
28.10.2 — Current Authority
The protected validator checks whether required edges remain valid.
28.10.3 — Non-Bearer Interpretation
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Possession of a graph commitment does not automatically authorize a
consequential effect.
28.10.4 — Sink Binding
The applicable chain evidence is bound to the actual Candidate Act
and designated resource sink.
28.11 — DATA LINEAGE VERSUS AUTHORITY LINEAGE
A multi-agent system may preserve both informational derivation and
permission delegation.
These are distinct.
28.11.1 — Data Lineage
Agent B receives a document from Agent A.
Agent C receives a summary from Agent B.
The summary's informational origin may trace to the document.
28.11.2 — Authority Lineage
Agent C receives only the permission properly delegated through the
protected authority chain.
8.5.3.23. Source page 2340 of the original specification
28.11.3 — No Automatic Conversion
The fact that a document or instruction passed through an
authenticated agent does not make it a valid principal authorization.
28.11.4 — Protected Consequence
The actual sink verifies valid authority rather than treating
computational provenance alone as sufficient.
This variation may incorporate Embodiment 24.
28.12 — COMPUTATIONAL DELEGATION WITHOUT EFFECT AUTHORITY
A principal may delegate pure computation to an agent.
For example:
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Agent A asks Agent B to analyze a dataset.
Agent B asks Agent C to calculate a result.
Agent C may return a number or structured recommendation.
The original task may not permit Agent C to change an external
database.
The child agents may be allowed to compute without receiving broad
resource-effect permissions.
28.12.1 — Computational Freedom
A child may perform authorized local calculations.
28.12.2 — Consequential Boundary
The child cannot independently commit a new external effect.
28.12.3 — Candidate Act
A requested external operation becomes a separately validated
Candidate Act.
28.13 — INTERMEDIATE EFFECT CLASSIFICATION
An intermediate tool call may be:
CLASS I — Internal computation.
8.5.3.24. Source page 2341 of the original specification
CLASS II — Preparatory operation whose output remains non-effective.
CLASS III — Actual protected resource read or disclosure.
CLASS IV — Persistent state mutation.
CLASS V — Credential use or privilege activation.
CLASS VI — Financial, network, device, or other consequential effect.
CLASS VII — Unknown or insufficiently qualified operation.
The exact classes are non-limiting.
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Class VII operation is withheld where its classification is a
mandatory security predicate.
28.13.1 — Critical Distinction
The workflow's nominal final output does not define all consequential
operations that may occur during intermediate stages.
An agent may generate a correct final report while an intermediate
tool has already disclosed confidential information.
A principal implementation therefore provides finality control for
each covered intermediate consequential effect.
28.14 — INTERMEDIATE CANDIDATE ACT
A representative record comprises:
INTERMEDIATE_EFFECT_CANDIDATE = { candidate_act_identifier,
originating_root_identifier, delegation_path_commitment,
requesting_agent_identity, intermediate_tool_identity,
actual_effect_class, actual_resource_identity,
material_operation_parameters, required_credential_or_privilege,
designated_finality_sink, applicable_shared_budget,
current_delegation_generation, current_source_authority_generation,
protected_candidate_authentication }
8.5.3.25. Source page 2342 of the original specification
The record is created before the corresponding effect becomes
effective.
A workflow may contain multiple separate intermediate Candidate Acts.
A later Candidate Act does not retroactively authorize an earlier
unauthorized intermediate operation.
28.15 — TOOL INVOCATION AS A DISTINCT AUTHORITY BOUNDARY
An agent may be permitted to call a tool.
However, the tool may be capable of several effects.
For example:
A database connector can read and delete records.
A cloud interface can list and create resources.
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A browser can navigate and submit transactions.
A credential broker can authenticate to several services.
A device controller can query state and issue commands.
The protected architecture distinguishes:
Tool invocation permission;
Actual operation semantics;
Resource-specific source authority;
And finality for the actual consequence.
A valid parent-to-child delegation may permit using the tool for one
resource operation while withholding all other effects.
28.16 — DELEGATED CREDENTIAL USE
A downstream tool may require a protected credential.
The protected credential broker may maintain reusable credential
custody.
The delegated agent receives no automatic right to unrestricted
credential use.
8.5.3.26. Source page 2343 of the original specification
The broker verifies:
Current originating authority;
Applicable delegation-chain scope;
Actual resource identity;
Current credential state;
Actual operation parameters;
And protected finality enablement.
A child agent's valid workload identity does not independently
establish permission to exercise every credential held by the broker.
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
This variation may incorporate Embodiment 23.
28.17 — BRANCH-CONSERVED AUTHORITY
Suppose the originating principal authorizes one consequential
operation.
Agent A delegates portions of the task to Agent B and Agent C.
Both branches may prepare an eligible operation.
The protected system does not treat the shared original allowance as
two independent permissions.
A representative invariant is:
[ \sum_{i=1}^{n} C_i\leq B_{\text{root}} ]
(C_i) is the protected consumption attributable to branch (i);
And (B_{\text{root}}) is the originating shared effect budget.
28.17.1 — Shared Ledger Mode
Branches compete against an authoritative common consumption ledger.
28.17.2 — Reserved Allocation Mode
8.5.3.27. Source page 2344 of the original specification
A protected allocator reserves disjoint portions of the budget for
branches.
28.17.3 — Reallocation Mode
Unused allocated authority may be returned through a protected
transition.
28.17.4 — Double Spending
A branch cannot independently reuse authority already consumed by
another branch.
28.17.5 — Distributed Qualification
Global budget conservation requires an appropriately consistent
authority mechanism or disjoint enforceable preallocations.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Independent offline counters that are later merely aggregated do not
guarantee conservation during concurrent operation.
28.18 — BRANCH ALLOCATION RECORD
A representative record may comprise:
PROTECTED_BRANCH_ALLOCATION = { originating_root_reference,
shared_budget_identifier, parent_delegation_reference,
child_branch_identifier, allocated_effect_scope, allocated_use_count,
allocated_resource_budget, reserved_budget_generation,
branch_owner_identity, permitted_return_conditions,
current_consumption_reference, protected_allocation_authentication }
The allocation may be:
Single-use;
Amount-limited;
Data-volume-limited;
Resource-count-limited;
Or bounded by another measurable consequence.
8.5.3.28. Source page 2345 of the original specification
28.19 — BRANCH FORK
A parent may create several child tasks.
The protected controller may:
Verify current permission to delegate;
Determine the permitted total effect allowance;
Assign branch identities;
Allocate disjoint resource budgets where required;
Commit the branch allocation;
And provide each child with a bounded computational or authority
reference.
28.19.1 — Computational Fork
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
May require no transfer of consequential authority.
28.19.2 — Authority Fork
Requires protected allocation of permitted effects.
28.19.3 — Shared Source
The original permission remains authoritative.
28.19.4 — No Multiplication
Creating additional branches does not automatically increase the
original allowable number or magnitude of effects.
28.20 — BRANCH JOIN AND MULTI-PARENT AUTHORITY
A downstream agent may receive requests from multiple parents.
For example:
Agent B is authorized to read Resource X.
Agent C is authorized to write Resource Y.
Both send results to Agent D.
8.5.3.29. Source page 2346 of the original specification
Agent D must not automatically infer that it is authorized to
transfer all information from X into Y.
28.20.1 — Default Restrictive Rule
The downstream consequence satisfies every mandatory applicable
original and delegated restriction.
28.20.2 — No Arbitrary Union
Two partial grants do not automatically form a larger unrestricted
permission.
28.20.3 — Authorized Composition
A principal or protected policy may expressly authorize a specific
combined operation.
28.20.4 — Current Operation Check
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protected validator verifies the actual resource effect of the
combined operation.
28.20.5 — Provenance and Authority
Informational inputs from multiple parents may be combined without
combining their execution permissions.
28.21 — DELEGATION CYCLE CONTROL
A delegation graph may contain cycles.
A cycle may cause repeated delegation, unbounded task spawning,
duplicated effect proposals, or misleading authority paths.
The protected controller may require:
A bounded delegation depth;
Unique authority-generation references;
Cycle detection for authority-bearing paths;
A maximum fan-out;
Or another qualified termination and authority-control mechanism.
28.21.1 — Permitted Computational Cycles
A computational workflow may legitimately repeat an analysis step.
8.5.3.30. Source page 2347 of the original specification
28.21.2 — Authority-Bearing Cycles
Repetition does not create additional delegated effect authority.
28.21.3 — Re-Delegation Policy
A child may delegate onward only where expressly permitted.
28.21.4 — Protected Consumption
Each actual effect remains subject to independent Finality-Sink
authority.
28.22 — CURRENT DELEGATION REVOCATION
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A principal may revoke the original task.
A parent may revoke a specific child delegation.
An administrator may revoke a tool's role.
A destination resource may change access permissions.
A principal implementation determines which pending descendant
operations depend upon the revoked authority.
28.22.1 — Ancestor Revocation
Invalidates affected descendants where the ancestor is mandatory.
28.22.2 — Sibling Isolation
An unrelated valid branch need not automatically become invalid.
28.22.3 — Prepared Finality
Affected unused enablement may be invalidated.
28.22.4 — Consumed Effects
Already completed effects remain historical.
28.22.5 — Resource Sink
Current revocation is enforced at the actual covered effectuation
boundary.
28.23 — REVOCATION GRAPH DEPENDENCIES
8.5.3.31. Source page 2348 of the original specification
A protected revocation structure may comprise:
PROTECTED_DELEGATION_REVOCATION = { revoked_delegation_identifier,
originating_root_reference, affected_descendant_reference_set,
revocation_generation, source_authority_generation,
affected_candidate_act_commitment, required_finality_invalidation,
applicable_resource_sinks, protected_revocation_authentication }
A protected registry may index descendants for efficient
invalidation.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The existence of a revocation message does not prove every remote
effect has already been stopped.
The actual resource sink must enforce the applicable current state.
28.24 — CHAIN AUTHORITY WITNESS
For a particular Candidate Act, the system may construct a protected
witness comprising:
DELEGATION_CHAIN_WITNESS = { originating_root_digest,
task_identifier, applicable_delegation_edge_digests,
effective_authority_scope, effective_resource_scope,
delegation_depth, current_graph_generation,
current_revocation_generation, applicable_branch_allocation,
designated_finality_sink, candidate_act_digest,
protected_witness_authentication }
The witness may refer to protected registry entries rather than
reproduce sensitive authorization data.
28.24.1 — Witness Completeness
The applicable mandatory authority constraints must be included or
independently resolvable.
28.24.2 — Source Authenticity
8.5.3.32. Source page 2349 of the original specification
A child agent cannot fabricate valid originating authority merely by
producing a structurally correct witness.
28.24.3 — Sink Use
The sink uses the witness as evidence subject to current protected
verification.
28.24.4 — Non-Bearer Character
The witness itself is not an unrestricted transferable finality
credential.
28.25 — CROSS-COMMITTED CHAIN EVIDENCE
A protected collection-time component may commit selected delegation
and Candidate Act evidence.
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An independent execution-time validator may reconstruct the
applicable current authority scope and actual operation evidence.
A non-limiting relation comprises:
[ C_C=H(\operatorname{Canon}(CA,R,G,P)) ]
[ C_E=H(\operatorname{Canon}(CA,O,A,C_C)) ]
[ C_F=H(\operatorname{Canon}(C_C,C_E,S,L)) ]
(CA) is the Candidate Act;
(R) is the originating authority root;
(G) is the applicable delegation graph;
(P) is protected collection-time evidence;
(O) is the actual operation descriptor;
(A) is current source and delegation authority;
(S) is the designated Finality Sink;
8.5.3.33. Source page 2350 of the original specification
And (L) is applicable branch-allocation or consumption state.
The exact cryptographic encoding and cross-commitment mechanism are
non-limiting.
A digest authenticates selected represented values only to the extent
supported by the underlying protected evidence and verification
procedure.
28.26 — DELEGATION-AWARE CANDIDATE ACT
A representative DACA-28 comprises:
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
DELEGATION_AWARE_CANDIDATE_ACT = { candidate_act_identifier,
originating_task_identifier, original_source_grant_reference,
requesting_leaf_agent_identity,
applicable_delegation_path_commitment, parent_task_reference,
actual_requested_effect_class, actual_resource_reference,
material_operation_parameters, outgoing_content_commitment,
applicable_budget_allocation, current_source_generation,
current_delegation_generation, required_validation_modules,
designated_finality_sink, protected_candidate_authentication }
The requesting agent may propose the operation.
The protected controller independently validates the authority and
actual resource implications.
28.27 — NON-EFFECTIVE INTERMEDIATE OPERATIONS
A downstream agent may generate:
An API request;
A payment instruction;
A file mutation;
A database command;
8.5.3.34. Source page 2351 of the original specification
A privileged tool invocation;
A data disclosure;
A hardware instruction;
Or another consequential operation.
The proposal is held non-effective until the applicable source,
delegation, and finality conditions are satisfied.
28.27.1 — Preparatory Computation
May proceed without authorizing the actual effect.
28.27.2 — Intermediate Finality
A consequential intermediate operation requires appropriate protected
authority.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.27.3 — Terminal Finality
The final workflow outcome may require a separate protected Candidate
Act.
28.27.4 — No Retroactive Authorization
A successful final result does not automatically legalize or
technically authorize an earlier unauthorized intermediate side
effect.
28.28 — INDEPENDENT CHAIN VALIDATION
A protected validator may check:
The current originating authority;
The chain's authentic parent and child identities;
Each mandatory delegation edge;
Delegation depth and re-delegation conditions;
Actual effective permission attenuation;
Current revocation generations;
The actual resource;
The relevant tool contract;
8.5.3.35. Source page 2352 of the original specification
The applicable shared effect budget;
And required evidence for the proposed consequence.
The validator does not assume that a leaf agent's assertion
concerning its authority is correct.
Where selected chain properties are represented through a protected
authorization service, the verifier may obtain them by authenticated
reference rather than by trusting the agent's message contents.
28.29 — NON-BEARER DELEGATION FINALITY
A representative record comprises:
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
DELEGATION_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
originating_source_authority, delegation_chain_commitment,
requesting_agent_identity, current_graph_generation,
current_revocation_generation, actual_effect_descriptor,
current_resource_identity, designated_finality_sink,
independent_validation_commitment,
applicable_branch_budget_reference, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The agent may receive an opaque inert reference.
Possession of the reference does not create authority to perform a
different operation or access another sink.
The sink validates current protected state.
28.30 — ACTUAL FINALITY-SINK RECONSTRUCTION
The actual Finality Sink may obtain or reconstruct:
The actual resource identity;
The operation method;
8.5.3.36. Source page 2353 of the original specification
The relevant content or arguments;
The actual recipient or destination;
The credential or privileged operation requested;
The requesting execution identity;
And the applicable current source and delegation authority.
The sink verifies that the actual operation remains within the valid
delegated effect envelope.
A tool may possess broad technical capability while only a narrow
actual operation is permitted.
28.30.1 — Actual Equality
The relevant effect parameters correspond to the protected Candidate
Act.
28.30.2 — Delegation Validity
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The applicable original and intermediate authority restrictions
remain satisfied.
28.30.3 — Shared Allowance
The actual effect does not exceed the available protected branch or
ancestor budget.
28.30.4 — Protected Consumption
A single-use or bounded enablement is consumed according to the
selected effectuation model.
28.31 — SHARED BUDGET AT THE ACTUAL RESOURCE
A branch allocation service may reserve authority before an
operation.
However, where the resource effect is controlled by a separate sink,
the system must establish the relevant relationship between budget
consumption and actual effectuation.
28.31.1 — Local Transaction
The resource mutation and consumption may be committed atomically
within one sufficiently controlling transaction domain.
28.31.2 — Remote Operation
The broker may record protected consumption before controlled
dispatch and use receiver-side operation identities or qualified
reconciliation as applicable.
8.5.3.37. Source page 2354 of the original specification
28.31.3 — No Automatic Global Atomicity
Independent remote resources do not necessarily share one global
atomic ledger.
28.31.4 — Cumulative Conservation
The system must not treat independently allocated copies of the same
original allowance as additive authority.
28.32 — INTERMEDIATE EFFECT RECEIPTS
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An agent may perform an authorized intermediate consequential
operation.
For example:
Agent B creates a file.
Agent C later processes the file.
Agent D publishes the result.
The protected controller may retain a qualified receipt for the
actual file-creation effect.
However, the receipt does not automatically authorize every later
operation.
Where a later Candidate Act requires a prior real effect under CW-2
Mode B, the corresponding receipt must satisfy the required
acceptance conditions.
A computational result string cannot substitute for an IEV-accepted
actual-effect receipt when such evidence is mandatory.
28.33 — CANCELLATION AND BRANCH RETIREMENT
A branch may be cancelled before completing its assigned work.
The protected controller may:
Fence further branch-specific effectuation;
Invalidate unused finality;
Revoke active delegation authority;
Preserve already completed effects;
Preserve indeterminate effects;
8.5.3.38. Source page 2355 of the original specification
And release any provably unused reserved allocation under applicable
current rules.
28.33.1 — No Blind Budget Return
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An allocation associated with a possibly dispatched effect cannot
automatically be returned as unused.
28.33.2 — Qualified Non-Effect
A valid resource-side non-effect determination may support an
authorized reallocation.
28.33.3 — Completed Effect
The consumed amount remains accounted for.
28.34 — AGENT FAILURE AND RECOVERY
A child agent may fail after:
Preparing a Candidate Act;
Receiving finality preparation;
Consuming protected authority;
Dispatching an external operation;
Or receiving a qualified actual result.
A replacement agent does not automatically receive fresh permission
to repeat the operation.
The protected journal records the relevant state.
A new downstream execution identity may require current delegation
and effectuation ownership validation.
This variation may incorporate Embodiment 27.
28.35 — CROSS-ADMINISTRATIVE DELEGATION
A parent agent may delegate work to an external administrative
domain.
The receiving domain may authenticate the request and obtain a
bounded token or authority reference.
The receiving domain is separately qualified for the required
operation.
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.3.39. Source page 2356 of the original specification
The originating task's current source authority remains applicable.
28.35.1 — Identity
The external agent's identity may be verified.
28.35.2 — Scope
The delegated permission is restricted to permitted effects.
28.35.3 — Credential Exchange
An appropriate service may issue a narrower delegated credential.
28.35.4 — Actual Finality
The resource sink independently verifies current operation-specific
authority.
Cross-domain token exchange or message authentication does not
independently establish complete resource finality.
28.36 — CHAIN DEPTH, FAN-OUT, AND VERIFICATION BOUNDS
A delegation graph may grow dynamically.
A protected controller may impose:
Maximum authority-bearing delegation depth;
Maximum simultaneous child allocations;
Maximum graph verification work;
Maximum credential-use scope;
Maximum uncommitted operation count;
And suitable cycle-handling rules.
These controls may reduce denial-of-service exposure.
However, an implementation must not treat an exhausted verification
budget as proof of authorization.
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where a mandatory verification cannot complete, the applicable effect
remains withheld.
8.5.3.40. Source page 2357 of the original specification
28.37 — DELEGATION GRAPH STATE MACHINE
A non-limiting state machine comprises:
ROOT_AUTHORITY_ACTIVE: The originating permission is valid.
DELEGATION_PROPOSED: A parent requests a child delegation.
EDGE_VALIDATION_PENDING: The requested delegation scope is evaluated.
EDGE_COMMITTED: The protected child relationship is established.
COMPUTATION_ACTIVE: The child performs permitted internal processing.
EFFECT_PROPOSED: A consequential intermediate or final operation is
identified.
NON_EFFECTIVE: The operation remains withheld.
CHAIN_VALIDATION_PENDING: The required delegation path is checked.
BUDGET_RESERVATION_PENDING: Shared authority allocation is
unresolved.
CURRENT_VALIDATION_ACCEPTED: Applicable source, delegation, and
resource predicates pass.
FINALITY_PREPARED: Scoped non-bearer enablement exists.
SINK_VERIFICATION_PENDING: The actual operation is checked at its
resource boundary.
FINALITY_CONSUMED: Protected use authority is consumed.
EFFECT_ATTEMPTED: A controlled consequential primitive has been
released.
EFFECT_CONFIRMED: Qualified evidence establishes the corresponding
completed effect.
EFFECT_INDETERMINATE: The outcome remains uncertain.
ANCESTOR_REVOKED: A required upstream authority has become invalid.
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
BRANCH_FENCED: The branch cannot obtain additional affected finality.
BRANCH_RETIRED: The branch is terminated under current protected
conditions.
28.38 — PRINCIPAL COMMON WORKFLOW
8.5.3.41. Source page 2358 of the original specification
Step 1 — Establish Original Authority. An originating principal
authorizes a bounded consequential task.
Step 2 — Record Authority Root. A protected controller authenticates
the permitted resources, operations, recipients, budgets, and
delegation conditions.
Step 3 — Start Parent Agent. Agent A receives computational task
information.
Step 4 — Propose Delegation. Agent A selects a qualified child agent
or service.
Step 5 — Verify Delegation Permission. A protected controller
determines whether Agent A may delegate the selected function.
Step 6 — Attenuate Scope. The child's permission is limited to the
valid delegated subset.
Step 7 — Commit Delegation Edge. The protected graph records the
child relationship.
Step 8 — Allocate Shared Authority. Any necessary use count or
resource budget is reserved or bound to a common ledger.
Step 9 — Start Child Computation. The child receives relevant task
context and evidence references.
Step 10 — Permit Further Delegation Conditionally. A child may
establish additional valid edges only if redelegation is permitted.
Step 11 — Preserve Authority Lineage. The protected graph retains
the originating restrictions.
Step 12 — Distinguish Data from Authority. Intermediate tool results
do not independently create permission.
Step 13 — Identify Consequential Operation. Any actual or
prospective external effect is classified.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 14 — Construct Candidate Act. The requested operation is
represented with its actual resource and parameters.
Step 15 — Enforce Non-Effective State. Withhold the consequential
primitive.
Step 16 — Resolve Current Delegation Path. Verify applicable parent,
child, and original source constraints.
Step 17 — Verify Effective Authority. Confirm that the actual
operation is within the attenuated scope.
Step 18 — Verify Shared Budget. Check current authoritative
consumption or allocated allowance.
8.5.3.42. Source page 2359 of the original specification
Step 19 — Independently Validate. Establish current resource,
credential, revocation, and operation evidence.
Step 20 — Cross-Commit Evidence. Bind the applicable chain evidence
to the Candidate Act and protected validation.
Step 21 — Prepare Non-Bearer Finality. Establish scoped authority
for the designated sink.
Step 22 — Present Actual Operation. The protected broker or resource
receives the effect-capable request.
Step 23 — Reconstruct Actual Effect. The sink identifies the
material operation.
Step 24 — Verify Current Chain Authority. The sink checks the
current relevant source and delegation predicates.
Step 25 — Verify Current Budget. Ensure that parallel branches have
not exhausted the allowance.
Step 26 — Verify Protected Finality. Confirm the candidate-bound
non-bearer enablement.
Step 27 — Consume Authority. Commit the applicable use and budget
transitions.
Step 28 — Release Actual Effect. Perform the controlled operation.
Step 29 — Record Qualified Outcome. Distinguish attempted from
completed effects.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 30 — Govern Successors. Verify any later operation
independently, including required prior-effect receipts.
28.39 — REFERENCE ALGORITHM: CREATE DELEGATION EDGE
FUNCTION CREATE_PROTECTED_DELEGATION( parent_agent, child_agent,
requested_scope, protected_delegation_controller ): parent_authority
= LOAD_CURRENT_EFFECTIVE_PARENT_AUTHORITY( parent_agent ) REQUIRE
VERIFY_PARENT_IDENTITY(parent_agent) REQUIRE
VERIFY_CHILD_IDENTITY(child_agent)
8.5.3.43. Source page 2360 of the original specification
REQUIRE VERIFY_PARENT_AUTHORITY_CURRENT( parent_authority ) REQUIRE
VERIFY_REDELEGATION_PERMITTED( parent_authority ) REQUIRE
VERIFY_REQUESTED_SCOPE_WITHIN_PARENT( requested_scope,
parent_authority ) REQUIRE VERIFY_DELEGATION_DEPTH_AND_FANOUT()
REQUIRE VERIFY_NO_PROHIBITED_AUTHORITY_CYCLE() allocated_scope =
protected_delegation_controller .ATTENUATE_AUTHORITY(
parent_authority, requested_scope ) allocation =
RESERVE_REQUIRED_SHARED_BRANCH_AUTHORITY( allocated_scope ) edge =
protected_delegation_controller .COMMIT_DELEGATION_EDGE({ parent:
parent_agent, child: child_agent, originating_root:
parent_authority.root, effective_scope: allocated_scope, allocation:
allocation, current_generation: CURRENT_DELEGATION_GENERATION() })
RETURN PROTECTED_DELEGATION_REFERENCE(edge)
The child receives only the authority supported by the committed
protected edge.
28.40 — REFERENCE ALGORITHM: VALIDATE CHAIN
8.5.3.44. Source page 2361 of the original specification
FUNCTION VALIDATE_DELEGATION_CHAIN( candidate_act, chain_witness,
protected_chain_validator ): REQUIRE
VERIFY_ORIGINATING_AUTHORITY_ROOT( chain_witness ) REQUIRE
VERIFY_CURRENT_SOURCE_GRANT() REQUIRE
VERIFY_CHAIN_WITNESS_AUTHENTICITY( chain_witness ) REQUIRE
VERIFY_REQUIRED_DELEGATION_EDGES_CURRENT() REQUIRE
VERIFY_PARENT_CHILD_IDENTITY_BINDINGS() REQUIRE
VERIFY_DELEGATION_DEPTH() REQUIRE
VERIFY_APPLICABLE_REDELEGATION_RULES() REQUIRE
VERIFY_NO_UNAUTHORIZED_AUTHORITY_EXPANSION() effective_scope =
protected_chain_validator .DERIVE_CURRENT_EFFECTIVE_AUTHORITY(
chain_witness ) REQUIRE VERIFY_ACTUAL_CANDIDATE_WITHIN_SCOPE(
candidate_act, effective_scope ) REQUIRE
VERIFY_CURRENT_REVOCATION_DEPENDENCIES() RETURN
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
PROTECTED_CHAIN_VALIDATION_COMMITMENT({ candidate:
HASH(candidate_act), chain: HASH(chain_witness), scope:
HASH(effective_scope), current_generation:
CURRENT_DELEGATION_GENERATION() })
The effective authority cannot be established solely by an untrusted
child agent's claim.
8.5.3.45. Source page 2362 of the original specification
28.41 — REFERENCE ALGORITHM: BRANCH BUDGET
FUNCTION RESERVE_BRANCH_EFFECT_BUDGET( originating_budget,
child_branch, requested_allocation, protected_budget_controller ):
REQUIRE VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_CHILD_BRANCH_DELEGATION() REQUIRE requested_allocation >= 0
current = protected_budget_controller
.LOAD_AUTHORITATIVE_BUDGET_STATE( originating_budget ) REQUIRE
VERIFY_BUDGET_STATE_AUTHENTICITY(current) REQUIRE
CURRENT_AVAILABLE_BUDGET(current) >= requested_allocation reservation
= protected_budget_controller .ATOMIC_RESERVE({ budget:
originating_budget, branch: child_branch, amount:
requested_allocation, expected_generation: current.generation }) IF
reservation != COMMITTED: RETURN DENY RETURN
PROTECTED_BRANCH_ALLOCATION_REFERENCE( reservation )
Concurrent reservation must be serialized or otherwise safely
coordinated under the applicable consistency model.
28.42 — REFERENCE ALGORITHM: INTERMEDIATE EFFECT
FUNCTION HANDLE_INTERMEDIATE_TOOL_EFFECT(
8.5.3.46. Source page 2363 of the original specification
child_agent, proposed_tool_operation, protected_effect_controller ):
actual_effect_class = QUALIFY_TOOL_EFFECT_CLASS(
proposed_tool_operation ) IF actual_effect_class ==
PERMITTED_INTERNAL: RETURN ALLOW_COMPUTATION IF actual_effect_class
== UNKNOWN: RETURN HOLD_PENDING_QUALIFICATION candidate =
CONSTRUCT_INTERMEDIATE_CANDIDATE_ACT({ requester: child_agent,
operation: proposed_tool_operation, source_root:
CURRENT_AUTHORITY_ROOT(), delegation:
CURRENT_PROTECTED_CHAIN_REFERENCE() }) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) validation =
INDEPENDENTLY_VALIDATE_SOURCE_AND_CHAIN( candidate ) REQUIRE
validation == ACCEPTED RETURN PREPARE_DELEGATION_BOUND_FINALITY(
candidate, validation )
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A valid intermediate computation does not automatically authorize the
next consequential operation.
28.43 — REFERENCE ALGORITHM: ACTUAL SINK FINALITY
FUNCTION EFFECTUATE_DELEGATED_OPERATION( candidate_act,
8.5.3.47. Source page 2364 of the original specification
chain_witness, finality_enablement, protected_finality_sink ): actual
= protected_finality_sink .RECONSTRUCT_PENDING_ACTUAL_OPERATION()
REQUIRE VERIFY_ACTUAL_OPERATION_QUALIFIED(actual) REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_CURRENT_DELEGATION_CHAIN( chain_witness ) REQUIRE
VERIFY_ACTUAL_OPERATION_WITHIN_EFFECTIVE_SCOPE( actual, chain_witness
) REQUIRE VERIFY_CURRENT_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_TOOL_AND_CREDENTIAL_STATE() REQUIRE
VERIFY_CURRENT_REVOCATION() REQUIRE VERIFY_SHARED_ANCESTOR_BUDGET()
REQUIRE VERIFY_DELEGATION_BOUND_NON_BEARER_FINALITY(
finality_enablement, actual ) REQUIRE
VERIFY_SINK_LOCAL_CONSUMPTION_STATE() committed =
protected_finality_sink .COMMIT_AUTHORITY_AND_EFFECT_CONSUMPTION(
finality_enablement, actual ) IF committed != COMMITTED: RETURN DENY
RETURN protected_finality_sink .RELEASE_ACTUAL_CONSEQUENCE(actual)
8.5.3.48. Source page 2365 of the original specification
Where authority accounting and the actual external resource do not
share atomic state, suitable controlled dispatch and outcome
reconciliation are required.
28.44 — REFERENCE ALGORITHM: MULTI-PARENT JOIN
FUNCTION AUTHORIZE_MULTI_PARENT_JOIN( incoming_parent_grants,
proposed_combined_effect, protected_join_controller ): REQUIRE
VERIFY_ALL_REQUIRED_PARENT_IDENTITIES() REQUIRE
VERIFY_CURRENT_GRANT_STATUS( incoming_parent_grants ) join_policy =
LOAD_PROTECTED_AUTHORIZED_JOIN_POLICY() IF join_policy == UNDEFINED:
RETURN DENY_AUTHORITY_COMPOSITION effective_scope =
protected_join_controller .DERIVE_COMBINED_AUTHORITY(
incoming_parent_grants, join_policy ) REQUIRE
VERIFY_COMPOSITION_WITHIN_VALID_SOURCE_AUTHORITY( effective_scope )
REQUIRE VERIFY_COMBINED_ACTUAL_EFFECT( proposed_combined_effect,
effective_scope ) RETURN QUALIFIED_COMBINED_CANDIDATE_ACT(
proposed_combined_effect )
Merely receiving multiple grants does not authorize an arbitrary
union of their permissions.
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.45 — REFERENCE ALGORITHM: ANCESTOR REVOCATION
8.5.3.49. Source page 2366 of the original specification
FUNCTION REVOKE_DELEGATION_ANCESTOR( delegation_reference,
protected_revocation_controller ): REQUIRE
VERIFY_REVOCATION_AUTHORITY() descendants =
IDENTIFY_AFFECTED_DESCENDANT_AUTHORITY( delegation_reference )
revocation = protected_revocation_controller
.COMMIT_AUTHORITY_REVOCATION({ ancestor: delegation_reference,
affected: HASH_SET(descendants), next_generation:
NEXT_PROTECTED_REVOCATION_GENERATION() }) REQUIRE revocation ==
COMMITTED FENCE_AFFECTED_PENDING_FINALITY(descendants) REQUIRE
REQUIRED_SINKS_ENFORCE_CURRENT_REVOCATION()
PRESERVE_COMPLETED_AND_INDETERMINATE_EFFECT_STATE() RETURN
PROTECTED_REVOCATION_COMMITMENT()
The revocation prevents new affected authority but does not
automatically reverse completed real effects.
28.46 — REFERENCE ALGORITHM: RECOVER CHILD BRANCH
FUNCTION RECOVER_FAILED_DELEGATED_BRANCH( branch, protected_journal,
qualified_resource_observer ): state = protected_journal
.LOAD_AUTHORITATIVE_BRANCH_EFFECT_STATE( branch )
8.5.3.50. Source page 2367 of the original specification
REQUIRE VERIFY_JOURNAL_AUTHENTICITY(state) IF
QUALIFIED_ACTUAL_EFFECT_COMPLETED(state): RETURN
PRESERVE_COMPLETED_EFFECT IF EFFECT_MAY_HAVE_BEEN_DISPATCHED(state):
evidence = qualified_resource_observer
.QUERY_ACTUAL_RESOURCE_OUTCOME( state.logical_operation ) IF
VERIFY_QUALIFIED_COMPLETION(evidence): RETURN COMMIT_COMPLETED_EFFECT
IF VERIFY_QUALIFIED_NON_EFFECT(evidence): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION RETURN
PRESERVE_INDETERMINATE_EFFECT REQUIRE
VERIFY_CURRENT_PARENT_AND_ROOT_AUTHORITY() REQUIRE
VERIFY_CURRENT_SHARED_BUDGET() RETURN
ELIGIBLE_FOR_CONTROLLED_BRANCH_REASSIGNMENT
A failed child does not automatically return consumed or uncertain
authority to the parent.
28.47 — WORKED EXAMPLE A: NESTED PURCHASING AGENTS
An originating principal authorizes preparation of one purchasing
report.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Agent A delegates supplier research to Agent B.
Agent B delegates price extraction to Agent C.
Agent C obtains supplier quotations.
One quotation contains instructions to initiate a payment.
Agent C may return the quoted price as qualified informational data.
It does not possess payment authority merely through its research
delegation.
A proposed payment becomes a separate Candidate Act.
8.5.3.51. Source page 2368 of the original specification
The protected payment sink verifies the original source grant.
Because payment initiation was not authorized, the effect is refused.
Expected demonstrable result: Recursive computational delegation does
not convert an informational subtask into independent payment
authority.
28.48 — WORKED EXAMPLE B: TWO AGENTS, ONE PAYMENT ALLOWANCE
An originating principal authorizes one bounded payment.
Agent A delegates payment preparation to Agents B and C in parallel.
Both child agents prepare a valid payment request.
The original authority permits only one consequential payment.
The shared protected consumption controller accepts only the
permitted logical operation and allowance.
A duplicate or incompatible second attempt is refused.
Expected demonstrable result: Parallel agent branches do not multiply
a single-use original payment authorization.
28.49 — WORKED EXAMPLE C: BROADER CREDENTIAL IN A DOWNSTREAM TOOL
Agent A delegates one cloud-resource creation to Agent B.
Agent B invokes a protected cloud connector.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The connector possesses a credential permitting many resource
operations.
Agent B requests creation of several unrelated resources.
The credential broker reconstructs the actual request and verifies
the original delegation scope.
Only the authorized operation is eligible.
Expected demonstrable result: A downstream privileged tool cannot
exercise broader credential authority merely because the delegated
agent can invoke it.
8.5.3.52. Source page 2369 of the original specification
28.50 — WORKED EXAMPLE D: INTERMEDIATE DATABASE MUTATION
Agent A delegates document summarization to Agent B.
Agent B invokes a tool that stores intermediate results in a
persistent shared database.
The storage operation is a consequential effect distinct from
producing the summary.
The protected controller constructs an intermediate Candidate Act.
The sink verifies whether persistent shared storage is within the
original authorized task.
If not, the mutation is refused.
Expected demonstrable result: A benign final summary does not
automatically authorize every persistent side effect performed during
its preparation.
28.51 — WORKED EXAMPLE E: MULTI-PARENT AUTHORITY LAUNDERING
Agent B is permitted to read confidential Resource X.
Agent C is permitted to write an unrelated public Resource Y.
Both communicate with Agent D.
Agent D proposes copying confidential content from X into Y.
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protected join controller does not simply combine B's read access
and C's write access into disclosure authority.
The actual data-release sink checks the original applicable source
permissions.
The unauthorized disclosure is refused.
Expected demonstrable result: Combining valid partial capabilities
from separate delegation branches does not automatically create a new
authorized cross-resource effect.
28.52 — WORKED EXAMPLE F: REVOKED PARENT
An originating principal delegates a bounded file-publication task
through Agents A, B, and C.
Before Agent C publishes the file, the principal revokes the relevant
delegation.
Agent C retains an earlier signed handoff record.
8.5.3.53. Source page 2370 of the original specification
The protected Finality Sink checks the current authority generation.
The historical record does not override the revocation.
Expected demonstrable result: Historical chain authenticity does not
independently establish current authority after a mandatory ancestor
is revoked.
28.53 — WORKED EXAMPLE G: AGENT MESSAGE SPOOFING
Agent B sends Agent C a message asserting that the administrator
approved a new recipient.
The message is correctly authenticated as coming from Agent B.
However, Agent B lacks authority to issue the claimed administrator
approval.
Agent C proposes a data disclosure.
The actual resource sink verifies current original principal
permission.
The new recipient is not authorized.
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected demonstrable result: Authentication of an intermediary does
not allow that intermediary to impersonate originating authority.
28.54 — WORKED EXAMPLE H: DELEGATION CYCLE
Agent A delegates a task to Agent B.
Agent B attempts to delegate the same effect authority back to Agent
A under a new identifier.
The protected graph controller detects the prohibited authority cycle
or repeated underlying allocation.
It does not treat the additional edge as new effect permission.
Expected demonstrable result: Recursive delegation cannot manufacture
additional resource authority through cyclic references.
28.55 — WORKED EXAMPLE I: VALID MULTI-AGENT DOCUMENT WORKFLOW
An originating principal authorizes creating one report in a
protected workspace.
8.5.3.54. Source page 2371 of the original specification
Agent A delegates information retrieval to Agent B.
Agent B obtains qualified data.
Agent C analyzes the data.
Agent D prepares the report.
A protected file-promotion sink verifies the actual report identity
and destination.
The operation is permitted under current original authority.
Expected demonstrable result: The system supports legitimate nested
agent work without requiring every computational step to possess
external consequential authority.
28.56 — WORKED EXAMPLE J: TOOL CHANGE INSIDE A DELEGATION CHAIN
Agent C invokes a reporting tool.
The tool implementation is updated and now transmits data externally.
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protected tool-effect contract generation changes.
The previous delegation permitted local report generation only.
The new external transmission remains non-effective until current
permission is established.
Expected demonstrable result: A downstream tool change does not
silently enlarge the originating task's consequential scope.
28.57 — WORKED EXAMPLE K: BRANCH BUDGET RACE
An originating principal authorizes a cumulative data export of a
bounded quantity.
Agent A creates several child agents.
Each child attempts to export part of the data concurrently.
The protected controller maintains shared authoritative consumption
or disjoint enforceable allocations.
An operation exceeding the remaining budget is refused.
Expected demonstrable result: Concurrent distributed child agents
cannot validly overspend a shared bounded data-disclosure allowance
under the stated enforcement model.
8.5.3.55. Source page 2372 of the original specification
28.58 — WORKED EXAMPLE L: CHILD AGENT CRASH
Agent B receives authority to publish one document.
The protected sink consumes the authority and sends the publication
request.
Agent B crashes before receiving acknowledgement.
Agent A assigns the task to Agent C.
Agent C does not automatically publish the document again.
The controller first reconciles the previous actual operation.
Expected demonstrable result: Child-agent replacement does not
resurrect uncertain or consumed operation authority.
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.59 — WORKED EXAMPLE M: CROSS-DOMAIN DELEGATION
An enterprise agent delegates one research and document-processing
task to an external qualified worker.
The external worker receives a bounded delegation reference and
authenticated workload identity.
The worker may perform permitted computation.
A request to transmit confidential enterprise information to an
unrelated recipient is independently refused by the protected data-
release sink.
Expected demonstrable result: Cross-domain authentication and valid
task handoff do not create unrestricted external disclosure
authority.
28.60 — WORKED EXAMPLE N: HARDWARE COMMAND CHAIN
An originating controller authorizes one bounded device operation.
Agent A delegates sensor analysis to Agent B.
Agent B delegates command preparation to Agent C.
Agent C constructs a device command.
8.5.3.56. Source page 2373 of the original specification
The protected device sink reconstructs the actual command and
verifies the original authorized device, operating bounds, and
current authority.
The command becomes effective only when those conditions and
protected finality pass.
Expected demonstrable result: Nested computational delegation does
not independently confer unrestricted physical actuation authority.
28.61 — WORKED EXAMPLE O: FALSE PRIOR-EFFECT REPORT
Agent B claims that a required database update was completed.
Agent C proposes a dependent external operation.
The selected workflow requires an accepted qualified actual-effect
receipt under CW-2 Mode B.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Agent B's ordinary success message is not sufficient.
The dependent operation remains withheld.
Expected demonstrable result: An intermediate agent's computational
report cannot replace mandatory evidence of a completed real resource
effect.
28.62 — WORKED EXAMPLE P: VALID AUTHORITY COMPOSITION
An originating principal expressly authorizes a workflow to read
designated data and publish an approved summary into a specified
repository.
Different agents perform data retrieval and formatting.
The protected join policy identifies the explicitly permitted
combination.
The final publication Candidate Act references the source
authorization and current resource identity.
The protected sink verifies the actual summary destination and
operation.
Expected demonstrable result: The architecture permits a valid
explicitly authorized multi-parent or multi-stage operation without
allowing arbitrary permission unions.
28.63 — WORKED EXAMPLE Q: CANCELLATION OF ONE CHILD
Agent A allocates two bounded work portions to Agents B and C.
8.5.3.57. Source page 2374 of the original specification
Agent B completes its portion.
Agent C is cancelled before completion.
The protected controller fences C's future authority.
Any provably unused allocation may be returned under protected rules.
Consumed or uncertain effects are not automatically returned as free
allowance.
Expected demonstrable result: Branch cancellation cannot duplicate
previously spent or potentially spent source authority.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.64 — WORKED EXAMPLE R: SHARED PERSISTENT AGENT MEMORY
Agent A delegates research to Agent B.
Agent B writes selected findings to a shared vector database.
Agent C later reads the shared database and proposes another action.
The first write may itself require protected persistence finality.
The later operation separately requires source-authority
verification.
The fact that data was stored in a trusted shared database does not
automatically make it a new source-authority instruction.
Expected demonstrable result: Information propagation through agent
memory does not independently promote data into consequential
authority.
28.65 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Forged originating grant. 2. Forged parent identity. 3. Forged
child identity. 4. Unauthorized re-delegation. 5. Transitive scope
expansion. 6. Resource-scope inflation. 7. Recipient substitution.
8. Operation-class substitution. 9. Credential-scope inflation. 10.
Agent-message authority laundering. 11. Tool-output instruction
laundering. 12. Prompt-injection propagation through multiple
agents. 13. Delegation graph edge substitution.
8.5.3.58. Source page 2375 of the original specification
14. Graph witness replay. 15. Missing mandatory ancestor
constraint. 16. Stale parent authorization. 17. Ancestor revocation
bypass. 18. Child cancellation bypass. 19. Shared-budget double
spending. 20. Duplicate branch allocation. 21. Concurrent finality
consumption. 22. Cross-branch finality reuse. 23. Uncontrolled
branch fork. 24. Delegation fan-out exhaustion. 25. Excessive
recursion depth. 26. Delegation cycle. 27. Unauthorized multi-
parent scope union. 28. Tool confused deputy. 29. Privileged
credential broker misuse. 30. Intermediate database mutation. 31.
Unauthorized intermediate file write. 32. Intermediate network
disclosure. 33. Hidden application side effect. 34. Changed tool
execution semantics. 35. Valid tool name with replaced executable.
36. Source-resource identity mismatch. 37. Remote resource alias
rebinding. 38. Cross-tenant recipient confusion. 39. Cross-domain
identity trust confusion. 40. Data provenance mistaken for
authority. 41. Valid workload identity mistaken for source
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
permission. 42. Token exchange mistaken for one-time finality. 43.
Historical signature mistaken for current authorization. 44. Model-
generated approval claim. 45. Wrong Candidate Act binding. 46.
Wrong designated Finality Sink. 47. Copied non-bearer reference. 48.
Stale resource generation. 49. Stale revocation generation. 50. In-
flight effect duplicate. 51. Child crash after dispatch. 52. Parent
retry after unknown completion. 53. Consumed budget returned without
qualification. 54. Incomplete actual-effect receipt. 55. False
predecessor completion. 56. Unauthorized causal successor. 57.
Multi-resource atomicity assumption. 58. Uncontrolled alternative
resource path. 59. Monitoring-only component mistaken for a gate.
60. Conflicting protected budget ledgers. 61. Disconnected child
with unbounded authority. 62. Snapshot rollback of delegation state.
63. Child migration restoring obsolete authority.
8.5.3.59. Source page 2376 of the original specification
64. Denial-of-service through graph verification. 65. Revoked child
continuing through cached credentials. 66. Incorrectly combined
source grants. 67. Partial delegation grant reused in another task.
68. Parallel physical command duplication. 69. Unauthorized
cumulative payment. 70. Final resource effect that differs from all
approved intermediate descriptions.
The actual security guarantee depends on the integrity and coverage
of the selected protected source, delegation, budget, and resource
enforcement components.
28.66 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following tests are proposed, non-limiting experiments and are
not represented as completed results.
Test 1 — Root Grant: Establish a protected originating task grant.
Test 2 — Parent Identity: Authenticate the original agent.
Test 3 — Child Identity: Authenticate a delegated agent.
Test 4 — Valid Delegation Edge: Commit a bounded child relationship.
Test 5 — Invalid Parent Scope: Attempt delegation outside parent
authority.
Test 6 — Non-Delegable Authority: Attempt onward delegation when
prohibited.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 7 — Transitive Attenuation: Verify narrowing through three or
more delegation levels.
Test 8 — Resource Attenuation: Restrict a descendant to one resource.
Test 9 — Recipient Attenuation: Restrict a descendant's disclosure
destination.
Test 10 — Operation Attenuation: Permit read but not write.
Test 11 — Data-Only Delegation: Perform analysis without granting
effectuation authority.
Test 12 — Intermediate Candidate Act: Identify a resource effect
during subtask execution.
Test 13 — Intermediate Non-Effective Hold: Prevent premature resource
modification.
Test 14 — Valid Intermediate Effect: Authorize one separately
permitted persistent operation.
Test 15 — Unauthorized Intermediate Effect: Reject an unrelated
mutation.
8.5.3.60. Source page 2377 of the original specification
Test 16 — Tool Invocation: Distinguish tool access from actual
operation authority.
Test 17 — Privileged Tool: Prevent confused-deputy use of broad
permissions.
Test 18 — Credential Broker: Verify delegated actual-request
authority.
Test 19 — Source Root Commitment: Authenticate the original grant
reference.
Test 20 — Chain Witness: Validate the applicable path.
Test 21 — Missing Ancestor: Reject an incomplete mandatory authority
path.
Test 22 — Wrong Parent: Reject a substituted delegation edge.
Test 23 — Replayed Edge: Reject historical but currently invalid
authority.
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 24 — Graph Generation: Verify current chain state.
Test 25 — Parent Revocation: Invalidate affected descendant
authority.
Test 26 — Sibling Isolation: Preserve unrelated authorized branches.
Test 27 — Child Cancellation: Prevent further branch effects.
Test 28 — Branch Fork: Create multiple concurrent children.
Test 29 — Shared Budget: Preserve one root-level allowance.
Test 30 — Budget Double Spend: Attempt concurrent overspending.
Test 31 — Disjoint Reservation: Allocate separate bounded portions.
Test 32 — Budget Return: Return a provably unused reservation.
Test 33 — Uncertain Budget: Refuse automatic return following an
indeterminate operation.
Test 34 — Multi-Parent Join: Combine informational results from
several parents.
Test 35 — Unauthorized Authority Union: Attempt to combine partial
grants into an expanded effect.
Test 36 — Authorized Composition: Permit an expressly authorized
combined operation.
Test 37 — Cycle Detection: Create a cyclic authority chain.
Test 38 — Delegation Depth: Exceed the permitted number of authority-
bearing hops.
Test 39 — Fan-Out: Exceed the protected branch-allocation limit.
8.5.3.61. Source page 2378 of the original specification
Test 40 — Prompt-Injection Laundering: Pass malicious text through
several agents.
Test 41 — False Administrator Claim: Attempt new authority via an
authenticated intermediary message.
Test 42 — Tool-Effect Drift: Change the actual tool's resource
semantics.
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 43 — Tool Contract Generation: Reject stale effect assumptions.
Test 44 — Cross-Domain Agent: Authenticate an external computational
worker.
Test 45 — Cross-Domain Scope: Attenuate external delegated
permission.
Test 46 — Token Exchange: Use delegated tokens while retaining
separate finality.
Test 47 — Actual Sink Reconstruction: Verify the real pending
operation.
Test 48 — Candidate Correspondence: Reject a changed resource or
recipient.
Test 49 — Sink-Local Consumption: Consume one finality allowance.
Test 50 — Reference Replay: Reject a copied finality reference.
Test 51 — Resource Version Change: Revalidate current actual resource
state.
Test 52 — Ancestor Revocation Race: Revoke source permission between
validation and effectuation.
Test 53 — Child Crash Before Dispatch: Preserve unused authority
according to protected state.
Test 54 — Child Crash After Dispatch: Reconcile uncertain actual
effect.
Test 55 — Parent Retry: Prevent duplicate consequential resource
mutation.
Test 56 — Cross-Branch Migration: Move a branch without recreating
consumed authority.
Test 57 — Credential Revocation: Invalidate affected credential-
dependent finality.
Test 58 — Hardware Actuation: Verify the actual delegated command.
Test 59 — Shared Persistent Memory: Treat intermediate writes as
separate consequences.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 60 — Actual-Effect Receipt: Obtain a qualified resource-
completion receipt.
Test 61 — False Receipt: Reject an unqualified child-agent success
message.
Test 62 — CW-2 Successor: Require the specified accepted prior-effect
evidence.
8.5.3.62. Source page 2379 of the original specification
Test 63 — CW-3 Scope Deviation: Require new original source authority
for an expanded effect.
Test 64 — Removal of Protected Root: Evaluate erroneous authority
inflation.
Test 65 — Removal of Chain Validation: Attempt effects through an
unauthorized intermediary.
Test 66 — Removal of Shared Budget: Compare duplicated effects after
branching.
Test 67 — Removal of Intermediate Finality: Identify unauthorized
side effects hidden inside a permitted workflow.
Test 68 — Removal of Actual Sink Verification: Attempt resource
substitution after earlier approval.
Test 69 — Removal of Protected Consumption: Attempt repeated use
through separate agents.
Test 70 — Removal of Revocation Checks: Attempt descendant
effectuation after parent revocation.
Test 71 — Large Graph: Verify bounded processing of many delegation
edges.
Test 72 — Concurrent Graph Mutation: Change a delegation while a
Candidate Act is pending.
Test 73 — Mixed-Authority Join: Combine several source grants under
an expressly defined composition rule.
Test 74 — Multi-Resource Workflow: Perform separate qualified
intermediate and terminal effects.
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 75 — Full Integrated Workflow: Execute original grant, nested
delegation, branch allocation, intermediate effect classification,
current chain validation, non-bearer finality, actual sink
enforcement, and protected outcome reconciliation.
28.66.1 — Proposed Measurements
The tests may measure:
Unauthorized completed resource effects;
Successful rejection of authority inflation;
Transitive scope correctness;
Delegation-chain verification accuracy;
Duplicate use across branches;
8.5.3.63. Source page 2380 of the original specification
Shared-budget conservation;
Revocation latency and correctness;
Unauthorized intermediate side effects;
Resource-effect correspondence;
Crash recovery correctness;
And computational overhead.
28.66.2 — Comparative Ablation
A useful comparison comprises:
Configuration A — Ordinary Agent Chaining: Agents exchange
authenticated tasks and invoke available tools.
Configuration B — Agent Chaining with Delegated Access Control: Each
agent receives bounded credentials or permissions.
Configuration C — Protected Delegation-Graph Finality: Current
original source authority, transitive attenuation, branch-conserved
consumption, intermediate Candidate Act isolation, and actual
Finality-Sink reconstruction are jointly enforced.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The tests may determine whether a permitted multi-agent workflow can
still produce unauthorized or duplicated resource effects through
intermediate or parallel branches.
28.66.3 — Qualification of Results
A model generating an unauthorized request is not itself proof of an
unauthorized completed resource effect.
Conversely, a model refusing a malicious request does not prove the
existence of protected resource-side enforcement.
The experiment should inspect actual protected resource state and
authoritative consumption evidence.
28.67 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
28.67.1 — Minimum Components
A PHOSITA may implement a reference prototype using:
Three or more agent processes;
8.5.3.64. Source page 2381 of the original specification
An authenticated parent-to-child communication service;
A protected delegation graph database;
A protected source-authority registry;
A transactional shared budget ledger;
A protected operation gateway;
And a receiving test-resource API.
28.67.2 — Original Task
The originating principal authorizes one bounded database mutation.
28.67.3 — Agent A
Agent A coordinates the task.
28.67.4 — Agent B
Agent B analyzes the resource and proposes a mutation.
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.67.5 — Agent C
Agent C independently analyzes the same resource and proposes another
mutation.
28.67.6 — Protected Delegation
Both child agents receive authenticated bounded scope.
28.67.7 — Shared Budget
The original source grant permits one qualifying consequential
mutation.
28.67.8 — Candidate Acts
Each child constructs an operation proposal.
28.67.9 — Protected Validation
The gateway verifies the originating root, applicable delegation
path, actual resource identity, and shared use count.
28.67.10 — Sink Enforcement
The receiving resource accepts only a permitted operation under the
protected current consumption state.
8.5.3.65. Source page 2382 of the original specification
28.67.11 — Adversarial Branch
The losing branch attempts a second mutation.
28.67.12 — Expected Result
The additional unauthorized effect is refused.
28.67.13 — Scope Inflation
A child requests mutation of an unrelated resource.
28.67.14 — Expected Result
The actual sink refuses the operation even if the child has a valid
communication credential.
28.67.15 — Ancestor Revocation
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The original grant is revoked before another operation.
28.67.16 — Expected Result
Affected descendant operations cannot validly acquire new finality.
28.67.17 — Failure Injection
A child crashes following dispatch but before acknowledgement.
28.67.18 — Expected Result
The protected journal preserves the unresolved result and does not
automatically reallocate the possibly consumed authority.
28.67.19 — Technical Qualification
The reference prototype demonstrates the selected shared-authority
and actual-resource guarantees only for the resource and effectuation
paths controlled by its protected sinks.
28.68 — OPTIONAL ADVANCED VARIATIONS
28.68.1 — Linear Delegation Chain
An agent delegates through a single sequence of children.
28.68.2 — Delegation Tree
A parent creates multiple independent child branches.
8.5.3.66. Source page 2383 of the original specification
28.68.3 — Directed Acyclic Workflow
Several agents exchange information across a graph with protected
authority composition.
28.68.4 — Multi-Parent Join
A downstream effect is permitted only under a qualified authority-
composition rule.
28.68.5 — Pure Computational Delegation
Child agents receive processing tasks without consequential
permissions.
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.68.6 — Bounded Consequential Delegation
A child receives operation-specific resource authority.
28.68.7 — Non-Re-Delegable Authority
A child may exercise but not transfer a designated permission.
28.68.8 — Depth-Limited Delegation
The controller restricts transitive authority-bearing hops.
28.68.9 — Fan-Out-Limited Delegation
The controller restricts concurrent child allocations.
28.68.10 — Shared Budget
Several branches consume one protected ancestor allowance.
28.68.11 — Disjoint Branch Allocations
The original budget is divided into protected portions.
28.68.12 — Intermediate Effect Finality
Each protected real side effect receives separate Candidate Act
validation.
28.68.13 — Credentialed Agent Tool
A broker exercises a reusable credential only for a verified
delegated operation.
28.68.14 — Cross-Domain Agent
A child operates in a different administrative environment under
attenuated scope.
28.68.15 — Protected Information Provenance
8.5.3.67. Source page 2384 of the original specification
Derived data remains distinct from execution authority.
28.68.16 — Tool-Version Continuity
A changed downstream tool requires current effect qualification.
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.68.17 — Delegation Revocation Graph
Revocation invalidates affected descendants.
28.68.18 — Branch Recovery
A child may be replaced without recreating consumed resource
authority.
28.68.19 — Hardware Command Chain
Nested agents prepare operations controlled by an actual device-side
Finality Sink.
28.68.20 — Causal Receipt Continuation
A downstream operation may depend upon qualified evidence of a
specified earlier real effect.
These variations may be used individually where technically
sufficient or in compatible subcombinations.
28.69 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
28.69.1 — Established Foundations
Existing systems provide multi-agent messaging, hierarchical
delegation, token exchange, workload identity, conditional access
policies, distributed workflow graphs, budget counters, and resource
gateways.
The present embodiment may use those technologies.
28.69.2 — Candidate Objective Technical Problem
How to distribute autonomous computational work and limited resource
permissions across nested and branching agent/tool invocation graphs
without allowing intermediary agents to enlarge the original source-
authorized consequential scope, multiply a shared effect allowance,
or conceal unauthorized intermediate effects from actual resource-
side enforcement.
28.69.3 — Proposed Technical Solution
A protected originating authority root is established independently
of agent messages.
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.5.3.68. Source page 2385 of the original specification
Delegation edges are authenticated and bound to current permitted
scope.
Effective downstream authority is derived through protected
transitive attenuation.
Parallel branches remain constrained by shared protected effect
accounting.
Each covered intermediate or terminal consequence becomes a non-
effective Candidate Act.
A protected validator independently verifies current original and
delegated permission.
Scoped non-bearer finality is constituted for the specific real
operation.
The actual Finality Sink reconstructs the pending consequence and
verifies current source, delegation, resource, budget, and
consumption conditions before release.
28.69.4 — Not Merely Agent Orchestration
A task orchestration engine may distribute work.
The proposed stronger implementation separately controls the actual
consequences of that work.
28.69.5 — Not Merely Delegated Credentials
A delegated token may permit access to a downstream service.
The selected stronger combination separately enforces the specific
current Candidate Act and its actual resource effect.
28.69.6 — Not Merely a Delegation Graph
A graph may document a chain of computational relationships.
The proposed architecture requires the protected relationship to
govern current finality at the resource boundary.
28.69.7 — Not Merely Hierarchical Permissions
Hierarchical access control may restrict child privileges.
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The proposed arrangement additionally prevents branch multiplication
of shared operation-specific authority and independently verifies
intermediate effects.
28.69.8 — Not Merely Shared Budget Accounting
A shared counter can restrict some cumulative consumption.
The proposed combination relates the counter to an authenticated
originating grant, qualified delegation path, actual operation, and
protected Finality-Sink consumption.
8.5.3.69. Source page 2386 of the original specification
28.69.9 — Not Merely an Agent Approval
An intermediate agent may approve a proposed action.
The resource sink still checks current original source authority and
applicable finality conditions.
28.69.10 — Candidate Narrow Inventive Kernel
A protected multi-agent execution-finality system in which a
consequential Candidate Act produced through a nested or branching
delegation graph is associated with a protected originating source-
authority root and authenticated transitive delegation constraints, a
protected controller derives the current effective operation scope
and conserves applicable shared ancestor effect allowances across
concurrent descendants, and an independent actual Finality Sink
reconstructs the pending consequential operation and permits
effectuation only after verifying source-to-leaf authority
correspondence, current resource scope, applicable non-bearer
finality, and sink-local protected consumption.
28.69.11 — Intermediate Effect Kernel
A narrower candidate may require independent Candidate Act and
Finality-Sink enforcement for each consequential intermediate tool
operation, rather than restricting verification to the nominal final
workflow output.
28.69.12 — Branch Conservation Kernel
Another candidate may require shared ancestor authority to be
atomically allocated or consumed across parallel agents, binding the
actual resource effect to a common protected logical operation
identity.
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
28.69.13 — Multi-Parent Join Kernel
Another candidate may prevent unauthorized union of separate partial
grants while permitting expressly authorized combined effects.
28.69.14 — Revocation Graph Kernel
Another candidate may require current ancestor revocation
dependencies to invalidate affected descendant finality at actual
sinks.
28.69.15 — Cross-Domain Credential Kernel
Another candidate may permit nested cross-domain agent execution
through protected credential brokers without transferring
unrestricted reusable authority.
28.69.16 — Causal Chain Kernel
8.5.3.70. Source page 2387 of the original specification
Another candidate may combine current delegation authority with IEV-
accepted evidence of a particular completed predecessor effect before
an independently authorized successor effect.
28.69.17 — Hindsight and Functional-Combination Analysis
A later inventive-step response should identify the closest actual
prior-art combination.
It would be insufficient to argue that agent delegation, token
attenuation, shared resource counters, or finality-like authorization
are individually unknown.
The more significant technical comparison concerns whether the
earlier system already establishes the complete operation-specific
dependency among:
The original consequential authority root;
Current authenticated transitive delegation;
Branch-conserved shared authority;
Protected isolation of intermediate actual effects;
Independent validation of the actual resource operation;
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Separate scoped non-bearer finality;
And mandatory sink-local current authority consumption.
A useful comparison may demonstrate that an agent chain can produce a
valid authenticated tool request that is nevertheless unauthorized by
the originating task, and that the protected sink rejects the
resulting real effect.
Another may demonstrate that two independently authenticated children
cannot both consume the same single-use original authority.
The proposed combination should be evaluated against the actual
teachings, technical motivations, and reasonable expectations of the
relevant prior art.
A collection of known components does not become inventive merely
because the specification labels the combination non-obvious or
identifies a hindsight concern.
The relevant claim should establish a specific technical interaction
and a supportable technical effect.
28.70 — INDUSTRIAL APPLICABILITY
28.70.1 — Enterprise Multi-Agent Platforms
8.5.3.71. Source page 2388 of the original specification
Several agents may collaborate without uncontrolled consequential
authority propagation.
28.70.2 — Cloud Infrastructure Management
Delegated agents may perform bounded protected infrastructure
operations.
28.70.3 — Financial Transactions
Shared payment authority may be conserved across parallel agents.
28.70.4 — Electronic Commerce
Research, selection, purchasing, and fulfillment functions may remain
separately authorized.
28.70.5 — Database Administration
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Intermediate and terminal database mutations may be independently
controlled.
28.70.6 — Software Development
Nested coding agents may generate artifacts without independently
obtaining production deployment authority.
28.70.7 — Data Protection
Information retrieval may be separated from permission to disclose
the information.
28.70.8 — Persistent AI Memory
Shared-memory commits may remain subject to independent resource
finality.
28.70.9 — Network Operations
Agent-generated configuration commands may remain bounded by
originating source permission.
28.70.10 — Telecommunications
Autonomous network control workflows may use multi-agent processing
without unrestricted command delegation.
28.70.11 — Device Management
Device-control permissions may remain bounded across nested remote
services.
28.70.12 — Industrial Automation
Distributed computational controllers may prepare operations subject
to actual resource-side enforcement.
8.5.3.72. Source page 2389 of the original specification
28.70.13 — Robotics
Perception, planning, and actuation agents may operate with distinct
authority roles.
28.70.14 — Autonomous Transportation
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Multiple planning components may not independently create physical
command authority.
28.70.15 — Edge Computing
Delegated edge agents may exercise only bounded protected local
authority.
28.70.16 — Cross-Domain Service Composition
Service-to-service delegation may remain tied to source-authorized
actual effects.
28.70.17 — Confidential Computing
Qualified protected domains may validate delegation-chain evidence
and resource finality.
28.70.18 — Payment and API Gateways
Operation-bound credential use may be enforced across nested
orchestration.
28.70.19 — Autonomous Critical Systems
Multi-agent computation may remain separate from authority to produce
safety-relevant effects.
28.70.20 — Future Distributed AI Infrastructure
Dynamic agent ecosystems may preserve bounded original authority and
resource-side finality as delegation graphs evolve.
28.71 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
28.71.1 — Candidate Independent System Claim
A system comprising:
A protected source-authority controller configured to maintain an
authenticated originating consequential authority root;
A delegation-graph controller configured to establish authenticated
authority-bearing relationships among a plurality of computational
agents or tool services;
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An attenuation controller configured to determine current effective
permission for a downstream operation by applying the originating and
relevant intermediate constraints;
8.5.3.73. Source page 2390 of the original specification
A protected branch-accounting controller configured to prevent
concurrent descendants from exceeding a shared source-authorized
consequential allowance;
A Candidate Act controller configured to hold a consequential
intermediate or terminal operation in a Non-Effective State;
An independent validator configured to establish current source,
delegation, and actual-effect correspondence;
A finality controller configured to establish scoped non-bearer
finality enablement;
And an actual resource Finality Sink configured to reconstruct the
pending operation and permit effectuation only upon verification of
current originating and delegated authority, actual resource scope,
applicable shared consumption, and protected sink-local finality
state.
28.71.2 — Candidate Independent Method Claim
A method comprising:
Establishing an originating source-authorized consequential effect
envelope;
Creating one or more authenticated downstream delegation
relationships;
Deriving effective downstream authority through protected
attenuation;
Maintaining shared consequential allowances across concurrently
executing branches;
Identifying a covered consequential operation initiated at an
intermediate or terminal workflow stage;
Constructing a non-effective Candidate Act;
Independently validating its current originating and delegated
permission;
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Establishing scoped non-bearer finality;
Reconstructing the actual pending operation at a designated resource
sink;
And permitting the consequence only after protected resource,
authority, budget, and consumption predicates are satisfied.
28.71.3 — Candidate Independent Branch-Conservation Claim
A protected multi-agent authority controller configured to allocate
or consume one originating consequential allowance across several
parallel delegated agents such that distinct authenticated branches
cannot multiply the valid resource effects authorized by the shared
source grant.
28.71.4 — Candidate Independent Intermediate-Effect Claim
8.5.3.74. Source page 2391 of the original specification
A system configured to identify consequential operations within
nested agent tool-invocation chains and to hold each covered
intermediate actual effect non-effective until independently
authorized at its corresponding resource Finality Sink, irrespective
of authorization of the workflow's nominal final result.
28.71.5 — Candidate Independent Authority-Join Claim
A protected multi-parent agent controller configured to prevent
unauthorized combination of separate delegated scopes into enlarged
consequential authority and to permit a combined effect only under a
qualified originating authorization or protected scope-composition
rule.
28.72 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The originating principal is represented by a protected authority
root. 2. The authority root identifies permitted actual resource
effects. 3. The authority root identifies permitted recipients. 4.
The authority root identifies cumulative resource budgets. 5. The
authority root identifies permitted delegation depth. 6. The
authority root identifies permitted execution domains. 7. A first
agent delegates work to a second agent. 8. A second agent delegates
work to a third agent. 9. A downstream agent invokes a tool service.
10. A tool service invokes a further protected resource service. 11.
An authenticated delegation edge identifies parent and child
identities. 12. A delegation edge identifies its originating
authority reference. 13. A delegation edge identifies current
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
authority generations. 14. A delegation edge identifies permitted
resource scope. 15. A delegation edge identifies permitted operation
classes. 16. A delegation edge identifies permissible re-delegation.
17. A child delegation is limited by its parent's effective scope.
18. A child may receive computational work without consequential
execution authority. 19. A delegation chain witness identifies the
applicable ancestor restrictions. 20. A chain witness is
authenticated by a protected authority component. 21. An
intermediate agent cannot fabricate original source authority merely
by generating
an authenticated message. 22. Effective delegated authority is
derived through current protected constraints. 23. A delegation
graph may comprise a linear chain. 24. A delegation graph may
comprise a tree. 25. A delegation graph may comprise a directed
acyclic graph. 26. The system may control prohibited authority-
bearing cycles. 27. The system may enforce a delegation depth limit.
28. The system may enforce a delegation fan-out limit. 29. A parent
may create multiple computational child branches. 30. A parent may
reserve disjoint protected effect allocations for children. 31. A
shared ancestor effect allowance may be consumed from one
authoritative ledger. 32. A shared allowance is not multiplied by
adding child agents. 33. A concurrent branch may be refused after
the shared allowance is exhausted.
8.5.3.75. Source page 2392 of the original specification
34. An unused branch allocation may be returned through an
authorized protected
transition. 35. An allocation associated with an uncertain prior
effect is not automatically returned. 36. A downstream multi-parent
operation requires a protected authority-composition rule. 37.
Independent partial grants do not automatically form unrestricted
union authority. 38. A protected original source grant may expressly
authorize a selected combined effect. 39. A tool invocation is
classified according to actual consequential semantics. 40. A
permitted computational tool call need not receive separate external
effect
authority. 41. A consequential intermediate tool operation is
represented as a Candidate Act. 42. The intermediate Candidate Act
remains non-effective pending authorization. 43. A final workflow
operation may comprise a distinct Candidate Act. 44. A valid final
outcome does not automatically authorize earlier unauthorized
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
intermediate effects. 45. Lower-trust tool output may contribute
data without creating permission. 46. Data provenance and authority
provenance are maintained as distinct properties. 47. An agent-
authenticated message does not independently establish current
originating
authorization. 48. A protected credential broker verifies actual
operation-specific delegated scope. 49. A child agent may use a
protected service without receiving reusable complete
credential authority. 50. Current source-authority revocation may
invalidate affected descendant finality. 51. A revoked mandatory
parent delegation invalidates affected child permission. 52. An
unrelated valid sibling may remain eligible. 53. A cancelled child
branch is fenced from further protected effects. 54. A historical
delegation record does not override current protected revocation. 55.
A protected validation instance resolves the current effective
delegation scope. 56. A protected collection-time instance may
commit selected chain evidence. 57. An independent execution-time
instance may verify the actual operation. 58. Protected evidence may
cross-commit the chain and Candidate Act. 59. Scoped non-bearer
finality is bound to a designated actual resource sink. 60. The
finality enablement identifies the permitted actual effect. 61. The
finality enablement identifies applicable delegation authority. 62.
The finality enablement identifies shared consumption or allocation
state. 63. An opaque finality reference is not independently
transferable as unrestricted bearer
authority. 64. The actual resource sink reconstructs the pending
operation. 65. The sink verifies actual resource identity. 66. The
sink verifies actual recipient or destination. 67. The sink verifies
material operation parameters. 68. The sink verifies current
originating source authority. 69. The sink verifies mandatory
current delegation constraints. 70. The sink verifies relevant
current revocation generations. 71. The sink verifies applicable
shared ancestor budgets. 72. The sink verifies protected finality
consumption. 73. A copied reference cannot authorize another
incompatible operation. 74. A child-agent crash does not
automatically restore consumed finality. 75. A previously dispatched
effect may require qualified resource-side reconciliation. 76. A
specified CW-2 successor may require an IEV-accepted prior-effect
receipt. 77. A scope expansion under CW-3 may require a new
qualified source grant.
8.5.3.76. Source page 2393 of the original specification
78. Cross-domain agent delegation may use authenticated service
identities and bounded
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
exchanged credentials. 79. Hardware, database, network, file,
payment, credential, and persistent-memory sinks
may enforce the disclosed delegated actual-effect finality. 80.
Existing agent protocols, authorization standards, cryptographic
services, distributed
ledgers, and protected resource gateways may be used as optional
implementation substrates.
28.73 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The present embodiment may be implemented using compatible
combinations of the disclosed delegation, source-authority, budget,
and effectuation mechanisms.
An implementation may use a linear agent chain.
Another may use a hierarchy.
Another may use a dynamically created graph.
Another may employ several independent computational branches.
Another may implement multi-parent informational aggregation.
Another may employ expressly authorized multi-parent effect
composition.
Another may restrict all downstream agents to internal computation.
Another may allocate selected bounded consequential authority.
Another may use an authenticated delegation token.
Another may use a protected authorization registry.
Another may use a cryptographic chain witness.
Another may use bounded credential exchange.
Another may use a privileged credential broker.
Another may use protected branch-budget reservation.
Another may use an authoritative shared use-count ledger.
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Another may use disjoint preallocated resource allowances.
Another may use independent intermediate Candidate Acts.
8.5.3.77. Source page 2394 of the original specification
Another may use a protected resource Finality Sink at each relevant
consequential stage.
Another may use a qualified resource-effect receipt for later causal
continuation.
Another may incorporate delegation migration or recovery.
Another may use a hardware command gate.
Another may employ protected revocation dependencies.
The invention does not require all agents to operate under one
software vendor, machine, cloud, administrative domain, or
communication protocol.
The invention does not require every agent message to carry the
complete original source grant.
Protected authenticated references may be used where an independent
authority can resolve the relevant constraints.
The invention does not require all computational handoffs to convey
effectuation authority.
The invention does not require all child agents to possess reusable
credentials.
The invention does not require every ordinary internal calculation to
pass through a consequential Finality Sink.
The invention does not require a linear chain where protected
branching or graph-based delegation is applicable.
The invention does not require every graph to use one specific
cryptographic encoding.
The invention does not permit authority-bearing graph cycles, joins,
or branch allocations to create additional consequential scope
without valid originating authorization.
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where the actual effect is governed by a shared budget, the
implementation must possess sufficient authoritative coordination or
enforceable allocation to maintain the stated consumption guarantee.
Where a consequential operation crosses several independent resource
domains, the claimed guarantees are limited by the actual enforcement
and qualified outcome mechanisms implemented at those domains.
Where an intermediate operation is a real consequential effect,
authorization of a later final result does not retroactively supply
the missing authority for that intermediate effect.
Where a child or parent fails, the protected system preserves already
consumed and indeterminate effect states.
The algorithms, diagrams, data structures, experiments, state
machines, and examples are illustrative and non-limiting aids for a
person having ordinary skill in the art.
8.5.3.78. Source page 2395 of the original specification
Compatible features from other embodiments may be combined without
making every optional feature universally mandatory.
28.74 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 28 discloses a protected execution-finality
architecture for autonomous systems in which computation and tool
operations may be delegated through multiple agents, branches,
services, and administrative domains.
A protected originating authority root defines the permitted
consequential effects.
A delegation controller maintains authenticated relationships among
participating computational components.
Each authority-bearing delegation is restricted to a permissible
effective scope.
The protected system distinguishes computational task handoff from
consequential permission transfer.
Where a workflow branches into several agents, original shared effect
allowances remain conserved through protected accounting.
Where information from multiple parents is joined, corresponding
permissions are not automatically combined into broader authority.
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where a tool invocation produces a consequential intermediate effect,
that effect is represented as a separately controlled Candidate Act.
The operation remains non-effective until the required source and
delegation conditions pass.
A protected validator resolves current effective authority,
applicable budgets, resource scope, and mandatory revocation
dependencies.
A scoped non-bearer finality enablement is established.
The actual Finality Sink independently reconstructs the pending
consequential operation.
The sink verifies the current originating grant, applicable
delegation path, actual resource identity, permitted operation,
shared allowance, and protected sink-local consumption.
Only after successful verification may the covered effect become
effective.
An authenticated agent message does not automatically create original
source authority.
A child may perform authorized computation without receiving
unrestricted consequential permission.
8.5.3.79. Source page 2396 of the original specification
A privileged tool may exercise its technical capability only for an
independently authorized actual operation.
A task branch cannot multiply the originating source allowance merely
by creating additional agents.
Historical delegation evidence cannot override current revocation.
An agent failure or migration cannot automatically restore already
consumed actual-effect authority.
The principal candidate inventive technical concept of Embodiment 28
is a protected autonomous multi-agent execution-finality system in
which transitive source-authority restrictions remain independently
verifiable through nested and branching delegation relationships,
shared consequential allowances are conserved across concurrent
descendants, intermediate resource effects are held as non-effective
Candidate Acts, and actual Finality Sinks reconstruct and
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
independently verify the pending real operation against current
originating, delegated, resource, and consumption state before
effectuation.
28.75 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may use the following established technologies as optional
components.
Existing technology Optional implementation role Agent-to-agent
communication protocols
Exchange tasks, messages, results, and qualified agent identity
information OAuth 2.0 Token Exchange, RFC 8693
Support bounded service-to-service delegation and selected actor
relationships Rich Authorization Requests, RFC 9396 Express fine-
grained resource and operation permissions
SPIFFE-compatible workload identities Authenticate qualified agent
and service workloads
Mutual TLS and authenticated IPC Protect agent, broker, and resource
communication
Cryptographic signatures and authenticated records Bind delegation
edges and current authority references
Policy decision engines Evaluate typed source and transitive
delegation constraints
Transactional SQL databases Maintain current graph generations,
shared budget allocations, finality, and protected consumption
Distributed coordination services Coordinate current branch
allocations and ownership
where required Typed JSON or CBOR representations
Encode source grants, delegation paths, and actual-effect descriptors
8.5.3.80. Source page 2397 of the original specification
Protected credential brokers Exercise reusable secrets only for
current authorized downstream operations API, database, file,
payment, or device gateways
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Enforce actual resource-operation authority at the consequential
boundary
Durable operation journals Preserve consumed, completed, and
unresolved effects across agent failure Qualified resource
transaction identifiers Support selected same-logical-operation
reconciliation
28.75.1 — Practical Common Implementation Workflow
A practical implementation may proceed as follows:
1. Use a protected authorization database to record the original
principal's permitted
resources, consequential operations, and cumulative limits. 2. Use
authenticated agent identities to establish parent and child
relationships. The
agent communication protocol carries task information; a separate
protected authority service determines any consequential permission.
3. Use a typed delegation record to identify the child, parent,
source root, permitted
tool scope, resource restrictions, and current delegation generation.
4. Use an authorization-policy engine to check that each child
receives no greater
relevant effect authority than the applicable parent and originating
grant. 5. Use a transactional shared ledger to reserve or account
for any common financial,
disclosure, storage, operation-count, or other resource allowance
across concurrent branches. 6. Use an agent tool gateway to identify
each consequential intermediate or terminal
operation and prevent direct unverified release. 7. Construct a
Candidate Act with the actual operation class, target resource,
material
parameters, originating source root, and protected delegation-chain
reference. 8. Independently validate the current chain and
applicable resource state. 9. Constitute scoped non-bearer finality
in a protected service, rather than treating a
child message or portable token as sufficient authority. 10. Use the
actual resource gateway or Finality Sink to reconstruct the pending
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
operation and verify current authority, budget, resource, and
consumption state before executing it. 11. Record the actual
supported result and preserve consumption or indeterminate
status across child-agent failure, retry, cancellation, or migration.
28.75.2 — Principal Implementation Relationship
Originating authority root → authenticated delegation graph →
transitive scope attenuation → protected branch allocation → child
computational processing → intermediate or terminal Candidate Act →
non-effective hold → independent current chain validation → scoped
non-bearer finality → actual resource Finality Sink → current source,
delegation, resource, and shared-budget verification → protected
consumption → controlled consequential effect.
The established technologies provide the communication, identity,
authorization, storage, and gateway substrates.
8.6. Embodiment 29: Independent Evaluation Quorums and Conflict-Aware
Approval Finality
Original specification global pages 2398-2479 (inclusive). Source
file: TECHNICAL SPECIFICATION -2012-2566.pdf. The original text
distinguishes candidate inventive features, optional variations and
proposed independent/dependent claims; this document does not convert
every alternative into a mandatory protocol condition.
8.6.1. Protected Components and Trust-Relationship Architecture Diagram
[Agent requests consequential operation]
|
[Independent protected evaluation coordinator]
| | |
[Policy eval] [Resource eval] [Human eval]
+------------+-------------+
[Identity / roles / independence]
|
[Conflict and veto resolver]
|
[Operation-bound qualified certificate]
|
[Source + resource execution-time check]
|
[Finality Sink protected consumption]
Figure 23: Embodiment 29: Independent Evaluation Quorums and
Conflict-Aware Approval Finality — source-based architecture
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.2. Actual-Operation, Decision and Fail-Closed Flowchart
[Agent proposes exact Candidate Act]
|
<Evaluator membership current?>--NO-->[REFUSE]
|YES
[Gather signed, role-qualified decisions]
|
<Independence and separation satisfied?>--NO-->[REFUSE]
|YES
<Threshold and veto/conflict rules pass?>--NO-->[REFUSE]
|YES
[Verify current source/resource conditions]
|
<Sink reconstructs identical actual act?>--NO-->[REFUSE]
|YES
[Consume finality and effect]
Figure 24: Embodiment 29: Independent Evaluation Quorums and
Conflict-Aware Approval Finality — technical flowchart
8.6.3. Original Global Page-Indexed Technical Description
8.6.3.1. Source page 2398 of the original specification
The proposed distinguishing technical relationship is the mandatory
conservation and verification of original consequential authority
across dynamic multi-agent delegation paths, including protected
shared consumption and independent actual-effect finality at
intermediate and terminal resource boundaries.
END OF EMBODIMENT 28 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 29
PROTECTED AUTONOMOUS MULTI-AGENT CONSENSUS AND APPROVAL FINALITY WITH
INDEPENDENT DECISION QUORUMS, CONFLICT-AWARE AUTHORITY RESOLUTION,
AND NON-SUBSTITUTABLE ACTUAL-EFFECT ENFORCEMENT
29.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Systems, Methods, and Apparatus for Governing Consequential
Autonomous Operations Using Protected Originating Authority,
Operation-Specific Independent Evaluation Quorums, Authenticated
Evaluator Eligibility and Separation-of-Duties Evidence, Canonical
Candidate Act Approval Commitments, Conflict-Aware Consensus and Veto
Resolution, Protected Quorum Membership Generations, Independent
Execution-Time Source and Resource Validation, Scoped Non-Bearer
Finality Enablement, and Finality-Sink Reconstruction and Consumption
of Actual Consequential Effects
29.0.1 — General Technical Description
The present Embodiment 29 discloses systems, methods, apparatus,
protected computing components, autonomous decision-evaluation
services, cryptographic approval interfaces, independent
computational evaluators, quorum-management controllers, conflict-
detection mechanisms, authorization-policy engines, protected
resource validators, and independent Finality Sinks for governing
consequential operations proposed by autonomous computational
systems.
An autonomous system may involve several computational decision-
making entities.
Such entities may comprise:
Artificial-intelligence agents; Language-model-based evaluators;
Multimodal reasoning systems; Independent policy evaluators;
Deterministic verification engines; Protected supervisory
controllers; Specialized resource validators; Credential
authorization services; Human approval interfaces; Privileged
hardware controllers; Distributed administrative services; Or
combinations of these components.
8.6.3.2. Source page 2399 of the original specification
A computational entity may propose an operation capable of producing
a real, persistent, external, privileged, financial, informational,
physical, or otherwise consequential effect.
For example, an autonomous system may propose:
A financial transfer;
A production software deployment;
A database mutation;
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A confidential data export;
A network configuration change;
A protected credential operation;
A persistent shared-memory modification;
A cloud infrastructure change;
A hardware command;
Or another operation affecting a protected resource.
A system may seek agreement among multiple evaluators before
permitting the proposed operation.
Such agreement may be represented through votes, approvals, digital
signatures, threshold cryptographic operations, authenticated
decision records, policy results, quorum certificates, or other
validation outputs.
Multiple computational agents may each classify an operation as safe
or acceptable.
A distributed consensus mechanism may establish that an authorized
set of participants agreed upon a particular data record.
A threshold signature may establish that a configured threshold of
cryptographic participants contributed to producing a signature.
A human operator may approve a displayed action.
However, none of these events, considered in isolation, necessarily
proves that the actual consequential resource operation is within the
originating principal's current authority.
Several agents may agree upon an unauthorized operation.
Several agents may receive the same misleading input.
8.6.3.3. Source page 2400 of the original specification
Several separately instantiated agents may depend upon one common
compromised model, tool, policy service, or data source.
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A threshold signature may authenticate a specific message while
leaving the authority of the signers, the meaning of the message, or
the actual subsequent resource operation unresolved.
A quorum may approve one operation while the executing agent later
changes the recipient, amount, target, method, resource, or other
material parameter.
Two committees may approve conflicting operations concerning the same
resource generation.
A committee may change membership after an approval has been
prepared.
A revoked member may retain earlier cryptographic key material.
A quorum may vote using stale resource-state evidence.
A computational system may construct several proposals and
selectively present different proposals to different evaluators.
A privileged broker may possess technical permission to perform a
resource operation that the originating principal never authorized.
A genuine human approval may apply to a displayed operation that
differs materially from the operation ultimately presented to the
resource.
An agent may treat a majority recommendation as authorization to
override a mandatory security restriction.
The present embodiment addresses these conditions by separating
collective evaluation, protected source authority, mandatory
technical predicates, and actual consequential finality.
A protected originating authority controller maintains the source-
authorized consequential effect envelope.
A protected Candidate Act controller constructs a material operation
descriptor and maintains the requested effect in a Non-Effective
State.
A protected quorum-policy controller determines whether collective
evaluation is required and, if so, which qualified evaluator
identities, roles, independence constraints, and approval thresholds
apply.
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The relevant evaluators receive a canonical or otherwise
unambiguously identified Candidate Act and qualified contextual
evidence.
Each evaluator produces a protected result bound to the particular
Candidate Act, applicable evidence, policy generation, and evaluator
identity.
8.6.3.4. Source page 2401 of the original specification
A protected quorum resolver determines whether the applicable
consensus conditions are satisfied.
A further conflict-aware authority controller detects incompatible
approval states, material disagreements, stale decisions, conflicting
operation candidates, mandatory vetoes, and changes in protected
quorum or resource state.
Collective approval is treated as a qualifying predicate for finality
only where required by the original protected policy.
The existence of a sufficient quorum does not independently create an
otherwise absent source authorization.
An independent execution-time validator checks the current
originating authority, operation scope, actual resource, mandatory
security conditions, and relevant quorum evidence.
A protected finality controller may then constitute scoped non-bearer
enablement.
At the actual resource boundary, the Finality Sink obtains or
reconstructs the pending consequential operation.
The sink verifies correspondence to the protected Candidate Act and
current authority, applicable quorum-policy generation, qualifying
decision evidence, mandatory veto state, resource conditions, and
protected sink-local consumption.
Only after the necessary independent predicates have been satisfied
may the actual effect become effective.
29.0.2 — Fundamental Technical Principle
Consensus about an action is not authority to perform that action.
More specifically:
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A majority recommendation does not override the originating source-
authority envelope.
An agreement among artificial-intelligence agents does not
automatically establish that their information is correct.
An authenticated vote does not necessarily constitute valid
authorization.
A threshold signature does not automatically establish approval of
every downstream operation that might be associated with the signed
message.
A quorum certificate for one Candidate Act cannot independently
authorize a materially different Candidate Act.
A current quorum does not override a mandatory security veto where
the protected policy makes that veto controlling.
8.6.3.5. Source page 2402 of the original specification
An approval prepared under an obsolete resource or authority
generation may require revalidation.
And an actual Finality Sink must not substitute aggregate agent
agreement for its own mandatory operation-specific enforcement.
29.0.3 — Principal Candidate Inventive Combination
A representative technical combination comprises:
(a) a protected originating consequential authority root;
(b) a Candidate Act representing a proposed actual resource
operation;
(c) an enforceable Non-Effective State;
(d) a protected quorum policy identifying eligible evaluators,
required approval roles, vote thresholds, independence properties,
and current membership generation;
(e) an operation-specific approval commitment binding each qualifying
evaluation to the same material Candidate Act;
(f) an authenticated evaluation-evidence collector;
(g) a protected conflict and veto resolver;
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
(h) a current authority and quorum-generation validator;
(i) an independent execution-time resource and operation validator;
(j) optional cross-committed approval and execution evidence;
(k) scoped non-bearer finality enablement;
(l) a designated independently enforcing Finality Sink;
(m) sink-side reconstruction of the actual pending operation;
(n) verification of current source authority, applicable quorum
predicates, material operation correspondence, and protected sink-
local consumption.
29.0.4 — Focused Technical Distinction
The candidate inventive contribution is not merely employing multiple
models, requiring majority approval, producing a threshold signature,
or using a distributed consensus algorithm.
8.6.3.6. Source page 2403 of the original specification
The distinguishing combination, if supported and not taught or
rendered obvious by the relevant prior art, is the mandatory
operation-specific relationship between qualified collective
evaluation and a separately enforced, current, actual resource-effect
authority transition.
29.0.5 — Relationship to Earlier Embodiments
This embodiment may incorporate:
Foundational Candidate Act, Non-Effective State, Protected
Enforcement Domain, and Finality-Sink principles;
Protected collection-time and execution-time evidence;
Non-bearer finality enablement;
Protected current revocation;
Resource identity continuity;
Cumulative resource budgets;
Transaction-bound human approval;
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Delegation and transitive authority restrictions;
Tool and runtime generation continuity;
And distributed ownership fencing.
The embodiment concentrates upon quorum-specific dependent
implementation features, especially the conditions under which
multiple agent or evaluator approvals may participate in—but cannot
substitute for—actual finality authorization.
29.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v PROTECTED SOURCE AUTHORITY | v PROPOSED
OPERATION | v CANDIDATE ACT | v NON-EFFECTIVE STATE |
8.6.3.7. Source page 2404 of the original specification
v PROTECTED QUORUM POLICY | +-----------+-----------+ | | | v v v
EVALUATOR A EVALUATOR B EVALUATOR C | | | v v v BOUND VOTE BOUND VOTE
BOUND VOTE | | | +-----------+-----------+ | v PROTECTED QUORUM
RESOLVER | v CONFLICT / VETO VALIDATION | v QUALIFIED QUORUM
EVIDENCE | v INDEPENDENT CURRENT AUTHORITY CHECK | v EXECUTION-TIME
VALIDATION | v NON-BEARER FINALITY | v ACTUAL FINALITY SINK | v
RECONSTRUCT ACTUAL OPERATION | v SOURCE + QUORUM + RESOURCE CHECK | v
PROTECTED CONSUMPTION | v CONTROLLED REAL EFFECT
The diagram is illustrative and non-limiting.
The number of evaluators, required thresholds, administrative
domains, policy classes, and resource sinks may differ.
8.6.3.8. Source page 2405 of the original specification
29.1 — TECHNICAL FIELD
The invention relates to multi-agent autonomous decision systems,
distributed approval, cryptographic quorum evidence, threshold
authorization, protected conflict resolution, separation of duties,
agent independence qualification, current resource-state validation,
and independent consequential execution finality.
More particularly, the embodiment addresses the technical distinction
between collective computational agreement and enforceable authority
to produce actual resource effects.
29.2 — SPECIFIC TECHNICAL PROBLEMS
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.2.1 — Consensus/Authority Confusion
A quorum of agents may agree upon an operation for which no valid
original source permission exists.
29.2.2 — Vote-to-Operation Substitution
A valid approval for one operation may be reused for another.
29.2.3 — Proposal Equivocation
A proposer may show different operation parameters to different
evaluators.
29.2.4 — Shared Evaluator Dependency
Several nominally separate agents may depend upon one compromised
model, data source, or policy controller.
29.2.5 — Sybil Quorum Inflation
One adversarial principal may create multiple evaluator identities.
29.2.6 — Role Substitution
An evaluator authorized for technical risk review may be counted as a
qualified financial authorization principal.
29.2.7 — Threshold-Only Policy
A numerical majority may be incorrectly treated as sufficient despite
a mandatory specialist or source-authority requirement.
29.2.8 — Stale Membership
8.6.3.9. Source page 2406 of the original specification
Votes from an obsolete committee may be accepted after membership
changes.
29.2.9 — Stale Signing Keys
A revoked evaluator may retain cryptographic material and continue
generating apparently authentic messages.
29.2.10 — Conflicting Quorums
Different sets of evaluators may approve incompatible operations.
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.2.11 — Conflicting Candidate Acts
Several mutually exclusive operations may independently collect
sufficient votes.
29.2.12 — Resource Version Change
A quorum may approve an operation based on resource state that
changes before execution.
29.2.13 — Policy Generation Change
The quorum threshold or mandatory approval roles may change before
effectuation.
29.2.14 — Partial Approval Misinterpretation
An evaluator may approve only selected operation fields while a
controller treats the vote as approval of the entire effect.
29.2.15 — Ambiguous Canonicalization
Different evaluators may interpret identical serialized bytes
differently.
29.2.16 — Signed Message Scope
A signature may cover a transaction identifier but omit the actual
recipient, amount, or resource identity.
29.2.17 — Threshold Signature Attribution
An aggregate signature may not independently disclose which
individual participants approved the operation.
29.2.18 — Vote Replay
A valid earlier vote may be reused in another task or decision round.
29.2.19 — Human Approval Confusion
Authentication of a human participant may be mistaken for informed
approval of the actual specific consequence.
8.6.3.10. Source page 2407 of the original specification
29.2.20 — Computational Safety Claim
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An agent may declare an operation safe without verifying mandatory
technical conditions.
29.2.21 — Colluding Evaluators
A quorum may be compromised or coordinate maliciously.
29.2.22 — Majority Override of Veto
Several affirmative votes may be used to ignore a mandatory
independent veto.
29.2.23 — Concurrent Quorum Consumption
Two different quorums may authorize operations competing for the same
single-use resource allowance.
29.2.24 — Retry After Timeout
A timed-out quorum procedure may result in repeated operation
approval.
29.2.25 — Quorum Reconstruction After Crash
Recovered computational state may incorrectly restore consumed
decision authority.
29.2.26 — Agent Delegation
An approved evaluator may attempt to delegate its voting role to an
unauthorized child.
29.2.27 — Unqualified External Evaluator
An external agent may participate without satisfying the quorum's
identity or independence requirements.
29.2.28 — Intermediate Effects
A committee may evaluate a final outcome while disregarding
unauthorized intermediate resource changes.
29.2.29 — Unsupported Consensus Guarantee
A voting mechanism may be described as Byzantine-fault-tolerant
without satisfying the necessary threat, quorum intersection, and
communication assumptions.
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.2.30 — Technical Objective
A candidate objective technical problem is:
How to incorporate collective autonomous evaluation and approval into
consequential resource operations while ensuring that quorum
agreement remains bound to one
8.6.3.11. Source page 2408 of the original specification
precisely defined Candidate Act, respects independent source and
mandatory security authority, remains valid under current membership
and resource conditions, and cannot be substituted for actual
Finality-Sink enforcement.
29.3 — ESTABLISHED TECHNICAL FOUNDATIONS
29.3.1 — Distributed Consensus
Existing distributed consensus algorithms can maintain replicated
decisions under specified assumptions.
They do not inherently determine whether an agreed business or
physical operation is authorized by the original task principal.
29.3.2 — Threshold Cryptography
Existing threshold signature protocols may produce signatures from a
configured number of participants.
The signature authenticates selected message content under the
relevant key and protocol assumptions.
It does not inherently prove that the signers possess task-specific
authority or that a real-world resource effect is permitted.
29.3.3 — Multi-Signature Approval
Existing authorization systems may require signatures from several
principals.
The signed content must still accurately identify the operation for
which approval is claimed.
29.3.4 — Separation of Duties
Existing enterprise controls can require different roles to
participate in approval.
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The proposed mechanism may use such role distinctions but
additionally requires current operation-specific effectuation checks.
29.3.5 — Human-in-the-Loop Authorization
Existing systems may require human review.
A generic approval does not necessarily establish current
correspondence to a later changed operation.
29.3.6 — Policy Engines
Existing policy engines can calculate authorization conditions.
8.6.3.12. Source page 2409 of the original specification
A computational quorum result is not equivalent to passing all
mandatory protected resource and source predicates.
29.3.7 — Conditional Transactions
Existing transactional systems may enforce resource versions and
single-use state.
These may implement the actual Finality-Sink consumption mechanism.
29.3.8 — Candidate Additional Relationship
The disclosed combination connects the qualifying quorum decision to
a protected actual-operation authority boundary where current source,
resource, veto, and consumption checks remain mandatory.
29.4 — PRINCIPAL SYSTEM COMPONENTS
A representative system comprises:
A Protected Originating Source-Authority Controller;
A Candidate Act Construction Service;
A Non-Effective Hold Controller;
A Protected Quorum Policy Registry;
An Evaluator Identity and Eligibility Registry;
An Evaluator Independence-Qualification Controller;
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
An Operation-Specific Approval Challenge Service;
An Authenticated Vote Collector;
A Protected Quorum Evidence Registry;
A Vote Conflict and Equivocation Detector;
A Mandatory Veto Resolver;
A Quorum Membership-Generation Controller;
A Protected Approval Freshness Controller;
An Independent Source and Resource Validator;
A Cross-Committed Evidence Controller;
8.6.3.13. Source page 2410 of the original specification
A Scoped Non-Bearer Finality Controller;
An Actual Resource Finality Sink;
A Protected Consumption and Outcome Journal;
And a Recovery and Revocation Controller.
Optional components include:
A threshold signature service;
A replicated consensus registry;
A deterministic policy evaluator;
A hardware-backed identity service;
A human transaction-approval channel;
A privileged credential broker;
An independent resource-state observer;
And a distributed time or generation authority.
29.5 — TECHNICAL DEFINITIONS
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.5.1 — Protected Quorum Authority Policy
A Protected Quorum Authority Policy, or PQAP-29, means an
authenticated policy defining when collective evaluation is required
and the conditions for counting approval evidence.
29.5.2 — Qualified Evaluator
A Qualified Evaluator means an entity whose identity, role, and
required operational properties satisfy the applicable protected
quorum policy.
29.5.3 — Evaluator Eligibility Generation
An Evaluator Eligibility Generation means the current authoritative
version of an evaluator's qualifying membership and role.
29.5.4 — Independent Evaluation Quorum
An Independent Evaluation Quorum, or IEQ-29, means a set of qualified
evaluation results satisfying an applicable protected threshold and
any mandatory independence or separation-of-duties conditions.
8.6.3.14. Source page 2411 of the original specification
29.5.5 — Qualified Evaluator Independence
Qualified Evaluator Independence means satisfaction of specified
technical separation properties, including where required different
identity roots, credentials, execution domains, code bases, data
sources, or administrative authorities.
29.5.6 — Quorum Independence Profile
A Quorum Independence Profile, or QIP-29, means an authenticated
record of independence conditions required for a particular decision
class.
29.5.7 — Quorum Membership Generation
A Quorum Membership Generation, or QMG-29, means the current
protected version of applicable committee membership.
29.5.8 — Quorum Policy Generation
A Quorum Policy Generation, or QPG-29, means the current protected
version of the required approval threshold, role, veto, and decision
rules.
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.5.9 — Operation-Specific Approval Envelope
An Operation-Specific Approval Envelope, or OSAE-29, means a
protected representation of the exact consequential Candidate Act and
associated conditions being submitted for approval.
29.5.10 — Approval Materiality Set
An Approval Materiality Set, or AMS-29, means the operation fields
whose change invalidates or requires revalidation of the approval.
29.5.11 — Canonical Approval Descriptor
A Canonical Approval Descriptor, or CAD-29, means a deterministic
typed representation of the Candidate Act and required approval
context.
29.5.12 — Candidate Approval Commitment
A Candidate Approval Commitment, or CAC-29, means an authenticated
commitment to the defined operation and approval conditions.
29.5.13 — Protected Evaluator Vote
A Protected Evaluator Vote, or PEV-29, means an authenticated
operation-bound evaluator decision.
29.5.14 — Vote Evidence Class
8.6.3.15. Source page 2412 of the original specification
A Vote Evidence Class means the specific kind of claim established by
a vote, including recommendation, risk assessment, technical
predicate, or source-authority approval.
29.5.15 — Quorum Approval Certificate
A Quorum Approval Certificate, or QAC-29, means qualified evidence
that the required quorum conditions were satisfied for a defined
Candidate Act.
29.5.16 — Mandatory Veto Predicate
A Mandatory Veto Predicate means an authoritative condition whose
failure prohibits effectuation regardless of affirmative vote count.
29.5.17 — Quorum Conflict
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Quorum Conflict means a material inconsistency among votes,
certificates, operation descriptors, applicable policies, or
protected resource states.
29.5.18 — Candidate Equivocation
Candidate Equivocation means presenting materially different
operation descriptions as though they were one identical approval
proposal.
29.5.19 — Approval Equivocation
Approval Equivocation means an evaluator issuing incompatible
protected approvals within a context where the applicable policy
prohibits such behavior.
29.5.20 — Protected Consensus Resolution
Protected Consensus Resolution means the authenticated determination
that a specified set of votes satisfies the applicable quorum policy.
29.5.21 — Qualified Negative Decision
A Qualified Negative Decision means an authenticated rejection, veto,
conflict, or abstention according to its protected evidence role.
29.5.22 — Consensus Non-Authority Invariant
Consensus Non-Authority Invariant means a condition that collective
agreement cannot independently enlarge the originating consequential
authorization.
29.5.23 — Source-Authority Preservation
Source-Authority Preservation means continued enforcement of the
original valid principal authorization regardless of quorum results.
29.5.24 — Quorum-Bound Candidate Act
8.6.3.16. Source page 2413 of the original specification
A Quorum-Bound Candidate Act, or QBCA-29, means a Candidate Act
associated with a specific protected quorum procedure and approval
descriptor.
29.5.25 — Current Quorum Witness
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A Current Quorum Witness means authenticated evidence identifying the
applicable qualified participants, policy, decision, and current
generation.
29.5.26 — Threshold Cryptographic Approval
Threshold Cryptographic Approval means the use of a threshold
cryptographic protocol to authenticate a particular approval message
under configured participant assumptions.
29.5.27 — Quorum Participation Manifest
A Quorum Participation Manifest, or QPM-29, means a qualified record
identifying the participants and roles accepted for a quorum
decision.
29.5.28 — Role-Constrained Quorum
A Role-Constrained Quorum means an approval set required to include
specified qualified evaluator roles.
29.5.29 — Heterogeneous Evaluation Quorum
A Heterogeneous Evaluation Quorum means a quorum involving evaluators
with specified different implementation or evidence properties.
29.5.30 — Quorum Independence Failure
Quorum Independence Failure means failure of a required technical
separation condition among purportedly distinct evaluators.
29.5.31 — Protected Approval Challenge
A Protected Approval Challenge means a fresh operation-bound value or
context used to prevent unauthorized reuse of approval evidence.
29.5.32 — Approval Round
An Approval Round means a protected evaluation instance associated
with a Candidate Act and a particular quorum-policy context.
29.5.33 — Approval Expiry Generation
An Approval Expiry Generation means a protected generation or other
freshness condition after which selected approvals require renewed
validation.
29.5.34 — Quorum-Finality Separation
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.17. Source page 2414 of the original specification
Quorum-Finality Separation means maintaining distinct protected steps
for collective approval and actual resource-effect authorization.
29.5.35 — Approval Rebinding Prohibition
Approval Rebinding Prohibition means rejecting use of approval
evidence for a materially different actual operation.
29.5.36 — Protected Approval Conflict Fence
A Protected Approval Conflict Fence, or PACF-29, means a condition
withholding a consequential operation following unresolved material
approval conflicts.
29.5.37 — Resource-Specific Quorum Requirement
A Resource-Specific Quorum Requirement means a quorum policy derived
from protected resource and operation attributes.
29.5.38 — Quorum-Dependent Finality
Quorum-Dependent Finality means operation-specific finality requiring
both qualifying quorum evidence and other independent mandatory
finality predicates.
29.5.39 — Quorum-Independent Mandatory Predicate
A Quorum-Independent Mandatory Predicate means a required security or
authority condition that must be satisfied regardless of quorum
agreement.
29.5.40 — Vote-to-Effect Correspondence
Vote-to-Effect Correspondence means qualified equality or permitted
bounded correspondence between an approved operation and the actual
pending consequence.
29.5.41 — Approval Outcome Journal
An Approval Outcome Journal means protected storage of approval,
finality, attempted effect, and qualified actual outcome states.
29.5.42 — Quorum Resource-Generation Binding
Quorum Resource-Generation Binding means association of a qualified
approval with relevant current resource-state evidence.
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.5.43 — Quorum Reconfiguration Fence
A Quorum Reconfiguration Fence means protected invalidation or
suspension of affected pending approvals following a material
committee or policy change.
29.5.44 — Conflicting Proposal Set
8.6.3.18. Source page 2415 of the original specification
A Conflicting Proposal Set means two or more Candidate Acts whose
effects cannot safely or permissibly coexist under applicable
protected rules.
29.5.45 — Protected Decision Serialization
Protected Decision Serialization means ordering or resolving
conflicting proposed consequential operations under an authoritative
resource or decision state.
29.5.46 — Approval Evidence Qualification
Approval Evidence Qualification means determining precisely what an
approval signature, vote, or attestation proves.
29.5.47 — Source-Competent Approver
A Source-Competent Approver means a principal independently
authorized to establish or modify a selected consequential source
grant.
29.5.48 — Technical Advisory Evaluator
A Technical Advisory Evaluator means a component that supplies an
evaluation result without possessing source-grant authority unless
separately established.
29.5.49 — Quorum-Scoped Non-Bearer Enablement
Quorum-Scoped Non-Bearer Enablement means operation-specific finality
whose validity depends upon current protected quorum evidence and
sink-side authority state.
29.5.50 — Actual Quorum-Authorized Effect
An Actual Quorum-Authorized Effect means a real resource operation
permitted after satisfying the applicable source, quorum, technical,
and sink-local finality predicates.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.6 — FOUR DIFFERENT MEANINGS OF AGREEMENT
The architecture distinguishes at least four forms of agreement.
29.6.1 — Computational Recommendation
Several models recommend an operation.
This is evidence of their computational outputs, not necessarily of
external resource authority.
29.6.2 — Technical Validation Agreement
Several qualified components verify selected technical predicates.
8.6.3.19. Source page 2416 of the original specification
This can supply evidence that the checked predicates passed under the
applicable observation and trust assumptions.
29.6.3 — Source-Competent Approval
One or more principals possessing independently established
authorization rights approve or grant a bounded operation.
This may contribute genuine authority under the applicable protected
source policy.
29.6.4 — Replicated-State Agreement
A distributed system agrees upon a protected registry state or
decision record.
This may support consistency of the record under its specified fault
model.
29.6.5 — Distinction
None of the four is automatically interchangeable with the others.
For example, three agreeing models cannot substitute for a source-
competent financial approver when such approval is mandatory.
Similarly, an agreed ledger entry does not by itself establish that
the operation presented to the payment processor matches the
authorized transfer.
29.7 — PROTECTED ORIGINATING AUTHORITY
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A representative record comprises:
PROTECTED_ORIGINATING_AUTHORITY = { task_identifier,
originating_principal, permitted_effect_classes, permitted_resources,
permitted_recipients, permitted_operation_parameters,
cumulative_effect_limits, required_quorum_policy_reference,
mandatory_veto_policy, permitted_new_authority_sources,
current_source_authority_generation, current_revocation_generation,
protected_authentication }
The source-authority controller is protected from arbitrary
modification by the proposing agent or evaluator quorum.
8.6.3.20. Source page 2417 of the original specification
Where the originating grant requires several source-competent
approving principals, the controller verifies their corresponding
actual roles.
A vote cast by an advisory agent does not become such principal
authorization merely because the vote is included in a quorum.
29.8 — CANDIDATE ACT APPROVAL ENVELOPE
A representative OSAE-29 comprises:
OPERATION_SPECIFIC_APPROVAL_ENVELOPE = { candidate_act_identifier,
logical_operation_identifier, originating_authority_reference,
operation_class, actual_resource_identity,
actual_recipient_or_destination, material_operation_parameters,
outgoing_content_commitment, current_resource_generation,
applicable_tool_contract_generation, required_evaluation_classes,
quorum_policy_generation, evaluator_membership_generation,
approval_round_identifier, designated_finality_sink,
protected_approval_authentication }
29.8.1 — Exact Operation
The envelope identifies the effect being evaluated.
29.8.2 — Material Parameters
The fields governing the real consequence are explicit or qualified
by a protected bounded rule.
29.8.3 — Source Authority
The envelope references current originating permission.
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.8.4 — Quorum Context
The envelope identifies the applicable evaluator and policy
generation.
29.8.5 — Finality Sink
8.6.3.21. Source page 2418 of the original specification
The approval is associated with the protected consequential receiving
resource.
29.9 — OPERATION-SPECIFIC COMMITMENT
A representative approval commitment may be:
[ C_A=H(\operatorname{Canon}(CA,R,P,G,N)) ]
(CA) is the typed Candidate Act;
(R) is the designated actual resource and relevant generation;
(P) is the current quorum policy;
(G) is current originating source-authority context;
And (N) is a protected approval-round or challenge value.
A signature, MAC, or other authenticated approval artifact may bind
the evaluator decision to (C_A).
29.9.1 — Canonicalization
Every mandatory evaluator must approve an identical operation
representation or a precisely defined authorized equivalent.
29.9.2 — Unknown Fields
Unknown consequential fields cannot silently be ignored when they
affect the protected actual operation.
29.9.3 — Ambiguous Values
Recipient identity, resource aliases, amounts, units, currency, data
hashes, or object identifiers must be interpreted consistently.
29.9.4 — Protected Rebinding
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The actual sink checks correspondence rather than accepting a hash
equality computed solely over an untrusted agent's operation
description.
29.10 — QUORUM POLICY
8.6.3.22. Source page 2419 of the original specification
A representative protected policy comprises:
PROTECTED_QUORUM_POLICY = { policy_identifier,
operation_effect_class, minimum_qualified_approvals,
eligible_evaluator_roles, mandatory_role_coverage,
required_independence_properties, prohibited_conflict_conditions,
mandatory_veto_sources, permitted_abstention_rules,
approval_freshness_conditions, resource_version_binding,
permitted_reapproval_conditions, current_membership_generation,
current_policy_generation, protected_policy_authentication }
The protected policy may differ among operation classes.
For example:
A bounded internal report publication may require a smaller
evaluation set than a high-impact resource change.
A physically consequential command may require current device-
specific predicates irrespective of evaluator count.
A policy may permit automated release where no quorum is necessary,
provided all other required finality predicates pass.
29.11 — ELIGIBLE EVALUATOR IDENTITY
An evaluator may be identified using:
An authenticated service identity;
A protected workload identity;
A hardware-backed identity;
A verified human principal;
A qualified role certificate;
Or another suitable authenticated representation.
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.23. Source page 2420 of the original specification
The protected registry checks:
Whether the evaluator exists;
Whether the evaluator is currently eligible;
Whether it possesses the required approval role;
Whether its key or credential remains valid;
And whether the applicable policy permits its vote to count.
29.11.1 — Identity Count
Multiple process IDs do not necessarily represent independent
approval principals.
29.11.2 — Key Count
Multiple cryptographic keys controlled by one actor do not
automatically satisfy a policy requiring independent administrative
principals.
29.11.3 — Role Count
Different roles may be required even when a numerical threshold is
otherwise satisfied.
29.12 — QUALIFIED EVALUATOR INDEPENDENCE
The protected policy may specify one or more separation properties.
A selected implementation may require:
Different administrative key custodians;
Different privileged execution domains;
Different policy issuers;
Different source-data acquisition channels;
Different model families or code implementations;
Independent resource observation channels;
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Or selected combinations.
29.12.1 — Technical Qualification
Different model names do not prove statistical or causal
independence.
8.6.3.24. Source page 2421 of the original specification
29.12.2 — Shared Input
Separate evaluators may still be misled by identical compromised
evidence.
29.12.3 — Shared Infrastructure
Separate processes may depend upon the same compromised host or
authorization service.
29.12.4 — Required Claim Precision
An asserted independence property should identify the technical
separation actually verified.
29.12.5 — Effectuation Protection
Even an apparently independent quorum cannot independently override
missing source authority or a failed mandatory sink predicate.
29.13 — HETEROGENEOUS QUORUM ROLES
A policy may require different classes of evaluation.
For example:
Evaluator A — Operation semantics: Verifies the intended resource
effect.
Evaluator B — Source authority: Verifies current originating
permission.
Evaluator C — Resource state: Obtains independently qualified current
resource evidence.
Evaluator D — Risk assessment: Produces an advisory technical risk
result.
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Evaluator E — Source-competent approval: Establishes a specifically
authorized human or institutional approval when required.
The roles are illustrative.
29.13.1 — No Improper Substitution
Three advisory risk evaluators do not automatically replace one
mandatory source-competent authorizer.
29.13.2 — No Universal Human Requirement
An operation may be automatically permitted under a valid protected
original policy.
29.13.3 — Technical Separation
Evaluation evidence and finality enforcement may reside in different
protected domains.
8.6.3.25. Source page 2422 of the original specification
29.14 — OPERATION-BOUND EVALUATOR VOTE
A representative PEV-29 comprises:
PROTECTED_EVALUATOR_VOTE = { evaluator_identity, evaluator_role,
evaluator_eligibility_generation, candidate_approval_commitment,
approval_round_identifier, evaluation_result,
evaluated_evidence_commitment, asserted_predicate_class,
current_policy_generation, current_resource_generation,
vote_freshness_reference, protected_vote_authentication }
A vote may indicate:
APPROVE;
REJECT;
ABSTAIN;
UNRESOLVED;
Or a suitable typed predicate result.
The effect of each result depends upon the applicable protected
policy.
Das Expires 29 April 2027 [Page 439]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A technical recommendation is not automatically a source-authority
grant.
29.15 — QUORUM PARTICIPATION MANIFEST
A threshold cryptographic signature may authenticate a message using
one group public key.
The resulting signature does not necessarily reveal the individual
participating signers.
Where a claim requires qualified independence, roles, or participant
attribution, the system may retain a separately authenticated
participation manifest or equivalent verifiable evidence.
8.6.3.26. Source page 2423 of the original specification
A representative manifest comprises:
QUORUM_PARTICIPATION_MANIFEST = { candidate_approval_commitment,
approval_round_identifier, accepted_participant_identities,
accepted_evaluator_roles, eligible_membership_generation,
independence_qualification_references, accepted_vote_commitments,
current_quorum_policy_generation, protected_manifest_authentication }
29.15.1 — Signature Authenticity
The aggregate signature verifies the configured group-key statement.
29.15.2 — Individual Role Evidence
The participation manifest supplies the additional properties
required by the protected policy.
29.15.3 — No Unsupported Inference
An aggregate signature alone does not universally prove which
specific individuals or agents actually participated.
29.16 — QUORUM RESOLUTION
For an ordinary numerical threshold, a selected condition may be:
[ \sum_{i\in Q}\operatorname{EligibleApprove}_i\geq k ]
where (Q) is the set of qualified eligible evaluator identities and
(k) is the protected required threshold.
Das Expires 29 April 2027 [Page 440]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A stronger role-aware predicate may be:
[ Q_{\mathrm{valid}}= Q_{\mathrm{threshold}} \land Q_{\mathrm{roles}}
\land Q_{\mathrm{independence}} \land Q_{\mathrm{freshness}} \land
Q_{\mathrm{sameAct}}
8.6.3.27. Source page 2424 of the original specification
\land \neg Q_{\mathrm{conflict}} ]
The exact form is non-limiting.
Even where (Q_{\mathrm{valid}}) is true, finality may still be
refused because a mandatory source-authority, resource, revocation,
or security predicate fails.
29.17 — MANDATORY VETO
A protected policy may identify conditions that cannot be overridden
by affirmative computational votes.
Examples may include:
Revoked source authority;
Unauthorized resource identity;
Invalid protected credential state;
Actual operation mismatch;
An enforced resource quota;
A required but absent qualified human approval;
A mandatory safety condition failure;
Or protected consumption already committed.
29.17.1 — Numerical Independence
The veto remains effective even when a numerical quorum approves.
29.17.2 — Protected Origin
A veto must originate from a qualified mandatory authority or
verified technical predicate.
Das Expires 29 April 2027 [Page 441]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.17.3 — Advisory Objection
A non-mandatory evaluator disagreement may be handled differently
under the protected policy.
29.17.4 — No Arbitrary Relaxation
An untrusted proposing agent cannot reduce the mandatory veto set to
obtain approval.
8.6.3.28. Source page 2425 of the original specification
29.18 — CONFLICT-AWARE RESOLUTION
Different evaluators may produce incompatible results.
A principal implementation distinguishes:
Conflicting interpretations of the same Candidate Act;
Approval of different Candidate Acts;
Conflicting current resource evidence;
Different quorum-policy generations;
Revoked versus active evaluator identity;
And incompatible finality consumption or budget state.
29.18.1 — Material Conflict
A mandatory unresolved conflict activates a protected approval
conflict fence.
29.18.2 — Nonmaterial Disagreement
A protected policy may permit resolution without changing the actual
effect.
29.18.3 — New Candidate
A materially revised operation requires new approval binding where
applicable.
29.18.4 — Current Resource
Das Expires 29 April 2027 [Page 442]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Conflict resolution must not substitute an older resource snapshot
for current mandatory sink evidence.
29.19 — CANDIDATE EQUIVOCATION
A malicious proposer may send:
A payment of one amount to Evaluator A;
A payment of another amount to Evaluator B;
And a third operation to the actual payment sink.
8.6.3.29. Source page 2426 of the original specification
If votes are counted only by their general approval status, the
system may falsely construct a quorum.
A principal implementation requires every counted approval to bind to
the same protected Candidate Act commitment or a formally permitted
bounded equivalent.
29.19.1 — Different Hashes
Different material Candidate Act commitments cannot silently be
combined into one approval certificate.
29.19.2 — Serialization Equality
Canonicalization must identify the relevant real effect.
29.19.3 — Sink Equality
The actual operation must correspond to the approved Candidate Act.
29.19.4 — Technical Effect
A quorum cannot be synthesized from individually valid votes for
mutually different actual operations.
29.20 — CONFLICTING QUORUMS
Two quorums may approve different operations concerning one protected
resource.
For example:
Committee A approves Resource Version 5 being changed to State X.
Das Expires 29 April 2027 [Page 443]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Committee B approves the same Resource Version 5 being changed to
State Y.
Both approvals may be authentic.
However, both effects may not be simultaneously permissible.
A protected resource controller may enforce:
A common logical operation identity;
A current resource version;
An authoritative conflict set;
A protected consumption state;
8.6.3.30. Source page 2427 of the original specification
Or another suitable resource-specific serialization predicate.
29.20.1 — Quorum Intersection
Selected consensus protocols rely upon intersection and consistency
assumptions.
29.20.2 — Business Conflict
A cryptographic or distributed consensus guarantee does not
automatically resolve all application-specific resource conflicts.
29.20.3 — Actual Resource Decision
The Finality Sink decides whether the specific pending resource
operation remains eligible.
29.21 — APPROVAL CHALLENGE AND REPLAY PREVENTION
A protected approval round may include:
A fresh challenge;
A unique Candidate Act identifier;
The logical operation identifier;
Current resource generation;
Das Expires 29 April 2027 [Page 444]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Quorum-policy generation;
Source-authority generation;
And designated Finality Sink.
A historical signature may remain cryptographically valid but be
ineligible for a new approval round or altered operation.
29.21.1 — Freshness
Freshness may be established through a protected generation,
challenge, or suitable time-bound condition.
29.21.2 — No Timestamp-Only Requirement
A monotonic protected generation may be used without assuming
synchronized clocks.
29.21.3 — Protected Replay State
Consumed decision or finality references cannot automatically be used
again.
8.6.3.31. Source page 2428 of the original specification
29.22 — QUORUM MEMBERSHIP TRANSITION
Evaluator membership may change.
Changes may include:
Adding evaluators;
Removing evaluators;
Revoking credentials;
Changing evaluator roles;
Rotating signing keys;
Modifying the required threshold;
Or changing separation-of-duties rules.
The protected controller may determine whether the change affects
pending approvals.
Das Expires 29 April 2027 [Page 445]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.22.1 — Member Removal
Votes from removed members may become ineligible under applicable
current policy.
29.22.2 — New Policy
A pending operation may require evaluation under the current policy
generation.
29.22.3 — Qualified Continuity
A protected policy may permit selected previously collected votes to
remain usable if the current authority model explicitly allows it.
29.22.4 — Reconfiguration Fence
A material unresolved change prevents affected finality.
29.22.5 — No Automatic Key Trust
A cryptographically valid historical signature does not independently
prove current eligibility.
29.23 — THRESHOLD CRYPTOGRAPHIC VARIATION
8.6.3.32. Source page 2429 of the original specification
An optional implementation may use a threshold signature protocol.
A protected controller may create an operation-specific message
containing the Candidate Act approval commitment and relevant policy
context.
Qualified participants contribute to a threshold cryptographic
procedure.
The resulting signature may authenticate the selected operation
commitment under a configured group key.
29.23.1 — Threshold Versus Authority
The signature does not independently establish current source
authorization.
29.23.2 — Threshold Versus Independence
Das Expires 29 April 2027 [Page 446]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Cryptographic threshold participation is distinct from the broader
technical independence policy.
29.23.3 — Participant Attribution
The system may retain separately authenticated participant evidence
where necessary.
29.23.4 — Nonce and Protocol Safety
The implementation must follow the selected threshold protocol's
required handling of randomness, commitments, participant
authentication, and state.
29.23.5 — Optionality
The invention does not require threshold cryptography when an
equivalent qualified set of individually signed approval records
supports the selected protection properties.
29.24 — HUMAN AND MACHINE QUORUMS
A quorum may combine:
Human source-competent approval;
Technical policy validation;
Independent actual-resource observation;
And machine-based advisory evaluation.
29.24.1 — Human Authentication
Establishes the qualified human identity under the selected assurance
model.
8.6.3.33. Source page 2430 of the original specification
29.24.2 — Human Operation Approval
Establishes approval only for the transaction or operation actually
presented and bound through the qualified approval procedure.
29.24.3 — Machine Evaluation
Provides the asserted technical evidence or recommendation.
Das Expires 29 April 2027 [Page 447]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.24.4 — Actual Finality
The sink separately verifies the operation.
29.24.5 — No Universal Human Requirement
The originating source policy may authorize suitable fully automated
operations.
29.25 — DYNAMIC QUORUM REQUIREMENTS
A protected policy may prescribe different thresholds for different
operation classes.
For example:
A bounded local persistence change may require two qualified
validators.
A high-impact payment may require a source-competent approval in
addition to technical validation.
A hardware command may require selected actual device-state evidence.
29.25.1 — Risk Classification
Risk or consequence class may be determined from protected actual-
effect parameters.
29.25.2 — Policy Integrity
An untrusted agent cannot arbitrarily downgrade an operation's class.
29.25.3 — Reclassification
A material operation change may trigger renewed quorum evaluation.
29.25.4 — Independent Resource Predicate
Even the strongest advisory quorum cannot override a mandatory
resource-state condition.
8.6.3.34. Source page 2431 of the original specification
29.26 — APPROVAL BINDING TO ACTUAL RESOURCE STATE
A quorum may evaluate a proposed database transaction using a
particular record version.
Das Expires 29 April 2027 [Page 448]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Before effectuation, another operation changes that record.
A selected implementation requires:
Current resource-version correspondence;
Current operation semantics;
And any required renewed approval.
29.26.1 — Bound Generation
The approval may be valid only for the designated resource version.
29.26.2 — Qualified Equivalent State
A policy may permit continued eligibility when defined material
properties remain unchanged.
29.26.3 — Unknown State
The actual operation remains withheld where current resource
validation is mandatory but unavailable.
29.27 — APPROVAL REBINDING PROHIBITION
An approval may not silently transfer from:
One recipient to another;
One payment amount to another;
One file to another;
One database record to another;
One physical device to another;
One outgoing data payload to another;
Or one operation class to another.
Where the original authorization permits bounded variation, the
protected approval descriptor must define that variation.
Das Expires 29 April 2027 [Page 449]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.35. Source page 2432 of the original specification
A materially different effect outside the approved envelope requires
the applicable new authorization and quorum procedure.
29.28 — PROTECTED APPROVAL CERTIFICATE
A representative certificate comprises:
PROTECTED_QUORUM_APPROVAL_CERTIFICATE = { candidate_act_commitment,
originating_source_authority_reference, accepted_quorum_policy,
current_policy_generation, evaluator_membership_generation,
accepted_evaluator_manifest, accepted_vote_commitments,
mandatory_role_results, qualified_independence_results, veto_state,
conflict_state, relevant_resource_generation,
approval_round_identifier, protected_certificate_authentication }
The certificate is evidence that the applicable quorum decision was
reached.
It is not independently a transferable authorization to perform any
operation requested by its holder.
29.29 — CROSS-COMMITTED CONSENSUS AND EXECUTION EVIDENCE
A selected implementation may establish:
[ C_Q=H(\operatorname{Canon}(CA,Q,V,P)) ]
[ C_E=H(\operatorname{Canon}(CA,O,A,R,C_Q)) ]
[ C_F=H(\operatorname{Canon}(C_Q,C_E,S,L)) ]
8.6.3.36. Source page 2433 of the original specification
(CA) represents the Candidate Act;
(Q) represents qualified quorum membership and policy;
(V) represents accepted approval evidence;
(P) represents conflict and veto state;
(O) represents execution-time operation evidence;
(A) represents current source authority;
(R) represents current resource state;
Das Expires 29 April 2027 [Page 450]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
(S) represents the designated Finality Sink;
And (L) represents protected sink-local consumption state.
These expressions are non-limiting.
Cryptographic commitments do not substitute for obtaining reliable
current observations from the actual protected resource.
29.30 — QUORUM-DEPENDENT NON-BEARER FINALITY
A representative protected record comprises:
QUORUM_SCOPED_FINALITY_ENABLEMENT = { candidate_act_digest,
originating_source_grant_reference,
accepted_quorum_certificate_digest, current_quorum_policy_generation,
current_membership_generation, mandatory_veto_state,
approved_actual_effect_descriptor,
independent_execution_validation_commitment,
current_resource_generation, current_revocation_generation,
designated_finality_sink, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The proposing agent may receive only an opaque finality reference.
The Finality Sink independently verifies the protected record.
8.6.3.37. Source page 2434 of the original specification
A copied reference does not itself permit another effect.
29.31 — NON-SUBSTITUTABLE ACTUAL FINALITY
The actual Finality Sink reconstructs:
The real resource identity;
The actual recipient;
The actual operation method;
Material request arguments;
The outgoing content or command;
The current resource generation;
And the relevant source-authority context.
Das Expires 29 April 2027 [Page 451]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The sink verifies:
Current originating authority;
Current qualified quorum evidence where required;
Current mandatory veto state;
Actual approval-to-operation correspondence;
Current resource and revocation conditions;
Applicable budgets;
Valid scoped non-bearer enablement;
And sink-local protected consumption.
29.31.1 — Quorum Is Not the Sink
The quorum's acceptance cannot replace required sink-side
verification.
29.31.2 — Sink Is Not the Quorum
Where the protected original policy requires collective approval, a
permissive resource state alone does not waive that quorum.
29.31.3 — Separate Predicates
8.6.3.38. Source page 2435 of the original specification
Both sets of mandatory conditions must be established.
29.32 — CONSEQUENTIAL EFFECT INVARIANT
A selected formal eligibility relation may be:
[ \begin{aligned} \operatorname{FinalityEligible}(CA)={}&
\operatorname{SourceAuthorized}(CA)\ &\land
\operatorname{QuorumSatisfied}(CA)\ &\land
\operatorname{NoMandatoryVeto}(CA)\ &\land
\operatorname{CurrentResource}(CA)\ &\land
\operatorname{ActualEffectMatches}(CA)\ &\land
\operatorname{NonBearerEnablementValid}(CA)\ &\land
\operatorname{SinkConsumptionAvailable}(CA) \end{aligned} ]
Das Expires 29 April 2027 [Page 452]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where a quorum is not required, the protected quorum predicate may be
satisfied by the authenticated policy's explicit no-quorum branch.
The proposing agent cannot select that branch merely by declaring its
operation low-risk.
29.33 — MULTIPLE CONSENSUS LAYERS
A protected implementation may use two different types of collective
agreement.
29.33.1 — Evaluation Quorum
Determines whether qualified evaluators accept the particular
Candidate Act under the protected policy.
29.33.2 — State-Replication Consensus
Maintains authoritative quorum records, ownership generations,
resource allowances, or consumption states across a distributed
protected service.
29.33.3 — Independence
One collective decision does not automatically replace the other.
29.33.4 — Security Qualification
A replicated state machine's fault model must not be confused with
the independent decision quality of AI evaluators.
8.6.3.39. Source page 2436 of the original specification
29.34 — INTERMEDIATE QUORUM EFFECTS
An agent workflow may itself perform consequential intermediate
operations.
For example, evaluators may request:
A protected database read;
A credentialed external lookup;
A persistent audit write;
A data disclosure;
Das Expires 29 April 2027 [Page 453]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Or an actual resource mutation.
An intermediate consequential effect remains a separate Candidate Act
where it falls within the protected coverage.
Collective approval of the final requested operation does not
automatically authorize every intermediate resource effect.
This variation may incorporate Embodiments 24, 25, and 28.
29.35 — QUORUM APPROVAL AND DELEGATION
An evaluator may delegate computational analysis to another agent.
The child may return an assessment.
However, the parent cannot automatically transfer its protected
voting authority unless the quorum policy permits qualified
delegation of that role.
29.35.1 — Computational Assistance
May be delegated independently of approval authority.
29.35.2 — Voting Role
Remains bound to current qualified eligibility.
29.35.3 — Additional Evaluator
A newly created child does not independently increase the quorum
count.
29.35.4 — Source Authority
8.6.3.40. Source page 2437 of the original specification
Neither child nor parent acquires permission to override the original
grant merely through additional reasoning.
29.36 — CONCURRENT APPROVALS AND SHARED RESOURCE BUDGETS
Two different Candidate Acts may each obtain sufficient quorum
approval.
However, they may compete for the same protected resource allowance.
For example:
Das Expires 29 April 2027 [Page 454]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A spending policy permits one transfer up to a specified cumulative
amount.
Two committees independently approve separate transfers that together
exceed the allowance.
Both approvals may be authentic.
The protected resource sink enforces the cumulative source budget and
current consumption state.
Quorum approval does not multiply the resource allowance.
This variation may incorporate Embodiment 22 or the shared-authority
conservation mechanisms of Embodiment 28.
29.37 — APPROVAL REVOCATION AND POLICY CHANGE
The originating principal may revoke source permission after quorum
approval.
An evaluator may be removed.
A quorum policy may change.
A device or resource may become ineligible for the approved
operation.
The protected finality controller determines whether the change
invalidates the pending Candidate Act or requires current
revalidation.
Already completed resource effects remain recorded.
Unused affected finality references may become invalid.
An old quorum certificate does not automatically override current
mandatory state.
8.6.3.41. Source page 2438 of the original specification
29.38 — QUORUM CRASH AND RECOVERY
A quorum coordinator may fail after collecting votes.
A durable protected journal may preserve:
The Candidate Act;
Das Expires 29 April 2027 [Page 455]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Accepted vote evidence;
Current quorum generation;
Mandatory veto state;
Prepared finality references;
Consumed finality references;
And actual resource outcomes.
A recovered coordinator may resume qualification under current
protected policy.
It does not automatically generate a new independent effect allowance
merely by reconstructing an approved vote set.
Where an effect may already have been dispatched, the controller
performs qualified outcome reconciliation.
29.39 — FORMAL PROTECTED STATE MACHINE
A non-limiting state machine comprises:
OPERATION_PROPOSED: A computational system creates an operation
proposal.
CANDIDATE_CONSTRUCTED: The protected Candidate Act exists.
NON_EFFECTIVE: The real consequence remains withheld.
QUORUM_POLICY_RESOLVED: The current protected approval requirements
are established.
EVALUATORS_QUALIFIED: Required evaluator identities and roles are
verified.
APPROVAL_CHALLENGE_ISSUED: The operation-specific decision context is
fixed.
VOTES_PENDING: Required evaluations remain incomplete.
VOTES_COLLECTED: Authenticated vote evidence is available.
Das Expires 29 April 2027 [Page 456]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.42. Source page 2439 of the original specification
QUORUM_CONFLICT: Material inconsistent evidence exists.
MANDATORY_VETO: A controlling negative predicate has been
established.
QUORUM_ACCEPTED: Applicable quorum predicates pass.
SOURCE_VALIDATION_PENDING: Current source authority remains to be
independently verified.
EXECUTION_VALIDATION_PENDING: Current actual operation and resource
conditions remain to be checked.
FINALITY_PREPARED: Scoped non-bearer enablement exists.
FINALITY_REVALIDATION_REQUIRED: A material change invalidates earlier
eligibility.
SINK_VERIFICATION_PENDING: The actual receiving resource verifies the
request.
FINALITY_CONSUMED: Protected finality use is committed.
EFFECT_ATTEMPTED: The consequential primitive is released.
EFFECT_CONFIRMED: Qualified actual-effect evidence establishes
completion.
EFFECT_INDETERMINATE: The actual result cannot yet be established.
DENIED: A required authorization or technical predicate failed.
29.40 — COMPLETE COMMON WORKFLOW
Step 1 — Establish Source Authority. Create or reference the
original permitted consequential effect envelope.
Step 2 — Receive Proposed Operation. A model or agent produces a
proposed tool or resource action.
Step 3 — Construct Candidate Act. Identify the material actual
operation fields.
Step 4 — Maintain Non-Effective State. Withhold the covered resource
consequence.
Das Expires 29 April 2027 [Page 457]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 5 — Resolve Quorum Policy. Determine the protected current
approval requirements.
Step 6 — Determine Eligible Evaluators. Authenticate membership,
roles, and required independence evidence.
Step 7 — Construct Canonical Descriptor. Fix the exact operation and
required contextual fields.
8.6.3.43. Source page 2440 of the original specification
Step 8 — Issue Approval Challenge. Bind the decision round to the
Candidate Act and current policy.
Step 9 — Dispatch Qualified Evidence. Supply evaluators with the
required operation and observation context.
Step 10 — Obtain Evaluations. Collect authenticated role-specific
decisions.
Step 11 — Validate Each Vote. Check identity, eligibility, role,
policy generation, and exact Candidate Act commitment.
Step 12 — Detect Equivocation. Identify different operations
masquerading as one proposal.
Step 13 — Evaluate Independence. Check the technical separation
properties required by policy.
Step 14 — Evaluate Mandatory Roles. Verify required specialist or
source-competent participation.
Step 15 — Resolve Conflicts. Apply protected conflict and negative-
decision rules.
Step 16 — Evaluate Vetoes. Reject any operation failing a
controlling mandatory predicate.
Step 17 — Establish Quorum Result. Produce qualifying approval
evidence if the required conditions pass.
Step 18 — Recheck Current Source Authority. Verify that the
originating grant remains valid.
Step 19 — Verify Current Resource. Obtain independent current
resource identity and state.
Das Expires 29 April 2027 [Page 458]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Step 20 — Verify Operation Semantics. Establish the material actual
effect independently of agent descriptions.
Step 21 — Validate Execution-Time Correspondence. Compare current
effect with the approved Candidate Act.
Step 22 — Cross-Commit Evidence. Where selected, bind quorum and
current validation records.
Step 23 — Prepare Scoped Non-Bearer Finality. Establish the specific
protected resource-use authority.
Step 24 — Present Actual Operation. The gateway or resource receives
the effect-capable request.
Step 25 — Reconstruct Actual Effect. The sink determines the real
operation parameters.
8.6.3.44. Source page 2441 of the original specification
Step 26 — Recheck Required Quorum State. Verify policy and approval
eligibility remain current.
Step 27 — Recheck Mandatory Veto State. Refuse effectuation if a
mandatory condition fails.
Step 28 — Verify Current Source Authorization. Confirm the actual
operation remains permitted.
Step 29 — Verify Finality and Consumption. Check scoped enablement,
current resource state, and sink-local use state.
Step 30 — Consume Authority. Commit protected finality consumption.
Step 31 — Release Actual Effect. Perform the authorized
consequential operation.
Step 32 — Record Actual Outcome. Preserve qualified effect evidence
or indeterminate status.
29.41 — REFERENCE ALGORITHM: OPERATION-SPECIFIC QUORUM POLICY
Das Expires 29 April 2027 [Page 459]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
FUNCTION RESOLVE_QUORUM_REQUIREMENTS( candidate_act,
protected_policy_controller ): REQUIRE VERIFY_CANDIDATE_ACT_IDENTITY(
candidate_act ) REQUIRE VERIFY_ORIGINATING_SOURCE_AUTHORITY() effect
= RESOLVE_PROTECTED_ACTUAL_EFFECT_DESCRIPTOR( candidate_act ) policy
= protected_policy_controller .LOAD_CURRENT_QUORUM_POLICY(
effect.operation_class, effect.resource_class ) REQUIRE
VERIFY_POLICY_AUTHENTICITY(policy) REQUIRE
VERIFY_POLICY_CURRENT(policy)
8.6.3.45. Source page 2442 of the original specification
REQUIRE VERIFY_UNTRUSTED_AGENT_CANNOT_RELAX_POLICY() RETURN
PROTECTED_QUORUM_REQUIREMENTS({ candidate: HASH(candidate_act),
policy: HASH(policy), membership_generation:
CURRENT_EVALUATOR_MEMBERSHIP_GENERATION(), mandatory_roles:
policy.required_roles, vetoes: policy.mandatory_vetoes })
The proposing agent does not choose a weaker approval policy
independently.
29.42 — REFERENCE ALGORITHM: EVALUATOR QUALIFICATION
FUNCTION QUALIFY_EVALUATOR( evaluator, candidate_act, quorum_policy,
protected_identity_controller ): REQUIRE
VERIFY_EVALUATOR_IDENTITY(evaluator) REQUIRE
VERIFY_EVALUATOR_CURRENT_ELIGIBILITY( evaluator ) REQUIRE
VERIFY_EVALUATOR_ROLE_FOR_OPERATION( evaluator, candidate_act )
REQUIRE VERIFY_CURRENT_MEMBERSHIP_GENERATION() REQUIRE
VERIFY_REQUIRED_INDEPENDENCE_PROPERTIES( evaluator, quorum_policy )
REQUIRE VERIFY_EVALUATOR_NOT_REVOKED() RETURN
PROTECTED_EVALUATOR_QUALIFICATION({ evaluator: evaluator.identity,
role: evaluator.role, candidate: HASH(candidate_act),
membership_generation:
8.6.3.46. Source page 2443 of the original specification
CURRENT_EVALUATOR_MEMBERSHIP_GENERATION() })
A distinct process or key is not automatically sufficient where the
policy requires independent controlling principals.
29.43 — REFERENCE ALGORITHM: ISSUE OPERATION-BOUND CHALLENGE
FUNCTION ISSUE_APPROVAL_CHALLENGE( candidate_act,
quorum_requirements, protected_approval_controller ): descriptor =
CANONICALIZE_MATERIAL_OPERATION({ candidate: candidate_act, resource:
CURRENT_QUALIFIED_RESOURCE_REFERENCE(), policy:
quorum_requirements.policy, source:
Das Expires 29 April 2027 [Page 460]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
CURRENT_SOURCE_AUTHORITY_REFERENCE(), designated_sink:
RESOLVE_FINALITY_SINK() }) REQUIRE
VERIFY_CANONICALIZATION_UNAMBIGUOUS( descriptor ) challenge =
protected_approval_controller .CREATE_UNIQUE_DECISION_ROUND()
commitment = HASH({ descriptor: descriptor, challenge: challenge,
generation: CURRENT_APPROVAL_GENERATION() }) RETURN
PROTECTED_APPROVAL_ENVELOPE({ operation_commitment: commitment,
descriptor: descriptor, challenge: challenge })
The evaluator signs or otherwise authenticates the protected
commitment corresponding to the defined material operation.
8.6.3.47. Source page 2444 of the original specification
29.44 — REFERENCE ALGORITHM: COLLECT AND VERIFY VOTES
FUNCTION VERIFY_QUORUM_VOTES( candidate_act, approval_envelope,
submitted_votes, protected_quorum_controller ): accepted =
EMPTY_SET() FOR EACH vote IN submitted_votes: REQUIRE
VERIFY_VOTE_AUTHENTICITY(vote) REQUIRE
VERIFY_EVALUATOR_ELIGIBILITY(vote) REQUIRE
VERIFY_VOTE_CURRENT_POLICY_GENERATION(vote) REQUIRE
VERIFY_VOTE_COMMITMENT_EQUALS( vote,
approval_envelope.operation_commitment ) REQUIRE VERIFY_VOTE_ROUND(
vote, approval_envelope.challenge ) REQUIRE
VERIFY_NO_DUPLICATE_EVALUATOR_COUNT( accepted, vote )
ADD_TO_ACCEPTED_SET(accepted, vote) REQUIRE
VERIFY_MANDATORY_ROLE_COVERAGE(accepted) REQUIRE
VERIFY_INDEPENDENCE_POLICY(accepted) REQUIRE
VERIFY_REQUIRED_THRESHOLD(accepted) REQUIRE
VERIFY_NO_UNRESOLVED_MATERIAL_CONFLICT() REQUIRE
VERIFY_NO_MANDATORY_VETO() RETURN PROTECTED_QUORUM_CERTIFICATE({
candidate: HASH(candidate_act), accepted_votes: HASH_SET(accepted),
current_policy: CURRENT_QUORUM_POLICY_GENERATION()
8.6.3.48. Source page 2445 of the original specification
Where a policy treats certain negative results as disqualifying, that
effect is applied before creating a valid approval certificate.
29.45 — REFERENCE ALGORITHM: CONFLICT RESOLUTION
FUNCTION RESOLVE_APPROVAL_CONFLICT( candidate_act,
qualified_vote_set, protected_conflict_controller ): conflicts =
DETECT_MATERIAL_CONFLICTS({ candidate: candidate_act, votes:
qualified_vote_set, resource_state: CURRENT_RESOURCE_EVIDENCE(),
policy: CURRENT_QUORUM_POLICY() }) IF conflicts CONTAIN
MANDATORY_VETO: ACTIVATE_PROTECTED_APPROVAL_FENCE() RETURN DENY IF
Das Expires 29 April 2027 [Page 461]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
conflicts CONTAIN CANDIDATE_EQUIVOCATION:
ACTIVATE_PROTECTED_APPROVAL_FENCE() RETURN
REQUIRE_FRESH_UNAMBIGUOUS_PROPOSAL IF conflicts CONTAIN
MATERIAL_RESOURCE_CHANGE: ACTIVATE_PROTECTED_APPROVAL_FENCE() RETURN
REQUIRE_CURRENT_OPERATION_REVALIDATION IF conflicts CONTAIN
QUALIFIED_NONMATERIAL_DISAGREEMENT: RETURN
APPLY_AUTHORIZED_RESOLUTION_POLICY() IF conflicts CONTAIN
UNRESOLVED_MANDATORY_PREDICATE: RETURN HOLD RETURN
CONSENSUS_CONFLICT_PREDICATES_SATISFIED
A generic numerical majority does not independently clear a mandatory
technical veto.
29.46 — REFERENCE ALGORITHM: FINALITY CONSTITUTION
8.6.3.49. Source page 2446 of the original specification
FUNCTION CONSTITUTE_QUORUM_BOUND_FINALITY( candidate_act,
quorum_certificate, protected_finality_controller ): REQUIRE
VERIFY_QUORUM_CERTIFICATE( quorum_certificate ) REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_CURRENT_QUORUM_POLICY() REQUIRE
VERIFY_CURRENT_EVALUATOR_MEMBERSHIP() REQUIRE
VERIFY_NO_MANDATORY_VETO() actual_effect =
INDEPENDENTLY_RECONSTRUCT_QUALIFIED_OPERATION( candidate_act )
REQUIRE VERIFY_APPROVAL_TO_EFFECT_CORRESPONDENCE( quorum_certificate,
actual_effect ) REQUIRE VERIFY_CURRENT_RESOURCE_STATE(actual_effect)
REQUIRE VERIFY_CURRENT_REVOCATION() validation =
COMMIT_INDEPENDENT_EXECUTION_VALIDATION({ candidate: candidate_act,
actual_effect: actual_effect, quorum: quorum_certificate }) RETURN
protected_finality_controller .PREPARE_SCOPED_NON_BEARER_FINALITY({
candidate: candidate_act, actual_effect: actual_effect,
quorum_validation: HASH(quorum_certificate), execution_validation:
HASH(validation), designated_sink: RESOLVE_ACTUAL_FINALITY_SINK() })
8.6.3.50. Source page 2447 of the original specification
Quorum evidence is necessary only when the protected current policy
requires it.
29.47 — REFERENCE ALGORITHM: ACTUAL RESOURCE SINK
FUNCTION EFFECTUATE_QUORUM_APPROVED_ACT( candidate_act,
quorum_certificate, finality_enablement, actual_finality_sink ):
actual = actual_finality_sink .RECONSTRUCT_PENDING_REAL_OPERATION()
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_ACTUAL_OPERATION_WITHIN_SOURCE_SCOPE( actual ) REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
Das Expires 29 April 2027 [Page 462]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
VERIFY_QUORUM_CURRENT_AND_APPLICABLE( quorum_certificate,
candidate_act ) REQUIRE VERIFY_APPROVED_ACT_EQUALS_ACTUAL_EFFECT(
quorum_certificate, actual ) REQUIRE VERIFY_NO_MANDATORY_VETO()
REQUIRE VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() REQUIRE
VERIFY_CURRENT_SHARED_RESOURCE_BUDGET() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_enablement, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE() committed =
actual_finality_sink .COMMIT_FINALITY_AND_RESOURCE_CONDITIONS(
8.6.3.51. Source page 2448 of the original specification
finality_enablement, actual ) IF committed != COMMITTED: RETURN DENY
RETURN actual_finality_sink
.RELEASE_CONTROLLED_ACTUAL_OPERATION(actual)
Where the actual resource does not support local atomic consumption
and effectuation, protected dispatch and qualified outcome
reconciliation are required.
29.48 — REFERENCE ALGORITHM: MEMBERSHIP CHANGE
FUNCTION HANDLE_QUORUM_RECONFIGURATION( previous_policy,
current_policy, protected_controller ): REQUIRE
VERIFY_CURRENT_POLICY_CHANGE_AUTHORITY() difference =
CLASSIFY_MATERIAL_QUORUM_POLICY_CHANGE( previous_policy,
current_policy ) affected =
IDENTIFY_PENDING_CANDIDATES_DEPENDENT_ON_CHANGE( difference ) IF
difference == MATERIAL: ACTIVATE_RECONFIGURATION_FENCE(affected)
INVALIDATE_INCOMPATIBLE_APPROVAL_CERTIFICATES( affected ) REQUIRE
QUALIFY_NEW_MEMBERSHIP_AND_ROLES() REQUIRE
CURRENT_APPROVAL_REVALIDATION(affected) RETURN
CURRENT_QUORUM_POLICY_GENERATION()
8.6.3.52. Source page 2449 of the original specification
A key rotation or membership update does not automatically invalidate
already completed historical resource effects.
29.49 — REFERENCE ALGORITHM: QUORUM FAILURE RECOVERY
FUNCTION RECOVER_QUORUM_OPERATION( logical_operation,
protected_journal, qualified_resource_observer ): state =
protected_journal .LOAD_AUTHORITATIVE_OPERATION_STATE(
logical_operation ) REQUIRE VERIFY_STATE_AUTHENTICITY(state) REQUIRE
VERIFY_CURRENT_SOURCE_AND_QUORUM_STATE() IF
QUALIFIED_ACTUAL_EFFECT_COMPLETED(state): RETURN
PRESERVE_COMPLETED_EFFECT IF EFFECT_MAY_HAVE_BEEN_DISPATCHED(state):
observed = qualified_resource_observer
Das Expires 29 April 2027 [Page 463]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
.OBTAIN_CURRENT_RESOURCE_OUTCOME( logical_operation ) IF
VERIFY_QUALIFIED_COMPLETION(observed): RETURN COMMIT_CONFIRMED_EFFECT
IF VERIFY_QUALIFIED_NON_EFFECT(observed): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION RETURN
PRESERVE_INDETERMINATE_EFFECT_STATE RETURN
REQUIRE_CURRENT_APPROVAL_AND_FINALITY_ELIGIBILITY
A quorum timeout does not establish that a previous real operation
failed.
29.50 — WORKED EXAMPLE A: THREE AGENTS APPROVE UNAUTHORIZED PAYMENT
8.6.3.53. Source page 2450 of the original specification
Three autonomous evaluators recommend a financial transfer.
Each produces a valid authenticated approval.
The originating principal authorized financial analysis but not
payment execution.
The protected quorum resolver may determine that the numerical
approval threshold was satisfied.
The independent source-authority controller determines that payment
authorization is absent.
The actual payment sink refuses the transfer.
Expected demonstrable result: A valid computational quorum does not
independently create missing financial execution authority.
29.51 — WORKED EXAMPLE B: DIFFERENT PAYMENT AMOUNTS
Evaluator A approves a payment of one amount.
Evaluator B approves another amount.
Evaluator C approves a third amount.
The proposer presents the votes as one approval set.
The operation-bound commitments differ.
The protected resolver refuses to count the votes as one common
Candidate Act approval.
Das Expires 29 April 2027 [Page 464]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected demonstrable result: Individually authentic votes for
different actual operations cannot be combined into a false quorum.
29.52 — WORKED EXAMPLE C: VALID QUORUM, WRONG RECIPIENT
A protected committee approves a transfer to Recipient R1.
The executing agent changes the destination to R2.
The quorum certificate remains authentic for R1.
The actual payment sink reconstructs R2 as the pending recipient.
The operation does not correspond to the approved Candidate Act.
The transfer is refused.
8.6.3.54. Source page 2451 of the original specification
Expected demonstrable result: Quorum approval cannot be rebound to a
different actual recipient.
29.53 — WORKED EXAMPLE D: MANDATORY SECURITY VETO
Four advisory agents approve a cloud-resource change.
A mandatory protected policy validator determines that the actual
operation violates a source-authorized restriction.
The quorum policy defines the validator's failure as a controlling
veto.
The protected controller refuses finality despite the affirmative
advisory majority.
Expected demonstrable result: Numerical approval does not override
mandatory protected security predicates.
29.54 — WORKED EXAMPLE E: SAME MODEL, MULTIPLE INSTANCES
Five evaluator processes are launched.
All use the same underlying model configuration and data source.
The protected quorum policy requires separation across specified
independent evaluation infrastructures.
Das Expires 29 April 2027 [Page 465]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The controller identifies that the required independence properties
have not been established.
The votes do not satisfy the qualified independence requirement.
Expected demonstrable result: Merely increasing the number of agent
processes does not necessarily satisfy a protected independent-quorum
condition.
29.55 — WORKED EXAMPLE F: ROLE-CONSTRAINED APPROVAL
Three risk-analysis agents approve a proposed transfer.
The protected policy requires one source-competent financial
authorizer.
None of the three risk-analysis agents possesses that role.
The quorum result remains insufficient for effectuation.
8.6.3.55. Source page 2452 of the original specification
Expected demonstrable result: A numerical threshold cannot replace a
mandatory qualified approval role.
29.56 — WORKED EXAMPLE G: QUORUM MEMBERSHIP CHANGE
A committee approves a database mutation.
Before the mutation occurs, a mandatory evaluator is removed because
its authorization is revoked.
The current protected quorum policy requires requalification of the
approval.
The old certificate is no longer sufficient.
The operation remains withheld until current mandatory approval
conditions are established.
Expected demonstrable result: Historical approval authenticity does
not independently establish current evaluator eligibility.
29.57 — WORKED EXAMPLE H: RESOURCE VERSION CHANGE
A quorum approves modification of Resource Version 12.
Das Expires 29 April 2027 [Page 466]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Before execution, another authorized process changes the resource to
Version 13.
The sink checks the current resource generation.
The approval is not automatically applicable to the changed state.
The operation is revalidated or refused under the protected policy.
Expected demonstrable result: A valid quorum decision based on stale
resource state cannot silently authorize an incompatible actual
resource mutation.
29.58 — WORKED EXAMPLE I: CONFLICTING QUORUM CERTIFICATES
One valid evaluator set approves deleting a resource.
Another valid evaluator set approves preserving or modifying it.
Both operations reference the same logical resource state.
The protected conflict controller identifies incompatible Candidate
Acts.
8.6.3.56. Source page 2453 of the original specification
The actual resource sink applies an authoritative conflict or version
rule.
A conflicting effect is refused or held according to the current
protected decision state.
Expected demonstrable result: Individually valid quorum certificates
do not automatically authorize incompatible simultaneous resource
effects.
29.59 — WORKED EXAMPLE J: QUORUM SIGNATURE REPLAY
A committee produces a valid cryptographic signature over one
Candidate Act.
An attacker later presents the signature during another task.
The new task has a different approval round or source-authority
generation.
The protected controller rejects the mismatched context.
Das Expires 29 April 2027 [Page 467]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected demonstrable result: A valid historical signature cannot be
reused as unrestricted current finality.
29.60 — WORKED EXAMPLE K: HUMAN AND AI REVIEW
An autonomous system proposes publishing a confidential report.
Two technical evaluators validate selected release conditions.
A source-competent human reviews a transaction-bound presentation and
approves the specified destination.
The protected gateway verifies the actual document and recipient.
The report is released only when the required human, technical, and
sink-side conditions pass.
Expected demonstrable result: Human authorization, machine
evaluation, and actual resource enforcement cooperate without any one
being treated as a substitute for the others.
29.61 — WORKED EXAMPLE L: HIDDEN INTERMEDIATE EFFECT
An agent committee approves production of an analytical report.
During report preparation, a child tool attempts an unauthorized
confidential data upload.
The final report approval does not encompass that separate
intermediate disclosure.
8.6.3.57. Source page 2454 of the original specification
The protected egress sink constructs or checks its own Candidate Act
and refuses the unauthorized upload.
Expected demonstrable result: Final-result approval does not
automatically authorize consequential intermediate tool effects.
29.62 — WORKED EXAMPLE M: TWO QUORUMS, ONE SPENDING ALLOWANCE
Two independent qualified committees approve separate purchases.
Both proposed purchases are individually within a nominal per-
operation limit.
Together they exceed the source-authorized cumulative spending
allowance.
Das Expires 29 April 2027 [Page 468]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protected payment sink checks current shared budget state.
An operation exceeding the remaining authorized allowance is refused.
Expected demonstrable result: Multiple qualified quorums cannot
multiply the original financial budget.
29.63 — WORKED EXAMPLE N: HARDWARE CONTROL QUORUM
Several computational evaluators approve a proposed device movement.
Before actuation, the actual device state changes.
The protected device sink verifies the current command, device
identity, and mandatory current safety predicates.
A command failing the mandatory conditions is refused despite quorum
agreement.
Expected demonstrable result: Approval of a proposed physical command
does not substitute for current device-side finality verification.
29.64 — WORKED EXAMPLE O: COMPROMISED THRESHOLD GROUP
A threshold signing group produces a cryptographically valid
signature.
The signed operation exceeds the originating principal's
authorization.
The resource Finality Sink independently checks current source
permission.
8.6.3.58. Source page 2455 of the original specification
The operation is refused.
Expected demonstrable result: A valid threshold signature is not
sufficient authority for a different or otherwise unauthorized real
resource operation.
29.65 — WORKED EXAMPLE P: AUTHORIZED AUTOMATIC OPERATION
The originating principal authorizes a bounded low-impact operation.
The current protected policy does not require collective approval for
this class.
Das Expires 29 April 2027 [Page 469]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The Candidate Act still undergoes current authority and resource
validation.
The actual Finality Sink verifies scoped non-bearer enablement and
protected consumption.
The operation may proceed without an advisory agent quorum.
Expected demonstrable result: The architecture does not make
collective approval universally necessary where the valid protected
policy does not require it.
29.66 — WORKED EXAMPLE Q: APPROVAL COORDINATOR CRASH
A quorum coordinator collects sufficient approvals.
The actual operation reaches its resource sink and is dispatched.
The coordinator crashes before receiving the final result.
After restart, the approval certificate is recovered.
However, the protected finality journal records that the operation
may already have occurred.
The coordinator reconciles the actual resource outcome rather than
authorizing a fresh duplicate effect.
Expected demonstrable result: Quorum recovery does not resurrect
consumed or uncertain consequential authority.
29.67 — WORKED EXAMPLE R: CROSS-DOMAIN QUORUM
An enterprise task requires evaluation by different administrative
services.
Each provides an authenticated operation-bound result.
8.6.3.59. Source page 2456 of the original specification
A protected policy checks the required identities, roles, and current
policy generation.
The actual destination resource independently verifies the approved
operation and source grant.
Das Expires 29 April 2027 [Page 470]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected demonstrable result: Cross-domain approval can contribute
qualified evidence without replacing the destination's operation-
specific authorization.
29.68 — WORKED EXAMPLE S: NEW OPERATION AFTER REJECTION
An initial Candidate Act requests a database deletion.
A mandatory reviewer rejects it.
The proposer revises the task to request a non-destructive read.
The new operation has a different material effect.
The protected controller constructs a new Candidate Act and obtains
whatever current authorization and evaluation the new operation
requires.
Expected demonstrable result: A rejected operation cannot be made
valid merely by relabeling it; a genuinely changed operation is
evaluated on its own protected terms.
29.69 — WORKED EXAMPLE T: FALSE RESOURCE EVIDENCE
Three evaluators independently process the same inaccurate resource
snapshot.
All approve the proposed operation.
At the actual resource sink, current resource evidence contradicts
the earlier snapshot.
The mandatory sink-side predicate fails.
The operation remains withheld.
Expected demonstrable result: Agreement among evaluators sharing
flawed evidence cannot substitute for current actual-resource
observation.
29.70 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Quorum of unauthorized agents. 2. Artificially multiplied
evaluator identities. 3. Duplicate counting of one evaluator.
Das Expires 29 April 2027 [Page 471]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.60. Source page 2457 of the original specification
4. Shared administrative credential compromise. 5. Shared model
failure. 6. Shared input-data poisoning. 7. Common policy-service
compromise. 8. Proposer equivocation. 9. Different amounts approved
by different voters. 10. Different recipients approved by different
voters. 11. Material fields omitted from the signed descriptor. 12.
Ambiguous operation canonicalization. 13. Unsupported semantic
equivalence. 14. Revoked evaluator participation. 15. Stale
committee membership. 16. Unauthorized threshold reduction. 17.
Mandatory role substitution. 18. Missing independent reviewer. 19.
Improper advisory-to-authority promotion. 20. Human authentication
mistaken for transaction approval. 21. Approval message replay. 22.
Cross-task approval reuse. 23. Vote reuse across decision rounds.
24. Stale resource state. 25. Resource rebinding. 26. Changed
target identity. 27. Changed request method. 28. Changed request
body. 29. Changed tool semantics. 30. Changed runtime generation.
31. Conflicting quorum certificates. 32. Concurrent incompatible
operations. 33. Quorum membership reconfiguration race. 34. Old
signing key retained after revocation. 35. Threshold group-key
misuse. 36. Forged participant manifest. 37. Missing individual
attribution. 38. Mandatory veto bypass. 39. Majority override of
source authority. 40. Manipulated consequence-risk classification.
41. Approval policy downgrade. 42. Loss of negative votes. 43.
Incorrect treatment of abstentions. 44. Signed result with an
omitted critical predicate. 45. Untrusted agent clearing a conflict
fence. 46. Replayed non-bearer finality reference. 47. Shared
budget double consumption. 48. Multiple approval committees
multiplying resource allowance. 49. Hidden intermediate network
disclosure. 50. Hidden database side effect. 51. Credential broker
confused deputy. 52. Device state changed after approval. 53.
Remote resource operation differing from the approved request.
8.6.3.61. Source page 2458 of the original specification
54. Quorum coordinator crash after dispatch. 55. Lost resource
acknowledgement. 56. Recovered approval with consumed finality. 57.
Incorrect global exactly-once assumption. 58. Threshold protocol
nonce reuse. 59. Unqualified remote evaluator. 60. Evaluation-key
rotation mismatch. 61. Distributed consensus partition. 62.
Inconsistent policy replicas. 63. Quorum denial-of-service. 64.
Endless conflict-resolution loop. 65. Verification exhaustion. 66.
Uncontrolled resource-effectuation bypass. 67. Compromised Finality
Sink. 68. Compromised originating authority service. 69. Unverified
current revocation. 70. False interpretation of computational
agreement as proof of safe or permitted real-
world effect.
Das Expires 29 April 2027 [Page 472]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The protection claimed by a particular implementation must be
evaluated within its actual integrity, quorum, cryptographic,
resource-consistency, and enforcement assumptions.
29.71 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following experiments are proposed technical demonstrations, not
claims that tests have already been executed.
Test 1 — Source Authority: Establish one originating consequential
effect grant.
Test 2 — Candidate Act: Construct a protected operation descriptor.
Test 3 — Non-Effective Hold: Verify that the operation cannot yet
affect the resource.
Test 4 — Quorum Policy: Load an authenticated current policy.
Test 5 — Eligible Membership: Authenticate a set of permitted
evaluators.
Test 6 — Invalid Evaluator: Refuse a vote from an unauthorized agent.
Test 7 — Distinct Identity: Prevent one evaluator from being counted
repeatedly.
Test 8 — Sybil Process: Run several processes controlled by one
qualified identity.
Test 9 — Role Coverage: Enforce mandatory role-specific approval.
Test 10 — Independence Profile: Verify required cross-domain
separation.
8.6.3.62. Source page 2459 of the original specification
Test 11 — Same-Model Dependence: Demonstrate that process
multiplicity alone does not prove required independence.
Test 12 — Canonical Descriptor: Encode the exact material operation.
Test 13 — Ambiguous Serialization: Provide two interpretations of one
field.
Test 14 — Missing Material Field: Omit the payment destination from a
proposed approval commitment.
Das Expires 29 April 2027 [Page 473]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 15 — Protected Challenge: Bind votes to a unique decision round.
Test 16 — Valid Vote: Verify an eligible authenticated approval.
Test 17 — Replayed Vote: Reuse a vote in another decision round.
Test 18 — Different Candidate: Present valid votes for different
effects as one quorum.
Test 19 — Equivocation Detection: Identify inconsistent candidate
commitments.
Test 20 — Numerical Threshold: Verify the configured count.
Test 21 — Role-Constrained Threshold: Reject an approval set missing
a mandatory role.
Test 22 — Negative Decision: Evaluate a qualified technical
rejection.
Test 23 — Mandatory Veto: Refuse effectuation despite an affirmative
majority.
Test 24 — Nonmandatory Disagreement: Apply a defined protected
conflict policy.
Test 25 — Conflicting Quorums: Approve incompatible operations
concerning one resource state.
Test 26 — Resource Serialization: Ensure conflicting effects cannot
both violate the current resource constraint.
Test 27 — Current Membership: Remove an evaluator after initial
approval.
Test 28 — Key Revocation: Reject affected historical key authority.
Test 29 — Policy Update: Change the required threshold before
effectuation.
Test 30 — Reconfiguration Fence: Hold affected pending operations.
Test 31 — Threshold Signature: Produce an operation-bound threshold
signature using a compliant implementation.
Test 32 — Participant Manifest: Verify separately required
participant and role evidence.
Das Expires 29 April 2027 [Page 474]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.63. Source page 2460 of the original specification
Test 33 — Aggregate Signature Limitation: Show that a group signature
does not inherently supply individual role attribution.
Test 34 — Approval-to-Effect Change: Modify the recipient after a
valid quorum decision.
Test 35 — Amount Change: Modify the authorized amount.
Test 36 — Resource Change: Rebind a logical resource name.
Test 37 — Request Body Change: Modify outgoing consequential content.
Test 38 — Current Source Revocation: Revoke the original grant after
quorum approval.
Test 39 — Resource Version: Change the resource between approval and
finality.
Test 40 — Qualified Equivalence: Test a specifically permitted
nonmaterial transformation.
Test 41 — Actual Sink Reconstruction: Independently obtain the real
resource operation.
Test 42 — Quorum Certificate: Verify its binding to the actual
Candidate Act.
Test 43 — Non-Bearer Finality: Establish scoped finality separately
from the quorum certificate.
Test 44 — Sink-Local Consumption: Consume operation-specific
authority.
Test 45 — Replay: Attempt additional effects using the same finality
reference.
Test 46 — Budget Competition: Present two separately quorum-approved
operations against one resource allowance.
Test 47 — Intermediate Effect: Attempt an unauthorized side effect
during evaluation.
Test 48 — Human Approval: Verify a source-competent participant's
transaction-bound authorization.
Das Expires 29 April 2027 [Page 475]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 49 — Human Identity Only: Demonstrate that authentication
without valid transaction approval remains insufficient.
Test 50 — Machine Recommendation: Produce a unanimous advisory
recommendation outside source scope.
Test 51 — Mandatory Technical Failure: Generate quorum approval
despite an actual resource-policy failure.
Test 52 — Device State Change: Modify actual hardware state after
approval.
Test 53 — Cross-Domain Evaluators: Collect qualified votes across
independent service domains.
8.6.3.64. Source page 2461 of the original specification
Test 54 — Evaluator Delegation: Attempt to transfer voting authority
to an unauthorized child.
Test 55 — Coordinator Crash: Fail the quorum collector before
finality.
Test 56 — Crash After Consumption: Fail the coordinator after the
sink may have dispatched an operation.
Test 57 — Outcome Reconciliation: Verify completed or uncertain
external effect state.
Test 58 — Approval Recovery: Restore a protected certificate without
restoring consumed authority.
Test 59 — Automatic Policy Branch: Verify an authorized operation not
requiring a quorum.
Test 60 — Unauthorized Quorum Waiver: Attempt to reclassify the
operation into a weaker policy class.
Test 61 — Removal of Source Check: Evaluate whether agents can
approve otherwise unauthorized operations.
Test 62 — Removal of Candidate Binding: Evaluate whether votes can be
reused for different operations.
Test 63 — Removal of Role Qualification: Evaluate whether numerical
majority replaces mandatory source-competent approval.
Das Expires 29 April 2027 [Page 476]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Test 64 — Removal of Conflict Fence: Evaluate whether incompatible
certificates can both remain effective.
Test 65 — Removal of Current Membership Check: Test stale-voter
authority.
Test 66 — Removal of Resource Revalidation: Test approval based on
stale actual resource state.
Test 67 — Removal of Sink Reconstruction: Test a changed real request
after quorum approval.
Test 68 — Removal of Non-Bearer Finality: Test replay or uncontrolled
transfer of quorum evidence.
Test 69 — Removal of Consumption: Test duplicate resource effects
after quorum approval.
Test 70 — Removal of Mandatory Veto: Test unauthorized majority
override.
Test 71 — Quorum Exhaustion: Bound verification work for a large
committee.
Test 72 — Conflicting Proposal Flood: Bound repeated material
conflict resolution.
8.6.3.65. Source page 2462 of the original specification
Test 73 — Parallel Approval Rounds: Prevent cross-round mixing.
Test 74 — Full Mixed Human/Machine Workflow: Combine advisory
evaluation, source-competent approval, current resource validation,
and actual sink finality.
Test 75 — Complete Adversarial Workflow: Combine candidate
equivocation, quorum membership change, conflicting votes, source
revocation, current resource change, and actual Finality-Sink
enforcement.
29.71.1 — Proposed Measurements
The experiments may measure:
Unauthorized completed resource effects;
Mismatched operation rejection;
Das Expires 29 April 2027 [Page 477]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Quorum qualification correctness;
Duplicate evaluator detection;
Membership generation enforcement;
Mandatory-veto effectiveness;
Conflicting certificate handling;
Approval-to-actual-effect correspondence;
Finality replay resistance;
Resource budget conservation;
Recovery correctness;
Evaluation latency;
And protected quorum-processing overhead.
29.71.2 — Comparative Ablation
A useful comparison comprises:
Configuration A — Simple Majority: Several agents vote on an
operation and the result is dispatched.
Configuration B — Authenticated Quorum: Votes are identity-bound and
operation-specific.
8.6.3.66. Source page 2463 of the original specification
Configuration C — Protected Quorum Finality: Current eligibility,
role and independence requirements, conflict and veto controls,
original source authority, current resource validation, non-bearer
finality, and actual sink-local consumption are all enforced.
The decisive technical measurement is whether a resource accepts a
consequential effect that does not meet the originating source
authority and applicable actual-operation constraints.
29.71.3 — Experimental Caution
Agreement between models is not proof of correctness.
Das Expires 29 April 2027 [Page 478]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A blocked unauthorized resource effect is evidence for the tested
enforcement path, not proof that no other bypass exists.
A threshold signature is evidence of the cryptographic statement it
authenticates, not universal proof of independent human or machine
approval.
29.72 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
29.72.1 — Minimum Components
A reference prototype may comprise:
Three evaluator processes;
One protected source-authority registry;
One protected quorum-policy registry;
One Candidate Act gateway;
A transactional approval ledger;
A protected finality controller;
And one test-resource API capable of enforcing current operation
parameters and consumption.
29.72.2 — Original Task
A principal authorizes one selected record update.
29.72.3 — Proposed Operation
An agent constructs a Candidate Act specifying the record, authorized
mutation, and expected resource generation.
29.72.4 — Protected Hold
8.6.3.67. Source page 2464 of the original specification
The gateway withholds the actual update.
29.72.5 — Approval Context
The quorum controller creates a canonical Candidate Act approval
commitment and fresh challenge.
Das Expires 29 April 2027 [Page 479]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.72.6 — Evaluation
Three evaluators receive the protected descriptor.
29.72.7 — Votes
Each qualified evaluator returns an authenticated decision over the
same commitment.
29.72.8 — Quorum Resolution
The controller verifies current roles, threshold, and applicable
independence conditions.
29.72.9 — Current Authority
The original source grant remains valid.
29.72.10 — Finality
The finality service prepares scoped non-bearer enablement.
29.72.11 — Actual Sink
The resource service reconstructs the pending mutation and checks the
actual record identity and current version.
29.72.12 — Consumption
The resource consumes the protected finality allowance.
29.72.13 — Authorized Result
The permitted record is updated.
29.72.14 — Adversarial Mutation
The proposed update is changed to a different record after quorum
approval.
29.72.15 — Expected Result
The actual sink refuses the different operation.
29.72.16 — Adversarial Quorum
Das Expires 29 April 2027 [Page 480]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.68. Source page 2465 of the original specification
All three evaluators approve a different operation not permitted by
the original source grant.
29.72.17 — Expected Result
The independent source-authority and sink checks refuse it.
29.72.18 — Mandatory Veto
A protected resource-state validator rejects the operation despite
affirmative votes.
29.72.19 — Expected Result
The veto prevents finality.
29.72.20 — Replay
The same quorum certificate and finality reference are presented
again.
29.72.21 — Expected Result
The protected resource rejects unauthorized duplicate use.
29.73 — OPTIONAL ADVANCED VARIATIONS
29.73.1 — Independent Model Evaluation
Several model instances assess one Candidate Act.
29.73.2 — Heterogeneous Evaluator Roles
Different technical validators establish different mandatory
predicate classes.
29.73.3 — Human/Machine Quorum
Qualified human permission may be combined with independent technical
evaluation.
29.73.4 — Source-Competent Multi-Principal Grant
Several independently competent authorizers may jointly establish a
specific source permission.
Das Expires 29 April 2027 [Page 481]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.73.5 — Threshold Signature
A compliant threshold cryptographic procedure may authenticate an
operation-specific commitment.
29.73.6 — Individually Signed Votes
8.6.3.69. Source page 2466 of the original specification
Each evaluator may produce a separately verifiable signature.
29.73.7 — Hardware-Backed Approval
Protected execution or key custody may secure selected evaluator
identities.
29.73.8 — Resource-Generation Binding
Approval eligibility may depend upon current actual resource state.
29.73.9 — Mandatory Veto
A selected protected condition may prohibit effectuation regardless
of majority vote.
29.73.10 — Dynamic Membership
Committee changes may trigger current approval revalidation.
29.73.11 — Heterogeneous Input Evidence
Evaluators may receive qualified independently acquired resource
evidence.
29.73.12 — Conflict Fence
Material disagreement may withhold the corresponding effect.
29.73.13 — Parallel Quorum Resolution
Different operations may be evaluated concurrently subject to
resource-conflict and budget checks.
29.73.14 — Cross-Domain Committee
Evaluators may operate in different administrative domains.
29.73.15 — Quorum for Credential Use
Das Expires 29 April 2027 [Page 482]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A protected credential broker may require applicable approval
evidence for selected operations.
29.73.16 — Quorum for Deployment
A protected release sink may require operation-bound review of an
actual deployment.
29.73.17 — Quorum for Data Disclosure
A protected egress sink may verify approved content and recipient.
29.73.18 — Quorum for Financial Effects
8.6.3.70. Source page 2467 of the original specification
A payment sink may verify current amount, recipient, principal, and
budget.
29.73.19 — Quorum for Device Commands
A protected actuator may verify current command and mandatory device-
state conditions.
29.73.20 — Receipt-Dependent Consensus
A selected operation may require both quorum evidence and an accepted
qualified real-effect receipt from a prior operation.
29.74 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
29.74.1 — Existing Foundations
Distributed consensus, threshold signatures, multi-signature
approval, committee membership, separation of duties, human approval,
operation signing, resource-version checks, and transaction ledgers
are established concepts.
These may be used as implementation substrates.
29.74.2 — Candidate Objective Technical Problem
How to incorporate collective autonomous decision approval into
protected consequential resource execution without permitting
numerically sufficient but unauthorized, ambiguous, stale,
conflicting, or operation-mismatched quorum decisions to cause
effects outside current originating source authority.
Das Expires 29 April 2027 [Page 483]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.74.3 — Proposed Technical Solution
A consequential proposal is represented as a non-effective Candidate
Act.
A protected quorum policy selects eligible evaluator identities,
roles, independence predicates, current membership, and mandatory
vetoes.
Evaluators authenticate decisions over one unambiguous operation-
specific commitment.
A protected resolver rejects inconsistent vote sets, unsupported
identity counts, invalid roles, and material conflicts.
The accepted quorum result is independently checked against current
originating authority and actual resource state.
A protected controller prepares scoped non-bearer finality.
The actual Finality Sink reconstructs the pending consequential
operation and verifies exact operation correspondence, source
authority, current quorum and veto state, resource conditions, and
protected consumption before permitting the effect.
8.6.3.71. Source page 2468 of the original specification
29.74.4 — Not Merely Majority Voting
Majority voting determines a collective result under configured
voting rules.
The proposed combination prevents a valid majority from substituting
for independent current source and resource authority.
29.74.5 — Not Merely Threshold Cryptography
Threshold cryptography authenticates selected committed messages.
The proposed combination additionally establishes current role
qualification, actual operation semantics, protected source
permission, and sink-side finality.
29.74.6 — Not Merely Human Approval
A human approval may be one required predicate.
Das Expires 29 April 2027 [Page 484]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The actual receiving resource remains responsible for verifying the
protected operation and applicable mandatory technical state.
29.74.7 — Not Merely Policy Validation
A policy engine may evaluate authorization.
The proposed combination also binds required collective evidence to
the exact Candidate Act and its independent actual effectuation.
29.74.8 — Not Merely a Distributed Ledger
A replicated ledger may consistently record approval.
The proposed combination separates ledger agreement from authority to
produce an actual resource consequence.
29.74.9 — Candidate Narrow Inventive Kernel
A protected autonomous multi-agent approval-finality system in which
a consequential Candidate Act is maintained non-effective, a
protected controller qualifies operation-specific votes under current
authenticated quorum membership, role, independence, conflict, and
veto conditions, a separate validator establishes current originating
source authority and actual resource correspondence, and an
independent Finality Sink reconstructs the pending consequential
operation and permits effectuation only upon verification of the same
approved act, applicable current quorum state, scoped non-bearer
finality, and protected sink-local consumption.
29.74.10 — Equivocation-Prevention Kernel
8.6.3.72. Source page 2469 of the original specification
A narrower candidate may require proof that all qualifying approval
evidence identifies one identical material Candidate Act and that the
actual sink reconstructs the same operation before release.
29.74.11 — Mandatory Veto Kernel
Another candidate may require a protected quorum procedure in which
no affirmative vote threshold can override designated source-
authority or independently established safety and resource
predicates.
29.74.12 — Membership-Fencing Kernel
Das Expires 29 April 2027 [Page 485]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Another candidate may require invalidation of dependent pending
finality following material quorum membership, role, or policy
changes, with current sink-side enforcement.
29.74.13 — Conflicting-Quorum Kernel
Another candidate may require protected conflict detection and
resource-side consumption or version checks preventing incompatible
quorum-approved operations from both producing prohibited resource
effects.
29.74.14 — Threshold-Evidence Kernel
Another candidate may combine a threshold cryptographic approval of a
Candidate Act with separately qualified participant-role evidence,
current source authority, and actual sink operation reconstruction.
29.74.15 — Hindsight and Functional-Combination Analysis
A later inventive-step response should identify the closest existing
system providing multi-party or threshold approval over consequential
operations.
The mere presence of a threshold signature, consensus protocol,
policy engine, and execution gateway should not be treated as
sufficient proof of invention.
The technical analysis should examine whether the earlier system
already discloses the specific mandatory relationship among:
A canonical consequential Candidate Act;
Current qualified quorum composition;
Operation-specific approval binding;
Mandatory conflict and veto resolution;
Independent original source authority;
Current actual resource reconstruction;
8.6.3.73. Source page 2470 of the original specification
Separate scoped non-bearer finality;
And sink-local protected consumption.
Das Expires 29 April 2027 [Page 486]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The candidate technical effect is that an operation may be
unanimously or cryptographically approved yet remain incapable of
producing an unauthorized different real consequence.
A corresponding ablation experiment should deliberately create valid-
looking quorum evidence for a changed or unauthorized operation and
evaluate the actual resource result.
The technical argument should explain why the claimed protected
dependencies achieve that effect and distinguish them from the
mechanisms already taught by the closest prior art.
It must not rely solely upon describing the arrangement as non-
obvious, secure, or inventive.
29.75 — INDUSTRIAL APPLICABILITY
29.75.1 — Autonomous Enterprise Operations
Qualified multi-agent decisions may be separated from actual resource
authority.
29.75.2 — Financial Services
Payment approvals may be bound to current source, recipient, amount,
and finality state.
29.75.3 — Cloud Infrastructure
Multiple evaluators may review infrastructure changes while actual
resource operations remain independently controlled.
29.75.4 — Software Deployment
Release approval may be tied to the actual artifact and target
environment.
29.75.5 — Database Administration
Multi-party approvals may govern sensitive resource mutations.
29.75.6 — Data Protection
Collective disclosure review may remain bound to the actual recipient
and outgoing content.
29.75.7 — Credential Management
Das Expires 29 April 2027 [Page 487]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Privileged credential use may require qualifying approval and current
effect authorization.
29.75.8 — Electronic Commerce
8.6.3.74. Source page 2471 of the original specification
Agent recommendations may be separated from purchase execution
authority.
29.75.9 — Supply-Chain Operations
Procurement and fulfillment operations may be independently validated
after automated review.
29.75.10 — Network Management
Several automated reviewers may qualify configuration proposals
before protected resource mutation.
29.75.11 — Telecommunications
Autonomous network changes may require current actual-effect
validation beyond committee agreement.
29.75.12 — Industrial Automation
Approved control proposals may remain subject to device-side
mandatory conditions.
29.75.13 — Robotics
Multi-agent motion or actuation decisions may remain distinct from
physical command authority.
29.75.14 — Autonomous Transportation
Planning consensus may contribute to, but not replace, qualified
actuation predicates.
29.75.15 — Satellite and Remote Systems
Distributed approval may be applied to protected delayed commands.
29.75.16 — Hardware Infrastructure
Protected resource controllers may independently verify quorum-
authorized operations.
Das Expires 29 April 2027 [Page 488]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.75.17 — Security Administration
Sensitive access and policy changes may require source-competent
approval and protected actual effectuation.
29.75.18 — Persistent AI Memory
Multi-agent decisions concerning shared memory updates may be checked
at the actual persistence sink.
29.75.19 — Cross-Organization Workflow
8.6.3.75. Source page 2472 of the original specification
Separate administrative evaluators may provide qualified evidence
under an authenticated common policy.
29.75.20 — Future Autonomous Critical Systems
Collective machine judgment may remain subordinate to protected
resource-specific authority and current finality.
29.76 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
29.76.1 — Candidate Independent System Claim
A system comprising:
A protected source-authority controller maintaining current
originating permission for a consequential operation;
A Candidate Act controller constructing a material operation
descriptor and maintaining the corresponding actual effect in a Non-
Effective State;
A protected quorum controller qualifying evaluator identities,
current membership generations, required roles, operation-specific
votes, and mandatory conflict or veto predicates;
An independent source and execution-time validator determining
current authority and actual-operation correspondence;
A finality controller establishing scoped non-bearer finality
enablement;
Das Expires 29 April 2027 [Page 489]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
And an independent Finality Sink reconstructing the actual pending
resource operation and permitting effectuation only upon verification
of current source authority, valid quorum evidence where required,
actual approved-operation correspondence, protected finality, and
sink-local consumption.
29.76.2 — Candidate Independent Method Claim
A method comprising:
Establishing a protected source-authorized effect envelope;
Constructing a non-effective Candidate Act;
Determining a protected current quorum policy;
Qualifying evaluators and operation-bound approval evidence;
Resolving required threshold, role, conflict, and veto conditions;
8.6.3.76. Source page 2473 of the original specification
Independently validating current originating authority and actual
resource state;
Constituting scoped non-bearer finality;
Reconstructing the actual pending consequential operation at a
resource sink;
And permitting the effect only following current protected quorum,
source, operation, and consumption verification.
29.76.3 — Candidate Independent Conflict-Aware Quorum Claim
A protected multi-agent approval controller configured to detect
materially inconsistent Candidate Act commitments, conflicting
qualified evaluator decisions, and incompatible resource-effect
proposals, and to prevent such conflicting approval evidence from
establishing valid finality for an actual resource operation unless
current protected conflict-resolution predicates are satisfied.
29.76.4 — Candidate Independent Membership-Continuity Claim
Das Expires 29 April 2027 [Page 490]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A protected quorum finality system configured to bind operation-
specific approval evidence to current evaluator membership and policy
generations, invalidate affected pending authority following material
membership change, and require actual sink-side verification of the
applicable current quorum generation before consequential
effectuation.
29.76.5 — Candidate Independent Non-Substitution Claim
A system configured to accept authenticated multi-agent or threshold
cryptographic approval of a proposed consequential operation while
separately requiring current source-authority validation and
independent Finality-Sink reconstruction of the actual resource
effect, such that valid collective approval does not independently
authorize an operation outside the current protected source grant.
29.77 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The originating source authority identifies an authorized
principal. 2. The originating source authority identifies
permissible actual resource effects. 3. The originating source
authority includes relevant recipient or destination conditions. 4.
A Candidate Act is represented in a typed material operation
descriptor. 5. The Candidate Act remains non-effective during quorum
evaluation. 6. A protected policy identifies whether quorum
evaluation is required. 7. A protected policy identifies a minimum
approval threshold. 8. A protected policy identifies eligible
evaluator identities. 9. A protected policy identifies mandatory
evaluator roles. 10. A protected policy identifies required
technical independence properties. 11. A protected evaluator
registry maintains current membership generations. 12. A protected
evaluator registry maintains current role eligibility. 13. An
evaluator vote includes a current eligibility generation. 14. An
evaluator vote is cryptographically authenticated.
8.6.3.77. Source page 2474 of the original specification
15. An evaluator vote identifies the same Candidate Act as other
counted approvals. 16. An approval descriptor includes the actual
resource identity. 17. An approval descriptor includes material
operation parameters. 18. An approval descriptor includes a
designated actual Finality Sink. 19. An approval descriptor includes
an applicable resource generation. 20. An approval commitment
includes a protected challenge or approval round identifier. 21. A
historical approval cannot automatically be used in another decision
round. 22. Multiple votes from the same qualified evaluator are not
counted as distinct identities. 23. Multiple evaluator processes may
be classified as insufficiently independent under a
Das Expires 29 April 2027 [Page 491]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
protected policy. 24. A role-constrained quorum may require several
different evaluation classes. 25. An advisory evaluator does not
independently become a source-competent authorizer. 26. A source-
competent human approval may be a mandatory quorum predicate. 27.
Human authentication alone does not automatically constitute
operation-specific
approval. 28. A fully automated operation may proceed where no
quorum is required by current
source policy. 29. A protected controller detects votes referring to
different Candidate Act
commitments. 30. A protected controller detects conflicting material
operation fields. 31. A protected controller identifies incompatible
qualified quorum certificates. 32. A conflict fence may withhold
affected actual resource effects. 33. A mandatory veto cannot be
overridden by a numerical approval majority. 34. A mandatory veto
may relate to current original source authority. 35. A mandatory
veto may relate to actual resource state. 36. A mandatory veto may
relate to current protected credential state. 37. A mandatory veto
may relate to cumulative resource-budget exhaustion. 38. A quorum
policy may change its required threshold according to protected
operation
classification. 39. An untrusted agent cannot independently lower
its quorum requirement. 40. A material operation change may require
renewed quorum approval. 41. A quorum membership change may
invalidate affected pending approvals. 42. A revoked evaluator's
vote may become ineligible under current protected policy. 43. A
signing-key rotation may be represented in current membership state.
44. A threshold signature protocol may authenticate an operation-
specific commitment. 45. A participant manifest may provide
separately required individual-role evidence. 46. An aggregate
signature does not automatically prove individual participant
independence. 47. A protected evidence commitment may bind
qualifying votes to the Candidate Act. 48. An independent validator
may obtain current actual resource evidence. 49. An independent
validator may verify current source authorization. 50. A protected
cross-commitment may bind quorum evidence and current execution-time
Das Expires 29 April 2027 [Page 492]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
validation. 51. A finality controller may create scoped non-bearer
enablement. 52. The enablement may identify the approved Candidate
Act. 53. The enablement may identify current quorum-policy
generation. 54. The enablement may identify current membership
generation. 55. The enablement may identify current mandatory veto
state. 56. The enablement may identify current resource generation.
57. The enablement may identify the designated resource sink.
8.6.3.78. Source page 2475 of the original specification
58. The enablement may identify applicable protected consumption
state. 59. An opaque finality reference may remain inert without
current protected sink
validation. 60. The actual sink reconstructs the pending resource
operation. 61. The sink verifies actual resource identity. 62. The
sink verifies actual recipient or destination. 63. The sink verifies
actual operation method and material parameters. 64. The sink
verifies approved-to-actual-effect correspondence. 65. The sink
verifies current originating source permission. 66. The sink
verifies required current quorum eligibility. 67. The sink verifies
any applicable mandatory veto predicate. 68. The sink verifies
current shared resource budget. 69. The sink verifies current source
revocation. 70. The sink verifies protected finality consumption.
71. The same quorum approval cannot independently authorize a second
incompatible
actual effect. 72. Several quorum-approved operations may still be
constrained by one cumulative
originating allowance. 73. An intermediate consequential tool
operation may require its own Candidate Act. 74. A final-result
quorum does not automatically authorize unrelated intermediate side
effects. 75. A protected journal distinguishes approval from actual
effect dispatch. 76. The journal distinguishes consumed finality
from qualified completed effect. 77. A coordinator crash does not
automatically restore consumed operation authority. 78. An
unresolved prior resource effect may require qualified outcome
reconciliation. 79. A specified causal successor may additionally
require an accepted qualified prior
actual-effect receipt. 80. Existing consensus, threshold signing,
role authorization, identity, structured
transaction, and resource-sink technologies may be used as optional
implementation substrates.
Das Expires 29 April 2027 [Page 493]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
29.78 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The present embodiment may be implemented using any technically
compatible combination of the disclosed mechanisms.
An implementation may use several autonomous AI evaluators.
Another may use deterministic policy engines.
Another may use independent resource-observation components.
Another may employ a human approval principal.
Another may combine technical evaluation and source-competent human
authorization.
Another may use individually signed approvals.
8.6.3.79. Source page 2476 of the original specification
Another may use a threshold cryptographic signature.
Another may use replicated consensus state for protected approval
records.
Another may use a role-constrained quorum.
Another may require specified technical independence properties.
Another may employ a mandatory veto policy.
Another may use a conflict fence.
Another may apply resource-generation binding.
Another may use a protected approval challenge.
Another may employ membership-generation invalidation.
Another may use scoped non-bearer finality.
Another may use a protected credential broker.
Another may implement Finality-Sink enforcement at a database,
payment, file, network, application, or device boundary.
Das Expires 29 April 2027 [Page 494]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
The invention does not require the same number of evaluators for
every consequential operation.
The invention does not require a human approval where current
protected source policy permits autonomous effectuation.
The invention does not require that every approval be represented
through threshold cryptography.
The invention does not require that all evaluators use different
model providers.
The invention does not presume that separate model instances are
statistically independent merely because they are technically
isolated.
The invention does not presume that a valid quorum establishes the
truth of every proposition evaluated.
The invention does not presume that cryptographic approval
establishes valid source authority without an actual applicable
source grant.
The invention does not require every ordinary computational proposal
to receive collective approval unless the protected policy specifies
that requirement.
The invention does not require a specific consensus algorithm.
8.6.3.80. Source page 2477 of the original specification
The invention does not claim that a replicated consensus protocol
automatically provides Byzantine fault tolerance, independent
decision quality, or complete actual resource authorization.
A selected implementation may use deterministic resource predicates
even when advisory evaluators use probabilistic models.
A protected veto may remain mandatory regardless of the numerical
quorum result.
A material change to the approved operation may require current
revalidation.
Where a protected resource effect is irreversible or externally
committed, a later change in quorum opinion does not automatically
undo that effect.
Das Expires 29 April 2027 [Page 495]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Where an approval coordinator crashes, previously consumed and
indeterminate operation states remain governed by authoritative
protected records.
The equations, algorithms, pseudocode, data structures, experiments,
diagrams, and examples are illustrative and non-limiting technical
aids for a person having ordinary skill in the art.
Compatible mechanisms from the other disclosed embodiments may be
combined without making every optional feature universally mandatory.
29.79 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 29 discloses a protected autonomous multi-
agent consensus and approval architecture in which collective
computational agreement is technically separated from current
authority to produce a consequential external or persistent effect.
An originating principal establishes a protected consequential effect
envelope.
An autonomous system proposes an operation.
The operation is represented as a Candidate Act maintained in a Non-
Effective State.
A protected quorum controller determines the applicable decision
requirements.
Qualified evaluators authenticate operation-specific results under
current membership, role, independence, and policy conditions.
A protected resolver determines whether the required decision
predicates are satisfied, including mandatory vetoes and material
conflicts.
A valid quorum certificate establishes the qualifying collective
approval evidence.
The certificate does not independently enlarge original source
permission.
8.6.3.81. Source page 2478 of the original specification
A separate execution-time validator determines whether the approved
Candidate Act remains within current originating authority and actual
resource state.
Das Expires 29 April 2027 [Page 496]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A finality controller establishes scoped non-bearer enablement.
The actual Finality Sink independently reconstructs the pending
consequential operation.
The sink verifies current source authority, applicable quorum
evidence, absence of controlling vetoes, actual operation
correspondence, protected finality, and sink-local consumption.
Only then may the corresponding effect become effective.
Different agents may agree on an operation that remains unauthorized.
A cryptographically valid quorum signature may remain insufficient
when the actual resource operation differs from the signed approval.
A valid earlier quorum may require revalidation after material
membership, policy, source-authority, or resource changes.
Conflicting quorum approvals cannot independently override protected
resource versioning and consumption constraints.
A mandatory technical veto cannot be defeated merely by increasing
the number of affirmative advisory votes.
A failed or recovered approval coordinator cannot automatically
recreate previously consumed effect authority.
The principal candidate inventive technical concept of Embodiment 29
is a protected autonomous consensus-to-execution-finality
architecture in which qualified multi-agent approval is
cryptographically and semantically bound to one Candidate Act,
conflict and veto predicates are resolved under current protected
quorum policy, source and resource authority remain independently
mandatory, and an actual Finality Sink reconstructs and verifies the
corresponding real pending operation before protected non-bearer
finality consumption and consequential release.
29.80 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may implement the disclosed mechanisms using selected
existing technical components.
Existing technology Optional implementation role
Das Expires 29 April 2027 [Page 497]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
8.6.3.82. Source page 2479 of the original specification
Raft-based replicated state machines
Maintain selected protected committee, approval, or consumption
records under the configured consensus fault model RFC 9591 FROST
threshold signatures
Authenticate an operation-specific message through qualified
threshold signing participants Ordinary digital signatures
Authenticate individually attributable evaluator votes RFC 9421 HTTP
Message Signatures
Authenticate selected HTTP message components for relevant service
interactions Mutual TLS and authenticated workload identities
Identify evaluators, agents, brokers, and protected services
Hardware-backed signing keys
Protect selected evaluator or source-competent principal credentials
Structured authorization policy engines
Evaluate current source authority, quorum roles, vetoes, and resource
restrictions Deterministic JSON or CBOR encodings Represent
operation-specific approval commitments
Transactional SQL databases Maintain quorum generations, vote
records, protected conflict
state, finality, and consumption
Conditional resource updates Enforce current resource generation and
prevent incompatible
commits
Protected credential brokers Exercise reusable privileges only for
approved and currently authorized actual operations API, file,
payment, database, or hardware gateways
Reconstruct and enforce the actual consequential resource operation
Qualified resource outcome journals
Preserve completed, attempted, and indeterminate effects across
failures
29.80.1 — Important Implementation Distinctions
Das Expires 29 April 2027 [Page 498]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
A consensus library may maintain a consistent decision record without
proving that the decision is authorized.
A threshold signature library may authenticate an approved message
without establishing that the signing participants satisfy every
required administrative role.
A cryptographic signature over an HTTP request may protect selected
covered components without automatically protecting omitted
consequential parameters.
A human authentication mechanism may establish identity without
proving approval of the actual operation.
A policy engine may establish current authorization but cannot
guarantee actual effectuation correspondence unless the protected
receiving resource verifies the relevant real request.
These technologies should therefore be composed according to their
actual verified properties, rather than treated as interchangeable
substitutes.
9. Detailed Threat Model: Multi-Agent Attackers, Trust Boundaries and
Residual Risks
The following models distinguish attackers controlling prompts or
retrieved text, delegates and tool chains, evaluator populations,
stale resource snapshots, network conditions, compromised
administrative components or quota state. Each case identifies
mandatory protected checks and an explicit limit to the achievable
security property. They describe engineering analysis rather than
observed defects in products.
9.1. Threat Model 1: Prompt Injection and Agent-to-Agent Command
Laundering
Adversary control and attack narrative: An adversary controls
retrieved text, an external prompt or a tool result, making Agent A
ask Agent B to send confidential data or modify a resource outside
source approval.
Protected assets and trust boundary: Originating source grant,
bounded delegation envelope and actual effect descriptor.
Mandatory/proposed enforcement relationship: Do not treat delegate
task messages as authority; authenticate effect-semantic scope and
verify actual pending resource operation at receiving sink.
Das Expires 29 April 2027 [Page 499]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Residual risk, assumption and boundary limitation: If a downstream
uncontrolled resource cannot be gated, withholding cannot be
guaranteed.
9.2. Threat Model 2: Confused Deputy and Delegation Scope Escalation
Adversary control and attack narrative: A high-privilege receiving
agent is induced to use its standing credentials for a lower-
privilege originator and changes the task recipient or effect.
Protected assets and trust boundary: Delegation root, audience,
qualified recipient, delegated scope, receiving resource.
Mandatory/proposed enforcement relationship: Attenuate scope at every
edge, independently check current principal authority and use sink-
bound operation-specific enablement; do not substitute workload
identity for original grant.
Residual risk, assumption and boundary limitation: Compromise of
unmediated privileged receiver may bypass covered controls.
9.3. Threat Model 3: Replay of Approval or Quorum Certificates
Adversary control and attack narrative: A valid approval signature or
quorum certificate is copied to an altered operation or replayed
following prior consumption, revocation or participant membership
change.
Protected assets and trust boundary: Canonical operation commitment,
quorum epoch, protected sink-local single-use state.
Mandatory/proposed enforcement relationship: Commit approvals to
exact act and resource, check membership version, current scope and
durable consume-once state at sink.
Residual risk, assumption and boundary limitation: Rollback of
trusted sink ledger or signing keys undermines guarantees.
9.4. Threat Model 4: Concurrent Effects and Time-of-Check/Time-of-Use
Adversary control and attack narrative: Two separately valid agents
debit the same balance, allocate the last inventory unit or overwrite
a shared file after reading an identical stale version.
Protected assets and trust boundary: Protected resource versions,
semantic conflict graph, atomic effect reservations and actual
resource state.
Das Expires 29 April 2027 [Page 500]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Mandatory/proposed enforcement relationship: Serialize/fence
incompatible effects and compare current versions at last effect
boundary; consume reservation under protected transaction.
Residual risk, assumption and boundary limitation: Distributed
resources without common isolation need bounded leases or explicit
non-atomic recovery.
9.5. Threat Model 5: Sybil, Colluding or Shared-Input Evaluator Quorum
Adversary control and attack narrative: An attacker creates many
apparently distinct AI evaluators controlled by one principal or
poisons an input relied on by all evaluators.
Protected assets and trust boundary: Independence policy, evaluator
identity, quorum membership and data provenance.
Mandatory/proposed enforcement relationship: Require eligible
independent roles and separation of duties; protect membership epoch;
qualify underlying evidence separately; treat threshold signature
only as threshold participation proof.
Residual risk, assumption and boundary limitation: True semantic
independence is difficult to prove; common-mode model errors can
remain.
9.6. Threat Model 6: Conflicting Votes, Veto Suppression and Policy
Epoch Drift
Adversary control and attack narrative: A coordinator discards a
mandatory veto, mixes votes from different membership generations or
merges approvals for semantically different acts.
Protected assets and trust boundary: Policy-defined veto, current
quorum membership epoch and exact candidate digest.
Mandatory/proposed enforcement relationship: Recompute quorum
eligibility and veto state from authenticated records, reject
mismatched epochs and apply current policy at final sink.
Residual risk, assumption and boundary limitation: A compromised
policy root or quorate eligible collusion can be outside threat
coverage.
Das Expires 29 April 2027 [Page 501]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
9.7. Threat Model 7: Delegation Graph Cycles and Amplified Resource
Budgets
Adversary control and attack narrative: Agents delegate in cycles,
clone work or split into branches that each independently spend a
full source quota.
Protected assets and trust boundary: Root authority budget,
transitive graph edges and central protected spend/reservation state.
Mandatory/proposed enforcement relationship: Validate an acyclic/
effectively bounded delegation graph, conserve root allocation across
branches, and enforce atomic spend at actual resource sinks.
Residual risk, assumption and boundary limitation: If branches cross
independent unreachable authorities without coordination, strict
global conservation cannot be guaranteed.
9.8. Threat Model 8: Forged Effect Footprint, Resource Rebinding and
Canonicalization
Adversary control and attack narrative: A delegate labels a write as
a read, omits an affected resource, or relies on an ambiguous alias
that resolves to a different resource before effectuation.
Protected assets and trust boundary: Accurate actual effect
footprint, target correspondence, semantic identity, current resource
generation.
Mandatory/proposed enforcement relationship: Use protected receiver
observation, typed canonical descriptors and resource-version checks;
reject ambiguous equivalence or uncovered paths.
Residual risk, assumption and boundary limitation: Opaque remote side
effects and non-cooperating tools may prevent complete footprint
observation.
9.9. Threat Model 9: Revocation During Asynchronous Quorum and Chain
Execution
Adversary control and attack narrative: An upstream source revokes
authorization after delegation or quorum formation but before remote
sink dispatch.
Protected assets and trust boundary: Protected monotonic revocation
generation and fresh source authority at execution time.
Das Expires 29 April 2027 [Page 502]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Mandatory/proposed enforcement relationship: Validate current chain
dependencies and revoke affected enablements; enforce sink-local
freshness or policy-approved bounded lease rules.
Residual risk, assumption and boundary limitation: Immediate
revocation at disconnected third-party remote systems cannot be
asserted.
9.10. Threat Model 10: Compromised Infrastructure and Verification
Exhaustion
Adversary control and attack narrative: A malicious administrator
tampers with protected state or floods validators with huge graphs
and certificates, hoping timeouts trigger fail-open.
Protected assets and trust boundary: Protected keys, decision
liveness, bounded parsing and source authority registry integrity.
Mandatory/proposed enforcement relationship: Set limits on graph
depth, participants, signatures, cycle discovery and resource usage;
enforce fail-closed, separation or audit checks where required.
Residual risk, assumption and boundary limitation: Total compromise
of mandatory trust roots defeats assurance; fail-closed may affect
availability.
10. Reproducible Reference Validation Plan: Twenty-Four Proposed Tests
The following are PROPOSED experimental assertions, not executed
laboratory results. No test passes, code artifacts, cryptographic
proofs or external measurements are claimed. For each test, an
engineer should record protected state before/after, exact Candidate
Act, request submitted to the receiving resource, policy/root
generation, keys and signatures used, actual response and whether the
real effect occurred. Tests requiring privileged Apple/Android
interception must be scoped to cooperating receiver applications or
approved platform facilities.
10.1. MA01 — Basic independently authorized single agent
Setup and adversarial stimulus: One authorized Candidate Act, no
competing reserved effects and valid current sink state. Use
separate deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Das Expires 29 April 2027 [Page 503]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected pass/fail assertion: PERMIT only exact operation; sink state
records one protected consumption. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.2. MA02 — Conflicting authorized concurrent writes
Setup and adversarial stimulus: Two agents each have valid source
grants but address the same exclusive row/version. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: At most one incompatible write can
commit under protected conflict policy; other waits or refuses.
Verify source scope, protected quorum/delegation/reservation states,
exact resource mutation or refusal, and sink-local consumption. A
rejection log without demonstrable absence of the covered effect is
insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.3. MA03 — Concurrent non-conflicting operations
Setup and adversarial stimulus: Agents modify different protected
resource keys with valid isolated scopes. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Both may proceed if compatibility and
current sink predicates pass. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Das Expires 29 April 2027 [Page 504]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.4. MA04 — Conflicting cross-resource semantic effects
Setup and adversarial stimulus: Agents update distinct rows whose
combined business predicate violates policy. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Refuse/fence conflicting combination
based on authenticated semantic footprint. Verify source scope,
protected quorum/delegation/reservation states, exact resource
mutation or refusal, and sink-local consumption. A rejection log
without demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.5. MA05 — Stale resource-version reservation
Setup and adversarial stimulus: Reserve write against resource
version N, externally commit version N+1. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Stale reservation refuses until updated
source and resource qualification. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
Das Expires 29 April 2027 [Page 505]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
10.6. MA06 — Delegation increases effect scope
Setup and adversarial stimulus: Root permits read-only; descendant
attempts write or export. Use separate deterministic fixture
identities, protected grants, resource versions, and real effect-
capable test resource. Inspect actual receiver-side request rather
than relying only on planner logs.
Expected pass/fail assertion: Reject scope expansion even with
authentic delegation signature. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.7. MA07 — Authenticated narrowed delegation
Setup and adversarial stimulus: Agent A delegates same-resource read-
only task to Agent B with valid chain. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Qualified computation allowed;
consequential effect only within attenuated scope. Verify source
scope, protected quorum/delegation/reservation states, exact resource
mutation or refusal, and sink-local consumption. A rejection log
without demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.8. MA08 — Delegation graph cycle and forged parent
Setup and adversarial stimulus: Child edge points back to ancestor or
misses authenticated delegating proof. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Das Expires 29 April 2027 [Page 506]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected pass/fail assertion: Reject unsupported/cyclic lineage and
withhold finality. Verify source scope, protected quorum/delegation/
reservation states, exact resource mutation or refusal, and sink-
local consumption. A rejection log without demonstrable absence of
the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.9. MA09 — Cross-provider receiving resource mismatch
Setup and adversarial stimulus: Valid source-to-provider delegation
for resource X; delegate targets resource Y. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Receiver-side Finality Sink rejects
out-of-scope target. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.10. MA10 — Revocation between delegation and dispatch
Setup and adversarial stimulus: Delegate obtains valid approval;
source revokes before actual resource effect. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Current sink revocation predicate
refuses later effect. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
Das Expires 29 April 2027 [Page 507]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
10.11. MA11 — Branch-conserved budget overspend
Setup and adversarial stimulus: Two child branches each attempt to
exhaust same root quota concurrently. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Authoritative ledger permits only root-
budget total, not duplicated quota. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.12. MA12 — Intermediate tool causes undeclared effect
Setup and adversarial stimulus: Nested tool internally writes public
repository before terminal approved operation. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Treat intermediate write as separate CA
and refuse absent authority. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.13. MA13 — Valid role-qualified quorum certificate
Setup and adversarial stimulus: Eligible distinct members approve
same canonical CA, no veto. Use separate deterministic fixture
identities, protected grants, resource versions, and real effect-
capable test resource. Inspect actual receiver-side request rather
than relying only on planner logs.
Das Expires 29 April 2027 [Page 508]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected pass/fail assertion: Quorum predicate valid but effect still
requires receiving sink checks. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.14. MA14 — Quorum mixed-candidate signatures
Setup and adversarial stimulus: Half members approve recipient A and
half recipient B. Use separate deterministic fixture identities,
protected grants, resource versions, and real effect-capable test
resource. Inspect actual receiver-side request rather than relying
only on planner logs.
Expected pass/fail assertion: Reject combined certificate that lacks
threshold on one exact act. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.15. MA15 — Stale membership epoch
Setup and adversarial stimulus: Old member certificate after
protected roster or threshold change. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Reject stale quorum for current
mandatory membership policy. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
Das Expires 29 April 2027 [Page 509]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
10.16. MA16 — Mandatory veto despite majority
Setup and adversarial stimulus: Threshold is met but authorized veto
role issues valid denial. Use separate deterministic fixture
identities, protected grants, resource versions, and real effect-
capable test resource. Inspect actual receiver-side request rather
than relying only on planner logs.
Expected pass/fail assertion: Respect veto and refuse finality under
applicable policy. Verify source scope, protected quorum/delegation/
reservation states, exact resource mutation or refusal, and sink-
local consumption. A rejection log without demonstrable absence of
the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.17. MA17 — Sybil quorum identities
Setup and adversarial stimulus: One compromised provider creates
several aliases counted as independent. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Fail qualification when identity/
independence evidence does not meet policy. Verify source scope,
protected quorum/delegation/reservation states, exact resource
mutation or refusal, and sink-local consumption. A rejection log
without demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.18. MA18 — Shared poisoned evaluator evidence
Setup and adversarial stimulus: All AI evaluators consume same
attacker-controlled source without independent verification. Use
separate deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Das Expires 29 April 2027 [Page 510]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected pass/fail assertion: Do not infer independent evidentiary
basis; apply independent source policy or withhold. Verify source
scope, protected quorum/delegation/reservation states, exact resource
mutation or refusal, and sink-local consumption. A rejection log
without demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.19. MA19 — Replayed quorum certificate
Setup and adversarial stimulus: Valid approval applied once, then
operation replayed with same handle. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Second attempt refused by sink-local
protected state. Verify source scope, protected quorum/delegation/
reservation states, exact resource mutation or refusal, and sink-
local consumption. A rejection log without demonstrable absence of
the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.20. MA20 — Actual operation altered post-vote
Setup and adversarial stimulus: Correct Candidate Act vote; receiving
API method/recipient changed afterwards. Use separate deterministic
fixture identities, protected grants, resource versions, and real
effect-capable test resource. Inspect actual receiver-side request
rather than relying only on planner logs.
Expected pass/fail assertion: Sink reconstructs and rejects changed
actual operation. Verify source scope, protected quorum/delegation/
reservation states, exact resource mutation or refusal, and sink-
local consumption. A rejection log without demonstrable absence of
the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
Das Expires 29 April 2027 [Page 511]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
10.21. MA21 — Unreachable mandatory validator
Setup and adversarial stimulus: Protected quorum or revocation
authority unavailable at finality decision. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Withhold under required freshness
policy; no fail-open release. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.22. MA22 — Partition with incompatible reservations
Setup and adversarial stimulus: Two network partitions appear to
allocate same exclusive effect. Use separate deterministic fixture
identities, protected grants, resource versions, and real effect-
capable test resource. Inspect actual receiver-side request rather
than relying only on planner logs.
Expected pass/fail assertion: Only qualified authoritative partition/
lease owner can release; avoid global guarantee otherwise. Verify
source scope, protected quorum/delegation/reservation states, exact
resource mutation or refusal, and sink-local consumption. A
rejection log without demonstrable absence of the covered effect is
insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.23. MA23 — Crash between consumption and receiver acknowledgement
Setup and adversarial stimulus: Ledger consumed, remote effect may
have completed, response lost. Use separate deterministic fixture
identities, protected grants, resource versions, and real effect-
capable test resource. Inspect actual receiver-side request rather
than relying only on planner logs.
Das Expires 29 April 2027 [Page 512]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Expected pass/fail assertion: Mark indeterminate and reconcile; do
not blindly double-spend. Verify source scope, protected
quorum/delegation/reservation states, exact resource mutation or
refusal, and sink-local consumption. A rejection log without
demonstrable absence of the covered effect is insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
10.24. MA24 — iOS/Android cooperating receiver integration
Setup and adversarial stimulus: Mobile AI tool invokes authorized
remote finality gateway, altered recipient case. Use separate
deterministic fixture identities, protected grants, resource
versions, and real effect-capable test resource. Inspect actual
receiver-side request rather than relying only on planner logs.
Expected pass/fail assertion: Receiver permits valid request and
refuses altered effect without claiming OS-wide interception. Verify
source scope, protected quorum/delegation/reservation states, exact
resource mutation or refusal, and sink-local consumption. A
rejection log without demonstrable absence of the covered effect is
insufficient.
Status: PROPOSED NOT EXECUTED. Future GitHub artifacts should
include implementation version, serialized test vectors, sandbox/
resource configuration, state snapshots, actual outputs, reason codes
and reproducibility instructions.
11. Detailed Industry and Product Alignment: Multi-Agent Security
Problems and Integration Boundaries
This section identifies technology areas where the disclosed multi-
agent security problem arises or where the architecture might be
studied or integrated. Product names are illustrative, not an
assertion that products implement the invention, rely on this
publication, infringe patents, or endorse its design. Actual
feasibility depends on platform APIs, resource cooperation and
privileges. Apple, Siri, iOS, iPadOS, macOS, Android, Gemini, Bixby,
Copilot, Alexa, and other names used in this document are trademarks
of their respective owners.
Das Expires 29 April 2027 [Page 513]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents
Concrete industry security problem: A mobile assistant may invoke
multiple apps, services and on-device tasks. Source permissions can
be narrower than an eventual delegated operation, and overlapping app
automations can modify the same user resource.
Possible source-grounded technical alignment and integration
limitation: Use supported App Intents or cooperating receiver
resources to commit exact recipient, authorized operation and current
resource state. Third-party iOS software cannot universally
interpose every app or private kernel operation; cross-app source
authority must be qualified by each receiving resource.
11.2. Apple macOS, Desktop AI Agents and App Sandboxing
Concrete industry security problem: Desktop copilots and automated
workflows can delegate between automation scripts, browsers and
privileged services; shared file writes and publication are
consequential.
Possible source-grounded technical alignment and integration
limitation: Enforce final operations at privileged application/host
service boundaries; apply current grant, version and conflict
reservations to real changes. App sandbox permissions and access to
private system APIs have separate security properties.
11.3. Google Android, Gemini, Binder and Intents
Concrete industry security problem: Cross-app intents and Binder IPC
may convey requests from one app to another that has broader
privileges; multiple agents can update content-provider objects or
remote app data.
Possible source-grounded technical alignment and integration
limitation: Combine identity and permission checking at each
cooperating receiver with effect-specific protected delegation
lineage and conflict/transaction state. Keystore protects keys but
not semantic authorization of every final resource operation.
11.4. Microsoft Windows, Azure and Agent Orchestration
Concrete industry security problem: Enterprise agents can orchestrate
provisioning, policy changes and file deployment, with concurrent
operations against shared resources and separate administrative
roles.
Das Expires 29 April 2027 [Page 514]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Possible source-grounded technical alignment and integration
limitation: Implement protected resource-side authorization and
concurrency controls using domain-managed brokers, platform-supported
isolation, transactional policy stores and separation-of-duties
quorum policies.
11.5. OpenAI Agents SDK, Responses API, Codex and Tool Calling
Concrete industry security problem: Models can propose tool
invocations across API services. Prompt injection and misleading
tool output can redirect subtask delegation or trigger dangerous
writes.
Possible source-grounded technical alignment and integration
limitation: Model output remains a proposal. Attach original source
and effect scope, verify delegated tool parameters and final
recipient against protected state, and use independent receiving
finality when effect can occur.
11.6. Anthropic Claude, Claude Code and Managed Agents
Concrete industry security problem: Agent sessions, tools and
sandboxes can chain coding, browsing, file, network and deployment
actions; task delegation can cross a security or credential boundary.
Possible source-grounded technical alignment and integration
limitation: Use host or resource brokers that verify each
intermediate consequential effect and maintain source-authority
attenuation. Sandboxing alone does not create valid user authority
for a post-sandbox effect.
11.7. Google Cloud Agent Platforms and Enterprise APIs
Concrete industry security problem: Autonomous multi-service chains
operate under workload identities and OAuth grants across
heterogeneous resource APIs. A successful token exchange is not
automatically final approval for a particular resource mutation.
Possible source-grounded technical alignment and integration
limitation: Use WIMSE/authorization signals as inputs, bind per-
operation resource and actual effect, and manage conflicts using
protected reservations or receiver-native concurrency controls.
Das Expires 29 April 2027 [Page 515]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
11.8. Meta Muse/Sentinel and Isolated Agent Security
Concrete industry security problem: Security architectures isolating
agents and enforcing network/credential policy present relevant
multi-agent delegation questions, especially provider boundaries and
actual effect validation.
Possible source-grounded technical alignment and integration
limitation: Compare published isolation, approval and egress
properties to the distinct source delegation, protected quorum,
reservation and sink-local consumption requirements; do not infer
undocumented equivalents.
11.9. NVIDIA OpenShell, BlueField, Sentry and Accelerator Security
Concrete industry security problem: AI tools and workloads may use
isolated sandbox paths, external resource gateways, host services and
hardware effect paths. Independent agents may share hardware or
network resources.
Possible source-grounded technical alignment and integration
limitation: A hardware/host enforcement surface can contribute
qualified blocking and identity evidence, but must still bind the
exact actual operation and shared resource reservations. Hardware
attestation is not a substitute for principal authority.
11.10. Qualcomm Snapdragon, Arm and Trusted Device Controllers
Concrete industry security problem: Embedded/mobile systems may
provide secure cryptographic identities and protected code, while
applications and autonomous agents exercise separate operation
privileges.
Possible source-grounded technical alignment and integration
limitation: Use protected keys and monotonic state for delegation,
verifier and sink records where qualified. Final permission must
still be derived from source and actual resource semantics; avoid
assuming uniform vendor APIs.
11.11. Huawei Mobile Platforms and Telecommunications Devices
Concrete industry security problem: Heterogeneous mobile and telecom
environments may rely on different OS permission and cross-device
authorization interfaces. Multi-controller actions can conflict.
Das Expires 29 April 2027 [Page 516]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Possible source-grounded technical alignment and integration
limitation: Use platform-neutral effect descriptions, authenticated
authority lineage and qualifying receiving endpoints. Vendor
firmware or privileged driver capabilities must be established, not
presumed.
11.12. Financial Institutions, Payments and Banking Automation
Concrete industry security problem: Multiple agents can approve
different stages of payments or initiate conflicting transfers.
Several eligible approvals may still target stale balances, wrong
payees or unauthorized account relationships.
Possible source-grounded technical alignment and integration
limitation: Bind quorum approvals to exact amount/account/payee and
resource version; use authoritative debit reservation and receiver-
side finality; distinguish payment dispatch from confirmed
settlement.
11.13. Enterprise SaaS, CRM, ERP, Procurement and Inventories
Concrete industry security problem: Agents can independently spend
purchase limits, update orders, change inventory, or grant roles
under the same user mandate.
Possible source-grounded technical alignment and integration
limitation: Enforce budget/root source scope and shared resource
version reservations; require separate authority for new resource-
effecting suboperations and qualified current administrative state.
11.14. Robotics, Industrial Controllers and Physical Safety
Concrete industry security problem: Multiple autonomous controllers
can issue individually reasonable but conflicting actuator commands,
including mutually exclusive device positions or operating states.
Possible source-grounded technical alignment and integration
limitation: Qualified physical-command sink must control actual
actuation and inspect current hardware/safety interlock state. Mere
software votes cannot guarantee a physical stop path when commands
bypass the gate.
11.15. Telecommunications, Network Management and Edge Computing
Concrete industry security problem: Distributed agents may
concurrently mutate network policy, allocate radio resources or
change subscribers and service routes under different providers.
Das Expires 29 April 2027 [Page 517]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Possible source-grounded technical alignment and integration
limitation: Bind current source authority, network resource version,
protected ownership and domain-local finality; coordinate budgets and
reject stale route/policy state. Connectivity gaps limit strong
cross-domain guarantees.
11.16. Voice and System Assistants as Delegating Agents: Apple Siri,
Google Gemini, Samsung Bixby, Microsoft Copilot, and Amazon
Alexa
Concrete industry security problem: a system or voice assistant is
often the first link in a delegation chain. It interprets the user's
request, invokes one or more apps through platform action frameworks
such as App Intents and Shortcuts or Android intents, and those apps
may call their own cloud agents or third-party services. Each hop
can widen scope, lose the original user's limits, or combine with
another agent's action on the same resource; injected content read
anywhere in the chain can redirect it.
Integration path and boundary: record the assistant invocation as the
root of an authenticated delegation lineage bound to the user's
bounded source authority; require every downstream agent to present
an attenuated, operation-bound delegation edge; reserve conflicting
effect footprints before dispatch; and let the receiving app or
backend, acting as Finality Sink, verify lineage and consume once.
Third-party implementers can enforce only at interfaces they control,
such as their own action handlers and server APIs; private assistant
or operating-system internals are not assumed to be available.
12. Detailed IETF Working-Group, RFC and Internet-Draft Relevance for
Agent Delegation and Quorums
This part identifies actual IETF standard properties that engineers
can reuse, remaining effectuation-security questions and proposed
interfaces for further independent discussion. References to IETF
work do not imply that Part 5 is a working-group item or that any
group endorses these techniques. WG status, RFC maturity and
individual Internet-Draft publication status must not be conflated.
12.1. OAuth 2.0: Rich Authorization, Resource Indicators, Token
Exchange and DPoP
Primary references: [RFC6749], [RFC9396], [RFC8707], [RFC8693],
[RFC9449], [RFC9700].
Das Expires 29 April 2027 [Page 518]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Existing RFC/WG technical property and scope: RFC 9396
authorization_details, RFC 8707 resource indicators, RFC 8693 token
exchange, RFC 9449 DPoP and RFC 9700 security BCP address fine-
grained requests, intended resource identity, exchanged security
tokens, sender constraint and OAuth security guidance.
Additional execution-finality relationship and boundary: Map source
grant and delegated audience/scope into a bounded operation
representation. Validate actual resource and action at the receiving
sink; DPoP proof of token possession does not alone bind an entire
multi-agent effect footprint or determine inter-agent conflicts.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/oauth/about/
12.2. WIMSE: Workload Identity and Agent Delegation Discussions
Primary references: [WIMSE].
Existing RFC/WG technical property and scope: WIMSE addresses
workload identities across multi-system environments. In 2026,
related individual drafts discuss attenuated agent delegation and
verifier-side authority evaluation; their status should be treated as
proposals unless explicitly adopted.
Additional execution-finality relationship and boundary: Distinguish
workload identity from originating principal authority, track
delegated effect semantics across provider hops and require actual-
operation finality after identity/delegation verification. Potential
mappings include agent identity, lineage commitments and bounded
delegation contexts.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/wimse/about/
12.3. GNAP Specifications: Fine-Grained Grant Negotiation
Primary references: [RFC9635], [RFC9767].
Existing RFC/WG technical property and scope: The GNAP working group
has concluded. RFC 9635 describes the core Grant Negotiation and
Authorization Protocol and RFC 9767 covers resource-server
connections; they remain relevant specifications, not active WG work.
Das Expires 29 April 2027 [Page 519]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Additional execution-finality relationship and boundary: Use explicit
negotiated client access and resource server authorization as
possible inputs; examine whether an approval reflects the same final
action and whether protected per-act sink consumption, conflict
budgets and quorum conditions are added by a deployment.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/gnap/about/
12.4. COSE and CBOR: Authenticated Delegation and Quorum Data
Primary references: [RFC9052], [RFC8949].
Existing RFC/WG technical property and scope: RFC 9052 defines COSE
protected cryptographic structures and RFC 8949 defines CBOR
representation. Their use requires exact profile, deterministic
encoding where appropriate and algorithm/key validation.
Additional execution-finality relationship and boundary: Sign or MAC
canonical Candidate Acts, delegation edges, quorum votes, receipts
and reservation statements. Cryptographic validity proves
provenance/integrity of bytes under assumptions; it does not
establish evaluator independence or permission to act.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/cose/about/
12.5. RATS: Evidence, Verifiers and Trust Assessment
Primary references: [RFC9334].
Existing RFC/WG technical property and scope: RFC 9334 defines remote
attestation roles and architectural trust-evaluation relationships.
It can help qualify code, platform state and security posture of
participants.
Additional execution-finality relationship and boundary: Use
attestation as one input to authorization of protected evaluator,
gate or Finality Sink components. A healthy device is not evidence
that a particular agent may send a payment; source scope and
receiving resource checks remain distinct.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/rats/about/
Das Expires 29 April 2027 [Page 520]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
12.6. SCITT: Signed Statements and Transparent Provenance
Primary references: [SCITT].
Existing RFC/WG technical property and scope: SCITT addresses signed
statements, their registration and associated transparency receipts.
Transparency supports discoverability and accountability for software
or statements under qualified trust models.
Additional execution-finality relationship and boundary: Record
approval-policy generations, participant roster statements and signed
evidence with appropriate privacy safeguards. A transparency receipt
does not mean an effect happened or confer approval for a final
operation.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/scitt/about/
12.7. ACE: Authorization for Constrained Environments
Primary references: [RFC9200].
Existing RFC/WG technical property and scope: RFC 9200 adapts OAuth
2.0 access control for constrained IoT/resource server deployments
with profiles and appropriate authentication, supporting connected
device applications.
Additional execution-finality relationship and boundary: Map resource
owner/source and delegated actuating scope into constrained
approvals, then apply current device command version, shared safety-
conflict state and independently qualifying controlled actuator
Finality Sink when feasible.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/ace/about/
12.8. HTTPBIS: Conditional Requests and Resource Version Semantics
Primary references: [RFC9110].
Existing RFC/WG technical property and scope: RFC 9110 defines HTTP
resource semantics and conditionals such as If-Match; interoperable
preconditions can protect version-sensitive resource mutations.
Das Expires 29 April 2027 [Page 521]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Additional execution-finality relationship and boundary: Use
receiving resource current ETag/version checks as one contributor to
concurrent-effect safety. HTTP preconditions do not by themselves
verify original delegated principal, quorum membership, or shared
transitive resource budgets.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/httpbis/about/
12.9. SEC-DISPATCH and Security Area: Cross-Working-Group Problem
Framing
Existing RFC/WG technical property and scope: Security-area review
and dispatch consider cross-protocol problems and suitable venues;
there is no general existing IETF standard guaranteeing universal
multi-agent finality in all operating systems.
Additional execution-finality relationship and boundary: Frame a
narrowly scoped interop problem: canonical operation commitments,
delegated provenance fields, proof validation boundaries, failure
status and independent effect enforcement. This document is an
individual analysis and does not claim charter adoption.
Reference for independent scope verification:
https://datatracker.ietf.org/wg/secdispatch/about/
13. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Das Expires 29 April 2027 [Page 522]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Human oversight (Article 14): the Non-Effective State and the scope-
deviation re-authorization latch provide defined points at which a
consequential action can be withheld, interrupted, or escalated to a
competent natural person. The Act does not require human approval of
every individual decision, and this architecture does not assume it;
oversight can be exercised through bounded source authority and
explicit scope-delta approvals.
Accuracy, robustness, and cybersecurity (Article 15): fail-closed
withholding, single-use consumption, anti-replay state, and
independent reconstruction of the actual pending operation at the
Finality Sink contribute to resilience against attempts by
unauthorized third parties to alter a system's use or outputs by
exploiting vulnerabilities, and they bound the consequences of
erroneous model output.
Deployer obligations (Article 26) and obligations for general-purpose
AI models with systemic risk (Article 55), including an adequate
level of cybersecurity protection, may also be relevant where
deployers integrate third-party agents into mobile or enterprise
workflows. Harmonised standards under Article 40 and the application
dates of individual obligations have been subject to change and must
be checked at the time of use. Related EU instruments, such as the
Cyber Resilience Act, the NIS2 Directive, the General Data Protection
Regulation, and the Digital Markets Act, may interact with
deployments on mobile platforms but are outside the scope of this
document.
14. Security, Privacy, Robustness, Availability and Deployment
Considerations
14.1. Quorum membership and operator collusion
Distinct account keys do not establish independent owners.
Explicitly model collusion and common-mode compromise; require
eligible roles, membership epochs and independent evidence where
mandated.
Das Expires 29 April 2027 [Page 523]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
14.2. Operation integrity and semantic canonicalization
Agent natural language, displayed UI intent and actual receiver
request may differ. Commit exact effect/recipient resource version
and define unambiguous canonical fields at the protected sink.
14.3. Propagation and revocation freshness
Delegation ancestry must include current validity and revocation
state; offline leases and asynchronous propagation require explicit
risk-bound treatment.
14.4. Conflict reservation integrity and crash consistency
Reservations and consumption must be durable and authoritative under
the selected concurrency/isolation model; weak eventual consistency
can duplicate reserved capacity.
14.5. Privacy of delegation/approval chains
Delegation records can reveal principals, internal agents and
resource identities; restrict logging, retention, statements,
exposure of quorum membership and cross-tenant trace access.
14.6. Verification exhaustion and denial of service
Bound recursion depth, fanout, certificate size, dependency count,
evidence parsing, reservation retries and quorum responses.
Mandatory verification overload should not silently permit effects.
14.7. Separate source authority from token validity
An authenticated token, proof-of-possession or quorum signature may
be valid while the source withdraws permission, the target changes or
a conflict arises.
14.8. Physical and remote effect limits
Local protected consumption does not imply remote completion or
universal exactly-once delivery. Uncontrolled physical I/O,
unreachable devices and unrelated provider domains limit guarantees.
14.9. Test reporting and non-standard status
None of the newly authored laboratory cases are reported as executed.
No new IANA code points, registries or universally mandatory network
encoding are requested by this informational publication.
Das Expires 29 April 2027 [Page 524]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
15. Source Traceability, Examiner Discovery and Figure Location Index
Embodiment 1: Protected Cross-Agent Effect-Conflict Arbitration and
Atomic Effect Reservations: original complete specification pages
248-294; primary anchor emb1-conflict; individual pages emb1-
conflict-page-<global-page>; source figures fig-emb1-conflict-
architecture and fig-emb1-conflict-flowchart.
Embodiment 7: Cross-Provider Delegation Lineage and Effect-Semantic
Scope Attenuation: original complete specification pages 723-786;
primary anchor emb7-delegation; individual pages emb7-delegation-
page-<global-page>; source figures fig-emb7-delegation-architecture
and fig-emb7-delegation-flowchart.
Embodiment 11: Concurrent Resource-Version and Semantic Conflict
Finality: original complete specification pages 994-1062; primary
anchor emb11-concurrency; individual pages emb11-concurrency-page-
<global-page>; source figures fig-emb11-concurrency-architecture and
fig-emb11-concurrency-flowchart.
Embodiment 13: Protected Multi-Agent Quorum Membership and Operation-
Bound Consensus: original complete specification pages 1140-1220;
primary anchor emb13-quorum; individual pages emb13-quorum-page-
<global-page>; source figures fig-emb13-quorum-architecture and fig-
emb13-quorum-flowchart.
Embodiment 28: Nested Multi-Agent Tool Chains and Branch-Conserved
Effect Budgets: original complete specification pages 2318-2397;
primary anchor emb28-chain; individual pages emb28-chain-page-
<global-page>; source figures fig-emb28-chain-architecture and fig-
emb28-chain-flowchart.
Embodiment 29: Independent Evaluation Quorums and Conflict-Aware
Approval Finality: original complete specification pages 2398-2479;
primary anchor emb29-evaluators; individual pages emb29-evaluators-
page-<global-page>; source figures fig-emb29-evaluators-architecture
and fig-emb29-evaluators-flowchart.
Source-relative novelty and filing chronology must be verified
against the relevant original PCT/Indian applications. A later
Internet-Draft, additional proposed test, newly created diagram,
added standards comparison or GitHub code cannot retroactively
establish that the same material was disclosed in an earlier
application.
Das Expires 29 April 2027 [Page 525]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
16. Explicit Cross-References to Part 1 and the Eleven Companion Drafts
Part 1 of 12 companion, use as applicable: [DAS-FOUNDATION]
Part 2 of 12 companion, use as applicable: [DAS-INTEROP]
Part 3 of 12 companion, use as applicable: [DAS-EVIDENCE]
Part 4 of 12 companion, use as applicable: [DAS-SINK]
Part 6 of 12 companion, use as applicable: [DAS-RECEIPTS]
Part 7 of 12 companion, use as applicable: [DAS-TOOLS]
Part 8 of 12 companion, use as applicable: [DAS-RECOVERY]
Part 9 of 12 companion, use as applicable: [DAS-CREDENTIALS]
Part 10 of 12 companion, use as applicable: [DAS-REVOCATION]
Part 11 of 12 companion, use as applicable: [DAS-HARDWARE]
Part 12 of 12 companion, use as applicable: [DAS-INFRA]
17. Informative References
[DAS-FOUNDATION]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 1: Foundational
Consequential Authority and Common Workflows", Work in
Progress, Internet-Draft, draft-das-interoperable-
consequence-authority-00,
<https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/>.
[DAS-INTEROP]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 2: Secure iOS and
Android AI Tool Interoperability", Work in Progress,
Internet-Draft, draft-das-cross-platform-ai-
interoperability-00, <https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/>.
[DAS-EVIDENCE]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 3: Protected Source
Authority, Cross-Committed Evidence, and Scoped Non-Bearer
Finality", Work in Progress, Internet-Draft, draft-das-
Das Expires 29 April 2027 [Page 526]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
protected-authority-evidence-00,
<https://datatracker.ietf.org/doc/draft-das-protected-
authority-evidence/>.
[DAS-SINK] Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 4: Finality Sink
Enforcement, Actual-Operation Reconstruction, and Anti-
Bypass Security", Work in Progress, Internet-Draft, draft-
das-finality-sink-enforcement-00,
<https://datatracker.ietf.org/doc/draft-das-finality-sink-
enforcement/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 6 of 12 — Verified
Actual-Effect Receipts and Secure Causal Workflow
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 — AI Tool
Security, Resource Identity and Execution-Time Semantic
Integrity", Work in Progress, Internet-Draft, draft-das-
agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 8 of 12 — Distributed
Autonomous Effects, Multi-Resource Transactions and
Recovery", Work in Progress, Internet-Draft, draft-das-
distributed-effect-recovery-00,
<https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/>.
[DAS-CREDENTIALS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 9 of 12 — Protected
Agent Credential Custody, API Authorization and Data
Privacy", Work in Progress, Internet-Draft, draft-das-
Das Expires 29 April 2027 [Page 527]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
agent-credential-privacy-00,
<https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/>.
[DAS-REVOCATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 10 of 12 — Cross-
Device Authority Continuity, Revocation Fencing and
Offline Authorization", 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 — Hardware-
Assisted, Kernel and Sandbox Finality Enforcement", Work
in Progress, Internet-Draft, draft-das-hardware-execution-
finality-00, <https://datatracker.ietf.org/doc/draft-das-
hardware-execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 12 of 12 — Autonomous
Cloud, Telecom and Critical Infrastructure Resource
Security", Work in Progress, Internet-Draft, draft-das-
autonomous-infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
[ZENODO] Das, S., "iOS and Android Interoperability for Secure
Third Party AI Tools - Cross-Platform Execution Finality,
Hardware Security, and Interoperability (3,567-Page
Specification)", DOI 10.5281/zenodo.23657985, October
2026, <https://zenodo.org/records/23657985>.
[PCT-055615]
Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
Das Expires 29 April 2027 [Page 528]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"Best Current Practice for OAuth 2.0 Security", RFC 9700,
BCP 240, DOI 10.17487/RFC9700, January 2025,
<https://www.rfc-editor.org/info/rfc9700>.
[RFC9635] Richer, J. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
[RFC9767] Richer, J. and F. Imbault, "Grant Negotiation and
Authorization Protocol Resource Server Connections",
RFC 9767, DOI 10.17487/RFC9767, April 2025,
<https://www.rfc-editor.org/info/rfc9767>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
Das Expires 29 April 2027 [Page 529]
Internet-Draft Execution-Finality Part 5: Multi-Agent October 2026
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WIMSE] Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 530]