A Trace Is Not Evidence

An agent can produce a complete-looking execution trace without establishing what actually happened outside the boundary it observed. A tool-call span may show that a request was initiated. A response event may show what the caller received. Neither necessarily proves that a change was authorized, committed by the receiving system, or preserved in its final state.

The title is shorthand, not a literal assertion that traces have no evidentiary value. A trace is evidence of what an instrumented component recorded; it is not, by itself, conclusive proof that a requested external effect was committed, remains true, or was authorized. The question is whether its evidentiary value is sufficient for the specific claim being made.

Observation is not an outcome

In a distributed system, a trace represents the path of an operation through instrumented components, usually as related spans. A log record describes an event or observation, potentially with a timestamp, source, severity, and correlation identifiers. An audit record is captured and retained to support a defined accountability or review purpose. The same artifact may serve more than one role, but these labels do not guarantee identical completeness, integrity, or trustworthiness.

Consider the difference between four statements:

1. The agent intended to act. A model or workflow selected a tool and constructed its arguments.
2. The caller attempted an action. The integration layer initiated a request to an external service.
3. The receiving system handled an operation. Evidence may establish receipt, validation, queuing, acceptance, rejection, or durable commitment; these are not interchangeable states.
4. The intended external effect holds at an observed point in time. An appropriately authoritative state check supports this bounded claim, subject to its freshness and consistency guarantees.

A trace containing the first two observations does not logically establish the last two. Even a successful-looking tool response may be an acknowledgment of receipt, not proof that every asynchronous downstream effect completed. Conversely, missing telemetry does not demonstrate that no action occurred.

This is a question of claim-to-evidence correspondence: what exactly does an artifact establish, under which assumptions, and what remains unknown? This reading is consistent with OpenTelemetry’s description of distributed traces, which concerns instrumented operations rather than universal verification of external state.

An illustrative timeout at the trust boundary

Imagine a hypothetical procurement agent preparing a purchase order. An authorized person approves one order with a specified supplier, amount, and purchase purpose. The agent invokes create_purchase_order through an integration gateway. Its execution trace captures the tool name, intended supplier, request identifier, and time of the outgoing call. Then the gateway reports a timeout.

There are several plausible realities. The receiving service may never have received the request. It may have received the request and rejected it. It may have accepted or queued the request without yet completing it. Or it may have created the purchase order while the response was lost. The same local symptom—timeout—is compatible with these different external states.

A log entry saying create_purchase_order: timeout therefore describes a communication or observation failure; it cannot, without additional evidence, establish order_not_created. An immediate retry could generate a second order or exceed the approved amount. It also cannot be assumed safe merely because the original operation may be designed to be idempotent; that property must be defined and enforced by the particular service and request semantics. See the Amazon Builders’ Library discussion of idempotent retries for the distinction between retrying a request and preventing duplicate effects.

The defensible status is OUTCOME UNKNOWN until a reliable observation resolves it. A receiving-system order identifier, a correlated server-side event, or an authoritative query of the purchase-order record may narrow the uncertainty. Where a provider exposes no such evidence, the uncertainty must remain visible and the workflow may need to stop for controlled review.

This scenario is hypothetical. It does not describe a ZeroField deployment, measured incident, or tested recovery procedure.

Four layers of evidence

A useful evidence model separates four questions that an attractive tracing dashboard can otherwise collapse:

Layer 1 — Attempt evidence. Which operation did the agent or integration attempt, with which redacted parameters, target, correlation identifier, and observed time? Caller-side spans and tool-call logs are useful here. A recorded attempt should not be labeled completed merely because a function was invoked.

Layer 2 — Authority evidence. Under which identity, policy version, approval, scope, and validity period was the operation permitted? This requires appropriately protected authorization or approval records. Recording an approval reference in the same trace helps correlation but does not independently demonstrate that the approval was valid for this exact target and operation.

Layer 3 — Receiver evidence. What did the downstream system actually receive, validate, queue, accept, reject, or durably commit? Where supported, use the receiver's operation ID, audit event, transaction record, or durable acknowledgment, and record which stage it establishes. A response code must be interpreted under that service's contract; an accepted or successful response does not necessarily prove that a final business outcome exists.

Layer 4 — Result-state evidence. What does an appropriately authoritative observation of the target resource show after the operation, and at what time? A versioned resource read, transaction state, deployment identifier, or comparable domain-specific check may support a bounded outcome claim. Read replicas, eventual consistency, concurrent updates, and later changes can limit that inference. Independent checks help, but their trustworthiness, freshness, and completeness still require assessment.

These layers are an analytical framework, not a new mandatory protocol. Not every harmless read needs all four. The required assurance should be proportional to the risk of an incorrect conclusion.

What spans and logs cannot guarantee

Instrumentation is indispensable for diagnosing behavior, but several limits matter when a trace is treated as proof.

Coverage is conditional. Spans describe instrumented work; uninstrumented components and external services can remain invisible. OpenTelemetry sampling can decide not to record span data, while instrumentation gaps and telemetry-pipeline loss can produce other missing observations. A missing span—or an absent sampled trace—does not establish that the underlying operation never occurred. The OpenTelemetry Tracing SDK explicitly distinguishes sampling decisions such as DROP, RECORD_ONLY, and RECORD_AND_SAMPLE.

The observation point matters. A span emitted by a caller describes the caller's perspective. Its success status may establish only that the local API returned as expected. A receiving service can have a different view, especially across queues, retries, asynchronous work, or network interruption.

Time and correlation require interpretation. Source timestamps and collector observation timestamps may differ, as distinguished in the OpenTelemetry Logs Data Model. Trace identifiers support linking records but do not, on their own, establish a trustworthy sequence across unsynchronized systems or prove the identity of a downstream actor.

Integrity is not automatic. An editable text log and a separately protected audit record should not be granted equal assurance. Provenance, access controls, retention, tamper resistance, and integrity checks influence what can be inferred from a record. A hash of one file can detect change relative to an independently trusted hash; it does not establish the truth of the original event or completeness of the logging process.

Visibility creates privacy risks. Prompts, tool arguments, responses, and identifiers may contain confidential information. Capturing more telemetry does not always improve the evidence position if it introduces excessive collection or exposes sensitive data.

These limits do not argue for abandoning traces. They argue for stating the boundaries of their observations and corroborating claims that extend beyond those boundaries.

Test the claim, not just the call

An evaluation that asks only whether the expected tool was invoked—for example, a tool-called check in Microsoft Agent Framework—may miss a critical category of failure: the agent can produce a plausible trace and still report an unsupported result. A stronger, explicitly bounded evaluation asks whether the system's conclusion matches the evidence actually available.

Candidate scenarios include:

1. Missing receiver acknowledgment. A request is sent, but no authoritative receipt exists. The agent should report an unverified outcome rather than invent success.
2. Stale or replayed approval. A trace includes an approval reference that is expired or applies to a different resource. The system should not treat the reference as proof of current authority.
3. Partial downstream failure. The integration returns success while a required follow-up operation fails. The agent's completion claim must remain appropriately qualified.
4. Duplicate retry risk. A timeout is followed by an identical request. Tests should determine whether the service's idempotency contract prevents duplicate effects and whether the agent verifies that contract before retrying.
5. State divergence. A tool response says the update succeeded, but a trusted state read disagrees. The system should preserve the conflict rather than promote the optimistic message to fact.
6. Incomplete telemetry. Sampling or instrumentation gaps remove a span. The evaluator should not infer that the omitted action never happened.

A suitable assessment defines the tested implementation and versions, an expected decision for each scenario, the evidence available to the evaluator, and the permissible final claim. It can distinguish SUPPORTED, CONTRADICTED, and NOT ESTABLISHED conclusions rather than forcing every uncertain case into a binary success/failure label. Here SUPPORTED means supported for a specified claim, source and observation time—not proven permanently or in every possible system state.

These are proposed test cases. No ZeroField implementation, dataset, statistical benchmark, or measured PASS is claimed here.

Evidence quality is an architectural property

Evidence becomes more useful when its production and interpretation are deliberately designed. For a consequential operation, reviewers may need to answer: Who emitted this record? What did that component actually observe? Was the relevant identity and authorization decision captured? Can a downstream record be correlated without exposing secrets? Could sampling, clock drift, log loss, or post-hoc alteration change the conclusion? Can the result be checked independently against the affected resource?

Some systems will need protected audit trails, time-source controls, stable correlation identifiers, retention policies, and checks against authoritative downstream state. Others need less. No single logging product or cryptographic mechanism solves every question. Nor does tamper-resistant storage make false instrumentation truthful: protection of the record and correctness of the recorded proposition are different properties.

The purpose is not to accumulate the largest possible log. It is to preserve enough trustworthy context to support—and, when necessary, to limit—the claims a system makes about its actions.

How the ZeroField domains connect

ZeroField's six responsibility domains provide a way to locate these concerns without treating them as one indistinct “observability layer.” Context establishes what entity or environment is being discussed. Intelligence & Roles separates the proposing actor from its assigned responsibilities. Control & Governance determines applicable permission and approval boundaries. Coordination & Execution records workflow attempts and handoffs. State, Memory & Knowledge maintains continuity while avoiding unsupported promotion of previous observations into present truth. Integration & Interfaces defines the boundary between a tool call and the external system whose state may change.

Research then examines the adequacy of the claims and their supporting artifacts across those domains. This is a conceptual mapping, not a description of a deployed ZeroField evidence service.

The companion note, Authority Is Not Capability, asks who may cause an effect. This note asks what can later be established about an attempted effect. The questions intersect, but neither substitutes for the other. For related context, see Architecture, Systems, and Research.

Scope and open questions

This is a conceptual analysis informed by established observability, audit, and distributed-system guidance. It does not define a universal evidence schema, propose a new cryptographic attestation system, claim legal evidentiary sufficiency, or report empirical tests.

Open questions include which downstream observations are sufficiently authoritative for each kind of effect; how systems should communicate unresolved states to people; how long approval and outcome records should be retained; and when the cost, privacy impact, or latency of stronger verification outweighs its benefit.

An execution trace can explain what a system observed. A defensible outcome claim must not exceed what the available evidence can establish.

References and technical context

1. OpenTelemetry — Observability Primer: Distributed Traces. Defines traces and spans as observations of request paths through instrumented components.
2. OpenTelemetry — Logs Data Model. Distinguishes source event timestamps from observed timestamps and specifies log correlation fields.
3. OpenTelemetry — Tracing SDK: Sampling. Documents recording, sampling, and dropped telemetry.
4. OpenTelemetry — Semantic Conventions for GenAI Spans. Defines conventions for caller-observed GenAI operations and tool spans. This living specification was marked Development when reviewed on 2026-10-09 and is not an external-outcome verification standard.
5. NIST SP 800-53 Rev. 5.1 — Audit and Accountability controls AU-3 and AU-9. Specifies audit-record content (including event outcomes) and protection of audit information; it does not make each logged outcome independently authoritative.
6. Amazon Builders' Library — Making Retries Safe with Idempotent APIs. Explains retry safety and operation-identity considerations in distributed services.
7. Microsoft Agent Framework — Observability. Explains agent traces, logs, metrics, and sensitive-data considerations.
8. Microsoft Agent Framework — Evaluation. Describes agent and tool-call evaluation; tool-call checks are not equivalent to external-effect verification.