Internet Engineering Task Force S. Das
Internet-Draft: draft-das-execution-finality-protocol-layer-00
Intended status: Informational August 25, 2026
Expires: February 25, 2027
The Missing Execution-Finality Protocol Layer of the Internet
Author:
Sangam Das
Independent Inventor
Balasore, Odisha, India
Email: info@sangamdas.com
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
Abstract
Internet protocols provide mature mechanisms for transporting,
encrypting, authenticating, authorizing access to, delegating, and
recording digital information. These mechanisms remain essential.
A separate question becomes increasingly important as AI agents,
autonomous services, programmable networks, cloud workloads, payment
systems, and cyber-physical systems generate consequential operations
at machine speed:
Was this specific machine-generated act authorized to become
externally effective?
There is no general cross-domain Internet protocol layer whose primary
role is to make protected, act-specific authorization a technical
prerequisite of external effectuation across AI, cloud, telecom,
payments, data export, storage, satellite systems, and physical
infrastructure.
A packet may be delivered correctly. A TLS channel may provide
authentication, confidentiality, and integrity. An HTTPS request may
reach the authoritative origin securely. An OAuth grant may authorize
access to a resource. An EMV transaction may use transaction-specific
cryptograms and payment-domain authorization. A log or ledger may
provide evidence of what occurred.
Each mechanism answers an important question. The proposed
execution-finality architecture addresses a different and more general
one: whether a particular Candidate Act is authorized to cross from
computation into externally effective consequence at a defined
Finality Sink.
Under this model, a machine-generated operation is treated as a
Candidate Act and held in a Non-Effective State. A Protected
Enforcement Domain, or equivalent protected validation mechanism,
verifies applicable authority, purpose, destination, jurisdiction,
freshness, revocation state, policy epoch, runtime integrity,
protected state, and effectuation-boundary identity.
Successful validation may produce protected evidence and a narrowly
scoped, non-bearer Execution Handle or equivalent capability bound to
the specific Candidate Act and Finality Sink. The Finality Sink
verifies the required authority before releasing the external effect.
The architectural invariant is:
Computation does not itself confer authority for consequence.
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.
Table of Contents
1. Introduction
2. The Internet Layers We Already Have
3. The Missing Architectural Question
4. Why Machine Time Changes the Problem
5. Execution-Finality Architecture
6. Candidate Acts and the Non-Effective State
7. Protected Validation and Bounded Authority
8. The Finality Sink
9. Comparison with TLS, HTTPS, OAuth, EMV, and Ledgers
10. Latency and Deployment Feasibility
11. Detailed Workflow, Pseudocode, and Examples
12. Industry and Infrastructure Relevance
13. Security and Failure Considerations
14. Frequently Asked Questions
15. IANA Considerations
16. References
Author's Address
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.
However, modern digital information increasingly represents commands
rather than merely content.
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 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.
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?
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.
4. Why Machine Time Changes the Problem
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.
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.
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.
AI-native infrastructure therefore increases the importance of
pre-effectuation authorization.
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;
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;
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:
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
TLS 1.3 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 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.
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.
EMV must be distinguished carefully because it already contains
transaction-specific security and authorization mechanisms.
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 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.
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/Transport Information delivery
TLS Secure authenticated channel
HTTP Request/response and resource semantics
HTTPS HTTP over a secured authoritative-origin channel
OAuth Delegated access authorization
EMV Payment-domain transaction authentication and
authorization
Logs/Ledgers Evidence, ordering, recording, or consensus
Execution Protected act-specific authorization remains a
Finality prerequisite of external effectuation at the
consequence boundary
10. Latency and Deployment Feasibility
Execution-finality control is useful only if it can be implemented
without placing expensive policy reasoning into every
latency-sensitive operation.
A practical implementation may therefore divide processing into a cold
path and a hot path.
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;
key provisioning;
rule compilation;
protected-state preparation; and
creation of validation evidence.
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.
10.3. 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;
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.
Actual latency depends on hardware, cryptographic primitive, assurance
level, topology, and implementation.
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. Detailed Workflow, Pseudocode, and Examples
11.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, 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.
The Candidate Act 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.
In this state, computation may continue and validation may occur, but
the consequence-bearing resource is withheld.
Depending on the domain, the withheld resource may be:
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.
The authorization context may be derived from enterprise policy,
user consent, delegated authority, regulatory constraints, payment
policy, network policy, device policy, application policy, or
previously issued protected authorization state.
The context may constrain:
permitted actor;
permitted purpose;
permitted destination;
permitted effect;
permitted data or resource scope;
permitted 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.
The verifier may check:
actor and workload identity;
integrity or attestation state where applicable;
purpose and scope;
destination and recipient;
jurisdiction;
policy and revocation epochs;
nonce or freshness state;
quota or single-use state;
runtime or model identity;
protected local state;
Candidate-Act digest; and
Finality-Sink binding.
Validation failure does not produce effectuation authority.
Step 6 - Commit Protected Validation Evidence
If validation succeeds, the protected domain may commit validation
evidence before or atomically with issuance of effectuation authority.
The evidence may be represented by a signed receipt, protected state
transition, authenticated record, hash-bound record, attested state,
append-only event, ledger commitment, or equivalent protected
evidence.
The purpose of the evidence is to bind the validation result to the
particular Candidate Act and the protected state under which the
decision was made.
Step 7 - Issue or Resolve Scoped Non-Bearer Authority
After successful validation, the protected domain issues or resolves
a narrowly scoped Execution Handle or equivalent effectuation
capability.
The authority SHOULD be bounded to the minimum required effect and MAY
be bound to:
Candidate-Act digest;
actor or workload;
purpose;
destination;
jurisdiction;
validity window;
nonce;
quota;
policy epoch;
revocation epoch;
protected validation evidence;
protected state; and
Finality Sink.
The authority is non-bearer in character: 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.
The sink verifies 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.
This check prevents 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.
Effectuation then occurs only within the verified scope.
Examples include:
transmitting the packet or radio command;
dispatching the API call;
committing the database write;
releasing the payment;
exporting the file;
rendering the output;
writing persistent model memory;
transmitting a satellite instruction; or
actuating the physical device.
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.
The system does not treat application intent, network delivery,
authenticated identity, possession of a token, or prior approval 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; the audit record does not
substitute for that control.
11.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.
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
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
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
11.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.
11.4. Payment and Settlement
An AI agent, user application, enterprise workflow, or payment service
prepares a payment instruction.
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.
11.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.
11.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.
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.
11.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.
11.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.
Result:
calculation of a control command is not treated as authority for
physical actuation.
11.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.
11.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.
12. 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.
12.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.
12.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.
12.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.
12.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.
12.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.
12.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.
12.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.
12.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.
12.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.
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.
12.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.
12.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.
12.12. Cross-Industry Common Structure
Although the underlying technologies differ, the same control pattern
can be applied:
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.
13. Security and Failure Considerations
Implementations should consider:
replay;
stale authorization;
compromised applications;
compromised AI agents;
forged validation evidence;
policy rollback;
nonce reuse;
quota races;
destination substitution;
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. Protecting one nominal Finality Sink
while leaving an unverified substitute path would weaken the intended
property.
14. Frequently Asked Questions
14.1. 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.
14.2. 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.
14.3. 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.
14.4. 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.
14.5. 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.
14.6. 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.
14.7. Does this require blockchain?
No. A ledger can be used for evidence or state anchoring where useful,
but it is not a baseline requirement.
14.8. 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.
14.9. 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.
14.10. 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.
14.11. 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.
15. IANA Considerations
This document has no IANA actions.
16. References
16.1. Informative References
[TLS13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, July 2026.
[HTTP]
Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics",
RFC 9110, June 2022.
[EMV-CHIP]
EMVCo, "EMV Chip" and related EMV Chip security documentation.
[EMV-3DS]
EMVCo, "EMV 3-D Secure" and related specifications and
explanatory material.
Author's Address
Sangam Das
Independent Inventor
Balasore, Odisha
India
Email: info@sangamdas.com