Observability and runs reporting

Observability is the reporting view over governed work: AI Runs groups runs by session, with session/run, owner, work item, model, runs, and tokens columns. Rows carry states such as awaiting_user, and subagent runs nest under their parent session. Tune from that record, not from impressions. Session how-to lives under Working with sessions; the transcript-and-preview view of a single running session is shown there.

• Read the transcript as it goes in-session; read the record after. Attempted, approved or denied, changed: all present, all under the right org scope.
• Denials are first-class outcomes. Zero denials across many sessions means rubber-stamping or gates too loose; spot-check approvals.
• The same denial repeatedly means the environment, goal, or policy is wrong. Fix the design; do not blame operators.
• Routine work constantly gated means policy is tighter than the workload; loosen with evidence, keep the risky gates.
• Approvers batching decisions means fatigue. Reduce gate volume (fewer, sharper gates) or add approver coverage.

Reporting checklist

• Each session closable to a one-line result with its record findable again.
• Denials exist in the record and get reviewed, not just allowed actions.
• Repeated patterns escalated with examples: session references, timestamps, tenant hostname, org scope.
• Sensitive departures trigger a review of recent sessions and approvals.
• Session URLs never treated as portable across tenants; records belong to their tenant and org scope.

Runs reporting lives at /ai/runs. Session how-to: Working with sessions. Approval design: Approvals design.