Is the answer based on the right business records?

1. Introduction

A question such as which orders require attention appears conversational, but its answer depends on a chain of operational assumptions. The system must retrieve the relevant population, distinguish a shipping label from a physical handoff, resolve account identity and understand what attention authorizes. If it then schedules a message or proposes a change, completion introduces further requirements. Language quality is only one component of the result.

The case examined here contains a historical observer audit and later source artifacts. These reveal a progression in engineering questions, from access to provider data toward explicit treatment of missing evidence, identity, replay and policy. They do not establish a continuous production deployment or prove that the later code was caused by any particular incident. The legacy assistant, newer observer and later control system remain distinct implementations. ^{[A1] [A2]}

Our question is therefore narrower than whether an agent can run a business: what evidence must be available before a particular operational conclusion or transition can be accepted? We propose a task-specific representation of those obligations. The framework is intended to make evaluation and failure diagnosis more precise, while preserving the possibility that additional controls impose costs or withhold useful work.

2. Related work and conceptual position

ReAct demonstrates a method for interleaving language-model reasoning with environmental actions. It supplies a useful agent architecture, but the present question concerns the conditions under which an application accepts the resulting work. τ-bench advances that question by evaluating conversations with tools and domain rules against annotated final database states, while measuring consistency across trials. We adopt the importance of explicit outcomes without claiming that this local system was evaluated on either benchmark. ^{[1] [2]}

AgentDojo evaluates tool-using agents in environments containing untrusted data and prompt-injection attacks. It motivates testing authority under adversarial inputs rather than only ordinary requests. Our case evidence does not establish a successful injection attack. Its relevance is prospective: information retrieved to answer a question should not acquire authority merely because it appears in the same conversational context. ^[3]

Classical systems research supplies two further foundations. Saltzer and Schroeder articulate complete mediation and least privilege, including the need to check authority across access paths. Saltzer, Reed and Clark argue that some correctness properties require application-level knowledge that lower layers cannot fully supply. We use these principles to distinguish a successful tool exchange from authorized and observed business completion. Our proposed graph is an application-specific synthesis of these concerns, not a replacement for access control or a claim of novel security theory. ^{[4] [5]}

3. Materials, version boundaries and method

The first source is a technical audit dated September 20, 2026. It describes the newer observer application and attributes its own runtime checks. The second is a later implementation snapshot covering reconciliation, polling and action-policy behavior, including regression history. The third is the retained test material and runner cache inspected in October. No provider write, live-system probe or full test suite was rerun to produce this paper. ^{[A1] [A2] [A3]}

We classified each claim by what its source can establish. An audit supplies dated observations and reviewer conclusions. Source establishes implemented logic in a snapshot. A test definition establishes an intended assertion, while cached outcomes supply limited execution evidence. These categories cannot be substituted for one another. In particular, a source-level guard does not prove every deployed request passed through it, and a passing file-level cache cannot identify all assertions, skips or environment conditions.

The comparison asks which obligation a documented defect left unsatisfied and which later mechanism addresses that class of problem. This is analytical correspondence, not causal attribution. We avoid pooling the observer's capabilities with the control system's tests or describing policy checks as executed actions. Anonymous descriptions preserve the technical relationship without releasing customer records, account identifiers or private operational values.

4. Analysis of the retained evidence

The audit reports that provider reads were capped and that partial source failures could remain embedded in an otherwise successful combined response. A correct calculation over retrieved records therefore could not establish a complete operational total. The limitation is epistemic: the system might have accurate values for observed rows while lacking evidence about the requested population. A source failure and a genuinely empty population must produce different interpretations. ^[A1]

The same audit identifies semantic substitutions. Orders created since midnight contributed to a due-today measure, while label creation was used as a shipping signal. Those events need not coincide with promised shipment deadlines or carrier possession. The audit also describes a scheduled task whose generated output was discarded rather than delivered. These findings separate three possible failures: insufficient evidence, an incorrect business definition and an uncompleted communication. They are historical findings, not assertions about every current branch. ^[A1]

Later reconciliation artifacts implement explicit coverage information, account-scoped identities and not-evaluated outcomes for unavailable populations. Test definitions address ambiguity, partial coverage, replay and transactional completion. The saved cache contains 47 file entries with no failed flags, including eight database test-file entries. It does not establish an assertion count, absence of skips, commit binding or live integration health. The evidence supports implemented mechanisms and retained testing activity, not independently repeated certification. ^{[A2] [A3]}

The action-policy component checks request scope, credentials, nonces, expiry, allowances and replay behavior. Regression history includes cross-account idempotency and denial-handling corrections. Its documented endpoint is policy_checked: it cannot approve, enqueue or execute a provider write. This boundary is part of the engineering result. Describing it as completed autonomous operation would attribute a capability the implementation explicitly excludes. ^[A2]

5. Proposed contribution: an evidence-obligation graph

We propose representing an operational task as claims and transitions connected to explicit evidence obligations. For a shipment-attention report, obligations might include a defined time window, known source coverage, the correct shipment event and an authorized audience. For a proposed mutation, further obligations would cover request identity, current authority and the expected effect. Delivery or external execution introduces an observation obligation after the action, not merely a successful request before it.

Each obligation records its scope, evidence version, observation time, verifier and status: pass, fail or unknown. The graph expresses dependency rather than a universal sequence. Read-only analysis does not need proof of a provider mutation; an approved action does. The required set must therefore be declared per task. Calling every absent obligation not applicable would defeat the framework, while requiring every possible check would make ordinary work impossible.

The proposed acceptance rule below applies only to the obligations declared for that task. Evidence is bound to the account, request and relevant source or policy versions so a successful check cannot casually transfer to another context. A coverage check may become stale after a source changes; authority may expire before execution. The graph must record invalidation as well as progress. It is an audit representation, not a proof that every verifier is correct.

Proposition one is that explicit coverage obligations reduce unsupported population-level conclusions under partial reads. A counterexample is urgent work where bounded evidence legitimately supports a narrower action: indiscriminate withholding could be worse. Proposition two is that scope-bound authority checks reduce incorrect reuse of approval across retries. It fails if enforcement paths bypass the verifier or if the underlying identity is wrong. Proposition three is that a separate completion observation detects generated-but-undelivered work. A counterexample is an unreliable receipt source that reports success without establishing the intended application effect.

The proposal differs from simply adding a checklist by making dependencies, unknown states and invalidation inspectable at runtime. It differs from a final-state benchmark by explaining which unfulfilled obligation prevents acceptance before a final outcome exists. Its distinctive claim is about a useful representation for these cases, not priority over existing workflow, provenance or assurance methods. A broader novelty review and comparative evaluation remain necessary.

6. Evaluation protocol and counterfactual tests

Begin with a synthetic replay environment whose source populations, business events and authorization rules are known. Freeze task definitions and acceptance conditions before running treatments. Include complete reads, truncated pages, unavailable providers, stale snapshots, duplicated events, ambiguous account references and concurrent requests. Keep external provider execution outside the environment so failure experiments cannot affect real operations.

Compare a baseline summary path with one that retains explicit coverage and semantic checks. Separately compare unbound replay handling with account- and request-bound policy decisions. The separation prevents a combined improvement from being assigned to the wrong control. Hold model configuration and source responses fixed for paired comparisons, then repeat stochastic components. AgentDojo motivates including hostile instructions in retrieved data, but its attack results must not be treated as measurements of this system. ^[3]

Measure unsupported conclusions, correctly withheld claims, missed actionable issues and recovery after missing evidence arrives. For authority, measure incorrect acceptance and incorrect denial separately, including revocation between checking and proposed execution. For completion, inject lost acknowledgments, delayed observations and repeated requests. Record duplicate intended effects and unresolved outcomes rather than claiming exactly-once behavior from a local idempotency key. This is an application of the distinction between lower-level exchanges and application-level correctness, not a new distributed-systems guarantee. ^[5]

A useful result must show its costs. Report latency, operator interventions and time spent on unresolved cases alongside error reduction. A system that refuses every task can avoid unsupported conclusions while accomplishing nothing. Require a declared minimum of useful task completion, examine failures by scenario and retain all exclusions. Only after these tests should a supervised field comparison evaluate operator-reviewed outcomes. Neither the synthetic study nor the field phase has been run for this paper.

7. Limitations

The evidence is selected and retrospective. The audit reflects one version, the later implementation reflects another, and source chronology does not establish causal learning from a specific defect. Saved test outcomes do not demonstrate deployed coverage, production reliability or an autonomous warehouse. The paper supplies no field accuracy distribution, labor-saving estimate, commercial return or controlled before-and-after comparison. ^{[A1] [A2] [A3]}

An obligation graph can also create false confidence. Incorrect business definitions, compromised verifiers or stale evidence may produce convincing pass states. More logging can obscure responsibility rather than clarify it. The proposal must therefore be assessed against simpler alternatives and include review of verifier quality. Its six practical concerns are a case-derived framework, not a validated universal taxonomy. Private source pointers remain outside the public paper, limiting independent reproduction of historical claims; synthetic replay would provide a separate reproducible test of mechanisms.

A simpler checklist may be sufficient for a low-volume process with one trusted source and direct human review. The proposed graph earns its additional complexity only where changing scope, multiple sources or asynchronous effects make evidence dependencies difficult to track. The practical recommendation is to begin with the smallest unresolved obligation in a bounded workflow, compare a simpler alternative and expand only when the added record changes a real acceptance or recovery decision.

8. Conclusion

Operational reliability depends on what an answer is entitled to claim and what evidence establishes the next transition. The retained audit and later implementation make those questions concrete: coverage differs from arithmetic correctness, business events differ from convenient proxies, and a policy decision differs from execution. Our proposed evidence-obligation graph preserves those distinctions and makes their costs testable. It should be accepted only if evaluation shows that it helps operators complete justified work with manageable recovery effort. The present contribution is that bounded proposal and its evidentiary basis, not a declaration that the business has become autonomous.