Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies

7.1. End-to-End Flow

A real deployment separates four moments that today's systems commonly collapse into one: the model computes; a Candidate Act is formed and held non-effective; a Protected Enforcement Domain validates machine-readable governance constraints; and a Finality Sink independently re-verifies immediately before the first usable external effect.¶

  GOVERNANCE (cold path; not on every call)
  -----------------------------------------
  Legal / organisational determination
      |  (Art. 5 / 9 / 14 / 26 / 50, or
      |   Korean / Japanese / other profile)
      v
  Compiled Governance Constraint Set (GCS)
      policy_profile_id, jurisdiction, policy_epoch,
      allowed operations, recipients, destinations,
      human-oversight predicate, transparency marker,
      risk-control / model-version / revocation state
      |
      |  signed policy bundle  ----------------+
                                               |
  COMPUTE PLANE (hot path may reason freely)   |
  ------------------------------------------   |
  AI model / agent / planner / workflow        |
      |                                        |
      |  proposes action                       |
      v                                        |
  Candidate Act  {                             |
      act_id, ai_system_id, workload_id,       |
      operation, target, purpose,              |
      recipient, destination,                  |
      input/output commitments,                |
      policy_epoch, nonce, expiry,             |
      finality_sink_id                         |
  }                                            |
      |                                        |
      |  ACT_DIGEST = HASH(CANONICALIZE(.))    |
      v                                        |
  NON-EFFECTIVE STATE                          |
  (no tool invoke, no DB commit, no wire,      |
   no actuator, no publication)                |
      |                                        |
      v                                        |
  AUTHORITY / FINALITY PLANE                   |
  ------------------------------------------   |
  Protected Enforcement Domain (PED)  <--------+
      |  evaluate exact act against GCS
      |  + current revocation / epoch
      |  + required human approval (if any)
      |  + transparency / runtime / safety state
      |
      +-- DENY --> remain NON-EFFECTIVE
      |            (queue / review / safe state)
      |
      +-- PASS --> Protected Validation Evidence
                   + act-bound Effectuation Authority
                     (non-bearer; sink-bound; digest-bound)
      |
      v
  FINALITY SINK  (at first usable external effect)
      API gateway | payment rail | DB COMMIT
      SMTP / publish | industrial controller
      OS / network egress | recipient-side service
      |
      |  re-verify:
      |    digest match, THIS sink, epoch current,
      |    not expired, not revoked, not consumed,
      |    signature + proof-of-possession,
      |    required current-state predicates
      |
      +-- FAIL --> HARD DENY / no effect
      |
      +-- PASS --> atomically consume authority
                   and perform protected effect
      |
      v
  EXTERNAL CONSEQUENCE
      + Finality record (Art. 12-compatible observation)

The load-bearing property is the last gate. Successful generation of a tool call, a UI "approve" click that is not bound to the act digest, an OAuth token for a class of operations, or a TLS session to the destination does not, by itself, cause the protected effect. Only a current, act-bound, sink-verified authority does. See Section 25 and Section 26.¶

7.2. Worked Operational Drawing -- Employment Decision Commit

The same path applied to the employment example in Section 22 is as follows. The HR database transition PENDING to REJECTED is the protected consequence. Everything above that transition may proceed; the transition itself may not.¶

  [Recruiter / ATS]     [High-risk employment AI]
          |                       |
          |  application 81274    |  scores / reasons
          |                       v
          |              Candidate Act
          |                operation   = REJECT_APPLICATION
          |                applicant   = 81274
          |                job         = ENGINEER-42
          |                destination = HR_SYSTEM
          |                policy_ep.  = 188
          |                       |
          |                       v
          |              NON-EFFECTIVE
          |              (HR row stays PENDING)
          |                       |
          |                       v
          |              PED checks GCS (EU AI Act profile)
          |                purpose allowed?
          |                model version approved?
          |                human oversight required? YES
          |                       |
          +---- review exact act -+
          |    digest-bound approval
          |    verifier_id + role + epoch
          v
       PED issues act-bound authority
          |
          v
       HR Finality Sink (commit proxy)
          digest match?   applicant still 81274?
          approval valid? epoch 188 still current?
          authority unused?
          |
          +-- any fail --> no COMMIT
          +-- all pass --> SQL COMMIT: PENDING -> REJECTED
                           consume nonce; write finality record

If the model later substitutes applicant 91311, or changes REJECT to an unrelated WRITE, the digest no longer matches and the first approval has no authority over the second act. That is the operational meaning of act-binding.¶

7.3. Worked Operational Drawing -- Agentic Export Blocked by Destination

Section 24 is the same drawing with a different GCS. Prompt injection may still cause the model to emit the tool call. The tool server never sees an authorised invocation.¶

  Attacker content --> agent context
           |
           v
  Model emits tool call:
     EXPORT_DATA / CUSTOMER_DATABASE
     recipient=attacker.example  destination=INTERNET
           |
           v
  Sidecar / tool router wraps exact call as Candidate Act
           |
           v
  PED / EU or enterprise GCS
     purpose/data relationship  FAIL
     recipient                  FAIL
     destination                FAIL
           |
           v
  no Effectuation Authority
           |
           v
  Tool-dispatch Finality Sink
           |
           v
  tool is not invoked; records stay inside the tenant

7.4. Where the Drawing Sits on an Existing System

As developed in Section 31, the drawing does not require rewriting the model, the SaaS backend, or the database. The enforcement point is the existing consequential boundary.¶

  +------------------+     ordinary request      +------------------+
  | Existing AI /    | ------------------------> | Finality sidecar |
  | agent / app      |                           | or gateway       |
  +------------------+                           |                  |
                                                 | Candidate Act    |
                                                 | GCS validation   |
                                                 | act-bound auth   |
                                                 | sink verify      |
                                                 +--------+---------+
                                                          |
                                          pass            |           fail
                                          |               |             |
                                          v               |             v
                                 +------------------+     |     NON-EFFECTIVE
                                 | Existing backend |     |     (no forward)
                                 | CRM / payments / |     |
                                 | PLC / publish    |     |
                                 +------------------+     |

8.1. Candidate Act

A Candidate Act is a concrete proposed operation that has been computed or prepared but has not yet been allowed to create the protected external consequence. Examples include:¶

reject employment applicant 812;
transfer EUR 8,500 to account X;
publish generated image Y;
open industrial valve V17;
send document D to recipient R;
execute tool call T with arguments A;
update entitlement record E;
release biometric identification result B.

A Candidate Act SHOULD contain enough information to identify the consequential operation unambiguously.¶

8.2. Non-Effective State

A Non-Effective State is a state in which an act may exist computationally but lacks a required condition for protected effectuation. For example:¶

model generated decision
        +
decision stored in memory
        +
UI displays proposed action
        +
tool arguments prepared

        !=

protected external consequence

The system architecture MUST ensure that the protected consequence cannot be reached through an uncontrolled parallel path if the finality property is claimed for that consequence.¶

8.3. Governance Constraint Set

A Governance Constraint Set (GCS) is a machine-readable representation of constraints supplied by an authorised external governance process. A GCS may represent:¶

allowed purpose;
prohibited operation;
system identity;
permitted model version;
risk-control profile;
human-oversight requirement;
permitted target;
permitted recipient;
permitted destination;
data-scope requirement;
transparency requirement;
logging requirement;
deployment context;
jurisdiction;
policy epoch;
revocation status;
time constraint;
operational threshold;
required approval;
required attestation;
safe-state requirement.

The GCS does not determine the law. It represents an already determined policy or technical requirement.¶

8.4. Protected Enforcement Domain

A Protected Enforcement Domain (PED) evaluates the applicable constraints for the exact Candidate Act. The PED may be implemented using protected software, a security service, an operating-system component, an API gateway, a trusted execution environment, a confidential VM, an HSM, a DPU or SmartNIC, an independently administered service, a protected database, or combinations of those mechanisms. No particular hardware primitive is required by this document.¶

8.5. Protected Validation Evidence

Successful validation MAY produce protected validation evidence recording the predicates, policy epoch, Candidate Act commitment, and other relevant validation state. The evidence may be used for Finality Sink verification, traceability, dispute resolution, audit, post-market monitoring, incident investigation, or interoperability between independently operated components.¶

The evidence itself SHOULD NOT automatically function as unrestricted bearer authority.¶

8.6. Effectuation Authority

An Effectuation Authority is a narrowly scoped technical condition allowing one validated Candidate Act to proceed toward effectuation. The authority SHOULD be bound to the relevant load-bearing state. For example:¶

candidate_act_digest
AI_system_identity
workload_identity
operation
target
purpose
recipient
destination
policy_epoch
nonce
expiry
Finality_Sink_identity

Possession of the representation alone SHOULD NOT necessarily be sufficient to exercise the authority. Proof-of-possession, protected channel binding, sink binding, workload binding, or another non-bearer mechanism MAY be used.¶

8.7. Finality Sink

A Finality Sink is the enforcement boundary controlling the first protected externally usable consequence. A Finality Sink may exist at:¶

API gateway;
tool server;
database commit;
message transmission boundary;
payment endpoint;
operating-system interface;
network egress;
file-release interface;
robotic controller;
industrial control interface;
publication service;
cloud service;
recipient-side service.

It is a functional boundary, not necessarily a separate physical appliance.¶

28.1. Emergency Revocation and Recovery Keys

A policy profile SHOULD identify which principal holds revocation authority, since possible triggers -- a discovered model vulnerability, a key compromise, a security incident, a regulatory recall, a court order, provider compromise, an unsafe policy, or a human-initiated emergency shutdown -- can arise from different sources with different urgency. A revocation object can carry a policy identifier, the revoked epoch or epoch range, its scope, its effective time, a reason code, the revoking authority, and a signature. Finality Sinks MUST obtain revocation state with a freshness appropriate to the deployment's assurance profile, and any offline or bounded-offline mode (Section 44.3) MUST define an explicit maximum revocation-staleness window rather than leaving revocation propagation unbounded.¶

A particular failure mode deserves separate treatment: if the policy-signing key itself is compromised, that key cannot be trusted to revoke itself. High-assurance deployments therefore SHOULD provision an independent recovery path -- for example, a threshold of independent principals such as a regulator key, an enterprise root key, and a separate recovery key -- so that ordinary policy updates and emergency revocation do not depend on the same single key. Without an independent recovery authority, compromise of the sole signing key can become terminal to the deployment's ability to revoke.¶

31.1. Legacy-System Compatibility

The architecture does not require replacement of the AI model, enterprise application, SaaS platform, database, or external API. A deployment can insert enforcement at an already existing consequential boundary. For example:¶

Existing AI / Application
          |
          v
Existing API / Tool Call
          |
          v
Execution-Finality Sidecar or Gateway
          |
          v
Existing Backend

The execution-finality component can therefore operate as an API gateway, reverse proxy, service-mesh component, tool router, sidecar, database proxy, message gateway, payment gateway, operating-system mediator, network egress control, or recipient-side verifier.¶

The legacy application need not understand the complete internal representation of the Candidate Act, Protected Validation Evidence, Effectuation Authority, or Finality Sink state. It may continue to issue a normal operation request. A gateway can transform that request into a Candidate Act, perform protected validation, and either allow the operation to be forwarded or deny and withhold it. This permits gradual adoption.¶

31.2. Sidecar Deployment

A practical transitional deployment may use a sidecar or gateway. For example:¶

+----------------------+
| Existing AI Service  |
+----------------------+
           |
           | ordinary API request
           v
+----------------------+
| Finality Sidecar     |
|                      |
| Candidate Act        |
| policy validation    |
| act binding          |
| finality verification|
+----------------------+
           |
           v
+----------------------+
| Existing SaaS / API  |
+----------------------+

No modification to the remote SaaS platform is required if the sidecar controls the only permitted egress path to that service.¶

The important condition is not whether the backend is legacy. The important condition is whether the protected consequence can bypass the enforcement point.¶

31.3. Incremental Adoption

A deployer does not need to migrate every system simultaneously. An incremental deployment can begin with only high-consequence operations. For example:¶

Phase 1:
    payment release

Phase 2:
    external data export

Phase 3:
    high-risk AI decision commit

Phase 4:
    privileged tool invocation

Low-risk read-only operations may continue through existing paths. This avoids requiring execution-finality checks on every internal computation. The architecture is therefore not "every token, every tensor, every database read, every packet -> Finality Sink." It is "selected consequential transition -> Finality Sink."¶

31.4. Enforcement at Existing Boundaries

Most production systems already contain points where consequences become externally effective. Examples include an HTTP gateway, message broker, database COMMIT, payment submission interface, SMTP submission, file download endpoint, cloud control-plane API, operating-system privileged call, and industrial actuator interface.¶

These are natural insertion points. A legacy system may therefore retain most of its existing architecture while strengthening the boundary where the protected effect occurs.¶

31.5. Cold Path Versus Hot Path

Latency analysis should distinguish the cold path from the hot path.¶

legal / governance process
          |
          v
compiled machine-readable policy
          |
          v
runtime enforcement

canonicalize Candidate Act
        |
hash exact act
        |
check policy epoch
        |
check required predicate(s)
        |
verify approval / attestation reference
        |
verify destination and recipient
        |
verify nonce / replay state
        |
verify cryptographic binding
        |
release

31.6. Not Every Predicate Requires a Remote Call

The architecture does not require each constraint to reside on a different remote server. A logical deployment may expose an Identity Vault, Purpose State, Risk State, Jurisdiction State, and Policy State while physically implementing them inside one protected process, one confidential VM, one gateway, one HSM-backed service, or one local protected database.¶

The use of separate architectural roles does not imply multiple network round trips. This distinction is important. Logical separation is an authority and data-flow property. It is not necessarily physical separation.¶

31.7. Parallel Predicate Evaluation

Where multiple predicates are independent, implementations may evaluate them concurrently. For example:¶

                +--> identity check -------+
                |                           |
Candidate Act --+--> destination check -----+
                |                           |
                +--> approval check --------+--> decision
                |                           |
                +--> runtime-state check ---+

Total validation latency need not equal the sum of every predicate latency.¶

31.8. Cached Long-Lived State

Stable state may be cached where appropriate. Examples include approved model identity, static service identity, trusted destination list, public keys, policy structure, and service metadata.¶

However, cacheable state should be distinguished from state that must remain current. Hot-path checks may still require current policy epoch, nonce, revocation status, expiry, Candidate Act digest, current destination, required human approval, and current safety state. Thus: cache stable state, but reverify load-bearing current state.¶

31.9. Sink-Local Verification

Where latency is particularly sensitive, the Finality Sink may reside at the same boundary where the external effect occurs. For example:¶

AI workload
    |
    v
local tool router + Finality Sink
    |
    v
tool

rather than:¶

AI workload
    |
    v
remote validator
    |
    <--- network round trip --->
    |
    v
tool

Remote validation is therefore a deployment option, not a protocol requirement. Sink-local verification can reduce latency and also narrow TOCTOU exposure.¶

31.10. Precomputation Without Preauthorization

A system can perform expensive computation before effectuation. For example, AI inference, simulation, candidate generation, risk scoring, document preparation, and tool argument preparation may all occur before the Finality Sink.¶

The Candidate Act can remain non-effective during this work. Only the minimal terminal authority check must occur immediately before effectuation. This enables precomputing expensive work without preauthorising the consequence.¶

31.11. Human Oversight and Latency

Human approval may introduce seconds or minutes of delay. That delay is not protocol-processing latency. It is an intended governance condition. For example:¶

AI proposes EUR 50,000 transfer
        |
        v
human approval required
        |
        v
approval arrives 45 seconds later

The relevant cryptographic verification may still take only a small fraction of that time. Benchmarking SHOULD therefore distinguish machine-validation latency from human-decision latency.¶

31.12. Attestation and Latency

A full remote-attestation exchange may be expensive relative to a local authorization check. The architecture does not require fresh evidence generation for every Candidate Act. A deployment may instead use:¶

attestation generated at time T
        |
        v
appraised runtime state
        |
        v
short-lived trusted-state reference
        |
        v
multiple Candidate Acts

subject to appropriate freshness and revocation limits. The hot path can verify the current validity of the attested state rather than regenerating the entire attestation exchange. This allows RATS-derived trust information to compose with execution-finality without requiring a complete attestation protocol round trip for every consequential act.¶

31.13. Cryptographic Cost

Typical terminal operations may consist primarily of hashing, signature verification, proof-of-possession verification, small policy comparisons, nonce lookup, and atomic state update.¶

The cost of these operations is generally much smaller than large-model inference, database analytics, remote service calls, human review, or complex business workflows.¶

However, this document does not assert a universal latency value. Actual cost must be measured in the intended deployment.¶

31.14. Benchmarking Requirements

Implementations SHOULD report latency by stage rather than publishing only one aggregate number. For example:¶

T_candidate
T_canonical
T_policy
T_identity
T_attestation
T_approval
T_crypto
T_network
T_sink
T_commit

Useful measurements include p50, p95, p99, maximum, throughput, cache hit rate, timeout rate, failure rate, remote-validation overhead, and local-sink overhead.¶

This makes it possible to identify whether latency originates from cryptography, network distance, storage, policy evaluation, attestation, human approval, or backend service, rather than attributing all delay to execution-finality.¶

31.15. Latency Claim Discipline

This architecture does not require or guarantee sub-millisecond operation or less than 10 ms in every deployment. Such numbers are implementation-specific.¶

A local implementation using precompiled policies, local state, compact cryptographic checks, and a sink located at the protected boundary may achieve very low overhead. A distributed system requiring remote attestation, multiple jurisdictions, remote approval, or cross-region validation may incur materially higher latency.¶

Accordingly, protocol specifications SHOULD describe the required security properties while implementations report measured performance.¶

31.16. High-Frequency Control-Loop Example

The hot-path/cold-path distinction (Section 31.5) extends to high-frequency control systems, where individually running a full public-key authorization exchange for every iteration of, for example, a 20 kHz control loop would be impractical. Instead, authority can bind a time-bounded operational envelope rather than a single instantaneous command -- for example, a device identifier, a validity window, a permitted speed or torque range, a maximum per-cycle delta, a controller identifier, and a policy epoch. Local Finality logic then checks individual commands against that already-established envelope without a remote round trip per command. A controller operating within the bound remains unable to leave it without new authority, consistent with Section 8.6.¶

31.17. Materiality and Aggregation

The base protocol does not define a universal materiality threshold below which enforcement is skipped; instead, deployment profiles define which effect classes are protected (for example, internal arithmetic, model-token generation, and temporary in-memory state are typically left ungated, while an external message, a physical actuator command, a production-data mutation, or a protected-data export are typically gated). A materiality threshold that is defined too loosely creates a specific risk: an adversarial or misconfigured system could divide one consequential operation into a sequence of individually sub-threshold operations. Deployment profiles that rely on materiality thresholds SHOULD therefore also define cumulative budgets or aggregation windows over related acts, rather than evaluating each act's materiality in isolation.¶

31.18. Legacy Deployment Example

Consider an enterprise already operating an AI assistant in front of a REST API gateway in front of a CRM. A migration does not require rewriting the CRM. The architecture can become:¶

AI assistant
      |
      v
existing REST request
      |
      v
Finality middleware
      |
      +--> Candidate Act
      +--> configured policy predicates
      +--> act-bound authority
      +--> finality verification
      |
      v
existing CRM

The CRM continues to receive a conventional request. The new technical property exists because only requests that pass the finality boundary are forwarded.¶

31.19. Legacy Database Example

A legacy database application may currently perform an AI-driven SQL update such as setting an employment record's status to REJECTED. A transitional architecture can insert a protected commit service:¶

AI
 |
 v
Candidate Act
 |
 v
Finality Database Proxy
 |
 v
SQL COMMIT

The database itself need not understand the Candidate Act protocol. The proxy controls access to the protected commit credential or connection.¶

31.20. Legacy Payment Example

An existing payment system may expose a POST /payments endpoint. The architecture may be deployed as follows.¶

AI Agent
   |
   v
Candidate Act
   |
   v
Payment Finality Gateway
   |
   +-- amount permitted?
   +-- recipient permitted?
   +-- purpose permitted?
   +-- approval present?
   +-- authority current?
   |
   v
Existing POST /payments

This preserves the legacy payment API. The deployment changes who possesses authority to invoke it.¶

31.21. Main Feasibility Principle

The architecture therefore does not require new Internet architecture, new AI models, replacement of SaaS systems, replacement of databases, new processors, or full reengineering of enterprise software.¶

A practical initial deployment may require only one protected mediation point, one machine-readable policy profile, one Candidate-Act representation, one protected authority path, and one Finality Sink for a selected high-consequence operation.¶

31.22. Summary

The legacy-system objection is addressed by placing enforcement at existing consequential boundaries rather than inside every legacy component.¶

The latency objection is addressed by separating cold-path governance from hot-path effectuation and by requiring finality checks only for selected consequential acts.¶

The architecture therefore permits existing AI, existing APIs, existing applications, existing databases, and existing SaaS to remain in place while introducing a protected execution dependency at the point where a regulated or high-consequence action first becomes externally effective.¶

The relevant engineering question is therefore not "can every legacy component be rewritten to understand execution-finality?" It is "can the authority required for the protected consequence be placed behind an enforceable boundary?" Where that can be done, gradual deployment is feasible.¶

Similarly, the latency question is not "can every governance function execute at sub-millisecond speed?" It is "what is the minimum current-state and cryptographic verification required at the terminal effectuation boundary after slower governance work has already been completed?"¶

37.1. Purpose and Claim Discipline

The repository does not claim to determine legal compliance with the EU AI Act, the South Korean AI Basic Act, Japanese AI law or guidance, or any other regime. The implementation begins only after an authorised governance process has translated a selected requirement into a machine-readable constraint.¶

The implemented invariant is narrower than "the system complies with AI law":¶

An AI system may compute, recommend, plan, prepare, or propose a consequential operation, but that computation is not sufficient authority for the protected external effect. The exact Candidate Act must satisfy the configured governance predicates and must be independently verified at the Finality Sink before effectuation.¶

That distinction is the same Compute Plane / Authority Plane split stated in Section 6 and Section 46.¶

37.2. Repository Architecture

The package contains two layers.¶

• finality_ref -- hardened generic execution-finality substrate (Candidate Act, canonical digest, protected validation, act-bound capability, Finality Sink, replay consumption).¶

• ai_governance_ref -- AI-governance-specific policy, human-approval, runtime-evidence, delegation, offline, and policy-governance layer.¶

The AI layer does not replace the hardened substrate. It composes with it.¶

37.3. Languages and Runtimes

Python contains the complete executable reference path: Candidate Act construction; machine-readable governance policy; human approvals; runtime evidence; delegation bounds; offline bounded mode; signed policy updates; emergency policy-epoch revocation; policy-profile intersection; protected state transition; validation evidence; act-bound capability issuance; Finality Sink verification; replay consumption; and modelled external effects. The project is declared for Python >= 3.11. The recorded test environment used CPython 3.13.5.¶

Node.js independently verifies portable Candidate-Act canonicalisation and SHA-256 digests for AI-governance vectors, and retains the hardened generic cross-language vectors and complete sink cases. The recorded environment used Node.js 22.16.0.¶

Go independently verifies the same AI-governance Candidate-Act vectors using the vendored Unicode NFC normalisation path already present in the hardened core, and retains the generic interoperability and full sink-verification programs. The recorded environment used Go 1.23.2.¶

The complete AI-governance policy engine is presently implemented in Python. This release does not claim that GovernanceProfile, HumanApproval, RuntimeEvidence, DelegationGrant, OfflineEnvelope, ProfileUpdate, or RevocationNotice are already standardised cross-language protocol objects. A standards-track profile would need normative representation rules, for example CBOR/CDDL/COSE or another precisely specified encoding.¶

37.4. Core Candidate Act Fields

The inherited Candidate Act binds an act identifier; act class; effect class; source/workload identity; destination; purpose; jurisdiction; policy epoch; nonce; issue time; freshness interval; sink identity; effect-boundary identity; operation scope; payload; runtime-evidence digest; authority context; and initial NON_EFFECTIVE status.¶

AI-specific load-bearing fields are carried in authority context, including operation, model identifier, target, governance-profile digest, approvals digest, runtime-evidence digest, delegation digest, offline-envelope digest, transparency-marker state, and connected/offline state. These are bound into the final Candidate digest before core authorisation. A material change to any load-bearing field produces a different digest and cannot reuse prior authority, consistent with Section 9.¶

37.5. GovernanceProfile Parameters

GovernanceProfile currently contains profile identifier; jurisdiction; policy epoch; allowed operations, destinations, purposes, and model identifiers; required human roles; approval threshold; transparency-marker requirement; runtime-evidence requirement; configured safe state; offline mode (DENY or BOUNDED); maximum offline age; maximum delegation depth; maximum actions; maximum budget; material effect classes; and absolute numeric bounds.¶

The profile digest sorts set-valued fields before hashing, to avoid non-determinism from unordered set iteration.¶

The implementation does not decide whether a system is legally high-risk, whether a practice is prohibited, whether human oversight is legally sufficient, or whether a transparency requirement applies. Those remain external determinations. The code only evaluates the supplied profile. See Section 36.¶

37.6. Deterministic Runtime Bounds

Deterministic bounds are bounds on effectuation authority, not deterministic model reasoning. The model may change its plan. If the plan changes a load-bearing field -- operation, destination, purpose, target, payload, model identity, policy epoch, or sink -- the Candidate digest changes and previously issued authority no longer applies. See Section 43.2.¶

Enforceable bounds include exact operation, destination, and purpose; approved model set; numeric actuator range; maximum action count; maximum delegated budget; maximum delegation depth; policy epoch; freshness; human-approval roles; runtime evidence; and Finality Sink identity.¶

37.7. Human Approvals

HumanApproval binds an approval identifier, approver identity, approver role, Candidate digest, policy epoch, decision, approval timestamp, expiry, verification-key identity, and signature. This is the load-bearing approval pattern of Section 16 and Section 17.¶

The default test registry uses separate deterministic HMAC keys for separate human identities. That is a test convenience, not a production identity recommendation.¶

The policy supports numeric approval thresholds and mandatory human roles. Tests cover 0-of-0, 0-of-1, 1-of-1, 1-of-2, and 2-of-2 behaviour, plus role requirements such as reviewer and supervisor. Duplicate approvers are not allowed to satisfy an independence requirement twice.¶

A cryptographically valid human approval proves only that the configured verifier authenticated the approval object under the configured key. It does not prove that the human understood the AI, was competent, was attentive, or was not coerced. If one root administrator controls human identity, role assignment, policy, verifier keys, and the sink, that administrator remains inside the trusted computing base. See Section 44.2.¶

37.8. Runtime Evidence and Relationship to RATS

RuntimeEvidence binds evidence identifier, subject/workload identifier, model identifier, runtime state, issue time, expiry, issuer identity, key identifier, and signature. The policy checks issuer authentication, subject binding, model binding, approved runtime state, future-clock skew, and expiry.¶

The reference models runtime evidence abstractly. It does not contain a production EAT/RATS verifier, TPM quote parser, GPU attestation parser, or vendor-specific TEE verifier. A RATS Attestation Result can be adapted into RuntimeEvidence after appraisal. The finality layer then asks whether the exact Candidate Act may become effective given that appraised state and the other required predicates. See Section 40.2.¶

37.9. Transparency Marker and Absolute Safety Bounds

Profiles can require a boolean transparency marker. This demonstrates making a configured publication requirement load-bearing. It does not determine whether a given output legally falls within Article 50 or an exception. See Section 20.¶

Profiles can define numeric absolute_bounds over payload fields. Example tests enforce a setting in the inclusive range 0..35. This is useful for local safety ceilings that should remain checkable even when AI reasoning is unconstrained. A compromised policy administrator who can replace the entire profile can still alter those bounds. Stronger deployments should put immutable or independently governed hard limits below ordinary policy administration. See Section 44.1.¶

37.10. Delegation, Multi-Agent Acts, and Composite Pipelines

Delegation does not automatically transfer all parent authority. Child derivation enforces that the child operation, destination, and purpose sets are subsets of the parent sets; that child budget and action allowance do not exceed the parent; and that child depth does not exceed the configured maximum. The resulting DelegationGrant binds parent Candidate digest, delegator, delegate, allowed scope, remaining budget and actions, depth, expiry, epoch, and signature.¶

Delegating computation is not the same as delegating execution authority. A sub-agent may compute without receiving external-effect authority. When a sub-agent must create a protected external effect, it requires either a new Candidate Act or a valid derived child delegation. See Section 44.4.¶

This release demonstrates digest binding and delegation. It does not implement a universal distributed workflow transaction engine. Each externally consequential boundary is independently material. Intermediate computation may remain internal. If an intermediate stage itself discloses data or invokes a consequential external tool, that stage is itself a Candidate Act. Composite atomic acts require the destination transaction system or an explicit protocol profile capable of atomic commit. See Section 44.5 and Section 30.¶

37.11. Offline and Partition Behaviour

Two modes are implemented. DENY rejects a disconnected operation. BOUNDED permits the operation only if a supplied offline envelope remains valid and the action is inside its operation, target, epoch, sink, time, and numeric bounds. There is no implicit fail-open mode. See Section 27 and Section 44.3.¶

The envelope binds profile identifier, policy epoch, sink identity, validity interval, allowed operations and targets, numeric bounds, maximum actions, maximum budget, key identifier, and signature. The hardened reference authenticates the envelope before using it. The verifier registry is separate from ordinary workload authorisation. A forged or semantically altered envelope is rejected. An offline envelope cannot learn a revocation that occurred while it was disconnected; that residual risk is bounded only by envelope lifetime, maximum offline age, local protected state, and deployment policy.¶

The generic hardened sink uses verify, then consume, then effect. That chooses at-most-once safety. If the sink consumes authority and the downstream effect fails, the same authority is not automatically retried. Exactly-once semantics require destination support such as a transaction, idempotency key, durable outbox, release-key mechanism, or coordinated state machine.¶

37.12. Policy-Profile Governance, Emergency Revocation, and Jurisdiction Intersection

GovernanceProfileRegistry separates normal profile-update verification from emergency recovery and revocation verification. A signed profile update must authenticate under an authorised update principal, bind the new profile digest, reference the current epoch as previous_epoch, and increase the epoch monotonically. See Section 44.9.¶

RevocationNotice is authenticated with a separately configurable recovery verifier registry. Tests demonstrate an independent recovery key revoking a current epoch. This addresses the failure mode in which a compromised ordinary policy-update key cannot be trusted to revoke itself. The reference does not implement distribution latency or consensus among multiple sinks. Production profiles must define revocation dissemination and maximum tolerated staleness. See Section 28.1.¶

Profile intersection demonstrates one safe technical operation for compatible constraints: intersection of allowed operations, destinations, purposes, models, and numeric ranges. If the resulting intersection is empty or numeric bounds conflict, the function raises a conflict rather than silently choosing the most permissive policy. This is not a conflict-of-law resolver. See Section 42.3.¶

37.13. Authority-Plane Compromise, Insiders, and Anti-Bypass

The reference assumes the configured Authority Plane signer is trusted for the authority it is allowed to issue. If that signing key is fully compromised, an attacker may produce cryptographically valid authority. Finality Sink verification cannot infer that the legitimate key holder is malicious. Higher-assurance mitigations include splitting policy author and authority issuer; independent approval identities; threshold signatures; HSM/TEE-protected keys; independently governed emergency revocation; local sink hard bounds; audit and receipt verification; and minimised privilege. These are mitigation patterns, not properties fully implemented by a single Python process. See Section 44.1.¶

The software tests demonstrate that an AI workload cannot manufacture a valid approval or runtime-evidence signature without the configured key. They do not demonstrate resistance to an administrator who can replace the verifier registry, modify source code, extract all keys, or invoke the backend through an alternate privileged path.¶

A correct Finality Sink does not provide protection if the AI workload can instead use a raw network socket, direct database credentials, another message broker, a secondary SaaS credential, a vendor maintenance interface, a DMA path, a debug renderer, an admin API, or another actuator bus. Complete mediation of the protected effect remains the strongest deployment condition. See Section 38.¶

37.14. Legacy Deployment and Assurance Profiles

The architecture may be inserted at an existing consequential boundary: REST or API reverse proxy or tool gateway; database commit proxy holding the only write credential; broker publishing gateway; renderer or publisher release boundary; industrial controller or actuator gateway; network egress proxy, UPF, or SmartNIC; or OS privileged syscall or tool mediator. Legacy compatibility is conditional on exclusive control of the protected effect path. See Section 31.¶

Four conceptual assurance levels are documented: L0 cooperative software-library mediation; L1 separate gateway with durable replay state and exclusive backend credentials; L2 HSM, TEE, or confidential-VM protected keys and policy state; L3 hardware or I/O-bound mediation at the physical, network, or device release path. These profiles are not formal certifications. See Section 44.8.¶

37.15. Cold Path, Hot Path, and High-Frequency Loops

Operations that should normally be amortised on the cold path include legal or policy interpretation, risk assessment, policy compilation, model approval, identity enrolment, key establishment, full certificate-chain validation, attestation setup, destination registration, trust-anchor establishment, and policy distribution.¶

The local effectuation hot path is intended to contain only current load-bearing checks: canonicalise and hash the Candidate Act; compare policy epoch; compare operation, purpose, and destination; verify required approval and runtime references; verify act-bound cryptographic authority; verify sink identity; verify nonce and replay state; consume or reserve authority; and release the effect. See Section 31.5.¶

The architecture applies to selected consequence-bearing transitions. It does not require a Finality Sink check for every model token, tensor operation, CPU instruction, packet, database read, or internal memory update.¶

For very high-frequency industrial loops, a short-lived protected operating envelope may be authorised rather than performing remote public-key governance for every micro-step. The local sink then checks each command against that envelope. Leaving the envelope requires new authority. The reference models bounded offline envelopes; it does not implement a real-time controller or prove deadlines on embedded hardware. See Section 31.16.¶

37.16. Benchmark Methodology and Recorded Local Results

The AI-specific benchmark measures four local paths: governance policy validation; governance binding plus protected authority issuance; governance issuance plus sink verification; and governance issuance plus sink verification plus modelled storage effect. Each path uses 1000 warm-up iterations, 3000 measured iterations, time.perf_counter_ns(), synthetic Candidates, local in-process policy, HMAC-SHA256 reference authentication, in-memory state, and no network round trip.¶

Recorded environment: CPython 3.13.5; Linux 6.18.35 x86_64 glibc 2.41; user-space reference process. Recorded means were approximately 3.8 us for governance policy validation, 1.03 ms for governance plus core authority issuance, 1.68 ms for sink verify after governance, and 1.86 ms for the full modelled path. Corresponding p50 values were approximately 3.7 us, 0.93 ms, 1.29 ms, and 1.72 ms. Large maximum outliers are retained rather than hidden. This is one reason the implementation does not claim deterministic real-time behaviour from CPython.¶

Illustrative engineering stress targets retained in the repository include 100 us embedded safety-envelope, 500 us accelerator or device-local, 1 ms telecom or network-egress, 2 ms API or tool-gateway, 5 ms database or message-commit, 10 ms high-consequence workflow, 20 ms cross-region governance, and 50 ms audit-heavy or human-assisted machine-path targets. These are engineering stress targets, not measured guarantees and not requirements taken from the EU AI Act, IETF, 3GPP, a medical standard, or a payment network. The recorded Python reference does not reliably meet the 100 us or 500 us classes. Those profiles require a different implementation technology and controlled hardware benchmarking.¶

The recorded benchmark excludes WAN latency, real HSM operations, full X.509 chain building, fresh RATS evidence acquisition, TPM/TEE/GPU attestation acquisition, human decision time, real database commit, real industrial actuator timing, real telecom forwarding, real medical EHR latency, OS scheduling control, and isolated-core or real-time kernel guarantees. See Section 31.14 and Section 31.15.¶

37.17. Tests, Coverage, and Hardening Corrections

The repository records a final clean collection of 727 Python tests, of which 246 are AI-governance-specific and 481 are inherited hardened execution-finality tests, all passing in the hardened run. Combined measured Python package coverage is recorded as 1059 statements exercised of 1059 (100% measured statement coverage across src/finality_ref and src/ai_governance_ref). The AI-specific layer is independently recorded at 335 of 335 statements exercised. Statement coverage is a test-coverage metric, not a security proof. It does not establish complete threat coverage, real deployment non-bypassability, legal compliance, or absence of unknown defects.¶

The 246 AI-specific tests cover allowed and forbidden operations, destinations, purposes, model identifiers, jurisdictions, policy epochs, transparency marker, approval thresholds, mandatory human roles, duplicate approvers, signed approval mutation, runtime-evidence freshness, signed runtime-evidence mutation, absolute safety bounds, delegation subset constraints, delegation budget, action and depth, offline modes and numeric bounds, post-authorisation mutation, five end-to-end sector scenarios, signed policy updates, emergency revocation, multi-profile intersection, a 10-sector policy matrix, dynamic-plan digest changes, invalid approval signatures not counting toward thresholds or required roles, semantically invalid but correctly signed approvals not counting toward thresholds, delegation parent-Candidate binding and delegate identity, delegation signature/scope/epoch/expiry/action/budget negative matrices, mandatory offline-envelope authentication, offline profile/sink/epoch/age/window/action/budget constraints, invalid action-cost and budget-cost types, and governance denial before capability return.¶

End-to-end modelled scenarios include employment record rejection, AI-generated publication, industrial valve command, data export and tool use, and clinical record write. The effectors are software simulations. They demonstrate control flow and state-machine properties, not physical non-bypassability.¶

Five AI-governance Candidate vectors -- employment rejection, industrial valve, publication marker, clinical record, and a decomposed-Unicode purpose/identifier case -- are independently hashed by Python, Node.js, and Go (5/5 PASS in the recorded Node and Go runs). A second cross-language set contains five governance objects: a governance profile, unsigned human approval, unsigned runtime evidence, unsigned delegation grant, and unsigned offline envelope. Python generates canonical SHA-256 and HMAC-SHA256 expectations; Node.js and Go independently canonicalise and verify both digests (5/5 PASS recorded). The test HMAC key is deliberately published and is only an interoperability vector. The generic inherited package additionally retains positive interoperability vectors, canonicalisation conformance cases, and baseline/Unicode Finality-Sink verification in both Node and Go.¶

Cross-runtime Unicode data versions differ. The portable profile is deliberately narrow and tests a defined repertoire. This is not exhaustive proof of equivalence for every future Unicode code point. A standards-track representation should pin a normative normalisation version or repertoire, or use a representation that avoids the ambiguity.¶

The package was re-reviewed after the first AI-governance test pass. Two issues were treated as security defects rather than documentation footnotes. First, an approval with an invalid signature must never count toward an approval threshold or a required-role set; the policy maintains a separate set of valid approvals and counts an approval only after signature, Candidate binding, epoch, decision, future-skew, and expiry checks all succeed. Tests prove that a forged supervisor approval cannot satisfy a 2-of-2 rule or a supervisor role requirement. Second, bounded offline operation must not trust an unauthenticated envelope; the policy requires an offline-envelope verifier and rejects an invalid signature before accepting offline semantics, and additionally checks profile identifier, policy epoch, Finality Sink, validity window, maximum offline age, operation, target, action ceiling, budget ceiling, and configured numeric bounds. The delegation path was tightened so a child grant must bind to the parent Candidate digest carried in the child Candidate context, preventing a valid delegation artefact from being silently transplanted to an unrelated parent chain.¶

37.18. Data Protection, Liability, and External Frameworks

The reference does not require a public immutable ledger and does not put production personal data into one. Production evidence should minimise personal information and may separate a long-lived integrity commitment, retention-controlled metadata, a subject lookup mapping, and encryption keys. A hash is not automatically anonymous. See Section 39.1.¶

This reference does not implement a GDPR data-subject request engine, retention scheduler, legal-hold engine, or cryptographic-erasure workflow. Those functions belong to deployment-specific data-governance systems.¶

The protocol does not allocate legal liability. A receipt can provide technical facts such as Candidate digest, policy epoch, evidence reference, approval state, authority issuer, sink identity, effect status, and timestamp. Those facts may support accountability; they do not determine civil, criminal, administrative, professional, contractual, or regulatory liability. Conformance is not a safe harbour and is not a liability shield. See Section 44.6.¶

Execution finality is complementary infrastructure, not a replacement for ISO/IEC 42001, NIST AI RMF, IEEE 7000-series work, RATS/EAT, WIMSE, OAuth/DPoP, SCITT, or sector conformity regimes. The finality layer asks a narrower question: given the required inputs, may this exact Candidate Act become externally effective now? See Section 40 and Section 44.7.¶

37.19. Fail-Closed Semantics and Residual Limitations

For connected high-consequence operations, unknown or missing required state is deny or hold, not allow. The implementation can return specific reasons such as POLICY_STALE, DESTINATION_NOT_ALLOWED, MODEL_NOT_APPROVED, TRANSPARENCY_REQUIREMENT_MISSING, RUNTIME_NOT_TRUSTED, APPROVAL_THRESHOLD_NOT_MET, DELEGATION_DEPTH_EXCEEDED, and OFFLINE_NOT_ALLOWED.¶

Fail-closed control increases availability sensitivity. An attacker who can suppress policy, evidence, revocation, or approval dependencies may prevent legitimate effects. Bounded offline modes, local caches, redundancy, and safe-state design can mitigate this; none removes the trade-off.¶

Reference HMAC keys are deterministic test keys and must not be used in production. A Python process cannot protect itself from an administrator who can modify its memory, patch its code, replace keys, or bypass it at the OS or hardware layer. A fully compromised sink controlling the protected effect can violate the finality property. A valid Finality Authority does not prove the AI recommendation is correct. A valid human approval does not prove the human decision was correct or legally sufficient. No test in the repository proves compliance with the EU AI Act or another law. No benchmark proves real-time industrial deadlines, telecom line-rate performance, GPU or DPU hot-path performance, hospital EHR performance, or cross-region regulatory latency. AI-specific governance objects are not yet standardised protocol objects.¶

37.20. Falsification Criteria and Correct Interpretation

A claimed deployment should be considered incomplete if, for a protected effect, any of the following is true:¶

1. the effect can bypass the Finality Sink;¶

2. a modified Candidate can use old authority;¶

3. a stale or revoked epoch is accepted contrary to policy;¶

4. a copied authority can be replayed where single-use is required;¶

5. a required human approval can be omitted without rejection;¶

6. a sub-agent can broaden delegated authority;¶

7. offline failure silently becomes unrestricted allow;¶

8. conflicting profiles silently select the most permissive rule;¶

9. the sink trusts caller-supplied sink identity instead of local identity;¶

10. the implementation claims legal compliance solely because technical conformance passed.¶

The reference demonstrates an executable and adversarially tested mechanism for making selected machine-readable AI-governance constraints load-bearing before a protected external effect. It does not demonstrate that law has been reduced to code, that every AI risk can be made deterministic, that privileged insiders are eliminated, that all distributed effects are atomic, or that software alone makes a deployment non-bypassable.¶

The strongest supportable claim remains: the exact Candidate Act can be kept non-effective until configured, independently verifiable technical predicates are satisfied and a Finality Sink controlling the relevant consequence accepts the act-bound authority.¶

39.1. Erasure Rights and Immutable Finality Evidence

The architecture does not require personal data to be permanently written to an immutable ledger. Regulation (EU) 2016/679 (GDPR) Article 5 requires data minimisation and storage limitation, and Article 17 provides a right to erasure subject to specified exceptions, including legal-obligation and legal-claims grounds; the erasure right is accordingly not absolute, but nor is retention unconstrained. A Finality Receipt design SHOULD therefore separate a minimal, long-lived integrity commitment (a receipt identifier, policy epoch, sink identifier, effect class, an opaque commitment, and a timestamp) from subject-related event metadata (person identifiers, clinical or transactional detail, destination detail, and approval explanation), which is held under an ordinary retention-controlled and erasable store rather than an immutable one.¶

A digest is not automatically anonymous. It would be incorrect to conclude that storing only a cryptographic hash removes a record from the scope of data-protection law: if a digest can be linked back to a person using available auxiliary information, it may remain personal or pseudonymous data. Deployments SHOULD therefore prefer opaque random identifiers, keyed commitments, encrypted metadata, separated lookup tables, purpose-limited access, and defined retention schedules over placing deterministic hashes of predictable personal identifiers into a durable or public ledger.¶

Where subject-related metadata is encrypted under a per-subject or per-record key, erasure can be effected by deleting the metadata, destroying the corresponding key, and removing the subject mapping. This form of cryptographic erasure is not, by itself, a complete compliance mechanism: it is effective only if all copies of the metadata are so encrypted, the key is genuinely and completely destroyed, no alternative key or plaintext backup survives, and the remaining integrity commitment cannot independently identify the subject. Over-aggressive anonymisation creates the converse problem, in which a controller cannot locate records relating to a data subject in order to respond to an access, rectification, or restriction request. A deployment therefore needs an explicit lifecycle for subject-linked operational records: a defined retention period during which access, rectification, and restriction remain possible, followed by erasure or continued retention where legally justified, leaving only the minimal residual integrity evidence described above. Long-lived integrity evidence of the kind described in this document does not require a public or append-only ledger; a privately held, access-controlled commitment store satisfies the same architectural role.¶

40.1. WIMSE -- Workload Identity in Multi-System Environments

WIMSE addresses workload identity, authentication, and fine-grained least-privilege access across multiple service environments.¶

This is directly relevant to agentic AI deployments in which an AI agent, tool router, gateway, model-serving workload, or downstream service operates as an identifiable workload across multiple systems.¶

A WIMSE workload identity or associated workload credential MAY therefore establish predicates such as:¶

workload_id
service_identity
authenticated_peer
workload_key
credential_binding
execution_context

for protected Candidate-Act validation. However:¶

TRUSTED WORKLOAD IDENTITY
        !=
AUTHORITY FOR EVERY ACT
THAT WORKLOAD CAN GENERATE

For example, authentication of workload = ai-agent-17 does not itself establish that the following is authorised.¶

operation   = EXPORT_CUSTOMER_DATABASE
recipient   = external-party
destination = public-internet
purpose     = CUSTOMER_SUPPORT

Execution-finality therefore uses workload identity as a potentially load-bearing input while binding effectuation authority to the exact Candidate Act. The relationship can be expressed as follows.¶

WIMSE
    establishes or conveys
    workload identity/context
            |
            v
Candidate Act
            |
            v
Protected Enforcement
            |
            v
Finality Sink

WIMSE and execution-finality therefore solve different but complementary problems.¶

WIMSE:
    Which workload is participating
    in the multi-service interaction?

EXECUTION FINALITY:
    May this exact act from that workload
    become externally effective now?

40.2. RATS -- Remote Attestation Procedures

RATS provides architecture and mechanisms through which evidence about an Attester can be appraised and converted into Attestation Results that a Relying Party can use when making trust decisions.¶

RATS evidence or Attestation Results MAY therefore provide runtime predicates to the Protected Enforcement Domain or Finality Sink. Examples include:¶

approved software measurement;
approved boot state;
approved hardware state;
approved security configuration;
current attestation epoch;
trusted execution environment state.

For example:¶

Candidate Act:
    RELEASE_HIGH_RISK_AI_DECISION

Required conditions:
    approved_model_version = TRUE
    approved_runtime_state = TRUE
    current_attestation    = TRUE

RATS may provide evidence supporting the second and third predicates. Execution-finality then determines whether the exact Candidate Act can become effective. The distinction is as follows.¶

RATS:

    Is sufficient trustworthy evidence
    available concerning this system
    or workload state?

EXECUTION FINALITY:

    Given the required evidence and all
    other applicable predicates, may
    THIS exact Candidate Act cross the
    effectuation boundary?

RATS evidence therefore MAY be consumed as protected validation input. Attestation evidence by itself SHOULD NOT automatically be interpreted as unrestricted authority to cause arbitrary external consequences.¶

40.3. OAuth

OAuth and related mechanisms can provide authorization grants, scoped tokens, proof-of-possession mechanisms, resource indicators, transaction context, and other authorization information.¶

Execution-finality does not require replacement of OAuth. An OAuth authorization MAY be one of the predicates required for a Candidate Act. For example:¶

OAuth authorization:
    workload may access payment service

Candidate Act:
    TRANSFER EUR 8,500
    from account A
    to account B
    purpose = supplier-payment

The first statement does not necessarily establish authority for the second. A deployment may therefore use the following.¶

OAuth authorization
        +
workload identity
        +
exact Candidate Act
        +
recipient/destination
        +
purpose
        +
policy epoch
        +
required approval
        +
current runtime state
        |
        v
Finality Sink

OAuth proof-of-possession mechanisms may also contribute to non-bearer behavior. The execution-finality architecture does not claim that OAuth is inherently bearer-only or incapable of fine-grained authorization.¶

The narrower distinction is that the architecture requires whatever authorization state is applicable to become a technical dependency of the exact consequential act at the protected effectuation boundary.¶

40.4. SCITT

SCITT provides interoperable mechanisms for integrity, transparency, and accountability of statements concerning digital supply-chain artifacts and related information.¶

SCITT receipts or other integrity-protected statements MAY therefore provide evidence relevant to Candidate-Act validation. For example, a deployment might require evidence that the following corresponds to an approved or registered state before allowing a protected operation.¶

model artifact M
policy bundle P
software component S

Such evidence can become a validation predicate. However:¶

VERIFIABLE EVIDENCE
        !=
EFFECTUATION AUTHORITY

A transparency receipt demonstrating that a particular artifact or statement exists does not by itself determine whether a consequential Candidate Act should execute. Execution-finality therefore treats such evidence as input to the decision rather than unrestricted authority.¶

40.5. TLS

TLS protects communication confidentiality, integrity, and peer authentication according to the selected authentication profile.¶

A secure TLS connection to payments.example establishes an important channel-security property. It does not by itself determine whether a transfer of EUR 50,000 is an authorised consequential act. Accordingly:¶

SECURE CHANNEL
        !=
AUTHORITY FOR CONTENT
TRANSMITTED OVER CHANNEL

TLS remains necessary in many deployments while operating below the execution-finality decision.¶

40.6. HSMs, TEEs, Confidential Computing, and Protected Hardware

HSMs, TEEs, confidential VMs, DPUs, SmartNICs, secure enclaves, and related mechanisms can protect keys, policy state, measurements, validation logic, counters, revocation state, and effectuation secrets.¶

The execution-finality architecture does not require a particular hardware technology. Instead, these technologies MAY strengthen implementation of the Protected Enforcement Domain, Protected Validation Evidence, Effectuation Authority, and Finality Sink.¶

A hardware security boundary therefore provides a mechanism for protecting the enforcement function. It is not itself the semantic definition of execution-finality.¶

40.7. ISO/IEC 42001

ISO/IEC 42001 is an AI management-system standard concerned with establishing, implementing, maintaining, and continually improving an organisational AI management system. Execution-finality operates at a different level: ISO/IEC 42001 addresses organisational governance, risk management, processes, and responsibilities, whereas execution-finality addresses runtime enforcement of selected machine-verifiable controls at consequence boundaries. It is therefore better positioned as complementary technical infrastructure than as a competing management-system standard. For example, an organisation may determine through its management system that deletion of production data requires two approvals; execution-finality can make that selected control technically load-bearing by treating the two required approvals as predicates of the corresponding Candidate Act.¶

40.8. NIST AI RMF

NIST describes the AI Risk Management Framework as a voluntary, use-case-agnostic framework for managing AI risk across design, development, deployment, use, and evaluation. Execution-finality does not replace that lifecycle risk process. Where the framework's risk-identification and control-selection process leads an organisation to select a particular control -- for example, that external publication requires an approved destination and human authorisation -- execution-finality can enforce the machine-verifiable parts of that selected control at the Finality Sink.¶

40.9. IEEE 7000-Series

IEEE 7000 establishes processes for incorporating ethical values and requirements into system design, and other standards in the 7000 series address areas such as transparency and privacy processes. These standards operate at the level of requirements, process, and value design, whereas execution-finality operates at the level of runtime enforcement of selected effect-bearing requirements once they have already been translated into machine-readable predicates. The architecture accordingly makes no claim to implement ethics; at most it can technically enforce selected deterministic constraints derived from requirements an organisation has already adopted.¶

40.10. Composition

A consequential AI operation may therefore combine several existing IETF mechanisms. For example:¶

WIMSE
    identifies the workload

        +

RATS
    supplies trustworthy runtime evidence

        +

OAuth
    supplies authorization context

        +

SCITT
    supplies integrity/transparency evidence

        +

TLS
    protects transport

        +

Candidate-Act Binding
    identifies the exact proposed consequence

        +

Finality Sink
    verifies the required current state

        |
        v

EXTERNAL EFFECT

The architecture therefore does not propose a new replacement for identity, authentication, authorization, attestation, secure transport, or transparency protocols. It proposes a point of composition: the boundary at which the exact consequential act becomes externally effective. The resulting division of responsibility is as follows.¶

WIMSE       -> WHO / WHICH WORKLOAD

RATS        -> WHAT TRUSTWORTHY RUNTIME STATE

OAuth       -> WHAT AUTHORIZATION CONTEXT

SCITT       -> WHAT VERIFIABLE INTEGRITY /
               TRANSPARENCY EVIDENCE

TLS         -> HOW THE COMMUNICATION IS PROTECTED

FINALITY    -> WHETHER THIS EXACT ACT
               MAY BECOME EFFECTIVE NOW

The final question is deliberately act-specific. Identity is not automatically authority. Attestation is not automatically effectuation authority. Evidence is not automatically authority. A secure channel is not automatically authority. And computation of an act is not authority for that act to become externally effective.¶

41.1. Candidate Act Representation

A common representation of actor, operation, target, purpose, recipient, destination, runtime identity, policy reference, nonce, expiry, and Finality Sink.¶

41.2. Canonicalisation

A deterministic method allowing independent systems to calculate the same Candidate Act commitment.¶

41.3. Validation Evidence

An interoperable representation of protected validation results.¶

41.4. Act-Bound Authorization

A mechanism binding authority to a specific Candidate Act rather than merely to a general workload session.¶

41.5. Proof-of-Possession

A mechanism preventing a copied authorization artifact from functioning as unrestricted bearer authority.¶

41.6. Finality-Sink Binding

A mechanism ensuring that authority intended for one enforcement boundary cannot automatically be exercised at another.¶

41.7. Freshness and Revocation

Interoperable representation of nonce, epoch, expiry, revocation state, and consumption state.¶

41.8. Error Semantics

Standard reasons such as the following may improve interoperability without attempting to standardise legal interpretation.¶

ACT_MISMATCH
POLICY_STALE
APPROVAL_REQUIRED
DESTINATION_NOT_ALLOWED
AUTHORITY_REPLAY
AUTHORITY_EXPIRED
RUNTIME_NOT_TRUSTED
TRANSPARENCY_REQUIREMENT_MISSING

42.1. Comparative Landscape of Current and Emerging AI-Specific Laws

The following non-exhaustive, informational comparison illustrates that the enforcement gap this document addresses is not confined to the EU AI Act. It is provided to show the diversity and comparability of current and emerging regimes, not as a legal analysis, and it does not purport to be complete or current beyond the time of writing.¶

Whatever their differences in scope, maturity, and legal technique, each of these regimes shares the same underlying technical question this document addresses: once a governance requirement has been written down, what makes an AI system technically unable to violate it before anyone can react? The execution-finality architecture described in this document is designed to accept any one of these regimes -- or a combination of them for a system subject to more than one -- as a source of machine-readable constraints, without this document taking a position on the relative stringency, maturity, or legal status of any jurisdiction's law.¶

42.2. Jurisdiction-Specific Governance Profiles

A common protocol could therefore carry jurisdiction-specific governance profiles as inputs to the same enforcement mechanism. Conceptually:¶

                    +--> EU AI Act profile
                    |
Candidate Act ------+--> Korean AI Basic Act profile
                    |
                    +--> national sector profile
                    |
                    +--> enterprise safety profile
                    |
                    +--> contractual policy profile

                           |
                           v

                    Finality Sink

The protocol should standardise the technical enforcement mechanics. It should not attempt to harmonise the substantive law of different jurisdictions.¶

42.3. Jurisdictional Policy Conflicts

The protocol cannot resolve a genuine conflict of law, and does not attempt to. Consider a case in which one applicable profile permits a data transfer and another applicable profile prohibits the same transfer. The protocol does not invent a legal hierarchy between the two, and does not implement an implicit "most permissive profile wins" or "last profile applied wins" rule. Instead, applicable profiles are evaluated for compatibility; where their constraints can be combined, the effective authority uses their intersection (for example, if one profile permits transfer to the EU and the US and a second profile permits transfer only to the EU, the effective permitted set is the EU alone). Where the profiles are semantically incompatible rather than merely differently scoped, the Candidate Act remains in a conflict state and is not authorised by default; resolution requires human or legal determination, a regulatory determination, a contractual hierarchy, or an explicit jurisdiction-specific gateway configured by the deployment. The architecture is jurisdiction-neutral in this sense: it surfaces an unresolved conflict rather than silently deciding it.¶

43.1. Can a Single Technical Enforcement Architecture Generalise Across the EU AI Act, South Korea's AI Basic Act, and Japan's AI Act?

Yes, if -- and only if -- it is implemented as a policy-neutral enforcement substrate rather than as an encoding of any one jurisdiction's substantive law. The architecture MUST NOT claim to implement EU law, Korean law, or Japanese law. It instead exposes machine-verifiable policy inputs (policy_profile_id, jurisdiction, policy_epoch, applicable_risk_class, required_human_approval, required_documentation_state, and comparable fields), and a deployment operating under one regime populates those inputs differently from a deployment operating under another, as illustrated in Section 42.2.¶

The invariant that generalises is the Candidate Act / Non-Effective State / policy validation / Finality Sink transition described throughout this document, not the substantive content of any policy profile. As stated in Section 36, this document takes no position on whether a given profile is legally sufficient under any specific regime; that determination remains outside the protocol.¶

43.2. What Do "Deterministic Runtime Bounds" Mean in Practice for an Agentic System That Uses External Tools and Dynamically Changes Its Plan?

Deterministic runtime bounds do not require deterministic AI reasoning. An agent MAY revise its plan, invoke different tools, abandon a strategy, delegate to another agent, or reorder tasks; the architecture does not attempt to predict or freeze the internal reasoning path. What is bounded is which load-bearing attributes of a proposed act -- destination, tool class, operation, parameter range, data classification, recipient, purpose, and the other fields enumerated in Section 8.1 -- are covered by an existing, act-bound authority.¶

Section 24 demonstrates this for a prompt-injected export attempt: the model may generate the tool call, but the Candidate Act it produces is evaluated independently against purpose, recipient, and destination predicates, and no effectuation authority issues when any predicate fails. The same principle applies when the change of plan is benign rather than adversarial: a material change to a load-bearing attribute (for example, a coding agent's plan changing from creating a pull request to deploying directly to production) produces a materially different Candidate Act, and the prior authority does not travel with it. The agent may change its plan; the authority does not silently expand with it.¶

43.3. How Does Execution-Layer Enforcement Interact with Existing Human-in-the-Loop Requirements Under the EU AI Act's High-Risk Provisions?

Execution Finality is designed to complement Article 14 human oversight, not to replace it. As described in Section 16, a UI pattern in which a human presses "approve" provides strong technical assurance only if the underlying execution path actually depends on that approval. The architecture makes the approval load-bearing by binding it to the exact Candidate Act digest -- operation, target, purpose, destination, policy epoch, approver identity, and approver role -- so that an approval for one act cannot be reused, substituted, or silently carried over to a materially different act after the AI system revises its proposal. Section 17 extends this to the Article 14(5) case requiring more than one human verification.¶

This binding has a stated limit. A signed approval establishes who approved what, under which role, and when; it does not establish that the human understood the model output, was adequately trained, was attentive, or exercised sound professional judgement. Those remain governance, organisational, and legal questions that this document does not claim to resolve.¶

43.4. Who Would Audit Compliance with a Runtime Enforcement Standard -- the AI Developer, a Third-Party Auditor, or the Regulatory Body?

Responsibility is not assigned to a single party; it is distributed by layer, consistent with how the AI Act itself allocates provider and deployer obligations. The developer or provider is responsible for implementation conformance testing, canonicalisation and authority-binding tests, and technical documentation. The deployer or operator is responsible for selecting the applicable policy profile, assigning human oversight, protecting the Finality Sink, and maintaining revocation state. An independent auditor or conformity body can perform adversarial testing -- Candidate-Act mutation, scope expansion, destination substitution, replay of a consumed authority, and human-approval substitution -- each of which MUST produce a reject outcome in a conformant implementation. A regulatory or supervisory authority inspects evidence, logs, finality receipts, and conformity results, and may commission independent testing where legally authorised. A standards organisation defines syntax, semantics, and conformance tests; it does not determine which regulator has jurisdiction or which profile is legally sufficient, consistent with Section 36.¶

Protocol-level conformance alone is not sufficient. As noted in Section 38, an implementation can correctly reject every invalid Candidate Act and still fail architecturally if the protected effect can reach its destination by a path that bypasses the Finality Sink. Any audit therefore also needs to cover the consequence topology described in that section, not only the validation logic itself.¶

The reference implementation described in Section 32 currently demonstrates the underlying conformance primitives -- act-bound authorization, policy-epoch and nonce checks, replay protection, and fail-closed validation -- against which several of these audit tests could be run today. It does not yet include a packaged negative-test conformance suite, human-approval-binding predicates, or multi-jurisdiction profile switching; see Section 35. Standardising such a conformance-test suite is listed as part of the potential IETF standardisation surface in Section 41.¶

44.1. Protection of the Authority Plane

The Authority Plane is not inherently trustworthy merely because it is designated as such. If a single entity controls policy definition, policy signing, authorization issuance, authorization keys, approval-role configuration, evidence-verifier configuration, revocation state, and Finality-Sink configuration, compromise or malicious control of that entity can undermine the architecture as a whole: a compromised Authority Plane can issue a cryptographically valid Finality Authority for an operation that should never have been authorised, and the Finality Sink cannot necessarily distinguish such an authority from one legitimately issued under valid policy. This is an unavoidable trusted-computing-base limitation; processor hardware, firmware, trusted execution environments, attestation systems, certificate authorities, and key-management infrastructure remain part of the residual trust boundary described in Section 38.¶

A high-assurance deployment SHOULD therefore avoid treating the Authority Plane as a single undifferentiated security principal, and instead separate policy-definition authority, policy-signing authority, runtime-evidence authority, human-approval authority, the Finality-Authority issuer, revocation authority, the Finality-Sink operator, audit authority, and recovery authority across distinct principals. For particularly sensitive deployments, authority issuance MAY require a threshold, such as 2-of-3 or 3-of-5 independent signers (for example, an enterprise policy authority, a regulated operator, and an independent trust service), rather than a single signing service. The architecture SHOULD support both single-authority and multi-authority/threshold deployment without claiming that the two provide equivalent assurance.¶

A related but distinct failure mode is misconfiguration rather than compromise: a cryptographically valid, correctly signed policy is not thereby a correct policy (for example, an intended maximum actuator setting of 60% mistakenly configured as 600%). Production deployments therefore need policy-change controls such as schema and semantic validation, policy linting, four-eyes review, test vectors, staged deployment, simulation, canary enforcement, rollback, versioning, and change audit. A policy engine SHOULD also allow specification of absolute invariants that an ordinary policy update cannot override (for example, an absolute maximum pressure that no operational policy may authorise exceeding), so that the Finality Sink retains a narrow set of locally enforced safety constraints even where an upstream policy is mistakenly over-permissive.¶

If every independent authority, recovery mechanism, root key, and Finality Sink relevant to a given act is compromised simultaneously, the architecture cannot manufacture trust from nothing. The defensible claim is accordingly narrower than "the system cannot be compromised": execution finality reduces discretionary authority above the effectuation boundary; it does not eliminate the trusted computing base.¶

44.2. Insider Forgery of Human Approval

A human-approval predicate provides limited assurance if the same administrator can create the human identity, assign the approval role, replace the verification key, modify the approval database, change the required approval count, disable the predicate, and control the Finality Sink; in such a deployment, "human approval required" may be no more than a configuration convention. A threat model applied to this architecture SHOULD therefore distinguish, at minimum, an external attacker, a compromised AI workload, a compromised application or service, an ordinary authenticated operator, a privileged deployer administrator, an Authority-Plane administrator, a human-identity administrator, a key-management administrator, a Finality-Sink administrator, a hypervisor/root/platform administrator, and a hardware or firmware root-of-trust compromise, since these actors possess materially different powers. A claim that human approval cannot be forged is accordingly too strong; the defensible claim is that, under the configured trust model, possession of workload authority alone is insufficient to manufacture the required, independently authenticated human approval.¶

A stronger human-approval binding combines a hardware-backed user credential, an authenticated human identity, a role assertion, the Candidate-Act digest, the approval decision, the applicable policy epoch, a timestamp, a freshness bound, and an approval nonce, verified against an identity source that is administratively separated from the workload itself. For higher assurance, the AI operator, the human-identity administrator, the policy administrator, and the Finality-Sink administrator SHOULD be distinct principals. Where a single root administrator nonetheless controls all of those trust domains, software cryptography alone cannot reliably distinguish that administrator from the legitimate system, and the architecture does not claim otherwise.¶

44.3. Finality-Sink Failure, Network Partition, and Loss of Connectivity

Implicit fail-open behaviour is excluded by Section 27. An unconditional "fail closed everywhere, indefinitely" rule is nonetheless too simple for every deployment, since in some safety-critical systems a failure to act can itself cause harm. The architecture therefore accommodates explicit, distinct deployment profiles rather than one universal connectivity behaviour.¶

Under a strict connected profile, appropriate for high-consequence operations requiring current remote authority (for example, privileged account creation, high-risk data export, a production configuration change, release of a controlled medical record, or a large infrastructure reconfiguration), unavailability of current authority leaves the Candidate Act NON-EFFECTIVE. Under a pre-issued bounded-offline profile, a deployment MAY permit a previously issued, narrowly scoped local authority (bound, for example, to a specific device, a permitted parameter range, a validity window, a maximum operation count, and a policy epoch, with offline use explicitly permitted) to remain usable during a network partition, provided it carries explicit restrictions -- a short maximum lifetime, a maximum offline age, a maximum use count, local monotonic consumption state, and a fixed sink, object, purpose, parameter envelope, and policy epoch -- because the sink cannot otherwise know whether the authority has since been revoked elsewhere. Under an emergency safe-state profile, certain systems distinguish an ordinary autonomous operating range, a narrower offline-safe range, and a set of emergency safety actions that remain locally permitted regardless of connectivity, rather than treating loss of connectivity as a reason to permit unrestricted local authority.¶

A Finality-Sink crash during effectuation also creates a transactional problem distinct from connectivity loss. If authority is consumed before the crash and the protected effect never occurs, the reference architecture favours at-most-once safety; if the effect occurs before authority is marked consumed and the sink then crashes, the authority may remain reusable and a duplicate consequence may occur. Systems requiring stronger transactional semantics need to integrate with the destination's own idempotency or transactional mechanism; this document does not claim that an arbitrary external request can be made exactly-once merely by validating it locally, consistent with Section 30.¶

44.4. Delegation Between Agents

A sub-agent receiving a delegated task should not automatically inherit the delegating agent's unrestricted authority; doing so would reintroduce transitive bearer authority and turn delegation into an authorisation bypass. Delegation instead produces either a new Candidate Act or a cryptographically derived child authority with narrower rights than its parent, subject to invariants such as: the child's scope is a subset of the parent's scope; the child's lifetime does not exceed the parent's remaining lifetime; the child's budget does not exceed the parent's remaining budget; and the child's permitted destinations are a subset of the parent's permitted destinations. A delegation MAY additionally bind the parent authority, the delegating agent, the receiving agent, the delegation purpose, the permitted tool, a maximum delegation depth, a maximum fan-out, the remaining quota, and the applicable policy epoch.¶

Where one agent invokes a third-party model purely to compute a result that is returned as text, no external operational authority need be delegated to that third-party model, which can remain within the Compute Plane described in Section 6. Where the third-party service is itself capable of causing an external effect (sending a message, writing to a database, controlling a device, or publishing content), that capability requires its own Finality treatment under this architecture rather than inheriting authority through the calling agent. The governing principle is that delegating computation does not automatically delegate execution authority.¶

44.5. Chained and Composite Multi-Agent Acts

In a multi-agent pipeline, authority follows the effect rather than following the agent. Consider an agent that reads a dataset and produces an internal summary, a second agent that turns that summary into a draft public report, and a third agent or publishing component that releases the report; the first two stages remain internal computational artefacts with no protected external consequence, and the Finality boundary applies at publication. The Candidate Act for publication MAY include a digest of the upstream artefacts it derives from (for example, a parent Candidate-Act digest, an input-artefact digest, a derived-output digest, and a final Candidate-Act digest) so that the published object cannot be substituted after authorisation, while provenance tracking of this kind does not itself propagate authority between stages.¶

Where an external tool or service appears in the middle of a pipeline -- for example, a call to an external search API positioned between two internal agents -- that invocation can itself already constitute an external consequence, because information is disclosed to another party at that point. The Finality boundary in such a pipeline accordingly need not sit only at the pipeline's final output; it can occur at an intermediate stage where the first genuine external disclosure occurs. Some sequences of operations belong together logically (for example, reserving inventory, issuing a shipment, and updating order state); a deployment MAY represent such a sequence as a single composite Candidate Act where the underlying transaction system can commit the steps atomically, and otherwise each consequence requires its own bounded authority together with compensation or recovery semantics. Authority for one step in a sequence does not, by default, authorise the remaining steps.¶

44.6. Liability Allocation and the Limits of Conformance

This architecture does not allocate legal liability; doing so is outside its technical scope. A harmful act mediated by a conformant implementation can arise from materially different causes -- an incorrect model output, a correct model paired with an incorrect policy, a correct policy paired with deployment misconfiguration, forged evidence, negligent human approval, a compromised authorization key, an implementation defect, a bypassed Finality Sink, a failure to revoke a vulnerable policy, or incorrect external data -- and potential actors involved can include the model developer, the application developer, the system provider, the deployer, the operator, the policy authority, the evidence issuer, the human approver, the Finality-Sink operator, the regulated organisation, and a third-party service provider. The architecture can produce evidence relevant to determining which Candidate Act existed, which policy epoch applied, which evidence was evaluated, which humans approved it, which Authority Plane issued the authority, which Finality Sink consumed it, and when the effect occurred; this can improve technical accountability without determining the legal conclusion. Specification and deployment documentation SHOULD state substantially the following: conformance with this architecture does not establish legal compliance, due care, regulatory approval, immunity, safe-harbor status, or the allocation of civil, criminal, contractual, professional, or administrative liability, which remains determined by applicable law, contract, regulatory requirement, organisational responsibility, and the facts of the particular deployment.¶

Conformance accordingly should not be described as reducing legal liability. A conformant implementation may become evidence that an organisation adopted certain controls, but it may equally produce stronger evidence of a specific failure -- for example, a Finality Receipt establishing that a policy epoch was stale, that a required human approval was absent, that an administrator overrode the sink, or that revocation had already occurred at the relevant time -- and such evidence could increase rather than reduce accountability. Technical conformance with this document is accordingly not equivalent to legal compliance, is not a liability shield, and is not a safe harbor; the architecture is more accurately described as providing technical evidence and enforcement properties than legal immunity, consistent with Section 36.¶

44.7. Relationship to Sector Certification Regimes

This architecture does not, by default, require a new certification regime. A medical system can remain subject to medical-device conformity assessment, clinical validation, and quality-management requirements; a financial system can remain subject to financial controls, operational-resilience requirements, payment-network rules, and internal and external audit. Execution finality can be assessed as one technical control operating inside those existing regimes, producing conformance evidence alongside sector certification rather than in place of it. A separate protocol-level conformance-test suite, of the kind described in Section 41, MAY still be useful to demonstrate interoperability between implementations; that is a narrower undertaking than establishing a new universal legal certification regime, and this document does not propose the latter.¶

44.8. Assurance Tiers and Organisational Scale

High-assurance deployment of this architecture has real cost, and it would be inaccurate to claim otherwise. A smaller organisation may not operate an HSM cluster, dedicated TEE infrastructure, an independent attestation system, a three-party policy authority, or a dedicated security operations centre. The architecture is intended to scale down in assurance rather than to require a single fixed deployment cost: for example, a Level 0 deployment MAY enforce through a software library or API-gateway integration; a Level 1 deployment adds a separate protected gateway with durable replay state; a Level 2 deployment adds HSM- or TEE-backed keys and authority; and a Level 3 deployment adds hardware- or I/O-bound, non-bypassable enforcement. A smaller organisation might, for example, combine an existing identity provider, a signed policy configuration, an API-gateway Finality Sink, and an ordinary relational database for replay state, which can provide meaningful protection against an AI workload without protecting against a hostile root administrator. Lower-assurance profiles MUST clearly state the weaker threat model they accept; the architecture does not eliminate the cost of high assurance, but it provides a path for selecting assurance proportionate to risk rather than requiring uniform maximum assurance for every deployment.¶

44.9. Governance of the Policy Profile

This document does not decide, globally, who is entitled to control a given policy profile; instead, each policy profile SHOULD identify its own authorised governance principals -- for example, a policy identifier, the current policy epoch, the named policy authorities (such as a hospital security function and a clinical governance function for a medical deployment), an update threshold (such as 2-of-2), and a validity interval. Updates to a policy profile are themselves authenticated governance acts; a policy administrator should not be able to overwrite policy state without provenance. A stronger model chains policy epochs through signed updates (epoch N to epoch N+1 to epoch N+2, and so forth), and the Finality Sink accepts only a monotonically current epoch or an explicitly permitted transition, consistent with Section 28.¶

44.10. Summary of Residual Limitations

The considerations in this section narrow, rather than remove, the properties claimed elsewhere in this document. The architecture does not resolve compromise of its own trust roots, an incorrect or malicious policy signed by an otherwise-valid authority, a malicious root administrator who controls every relevant trust domain simultaneously, a genuine conflict between applicable jurisdictions' laws, incorrect AI reasoning that never reaches a protected effect boundary, professional negligence by an approving human, or every class of distributed-system failure or data-protection obligation. What it provides is narrower and remains the core claim of this document: a technically enforced separation between the ability to compute or propose an operation and the authority required for that specific operation to become externally effective.¶

47.1. External Publications and Reference Implementation

A Commission Futurium community note presenting the same technical foundation in a European digital-sovereignty setting is [DAS-FUTURIUM-APPLY-AI], "Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance", Apply AI Alliance, at https://futurium.ec.europa.eu/en/apply-ai-alliance/community-content/protecting-europe-technical-foundation-digital-sovereignty-data-protection-and-ai-governance.¶

A published PCT application describing a hardware-rooted execution-finality system for sovereign AI infrastructure, AI-native telecommunications, and satellites is [WO2026150382], WO 2026/150382, WIPO PATENTSCOPE, at https://patentscope2.wipo.int/search/en/WO2026150382 (detail record: https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2026150382). That publication is cited for transparency of related technical disclosure. It is not an IETF document, is not a claim of IETF adoption, and is not a substitute for a BCP 79 IPR disclosure where one is required.¶

The primary AI-governance reference implementation is [DAS-AI-GOV-REFERENCE-IMPLEMENTATION], Execution-Finality Enforcement for EU AI Act and AI Governance Constraints, at https://github.com/sangmdas/Execution-Finality-Technical-Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints. The earlier privacy-substrate repository remains [DAS-REFERENCE-IMPLEMENTATION] at https://github.com/sangmdas/privacy-finality-reference, with versioned release [DAS-REFERENCE-IMPLEMENTATION-V010] at https://github.com/sangmdas/privacy-finality-reference/releases/tag/v0.1.0.¶

47.2. Related Internet-Drafts (Full Datatracker URLs)

The following Internet-Drafts share the execution-finality substrate. Each entry gives the bibliographic anchor and the full Datatracker URL.¶

• [I-D.das-purpose-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-purpose-execution-finality/¶

• [I-D.das-hardware-enforced-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-hardware-enforced-execution-finality/¶

• [I-D.das-protocols-candidate-act-finality] -- https://datatracker.ietf.org/doc/draft-das-protocols-candidate-act-finality/¶

• [I-D.das-ntn-rf-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-ntn-rf-execution-finality/¶

• [I-D.das-payment-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-payment-execution-finality/¶

• [I-D.das-precision-bounded-egress] -- https://datatracker.ietf.org/doc/draft-das-precision-bounded-egress/¶

• [I-D.das-ai-native-6g-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-ai-native-6g-execution-finality/¶

• [I-D.das-6g-query-scoped-communication-handles] -- https://datatracker.ietf.org/doc/draft-das-6g-query-scoped-communication-handles/¶

• [I-D.das-map-discovery-communication-finality] -- https://datatracker.ietf.org/doc/draft-das-map-discovery-communication-finality/¶

• [I-D.das-rats-attestation-bnd-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-rats-attestation-bnd-execution-finality/¶

• [I-D.das-child-safe-rendering-finality] -- https://datatracker.ietf.org/doc/draft-das-child-safe-rendering-finality/¶

• [I-D.das-rats-openai-anthropic-extraction] -- https://datatracker.ietf.org/doc/draft-das-rats-openai-anthropic-extraction/¶

• [I-D.das-protocols-enterprise-ai] -- https://datatracker.ietf.org/doc/draft-das-protocols-enterprise-ai/¶

• [I-D.das-rats-frontier-model-extraction] -- https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/¶

• [I-D.das-enterprise-ai-output-finality] -- https://datatracker.ietf.org/doc/draft-das-enterprise-ai-output-finality/¶

• [I-D.das-execution-finality-ai-interoperability] -- https://datatracker.ietf.org/doc/draft-das-execution-finality-ai-interoperability/¶

• [I-D.das-agentic-tool-binding] -- https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/¶

• [I-D.das-execution-finality-protocol-layer] -- https://datatracker.ietf.org/doc/draft-das-execution-finality-protocol-layer/¶

• [I-D.das-global-privacy-execution-enforcement] -- https://datatracker.ietf.org/doc/draft-das-global-privacy-execution-enforcement/¶

• [I-D.das-digital-sovereignty-finality] -- https://datatracker.ietf.org/doc/draft-das-digital-sovereignty-finality/¶

• [I-D.das-agentic-execution-finality] -- https://datatracker.ietf.org/doc/draft-das-agentic-execution-finality/¶

• [I-D.das-ot-actuation-finality] -- https://datatracker.ietf.org/doc/draft-das-ot-actuation-finality/¶

• [I-D.agentic-ai-tool-execution-finality] -- https://datatracker.ietf.org/doc/draft-agentic-ai-tool-execution-finality/¶

The umbrella vocabulary used across the family -- Candidate Act, Non-Effective State, Protected Enforcement Domain, and Finality Sink -- is collected in [I-D.das-execution-finality-protocol-layer]. Hardware-rooted and sovereign-infrastructure specialisations are developed in [I-D.das-hardware-enforced-execution-finality] and [WO2026150382]. Privacy-specific enforcement is developed in [I-D.das-global-privacy-execution-enforcement] and [I-D.das-purpose-execution-finality]. The reference implementation cited above implements the common substrate rather than every AI-Act-specific predicate in this document; see Section 35.¶