Skip to content

Spec: Audit Coverage Matrix

Mirrored from docs/design/auditability/specs/coverage-matrix.md. Edit the source document in the repository, not this generated page.

Every Orbit operation that touches code, task state, persistent runtime state, external services, or provider/tool execution must have an audit channel. This matrix defines the expected channel by operation class.

“Audit everything” is too vague to enforce in review. A coverage matrix gives reviewers a concrete checklist and makes known gaps visible.

Operation classRequired audit channelMinimum fields
Top-level CLI commandCommand audit rowcommand, subcommand, role, status, duration, cwd
Orbit tool mutationCommand audit row or targeted runtime rowtool/action name, target type/id, actor, status
Task lifecycle updateCommand/tool audit plus task historytask id, actor, status transition or document field changed
Task lock reservation/check/releaseTargeted command audit rowreservation target, files payload, status, conflict/denial state
Activity/job runV2 envelope JSONLrun id, agent identity, run start/finish
Activity/job stepV2 envelope JSONLrun id, step id, outcome or skip/retry reason
Filesystem policy decision inside v2 runV2 envelope JSONLprofile, op, path, allowed, matched rule
Filesystem or proc-spawn policy denial live projectionGlobal tracing JSONLtarget, tool, path, profile, matched_rule
Friction task submission live projectionGlobal tracing JSONLtarget, task_id, agent, model, summary
HTTP provider turnLoop audit JSONL plus blob storerun id, session id, provider, model, request/response blob hashes
Tool call inside HTTP loopLoop audit JSONL plus blob storerun id, session id, tool name, input/output blob hashes, outcome
CLI backend provider invocationV2 envelope JSONLprovider, redacted argv, stdin/stdout/stderr blob refs, timeout, exit code
Invocation cost/usageInvocation storejob run id, activity id, task ids, agent, model, token usage, tool-call summary
Audit export/pruneCommand audit row (planned)command, actor, target, status
  • A mutation path must not rely only on stdout text for auditability.
  • A provider request or response must not be stored inline in a command audit row.
  • A policy or allowlist denial must record both the denied subject and the reason.
  • Live tracing projections must be additional to canonical audit, error, log, or scoreboard writes.
  • A task-state mutation must leave task history or document metadata in addition to any audit row.
  • New operation classes must update this matrix in the same PR that introduces the operation.
  • orbit audit commands are not currently wrapped by AuditGuard, so export and prune operations are not command-audited.
  • Some deterministic automation actions rely on enclosing job context rather than dedicated targeted audit rows.
  • CLI backend tool allowlists are recorded as harness-delegated advisories, not enforced Orbit denials.
  • Command audit stdout/stderr fields exist but are not broadly populated.

When reviewing a change that mutates code or state, ask:

  1. Which operation class does this change add or modify?
  2. Which audit channel records success?
  3. Which audit channel records failure or denial?
  4. Which actor or agent/model identity is persisted?
  5. Are payloads redacted before durable storage?
  6. Does the change require a new ADR because it changes the audit contract?

Last revised by codex / gpt-5.5 for [T20260427-0023].