Execution-Finality for AI-Native 5G/6G and O-RAN

Introduction This document defines a focused execution-finality profile for programmable and AI-native telecommunications environments, including 5G-Advanced, future 6G/IMT-2030, O-RAN, AI-RAN, network APIs, edge functions, and autonomous network control. The problem addressed is narrower than general AI governance: an authenticated network function, controller, or AI agent may be permitted to participate in the network while lacking authority to cause every possible routing, signaling, session, resource-allocation, sensing, or subscriber-specific consequence. The standards surface is a Network Candidate Act plus a network Finality Sink at the actual enforcement boundary.

Long-Felt Need for AI-Native Network Consequence Control

FROM ACCESS SECURITY TO CONSEQUENCE SECURITY The need for execution-finality control does not arise because authentication, encryption, access control, application permissions, sandboxing, policy engines, or existing cybersecurity systems have ceased to be useful. Rather, the computing environment has changed around them. Traditional security controls primarily answer questions such as: Who may enter? Who may access this system? Who may read this information? Which application has permission? Is this device authenticated? Is this network function trusted? Is this process permitted to invoke this API? These remain important questions. Execution-finality security addresses a later and technically different question: Should this particular operation be permitted to become an actual consequence, in this state, for this purpose, at this destination, at this precision, under this policy and jurisdiction, at this moment? This distinction becomes increasingly important as software evolves from human-directed applications into interconnected, autonomous, AI-mediated systems. The security problem has therefore moved from controlling only access to controlling the transition: COMPUTATION to CONSEQUENCE.

WHY THIS LAYER WAS LESS NECESSARY A DECADE AGO A decade ago, the majority of deployed AI systems were not autonomous economic or infrastructure actors. Most systems produced informational outputs that still required another application or person to convert them into consequence. The recommendation did not itself make the payment. The prediction did not itself control the satellite. The classification did not itself alter the telecommunications network. The generated text did not normally invoke tools, operate a browser, execute a shell command, write enterprise memory, call another autonomous agent, transfer money, or modify a physical system. Accordingly, authentication, operating-system permissions, application-layer security, human review, network access controls, and conventional authorization frequently remained practical final barriers. The AI era changes this architecture. An autonomous system can now move through a chain such as: User Instruction AI Reasoning Tool Selection External API Another Agent Database Network Financial System Physical Device without necessarily returning to a human-controlled decision point before each real-world consequence. The missing boundary is therefore not another model-output filter. It is a boundary at which the system asks: "Even though this operation has been generated and upstream-approved, is it authorized to become effective now?"

THE UPCOMING 6G PROBLEM The transition to 6G makes this security problem more significant. ITU identifies the next generation of mobile communications as IMT-2030. The IMT-2030 framework includes six major usage scenarios, including Artificial Intelligence and Communication and Integrated Sensing and Communication. Current ITU work also describes expected 6G capabilities including: AI integration; distributed learning and inference; advanced sensing; object detection; localization; mapping; high-precision positioning; ubiquitous connectivity; large device density; very low latency; and interoperability across diverse systems. ITU's current IMT-2030 material discusses positioning accuracy potentially reaching approximately 1 to 10 centimetres for relevant scenarios. This remains part of the ongoing IMT-2030 technical development process rather than a statement that every deployed 6G device will necessarily provide such accuracy. Nevertheless, the architectural direction is important. The future network may know more than merely: "Device A is connected." A future communications environment may combine: communications; positioning; environmental sensing; AI; edge computation; device identity; mobility information; network telemetry; and continuous machine-to-machine interaction. This dramatically increases the value of controlling who receives precise data and what consequences AI-controlled network functions may create.

6G CAN TURN LOCATION FROM APPLICATION DATA INTO INFRASTRUCTURE DATA In today's mobile environment, location is often thought of as information obtained from GPS or another application-facing positioning interface. In an IMT-2030 environment, communications and sensing are expected to become more closely integrated. This means that the future security problem may not be limited to stopping an application from requesting a GPS API. Location or presence information may be derived from multiple infrastructure sources. For example: satellite positioning; radio measurements; network positioning; integrated sensing; device proximity; mobility state; beam information; edge observations; and AI-generated estimates. Therefore, simply removing one application's permission to invoke a traditional GPS API may not be sufficient to control the final disclosure of precise location.

AI + 6G + INTEGRATED SENSING: RISK OF COLLAPSE OF TRADITIONAL SECURITY AND PRIVACY ASSUMPTIONS The combination of AI and 6G creates a deeper architectural problem. Traditional privacy architectures frequently assume that sensitive information can be identified as particular fields: name; address; GPS coordinate; phone number; account number; medical record. Modern inference increasingly challenges this assumption. An AI system may reconstruct sensitive information from fields that individually appear non-sensitive. Future integrated sensing and communication networks may expand the quantity, precision, frequency, and variety of those signals. Without stronger consequence-level controls, this creates a risk of collapse of several traditional security and privacy assumptions. Assumption 1: "If secret data was never explicitly disclosed, the secret remains protected." AI inference weakens this assumption because a secret may be reconstructable from non-secret fragments. Assumption 2: "If an application has legitimate access to data, downstream use is safe." Autonomous agents, SDKs, cloud processors, and AI inference systems weaken this assumption. Assumption 3: "If a device or network function is authenticated, its resulting action is authorized." Agentic AI and autonomous networking weaken this assumption. Assumption 4: "If location permission was granted, precise coordinates can be treated as ordinary application data." Large-scale AI inference and integrated sensing weaken this assumption. Assumption 5: "If no conventional security breach occurred, no security-sensitive intelligence was lost." Machine inference increasingly weakens this assumption. This does not mean cybersecurity or privacy will inevitably collapse. It means that traditional access-centric security assumptions can collapse if they are relied upon without a separate control over consequence.

6G SECURITY WORK ITSELF RECOGNIZES EXPANDING TRUST BOUNDARIES This concern is consistent with current international standards work. An ITU-T security work item concerning technical security controls for IMT-2030 states that expected 6G characteristics such as native AI integration, cloud-native and edge-native architectures, network slicing, integrated sensing and communication, and heterogeneous multi-stakeholder environments significantly expand the attack surface, threat landscape, and trust boundaries compared with previous mobile generations. This is particularly relevant to execution finality. As the attack surface expands, security cannot rely only on determining whether an entity entered the system legitimately. It must also govern what that entity, agent, model, network function, or workload is permitted to cause.

THE NEW SECURITY BOUNDARY The resulting progression can be expressed as follows: EARLIER INTERNET SECURITY Protect access to the system. MOBILE SECURITY Protect applications, permissions, and sensitive information. CLOUD SECURITY Protect identities, APIs, workloads, and data flows. AI SECURITY Protect model behavior, tools, data, and autonomous workflows. AI + 6G SECURITY Protect the final transition from machine-generated computation and inference into real-world consequence.

RESULTING SECURITY PRINCIPLES The long-felt need can therefore be summarized through the following distinctions: AUTHENTICATION IS NOT FINALITY. APPLICATION PERMISSION IS NOT FINALITY. MODEL APPROVAL IS NOT FINALITY. NETWORK AUTHENTICATION IS NOT FINALITY. DATA ACCESS IS NOT DATA-EXPORT AUTHORITY. LOCATION ACCESS IS NOT PRECISE-LOCATION RELEASE AUTHORITY. TOOL SELECTION IS NOT TOOL-EFFECTUATION AUTHORITY. AI INFERENCE IS NOT EXTERNAL-ACTION AUTHORITY. 6G CONNECTIVITY IS NOT AUTHORITY FOR EVERY NETWORK CONSEQUENCE. COMPUTATION IS NOT AUTHORITY.

CONCLUSION OF THE LONG-FELT NEED The missing security control is therefore not another generic permission mechanism. The long-felt need is for a pre-effectuation, fail-closed security boundary capable of determining whether an already generated, computed, authenticated, routed, delegated, or upstream-approved operation is permitted to cross into real consequence. This becomes particularly important because modern AI can reconstruct sensitive information from ordinary data without a conventional breach, while upcoming IMT-2030/6G infrastructure is expected to increase connectivity, AI integration, sensing capability, positioning precision, and machine autonomy. In such an environment, allowing every application or AI component to obtain and externalize the most precise available information would progressively undermine both privacy and national-security assumptions. The appropriate security model is therefore not: "the application has GPS permission, therefore exact GPS may be released." It is: "the system possesses exact GPS, but exact GPS remains non-effective for external disclosure until the particular recipient, purpose, precision, destination, jurisdiction, policy state, and Finality Sink have been verified." The proposed execution-finality architecture supplies that missing control: Candidate Act to Non-Effective State to Protected Enforcement Domain validation to Protected Validation Evidence to Scoped Non-Bearer Finality Authority to Independent Finality Sink Verification to only the permitted consequence. The objective is not to prevent AI, 6G, sensing, autonomous agents, or advanced applications from using data. The objective is to ensure that increasing intelligence does not automatically become increasing authority. The final principle is therefore: COMPUTATION IS NOT AUTHORITY. AND IN THE AI AND 6G ERA: THE ABILITY TO INFER PRECISE INFORMATION MUST NOT AUTOMATICALLY CREATE THE AUTHORITY TO DISCLOSE OR ACT UPON IT.

Core Execution-Finality Protocol

Core Architectural Principle The execution-finality architecture separates computation, generation, routing, and upstream authorization from the authority required for an operation to become externally effective. The principal invariant is: A Candidate Act MUST NOT become consequence-bearing merely because it has been generated, computed, selected, routed, scheduled, delegated, authenticated, or permitted by an upstream application or AI system. A Candidate Act MUST remain in a Non-Effective State until: 1. a Protected Enforcement Domain validates the applicable act-specific predicates; 2. protected validation evidence is generated or committed;

scoped non-bearer finality authority is released;

an applicable Finality Sink independently verifies that authority; and

the finality authority and associated protected state are consumed, invalidated, advanced, or otherwise made unsuitable for unauthorized replay. This is a two-boundary architecture rather than a single authorization gate. The first boundary determines whether scoped finality authority may be created. The second determines whether the consequence may actually occur. 2.1 Terminology Candidate Act A Candidate Act is an operation that has been generated, selected, requested, staged, scheduled, routed, or otherwise prepared but has not yet been permitted to become consequence-bearing. Examples include: • an AI-agent tool call; • a function or API invocation; • a network transmission; • an exact-location export; • an AI-generated command; • a memory write; • a database commit; • a payment instruction; • a telecom control operation; • an RF transmission; • a satellite command; • an actuator signal; or • another externally effective operation. A Candidate Act MAY already be fully computed before finality authorization occurs. Computation alone MUST NOT cause effectuation. Non-Effective State A Non-Effective State is a state in which the Candidate Act may exist, be evaluated, staged, queued, hashed, transformed, or prepared, but the protected consequence cannot yet become externally effective. An implementation MUST preserve the Non-Effective State whenever a required element of the execution-finality chain is: • absent; • invalid; • stale; • expired; • revoked; • replayed; • already consumed; • act-mismatched; • scope-mismatched; • policy-mismatched; • jurisdiction-mismatched; • protected-state-mismatched; or • Finality-Sink-mismatched. The source architecture expressly requires failure at a load-bearing point to leave the Candidate Act non-effective rather than merely producing a warning or audit record. Protected Enforcement Domain A Protected Enforcement Domain (PED) is a protected validation environment that evaluates whether a Candidate Act is eligible to receive scoped finality authority. Depending on the implementation, the PED MAY be implemented using: • a trusted execution environment; • secure enclave; • HSM; • protected operating-system service; • protected network function; • secure controller; • confidential-computing environment; • hardware-assisted enforcement logic; or • an equivalent protected validation environment. The defining function is not a particular hardware product. The PED performs protected validation before finality authority is released. Protected Validation Evidence Protected Validation Evidence is evidence committed by the PED establishing the validation state associated with a Candidate Act. The evidence MAY take the form of a Ledger-Anchored Validation Receipt (LAVR) or an equivalent protected commitment. For this architecture, a LAVR is not required to use blockchain. It may instead use hashes, protected signatures, HSM or enclave signatures, MACs, sealed state, monotonic counters, timestamps, Merkle commitments, append-only protected records, secure audit registers, or equivalent protected mechanisms. External ledger or blockchain anchoring MAY be performed later on a cold path. The important requirement is: protected validation evidence MUST exist before, or atomically with, release of scoped finality authority. Scoped Non-Bearer Finality Authority A Scoped Non-Bearer Finality Authority is an act-specific enablement artifact or protected authorization state that permits a particular Candidate Act to cross a particular effectuation boundary only under its validated scope. It is non-bearer because possession alone MUST NOT be sufficient to cause effectuation. The Finality Sink MUST verify the relevant bindings before accepting it. The authority SHOULD be bound to applicable state including: • Candidate Act identity or digest; • protected validation evidence; • protected state; • nonce or freshness state; • policy epoch; • revocation epoch; • permitted scope; • permitted consequence class; • destination or resource where applicable; • jurisdiction where applicable; and • intended Finality Sink identity. An authority issued for one act, sink, scope, destination, precision level, policy state, or protected-state transition MUST NOT be reusable as authority for another consequence. Your specification expressly distinguishes this from conventional bearer credentials, RBAC decisions, risk scores, or upstream policy decisions. Finality Sink A Finality Sink is the functional boundary at which a Candidate Act would become externally, operationally, financially, physically, network-effectively, or sovereignty-effectively consequential. The Finality Sink is defined by its role, not by its product name or physical implementation. It MAY be implemented in hardware, firmware, software, virtualized logic, a protected operating-system service, cloud infrastructure, or a distributed enforcement arrangement. The determining question is: Does this component control the boundary at which the Candidate Act becomes effective? If yes, that component or arrangement can perform the Finality Sink role. A gateway, firewall, policy engine, or security module is not a Finality Sink merely because it performs security checks. It must control the consequence such that the consequence is technically non-completable without successful finality verification. 3. Candidate Act Descriptor A conforming implementation SHOULD create or derive a machine-verifiable descriptor for the Candidate Act before effectuation. The precise serialization format is implementation-specific in this version of the document. A conceptual descriptor may contain: Candidate-Act-ID Act-Type Act-Digest Initiating-Principal Application-ID Agent-ID Tool-or-Function-ID Purpose Resource-or-Data-Class Permitted-Scope Permitted-Consequence-Class Destination-ID Destination-Jurisdiction Data-Precision Data-Residency-State Policy-Epoch Authority-Epoch Revocation-Epoch Nonce Freshness-State Protected-State-Reference Validation-Evidence-Reference Finality-Sink-ID Effectuation-Boundary-ID Not every field is required for every domain. For example: • Data-Precision is particularly relevant to location or sensitive-data release. • Destination-Jurisdiction is relevant to cross-border data export. • Tool-or-Function-ID is important for agentic AI. • Permitted-Consequence-Class may distinguish a model response from a financial transfer or physical actuation. • Finality-Sink-ID identifies the boundary authorized to consume the authority. The underlying disclosure already contemplates binding the Candidate Act to protected state, validation evidence, nonce, freshness, policy and revocation epochs, jurisdiction state, permitted effect, and Finality Sink identity. 4. First Boundary — PED Validation The first execution-finality boundary is PED validation. Upon receiving or resolving a Candidate Act, the PED MUST keep that act non-effective while validation is performed. The PED SHOULD evaluate all predicates required by the applicable consequence class. Such predicates MAY include: authority purpose application identity agent identity tool/function scope instruction provenance destination jurisdiction data residency data precision policy epoch revocation state freshness nonce state protected state ALF or approved logic state Runtime Behavioral Descriptor permitted consequence class Finality Sink identity The PED MUST distinguish between validation success and effectuation. PED approval alone MUST NOT make the Candidate Act effective. This distinction is essential. The architecture requires: PED validation success != external consequence Instead: PED validation success | v Protected evidence commitment | v Scoped finality authority Only after the evidence commitment is made MAY the execution-finality chain advance. 4.1 PED Validation Success If validation succeeds, the PED MUST: 1. establish or confirm the applicable protected-state transition; 2. generate or commit protected validation evidence; 3. bind that evidence to the applicable Candidate Act; 4. bind the permitted scope and applicable Finality Sink; 5. release scoped non-bearer finality authority only after, or atomically with, the evidence commitment. The Candidate Act remains non-effective at this stage. The PED has authorized issuance of finality authority. It has not yet caused effectuation. 4.2 PED Validation Failure If validation fails, the PED MUST NOT release usable finality authority. The implementation SHOULD create protected denial state or denial evidence sufficient to prevent unauthorized retry, replay, rollback, substitution, or stale reuse where those risks apply. The implementation MAY: • consume or lock a nonce; • advance protected monotonic state; • generate a denial receipt; • generate a denial LAVR; • update a revocation or exposure state; • quarantine the Candidate Act; or • require renewed authorization. The Candidate Act MUST remain non-effective. Your disclosure specifically contemplates denial evidence, nonce consumption or locking, protected-state advancement, and continued non-effectuation following failed validation. 5. Protected Evidence Before Authority A defining property of this architecture is evidence-gated progression. The system MUST NOT treat a simple Boolean result such as: ALLOW = TRUE as sufficient execution-finality authority. Instead, the protected validation result is committed into protected evidence before the act can proceed. Conceptually: Candidate Act | v PED Validation | +---- FAIL ----> Denial Evidence | | | v | Remain Non-Effective | `---- PASS | v Protected Evidence | v Scoped Finality Authority This makes the validation state part of the consequence-control mechanism rather than merely part of an audit trail. A LAVR therefore represents a pre-effectuation protected commitment, not a post-event blockchain receipt.

Scoped Non-Bearer Finality Authority Following successful protected evidence commitment, the PED MAY release an Execution Handle, capability fragment, protected enablement state, or equivalent scoped non-bearer finality authority. Regardless of representation, the authority MUST be sufficiently constrained so that possession alone cannot authorize arbitrary effectuation. A conforming authority SHOULD be: Act-bound It applies only to the intended Candidate Act or Candidate Act Fragment. Evidence-bound It is associated with the protected validation evidence that caused its issuance. State-bound It reflects the relevant protected state. Scope-bound It permits only the validated consequence. Nonce- or freshness-bound It cannot be validly replayed outside the applicable freshness state. Epoch-bound It remains consistent with applicable policy, authorization, and revocation state. Sink-bound It is valid only at the intended Finality Sink. Non-bearer Copying, observing, storing, forwarding, or possessing it does not by itself create authority for effectuation. Where single-use effectuation is intended, the authority MUST be consumed, invalidated, burned, or rendered unusable before or atomically with successful effectuation. The source explicitly requires freshness, unconsumed state, revocation state, exact Candidate-Act binding, protected evidence/state binding, and intended sink binding to be verified.

Second Boundary — Independent Finality Sink Verification The second boundary is the Finality Sink. The Finality Sink MUST NOT merely trust the fact that the PED previously approved the Candidate Act. It MUST independently verify the applicable finality authority immediately before effectuation. The Finality Sink SHOULD verify, where applicable: authority validity Candidate Act identity/digest protected validation evidence protected-state reference or transition scope purpose destination jurisdiction data precision nonce freshness policy epoch revocation epoch consumption state permitted consequence class effectuation-boundary identity Finality Sink identity The Finality Sink MUST reject the Candidate Act if a required verification fails. A failed Finality Sink verification MUST NOT merely create an alert while allowing the consequence to proceed. It MUST prevent effectuation. For example: Data export failure: no protected data leaves the boundary. Payment failure: no settlement occurs. Telecom failure: no governed network consequence occurs. Satellite failure: no protected command or RF effect occurs. AI tool-call failure: the tool call remains non-effective. Location failure: exact GPS coordinates are not released. This independent sink-side verification is explicitly required by your disclosed architecture.

Successful Effectuation If Finality Sink verification succeeds, the implementation MUST ensure that the finality authority cannot be reused outside its permitted semantics. For single-use operations, consumption, invalidation, burning, or protected-state advancement SHOULD occur before or atomically with effectuation. The implementation SHOULD also create sink-side finality evidence identifying the completed protected consequence. The execution sequence is therefore: 1. Candidate Act created | 2. Candidate Act held non-effective | 3. PED validates act-specific predicates | 4. Protected validation evidence committed | 5. Scoped non-bearer finality authority released | 6. Finality Sink independently verifies authority | 7. Authority/state consumed or advanced | 8. Permitted consequence becomes effective |

Sink-side finality evidence recorded This progression closely follows the seven evidence-gated stages expressly described in the source specification. 9. Fail-Closed Requirement A conforming implementation MUST fail closed for a protected consequence when required execution-finality state cannot be verified. The following conditions SHOULD result in denial where applicable: missing authority invalid authority expired authority stale authority replayed authority revoked authority previously consumed authority Candidate Act mismatch descriptor mismatch scope mismatch purpose mismatch destination mismatch jurisdiction mismatch precision mismatch policy-epoch mismatch revocation-epoch mismatch nonce mismatch protected-state mismatch Finality Sink mismatch effectuation-boundary mismatch The important property is structural: failure prevents consequence rather than merely documenting that an unauthorized consequence occurred. This is the difference between execution finality and conventional audit-oriented control.

Protocol Invariant The complete Phase 2 invariant can therefore be stated as: Candidate Act | v Non-Effective State | v Protected Enforcement Domain | v Act-Specific Validation | v Protected Validation Evidence | v Scoped Non-Bearer Finality Authority | v Independent Finality Sink Verification | +------ FAILURE ------> remain non-effective | `------ SUCCESS | v authority consumed | v permitted consequence No individual element substitutes for this chain. A policy engine alone is insufficient. An app permission alone is insufficient. An access token alone is insufficient. An attestation alone is insufficient. A human approval alone is insufficient. A LAVR alone is insufficient. A Finality Sink without act-bound authority is insufficient. The execution-finality property arises because these elements remain mutually bound across the transition from computation to consequence.

AI-Native 5G/6G and O-RAN Execution-Finality Profile

Embodiment C — AI-Native 5G, 6G and O-RAN

Problem Future telecommunications infrastructure is increasingly: • programmable; • API-driven; • AI-assisted; • autonomous; • software-defined; and • distributed across network and edge domains. An authenticated AI agent or network function may be permitted to participate in the network while lacking authority to cause every possible network consequence. Authentication therefore answers: Who are you? Execution finality answers: May this exact network act become effective now, for this subscriber, purpose, scope, location, policy state, and network boundary? The source expressly distinguishes network authentication from authorization for a particular consequence at a particular moment and purpose.

Telecom Candidate Acts A telecom Candidate Act MAY include: • routing modification; • signaling operation; • session establishment; • resource allocation; • service activation; • slice orchestration; • network API invocation; • traffic-steering decision; • autonomous optimization; • machine-to-machine communication operation; • AI-RAN action; • subscriber-specific network operation; or • other network-state transition.

Example An AI network controller proposes: Act-Type: NETWORK_RESOURCE_REALLOCATION Network-Function: AI-RAN controller Cell: cell-108 Target-Slice: emergency-services Requested-Change: resource allocation Purpose: congestion optimization Policy-Epoch: 2018 Finality-Sink: RAN enforcement boundary The AI controller may generate the optimization. The optimization remains a Candidate Act. The PED validates the applicable network, policy, subscriber, jurisdiction, resource and authority predicates. Only then may scoped finality authority be released.

Telecom Finality Sink Placement Depending on deployment, a telecom Finality Sink MAY be located at or associated with: • carrier gateway; • UPF; • control-plane function; • session controller; • network API gateway; • AI-RAN enforcement point; • O-RAN control interface; • signaling gateway; • edge network function; or • future 6G enforcement node. The source expressly identifies carrier gateways, UPF functions, control-plane interfaces, session controllers, network APIs and AI-RAN control points as potential consequence boundaries.

Result The governing rule becomes: network identity is not network finality authority. An AI-generated routing or signaling operation can be fully calculated without yet being allowed to alter the live network.

JSON API and Schema for AI-Native Network Finality This section defines a concrete JSON interoperability profile for AI-generated or AI-mediated network Candidate Acts in 5G-Advanced, 6G/IMT-2030, O-RAN, AI-RAN, and related programmable network environments. The schema makes the proposed network effect, resource scope, subscriber scope, network function identity, policy state, and intended Network Finality Sink explicit.

NetworkCandidateAct Object { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "urn:ietf:params:json-schema:network-finality:candidate-act:1", "title": "NetworkCandidateAct", "type": "object", "additionalProperties": false, "required": [ "version", "object_type", "candidate_act_id", "act_type", "created_at", "expires_at", "initiator", "network_context", "resource_scope", "purpose", "requested_effect", "policy_state", "freshness", "finality_sink" ], "properties": { "version": { "type": "string", "const": "1.0" }, "object_type": { "type": "string", "const": "network_candidate_act" }, "candidate_act_id": { "type": "string", "minLength": 16 }, "act_type": { "type": "string", "enum": [ "ROUTE_CHANGE", "SESSION_MODIFICATION", "QOS_CHANGE", "SLICE_RESOURCE_ALLOCATION", "RAN_PARAMETER_CHANGE", "POLICY_UPDATE", "NETWORK_API_INVOCATION", "UPF_RULE_CHANGE", "BEAM_CHANGE", "SENSING_OPERATION", "RF_ENABLE", "SERVICE_ACTIVATION", "OTHER" ] }, "created_at": { "type": "string", "format": "date-time" }, "expires_at": { "type": "string", "format": "date-time" }, "initiator": { "type": "object", "required": [ "network_function_id", "function_type" ], "properties": { "network_function_id": { "type": "string" }, "function_type": { "type": "string", "enum": [ "AI_RAN_CONTROLLER", "RIC_XAPP", "RIC_RAPP", "SMF", "AMF", "PCF", "UPF_CONTROLLER", "ORCHESTRATOR", "NETWORK_API_CLIENT", "EDGE_AGENT", "OTHER" ] }, "agent_id": { "type": "string" }, "model_id": { "type": "string" }, "runtime_attestation_digest": { "type": "string" } } }, "network_context": { "type": "object", "properties": { "plmn_id": { "type": "string" }, "network_domain": { "type": "string" }, "slice_id": { "type": "string" }, "cell_ids": { "type": "array", "items": { "type": "string" } }, "edge_region": { "type": "string" }, "jurisdiction": { "type": "string" } } }, "resource_scope": { "type": "object", "required": [ "resource_type", "resource_ids" ], "properties": { "resource_type": { "type": "string", "enum": [ "SLICE", "CELL", "QOS_FLOW", "SESSION", "UPF_RULE", "ROUTE", "SPECTRUM_RESOURCE", "BEAM", "NETWORK_API", "SENSING_RESOURCE", "OTHER" ] }, "resource_ids": { "type": "array", "minItems": 1, "items": { "type": "string" } }, "subscriber_scope": { "type": "object", "properties": { "scope_type": { "type": "string", "enum": [ "NONE", "SINGLE_SUBSCRIBER", "SUBSCRIBER_GROUP", "TENANT", "SLICE", "CELL_POPULATION" ] }, "scope_reference": { "type": "string" } } } } }, "purpose": { "type": "object", "required": [ "purpose_id", "declared_purpose" ], "properties": { "purpose_id": { "type": "string" }, "declared_purpose": { "type": "string" }, "service_intent_reference": { "type": "string" }, "purpose_epoch": { "type": "integer", "minimum": 0 } } }, "requested_effect": { "type": "object", "required": [ "effect_type", "parameters_digest" ], "properties": { "effect_type": { "type": "string" }, "parameters_digest": { "type": "object", "required": [ "algorithm", "value" ], "properties": { "algorithm": { "type": "string", "enum": [ "SHA-256", "SHA-384", "SHA-512" ] }, "value": { "type": "string" } } }, "duration_seconds": { "type": "integer", "minimum": 0 }, "reversibility": { "type": "string", "enum": [ "REVERSIBLE", "PARTIALLY_REVERSIBLE", "IRREVERSIBLE" ] } } }, "policy_state": { "type": "object", "required": [ "policy_epoch", "authority_epoch", "revocation_epoch" ], "properties": { "policy_epoch": { "type": "integer", "minimum": 0 }, "authority_epoch": { "type": "integer", "minimum": 0 }, "revocation_epoch": { "type": "integer", "minimum": 0 }, "operator_policy_profile": { "type": "string" }, "regulatory_profile": { "type": "string" } } }, "freshness": { "type": "object", "required": [ "nonce" ], "properties": { "nonce": { "type": "string", "minLength": 16 }, "sequence": { "type": "integer", "minimum": 0 }, "session_id": { "type": "string" } } }, "finality_sink": { "type": "object", "required": [ "sink_id", "sink_type" ], "properties": { "sink_id": { "type": "string" }, "sink_type": { "type": "string", "enum": [ "UPF", "CONTROL_PLANE_GATEWAY", "RAN_CONTROL", "O_RAN_E2", "O_RAN_A1", "NETWORK_API_GATEWAY", "RF_ENABLE", "SESSION_CONTROLLER", "OTHER" ] } } } } }

NetworkValidationDecision Object The protected network enforcement function evaluates whether the proposed network consequence is valid for the current network state. A successful AI recommendation or policy-engine decision does not itself cause the network effect. { "version": "1.0", "object_type": "network_validation_decision", "decision_id": "nvd-1882bd", "candidate_act_id": "net-39f8820b", "decision": "ALLOW", "validated_predicates": { "initiator_attested": true, "resource_scope_valid": true, "subscriber_scope_valid": true, "purpose_valid": true, "requested_effect_valid": true, "operator_policy_valid": true, "regulatory_policy_valid": true, "network_state_valid": true, "policy_epoch_valid": true, "revocation_state_valid": true, "freshness_valid": true, "sink_binding_valid": true }, "network_state": { "topology_epoch": 993, "configuration_epoch": 771, "slice_state": "ACTIVE", "congestion_state": "NORMAL" }, "protected_state": { "state_reference": "net-ped-state-7801", "monotonic_counter": 184991 } }

NetworkFinalityAuthority Object { "version": "1.0", "object_type": "network_finality_authority", "authority_id": "nfa-7f51ca", "candidate_act_id": "net-39f8820b", "decision_id": "nvd-1882bd", "scope": { "act_type": "SLICE_RESOURCE_ALLOCATION", "resource_type": "SLICE", "resource_ids": [ "slice-17" ], "subscriber_scope": { "scope_type": "TENANT", "scope_reference": "tenant-A" }, "permitted_effect": { "effect_type": "ALLOCATE_CAPACITY", "parameters_digest": "base64url-effect-digest", "duration_seconds_max": 300 }, "network_domain": "ran-domain-2", "jurisdiction": "IN" }, "binding": { "candidate_act_digest": { "algorithm": "SHA-256", "value": "base64url-net-act-digest" }, "protected_state_reference": "net-ped-state-7801", "topology_epoch": 993, "configuration_epoch": 771, "policy_epoch": 42, "authority_epoch": 8, "revocation_epoch": 7, "nonce": "C3929177AA801C55", "finality_sink_id": "ran-finality-sink-04" }, "lifetime": { "issued_at": "2026-08-26T17:50:01Z", "expires_at": "2026-08-26T17:50:05Z", "single_use": true }, "issuer": { "ped_id": "operator-ped-1", "key_id": "operator-finality-key-4", "signature": "base64url-signature" } }

NetworkSinkVerify Request and Response The Network Finality Sink verifies the actual requested network effect immediately before the protected configuration, forwarding, signaling, RF, or resource-allocation change becomes effective. { "operation": "NetworkSinkVerify", "request_id": "net-verify-991", "candidate_act_id": "net-39f8820b", "authority_id": "nfa-7f51ca", "sink": { "sink_id": "ran-finality-sink-04", "sink_type": "RAN_CONTROL" }, "proposed_effect": { "effect_type": "ALLOCATE_CAPACITY", "resource_type": "SLICE", "resource_ids": [ "slice-17" ], "parameters": { "additional_prb_percent": 12, "duration_seconds": 120 }, "parameters_digest": { "algorithm": "SHA-256", "value": "base64url-effect-digest" } }, "current_network_state": { "topology_epoch": 993, "configuration_epoch": 771 }, "freshness": { "nonce": "C3929177AA801C55" } } { "operation": "NetworkSinkVerify", "request_id": "net-verify-991", "decision": "ALLOW", "verification": { "authority_signature": "VALID", "candidate_act_binding": "MATCH", "initiator_scope": "MATCH", "resource_scope": "MATCH", "subscriber_scope": "MATCH", "effect_parameters": "MATCH", "topology_epoch": "CURRENT", "configuration_epoch": "CURRENT", "policy_epoch": "CURRENT", "revocation_epoch": "CURRENT", "nonce": "FRESH", "consumption_state": "UNUSED", "sink_binding": "MATCH" }, "consumption": { "authority_id": "nfa-7f51ca", "status": "CONSUMED", "consumed_at": "2026-08-26T17:50:02Z" }, "effectuation": { "permitted": true, "network_effect_id": "net-effect-4481" } }

Network-State Mismatch Denial If the topology or configuration changes between protected validation and effectuation, the sink can deny the stale authority and require revalidation. This is important for low-latency autonomous network control because a valid decision for one state may be unsafe in a later state. { "operation": "NetworkSinkVerify", "request_id": "net-verify-992", "decision": "DENY", "error": { "code": "EF_NETWORK_STATE_MISMATCH", "message": "Current configuration epoch differs from the epoch bound to the finality authority.", "retryable": true }, "verification": { "authority_signature": "VALID", "configuration_epoch_expected": 771, "configuration_epoch_observed": 772, "resource_scope": "MATCH", "sink_binding": "MATCH" }, "effectuation": { "permitted": false, "required_action": "REVALIDATE_CANDIDATE_ACT" } }

Complete AI-RAN Resource Allocation Example { "step_1_ai_recommendation": { "agent_id": "ai-ran-controller-7", "recommendation": "Increase slice-17 radio capacity by 12 percent for 120 seconds", "effect_status": "NON_EFFECTIVE" }, "step_2_candidate_act": { "candidate_act_id": "net-39f8820b", "act_type": "SLICE_RESOURCE_ALLOCATION", "initiator": { "network_function_id": "ai-ran-controller-7", "function_type": "AI_RAN_CONTROLLER", "agent_id": "ran-agent-7", "model_id": "traffic-optimizer-v5" }, "network_context": { "plmn_id": "00101", "network_domain": "ran-domain-2", "slice_id": "slice-17", "jurisdiction": "IN" }, "resource_scope": { "resource_type": "SLICE", "resource_ids": [ "slice-17" ], "subscriber_scope": { "scope_type": "TENANT", "scope_reference": "tenant-A" } }, "purpose": { "purpose_id": "latency-optimization", "declared_purpose": "Maintain latency SLO for tenant-A" }, "requested_effect": { "effect_type": "ALLOCATE_CAPACITY", "parameters_digest": { "algorithm": "SHA-256", "value": "base64url-effect-digest" }, "duration_seconds": 120, "reversibility": "REVERSIBLE" }, "policy_state": { "policy_epoch": 42, "authority_epoch": 8, "revocation_epoch": 7, "operator_policy_profile": "ran-autonomy-v3" }, "freshness": { "nonce": "C3929177AA801C55", "sequence": 8821 }, "finality_sink": { "sink_id": "ran-finality-sink-04", "sink_type": "RAN_CONTROL" } }, "step_3_protected_validation": { "decision": "ALLOW", "topology_epoch": 993, "configuration_epoch": 771 }, "step_4_authority": { "authority_id": "nfa-7f51ca", "single_use": true, "expires_in_seconds": 4 }, "step_5_sink_verification": { "decision": "ALLOW", "authority_consumed": true }, "step_6_network_effect": { "slice_id": "slice-17", "additional_prb_percent": 12, "duration_seconds": 120, "effect_status": "EFFECTIVE" } }

Transport and Binding Considerations This JSON profile defines the semantic API contract but does not require one transport. Candidate Acts and finality authorities may be carried over protected local IPC, operator-internal HTTPS, service-based interfaces, O-RAN control interfaces, or other authenticated transports. A transport binding MUST preserve object integrity, sink identity, freshness, and the protected non-bearer semantics of the authority.

Protocol Operation, Verification, and Failure Handling

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as normative requirements when, and only when, they appear in all capitals. The execution-finality protocol is based on one mandatory invariant: Failure to establish current finality authority MUST NOT be converted into permission to effectuate.

End-to-End Protocol Workflow A conforming implementation follows the following logical sequence: Act Generator PED Finality Sink | | | |-- Candidate Act ---->| | | | | | NON-EFFECTIVE | | |<---------------------| | | | | | |-- validate predicates | | |-- verify protected state| | |-- verify nonce/epochs | | | | | | [DENY] | | |---- denial evidence ---->| | | | | | Candidate remains | | | NON-EFFECTIVE | | | | | | [ALLOW] | | |-- commit evidence | | |-- create scoped | | | finality authority | | | | |---------------------- finality authority ------>| | | | verify act | | verify scope | | verify nonce | | verify state | | verify epochs | | verify sink | | | | [FAIL] | | no effect | | | | [PASS] | | consume | | authority | | | |<---------------- permitted consequence ---------| The source architecture expressly requires the Candidate Act to remain non-effective, protected evidence to be committed before or atomically with authority issuance, and independent Finality Sink verification before effectuation.

Candidate Act Construction Before a protected consequence is attempted, the implementation SHOULD construct a Candidate Act Descriptor. A minimal logical representation is: CandidateAct { version candidate_act_id act_type act_digest initiator_id application_id agent_id tool_id purpose permitted_scope consequence_class destination_id jurisdiction data_class data_precision nonce creation_time expiration_time policy_epoch authority_epoch revocation_epoch protected_state_ref finality_sink_id } Fields MAY be omitted where they do not apply to the consequence class. However, every implementation MUST have sufficient binding information to prevent authority issued for one Candidate Act from being substituted, redirected, replayed, or used at another Finality Sink.

Candidate Act Digest A Candidate Act SHOULD have a stable digest calculated over its load-bearing attributes. Conceptually: ActDigest = HASH( canonical_act_type || canonical_effect_parameters || purpose || destination || jurisdiction || permitted_scope || consequence_class || finality_sink_id ) The exact canonicalization and hash format are outside the scope of this version. However, implementations MUST ensure that changing a load-bearing attribute causes the previously issued authority to fail verification. For example, changing: Exact GPS -> coarse GPS Recipient A -> Recipient B Jurisdiction X -> Jurisdiction Y $50 -> $5,000 Tool A -> Tool B Satellite 1 -> Satellite 2 Sink A -> Sink B MUST NOT preserve authority unless the changed operation is separately authorized.

PED Processing The PED receives or reconstructs the Candidate Act Descriptor and performs protected validation. A simplified procedure is: function PED_VALIDATE(candidate): if candidate is malformed: return DENY(MALFORMED_ACT) if candidate.nonce is not fresh: return DENY(REPLAY_OR_STALE) if candidate.policy_epoch != current_policy_epoch: return DENY(POLICY_EPOCH_MISMATCH) if candidate.revocation_epoch != current_revocation_epoch: return DENY(REVOCATION_STATE_MISMATCH) if candidate.finality_sink_id is not authorized: return DENY(SINK_NOT_AUTHORIZED) if protected_state does not permit candidate: return DENY(PROTECTED_STATE_DENIAL) if purpose is not permitted: return DENY(PURPOSE_DENIAL) if jurisdiction is not permitted: return DENY(JURISDICTION_DENIAL) if requested scope exceeds allowed scope: return DENY(SCOPE_DENIAL) if additional consequence-specific checks fail: return DENY(CONSEQUENCE_POLICY_DENIAL) evidence = COMMIT_PROTECTED_VALIDATION(candidate) authority = ISSUE_SCOPED_FINALITY_AUTHORITY( candidate, evidence, current_protected_state ) return ALLOW(authority) The pseudocode is illustrative. An implementation MAY evaluate additional predicates including ALF, Runtime Behavioral Descriptor, instruction provenance, neural-state integrity, data residency, accelerator identity, mission state, financial state, recipient state, or cumulative disclosure state. The disclosed architecture requires the PED to check act-specific predicates while the Candidate Act remains non-effective.

Protected Validation Evidence Upon successful validation, the PED MUST commit protected validation evidence before, or atomically with, issuance of usable finality authority. A conceptual evidence object may contain: ValidationEvidence { evidence_id candidate_act_digest decision = ALLOW protected_state_before protected_state_after policy_epoch authority_epoch revocation_epoch nonce permitted_scope consequence_class finality_sink_id validation_time validation_domain_id integrity_protection } The evidence MAY be a LAVR or an equivalent protected commitment. External blockchain finality is NOT required for the hot path. The source explicitly permits local receipts, protected hash-chain entries, TEE/HSM receipts, secure-register entries, and equivalent protected commitments, with slower external anchoring occurring later.

Scoped Finality Authority A finality authority MAY be represented as an Execution Handle, protected capability, capability fragment, protected state reference, or equivalent bounded artifact. A conceptual structure is: FinalityAuthority { authority_id candidate_act_digest validation_evidence_ref permitted_scope consequence_class destination_id jurisdiction data_precision nonce policy_epoch authority_epoch revocation_epoch protected_state_ref finality_sink_id issued_at expires_at single_use = true integrity_protection } The artifact MUST NOT operate as a generic bearer token. Merely copying the authority MUST NOT permit another process, sink, destination, jurisdiction, or Candidate Act to use it successfully.

Finality Sink Verification Algorithm Immediately before effectuation, the Finality Sink MUST independently verify the authority. Illustrative logic: function FINALITY_SINK_VERIFY(candidate, authority): if authority is absent: return DENY(NO_FINALITY_AUTHORITY) if authority integrity check fails: return DENY(INVALID_AUTHORITY) if HASH(candidate) != authority.candidate_act_digest: return DENY(ACT_MISMATCH) if authority.finality_sink_id != THIS_SINK: return DENY(SINK_MISMATCH) if authority is expired: return DENY(STALE_AUTHORITY) if authority is already consumed: return DENY(AUTHORITY_ALREADY_USED) if authority.nonce is not current: return DENY(NONCE_FAILURE) if authority.policy_epoch != current_policy_epoch: return DENY(POLICY_EPOCH_MISMATCH) if authority.revocation_epoch != current_revocation_epoch: return DENY(REVOKED_OR_STALE) if protected_state does not match: return DENY(PROTECTED_STATE_MISMATCH) if candidate scope exceeds authority scope: return DENY(SCOPE_MISMATCH) if candidate destination != authorized destination: return DENY(DESTINATION_MISMATCH) if candidate jurisdiction != authorized jurisdiction: return DENY(JURISDICTION_MISMATCH) if candidate data precision exceeds authorized precision: return DENY(PRECISION_MISMATCH) ATOMICALLY: consume(authority) advance_replay_state() permit_effectuation() return EFFECTUATED The source expressly describes verification of capability/evidence presence, sink identity, descriptor and fragment hashes, nonce freshness and consumption, policy and revocation epochs, purpose, jurisdiction, scope, protected state, and permitted consequence class.

Authority Consumption and Replay Prevention For a single-use operation, successful authority consumption SHOULD be atomic with the state transition that enables effectuation. An implementation MUST prevent the sequence: verify authority | v effectuate | v attacker replays same authority | v effectuate again Instead: verify | v reserve / consume authority | v advance protected replay state | v effectuate once Replay protection MAY use: • nonce consumption; • monotonic counters; • sequence numbers; • protected consumed flags; • protected state advancement; • short expiration windows; • epoch advancement; or • an equivalent anti-replay mechanism. The source requires capability consumption or protected-state advancement before or atomically with effectuation and describes nonce consumption as part of replay prevention.

Revocation A previously issued authority MUST NOT override a newer revocation state. If an authority was created under: Revocation-Epoch = 51 and the applicable protected state has advanced to: Revocation-Epoch = 52 the older authority SHOULD fail unless an explicitly defined policy permits continued validity. Conceptually: if authority.revocation_epoch < protected.revocation_epoch: DENY Revocation SHOULD be checked at the Finality Sink, not merely when the authority was originally created. This prevents: PED approves at T1 | v authorization revoked at T2 | v old authority used at T3 from automatically becoming an effective consequence.

Policy Epoch Changes The same principle applies to policy. An authority issued before a material policy change SHOULD NOT silently inherit authority under the new policy state. Examples include: • exact location became prohibited for the destination; • an AI tool was revoked; • a telecom action was removed from the authorized scope; • a satellite entered a different mission phase; • a counterparty became blocked; • a model version was withdrawn; • a data residency rule changed; or • a child-safety policy changed. The sink SHOULD therefore compare current policy state with the policy epoch bound to the authority.

Hot-Path and Cold-Path Processing Not every Candidate Act requires identical validation cost. The architecture therefore MAY support a hot path and a cold path.

Hot Path The hot path is suitable for: • frequent; • previously bounded; • low-risk; • latency-sensitive; or • pre-authorized classes of Candidate Acts. The hot path MAY rely on: local protected state fresh nonce state cached policy short-lived authority pre-bound sink identity known destination current revocation epoch bounded scope local protected evidence A hot-path operation MUST still perform Finality Sink verification. "Hot path" does not mean "skip finality."

Cold Path A Candidate Act SHOULD be escalated to a cold or higher-assurance path where it involves, for example: • high-value financial settlement; • exact location export; • high-value sovereign data export; • cross-jurisdiction processing; • satellite RF emission; • payload control; • cryptographic-key release; • actuator control; • unusual agent behavior; • new or unknown tool delegation; • changed destination; • uncertain jurisdiction; • policy anomaly; • missing cached state; or • high-consequence infrastructure operation. The cold path MAY require: • remote authority resolution; • fresh attestation; • deeper ALF/RBD validation; • sovereign approval; • enterprise approval; • regulatory checks; • multi-party approval; • consequence simulation; • human review; or • additional proof material. The source expressly identifies exact-location export, financial settlement, satellite RF, actuator control and high-value data egress as candidates for stronger validation.

Hot-to-Cold Escalation A Candidate Act MUST NOT obtain default permission merely because the hot path cannot make a decision. For example: cache miss policy miss revocation uncertainty network failure unknown destination unknown jurisdiction changed sink changed tool runtime anomaly SHOULD result in: HOT PATH | v cannot prove eligibility | v COLD PATH not: HOT PATH | v cannot verify | v ALLOW The source is explicit that timeout, cache miss, policy miss, uncertainty, or network failure does not create default authority.

Cold-to-Hot Authority Refresh A successful cold-path evaluation MAY establish a bounded policy envelope for subsequent low-latency operations. For example, a cold path may establish: Approved Model: model-A Approved Tool: map-search Approved Purpose: local-service-discovery Maximum Location Precision: CITY Destination: endpoint-X Jurisdiction: permitted Policy-Epoch: 203 Revocation-Epoch: 77 Finality-Sink: network-egress-4 Valid-Until: short bounded interval Later Candidate Acts within the exact envelope MAY use faster local validation. If any bound condition changes, the system SHOULD escalate again. The source expressly contemplates cold-path generation of protected hot-path policy objects while requiring freshness, scope, revocation and sink binding to remain valid.

Latency Model Execution finality SHOULD be implementable without requiring a remote ledger round trip for every operation. Representative embodiments in the source describe: • sub-10-ms operation for cached-policy paths; • approximately 1-5 ms in some hardware-adjacent paths; • approximately 1-20 ms for some mobile/browser/application-gateway paths; and • higher delays for stronger attestation, multi-party or regulatory validation. These figures are implementation examples, not protocol requirements. The important architectural separation is: HOT PATH --------- validate check nonce check protected state commit local protected evidence bind sink release scoped authority verify at sink effectuate COLD / AUDIT PATH ----------------- external ledger anchoring transparency log proof aggregation regulatory reporting enterprise synchronization long-term audit The cold path MUST NOT retroactively authorize an act that was not valid when effectuation occurred. External anchoring can strengthen later evidence, but it does not replace the pre-effectuation chain.

Failure and Denial Codes This section defines an IETF-draft-level proposed error taxonomy derived from the failure conditions in the source. The symbolic names below are protocol-design suggestions; the source describes the underlying failure conditions but does not prescribe these exact wire codes. A conforming implementation MAY expose equivalent numeric or symbolic codes. EF-001 MALFORMED_ACT EF-002 NO_FINALITY_AUTHORITY EF-003 INVALID_AUTHORITY EF-004 STALE_AUTHORITY EF-005 AUTHORITY_ALREADY_USED EF-006 REPLAY_DETECTED EF-007 NONCE_FAILURE EF-010 ACT_MISMATCH EF-011 DESCRIPTOR_MISMATCH EF-012 SCOPE_MISMATCH EF-013 PURPOSE_MISMATCH EF-014 CONSEQUENCE_CLASS_MISMATCH EF-020 DESTINATION_MISMATCH EF-021 JURISDICTION_MISMATCH EF-022 DATA_RESIDENCY_MISMATCH EF-023 PRECISION_MISMATCH EF-030 POLICY_EPOCH_MISMATCH EF-031 REVOCATION_STATE_MISMATCH EF-032 PROTECTED_STATE_MISMATCH EF-040 SINK_MISMATCH EF-041 EFFECTUATION_BOUNDARY_MISMATCH EF-050 ATTESTATION_FAILURE EF-051 ALF_MISMATCH EF-052 RUNTIME_BEHAVIOR_MISMATCH EF-053 INSTRUCTION_PROVENANCE_FAILURE EF-060 VALIDATION_TIMEOUT EF-061 AUTHORITY_UNCERTAIN EF-062 POLICY_UNAVAILABLE EF-063 JURISDICTION_UNRESOLVED EF-070 ESCALATION_REQUIRED EF-071 HUMAN_REVIEW_REQUIRED EF-080 FAIL_CLOSED The source identifies absence, staleness, revocation, replay, prior consumption, descriptor, nonce, policy, jurisdiction, protected-state, scope and Finality-Sink mismatch as conditions requiring the Candidate Act to remain non-effective.

Denial Behavior A denial response MAY specify an allowed remediation. For example: EF-023 PRECISION_MISMATCH Action: DOWNGRADE_TO_CITY or: EF-063 JURISDICTION_UNRESOLVED Action: ESCALATE_TO_COLD_PATH or: EF-031 REVOCATION_STATE_MISMATCH Action: REQUIRE_FRESH_AUTHORITY or: EF-051 ALF_MISMATCH Action: QUARANTINE Permitted denial actions MAY include: • deny; • delay; • downgrade; • redact; • suppress; • quarantine; • zeroize; • request new authority; • escalate to a cold path; or • route for review. The source expressly supports denial, suppression, quarantine, redaction, zeroization, delay, downgrade, isolation and review following failed validation.

No Fail-Open on Timeout A timeout MUST NOT be interpreted as approval. For a protected consequence: verification timeout != permission Instead: verification timeout | +--> retry within policy | +--> escalate | +--> delay | +--> downgrade | `--> deny If no permitted resolution is available, the Candidate Act remains non-effective.

Alternate-Path Closure An implementation MUST consider alternate paths capable of producing the same protected consequence. For precise location, relevant paths may include: main application upload analytics SDK advertising SDK telemetry browser upload cloud sync backup clipboard bridge file export AI-agent tool call background service For an AI act: normal tool dispatcher direct API call shell execution browser control IPC memory write alternate plugin For hardware: CPU path GPU DMA SmartNIC DPU accelerator driver alternate interconnect Moving the act to a different path MUST NOT inherently remove the execution-finality requirement if that path can produce the same protected consequence. The source explicitly states that routing around a cold path, using stale cached authority, fragmenting an act, relocating the Finality Sink, or moving effectuation to another component does not create a bypass.

Security Considerations The execution-finality architecture is intended to prevent an upstream security decision, AI decision, application permission, credential, or network authorization from automatically becoming authority for an external consequence. The principal security objective is: A protected consequence MUST remain technically non-effective unless current, act-specific, scoped authority is verified at the applicable Finality Sink. Implementations MUST consider attacks against every load-bearing element of the finality chain.

Replay Attacks An attacker may attempt to reuse a previously valid finality authority. For example: Act A approved | v Authority A issued | v Act A completed | v Attacker copies Authority A | v Attempts second consequence A conforming implementation MUST prevent this. Finality authority SHOULD therefore be bound to one or more of: Candidate Act identity Candidate Act digest nonce sequence state policy epoch revocation epoch protected state scope Finality Sink identity consumption state Single-use authority MUST be consumed or otherwise made unusable before or atomically with effectuation. The source specifically identifies replay, stale retry, duplicate effectuation, cross-sink reuse and consumed-authority reuse as conditions that must prevent effectuation.

Candidate Act Substitution An attacker may obtain valid authority for one Candidate Act and attempt to substitute a different operation. Examples include: authorized: send coarse location substituted: send precise GPS or: authorized: payment = 50 substituted: payment = 5,000 or: authorized: Tool A substituted: Tool B The Finality Sink MUST verify that the actual consequence corresponds to the act or digest bound to the authority. A load-bearing field change MUST invalidate authority unless separately authorized.

Sink Substitution and Cross-Sink Laundering Authority issued for one Finality Sink MUST NOT automatically be usable at another sink. For example: Authority: sink = approved-data-egress-A Attack: redirect through egress-B or: Authority: tool-dispatcher-A Attack: direct shell interface A Finality Sink MUST verify its own identity or protected boundary identity against the authority before effectuation. The source identifies sink mismatch, boundary mismatch and cross-sink laundering as explicit conditions for denial.

Stale Policy and Revocation An act MAY have been valid when created but invalid when effectuation is attempted. Examples include: • revoked tool authority; • changed location-export policy; • new data-residency restriction; • revoked model version; • changed mission state; • new financial restriction; • expired user authorization; or • changed recipient status. The Finality Sink SHOULD therefore verify current policy and revocation state immediately before consequence. An old upstream approval MUST NOT automatically override current protected state.

Protected-State Integrity An attacker may attempt: • rollback; • deletion of consumed state; • nonce reset; • policy-epoch rollback; • revocation-epoch rollback; • stale snapshot restoration; • duplicate authorization; or • protected-state substitution. High-assurance implementations SHOULD use protected monotonic state, sealed storage, secure counters, authenticated state transitions or equivalent mechanisms where rollback could produce a consequence.

Failure of the PED The PED is security critical. If its integrity cannot be established, the implementation SHOULD NOT release finality authority for protected consequence classes. Depending on the risk class, the system MAY: • fail closed; • downgrade; • quarantine; • require another protected validator; • require human approval; • move to a cold path; or • disable the protected consequence.

Failure of the Finality Sink The Finality Sink is equally load-bearing. An upstream PED cannot compensate for a sink that permits consequence without checking authority. The architecture therefore requires the complete chain: Non-Effective State + PED Validation + Protected Evidence + Scoped Authority + Protected State + Finality Sink Verification A Finality Sink without act-bound authority is not equivalent to the described architecture. The source expressly treats these elements as mutually load-bearing rather than independent advisory controls.

Telecom and 5G/6G Deployment Considerations The architecture is intended as an additional finality-control mechanism, not a replacement for ordinary telecommunications authentication, authorization or routing procedures. In AI-native 5G, 5G-Advanced, O-RAN and future 6G environments, possible Finality Sink locations include: • UPF; • carrier gateway; • network API gateway; • control-plane interface; • signaling gateway; • session-control function; • O-RAN enforcement point; • AI-RAN control boundary; • packet-egress boundary; or • other consequence-bearing network function. The source expressly contemplates AI-generated routing, signaling, orchestration, communication and resource-allocation acts being held non-effective until scoped authority is verified.

Network Authentication Is Not Finality A valid network identity demonstrates that an entity is recognized. It does not necessarily establish: this act this purpose this subscriber this destination this jurisdiction this time this policy state this consequence Therefore: authentication SHOULD NOT be treated as universal network-consequence authority.

Latency Carrier and 6G deployments may require line-rate or near-line-rate behavior. Such deployments MAY rely on: • local protected state; • cached short-lived policy; • current revocation epoch; • sink-bound capabilities; • SmartNIC or DPU enforcement; • secure network functions; or • hardware-adjacent validation. High-risk or anomalous operations MAY be escalated to a slower validation path rather than allowing an unverifiable network consequence.

Interoperability and Deployment Model The execution-finality architecture is intended to coexist with existing systems. It MAY consume decisions or evidence from: identity systems OAuth/access-control systems RBAC policy engines AI safety systems attestation systems telecom authentication enterprise policy regulatory policy human approval risk engines content classifiers However, those systems provide inputs to finality validation. They do not replace Finality Sink verification. This preserves the distinction: policy decision != final consequence

IANA Considerations This version of the document requests no IANA actions. It does not presently define: • a new IP protocol number; • transport port; • DNS record type; • media type; • URI scheme; or • mandatory global registry. If later versions standardize wire-format fields, error codes, consequence classes, precision classes, capability types or protocol parameters, an IANA registry MAY be proposed at that time. The EF-xxx failure identifiers shown in Phase 4 are currently illustrative protocol-design identifiers and are not IANA assignments.

Intellectual Property Considerations Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family. The source identifies, among others: PCT/IB2026/054453 Capability-Validated Inbound Descriptor / CVID-PCT-1 PCT/IB2026/055615 THE DAS PROTOCOLS PCT/IB2026/055760 THE DAS PROTOCOLS PART II PCT/IB2026/055870 THE DAS PROTOCOLS PART III PCT/IB2026/056058 THE DAS PROTOCOLS PART IV PCT/IB2026/053385 Algorithmic Logic Fingerprint-related architecture The source states that these filings disclose related elements including non-bearer execution handles, protected enforcement domains, neural candidate acts, AI-output finality, device-side enforcement, agentic tool-use enforcement and Algorithmic Logic Fingerprints. Any IETF intellectual-property disclosure required in connection with standardization of this work should be handled separately in accordance with applicable IETF IPR procedures. This section is informational and does not define licensing terms.

References The following references are relevant to the motivation, policy context, or technical lineage described in this document.

Normative References At this stage, this document does not define a completed interoperable wire protocol requiring a finalized normative dependency set. A later revision SHOULD add the applicable IETF normative references once the encoding, transport, integrity mechanism and protocol negotiation elements are selected.

Informative References The following materials are identified in the source disclosure as relevant background or policy context: [EO14110] United States Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, October 2023. [EDPB-28-2024] European Data Protection Board, Opinion 28/2024. [EU-AI-ACT] Regulation of the European Union concerning artificial intelligence. [ENISA] European Union Agency for Cybersecurity, relevant threat-landscape and network-security material. [NATO-CCDCOE] NATO Cooperative Cyber Defence Centre of Excellence, material concerning cyber operations and critical infrastructure. [NATO-STRATCOM] NATO Strategic Communications Centre of Excellence, work concerning metadata, telemetry and information exploitation. [UK-OSA] United Kingdom Online Safety Act 2023. [3GPP] 3GPP specifications relevant to 5G, 5G-Advanced, O-RAN-adjacent deployment environments and non-terrestrial networks. [ITU] ITU work concerning future networks and AI-assisted telecommunications. These references provide motivation or deployment context. They do not themselves define the execution-finality protocol. The source expressly maps the long-felt need to frontier-AI governance, data protection, telecommunications, sovereign infrastructure, cybersecurity, financial finality and digital child safety.

Technical-Lineage References [DAS-CVID] PCT/IB2026/054453, Capability-Validated Inbound Descriptor / CVID-PCT-1. [DAS-MOTHERSHIP] PCT/IB2026/055615, THE DAS PROTOCOLS. [DAS-II] PCT/IB2026/055760, THE DAS PROTOCOLS PART II. [DAS-III] PCT/IB2026/055870, THE DAS PROTOCOLS PART III. [DAS-IV] PCT/IB2026/056058, THE DAS PROTOCOLS PART IV. [DAS-ALF] PCT/IB2026/053385, Algorithmic Logic Fingerprint-related architecture. These applications are identified in the source as related technical disclosures.

Conclusion In AI-native telecommunications, network identity and upstream policy approval should not automatically become authority for a live network consequence. A proposed network operation remains non-effective until protected validation, evidence commitment, scoped finality authority, and independent sink verification complete successfully. The resulting rule is: network authentication is not network finality; computation is not authority.