Views for review and recovery

The main operational view should show a short ordered sequence: task accepted, sources read, proposal created, approval recorded, action attempted, destination confirmed, task closed. Retries, denials and model calls can expand underneath those.

A reviewer should be able to filter by task, actor, workload identity, source object, destination object, action ID, policy version and time range. Keep identifiers easy to copy so people can check them in the source system.

Add a current-state panel derived from the events. It can show a pending approval, the active run, uncertain actions, unresolved denials, the latest confirmed effect and what recovery action is available. Keep the underlying events one click away, though, because derived state can be wrong after a bug or a delayed message.

Recovery procedures should name the event patterns that set them off. For example, an action_sent with no later confirmed or rejected outcome creates a reconciliation item. An expired approval leaves the proposal visible but unable to run. A run that ends while a tool call is still open should block the task from completing.

Write down the queries you'll use for periodic review. A few I'd start with: actions outside the usual task sequences, access to restricted source classes, repeated denied calls, approvals followed by a payload mismatch, unusually broad reads, uncertain outcomes older than their service window, and tasks marked complete with no destination evidence.

Where private systems are involved, give users their own activity view. It can tell them which sources were accessed and which changes were confirmed without exposing internal instructions, security rules or anyone else's restricted material.