Build views for review and recovery

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

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 copyable so they can be checked in the source system.

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

Recovery procedures should name the event patterns that trigger them. For example, action_sent without a later confirmed or rejected outcome creates a reconciliation item. An expired approval leaves the proposal visible but non-executable. A run ending while a tool call remains open should stop task completion.

Define the queries used in periodic review. Examples include actions outside common task sequences, access to restricted source classes, repeated denied calls, approvals followed by payload mismatch, unusually broad reads, uncertain outcomes older than their service window and tasks completed with missing destination evidence.

Give users an appropriate activity view where private systems are involved. It can state which sources were accessed and what changes were confirmed without exposing internal instructions, security rules or other people's restricted material.