AI Vendor Evidence Gap Notes #16
An AI agent that updates customer records has completed acceptance testing. The engineering team provides a report showing that the main scenarios passed, along with the execution traces collected during testing.
A few months later, another reviewer examines the results. The report does not clearly identify the model version used, and the approval records do not establish whether a database write was actually blocked after a request was rejected.
The original testing may have been thorough. The difficulty is that the retained material does not allow someone else to reconstruct what happened.
Claim
“The agent passed acceptance testing. We have the test report and logs.”
In practice, these records often sit in different systems. An evaluation dashboard holds the test results, a tracing platform records tool calls, approval decisions remain in the business application, and the final data state must be checked in the database.
There is nothing inherently wrong with keeping evidence in separate systems. The difficulty arises when those records cannot be linked. A reviewer can read the reported conclusion but cannot independently examine the execution that supports it.
What it actually proves
In A Successful Demo Is Not an Acceptance Test, I discussed why acceptance testing needs to cover conditions beyond the normal execution path. Once those tests are completed, the supporting records need to remain available for review.
Anthropic’s Demystifying Evals for AI Agents distinguishes between a task, an individual trial, its execution transcript, and the final outcome. This is useful when organizing acceptance evidence because a successful final response does not necessarily tell us which actions were performed or what changed in the underlying system.
For a practical review, I would expect an acceptance evidence pack to make the following material available:
Evidence materialWhat it should establishSystem and usage scopeThe agent’s task, data types, permitted actions, and the model, prompt, tools, permissions, and configuration versions used during testingAcceptance scenariosTest conditions, expected behaviour, success criteria, and the normal and exception scenarios coveredExecution evidenceStarting state, execution results, relevant traces, control events, and final system state for each trialExceptions and gapsFailures, exceptions, untested scenarios, and behaviour that remains unverifiedChange and regression recordRelevant system changes after testing and which previous conclusions have been revalidatedReview note and usage boundaryThe usage conditions supported by current evidence and areas requiring further examination
These materials do not need to be copied into a single document. Existing testing, tracing, and logging platforms can remain the sources, provided there is a reliable way to locate the relevant records.
OpenAI’s Agents SDK tracing documentation illustrates how model activity, tool calls, handoffs, and guardrail events can be captured. Such traces can help reconstruct execution, although the reviewer still needs to establish which events were actually recorded for the system under examination.
For the customer-record example, I would start with a rejected approval scenario. The evidence should connect the test run to the approval decision, subsequent tool activity, and final database state.
If the only retained evidence is an approval screen showing “Rejected,” I still cannot establish that the write operation was blocked. And if the scenario was executed repeatedly, I would want the failed and divergent attempts retained alongside the successful ones.
What it does not prove
Even a well-organized evidence pack supports conclusions only within the tested conditions.
An exception scenario that was never executed, an alternative tool path that was not covered, or a model change introduced after testing may limit how far the original results can be relied upon. The pack should identify these limitations rather than leave reviewers to discover them later.
There is also a distinction between technical acceptance evidence and the decision to continue operating the agent under its existing business authorization.
The evidence pack should provide the facts needed for that decision: what was tested, what happened, what remains uncertain, and which usage conditions the results support. It does not itself authorize the agent to operate.
Weak-answer pattern
Two answers often come up during review:
“Everything is available in the evaluation dashboard.”
“We retained all the system logs.”
Both may be accurate, but I would still need to establish which system version was tested, whether all trials were retained, and whether the logs can be connected to the final state of the business system.
As discussed in AI Audit Logs: What Events Are Missing?, retaining logs does not necessarily mean the events needed to reconstruct an AI workflow are present.
Rather than asking for more screenshots, I would prefer a simple evidence index linking each acceptance scenario to its trial records, relevant control events, and observed outcome.
Evidence request
Please provide the acceptance test records for the current agent version and intended usage scope, including test conditions, expected behaviour, individual trial results, relevant execution traces, and verified final system states.
Include failed and exceptional executions, untested scenarios, relevant changes since testing, and usage conditions not yet supported by the available evidence. Records may remain in existing systems, provided they can be located and linked to the corresponding test results.
This request does not require a new testing platform or a separate archive containing every raw log. The immediate need is a traceable relationship between the acceptance conclusion and the records supporting it.
Review note
Where the report is available but some underlying evidence cannot yet be checked, I would record:
The available material indicates that the agent completed several defined acceptance scenarios. However, some reported results lack linked execution records, control events, or evidence of the final system state. The relationship between the test report and the current runtime configuration also remains unconfirmed. The conclusions supported by the available evidence are therefore limited to the recorded and verifiable test conditions.
Usage boundary
For an agent that produces recommendations subject to human review, some missing execution detail may have limited consequences for its current use. The position is different for an agent that can modify production data, send external requests, or operate privileged tools.
In those cases, approval events, exception handling, and final-state verification become particularly important. I would record which operations have supporting evidence from the current system version and which execution paths remain untested, so that the people responsible for the operating scope can assess those limitations.
A useful acceptance evidence pack should allow someone returning to the review months later to find the test conditions, actual results, unresolved issues, and corresponding system version without having to ask the engineering team to reconstruct the entire testing exercise.
Boundary
This material is for evidence structuring, review preparation, and evidence-oriented testing discussion. It does not provide legal, regulatory, audit, procurement, certification, or implementation advice.