AI Agent Evidence Completeness: Find Missing Events

AI agent evidence completeness asks whether all records needed to explain a bounded operation are present, linked and interpretable. A collection of valid signatures can still omit a denied attempt, an uncertain dispatch or a later reversal. Define the expected event relationships, compare them with authoritative operation records and report gaps without turning missing evidence into an assumed success.

This method is for audit and platform teams reviewing agent-assisted workflows. It complements integrity verification rather than replacing it. The example follows a prepared document through approval, dispatch and acknowledgement. The event names are a proposed local model, not an OATI wire format or a universal standard for every enterprise process.

Define the population before counting records

Choose the cases, time interval, tenants and operation types under review. State whether the interval is based on request time, dispatch time or outcome time. An operation started near the boundary may finish later; excluding its later outcome without explanation makes an otherwise legitimate sequence look incomplete.

Use an independent operation source where possible, such as the receiving system's transaction register. Comparing an evidence database only with itself can confirm internal consistency while missing actions that bypassed the collector entirely. If no independent population is available, describe the result as completeness within the observed dataset, not proof that every real-world action was captured.

The OpenTelemetry Logs Data Model distinguishes event and observed timestamps and supports trace correlation. Those fields help investigation. They do not define which business evidence must exist or prove that a collector saw every action. The expected relationships below are application-specific review rules.

Specify valid event relationships

Not every request should end with a success receipt. Denied requests should have a denial record and no dispatch under the protected path. Approved requests may remain pending or uncertain. A cancellation before dispatch and a reversal after completion are different events with different consequences.

Observed state	Required related evidence	Question raised by a gap
Request denied	Decision reason and request reference	Was the rejection recorded without a later forbidden dispatch?
Approval recorded	Exact object version and authorised reviewer	Does approval refer to what was actually submitted?
Dispatch attempted	Operation reference and receiving-system correlation	Can an investigator distinguish a retry from a new action?
Outcome uncertain	Timeout or interruption plus reconciliation status	Has unknown state been incorrectly reported as failure or success?
Completion observed	Authoritative outcome reference and observation time	Is the claimed completion supported outside the model transcript?
Later correction	Link to the earlier outcome and reason	Can the original conclusion still be mistakenly treated as current?

Keep multiplicity rules explicit. One operation may have several attempts, several observations and one eventual reconciled outcome. Treating every repeated identifier as a duplicate error can erase useful retry history. Conversely, accepting every repeated record without comparing meaning can conceal conflicting outcomes.

Reconcile sets, not just totals

Equal record counts do not prove completeness. Ten dispatches and ten receipts may concern different operations. Join by stable tenant-bound operation identifiers and compare the expected relationships for each operation. Record unmatched items in both directions: a dispatch without evidence and evidence without a known dispatch need different investigations.

Use a defined waiting period for delayed records, but keep pending items visible during that period. A late record can resolve a gap; it should not rewrite the earlier report to imply the gap never existed. Preserve the original report time and the later reconciliation event so reviewers can distinguish timely evidence from evidence recovered after a failure.

Handle ordering and clock uncertainty

Events can arrive out of order even when the underlying workflow was valid. Compare causal references and source versions before concluding that an approval followed execution. Wall-clock timestamps from separate services may differ. Record the clock assumptions and any uncertainty that affects the conclusion.

A sequence number or hash chain can reveal missing entries within its defined scope, but it does not prove that all external actions entered that sequence. Inspect how the sequence is created, where the enforcement boundary sits and whether alternate credentials or routes can bypass it. The assurance claim must match the actual collection mechanism.

Build a small missing-event exercise

Create a synthetic population of three operations: one denied, one completed and one uncertain. Write the expected relationships first. Remove the approval reference from the completed operation, remove the uncertainty marker from the interrupted operation and add a receipt for an unknown operation. The review should produce three distinct findings rather than one generic count mismatch.

Then add the missing records back with later observation times. Verify that the findings move to resolved while the original report remains available. Add a conflicting outcome for the completed operation and confirm that the system requests reconciliation instead of selecting whichever event arrived last.

Finally, place an extra synthetic operation only in the receiver register. This tests whether the independent population comparison detects an action absent from the evidence store. A check that passes this case has demonstrated a useful reconciliation behavior; it has not proven that your real receiver register is complete or trustworthy.

Recover evidence without inventing history

When a source can re-export a missing record, preserve its origin and the recovery time. When a person reconstructs a fact from other records, label the result as a reconstruction and identify its basis. Do not generate a new signed record that falsely claims to have been created contemporaneously with the original action.

If the record cannot be recovered, report the gap and its effect on the conclusion. The outcome may still be known from another authoritative source while the original approval basis remains unverified. Different claims can have different confidence and should not be collapsed into a single green status.

Report coverage with meaningful denominators

Publish the bounded population, expected record types, unresolved gaps, recovered gaps and conflicts. Separate ordinary processing delay from expired evidence expectations. Explain which sources were compared and which bypass paths were outside the review. A percentage without those definitions is difficult for an independent reviewer to interpret.

Use the worksheet during release testing and after changes to collectors, queues, retention or export pipelines. Assign an owner to each unresolved finding and record the next investigation step. Completeness becomes an operational control when a missing event triggers a specific decision, not merely a warning that disappears from the next dashboard refresh.

Use the worksheet and related implementation guides

Use the parent guide for the wider architecture, then apply this article to one bounded implementation. The adjacent articles cover related decisions without replacing this worksheet.

Download the editable worksheet. Next step.

Engineering draft, 18 October 2026. Primary sources checked on this date; specialist review remains pending. The worksheets describe proposed tests, not measured customer results. OATI remains a developer preview. Local implementation evidence does not establish independent assurance, customer acceptance or production readiness for a particular deployment.