Internet-Draft Execution-Finality Protocol Layer September 2026
Das Expires 14 March 2027 [Page]
Workgroup:
Independent Submission
Internet-Draft:
draft-das-execution-finality-protocol-layer-01
Published:
Intended Status:
Informational
Expires:
Author:
S. Das
Independent Inventor

The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority

Abstract

TLS tells you the channel is authentic. OAuth tells you the caller holds a valid grant. HTTPS tells you the origin is who it claims to be. EMV tells you a payment cryptogram is transaction-specific. None of these mechanisms answer a question that autonomous, machine-speed systems now raise on every turn: is this specific act, generated by this model, agent, or workload, at this moment, actually authorized to become externally effective?

Large language model agents, autonomous cloud workloads, and machine-to-machine network functions increasingly compute, decide, and act inside a single event loop, at latencies where no human, log reviewer, or downstream audit process can intervene before an API call fires, a payment settles, a file leaves the enterprise boundary, or a physical actuator moves. Transport, authentication, and authorization protocols were designed for a world in which the gap between "this request was generated" and "this request had a chance to be reviewed" was measured in human-relevant time. That gap has collapsed to milliseconds. Existing protocol layers were never built to close it, because the question they answer -- identity, channel integrity, delegated scope -- is a necessary but categorically different question from whether this act, right now, should be allowed to leave computation and become consequence.

This document specifies an architectural pattern, execution finality, that treats every machine-generated operation as a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority -- purpose, destination, jurisdiction, freshness, revocation state, policy epoch, and runtime integrity -- and issues a narrowly scoped, non-bearer Execution Handle bound to that act and to a specific Finality Sink, the first boundary at which the act would otherwise become externally effective. The document formalizes the vocabulary, a cold-path/hot-path split for latency-sensitive deployment, a structured threat model with adversary-facing pseudocode, an incremental migration path for coexistence with TLS, HTTPS, OAuth, and EMV rather than replacement of them, and worked examples spanning AI agents, payments, telecommunications, cloud infrastructure, satellite command, industrial control, and robotics.

The central claim is narrow and falsifiable: computation does not itself confer authority for consequence, and no general, cross-domain Internet layer currently makes that separation a structural property of the release path rather than an application-specific convention. This document is intended to solicit IETF community review of whether that gap is real, whether it is already covered by existing or in-progress work, and if not, which venue should take it up.

This document describes a patent-pending architectural concept. Any intellectual-property rights or disclosure obligations relating to implementation are outside the technical scope of this document and are subject to applicable IETF IPR procedures, including BCP 79.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 March 2027.

▲

Table of Contents

1. Introduction

The Internet was built in layers because different technical problems require different mechanisms.

IP provides internetwork delivery. Transport protocols carry data between endpoints. TLS protects communication channels. HTTP defines application-level request and response semantics. HTTPS combines HTTP semantics with a secured connection to an authoritative origin. Authentication systems establish identity. Authorization frameworks can delegate access. Payment protocols provide payment-specific authentication and authorization mechanisms. Logs and ledgers record events.

These mechanisms solve indispensable problems. This document does not propose replacing any of them.

However, modern digital information increasingly represents commands rather than merely content, and the entity generating those commands is, with growing frequency, itself a model rather than a human operator sitting at a keyboard.

An AI-generated message may invoke an API. An API request may export a database. An autonomous workload may initiate a payment. A network controller may reconfigure infrastructure. A telecom function may trigger a transmission. A satellite controller may issue an RF or command operation. A machine-generated instruction may cause physical actuation.

This creates a distinct architectural question:

Even when the information is correctly transported, cryptographically protected, authenticated, and syntactically valid, should the represented act be allowed to become externally effective?

This document calls the architectural control of that boundary execution finality.

Readers seeking additional explanatory material, industry-specific examples, frequently asked questions, implementation discussion, and illustrative diagrams may consult the accompanying public technical disclosure:

Sangam Das, "The Internet Solved Communication. It Never Solved Authority," Zenodo, August 2026 [ZENODO-DAS]. https://zenodo.org/records/22082995

The supplementary material provides broader discussion of execution finality across artificial intelligence, telecommunications and 5G/6G, cloud and data-centre infrastructure, payments, satellite systems, cybersecurity, industrial control, robotics, and other consequence-bearing environments. It is provided for explanatory context; this Internet-Draft defines the architectural discussion independently.

2. The Internet Layers We Already Have

A simplified view is:

IP / transport:
How does information reach another endpoint?
TLS:
Can communicating peers establish a secure channel with authentication, confidentiality, and integrity?
HTTP:
How are application requests, responses, resources, methods, and representations expressed?
HTTPS:
Can HTTP communication with the intended origin be protected by an authenticated, confidential, integrity-protected channel?
OAuth and related authorization frameworks:
What access or delegated authority may a client receive?
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: The Agentic Era

Earlier digital systems frequently operated within workflows where human review, incident response, rollback, revocation, or manual intervention remained relevant to the time scale of the action.

AI-native infrastructure compresses that interval to the point where it no longer functions as a safety margin. This is the specific condition that motivates this document, and it is worth stating plainly: the reason execution finality did not need to exist as a general cross-domain layer in 1995, 2005, or even 2015 is that the actor generating consequential requests was, in the overwhelming majority of cases, a human, and humans are slow enough relative to review, monitoring, and manual intervention that application-level and post-hoc controls were sufficient.

Autonomous agents can invoke tools, call APIs, transmit data, create files, modify databases, initiate payments, trigger workflows, reconfigure infrastructure, generate telecommunications operations, or issue machine commands within milliseconds, in loops that may run thousands of times per hour without a human observing any individual iteration. An agent does not need to be malicious to be dangerous in this model: a correctly authenticated, correctly authorized, non-adversarial agent that is simply wrong about the current purpose, destination, or policy state can still generate a fully valid, fully transportable, fully credentialed Candidate Act that should not become effective.

By the time a log is read:

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, and does so specifically because the traditional backstop -- a human somewhere in the loop who is slow enough to be a safety margin -- is being architecturally removed by the same agentic systems that make this document relevant.

5. Execution-Finality Architecture

The proposed architecture introduces an execution-finality layer between computation and externally effective consequence.

A conceptual sequence is:

  1. A workload computes or prepares an operation.
  2. The operation is represented as a Candidate Act.
  3. The Candidate Act is placed or maintained in a Non-Effective State.
  4. A Protected Enforcement Domain or equivalent protected mechanism validates the required authority and protected state.
  5. Successful validation produces or resolves protected validation evidence and narrowly scoped effectuation authority.
  6. The authority is bound to the intended Candidate Act, scope, destination, protected state, and Finality Sink.
  7. The Finality Sink independently verifies the required authority.
  8. Only after successful verification may the protected external effect occur.

Failure to validate leaves the Candidate Act non-effective.

6. Candidate Acts and the Non-Effective State

A Candidate Act is a proposed operation capable of producing an external consequence but not yet permitted to do so.

Candidate Acts may include:

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:

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:

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 [TLS13] is designed to provide a secure channel between communicating peers. Its security properties include peer authentication, confidentiality, integrity, and record-layer protections.

TLS therefore answers questions such as:

Is this the authenticated peer?

Has the communication been protected from eavesdropping or undetected modification?

TLS does not define the application-specific semantic rule that a consequential command carried inside the protected channel is authorized to produce a particular external effect.

A malicious, compromised, or over-authorized endpoint can therefore transmit a perfectly valid TLS-protected command.

Execution finality is intended to operate after or alongside secure transport by independently controlling release of the consequential effect.

9.2. HTTPS

HTTPS combines HTTP [HTTP] semantics with a secured connection to an authoritative origin. HTTP request methods convey client intentions regarding identified resources, while HTTPS provides authentication of the relevant origin and confidentiality and integrity protection for the HTTP exchange.

This is an important distinction: HTTPS is not merely encryption.

Nevertheless, successful HTTPS communication does not itself establish a universal rule that every downstream real-world effect requested in the HTTP message is authorized for its current purpose, jurisdiction, protected state, runtime condition, and effectuation boundary.

An application can implement such controls, but they are application-specific.

Execution finality proposes making the final act-level release dependency explicit and reusable across domains.

9.3. OAuth and Delegated Authorization

OAuth and similar systems can provide powerful delegated authorization and scope-limited access.

These mechanisms may already be used to prevent unauthorized API operations.

Execution finality does not claim otherwise.

The distinction is that access authorization and effectuation authority need not be identical.

A token may authorize access to an API or resource while a particular requested consequence may require additional validation of purpose, current state, destination, jurisdiction, freshness, revocation, act-specific attributes, and the identity of the actual effectuation boundary.

The execution-finality model places that last validation structurally at or immediately before the Finality Sink.

9.4. EMV

EMV must be distinguished carefully because it already contains transaction-specific security and authorization mechanisms.

EMV Chip [EMV-CHIP] can generate transaction-specific cryptograms. Depending on the transaction flow, cryptographic information can be verified locally by a terminal or remotely by an issuer. EMV 3-D Secure [EMV-3DS] also supports payment authentication and issuer decision-making for e-commerce transactions.

EMV therefore demonstrates an important principle:

high-throughput infrastructure can make transaction-specific cryptographic authorization part of a real-time consequence-bearing workflow.

Execution finality does NOT claim that EMV merely authenticates a generic credential or that EMV fails to authorize payment transactions.

The distinction proposed here is scope and architectural generality.

EMV is purpose-built for payment ecosystems and payment consequences.

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

Table 1
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 Finality Protected act-specific authorization remains a prerequisite of external effectuation at the consequence boundary

10. Latency, Deployment Feasibility, and the Cold/Hot Path

Execution-finality control is useful only if it can be implemented without placing expensive policy reasoning into every latency-sensitive operation. A practical implementation therefore divides processing into a cold path and a hot path, and this section expands the split into concrete per-domain latency budgets, a failure taxonomy for the hot path, and pseudocode for both paths.

10.1. Cold Path

The cold path may perform:

  • policy evaluation;
  • AI risk assessment;
  • authorization issuance;
  • consent processing;
  • jurisdiction determination;
  • credential validation;
  • workload or model assessment;
  • destination approval;
  • key provisioning;
  • rule compilation;
  • protected-state preparation; and
  • creation of validation evidence.

The cold path is not latency-bounded by the effectuation event. It runs ahead of, or asynchronously with, the act it will eventually authorize, and its output is a compact, independently verifiable artifact (the Execution Handle plus validation evidence) rather than a live policy decision the hot path must wait on.

10.2. Hot Path

The effectuation-time hot path may be restricted to operations such as:

  • identifying the Candidate Act;
  • checking or reconstructing an act digest;
  • verifying a signature, MAC, attestation, or protected record;
  • checking nonce or freshness state;
  • checking revocation or policy epoch;
  • checking scope;
  • checking Finality-Sink binding;
  • consuming single-use or quota state; and
  • releasing or denying the consequence-bearing resource.

Every hot-path operation above is a bounded, deterministic, local check. None of them requires a network round trip to a policy engine, a human reviewer, or an AI model. This is the property that makes the architecture compatible with microsecond-to-low-millisecond release paths: the reasoning that is genuinely expensive (what should be allowed, for whom, under what conditions) has already happened on the cold path, and the hot path only checks whether the artifact produced by that reasoning still applies to the exact act now in front of the sink.

10.3. Indicative Per-Domain Latency Budgets

The following budgets are illustrative, not normative, and are intended only to show that hot-path verification is compatible with the timing constraints of the domains discussed in Section 14. Actual figures depend on hardware, cryptographic primitive, assurance level, and topology, and this document makes no universal latency claim.

Table 2
Domain Typical release-path budget Hot-path fit
API/tool-call dispatch (agentic AI) 1-50 ms Local signature/MAC check, cached revocation epoch
5G/6G user-plane gateway action <1-10 ms Hardware-assisted verification, precomputed epoch table
Card-present/EMV-adjacent payment release ~100-300 ms (existing EMV budget) Composable with existing terminal/issuer round trip
Industrial/safety actuator command <10 ms (interlock-class) Local protected-state check only; no remote call in hot path
Satellite command uplink Seconds (propagation-bound) Verification cost negligible relative to propagation delay

10.4. Feasibility

The architecture does not require a human reviewer, AI model, remote policy service, regulator, or distributed consensus protocol to execute synchronously for every Finality-Sink decision.

Policy and authorization can be prepared on the cold path and transformed into compact locally verifiable evidence.

The hot path can use mechanisms such as:

  • public-key signature verification;
  • MAC verification;
  • HSM-backed protected state;
  • TEE or secure-enclave state;
  • monotonic counters;
  • nonce stores;
  • protected database transactions;
  • cached revocation epochs;
  • precomputed authorization artifacts; and
  • device- or sink-bound credentials.

This document therefore does not claim a universal latency number. The architectural requirement is that expensive reasoning may remain outside the hot path while the final release decision remains independently enforceable at the consequence boundary.

11. Legacy System Interoperability and Incremental Migration

A cross-domain architectural proposal is only deployable if it can be introduced without a forklift replacement of TLS, HTTPS, OAuth, EMV, or the applications built on them. This section describes execution finality as an additive control plane, the specific interoperability points with each legacy mechanism, a gateway/shim deployment pattern for brownfield environments, and an explicit compatibility and downgrade posture.

11.1. Additive, Not Substitutive

Execution finality is designed to sit at or immediately before the existing release point of a legacy mechanism, not to replace the mechanism's channel security or its existing authorization semantics. A Finality Sink can be implemented as a thin verification shim placed directly in front of an existing egress gateway, API dispatcher, or payment-release interface, without modifying the transport (TLS remains TLS), the application protocol (HTTP remains HTTP), or the existing delegated-authorization layer (OAuth tokens continue to be validated exactly as before).

The added dependency is narrow: the shim additionally requires a valid, act-specific Execution Handle before forwarding the request to the legacy release path. If no Execution Handle is required by local policy for a given operation class, the shim is a no-op and legacy behavior is unchanged. This allows execution finality to be adopted operation-by-operation, starting with the highest-consequence acts (bulk data export, high-value payments, safety-critical actuation) and expanding coverage over time.

11.2. Interoperability with TLS/HTTPS

No change to the TLS handshake, cipher suite negotiation, or certificate validation is required. The Candidate Act, its digest, and the resulting Execution Handle can be carried as an application-layer artifact inside the existing HTTPS request (for example, as an additional header or a signed structured field), so that legacy HTTPS clients that do not generate an Execution Handle simply have the field absent, and a Finality-Sink shim in strict mode denies the act while a shim in permissive/observe mode logs the gap without blocking, which is the recommended posture during a migration window.

11.3. Interoperability with OAuth

Existing OAuth access tokens continue to gate resource access exactly as they do today. The Execution Handle is a second, narrower artifact layered on top of, not instead of, the OAuth grant: an OAuth token can authorize a client to call an export API at all, while the Execution Handle additionally authorizes this specific export, to this destination, under the current policy epoch. A resource server can be upgraded incrementally by adding an Execution-Handle check after its existing token-introspection step, with no change to the authorization server, token format, or grant flow.

11.4. Interoperability with EMV and Payment Rails

Execution finality does not attempt to sit inside the EMV cryptogram computation or the issuer authorization step; that domain-specific, already-mature control is left intact. Instead, an enterprise, agent-facing, or API-facing payment initiator can require an Execution Handle as a precondition to constructing the payment instruction that is handed to the existing EMV/payment-rail path, so the two controls compose in sequence (execution-finality check, then existing payment-domain authorization) rather than one subsuming the other.

11.5. Gateway/Shim Deployment Pattern

For brownfield environments where modifying every legacy endpoint is impractical, a Finality-Sink function can be deployed as a reverse proxy, service-mesh sidecar, API gateway plugin, or network-function filter placed in front of the unmodified legacy system. This concentrates the hot-path check at a small number of well-known chokepoints instead of requiring every downstream service to be individually upgraded, and mirrors how WAFs, API gateways, and service meshes already retrofit authentication and rate-limiting onto legacy backends without modifying them.

11.6. Downgrade and Fallback Posture

Three explicit deployment modes are RECOMMENDED for a migration window:

Observe mode:
the shim evaluates Execution-Handle presence and validity but never blocks; results are logged for coverage measurement.
Permissive mode:
acts without a valid Execution Handle are allowed but flagged, while acts that present an invalid or expired handle are denied; this catches active misuse while legacy callers are migrated.
Strict mode:
a valid, act-specific Execution Handle is a hard precondition for release; this is the target end state for high-consequence operation classes.

A deployment SHOULD NOT silently fail open from strict mode to permissive or observe mode; any mode transition should be an explicit, auditable configuration change, since a silent downgrade under load or during an incident is itself a bypass path (see Section 13.7).

12. Detailed Workflow, Pseudocode, and Examples

12.1. End-to-End Execution-Finality Workflow

The following sequence is a non-limiting reference workflow. The components may be distributed across a device, operating system, network function, cloud service, protected hardware environment, payment system, enterprise gateway, or cyber-physical controller.

Step 1 - Compute or Receive a Proposed Operation. An ordinary compute environment, including an AI agent, application, cloud workload, network function, payment process, or controller, computes, receives, or prepares an operation. At this stage the operation has no independent authority to become externally effective merely because it was generated by an authenticated process or arrived over a secure channel.

Step 2 - Construct the Candidate Act. The system represents the proposed operation as a Candidate Act, which may include or reference: an act identifier; an operation type; canonicalized load-bearing act attributes; an actor, workload, or AI-agent identity; purpose and requested scope; source and destination; requested effect; jurisdictional context; session or transaction context; freshness information; a policy epoch; a revocation epoch; the intended Finality Sink; and a digest over the attributes that must remain invariant before effectuation.

Step 3 - Enter the Non-Effective State. The Candidate Act is placed or maintained in a Non-Effective State. Computation may continue and validation may occur, but the consequence-bearing resource is withheld -- network egress, an API dispatch, a payment release, a database commit, a storage write, a message or notification release, a radio transmission, a satellite command, a model-output publication, a device wake, or a physical actuator transition.

Step 4 - Resolve the Applicable Authorization Context. The system resolves the authority required for this particular act, constraining permitted actor, purpose, destination, effect, data or resource scope, jurisdiction, time window, nonce or freshness state, quota, runtime identity, policy epoch, revocation state, and permitted Finality Sink.

Step 5 - Protected Validation. A Protected Enforcement Domain, or cooperating protected verifier, validates the Candidate Act against the required authorization context. Validation failure does not produce effectuation authority.

Step 6 - Commit Protected Validation Evidence. If validation succeeds, the protected domain may commit validation evidence -- a signed receipt, protected state transition, authenticated record, hash-bound record, attested state, append-only event, ledger commitment, or equivalent -- before or atomically with issuance of effectuation authority.

Step 7 - Issue or Resolve Scoped Non-Bearer Authority. After successful validation, the protected domain issues or resolves a narrowly scoped Execution Handle, bounded to the minimum required effect and bound to Candidate-Act digest, actor/workload, purpose, destination, jurisdiction, validity window, nonce, quota, policy epoch, revocation epoch, validation evidence, protected state, and Finality Sink. The authority is non-bearer: possession or copying of its representation alone does not authorize another actor, context, destination, or sink to use it.

Step 8 - Present or Resolve Authority at the Finality Sink. The Candidate Act reaches the Finality Sink only as a still non-effective operation. The Finality Sink, or a verifier structurally coupled to it, verifies the effectuation authority before release, including that the requested effect still matches the authorized act and that the authority has not expired, been revoked, been consumed, or been substituted across another sink or context.

Step 9 - Reconstruct or Recheck the Candidate Act. Where required, the Finality Sink reconstructs the load-bearing Candidate-Act attributes from sink-visible state and recomputes the act digest, preventing a validated act from being replaced with a different destination, amount, command, resource, recipient, output, or effect after validation.

Step 10 - Atomic Consumption and Effectuation. If all checks succeed, single-use or quota state is consumed before or atomically with release of the consequence-bearing resource, and effectuation occurs only within the verified scope.

Step 11 - Fail-Closed Denial. If any required condition is absent, invalid, stale, mismatched, replayed, revoked, quota-exhausted, or unverifiable, the Candidate Act remains non-effective. Application intent, network delivery, authenticated identity, possession of a token, or prior approval are not treated as a substitute for successful Finality-Sink verification.

Step 12 - Optional Audit and Accountability. The system may record the allow or deny result for audit, dispute resolution, security analysis, incident response, or compliance. Audit is complementary to execution finality: the protected consequence is controlled before release, and the audit record does not substitute for that control.

12.2. Non-Limiting Pseudocode

The following pseudocode illustrates the logical dependency. It does not prescribe a wire format, cryptographic primitive, hardware technology, or deployment topology.

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

12.3. AI-Agent Tool Invocation

An AI agent prepares an instruction to export customer records to an external analysis service.

Candidate Act: the proposed export, including dataset, fields, purpose, recipient, destination, model or agent identity, and requested transfer.

Protected validation: verifies that the agent is permitted to perform the requested purpose, that the data scope is allowed, that the destination and jurisdiction are permitted, that policy and revocation state are current, and that the requested effect matches enterprise policy.

Finality Sink: the first egress gateway, API dispatcher, storage-export boundary, or equivalent component capable of releasing the protected data.

Result: a valid HTTPS session or OAuth token alone does not release the export. The egress Finality Sink additionally requires valid act-specific effectuation authority.

12.4. Payment and Settlement

An AI agent, user application, enterprise workflow, or payment service prepares a payment instruction.

Candidate Act: the proposed transfer, including amount, payer, payee, purpose, currency or asset, destination, transaction context, and requested payment effect.

Protected validation: may combine existing payment-domain authorization with additional enterprise, agent, purpose, fraud, jurisdiction, quota, policy, or workflow constraints.

Finality Sink: the component that first releases the payment into an irrevocable or externally consequential settlement path.

Result: execution finality does not replace EMV or payment authorization. It provides a generalized control point for binding a machine-generated payment act to additional protected constraints before release.

12.5. Telecommunications and 5G/6G

An AI controller, network function, application, autonomous service, or machine-to-machine workflow prepares a consequential network operation.

Candidate Act: a packet egress request, network-slice change, roaming operation, radio command, message release, gateway action, or satellite/NTN transmission.

Protected validation: may verify network authority, purpose, subscriber or enterprise scope, destination, radio or spectrum constraints, jurisdiction, policy epoch, freshness, quota, and network-function identity.

Finality Sink: a gateway, user-plane or control-plane enforcement point, radio chain, network-function boundary, satellite gateway, or other release boundary.

Result: the fact that the request was generated by an authenticated network function does not alone make the requested consequence final.

12.6. Cloud and Data-Centre Infrastructure

A workload prepares a storage, memory, DMA, accelerator, or network operation.

Candidate Act: a DMA transfer, persistent storage write, accelerator-to-host transfer, privileged memory update, SmartNIC/DPU operation, or cloud egress event.

Protected validation: may bind tenant, workload, purpose, resource range, destination, device identity, attested runtime, policy epoch, and revocation state.

Finality Sink: a memory controller, storage controller, SmartNIC, DPU, accelerator boundary, hypervisor-mediated release point, or protected egress gateway.

Result: compromise of the ordinary workload need not automatically imply authority to create every external or persistent effect available to the underlying infrastructure.

12.7. Satellite and Non-Terrestrial Networks

A ground system, autonomous controller, AI system, or network service prepares an RF, routing, payload, or satellite-control operation.

Candidate Act: a beam command, RF transmission, payload instruction, routing update, cross-link operation, or spacecraft command.

Protected validation: may verify mission authority, command type, destination, spacecraft identity, geographic or jurisdictional constraints, time window, operational state, freshness, policy epoch, and command scope.

Finality Sink: the command-uplink interface, RF chain, payload-control boundary, or protected spacecraft actuator interface.

Result: command generation and command effectuation remain separate authorities.

12.8. Critical Infrastructure and Industrial Control

An AI system or control application computes a command affecting a physical process.

Candidate Act: a valve movement, breaker operation, process-setpoint change, robotic command, energy-grid action, or safety-system update.

Protected validation: may verify operator or machine authority, permitted operating envelope, plant state, purpose, interlocks, freshness, maintenance mode, policy epoch, and actuator identity.

Finality Sink: the protected controller, safety PLC boundary, actuator interface, motor controller, or other component that first creates the physical effect.

Result: calculation of a control command is not treated as authority for physical actuation.

12.9. Robotics, Vehicles, and Autonomous Machines

A planning model or autonomous controller generates a motion or environment-changing action.

Candidate Act: steering, braking, acceleration, robotic motion, payload release, door actuation, drone command, or other kinetic operation.

Protected validation: may check operating mode, safety envelope, actor identity, sensor or state freshness, geofence, destination, policy epoch, and permitted actuator scope.

Finality Sink: the motor controller, drive-by-wire interface, robotic actuator interface, or equivalent consequence boundary.

Result: a planner may propose the action without holding unrestricted final actuation authority.

12.10. Healthcare and Safety-Critical Systems

A clinical application, AI model, device controller, or workflow prepares an operation affecting a patient-facing system.

Candidate Act: a device-setting change, medication-device instruction, data disclosure, alert suppression, or safety-critical workflow action.

Protected validation: may verify device identity, clinician or workflow authority, patient context, purpose, permitted range, freshness, policy state, and safety constraints.

Finality Sink: the medical-device controller, protected workflow dispatcher, disclosure gateway, or equivalent first consequence boundary.

Result: an AI recommendation and an externally effective clinical-device action remain distinct stages.

13. Threat Model and Adversarial Analysis

This section enumerates the adversary classes and failure classes the architecture is intended to resist, states the corresponding assumption or guarantee, and gives adversary-facing pseudocode for the attack and the corresponding Finality-Sink defense. It is organized around the properties an Execution Handle and a Finality Sink are expected to provide: non-bearer scoping, freshness, revocability, act-binding, and sink-binding.

13.1. Adversary Model and Assumptions

The following adversary capabilities are assumed in scope:

  • full control over an ordinary (non-protected) compute environment, including an AI agent, application process, or cloud workload;
  • the ability to observe and replay network traffic on unprotected paths;
  • the ability to construct arbitrary Candidate Acts, including malformed or misleading purpose/destination fields;
  • the ability to attempt to reuse, forward, or present a captured Execution Handle in a different context, destination, or sink; and
  • the ability to attempt requests during known windows of policy change (for example, immediately after a revocation).

The following are explicitly out of scope or treated as trust anchors, consistent with Section 15:

  • full compromise of the Protected Enforcement Domain itself (protected-domain compromise is discussed as a residual risk, not defended against by this architecture alone);
  • physical extraction of key material from correctly functioning protected hardware; and
  • weaknesses in the underlying cryptographic primitives themselves.

13.2. T1: Replay of a Previously Authorized Act

Attack. An adversary captures a valid Execution Handle and its associated Candidate Act and resubmits them later, attempting to trigger the effect a second time.

# Attack
captured = intercept(candidate, authority)
sleep(arbitrary_delay)
resubmit(captured.candidate, captured.authority)   # attempt #2

# Defense (Finality Sink, Step 8-10 of Section 11.1)
if authority.nonce_or_counter is already consumed:
    return DENY   # single-use state blocks attempt #2

Guarantee. Single-use nonce or counter consumption is atomic with effectuation, so a captured Execution Handle cannot be reused after its first successful consumption at its bound Finality Sink.

13.3. T2: Time-of-Check to Time-of-Use (TOCTOU) Act Substitution

Attack. An adversary obtains validation for a low-risk Candidate Act (for example, exporting a small, permitted dataset) and then attempts to substitute a different, higher-risk effect (a larger dataset, a different destination) at the moment of release, hoping the sink trusts the earlier validation result without rechecking the act itself.

# Attack
authority = get_valid_authority(low_risk_candidate)
malicious_candidate = mutate(low_risk_candidate,
                              destination="attacker.example",
                              resource_scope="ALL_RECORDS")
finality_sink_receive(malicious_candidate, authority, sink_state)

# Defense (Step 9, and finality_sink_receive() in Section 11.2)
reconstructed_digest = canonical_digest(
    malicious_candidate.load_bearing_attributes)
if reconstructed_digest != authority.candidate_act_digest:
    return DENY   # digest mismatch: the substituted act is rejected

Guarantee. The Finality Sink recomputes the act digest from sink-visible attributes rather than trusting a caller-supplied description of the act, closing the gap between what was validated and what is actually released.

13.4. T3: Finality-Sink Substitution

Attack. An adversary obtains a valid Execution Handle scoped to one Finality Sink (for example, a low-security internal export path) and attempts to present it at a different, more consequential sink (for example, direct external egress) that was never the intended release boundary.

# Attack
authority = get_valid_authority(
    candidate, finality_sink_id="internal-export")
finality_sink_receive(
    candidate, authority,
    sink_state=SinkState(sink_id="external-egress"))

# Defense
if authority.finality_sink_id != sink_state.sink_id:
    return DENY

Guarantee. Sink-binding makes the Execution Handle meaningless outside the specific Finality Sink it was issued for, preventing lateral reuse across release boundaries of differing consequence.

13.5. T4: Stale Authorization After Policy or Revocation Change

Attack. An actor's authority is revoked (for example, an employee is offboarded, an agent is suspended, a destination is blacklisted) but the actor attempts to use an Execution Handle issued before the revocation.

# Attack
authority = get_authority_issued_before_revocation(candidate)
revoke_actor(candidate.actor_id)             # policy change
finality_sink_receive(candidate, authority, sink_state)

# Defense
if authority.policy_epoch != sink_state.policy_epoch:
    return DENY
if authority.revocation_epoch != sink_state.revocation_epoch:
    return DENY

Guarantee. Binding the Execution Handle to a policy epoch and a revocation epoch, and requiring the Finality Sink to hold current epoch state, ensures a policy or revocation change becomes effective at the next effectuation attempt rather than only at the next Execution Handle issuance.

Residual risk. If the sink's local epoch state is itself stale (for example, due to a partitioned network preventing epoch propagation), a revoked actor may continue to pass this check until the sink's epoch state catches up. Deployments with a low tolerance for this window SHOULD favor short epoch-propagation intervals or synchronous epoch lookups for the highest-consequence operation classes.

13.6. T5: Forged or Fabricated Validation Evidence

Attack. An adversary who controls the ordinary compute environment fabricates an Execution Handle or validation-evidence record without having gone through the Protected Enforcement Domain.

# Attack
forged_authority = ExecutionAuthority(
    candidate_act_digest=digest(candidate),
    permitted_effect="EXPORT_ALL",
    non_bearer=true, ...)   # never issued by a PED

# Defense
if not verify_validation_evidence(authority):
    return DENY   # sig/MAC verification against the PED's key fails

Guarantee. The Finality Sink verifies validation evidence cryptographically against keys or attestation roots controlled by the Protected Enforcement Domain, not against anything the ordinary compute environment can fabricate. This is the property that requires the Protected Enforcement Domain to be genuinely protected (see Section 13.1): if the ordinary compute environment can extract or spoof the PED's signing capability, this defense fails, which is why PED integrity is treated as a trust anchor rather than something this layer alone guarantees.

13.7. T6: Silent Downgrade / Fail-Open Under Load or Incident

Attack. Rather than attacking the cryptography, an adversary induces operational conditions (load spikes, timeouts, an incident-response scramble) under which an operator or an automated system quietly relaxes a Finality Sink from strict mode to permissive or observe mode (see Section 11.6) to "unblock" traffic, without an auditable decision to do so.

# Attack surface: an on-call engineer, under pressure, flips
# sink_state.mode from STRICT to PERMISSIVE to relieve a queue,
# without a tracked change record.

# Mitigation pattern
def set_sink_mode(sink_state, new_mode, actor, justification):
    if new_mode is LESS_STRICT_THAN(sink_state.mode):
        require_explicit_authorization(actor, justification)
        emit_audit_event(sink_state.sink_id, sink_state.mode,
                          new_mode, actor, justification)
    sink_state.mode = new_mode

Guarantee. This is a process/operational control rather than a cryptographic one: the architecture does not prevent an operator from choosing to weaken enforcement, but it recommends making any such weakening an explicit, attributable, audited action rather than a silent default, so that a downgrade is itself detectable and reviewable.

13.8. T7: Alternate Egress / Unverified Substitute Path

Attack. Rather than attacking the protected release path, an adversary locates a different, unprotected mechanism that produces the same or an equivalent external effect (for example, a debug export endpoint, a legacy API version, a secondary network interface) that was never fitted with a Finality Sink.

Defense posture. This attack cannot be closed by cryptography at a single sink; it requires the deployment to enumerate every path capable of producing the protected effect and ensure each one is either fitted with an equivalent Finality Sink or is itself decommissioned. Section 15 calls this out explicitly: protecting one nominal Finality Sink while leaving an unverified substitute path available weakens the intended property, and this document treats path enumeration as a deployment-time responsibility rather than something the protocol pattern can discover automatically.

13.9. Threat Summary Table

Table 3
ID Threat Primary defense Residual risk
T1 Replay Single-use nonce/counter, atomic consumption None if nonce store is itself protected
T2 Act substitution (TOCTOU) Sink-side digest reconstruction None if load-bearing attributes are exhaustively enumerated
T3 Sink substitution Finality-Sink binding check None if sink identity is unforgeable
T4 Stale authorization Policy/revocation epoch binding Propagation-delay window on partitioned sinks
T5 Forged evidence Cryptographic verification against PED root Full PED compromise (trust-anchor assumption)
T6 Silent downgrade Auditable, attributable mode-change control Operational/process discipline, not cryptographic
T7 Alternate/unverified path Deployment-time path enumeration Unenumerated paths remain fully unprotected

14. Industry and Infrastructure Relevance

Execution finality is relevant wherever software can prepare an act that produces an external, persistent, financial, communicative, jurisdictional, or physical consequence.

14.1. Artificial Intelligence and Agentic Systems

Relevant operations include model-output release, tool invocation, retrieval actions, code execution, agent-to-agent delegation, data export, memory writes, external API calls, autonomous workflows, and machine-generated decisions that trigger downstream systems.

Principal benefit: compromise or overreach of the reasoning environment does not automatically grant unrestricted effectuation authority.

Representative Finality Sinks: tool gateway, API dispatcher, egress broker, memory writer, model-output emitter, operating-system broker, or enterprise control point.

14.2. Telecommunications, 5G, 6G, and AI-Native Networks

Relevant operations include message or packet release, roaming, network-slice changes, subscriber-impacting commands, radio emission, gateway egress, AI-RAN actions, machine-to-machine commands, and non-terrestrial-network operations.

Principal benefit: authenticated network intelligence can remain distinct from final authority to create a network or RF consequence.

Representative Finality Sinks: telecom gateway, SBC, network function, user-plane/control-plane boundary, radio chain, satellite gateway, or device communication broker.

14.3. Cloud, Edge, and Data-Centre Infrastructure

Relevant operations include persistent writes, privileged state changes, DMA, accelerator transfers, storage actions, SmartNIC/DPU operations, tenant egress, infrastructure APIs, and confidential-computing boundary transitions.

Principal benefit: compromise of an application, VM, container, model server, or accelerator workload need not automatically become authority for every persistent or external effect exposed by the infrastructure.

Representative Finality Sinks: storage controller, memory controller, SmartNIC, DPU, hypervisor boundary, accelerator interface, secure service, or egress gateway.

14.4. Payments, Banking, Fintech, and Digital Assets

Relevant operations include payments, account transfers, settlement, digital-asset movement, CBDC operations, trading instructions, escrow release, ledger commitments, and machine-generated financial actions.

Principal benefit: existing payment-domain authorization can be composed with additional act-specific enterprise, purpose, agent, jurisdiction, destination, and protected-state constraints.

Representative Finality Sinks: payment-release interface, settlement gateway, ledger bridge, account-transfer boundary, trading gateway, or protected wallet interface.

14.5. Data Governance, Privacy, and Cross-Border Data Use

Relevant operations include export, disclosure, model access to protected datasets, cross-border transfer, data sharing, retrieval, publication, and persistent reconstruction of protected information.

Principal benefit: policy about purpose, recipient, destination, jurisdiction, and permitted data scope can remain technically coupled to the release boundary rather than existing only as upstream policy.

Representative Finality Sinks: data egress gateway, database export interface, object-store release boundary, API dispatcher, download service, or disclosure broker.

14.6. Satellite, Space, and Non-Terrestrial Infrastructure

Relevant operations include command uplink, RF transmission, payload control, routing, cross-link changes, beam configuration, and autonomous spacecraft actions.

Principal benefit: command preparation can be separated from authority to create the mission or RF consequence.

Representative Finality Sinks: command-uplink gateway, RF chain, payload controller, protected spacecraft interface, or ground-station release point.

14.7. Industrial Control, Energy, and Critical Infrastructure

Relevant operations include process-control commands, breaker operations, valve movements, safety-state changes, plant configuration, grid control, water-system control, and emergency automation.

Principal benefit: application or AI compromise does not automatically create unrestricted physical-control authority.

Representative Finality Sinks: safety PLC, industrial gateway, actuator controller, breaker interface, motor controller, or protected control boundary.

14.8. Robotics, Vehicles, Drones, and Autonomous Machines

Relevant operations include steering, braking, acceleration, robotic motion, drone navigation, payload actions, access control, and other kinetic effects.

Principal benefit: a planner or perception system can compute an action while final actuation remains dependent on independently verified authority and current protected state.

Representative Finality Sinks: drive-by-wire controller, motor controller, robotic actuator, flight-control boundary, or protected device broker.

14.9. Healthcare and Safety-Critical Digital Systems

Relevant operations include device setting changes, patient-data disclosure, safety alerts, clinical workflow actions, and machine-generated commands to connected medical equipment.

Principal benefit: recommendation, computation, and externally effective clinical action can remain distinct authorization stages.

Representative Finality Sinks: device controller, clinical workflow dispatcher, protected data gateway, or safety interlock boundary.

14.10. Cybersecurity and Automated Response

Relevant operations include account disabling, credential rotation, firewall changes, workload isolation, data deletion, quarantine, network blocking, and automated incident-response actions.

Principal benefit: a security agent may detect and propose remediation without automatically possessing unrestricted authority to create a potentially destructive response.

Representative Finality Sinks: identity-control plane, firewall controller, orchestration gateway, storage-delete boundary, endpoint-management service, or cloud control plane.

14.11. Content Publication and Machine-Generated Communications

Relevant operations include public posting, outbound messaging, automated notification, mass communication, email release, content publication, and AI-generated customer or citizen communication.

Principal benefit: generating content remains separate from authority to publish, transmit, notify, or otherwise make the communication externally effective.

Representative Finality Sinks: publisher, messaging gateway, email relay, notification renderer, telecom gateway, or platform communication broker.

14.12. Cross-Industry Common Structure

Although the underlying technologies differ, the same control pattern can be applied:

proposed machine operation
    ->
Candidate Act
    ->
Non-Effective State
    ->
protected act-specific validation
    ->
protected validation evidence
    ->
scoped non-bearer effectuation authority
    ->
Finality-Sink verification
    ->
atomic consumption where required
    ->
externally effective consequence

The proposal is therefore not that every industry must use the same protocol message, cryptographic algorithm, hardware root, or policy language.

The proposed common layer is the invariant that protected authorization of the specific act remains a technical dependency of the consequence boundary itself.

15. Security and Failure Considerations

Implementations should consider the threats enumerated in Section 13, and in addition:

The ordinary compute environment should not be assumed trustworthy merely because it generated the Candidate Act.

High-assurance deployments may fail closed when required protected authorization cannot be verified.

Deployments should also identify equivalent alternate paths that could create the same external effect (see Section 13.8). Protecting one nominal Finality Sink while leaving an unverified substitute path would weaken the intended property.

16. Frequently Asked Questions

Is execution finality another authentication protocol? No. Authentication establishes who or what is interacting. Execution finality determines whether a specific proposed act is authorized to become externally effective.

Is this a replacement for TLS or HTTPS? No. TLS and HTTPS remain necessary for protected communication. Execution finality addresses the semantic authorization of the consequence carried or requested through that protected communication (see Section 11).

Is this just OAuth with another token? No. OAuth provides delegated authorization and can strongly restrict API access. Execution finality focuses on the final act-specific release dependency at the consequence boundary, potentially adding current state, purpose, destination, jurisdiction, freshness, and Finality-Sink binding.

Does EMV already do this? EMV does something importantly similar inside the payment domain: transaction-specific cryptographic information and authorization are part of deciding whether a payment proceeds. The proposed contribution is not to recreate EMV. It is to generalize an execution-finality abstraction across heterogeneous machine acts and to make the protected consequence boundary explicit.

Why not simply put all checks in the application? Application-level checks can be effective, but a compromised or over-privileged application may also possess the path that produces the external effect. Execution finality separates ordinary computation from final consequence authority and places independent verification at or immediately before the effectuation boundary.

Is the Finality Sink necessarily hardware? No. It is a functional boundary. It may be implemented in hardware, protected software, an OS broker, API gateway, telecom function, storage controller, payment-release component, secure enclave, or other system controlling first usable release of the effect.

Does this require blockchain? No. A ledger can be used for evidence or state anchoring where useful, but it is not a baseline requirement.

Would this make AI systems too slow? Not necessarily. Slow policy reasoning can occur on the cold path. The effectuation hot path can be reduced to deterministic verification, state checks, replay prevention, and bounded release (see Section 10).

What happens if validation infrastructure fails? The assurance profile determines behavior. For high-consequence acts, fail-closed behavior may maintain the Candidate Act in the Non-Effective State until required authority can be verified.

Does adopting this require replacing TLS, OAuth, or EMV deployments already in production? No. Section 11 describes an additive shim/gateway pattern intended for incremental, operation-by-operation adoption alongside unmodified legacy mechanisms.

What is the Internet missing in one sentence? A general cross-domain execution-finality layer that makes protected, act-specific authorization a technical prerequisite of externally effective machine consequence.

What is the core invariant? A machine may compute, prepare, or propose an act, but computation alone does not create the authority to make that act externally effective.

17. Resources

The following resources provide additional public context, related prior disclosure, and a runnable reference implementation for the execution-finality architecture described in this document. They are provided for informational context; this Internet-Draft defines the architectural discussion independently of any of them.

19. IANA Considerations

This document has no IANA actions.

20. Informative References

[DAS-6G-CVID]
Das, S., "6G Query-Scoped Communication Handles", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-6g-query-scoped-communication-handles/>.
[DAS-AGENTIC-AI-TOOL-EXEC]
Das, S., "Agentic AI Tool Execution-Finality", Work in Progress, , <https://datatracker.ietf.org/doc/draft-agentic-ai-tool-execution-finality/>.
[DAS-AGENTIC-EXECUTION-FINALITY]
Das, S., "Execution-Finality for Agentic AI Systems", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-agentic-execution-finality/>.
[DAS-AGENTIC-TOOL-BINDING]
Das, S., "tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool Calls", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/>.
[DAS-AI-INTEROP]
Das, S., "Execution-Finality for Third-Party AI Interoperability Under EU DMA Article 6(7)", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-execution-finality-ai-interoperability/>.
[DAS-AI-NATIVE-6G]
Das, S., "Execution-Finality for AI-Native 5G/6G and O-RAN", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-ai-native-6g-execution-finality/>.
[DAS-CANDIDATE-ACT-FINALITY]
Das, S., "The DAS Protocols: Candidate Act Finality", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-protocols-candidate-act-finality/>.
[DAS-CHILD-SAFE-RENDERING]
Das, S., "Execution-Finality for Preventing Unauthorized Rendering of Age-Restricted Content", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-child-safe-rendering-finality/>.
[DAS-DIGITAL-SOVEREIGNTY]
Das, S., "Execution-Finality for Digital Sovereignty", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-digital-sovereignty-finality/>.
[DAS-ENTERPRISE-AI-OUTPUT]
Das, S., "Execution-Finality for Enterprise AI Output", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-enterprise-ai-output-finality/>.
[DAS-EU-AI-ACT]
Das, S., "Technical Execution Enforcement for the EU AI Act", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-eu-ai-act-execution-enforcement/>.
[DAS-FOUNDATIONAL-EF-IMPL]
Das, S., "Execution-Finality for AI Agents, GPUs, Confidential Computing, and Zero-Trust Automation -- Reference Implementation", , <https://github.com/sangmdas/Execution-Finality-for-AI-Agents-GPUs-Confidential-Computing-and-Zero-Trust-Automation>.
[DAS-GLOBAL-PRIVACY]
Das, S., "Global Privacy Execution Enforcement", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-global-privacy-execution-enforcement/>.
[DAS-HARDWARE-ENFORCED-EF]
Das, S., "Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-hardware-enforced-execution-finality/>.
[DAS-MAP-DISCOVERY]
Das, S., "Execution-Finality for MAP Discovery and Communication", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-map-discovery-communication-finality/>.
[DAS-NTN-RF]
Das, S., "Execution-Finality for Non-Terrestrial Network RF Operations", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-ntn-rf-execution-finality/>.
[DAS-OT-ACTUATION]
Das, S., "Execution-Finality for Operational Technology Actuation", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-ot-actuation-finality/>.
[DAS-PAYMENT-FINALITY]
Das, S., "A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-payment-execution-finality/>.
[DAS-PRECISION-EGRESS]
Das, S., "Precision-Bounded Egress", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-precision-bounded-egress/>.
[DAS-PROTOCOLS-ENTERPRISE-AI]
Das, S., "The DAS Protocols: Enterprise AI Governance", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-protocols-enterprise-ai/>.
[DAS-PURPOSE-EXECUTION-FINALITY]
Das, S., "Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-purpose-execution-finality/>.
[DAS-RATS-ATTESTATION-BND]
Das, S., "RATS Attestation-Bound Execution-Finality", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-rats-attestation-bnd-execution-finality/>.
[DAS-RATS-EXTRACT]
Das, S., "Execution-Finality for Frontier Model Information Extraction Control", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/>.
[DAS-RATS-OPENAI-ANTHROPIC]
Das, S., "Execution-Finality for Frontier Model Information Extraction Control: OpenAI and Anthropic", Work in Progress, , <https://datatracker.ietf.org/doc/draft-das-rats-openai-anthropic-extraction/>.
[EMV-3DS]
EMVCo, "EMV 3-D Secure and related specifications and explanatory material", <https://www.emvco.com/>.
[EMV-CHIP]
EMVCo, "EMV Chip and related EMV Chip security documentation", <https://www.emvco.com/>.
[FUTURIUM-EU]
Das, S. and European Commission, Apply AI Alliance, Futurium, "Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance", , <https://futurium.ec.europa.eu/en/apply-ai-alliance/community-content/protecting-europe-technical-foundation-digital-sovereignty-data-protection-and-ai-governance>.
[GITHUB-PRIVACY-FINALITY]
Das, S., "Privacy Finality Reference: A Public Runnable Reference Implementation of Candidate-Act-Based Execution-Finality Enforcement", , <https://github.com/sangmdas/privacy-finality-reference>.
[GITHUB-PRIVACY-FINALITY-RELEASE]
Das, S., "Privacy Finality Reference, Release v0.1.0", , <https://github.com/sangmdas/privacy-finality-reference/releases/tag/v0.1.0>.
[HTTP]
Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, , <https://www.rfc-editor.org/info/rfc9110>.
[TLS13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", , <https://www.rfc-editor.org/info/rfc9846>.
[WIPO-WO2026150382]
Das, S. and World Intellectual Property Organization, PATENTSCOPE, "Hardware-Rooted Execution-Finality System for Sovereign Artificial Intelligence Infrastructure, AI-Native Telecommunications and Satellites", WO 2026/150382, , <https://patentscope2.wipo.int/search/en/WO2026150382>.
[ZENODO-DAS]
Das, S., "The Internet Solved Communication. It Never Solved Authority", , <https://zenodo.org/records/22082995>.

Appendix A. Reference Architecture Diagram (FIG. 1A-1C)

This appendix reproduces, in text-artwork form, the three-sheet reference architecture drawing (FIG. 1A, FIG. 1B, FIG. 1C) corresponding to the execution-finality pipeline described in Section 5 through Section 8 and worked through step-by-step in Section 12.1. Reference numerals 100 through 138 are used consistently with the underlying patent disclosure referenced in Section 17 and are cross-referenced against the vocabulary of this document in Appendix A.4.

A.1. FIG. 1A -- Candidate Act Generation and Staging 

+--------------------------------------------------------------+
| 100  COMPUTE / WORKLOAD PLANE                                 |
| AI model, application, network function, payment engine,      |
| content system, agent, digital twin, or device                |
+--------------------------------------------------------------+
                            |
                            v
+--------------------------------------------------------------+
| 102  CANDIDATE ACT GENERATED                                  |
| Proposed output, packet, tensor, command, payment, API call,   |
| transmission, memory release, actuator command, rendering      |
| event, storage write, or other act                             |
|                                                                  |
| Status: NON-EFFECTIVE / PENDING                                 |
+--------------------------------------------------------------+
                            |
                            v
+--------------------------------------------------------------+
| 104  NON-EFFECTIVE STAGING / HOLD STATE PLANE                  |
| Candidate Act may be computed, queued, buffered, ranked,        |
| simulated, encrypted, sealed, or provisionally prepared, but     |
| cannot be released through a Finality Sink or cross an           |
| execution-finality boundary.                                     |
+--------------------------------------------------------------+
                            |
                            v
+--------------------------------------------------------------+
| 106  PROTECTED AUTHORITY PLANE / PROTECTED ENFORCEMENT          |
|      DOMAIN                                                      |
| TEE, HSM, secure element, SmartNIC, DPU, secure enclave,          |
| TPM-backed module, FPGA, baseband security domain, protected      |
| controller, or equivalent structure                                |
+--------------------------------------------------------------+
                            |
                            v
+--------------------------------------------------------------+
| 108  HCAD / MACHINE-VERIFIABLE ACT DESCRIPTOR                   |
| Descriptor binds act class, effect class, source, destination,   |
| purpose, jurisdiction, policy epoch, nonce, freshness,            |
| Finality Sink, boundary, scope, and evidence                       |
+--------------------------------------------------------------+
                            |
                     ( CONNECTOR A )
                            |
                            v
                  [ continued on FIG. 1B ]

A.2. FIG. 1B -- Protected Validation and Scoped Capability Issuance 

                  ( CONNECTOR A )
             [ continued from FIG. 1A ]
                            |
                            v
+--------------------------------------------------------------+
| 110  PROTECTED PREDICATE VALIDATION                             |
| Validates authority, purpose, jurisdiction, consent,             |
| ALF/RBD where applicable, revocation, freshness, policy           |
| epoch, sink binding, boundary binding, runtime evidence,           |
| quota, budget, and protected state                                  |
+--------------------------------------------------------------+
                 |                              |
          FAILS  |                              |  PASSES
                 v                              v
+---------------------------------+   +---------------------------------+
| 112  VALIDATION FAILS             |   | 114  VALIDATION PASSES            |
| Deny, suppress, quarantine,        |   | Continue to protected state,       |
| zeroize, or hold.  No capability   |   | evidence, and capability           |
| released.                           |   | generation sequence.                |
+---------------------------------+   +---------------------------------+
                 |                              |
                 v                              v
+---------------------------------+   +--------------------------------+
| 116  FAIL-CLOSED / DENIAL          |   | 118  PROTECTED STATE UPDATE /    |
|      ENFORCEMENT HANDLING           |   |      CONSUMPTION                  |
| Candidate Act remains non-effective.|   | Nonce, quota, budget, session,    |
| External effect disabled.  No       |   | revocation, monotonic, or replay  |
| scoped non-bearer capability is     |   | state updated/consumed.           |
| released.  Denial evidence or       |   +--------------------------------+
| denial LAVR is committed as                       |
| protected enforcement evidence of                  v
| non-completion; denial-related       +--------------------------------+
| protected state may be advanced,     | 120  PROTECTED VALIDATION        |
| locked, quarantined, or              |      EVIDENCE / LAVR COMMITMENT   |
| consumed-as-denied to prevent        | Protected validation evidence,    |
| replay, rollback, stale retry,       | receipt, or LAVR is committed      |
| substitution, or cross-sink          | before or atomically with scoped   |
| laundering.                          | non-bearer capability availability.|
+---------------------------------+   +--------------------------------+
                                                     |
                                                     v
                                       +--------------------------------+
                                       | 122  SCOPED NON-BEARER            |
                                       |      CAPABILITY AVAILABILITY /     |
                                       |      RELEASE                        |
                                       | Capability is act-bound,             |
                                       | descriptor-bound, sink-bound,        |
                                       | boundary-bound, nonce-bound,          |
                                       | scope-bound, protected-state-bound,  |
                                       | and evidence-bound.                   |
                                       +--------------------------------+
                                                     |
                                                     v
                                       +--------------------------------+
                                       | 124  FINALITY SINK /               |
                                       |      EFFECTUATION PLANE             |
                                       | Memory controller, DMA engine,      |
                                       | PCIe/CXL/NVLink/UALink boundary,    |
                                       | SmartNIC, DPU, UPF/N6 egress,       |
                                       | radio chain, payment terminal,      |
                                       | ledger bridge, renderer, actuator,  |
                                       | API dispatcher, storage writer, or  |
                                       | model-output emitter                 |
                                       +--------------------------------+
                                                     |
                                              ( CONNECTOR B )
                                                     |
                                                     v
                                           [ continued on FIG. 1C ]

A.3. FIG. 1C -- Sink-Side Verification and Effectuation 

                  ( CONNECTOR B )
             [ continued from FIG. 1B ]
                            |
                            v
+--------------------------------------------------------------+
| 126  SINK-SIDE DESCRIPTOR BUILD / MEASUREMENT                   |
| Finality Sink builds, reconstructs, measures, or verifies a      |
| sink-side descriptor corresponding to the Candidate Act and       |
| local effectuation boundary                                        |
+--------------------------------------------------------------+
                            |
                            v
+--------------------------------------------------------------+
| 128  FINALITY SINK VERIFICATION                                 |
| Verifies scoped capability against exact Candidate Act,          |
| descriptor digest, sink, boundary, nonce, policy epoch,           |
| evidence reference, protected state transition, and scope          |
+--------------------------------------------------------------+
                 |                              |
          FAILS  |                              |  PASSES
                 v                              v
+---------------------------------+   +---------------------------------+
| 132  SINK VERIFICATION FAILS       |   | 134  SINK VERIFICATION PASSES     |
| Candidate Act suppressed,           |   | External effect enabled only      |
| quarantined, zeroized, denied,      |   | within authorized scope.          |
| or withheld.  External effect       |   | Candidate Act may now be          |
| disabled.                            |   | released through the Finality     |
+---------------------------------+   | Sink and cross the execution-     |
                 |                     | finality boundary.                 |
                 v                     +---------------------------------+
+---------------------------------+                    |
| 136  FAIL-CLOSED AT SINK           |                  v
| No transmission, rendering,         |   +---------------------------------+
| write, settlement, emission,        |   | 130  CAPABILITY CONSUMPTION       |
| actuation, dispatch, or release     |   | Capability will be consumed,      |
| occurs.                              |   | invalidated, burned, marked, or   |
+---------------------------------+   | state-advanced before or          |
                                       | atomically with external           |
                                       | effectuation to prevent replay,    |
                                       | reuse, duplicate effectuation, or  |
                                       | cross-sink use.                     |
                                       +---------------------------------+
                                                     |
                                                     v
                                       +--------------------------------+
                                       | 137  SINK-SIDE FINALITY RECEIPT / |
                                       |      OUTPUT LAVR                    |
                                       | Upon successful sink verification, |
                                       | the Finality Sink or protected     |
                                       | enforcement domain may commit      |
                                       | sink-side finality evidence        |
                                       | representing capability            |
                                       | verification, sink identity,       |
                                       | boundary identity, protected-state |
                                       | reference, permitted scope, and    |
                                       | external effectuation status.       |
                                       +--------------------------------+
                                                     |
                                                     v
                                       +--------------------------------+
                                       | 138  EXTERNALLY EFFECTIVE ACT      |
                                       | Act is transmitted, rendered,      |
                                       | written, actuated, settled,        |
                                       | emitted, committed, or otherwise   |
                                       | effectuated.                         |
                                       |                                      |
                                       | Status: EFFECTIVE                    |
                                       +--------------------------------+

A.4. Reference Numeral Cross-Reference

The following table maps each reference numeral in FIG. 1A-1C to the corresponding vocabulary defined in the body of this document.

Table 4
Ref. Drawing element Corresponding document term
100 Compute / Workload Plane Ordinary compute environment (Section 13.1)
102 Candidate Act Generated Candidate Act (Section 6)
104 Non-Effective Staging / Hold State Plane Non-Effective State (Section 6)
106 Protected Authority Plane Protected Enforcement Domain (Section 7)
108 HCAD / Machine-Verifiable Act Descriptor Canonical act digest / load-bearing act attributes (Section 12.2)
110 Protected Predicate Validation Protected validation (Section 12.1, Step 5)
112/116 Validation Fails / Fail-Closed Denial DENY path, Step 11 (Section 12.1)
114 Validation Passes VALID result (Section 12.2)
118 Protected State Update / Consumption Nonce/quota/revocation state (Section 7)
120 Protected Validation Evidence / LAVR Validation evidence, Step 6 (Section 12.1)
122 Scoped Non-Bearer Capability Execution Handle (Section 7)
124 Finality Sink / Effectuation Plane Finality Sink (Section 8)
126 Sink-Side Descriptor Build Act-digest reconstruction, Step 9 (Section 12.1; Section 13.3)
128 Finality Sink Verification finality_sink_receive() (Section 12.2)
130 Capability Consumption Atomic consumption, Step 10 (Section 12.1; Section 13.2)
132/136 Sink Verification Fails / Fail-Closed at Sink DENY at sink (Section 12.2)
134 Sink Verification Passes Effectuation within verified scope (Section 8)
137 Sink-Side Finality Receipt / Output LAVR Optional audit/accountability evidence, Step 12 (Section 12.1)
138 Externally Effective Act EFFECTUATED result (Section 12.2)

Appendix B. Reference Implementation -- Foundational Architecture Methodology

This appendix documents, in detail, a hardened reference implementation of the foundational execution-finality architecture described in this document and diagrammed in Appendix A. It is provided so the architecture can be read as executable, inspectable, reproducible, and falsifiable, not only as prose. It is informational: nothing in this appendix is a normative requirement of this document, and the reference implementation is not itself a claim of hardware non-bypassability or of universal production certification (see Appendix B.13).

The full source code is published in a public GitHub repository, [DAS-FOUNDATIONAL-EF-IMPL].

B.1. Objective and Architectural Invariant

The implementation tests a single architectural invariant: a consequence-bearing operation may be computed, prepared, buffered, queued, ranked, simulated, encrypted, sealed, or otherwise processed, but it remains non-effective until the exact Candidate Act is independently verified by the Finality Sink controlling the corresponding external-effect boundary. The implementation therefore keeps computation, authorization, and effectuation as distinct, separately testable stages rather than collapsing them into a single authorize() -> token -> execute() call (Appendix B.3).

B.2. Derivation from FIG. 1A-1C and Architecture-to-Code Mapping

The implementation follows the three-stage drawing in Appendix A directly, rather than starting from a conventional token framework and renaming its components. The implemented sequence is:

Compute / Workload Plane
   -> Candidate Act
   -> Non-Effective Hold
   -> Protected Authority / PED
   -> HCAD
   -> Protected Predicate Validation
   -> Protected-State Transition
   -> Validation Evidence / LAVR
   -> Scoped Capability
   -> Finality Sink
   -> Sink-Side Descriptor Reconstruction
   -> Independent Verification
   -> Capability Consumption
   -> Sink Receipt
   -> External Effect

The Candidate Act is initially non-effective. The protected authority validates predicates and advances protected state. Evidence is committed before or atomically with capability availability. The Finality Sink independently reconstructs the local descriptor, verifies the exact Candidate Act and all load-bearing bindings, consumes the capability, and only then permits the external effect.

Table 5 gives the exact mapping between the foundational architecture elements used elsewhere in this document and the corresponding runnable construct.

Table 5
Foundational architecture element Runnable implementation
Compute / Workload Plane Any producer capable of constructing CandidateAct
Candidate Act Immutable CandidateAct dataclass
Non-Effective State ActStatus.NON_EFFECTIVE
Protected Authority / PED ProtectedAuthority
HCAD / machine-verifiable descriptor HCAD + build_hcad()
Protected Predicate Validation Policy.validate()
Protected State ProtectedState
Protected State Transition StateTransition
Validation Evidence / LAVR ValidationEvidence
Evidence commitment EvidenceStore
Scoped capability Capability
Strict non-bearer profile PresentationProof
Finality Sink FinalitySink
Sink-side descriptor reconstruction Sink-local build_hcad()
Replay consumption InMemoryConsumptionStore / SQLiteConsumptionStore
Effect boundary Guarded effectors (Appendix B.10)
Output / finality receipt SinkReceipt
External effect Bound effect handle invoked only after sink verification and claim

B.3. Why the Implementation Is Not Just authorize() -> token -> execute()

The reference keeps decision, state, evidence, authority, presentation, sink verification, replay consumption, and effectuation as separately represented stages. This allows tests to mutate each stage independently and determine whether the effect boundary still fails closed. A signature alone is never treated as sufficient: the sink verifies semantic consistency among the Candidate Act, HCAD, policy epoch, evidence, protected-state transition, sink identity, boundary identity, nonce, scope, and time bounds (Appendix B.9).

B.4. Implementation Languages

Three runtimes are intentionally included so that no single language's own bugs can validate themselves:

Table 6
Runtime Role
Python 3.11+ Complete, readable reference implementation (state machine)
Go 1.23.2 Independent infrastructure-oriented verifier
Node.js 22.16.0 Independent application/runtime verifier

Python contains the complete state machine; Go and Node independently reproduce the portable canonicalization and verify deterministic cryptographic and finality vectors. Python was chosen for the complete reference for auditability and readability, not because it is asserted to be the optimal production implementation for every latency class: for a 100-microsecond device or accelerator path, a production implementation would more plausibly be native code, firmware, kernel code, SmartNIC/DPU logic, FPGA logic, or another device-resident implementation. A single-language test suite can be self-consistent while still being wrong (Python could serialize a structure incorrectly and another Python function could reproduce the same mistake), which is why Go independently verifies canonicalization, SHA-256, HMAC, and complete portable Finality Sink vectors -- Go is also directly relevant to networking, gateways, cloud infrastructure, sidecars, and telecom control-plane software, and its Unicode-normalization dependency is vendored so conformance tests can run without Internet access. Node.js was included because JavaScript/TypeScript ecosystems are common in APIs, AI-agent tool systems, service gateways, and application and cloud control planes; the Node canonicalizer explicitly avoids relying on JavaScript's ordinary UTF-16 lexical ordering for security-bound object keys.

B.5. Candidate Act Data Model and Deterministic Test Parameters

The Candidate Act represents the concrete proposed consequence, not merely a generic permission:

Table 7
Parameter Meaning
act_id Candidate identifier
act_class Operation type
effect_class External consequence class
source Workload/agent/service generating the act
destination Exact consequence destination
purpose Authorized purpose
jurisdiction Applicable jurisdiction
policy_epoch Policy version
nonce Replay-resistant nonce
issued_at_ns Candidate creation time
freshness_ns Candidate validity interval
sink_id Intended Finality Sink
boundary_id Intended effect boundary
scope Exact permitted operation scope
payload Exact proposed action/data
runtime_evidence_digest Runtime/attestation evidence binding
authority_context Additional authority context
status Initially NON_EFFECTIVE

A stable reference Candidate is used for deterministic testing: act class api-call, effect class network-egress, source agent-A, destination https://example.invalid/payments, purpose approved-purpose, jurisdiction EU, policy epoch 7, sink sink-A, boundary boundary-A, scope POST:/payments, payload amount 1000 minor units in EUR to beneficiary B1, runtime evidence runtime-ok, freshness 10,000,000,000 ns (10 s), and status NON_EFFECTIVE. The deterministic test clock uses NOW = 1,800,000,000,000,000,000 ns, and a typical Candidate is issued 10,000 ns before NOW, removing wall-clock nondeterminism from security tests.

B.6. HCAD and Canonicalization

The HCAD binds structured consequence context including act class, effect class, source, destination, purpose, jurisdiction, policy epoch, nonce, issuance/freshness information, Finality Sink, boundary, scope, payload digest, and runtime-evidence digest. The implementation uses both a whole-Candidate digest and a structured descriptor digest, giving independent detection of Candidate mutation and of semantic descriptor mismatch.

Security-bound structures use a deliberately narrow canonical profile: UTF-8 encoding; Unicode NFC normalization; deterministic object-key ordering; compact deterministic JSON representation; floats rejected; NaN and infinity rejected; non-string map keys rejected; duplicate keys created by Unicode normalization rejected; portable integers restricted to JavaScript's exact integer range, ±(2^53-1); unpaired surrogate values rejected; and arbitrary bytes rejected from the portable cross-language JSON profile. The local Python canonical form and the narrower Python/Go/Node portable profile are explicitly distinguished. Canonicalization prevents cryptographic disagreement caused by whitespace, object-key order, Unicode-equivalent forms, float rendering, parser differences, duplicate-normalized keys, and alternate serialization; the reference demonstrates one constrained profile rather than inventing a universal wire standard, and a standards-track version would need to define a normative canonical encoding or adopt an established canonical binary/JSON representation.

B.7. Policy, Protected State, and Predicate Validation

The reference policy uses the following example configuration (demonstration parameters, not normative limits):

Table 8
Parameter Reference configuration
Policy epoch 7
Purposes approved-purpose, diagnostic, render
Jurisdictions EU, US, IN
Sinks sink-A, sink-B
Boundaries boundary-A, boundary-B
Required runtime evidence runtime-ok
Maximum future-clock skew 1,000,000,000 ns (1 s)

Reference scopes include POST:/payments, WRITE:/records, DISPLAY, PUBLISH, SEND, SPAWN, ACTUATE, SETTLE, DMA:RELEASE, and QUEUE:PUBLISH. The policy rejects, among other conditions: Candidate not in NON_EFFECTIVE state; incorrect policy epoch; unauthorized purpose, jurisdiction, sink, or boundary; unsupported effect class; unauthorized or empty scope; duplicate scope; revoked source; stale Candidate; future-dated Candidate beyond permitted skew; invalid freshness; and wrong runtime-evidence digest. Additional real deployments may add consent, legal basis, ALF/RBD identity, device posture, transaction risk, model identity, data classification, and other predicates.

ProtectedState models state that should reside in a rollback-resistant or protected location in production: monotonic version (starts at 0), quota (reference default 1,000), budget (reference default 1,000), and authorization cost (reference default 1). A successful authorization advances state: version N to N+1, quota Q to Q-1, budget B to B minus cost. The state-transition identifier cryptographically incorporates the relevant before/after values, nonce, source, epoch, and Candidate digest.

B.8. Evidence-Before-Capability Ordering, LAVR, and Capability Construction

The implementation deliberately performs, in this order:

validate Candidate
    |
    v
advance protected state
    |
    v
construct ValidationEvidence
    |
    v
sign evidence
    |
    v
commit evidence
    |
    v
construct/sign capability
    |
    v
make capability available

It does not issue authority first and attempt to log evidence later: if evidence commitment fails, the operation fails closed and no usable capability is returned. The reference evidence (the LAVR) includes: evidence_id (cryptographic evidence identity), authority_id (authority issuing the decision), descriptor_digest (exact HCAD), candidate_digest (exact Candidate), transition_id (protected-state transition), policy_epoch, decision (ALLOW/DENY), reasons (decision rationale), committed_at_ns, key_id (signing-key identity), and signature. The evidence store rejects invalid signatures and duplicate evidence identifiers.

The scoped capability binds: authority identity; Candidate digest; descriptor digest; sink identity; boundary identity; nonce; permitted scope; policy epoch; evidence identifier; protected-state transition identifier; issue time; expiry; and signing-key identity. The default maximum capability TTL is 5,000,000,000 ns (5 s). Actual expiry is the minimum of Candidate freshness expiry and authority TTL expiry, so capability issuance cannot extend Candidate freshness.

The dependency-light baseline uses SHA-256 for digests and HMAC-SHA256 for deterministic authentication, chosen because Python, Go, and Node can independently reproduce the vectors with minimal dependencies -- not as a recommendation to share one symmetric key across unrelated trust domains. The repository also includes optional Ed25519 support. Production systems should normally separate at least an authority key (capability/evidence signing), a presenter key (proof of possession), and a sink key (finality-receipt signing).

Red-team analysis identified that act-bound + sink-bound + single-use does not automatically make an artifact non-bearer: an attacker stealing the exact Candidate and exact unused capability could potentially race the legitimate presenter. The strict profile therefore binds a presenter identity and requires a fresh proof over: capability identifier; Candidate digest; sink identifier; boundary identifier; nonce; presentation timestamp; and presenter key identifier. Default presentation freshness is 2,000,000,000 ns (2 s); tests explicitly reject proofs just outside both positive and negative freshness windows.

B.9. Finality Sink Verification and Replay Protection

The Finality Sink owns its own local context -- sink ID (sink-A in the reference), boundary ID (boundary-A), policy epoch (7), supported scopes, and effect class, all locally configured. The caller is not allowed to dictate the sink's identity; the sink uses its own local configuration when reconstructing the HCAD (Section 13.4). The sink approximately verifies, in sequence:

Candidate remains NON_EFFECTIVE
  -> effect class matches local sink
  -> Candidate sink matches local sink
  -> capability sink matches local sink
  -> Candidate boundary matches local boundary
  -> capability boundary matches local boundary
  -> Candidate epoch matches local epoch
  -> capability epoch matches local epoch
  -> Candidate scope matches capability scope
  -> scope is locally supported
  -> nonce matches
  -> capability time is valid
  -> capability does not outlive Candidate
  -> capability signature is valid
  -> optional presenter proof is valid and fresh
  -> Candidate digest matches reconstructed Candidate
  -> HCAD is rebuilt using local sink/boundary
  -> descriptor digest matches locally rebuilt descriptor
  -> evidence exists
  -> evidence signature is valid
  -> evidence decision is ALLOW
  -> evidence authority matches capability authority
  -> evidence Candidate matches capability Candidate
  -> evidence descriptor matches capability descriptor
  -> evidence state transition matches capability state transition
  -> evidence epoch matches capability epoch
  -> protected-state transition is valid
  -> capability is claimed/consumed
  -> external effect is invoked

This is intentionally stronger than "signature valid implies allow." The Finality Sink does not trust an upstream assertion that the descriptor was already checked; it reconstructs the effect context using sink-owned identity, boundary, epoch, effect class, and scope configuration, which lets it detect cross-sink laundering, wrong-boundary presentation, local epoch mismatch, unsupported scope, post-authorization Candidate mutation, and semantically inconsistent but validly re-signed artifacts -- directly exercising the T2 and T3 defenses of Section 13.3 and Section 13.4.

Two replay/consumption backends are included. The in-memory backend uses a lock to protect capability claim state. The SQLite durable backend uses SQLite 3.46.1, WAL journal mode, capability_id as the primary key, BEGIN IMMEDIATE for the claim transaction, and a 30-second connection timeout; duplicate capability identifiers are converted into replay rejection. Replay is exercised under contention: 2, 3, 4, 8, 16, 32, and 64 concurrent contenders for the in-memory store, and 2, 4, 8, 16, and 32 for the SQLite store, plus 2, 3, 5, 10, and 25 sequential replay attempts. The expected invariant in every case is that exactly one contender may create the effect and every other contender is rejected (directly exercising Section 13.2).

The reference uses VERIFY -> CLAIM/CONSUME -> EXTERNAL EFFECT rather than VERIFY -> EXTERNAL EFFECT -> CONSUME. This chooses at-most-once safety and avoids the failure mode where an effect occurs, the process crashes before consumption, and a retry produces a duplicate effect. The opposite residual is explicitly documented: capability consumption may succeed and the process may crash before the external effect occurs, producing consumed/no-effect. Systems requiring stronger exactly-once semantics should bind capability_id to a target-native transaction, idempotency key, ledger transaction identifier, transactional outbox, or device-resident atomic consume-and-release primitive.

B.10. Guarded Effectors and Wide-Channel Threat Surface

Nine consequence-boundary simulations are implemented:

Table 9
Consequence Reference effector
Network transmission NetworkEffector
Storage mutation StorageEffector
Rendering RendererEffector
Message queue QueueEffector
Process spawning ProcessEffector
Actuation ActuatorEffector
Payment/ledger PaymentEffector
AI/model output ModelOutputEffector
DMA/memory release DMAEffector

The ordinary public effect path rejects direct invocation; the sink receives a private bound handle. This proves the reference API seam (Section 13.8), not physical non-bypassability against privileged attackers -- see Appendix B.13.

A wider deployment threat model additionally covers twenty consequence channels: network-egress, storage-write, renderer, message-queue, process-spawn, actuator, payment-ledger, model-output, DMA/memory-release, webhook, email-send, SMS-send, radio-transmit, ledger-bridge, file-export, clipboard, print-spool, socket-egress, shared-memory-release, and device-command. Every declared channel records whether it is externally effective, sink-mediated, protected by an enforcement boundary, and privileged. Externally effective, non-mediated paths are treated as critical; missing or non-privileged enforcement boundaries are separately flagged -- the reference-implementation instance of alternate-path closure (Section 13.8).

Eight reference deployment profiles illustrate how the hot path/cold path split of Section 10 applies at different consequence boundaries:

Table 10
Profile Example sink Latency target Example enforcement
Embedded control actuator 100 μs MCU / secure element
Accelerator hot path DMA/memory release 500 μs GPU/DPU/SmartNIC
UPF egress network 1 ms UPF/N6 or SmartNIC
API gateway network 2 ms reverse proxy/gateway
Storage writer storage 5 ms transactional writer
Payment finality ledger 10 ms payment/ledger bridge
Cross-region governance network 20 ms regional gateway
Audit-heavy output model output 50 ms controlled emitter

These latency values are engineering stress bands, not vendor specifications or normative requirements. Cold-path examples include remote attestation collection, certificate-chain validation, policy retrieval, policy compilation, trust-anchor verification, and configuration distribution; hot-path examples include local descriptor reconstruction, digest/signature verification, local epoch/state lookup, replay claim, and effect commit. Very tight latency targets generally require precomputation and execution near the actual protected effect boundary.

B.11. Verification Campaign: Test Counts and Methodology

The hardened implementation contains 481 collected Python tests, all reported passing in the recorded run:

Table 11
Test module/category Tests
Binding integrity 66
Canonicalization 54
Consequence channels 36
Concurrency/replay 17
Core architecture 11
Defensive branches 13
Ed25519 2
Fail-closed/fault injection 16
Seeded fuzz mutations 76
Interoperability 37
Non-bearer/PoP 13
Policy matrix 35
System profiles 17
Key-role separation 2
Finality Sink adversarial 43
Wide-channel surface 43
TOTAL 481

Binding-mutation tests mutate load-bearing Candidate fields after authorization -- act ID, act class, effect class, source, destination, purpose, jurisdiction, policy epoch, nonce, issue time, freshness, sink, boundary, scope, runtime evidence, and authority context -- and payload tests independently alter amount, currency, beneficiary, missing/extra fields, zero/negative values, large integers, nested structures, reordered lists, type changes, case changes, and whitespace-sensitive values; the original capability must never authorize the changed Candidate (the reference-implementation instance of T2, Section 13.3).

Many adversarial tests do not merely corrupt signatures -- they alter capability or evidence fields and then re-sign the malicious artifact with a valid reference key, testing whether the sink validates semantics rather than using the weak rule "valid signature equals valid authority." Re-signed attacks target authority, Candidate digest, descriptor digest, sink, boundary, nonce, scope, epoch, evidence identifier, state transition, and timing values -- directly exercising T5, Section 13.6.

Seventy-six deterministic seeded mutation tests (fixed seeds, reproducible failures) cover payment-like payload properties and destination/context properties; this is not claimed to be coverage-guided fuzzing such as AFL/libFuzzer or a complete stateful property-fuzz campaign. Policy variation tests cover combinations and boundary values for jurisdictions (EU, US, IN), purposes, quota and budget boundaries, valid and over-budget costs, source revocation sets, correct and incorrect epochs, valid/zero/stale/future freshness, and correct/empty/duplicate/unauthorized scopes -- purpose x jurisdiction alone creates a 3x3 cross-product. Sink-focused adversarial tests exercise wrong sink IDs, wrong boundaries, wrong epochs, restricted scopes, multiple valid and invalid time points, altered destinations and scopes, and sinks configured with the wrong authority verification material, with adversarial epoch values including 0, 1, 6, 8, 9, and 2^31-1 (covering ordinary off-by-one conditions and extreme values).

Cross-language interoperability is checked with 20 positive deterministic vectors independently verified by Python, Node, and Go, exercising canonical representation, UTF-8 bytes, SHA-256, and HMAC-SHA256, plus additional vectors covering decomposed Unicode values and keys, BMP-versus-supplementary-plane key ordering, JSON control characters, <, >, &, U+2028/U+2029, and canonical-equivalent forms. A separate nine-case canonicalization conformance suite (five required-success, four required-rejection cases, including NFC key collision, float rejection, and integers outside the portable safe range) is executed independently by Node and Go, with corresponding Python tests covering the same profile. Two complete portable Finality Sink vectors (a baseline Candidate and a Candidate containing decomposed Unicode inside load-bearing material) are independently reconstructed and verified end-to-end (Candidate to payload digest to HCAD to Candidate digest to protected-state transition to validation evidence to capability to sink-local context to Finality Sink verification) by Node and Go, so the implementation does not rely on Python to generate and verify its own artifacts exclusively.

The hardened run reports 724 Python source statements, 0 statements missed, 100% statement coverage, via pytest --cov=src/finality_ref --cov-report=term-missing:skip-covered -q. This does not mean 100% security coverage; it means every measured executable Python statement was exercised by the test suite.

B.12. Benchmark Methodology and Results

The benchmark uses time.perf_counter_ns() and performs 1,000 warm-up iterations followed by 3,000 measured iterations per path, across three paths: canonicalization plus SHA-256; Finality Sink verification only; and complete authority plus sink plus guarded effectuation. The benchmark Candidate uses a network-egress act from bench-agent to example.invalid/effect, purpose bench, jurisdiction EU, epoch 1, sink bench-sink, boundary bench-boundary, scope SEND, runtime evidence runtime-ok, 60-second Candidate freshness, 30-second capability TTL, and quota/budget of 1,000,000 to prevent benchmark exhaustion.

The recorded reference environment:

Table 12
Environment item Recorded value
Python CPython 3.13.5
Kernel Linux 6.18.35
Architecture x86-64
libc glibc 2.41
CPU AMD EPYC 9V74 80-Core Processor (AuthenticAMD)
Logical CPUs visible 5 (process affinity CPUs 0-4)
Visible memory 6,236,925,952 bytes
SQLite / OpenSSL 3.46.1 / 3.5.5
Node.js / ICU 22.16.0 / 77.1
Go 1.23.2 linux/amd64
pytest / pytest-cov / coverage 9.0.2 / 7.0.0 / 7.13.3
cryptography / setuptools 46.0.4 / 82.0.1

The recorded benchmark results:

Table 13
Operation Mean p50 p95 p99 Max
Canonical SHA-256 7.98 μs 7.12 μs 8.90 μs 29.37 μs 233.75 μs
Sink verify only 215.32 μs 197.30 μs 287.84 μs 504.20 μs 1,314.27 μs
Authority + sink + effect 1,113.22 μs 1,054.97 μs 1,350.46 μs 1,847.28 μs 4,037.53 μs

These are reproducible user-space Python reference measurements, not certified production measurements for GPU, DPU, telecom, payment, embedded, or other target hardware. The benchmark does not establish controlled CPU frequency, turbo state, cache topology, NUMA placement, power governor, core isolation, virtualization contention, or dedicated accelerator usage.

B.13. Threat Model, Limitations, and Deployment-Required Items

The reference implementation's threat model includes Candidate mutation, destination substitution, purpose/jurisdiction substitution, scope expansion, sink and boundary substitution, cross-sink laundering, epoch rollback, stale/future capabilities, evidence mutation/deletion, protected-state substitution, sequential and parallel replay, capability theft, confused-deputy presentation, canonicalization disagreement, Unicode collision, downstream crash, direct raw-socket bypass, direct database bypass, renderer/debug leakage, DMA/P2P bypass, hidden consequence channels, sink compromise, key compromise, denial of service, and covert channels -- a superset of the threat model in Section 13. The reference package classifies each item as TESTED (directly exercised in executable tests), MITIGATED (design reduces risk but residual remains), DEPLOYMENT_REQUIRED (cannot be solved by the user-space reference alone), or RESIDUAL/OUT_OF_SCOPE (explicitly unresolved).

Principal limitations, stated directly rather than implied:

  • Python is not a hardware security boundary.
  • The repository cannot automatically discover every hidden effect path.
  • HMAC is reference/interoperability crypto, not a universal production key-distribution recommendation.
  • Vendor-specific RATS/TPM/TEE/GPU attestation verification remains pluggable rather than fabricated.
  • Exactly-once consequences are not universally guaranteed.
  • Timing/cache/RF/power and other covert or physical side channels are outside the model.
  • A fully compromised privileged Finality Sink remains a fundamental threat.
  • Python memory alone cannot provide hardware rollback resistance.
  • The canonical JSON profile is deliberately narrow and should become a normative wire profile in a standards-track implementation.
  • Runtime Unicode-data versions differ; the current conformance claim is tied to the defined profile and included repertoire, not every future Unicode code point.
  • Latency profiles are targets/stress bands, not guarantees.
  • 481 tests and 100% statement coverage do not prove absence of unknown vulnerabilities.
  • The implementation is an engineering realization and does not by itself establish patent scope or legal claim construction.
  • Actual non-bypassability requires that every consequence-bearing path converge on a privileged Finality Sink or equivalent enforcement boundary.

A real deployment should be considered incomplete if a raw socket, alternate database credential, unmediated renderer, DMA mapping, message-broker credential, direct file writer, or other external-effect path can bypass the Finality Sink (the general alternate-path-closure requirement of Section 13.8 and Section 15).

B.14. Reproduction and Falsifiability

Representative complete verification commands are:

python3 -m compileall -q src
pytest -q

node node/verify.mjs vectors/interop.json
node node/canonical_conformance.mjs \
    vectors/canonicalization_conformance.json
node node/finality_verify.mjs vectors/finality_case.json
node node/finality_verify.mjs vectors/finality_case_unicode.json

cd go
go test -mod=vendor ./...
go vet -mod=vendor ./...
go run -mod=vendor . ../vectors/interop.json
go run -mod=vendor ./cmd/canonicalconformance \
    ../vectors/canonicalization_conformance.json
go run -mod=vendor ./cmd/finalityverify ../vectors/finality_case.json
go run -mod=vendor ./cmd/finalityverify \
    ../vectors/finality_case_unicode.json

python3 examples/demo.py
python3 examples/strict_non_bearer.py
python3 scripts/benchmark.py

The architecture is intentionally falsifiable. A claimed deployment should fail review if an external effect can bypass the sink, if sink identity is caller-controlled, if effect occurs before final verification, if replay can produce a second consequence, if evidence or protected state can be substituted without rejection, if epoch downgrade is accepted, if scope can be enlarged, if a claimed strict non-bearer capability works through mere possession, or if the claimed sink is only a user-space wrapper around an otherwise unrestricted effect path.

The supportable conclusion from the current hardened package is that the foundational execution-finality architecture has been converted into an executable state machine in which exact Candidate Acts remain non-effective until protected validation, protected-state advancement, evidence commitment, scoped authority generation, sink-local descriptor reconstruction, independent effect-time verification, replay consumption, and guarded effectuation occur. The implementation has been exercised through hundreds of deterministic adversarial tests, concurrency races, failure injections, canonicalization attacks, cross-language verifiers, and system/deployment variations. Actual deployment non-bypassability still depends on locating the Finality Sink at the real privileged consequence boundary.

Table 14
Verification summary item Value
Python tests 481 passed
Python source statement coverage 724/724 statements exercised (100%)
Cross-language positive vectors 20
Canonicalization conformance cases 9
Complete Finality Sink vectors 2
Independent runtimes Python + Node.js + Go
Concurrent replay testing up to 64 contenders
Wide-channel deployment model 20 consequence channels
Executable consequence simulations 9
Deployment/latency profiles 8 profiles, 100 μs to 50 ms
Benchmark 1,000 warm-up + 3,000 measured iterations per path

Author's Address

Sangam Das
Independent Inventor
Balasore
Odisha
India