What an agent audit trail needs to show

An investigator asks whether an agent was permitted to change a customer record. A performance trace shows a successful model response. A backend log shows a write. Neither, on its own, establishes which authority connected the two.

Before collecting more logs, write down what you need to prove. In this case: who requested the change, why it was allowed, and whether it actually happened.

Turn the investigation into a checklist

Use this worksheet to identify the records you'll need. Some answers will come from Dome; others need evidence from the backend.

A reviewer should be able to turn a row into a test: produce a controlled event, retrieve the relevant evidence, and state exactly what it supports. This is a proposed validation exercise, not a claim that the exercise has been performed.

Use a shared trail for configuration and runtime

Dome's audit model places configuration changes and governed runtime activity in one workspace-scoped trail. That lets an investigator connect a rules deployment with later decisions without first reconciling two unrelated event models.

The envelope records actor, scope, operation, lifecycle stage, result, and independent error or denial information. When a governing decision uses a loaded rules bundle, its payload carries policy provenance. An event that never loaded a bundle does not acquire that evidence merely because the schema supports it.

That distinction changes the finding. If policy was unavailable, say so. Don't report that a business rule deliberately refused the operation.

Connect the records carefully

Dome distinguishes three useful correlation scopes:

activity_id: a broader run or activity
  trace_id: one request cascade
    operation_id: attempted and completed phases of one operation

Use the narrowest identifier that answers the question. Joining two phases by operation ID is different from grouping several requests by a shared activity ID.

Activity identifiers also carry trust labels such as server-owned or caller-asserted. A caller-supplied grouping value can help locate related records, but it does not establish a verified delegation chain. Preserve that distinction in the investigation finding.

Runtime records may omit client-origin information that appears on direct configuration requests. Do not fill those gaps with the gateway's address and call it the originating user.

Know what a missing trace means

Traces, metrics, and model telemetry are useful for latency, failures, and cost. They may also contribute to an investigation. Their collection contract determines whether they can support a claim about a particular event.

OpenTelemetry sampling deliberately selects which traces are processed and exported. An absent sampled trace therefore cannot establish that a request never occurred. Conversely, an existing unsampled evidence system may already meet the required audit contract. Evaluate its guarantees rather than its label.

Correlate the systems where helpful: use telemetry to understand a slow request, the decision record to establish its authority, and the backend to establish its effect.

Make retrieval part of the acceptance test

Save the workspace, time range, filters, and pagination used to retrieve the evidence. Check the completeness metadata before saying the export contains every matching event. Dome distinguishes readable partial views from stricter export behavior; a screen full of rows is not itself a completeness claim.

Access to the trail also matters. Dome records audit queries and exports, allowing evidence access to be investigated alongside the activity it describes.

Use the audit command reference to retrieve a small controlled sequence and have another operator write the finding. Can that operator explain what happened, cite the supporting records, and identify what is still unknown? That's a more useful test than counting log entries.