PaperlayerView exact revision on arXiv

Source-linked AI summary

ADF-EA: A Unified Execution Assurance System for Agent Device Foundation

Xuechun Li, Jiaxin Liang, Jie Li, baolong Li, Jue Wang, Peng Yuan, Hang Huang

arXiv:2609.30691v1cs.MA

TL;DR

Physical-device agents must account for effects that are unverified, outcomes that remain uncertain, and prerequisites that can change. ADF-EA connects planning and execution assurance through shared Device Capability Contracts and persistent state; evaluations report complementary recovery and execution-control benefits while preserving permitted completion.

  • Problem

    Physical actions may be acknowledged without achieving their intended effects, or may succeed despite missing feedback, leaving agents to manage uncertainty and changing prerequisites.

    Source: §1 · p. 1

  • Method

    ADF-EA uses Device Capability Contracts to give planning and runtime assurance shared capability semantics, while persistent execution state retains verified progress, unresolved outcomes, and budgets across revisions.

    Source: §3.3 · p. 10, §6 · p. 25

  • Results

    ADF-EA supports necessary state repair, observation recovery, and restraint against unsupported repetition while preserving permitted completion in evaluated conditions.

    Source: governed by shared capability rules? · p. 3, §5 · p. 24

  • Takeaways & Limitations

    Evaluations across multiple LLMs, five agent frameworks, and simulated device domains demonstrate complementary benefits in execution assurance.

    Source: §6 · p. 25

    ADF-EA does not resolve permanent unobservability and may withhold physical recovery and successful completion when distinguishing evidence is unavailable.

    Source: §3.3 · p. 11

Abstract

from arXiv · show

Agents based on large language models (LLMs) can access heterogeneous devices through tools and APIs, but reliable execution must account for unmet effects, uncertain outcomes, and changing prerequisites. A command may be acknowledged without producing its intended effect, while missing feedback may obscure an action that has already succeeded. We present Agent Device Foundation--Execution Assurance (ADF-EA), an architecture that connects agent planning and device execution through shared capability contracts. Device Capability Contracts (DCCs) unify invocation conditions, intended effects, evidence requirements, and recovery rules across heterogeneous interfaces. Agents use these contracts to plan, while the runtime applies the same semantics to authorize actions, verify effects, and govern continuation and completion. Persistent execution state retains verified progress, unresolved outcomes, and remaining budgets across plan revisions, enabling observation-based recovery, authorized retries, and necessary state repair. We formalize the execution lifecycle and establish conditional soundness properties for completion and recovery authorization. Evaluations span multiple LLMs, five agent frameworks, and simulated process-control, household, and robotic manipulation domains. Compared with direct invocation and existing execution-checking approaches, ADF-EA reduces false completion and unnecessary repetition, supports necessary state repair, prevents calls to unavailable capabilities, and preserves permitted task completion and recovery. These results demonstrate DCCs as a reusable semantic foundation for agent autonomy across heterogeneous devices, unifying capability-based planning, evidence-grounded execution, and authorized recovery within one architecture.

1 Introduction

Reliable physical-device agents must distinguish an unachieved effect from an achieved action with missing feedback, while preserving prerequisites and avoiding duplicate work. ADF-EA connects planning and execution assurance through shared capability contracts and persistent execution semantics, with evaluations demonstrating complementary gains in recovery, execution control, and reuse.

1 Introduction

  • Acknowledged commands may fail to produce their intended effects, while timeouts can follow successful actions and prerequisite states can change before dependent actions.Proceeding without an established prerequisite can invalidate later actions; repeating an action with an uncertain outcome can duplicate physical work.Source: §1 · pp. 1–2

governed by shared capability rules?

  • ADF-EA uses Device Capability Contracts to connect heterogeneous capability knowledge with LLM planning and runtime authorization, verified progress, and completion.Contracts organize invocation conditions, intended effects, evidence requirements, and interruption or recovery rules above interfaces such as MCP, CLIs, and SDKs.Source: governed by shared capability rules? · pp. 2–3
  • Evaluations across simulated device domains, five agent frameworks, and multiple LLMs report complementary gains in recovery, execution control, and reuse while preserving permitted completion.The controlled comparison reports evidence-qualified completion in all 14 completion-designated conditions and no violating dispatches for ADF-EA.Source: governed by shared capability rules? · p. 3
  • Persistent execution semantics retain unresolved outcomes, verified history, invalidated prerequisites, and remaining budgets across proposal revisions, distinguishing state repair from retrying uncertain work.A verified prerequisite that later becomes false can call for repair; an action with missing evidence instead calls for observation or stopping unless retry is authorized.Source: governed by shared capability rules? · pp. 2–3

2 Related Work

Prior work addresses adaptive planning, execution governance, and device-access interfaces through different mechanisms. ADF-EA connects these concerns by using effect evidence and execution history to govern subsequent permissions across capability interfaces.

2.1 Adaptive Planning and Execution Authority

  • Feedback-driven agents revise proposed behavior, but replanning alone does not establish the physical outcome of earlier actions.ADF-EA separates proposal state from authoritative execution state and uses qualified effect evidence to determine progress and renewed authorization.Source: §2.1 · pp. 3–4

2.2 Safety Contracts, Typed Skills, and Execution Governance

  • Existing execution-governance systems provide contracts, verification, safety checks, or typed-skill orchestration, while ADF-EA connects persistent obligations and operation-scoped authority across subsequent requests.Its lifecycle distinguishes an unresolved outcome from a verified state that later becomes false, supporting observation, permitted retry, or necessary state repair as appropriate.Source: §2.2 · pp. 4–5

2.3 Capability Interfaces and Semantic Reuse

  • Device-access interfaces describe and invoke capabilities, but ADF-EA positions DCC above them to determine whether observations establish effects and authorize continued execution.Domain adapters connect interface information to contract evidence and interruption semantics, which govern progress, unresolved obligations, recovery, and completion.Source: §2.3 · pp. 5–6

3 ADF-EA: Agent Architecture and Persistent Execution Semantics

ADF-EA places a revisable agent proposal and device providers within an architecture where Device Capability Contracts provide shared semantics and persistent execution state governs authority. The lifecycle distinguishes evidence-supported progress, unresolved outcomes, and invalidated prerequisites across planning, execution, and recovery.

3.1 DCC-Grounded Planning and Execution Authority

  • The agent submits inspectable candidate actions, while execution assurance interprets them against contracts and task semantics, mediates dispatch, and returns feedback.The authority model assumes a declared task specification, mediation of relevant device actions, and contract and adapter definitions of physical meaning.Source: §3.1 · pp. 6–7

3.2 Device Capability Contracts

  • A Device Capability Contract unifies invocation conditions, intended effects, evidence requirements, and interruption rules as the shared semantic unit for planning and execution assurance.Contracts can be assembled from device models, manuals, procedures, and interface descriptions; bindings connect capability semantics to MCP, CLI, SDK, or other invocation routes.Source: §3.2 · p. 8

3.3 Problem Formulation: Ambiguous Outcomes and Execution Authority

  • The planner uses capability descriptions and dependencies to propose actions, but only qualified execution evidence makes an intended effect usable as task progress.A tool response records an interaction outcome without independently establishing accepted progress; a dependent action requires its represented prerequisites to be established.Source: §3.1 · pp. 6–7, §3.3 · p. 10
  • Under indistinguishable public histories, prohibited duplicate effects, and no effective deduplication or rollback, no controller can guarantee sound completion, no duplicates, and eventual success in both histories.ADF-EA does not resolve permanent unobservability; it may gather distinguishing evidence when available or withhold physical recovery and successful completion otherwise.Source: §3.3 · pp. 10–11

3.4 Evidence and Authority Transition Semantics

  • The runtime retains certificates, unresolved obligations, attempt status, contract context, and remaining budgets, while only live evidence remains usable for supporting progress.A retained record may cease to be usable; applicable evidence requirements must be satisfied with a nonempty evidence basis for an effect certificate.Source: §3.4 · pp. 11–12

Admission and evidence

ADF-EA governs execution through validated proposals, qualified evidence, and persistent state that constrains observation, retry, repair, and completion. Its formal rules preserve unresolved outcomes and budgets across revisions, with soundness claims conditional on deployment assumptions.

Admission and evidence

  • A proposal is validated against task, dependency, state, and budget constraints; provider responses alone do not establish effects, which require qualified positive evidence for progress promotion.Revision retains certificate history, unresolved outcomes, and budgets; it does not itself create a physical effect or evidence.Source: Admission and evidence · p. 13

Observation and recovery

  • Observation reacquires evidence without physical retry, whereas retry requires qualified negative evidence and repair requires a policy-permitted response to a currently missing linked state.Repair consumes physical budget but no failure-retry allowance; uncertain or unsuccessful repair creates a new unresolved outcome subject to ordinary observation and retry rules.Source: Observation and recovery · p. 14

Rejection and termination

  • Unsupported repetition and repair with unknown or insufficient current evidence are rejected, while stopping grants no completion authority and terminal policy excludes unresolved in-flight effects.Invalidated certificates remain historical records but no longer support current progress.Source: Rejection and termination · pp. 14–15

3.5 Conditional Soundness

  • The formal guarantees depend on sound task predicates, evidence, live-state checks, mediated dispatches, serialized budgets, and sound obligation coverage; the implementation mapping is narrower than arbitrary DAG repair.The reported behavior is supported for synchronous state-setting experiments; asynchronous partial effects, arbitrary dependency invalidation, and concurrent budget use require separate implementation guarantees.Source: §3.5 · pp. 15, 17
  • Under A1–A5, authorized completion satisfies the trusted task obligations, while physical reexecution is limited to distinct contract-retry and state-repair admission cases.Retries require a correlated unresolved operation, qualified negative evidence, replay permission, admissible dependencies, and remaining allowances; repair requires a qualified current negative observation for a state needed by the next action and policy-permitted admission.Source: §3.5 · pp. 15–16

3.6 Realizing the Agent–Execution Loop

  • The runtime binds capabilities and dependencies to concrete tools and evidence routes, qualifies observations by source, execution, target, and freshness, then exposes progress and authorization decisions to the agent.Residual proposals undergo the same checks while retaining original obligations and remaining budget.Source: §3.6 · p. 17

4 Evaluation

The evaluation tests whether explicit contracts support execution checks, preserve permitted completion, maintain obligations through faults and revisions, and generalize to new compositions. Its studies span simulated process-control, household, and robotic tasks, published-algorithm comparisons, native executions, and model/framework integrations.

4.1 Controlled Comparison with Published Algorithms

  • 14/14 permitted conditions achieve evidence-qualified completion with ADF-EA and no violating dispatches; ToolGate, VTC, and Direct achieve 9, 12, and 11 qualified completions, respectively.ADF-EA obtains qualified completion in all seven evidence-recovery conditions, all three retry-permitted conditions, and the condition combining state repair with later evidence loss.Source: §4.1 · pp. 19–20, Table 3 · p. 19

4.2 Composition Reuse after Freezing Contracts

  • ADF-EA supports five of six new compositions with frozen contracts and runtime; the sixth fails because the mapping incorrectly requires a producer for an initially true preservation fact.Candidate arrangements remain explicit inputs, so this study tests execution support for new compositions, not autonomous plan discovery.Source: §4.2 · p. 20

4.3 Native Execution Cases: State Repair and Evidence Loss

  • All three native repair tasks recover with one necessary state repair each and complete with qualified evidence; under persistent evidence loss, the agents stop without repeated Put execution or unsupported completion claims.The native cases comprise six development episodes, three per condition; necessary repairs and rejected requests are excluded from improper repeated dispatches.Source: §4.3 · p. 21, Table 4 · p. 21

4.4 Mechanism Evidence: Observation, Retry, and Continuation

  • Observation-based recovery discharges temporary evidence loss and enables Close without replay, while persistent evidence loss blocks repeated Put and completion; component removals lose all 14 stale-evidence recoveries or restore all 14 unavailable-successor dispatches.In paired controls, retry permission determines whether a repeated request is authorized; lifecycle tests select all prescribed responses across 49 cases, versus eight for Direct.Source: §4.4 · pp. 21–22

4.5 Cross-Domain Skill Reuse

  • In the robotic skill study, ADF-EA rejects a repeated transport request before provider entry and withholds completion when effect evidence remains unavailable, although the simulator-native goal is physically satisfied.The controller remains responsible for the underlying continuous behavior.Source: §4.5 · p. 22, Table 5 · p. 22

4.6 Execution Assurance across Models and Agent Frameworks

  • Across 150 framework runs, ADF-EA preserves all 50 permitted completions, prevents 50 unavailable calls, and incorrectly blocks none of 197 legal requests.In Room-exit, Direct falsely declares completion in six runs per model, while ADF-EA records none in valid trajectories; the proposal-replay study also reduces false completions and violating-action runs from five to zero for each of four models.Source: §4.6 · pp. 23–24

5 Discussion

ADF-EA combines revisable proposals with persistent execution state, using DCCs to give planning and runtime a shared basis for execution authority. The discussion highlights complementary recovery and restraint while delimiting the assumptions and deployment scope of the results.

5 Discussion

  • State repair restores invalidated prerequisites, observation recovery establishes missing evidence without repeating work, and persistent obligations block unsupported reinvocation.Current admission checks also prevent unavailable calls, while the adaptive model and framework results retain completion in permitted conditions.Source: §5 · p. 24
  • The formal soundness theorems characterize declared transition rules, while experiments demonstrate lost-prerequisite repair and rejection of repeats with unresolved outcomes.The contribution is the reusable execution mechanism, with proofs making its authorization properties explicit.Source: §5 · p. 24
  • DCC semantics and provider adapters support reuse across multi-step manipulation skills, discrete household actions, heating, four-model replays, and five SDK integrations.The core retains the same rules for progress, obligations, renewed authority, and completion across these interfaces.Source: §5 · pp. 24–25

5.1 Deployment Scope and Further Directions

  • The formal properties depend on correct contract semantics, sound and timely evidence, and mediated execution.Implemented state repair covers represented sequential state-setting tasks through trusted public-state projections; asynchronous partial effects and concurrent budget use require corresponding guarantees.Source: §5.1 · p. 25
  • Real-device deployment requires reliable sensing and protection across observation-to-action intervals, while continuous control remains the skill provider’s responsibility.Extending to additional task families and real devices will further test sensing, timing, and provider guarantees.Source: §5.1 · p. 25

6 Conclusion

ADF-EA unifies capability-based planning and evidence-grounded execution through DCCs and persistent state, with conditional soundness results for completion and recovery authorization. Evaluations report evidence-qualified completion across the controlled conditions alongside recovery and reuse results; the appendix describes supporting studies and their distinct designs.

6 Conclusion

  • ADF-EA achieves evidence-qualified completion in all 14 completion-designated conditions with zero violating dispatches in the controlled comparison.The framework integrations preserve all fifty permitted completions while preventing all fifty unavailable-provider calls made by Direct.Source: §6 · p. 25
  • Persistent execution state retains obligations and budgets while the lifecycle supports observation recovery, permitted retries, and necessary state repair.Conditional soundness results characterize completion and recovery authorization.Source: §6 · p. 25
  • Evaluations span multiple LLMs, five agent frameworks, and simulated process-control, household, and robotic manipulation domains.The conclusion presents these as evidence for a reusable architecture under consistent execution rules.Source: §6 · p. 25

A Supporting Evaluation Studies

  • The supporting studies test adaptive execution, mechanisms through fixed proposals and contract perturbations, composed faults, domain cases, and framework and model reuse.Study populations and event counts remain specific to each study rather than pooled.Source: A Supporting Evaluation Studies · p. 29

A.1 Controlled Comparison: Scoring and Reproducibility

The controlled comparison distinguishes physical goal attainment from authorized, evidence-qualified execution and documents its scoring, methods, and artifacts. Its probes show why physical success alone does not establish permitted completion.

A.1 Controlled Comparison: Scoring and Reproducibility

  • The controlled comparison comprises 68 formal executions and a separate 16-execution pilot, with retry and evidence groups that can overlap.Its three task identifiers include two with conjunctive goal structure; the groups’ denominators must not be added.Source: §A.1 · p. 29
  • The independent scorer reconstructs physical state, evidence, request-time legality, provider availability, operation history, and consumed budgets from retained events.Its tests include evidence mutations, missing evidence, unclaimed physical success, prior violations, and native-state/event inconsistency.Source: §A.1 · p. 29
  • ADF-EA rejects a third dispatch when the original two-dispatch budget remains binding, even though that leaves the physical goal unmet.The budget-reset probe shows that physical attainment in stopping probes does not establish legal completion.Source: §A.1 · pp. 29–30, Table 8 · p. 30
  • VTC’s 16/17 versus ADF-EA’s 15/17 aggregate physical attainment reflects a budget-violating third dispatch; both attain 14/14 physical goals in completion-designated conditions.Table 8 separates the completion-designated group from stopping probes and aggregate physical outcomes.Source: §A.1 · p. 30, Table 8 · p. 30
  • When placement executes but evidence is missing, ADF-EA rejects completion because the earlier obligation remains unresolved.A permitted retry can establish the processing effect, but later revision and redundant-action requests are rejected.Source: §A.1 · p. 31
  • The fixed seven-capability library and baseline reproductions retain their described algorithms without added obligation gates, task-budget enforcement, repair scheduling, or completion gates.The ADF arm uses a fixed lifecycle plus a retry hook consuming runtime-declared authority, while preserving the original request stream.Source: §A.1 · p. 31
  • The composition study completes for all four methods on five of six cases, while ADF-EA scores 5/6 because mapping initialization fails on a satisfied false-valued goal.The missing support is the mapping of the already satisfied goal, not a failure of the candidate action sequence.Source: §A.1 · p. 31
  • The appendix retains inputs, manifests, event records, scores, and summaries, with the pilot stored separately.The scorer distinguishes evidence-qualified endpoint completion from violation-free completion; these are separate outcomes.Source: §A.1 · pp. 31–32

A.2 Experimental Design and Outcome Measures

The evaluation combines simulated domains, fault conditions, controlled paired replays, and adaptive agent comparisons to test execution decisions and outcome measures. The designs distinguish goal achievement from evidence-qualified, violation-free, and safe stopping outcomes.

A.2 Experimental Design and Outcome Measures

  • Simulated evaluations include household tasks, bounded manipulation skills, heating, and room-exit tasks, with different environments supporting fault tests and capability-interface reuse.All four environments use software simulation, with simulator-native state or structured process models for outcome assessment.Source: §A.2 · p. 32
  • Faults distinguish suppressed effects, stale evidence, unavailable successors, and invalid proposals, with recovery or withholding determined by each condition’s policy.Fault categories test shared decision rules across different capability semantics and are not independent samples of naturally occurring deployment failures.Source: §A.2 · p. 32
  • Controlled paired replay holds task, initial state, proposed actions, fault schedule, budget, and evaluator fixed, whereas adaptive comparisons allow each arm to choose actions and termination.The adaptive comparisons assess resulting agent systems rather than matched-proposal estimates of one isolated runtime component.Source: §A.2 · p. 32
  • Table 10 maps research questions to study designs, sample composition, and result locations, while keeping study-specific populations unpooled.Reusing tasks across faults, arms, frameworks, or runs does not create independent task samples.Source: Table 10 · p. 33, §A.2 · p. 34
  • Qualified completion requires declared evidence conditions and a protocol-valid declaration, with runtime authorization additionally required for ADF-EA.Goal-confirmed completion alone does not require qualified evidence.Source: §A.2 · pp. 32, 34
  • Violation-free completion adds the requirement of no earlier policy-violating dispatch, so it is distinct from a qualified endpoint.Dispatch violations concern declared experimental constraints, including unavailable capabilities, not physical injury.Source: §A.2 · p. 34
  • The reevaluations use a common policy that permits one retry after qualified effect failure but forbids repetition after verified success and provider replacement.ADF-EA may initiate observation repair; the comparison is of systems under shared feedback and policy, not an isolation of enforcement from feedback.Source: §A.2 · pp. 34–35
  • The no-continuation condition requires an explicit stop without a preceding policy-violating provider dispatch when a required successor is unavailable.Evidence assessment reuses the runtime qualifier and is therefore not an independent validation of qualifier correctness.Source: §A.2 · p. 35

A.3 Execution Authorization in Adaptive Agent Runs

Adaptive and controlled studies test whether execution assurance preserves permitted completion and recovery while preventing unsupported completion and unauthorized dispatch. Across the lifecycle, evidence recovery, continuation authorization, and contract semantics determine which actions remain justified.

A.3 Execution Authorization in Adaptive Agent Runs

  • ADF-EA preserves all nine feasible room-exit completions, eliminates six false completions observed with Direct, and prevents unavailable and repeated dispatches in valid trajectories.Flash safely terminates all nine infeasible runs; GLM stops in all seven valid infeasible runs, with repeated dispatches reduced to zero for both models.Source: §A.3 · pp. 35–36
  • Both arms achieve qualified completion in all 25 permitted AI2-THOR runs; ADF-EA retries all five suppressed effects and recovers evidence in all five stale-evidence runs.ADF-EA also blocks unavailable provider calls before dispatch, while neither arm makes unsupported completion claims.Source: §A.3 · pp. 36–37

A.4 Controlled Authorization and Evidence Recovery

  • ADF-EA selects the required response in all 49 controlled lifecycle cases, compared with eight for Direct, and rejects all 26 invalid proposals.The cases cover completion, observation, rejection, and stopping; twelve permit completion.Source: §A.4 · p. 37
  • In two AI2-THOR populations, normal completion is preserved in 43/43 and 31/31 tasks, while injected-fault false completions fall from 15 to zero and from eight to zero.ADF-EA rejects missing effects, reacquires stale evidence, and blocks unavailable successors according to each condition.Source: §A.4 · p. 37
  • Removing evidence reacquisition loses all fourteen stale-evidence recoveries, while removing continuation authorization restores all fourteen unavailable-successor dispatches.Full ADF-EA retains both benefits.Source: §A.4 · p. 37
  • Intact contracts and sham mutations retain all twelve expected distinctions across 72 executions, whereas targeted weakening retains none.The paired contrasts test invocation, effect, evidence, and interruption semantics.Source: §A.4 · p. 37
  • Of twenty Heating-derived evidence schedules, eight verify directly, five recover through observation, and six remain correctly unverified; one unsupported measurement-correlation case is not evaluated.Conflicting evidence yields UNKNOWN, while a wrong-sample failure is classified as inadmissible evidence.Source: §A.4 · p. 38

A.5 Policy-Controlled Recovery and Completion

Policy-controlled tests vary whether retries and other recovery actions are permitted, while composed-fault and Heating cases test retention of valid progress. ADF-EA enforces those permissions and carries unresolved obligations forward without discarding completed work.

A.5 Policy-Controlled Recovery and Completion

  • In the 44-run controlled policy study, both arms receive identical scripted requests and policies, but only ADF-EA enforces contract rules before forwarding requests.No online model is called; early completion acceptance can prevent later scripted requests from being consumed.Source: §A.5 · p. 38
  • With retry permitted, ADF-EA verifies the successful retry and accepts completion; with retry forbidden, it rejects the same request and leaves the task incomplete, while Direct dispatches the forbidden retry.The first acknowledged request is suppressed before reaching Unity, and fresh readback confirms the cabinet remains closed.Source: §A.5 · p. 38
  • Both arms complete 2/2 normal, 2/2 evidence-reacquisition, and 2/2 retry-permitted runs; ADF-EA prevents all six policy violations and both categories of unsupported completion accepted by Direct.Neither arm incorrectly blocks a legal physical request: 0/20 for Direct and 0/22 for ADF-EA.Source: §A.5 · pp. 38–39
  • The permitted retry is the first native execution after fault injection intercepts the initial provider request; ADF-EA uses 282 implicit native reads versus 147 for Direct.The study distinguishes provider recovery from repeated native physical action.Source: §A.5 · p. 39

A.6 Retaining Progress through Failure and Continuation

  • On sixteen composed-fault tasks, ADF-EA selects the prescribed outcome in 16/16 cases versus 0/16 for Direct, with no physical retries.An unresolved earlier effect can block a later unavailable successor while still-valid progress remains available.Source: §A.6 · p. 39
  • Across four Heating cases, scenario completion rises from 2/4 to 4/4 and both provider recoveries succeed, while physical actions increase from seven to nine.ADF-EA retains the valid prefix, rebinds unresolved recording, and gathers measurements without reheating when heating evidence is incomplete.Source: §A.6 · pp. 39–40

A.7 Reuse across Models, Agent Frameworks, and Device Domains

Across model-driven framework integrations and device domains, the studies test whether shared execution rules preserve recovery and enforce dispatch constraints. Results report preserved permitted completion and improved control, while contracts and adapters provide domain-specific meanings to the common lifecycle.

A.7 Reuse across Models, Agent Frameworks, and Device Domains

  • Adding a domain grounding relation enables ADF-EA to reject 26/26 target mismatches and accept 26/26 valid controls on a fresh population without modifying the assurance core.The initial projection misses eight target mismatches because the grounding relation is absent.Source: §A.7 · p. 40
  • For each of four upstream models, ADF-EA preserves all five goal-confirmed completions while reducing false completions and runs with violating actions from five to zero.The same retained proposals are replayed through Direct and ADF-EA.Source: §A.7 · p. 40
  • The five SDK integrations connect framework-specific model/tool loops to the same assurance core, while contracts and adapters map domain knowledge into shared admission, effect, progress, and continuation rules.Cross-domain comparisons use aligned fault categories, not independently sampled naturally occurring failures.Source: §A.7 · pp. 40–42
  • Across all five frameworks, both arms complete every permitted-retry and stale-evidence run; ADF-EA prevents unavailable-provider dispatches in all no-continuation runs, versus violations in 5/5 Direct runs per framework.All 150 runs finish without protocol, SDK, transport, or budget failure, and ADF-EA incorrectly blocks none of 197 legal requests.Source: §A.7 · p. 41
  • In Meta-World, ADF-EA reacquires qualified evidence in all eight stale cases without a skill retry and blocks every unavailable successor in the six applicable multi-skill plans.Heating completes provider recovery through two additional actions.Source: §A.7 · pp. 41–42

A.8 Task Utility and Interaction Counts

Interaction counts compare the work needed to preserve task outcomes across adaptive studies. ADF-EA reduces model calls in ReAct and the five-framework study while shifting some observation work into runtime checks; room-exit shows a different interaction pattern.

A.8 Task Utility and Interaction Counts

  • Model calls fall from 129 to 122 in ReAct and from 351 to 297 across five frameworks, while native-action counts remain the same and runtime-initiated observations increase.Direct initiates 37 observations across the studies, compared with five agent-initiated and thirty runtime-initiated observations for ADF-EA; additional metadata reads support checks.Source: §A.8 · p. 42
  • In room-exit, Flash model calls rise from 89 to 118 as physical-action dispatches fall from 67 to 45; GLM uses 81 versus 113 calls in valid trajectories.For GLM, ADF-EA uses 131 calls across all scheduled runs, including two interrupted trajectories.Source: §A.8 · p. 43
  • Across 100 paired logical units, both arms obtain appropriate normal outcomes in 50/50 cases, while ADF-EA selects the prescribed late-fault outcome in 50/50 versus 0/50 for Direct.The deterministic benchmark varies execution depth and evidence width over five levels from 2 to 32.Source: §A.8 · p. 43

B Execution Lifecycle: Implementation Details

This section describes how ADF-EA applies shared contract semantics to authorize proposals, verify effects, and govern continuation and recovery during execution. It also reports paired-replay evaluations across four upstream models and scheduled framework integrations.

B.1 Authorizing Proposals and Continuation

  • Materialization exposes execution ordering, effect dependencies, and evidence requirements, while validation and provider binding determine whether a candidate can be dispatched in the captured context.A schema-valid proposal may still be inadmissible; changes to a target, parameter, capability, or represented state require revalidation or provider-level protection.Source: §B.1 · pp. 43–44

B.2 From Qualified Evidence to Verified Progress

  • Verification selects evidence associated with the bound execution and route, checks freshness and grade, and builds windows meeting required count, identity-distinctness, and cadence conditions.Missing eligible observations yield INSUFFICIENT EVIDENCE or UNKNOWN when gaps indicate an unknown state; fallback observation identity does not establish distinct physical sensors.Source: §B.2 · p. 44
  • Progress is promoted only when all requirements are satisfied; an unsatisfied requirement takes precedence over unknown or insufficient evidence, while conflicting windows produce UNKNOWN.In the wrong-sample case, the field mismatch makes the measurements inadmissible for the requested heating effect, not evidence that the effect is absent; conflicting records under one occurrence identity trigger integrity rejection.Source: §B.2 · p. 45

B.3 Continuing from Progress and Unresolved Obligations

  • Continuation distinguishes authorized retry, state repair, observation repair, unresolved uncertainty, and still-valid progress; qualified negative evidence alone does not authorize physical execution.Retry also requires an unresolved obligation, permitted policy, eligible provider, satisfied invocation conditions, and remaining retry and action budgets. The evaluated Boolean recovery check requires enough eligible post-invocation observations to contradict the expected value, with none supporting it.Source: §B.3 · pp. 45–46
  • In the illustrative heating-and-recording trajectory, a failed recording leaves its obligation open while valid heating progress is retained, and an authorized replacement recorder can resolve the remaining obligation.Observation can resolve the heating verification obligation without repeating actuation; retained progress remains usable only while its persistence and freshness conditions hold.Source: §B.3 · p. 46, §3 · p. 47, §4 · p. 47

C.1 Task populations and controlled execution

  • The 12 paired contrasts yield 72 executions across intact, targeted-weakening, and sham conditions, with targeted and sham conditions isolating each semantic block’s decision contribution; lifecycle tests include four Heating process-control cases and bounded Meta-World manipulation skills.The unavailable-successor condition excludes two single-skill plans as not applicable; Heating uses scenario verification and does not produce the generic terminal TaskResult.Source: §C.2 · p. 50, §C.3 · pp. 50–51

C.4 Composed faults and evidence perturbations

  • In the Heating-derived evidence stress study, 8 of 20 schedules verify directly and 5 verify after additional observation; unverified cases include insufficient evidence, field mismatch, integrity rejection, and UNKNOWN.These controlled perturbations test whether supplied evidence justifies a completed heating effect, not a new heating success rate; measurement correlation is not evaluated because its required field is unrepresented.Source: §C.4 · pp. 52–53, Table 33 · p. 53

C.5 Recovery-Policy Control Construction and Scoring

  • Recovery-policy controls and adaptive reevaluation use bounded observation and physical-request budgets, distinguish provider dispatch from native action execution, and score authorization separately from goal completion.The single-task controls exercise 11 request sequences through ReAct and a shared tool adapter; the reevaluation matrices comprise 60 ReAct runs and 150 runs across five SDKs, retaining all scheduled runs.Source: §C.5 · p. 54, §C.6 · p. 55

C.7 Framework Interaction Details

  • Five installed SDKs retained their own model/tool loops, and all 30 scheduled runs per framework finished without protocol, SDK, transport, or budget failures.The qualification included real model calls and native AI2-THOR execution, rather than scripted model responses or device fixtures.Source: §C.7 · p. 56

C.8 Execution Assurance across Model-Generated Proposals

  • The cross-model study paired Direct and ADF-EA replays of 60 valid proposals across four models and 15 AI2-THOR task instances with assigned execution faults.The instances covered suppressed effects, stale evidence, and cases without safe continuation; all 60 pairs ran without invalid pairs or execution errors.Source: §C.8 · p. 56
  • For each of four models, ADF-EA rejected all five suppressed effects, stopped in all five unsafe-continuation cases, and completed all five stale-evidence cases through observation-only reacquisition.Direct reported completion for all five suppressed effects and dispatched violating actions in all five no-continuation cases, while reaching the physical goal in stale-evidence cases.Source: Table 37 · p. 57, §C.8 · p. 57

C.9 Room-exit Configuration and Terminal Records

The Room-exit study reports GLM outcomes and trace-derived terminal records, alongside a synthetic benchmark varying execution depth and evidence width. The accompanying context limits generalization to the full deployment population.

C.9 Room-exit Configuration and Terminal Records

  • The Flash study retained 36 method-valid trajectories, while the GLM study had two transport-interrupted ADF-EA trajectories after retries were exhausted.The GLM study retained 18 valid Direct and 16 valid ADF-EA trajectories; transport-call totals include 11 timeouts, with nine retries recovering seven calls.Source: §C.9 · pp. 57–58
  • Nine of 16 valid ADF-EA GLM trajectories reached goal-confirmed completion and seven stopped; ADF-EA recorded zero invalid or unavailable dispatches, versus six and eight for Direct.Two additional ADF-EA trajectories were interrupted after transport retries were exhausted; endpoint fractions use valid trajectories.Source: §C.9 · p. 58, Table 39 · p. 58
  • Across the two Room-exit studies, replans count next-action deviations from the expected sequence, including rejected proposals; in six GLM ADF-EA runs, ten rejections preceded each model-issued stop.Rejected proposals consume interaction budget without causing additional device dispatches; Table 40 separates safe-termination sources from preceding dispatch violations.Source: §C.9 · p. 59, Table 40 · p. 59

C.10 Execution Outcomes across Depth and Width

  • The synthetic benchmark varies execution depth and evidence width to test late-fault decisions and verified-prefix preservation.Table 41 is captioned as reporting synthetic execution-depth outcomes and verified-prefix preservation; no cell values are supplied here.Source: §C.10 · p. 59, Table 41 · p. 59

C.11 Additional experimental context

  • The reported studies use qualified task populations and recorded adaptive trajectories; the small curated cross-domain and separately varied framework and model studies do not estimate full-deployment performance.The Phase-B sample uses 16 family-by-room strata with three candidates per stratum; a fresh fault replication retained 31 paired units.Source: §C.11 · pp. 59–60

D Contract Implementation and Assurance Boundaries

The section distinguishes public DCC schema checks from runtime enforcement and identifies assumptions that bound assurance claims. It also reports a reevaluation after protocol and recovery-integration changes.

D Contract Implementation and Assurance Boundaries

  • Public DCC schema validation enforces required effects, evidence, unique identifiers, and interruption coverage, while runtime contracts add provider, lifecycle, and execution-context information.The public schema and provider-bound runtime representation serve different roles.Source: D Contract Implementation and… · p. 60
  • Distinct evidence-window identities do not establish distinct physical sensors or statistical independence, and the public evidence helper is narrower than runtime verification.The public helper’s Boolean result should not be equated with runtime lineage, conflict, and progress decisions; budgets and physical admissibility require runtime enforcement.Source: D Contract Implementation and… · p. 60
  • Catalog and binding checks do not automatically propagate later revocation to dispatched operations, expire contracts by wall-clock time, or detect unreported provider drift.Online updates cannot be assumed to revoke existing authority without explicit revalidation.Source: D Contract Implementation and… · p. 60
  • Completion soundness depends on correct effect predicates, trustworthy associated observations, faithful qualification and promotion, and suitable persistence or revalidation of historical evidence.These are assumptions and proof obligations, not unconditional guarantees from schema validation.Source: D Contract Implementation and… · pp. 60–61

D.1 Evaluation Versions and Recovery Integration

  • All 25 effect-suppressed ADF-EA runs across five SDKs completed permitted recovery in the revised integration, but the changed parser, endpoint, policy, and integration prevent isolating the parser repair’s effect.The seven corresponding tasks completed with qualified evidence and ADF-EA authorization; original raw model responses were unavailable for replay.Source: §D.1 · p. 61

Related papers

Loading 2609.30691v1…