]> Independent Inventor

Balasore Odisha India info@sangamdas.com

General Independent Submission execution finality agentic AI candidate act authorization threat model finality sink 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.

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 . 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.

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?

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.

Earlier digital systems frequently operated within workflows where human review, incident response, rollback, revocation, or manual intervention remained relevant to the time scale of the action. AI-native infrastructure compresses that interval to the point where it no longer functions as a safety margin. This is the specific condition that motivates this document, and it is worth stating plainly: the reason execution finality did not need to exist as a general cross-domain layer in 1995, 2005, or even 2015 is that the actor generating consequential requests was, in the overwhelming majority of cases, a human, and humans are slow enough relative to review, monitoring, and manual intervention that application-level and post-hoc controls were sufficient. Autonomous agents can invoke tools, call APIs, transmit data, create files, modify databases, initiate payments, trigger workflows, reconfigure infrastructure, generate telecommunications operations, or issue machine commands within milliseconds, in loops that may run thousands of times per hour without a human observing any individual iteration. An agent does not need to be malicious to be dangerous in this model: a correctly authenticated, correctly authorized, non-adversarial agent that is simply wrong about the current purpose, destination, or policy state can still generate a fully valid, fully transportable, fully credentialed Candidate Act that should not become effective. By the time a log is read:

• the data may already have crossed a jurisdiction;
• the payment may already have been released;
• the network state may already have changed;
• the telecom transmission may already have occurred;
• the model or system memory may already have changed; or
• the physical actuation may already have happened.

Post-event evidence is essential. But: evidence of an unauthorized act is not prevention of the act. 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.

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.

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

• AI-agent tool calls;
• API requests;
• file or database exports;
• storage writes;
• model-memory updates;
• payment instructions;
• telecom transmissions;
• network configuration changes;
• radio emissions;
• satellite commands;
• content publication;
• notification rendering;
• actuator commands;
• vehicle or robotic operations; and
• other consequence-bearing machine operations.

The Non-Effective State is the logical state in which the Candidate Act may exist computationally but cannot yet cross the relevant effectuation boundary. In shorthand: computation exists != consequence is authorized

Before effectuation, applicable conditions may be validated inside a protected hardware, cryptographically isolated, or otherwise protected enforcement environment. Conditions may include:

• actor identity;
• workload identity;
• AI-agent identity;
• purpose;
• user or enterprise authority;
• consent;
• destination;
• recipient;
• jurisdiction;
• policy epoch;
• revocation state;
• nonce or freshness state;
• quota;
• permitted effect;
• runtime integrity;
• protected state;
• algorithm or model identity;
• execution context; and
• Finality Sink identity.

Successful validation may produce protected evidence and a bounded Execution Handle or equivalent capability. Such effectuation authority may be non-bearer, single-use, quota-limited, revocable, time-bounded, purpose-bound, destination-bound, state-bound, and Finality-Sink-bound. Possession or copying of a representation alone should not transfer the underlying execution authority to another actor, context, destination, session, or sink.

The Finality Sink is the first boundary at which a Candidate Act would become externally effective. It is a functional role and does not require one specific physical component. A Finality Sink may be:

• an API dispatcher;
• an egress gateway;
• a model-output emitter;
• a telecom gateway;
• an IMS or network-function boundary;
• a radio transmission chain;
• a SmartNIC or DPU;
• a memory controller;
• a storage writer;
• a payment-release interface;
• a settlement or ledger bridge;
• an operating-system broker;
• a notification renderer;
• a satellite-command interface; or
• a physical actuator.

The Finality Sink verifies the applicable effectuation authority before releasing the consequence-bearing operation. If verification fails: the Candidate Act remains non-effective. If verification succeeds: effectuation may proceed only within the verified scope. Where required, single-use capability or protected state is consumed before or atomically with effectuation.

TLS 1.3 is designed to provide a secure channel between communicating peers. Its security properties include peer authentication, confidentiality, integrity, and record-layer protections. TLS therefore answers questions such as: Is this the authenticated peer? Has the communication been protected from eavesdropping or undetected modification? TLS does not define the application-specific semantic rule that a consequential command carried inside the protected channel is authorized to produce a particular external effect. A malicious, compromised, or over-authorized endpoint can therefore transmit a perfectly valid TLS-protected command. Execution finality is intended to operate after or alongside secure transport by independently controlling release of the consequential effect.

HTTPS combines HTTP semantics with a secured connection to an authoritative origin. HTTP request methods convey client intentions regarding identified resources, while HTTPS provides authentication of the relevant origin and confidentiality and integrity protection for the HTTP exchange. This is an important distinction: HTTPS is not merely encryption. Nevertheless, successful HTTPS communication does not itself establish a universal rule that every downstream real-world effect requested in the HTTP message is authorized for its current purpose, jurisdiction, protected state, runtime condition, and effectuation boundary. An application can implement such controls, but they are application-specific. Execution finality proposes making the final act-level release dependency explicit and reusable across domains.

OAuth and similar systems can provide powerful delegated authorization and scope-limited access. These mechanisms may already be used to prevent unauthorized API operations. Execution finality does not claim otherwise. The distinction is that access authorization and effectuation authority need not be identical. A token may authorize access to an API or resource while a particular requested consequence may require additional validation of purpose, current state, destination, jurisdiction, freshness, revocation, act-specific attributes, and the identity of the actual effectuation boundary. The execution-finality model places that last validation structurally at or immediately before the Finality Sink.

EMV must be distinguished carefully because it already contains transaction-specific security and authorization mechanisms. EMV Chip can generate transaction-specific cryptograms. Depending on the transaction flow, cryptographic information can be verified locally by a terminal or remotely by an issuer. EMV 3-D Secure also supports payment authentication and issuer decision-making for e-commerce transactions. EMV therefore demonstrates an important principle: high-throughput infrastructure can make transaction-specific cryptographic authorization part of a real-time consequence-bearing workflow. Execution finality does NOT claim that EMV merely authenticates a generic credential or that EMV fails to authorize payment transactions. The distinction proposed here is scope and architectural generality. EMV is purpose-built for payment ecosystems and payment consequences. Execution finality proposes a generalized abstraction for arbitrary machine-generated consequences, including AI-agent tool use, data export, telecom transmission, cloud and storage operations, network reconfiguration, satellite commands, and physical actuation. It additionally emphasizes a common cross-domain structure: 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.

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.

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

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.

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.

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.

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 . Actual figures depend on hardware, cryptographic primitive, assurance level, and topology, and this document makes no universal latency claim.

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

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.

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.

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.

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.

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.

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.

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.

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 ).

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 :

• 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.

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. 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.

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. 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.

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. 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.

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. 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.

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. 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 ): 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.

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 ) to "unblock" traffic, without an auditable decision to do so. 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.

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. 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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Although the underlying technologies differ, the same control pattern can be applied: 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.

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

• replay;
• stale authorization;
• compromised applications;
• compromised AI agents;
• forged validation evidence;
• policy rollback;
• nonce reuse;
• quota races;
• destination substitution;
• sink substitution;
• authority forwarding;
• cross-session reuse;
• fail-open behavior;
• bypass paths;
• alternate egress mechanisms;
• protected-domain compromise; and
• denial-of-service attacks.

The ordinary compute environment should not be assumed trustworthy merely because it generated the Candidate Act. High-assurance deployments may fail closed when required protected authorization cannot be verified. Deployments should also identify equivalent alternate paths that could create the same external effect (see ). Protecting one nominal Finality Sink while leaving an unverified substitute path would weaken the intended property.

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 ). 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 ). 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. 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.

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

• EU AI Alliance Futurium community article, : "Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance," discussing the same execution-finality architecture in the context of EU digital-sovereignty and AI-governance policy.
• WIPO PatentScope international publication, : WO 2026/150382, "Hardware-Rooted Execution-Finality System for Sovereign Artificial Intelligence Infrastructure, AI-Native Telecommunications and Satellites," the published international patent application corresponding to the architecture described in this document.
• Privacy Finality Reference, : a public, runnable reference implementation of Candidate-Act-based execution-finality enforcement, illustrating the Candidate Act, Protected Enforcement Domain, Execution Handle, and Finality Sink constructs defined in this document.
• Privacy Finality Reference, release v0.1.0, : the versioned reference-implementation release corresponding to the architecture described in this document.
• Execution-Finality for AI Agents, GPUs, Confidential Computing, and Zero-Trust Automation, : the primary reference implementation from which the detailed methodology, architecture-to-code mapping, threat-model testing, and benchmark results in are drawn.

This document is part of a series of Internet-Drafts by the same author applying the Candidate Act / Non-Effective State / Protected Enforcement Domain / scoped non-bearer Execution Handle / independent Finality Sink architecture described in this document to specific domains, regulatory frameworks, and neural/agentic-AI surfaces. They are listed here for cross-reference; none of them is incorporated normatively into this document, and each remains an independent Work in Progress.

, "The DAS Protocols: Candidate Act Finality," and , "The DAS Protocols: Enterprise AI Governance," develop the same foundational vocabulary used throughout this document from complementary angles.

, "Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse"; , "Technical Execution Enforcement for the EU AI Act"; and , "Global Privacy Execution Enforcement," apply the architecture to purpose-limitation, EU AI Act high-risk system, and general-purpose privacy enforcement respectively. , "Precision-Bounded Egress," and , "Execution-Finality for Digital Sovereignty," apply it to data-precision export bounds and to digital-sovereignty enforcement.

, "Execution-Finality for AI-Native 5G/6G and O-RAN"; , "6G Query-Scoped Communication Handles"; , "Execution-Finality for MAP Discovery and Communication"; and , "Execution-Finality for Non-Terrestrial Network RF Operations," apply the architecture to 5G/6G/O-RAN, query-scoped communication handles, MAP discovery, and satellite/NTN RF command paths.

, "Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents," is the most directly related companion, applying this document's architecture specifically to MCP tool dispatch, computer use, memory writes, GPU/accelerator egress, and industrial-agent settlement, with a runnable reference implementation and threat model of its own. , "Execution-Finality for Frontier Model Information Extraction Control," and its companion , "Execution-Finality for Frontier Model Information Extraction Control: OpenAI and Anthropic," apply it to controlling release of sensitive model information. , "RATS Attestation-Bound Execution-Finality," binds the architecture to RATS attestation evidence. , "Execution-Finality for Preventing Unauthorized Rendering of Age-Restricted Content," and , "Execution-Finality for Third-Party AI Interoperability Under EU DMA Article 6(7)," apply it to child-safe content rendering and to third-party AI interoperability under EU DMA Article 6(7). , "tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool Calls"; , "Execution-Finality for Enterprise AI Output"; , "Execution-Finality for Agentic AI Systems"; and , "Agentic AI Tool Execution-Finality," each bind the architecture to a further agentic tool-use or enterprise AI-output surface.

, "A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments," and , "Execution-Finality for Operational Technology Actuation," apply the architecture to agentic/API payment settlement and to OT/industrial-actuation command paths.

This document has no IANA actions.

EMVCo EMVCo European Commission, Apply AI Alliance, Futurium World Intellectual Property Organization, PATENTSCOPE Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress

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 through and worked through step-by-step in . Reference numerals 100 through 138 are used consistently with the underlying patent disclosure referenced in and are cross-referenced against the vocabulary of this document in .

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

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

This appendix documents, in detail, a hardened reference implementation of the foundational execution-finality architecture described in this document and diagrammed in . 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 ). The full source code is published in a public GitHub repository, .

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 ().

The implementation follows the three-stage drawing in directly, rather than starting from a conventional token framework and renaming its components. The implemented sequence is: 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. gives the exact mapping between the foundational architecture elements used elsewhere in this document and the corresponding runnable construct.

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 ()
Output / finality receipt	SinkReceipt
External effect	Bound effect handle invoked only after sink verification and claim

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 ().

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

Runtime	Role
Python 3.11+	Complete, readable reference implementation (state machine)
Go 1.23.2	Independent infrastructure-oriented verifier
Node.js 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.

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

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.

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.

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

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.

The implementation deliberately performs, in this order: 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.

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 (). The sink approximately verifies, in sequence: 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 and . 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 ). 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.

Nine consequence-boundary simulations are implemented:

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

The ordinary public effect path rejects direct invocation; the sink receives a private bound handle. This proves the reference API seam (), not physical non-bypassability against privileged attackers -- see . 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 (). Eight reference deployment profiles illustrate how the hot path/cold path split of applies at different consequence boundaries:

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.

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

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, ). 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, . 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.

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:

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:

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.

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 . 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 and ).

Representative complete verification commands are: 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.

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