Hardware-Rooted National Control to Prevent Covert Intelligence Data Export and Unauthorized Frontier and Neural AI/Autonomous Acts in Critical Infrastructure

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.

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?"

Precise GPS is one of the clearest examples of why conventional permission models are becoming insufficient.
Historically, mobile operating systems commonly framed location as an application permission.
The security question was approximately:
"May Application A access the user's location?"
The AI-era question needs to become more precise:
"May Application A, or one of its SDKs, agents, analytics components, tools, or external processors, release this exact level of location precision to Recipient B, for Purpose C, in Jurisdiction D, at Time E?"
Those are not equivalent questions.
ENISA's mobile-application privacy work already recognized the importance of data minimisation and specifically stated that an application should not store an exact location point where a generic location area is sufficient for its functionality.
That principle becomes substantially more important when the recipient may itself be an AI system capable of combining location with many other sources.
Accordingly:
permission to collect precise GPS is not unrestricted authority to externalize precise GPS.

Consider a hypothetical scenario.
No application contains a field stating:
"Secret Laboratory X is located here."
No attacker steals a classified database.
Instead, several applications or services obtain ordinary data for apparently legitimate purposes.
One application observes device location.
Another records exercise or mobility patterns.
Another records periodic weather-location requests.
An enterprise application generates ordinary working-hour telemetry.
A mapping service provides public road and land-use information.
Individual records may appear harmless.
An AI inference system can nevertheless identify that:
a particular set of devices repeatedly converges on the same geographic area;
those devices belong to people who otherwise travel from different residential locations;
the convergence occurs primarily during working hours;
the location is absent from ordinary public business listings;
movement patterns show controlled entrance and exit points;
the same devices repeatedly travel between the location and known research, defence, technology, industrial, or government areas;
and the temporal pattern persists for months.
No individual GPS record identifies a sensitive laboratory.
The sensitive conclusion emerges from correlation.
Conceptually:
Ordinary GPS records
+
timestamps
+
mobility histories
+
public maps
+
device relationships
+
other low-sensitivity metadata
|
v
AI correlation and clustering
|
v
repeated-location pattern
|
v
relationship and activity inference
|
v
possible identification of a sensitive facility
or operational function
This is an important change in security framing.
The question is no longer only:
"Was secret information stolen?"
It is also:
"Did individually ordinary disclosures collectively make the secret inferable?"
That is why indiscriminate release of precise coordinates becomes an intelligence-security problem in addition to a conventional privacy problem.

The concern is not theoretical.
Research published by the NATO Strategic Communications Centre of Excellence has examined IoT-generated data and specifically discussed fitness devices and tracking applications that expose geolocation information.
Its case-study material describes how location information associated with ordinary fitness activity could reveal activity linked to sensitive military locations.
The NATO StratCom CoE material notes that researchers were able to determine geolocation associated with sensitive military bases from such consumer-generated data.
The security lesson is broader than any particular product or company.
The relevant chain is:
ordinary consumer activity
|
v
precise geolocation records
|
v
aggregation
|
v
pattern recognition
|
v
operationally significant intelligence
A person recording an exercise route may never intend to disclose military infrastructure.
Yet the aggregate consequence may reveal information far beyond the purpose for which the coordinate was originally generated.
A single GPS coordinate may appear harmless.
Thousands of coordinates, timestamps, routes, recurring locations, and behavioral records may expose:
sensitive facilities;
operational routines;
personnel movement;
regular working locations;
relationships between locations;
and other information useful for intelligence analysis.
The security consequence therefore arises from aggregation and inference rather than necessarily from unauthorized initial collection.

A widely reported location-tracking incident beginning in 2018 demonstrated that aggregated exercise-location data created by ordinary consumer activity could expose patterns around military installations and other sensitive locations.
The important point for this document is not the identity of the application.
The important technical fact is that individuals could legitimately generate location information for one benign purpose, while subsequent aggregation produced a security consequence very different from that original purpose.
The existence of user permission therefore did not eliminate the downstream intelligence risk.
This demonstrates why:
DATA COLLECTION AUTHORITY
must be distinguished from:
DATA-RELEASE AUTHORITY
and why:
PRECISE LOCATION ACCESS
must be distinguished from:
PRECISE LOCATION FINALITY.

The underlying possibility of correlating location information existed before modern generative and agentic AI.
What has changed is the economics of inference.
Large-scale AI systems can automate:
clustering;
temporal correlation;
relationship discovery;
mobility analysis;
anomaly identification;
multisource fusion;
semantic interpretation;
pattern comparison;
continuous surveillance analysis;
and inference across previously disconnected datasets.
A task that once required skilled analysts manually examining multiple sources can increasingly be performed automatically across very large datasets.
Modern AI can also continuously update its inference when new information arrives.
This changes the risk from occasional specialist analysis to potentially continuous machine-scale analysis.
The important privacy and security property of a data item can therefore no longer always be determined by inspecting that item in isolation.
An apparently low-risk GPS observation may become highly sensitive when combined with hundreds of thousands of other observations.
This creates what may be called an inference-finality problem:
the security significance of a disclosure may depend not only on the disclosed value, but also on what that value enables a downstream machine to infer.

Location and data-protection rules vary between jurisdictions.
This architecture therefore does not attempt to define whether the applicable legal rule should be American, European, Chinese, Indian, or another national or regional rule.
Instead, the Protected Enforcement Domain may consume the policy applicable to the relevant jurisdiction.
For example:
Candidate Act:
release precise location
Application:
App A
Purpose:
weather information
Requested Precision:
exact latitude and longitude
Recipient:
Service B
Destination Jurisdiction:
Jurisdiction Y
Applicable Policy:
Policy Epoch 481
The Protected Enforcement Domain may determine:
exact GPS:
NOT REQUIRED
city-level location:
SUFFICIENT
authorized effect:
CITY ONLY
The resulting finality authority is therefore scoped to city-level disclosure.
If the application subsequently attempts to transmit exact coordinates, the Finality Sink detects a precision mismatch and the Candidate Act remains non-effective.
Different sovereign jurisdictions can apply different policy rules while using the same technical enforcement architecture.
Thus:
USA policy may produce one scoped decision.
EU policy may produce another.
China may impose another applicable boundary.
India or another jurisdiction may impose another.
The protocol itself need not decide the law.
Its role is to prevent the selected lawful or authorized policy from becoming merely advisory once software attempts effectuation.

European Commission GDPR guidance states that data-protection principles should be implemented through technical and organizational measures from the design stage and that, by default, only data necessary for the intended purpose should be processed and accessibility should be limited.
The Commission's GDPR guidance also describes data minimisation as requiring personal data to be adequate, relevant, and limited to what is necessary for the purpose.
This provides an important policy context for precise-location enforcement.
If a service requires only regional location, there is no technical reason for the final consequence to automatically contain centimetre-level, metre-level, or otherwise unnecessarily precise coordinates merely because the device possesses them.
Execution finality provides a possible technical mechanism for moving this principle closer to the actual disclosure boundary.
Instead of merely stating:
"collect only necessary data,"
the protected system can enforce:
"release only the authorized representation at the Finality Sink."

ENISA has examined mobile-application privacy and security for many years.
Its mobile privacy guidance identifies excessive collection and sharing arising from unnecessary sensor activation and third-party libraries as privacy risks.
Significantly, its data-minimisation guidance gives the example that an application should not store the exact location point where a generic location area is sufficient.
ENISA has also previously highlighted accidental disclosure of sensitive information through GPS data and the need to scrutinize whether a mobile application's requested permissions are genuinely necessary.
These principles pre-date modern agentic AI.
AI makes their technical enforcement more important because the downstream recipient may no longer be a simple database.
It may be an inference system capable of reconstructing sensitive relationships from data fragments.
The security question therefore evolves from:
"Does this app have location permission?"
to:
"Is this application, component, recipient, destination, purpose, jurisdiction, and requested precision authorized for this particular location release?"

The NATO Cooperative Cyber Defence Centre of Excellence provides a separate but complementary security context.
Cybersecurity increasingly concerns effects on critical national infrastructure, operational technology, communications, space systems, and other systems in which a successful cyber operation can produce consequences beyond information disclosure.
Cyber Coalition 2025, supported by CCDCOE, included scenarios concerning attacks on critical national infrastructure, a power-grid control network, space-related cyber incidents, and satellite-related operational questions.
This matters to execution finality because once a command has:
changed a power-grid state;
transmitted an RF signal;
altered a network;
issued a satellite command;
caused physical actuation;
or transferred financial value,
post-event logging cannot necessarily reverse the consequence.
Authentication is therefore necessary but may be insufficient.
A trusted operator account or authenticated machine can still generate an act that is stale, revoked, out of scope, policy-inconsistent, destination-mismatched, or otherwise unauthorized at the moment of effectuation.
The security architecture therefore needs a final question:
"Is this specific consequence authorized now?"
The proposed architecture addresses that technical boundary without suggesting that NATO CCDCOE has endorsed this particular mechanism.

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.

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.

The proposed architecture treats a precise-location release as a Candidate Act.
For example:
Application or AI obtains location locally
|
v
Precise coordinates remain inside protected domain
|
v
Application / SDK / AI proposes external disclosure
|
v
LOCATION-RELEASE CANDIDATE ACT
|
v
NON-EFFECTIVE STATE
|
v
Protected Enforcement Domain
|
+-- requesting application identity
+-- requesting component / agent identity
+-- purpose
+-- recipient
+-- destination
+-- jurisdiction
+-- regulatory / sovereign policy
+-- required precision
+-- user authorization
+-- policy epoch
+-- revocation state
+-- cumulative disclosure state
+-- Finality Sink identity
|
v
Protected validation evidence
|
v
Scoped non-bearer finality authority
|
v
DATA-EGRESS FINALITY SINK
|
+-- exact GPS permitted
|
+-- coarse representation permitted
|
`-- disclosure denied

Assume an AI assistant receives the instruction:
"Find pharmacies near me."
The device possesses highly precise location information.
The AI does not necessarily require those exact coordinates to leave the device.
The PED may evaluate:
Purpose:
nearby pharmacy discovery
Requested Precision:
exact GPS
Necessary Precision:
city/local area
Destination:
external discovery service
Jurisdiction:
permitted
Decision:
exact GPS denied
coarse locality allowed
The external service therefore receives:
Balasore, Odisha
rather than an exact coordinate.
The AI can still perform the requested task.
Privacy and security are preserved because computation was allowed while unnecessary precision was not externalized.
The important principle is:
AI UTILITY DOES NOT REQUIRE UNRESTRICTED DATA AUTHORITY.

The same mechanism can enforce different policies without requiring one global privacy rule.
For example:
United States deployment:
apply applicable U.S. legal, sectoral,
enterprise, and user policy.
European deployment:
apply applicable EU and Member-State
rules, purpose limitation,
minimisation, and authorization state.
China deployment:
apply the applicable national
localization, transfer, security,
and authorization policies.
India deployment:
apply applicable Indian policy,
sectoral requirements,
enterprise rules,
and user authorization.
Other jurisdictions:
apply their corresponding
policy and regulatory state.
The protected-finality protocol does not itself decide which rule is legally correct.
It provides the enforcement mechanism by which the selected rule can remain technically binding at the point of consequence.

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.

Is the operation reaching the protected boundary for which the authority was issued?
The PED therefore does not need to make only a binary "location allowed/location denied" decision.
It may make a precision-bounded release decision.
________________________________________
4. Precision-Bounded Location Release
The architecture can support at least three outcomes.
4.1 Exact Location Allowed
Example:
Application: navigation service
Purpose: active turn-by-turn navigation
Destination: authorized navigation processor
Requested precision: exact GPS
Jurisdiction: permitted
Current authorization: valid

Result:
   EXACT_LOCATION_ALLOWED
The PED generates the applicable protected validation evidence and scoped non-bearer finality authority.
The Finality Sink verifies that authority before releasing the exact coordinates.
4.2 Exact Location Denied, Coarse Location Allowed
Example:
Application: weather application
Purpose: local weather forecast
Requested precision: exact GPS
Required precision: city/region
Destination: authorized weather service

Result:
   EXACT_LOCATION_DENIED
   COARSE_LOCATION_ALLOWED
Instead of:
20.123456, 86.123456
the Finality Sink may release only an authorized representation such as:
Balasore, Odisha
or a permitted grid, geohash prefix, region, delayed location, randomized location, or other reduced representation.
This precise-versus-normalized behavior is already expressly contemplated by your disclosure.
4.3 Location Export Denied
Example:
Application: legitimate local service
Embedded component: third-party analytics SDK
Purpose: unrelated analytics
Destination: unauthorized foreign endpoint
Requested precision: exact GPS

Result:
   DENY
The exact coordinates remain inside the protected environment.
No usable location consequence is released.
________________________________________
5. Finality Sink Enforcement
This is the important connection to your invention.
The PED deciding "deny" is not sufficient by itself.
The system must ensure that an alternate software path cannot simply ignore that decision.
Therefore, the Finality Sink is positioned at or associated with the boundary at which the protected data would actually become externally usable.
Your specification identifies possible location/data Finality Sinks including:
•       network egress interface;
•       operating-system data broker;
•       browser upload controller;
•       API gateway;
•       cloud-sync adapter;
•       backup service;
•       telemetry boundary;
•       analytics SDK boundary;
•       advertising SDK boundary;
•       file-system export layer;
•       clipboard bridge;
•       database export layer; and
•       storage-commit controller.
The enforcement sequence becomes:
Application / AI Agent
        |
        v
Requests location operation
        |
        v
Candidate Location Act
        |
        v
NON-EFFECTIVE STATE
        |
        v
Protected Enforcement Domain
        |
        +--> Verify application/component
        +--> Verify purpose
        +--> Verify requested precision
        +--> Verify destination
        +--> Verify jurisdiction
        +--> Verify authorization/revocation
        +--> Verify cumulative disclosure state
        +--> Verify Finality Sink
        |
        v
Protected validation evidence
        |
        v
Scoped non-bearer finality authority
        |
        v
FINALITY SINK
        |
        +--> exact release
        |
        +--> normalized/coarse release
        |
        `--> deny / fail closed
This is the central rule:
The location value may be computable and locally available without being externally effective.
That is exactly where your broader principle "computation is not authority" becomes useful for privacy and sovereign-data enforcement.
________________________________________
6. Why This Matters More for Agentic AI
Agentic AI substantially increases the importance of this distinction.
An ordinary application may have a relatively fixed flow. An autonomous agent may dynamically decide to:
•       call a map API;
•       invoke another agent;
•       send telemetry;
•       upload a file;
•       query a cloud service;
•       use a browser;
•       invoke an MCP tool;
•       populate a CRM;
•       contact a business;
•       create a report;
•       perform background synchronization; or
•       combine location with other data.
Therefore, simply granting an AI agent "location access" can become far broader than the original user intent.
Under the execution-finality architecture, the AI agent can possess sufficient information to reason and compute, while each consequence-bearing release remains separately governed.
Thus:
AI access to precise GPS does not imply AI authority to export precise GPS.
AI authority to use location for one tool does not imply authority to provide it to another tool.
Authorization for one destination does not imply authorization for another jurisdiction.
Authorization for one moment does not imply permanent authorization.
Authorization for coarse location does not imply authorization for exact latitude and longitude.

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;

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

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.

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.

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
              |

The location embodiment demonstrates the protocol particularly clearly.
Assume:
Application:
   NavigationApp

Requested Data:
   20.123456, 86.123456
The application having local GPS permission does not settle the export question.
The architecture performs:
NavigationApp obtains GPS locally
            |
            v
AnalyticsSDK attempts transmission
            |
            v
Candidate Data-Export Act
            |
            v
NON-EFFECTIVE STATE
            |
            v
PED
   |
   +-- Application identity
   +-- SDK identity
   +-- Purpose
   +-- Precise-location necessity
   +-- Destination
   +-- Jurisdiction
   +-- User authorization
   +-- Policy/revocation epoch
   +-- Cumulative disclosure state
   +-- Data-egress Finality Sink
            |
            v
Decision
Three results are possible.
Result A — Exact GPS Permitted
EXACT_LOCATION
20.123456, 86.123456
The PED commits the applicable protected evidence.
A finality authority explicitly scoped to exact-location release is issued.
The data-egress Finality Sink verifies it and permits the release.
Result B — Exact GPS Not Permitted but Coarse Location Permitted
The PED does not issue finality authority for the exact coordinates.
It MAY authorize a transformed representation:
COARSE_LOCATION
Balasore, Odisha
or:
REGION
Odisha
or an authorized:
grid cell
geohash prefix
randomized location
delayed location
regional representation
The original exact coordinates remain non-effective for the external destination.
Your source explicitly provides for blocking precise GPS or releasing a normalized lower-risk representation.
Result C — No Location Export Permitted
If the destination, purpose, jurisdiction, recipient, or authorization state is not permitted:
DENY
No finality authority for location release is created.
The Finality Sink therefore has no valid authority to release either exact or protected location information.
The export remains technically non-effective.

A conventional system may implement:
if app_has_location_permission:
    location = get_precise_location()
    send(location)
The execution-finality architecture separates these operations:
if app_has_location_access:
    location = obtain_location_locally()

candidate = create_candidate_export(
    data=location,
    purpose=purpose,
    destination=destination,
    jurisdiction=jurisdiction,
    requested_precision=precision
)

if validation fails:
    deny()

authority = PED.release_scoped_finality_authority(
    candidate,
    evidence
)

if FinalitySink.verify(authority, candidate) fails:
    deny()

release_only_permitted_effect(candidate)
The difference is therefore:
ACCESS PERMISSION
        !=
EXPORT AUTHORITY
and:
UPSTREAM ALLOW
        !=
FINAL EFFECTUATION
The source makes the same structural distinction between generic policy permission and act-specific, protected-state-bound, nonce-bound, epoch-bound, scope-bound, sink-bound finality authority.

The same protocol applies when the initiator is an autonomous AI agent.
For example:
User:
   "Find a nearby hospital."

Agent decision:
   call external discovery service
The AI's access to precise location does not automatically authorize transmission of that precision.
The external API call becomes a Candidate Act.
The PED may determine:
Purpose:
   nearby service discovery

Decision:
   downgrade precision
The Finality Sink may therefore authorize:
approximate region
while preventing release of:
exact coordinates
The AI remains capable of performing the user-requested task, but it does not acquire unrestricted authority to disclose the most sensitive form of the underlying data.
This implements the broader principle:
AI reasoning authority is not data-export authority.
Tool-use authority is not unrestricted consequence authority.
Access to precise GPS is not authority to disclose precise GPS.

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.

The execution-finality architecture is not limited to a particular AI model, operating system, network, accelerator, satellite platform, financial system, or data-protection regime.
The same protocol invariant applies wherever a computed or generated operation attempts to cross into an externally effective consequence:
Candidate Act
       |
       v
Non-Effective State
       |
       v
Protected Enforcement Domain
       |
       v
Protected Validation Evidence
       |
       v
Scoped Non-Bearer Finality Authority
       |
       v
Finality Sink Verification
       |
       +---- FAIL ----> No Consequence
       |
       `---- PASS ----> Permitted Consequence
The physical or logical location of the Finality Sink changes according to the consequence being controlled.
For example, the Finality Sink may be a tool dispatcher, data-egress gateway, GPU memory controller, telecom gateway, RF transmit controller, payment rail, or protected display interface. The source architecture expressly treats these as different implementations of the same execution-finality mechanism rather than independent security concepts.

These examples involve very different industries, but the technical mechanism remains unchanged.
Domain  Candidate Act   Example Finality Sink
Agentic AI      Tool/API invocation     Tool dispatcher
Precise location        GPS export      Data-egress controller
5G/6G   Network-control act     UPF/control/network boundary
GPU/AI  Accelerator output      GPU/interconnect controller
Satellite       RF/space command        RF or spacecraft controller
Finance Payment instruction     Settlement rail
Child safety    Protected rendering     Display/rendering boundary
The defining feature is not the industry.
The defining feature is the transition:
COMPUTED
    |
    v
PROPOSED
    |
    v
VALIDATED
    |
    v
FINALITY AUTHORIZED
    |
    v
CONSEQUENCE
The first four states MUST NOT be collapsed merely because upstream software has decided to allow an operation.
This is particularly important for agentic AI because a model may dynamically move among tools, network endpoints, data stores and external systems. The source applies the same finality principle to neural output, tool selection, retrieval-dependent response, memory writes, delegated agent acts and autonomous decisions.

Across the representative embodiments:
Computation is not authority.
Authentication is not finality.
Application permission is not finality.
Model approval is not finality.
Tool selection is not tool-execution authority.
Precise GPS access is not precise GPS export authority.
Network authentication is not authority for every 6G network consequence.
Successful GPU inference is not accelerator-egress authority.
Mission approval is not RF finality.
AI payment approval is not settlement authority.
Permission to deliver content is not necessarily permission to render it.
The purpose of execution finality is therefore not to replace existing identity, permission, consent, policy, model-safety, network-security or compliance systems.
Those systems MAY provide predicates to the PED.
The execution-finality layer performs a different function:
it determines whether the proposed consequence can technically become effective at the actual consequence boundary.

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.

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.

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)

    authority = ISSUE_SCOPED_FINALITY_AUTHORITY(
        candidate,
        evidence,
        current_protected_state
    )

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

    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.

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

    issued_at
    expires_at

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

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.

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.

For sensitive data, denial need not always mean that no useful operation
can proceed.
The PED MAY return a bounded downgrade.
Example:
Requested:
    PRECISE_GPS

Result:
    PRECISE_GPS = DENY
    CITY_LEVEL = ALLOW
The Candidate Act MUST then be transformed into the permitted
representation.
A new or correspondingly bound Candidate Act SHOULD represent the
authorized output:
Original:
    Latitude  = 20.123456
    Longitude = 86.123456

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.

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.

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.

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.

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.

Agent proposes:
    call external search API
The proposed API transmission is a Candidate Act:
Act-Type:
    DATA_EXPORT / TOOL_CALL

Policy:
    external service requires only coarse locality
PED decision:
EXACT GPS:
    DENY

CITY/REGION:
    ALLOW
The system constructs the permitted Candidate Act:
Location:
    Balasore, Odisha
The PED commits protected evidence and releases authority bound to:
purpose = pharmacy discovery
precision = CITY
destination = search-provider-X
sink = egress-controller-7
The Finality Sink checks the actual outgoing payload.
If the payload contains:
20.123456, 86.123456
verification fails:
EF-023 PRECISION_MISMATCH
and transmission remains non-effective.
If the payload contains only:
Balasore, Odisha
and all remaining bindings are valid, the sink consumes the authority and
permits transmission.
This illustrates the key property:
the AI can use precise information internally without acquiring
unrestricted authority to externalize that precision.

ANY REQUIRED FAILURE:
    remain NON-EFFECTIVE.
This preserves the core distinction of the source architecture: the system
does not merely decide whether software may attempt an action; it controls
whether that action can cross the actual boundary from computation into
consequence.

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.

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

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

A trusted agent may delegate to another agent, which delegates again,
creating a chain whose cumulative authority or consequence exceeds the
original task.
Example:
User
 |
 v
Agent A
 |
 +--> Agent B
       |
       +--> Agent C
             |
             +--> payment tool
             +--> external API
             +--> data export
A marketplace entry, advertised capability, endpoint response, or tool
description MUST NOT by itself be treated as authority for
consequence-bearing delegation.
The source states that discovery of an external agent does not establish
trust to receive credentials, data, payment authority, file access or
execution privileges.
An implementation MAY maintain cumulative delegation depth, resource use,
tool-call count, execution velocity or consequence state.
Where the permitted envelope is exceeded, further finality authority
SHOULD be withheld.

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.

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.

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.

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

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