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 9.1. TLS 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. 9.4. EMV 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