Audit Brief: AI Reading of Heterogeneous Audit Events Across Four Services

The Admin console's audit trail is append-only and heterogeneous: a 'version.publish' row and an 'api_key.rotated' row and a 'deployment.activate' row share four columns and nothing else. Each service writes its own 'detail' payload in its own shape.

An auditor's actual question — 'what changed here, and what should I look at?' — is answered by reading those payloads and relating events to each other across entity types. That is not a query.

**What counts stays with the console**: the audit view already reports the total, the actor count, the destructive-action count, and the page span — computed from rows. The model is asked for none of them. It is asked only for the reading.

**Two modes**: 'query' briefs the exact filtered query the reviewer is looking at (the panel reads the same 'audit_*' URL parameters the view mirrors). 'actor' pins the same capability to one person — the question the members page and the members detail drawer each need.

**Separation of duties review**: the strongest AI placement in the admin console. 'Nobody may approve their own change' is a control every regulated organisation claims and almost none can evidence — evidencing it means joining authoring events to approval events to publish events to release events per version across four services. The platform computes this. Five violation tests run as code and are the finding. The model is never asked *whether* a chain violates separation of duties (it would answer fluently either way). It is asked to read the free-form detail payloads behind flagged windows and say what they mean.

**Omission made visible**: the findings list iterates the computed violations and joins the model's commentary by stored event ID. A violation the brief never touched renders 'not commented on' — not disappearing. The panel also shows how many rows the model actually saw, so 'not commented on' is never read as 'cleared'.