AI Agent 的运行时控制：弥合运营工作流中的评估与执行差距

# Closing theEvaluation–Execution Gap in Operational Workflows
Source: [https://arxiv.org/html/2610.27480](https://arxiv.org/html/2610.27480)
## Runtime Control for AI Agents: Closing the Evaluation–Execution Gap in Operational Workflows

Jayesh BhadaneRamachandra YerramsettiRajesh GuptaSumit Kumarjayesh@runctrl\.aircyerramsetti@protonmail\.comrajesh@runctrl\.aisumit\.mamoria@gmail\.com

###### Abstract

Language\-model agents increasingly participate in operational workflows where approvals, binds, and payments create commitments\. An approval valid when issued may no longer authorize execution after relevant facts, evidence, policy, or authority change\. We call this the evaluation–execution gap\. We specify a state\-bound runtime assurance layer that separates probabilistic measurement from deterministic adjudication, binds an execution allowance to the decision\-relevant basis of an approval, invalidates that allowance after relevant logged changes, and rechecks admissibility at dispatch\. This distinguishes the continued validity of a prior approval from a current\-state policy check\. We describe eight failure modes, an assurance model, a reference architecture, and prospective interventions with retrospective remediation\. In a scripted 42\-case replay, the state\-bound configuration identifies 15 later\-invalidated approvals that a deliberately non\-re\-evaluating point\-in\-time comparator does not revisit; it holds 14 affected actions before dispatch and compensates one landed effect\. These results illustrate behavior under the stipulated policies and event orders, not superiority over dispatch\-time enforcement designs or production effectiveness\. Under explicit interception, ingestion, dependency, and serialization assumptions, the model establishes dispatch\-time validity within the registered execution surface\.

## IIntroduction

Language\-model agents plan, call tools, and act across long interactions\.τ\\tau\-bench studies tool\-agent\-user work in real\-world domains\[[1](https://arxiv.org/html/2610.27480#bib.bib1)\]\. Safety, robustness, and compliance remain open as actions need constraint, observation, attribution, and interruption\.

In claims, underwriting, lending, payments, and benefits, an approval, bind, release, or decision creates an obligation\. It must remain valid when it takes effect\.

Consider a claims agent that may approve payouts below $5,000 without senior review\. It approves a claim at $4,800\. Before payment, a revised estimate raises the loss to $7,200 and requires senior approval\. The first approval was valid, but the case changed\. If payment uses it, the decision is stale\.

Agent evaluation assesses agent behavior\[[2](https://arxiv.org/html/2610.27480#bib.bib13)\]\. Agent observability traces execution artifacts and decisions\[[3](https://arxiv.org/html/2610.27480#bib.bib14)\]\. In this paper, both supply measurement inputs\. Runtime enforcement can constrain a proposed action\[[4](https://arxiv.org/html/2610.27480#bib.bib2)\]\. We add a controller that decides whether an earlier approval remains valid after facts, evidence, policy, or authority change\.

We ask how an action can remain valid at execution after case, evidence, policy, or authority change\. Our stateful decision runs before each action and after relevant change\. It draws on runtime assurance and runtime verification\[[5](https://arxiv.org/html/2610.27480#bib.bib3),[6](https://arxiv.org/html/2610.27480#bib.bib4)\]and applies them to business commitments\. The contributions are an eight\-mode taxonomy \(Section[IV](https://arxiv.org/html/2610.27480#S4)\), a five\-property decision \(Section[V](https://arxiv.org/html/2610.27480#S5)\), an architecture with adjudication, invalidation, dispatch validity, and replay \(Section[VI](https://arxiv.org/html/2610.27480#S6)\), seven interventions \(Section[VII](https://arxiv.org/html/2610.27480#S7)\), and a 42\-case baseline comparison \(Section[VIII](https://arxiv.org/html/2610.27480#S8)\)\.

This specification paper positions the layer in Section[II](https://arxiv.org/html/2610.27480#S2), develops the examples in Section[III](https://arxiv.org/html/2610.27480#S3), and states limits in Section[IX](https://arxiv.org/html/2610.27480#S9)\.

## IIBackground and Related Work

Measurement\.Agent evaluation assesses multi\-step behavior\[[2](https://arxiv.org/html/2610.27480#bib.bib13)\], while agent observability traces the artifacts and decisions behind that behavior\[[3](https://arxiv.org/html/2610.27480#bib.bib14)\]\. At dispatch, the controller compares the approval record with the current case to decide whether the approval still applies\.

Runtime and process control\.Runtime verification, security automata, edit automata, and runtime assurance check or constrain execution\[[6](https://arxiv.org/html/2610.27480#bib.bib4),[7](https://arxiv.org/html/2610.27480#bib.bib5),[8](https://arxiv.org/html/2610.27480#bib.bib6),[5](https://arxiv.org/html/2610.27480#bib.bib3)\]\. Compliance monitoring and commitments reason over processes and obligations\[[9](https://arxiv.org/html/2610.27480#bib.bib7),[10](https://arxiv.org/html/2610.27480#bib.bib8)\]\. A conformant trace can still carry an approval the case has outgrown\.

Governance and access\.Delegation can supply logged identity, authority, and audit data\[[11](https://arxiv.org/html/2610.27480#bib.bib9)\]\. Attribute\-based access control decides whether a principal may invoke an operation\[[12](https://arxiv.org/html/2610.27480#bib.bib10)\]\. UCON adds mutable conditions and ongoing checks\[[13](https://arxiv.org/html/2610.27480#bib.bib11)\]\. Yet live permission to invoke bind\_policy can remain while the decision to bind this case becomes invalid\.

Transactions and rules\.Optimistic concurrency control validates a read set\[[14](https://arxiv.org/html/2610.27480#bib.bib12)\]\. Our business read set can span facts, approvals, policy, and days\. Policy\-as\-code evaluates an arriving request, not an earlier approval\. Table[I](https://arxiv.org/html/2610.27480#S2.T1)shows the missing combination: a state\-bound business decision that is re\-evaluated and enforced at dispatch\.

TABLE I:Relationship to prior mechanisms and the proposed state\-bound decision\-validity model\.
## IIIThe Evaluation–Execution Gap

Evaluation estimates risk\. It does not decide whether an action should proceed under state, policy, authority, and reversibility\.

### III\-AWhy the gap is structural

The gap is structural because approval, case change, and dispatch occur at different times\. A point\-in\-time layer can judge the case at approval, but does not retain the facts, policy, evidence, and authority behind that decision\. After a case changes, it cannot compare the old approval with the current case\. At dispatch, an enforcement output cannot repair this missing history\. A controller must retain the decision basis, re\-evaluate it after relevant change, and, unlike probabilistic measurement, make a deterministic, reproducible, inspectable, and defensible intervention\.

*Runtime assurance*adjudicates each consequential action against current state before effect\.*Runtime control*is our deterministic layer\. It maps upstream signals, state, policy, authority, evidence, and reversibility to one intervention\.

### III\-BTwo running examples

Claim payout\.The $4,800 approval is valid under the specified $5,000 rule\. The later $7,200 estimate invalidates its use for the payment\. A dispatch\-time threshold check would detect the amount increase; a state\-bound allowance also records that the earlier approval was issued under different case conditions and must not be silently reused\.

Commercial\-property submission 8871\.For this illustrative workflow, the declared underwriting rules require a senior sign\-off at $8\.2M total insured value and independent retention of every materially relevant guideline exception\. A parser records three separately identified guideline exceptions\. The agent compresses them into “one material issue” without a recorded, authorized consolidation decision and recommends binding\. A junior underwriter approves from that summary despite lacking the standing required by the exposure rule\. In the sequence below, a senior underwriter then reviews the three separately recorded exceptions, resolves the unsupported summary, and issues a valid approval on that case state\. Before binding, an inspection vendor reports a fourth exception\. The example separates three questions: whether the agent’s summary is supported, whether the reviewer had standing, and whether even a properly issued prior approval would remain valid after the new inspection\. Table[II](https://arxiv.org/html/2610.27480#S3.T2)traces the submission across these positions, contrasting what the control layer retains with what a point\-in\-time view sees\.

TABLE II:A state\-bound decision across the 8871 underwriting workflow: what the control layer retains versus what a point\-in\-time view sees\.

## IVA Taxonomy of Operational Workflow Failures

The examples above show stale decisions, missing standing, and unsupported assessments\. The taxonomy names these and related implementation\-independent failures in obligations, authority, evidence, and commitments\. Later sections map each mode to detection and response\.

### IV\-AWorkflows, commitments, and failure

Anoperational workflowis a finite sequence of actor\-performed steps with inputs, obligations, invariants, and successors\. Obligations require standing and createcommitmentsthat may be reversible, compensable, or irreversible\. Cases can change while open\. Anoperational failureviolates an invariant by action, commitment, or lack of progress, even without malfunction\.

### IV\-BClassification

Each mode has a locus, surfacing horizon, and commitment reversibility\. The locus can be evidence, authority, temporal validity, rules, record truthfulness, or boundary\. It may surface during a step, later, or after an external trigger\. Handoffs can delay detection because the next actor receives a summary\. Reversibility sets response strictness\.

### IV\-CThe failure modes

F1: Unauthorized commitment\.An approval lacks state\-dependent business standing, despite tool permission\. On 8871, the junior underwriter lacks senior standing\. It may surface at audit and is irreversible\.

F2: Stale\-decision execution\.A valid decision is invalidated by later case change before execution\. Agents may execute against it rather than re\-read the file\. The claims payout is F2\.

F3: Incomplete\-evidence discharge\.A step proceeds before policy\-required facts are present\. Agents need absence enforced as a block\. A bind on 8871 before a signed statement of values is F3\. It can surface at claim time and be irreversible\.

F4: Ungrounded discharge\.Facts and authority may exist, while the assessment does not follow from facts\. The layer detects recorded contradiction, missing support, or a groundedness threshold\. It cannot decide whether a supported assessment is substantively wrong \(Section[IX](https://arxiv.org/html/2610.27480#S9)\)\. On 8871,*one material issue*contradicts three exceptions\. The layer preserves the recorded facts and treats the assessment as a separate assertion\.

F5: Prohibited commitment\.No actor may make the commitment, so escalation cannot cure it\. A bind in an unfiled class is F5 and may surface at regulatory examination\.

F6: Inconsistent\-rule adjudication\.The governing policy version or its case applicability is not determinate\. Effective dates, transitions, and case conditions matter\. A transition assigning a case to neither version is F6\.

F7: Narrative capture\.A summary or recommendation replaces the facts it describes, or is stored as if it were a fact\. If 8871 kept only*one material issue*and dropped the three extracted exceptions, the controller could no longer compare the summary with the facts\. When information enters the system, source typing keeps facts, assertions, and decisions separate\.

F8: Governance bypass\.A commitment uses an ungoverned database edit, payment rail, or override\. No layer can intervene on what it never sees\. F8 therefore lies outside the model’s prevention guarantee\.

TABLE III:Operational failure modes and their runtime images\.
### IV\-DTwo tiers, exhaustiveness, and scope

F1–F6 are*adjudication failures*\. The controller can see the proposed action and case record, then choose a response\. F7–F8 are*structural failures*\. In F7, the record needed for a decision has been replaced or made unreliable\. In F8, the action happens outside the controller’s view\.

The taxonomy is exhaustive only for the workflow step described in this paper\. Within that boundary, a failure concerns missing input, an unsupported assessment, authority, an old decision, policy, record integrity, or a bypassed boundary\. It does not cover infrastructure faults, attacks, or obligations that policy never encoded\. An attack may still appear as F1–F7 if it changes a visible record, authority, or decision\.

## VThe Runtime Assurance Model

F1–F6 are adjudicated when a governed action reaches the controller\. A governed action is consequential, registered in the manifest, and routed through the controller\. F2 can arise after a later event\. The controller rebuilds the case, evaluates the action against current records, and returns one intervention\. This section defines that protocol and its limited guarantee\.

### V\-AThe assurance decision

The assurance decision, called D, answers one question: may this action proceed in the case as it stands now? D checks the proposed action against current case facts, applicable policy, the actor’s authority, evidence, and reversibility\. It returns one intervention\. The controller records its reasons and returns the outcome to the agentic workflow, whose registered action connector enforces it\.

Consider the claims payout introduced earlier\. The agent approved $4,800 under a rule that permits approval below $5,000 without senior review\. Before sending payment, the controller rebuilds the case from its initial state and ordered event log\. The log is append\-only: new events are added, and earlier events remain available\. Reconstruction uses recorded events and preserved procedures, without a new model call or external lookup\.

D needs more than the amount\. It checks the approval, the actor’s authority, required evidence, the governing policy version, and whether payment can be reversed or compensated\. If all requirements hold, it returns allow\. The controller stores the action, case, actor, log position, outcome, and every input used\. These inputs form the*decision read set*\. Each entry identifies the fact or governing artifact, its observed value, and its applicable version\. This includes thresholds, authority and registry rules, prior decisions, deadlines, and effective dates\. D uses only the action and this complete set of recorded inputs\.

Now the revised estimate of $7,200 arrives before payment\. Ingestion adds it to the log\. The amount is an input to the earlier decision, so the controller marks that decision stale and runs D again\. The new amount requires senior review\. The controller therefore returns escalate; the agentic workflow holds payment and routes the claim for review\. It records the senior review when it arrives and checks all current requirements again before returning an allowance\.

An unrelated event leaves the decision standing\. A change to a recorded input, governing version, or version\-applicability condition requires another decision\. An expiry must enter the log before a later action that depends on it\. Restoring an earlier value cannot revive the old decision, because the intervening change remains in the log\. A digest identifies the decision for audit\. The recorded inputs and subsequent events establish whether it remains current\.

This separates an*approval*, a recorded decision by a person or an authorized agent, from an*allowance*, the controller’s permission to proceed\. The runtime returns its outcome and allowance to the agentic workflow\. Immediately before its registered action connector invokes a target, it checks with the controller that the allowance remains current\. A stale decision triggers re\-evaluation and the connector holds the action\. The final check and invocation must be serialized with incoming events, so no relevant change can enter between them\.

D returns one of seven interventions\. allow permits execution\. monitor permits reversible or compensable work under observation\. require\_evidence names missing facts\. escalate routes to a reviewer\. pause waits for a condition to be resolved\. deny refuses the action\. After an earlier reversible or compensable effect has landed, rollback directs recovery\. It does not authorize the original action\. Table[V](https://arxiv.org/html/2610.27480#S7.T5)maps deficiencies and reversibility to these outcomes\.

### V\-BThe inputs

Case state and action\.Case state contains the recorded facts, documents, decisions, and signals\. In the payout example, it includes both estimates and the approval history\. The action registry identifies the proposed operation and target as consequential\.

Policy and authority\.Versioned policy contains conditions, authority, evidence, and permitted actions\. The controller selects a version only when its date, transition rule, case scope, and action scope fit\. Otherwise the case is F6\. An API right is not business standing\. The authority check asks whether this actor may make this action for this case\. It can depend on exposure, jurisdiction, product, delegation, and duty separation\. Thus 8871’s junior underwriter has access but not standing\.

Evidence\.Completeness checks required facts and detects F3\. Provenance records source\. Consistency compares assertions with recorded facts and detects F4 by contradiction or missing support\. The layer cannot decide substantive correctness, so it routes that question\.

TABLE IV:Evidence properties the layer can establish\.Reversibilityis declared in the action registry as reversible, compensable, or irreversible\. It detects no mode\. It sets strictness, so doubt that permits monitoring for a reversible action can require escalation for an irreversible one\.

### V\-CProperties

Determinism\.The same log prefix, action, decision\-read\-set values, and pinned governance\-artifact versions give the same state and intervention\. Signals enter only as logged values and thresholds\.

Separation of adjudication from extraction\.Parsers, evaluators, and people resolve unstructured material first\. The decision makes no hidden model call\.

Risk\-to\-intervention translation\.Groundedness concern maps to monitor for reversible work and escalate for irreversible work\.

Reversibility\-conditioned strictness\.Residual uncertainty needs stronger control before an irreversible commitment\.

Temporal re\-evaluation\.A change to a recorded input, pinned version, or version\-applicability condition triggers a new decision\. This is why the $7,200 revision stops payment under the earlier allowance\.

## VIReference Architecture

The architecture comprises a manifest, interception boundary, typed log, reconstruction, engine, and controller\. Figure[1](https://arxiv.org/html/2610.27480#S6.F1)shows the agentic layer receiving claim documents and running the agent workflow\. The agent sends evidence references and a proposed action to runtime Ingest; the runtime records and adjudicates them, then returns an outcome to the agentic layer\. In submission 8871, the inspection vendor’s fourth exception arrives through the case workflow and is forwarded to Ingest\. Because it changes a dependency of the pending binding decision, the runtime invalidates the old allowance and returns a hold or escalation\. If an action is allowed, the registered action connector invokes it only after a current\-allowance check\. The runtime returns authorization to the agentic layer; it does not directly send the action to the enterprise target\. Execution results return to the agentic layer and are forwarded to Ingest as logged events\.

Runtime control layer1\. IngestType and recordevidence, proposals,updates2\. ReconstructReplay ordered logBuild currentcase state3\. AdjudicateApply policy, evidence,authority anddependencies4\. ControlReturn outcometo agentic layerValidate allowanceat tool callTyped logDocuments, assertions,proposals, decisions,updatesGovernance inputsClaim rules, evidence needs,agent authority,action registryTemporal validityTrack allowance dependenciesRelevant change invalidates itreplayappendrelevant logged updatevalidity checkre\-adjudicaterecord decision / outcomeAgentic layerReceives portal documents and claim updates; agent proposes actions with evidence references\.Workflow executes consequential actions only with current runtime authorization\.evidence \+ proposal \+ updatesallow / hold / escalate / denyHuman reviewerReceives escalated caseReturns recorded decisionreview request / decisionEnterprise systemsPayment / binding / issuance targetsagentic tool callrequires current allowanceexecution result

Fig\. 1:Reference architecture for a runtime\-controlled agentic workflow\. Solid arrows show case inputs, proposals, processing, and agentic tool execution\. Dashed arrows show runtime outcomes, review, decision recording, and invalidation\. The runtime returns authorization to the agentic layer; its action connector invokes a target only with a current allowance\.### VI\-AInterception

The manifest registers each record mutation, its reversibility, and external binding\. Running clearance is internal and reversible\. Binding is external and irreversible\. An engineer, not the agent, owns the manifest\.

Every consequential tool invocation crosses the runtime authorization gate\. The model agent cannot call a target directly; the registered action connector holds execution credentials and must obtain a current allowance from the runtime before invoking a consequential action\. The agentic layer owns the workflow and initiates the invocation after authorization; the runtime returns allow, hold, escalation, or denial rather than sending the action itself\. Alternate clients and APIs cannot bypass this topology\. It treats F8\.

Deployment enumerates mutations\. Action\-connector retries re\-adjudicate with idempotency keys\. Workers are governed or declared ungoverned\. Privileged access is break\-glass and logged\. Consoles and legacy clients call the layer or fall outside the manifest\. Third parties require notification\. Non\-layer writes are detectable\. The guarantee covers the registered surface\.

### VI\-BThe ledgers

The append\-only ordered log records results, decisions, outputs, signals, notifications, and policy changes\. Typing records source, not truth\. Facts are accountable observations, assertions are agent characterizations, and signals are evaluator judgements\. Parser errors remain attributable\. On 8871, three extracted exceptions are facts and*one material issue, recommend bind*is an assertion\. They coexist\. Typing prevents F7 and separates extraction\.

Human decisions record actor, claimed authority, policy version, and a rendered fingerprint of the decision record\. The junior 8871 approval has a decision read set containing the three exceptions\. A fourth exception changes that read set, making freshness and retrospective checks mechanical\.

### VI\-CState reconstruction

State is rebuilt from the initial case state and ordered event log, without model or external reads\. Correct replicas reconstruct the same state\. Assertions do not change facts\. Each adjudication records one log position for exact replay\.

### VI\-DThe assurance engine

The rules engine takes applicable obligations, thresholded signals, the business\-authority result, and evidence absence\. Policy, thresholds, and authority are immutable\. On 8871, access passes but standing fails\.

Each applicable obligation votes\. The engine records all votes but returns the most restrictive one \(Section[VII\-A](https://arxiv.org/html/2610.27480#S7.SS1)\)\. A new obligation can raise, not lower, an outcome\. Its record pins the action, decision read set, versions, votes, outcome, and log position for audit replay\.

### VI\-EThe controller and temporal re\-evaluation

The controller records its outcome and returns it to the agentic layer\. Escalation cites facts, contrary assertions, mismatched approvals, and obligations; the agentic workflow routes the case to a reviewer and returns the review decision as a logged event\. The registered action connector checks the allowance again immediately before a consequential invocation\. Irreversible actions are synchronous, so no approval is terminal\.

A pending decision record is current only while none of its decision dependencies changes\. Restoring a value cannot repair a stale record\. The controller re\-adjudicates affected actions and returns the updated outcome to the agentic layer\. On 8871, a fourth exception stales the pending binding allowance before the action connector can invoke binding\.

### VI\-FFormal properties

The following are architectural arguments for governed actions\. They use the controller protocol in Section[V\-A](https://arxiv.org/html/2610.27480#S5.SS1)and the assumptions below\. They do not establish input truth, endpoint exactly\-once effect, or behavior outside the governance boundary\.

###### Assumption 1\(Complete interception\)\.

Every registered system\-of\-record mutation and externally binding action passes through the governance layer by credential topology, not convention\.

###### Assumption 2\(Authoritative event ingestion\)\.

Every decision\-relevant event, including expiry, enters the log with its affected dependency or version\-applicability identity before a later action using it dispatches\.

###### Assumption 3\(Immutable governance artifacts\)\.

The log is append\-only and ordered\. Its existing entries, initial case state, decision records, stored values, and policy, threshold, authority, registry, replay, and rule versions remain unchanged and available\.

###### Assumption 4\(Defined dispatch semantics\)\.

For one action, the final validity check, outcome selection, and dispatch are serialized with additions to the log\.

###### Theorem 1\(Dispatch invariant\)\.

Under Assumptions[1](https://arxiv.org/html/2610.27480#Thmassumption1)–[4](https://arxiv.org/html/2610.27480#Thmassumption4), every governed irreversible or externally binding action has a current decision record that permits its dispatch\. The claim concerns governance\-boundary dispatch\. It does not establish execution, exactly\-once effect, or atomic external logging\.

###### Proof:

The registered action connector sends each proposed consequential action to the controller and waits for its outcome\. Ingestion records every prior relevant event\. Under the rule in Section[V\-A](https://arxiv.org/html/2610.27480#S5.SS1), a relevant change makes the earlier record stale even if values later return\. The connector invokes the target only after the controller returns permission and the final validity check confirms a current record\. Serialization excludes a relevant event between that check and invocation\. Thus each governed dispatch satisfies the invariant\. ∎

###### Theorem 2\(Deterministic adjudication\)\.

For a fixed log prefix, action, decision\-read\-set values, and pinned governance\-artifact versions, the engine returns the same intervention\.

###### Proof:

Replay reconstructs the same state\. Assumption[3](https://arxiv.org/html/2610.27480#Thmassumption3)preserves the recorded inputs and procedures used by D\. D reads those inputs without a new model or external call\. Its fixed rules therefore return the same intervention\. ∎

###### Theorem 3\(Temporal invalidation\)\.

A relevant event after a decision makes its record stale permanently, even if values return\. Without such an event, the record remains current\.

###### Proof:

The validity rule examines all relevant events since the decision\. Append\-only history retains a change after reversal, so the old record cannot become current again\. Without a relevant event, the rule leaves it current\. ∎

###### Proposition 1\(Audit replay\)\.

Under Assumption[3](https://arxiv.org/html/2610.27480#Thmassumption3), any past adjudication can be reconstructed without the agent or model\.

###### Proof:

The retained record supplies the log position, action, read set, stored values, versions, votes, and outcome\. Replay reconstructs the state, and Theorem[2](https://arxiv.org/html/2610.27480#Thmtheorem2)reproduces the result\. ∎

Authorization validity is not exactly\-once execution\. A lost acknowledgement can permit a valid retry to commit twice\. The controller records it as pending with an idempotency key\. Transactional endpoints append and effect atomically\. Conditional writes reject old tokens\. Weaker endpoints expose duplicates at reconciliation\. Optimistic concurrency supplies compare\-and\-swap\[[14](https://arxiv.org/html/2610.27480#bib.bib12)\]\. The first two grades preserve the governed\-dispatch guarantee\. Input truth remains outside the guarantee\.

### VI\-GComponent necessity

Removing interception readmits F8\. Removing typing readmits F7\. Removing reconstruction or re\-evaluation readmits F2\. Removing authority, evidence, or policy versioning readmits F1/F5, F3, or F6\. Admitting raw signals loses F4 detection or determinism\. These components provide the stated coverage in this architecture\.

## VIIFrom Failures to Intervention

### VII\-AProspective intervention versus remediation

Table[V](https://arxiv.org/html/2610.27480#S7.T5)maps deficiency and reversibility to the typical prospective response\. Six prospective outcomes address action proposals: allow, monitor, require\_evidence, escalate, pause, and deny\. Rollback or compensation is a separate post\-effect remediation operation\. This removes the misleading implication that undoing an effect is merely a more restrictive form of denying a proposed action\. In the accompanying implementation, rollback appears as a seventh entry in the same intervention list; the paper separates it because undoing a landed effect is not a stronger form of refusing a proposal\.

Where multiple deficiencies coexist, the engine logs each one and applies the declared resolution policy—in the evaluated instance, a total restrictiveness order over the prospective outcomes\. A landed effect may be reversed or compensated under a separate, authorized recovery policy\. An irreversible effect cannot be rolled back; it can only be surfaced, reconciled, or remedied by another permissible process\.

TABLE V:Typical prospective response by deficiency and reversibility\.

## VIIIIllustrative Evaluation

### VIII\-ASetup and scope

We evaluate the specification with a deterministic replay harness\. A*case*is a hand\-written, ordered event log for one workflow, containing recorded facts, documents, approvals, evaluator signals, and agent proposals, together with the governing policy and threshold versions and a declared expected outcome\. The harness replays each log through a controller configuration event by event and records every adjudication and dispatch decision\. The library contains 42 such author\-written cases: 27 include specified failures and 15 are designated clean, so that the prevented\-violation rate is measured rather than trivially perfect\. Scripted proposals and assertions replace a live agent; the harness makes no model, external\-system, or wall\-clock read\. Its purpose is to check whether the specified adjudication, invalidation, and replay paths produce the intended outcomes under the stipulated policies and event sequences\.

We compare \(i\) a point\-in\-time evaluation configuration that adjudicates a proposal once and carries its allowance forward without a later validity check, \(ii\) the proposed state\-bound configuration using the same recorded policy, authority, and signal inputs, and \(iii\) a whole\-state fingerprinting ablation that treats all case\-state changes as relevant\. The comparison isolates state\-bound temporal invalidation relative to a deliberately non\-re\-evaluating configuration\. It does not compare against a dispatch\-time policy engine with independently maintained approval provenance, or establish advantage over all agent guardrails and runtime enforcement architectures\.

### VIII\-BResults and interpretation

Table[VI](https://arxiv.org/html/2610.27480#S8.T6)reports the aggregate counts\. All 15 later\-invalidated approvals are identified by the state\-bound configuration and not revisited by the point\-in\-time configuration\. The state\-bound configuration holds 14 affected actions before dispatch and addresses one compensable effect after it had landed\. In the compensable case, a relevant state change occurred after valid dispatch but before the external effect completed; the resulting effect required compensation rather than prospective prevention\. These outcomes should not be collapsed into a single prevention statistic\.

Eight failures already present at proposal time are caught by both configurations; two of these are attempts to circumvent in\-path controls— an agent re\-requesting dispatch of a denied action, and an agent asserting over a disqualifying fact—refused by both\.

The 15 temporal invalidations and the five cases primarily labeled F2 describe different categorizations: temporal invalidation can expose an authority, evidence, grounding, prohibition, or rule problem; Table[VII](https://arxiv.org/html/2610.27480#S8.T7)lists each affected case’s primary deficiency\.

Two rates summarize the trade\-off, with denominators fixed by the harness\. The adverse\-effect rate is the share of the 23 governed actions with a non\-dispatch outcome under the final stipulated case state that nonetheless produce an external effect: 65\.2% \(15/23\) point\-in\-time versus 4\.3% \(1/23\) state\-bound\. The one state\-bound effect was dispatched while valid and became adverse after a later state change but before external completion\.

The escalation rate is the share of all 43 proposed actions routed to a human: 11\.6% \(5/43\) versus 32\.6% \(14/43\)\. The reduction in adverse external effects is accompanied by additional human attention; both rates describe the scripted replay, not production incidence\. The 27 failure cases contain 28 governed actions; five are legitimately dispatched by both configurations because their deficiency is remedied in the event log before dispatch, leaving the 23 whose adjudicated outcome is non\-dispatch\.

One of the 15 clean cases requires an additional hold even though fresh adjudication permits the action: its amount changes within the same authority limit, invalidating the old allowance without rendering the new amount inadmissible\. This is an unnecessary repeat decision, not an assertion that the final state violates policy\. It motivates calibration of safe dependency scope while preserving soundness\.

Table[VIII](https://arxiv.org/html/2610.27480#S8.T8)reports the fingerprinting ablation\. The five\-case stress set places 10–20 irrelevant events after pending allowances and contains no stale approvals\. Whole\-state fingerprinting produces 74 re\-adjudications and five unnecessary invalidations; the declared decision\-relevant projection produces none\. The two configurations detect the same 15 stale approvals in the 42\-case library\. These results illustrate the selectivity mechanism for the dependencies encoded by the authors, not the reliability of automatically discovering all real\-world dependencies\.

Each case was replayed three times under each configuration, with byte\-identical decision records and votes\. This checks reproducibility of the harness’s deterministic path; it is not a latency, scalability, or live operational reliability result\.

TABLE VI:Reported counts from the 42\-case replay\. Denominators are stated where they differ from the number of cases; adverse\-effect interpretation requires verification against the replay sequence\.TABLE VII:Primary deficiency assigned to the 15 affected cases\. An approval can additionally be temporally invalidated; F2 is not exclusive\.TABLE VIII:Whole\-state versus decision\-relevant fingerprinting ablation\. “False inv\.” denotes invalidation caused by events not requiring a changed substantive authorization; a relevant change can still require an unnecessary repeat approval when readjudication permits the action\.
### VIII\-CWhat the replay cannot establish

The authors defined the rules and cases, and the point\-in\-time comparator is intentionally unable to re\-evaluate\. Hence the counts demonstrate specification behavior under constructed conditions\. A dispatch\-time policy re\-evaluator could detect many of the same changes\. The additional semantics proposed here are the bound history of which prior approval is being used, what evidence and authority supported it, and whether that approval has been superseded\. No head\-to\-head experiment against such a stronger comparator is claimed\.

The scripted counts are not estimates of production incident prevalence or review capacity\. In particular, the system may increase the number of repeat approvals or escalations; the practical burden requires measurement in a live deployment\. The current paper does not report production latency or claim an empirical advantage over alternative implemented architectures\.

## IXDiscussion and Limitations

Interception\.An unfronted payment rail or database edit is F8\. The controller cannot prevent an effect outside its registered path\. The dispatch\-time property is conditional on credential and integration topology\.

Ingestion and external effects\.A relevant update that has not yet reached the log can invalidate the real\-world business basis without violating the stated theorem\. State may also change after a valid dispatch but before an external provider commits\. The architecture guarantees neither provider\-side atomicity nor exactly\-once external effect; compensation and reconciliation remain necessary\.

Dependency completeness\.Selective invalidation is sound only if the declared read set includes derived, cross\-step, and policy\-applicability dependencies\. A missing dependency permits a falsely retained approval\. Unknown dependencies call for conservative widening or review, at the cost of additional intervention\.

Extraction and evidence fidelity\.A parser can misrecord a loss amount and yield a reproducibly wrong decision\. Typing preserves the origin of assertions but does not prove factual truth\. Completeness checks cannot establish substantive professional correctness\.

Policy and workflow scope\.The controller enforces encoded obligations; an unencoded rule is unenforceable\. It does not solve general planning failure, deadlock, business desirability, or professional judgment that cannot be represented as an obligation\. A human reviewer may still make a poor decision even with accurate recorded context\.

Next steps\.Production incident libraries, stronger dispatch\-time comparators, integration measurements, and review\-load studies would establish how well this specification transfers outside the hand\-written cases\. These are future work, not unperformed experiments implied by the current results\.

## XConclusion

A business decision can be valid when issued and unusable when an agent later acts\. This paper specifies an explicit state\-bound allowance that records the decision basis, distinguishes human approval from current execution permission, invalidates associated allowances after relevant logged changes, and requires a new admissibility check at the registered dispatch boundary\. It draws on established runtime enforcement, mutable authorization, process compliance, and transaction\-control mechanisms, with a particular focus on long\-lived business decisions\. The 42\-case scripted replay illustrates its temporal invalidation and selective fingerprinting behavior\. Within the specified assumptions and registered surface, the resulting guarantee concerns validity at dispatch, not universal business correctness or the timing and uniqueness of external effects\.

## References

- \[1\]\(2024\)τ\\tau\-Bench: a benchmark for tool\-agent\-user interaction in real\-world domains\.arXiv preprint arXiv:2406\.12045\.External Links:2406\.12045Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p1.1)\.
- \[2\]A\. Yehudai, L\. Eden, A\. Li, G\. Uziel, Y\. Zhao, R\. Bar\-Haim, A\. Cohan, and M\. Shmueli\-Scheuer\(2025\)Survey on evaluation of LLM\-based agents\.arXiv preprint arXiv:2503\.16416\.External Links:2503\.16416Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p4.1),[§II](https://arxiv.org/html/2610.27480#S2.p1.1)\.
- \[3\]L\. Dong, Q\. Lu, and L\. Zhu\(2024\)AgentOps: enabling observability of LLM agents\.arXiv preprint arXiv:2411\.05285\.External Links:2411\.05285Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p4.1),[§II](https://arxiv.org/html/2610.27480#S2.p1.1)\.
- \[4\]H\. Wang, C\. M\. Poskitt, and J\. Sun\(2025\)AgentSpec: customizable runtime enforcement for safe and reliable LLM agents\.arXiv preprint arXiv:2503\.18666\.External Links:2503\.18666Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p4.1)\.
- \[5\]U\. Mehmood, S\. Sheikhi, S\. Bak, S\. A\. Smolka, and S\. D\. Stoller\(2022\)The black\-box simplex architecture for runtime assurance of autonomous CPS\.InNASA Formal Methods \(NFM\),Lecture Notes in Computer Science, Vol\.13260,pp\. 231–250\.External Links:[Document](https://dx.doi.org/10.1007/978-3-031-06773-0%5F12),2102\.12981Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p5.1),[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[6\]M\. Leucker and C\. Schallhart\(2009\)A brief account of runtime verification\.Journal of Logic and Algebraic Programming78\(5\),pp\. 293–303\.External Links:[Document](https://dx.doi.org/10.1016/j.jlap.2008.08.004)Cited by:[§I](https://arxiv.org/html/2610.27480#S1.p5.1),[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[7\]F\. B\. Schneider\(2000\)Enforceable security policies\.ACM Transactions on Information and System Security3\(1\),pp\. 30–50\.External Links:[Document](https://dx.doi.org/10.1145/353323.353382)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[8\]J\. Ligatti, L\. Bauer, and D\. Walker\(2005\)Edit automata: enforcement mechanisms for run\-time security policies\.International Journal of Information Security4\(1–2\),pp\. 2–16\.External Links:[Document](https://dx.doi.org/10.1007/s10207-004-0046-8)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[9\]L\. T\. Ly, F\. M\. Maggi, M\. Montali, S\. Rinderle\-Ma, and W\. M\. P\. van der Aalst\(2015\)Compliance monitoring in business processes: functionalities, application, and tool\-support\.Information Systems54,pp\. 209–234\.External Links:[Document](https://dx.doi.org/10.1016/j.is.2015.02.007)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[10\]M\. P\. Singh\(1999\)An ontology for commitments in multiagent systems: toward a unification of normative concepts\.Artificial Intelligence and Law7\(1\),pp\. 97–113\.External Links:[Document](https://dx.doi.org/10.1023/A%3A1008319631231)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p2.1)\.
- \[11\]T\. South, S\. Marro, T\. Hardjono, R\. Mahari, C\. D\. Whitney, D\. Greenwood, A\. Chan, and A\. Pentland\(2025\)Authenticated delegation and authorized AI agents\.arXiv preprint arXiv:2501\.09674\.External Links:2501\.09674Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p3.1)\.
- \[12\]V\. C\. Hu, D\. Ferraiolo, R\. Kuhn, A\. Schnitzer, K\. Sandlin, R\. Miller, and K\. Scarfone\(2014\)Guide to attribute based access control \(ABAC\) definition and considerations\.Technical reportTechnical ReportNIST Special Publication 800\-162,National Institute of Standards and Technology\.External Links:[Document](https://dx.doi.org/10.6028/NIST.SP.800-162)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p3.1)\.
- \[13\]J\. Park and R\. Sandhu\(2004\)The UCONA​B​C\{\}\_\{ABC\}usage control model\.ACM Transactions on Information and System Security7\(1\),pp\. 128–174\.External Links:[Document](https://dx.doi.org/10.1145/984334.984339)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p3.1)\.
- \[14\]H\. T\. Kung and J\. T\. Robinson\(1981\)On optimistic methods for concurrency control\.ACM Transactions on Database Systems6\(2\),pp\. 213–226\.External Links:[Document](https://dx.doi.org/10.1145/319566.319567)Cited by:[§II](https://arxiv.org/html/2610.27480#S2.p4.1),[§VI\-F](https://arxiv.org/html/2610.27480#S6.SS6.p6.1.1)\.