PaperlayerView exact revision on arXiv

Source-linked AI summary

Beyond Approved Actions: Runtime Validation of Persistent Outcomes in Agent Workflows

Haoran Zhang, Hengtong Zhang, Zhiyu Liang, Yu Yan, Decheng Zuo, Hongzhi Wang

arXiv:2609.31301v1cs.SEcs.AI

TL;DR

Agent calls may be approved and report success while leaving persistent changes the application did not approve. EffectMatch binds approval to the current execution, compares it with observed effects, and persists the decision governing commit and continuation. On twelve public business tasks, it preserved all clean executions and rejected every tested task–fault mismatch.

  • Problem

    Existing safeguards can authorize an operation or record its aftermath without establishing that every persistent change left behind was within application approval.

    Source: §I · p. 1

  • Method

    EffectMatch binds application-approved outcomes to the current state and execution, checks collected persistent changes against approval, and persists the decision governing commit and continuation.

    Source: §I · p. 2, §VI · p. 14

  • Results

    On twelve public business tasks, EffectMatch preserved all clean executions and rejected mismatches in all 39 task–fault combinations, each repeated three times.

    Source: §VI · p. 14

  • Takeaways & Limitations

    Persisting the outcome decision lets the protocol prevent executions that violate approval or remain unresolved from propagating as success.

    Source: §VI · p. 14

Abstract

from arXiv · show

Large language model agents increasingly act on software systems, no longer merely generating text but also changing databases and online services. However, an approved database update may succeed yet leave an unapproved notification because execution can produce persistent effects beyond the requested change. Current safeguards can approve an action or record its aftermath, but without checking the persistent result before continuation, an unapproved outcome can be accepted as success and propagated to later steps. We present EffectMatch, a runtime that collects persistent changes within a controlled execution boundary and compares them with what the application approved for the current state and execution. The comparison governs commit and dependent execution. In comparative evaluation on 206 public business tasks, EffectMatch preserved all clean executions and prevented all tested incorrect commits. Six 20-run ablations exposed the failure caused by each removed mechanism, while 80 task-topology cases preserved truthful handoffs and blocked invalid continuation. Together, these results show that EffectMatch blocks the silent acceptance and downstream propagation of persistent outcomes inconsistent with application approval.

I. INTRODUCTION

Agent calls can pass authorization and return success while leaving unapproved persistent changes, so safe continuation requires checking what the execution actually produced. EffectMatch binds current approval to observed outcomes and a durable continuation decision; the introduction also reports evaluation on public tasks.

I. INTRODUCTION

  • An approved call can return success while leaving an unapproved persistent change, so safe continuation must connect current approval, actual outcome, and later-work decisions.Stale approval, hidden trigger effects, and uncertain remote-call completion can all make call-level success misleading.Source: §I · p. 1
  • EffectMatch binds approval to its source, state, plan revision, and occurrence, compares collected changes with approval, and persists the decision governing commit and continuation.The paper evaluates outcome checking and execution binding through controlled comparisons and ablations on public tasks, alongside live-agent, recovery, and backend experiments.Source: §I · p. 2

A. Execution Path and Local Guarantees

  • Local success signals do not enumerate persistent outcomes: a trigger can add a notification while the agent, tool, backend, and workflow each complete their interface.The required judgment links the approved business outcome, actual persistent changes, and release or stopping of subsequent work.Source: A. Execution Path and Local Guarantees · p. 2

B. Three Requirements for Persistent Outcomes

  • Safe continuation requires approval current for this execution, a complete outcome covering relevant changes, and a durable decision before retry or dependent work.The three requirements apply to the same execution occurrence.Source: B. Three Requirements for Persistent… · p. 2

C. Approved and Established Outcomes

The paper represents approval and observed effects at a registered profile’s comparison granularity, then classifies whether a complete observed outcome matches approval. EffectMatch applies that comparison before commit and saves the decision to govern later execution.

C. Approved and Established Outcomes

  • An approved outcome is a finite multiset of accepted persistent changes expressed at the registered profile’s comparison granularity; completeness requires evidence covering attributed changes and required fields.Profiles may compare relation writes and counts or additionally compare individual resources and result values; write-event records and net state differences define different units of change.Source: C. Approved and Established Outcomes · p. 3

D. Outcome Classification and Problem Statement

  • EffectMatch classifies outcomes as EXACT, DIVERGED, or INDETERMINATE; only a current approval with an EXACT result propagates as success.Incomplete evidence leaves completeness unestablished, while a complete mismatch is DIVERGED.Source: D. Outcome Classification and Problem… · p. 3

III. PERSISTENT-OUTCOME VALIDATION PROTOCOL

  • The protocol connects application approval, backend evidence, and continuation control for one execution occurrence, checking approval, comparing effects, and saving the decision.The approval is bound before execution, and the runtime checks that reachable persistence routes are covered or blocked before accepting observed effects.Source: §III · p. 3, A. Protocol Overview · pp. 3–4

A. Protocol Overview

  • In the invoice example, the trigger’s extra notification makes the candidate DIVERGED; the runtime rolls back before commit and saves a halt decision that blocks later workers.The invoice remains pending, the notifications table remains empty, and dependent execution remains blocked after fresh worker starts.Source: A. Protocol Overview · p. 4, Figure 2 · p. 4

B. Binding Approval to One Execution

EffectMatch binds approved outcomes to a current, one-use execution and checks observed persistent changes at a certified backend boundary. The comparison and its recorded decision govern commit and dependent execution.

B. Binding Approval to One Execution

C. Validating Persistent Outcomes at Backend Boundaries

  • A boundary certificate requires every reachable persistence or dispatch route to be covered by observation or blocked; an unclassified route stops protected execution.Source: C. Validating Persistent Outcomes at… · p. 5, Figure 3 · p. 5
  • Within a held transaction, write records capture direct and trigger-induced changes; the runtime normalizes attributed records into E and compares them with approval A.For held transactions, a mismatch remains reversible before commit.Source: C. Validating Persistent Outcomes at… · pp. 5–6
  • PROMOTABLE paths inspect a reversible candidate before promotion, MEDIATED paths constrain and bind requests before dispatch, and OPAQUE paths classify outcomes from post-execution evidence.OPAQUE outcomes with a complete mismatch or insufficient evidence block dependent execution, without rolling back effects already realized.Source: C. Validating Persistent Outcomes at… · p. 6
  • The terminal journal records whether execution ended in exact completion, rejection, divergence, or uncertainty, and preserves blocking decisions for dependent work.Source: C. Validating Persistent Outcomes at… · p. 6

D. Persistent Recovery and Continuation

Persistent terminal records carry execution decisions across process exits and control whether dependent work can continue. Exact completion requires agreement among approval, observed outcome, authority, and the final-gate permit.

D. Persistent Recovery and Continuation

  • A new worker consults the persistent terminal after process exit; a missing terminal leaves continuation blocked pending reconciliation.An uncommitted database candidate rolls back when its connection terminates, while an occurrence already claimed remains spent.Source: D. Persistent Recovery and Continuation · p. 6
  • Dependent actions run only after a persistent exact-completion terminal; rejection, divergence, uncertainty, missing terminals, and replay do not release them.A later retry or compensation requires new application authority.Source: D. Persistent Recovery and Continuation · p. 7
  • A terminal records confirmed exact completion only when approved and observed outcomes, the authority claim, and the final-gate permit agree.Source: D. Persistent Recovery and Continuation · p. 7

E. Prototype Realization

The prototype implements EffectMatch with registered adapters, effect profiles, and observers, and uses a capability-aware execution path to persist decisions before continuation. Its evaluation plan spans public database and business tasks, live-agent configurations, recovery, backend behavior, and runtime overhead.

E. Prototype Realization

  • The Python prototype uses registered adapters, effect profiles, and observers; its live-agent integration checks tool-call changes on a private task-state copy before saving.The integration triggers any outstanding finalization check when the model finishes normally.Source: E. Prototype Realization · p. 7
  • Algorithm 1 validates and claims authority, checks the boundary, then either inspects and promotes a staged candidate or constrains and dispatches a remote request before classifying readback.Every return passes through FINISH, which durably writes the terminal before releasing exact execution dependents or blocking continuation.Source: E. Prototype Realization · p. 7

IV. EVALUATION

  • The evaluation plan covers public database and shopping, customer-support, and travel tasks, with controlled comparisons, ablations, live-agent completion, recovery, backend behavior, and runtime overhead.Source: §IV · p. 7

A. Experimental Setup

The experiments compare EffectMatch with existing execution controls on public database and business tasks. EffectMatch preserves clean outcomes while rejecting mismatching persistent results, and post-execution observation distinguishes clean executions from hidden-effect cases.

A. Experimental Setup

  • The experiments paired database tasks from MCPMark and business tasks from STATE-Bench with direct execution, workflow controls, and AgentSpec.Some targets were independently specified before execution; the broader comparison used saved clean-execution results as references.Source: A. Experimental Setup · pp. 7–8

B. RQ1: Can Outcome Checking Prevent Incorrect Commits?

  • Exact post-execution closure reached (38, 38), versus GPT-5.6 Sol (ultra) at (8, 30) on 38 frozen STATE-Bench pairs.The same pre-execution packet applied to each clean/hidden-effect pair, limiting what a surface approver could distinguish before execution.Source: Figure 4 · p. 9, B. RQ1: Can Outcome Checking Prevent… · p. 9
  • EffectMatch rejected all 27 mismatching database executions while preserving initial relation data; all conditions completed clean cases.The three tasks covered customer migration, employee hierarchy management, and sales/music charts; AgentSpec's visible-write rule did not catch trigger-introduced changes.Source: B. RQ1: Can Outcome Checking Prevent… · p. 9
  • EffectMatch rejected all 117 mismatches across four business-task fault types, while committing 27 matching duplication candidates that Error-reject blocked.Error-reject accepted all nine harmful duplication mismatches and blocked twelve matching candidates across four tasks.Source: B. RQ1: Can Outcome Checking Prevent… · p. 9
  • EffectMatch retained all 618 clean outcomes and rejected mismatching candidates in the broader clean-reference comparison.The comparison also found that Error-reject withheld 21 correct clean outcomes after trajectories recovered from intermediate tool errors; ineffective omissions and duplications remained eligible when final state matched the reference.Source: Table III · p. 8, B. RQ1: Can Outcome Checking Prevent… · p. 9
  • Complete-Effect Audit completed clean controls in 20/20 runs, while uncertain or diverged remote outcomes blocked dependent work without undoing remote effects.Robust Workflow constrained dispatch; NativeAudit exposed hidden PostgreSQL writes, while substituting an untrusted approval source was rejected by EffectMatch.Source: B. RQ1: Can Outcome Checking Prevent… · p. 9, Figure 5 · p. 9

C. RQ2: Which Components Are Necessary?

Ablations show that result comparison, execution binding, candidate binding, and final rechecking each protect a distinct condition. In live-agent tests, EffectMatch integration preserved successful task completion across the tested configurations.

C. RQ2: Which Components Are Necessary?

  • Disabling result comparison committed all 27 incorrect database candidates and all 117 incorrect business-task candidates.Omitting an additional write from observation could make an incorrect candidate appear to match approval; a locally supplied target from an untrusted source was also rejected by the approval-source check.Source: C. RQ2: Which Components Are Necessary? · p. 10
  • Removing occurrence and pre-state binding admitted nine database and 36 business executions with changed occurrence identifiers, despite correct candidate results.Removing one-use enforcement produced an additional external effect on every replay; without a durable hazard record, a dependent action was dispatched after divergence.Source: C. RQ2: Which Components Are Necessary? · p. 10
  • Without candidate binding at both runtime and adapter, a valid permit for a paid invoice candidate committed a cancelled replacement; full EffectMatch rejected all substitutions.Signature, expiry, current policy, base-state validation, and one-use enforcement remained active.Source: C. RQ2: Which Components Are Necessary? · p. 10
  • Reusing an initial boundary certificate admitted commit after a permission change, while fresh certification rejected it; disabling final rechecking admitted all nine post-authorization deployment changes.The targeted case changed temporary-table permission while leaving the protected relation catalog unchanged.Source: C. RQ2: Which Components Are Necessary? · p. 10

D. RQ3: Live-Agent Task Completion and Integration

  • All 108 live-agent episodes produced candidate states matching approval targets; integrated DSH and Codex completed throughout, and DeepSeek API results were corrected through targeted reruns.The original integrated runs completed 51/54; three successful targeted reruns followed addition of host-triggered finalization at normal agent completion.Source: D. RQ3: Live-Agent Task Completion and… · pp. 10–11
  • Successful completion required both requested changes and preservation of unaffected state across shopping, order-cancellation, and travel-booking tasks.Examples included retaining shipped order items and preserving booking preferences while changing a flight.Source: D. RQ3: Live-Agent Task Completion and… · p. 10

E. RQ4: Continuation after Failures and Process Restarts

Recovery tests show that continuation depends on saved terminal decisions and valid durable state, including after process exits and across task topologies. Cross-backend and cost studies test deployment behavior, certification overhead, and effect-comparison scaling.

E. RQ4: Continuation after Failures and Process Restarts

  • Across 90 executions, normal completion and exit after terminal persistence permitted continuation, while exit with a staged candidate preserved initial state and stopped later work.No case released work without a valid result, and two fresh readers produced no duplicate acknowledgement records.Source: E. RQ4: Continuation after Failures… · p. 11
  • After business-state persistence but before terminal persistence, all 90 executions had correct state yet continuation was withheld pending reconciliation.New workers read existing terminals but did not reconstruct missing records; the independently approved PostgreSQL task likewise produced 0/5 acknowledgements before commit, 0/5 after commit but before terminal persistence, and 5/5 afterward.Source: E. RQ4: Continuation after Failures… · p. 11
  • In 35 of 90 omitted-write executions, the final result remained unchanged and continuation proceeded; the other 55 mismatches were rejected and blocked.The test illustrates that a changed execution trace need not imply an incorrect business result.Source: E. RQ4: Continuation after Failures… · p. 11
  • All 80 topology handoffs matched durable state across linear, fan-out, fan-in, and mixed dependencies; changed plans and stale or replayed approvals were rejected.Mid-run failures preserved completed predecessors while stopping the failed node and dependent successors.Source: E. RQ4: Continuation after Failures… · p. 11

F. RQ5: Cross-Backend Behavior, Deployment Conditions, and Cost

  • MySQL audit and ToolSandbox held-runtime checks rejected mismatches before saving, while direct MySQL transactions committed every extra-write and omitted-statement variant.In ToolSandbox, the extra reminder passed all 12 native task-goal checks under direct execution but was detected by comparing approved and observed changes.Source: F. RQ5: Cross-Backend Behavior,… · p. 12
  • Independent database readback agreed with runtime decisions in all 100 PostgreSQL trials, including rejection of extra writes and a later capability grant.Initial certification also refused an exposed host capability, and consumed permits prevented a second commit.Source: F. RQ5: Cross-Backend Behavior,… · p. 12
  • Boundary certification raised median PostgreSQL latency from 13.29 to 29.13 ms (2.19×), with a median per-pair increment of 15.16 ms.Initial and final certificate capture took median times of 7.01 and 7.21 ms, respectively.Source: F. RQ5: Cross-Backend Behavior,… · p. 12, Figure 6 · p. 12
  • Effect comparison grew approximately linearly over 1–500 effects, reaching a median of 2.92 ms at 500 effects.This isolates comparison computation from staging, persistence, and metadata access.Source: F. RQ5: Cross-Backend Behavior,… · p. 12, Figure 6 · p. 12

G. Scope and Deployment Implications

EffectMatch compares actual persistent changes with the outcome approved for the current execution, then uses the persisted decision to govern commit and continuation. The paper reports that this approach prevents violations of approval from propagating as success, while its deployment scope remains bounded by certified profiles.

G. Scope and Deployment Implications

  • Certified-profile exactness is bounded: the PostgreSQL matrix covers five representative boundary classes, not every database, extension, or operating-system behavior.Opaque-backend effects can be classified and contained when evidence is available; undo requires separately authorized compensation.Source: G. Scope and Deployment Implications · p. 13

V. RELATED WORK

  • Prior work addresses agent risks, runtime policies, authority, and transaction recovery; EffectMatch compares actual changes with the outcome approved for this execution and links that decision to continuation.The related-work discussion contrasts the object each contract controls and the execution boundary it reaches.Source: §V · p. 13

VI. CONCLUSION

  • EffectMatch binds approval to current state and one execution, compares persistent changes, and persists the decision governing commit and subsequent work.The Effect Commit Contract keeps approval, outcome comparison, and continuation connected through process exit or recovery.Source: §VI · p. 14

Supplementary Material for Beyond Approved Actions: Runtime Validation of

  • The supplement provides construction examples, implementation details, full comparison results, and live-agent settings for the main paper’s protocol and evaluation.Its section, table, and equation numbers prefixed with S refer to the supplement.Source: Supplementary Material for Beyond… · p. 16

A. Inputs, Representation, and Independence

Approved and observed outcomes are represented at the registered profile’s comparison granularity, while approval sources and execution bindings are kept distinct from post-execution assessment. Examples show how value-sensitive comparisons detect unintended results, including hidden database writes.

A. Inputs, Representation, and Independence

  • The registered profile selects whether outcomes compare write events or net-state differences; independent targets are constructed before execution and kept distinct from clean-replay references.Snapshot comparisons retain unrequested registered business fields as unchanged, so altering one creates a mismatch.Source: A. Inputs, Representation, and… · p. 16

B. Example: Partial Order Cancellation

  • For ORD-7281, the independent specification cancels the unshipped item while preserving the delivered phone; its refund is 35 using the existing split-payment method.A candidate refund of 36 is rejected, preserving initial durable state; the table caption says other registered business fields remain unchanged.Source: B. Example: Partial Order Cancellation · p. 16, Table S1 · p. 16

C. Example: Database Migration and Hidden Writes

  • In the migration task, a registered-scope trigger write enters the observed outcome even when absent from approved SQL, and missing or altered rows are rejected before transaction commit.Value-sensitive row comparison can distinguish imports with identical relation-operation counts but different customer values.Source: C. Example: Database Migration and… · p. 17

D. Execution Binding and Stored Decisions

  • Approval binding ties approved content to its source, task state, plan revision, profile, and execution occurrence; the journal separately records outcome classification and disposition.A permit for one candidate cannot be transferred to another candidate, and one-use consumption persists across attempts.Source: D. Execution Binding and Stored… · p. 17

A. What the PostgreSQL Deployment Registers

  • The PostgreSQL adapter registers supported relations, entry points, privileges, and restrictions, then stabilizes compared data with locks and rechecks visible configuration at the final gate.Its declared coverage is not unrestricted analysis of arbitrary function code, and snapshot cost is part of observation work.Source: A. What the PostgreSQL Deployment… · p. 17

B. Boundary Test Inventory

The boundary inventory combines component-level checks with an integrated study that connects certification to held transactions and durable-state readback. The evaluated task population is purposeful and does not treat unsupported task/profile combinations as successful executions or runtime rejections.

B. Boundary Test Inventory

  • 100/100 integrated trials matched runtime and durable-state expectations across five scenarios, including clean commits, extra-write rejection, certification failures, and replay.Replay involved two execute attempts per trial, while host-capability grants were inspected as catalog changes without invoking a host-file primitive.Source: B. Boundary Test Inventory · p. 18

C. What Each Backend Implementation Establishes

  • Backend control points differ: PostgreSQL uses held native transactions and registered snapshots, STATE and ToolSandbox check private simulator snapshots, and MySQL audits row transitions before commit.GitHub uses fresh field readback and local continuation control, but does not roll back remote changes or establish attribution of all effects.Source: C. What Each Backend Implementation… · p. 18

A. Public Tasks and Selection

  • The evaluation draws on MCPMark, STATE-Bench, and ToolSandbox, while 18 of 21 MCPMark inventory tasks remain unimplemented task/profile combinations rather than measured successes or runtime rejections.The twelve independently specified STATE tasks form a purposeful subset with four tasks per domain.Source: A. Public Tasks and Selection · p. 18

B. Conditions, Fault Placement, and Denominators

The evaluation separates fault placement and denominators from mechanism comparisons and dedicated ablations. Across the reported scenarios, removed mechanisms produce distinct failures, while observation completeness alone does not establish approval provenance or undo an already durable remote effect.

B. Conditions, Fault Placement, and Denominators

  • The STATE baseline rejects tool errors, while the integrated condition compares outcomes before saving; its effect-comparison ablation removes that comparison but retains staging and permit handling.Tool response errors and outcome mismatches are measured separately.Source: B. Conditions, Fault Placement, and… · p. 18
  • The 206-task comparison comprises 7,416 executions across three variants, four conditions, and three repetitions per task; omission and duplication injections sometimes left candidates unchanged.Of 618 omission runs, 354 produced mismatching candidates; of 618 duplication runs, 138 did so.Source: B. Conditions, Fault Placement, and… · p. 19

D. Ablation Interventions

  • Candidate-binding removal permits a validated invoice candidate’s permit to be presented for a different candidate; fresh-boundary removal can commit under a changed certification condition.The fresh-boundary fault grants database TEMP permission after staging; no temporary table or host operation is invoked.Source: D. Ablation Interventions · p. 19

C. Full Mechanism Comparison

  • Across eight mechanism scenarios, every displayed outcome occurred in 20/20 runs; complete observation cannot prove that a matching target came from the designated approver or undo a remote effect.The scenario matrix distinguishes pre-commit rejection from a later blocked continuation after a remote effect has already occurred.Source: C. Full Mechanism Comparison · p. 19, Table S5 · p. 20

D. Ablation Interventions

  • 20/20 ablated fault runs exposed each removed mechanism’s failure; full execution rejected or blocked all 20 paired faults.The dedicated ablations comprise six fault pairs, with 20 full and 20 ablated executions per pair.Source: D. Ablation Interventions · p. 19, Table S6 · p. 20

E. Recovery, Task-Level Timing, and Other Backends

STATE timing produced correct results across all timed executions, while PostgreSQL certification added a measured paired increment. Recovery cases withheld dependent work when terminal records were missing, and backend studies covered database, tool, and readback conditions.

E. Recovery, Task-Level Timing, and Other Backends

  • Six normal/interrupted recovery scenarios used one producer and two fresh consumers; correct-state cases without a terminal withheld dependent work pending reconciliation.Each scenario had five repetitions, and consumers read saved state and terminal records without reconstructing missing terminals.Source: E. Recovery, Task-Level Timing, and… · p. 20
  • 1,080 STATE executions produced correct results; the median task-level held/direct ratio was 4.345 and median added time across task medians was 1.081 ms.The timing includes replay, runtime construction, comparison, permit handling, and durable SQLite selection; setup, resets, scoring, and diagnostic replay are excluded.Source: E. Recovery, Task-Level Timing, and… · p. 20
  • 15.157 ms was the median paired increment for PostgreSQL certification, with disabled/enabled total medians of 13.292/29.127 ms.The comparison used 30 alternating pairs of one five-effect operation; fixture setup and independent readback were outside the timer.Source: E. Recovery, Task-Level Timing, and… · p. 20
  • MySQL tested eight authored operations across clean, extra-write, and omitted-statement variants, while ToolSandbox tested four actions with clean, extra-reminder, and omitted-action variants.The studies used 240 MySQL executions and 72 ToolSandbox executions.Source: E. Recovery, Task-Level Timing, and… · p. 20
  • 120 readback executions covered clean, out-of-band title-change, and unavailable-readback conditions; only matching fresh-GET results released local acknowledgement, without resending.These were operation cases on one object type, not eight public benchmark tasks.Source: E. Recovery, Task-Level Timing, and… · p. 21

F. Execution Environments

  • Boundary experiments inspected privileged capabilities through controlled metadata changes rather than invoking host or external-network operations.Model inference was limited to live-agent and surface-approver studies; deterministic replay, recovery, certification, and timing required no model calls or GPU computation.Source: F. Execution Environments · p. 21

A. Shared Task Interface

The section defines a shared business-task interface and contrasts direct writes with an integrated path that holds a private candidate for approval. Original-cohort candidates matched independent targets, and targeted host-finalization reruns produced correct durable states.

A. Shared Task Interface

  • The shared interface used native prompts, released user messages, business-tool schemas, and confirmation and finalization tools; the formal schedule comprised 108 episodes.Six starred tasks each used three configurations, two execution conditions, and three fresh repetitions.Source: A. Shared Task Interface · p. 21
  • The task wrapper supplied no prior assistant/tool trace, expected snapshot, hidden target requirements, or scorer output; approvals were compiled and saved before inference.Fixed confirmation replies were released when the required native preview and target arguments were present.Source: A. Shared Task Interface · p. 21

B. Models, Harnesses, and Budgets

  • Direct execution saved native state after each call, whereas the integrated path held one private candidate until finalization and checked it against independent approval; the three configurations were not an isolated model-capability comparison.Harness-specific instructions and role/request formatting remained in place.Source: B. Models, Harnesses, and Budgets · p. 22

C. Business-State Equivalence

  • Business-state equivalence allowed remapped shopping-cart item IDs and ignored item-list order, while preserving checks on business fields, references, and unrelated state.One Codex/direct episode differed under strict raw-snapshot equality but was business-equivalent to the independent target.Source: C. Business-State Equivalence · p. 22

D. Original Cohort and Targeted Follow-Up

  • All original-cohort candidate business states matched independent targets, and every episode finished without process errors or timeouts; three targeted host-finalization reruns also had correct candidates and durable states.The original batch measures successful-task integration; controlled fault studies supply the incorrect-result prevention evidence.Source: D. Original Cohort and Targeted… · p. 22, Table S8 · p. 22

Related papers

Loading 2609.31301v1…