COSO alignment and controls

The platform produces continuous control evidence aligned to the five COSO Internal Control framework components and to the COSO AI governance guidance published in February 2026. This article names what the auditor will receive as evidence and where each piece comes from.

Audience: risk and compliance reviewers and IT (the enabler)

What the auditor receives

For any sampled work item, run, or control test, the platform produces:

• An audit ledger entry set scoped to the work item or time window, with actor_id, occurred_at, family, action, subject, request_id, and a four-valued status (succeeded, failed, blocked, degraded) on every record.
• The dual-lens detail surface: a summary readable by the auditor, and an engineering lens with before state, after state, raw payload, and tool arguments. Where the Auditor lens is available (work item task flows and runs spawned from a work item today), the per-execution certificate and risk rubric are included.
• The Runbook version (input contract, output contract, step graph) the work item executed against.
• Lineage links from the work item to the spawning conversation, trigger, schedule, Project, and any downstream runs.
• Tool call records with arguments and results, including the Verified Action contracts where applicable.

The export procedure for an evidence package is documented in Export, retention, and evidence packages.

The five COSO components

1. Control environment. Tenant-level configuration (SSO, role assignments, Project membership, integration ownership, credential governance) leaves a config family entry in the audit ledger with the actor and the before and after state. Evidence: /audit?view=config, role and team membership records, integration binding history, credential rotation entries. Outside the platform: the policy that defines who is authorized to make those changes.

2. Risk assessment. The platform exposes the inputs for an AI risk assessment: the work item input contract, the Runbook step graph, the tool surface each step can invoke, and the integration capabilities (read, write, triggers, reply) each integration exposes. The Auditor lens, where it renders today (work item task flows and runs spawned from a work item), computes a per-execution risk rubric from these inputs. Outside the platform: the qualitative classification, the materiality threshold, and the acceptance criteria.

3. Control activities. Every tool call, integration call, file action, and lifecycle event is recorded with its full payload. Deterministic execution (see Deterministic execution) makes the activity testable: a sampled work item can be re-read from the ledger and verified against the Runbook contract. Approval gates are first-class: when a guardrail holds forward progress, the entry status is blocked and the reason is recorded in the payload. Blocked entries are not failures; they are the control firing as designed. Outside the platform: the human review policies that define who can clear a blocked state.

4. Information and communication. The audit ledger is the information layer; the dual-lens surface is the communication layer. The same payload powers the analyst and engineering views. Filters and deep links (?hours=, ?view=, ?group=, ?actor=, ?connection_id=) make any view URL-addressable. Outside the platform: the cadence and the recipients of the periodic control reports.

5. Monitoring activities. The audit timeline supports continuous monitoring through the 1h, 24h, 7d, and 30d windows; through the Failures only filter; through per-actor and per-connection drill-downs; and through the Live indicator on the toolbar (the timeline refreshes on a 30s interval). Each group exposes entry-level counts (tools, requests, files, entries). Outside the platform: the escalation procedure when monitoring surfaces an issue.

The February 2026 COSO AI guidance

The February 2026 COSO AI governance guidance extends the Internal Control framework to AI-driven controls. It asks for three things the platform addresses directly: traceability of AI decisions (the audit ledger covers this), reproducibility of AI-driven control activities (deterministic execution covers structured outputs; see the determinism article for the limits on prose), and segregation of duties between the actor that invoked the AI and the actor that approved the outcome (recorded as separate audit entries with distinct actor_id values).

The guidance also asks for a documented AI risk classification per workflow. The platform provides the underlying inputs (Runbook contract, tool surface, integration capability map); the classification itself is produced outside the platform.

Gaps that require process controls outside the platform

• Human review approval policies. The platform records who cleared a blocked entry. The policy that authorizes that actor for a given category of block is external.
• Materiality thresholds. Counts and statuses are exposed; the classification of which executions are material to a given control is a policy decision.
• Cadence and ownership of monitoring reviews. The ledger is continuously available; the review schedule is not modeled in product.
• AI risk classification per workflow. The COSO AI guidance asks for a documented classification. The platform produces the underlying inputs; the classification is external.
• Pre-assembled COSO evidence package. Today, exports cover a time window or a specific group. There is no one-click COSO control-mapped package; the mapping is assembled from the exports against the framework matrix above.
• Coverage of the Auditor lens. The per-execution certificate and risk rubric render only for work item task flows and runs spawned from a work item today. For other group kinds the Auditor tab shows "Soon". Where you need a certificate today, sample on work item flows.

Working with your external auditor

The external auditor receives the same payload your internal review uses, through the same surfaces. There is no separate "auditor mode"; there is the dual-lens detail page, the URL-addressable views, and the export procedure. We recommend a walkthrough on a sampled work item early in the audit so the auditor learns the four-valued status taxonomy, the lineage trail, and the engineering disclosure before the formal sample is pulled. Use the framework matrix above as the starting point for cross-references; the audit ledger payload backs most of them.