The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority
draft-das-execution-finality-protocol-layer-01
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-09-29 (Latest revision 2026-09-09) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo
Execution-Finality Reference Implementation — Runnable implementation for AI agents, GPUs, confidential computing, and zero-trust automation The Internet Solved Communication. It Never Solved Authority — Technical background, architectural explanation, diagrams, use cases, and supporting material on execution-finality |
||
| 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-execution-finality-protocol-layer-01
Independent Submission S. Das
Internet-Draft Independent Inventor
Intended status: Informational 10 September 2026
Expires: 14 March 2027
The Missing Protocol Layer for the Agentic Internet: Computation Is Not
Authority
draft-das-execution-finality-protocol-layer-01
Abstract
TLS tells you the channel is authentic. OAuth tells you the caller
holds a valid grant. HTTPS tells you the origin is who it claims to
be. EMV tells you a payment cryptogram is transaction-specific.
None of these mechanisms answer a question that autonomous, machine-
speed systems now raise on every turn: is _this specific act_,
generated by _this_ model, agent, or workload, at _this_ moment,
actually authorized to become externally effective?
Large language model agents, autonomous cloud workloads, and machine-
to-machine network functions increasingly compute, decide, and act
inside a single event loop, at latencies where no human, log
reviewer, or downstream audit process can intervene before an API
call fires, a payment settles, a file leaves the enterprise boundary,
or a physical actuator moves. Transport, authentication, and
authorization protocols were designed for a world in which the gap
between "this request was generated" and "this request had a chance
to be reviewed" was measured in human-relevant time. That gap has
collapsed to milliseconds. Existing protocol layers were never built
to close it, because the question they answer -- identity, channel
integrity, delegated scope -- is a necessary but categorically
different question from whether _this act, right now, should be
allowed to leave computation and become consequence_.
Das Expires 14 March 2027 [Page 1]
Internet-Draft Execution-Finality Protocol Layer September 2026
This document specifies an architectural pattern, execution finality,
that treats every machine-generated operation as a Candidate Act held
in a Non-Effective State until a Protected Enforcement Domain
validates act-specific authority -- purpose, destination,
jurisdiction, freshness, revocation state, policy epoch, and runtime
integrity -- and issues a narrowly scoped, non-bearer Execution
Handle bound to that act and to a specific Finality Sink, the first
boundary at which the act would otherwise become externally
effective. The document formalizes the vocabulary, a cold-path/hot-
path split for latency-sensitive deployment, a structured threat
model with adversary-facing pseudocode, an incremental migration path
for coexistence with TLS, HTTPS, OAuth, and EMV rather than
replacement of them, and worked examples spanning AI agents,
payments, telecommunications, cloud infrastructure, satellite
command, industrial control, and robotics.
The central claim is narrow and falsifiable: _computation does not
itself confer authority for consequence_, and no general, cross-
domain Internet layer currently makes that separation a structural
property of the release path rather than an application-specific
convention. This document is intended to solicit IETF community
review of whether that gap is real, whether it is already covered by
existing or in-progress work, and if not, which venue should take it
up.
This document describes a patent-pending architectural concept. Any
intellectual-property rights or disclosure obligations relating to
implementation are outside the technical scope of this document and
are subject to applicable IETF IPR procedures, including BCP 79.
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 14 March 2027.
Das Expires 14 March 2027 [Page 2]
Internet-Draft Execution-Finality Protocol Layer September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Internet Layers We Already Have . . . . . . . . . . . . . 6
3. The Missing Architectural Question . . . . . . . . . . . . . 7
4. Why Machine Time Changes the Problem: The Agentic Era . . . . 8
5. Execution-Finality Architecture . . . . . . . . . . . . . . . 9
6. Candidate Acts and the Non-Effective State . . . . . . . . . 9
7. Protected Validation and Bounded Authority . . . . . . . . . 10
8. The Finality Sink . . . . . . . . . . . . . . . . . . . . . . 11
9. Comparison with TLS, HTTPS, OAuth, EMV, and Ledgers . . . . . 12
9.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.3. OAuth and Delegated Authorization . . . . . . . . . . . . 14
9.4. EMV . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.5. Logs and Distributed Ledgers . . . . . . . . . . . . . . 15
9.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Latency, Deployment Feasibility, and the Cold/Hot Path . . . 16
10.1. Cold Path . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Hot Path . . . . . . . . . . . . . . . . . . . . . . . . 17
10.3. Indicative Per-Domain Latency Budgets . . . . . . . . . 18
10.4. Feasibility . . . . . . . . . . . . . . . . . . . . . . 18
11. Legacy System Interoperability and Incremental Migration . . 19
11.1. Additive, Not Substitutive . . . . . . . . . . . . . . . 19
11.2. Interoperability with TLS/HTTPS . . . . . . . . . . . . 20
11.3. Interoperability with OAuth . . . . . . . . . . . . . . 20
11.4. Interoperability with EMV and Payment Rails . . . . . . 20
11.5. Gateway/Shim Deployment Pattern . . . . . . . . . . . . 21
11.6. Downgrade and Fallback Posture . . . . . . . . . . . . . 21
12. Detailed Workflow, Pseudocode, and Examples . . . . . . . . . 21
12.1. End-to-End Execution-Finality Workflow . . . . . . . . . 21
12.2. Non-Limiting Pseudocode . . . . . . . . . . . . . . . . 23
12.3. AI-Agent Tool Invocation . . . . . . . . . . . . . . . . 26
12.4. Payment and Settlement . . . . . . . . . . . . . . . . . 26
12.5. Telecommunications and 5G/6G . . . . . . . . . . . . . . 27
12.6. Cloud and Data-Centre Infrastructure . . . . . . . . . . 27
12.7. Satellite and Non-Terrestrial Networks . . . . . . . . . 28
Das Expires 14 March 2027 [Page 3]
Internet-Draft Execution-Finality Protocol Layer September 2026
12.8. Critical Infrastructure and Industrial Control . . . . . 28
12.9. Robotics, Vehicles, and Autonomous Machines . . . . . . 29
12.10. Healthcare and Safety-Critical Systems . . . . . . . . . 29
13. Threat Model and Adversarial Analysis . . . . . . . . . . . . 30
13.1. Adversary Model and Assumptions . . . . . . . . . . . . 30
13.2. T1: Replay of a Previously Authorized Act . . . . . . . 30
13.3. T2: Time-of-Check to Time-of-Use (TOCTOU) Act
Substitution . . . . . . . . . . . . . . . . . . . . . . 31
13.4. T3: Finality-Sink Substitution . . . . . . . . . . . . . 31
13.5. T4: Stale Authorization After Policy or Revocation
Change . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.6. T5: Forged or Fabricated Validation Evidence . . . . . . 33
13.7. T6: Silent Downgrade / Fail-Open Under Load or
Incident . . . . . . . . . . . . . . . . . . . . . . . . 33
13.8. T7: Alternate Egress / Unverified Substitute Path . . . 34
13.9. Threat Summary Table . . . . . . . . . . . . . . . . . . 34
14. Industry and Infrastructure Relevance . . . . . . . . . . . . 35
14.1. Artificial Intelligence and Agentic Systems . . . . . . 35
14.2. Telecommunications, 5G, 6G, and AI-Native Networks . . . 35
14.3. Cloud, Edge, and Data-Centre Infrastructure . . . . . . 36
14.4. Payments, Banking, Fintech, and Digital Assets . . . . . 36
14.5. Data Governance, Privacy, and Cross-Border Data Use . . 36
14.6. Satellite, Space, and Non-Terrestrial Infrastructure . . 37
14.7. Industrial Control, Energy, and Critical
Infrastructure . . . . . . . . . . . . . . . . . . . . 37
14.8. Robotics, Vehicles, Drones, and Autonomous Machines . . 37
14.9. Healthcare and Safety-Critical Digital Systems . . . . . 37
14.10. Cybersecurity and Automated Response . . . . . . . . . . 38
14.11. Content Publication and Machine-Generated
Communications . . . . . . . . . . . . . . . . . . . . 38
14.12. Cross-Industry Common Structure . . . . . . . . . . . . 38
15. Security and Failure Considerations . . . . . . . . . . . . . 39
16. Frequently Asked Questions . . . . . . . . . . . . . . . . . 40
17. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 42
18. Related Execution-Finality Internet-Drafts . . . . . . . . . 42
18.1. Foundational and Cross-Domain . . . . . . . . . . . . . 43
18.2. Privacy and Regulatory Enforcement . . . . . . . . . . . 43
18.3. Telecommunications and Non-Terrestrial Networks . . . . 43
18.4. Neural, Agentic, and Model-Governance Applications . . . 43
18.5. Settlement and Operational Technology . . . . . . . . . 44
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . 44
Appendix A. Reference Architecture Diagram (FIG. 1A-1C) . . . . 48
A.1. FIG. 1A -- Candidate Act Generation and Staging . . . . . 48
A.2. FIG. 1B -- Protected Validation and Scoped Capability
Issuance . . . . . . . . . . . . . . . . . . . . . . . . 50
A.3. FIG. 1C -- Sink-Side Verification and Effectuation . . . 51
A.4. Reference Numeral Cross-Reference . . . . . . . . . . . . 53
Das Expires 14 March 2027 [Page 4]
Internet-Draft Execution-Finality Protocol Layer September 2026
Appendix B. Reference Implementation -- Foundational Architecture
Methodology . . . . . . . . . . . . . . . . . . . . . . . 54
B.1. Objective and Architectural Invariant . . . . . . . . . . 54
B.2. Derivation from FIG. 1A-1C and Architecture-to-Code
Mapping . . . . . . . . . . . . . . . . . . . . . . . . 55
B.3. Why the Implementation Is Not Just authorize() -> token ->
execute() . . . . . . . . . . . . . . . . . . . . . . . 57
B.4. Implementation Languages . . . . . . . . . . . . . . . . 57
B.5. Candidate Act Data Model and Deterministic Test
Parameters . . . . . . . . . . . . . . . . . . . . . . . 58
B.6. HCAD and Canonicalization . . . . . . . . . . . . . . . . 60
B.7. Policy, Protected State, and Predicate Validation . . . . 60
B.8. Evidence-Before-Capability Ordering, LAVR, and Capability
Construction . . . . . . . . . . . . . . . . . . . . . . 61
B.9. Finality Sink Verification and Replay Protection . . . . 63
B.10. Guarded Effectors and Wide-Channel Threat Surface . . . . 65
B.11. Verification Campaign: Test Counts and Methodology . . . 67
B.12. Benchmark Methodology and Results . . . . . . . . . . . . 70
B.13. Threat Model, Limitations, and Deployment-Required
Items . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.14. Reproduction and Falsifiability . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction
The Internet was built in layers because different technical problems
require different mechanisms.
IP provides internetwork delivery. Transport protocols carry data
between endpoints. TLS protects communication channels. HTTP
defines application-level request and response semantics. HTTPS
combines HTTP semantics with a secured connection to an authoritative
origin. Authentication systems establish identity. Authorization
frameworks can delegate access. Payment protocols provide payment-
specific authentication and authorization mechanisms. Logs and
ledgers record events.
These mechanisms solve indispensable problems. This document does
not propose replacing any of them.
However, modern digital information increasingly represents commands
rather than merely content, and the entity generating those commands
is, with growing frequency, itself a model rather than a human
operator sitting at a keyboard.
An AI-generated message may invoke an API. An API request may export
a database. An autonomous workload may initiate a payment. A
network controller may reconfigure infrastructure. A telecom
Das Expires 14 March 2027 [Page 5]
Internet-Draft Execution-Finality Protocol Layer September 2026
function may trigger a transmission. A satellite controller may
issue an RF or command operation. A machine-generated instruction
may cause physical actuation.
This creates a distinct architectural question:
Even when the information is correctly transported, cryptographically
protected, authenticated, and syntactically valid, should the
represented act be allowed to become externally effective?
This document calls the architectural control of that boundary
execution finality.
Readers seeking additional explanatory material, industry-specific
examples, frequently asked questions, implementation discussion, and
illustrative diagrams may consult the accompanying public technical
disclosure:
Sangam Das, "The Internet Solved Communication. It Never Solved
Authority," Zenodo, August 2026 [ZENODO-DAS]. https://zenodo.org/
records/22082995
The supplementary material provides broader discussion of execution
finality across artificial intelligence, telecommunications and
5G/6G, cloud and data-centre infrastructure, payments, satellite
systems, cybersecurity, industrial control, robotics, and other
consequence-bearing environments. It is provided for explanatory
context; this Internet-Draft defines the architectural discussion
independently.
2. The Internet Layers We Already Have
A simplified view is:
IP / transport: How does information reach another endpoint?
TLS: Can communicating peers establish a secure channel with
authentication, confidentiality, and integrity?
HTTP: How are application requests, responses, resources, methods,
and representations expressed?
HTTPS: Can HTTP communication with the intended origin be protected
by an authenticated, confidential, integrity-protected channel?
OAuth and related authorization frameworks: What access or delegated
authority may a client receive?
Das Expires 14 March 2027 [Page 6]
Internet-Draft Execution-Finality Protocol Layer September 2026
EMV technologies: Within the payment ecosystem, can payment
credentials, transaction-specific data, cardholder or device
information, and issuer authorization be used to determine whether
a payment transaction should proceed?
Logs / ledgers: What happened, and in what sequence?
These questions are not replaced by execution finality.
The additional question is:
May this specific consequential machine act become externally
effective at this particular boundary, under the current protected
authorization state?
3. The Missing Architectural Question
Many systems couple the ability to compute an operation with the
practical ability to execute it.
A workload may obtain an authenticated session, an API credential, a
delegated token, and a network route, and then possess all of the
technical machinery required to produce the external effect.
Application-specific controls can and do authorize individual
actions. Payment systems can authorize transactions. Network
devices can enforce policy. Operating systems can mediate privileged
operations.
The claim of this document is therefore not that existing systems
never authorize actions.
The narrower architectural observation is that there is no general
cross-domain layer whose central invariant is: protected act-specific
validation MUST remain a dependency of the consequence-bearing
release path itself.
Execution finality separates:
authority to compute or prepare an act;
from:
authority to make that act externally effective.
Das Expires 14 March 2027 [Page 7]
Internet-Draft Execution-Finality Protocol Layer September 2026
4. Why Machine Time Changes the Problem: The Agentic Era
Earlier digital systems frequently operated within workflows where
human review, incident response, rollback, revocation, or manual
intervention remained relevant to the time scale of the action.
AI-native infrastructure compresses that interval to the point where
it no longer functions as a safety margin. This is the specific
condition that motivates this document, and it is worth stating
plainly: the reason execution finality did not need to exist as a
general cross-domain layer in 1995, 2005, or even 2015 is that the
actor generating consequential requests was, in the overwhelming
majority of cases, a human, and humans are slow enough relative to
review, monitoring, and manual intervention that application-level
and post-hoc controls were sufficient.
Autonomous agents can invoke tools, call APIs, transmit data, create
files, modify databases, initiate payments, trigger workflows,
reconfigure infrastructure, generate telecommunications operations,
or issue machine commands within milliseconds, in loops that may run
thousands of times per hour without a human observing any individual
iteration. An agent does not need to be malicious to be dangerous in
this model: a correctly authenticated, correctly authorized, non-
adversarial agent that is simply wrong about the current purpose,
destination, or policy state can still generate a fully valid, fully
transportable, fully credentialed Candidate Act that should not
become effective.
By the time a log is read:
* the data may already have crossed a jurisdiction;
* the payment may already have been released;
* the network state may already have changed;
* the telecom transmission may already have occurred;
* the model or system memory may already have changed; or
* the physical actuation may already have happened.
Post-event evidence is essential.
But: evidence of an unauthorized act is not prevention of the act.
Das Expires 14 March 2027 [Page 8]
Internet-Draft Execution-Finality Protocol Layer September 2026
AI-native infrastructure therefore increases the importance of pre-
effectuation authorization, and does so specifically because the
traditional backstop -- a human somewhere in the loop who is slow
enough to be a safety margin -- is being architecturally removed by
the same agentic systems that make this document relevant.
5. Execution-Finality Architecture
The proposed architecture introduces an execution-finality layer
between computation and externally effective consequence.
A conceptual sequence is:
1. A workload computes or prepares an operation.
2. The operation is represented as a Candidate Act.
3. The Candidate Act is placed or maintained in a Non-Effective
State.
4. A Protected Enforcement Domain or equivalent protected mechanism
validates the required authority and protected state.
5. Successful validation produces or resolves protected validation
evidence and narrowly scoped effectuation authority.
6. The authority is bound to the intended Candidate Act, scope,
destination, protected state, and Finality Sink.
7. The Finality Sink independently verifies the required authority.
8. Only after successful verification may the protected external
effect occur.
Failure to validate leaves the Candidate Act non-effective.
6. Candidate Acts and the Non-Effective State
A Candidate Act is a proposed operation capable of producing an
external consequence but not yet permitted to do so.
Candidate Acts may include:
* AI-agent tool calls;
* API requests;
* file or database exports;
Das Expires 14 March 2027 [Page 9]
Internet-Draft Execution-Finality Protocol Layer September 2026
* storage writes;
* model-memory updates;
* payment instructions;
* telecom transmissions;
* network configuration changes;
* radio emissions;
* satellite commands;
* content publication;
* notification rendering;
* actuator commands;
* vehicle or robotic operations; and
* other consequence-bearing machine operations.
The Non-Effective State is the logical state in which the Candidate
Act may exist computationally but cannot yet cross the relevant
effectuation boundary.
In shorthand: computation exists != consequence is authorized
7. Protected Validation and Bounded Authority
Before effectuation, applicable conditions may be validated inside a
protected hardware, cryptographically isolated, or otherwise
protected enforcement environment.
Conditions may include:
* actor identity;
* workload identity;
* AI-agent identity;
* purpose;
* user or enterprise authority;
Das Expires 14 March 2027 [Page 10]
Internet-Draft Execution-Finality Protocol Layer September 2026
* consent;
* destination;
* recipient;
* jurisdiction;
* policy epoch;
* revocation state;
* nonce or freshness state;
* quota;
* permitted effect;
* runtime integrity;
* protected state;
* algorithm or model identity;
* execution context; and
* Finality Sink identity.
Successful validation may produce protected evidence and a bounded
Execution Handle or equivalent capability.
Such effectuation authority may be non-bearer, single-use, quota-
limited, revocable, time-bounded, purpose-bound, destination-bound,
state-bound, and Finality-Sink-bound.
Possession or copying of a representation alone should not transfer
the underlying execution authority to another actor, context,
destination, session, or sink.
8. The Finality Sink
The Finality Sink is the first boundary at which a Candidate Act
would become externally effective.
It is a functional role and does not require one specific physical
component.
A Finality Sink may be:
Das Expires 14 March 2027 [Page 11]
Internet-Draft Execution-Finality Protocol Layer September 2026
* an API dispatcher;
* an egress gateway;
* a model-output emitter;
* a telecom gateway;
* an IMS or network-function boundary;
* a radio transmission chain;
* a SmartNIC or DPU;
* a memory controller;
* a storage writer;
* a payment-release interface;
* a settlement or ledger bridge;
* an operating-system broker;
* a notification renderer;
* a satellite-command interface; or
* a physical actuator.
The Finality Sink verifies the applicable effectuation authority
before releasing the consequence-bearing operation.
If verification fails: the Candidate Act remains non-effective.
If verification succeeds: effectuation may proceed only within the
verified scope.
Where required, single-use capability or protected state is consumed
before or atomically with effectuation.
9. Comparison with TLS, HTTPS, OAuth, EMV, and Ledgers
Das Expires 14 March 2027 [Page 12]
Internet-Draft Execution-Finality Protocol Layer September 2026
9.1. TLS
TLS 1.3 [TLS13] is designed to provide a secure channel between
communicating peers. Its security properties include peer
authentication, confidentiality, integrity, and record-layer
protections.
TLS therefore answers questions such as:
Is this the authenticated peer?
Has the communication been protected from eavesdropping or undetected
modification?
TLS does not define the application-specific semantic rule that a
consequential command carried inside the protected channel is
authorized to produce a particular external effect.
A malicious, compromised, or over-authorized endpoint can therefore
transmit a perfectly valid TLS-protected command.
Execution finality is intended to operate after or alongside secure
transport by independently controlling release of the consequential
effect.
9.2. HTTPS
HTTPS combines HTTP [HTTP] semantics with a secured connection to an
authoritative origin. HTTP request methods convey client intentions
regarding identified resources, while HTTPS provides authentication
of the relevant origin and confidentiality and integrity protection
for the HTTP exchange.
This is an important distinction: HTTPS is not merely encryption.
Nevertheless, successful HTTPS communication does not itself
establish a universal rule that every downstream real-world effect
requested in the HTTP message is authorized for its current purpose,
jurisdiction, protected state, runtime condition, and effectuation
boundary.
An application can implement such controls, but they are application-
specific.
Execution finality proposes making the final act-level release
dependency explicit and reusable across domains.
Das Expires 14 March 2027 [Page 13]
Internet-Draft Execution-Finality Protocol Layer September 2026
9.3. OAuth and Delegated Authorization
OAuth and similar systems can provide powerful delegated
authorization and scope-limited access.
These mechanisms may already be used to prevent unauthorized API
operations.
Execution finality does not claim otherwise.
The distinction is that access authorization and effectuation
authority need not be identical.
A token may authorize access to an API or resource while a particular
requested consequence may require additional validation of purpose,
current state, destination, jurisdiction, freshness, revocation, act-
specific attributes, and the identity of the actual effectuation
boundary.
The execution-finality model places that last validation structurally
at or immediately before the Finality Sink.
9.4. EMV
EMV must be distinguished carefully because it already contains
transaction-specific security and authorization mechanisms.
EMV Chip [EMV-CHIP] can generate transaction-specific cryptograms.
Depending on the transaction flow, cryptographic information can be
verified locally by a terminal or remotely by an issuer. EMV 3-D
Secure [EMV-3DS] also supports payment authentication and issuer
decision-making for e-commerce transactions.
EMV therefore demonstrates an important principle:
high-throughput infrastructure can make transaction-specific
cryptographic authorization part of a real-time consequence-bearing
workflow.
Execution finality does NOT claim that EMV merely authenticates a
generic credential or that EMV fails to authorize payment
transactions.
The distinction proposed here is scope and architectural generality.
EMV is purpose-built for payment ecosystems and payment consequences.
Das Expires 14 March 2027 [Page 14]
Internet-Draft Execution-Finality Protocol Layer September 2026
Execution finality proposes a generalized abstraction for arbitrary
machine-generated consequences, including AI-agent tool use, data
export, telecom transmission, cloud and storage operations, network
reconfiguration, satellite commands, and physical actuation.
It additionally emphasizes a common cross-domain structure:
Candidate Act
->
Non-Effective State
->
Protected Validation
->
narrowly scoped non-bearer effectuation authority
->
Finality-Sink verification
->
external effect
EMV is therefore better understood as a useful domain-specific
analogy showing the feasibility and value of transaction-bound
authorization, rather than as a protocol that the proposed
architecture seeks to replace.
9.5. Logs and Distributed Ledgers
Logs, audit systems, and ledgers can provide evidence, ordering,
integrity protection, or consensus regarding events.
They can also participate in authorization architectures.
However, recording an event does not by itself prove that the event
was authorized to become externally effective before it occurred.
Execution finality can use a ledger or validation receipt where
useful, but a ledger is not a baseline requirement.
9.6. Summary
+===========+==========================================+
| Mechanism | Primary property |
+===========+==========================================+
| IP/ | Information delivery |
| Transport | |
+-----------+------------------------------------------+
| TLS | Secure authenticated channel |
+-----------+------------------------------------------+
| HTTP | Request/response and resource semantics |
Das Expires 14 March 2027 [Page 15]
Internet-Draft Execution-Finality Protocol Layer September 2026
+-----------+------------------------------------------+
| HTTPS | HTTP over a secured authoritative-origin |
| | channel |
+-----------+------------------------------------------+
| OAuth | Delegated access authorization |
+-----------+------------------------------------------+
| EMV | Payment-domain transaction |
| | authentication and authorization |
+-----------+------------------------------------------+
| Logs/ | Evidence, ordering, recording, or |
| Ledgers | consensus |
+-----------+------------------------------------------+
| Execution | Protected act-specific authorization |
| Finality | remains a prerequisite of external |
| | effectuation at the consequence boundary |
+-----------+------------------------------------------+
Table 1
10. Latency, Deployment Feasibility, and the Cold/Hot Path
Execution-finality control is useful only if it can be implemented
without placing expensive policy reasoning into every latency-
sensitive operation. A practical implementation therefore divides
processing into a cold path and a hot path, and this section expands
the split into concrete per-domain latency budgets, a failure
taxonomy for the hot path, and pseudocode for both paths.
10.1. Cold Path
The cold path may perform:
* policy evaluation;
* AI risk assessment;
* authorization issuance;
* consent processing;
* jurisdiction determination;
* credential validation;
* workload or model assessment;
* destination approval;
Das Expires 14 March 2027 [Page 16]
Internet-Draft Execution-Finality Protocol Layer September 2026
* key provisioning;
* rule compilation;
* protected-state preparation; and
* creation of validation evidence.
The cold path is not latency-bounded by the effectuation event. It
runs ahead of, or asynchronously with, the act it will eventually
authorize, and its output is a compact, independently verifiable
artifact (the Execution Handle plus validation evidence) rather than
a live policy decision the hot path must wait on.
10.2. Hot Path
The effectuation-time hot path may be restricted to operations such
as:
* identifying the Candidate Act;
* checking or reconstructing an act digest;
* verifying a signature, MAC, attestation, or protected record;
* checking nonce or freshness state;
* checking revocation or policy epoch;
* checking scope;
* checking Finality-Sink binding;
* consuming single-use or quota state; and
* releasing or denying the consequence-bearing resource.
Every hot-path operation above is a bounded, deterministic, local
check. None of them requires a network round trip to a policy
engine, a human reviewer, or an AI model. This is the property that
makes the architecture compatible with microsecond-to-low-millisecond
release paths: the reasoning that is genuinely expensive (what should
be allowed, for whom, under what conditions) has already happened on
the cold path, and the hot path only checks whether the artifact
produced by that reasoning still applies to the exact act now in
front of the sink.
Das Expires 14 March 2027 [Page 17]
Internet-Draft Execution-Finality Protocol Layer September 2026
10.3. Indicative Per-Domain Latency Budgets
The following budgets are illustrative, not normative, and are
intended only to show that hot-path verification is compatible with
the timing constraints of the domains discussed in Section 14.
Actual figures depend on hardware, cryptographic primitive, assurance
level, and topology, and this document makes no universal latency
claim.
+=================+=====================+=========================+
| Domain | Typical release- | Hot-path fit |
| | path budget | |
+=================+=====================+=========================+
| API/tool-call | 1-50 ms | Local signature/MAC |
| dispatch | | check, cached |
| (agentic AI) | | revocation epoch |
+-----------------+---------------------+-------------------------+
| 5G/6G user- | <1-10 ms | Hardware-assisted |
| plane gateway | | verification, |
| action | | precomputed epoch table |
+-----------------+---------------------+-------------------------+
| Card-present/ | ~100-300 ms | Composable with |
| EMV-adjacent | (existing EMV | existing terminal/ |
| payment release | budget) | issuer round trip |
+-----------------+---------------------+-------------------------+
| Industrial/ | <10 ms (interlock- | Local protected-state |
| safety actuator | class) | check only; no remote |
| command | | call in hot path |
+-----------------+---------------------+-------------------------+
| Satellite | Seconds | Verification cost |
| command uplink | (propagation-bound) | negligible relative to |
| | | propagation delay |
+-----------------+---------------------+-------------------------+
Table 2
10.4. Feasibility
The architecture does not require a human reviewer, AI model, remote
policy service, regulator, or distributed consensus protocol to
execute synchronously for every Finality-Sink decision.
Policy and authorization can be prepared on the cold path and
transformed into compact locally verifiable evidence.
The hot path can use mechanisms such as:
* public-key signature verification;
Das Expires 14 March 2027 [Page 18]
Internet-Draft Execution-Finality Protocol Layer September 2026
* MAC verification;
* HSM-backed protected state;
* TEE or secure-enclave state;
* monotonic counters;
* nonce stores;
* protected database transactions;
* cached revocation epochs;
* precomputed authorization artifacts; and
* device- or sink-bound credentials.
This document therefore does not claim a universal latency number.
The architectural requirement is that expensive reasoning may remain
outside the hot path while the final release decision remains
independently enforceable at the consequence boundary.
11. Legacy System Interoperability and Incremental Migration
A cross-domain architectural proposal is only deployable if it can be
introduced without a forklift replacement of TLS, HTTPS, OAuth, EMV,
or the applications built on them. This section describes execution
finality as an additive control plane, the specific interoperability
points with each legacy mechanism, a gateway/shim deployment pattern
for brownfield environments, and an explicit compatibility and
downgrade posture.
11.1. Additive, Not Substitutive
Execution finality is designed to sit at or immediately before the
existing release point of a legacy mechanism, not to replace the
mechanism's channel security or its existing authorization semantics.
A Finality Sink can be implemented as a thin verification shim placed
directly in front of an existing egress gateway, API dispatcher, or
payment-release interface, without modifying the transport (TLS
remains TLS), the application protocol (HTTP remains HTTP), or the
existing delegated-authorization layer (OAuth tokens continue to be
validated exactly as before).
The added dependency is narrow: the shim additionally requires a
valid, act-specific Execution Handle before forwarding the request to
the legacy release path. If no Execution Handle is required by local
Das Expires 14 March 2027 [Page 19]
Internet-Draft Execution-Finality Protocol Layer September 2026
policy for a given operation class, the shim is a no-op and legacy
behavior is unchanged. This allows execution finality to be adopted
operation-by-operation, starting with the highest-consequence acts
(bulk data export, high-value payments, safety-critical actuation)
and expanding coverage over time.
11.2. Interoperability with TLS/HTTPS
No change to the TLS handshake, cipher suite negotiation, or
certificate validation is required. The Candidate Act, its digest,
and the resulting Execution Handle can be carried as an application-
layer artifact inside the existing HTTPS request (for example, as an
additional header or a signed structured field), so that legacy HTTPS
clients that do not generate an Execution Handle simply have the
field absent, and a Finality-Sink shim in strict mode denies the act
while a shim in permissive/observe mode logs the gap without
blocking, which is the recommended posture during a migration window.
11.3. Interoperability with OAuth
Existing OAuth access tokens continue to gate resource access exactly
as they do today. The Execution Handle is a second, narrower
artifact layered on top of, not instead of, the OAuth grant: an OAuth
token can authorize a client to call an export API at all, while the
Execution Handle additionally authorizes this specific export, to
this destination, under the current policy epoch. A resource server
can be upgraded incrementally by adding an Execution-Handle check
after its existing token-introspection step, with no change to the
authorization server, token format, or grant flow.
11.4. Interoperability with EMV and Payment Rails
Execution finality does not attempt to sit inside the EMV cryptogram
computation or the issuer authorization step; that domain-specific,
already-mature control is left intact. Instead, an enterprise,
agent-facing, or API-facing payment initiator can require an
Execution Handle as a precondition to constructing the payment
instruction that is handed to the existing EMV/payment-rail path, so
the two controls compose in sequence (execution-finality check, then
existing payment-domain authorization) rather than one subsuming the
other.
Das Expires 14 March 2027 [Page 20]
Internet-Draft Execution-Finality Protocol Layer September 2026
11.5. Gateway/Shim Deployment Pattern
For brownfield environments where modifying every legacy endpoint is
impractical, a Finality-Sink function can be deployed as a reverse
proxy, service-mesh sidecar, API gateway plugin, or network-function
filter placed in front of the unmodified legacy system. This
concentrates the hot-path check at a small number of well-known
chokepoints instead of requiring every downstream service to be
individually upgraded, and mirrors how WAFs, API gateways, and
service meshes already retrofit authentication and rate-limiting onto
legacy backends without modifying them.
11.6. Downgrade and Fallback Posture
Three explicit deployment modes are RECOMMENDED for a migration
window:
Observe mode: the shim evaluates Execution-Handle presence and
validity but never blocks; results are logged for coverage
measurement.
Permissive mode: acts without a valid Execution Handle are allowed
but flagged, while acts that present an invalid or expired handle
are denied; this catches active misuse while legacy callers are
migrated.
Strict mode: a valid, act-specific Execution Handle is a hard
precondition for release; this is the target end state for high-
consequence operation classes.
A deployment SHOULD NOT silently fail open from strict mode to
permissive or observe mode; any mode transition should be an
explicit, auditable configuration change, since a silent downgrade
under load or during an incident is itself a bypass path (see
Section 13.7).
12. Detailed Workflow, Pseudocode, and Examples
12.1. End-to-End Execution-Finality Workflow
The following sequence is a non-limiting reference workflow. The
components may be distributed across a device, operating system,
network function, cloud service, protected hardware environment,
payment system, enterprise gateway, or cyber-physical controller.
*Step 1 - Compute or Receive a Proposed Operation.* An ordinary
compute environment, including an AI agent, application, cloud
workload, network function, payment process, or controller, computes,
Das Expires 14 March 2027 [Page 21]
Internet-Draft Execution-Finality Protocol Layer September 2026
receives, or prepares an operation. At this stage the operation has
no independent authority to become externally effective merely
because it was generated by an authenticated process or arrived over
a secure channel.
*Step 2 - Construct the Candidate Act.* The system represents the
proposed operation as a Candidate Act, which may include or
reference: an act identifier; an operation type; canonicalized load-
bearing act attributes; an actor, workload, or AI-agent identity;
purpose and requested scope; source and destination; requested
effect; jurisdictional context; session or transaction context;
freshness information; a policy epoch; a revocation epoch; the
intended Finality Sink; and a digest over the attributes that must
remain invariant before effectuation.
*Step 3 - Enter the Non-Effective State.* The Candidate Act is placed
or maintained in a Non-Effective State. Computation may continue and
validation may occur, but the consequence-bearing resource is
withheld -- network egress, an API dispatch, a payment release, a
database commit, a storage write, a message or notification release,
a radio transmission, a satellite command, a model-output
publication, a device wake, or a physical actuator transition.
*Step 4 - Resolve the Applicable Authorization Context.* The system
resolves the authority required for this particular act, constraining
permitted actor, purpose, destination, effect, data or resource
scope, jurisdiction, time window, nonce or freshness state, quota,
runtime identity, policy epoch, revocation state, and permitted
Finality Sink.
*Step 5 - Protected Validation.* A Protected Enforcement Domain, or
cooperating protected verifier, validates the Candidate Act against
the required authorization context. Validation failure does not
produce effectuation authority.
*Step 6 - Commit Protected Validation Evidence.* If validation
succeeds, the protected domain may commit validation evidence -- a
signed receipt, protected state transition, authenticated record,
hash-bound record, attested state, append-only event, ledger
commitment, or equivalent -- before or atomically with issuance of
effectuation authority.
*Step 7 - Issue or Resolve Scoped Non-Bearer Authority.* After
successful validation, the protected domain issues or resolves a
narrowly scoped Execution Handle, bounded to the minimum required
effect and bound to Candidate-Act digest, actor/workload, purpose,
destination, jurisdiction, validity window, nonce, quota, policy
epoch, revocation epoch, validation evidence, protected state, and
Das Expires 14 March 2027 [Page 22]
Internet-Draft Execution-Finality Protocol Layer September 2026
Finality Sink. The authority is non-bearer: possession or copying of
its representation alone does not authorize another actor, context,
destination, or sink to use it.
*Step 8 - Present or Resolve Authority at the Finality Sink.* The
Candidate Act reaches the Finality Sink only as a still non-effective
operation. The Finality Sink, or a verifier structurally coupled to
it, verifies the effectuation authority before release, including
that the requested effect still matches the authorized act and that
the authority has not expired, been revoked, been consumed, or been
substituted across another sink or context.
*Step 9 - Reconstruct or Recheck the Candidate Act.* Where required,
the Finality Sink reconstructs the load-bearing Candidate-Act
attributes from sink-visible state and recomputes the act digest,
preventing a validated act from being replaced with a different
destination, amount, command, resource, recipient, output, or effect
after validation.
*Step 10 - Atomic Consumption and Effectuation.* If all checks
succeed, single-use or quota state is consumed before or atomically
with release of the consequence-bearing resource, and effectuation
occurs only within the verified scope.
*Step 11 - Fail-Closed Denial.* If any required condition is absent,
invalid, stale, mismatched, replayed, revoked, quota-exhausted, or
unverifiable, the Candidate Act remains non-effective. Application
intent, network delivery, authenticated identity, possession of a
token, or prior approval are not treated as a substitute for
successful Finality-Sink verification.
*Step 12 - Optional Audit and Accountability.* The system may record
the allow or deny result for audit, dispute resolution, security
analysis, incident response, or compliance. Audit is complementary
to execution finality: the protected consequence is controlled before
release, and the audit record does not substitute for that control.
12.2. Non-Limiting Pseudocode
The following pseudocode illustrates the logical dependency. It does
not prescribe a wire format, cryptographic primitive, hardware
technology, or deployment topology.
Das Expires 14 March 2027 [Page 23]
Internet-Draft Execution-Finality Protocol Layer September 2026
CandidateAct {
act_id
actor_id
operation_type
purpose
resource_scope
destination
jurisdiction
requested_effect
policy_epoch
revocation_epoch
freshness
finality_sink_id
canonical_act_digest
}
ExecutionAuthority {
authority_id
candidate_act_digest
permitted_actor
permitted_purpose
permitted_scope
permitted_destination
permitted_effect
permitted_jurisdiction
expiry
nonce_or_counter
quota
policy_epoch
revocation_epoch
validation_evidence_ref
finality_sink_id
non_bearer = true
}
process_candidate(candidate):
candidate.state = NON_EFFECTIVE
context = resolve_authorization_context(candidate)
if context is absent:
return DENY
result = protected_validate(candidate, context)
if result != VALID:
return DENY
Das Expires 14 March 2027 [Page 24]
Internet-Draft Execution-Finality Protocol Layer September 2026
evidence = commit_validation_evidence(
candidate,
context,
result
)
authority = issue_scoped_authority(
candidate,
context,
evidence
)
return deliver_non_effective_candidate_to_sink(
candidate,
authority
)
finality_sink_receive(candidate, authority, sink_state):
if candidate.state != NON_EFFECTIVE:
return DENY
if authority.finality_sink_id != sink_state.sink_id:
return DENY
if authority is expired or revoked:
return DENY
if authority.nonce_or_counter is already consumed:
return DENY
if authority.quota is exhausted:
return DENY
if authority.policy_epoch != sink_state.policy_epoch:
return DENY
if authority.revocation_epoch != sink_state.revocation_epoch:
return DENY
reconstructed_digest =
canonical_digest(candidate.load_bearing_attributes)
if reconstructed_digest !=
authority.candidate_act_digest:
return DENY
Das Expires 14 March 2027 [Page 25]
Internet-Draft Execution-Finality Protocol Layer September 2026
if not scope_matches(candidate, authority):
return DENY
if not verify_validation_evidence(authority):
return DENY
atomic {
consume(authority.nonce_or_counter)
decrement_if_required(authority.quota)
mark_effectuation_committed(candidate.act_id)
release_only_authorized_effect(
candidate,
authority.permitted_effect
)
}
return EFFECTUATED
12.3. AI-Agent Tool Invocation
An AI agent prepares an instruction to export customer records to an
external analysis service.
Candidate Act: the proposed export, including dataset, fields,
purpose, recipient, destination, model or agent identity, and
requested transfer.
Protected validation: verifies that the agent is permitted to perform
the requested purpose, that the data scope is allowed, that the
destination and jurisdiction are permitted, that policy and
revocation state are current, and that the requested effect matches
enterprise policy.
Finality Sink: the first egress gateway, API dispatcher, storage-
export boundary, or equivalent component capable of releasing the
protected data.
Result: a valid HTTPS session or OAuth token alone does not release
the export. The egress Finality Sink additionally requires valid
act-specific effectuation authority.
12.4. Payment and Settlement
An AI agent, user application, enterprise workflow, or payment
service prepares a payment instruction.
Das Expires 14 March 2027 [Page 26]
Internet-Draft Execution-Finality Protocol Layer September 2026
Candidate Act: the proposed transfer, including amount, payer, payee,
purpose, currency or asset, destination, transaction context, and
requested payment effect.
Protected validation: may combine existing payment-domain
authorization with additional enterprise, agent, purpose, fraud,
jurisdiction, quota, policy, or workflow constraints.
Finality Sink: the component that first releases the payment into an
irrevocable or externally consequential settlement path.
Result: execution finality does not replace EMV or payment
authorization. It provides a generalized control point for binding a
machine-generated payment act to additional protected constraints
before release.
12.5. Telecommunications and 5G/6G
An AI controller, network function, application, autonomous service,
or machine-to-machine workflow prepares a consequential network
operation.
Candidate Act: a packet egress request, network-slice change, roaming
operation, radio command, message release, gateway action, or
satellite/NTN transmission.
Protected validation: may verify network authority, purpose,
subscriber or enterprise scope, destination, radio or spectrum
constraints, jurisdiction, policy epoch, freshness, quota, and
network-function identity.
Finality Sink: a gateway, user-plane or control-plane enforcement
point, radio chain, network-function boundary, satellite gateway, or
other release boundary.
Result: the fact that the request was generated by an authenticated
network function does not alone make the requested consequence final.
12.6. Cloud and Data-Centre Infrastructure
A workload prepares a storage, memory, DMA, accelerator, or network
operation.
Candidate Act: a DMA transfer, persistent storage write, accelerator-
to-host transfer, privileged memory update, SmartNIC/DPU operation,
or cloud egress event.
Das Expires 14 March 2027 [Page 27]
Internet-Draft Execution-Finality Protocol Layer September 2026
Protected validation: may bind tenant, workload, purpose, resource
range, destination, device identity, attested runtime, policy epoch,
and revocation state.
Finality Sink: a memory controller, storage controller, SmartNIC,
DPU, accelerator boundary, hypervisor-mediated release point, or
protected egress gateway.
Result: compromise of the ordinary workload need not automatically
imply authority to create every external or persistent effect
available to the underlying infrastructure.
12.7. Satellite and Non-Terrestrial Networks
A ground system, autonomous controller, AI system, or network service
prepares an RF, routing, payload, or satellite-control operation.
Candidate Act: a beam command, RF transmission, payload instruction,
routing update, cross-link operation, or spacecraft command.
Protected validation: may verify mission authority, command type,
destination, spacecraft identity, geographic or jurisdictional
constraints, time window, operational state, freshness, policy epoch,
and command scope.
Finality Sink: the command-uplink interface, RF chain, payload-
control boundary, or protected spacecraft actuator interface.
Result: command generation and command effectuation remain separate
authorities.
12.8. Critical Infrastructure and Industrial Control
An AI system or control application computes a command affecting a
physical process.
Candidate Act: a valve movement, breaker operation, process-setpoint
change, robotic command, energy-grid action, or safety-system update.
Protected validation: may verify operator or machine authority,
permitted operating envelope, plant state, purpose, interlocks,
freshness, maintenance mode, policy epoch, and actuator identity.
Finality Sink: the protected controller, safety PLC boundary,
actuator interface, motor controller, or other component that first
creates the physical effect.
Das Expires 14 March 2027 [Page 28]
Internet-Draft Execution-Finality Protocol Layer September 2026
Result: calculation of a control command is not treated as authority
for physical actuation.
12.9. Robotics, Vehicles, and Autonomous Machines
A planning model or autonomous controller generates a motion or
environment-changing action.
Candidate Act: steering, braking, acceleration, robotic motion,
payload release, door actuation, drone command, or other kinetic
operation.
Protected validation: may check operating mode, safety envelope,
actor identity, sensor or state freshness, geofence, destination,
policy epoch, and permitted actuator scope.
Finality Sink: the motor controller, drive-by-wire interface, robotic
actuator interface, or equivalent consequence boundary.
Result: a planner may propose the action without holding unrestricted
final actuation authority.
12.10. Healthcare and Safety-Critical Systems
A clinical application, AI model, device controller, or workflow
prepares an operation affecting a patient-facing system.
Candidate Act: a device-setting change, medication-device
instruction, data disclosure, alert suppression, or safety-critical
workflow action.
Protected validation: may verify device identity, clinician or
workflow authority, patient context, purpose, permitted range,
freshness, policy state, and safety constraints.
Finality Sink: the medical-device controller, protected workflow
dispatcher, disclosure gateway, or equivalent first consequence
boundary.
Result: an AI recommendation and an externally effective clinical-
device action remain distinct stages.
Das Expires 14 March 2027 [Page 29]
Internet-Draft Execution-Finality Protocol Layer September 2026
13. Threat Model and Adversarial Analysis
This section enumerates the adversary classes and failure classes the
architecture is intended to resist, states the corresponding
assumption or guarantee, and gives adversary-facing pseudocode for
the attack and the corresponding Finality-Sink defense. It is
organized around the properties an Execution Handle and a Finality
Sink are expected to provide: non-bearer scoping, freshness,
revocability, act-binding, and sink-binding.
13.1. Adversary Model and Assumptions
The following adversary capabilities are assumed in scope:
* full control over an ordinary (non-protected) compute environment,
including an AI agent, application process, or cloud workload;
* the ability to observe and replay network traffic on unprotected
paths;
* the ability to construct arbitrary Candidate Acts, including
malformed or misleading purpose/destination fields;
* the ability to attempt to reuse, forward, or present a captured
Execution Handle in a different context, destination, or sink; and
* the ability to attempt requests during known windows of policy
change (for example, immediately after a revocation).
The following are explicitly out of scope or treated as trust
anchors, consistent with Section 15:
* full compromise of the Protected Enforcement Domain itself
(protected-domain compromise is discussed as a residual risk, not
defended against by this architecture alone);
* physical extraction of key material from correctly functioning
protected hardware; and
* weaknesses in the underlying cryptographic primitives themselves.
13.2. T1: Replay of a Previously Authorized Act
*Attack.* An adversary captures a valid Execution Handle and its
associated Candidate Act and resubmits them later, attempting to
trigger the effect a second time.
Das Expires 14 March 2027 [Page 30]
Internet-Draft Execution-Finality Protocol Layer September 2026
# Attack
captured = intercept(candidate, authority)
sleep(arbitrary_delay)
resubmit(captured.candidate, captured.authority) # attempt #2
# Defense (Finality Sink, Step 8-10 of Section 11.1)
if authority.nonce_or_counter is already consumed:
return DENY # single-use state blocks attempt #2
*Guarantee.* Single-use nonce or counter consumption is atomic with
effectuation, so a captured Execution Handle cannot be reused after
its first successful consumption at its bound Finality Sink.
13.3. T2: Time-of-Check to Time-of-Use (TOCTOU) Act Substitution
*Attack.* An adversary obtains validation for a low-risk Candidate
Act (for example, exporting a small, permitted dataset) and then
attempts to substitute a different, higher-risk effect (a larger
dataset, a different destination) at the moment of release, hoping
the sink trusts the earlier validation result without rechecking the
act itself.
# Attack
authority = get_valid_authority(low_risk_candidate)
malicious_candidate = mutate(low_risk_candidate,
destination="attacker.example",
resource_scope="ALL_RECORDS")
finality_sink_receive(malicious_candidate, authority, sink_state)
# Defense (Step 9, and finality_sink_receive() in Section 11.2)
reconstructed_digest = canonical_digest(
malicious_candidate.load_bearing_attributes)
if reconstructed_digest != authority.candidate_act_digest:
return DENY # digest mismatch: the substituted act is rejected
*Guarantee.* The Finality Sink recomputes the act digest from sink-
visible attributes rather than trusting a caller-supplied description
of the act, closing the gap between what was validated and what is
actually released.
13.4. T3: Finality-Sink Substitution
*Attack.* An adversary obtains a valid Execution Handle scoped to one
Finality Sink (for example, a low-security internal export path) and
attempts to present it at a different, more consequential sink (for
example, direct external egress) that was never the intended release
boundary.
Das Expires 14 March 2027 [Page 31]
Internet-Draft Execution-Finality Protocol Layer September 2026
# Attack
authority = get_valid_authority(
candidate, finality_sink_id="internal-export")
finality_sink_receive(
candidate, authority,
sink_state=SinkState(sink_id="external-egress"))
# Defense
if authority.finality_sink_id != sink_state.sink_id:
return DENY
*Guarantee.* Sink-binding makes the Execution Handle meaningless
outside the specific Finality Sink it was issued for, preventing
lateral reuse across release boundaries of differing consequence.
13.5. T4: Stale Authorization After Policy or Revocation Change
*Attack.* An actor's authority is revoked (for example, an employee
is offboarded, an agent is suspended, a destination is blacklisted)
but the actor attempts to use an Execution Handle issued before the
revocation.
# Attack
authority = get_authority_issued_before_revocation(candidate)
revoke_actor(candidate.actor_id) # policy change
finality_sink_receive(candidate, authority, sink_state)
# Defense
if authority.policy_epoch != sink_state.policy_epoch:
return DENY
if authority.revocation_epoch != sink_state.revocation_epoch:
return DENY
*Guarantee.* Binding the Execution Handle to a policy epoch and a
revocation epoch, and requiring the Finality Sink to hold current
epoch state, ensures a policy or revocation change becomes effective
at the next effectuation attempt rather than only at the next
Execution Handle issuance.
*Residual risk.* If the sink's local epoch state is itself stale (for
example, due to a partitioned network preventing epoch propagation),
a revoked actor may continue to pass this check until the sink's
epoch state catches up. Deployments with a low tolerance for this
window SHOULD favor short epoch-propagation intervals or synchronous
epoch lookups for the highest-consequence operation classes.
Das Expires 14 March 2027 [Page 32]
Internet-Draft Execution-Finality Protocol Layer September 2026
13.6. T5: Forged or Fabricated Validation Evidence
*Attack.* An adversary who controls the ordinary compute environment
fabricates an Execution Handle or validation-evidence record without
having gone through the Protected Enforcement Domain.
# Attack
forged_authority = ExecutionAuthority(
candidate_act_digest=digest(candidate),
permitted_effect="EXPORT_ALL",
non_bearer=true, ...) # never issued by a PED
# Defense
if not verify_validation_evidence(authority):
return DENY # sig/MAC verification against the PED's key fails
*Guarantee.* The Finality Sink verifies validation evidence
cryptographically against keys or attestation roots controlled by the
Protected Enforcement Domain, not against anything the ordinary
compute environment can fabricate. This is the property that
requires the Protected Enforcement Domain to be genuinely protected
(see Section 13.1): if the ordinary compute environment can extract
or spoof the PED's signing capability, this defense fails, which is
why PED integrity is treated as a trust anchor rather than something
this layer alone guarantees.
13.7. T6: Silent Downgrade / Fail-Open Under Load or Incident
*Attack.* Rather than attacking the cryptography, an adversary
induces operational conditions (load spikes, timeouts, an incident-
response scramble) under which an operator or an automated system
quietly relaxes a Finality Sink from strict mode to permissive or
observe mode (see Section 11.6) to "unblock" traffic, without an
auditable decision to do so.
# Attack surface: an on-call engineer, under pressure, flips
# sink_state.mode from STRICT to PERMISSIVE to relieve a queue,
# without a tracked change record.
# Mitigation pattern
def set_sink_mode(sink_state, new_mode, actor, justification):
if new_mode is LESS_STRICT_THAN(sink_state.mode):
require_explicit_authorization(actor, justification)
emit_audit_event(sink_state.sink_id, sink_state.mode,
new_mode, actor, justification)
sink_state.mode = new_mode
Das Expires 14 March 2027 [Page 33]
Internet-Draft Execution-Finality Protocol Layer September 2026
*Guarantee.* This is a process/operational control rather than a
cryptographic one: the architecture does not prevent an operator from
choosing to weaken enforcement, but it recommends making any such
weakening an explicit, attributable, audited action rather than a
silent default, so that a downgrade is itself detectable and
reviewable.
13.8. T7: Alternate Egress / Unverified Substitute Path
*Attack.* Rather than attacking the protected release path, an
adversary locates a different, unprotected mechanism that produces
the same or an equivalent external effect (for example, a debug
export endpoint, a legacy API version, a secondary network interface)
that was never fitted with a Finality Sink.
*Defense posture.* This attack cannot be closed by cryptography at a
single sink; it requires the deployment to enumerate every path
capable of producing the protected effect and ensure each one is
either fitted with an equivalent Finality Sink or is itself
decommissioned. Section 15 calls this out explicitly: protecting one
nominal Finality Sink while leaving an unverified substitute path
available weakens the intended property, and this document treats
path enumeration as a deployment-time responsibility rather than
something the protocol pattern can discover automatically.
13.9. Threat Summary Table
+====+===============+====================+=========================+
| ID | Threat | Primary defense | Residual risk |
+====+===============+====================+=========================+
| T1 | Replay | Single-use nonce/ | None if nonce store is |
| | | counter, atomic | itself protected |
| | | consumption | |
+----+---------------+--------------------+-------------------------+
| T2 | Act | Sink-side digest | None if load-bearing |
| | substitution | reconstruction | attributes are |
| | (TOCTOU) | | exhaustively enumerated |
+----+---------------+--------------------+-------------------------+
| T3 | Sink | Finality-Sink | None if sink identity |
| | substitution | binding check | is unforgeable |
+----+---------------+--------------------+-------------------------+
| T4 | Stale | Policy/revocation | Propagation-delay |
| | authorization | epoch binding | window on partitioned |
| | | | sinks |
+----+---------------+--------------------+-------------------------+
| T5 | Forged | Cryptographic | Full PED compromise |
| | evidence | verification | (trust-anchor |
| | | against PED root | assumption) |
Das Expires 14 March 2027 [Page 34]
Internet-Draft Execution-Finality Protocol Layer September 2026
+----+---------------+--------------------+-------------------------+
| T6 | Silent | Auditable, | Operational/process |
| | downgrade | attributable | discipline, not |
| | | mode-change | cryptographic |
| | | control | |
+----+---------------+--------------------+-------------------------+
| T7 | Alternate/ | Deployment-time | Unenumerated paths |
| | unverified | path enumeration | remain fully |
| | path | | unprotected |
+----+---------------+--------------------+-------------------------+
Table 3
14. Industry and Infrastructure Relevance
Execution finality is relevant wherever software can prepare an act
that produces an external, persistent, financial, communicative,
jurisdictional, or physical consequence.
14.1. Artificial Intelligence and Agentic Systems
Relevant operations include model-output release, tool invocation,
retrieval actions, code execution, agent-to-agent delegation, data
export, memory writes, external API calls, autonomous workflows, and
machine-generated decisions that trigger downstream systems.
Principal benefit: compromise or overreach of the reasoning
environment does not automatically grant unrestricted effectuation
authority.
Representative Finality Sinks: tool gateway, API dispatcher, egress
broker, memory writer, model-output emitter, operating-system broker,
or enterprise control point.
14.2. Telecommunications, 5G, 6G, and AI-Native Networks
Relevant operations include message or packet release, roaming,
network-slice changes, subscriber-impacting commands, radio emission,
gateway egress, AI-RAN actions, machine-to-machine commands, and non-
terrestrial-network operations.
Principal benefit: authenticated network intelligence can remain
distinct from final authority to create a network or RF consequence.
Representative Finality Sinks: telecom gateway, SBC, network
function, user-plane/control-plane boundary, radio chain, satellite
gateway, or device communication broker.
Das Expires 14 March 2027 [Page 35]
Internet-Draft Execution-Finality Protocol Layer September 2026
14.3. Cloud, Edge, and Data-Centre Infrastructure
Relevant operations include persistent writes, privileged state
changes, DMA, accelerator transfers, storage actions, SmartNIC/DPU
operations, tenant egress, infrastructure APIs, and confidential-
computing boundary transitions.
Principal benefit: compromise of an application, VM, container, model
server, or accelerator workload need not automatically become
authority for every persistent or external effect exposed by the
infrastructure.
Representative Finality Sinks: storage controller, memory controller,
SmartNIC, DPU, hypervisor boundary, accelerator interface, secure
service, or egress gateway.
14.4. Payments, Banking, Fintech, and Digital Assets
Relevant operations include payments, account transfers, settlement,
digital-asset movement, CBDC operations, trading instructions, escrow
release, ledger commitments, and machine-generated financial actions.
Principal benefit: existing payment-domain authorization can be
composed with additional act-specific enterprise, purpose, agent,
jurisdiction, destination, and protected-state constraints.
Representative Finality Sinks: payment-release interface, settlement
gateway, ledger bridge, account-transfer boundary, trading gateway,
or protected wallet interface.
14.5. Data Governance, Privacy, and Cross-Border Data Use
Relevant operations include export, disclosure, model access to
protected datasets, cross-border transfer, data sharing, retrieval,
publication, and persistent reconstruction of protected information.
Principal benefit: policy about purpose, recipient, destination,
jurisdiction, and permitted data scope can remain technically coupled
to the release boundary rather than existing only as upstream policy.
Representative Finality Sinks: data egress gateway, database export
interface, object-store release boundary, API dispatcher, download
service, or disclosure broker.
Das Expires 14 March 2027 [Page 36]
Internet-Draft Execution-Finality Protocol Layer September 2026
14.6. Satellite, Space, and Non-Terrestrial Infrastructure
Relevant operations include command uplink, RF transmission, payload
control, routing, cross-link changes, beam configuration, and
autonomous spacecraft actions.
Principal benefit: command preparation can be separated from
authority to create the mission or RF consequence.
Representative Finality Sinks: command-uplink gateway, RF chain,
payload controller, protected spacecraft interface, or ground-station
release point.
14.7. Industrial Control, Energy, and Critical Infrastructure
Relevant operations include process-control commands, breaker
operations, valve movements, safety-state changes, plant
configuration, grid control, water-system control, and emergency
automation.
Principal benefit: application or AI compromise does not
automatically create unrestricted physical-control authority.
Representative Finality Sinks: safety PLC, industrial gateway,
actuator controller, breaker interface, motor controller, or
protected control boundary.
14.8. Robotics, Vehicles, Drones, and Autonomous Machines
Relevant operations include steering, braking, acceleration, robotic
motion, drone navigation, payload actions, access control, and other
kinetic effects.
Principal benefit: a planner or perception system can compute an
action while final actuation remains dependent on independently
verified authority and current protected state.
Representative Finality Sinks: drive-by-wire controller, motor
controller, robotic actuator, flight-control boundary, or protected
device broker.
14.9. Healthcare and Safety-Critical Digital Systems
Relevant operations include device setting changes, patient-data
disclosure, safety alerts, clinical workflow actions, and machine-
generated commands to connected medical equipment.
Das Expires 14 March 2027 [Page 37]
Internet-Draft Execution-Finality Protocol Layer September 2026
Principal benefit: recommendation, computation, and externally
effective clinical action can remain distinct authorization stages.
Representative Finality Sinks: device controller, clinical workflow
dispatcher, protected data gateway, or safety interlock boundary.
14.10. Cybersecurity and Automated Response
Relevant operations include account disabling, credential rotation,
firewall changes, workload isolation, data deletion, quarantine,
network blocking, and automated incident-response actions.
Principal benefit: a security agent may detect and propose
remediation without automatically possessing unrestricted authority
to create a potentially destructive response.
Representative Finality Sinks: identity-control plane, firewall
controller, orchestration gateway, storage-delete boundary, endpoint-
management service, or cloud control plane.
14.11. Content Publication and Machine-Generated Communications
Relevant operations include public posting, outbound messaging,
automated notification, mass communication, email release, content
publication, and AI-generated customer or citizen communication.
Principal benefit: generating content remains separate from authority
to publish, transmit, notify, or otherwise make the communication
externally effective.
Representative Finality Sinks: publisher, messaging gateway, email
relay, notification renderer, telecom gateway, or platform
communication broker.
14.12. Cross-Industry Common Structure
Although the underlying technologies differ, the same control pattern
can be applied:
Das Expires 14 March 2027 [Page 38]
Internet-Draft Execution-Finality Protocol Layer September 2026
proposed machine operation
->
Candidate Act
->
Non-Effective State
->
protected act-specific validation
->
protected validation evidence
->
scoped non-bearer effectuation authority
->
Finality-Sink verification
->
atomic consumption where required
->
externally effective consequence
The proposal is therefore not that every industry must use the same
protocol message, cryptographic algorithm, hardware root, or policy
language.
The proposed common layer is the invariant that protected
authorization of the specific act remains a technical dependency of
the consequence boundary itself.
15. Security and Failure Considerations
Implementations should consider the threats enumerated in Section 13,
and in addition:
* replay;
* stale authorization;
* compromised applications;
* compromised AI agents;
* forged validation evidence;
* policy rollback;
* nonce reuse;
* quota races;
* destination substitution;
Das Expires 14 March 2027 [Page 39]
Internet-Draft Execution-Finality Protocol Layer September 2026
* sink substitution;
* authority forwarding;
* cross-session reuse;
* fail-open behavior;
* bypass paths;
* alternate egress mechanisms;
* protected-domain compromise; and
* denial-of-service attacks.
The ordinary compute environment should not be assumed trustworthy
merely because it generated the Candidate Act.
High-assurance deployments may fail closed when required protected
authorization cannot be verified.
Deployments should also identify equivalent alternate paths that
could create the same external effect (see Section 13.8). Protecting
one nominal Finality Sink while leaving an unverified substitute path
would weaken the intended property.
16. Frequently Asked Questions
*Is execution finality another authentication protocol?* No.
Authentication establishes who or what is interacting. Execution
finality determines whether a specific proposed act is authorized to
become externally effective.
*Is this a replacement for TLS or HTTPS?* No. TLS and HTTPS remain
necessary for protected communication. Execution finality addresses
the semantic authorization of the consequence carried or requested
through that protected communication (see Section 11).
*Is this just OAuth with another token?* No. OAuth provides
delegated authorization and can strongly restrict API access.
Execution finality focuses on the final act-specific release
dependency at the consequence boundary, potentially adding current
state, purpose, destination, jurisdiction, freshness, and Finality-
Sink binding.
Das Expires 14 March 2027 [Page 40]
Internet-Draft Execution-Finality Protocol Layer September 2026
*Does EMV already do this?* EMV does something importantly similar
inside the payment domain: transaction-specific cryptographic
information and authorization are part of deciding whether a payment
proceeds. The proposed contribution is not to recreate EMV. It is
to generalize an execution-finality abstraction across heterogeneous
machine acts and to make the protected consequence boundary explicit.
*Why not simply put all checks in the application?* Application-level
checks can be effective, but a compromised or over-privileged
application may also possess the path that produces the external
effect. Execution finality separates ordinary computation from final
consequence authority and places independent verification at or
immediately before the effectuation boundary.
*Is the Finality Sink necessarily hardware?* No. It is a functional
boundary. It may be implemented in hardware, protected software, an
OS broker, API gateway, telecom function, storage controller,
payment-release component, secure enclave, or other system
controlling first usable release of the effect.
*Does this require blockchain?* No. A ledger can be used for
evidence or state anchoring where useful, but it is not a baseline
requirement.
*Would this make AI systems too slow?* Not necessarily. Slow policy
reasoning can occur on the cold path. The effectuation hot path can
be reduced to deterministic verification, state checks, replay
prevention, and bounded release (see Section 10).
*What happens if validation infrastructure fails?* The assurance
profile determines behavior. For high-consequence acts, fail-closed
behavior may maintain the Candidate Act in the Non-Effective State
until required authority can be verified.
*Does adopting this require replacing TLS, OAuth, or EMV deployments
already in production?* No. Section 11 describes an additive shim/
gateway pattern intended for incremental, operation-by-operation
adoption alongside unmodified legacy mechanisms.
*What is the Internet missing in one sentence?* A general cross-
domain execution-finality layer that makes protected, act-specific
authorization a technical prerequisite of externally effective
machine consequence.
*What is the core invariant?* A machine may compute, prepare, or
propose an act, but computation alone does not create the authority
to make that act externally effective.
Das Expires 14 March 2027 [Page 41]
Internet-Draft Execution-Finality Protocol Layer September 2026
17. Resources
The following resources provide additional public context, related
prior disclosure, and a runnable reference implementation for the
execution-finality architecture described in this document. They are
provided for informational context; this Internet-Draft defines the
architectural discussion independently of any of them.
* EU AI Alliance Futurium community article, [FUTURIUM-EU]:
"Protecting Europe: A Technical Foundation for Digital
Sovereignty, Data Protection, and AI Governance," discussing the
same execution-finality architecture in the context of EU digital-
sovereignty and AI-governance policy.
* WIPO PatentScope international publication, [WIPO-WO2026150382]:
WO 2026/150382, "Hardware-Rooted Execution-Finality System for
Sovereign Artificial Intelligence Infrastructure, AI-Native
Telecommunications and Satellites," the published international
patent application corresponding to the architecture described in
this document.
* Privacy Finality Reference, [GITHUB-PRIVACY-FINALITY]: a public,
runnable reference implementation of Candidate-Act-based
execution-finality enforcement, illustrating the Candidate Act,
Protected Enforcement Domain, Execution Handle, and Finality Sink
constructs defined in this document.
* Privacy Finality Reference, release v0.1.0,
[GITHUB-PRIVACY-FINALITY-RELEASE]: the versioned reference-
implementation release corresponding to the architecture described
in this document.
* Execution-Finality for AI Agents, GPUs, Confidential Computing,
and Zero-Trust Automation, [DAS-FOUNDATIONAL-EF-IMPL]: the primary
reference implementation from which the detailed methodology,
architecture-to-code mapping, threat-model testing, and benchmark
results in Appendix B are drawn.
18. Related Execution-Finality Internet-Drafts
This document is part of a series of Internet-Drafts by the same
author applying the Candidate Act / Non-Effective State / Protected
Enforcement Domain / scoped non-bearer Execution Handle / independent
Finality Sink architecture described in this document to specific
domains, regulatory frameworks, and neural/agentic-AI surfaces. They
are listed here for cross-reference; none of them is incorporated
normatively into this document, and each remains an independent Work
in Progress.
Das Expires 14 March 2027 [Page 42]
Internet-Draft Execution-Finality Protocol Layer September 2026
18.1. Foundational and Cross-Domain
[DAS-CANDIDATE-ACT-FINALITY], "The DAS Protocols: Candidate Act
Finality," and [DAS-PROTOCOLS-ENTERPRISE-AI], "The DAS Protocols:
Enterprise AI Governance," develop the same foundational vocabulary
used throughout this document from complementary angles.
18.2. Privacy and Regulatory Enforcement
[DAS-PURPOSE-EXECUTION-FINALITY], "Data-Purpose Laundering
Prevention: Execution-Finality for Preventing Cross-Domain Data
Reuse"; [DAS-EU-AI-ACT], "Technical Execution Enforcement for the EU
AI Act"; and [DAS-GLOBAL-PRIVACY], "Global Privacy Execution
Enforcement," apply the architecture to purpose-limitation, EU AI Act
high-risk system, and general-purpose privacy enforcement
respectively. [DAS-PRECISION-EGRESS], "Precision-Bounded Egress,"
and [DAS-DIGITAL-SOVEREIGNTY], "Execution-Finality for Digital
Sovereignty," apply it to data-precision export bounds and to
digital-sovereignty enforcement.
18.3. Telecommunications and Non-Terrestrial Networks
[DAS-AI-NATIVE-6G], "Execution-Finality for AI-Native 5G/6G and
O-RAN"; [DAS-6G-CVID], "6G Query-Scoped Communication Handles";
[DAS-MAP-DISCOVERY], "Execution-Finality for MAP Discovery and
Communication"; and [DAS-NTN-RF], "Execution-Finality for Non-
Terrestrial Network RF Operations," apply the architecture to 5G/6G/
O-RAN, query-scoped communication handles, MAP discovery, and
satellite/NTN RF command paths.
18.4. Neural, Agentic, and Model-Governance Applications
[DAS-HARDWARE-ENFORCED-EF], "Computation Is Not Authority: Hardware-
Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and
Industrial Agents," is the most directly related companion, applying
this document's architecture specifically to MCP tool dispatch,
computer use, memory writes, GPU/accelerator egress, and industrial-
agent settlement, with a runnable reference implementation and threat
model of its own. [DAS-RATS-EXTRACT], "Execution-Finality for
Frontier Model Information Extraction Control," and its companion
[DAS-RATS-OPENAI-ANTHROPIC], "Execution-Finality for Frontier Model
Information Extraction Control: OpenAI and Anthropic," apply it to
controlling release of sensitive model information.
[DAS-RATS-ATTESTATION-BND], "RATS Attestation-Bound Execution-
Finality," binds the architecture to RATS attestation evidence.
[DAS-CHILD-SAFE-RENDERING], "Execution-Finality for Preventing
Unauthorized Rendering of Age-Restricted Content," and
[DAS-AI-INTEROP], "Execution-Finality for Third-Party AI
Das Expires 14 March 2027 [Page 43]
Internet-Draft Execution-Finality Protocol Layer September 2026
Interoperability Under EU DMA Article 6(7)," apply it to child-safe
content rendering and to third-party AI interoperability under EU DMA
Article 6(7). [DAS-AGENTIC-TOOL-BINDING], "tool_use Is Not invoke():
Binding Execution-Finality to Agentic Tool Calls";
[DAS-ENTERPRISE-AI-OUTPUT], "Execution-Finality for Enterprise AI
Output"; [DAS-AGENTIC-EXECUTION-FINALITY], "Execution-Finality for
Agentic AI Systems"; and [DAS-AGENTIC-AI-TOOL-EXEC], "Agentic AI Tool
Execution-Finality," each bind the architecture to a further agentic
tool-use or enterprise AI-output surface.
18.5. Settlement and Operational Technology
[DAS-PAYMENT-FINALITY], "A Signed Instruction Is Not Settlement:
Finality for Agentic and API Payments," and [DAS-OT-ACTUATION],
"Execution-Finality for Operational Technology Actuation," apply the
architecture to agentic/API payment settlement and to OT/industrial-
actuation command paths.
19. IANA Considerations
This document has no IANA actions.
20. Informative References
[DAS-6G-CVID]
Das, S., "6G Query-Scoped Communication Handles", Work in
Progress, 2026, <https://datatracker.ietf.org/doc/draft-
das-6g-query-scoped-communication-handles/>.
[DAS-AGENTIC-AI-TOOL-EXEC]
Das, S., "Agentic AI Tool Execution-Finality", Work in
Progress, 2026, <https://datatracker.ietf.org/doc/draft-
agentic-ai-tool-execution-finality/>.
[DAS-AGENTIC-EXECUTION-FINALITY]
Das, S., "Execution-Finality for Agentic AI Systems", Work
in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-agentic-execution-finality/>.
[DAS-AGENTIC-TOOL-BINDING]
Das, S., "tool_use Is Not invoke(): Binding Execution-
Finality to Agentic Tool Calls", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-agentic-tool-
binding/>.
Das Expires 14 March 2027 [Page 44]
Internet-Draft Execution-Finality Protocol Layer September 2026
[DAS-AI-INTEROP]
Das, S., "Execution-Finality for Third-Party AI
Interoperability Under EU DMA Article 6(7)", Work in
Progress, 2026, <https://datatracker.ietf.org/doc/draft-
das-execution-finality-ai-interoperability/>.
[DAS-AI-NATIVE-6G]
Das, S., "Execution-Finality for AI-Native 5G/6G and
O-RAN", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-ai-native-6g-
execution-finality/>.
[DAS-CANDIDATE-ACT-FINALITY]
Das, S., "The DAS Protocols: Candidate Act Finality", Work
in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-protocols-candidate-act-finality/>.
[DAS-CHILD-SAFE-RENDERING]
Das, S., "Execution-Finality for Preventing Unauthorized
Rendering of Age-Restricted Content", Work in Progress,
2026, <https://datatracker.ietf.org/doc/draft-das-child-
safe-rendering-finality/>.
[DAS-DIGITAL-SOVEREIGNTY]
Das, S., "Execution-Finality for Digital Sovereignty",
Work in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-digital-sovereignty-finality/>.
[DAS-ENTERPRISE-AI-OUTPUT]
Das, S., "Execution-Finality for Enterprise AI Output",
Work in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-enterprise-ai-output-finality/>.
[DAS-EU-AI-ACT]
Das, S., "Technical Execution Enforcement for the EU AI
Act", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-eu-ai-act-
execution-enforcement/>.
[DAS-FOUNDATIONAL-EF-IMPL]
Das, S., "Execution-Finality for AI Agents, GPUs,
Confidential Computing, and Zero-Trust Automation --
Reference Implementation", 2026,
<https://github.com/sangmdas/Execution-Finality-for-AI-
Agents-GPUs-Confidential-Computing-and-Zero-Trust-
Automation>.
Das Expires 14 March 2027 [Page 45]
Internet-Draft Execution-Finality Protocol Layer September 2026
[DAS-GLOBAL-PRIVACY]
Das, S., "Global Privacy Execution Enforcement", Work in
Progress, 2026, <https://datatracker.ietf.org/doc/draft-
das-global-privacy-execution-enforcement/>.
[DAS-HARDWARE-ENFORCED-EF]
Das, S., "Computation Is Not Authority: Hardware-Enforced
Execution-Finality for Agentic AI, MCP Tool Calls, and
Industrial Agents", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-hardware-
enforced-execution-finality/>.
[DAS-MAP-DISCOVERY]
Das, S., "Execution-Finality for MAP Discovery and
Communication", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-map-discovery-
communication-finality/>.
[DAS-NTN-RF]
Das, S., "Execution-Finality for Non-Terrestrial Network
RF Operations", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-ntn-rf-
execution-finality/>.
[DAS-OT-ACTUATION]
Das, S., "Execution-Finality for Operational Technology
Actuation", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-ot-actuation-
finality/>.
[DAS-PAYMENT-FINALITY]
Das, S., "A Signed Instruction Is Not Settlement: Finality
for Agentic and API Payments", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-payment-
execution-finality/>.
[DAS-PRECISION-EGRESS]
Das, S., "Precision-Bounded Egress", Work in Progress,
2026, <https://datatracker.ietf.org/doc/draft-das-
precision-bounded-egress/>.
[DAS-PROTOCOLS-ENTERPRISE-AI]
Das, S., "The DAS Protocols: Enterprise AI Governance",
Work in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-protocols-enterprise-ai/>.
Das Expires 14 March 2027 [Page 46]
Internet-Draft Execution-Finality Protocol Layer September 2026
[DAS-PURPOSE-EXECUTION-FINALITY]
Das, S., "Data-Purpose Laundering Prevention: Execution-
Finality for Preventing Cross-Domain Data Reuse", Work in
Progress, 2026, <https://datatracker.ietf.org/doc/draft-
das-purpose-execution-finality/>.
[DAS-RATS-ATTESTATION-BND]
Das, S., "RATS Attestation-Bound Execution-Finality", Work
in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-rats-attestation-bnd-execution-finality/>.
[DAS-RATS-EXTRACT]
Das, S., "Execution-Finality for Frontier Model
Information Extraction Control", Work in Progress, 2026,
<https://datatracker.ietf.org/doc/draft-das-rats-frontier-
model-extraction/>.
[DAS-RATS-OPENAI-ANTHROPIC]
Das, S., "Execution-Finality for Frontier Model
Information Extraction Control: OpenAI and Anthropic",
Work in Progress, 2026, <https://datatracker.ietf.org/doc/
draft-das-rats-openai-anthropic-extraction/>.
[EMV-3DS] EMVCo, "EMV 3-D Secure and related specifications and
explanatory material", <https://www.emvco.com/>.
[EMV-CHIP] EMVCo, "EMV Chip and related EMV Chip security
documentation", <https://www.emvco.com/>.
[FUTURIUM-EU]
Das, S. and European Commission, Apply AI Alliance,
Futurium, "Protecting Europe: A Technical Foundation for
Digital Sovereignty, Data Protection, and AI Governance",
2026, <https://futurium.ec.europa.eu/en/apply-ai-alliance/
community-content/protecting-europe-technical-foundation-
digital-sovereignty-data-protection-and-ai-governance>.
[GITHUB-PRIVACY-FINALITY]
Das, S., "Privacy Finality Reference: A Public Runnable
Reference Implementation of Candidate-Act-Based Execution-
Finality Enforcement", 2026,
<https://github.com/sangmdas/privacy-finality-reference>.
[GITHUB-PRIVACY-FINALITY-RELEASE]
Das, S., "Privacy Finality Reference, Release v0.1.0",
2026, <https://github.com/sangmdas/privacy-finality-
reference/releases/tag/v0.1.0>.
Das Expires 14 March 2027 [Page 47]
Internet-Draft Execution-Finality Protocol Layer September 2026
[HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[WIPO-WO2026150382]
Das, S. and World Intellectual Property Organization,
PATENTSCOPE, "Hardware-Rooted Execution-Finality System
for Sovereign Artificial Intelligence Infrastructure, AI-
Native Telecommunications and Satellites", WO 2026/150382,
2026,
<https://patentscope2.wipo.int/search/en/WO2026150382>.
[ZENODO-DAS]
Das, S., "The Internet Solved Communication. It Never
Solved Authority", August 2026,
<https://zenodo.org/records/22082995>.
Appendix A. Reference Architecture Diagram (FIG. 1A-1C)
This appendix reproduces, in text-artwork form, the three-sheet
reference architecture drawing (FIG. 1A, FIG. 1B, FIG. 1C)
corresponding to the execution-finality pipeline described in
Section 5 through Section 8 and worked through step-by-step in
Section 12.1. Reference numerals 100 through 138 are used
consistently with the underlying patent disclosure referenced in
Section 17 and are cross-referenced against the vocabulary of this
document in Appendix A.4.
A.1. FIG. 1A -- Candidate Act Generation and Staging
Das Expires 14 March 2027 [Page 48]
Internet-Draft Execution-Finality Protocol Layer September 2026
+--------------------------------------------------------------+
| 100 COMPUTE / WORKLOAD PLANE |
| AI model, application, network function, payment engine, |
| content system, agent, digital twin, or device |
+--------------------------------------------------------------+
|
v
+--------------------------------------------------------------+
| 102 CANDIDATE ACT GENERATED |
| Proposed output, packet, tensor, command, payment, API call, |
| transmission, memory release, actuator command, rendering |
| event, storage write, or other act |
| |
| Status: NON-EFFECTIVE / PENDING |
+--------------------------------------------------------------+
|
v
+--------------------------------------------------------------+
| 104 NON-EFFECTIVE STAGING / HOLD STATE PLANE |
| Candidate Act may be computed, queued, buffered, ranked, |
| simulated, encrypted, sealed, or provisionally prepared, but |
| cannot be released through a Finality Sink or cross an |
| execution-finality boundary. |
+--------------------------------------------------------------+
|
v
+--------------------------------------------------------------+
| 106 PROTECTED AUTHORITY PLANE / PROTECTED ENFORCEMENT |
| DOMAIN |
| TEE, HSM, secure element, SmartNIC, DPU, secure enclave, |
| TPM-backed module, FPGA, baseband security domain, protected |
| controller, or equivalent structure |
+--------------------------------------------------------------+
|
v
+--------------------------------------------------------------+
| 108 HCAD / MACHINE-VERIFIABLE ACT DESCRIPTOR |
| Descriptor binds act class, effect class, source, destination, |
| purpose, jurisdiction, policy epoch, nonce, freshness, |
| Finality Sink, boundary, scope, and evidence |
+--------------------------------------------------------------+
|
( CONNECTOR A )
|
v
[ continued on FIG. 1B ]
Das Expires 14 March 2027 [Page 49]
Internet-Draft Execution-Finality Protocol Layer September 2026
A.2. FIG. 1B -- Protected Validation and Scoped Capability Issuance
( CONNECTOR A )
[ continued from FIG. 1A ]
|
v
+--------------------------------------------------------------+
| 110 PROTECTED PREDICATE VALIDATION |
| Validates authority, purpose, jurisdiction, consent, |
| ALF/RBD where applicable, revocation, freshness, policy |
| epoch, sink binding, boundary binding, runtime evidence, |
| quota, budget, and protected state |
+--------------------------------------------------------------+
| |
FAILS | | PASSES
v v
+---------------------------------+ +---------------------------------+
| 112 VALIDATION FAILS | | 114 VALIDATION PASSES |
| Deny, suppress, quarantine, | | Continue to protected state, |
| zeroize, or hold. No capability | | evidence, and capability |
| released. | | generation sequence. |
+---------------------------------+ +---------------------------------+
| |
v v
+---------------------------------+ +--------------------------------+
| 116 FAIL-CLOSED / DENIAL | | 118 PROTECTED STATE UPDATE / |
| ENFORCEMENT HANDLING | | CONSUMPTION |
| Candidate Act remains non-effective.| | Nonce, quota, budget, session, |
| External effect disabled. No | | revocation, monotonic, or replay |
| scoped non-bearer capability is | | state updated/consumed. |
| released. Denial evidence or | +--------------------------------+
| denial LAVR is committed as |
| protected enforcement evidence of v
| non-completion; denial-related +--------------------------------+
| protected state may be advanced, | 120 PROTECTED VALIDATION |
| locked, quarantined, or | EVIDENCE / LAVR COMMITMENT |
| consumed-as-denied to prevent | Protected validation evidence, |
| replay, rollback, stale retry, | receipt, or LAVR is committed |
| substitution, or cross-sink | before or atomically with scoped |
| laundering. | non-bearer capability availability.|
+---------------------------------+ +--------------------------------+
|
v
+--------------------------------+
| 122 SCOPED NON-BEARER |
| CAPABILITY AVAILABILITY / |
| RELEASE |
| Capability is act-bound, |
Das Expires 14 March 2027 [Page 50]
Internet-Draft Execution-Finality Protocol Layer September 2026
| descriptor-bound, sink-bound, |
| boundary-bound, nonce-bound, |
| scope-bound, protected-state-bound, |
| and evidence-bound. |
+--------------------------------+
|
v
+--------------------------------+
| 124 FINALITY SINK / |
| EFFECTUATION PLANE |
| Memory controller, DMA engine, |
| PCIe/CXL/NVLink/UALink boundary, |
| SmartNIC, DPU, UPF/N6 egress, |
| radio chain, payment terminal, |
| ledger bridge, renderer, actuator, |
| API dispatcher, storage writer, or |
| model-output emitter |
+--------------------------------+
|
( CONNECTOR B )
|
v
[ continued on FIG. 1C ]
A.3. FIG. 1C -- Sink-Side Verification and Effectuation
( CONNECTOR B )
[ continued from FIG. 1B ]
|
v
+--------------------------------------------------------------+
| 126 SINK-SIDE DESCRIPTOR BUILD / MEASUREMENT |
| Finality Sink builds, reconstructs, measures, or verifies a |
| sink-side descriptor corresponding to the Candidate Act and |
| local effectuation boundary |
+--------------------------------------------------------------+
|
v
+--------------------------------------------------------------+
| 128 FINALITY SINK VERIFICATION |
| Verifies scoped capability against exact Candidate Act, |
| descriptor digest, sink, boundary, nonce, policy epoch, |
| evidence reference, protected state transition, and scope |
+--------------------------------------------------------------+
| |
FAILS | | PASSES
v v
+---------------------------------+ +---------------------------------+
Das Expires 14 March 2027 [Page 51]
Internet-Draft Execution-Finality Protocol Layer September 2026
| 132 SINK VERIFICATION FAILS | | 134 SINK VERIFICATION PASSES |
| Candidate Act suppressed, | | External effect enabled only |
| quarantined, zeroized, denied, | | within authorized scope. |
| or withheld. External effect | | Candidate Act may now be |
| disabled. | | released through the Finality |
+---------------------------------+ | Sink and cross the execution- |
| | finality boundary. |
v +---------------------------------+
+---------------------------------+ |
| 136 FAIL-CLOSED AT SINK | v
| No transmission, rendering, | +---------------------------------+
| write, settlement, emission, | | 130 CAPABILITY CONSUMPTION |
| actuation, dispatch, or release | | Capability will be consumed, |
| occurs. | | invalidated, burned, marked, or |
+---------------------------------+ | state-advanced before or |
| atomically with external |
| effectuation to prevent replay, |
| reuse, duplicate effectuation, or |
| cross-sink use. |
+---------------------------------+
|
v
+--------------------------------+
| 137 SINK-SIDE FINALITY RECEIPT / |
| OUTPUT LAVR |
| Upon successful sink verification, |
| the Finality Sink or protected |
| enforcement domain may commit |
| sink-side finality evidence |
| representing capability |
| verification, sink identity, |
| boundary identity, protected-state |
| reference, permitted scope, and |
| external effectuation status. |
+--------------------------------+
|
v
+--------------------------------+
| 138 EXTERNALLY EFFECTIVE ACT |
| Act is transmitted, rendered, |
| written, actuated, settled, |
| emitted, committed, or otherwise |
| effectuated. |
| |
| Status: EFFECTIVE |
+--------------------------------+
Das Expires 14 March 2027 [Page 52]
Internet-Draft Execution-Finality Protocol Layer September 2026
A.4. Reference Numeral Cross-Reference
The following table maps each reference numeral in FIG. 1A-1C to the
corresponding vocabulary defined in the body of this document.
+=========+===========================+============================+
| Ref. | Drawing element | Corresponding document |
| | | term |
+=========+===========================+============================+
| 100 | Compute / Workload Plane | Ordinary compute |
| | | environment (Section 13.1) |
+---------+---------------------------+----------------------------+
| 102 | Candidate Act Generated | Candidate Act (Section 6) |
+---------+---------------------------+----------------------------+
| 104 | Non-Effective Staging / | Non-Effective State |
| | Hold State Plane | (Section 6) |
+---------+---------------------------+----------------------------+
| 106 | Protected Authority Plane | Protected Enforcement |
| | | Domain (Section 7) |
+---------+---------------------------+----------------------------+
| 108 | HCAD / Machine-Verifiable | Canonical act digest / |
| | Act Descriptor | load-bearing act |
| | | attributes (Section 12.2) |
+---------+---------------------------+----------------------------+
| 110 | Protected Predicate | Protected validation |
| | Validation | (Section 12.1, Step 5) |
+---------+---------------------------+----------------------------+
| 112/116 | Validation Fails / Fail- | DENY path, Step 11 |
| | Closed Denial | (Section 12.1) |
+---------+---------------------------+----------------------------+
| 114 | Validation Passes | VALID result |
| | | (Section 12.2) |
+---------+---------------------------+----------------------------+
| 118 | Protected State Update / | Nonce/quota/revocation |
| | Consumption | state (Section 7) |
+---------+---------------------------+----------------------------+
| 120 | Protected Validation | Validation evidence, Step |
| | Evidence / LAVR | 6 (Section 12.1) |
+---------+---------------------------+----------------------------+
| 122 | Scoped Non-Bearer | Execution Handle |
| | Capability | (Section 7) |
+---------+---------------------------+----------------------------+
| 124 | Finality Sink / | Finality Sink (Section 8) |
| | Effectuation Plane | |
+---------+---------------------------+----------------------------+
| 126 | Sink-Side Descriptor | Act-digest reconstruction, |
| | Build | Step 9 (Section 12.1; |
| | | Section 13.3) |
Das Expires 14 March 2027 [Page 53]
Internet-Draft Execution-Finality Protocol Layer September 2026
+---------+---------------------------+----------------------------+
| 128 | Finality Sink | finality_sink_receive() |
| | Verification | (Section 12.2) |
+---------+---------------------------+----------------------------+
| 130 | Capability Consumption | Atomic consumption, Step |
| | | 10 (Section 12.1; |
| | | Section 13.2) |
+---------+---------------------------+----------------------------+
| 132/136 | Sink Verification Fails / | DENY at sink |
| | Fail-Closed at Sink | (Section 12.2) |
+---------+---------------------------+----------------------------+
| 134 | Sink Verification Passes | Effectuation within |
| | | verified scope (Section 8) |
+---------+---------------------------+----------------------------+
| 137 | Sink-Side Finality | Optional audit/ |
| | Receipt / Output LAVR | accountability evidence, |
| | | Step 12 (Section 12.1) |
+---------+---------------------------+----------------------------+
| 138 | Externally Effective Act | EFFECTUATED result |
| | | (Section 12.2) |
+---------+---------------------------+----------------------------+
Table 4
Appendix B. Reference Implementation -- Foundational Architecture
Methodology
This appendix documents, in detail, a hardened reference
implementation of the foundational execution-finality architecture
described in this document and diagrammed in Appendix A. It is
provided so the architecture can be read as executable, inspectable,
reproducible, and falsifiable, not only as prose. It is
informational: nothing in this appendix is a normative requirement of
this document, and the reference implementation is not itself a claim
of hardware non-bypassability or of universal production
certification (see Appendix B.13).
The full source code is published in a public GitHub repository,
[DAS-FOUNDATIONAL-EF-IMPL].
B.1. Objective and Architectural Invariant
The implementation tests a single architectural invariant: a
consequence-bearing operation may be computed, prepared, buffered,
queued, ranked, simulated, encrypted, sealed, or otherwise processed,
but it remains non-effective until the exact Candidate Act is
independently verified by the Finality Sink controlling the
corresponding external-effect boundary. The implementation therefore
Das Expires 14 March 2027 [Page 54]
Internet-Draft Execution-Finality Protocol Layer September 2026
keeps computation, authorization, and effectuation as distinct,
separately testable stages rather than collapsing them into a single
authorize() -> token -> execute() call (Appendix B.3).
B.2. Derivation from FIG. 1A-1C and Architecture-to-Code Mapping
The implementation follows the three-stage drawing in Appendix A
directly, rather than starting from a conventional token framework
and renaming its components. The implemented sequence is:
Compute / Workload Plane
-> Candidate Act
-> Non-Effective Hold
-> Protected Authority / PED
-> HCAD
-> Protected Predicate Validation
-> Protected-State Transition
-> Validation Evidence / LAVR
-> Scoped Capability
-> Finality Sink
-> Sink-Side Descriptor Reconstruction
-> Independent Verification
-> Capability Consumption
-> Sink Receipt
-> External Effect
The Candidate Act is initially non-effective. The protected
authority validates predicates and advances protected state.
Evidence is committed before or atomically with capability
availability. The Finality Sink independently reconstructs the local
descriptor, verifies the exact Candidate Act and all load-bearing
bindings, consumes the capability, and only then permits the external
effect.
Table 5 gives the exact mapping between the foundational architecture
elements used elsewhere in this document and the corresponding
runnable construct.
+=======================+===================================+
| Foundational | Runnable implementation |
| architecture element | |
+=======================+===================================+
| Compute / Workload | Any producer capable of |
| Plane | constructing CandidateAct |
+-----------------------+-----------------------------------+
| Candidate Act | Immutable CandidateAct dataclass |
+-----------------------+-----------------------------------+
| Non-Effective State | ActStatus.NON_EFFECTIVE |
Das Expires 14 March 2027 [Page 55]
Internet-Draft Execution-Finality Protocol Layer September 2026
+-----------------------+-----------------------------------+
| Protected Authority / | ProtectedAuthority |
| PED | |
+-----------------------+-----------------------------------+
| HCAD / machine- | HCAD + build_hcad() |
| verifiable descriptor | |
+-----------------------+-----------------------------------+
| Protected Predicate | Policy.validate() |
| Validation | |
+-----------------------+-----------------------------------+
| Protected State | ProtectedState |
+-----------------------+-----------------------------------+
| Protected State | StateTransition |
| Transition | |
+-----------------------+-----------------------------------+
| Validation Evidence / | ValidationEvidence |
| LAVR | |
+-----------------------+-----------------------------------+
| Evidence commitment | EvidenceStore |
+-----------------------+-----------------------------------+
| Scoped capability | Capability |
+-----------------------+-----------------------------------+
| Strict non-bearer | PresentationProof |
| profile | |
+-----------------------+-----------------------------------+
| Finality Sink | FinalitySink |
+-----------------------+-----------------------------------+
| Sink-side descriptor | Sink-local build_hcad() |
| reconstruction | |
+-----------------------+-----------------------------------+
| Replay consumption | InMemoryConsumptionStore / |
| | SQLiteConsumptionStore |
+-----------------------+-----------------------------------+
| Effect boundary | Guarded effectors (Appendix B.10) |
+-----------------------+-----------------------------------+
| Output / finality | SinkReceipt |
| receipt | |
+-----------------------+-----------------------------------+
| External effect | Bound effect handle invoked only |
| | after sink verification and claim |
+-----------------------+-----------------------------------+
Table 5
Das Expires 14 March 2027 [Page 56]
Internet-Draft Execution-Finality Protocol Layer September 2026
B.3. Why the Implementation Is Not Just authorize() -> token ->
execute()
The reference keeps decision, state, evidence, authority,
presentation, sink verification, replay consumption, and effectuation
as separately represented stages. This allows tests to mutate each
stage independently and determine whether the effect boundary still
fails closed. A signature alone is never treated as sufficient: the
sink verifies semantic consistency among the Candidate Act, HCAD,
policy epoch, evidence, protected-state transition, sink identity,
boundary identity, nonce, scope, and time bounds (Appendix B.9).
B.4. Implementation Languages
Three runtimes are intentionally included so that no single
language's own bugs can validate themselves:
+==============+================================+
| Runtime | Role |
+==============+================================+
| Python 3.11+ | Complete, readable reference |
| | implementation (state machine) |
+--------------+--------------------------------+
| Go 1.23.2 | Independent infrastructure- |
| | oriented verifier |
+--------------+--------------------------------+
| Node.js | Independent application/ |
| 22.16.0 | runtime verifier |
+--------------+--------------------------------+
Table 6
Python contains the complete state machine; Go and Node independently
reproduce the portable canonicalization and verify deterministic
cryptographic and finality vectors. Python was chosen for the
complete reference for auditability and readability, not because it
is asserted to be the optimal production implementation for every
latency class: for a 100-microsecond device or accelerator path, a
production implementation would more plausibly be native code,
firmware, kernel code, SmartNIC/DPU logic, FPGA logic, or another
device-resident implementation. A single-language test suite can be
self-consistent while still being wrong (Python could serialize a
structure incorrectly and another Python function could reproduce the
same mistake), which is why Go independently verifies
canonicalization, SHA-256, HMAC, and complete portable Finality Sink
vectors -- Go is also directly relevant to networking, gateways,
cloud infrastructure, sidecars, and telecom control-plane software,
and its Unicode-normalization dependency is vendored so conformance
Das Expires 14 March 2027 [Page 57]
Internet-Draft Execution-Finality Protocol Layer September 2026
tests can run without Internet access. Node.js was included because
JavaScript/TypeScript ecosystems are common in APIs, AI-agent tool
systems, service gateways, and application and cloud control planes;
the Node canonicalizer explicitly avoids relying on JavaScript's
ordinary UTF-16 lexical ordering for security-bound object keys.
B.5. Candidate Act Data Model and Deterministic Test Parameters
The Candidate Act represents the concrete proposed consequence, not
merely a generic permission:
Das Expires 14 March 2027 [Page 58]
Internet-Draft Execution-Finality Protocol Layer September 2026
+=========================+============================+
| Parameter | Meaning |
+=========================+============================+
| act_id | Candidate identifier |
+-------------------------+----------------------------+
| act_class | Operation type |
+-------------------------+----------------------------+
| effect_class | External consequence class |
+-------------------------+----------------------------+
| source | Workload/agent/service |
| | generating the act |
+-------------------------+----------------------------+
| destination | Exact consequence |
| | destination |
+-------------------------+----------------------------+
| purpose | Authorized purpose |
+-------------------------+----------------------------+
| jurisdiction | Applicable jurisdiction |
+-------------------------+----------------------------+
| policy_epoch | Policy version |
+-------------------------+----------------------------+
| nonce | Replay-resistant nonce |
+-------------------------+----------------------------+
| issued_at_ns | Candidate creation time |
+-------------------------+----------------------------+
| freshness_ns | Candidate validity |
| | interval |
+-------------------------+----------------------------+
| sink_id | Intended Finality Sink |
+-------------------------+----------------------------+
| boundary_id | Intended effect boundary |
+-------------------------+----------------------------+
| scope | Exact permitted operation |
| | scope |
+-------------------------+----------------------------+
| payload | Exact proposed action/data |
+-------------------------+----------------------------+
| runtime_evidence_digest | Runtime/attestation |
| | evidence binding |
+-------------------------+----------------------------+
| authority_context | Additional authority |
| | context |
+-------------------------+----------------------------+
| status | Initially NON_EFFECTIVE |
+-------------------------+----------------------------+
Table 7
Das Expires 14 March 2027 [Page 59]
Internet-Draft Execution-Finality Protocol Layer September 2026
A stable reference Candidate is used for deterministic testing: act
class api-call, effect class network-egress, source agent-A,
destination https://example.invalid/payments, purpose approved-
purpose, jurisdiction EU, policy epoch 7, sink sink-A, boundary
boundary-A, scope POST:/payments, payload amount 1000 minor units in
EUR to beneficiary B1, runtime evidence runtime-ok, freshness
10,000,000,000 ns (10 s), and status NON_EFFECTIVE. The
deterministic test clock uses NOW = 1,800,000,000,000,000,000 ns, and
a typical Candidate is issued 10,000 ns before NOW, removing wall-
clock nondeterminism from security tests.
B.6. HCAD and Canonicalization
The HCAD binds structured consequence context including act class,
effect class, source, destination, purpose, jurisdiction, policy
epoch, nonce, issuance/freshness information, Finality Sink,
boundary, scope, payload digest, and runtime-evidence digest. The
implementation uses both a whole-Candidate digest and a structured
descriptor digest, giving independent detection of Candidate mutation
and of semantic descriptor mismatch.
Security-bound structures use a deliberately narrow canonical
profile: UTF-8 encoding; Unicode NFC normalization; deterministic
object-key ordering; compact deterministic JSON representation;
floats rejected; NaN and infinity rejected; non-string map keys
rejected; duplicate keys created by Unicode normalization rejected;
portable integers restricted to JavaScript's exact integer range,
±(2^53-1); unpaired surrogate values rejected; and arbitrary bytes
rejected from the portable cross-language JSON profile. The local
Python canonical form and the narrower Python/Go/Node portable
profile are explicitly distinguished. Canonicalization prevents
cryptographic disagreement caused by whitespace, object-key order,
Unicode-equivalent forms, float rendering, parser differences,
duplicate-normalized keys, and alternate serialization; the reference
demonstrates one constrained profile rather than inventing a
universal wire standard, and a standards-track version would need to
define a normative canonical encoding or adopt an established
canonical binary/JSON representation.
B.7. Policy, Protected State, and Predicate Validation
The reference policy uses the following example configuration
(demonstration parameters, not normative limits):
Das Expires 14 March 2027 [Page 60]
Internet-Draft Execution-Finality Protocol Layer September 2026
+===========================+======================================+
| Parameter | Reference configuration |
+===========================+======================================+
| Policy epoch | 7 |
+---------------------------+--------------------------------------+
| Purposes | approved-purpose, diagnostic, render |
+---------------------------+--------------------------------------+
| Jurisdictions | EU, US, IN |
+---------------------------+--------------------------------------+
| Sinks | sink-A, sink-B |
+---------------------------+--------------------------------------+
| Boundaries | boundary-A, boundary-B |
+---------------------------+--------------------------------------+
| Required runtime evidence | runtime-ok |
+---------------------------+--------------------------------------+
| Maximum future-clock skew | 1,000,000,000 ns (1 s) |
+---------------------------+--------------------------------------+
Table 8
Reference scopes include POST:/payments, WRITE:/records, DISPLAY,
PUBLISH, SEND, SPAWN, ACTUATE, SETTLE, DMA:RELEASE, and
QUEUE:PUBLISH. The policy rejects, among other conditions: Candidate
not in NON_EFFECTIVE state; incorrect policy epoch; unauthorized
purpose, jurisdiction, sink, or boundary; unsupported effect class;
unauthorized or empty scope; duplicate scope; revoked source; stale
Candidate; future-dated Candidate beyond permitted skew; invalid
freshness; and wrong runtime-evidence digest. Additional real
deployments may add consent, legal basis, ALF/RBD identity, device
posture, transaction risk, model identity, data classification, and
other predicates.
ProtectedState models state that should reside in a rollback-
resistant or protected location in production: monotonic version
(starts at 0), quota (reference default 1,000), budget (reference
default 1,000), and authorization cost (reference default 1). A
successful authorization advances state: version N to N+1, quota Q to
Q-1, budget B to B minus cost. The state-transition identifier
cryptographically incorporates the relevant before/after values,
nonce, source, epoch, and Candidate digest.
B.8. Evidence-Before-Capability Ordering, LAVR, and Capability
Construction
The implementation deliberately performs, in this order:
Das Expires 14 March 2027 [Page 61]
Internet-Draft Execution-Finality Protocol Layer September 2026
validate Candidate
|
v
advance protected state
|
v
construct ValidationEvidence
|
v
sign evidence
|
v
commit evidence
|
v
construct/sign capability
|
v
make capability available
It does not issue authority first and attempt to log evidence later:
if evidence commitment fails, the operation fails closed and no
usable capability is returned. The reference evidence (the LAVR)
includes: evidence_id (cryptographic evidence identity), authority_id
(authority issuing the decision), descriptor_digest (exact HCAD),
candidate_digest (exact Candidate), transition_id (protected-state
transition), policy_epoch, decision (ALLOW/DENY), reasons (decision
rationale), committed_at_ns, key_id (signing-key identity), and
signature. The evidence store rejects invalid signatures and
duplicate evidence identifiers.
The scoped capability binds: authority identity; Candidate digest;
descriptor digest; sink identity; boundary identity; nonce; permitted
scope; policy epoch; evidence identifier; protected-state transition
identifier; issue time; expiry; and signing-key identity. The
default maximum capability TTL is 5,000,000,000 ns (5 s). Actual
expiry is the minimum of Candidate freshness expiry and authority TTL
expiry, so capability issuance cannot extend Candidate freshness.
The dependency-light baseline uses SHA-256 for digests and HMAC-
SHA256 for deterministic authentication, chosen because Python, Go,
and Node can independently reproduce the vectors with minimal
dependencies -- not as a recommendation to share one symmetric key
across unrelated trust domains. The repository also includes
optional Ed25519 support. Production systems should normally
separate at least an authority key (capability/evidence signing), a
presenter key (proof of possession), and a sink key (finality-receipt
signing).
Das Expires 14 March 2027 [Page 62]
Internet-Draft Execution-Finality Protocol Layer September 2026
Red-team analysis identified that act-bound + sink-bound + single-use
does not automatically make an artifact non-bearer: an attacker
stealing the exact Candidate and exact unused capability could
potentially race the legitimate presenter. The strict profile
therefore binds a presenter identity and requires a fresh proof over:
capability identifier; Candidate digest; sink identifier; boundary
identifier; nonce; presentation timestamp; and presenter key
identifier. Default presentation freshness is 2,000,000,000 ns (2
s); tests explicitly reject proofs just outside both positive and
negative freshness windows.
B.9. Finality Sink Verification and Replay Protection
The Finality Sink owns its own local context -- sink ID (sink-A in
the reference), boundary ID (boundary-A), policy epoch (7), supported
scopes, and effect class, all locally configured. The caller is not
allowed to dictate the sink's identity; the sink uses its own local
configuration when reconstructing the HCAD (Section 13.4). The sink
approximately verifies, in sequence:
Das Expires 14 March 2027 [Page 63]
Internet-Draft Execution-Finality Protocol Layer September 2026
Candidate remains NON_EFFECTIVE
-> effect class matches local sink
-> Candidate sink matches local sink
-> capability sink matches local sink
-> Candidate boundary matches local boundary
-> capability boundary matches local boundary
-> Candidate epoch matches local epoch
-> capability epoch matches local epoch
-> Candidate scope matches capability scope
-> scope is locally supported
-> nonce matches
-> capability time is valid
-> capability does not outlive Candidate
-> capability signature is valid
-> optional presenter proof is valid and fresh
-> Candidate digest matches reconstructed Candidate
-> HCAD is rebuilt using local sink/boundary
-> descriptor digest matches locally rebuilt descriptor
-> evidence exists
-> evidence signature is valid
-> evidence decision is ALLOW
-> evidence authority matches capability authority
-> evidence Candidate matches capability Candidate
-> evidence descriptor matches capability descriptor
-> evidence state transition matches capability state transition
-> evidence epoch matches capability epoch
-> protected-state transition is valid
-> capability is claimed/consumed
-> external effect is invoked
This is intentionally stronger than "signature valid implies allow."
The Finality Sink does not trust an upstream assertion that the
descriptor was already checked; it reconstructs the effect context
using sink-owned identity, boundary, epoch, effect class, and scope
configuration, which lets it detect cross-sink laundering, wrong-
boundary presentation, local epoch mismatch, unsupported scope, post-
authorization Candidate mutation, and semantically inconsistent but
validly re-signed artifacts -- directly exercising the T2 and T3
defenses of Section 13.3 and Section 13.4.
Two replay/consumption backends are included. The in-memory backend
uses a lock to protect capability claim state. The SQLite durable
backend uses SQLite 3.46.1, WAL journal mode, capability_id as the
primary key, BEGIN IMMEDIATE for the claim transaction, and a
30-second connection timeout; duplicate capability identifiers are
converted into replay rejection. Replay is exercised under
contention: 2, 3, 4, 8, 16, 32, and 64 concurrent contenders for the
in-memory store, and 2, 4, 8, 16, and 32 for the SQLite store, plus
Das Expires 14 March 2027 [Page 64]
Internet-Draft Execution-Finality Protocol Layer September 2026
2, 3, 5, 10, and 25 sequential replay attempts. The expected
invariant in every case is that exactly one contender may create the
effect and every other contender is rejected (directly exercising
Section 13.2).
The reference uses VERIFY -> CLAIM/CONSUME -> EXTERNAL EFFECT rather
than VERIFY -> EXTERNAL EFFECT -> CONSUME. This chooses at-most-once
safety and avoids the failure mode where an effect occurs, the
process crashes before consumption, and a retry produces a duplicate
effect. The opposite residual is explicitly documented: capability
consumption may succeed and the process may crash before the external
effect occurs, producing consumed/no-effect. Systems requiring
stronger exactly-once semantics should bind capability_id to a
target-native transaction, idempotency key, ledger transaction
identifier, transactional outbox, or device-resident atomic consume-
and-release primitive.
B.10. Guarded Effectors and Wide-Channel Threat Surface
Nine consequence-boundary simulations are implemented:
+======================+=====================+
| Consequence | Reference effector |
+======================+=====================+
| Network transmission | NetworkEffector |
+----------------------+---------------------+
| Storage mutation | StorageEffector |
+----------------------+---------------------+
| Rendering | RendererEffector |
+----------------------+---------------------+
| Message queue | QueueEffector |
+----------------------+---------------------+
| Process spawning | ProcessEffector |
+----------------------+---------------------+
| Actuation | ActuatorEffector |
+----------------------+---------------------+
| Payment/ledger | PaymentEffector |
+----------------------+---------------------+
| AI/model output | ModelOutputEffector |
+----------------------+---------------------+
| DMA/memory release | DMAEffector |
+----------------------+---------------------+
Table 9
Das Expires 14 March 2027 [Page 65]
Internet-Draft Execution-Finality Protocol Layer September 2026
The ordinary public effect path rejects direct invocation; the sink
receives a private bound handle. This proves the reference API seam
(Section 13.8), not physical non-bypassability against privileged
attackers -- see Appendix B.13.
A wider deployment threat model additionally covers twenty
consequence channels: network-egress, storage-write, renderer,
message-queue, process-spawn, actuator, payment-ledger, model-output,
DMA/memory-release, webhook, email-send, SMS-send, radio-transmit,
ledger-bridge, file-export, clipboard, print-spool, socket-egress,
shared-memory-release, and device-command. Every declared channel
records whether it is externally effective, sink-mediated, protected
by an enforcement boundary, and privileged. Externally effective,
non-mediated paths are treated as critical; missing or non-privileged
enforcement boundaries are separately flagged -- the reference-
implementation instance of alternate-path closure (Section 13.8).
Eight reference deployment profiles illustrate how the hot path/cold
path split of Section 10 applies at different consequence boundaries:
Das Expires 14 March 2027 [Page 66]
Internet-Draft Execution-Finality Protocol Layer September 2026
+==============+==============+================+===============+
| Profile | Example sink | Latency target | Example |
| | | | enforcement |
+==============+==============+================+===============+
| Embedded | actuator | 100 μs | MCU / secure |
| control | | | element |
+--------------+--------------+----------------+---------------+
| Accelerator | DMA/memory | 500 μs | GPU/DPU/ |
| hot path | release | | SmartNIC |
+--------------+--------------+----------------+---------------+
| UPF egress | network | 1 ms | UPF/N6 or |
| | | | SmartNIC |
+--------------+--------------+----------------+---------------+
| API gateway | network | 2 ms | reverse |
| | | | proxy/gateway |
+--------------+--------------+----------------+---------------+
| Storage | storage | 5 ms | transactional |
| writer | | | writer |
+--------------+--------------+----------------+---------------+
| Payment | ledger | 10 ms | payment/ |
| finality | | | ledger bridge |
+--------------+--------------+----------------+---------------+
| Cross-region | network | 20 ms | regional |
| governance | | | gateway |
+--------------+--------------+----------------+---------------+
| Audit-heavy | model output | 50 ms | controlled |
| output | | | emitter |
+--------------+--------------+----------------+---------------+
Table 10
These latency values are engineering stress bands, not vendor
specifications or normative requirements. Cold-path examples include
remote attestation collection, certificate-chain validation, policy
retrieval, policy compilation, trust-anchor verification, and
configuration distribution; hot-path examples include local
descriptor reconstruction, digest/signature verification, local
epoch/state lookup, replay claim, and effect commit. Very tight
latency targets generally require precomputation and execution near
the actual protected effect boundary.
B.11. Verification Campaign: Test Counts and Methodology
The hardened implementation contains 481 collected Python tests, all
reported passing in the recorded run:
Das Expires 14 March 2027 [Page 67]
Internet-Draft Execution-Finality Protocol Layer September 2026
+=============================+=======+
| Test module/category | Tests |
+=============================+=======+
| Binding integrity | 66 |
+-----------------------------+-------+
| Canonicalization | 54 |
+-----------------------------+-------+
| Consequence channels | 36 |
+-----------------------------+-------+
| Concurrency/replay | 17 |
+-----------------------------+-------+
| Core architecture | 11 |
+-----------------------------+-------+
| Defensive branches | 13 |
+-----------------------------+-------+
| Ed25519 | 2 |
+-----------------------------+-------+
| Fail-closed/fault injection | 16 |
+-----------------------------+-------+
| Seeded fuzz mutations | 76 |
+-----------------------------+-------+
| Interoperability | 37 |
+-----------------------------+-------+
| Non-bearer/PoP | 13 |
+-----------------------------+-------+
| Policy matrix | 35 |
+-----------------------------+-------+
| System profiles | 17 |
+-----------------------------+-------+
| Key-role separation | 2 |
+-----------------------------+-------+
| Finality Sink adversarial | 43 |
+-----------------------------+-------+
| Wide-channel surface | 43 |
+-----------------------------+-------+
| *TOTAL* | *481* |
+-----------------------------+-------+
Table 11
Das Expires 14 March 2027 [Page 68]
Internet-Draft Execution-Finality Protocol Layer September 2026
Binding-mutation tests mutate load-bearing Candidate fields after
authorization -- act ID, act class, effect class, source,
destination, purpose, jurisdiction, policy epoch, nonce, issue time,
freshness, sink, boundary, scope, runtime evidence, and authority
context -- and payload tests independently alter amount, currency,
beneficiary, missing/extra fields, zero/negative values, large
integers, nested structures, reordered lists, type changes, case
changes, and whitespace-sensitive values; the original capability
must never authorize the changed Candidate (the reference-
implementation instance of T2, Section 13.3).
Many adversarial tests do not merely corrupt signatures -- they alter
capability or evidence fields and then re-sign the malicious artifact
with a valid reference key, testing whether the sink validates
semantics rather than using the weak rule "valid signature equals
valid authority." Re-signed attacks target authority, Candidate
digest, descriptor digest, sink, boundary, nonce, scope, epoch,
evidence identifier, state transition, and timing values -- directly
exercising T5, Section 13.6.
Seventy-six deterministic seeded mutation tests (fixed seeds,
reproducible failures) cover payment-like payload properties and
destination/context properties; this is not claimed to be coverage-
guided fuzzing such as AFL/libFuzzer or a complete stateful property-
fuzz campaign. Policy variation tests cover combinations and
boundary values for jurisdictions (EU, US, IN), purposes, quota and
budget boundaries, valid and over-budget costs, source revocation
sets, correct and incorrect epochs, valid/zero/stale/future
freshness, and correct/empty/duplicate/unauthorized scopes -- purpose
x jurisdiction alone creates a 3x3 cross-product. Sink-focused
adversarial tests exercise wrong sink IDs, wrong boundaries, wrong
epochs, restricted scopes, multiple valid and invalid time points,
altered destinations and scopes, and sinks configured with the wrong
authority verification material, with adversarial epoch values
including 0, 1, 6, 8, 9, and 2^31-1 (covering ordinary off-by-one
conditions and extreme values).
Cross-language interoperability is checked with 20 positive
deterministic vectors independently verified by Python, Node, and Go,
exercising canonical representation, UTF-8 bytes, SHA-256, and HMAC-
SHA256, plus additional vectors covering decomposed Unicode values
and keys, BMP-versus-supplementary-plane key ordering, JSON control
characters, <, >, &, U+2028/U+2029, and canonical-equivalent forms.
A separate nine-case canonicalization conformance suite (five
required-success, four required-rejection cases, including NFC key
collision, float rejection, and integers outside the portable safe
range) is executed independently by Node and Go, with corresponding
Python tests covering the same profile. Two complete portable
Das Expires 14 March 2027 [Page 69]
Internet-Draft Execution-Finality Protocol Layer September 2026
Finality Sink vectors (a baseline Candidate and a Candidate
containing decomposed Unicode inside load-bearing material) are
independently reconstructed and verified end-to-end (Candidate to
payload digest to HCAD to Candidate digest to protected-state
transition to validation evidence to capability to sink-local context
to Finality Sink verification) by Node and Go, so the implementation
does not rely on Python to generate and verify its own artifacts
exclusively.
The hardened run reports 724 Python source statements, 0 statements
missed, 100% statement coverage, via pytest --cov=src/finality_ref --
cov-report=term-missing:skip-covered -q. This does not mean 100%
security coverage; it means every measured executable Python
statement was exercised by the test suite.
B.12. Benchmark Methodology and Results
The benchmark uses time.perf_counter_ns() and performs 1,000 warm-up
iterations followed by 3,000 measured iterations per path, across
three paths: canonicalization plus SHA-256; Finality Sink
verification only; and complete authority plus sink plus guarded
effectuation. The benchmark Candidate uses a network-egress act from
bench-agent to example.invalid/effect, purpose bench, jurisdiction
EU, epoch 1, sink bench-sink, boundary bench-boundary, scope SEND,
runtime evidence runtime-ok, 60-second Candidate freshness, 30-second
capability TTL, and quota/budget of 1,000,000 to prevent benchmark
exhaustion.
The recorded reference environment:
Das Expires 14 March 2027 [Page 70]
Internet-Draft Execution-Finality Protocol Layer September 2026
+==================+================================================+
| Environment item | Recorded value |
+==================+================================================+
| Python | CPython 3.13.5 |
+------------------+------------------------------------------------+
| Kernel | Linux 6.18.35 |
+------------------+------------------------------------------------+
| Architecture | x86-64 |
+------------------+------------------------------------------------+
| libc | glibc 2.41 |
+------------------+------------------------------------------------+
| CPU | AMD EPYC 9V74 80-Core |
| | Processor (AuthenticAMD) |
+------------------+------------------------------------------------+
| Logical CPUs | 5 (process affinity CPUs |
| visible | 0-4) |
+------------------+------------------------------------------------+
| Visible memory | 6,236,925,952 bytes |
+------------------+------------------------------------------------+
| SQLite / OpenSSL | 3.46.1 / 3.5.5 |
+------------------+------------------------------------------------+
| Node.js / ICU | 22.16.0 / 77.1 |
+------------------+------------------------------------------------+
| Go | 1.23.2 linux/amd64 |
+------------------+------------------------------------------------+
| pytest / pytest- | 9.0.2 / 7.0.0 / 7.13.3 |
| cov / coverage | |
+------------------+------------------------------------------------+
| cryptography / | 46.0.4 / 82.0.1 |
| setuptools | |
+------------------+------------------------------------------------+
Table 12
The recorded benchmark results:
Das Expires 14 March 2027 [Page 71]
Internet-Draft Execution-Finality Protocol Layer September 2026
+===========+==========+==========+==========+==========+==========+
| Operation | Mean | p50 | p95 | p99 | Max |
+===========+==========+==========+==========+==========+==========+
| Canonical | 7.98 μs | 7.12 μs | 8.90 μs | 29.37 μs | 233.75 |
| SHA-256 | | | | | μs |
+-----------+----------+----------+----------+----------+----------+
| Sink | 215.32 | 197.30 | 287.84 | 504.20 | 1,314.27 |
| verify | μs | μs | μs | μs | μs |
| only | | | | | |
+-----------+----------+----------+----------+----------+----------+
| Authority | 1,113.22 | 1,054.97 | 1,350.46 | 1,847.28 | 4,037.53 |
| + sink + | μs | μs | μs | μs | μs |
| effect | | | | | |
+-----------+----------+----------+----------+----------+----------+
Table 13
These are reproducible user-space Python reference measurements, not
certified production measurements for GPU, DPU, telecom, payment,
embedded, or other target hardware. The benchmark does not establish
controlled CPU frequency, turbo state, cache topology, NUMA
placement, power governor, core isolation, virtualization contention,
or dedicated accelerator usage.
B.13. Threat Model, Limitations, and Deployment-Required Items
The reference implementation's threat model includes Candidate
mutation, destination substitution, purpose/jurisdiction
substitution, scope expansion, sink and boundary substitution, cross-
sink laundering, epoch rollback, stale/future capabilities, evidence
mutation/deletion, protected-state substitution, sequential and
parallel replay, capability theft, confused-deputy presentation,
canonicalization disagreement, Unicode collision, downstream crash,
direct raw-socket bypass, direct database bypass, renderer/debug
leakage, DMA/P2P bypass, hidden consequence channels, sink
compromise, key compromise, denial of service, and covert channels --
a superset of the threat model in Section 13. The reference package
classifies each item as TESTED (directly exercised in executable
tests), MITIGATED (design reduces risk but residual remains),
DEPLOYMENT_REQUIRED (cannot be solved by the user-space reference
alone), or RESIDUAL/OUT_OF_SCOPE (explicitly unresolved).
Principal limitations, stated directly rather than implied:
* Python is not a hardware security boundary.
* The repository cannot automatically discover every hidden effect
path.
Das Expires 14 March 2027 [Page 72]
Internet-Draft Execution-Finality Protocol Layer September 2026
* HMAC is reference/interoperability crypto, not a universal
production key-distribution recommendation.
* Vendor-specific RATS/TPM/TEE/GPU attestation verification remains
pluggable rather than fabricated.
* Exactly-once consequences are not universally guaranteed.
* Timing/cache/RF/power and other covert or physical side channels
are outside the model.
* A fully compromised privileged Finality Sink remains a fundamental
threat.
* Python memory alone cannot provide hardware rollback resistance.
* The canonical JSON profile is deliberately narrow and should
become a normative wire profile in a standards-track
implementation.
* Runtime Unicode-data versions differ; the current conformance
claim is tied to the defined profile and included repertoire, not
every future Unicode code point.
* Latency profiles are targets/stress bands, not guarantees.
* 481 tests and 100% statement coverage do not prove absence of
unknown vulnerabilities.
* The implementation is an engineering realization and does not by
itself establish patent scope or legal claim construction.
* Actual non-bypassability requires that every consequence-bearing
path converge on a privileged Finality Sink or equivalent
enforcement boundary.
A real deployment should be considered incomplete if a raw socket,
alternate database credential, unmediated renderer, DMA mapping,
message-broker credential, direct file writer, or other external-
effect path can bypass the Finality Sink (the general alternate-path-
closure requirement of Section 13.8 and Section 15).
B.14. Reproduction and Falsifiability
Representative complete verification commands are:
Das Expires 14 March 2027 [Page 73]
Internet-Draft Execution-Finality Protocol Layer September 2026
python3 -m compileall -q src
pytest -q
node node/verify.mjs vectors/interop.json
node node/canonical_conformance.mjs \
vectors/canonicalization_conformance.json
node node/finality_verify.mjs vectors/finality_case.json
node node/finality_verify.mjs vectors/finality_case_unicode.json
cd go
go test -mod=vendor ./...
go vet -mod=vendor ./...
go run -mod=vendor . ../vectors/interop.json
go run -mod=vendor ./cmd/canonicalconformance \
../vectors/canonicalization_conformance.json
go run -mod=vendor ./cmd/finalityverify ../vectors/finality_case.json
go run -mod=vendor ./cmd/finalityverify \
../vectors/finality_case_unicode.json
python3 examples/demo.py
python3 examples/strict_non_bearer.py
python3 scripts/benchmark.py
The architecture is intentionally falsifiable. A claimed deployment
should fail review if an external effect can bypass the sink, if sink
identity is caller-controlled, if effect occurs before final
verification, if replay can produce a second consequence, if evidence
or protected state can be substituted without rejection, if epoch
downgrade is accepted, if scope can be enlarged, if a claimed strict
non-bearer capability works through mere possession, or if the
claimed sink is only a user-space wrapper around an otherwise
unrestricted effect path.
The supportable conclusion from the current hardened package is that
the foundational execution-finality architecture has been converted
into an executable state machine in which exact Candidate Acts remain
non-effective until protected validation, protected-state
advancement, evidence commitment, scoped authority generation, sink-
local descriptor reconstruction, independent effect-time
verification, replay consumption, and guarded effectuation occur.
The implementation has been exercised through hundreds of
deterministic adversarial tests, concurrency races, failure
injections, canonicalization attacks, cross-language verifiers, and
system/deployment variations. Actual deployment non-bypassability
still depends on locating the Finality Sink at the real privileged
consequence boundary.
Das Expires 14 March 2027 [Page 74]
Internet-Draft Execution-Finality Protocol Layer September 2026
+==================================+==============================+
| Verification summary item | Value |
+==================================+==============================+
| Python tests | 481 passed |
+----------------------------------+------------------------------+
| Python source statement coverage | 724/724 statements exercised |
| | (100%) |
+----------------------------------+------------------------------+
| Cross-language positive vectors | 20 |
+----------------------------------+------------------------------+
| Canonicalization conformance | 9 |
| cases | |
+----------------------------------+------------------------------+
| Complete Finality Sink vectors | 2 |
+----------------------------------+------------------------------+
| Independent runtimes | Python + Node.js + Go |
+----------------------------------+------------------------------+
| Concurrent replay testing | up to 64 contenders |
+----------------------------------+------------------------------+
| Wide-channel deployment model | 20 consequence channels |
+----------------------------------+------------------------------+
| Executable consequence | 9 |
| simulations | |
+----------------------------------+------------------------------+
| Deployment/latency profiles | 8 profiles, 100 μs to 50 ms |
+----------------------------------+------------------------------+
| Benchmark | 1,000 warm-up + 3,000 |
| | measured iterations per path |
+----------------------------------+------------------------------+
Table 14
Author's Address
Sangam Das
Independent Inventor
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 14 March 2027 [Page 75]