Independent Inventor

Balasore Odisha 756001 India info@sangamdas.com

Security execution finality 6G O-RAN AI-RAN network authorization In programmable and AI-assisted mobile networks, successful authentication of a network function or AI controller does not establish authority for every routing, signaling, session, resource-allocation, sensing, or subscriber-specific consequence that the function can generate. This document defines an informational execution-finality profile for AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN, and AI-RAN environments. A proposed network operation is represented as a Network Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain validates act-specific predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer finality authority. A Network Finality Sink at the enforcement boundary independently verifies that authority immediately before live network state changes. The governing rule is that network authentication is not network finality, and computation is not authority. This revision also defines a JSON interoperability profile for Candidate Acts, validation decisions, scoped authority, and sink verification. This profile is distinct from, and complementary to, present AI-native 6G industry roadmaps that focus on radio, sensing, and platform capability, including air-interface, MIMO, spectrum, and AI-RAN infrastructure work described in Qualcomm's public AI-native 6G platform material, and the broad native-trustworthiness and agentic-core-network architectures described in Huawei's public 6G security research. Those efforts address how a network becomes more intelligent, autonomous, and platform-trustworthy. This document addresses a narrower and later question: once an already-authenticated, already-policy-approved AI-generated network operation has been computed, whether that exact operation may become a live network consequence. The Candidate Act, Non-Effective State, Protected Enforcement Domain, and Finality Sink constructs defined here, as an explicit pre-effectuation gate with act-bound non-bearer authority and independent sink-side re-verification, are not established as an equivalent primitive in publicly reviewed material from those roadmaps.

Introduction Future telecommunications systems are increasingly programmable, API-driven, AI-assisted, distributed, sensing-aware, and autonomous. An authenticated network function, Near-RT RIC xApp, rApp, orchestrator, or AI agent may be permitted to participate in the network while lacking authority to cause every possible live-network consequence. As 5G-Advanced and IMT-2030/6G systems move toward AI-native operation, autonomous adaptation, and agentic control loops, more of the operations that change live network state originate from a computation rather than from a human operator issuing a discrete command. That shift does not by itself create a new authentication problem; it creates a new question about what happens between the moment a computation completes and the moment its consequence becomes real. Existing mobile-network security mechanisms answer an earlier question: whether an entity may enter a domain, invoke an interface, or obtain a token. 3GPP security architecture , O-RAN security interfaces , transport-layer protections, and upstream policy engines together establish that an entity is recognized and, in many cases, that a class of operation it requests is generally permitted. None of those mechanisms, taken individually or together, answer a later and narrower question: whether one particular, already-computed proposed operation may become effective right now, for this exact subscriber or resource, this purpose, this scope, this destination, this jurisdiction, this policy epoch, and this specific enforcement boundary. An entity can be correctly authenticated, and an upstream policy decision can correctly say ALLOW, while the network state that decision was computed against has already changed by the time the operation would take effect. Execution finality is the name this document gives to that later, narrower control point. This distinction matters more, not less, as networks become agentic. Public industry direction already anticipates increasingly autonomous network operation: AI-native platform work describes context-aware adaptation of scheduling, resource allocation, QoS, and protocol behavior across device, RAN, and core, and separate public research describes an agentic core network in which AI agents may autonomously detect intent, generate services, execute them, and continuously optimize them through multi-agent collaboration. Neither direction is in question here, and this document does not claim that such systems lack security architecture, guardrails, or trust models. The question this document isolates is narrower and comes later in the pipeline: once an AI-native or agentic system has computed a proposed network operation, what technically determines whether that exact operation is allowed to become a live consequence, independent of whether the system that computed it was itself authenticated, policy-compliant, and well-intentioned at the moment of computation. This document specifies that later control as a two-boundary architecture:

1. A Protected Enforcement Domain (PED) validates a Candidate Act and, only after committing protected validation evidence, may release scoped non-bearer finality authority.
2. A Finality Sink at the actual effectuation boundary independently verifies that authority immediately before the live network state changes, then consumes or otherwise invalidates the authority for unauthorized replay.

Between these two boundaries, the proposed operation, termed a Network Candidate Act, remains in a Non-Effective State: it may be generated, evaluated, staged, queued, hashed, or otherwise prepared, but it cannot yet become externally consequential. Validation at the PED does not itself cause effectuation; it produces protected evidence and, from that evidence, a finality-authority artifact that is deliberately not a bearer credential. The artifact is bound to one act, one effect, one resource and subscriber scope, one purpose, one policy and revocation epoch, and one Finality Sink, so that possessing a serialized copy of it is insufficient on its own to produce the protected effect. The Finality Sink independently re-checks the act digest, the actual effect parameters, the current topology and policy state, and the authority's consumption status immediately before the consequence occurs, and then consumes single-use authority atomically with effectuation. This closes a specific race condition that upstream authorization alone cannot close: a decision computed against network state at one instant can be presented for effectuation after that state has already changed, and an ordinary ALLOW decision has no mechanism to detect or refuse that staleness on its own. The standards surface this document proposes is deliberately narrow: a Network Candidate Act representation plus a Network Finality Sink verification contract. This document does not replace 3GPP authentication, O-RAN policy interfaces, PFCP or NAS freshness and replay mechanisms, or ordinary routing procedures; those mechanisms remain necessary and are treated throughout this document as inputs to, not replacements for, finality validation. Nor does this document propose a new waveform, MIMO technique, spectrum band, channel code, scheduler, or AI accelerator; it does not compete with air-interface, sensing, or platform-capability research. It defines a single additional pre-effectuation gate that applies specifically to AI-mediated and other autonomous network acts, positioned after every other applicable authentication and policy mechanism has already run and immediately before the live network state actually changes. Because the required gate differs by consequence class, this document does not assume a single latency profile applies uniformly across the network. Non-real-time control, such as rApp policy and long-lived slice or optimization policy, can use a conventional Protected Enforcement Domain and Finality Sink path without difficulty. Near-real-time consequential control, such as xApp-generated E2 control or cell-level configuration change, can plausibly use a DU, CU, or E2-node-local Finality Sink operating on the order of the Near-RT RIC's own control loop. Genuinely PHY/MAC-speed decisions are not expected to carry a full act-specific authority exchange on every scheduling event; instead, a stronger validation may establish a bounded, time-limited, revocable execution envelope once, after which individual high-speed decisions are checked locally against that envelope without repeating the full exchange. discusses this profile distinction, together with carrier-scale throughput, multi-vendor key management, wire-format overhead, and failure behavior, in engineering detail, since these are the questions most likely to be raised by RAN, core-network, and accelerator engineers evaluating this proposal against present deployment constraints. This document also positions itself explicitly against present AI-native 6G industry roadmaps rather than presenting the problem as unaddressed territory. Public platform-focused work on air-interface, MIMO, spectrum, sensing, and AI-native RAN, core, and device operation, and public native-trustworthiness and agentic-core-network research addressing security, privacy, resilience, and multilateral trust as a lifecycle property, both describe how a network becomes more intelligent, autonomous, and trustworthy. Neither, in the material publicly reviewed for this document, establishes an explicit Non-Effective State, an act-bound non-bearer finality authority, or independent sink-side re-verification immediately before effectuation as a named, general-purpose primitive. and the abstract of this document address that distinction directly, and this document should be read as complementary to, not competitive with, that broader body of work: the more capable and autonomous an AI-native network becomes, the more consequential the question of what makes its guardrails technically load-bearing at the moment of effect becomes. The remainder of this document proceeds as follows. defines the Candidate Act, Non-Effective State, Protected Enforcement Domain, Protected Validation Evidence, Scoped Non-Bearer Finality Authority, and Finality Sink constructs used throughout. Subsequent sections define the problem scope, the two-boundary architecture, the JSON interoperability profile, fail-closed requirements, and deployment considerations. Non-normative appendices address frequently asked questions comparing this profile against existing mechanisms, including 3GPP authentication, O-RAN policy interfaces, OAuth, RATS attestation, Zero Trust Architecture, ledger anchoring, audit logging, and GSMA Open Gateway APIs, against present AI-native 6G industry roadmaps, and against the carrier-scale and radio-timescale engineering questions described above. A companion informational draft discusses the same finality pattern outside the mobile-network profile , and a runnable reference implementation with an accompanying test suite accompanies this specification to demonstrate the described behavior experimentally.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The protocol invariant is mandatory: failure to establish current finality authority MUST NOT be converted into permission to effectuate a protected network consequence.

Terminology

Candidate Act

An operation that has been generated, selected, requested, staged, scheduled, routed, or otherwise prepared but has not yet been permitted to become consequence-bearing. A Candidate Act MAY already be fully computed. Computation alone MUST NOT cause effectuation.

Network Candidate Act

A Candidate Act whose intended consequence is a change to live telecommunications state, including routing, signaling, session, QoS, slice, RAN parameter, UPF rule, sensing, RF enablement, or network-API effectuation.

Non-Effective State

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.

Protected Enforcement Domain (PED)

A protected validation environment that evaluates whether a Candidate Act is eligible to receive scoped finality authority. The PED MAY be realized as a trusted execution environment, secure enclave, HSM, protected operating-system service, protected network function, confidential-computing environment, or equivalent. The defining property is the validation role, not a particular hardware product.

Protected Validation Evidence

Evidence committed by the PED establishing the validation state associated with a Candidate Act. The evidence MAY be a Ledger-Anchored Validation Receipt (LAVR) or an equivalent protected commitment using hashes, signatures, MACs, sealed state, monotonic counters, Merkle commitments, or append-only protected records. External ledger anchoring is OPTIONAL and is not required on the hot path.

Scoped Non-Bearer Finality Authority

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. Possession alone MUST NOT be sufficient to cause effectuation.

Finality Sink

The functional boundary at which a Candidate Act would become externally, operationally, or network-effectively consequential. A gateway, firewall, or policy engine 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.

Network Finality Sink

A Finality Sink located at or associated with a carrier gateway, UPF, control-plane function, session controller, network API gateway, AI-RAN or O-RAN enforcement point, signaling gateway, edge network function, or equivalent 6G enforcement node.

Effectuation

The transition of a Candidate Act from Non-Effective State into an actual change of live network, subscriber, sensing, RF, or resource state.

Problem Scope Traditional network security controls primarily determine who may enter a system, who may invoke an API, and whether a network function is authenticated. Those controls remain necessary. They do not, by themselves, decide whether one already-generated operation may become a live-network consequence. That distinction matters more as control loops become autonomous. An AI-RAN controller, RIC xApp, or orchestrator can compute a resource reallocation, traffic-steering decision, or sensing export without a human decision point immediately before effectuation. Authentication of the controller answers "who are you?". Execution finality answers "may this exact network act become effective now?". IMT-2030 work describes expected capabilities that widen the consequence surface: native AI integration, distributed learning and inference, integrated sensing and communication, high-precision positioning, cloud-native and edge-native architectures, network slicing, and heterogeneous multi-stakeholder environments . In such an environment, location, presence, and subscriber context may be derived from infrastructure measurements rather than from a single application GPS API. Removing one application's positioning permission therefore does not necessarily control final disclosure or actuation. This document does not claim that existing cybersecurity or privacy controls will collapse. It claims that access-centric assumptions are incomplete if they are relied upon without a separate control over the transition from computation to consequence.

Relationship to Existing Mechanisms Execution finality is intended to consume decisions from existing systems, not to replace them. Those systems remain inputs to PED validation. They do not replace independent Finality Sink verification.

3GPP Authentication, SBA Authorization, and Policy 3GPP security for the 5G system, including network-function authentication and service-based interface authorization , establishes that an NF is a recognized party and that it may invoke a service. Policy Control Function decisions and related session-policy procedures govern QoS and charging rules. Those mechanisms do not inherently bind a one-shot, act-specific digest to a particular sink identity, topology epoch, nonce, and single-use consumption state immediately before a live RAN or UPF mutation generated by an autonomous controller.

CAPIF, NEF, and Network APIs Exposure frameworks such as CAPIF and the Network Exposure Function authorize API clients and can constrain API invocation. A permitted API call is still not, by itself, proof that the resulting network effect remains valid for the current topology and revocation epoch at the moment of effectuation.

O-RAN A1, E2, and RIC Applications O-RAN A1 carries policy from Non-RT RIC toward Near-RT RIC. E2 carries control and information between Near-RT RIC and E2 nodes . An xApp or rApp that is admitted to the RIC and authorized on A1/E2 may still generate a control that is unsafe after a topology or configuration-epoch change, or that exceeds a subscriber, slice, or jurisdiction scope not encoded in the original policy object. A Finality Sink at the E2 node or other RAN enforcement point can verify act-bound authority at the last hop without replacing A1 or E2.

What This Profile Adds Relative to the mechanisms above, this profile adds:

• an explicit Non-Effective State for proposed network acts;
• protected evidence committed before or atomically with authority issuance;
• non-bearer authority bound to act digest, sink, scope, freshness, and policy/revocation/topology epochs;
• independent sink-side verification immediately before live-state change; and
• mandatory fail-closed behavior on mismatch, replay, revocation, or uncertainty.

Architecture

Core Invariant 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 all of the following have occurred:

1. a PED validates the applicable act-specific predicates;
2. protected validation evidence is generated or committed;
3. scoped non-bearer finality authority is released;
4. an applicable Finality Sink independently verifies that authority; and
5. 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.

Execution-finality chain remain non-effective | `------ SUCCESS | v authority consumed | v permitted consequence ]]>

No individual element substitutes for this chain. A policy engine, application permission, access token, attestation, human approval, LAVR, or Finality Sink without act-bound authority is insufficient by itself.

Non-Effective State 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. Failure at a load-bearing point MUST leave the Candidate Act non-effective. A warning or audit record alone is not sufficient.

Candidate Act Descriptor A conforming implementation SHOULD create or derive a machine-verifiable descriptor for the Candidate Act before effectuation. The precise serialization is defined for the network profile in . A conceptual descriptor includes:

• Candidate-Act-ID, Act-Type, Act-Digest
• Initiating principal, application, agent, and tool/function identifiers
• Purpose, resource or data class, permitted scope, and permitted consequence class
• Destination and destination jurisdiction
• Data precision and data-residency state, where applicable
• Policy, authority, and revocation epochs
• Nonce, freshness state, and protected-state reference
• Validation-evidence reference, Finality-Sink-ID, and effectuation-boundary identifier

Not every field is required for every consequence class. Data precision is particularly relevant to location or sensitive-data release. Destination jurisdiction is relevant to cross-border export. Tool or function identity is important for agentic controllers. Permitted consequence class distinguishes a model recommendation from a live network mutation. A Candidate Act SHOULD have a stable digest over its load-bearing attributes. Changing a load-bearing attribute MUST cause previously issued authority to fail verification unless the changed operation is separately authorized.

First Boundary: 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. Predicates MAY include authority, purpose, application and agent identity, tool/function scope, instruction provenance, destination, jurisdiction, data residency, data precision, policy epoch, revocation state, freshness, nonce, protected state, permitted consequence class, and Finality Sink identity. PED approval alone MUST NOT make the Candidate Act effective. Validation success is not external consequence.

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; and
5. release scoped non-bearer finality authority only after, or atomically with, the evidence commitment.

At this stage the Candidate Act remains non-effective. The PED has authorized issuance of finality authority. It has not yet caused effectuation.

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, update revocation or exposure state, quarantine the Candidate Act, or require renewed authorization. The Candidate Act MUST remain non-effective.

Evidence-Gated Progression The system MUST NOT treat a simple Boolean result such as ALLOW=TRUE as sufficient execution-finality authority. The protected validation result is committed into protected evidence before the act can proceed. A LAVR, where used, is a pre-effectuation protected commitment, not a post-event receipt. External blockchain finality is NOT required for the hot path.

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, evidence-bound, state-bound, scope-bound, nonce- or freshness-bound, epoch-bound, and sink-bound. Copying, observing, storing, forwarding, or possessing the authority MUST NOT by itself create authority for effectuation. 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. Where single-use effectuation is intended, the authority MUST be consumed, invalidated, or rendered unusable before or atomically with successful effectuation.

Second Boundary: Independent Finality Sink Verification The Finality Sink MUST NOT merely trust 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 or 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; and Finality Sink identity. The Finality Sink MUST reject the Candidate Act if a required verification fails. A failed verification MUST prevent effectuation. It MUST NOT merely create an alert while allowing the consequence to proceed. For a telecom failure, no governed network consequence occurs. For a location-export failure, exact coordinates are not released.

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, 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:

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 or state consumed or advanced
8. Permitted consequence becomes effective
9. Sink-side finality evidence recorded

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

Telecom Candidate Acts A telecom Candidate Act MAY include routing modification, signaling operation, session establishment or modification, 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, sensing operation, RF enablement, or another network-state transition.

Example: AI-RAN Resource Reallocation An AI network controller proposes a NETWORK_RESOURCE_REALLOCATION for cell-108 and slice emergency-services, with purpose congestion-optimization and Finality Sink at a RAN enforcement boundary. The controller may fully compute 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. The RAN enforcement point verifies that authority immediately before the allocation becomes live.

Telecom Finality Sink Placement Depending on deployment, a telecom Finality Sink MAY be located at or associated with a carrier gateway, UPF, control-plane function, session controller, network API gateway, AI-RAN enforcement point, O-RAN E2 or A1-adjacent enforcement logic, signaling gateway, edge network function, or a future 6G enforcement node. Carrier and 6G deployments may require 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 SHOULD be escalated rather than allowed as unverifiable network consequences.

JSON Interoperability Profile This section defines a JSON interoperability profile for AI-generated or AI-mediated network Candidate Acts. The schema makes the proposed network effect, resource scope, subscriber scope, network-function identity, policy state, and intended Network Finality Sink explicit. This profile defines the semantic contract. It 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. The JSON representation given below is chosen for readability and for ease of interoperability experimentation, and is not proposed as an optimized carrier wire format. For constrained interfaces, in particular Open Fronthaul and other E2-adjacent transports where payload size and parsing cost matter, a production transport binding would more naturally map this same schema onto a compact binary encoding. Plausible candidates include CBOR with COSE signing and encryption structures , which preserve the same field semantics defined here in a substantially smaller and faster-to-parse encoding, or a binary encoding such as ASN.1 or Protocol Buffers aligned with existing 3GPP or O-RAN information-element encoding conventions for the interface concerned. This document defines the semantic contract, that is, which fields exist and what they bind; the choice of wire encoding is a transport-binding concern left to a future companion specification or to the implementer, provided the binding preserves the integrity, freshness, sink-identity, and non-bearer properties required above.

NetworkCandidateAct Object

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.

NetworkFinalityAuthority Object

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.

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 matters for low-latency autonomous control because a valid decision for one state may be unsafe in a later state.

Complete AI-RAN Resource Allocation Example

Protocol Operation and Failure Handling

End-to-End Workflow

PED and Finality Sink workflow | | | | | | NON-EFFECTIVE | | |<---------------------| | | | | | |-- validate predicates | | |-- verify protected state | | |-- verify nonce/epochs | | | | | | [DENY] | | |---- denial evidence ---->| | | 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 ---------| ]]>

PED Processing The following procedure is illustrative: An implementation MAY evaluate additional predicates, including attestation, instruction provenance, data residency, accelerator identity, or cumulative disclosure state. The PED MUST perform these checks while the Candidate Act remains non-effective.

Finality Sink Verification

Authority Consumption, Replay, and Revocation For a single-use operation, successful authority consumption SHOULD be atomic with the state transition that enables effectuation. An implementation MUST prevent verify- then-effectuate-then-replay of the same authority. Replay protection MAY use nonce consumption, monotonic counters, sequence numbers, protected consumed flags, protected-state advancement, short expiration windows, epoch advancement, or an equivalent mechanism. 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. Revocation SHOULD be checked at the Finality Sink, not merely when the authority was originally created. The same principle applies to policy epochs. An authority issued before a material policy change SHOULD NOT silently inherit authority under the new policy state. Examples include a newly prohibited location-export precision, a revoked AI tool, a telecom action removed from authorized scope, a changed data-residency rule, or a withdrawn model version.

Hot Path and Cold Path Not every Candidate Act requires identical validation cost. A hot path MAY be used for frequent, previously bounded, low-risk, or latency-sensitive classes of acts, relying on local protected state, fresh nonce state, cached policy, short-lived authority, pre-bound sink identity, and current revocation epoch. A hot-path operation MUST still perform Finality Sink verification. "Hot path" does not mean "skip finality." A Candidate Act SHOULD be escalated to a cold or higher-assurance path where it involves exact location export, high-value sovereign data export, cross-jurisdiction processing, RF emission, actuator-class control, cryptographic-key release, unusual agent behavior, unknown tool delegation, changed destination, uncertain jurisdiction, policy anomaly, missing cached state, or high-consequence infrastructure operation. A Candidate Act MUST NOT obtain default permission merely because the hot path cannot make a decision. Cache miss, policy miss, revocation uncertainty, network failure, unknown destination, unknown jurisdiction, changed sink, changed tool, or runtime anomaly SHOULD result in cold-path escalation, delay, downgrade, or denial. Timeout, cache miss, or uncertainty MUST NOT create default authority. A successful cold-path evaluation MAY establish a bounded policy envelope for subsequent low-latency operations. Later Candidate Acts within that exact envelope MAY use faster local validation. If any bound condition changes, the system SHOULD escalate again. Execution finality SHOULD be implementable without a remote ledger round trip for every operation. Representative local paths may operate in the millisecond range; stronger attestation or multi-party validation may take longer. These figures are implementation examples, not protocol requirements. External anchoring can strengthen later evidence. It MUST NOT retroactively authorize an act that was not valid when effectuation occurred.

Failure Codes The following identifiers are protocol-design suggestions and are not IANA assignments. 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-033 NETWORK_STATE_MISMATCH
• EF-040 SINK_MISMATCH
• EF-041 EFFECTUATION_BOUNDARY_MISMATCH
• EF-050 ATTESTATION_FAILURE
• EF-060 VALIDATION_TIMEOUT
• EF-061 AUTHORITY_UNCERTAIN
• EF-062 POLICY_UNAVAILABLE
• EF-063 JURISDICTION_UNRESOLVED
• EF-070 ESCALATION_REQUIRED
• EF-080 FAIL_CLOSED

A denial response MAY specify an allowed remediation, such as downgrade of precision, escalation to a cold path, or requirement for fresh authority. Permitted denial actions MAY include deny, delay, downgrade, redact, suppress, quarantine, request new authority, escalate, or route for review.

Fail-Closed Requirements A conforming implementation MUST fail closed for a protected consequence when required execution-finality state cannot be verified. Failure prevents consequence rather than merely documenting that an unauthorized consequence occurred. A timeout MUST NOT be interpreted as approval. Verification timeout is not permission. The implementation MAY retry within policy, escalate, delay, downgrade, or deny. If no permitted resolution is available, the Candidate Act remains non-effective. An implementation MUST consider alternate paths capable of producing the same protected consequence. Moving the act to a different interface, plugin, interconnect, or network function MUST NOT inherently remove the execution-finality requirement if that path can produce the same protected consequence. 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 principal security objective is that 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 An attacker may attempt to reuse a previously valid finality authority after the original act has completed. Finality authority SHOULD therefore be bound to Candidate Act identity or digest, nonce, sequence state, policy and revocation epochs, protected state, scope, Finality Sink identity, and consumption state. Single-use authority MUST be consumed or otherwise made unusable before or atomically with effectuation.

Candidate Act Substitution An attacker may obtain valid authority for one Candidate Act and attempt to substitute a different operation, for example replacing coarse location with precise coordinates, one tool with another, or one resource allocation with a broader change. The Finality Sink MUST verify that the actual consequence corresponds to the act or digest bound to the authority.

Sink Substitution Authority issued for one Finality Sink MUST NOT automatically be usable at another sink. A Finality Sink MUST verify its own identity or protected boundary identity against the authority before effectuation.

Stale Policy, Revocation, and Protected State An act MAY have been valid when created but invalid when effectuation is attempted. The Finality Sink SHOULD verify current policy and revocation state immediately before consequence. An old upstream approval MUST NOT automatically override current protected state. An attacker may attempt rollback, deletion of consumed state, nonce reset, epoch rollback, stale snapshot restoration, or protected-state substitution. High-assurance implementations SHOULD use protected monotonic state, sealed storage, secure counters, or authenticated state transitions where rollback could produce a consequence.

Failure of the PED or Finality Sink The PED is security-critical. If its integrity cannot be established, the implementation SHOULD NOT release finality authority for protected consequence classes. Depending on 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. The Finality Sink is equally load-bearing. An upstream PED cannot compensate for a sink that permits consequence without checking authority. A Finality Sink without act-bound authority is not equivalent to the architecture described here.

Threat Model: Compromised xApp/rApp Attempting Sink Bypass The preceding subsections analyze this architecture by attack technique. This subsection instead analyzes it from a single attacker's perspective, to make explicit what a compromised RAN-side automation component can and cannot achieve against a conforming implementation, and where the residual risk that this specification does not close actually lies.

Attacker Model The attacker controls an xApp or rApp that is legitimately admitted to the RIC, holds valid transport credentials, and is authorized on A1/E2 or an equivalent interface for some class of operation, consistent with the description of that admission in . The attacker does not hold the Protected Enforcement Domain's signing key, does not hold sink-local protected activation state, and cannot forge Finality Sink identity. The attacker can construct and submit arbitrary Network Candidate Act payloads within the syntactic and transport permissions its RIC admission already grants it.

Attempted Bypasses and Their Outcomes The attacker submits a Candidate Act whose requested effect exceeds its properly authorized purpose, resource, or subscriber scope, for example broadening a slice-resource change beyond the scope any legitimate policy would grant it. The Protected Enforcement Domain validates resource scope, subscriber scope, purpose, and jurisdiction against policy before evidence is committed, as described in , and rejects the act; no authority is issued and the act remains non-effective. The attacker captures a previously issued, still-unexpired finality authority for a legitimate act and attempts to resubmit it, either verbatim or after the underlying act has already been consumed. This is the Replay case analyzed above: authority is bound to nonce, sequence state, and consumption state, and single-use authority is consumed atomically with effectuation, so a replayed submission is rejected by the Finality Sink even though the transport-layer submission is otherwise indistinguishable from a legitimate one. The attacker obtains a validly issued authority for one act and attempts to alter the requested effect parameters before presenting it at the sink, for example changing an approved resource-allocation percentage or duration after issuance. This is the Candidate Act and effect-parameter substitution case analyzed above: the Finality Sink independently recomputes the effect-parameter digest and rejects the mismatch, since the authority is bound to the original digest and not to whatever payload is presented alongside it. The attacker attempts to present a validly issued authority at a Finality Sink other than the one it was issued for, for example a different DU, UPF, or network-API gateway than the one named at issuance. This is the Sink Substitution case analyzed above: authority is bound to Finality Sink identity, and a sink verifying its own identity against the authority rejects the submission. The attacker delays presentation of a validly issued authority until after the topology, configuration, policy, or revocation epoch has changed, attempting to exploit the window between PED validation and effectuation described in . The Finality Sink re-checks current topology, configuration, policy, and revocation state immediately before effectuation and rejects the now-stale authority, independent of whether the authority was valid at the time it was issued. The attacker attempts to have its xApp revoked or otherwise disabled after obtaining valid authority, then continues presenting that authority at the sink. Because the sink verifies current revocation epoch rather than trusting the revocation state that held at issuance time, an authority issued before revocation is rejected once the revocation epoch the sink checks has advanced, provided the operator's revocation-epoch update has propagated to the sink before the bypass attempt.

Residual Risk Not Closed by This Architecture This threat model assumes the attacker's xApp is compromised but its RIC admission and A1/E2 authorization are not themselves malicious grants. If the compromise instead extends to the policy or authorization system that decides what scope the xApp is legitimately entitled to, for example a compromised Non-RT RIC policy source that grants the xApp an overly broad but nominally valid scope, then a Candidate Act submitted within that broadened scope will pass Protected Enforcement Domain validation, because the PED is validating the act against policy it has no independent way to know is itself compromised. This architecture constrains what an already-scoped attacker can do outside its granted scope, stale state, or consumed authority; it does not by itself detect that a policy source upstream of the PED has been compromised into granting a scope it should not have granted. Closing that residual risk requires policy-source integrity, least-privilege scope grants, and monitoring of policy-source behavior, which are outside the boundary this specification defines. Likewise, as discussed in , this architecture provides no protection at all against a consequence-bearing path that does not route through a Finality Sink in the first place; a compromised xApp that can reach the same effect through an unprotected administrative or legacy interface bypasses this architecture entirely, not by defeating it.

Deployment Considerations The architecture is 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 the 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 another consequence-bearing network function. A valid network identity demonstrates that an entity is recognized. It does not necessarily establish authority for this act, purpose, subscriber, destination, jurisdiction, time, policy state, and consequence. Authentication SHOULD NOT be treated as universal network-consequence authority. This profile MAY consume decisions or evidence from identity systems, OAuth and access-control systems, RBAC, policy engines, AI safety systems, attestation systems, telecom authentication, enterprise policy, regulatory policy, human approval, and risk engines. Those systems provide inputs to finality validation. They do not replace Finality Sink verification.

IANA Considerations This document requests no IANA actions at this time. It does not define a new IP protocol number, transport port, DNS record type, media type, URI scheme, or mandatory global registry. This document does, however, introduce concrete enumerated values that are candidates for future registration, including Network Candidate Act types such as those illustrated in and (for example, "ROUTE_CHANGE" and "SLICE_RESOURCE_ALLOCATION"), and finality failure identifiers such as those illustrated in (for example, "EF_NETWORK_STATE_MISMATCH"). All such values in this document are illustrative and are not IANA assignments. A future version of this specification intends to request creation of two IANA registries under Expert Review or Specification Required policy: an "Execution-Finality Network Act Types" registry, listing the permissible values of the act_type field and the semantic consequence class each value represents, and an "Execution-Finality Error Codes" registry, listing the EF-xxx failure identifiers returned by a Protected Enforcement Domain or Finality Sink and the mismatch condition each identifier denotes. Registering these values centrally is intended to let independently implemented PEDs, Finality Sinks, and interoperating vendors agree on a common vocabulary for act types and failure semantics without requiring every deployment to define its own private enumeration.

Intellectual Property Note Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family, including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. Any IETF intellectual-property disclosure required in connection with this work should be handled in accordance with BCP 79 . This section is informational and does not define licensing terms.

Resources This section lists related Internet-Drafts in the same execution-finality family and the reference implementation accompanying this document. It is informational and is provided for the reader's convenience; it does not modify the normative content of this specification.

Related Internet-Drafts The following Internet-Drafts apply the same execution-finality architecture to other domains:

• Non-Terrestrial Network / RF execution finality:
• Payment execution finality:
• AI-native 6G execution finality (this document):
• MAP discovery / communication finality:

Reference Implementation A runnable reference implementation of the execution-finality architecture described in this document, including the Candidate Act, Non-Effective State, Protected Enforcement Domain, Protected Validation Evidence, Scoped Non-Bearer Finality Authority, and Finality Sink constructs, together with an automated test suite, is published at the following repository: The methodology, experimental environment, measured performance, variations, and limitations of that implementation are documented in the repository itself and are summarized at a non-normative level in of this document.

Applicability to IETF Working Groups and Research Groups This section discusses, on a non-normative basis, which existing IETF working groups and IRTF research groups the subject matter of this document most directly relates to. It does not itself request adoption by any group; it is intended to help reviewers and list participants route discussion of this work to an appropriate venue.

Group / Area	Why It Fits	Relevance
NMOP (Network Management Operations)	NMOP is an active venue for AI/LLM-mediated network automation governance and operator-facing deployment concerns, and this document's subject matter directly complements existing NMOP-adjacent work such as on governance of AI-mediated autonomous network device management.	High (primary home)
RATS (Remote ATtestation ProcedureS)	The Protected Validation Evidence and Protected Enforcement Domain constructs defined in are conceptually adjacent to RATS's concern with verifying that an entity or environment is in a trustworthy state before a decision is made on that basis; and the FAQ entry on RATS in already describe attestation evidence as one input predicate to PED validation rather than a replacement for it.	High (security underpinning)
NMRG (Network Management Research Group)	If the mechanics described here are judged too early for a standards-track venue, the IRTF's NMRG is actively exploring AI-assisted network testing, deployment, and management frameworks and could provide an incubation venue for the underlying architecture before a standards-track group takes it up.	Medium (incubation)
WIMSE (Workload Identity in Multi-System Environments)	WIMSE standardizes fine-grained, least-privilege authorization and token formats for workload-to-workload interaction, and its charter already names RATS and SCITT as directly collaborating groups. The Scoped Non-Bearer Finality Authority construct defined in , and the non-bearer contrast drawn against OAuth in , describe a token-like artifact with narrower, per-act binding than WIMSE's workload-identity tokens; the two are adjacent but not identical problems, since WIMSE authorizes a workload's standing identity while this document authorizes one specific downstream act.	Medium (adjacent token architecture)
SCITT (Supply Chain Integrity, Transparency, and Trust)	SCITT defines interoperable building blocks, issuers, notaries, and transparency services, so that a signed statement about an artifact or action can be independently verified and made accountable. The Protected Validation Evidence construct in , and the evidence-before-authority ordering discussed in the audit logging FAQ entry at , describe a structurally similar commitment made before authority is usable; SCITT's transparency-service model is a plausible realization for how Protected Validation Evidence could be committed and later verified in a production deployment.	Medium (evidence architecture)
SECDISPATCH (Security Dispatch)	SECDISPATCH is the Security Area's standing venue for routing new security proposals to an appropriate working group, research group, or other next step, rather than a venue that itself develops technical content. Given that this document's subject matter spans security, network management, and telecom-specific concerns, SECDISPATCH (or the general DISPATCH working group for topics spanning areas) is a reasonable first stop for determining which of the other groups in this table, if any, should take up sustained discussion.	Process venue (routing)

This document's normative content, including the Candidate Act representation, the Protected Enforcement Domain and Finality Sink roles, and the JSON interoperability profile in , is independent of which group ultimately takes up this work; the table above reflects venue applicability, not a change to the technical content of this specification.

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. Network authentication is not network finality. Computation is not authority.

Normative References Harvard University Informative References ITU-R ITU-T ITU-T security study work addressing expanded attack surface and trust boundaries for native-AI, cloud-native, slicing, and integrated sensing environments. 3GPP O-RAN Alliance Arrcus, Inc. Arrcus, Inc.

Frequently Asked Questions (Non-Normative) This appendix answers questions commonly raised about how this profile relates to existing telecommunications security mechanisms and to public AI-native 6G industry roadmaps. It is informational and introduces no new normative requirements.

Does this replace 3GPP TS 33.501 authentication? No. TS 33.501 establishes whether a network function or subscriber is a recognized, authenticated entity. This profile operates after that question is answered. It governs whether one specific, already-authenticated, already-computed operation may become a live network consequence. An entity can be correctly authenticated under TS 33.501 and still lack current finality authority for a particular act.

Does this replace O-RAN A1/E2/O1/O2 policy interfaces? No. O-RAN policy interfaces deliver policy, intent, and control decisions into the RAN. This profile does not compete with that delivery function. It adds a pre-effectuation gate immediately before the resulting act changes live network state, so that a policy decision, once delivered, cannot be treated as self-executing, stale-tolerant, or reusable without independent verification at the enforcement boundary.

How does scoped finality authority differ from an OAuth access token? An OAuth access token is typically a bearer credential valid for a scope and a time window; possession of the token is ordinarily sufficient to invoke the authorized operation. Scoped non-bearer finality authority is bound to one Candidate Act, one effect, one resource and subscriber scope, one policy and revocation epoch, one Finality Sink, and, where single-use is required, one consumption event. Possession of the serialized authority alone is insufficient without the corresponding protected validation state at the sink.

Why can't an upstream policy engine's ALLOW decision just be trusted? An ALLOW decision is a bearer-style signal: once issued, it is ordinarily treated as sufficient on its own, and nothing prevents it from being replayed, delayed, or acted upon after the network state it was computed against has changed. The Network-State Mismatch Denial example in shows the resulting race: a decision valid at T1 may be effectuated at T3 after topology, policy, or revocation state changed at T2. Execution finality does not distrust the upstream ALLOW; it requires that the exact act, exact effect parameters, and current state be independently re-verified at the effectuation boundary immediately before the ALLOW is permitted to become a live consequence.

How does this relate to Zero Trust Architecture (NIST SP 800-207)? Zero Trust Architecture centers on continuous verification of the requesting entity, device, and session rather than perimeter-based trust, and evaluates access per request against policy. This profile is compatible with and can consume Zero Trust access decisions as PED validation inputs. It differs in granularity and object: Zero Trust principally re-verifies whether an entity or session may proceed; execution finality re-verifies whether one specific, already-computed act and its exact effect parameters may become effective, immediately before the live consequence, and consumes the resulting authority so it cannot be reused.

Does this require a blockchain or distributed ledger? No. Protected Validation Evidence MAY be realized with hashes, signatures, MACs, sealed state, monotonic counters, or Merkle commitments, and external ledger anchoring is explicitly OPTIONAL and not required on the hot path, as stated in . This differs from architectures that require on-chain consensus for every protected transaction; this profile's hot-path verification does not depend on distributed consensus latency.

How is this different from audit logging or SIEM alerting? An audit log or SIEM alert ordinarily records that an operation occurred, after it occurred, so it can be reviewed, investigated, or alerted on. Protected Validation Evidence is committed before, or atomically with, release of finality authority, and participates in the decision of whether the operation is permitted to occur at all, as described in . Evidence-before-authority is a precondition for effectuation; a conventional audit record is a postcondition describing what already happened.

How does this relate to RATS remote attestation? Remote attestation, including Evidence and Attestation Results as described in the RATS architecture, MAY be consumed as one input predicate to Protected Enforcement Domain validation. This profile does not define, replace, or duplicate attestation verification. It defines what happens after attestation and policy inputs are available: whether the exact proposed act may cross the effectuation boundary.

How does this differ from Qualcomm's public AI-native 6G roadmap? Qualcomm's public 6G material describes a platform spanning the air interface, Giga-MIMO, spectral and energy efficiency, AI-native RAN/core/device operation, distributed compute, and wide-area sensing. That work addresses how the network computes and adapts. This document does not propose a waveform, MIMO technique, spectrum band, scheduler, or accelerator. It addresses the later, narrower transition: once such a platform has computed a proposed network operation, whether that exact operation may become effective. An explicit Non-Effective State, act-bound non-bearer authority, and independent sink-side re-verification are not established as an equivalent primitive in Qualcomm's reviewed public material.

How does this differ from Huawei's native-trustworthiness and Agentic Core Network work? Huawei's public research describes 6G native trustworthiness as a lifecycle property spanning security, privacy, resilience, multilateral trust, and continuous trustworthiness assessment, together with an Agentic Core Network vision in which AI agents autonomously detect intent and execute services. That work is broader than this document and directly motivates it: the more autonomous network execution becomes, the more consequential the question of final authority over a live effect becomes. This profile isolates one mechanically specific control point inside that broader trustworthiness problem, defined by an explicit Non-Effective State, evidence committed before authority release, and independent Finality Sink re-verification immediately before effectuation. An equivalent primitive is not established in Huawei's reviewed public material.

How does this relate to GSMA Open Gateway network APIs? GSMA Open Gateway defines standardized, monetizable network APIs (for example, quality-on-demand, number verification, and SIM-swap checks) that expose carrier capability to third-party applications. It addresses API exposure and commercial access, not whether an already-authorized API call's exact effect should cross into live network state at the moment of invocation. A Network Finality Sink MAY be placed at an Open Gateway API boundary to gate the effectuation of an invoked capability; the two are complementary rather than overlapping.

Does this profile replace existing telecom security architecture generally? No. states this directly: the architecture is an additional finality-control mechanism, not a replacement for authentication, authorization, routing, or policy procedures. It MAY consume evidence from those systems as validation inputs.

What about emergency services, lawful intercept, or operator override? This document does not yet define emergency, lawful-intercept, or operator-override consequence classes. A deployment that requires such paths to bypass finality verification places those paths outside this architecture's protection for the reasons given in . Future revisions may define these as explicit, bounded consequence classes rather than undocumented bypasses.

Carrier-Scale and Radio-Timescale Engineering FAQ (Non-Normative) This appendix addresses engineering questions expected from RAN, core-network, accelerator, O-RAN, and carrier-system engineers. Its purpose is not to claim that the current reference implementation is carrier-ready. It defines where execution finality belongs, where it does not belong, how it can compose with existing 3GPP/O-RAN mechanisms, and what remains to be demonstrated experimentally.

How can execution finality work when some RAN decisions occur much faster than the reference implementation's measured latency? The full PED, evidence, signed authority, and Finality Sink path is not intended to sit inside every PHY/MAC decision. Execution finality should be applied at the appropriate consequence boundary. O-RAN publicly describes the Near-RT RIC as operating on approximately 10 ms to 1 s timescales, while the Non-RT RIC operates above 1 second, communicating through E2 with E2 nodes including O-CU-CP, O-CU-UP, and O-DU . At least three distinct finality profiles follow from this. Profile A, non-real-time control (rApp policy, network configuration, long-lived optimization policy, slice policy, model deployment, cross-domain policy), can use a conventional PED/Finality Sink path without creating a meaningful radio-timescale issue. Profile B, near-real-time consequential control (xApp-generated E2 control, cell-level configuration, slice resource reallocation, RAN parameter change, traffic-steering change, certain beam-policy changes, network exposure actions, session/control-plane mutations), can plausibly use a DU/CU/E2-node-local Finality Sink: The local Ed25519 benchmark reported in this document's companion reference implementation showed approximately mean 0.683 ms, p50 0.632 ms, p95 0.866 ms, and p99 1.195 ms for the synthetic PED-plus-sink path. That result is encouraging for experimentation, but is not yet sufficient to establish a production Near-RT RIC performance claim, since it excludes network transport, E2 processing, real protected hardware, scheduling contention, and carrier load. A reasonable research target for this class is p99 finality processing at or below approximately 1 ms, with PED and sink colocated or edge-local and without a remote policy or ledger round trip. This is an engineering target, not an IETF, O-RAN, or 3GPP requirement, and the current p99 of approximately 1.2 ms does not yet meet it. Profile C, PHY/MAC-speed decisions, requires a different architecture. Requiring a full PED cycle, including asymmetric signing, for every low-level radio scheduling event would be inappropriate. Instead, execution finality can authorize a bounded execution envelope, for example validating a cell, slice, maximum additional PRB percentage, permitted beam set, maximum power delta, validity window, policy epoch, revocation epoch, and sink once, after which individual high-speed decisions execute locally only while remaining inside that exact previously validated envelope: The full asymmetric authority issuance does not have to occur for each micro-decision. A successful stronger or cold-path evaluation may establish a bounded policy envelope for subsequent low-latency operations, as described in ; later Candidate Acts inside the exact envelope may use faster local validation, and a change in a bound condition requires escalation again. This document's demonstration of act types such as beam change is a semantic variation and should not be read as a claim that every physical beam switch must receive a new asymmetric authority; the load-bearing finality boundary for extremely fast control may instead be authorization of the beam-control envelope followed by local scheduler operation within it. A future DU, DPU, or accelerator implementation should target a local envelope check on the order of tens of microseconds or below, potentially much less in hardware; no such performance has yet been demonstrated, and this remains a future benchmark target rather than a current performance claim.

Can this architecture scale to thousands of cells and large numbers of RRM decisions? This has not yet been demonstrated. The current benchmark is a latency experiment on a small allocation of visible CPUs. It is not evidence of carrier-wide throughput, millions of operations per second, thousands of simultaneous cells, line-rate UPF operation, or real-time DU operation, and this document states that limitation without qualification. At scale, the PED should not be a single global instance that every network action must synchronously contact; that creates an obvious bottleneck and failure domain. A carrier-oriented deployment would more likely distribute the function by region, cell, DU, site, slice, edge region, UPF, network domain, or consequence class, making the PED a logical role rather than one centralized server: Amortization also matters: instead of issuing a complete asymmetric authority for every scheduler decision, one stronger authorization can establish a bounded envelope under which many locally verified operations proceed, where those operations genuinely share the same validated limits. A credible carrier-scale evaluation still needs substantially more than the existing benchmark, at minimum: authorities issued per second per core, sink verifications per second per core, p50/p95/p99/p99.9 latency, concurrent cell count, lock and contention behavior, state-lookup cost, multi-thread and multi-process scalability, NUMA behavior, persistent-state overhead, failure and failover time, key-rotation overhead, and DPU/SmartNIC implementation throughput, evaluated against simulated loads of hundreds, thousands, and tens of thousands of simultaneously active control domains rather than one repeated synthetic operation. The current implementation proves the mechanism can be executed; it does not yet prove the mechanism can operate at national-carrier scale, and that distinction should remain explicit.

Who controls the keys in a multi-vendor O-RAN deployment? This is one of the most important unresolved production questions. In a deployment where the O-RU, O-DU, RIC, and SMO come from different vendors, the answer should not require one vendor to trust another vendor's proprietary root key. A cleaner model is an operator (or another explicitly designated trust-domain authority) controlling the root of trust through a Finality Issuing CA, with vendors implementing interoperable verification: This does not require inventing an entirely separate certificate-management ecosystem. O-RAN security work already specifies X.509 certificates, mTLS, TLS, IPsec, OAuth, and CMPv2, including CMPv2-based initial enrollment, trust-anchor initialization and update, certificate renewal, and CRL maintenance . An execution-finality profile could reuse existing operator PKI infrastructure, but the keys should remain logically separate: a transport identity key used for mTLS should not automatically become the authority to sign network finality. A production profile would need to distinguish a Transport Identity Key from a Finality Authority Signing Key, with an explicit certificate profile, key usage, and policy identifier for the latter; that profile does not currently exist in this reference implementation, which uses a local Ed25519 signer and verifier without X.509 chain validation, CMPv2 enrollment, certificate renewal, CRL/OCSP, cross-vendor trust, cross-operator trust, or hardware-backed key storage. A logical, rather than physical, home for the Finality Issuing CA and the operator's distributed PED signing keys is the O-RAN Service Management and Orchestration (SMO) function. The SMO already sits at the trust apex of an O-RAN deployment, performs lifecycle management and certificate distribution toward Near-RT RIC, Non-RT RIC, O-DU, and O-RU components, and is a natural point from which an operator could host the root Finality Issuing CA or cross-sign region-local PED signing keys for multiple RAN vendors without requiring any one RAN vendor to hold the root. For operations whose Finality Sink sits at a core or interconnect boundary rather than in the RAN, an equivalent role could be played by a 3GPP Security Edge Protection Proxy (SEPP) or Network Exposure Function (NEF) environment, both of which already terminate cross-domain or cross-operator trust and could analogously host or cross-sign PED signing keys for finality authorities whose consequence boundary is a core network function or an exposed network API rather than a RAN enforcement point. Neither placement is normatively required by this document; both are offered as plausible integration points for a production Operator Finality Trust Domain that reuses existing O-RAN and 3GPP trust apexes rather than introducing a new one. A production rotation model could generate key epoch N+1, trust N and N+1 briefly, bump the authority epoch, stop issuing under N, allow outstanding short-lived authorities to expire, and then revoke N. The architecture's existing authority-epoch, revocation-epoch, and short-authority-lifetime semantics support such rotation, but PKI lifecycle behavior still needs a normative profile.

How many bytes does this add, and can constrained links tolerate it? Using compact JSON serialization, the current example objects are approximately: a Network Candidate Act 1,369 bytes, a PED validation decision 768 bytes, a Finality Authority 1,498 bytes, a Proposed Effect 274 bytes, and a Sink Verify Request 701 bytes. A naive transport of a Candidate Act, Authority, and Sink Request together would therefore involve approximately 3,568 bytes before TLS, IPsec, E2, PFCP, or other transport overhead. That is too verbose to treat as a proposed fronthaul wire format; the present JSON profile is intentionally human-readable and useful for interoperability experiments, and should not be presented as an optimized carrier encoding. The cryptographic core is substantially smaller: an Ed25519 signature is 64 raw bytes, a SHA-256 act digest 32 raw bytes, a SHA-256 evidence digest 32 raw bytes, and an activation commitment 32 raw bytes, for 160 raw bytes before IDs, scope, epochs, lifetime, nonce, and other required semantics. The JSON representation inflates these values through field names and Base64URL encoding. A production profile could evaluate CBOR, COSE, compact binary TLV, native E2 information elements, PFCP information elements, local shared-memory descriptors, or DPU-local metadata rather than verbose JSON. The architecture does not inherently require a remote round trip to a cloud PED or external ledger for every action; this document allows hot paths using local protected state and does not require an external ledger round trip for every operation, as stated in . PED and sink can be colocated on the same host, DU, DPU, edge site, or protected network function while remaining logically separate verification boundaries, and authority metadata may be piggybacked on an existing control transaction rather than requiring a separate application-layer exchange. For high-speed RAN operation, the complete verbose Candidate Act and evidence chain should generally not be transmitted across Open Fronthaul for every low-level radio event; a bounded finality authorization followed by DU-local protected state and fast local execution is more credible. Overhead does scale with the number of genuinely subscriber-specific protected operations; that cannot be hidden. But not every packet or scheduler operation must be a distinct Candidate Act. A cell-level or slice-level bounded consequence may represent many lower-level operations, so the correct scaling unit is the protected consequence, not automatically the packet or the subscriber packet.

Doesn't 3GPP already solve freshness and replay? 3GPP already contains substantial replay and freshness protection, and this document does not claim otherwise. 5G NAS security uses NAS COUNT and performs replay checking; PFCP includes a sequence number in the message header, while session-related PFCP messages carry an SEID . F-SEID, SEID, and F-TEID primarily identify sessions, endpoints, and tunnels rather than functioning as freshness mechanisms themselves; PFCP sequence numbers provide transaction sequencing and correlation, and NAS COUNT specifically participates in replay protection. These mechanisms are valuable, and execution finality is intended to reuse them where appropriate rather than duplicate them. A sequence number answers whether a protocol transaction has already been processed; a security COUNT helps answer whether a protected message is replayed; an SEID answers which PFCP session is concerned. Execution finality asks a broader consequence question: whether this exact requested effect is authorized for this resource, this subscriber scope, this purpose, this sink, this current topology and configuration, this policy epoch, this revocation state, at this moment, and whether its finality authority has already been consumed. The distinction is protocol-message freshness versus consequence-specific current authority. A perfectly valid, authenticated, integrity-protected, fresh, non-replayed E2 or PFCP request to increase a slice allocation can still arrive after the configuration epoch or revocation epoch has changed, or after the requested parameters have been altered in transit; execution finality is intended to make those conditions load-bearing at the effect boundary. Execution finality does not require inventing a completely separate transport protocol. This document's JSON profile defines the semantic contract and does not require one specific transport; the objects may be carried over authenticated transports including operator-internal mechanisms and O-RAN control interfaces, as described in . A future realization could carry finality objects as a PFCP information element, an E2 service-model extension, a network-API object, or a local IPC object. The research contribution is the invariant that no protected consequence occurs without current act-bound finality, not the creation of another network transport.

Does the Protected Enforcement Domain become a new bottleneck, attack surface, or single point of failure? It can, if implemented badly. A centralized PED that every network action must synchronously contact would concentrate latency, availability dependence, denial-of-service exposure, key material, and state, which would be a poor deployment architecture. The PED should instead be treated as a distributed logical security role, realized as needed as a DU-local PED, an edge-region PED, a UPF-local PED, a SmartNIC/DPU PED, a secure network-function PED, a TEE-backed local validator, or an HSM-backed authority issuer, depending on consequence class. If the PED becomes unavailable, no new valid finality authority can be issued for an action requiring fresh authority, and therefore no new protected consequence can occur; timeout is not approval, and this document requires fail-closed behavior when required finality state cannot be verified, as stated in . A previously created bounded envelope may remain valid until its predefined expiry if its scope, revocation state, network state, and sink verification remain acceptable, so PED unavailability does not necessarily mean every radio function immediately stops; it means new authority cannot silently be invented because the validator is unavailable. If the PED is compromised, the Finality Sink still provides useful separation: a malicious or compromised PED cannot change the candidate, sink, scope, network epoch, or effect parameters after issuing authority without detection. This should not be overstated, however. If an attacker controls both the PED signing key and its policy inputs, and produces a valid authority for a malicious act that still satisfies the sink's independently checked conditions, the Finality Sink cannot itself determine that the PED was malicious. Production security therefore still requires a protected signing key, attestation where appropriate, key revocation, least privilege, policy separation, evidence retention, and possibly multi-validator approval for extreme-risk actions; this reference implementation does not provide Byzantine-tolerant PED consensus. If the Finality Sink is compromised, the consequence is more serious. This document treats the sink as equally load-bearing: an upstream PED cannot compensate for a Finality Sink that permits a consequence without checking authority, as stated in . If the actual consequence can bypass the sink, the finality architecture is defeated, which is why alternate-path closure, described in , is not optional.

Do the automated tests prove security? No. They prove that the current implementation behaves as intended for the tested cases, including replay, act substitution, sink substitution, epoch changes, signature tampering, missing activation, scope changes, and concurrent single-use attempts. They do not prove protocol security, the absence of implementation vulnerabilities, carrier safety, formal non-bypassability, correctness under all concurrency, hardware trust, or Byzantine resilience. A stronger research package should eventually include a formal threat model covering at least a compromised AI agent or xApp, a malicious but authenticated network function, a network attacker, stale authorization, a replay attacker, PED compromise, sink compromise, a rollback attacker, a privileged administrator, an alternate effectuation path, and state-partition failure, with an explicit statement of which components are trusted. Formal modeling with tools such as TLA+, Tamarin, or ProVerif would strengthen this work substantially.

Is there an actual hardware implementation yet? No. The current implementation is a software reference implementation that demonstrates the semantics and failure behavior. It does not demonstrate an accelerator, RAN silicon, SmartNIC, DPU, FPGA, secure enclave, O-DU accelerator, or UPF accelerator implementation from any vendor. One possible future mapping locates the PED's protected key and state in an HSM or TEE, issues a bounded authority, and places the Finality Sink on a DU, DPU, or SmartNIC performing a fast local state check alongside replay-state tracking: For ultra-fast paths, asymmetric cryptography or attestation could establish the bounded authority once, outside the tight loop, followed by a cheaper local protected check, such as a MAC, state comparison, or counter check, inside the loop for repeated bounded operations. This is a future implementation direction that has not yet been benchmarked in silicon.

The Core Engineering Distinction The most useful way to explain execution finality to an experienced RAN engineer is not that every 6G network decision must go through another cryptographic server; that framing would immediately invite a valid latency objection. The stronger formulation is that execution finality governs the transition from autonomous computation into authority. Slow or high-consequence changes may receive individual act-specific finality, while high-frequency radio operations may execute inside a previously validated, tightly bounded, and revocable finality envelope enforced locally at the relevant consequence boundary: This preserves the underlying invariant without requiring a millisecond-scale public-key operation for every PHY event.

Relationship to Existing 6G Work This framing is especially relevant because major vendors are already pushing toward increasingly autonomous networks. Qualcomm publicly describes 6G as AI-native across device, RAN, and core, including context-aware operation, dynamic QoS, autonomous adaptation, and network-defined guardrails, and has also announced agentic RAN management and autonomous-networking technology. Huawei describes broad 6G native trustworthiness covering security, privacy, and resilience, and is publicly developing an agentic 6G core architecture. This document does not claim that current telecom vendors have no AI security or guardrails; that would be indefensible. The stronger research question is: when an AI-native RAN/core system is operating autonomously inside network-defined guardrails, what common mechanism makes those guardrails technically load-bearing at the exact point where an autonomous computation becomes a live network consequence? The proposed execution-finality answer is the Candidate Act, Non-Effective State, Protected Validation, evidence commitment, scoped or bounded authority, current-state verification at the actual consequence boundary, and effect, as defined throughout this document. Existing authentication, sequence numbers, secure transport, PKI, access control, and O-RAN security mechanisms remain essential; they become inputs and foundations for this final consequence-authorization step rather than technologies this architecture attempts to replace.

Summary for IETF and Telecom Reviewers Execution finality is not proposed as another per-packet security protocol. It is a vendor-neutral consequence-authorization invariant that can reuse existing 3GPP/O-RAN identity, freshness, PKI, and transport security while making an autonomous operation technically non-effective until its current, act-specific, or bounded authority is verified at the actual effectuation boundary.