The Missing Execution-Finality Protocol Layer of the Internet
draft-das-execution-finality-protocol-layer-00

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