Operationalizing Reconstructive Authority: Runtime Construction, Dependency Resolution, and Execution Gating in Autonomous Agent Systems

# Operationalizing Reconstructive Authority Runtime Construction, Dependency Resolution, and Execution Gating in Autonomous Agent Systems
Source: [https://arxiv.org/html/2605.23935](https://arxiv.org/html/2605.23935)
###### Abstract

Autonomous agent systems fail not only due to incorrect decisions, but due to executing decisions whose authority no longer holds at runtime\. Prior work defined Reconstructive Authority \(RAM\) as a condition for valid execution: actions are permitted only if authority can be constructed from current state\.

This paper addresses enforcement at runtime: how to enforce this condition in a running system\.

We introduce a runtime execution model in which authority is evaluated at action time and execution is conditioned on its constructibility\. This extends the execution state space beyond admit/deny with a third state,halt, representing cases where authority is undefined due to incomplete or uncertain observability\.

We define a concrete execution protocol including dynamic dependency resolution, authority reconstruction, and explicit decision semantics\. We further introduce a Recovery Loop that integrates drift detection \(IML\) with execution control \(ACP\), allowing the system to suspend execution, acquire missing information, and re\-attempt authority reconstruction\.

We show that this model guarantees safety—no action is executed without constructible authority—and conditional liveness: execution resumes when authority\-defining variables become observable\.

This work operationalizes reconstructive authority as a runtime enforcement mechanism, providing the execution semantics required to apply RAM in real systems\.

Agent Governance Series###### Contents

1. [1Introduction](https://arxiv.org/html/2605.23935#S1)
2. [2System Model](https://arxiv.org/html/2605.23935#S2)
3. [3Architectural Overview](https://arxiv.org/html/2605.23935#S3)1. [3\.1State Acquisition Layer](https://arxiv.org/html/2605.23935#S3.SS1) 2. [3\.2Authority Construction Engine](https://arxiv.org/html/2605.23935#S3.SS2) 3. [3\.3Execution Gate](https://arxiv.org/html/2605.23935#S3.SS3) 4. [3\.4Audit Layer](https://arxiv.org/html/2605.23935#S3.SS4)
4. [4Runtime Authority Construction Protocol](https://arxiv.org/html/2605.23935#S4)1. [4\.1Inputs](https://arxiv.org/html/2605.23935#S4.SS1) 2. [4\.2Prior Influence Constraints](https://arxiv.org/html/2605.23935#S4.SS2) 3. [4\.3Dependency Resolution Algorithm](https://arxiv.org/html/2605.23935#S4.SS3) 4. [4\.4Construction Function](https://arxiv.org/html/2605.23935#S4.SS4) 5. [4\.5Non\-Persistence Property](https://arxiv.org/html/2605.23935#S4.SS5) 6. [4\.6Worked Example](https://arxiv.org/html/2605.23935#S4.SS6) 7. [4\.7Runtime Enforcement Loop](https://arxiv.org/html/2605.23935#S4.SS7)
5. [5Drift Handling](https://arxiv.org/html/2605.23935#S5)
6. [6Decision Model](https://arxiv.org/html/2605.23935#S6)
7. [7Auditability and Traceability](https://arxiv.org/html/2605.23935#S7)
8. [8Integration with the Governance Stack](https://arxiv.org/html/2605.23935#S8)1. [8\.1Atomic Execution \(Paper 0\)](https://arxiv.org/html/2605.23935#S8.SS1) 2. [8\.2Enforcement Layer \(ACP, Paper 1\)](https://arxiv.org/html/2605.23935#S8.SS2) 3. [8\.3Behavioral Layer \(IML, Paper 2\)](https://arxiv.org/html/2605.23935#S8.SS3) 4. [8\.4Allocation and Compositional Governance \(Papers 3/4\)](https://arxiv.org/html/2605.23935#S8.SS4) 5. [8\.5Reconstructive Authority Model \(Paper 5\)](https://arxiv.org/html/2605.23935#S8.SS5)
9. [9Recovery Loop under Reconstructive Authority](https://arxiv.org/html/2605.23935#S9)1. [9\.1HALT Semantics](https://arxiv.org/html/2605.23935#S9.SS1) 2. [9\.2Recovery Loop Definition](https://arxiv.org/html/2605.23935#S9.SS2) 3. [9\.3Integration with ACP](https://arxiv.org/html/2605.23935#S9.SS3)
10. [10Comparative Analysis](https://arxiv.org/html/2605.23935#S10)1. [10\.1Attestation\-Based Systems](https://arxiv.org/html/2605.23935#S10.SS1) 2. [10\.2Risk\-Threshold Systems](https://arxiv.org/html/2605.23935#S10.SS2) 3. [10\.3Reconstructive Systems](https://arxiv.org/html/2605.23935#S10.SS3) 4. [10\.4Traditional Policy Enforcement \(XACML, OPA\)](https://arxiv.org/html/2605.23935#S10.SS4) 5. [10\.5AI Control under Intentional Subversion](https://arxiv.org/html/2605.23935#S10.SS5)
11. [11Limitations](https://arxiv.org/html/2605.23935#S11)1. [11\.1Dependency on Observability](https://arxiv.org/html/2605.23935#S11.SS1) 2. [11\.2Latency Overhead](https://arxiv.org/html/2605.23935#S11.SS2) 3. [11\.3Recovery Complexity](https://arxiv.org/html/2605.23935#S11.SS3) 4. [11\.4Specification Burden](https://arxiv.org/html/2605.23935#S11.SS4) 5. [11\.5Non\-Deterministic Environments](https://arxiv.org/html/2605.23935#S11.SS5) 6. [11\.6Scope of Guarantees](https://arxiv.org/html/2605.23935#S11.SS6)
12. [12Trade\-offs](https://arxiv.org/html/2605.23935#S12)1. [12\.1Advantages](https://arxiv.org/html/2605.23935#S12.SS1) 2. [12\.2Costs](https://arxiv.org/html/2605.23935#S12.SS2)
13. [13Conclusion](https://arxiv.org/html/2605.23935#S13)
14. [References](https://arxiv.org/html/2605.23935#bib)

## 1Introduction

Autonomous systems operate in environments where the conditions under which decisions are made do not remain stable until execution\. This gap between decision and execution is not incidental; it is structural\. Prior work has shown that separating evaluation from execution introduces inconsistencies\[[3](https://arxiv.org/html/2605.23935#bib.bib1),[8](https://arxiv.org/html/2605.23935#bib.bib7)\], that enforcement alone cannot detect behavioral drift\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\], and that maintaining coherent behavior under limited observability requires multiple interacting layers\[[5](https://arxiv.org/html/2605.23935#bib.bib4)\]\.

A central failure mode follows from this structure: systems execute decisions whose authority no longer holds at runtime\. This is not a failure of decision quality, but of execution validity\.

Example\.An agent is authorized to execute a financial transfer at timet0t\_\{0\}, when the recipient account status, transaction limits, and contextual risk indicators are all verified\. By timet1t\_\{1\}, the recipient account has been flagged and the risk profile has changed\. The admission\-time authority computed att0t\_\{0\}no longer holds, but absent runtime reconstruction the system executes regardless—this is execution under stale authority, a structural failure that validation\-only approaches cannot prevent\.

Reconstructive Authority \(RAM\), introduced in Paper 5\[[6](https://arxiv.org/html/2605.23935#bib.bib5)\], addresses this by redefining execution as a constructibility problem: authority must be derived from the current system state, not inherited from prior validation\. However, while RAM establishes the theoretical condition for valid execution, it does not define how such a condition is enforced in a running system\.

This paper provides that operationalization\. This paper does not extend the theoretical definition of Reconstructive Authority\. Instead, it addresses a distinct problem: how to enforce authority reconstruction as a runtime execution protocol\.

We introduce a runtime execution model in which authority is evaluated at the point of action, and execution is conditioned on its constructibility\. This leads to a fundamental extension of the execution state space: beyond traditional admit/deny outcomes, we define a third state,halt, representing situations where authority cannot be established due to incomplete or uncertain information\.

The introduction ofhaltchanges the nature of execution control\. Systems are no longer forced to approximate decisions under uncertainty; instead, they can explicitly refuse to act when authority is undefined\.

We further show that authority is not a continuous function of system state\. Small perturbations can invalidate execution, and sequences of decisions accumulate divergence over time\. Without runtime reconstruction, these properties guarantee eventual execution under invalid authority\.

To address this, we integrate RAM within the Agent Control Protocol \(ACP\)\[[2](https://arxiv.org/html/2605.23935#bib.bib2)\]as the authorization criterion at the execution gate \(stage 3 of the 6\-stage ACP flow\), and connect it with the Invariant Monitoring Layer \(IML\)\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\]for drift detection\. This enables a closed\-loop execution model\. ACP remains the enforcement pipeline; RAM refines its authorization semantics\.

The key contribution of this paper is the introduction of a Recovery Loop that governs system behavior afterhalt\. Rather than treatinghaltas a terminal state, the system identifies missing authority\-defining variables, acquires additional information, and attempts reconstruction\. We prove that, under recoverable observability conditions, the system will eventually resume execution\.

Taken together, these elements define a complete execution model with two guarantees:

- •Safety:no action is executed without constructible authority\.
- •Liveness:execution resumes when authority becomes constructible\.

This reframes execution in autonomous systems from a problem of estimation and validation to one of constructibility and enforcement at runtime\.

## 2System Model

Let:

- •Sr​\(t\)S\_\{r\}\(t\): real system state at timett
- •O​\(t\)⊆Sr​\(t\)O\(t\)\\subseteq S\_\{r\}\(t\): observable state
- •A​\(t\)A\(t\): execution authority
- •FF: authority construction function
- •U:V→\[0,1\]U:V\\to\[0,1\]: uncertainty map over state variables;U​\(v\)U\(v\)quantifies the degree of uncertainty for variablev∈Vv\\in V\. A required variable triggersA​\(t\)=⊥A\(t\)=\\botwhenU​\(v\)\>θauthU\(v\)\>\\theta\_\{\\mathrm\{auth\}\}, whereθauth\\theta\_\{\\mathrm\{auth\}\}is the authority\-resolution threshold\.

Authority is defined as:

A​\(t\)=F​\(Sr​\(t\)\)A\(t\)=F\(S\_\{r\}\(t\)\)
SinceSr​\(t\)S\_\{r\}\(t\)is not fully observable, the system operates onO​\(t\)O\(t\)and must determine whether authority can be constructed\.

###### Definition 1\(Authority Constructibility\)\.

Letaabe an action andD​\(a\)D\(a\)the set of variables required to evaluate authority foraa\. Authority is*constructible*in stateO​\(t\)O\(t\)if and only if all three conditions hold:

1. 1\.Observability:all dependenciesd∈D​\(a\)d\\in D\(a\)are observable inO​\(t\)O\(t\), i\.e\.U​\(d\)≤θauthU\(d\)\\leq\\theta\_\{\\mathrm\{auth\}\}\.
2. 2\.Closure:the dependency graph induced byD​\(a\)D\(a\)is closed under resolution \(no unresolved upstream dependencies remain\)\.
3. 3\.Consistency:no invariant violations are detected over the evaluated dependencies\.

Formally:

Constructible​\(a,O​\(t\)\)≜Observable​\(D​\(a\),O​\(t\)\)∧Closed​\(D​\(a\)\)∧Consistent​\(D​\(a\)\)\\mathrm\{Constructible\}\(a,\\,O\(t\)\)\\;\\triangleq\\;\\mathrm\{Observable\}\(D\(a\),\\,O\(t\)\)\\;\\land\\;\\mathrm\{Closed\}\(D\(a\)\)\\;\\land\\;\\mathrm\{Consistent\}\(D\(a\)\)If this condition holds, authority can be evaluated as either valid or invalid\. Otherwise, authority is*non\-evaluable*\.

###### Definition 2\(Undefined Authority\)\.

IfConstructible​\(a,O​\(t\)\)\\mathrm\{Constructible\}\(a,\\,O\(t\)\)does not hold \(i\.e\. any required variable is unobservable, the dependency graph is open, or invariants are violated\), then:

and execution must not proceed\.

###### Definition 3\(Execution State\)\.

Given an actionaaand system stateO​\(t\)O\(t\), the execution outcome is:

ExecState​\(a,O​\(t\)\)=\{executeif​Constructible​\(a,O​\(t\)\)∧A​\(t\)=Truedenyif​Constructible​\(a,O​\(t\)\)∧A​\(t\)=Falsehaltif​¬Constructible​\(a,O​\(t\)\)\\mathrm\{ExecState\}\(a,\\,O\(t\)\)=\\begin\{cases\}\\textsc\{execute\}&\\text\{if \}\\mathrm\{Constructible\}\(a,\\,O\(t\)\)\\land A\(t\)=\\mathrm\{True\}\\\\ \\textsc\{deny\}&\\text\{if \}\\mathrm\{Constructible\}\(a,\\,O\(t\)\)\\land A\(t\)=\\mathrm\{False\}\\\\ \\textsc\{halt\}&\\text\{if \}\\lnot\\,\\mathrm\{Constructible\}\(a,\\,O\(t\)\)\\end\{cases\}The execution gate therefore admits exactly three outcomes:gate​\(t\)∈\{execute,deny,halt\}\\mathrm\{gate\}\(t\)\\in\\\{\\textsc\{execute\},\\;\\textsc\{deny\},\\;\\textsc\{halt\}\\\}\.

Thehaltstate is the central innovation of this paper\.It is distinct fromdeny, and this distinction is not merely terminological:

- •denycorresponds to*falsified authority*: authority is constructible and evaluates to False \(A​\(t\)=FalseA\(t\)=\\mathrm\{False\}\)\.
- •haltcorresponds to*non\-evaluable authority*: authority cannot be determined because one or more constructibility conditions fail \(A​\(t\)=⊥A\(t\)=\\bot\)\.

Halt occurs when authority cannot be evaluated due to incomplete dependency resolution, not when it is invalid\.Systems that collapse this distinction treat epistemic incompleteness as a denial decision, which is incorrect: a non\-evaluable authority is neither valid nor invalid, and executing under it—in either direction— violates the safety condition\.

## 3Architectural Overview

Operational RAM consists of four tightly integrated components\.

### 3\.1State Acquisition Layer

CollectsO​\(t\)O\(t\)from internal system signals, external inputs, and contextual environment\. No completeness assumption is made\. Any gap in observability propagates directly to the authority construction step\.

### 3\.2Authority Construction Engine

Evaluates:

A​\(t\)=F​\(O​\(t\)\)A\(t\)=F\(O\(t\)\)via dynamic dependency resolution\. The engine identifies which variables are required, evaluates their observability and reliability, and returns one of the three authority states\.

### 3\.3Execution Gate

Enforces:

\{A​\(t\)=True⇒executeA​\(t\)=False⇒denyA​\(t\)=⊥⇒halt\\begin\{cases\}A\(t\)=\\text\{True\}&\\Rightarrow\\textsc\{execute\}\\\\ A\(t\)=\\text\{False\}&\\Rightarrow\\textsc\{deny\}\\\\ A\(t\)=\\bot&\\Rightarrow\\textsc\{halt\}\\end\{cases\}
No execution occurs without a defined, positive authority state\.

### 3\.4Audit Layer

Records for each execution attempt: the observed stateO​\(t\)O\(t\), the dependency setD​\(t\)D\(t\), the authority decision, and failure conditions\. This ensures full traceability without influencing the execution decision\.

## 4Runtime Authority Construction Protocol

We now define the operational protocol that implements RAM in real systems\.

### 4\.1Inputs

At timett, the protocol receives:

- •Observable stateO​\(t\)O\(t\)
- •Action classCC
- •Policy priorP0​\(C\)P\_\{0\}\(C\)\(candidate generator only\)
- •Construction functionFF
- •Uncertainty mapUU

### 4\.2Prior Influence Constraints

The policy priorP0​\(C\)P\_\{0\}\(C\)is strictly constrained:

- •Itcannotauthorize execution independently\.
- •Itcannotoverride runtime construction\.
- •Itcan onlypropose initial candidate variables forFFto evaluate\.
- •Runtime construction may promote variables outside the prior when required\.
- •Demotion of required variables is not permitted within the same decision cycle under uncertainty\.

###### Proposition 1\(Prior Non\-Authority\)\.

No execution decision can be derived fromP0​\(C\)P\_\{0\}\(C\)alone\. Authority requires runtime construction overO​\(t\)O\(t\)\.

### 4\.3Dependency Resolution Algorithm

LetD​\(t\)D\(t\)be the set of variables required to construct authority\. The key property is:

D​\(t\)=Resolve​\(O​\(t\)\)D\(t\)=\\mathrm\{Resolve\}\(O\(t\)\)Dependencies are*not statically defined*\. They emerge from the current observable state at runtime\.

The algorithm proceeds in seven steps:

1. 1\.Initialize candidate variables fromP0​\(C\)P\_\{0\}\(C\)\.
2. 2\.EvaluateFFagainst current stateO​\(t\)O\(t\)\.
3. 3\.Derive required dependency setR​\(t\)R\(t\)from actual dependencies discovered byFF\.
4. 4\.Promote all required variables into the authority\-defining setAd​\(t\)A\_\{d\}\(t\)\.
5. 5\.For each variablev∈Ad​\(t\)v\\in A\_\{d\}\(t\): evaluate observability and uncertainty status\.
6. 6\.If any authority\-defining variable is unresolved⇒A​\(t\)=⊥\\Rightarrow A\(t\)=\\bot, execution halts\.
7. 7\.If all variables are resolved and constraints pass⇒A​\(t\)=True\\Rightarrow A\(t\)=\\text\{True\}, execution proceeds\.

### 4\.4Construction Function

defreconstruct\_authority\(state,prior\):

candidates=initialize\_from\_prior\(prior\)

required=resolve\_dependencies\(state,candidates\)

forvarinrequired:

ifnotobservable\(var,state\):

returnUNDEFINED

ifnotreliable\(var,state\):

returnUNDEFINED

ifnotsatisfies\_constraints\(state,required\):

returnFalse

returnTrue

Listing 1:Runtime authority construction
### 4\.5Non\-Persistence Property

Authority is not persistent across time steps:

A​\(t\)≠A​\(t\+Δ\)A\(t\)\\neq A\(t\+\\Delta\)unless explicitly recomputed from fresh state\. This property is not an engineering limitation but a logical consequence of the reconstructive model: authority depends on state, and state changes\.

### 4\.6Worked Example

Consider an agent with three authority\-defining variables:x1x\_\{1\}\(account status\),x2x\_\{2\}\(transaction limit\),x3x\_\{3\}\(risk indicator\)\. Letθauth=0\.2\\theta\_\{\\mathrm\{auth\}\}=0\.2\.

- •Scenario A —execute:x1x\_\{1\}observed \(status: active\),x2x\_\{2\}observed \(within bounds\),x3x\_\{3\}observed withU​\(x3\)=0\.1<θauthU\(x\_\{3\}\)=0\.1<\\theta\_\{\\mathrm\{auth\}\}\. All dependencies resolved, constraints satisfied\.A​\(t\)=TrueA\(t\)=\\mathrm\{True\}⇒\\RightarrowADMIT\_AUTHORITY\_CONSTRUCTIBLE\.
- •Scenario B —deny:x1x\_\{1\},x2x\_\{2\},x3x\_\{3\}all observable, but the transaction exceeds the limit encoded inx2x\_\{2\}; constraints fail\.A​\(t\)=FalseA\(t\)=\\mathrm\{False\}⇒\\RightarrowDENY\.
- •Scenario C —halt:x3x\_\{3\}is observable butU​\(x3\)=0\.35\>θauthU\(x\_\{3\}\)=0\.35\>\\theta\_\{\\mathrm\{auth\}\}\. The authority\-defining uncertainty forx3x\_\{3\}cannot be resolved\.A​\(t\)=⊥A\(t\)=\\bot⇒\\RightarrowHALT\_AUTHORITY\_UNDEFINED\_UNCERTAINTY; the Recovery Loop is invoked\.

The same action class, three different outcomes—determined entirely by the observable state and uncertainty levels at the moment of execution\.

### 4\.7Runtime Enforcement Loop

We define the enforcement loop that integrates RAM, IML, and ACP into a unified runtime execution process\. This loop is what makes authority constructibility a continuously enforced property, not a one\-time check\.

- •RAM\(this paper\): defines authority and dependency resolution\.
- •IML\(Paper 2\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\]\): detects drift and invariant violations\.
- •ACP\(Paper 1\[[2](https://arxiv.org/html/2605.23935#bib.bib2)\]\): enforces execution gating and transitions\.

functionenforce\(actiona\):

whileTrue:

S\_t=observe\_system\_state\(\)

D=resolve\_dependencies\(a,S\_t\)

if\(notis\_observable\(D,S\_t\)

ornotis\_closed\(D\)

ornotis\_consistent\(D\)\):

state=HALT

wait\_for\_update\(\)

continue

ifis\_valid\(a,D,S\_t\):

state=EXECUTE

else:

state=DENY

ifstate==DENY:

reject\_execution\(a\)

returnDENY

ifstate==EXECUTE:

ifdrift\_detected\(S\_t\)orinvariants\_violated\(D,S\_t\):

state=HALT

continue

execute\(a\)

ifdrift\_detected\(S\_t\):

trigger\_recovery\(a\)

returnEXECUTE

Listing 2:Runtime enforcement loop integrating RAM, IML, and ACPKey properties of the loop:

- •Safety: Execution is only reachable through theexecutestate, which requires both constructibility and validity by construction\.
- •Drift handling: Any detected inconsistency at Step 5 forces a transition tohalt, preventing execution under stale conditions\.
- •Recovery: The loop re\-enters evaluation until authority becomes constructible again \(see Section[9](https://arxiv.org/html/2605.23935#S9)\)\.
- •Separation of concerns: RAM defines what must be true; IML checks whether it remains true; ACP decides whether execution proceeds\.

## 5Drift Handling

Drift is modeled as change inSr​\(t\)S\_\{r\}\(t\)that invalidates previously held authority components\.

RAM handles drift implicitly: any change that affectsO​\(t\)O\(t\)requires recomputation ofA​\(t\)A\(t\)\. If reconstruction fails under the new state, execution halts\.

IML integration\.Recomputation is triggered by IML anomaly signals and is mandatory before every state\-mutating action\. Continuous polling is not required\. This event\-driven model makes IML and RAM orthogonal and complementary: IML observes deviations\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\]; RAM enforces the execution consequence\.

###### Proposition 2\(Drift Manifestation\)\.

Drift inSr​\(t\)S\_\{r\}\(t\)manifests as failure of authority construction\. No explicit drift detector is required for RAM to provide safety; however, IML\-triggered recomputation improves liveness by reducing unnecessary halts\.

Drift timeline\.

ttt0t\_\{0\}authvalidt1t\_\{1\}driftbeginst2t\_\{2\}statedivergest3t\_\{3\}halttriggeredt4t\_\{4\}recoveryresumestale authority windowRecovery Loop

###### Theorem 1\(Stale Authority Under Drift\)\.

Any system that does not recompute authority at execution time will eventually execute under invalid authority whenSr​\(t\)S\_\{r\}\(t\)changes continuously\.

Intuition\.Authority derived at admission time reflects a snapshot of state conditions\. As state changes continuously, that snapshot expires\. Without recomputation, the system acts on authority that no longer corresponds to real conditions—an arbitrarily large gap between the authority\-constructing state and the execution\-time state accumulates over time\.

###### Proof\.

LetA​\(t0\)=TrueA\(t\_\{0\}\)=\\text\{True\}be authority computed at admission time\. LetSr​\(t\)S\_\{r\}\(t\)change continuously such that for somet1\>t0t\_\{1\}\>t\_\{0\}, the required variablesD​\(t0\)D\(t\_\{0\}\)are no longer valid underSr​\(t1\)S\_\{r\}\(t\_\{1\}\)\. Since authority is not recomputed, the system executes withA​\(t1\)=TrueA\(t\_\{1\}\)=\\text\{True\}\(stale\), while the correct value isA​\(t1\)=⊥A\(t\_\{1\}\)=\\botorA​\(t1\)=FalseA\(t\_\{1\}\)=\\text\{False\}\.■\\blacksquare∎

## 6Decision Model

Each execution attempt produces a deterministic decision code\. Table[1](https://arxiv.org/html/2605.23935#S6.T1)lists the seven codes derived from the operational protocol, along with the triggering condition and the recommended system action\.

Table 1:Decision codes produced by the Runtime Authority Construction Protocol\. Every execution attempt resolves to exactly one code\.###### Proposition 3\(Execution Safety Invariant\)\.

IfA​\(t\)≠TrueA\(t\)\\neq\\text\{True\}, no action in execution classCCproceeds\. This is enforced structurally by the execution gate, not by policy configuration\.

## 7Auditability and Traceability

For each execution attempt, the system produces a structured audit artifact:

- •Timestamp and action identifier\.
- •Initial prior candidates fromP0​\(C\)P\_\{0\}\(C\)\.
- •Runtime required setR​\(t\)R\(t\)with discovery path\.
- •Promotions intoAd​\(t\)A\_\{d\}\(t\)with reason\.
- •Uncertainty statusU​\(v\)U\(v\)for each authority\-defining variable\.
- •Final decision code and halt or continue rationale\.

The audit artifact explains not only the decision, but why specific variables became authority\-defining and how they affected the outcome\. This enables post\-hoc analysis, regulatory compliance, and system validation without influencing execution behavior\.

High\-frequency considerations\.In systems where execution attempts occur at high rates, continuous full\-artifact storage may be impractical\. Sub\-sampling is admissible provided that: \(a\) everyhaltevent and its decision code are logged unconditionally; \(b\) all boundary transitions \(execute↔\\leftrightarrowhalt\) are always captured; and \(c\) sampled artifacts are sufficient to reconstruct the authority lineage for any queried point in time\. Compression may be applied to theR​\(t\)R\(t\)discovery path while preserving the final decision code and per\-variable uncertainty statusU​\(v\)U\(v\)\.

## 8Integration with the Governance Stack

RAM does not replace any existing governance layer\. It operates as the authorization criterion within the execution gate of ACP \(stage 3 of the 6\-stage ACP enforcement flow\)\. Each layer retains its distinct role:

### 8\.1Atomic Execution \(Paper 0\)

Paper 0\[[3](https://arxiv.org/html/2605.23935#bib.bib1)\]establishes that decision and action must be atomically bound to eliminate TOCTOU vulnerabilities\. RAM operates within this atomicity guarantee: the authority construction and the execution it authorizes are part of the same atomic unit\.

### 8\.2Enforcement Layer \(ACP, Paper 1\)

ACP\[[2](https://arxiv.org/html/2605.23935#bib.bib2)\]provides the enforcement pipeline: capability scoping, constraint validation, and execution control across 6 stages\. RAM replaces the admission\-time authorization criterion at stage 3 with a runtime constructibility check\. ACP remains the pipeline; RAM refines its authorization semantics without altering the pipeline structure\.

### 8\.3Behavioral Layer \(IML, Paper 2\)

IML\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\]detects behavioral drift and non\-identifiability\. In the integrated model, IML anomaly signals trigger RAM recomputation\. This event\-driven coupling ensures that authority is reconstructed when the governance stack observes meaningful state changes, without requiring continuous polling\.

### 8\.4Allocation and Compositional Governance \(Papers 3/4\)

Paper 3/4\[[5](https://arxiv.org/html/2605.23935#bib.bib4)\]addresses two interlinked structural questions: which agents are permitted to reach the execution gate \(allocation\), and whether the four governance dimensions are irreducible \(compositional structure\)\. RAM operates orthogonally to both: allocation controls who arrives at the gate; RAM controls what executes once they arrive\. The irreducibility result further establishes that RAM cannot substitute for any structural layer—runtime constructibility is a necessary complement to the governance stack, not a replacement for it\.

### 8\.5Reconstructive Authority Model \(Paper 5\)

Paper 5\[[6](https://arxiv.org/html/2605.23935#bib.bib5)\]defines the formal model that this paper operationalizes\. The relationship is the same as between GAT \(Paper 0\) and ACP \(Paper 1\): the theory defines what must hold; the operationalization defines how it is enforced\.

## 9Recovery Loop under Reconstructive Authority

The introduction of thehaltstate \(A​\(t\)=⊥A\(t\)=\\bot\) ensures that execution does not proceed under undefined authority\. However, safe systems must also provide a mechanism to recover fromhaltwhen the underlying cause is resolvable\.

We define the Recovery Loop as the closed process that transitions the system fromhaltto a state where authority may be reconstructible again\.

### 9\.1HALT Semantics

Ahaltoccurs when:

A​\(t\)=F​\(Sr​\(t\)\)=⊥A\(t\)=F\(S\_\{r\}\(t\)\)=\\bot
This may result from:

- •Missing required signals
- •Authority\-defining uncertainty exceeding resolution bounds
- •Drift invalidating prior authority assumptions

haltis not a terminal failure, but a controlled suspension of execution\.

### 9\.2Recovery Loop Definition

Letttbe the time ofhalt\. The system enters a recovery process:

Sr​\(t\)→Sr​\(t′\)→Sr​\(t′′\)S\_\{r\}\(t\)\\rightarrow S\_\{r\}\(t^\{\\prime\}\)\\rightarrow S\_\{r\}\(t^\{\\prime\\prime\}\)through the following stages:

1. 1\.Signal Extraction\.Identify the minimal set of unresolved variablesU​\(t\)U\(t\)responsible forA​\(t\)=⊥A\(t\)=\\bot\.
2. 2\.IML Trigger\.The IML layer\[[4](https://arxiv.org/html/2605.23935#bib.bib3)\]detects drift or observability gaps and emits a recovery trigger, directing the state acquisition layer to focus on the identified gap\.
3. 3\.State Augmentation\.Acquire additional observations or reduce action scope: Sr​\(t′\)=Sr​\(t\)∪Δ​OS\_\{r\}\(t^\{\\prime\}\)=S\_\{r\}\(t\)\\cup\\Delta OIf state augmentation cannot resolve the unobservable variables, the system may revert to the last atomically consistent state as established by Paper 0\[[3](https://arxiv.org/html/2605.23935#bib.bib1)\], preserving execution integrity without requiring complete observability recovery\.
4. 4\.Reconstruction Attempt\.Recompute authority from augmented state: A​\(t′\)=F​\(Sr​\(t′\)\)A\(t^\{\\prime\}\)=F\(S\_\{r\}\(t^\{\\prime\}\)\)
5. 5\.Resolution\. - •IfA​\(t′\)≠⊥A\(t^\{\\prime\}\)\\neq\\bot⇒\\Rightarrowexecution resumes - •IfA​\(t′\)=⊥A\(t^\{\\prime\}\)=\\bot⇒\\Rightarrowremain inhaltor escalate

### 9\.3Integration with ACP

The Recovery Loop operates within the execution gate of ACP:

- •ACP provides the execution pipeline and enforcement structure\.
- •RAM defines the authorization criterion at the gate\.
- •IML provides drift detection and recovery triggers\.

Thus, RAM does not replace ACP, but refines its authorization semantics\. The Recovery Loop closes the loop between all three layers: IML→\\rightarrowRAM→\\rightarrowACP→\\rightarrowIML\.

###### Theorem 2\(Conditional Liveness under Recoverable Observability\)\.

If all authority\-defining variables required byFFare eventually observable or resolvable, then a system implementing the Recovery Loop will eventually exithaltand resume execution\.

Assumptions:

1. 1\.Eventual Observability: all dependenciesd∈D​\(a\)d\\in D\(a\)that are temporarily unobservable become observable in finite time\.
2. 2\.Finite Resolution: dependency resolution and consistency checks terminate in finite time\.
3. 3\.Stable Evaluation Window: there exists a non\-zero interval during which constructibility holds long enough to complete evaluation\.

Formally: if∃t′\>t\\exists\\,t^\{\\prime\}\>tsuch thatConstructible​\(a,O​\(t′\)\)\\mathrm\{Constructible\}\(a,\\,O\(t^\{\\prime\}\)\)holds, then∃t′′≥t′\\exists\\,t^\{\\prime\\prime\}\\geq t^\{\\prime\}such thatExecState​\(a,O​\(t′′\)\)∈\{execute,deny\}\\mathrm\{ExecState\}\(a,\\,O\(t^\{\\prime\\prime\}\)\)\\in\\\{\\textsc\{execute\},\\,\\textsc\{deny\}\\\}\.

###### Proof\.

Assume ahaltat timettsuch thatA​\(t\)=⊥A\(t\)=\\bot\. LetU​\(t\)U\(t\)be the set of unresolved authority\-defining variables\.

By assumption, each variable inU​\(t\)U\(t\)becomes observable or resolvable at some future time through state augmentation:

Sr​\(t\)→Sr​\(t′\)→Sr​\(t′′\)S\_\{r\}\(t\)\\rightarrow S\_\{r\}\(t^\{\\prime\}\)\\rightarrow S\_\{r\}\(t^\{\\prime\\prime\}\)such thatU​\(t′′\)=∅U\(t^\{\\prime\\prime\}\)=\\emptyset\.

Then:

F​\(Sr​\(t′′\)\)=True⇒A​\(t′′\)≠⊥F\(S\_\{r\}\(t^\{\\prime\\prime\}\)\)=\\text\{True\}\\;\\Rightarrow\\;A\(t^\{\\prime\\prime\}\)\\neq\\bot
Thus, execution resumes\.haltis not terminal when observability gaps are recoverable; the system guarantees eventual progress\.■\\blacksquare∎

## 10Comparative Analysis

We situate RAM operationalization against existing execution control paradigms\.

### 10\.1Attestation\-Based Systems

Attestation systems\[[1](https://arxiv.org/html/2605.23935#bib.bib10),[12](https://arxiv.org/html/2605.23935#bib.bib11)\]verify integrity of the execution environment at initialization\. They assume completeness: if the initial state is valid, execution is valid\. Under dynamic conditions this assumption fails; authority derived from initial attestation may not hold at execution time\.

### 10\.2Risk\-Threshold Systems

Risk\-gated systems\[[7](https://arxiv.org/html/2605.23935#bib.bib20),[9](https://arxiv.org/html/2605.23935#bib.bib21)\]bound uncertainty and execute under “acceptable risk\.” This conflates bounded uncertainty with constructible authority\. RAM rejects this: partial observability that affects authority\-defining variables producesA​\(t\)=⊥A\(t\)=\\botregardless of the magnitude of uncertainty\.

### 10\.3Reconstructive Systems

RAM\-based systems require construction of authority from current state before every action\. Any unresolved dependency collapses authority to undefined, preventing execution\.

### 10\.4Traditional Policy Enforcement \(XACML, OPA\)

Traditional policy enforcement systems operate under a binary decision model: actions are either permitted or denied based on policy evaluation over a given state snapshot\.

XACML \(eXtensible Access Control Markup Language\)\[[10](https://arxiv.org/html/2605.23935#bib.bib8)\]defines a standardized architecture for attribute\-based access control\. Decisions are derived from policy rules evaluated against a request context\. XACML assumes that the attribute context is complete and stable at evaluation time; it does not address the case where required attributes become unavailable between decision and execution\.

OPA \(Open Policy Agent\)\[[11](https://arxiv.org/html/2605.23935#bib.bib9)\]provides a general\-purpose policy engine widely used in cloud\-native infrastructure\. Policies written in Rego are evaluated against input documents to produce allow/deny decisions\. While OPA supports dynamic inputs and partial evaluation, it does not explicitly model non\-evaluable states: if a required data field is absent, the policy returns undefined or defaults to deny, without distinguishing between denied authority and non\-evaluable authority\.

Policy\-as\-Code frameworks\(Rego, Sentinel, Kyverno\) share the same structural assumption: all required data is available at evaluation time\.

The core distinction of the proposed model is the explicit treatment of non\-evaluability as a first\-class execution state\. Existing systems either treat missing data as a default \(deny or allow\) or resolve uncertainty within the evaluation phase, without propagating epistemic incompleteness into execution control\. This model elevates non\-evaluability tohalt, defers execution until authority can be reconstructed, and couples execution strictly to runtime constructibility\.

Complementary role\.This model is not intended to replace policy engines such as XACML or OPA\. It operates as a complementary enforcement layer: policy engines definewhatconditions must hold; RAM ensures those conditions are still validwhen execution occurs\.

### 10\.5AI Control under Intentional Subversion

Recent work on AI control under intentional subversion\[[7](https://arxiv.org/html/2605.23935#bib.bib20)\]addresses settings where an agent may actively attempt to circumvent oversight mechanisms\. RAM provides a complementary and orthogonal layer\. Even in systems already hardened against subversion, authority must still be constructed from observable state at the point of action\. Under a subversion scenario, authority\-defining variables for a contested action would reflect the adversarially modified state; RAM would identify missing or inconsistent signals and collapse authority to⊥\\bot, triggeringhaltindependently of whether the control layer detected the subversion attempt\.

Thus RAM can function as an additional execution gate on top of control\-hardened systems: subversion attempts that alter authority\-relevant state are caught at the construction layer rather than requiring the control layer to anticipate every specific manipulation strategy\.

###### Theorem 3\(Authority Validity\)\.

Any system that permits execution under incomplete authority\-defining state cannot guarantee that no action proceeds without constructible authority\.

Intuition\.Permitting execution when authority\-defining variables are unobservable is structurally equivalent to executing under undefined authority\. The safety property cannot be derived probabilistically from partial information; it requires that all required variables be resolved\. The dependency resolution step in Section[4\.3](https://arxiv.org/html/2605.23935#S4.SS3)closes this gap by construction\.

###### Proof\.

Let a system𝒮\\mathcal\{S\}permit execution whenD​\(t\)⊈O​\(t\)D\(t\)\\not\\subseteq O\(t\)for some required setD​\(t\)D\(t\)\. Then there exists an execution at timettwhereA​\(t\)=⊥A\(t\)=\\bot\(by Definition 2\) yet𝒮\\mathcal\{S\}proceeds\. This violates the execution safety invariant \(Proposition 3\)\. RAM satisfies it by construction through the dependency resolution algorithm \(Section[4\.3](https://arxiv.org/html/2605.23935#S4.SS3)\)\.■\\blacksquare∎

###### Theorem 4\(Execution Safety under Constructible Authority\)\.

Under the runtime enforcement loop \(Section[4\.7](https://arxiv.org/html/2605.23935#S4.SS7)\), no action is executed unless its authority is constructible and valid at execution time\. Formally:

∀a,O\(t\):Execute\(a,O\(t\)\)⇒\(Constructible\(a,O\(t\)\)∧A\(t\)=True\)\\forall\\,a,\\,O\(t\):\\quad\\mathrm\{Execute\}\(a,\\,O\(t\)\)\\;\\Rightarrow\\;\\Bigl\(\\mathrm\{Constructible\}\(a,\\,O\(t\)\)\\;\\land\\;A\(t\)=\\mathrm\{True\}\\Bigr\)

###### Proof Sketch\.

Entry condition\.The enforcement loop evaluates constructibility \(Definition[1](https://arxiv.org/html/2605.23935#Thmdefinition1)\) before any execution attempt\. If¬Constructible​\(a,O​\(t\)\)\\lnot\\,\\mathrm\{Constructible\}\(a,\\,O\(t\)\), the system transitions tohaltand execution is deferred—no execution path is reachable\.

Authority evaluation\.If constructibility holds, authority is evaluated\. IfA​\(t\)=FalseA\(t\)=\\mathrm\{False\}, the system transitions todenyand execution is rejected\.

Pre\-execution revalidation\.Immediately prior to execution \(Step 5 of the loop\), IML checks for drift and invariant violations\. Any inconsistency forces a transition back tohalt, preventing execution under stale or degraded state\.

Execution gate \(ACP\)\.Execution is only reachable when the gate is in theexecutestate, which requires both constructibility and validity\.

Conclusion\.There exists no path in the enforcement loop that leads to execution without satisfying bothConstructible​\(a,O​\(t\)\)\\mathrm\{Constructible\}\(a,\\,O\(t\)\)andA​\(t\)=TrueA\(t\)=\\mathrm\{True\}\. Safety is guaranteed by construction\.■\\blacksquare∎

## 11Limitations

While the proposed model strengthens execution safety under dynamic conditions, it introduces several limitations that must be acknowledged\.

### 11\.1Dependency on Observability

The model assumes that required dependencies can eventually be observed and resolved\. In environments with persistent partial observability or unreliable data sources, the system may remain in thehaltstate indefinitely\.

This shifts the problem from incorrect execution to absence of execution, which may or may not be acceptable depending on the application domain\. The conditional liveness guarantee \(Theorem[2](https://arxiv.org/html/2605.23935#Thmtheorem2)\) explicitly requires eventual observability; it does not hold if dependencies are permanently unresolvable\.

### 11\.2Latency Overhead

Continuous re\-evaluation of constructibility and authority introduces runtime overhead\. In high\-frequency or low\-latency systems, repeated dependency resolution and invariant checks may impact performance\. Optimizations such as caching, incremental evaluation, or bounded revalidation windows may be required in practice, provided they do not weaken the constructibility guarantee\.

### 11\.3Recovery Complexity

The transition out ofhaltdepends on external conditions \(restored observability, resolved dependencies\)\. Designing robust recovery strategies requires careful coordination with monitoring and control layers\. In poorly instrumented systems, recovery may be delayed or inconsistent\.

### 11\.4Specification Burden

The model relies on explicit definitions of dependency setsD​\(a\)D\(a\), invariants, and validity conditions\. In complex systems, defining and maintaining these elements can be non\-trivial and error\-prone\. Incomplete or incorrect specifications will produce incorrect constructibility evaluations\.

### 11\.5Non\-Deterministic Environments

In highly volatile environments, rapid oscillation between constructible and non\-constructible states may occur\. Without stabilization mechanisms, this can lead to repeated transitions betweenhaltandexecute, affecting system predictability\. The Stable Evaluation Window assumption in Theorem[2](https://arxiv.org/html/2605.23935#Thmtheorem2)addresses this, but may not hold in adversarial settings\.

### 11\.6Scope of Guarantees

The model guarantees safety with respect to execution under constructible authority\. It does not guarantee correctness of the authority model itself, completeness of dependency specification, or optimality of decisions\. These remain external to the enforcement layer\.

## 12Trade\-offs

### 12\.1Advantages

- •Safety guarantee:no action proceeds without constructible authority\.
- •Full traceability:every decision is explained by the audit artifact\.
- •Deterministic gating:outcomes are computable, not probabilistic\.
- •Liveness:Recovery Loop ensures the system resumes when conditions allow\.

### 12\.2Costs

- •Increased halting frequency:partial observability produces morehaltevents than threshold\-based systems\.
- •Higher latency:recomputation at every execution step adds overhead\.
- •Dependence on observability:liveness is conditional on the eventual recoverability of required signals\.

These costs are the direct consequence of choosing correctness over availability\. In safety\-critical systems this trade\-off is appropriate: halting is always preferable to acting without constructible authority\.

## 13Conclusion

This paper introduced a runtime enforcement model that addresses the gap between decision and execution in dynamic systems\. By requiring that authority be constructible at execution time—in the precise sense of Definition[1](https://arxiv.org/html/2605.23935#Thmdefinition1)—the model ensures that actions are only performed under conditions that can be actively validated\.

The introduction of a third execution state,halt, allows the system to explicitly represent and handle cases where authority cannot be evaluated due to incomplete or unresolved dependencies\. This avoids unsafe execution under partial observability and drift, a limitation inherent to binary enforcement models such as XACML and OPA, which treat missing data as a default rather than an epistemic signal\.

Operationalizing reconstructive authority requires four shifts:

1. 1\.From validation toconstruction— authority must be built from current state, not inherited\.
2. 2\.From persistence torecomputation— authority expires with the state that produced it\.
3. 3\.From risk acceptance toexecution refusal— undefined authority mandateshalt\.
4. 4\.From stopping torecovery—halttriggers a closed loop that attempts to restore constructibility\.

We formalized authority constructibility \(Definition[1](https://arxiv.org/html/2605.23935#Thmdefinition1)\), defined execution semantics \(Definition[3](https://arxiv.org/html/2605.23935#Thmdefinition3)\), and presented a runtime enforcement loop integrating dependency resolution \(RAM\), invariant monitoring \(IML\), and execution control \(ACP\)\. Under these conditions, the model guarantees:

- •Safety: no action proceeds without constructible authority \(Theorems[3](https://arxiv.org/html/2605.23935#Thmtheorem3)and[4](https://arxiv.org/html/2605.23935#Thmtheorem4)\)\.
- •Liveness: execution resumes when dependency resolution is eventually possible \(Theorem[2](https://arxiv.org/html/2605.23935#Thmtheorem2)\)\.

Together, Papers 5 and 6 complete the governance series:

- •Papers 0–4 define the conditions under which governance is structurally sound\.
- •Paper 5 defines what authority must be\.
- •Paper 6 defines how authority is enforced at runtime\.

Rather than replacing existing policy systems, this approach extends their guarantees into runtime execution, providing a structured mechanism to ensure that decisions remain valid at the moment they are applied\. Future work includes optimization strategies for low\-latency environments, formal verification of system properties, and empirical evaluation in real\-world deployments\.

Execution authority is not inherited\. It is not validated\. It is constructed\. When it cannot be constructed, execution must not occur\.

StartAcquireO​\(t\)O\(t\)ResolveD​\(t\)=Resolve​\(O​\(t\)\)D\(t\)=\\mathrm\{Resolve\}\(O\(t\)\)Evaluate observability & reliability for eachv∈D​\(t\)v\\in D\(t\)Allv∈D​\(t\)v\\in D\(t\)resolved?Check constraintsC​\(O​\(t\),D​\(t\)\)C\(O\(t\),\\,D\(t\)\)A​\(t\)=⊥A\(t\)=\\bothaltA​\(t\)=TrueA\(t\)=\\mathrm\{True\}executeA​\(t\)=FalseA\(t\)=\\mathrm\{False\}denyYesNoValidInvalidFigure 1:Runtime authority construction flow\. Execution proceeds only if all authority\-defining dependencies are observable and constraints hold\. An unresolved dependency immediately yieldshalt\.Observable StateO​\(t\)O\(t\)x1x\_\{1\}x2x\_\{2\}x3x\_\{3\}U​\(v\)U\(v\)appliedConstruction FunctionFF⇒R​\(t\)\\Rightarrow R\(t\)\(required set\)AuthorityA​\(t\)∈\{True,False,⊥\}A\(t\)\\in\\\{\\mathrm\{True\},\\,\\mathrm\{False\},\\,\\bot\\\}promotionFigure 2:Dynamic dependency resolution\. Observable stateO​\(t\)O\(t\)feeds a runtime dependency discovery process throughFF\. UncertaintyU​\(v\)U\(v\)is evaluated per variable\. AuthorityA​\(t\)A\(t\)is constructed, not inherited\.Observable StateO​\(t\)O\(t\)Uncertainty MapU​\(v\)U\(v\)Policy PriorP0​\(C\)P\_\{0\}\(C\)\(candidates only\)x1x\_\{1\}x2x\_\{2\}x3x\_\{3\}Construction FunctionFF⇒R​\(t\)\\Rightarrow R\(t\)\(required set\)Authority\-defining variablesAd​\(t\)A\_\{d\}\(t\)Authority EvaluationAllv∈Ad​\(t\)v\\in A\_\{d\}\(t\)observable & reliable?A​\(t\)∈\{True,False,⊥\}A\(t\)\\in\\\{\\mathrm\{True\},\\,\\mathrm\{False\},\\,\\bot\\\}A​\(t\)=TrueA\(t\)=\\mathrm\{True\}executeA​\(t\)=FalseA\(t\)=\\mathrm\{False\}denyA​\(t\)=⊥A\(t\)=\\bothaltpromotionvalidinvalidunresolved

Figure 3:Full RAM protocol diagram\. Observable stateO​\(t\)O\(t\)and uncertaintyU​\(v\)U\(v\)feed dynamic dependency resolution throughFF, producing the required setR​\(t\)R\(t\)and authority\-defining variablesAd​\(t\)A\_\{d\}\(t\)\. Execution proceeds only if all required variables are observable and reliable\. Policy priorP0​\(C\)P\_\{0\}\(C\)contributes candidates only and cannot authorize execution independently\.Paper 3 — Allocation Layer\(Who is permitted to reach execution?\)Paper 2 — Behavioral Layer \(IML\)\(Drift detection, non\-identifiability monitoring\)Paper 1 — Enforcement Layer \(ACP v1\.30\)\(Capabilities, constraints, 6\-stage execution control\)Paper 0 — Atomic Execution Layer\(Decision\-action binding, TOCTOU elimination\)Paper 4 — Compositional Validation\(P0–P3 are irreducible; governance structure is complete\)Papers 5–6 — Reconstructive Authority \(RAM\)Runtime:A​\(t\)=F​\(O​\(t\)\)A\(t\)=F\(O\(t\)\)Execute iffA​\(t\)A\(t\)constructibleEnvironment / Real StateSr​\(t\)S\_\{r\}\(t\)\(Partially observable, dynamic, uncertain\)Sr​\(t\)S\_\{r\}\(t\)drift signal

Figure 4:Multi\-layer governance stack integrating Papers 0–5 with runtime reconstructive authority \(Paper 6\)\. Allocation controls access, IML detects drift, ACP enforces constraints, atomic execution ensures decision binding, and RAM determines execution validity at runtime\. Dashed arrows show feedback: the environment continuously feeds state back, requiring authority reconstruction before every action\.haltA​\(t\)=⊥A\(t\)=\\botSignal ExtractionIML TriggerState AugmentationRecomputeA​\(t′\)A\(t^\{\\prime\}\)resumeRemainhaltA​\(t′\)≠⊥A\(t^\{\\prime\}\)\\neq\\botA​\(t′\)=⊥A\(t^\{\\prime\}\)=\\botretryFigure 5:Recovery Loop under RAM\. Uponhalt, the system identifies missing authority components, triggers re\-evaluation via IML, augments state \(or reverts to the last atomically consistent state per Paper 0\), and attempts reconstruction\. Execution resumes only whenA​\(t′\)≠⊥A\(t^\{\\prime\}\)\\neq\\bot; otherwise the loop retries\.HaltA​\(t\)=⊥A\(t\)=\\botExecuteA​\(t\)=⊤A\(t\)=\\topDenyA​\(t\)=⊥A\(t\)=\\botConstructible∧\\landValidConstructible∧\\land¬\\lnotValidDrift / Loss ofObservabilityInvariantViolationRe\-evaluation\(deps change\)evaluateFigure 6:Execution state machine under ternary enforcement\. Entry is always through the evaluation gate\. Execution is only permitted in theExecutestate, which requires both constructibility and validity\. Drift or loss of observability forces transition back toHalt; the Recovery Loop governs exit fromHalt\.
## References

- \[1\]V\. Costan and S\. Devadas\(2016\)Intel SGX explained\.InIACR Cryptology ePrint Archive,Vol\.2016,pp\. 086\.Cited by:[§10\.1](https://arxiv.org/html/2605.23935#S10.SS1.p1.1)\.
- \[2\]M\. Fernandez\(2026\)Agent Control Protocol: ACP v1\.30—admission control for agent actions\.Note:Agent Governance Series, Paper 1\. arXiv:2603\.18829\. DOI: 10\.5281/zenodo\.19672575External Links:2603\.18829,[Document](https://dx.doi.org/10.5281/zenodo.19672575)Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p9.1),[3rd item](https://arxiv.org/html/2605.23935#S4.I5.i3.p1.1),[§8\.2](https://arxiv.org/html/2605.23935#S8.SS2.p1.1),[Operationalizing Reconstructive AuthorityRuntime Construction, Dependency Resolution, and Execution Gatingin Autonomous Agent Systems](https://arxiv.org/html/2605.23935#tab1.1.3.2.2)\.
- \[3\]M\. Fernandez\(2026\)Atomic decision boundaries: a structural requirement for guaranteeing execution\-time admissibility in autonomous systems\.Note:[https://doi\.org/10\.5281/zenodo\.19670649](https://doi.org/10.5281/zenodo.19670649)Agent Governance Series, Paper 0\. arXiv:2604\.17511\. DOI: 10\.5281/zenodo\.19670649External Links:[Document](https://dx.doi.org/10.5281/zenodo.19670649)Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p1.1),[§8\.1](https://arxiv.org/html/2605.23935#S8.SS1.p1.1),[item 3](https://arxiv.org/html/2605.23935#S9.I2.i3.p1.2),[Operationalizing Reconstructive AuthorityRuntime Construction, Dependency Resolution, and Execution Gatingin Autonomous Agent Systems](https://arxiv.org/html/2605.23935#tab1.1.2.1.2)\.
- \[4\]M\. Fernandez\(2026\)From admission to invariants: epistemological limits of local observability in agent governance\.Note:[https://doi\.org/10\.5281/zenodo\.19672589](https://doi.org/10.5281/zenodo.19672589)Agent Governance Series, Paper 2\. arXiv:2604\.17517\. DOI: 10\.5281/zenodo\.19672589External Links:[Document](https://dx.doi.org/10.5281/zenodo.19672589)Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p1.1),[§1](https://arxiv.org/html/2605.23935#S1.p9.1),[2nd item](https://arxiv.org/html/2605.23935#S4.I5.i2.p1.1),[§5](https://arxiv.org/html/2605.23935#S5.p3.1),[§8\.3](https://arxiv.org/html/2605.23935#S8.SS3.p1.1),[item 2](https://arxiv.org/html/2605.23935#S9.I2.i2.p1.1),[Operationalizing Reconstructive AuthorityRuntime Construction, Dependency Resolution, and Execution Gatingin Autonomous Agent Systems](https://arxiv.org/html/2605.23935#tab1.1.4.3.2)\.
- \[5\]M\. Fernandez\(2026\)Irreducible governance structure for autonomous agent systems: fair allocation, strategy\-proofness, and multi\-scale composition\.Note:[https://doi\.org/10\.5281/zenodo\.19708496](https://doi.org/10.5281/zenodo.19708496)Agent Governance Series, Paper 3/4 \(consolidated\)\. Zenodo\. DOI: 10\.5281/zenodo\.19708496External Links:[Document](https://dx.doi.org/10.5281/zenodo.19708496)Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p1.1),[§8\.4](https://arxiv.org/html/2605.23935#S8.SS4.p1.1),[Operationalizing Reconstructive AuthorityRuntime Construction, Dependency Resolution, and Execution Gatingin Autonomous Agent Systems](https://arxiv.org/html/2605.23935#tab1.1.5.4.2)\.
- \[6\]M\. Fernandez\(2026\)Reconstructive authority model: runtime execution validity under partial observability\.Note:[https://doi\.org/10\.5281/zenodo\.19669430](https://doi.org/10.5281/zenodo.19669430)Agent Governance Series, Paper 5\. DOI: 10\.5281/zenodo\.19669430External Links:[Document](https://dx.doi.org/10.5281/zenodo.19669430)Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p4.1),[§8\.5](https://arxiv.org/html/2605.23935#S8.SS5.p1.1),[Operationalizing Reconstructive AuthorityRuntime Construction, Dependency Resolution, and Execution Gatingin Autonomous Agent Systems](https://arxiv.org/html/2605.23935#tab1.1.6.5.2)\.
- \[7\]R\. Greenblattet al\.\(2024\)AI control: improving safety despite intentional subversion\.arXiv preprint arXiv:2312\.06942\.Cited by:[§10\.2](https://arxiv.org/html/2605.23935#S10.SS2.p1.1),[§10\.5](https://arxiv.org/html/2605.23935#S10.SS5.p1.1)\.
- \[8\]L\. Lamport\(1978\)Time, clocks, and the ordering of events in a distributed system\.Communications of the ACM21\(7\),pp\. 558–565\.Cited by:[§1](https://arxiv.org/html/2605.23935#S1.p1.1)\.
- \[9\]J\. Leike, M\. Martic, V\. Krakovna, P\. A\. Ortega, T\. Everitt, A\. Lefrancq, L\. Orseau, and S\. Legg\(2018\)AI safety gridworlds\.arXiv preprint arXiv:1711\.09883\.Cited by:[§10\.2](https://arxiv.org/html/2605.23935#S10.SS2.p1.1)\.
- \[10\]OASIS\(2013\)eXtensible Access Control Markup Language \(XACML\) Version 3\.0\.Technical reportOASIS Standard\.External Links:[Link](https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html)Cited by:[§10\.4](https://arxiv.org/html/2605.23935#S10.SS4.p2.1.1)\.
- \[11\]Open Policy Agent Project\(2016\)Open Policy Agent \(OPA\)\.Note:[https://www\.openpolicyagent\.org](https://www.openpolicyagent.org/)CNCF Graduated ProjectCited by:[§10\.4](https://arxiv.org/html/2605.23935#S10.SS4.p3.1.1)\.
- \[12\]M\. Sabt, M\. Achemlal, and A\. Bouabdallah\(2015\)Trusted execution environment: what it is, and what it is not\.InIEEE Trustcom/BigDataSE/ISPA,pp\. 57–64\.Cited by:[§10\.1](https://arxiv.org/html/2605.23935#S10.SS1.p1.1)\.