A workflow that shows its risks before, during, and after.

AI workflows have plumbing diagrams. They don't have risk language.

The standard criticism of AI workflow adoption is that teams lack the support and knowledge to define a proper, complete, governable workflow. The tools don't help. Orchestrators like n8n, Alteryx, KNIME and Airflow give you nodes, edges and run logs, which is useful plumbing. But ask the questions a risk committee or an examiner asks (what could go wrong at this step, how badly, what stops it, and what's left over?) and the canvas has no vocabulary for the answer.

That vocabulary exists, and it has existed for decades. It is the risk-and-control matrix. The IIA's 2024 Global Internal Audit Standards describe it as the engagement's working artifact: the risk event, the control and its type, cause, effect, and the assessment of residual risk. KPMG's 2025 agentic-AI whitepaper says the first control for AI agents is an impact assessment that sets the risk level, which then calibrates everything else, including how much human oversight each step gets. The methodology is documented. It just has never been wired into the workflow itself.

• the missWorkflow tools record what ran. Governance needs to know what was at risk, what was controlled, and what remains, none of which appears on any canvas.
• the costWhen something breaks, the investigation has no contained scope. It's one big workflow, one big log, one big argument about what was supposed to happen.
• the fixMake the RCM live: attach the risk lifecycle to each step, contain each sub-process with its own evidence, and let an audit re-perform controls against the log rather than the diagram.

A canvas of green checkmarks is not a controlled process.

The naive move is to bolt a status column onto the workflow, so each node shows ✓ when it ran. That fails for a reason auditors learned long before AI. A control that exists is not a control that operates. In this demo, the dual-approval control on high-value payments is well designed: the workflow requires two named approvers above S$10k, and every dashboard shows green. But the out-of-office fallback path quietly releases approvals with a single signature. No error is thrown, and nothing is red. The process appears to work while the control does not.

That distinction between design adequacy and operating effectiveness is the load-bearing idea in control testing (IIA Std 14.3), and no amount of workflow observability gives it to you. You only find it by doing what an auditor does: sample the evidence and re-perform the control. That is exactly what this demo's audit mode does, which is why its finding lands on a step every monitoring view called healthy.

The audit then re-performs the controls against the ledger, because until it is tested the middle box is only an assertion.

The decision is made in code, the methodology is cited, and the audit trail acts as a control.

The demo is an invoice-to-pay process run by four AI agents: capture and extract, validate and match, approve, post and pay. The trust boundary is drawn the way every system on this site draws it. Deterministic code computes every decision (ratings, bands, match results, routing, hashes), the models only extract and phrase, and any consequential decision is a named human's. What is new here is the governance grammar wired into each step:

The conventions are deliberate and named in-app. Inherent means the controls fail; residual means the controls are operating (the COSO/Deloitte controls-effectiveness convention). We use the IIA's four control types rather than KPMG-ICFR's two, five-point scales with impact-weighted appetite bands, and agents classed by KPMG's TACO taxonomy with oversight graduated HITL / HOTL / MITL by the step's risk tier. We label that last mapping honestly as our extension of KPMG's prose, because no firm publishes a hard table. The workflow also ships as an importable n8n JSON, with the governance annotations riding along as sticky notes. The orchestrator carries the skeleton, and the RCM carries the accountability.

Here is the deterministic core from the shipped file: the band lookup and the chain verification the whole page rests on.

// the appetite band is a lookup, not a vibe , matrix indexed [likelihood][impact]
function band(l, i) { return SC.bands.matrix[l - 1][i - 1]; }

// verify: recompute every hash from genesis; a tampered record breaks the chain
// at exactly its own sequence number , the ledger locates its own corruption
let prev = "genesis", brokenAt = -1;
for (const e of RUN.ledger) {
  const h = fnv(prev + "|" + e.seq + e.txn + e.action + e.agent + e.human + e.amt);
  if (h !== e.hash) { brokenAt = e.seq; break; }
  prev = e.hash;
}

The audit arc: a green dashboard, a failing control, and a closed finding.

Run the workflow: 47 transactions in, 41 paid, 6 routed to human review by the gates, 13 high-value. Every action lands in the ledger with an agent ID and a human ID. Then switch to audit mode and follow Domain V.

• Plan (Std 13.2). Rank the eight risks by residual position. Two sit in the high band after controls: R6 (dual approval on the largest payments) and R1 (model extraction feeding the payment path). They set the scope.
• Walkthrough. One transaction, TX-002 at S$12,063, traced end-to-end, KPMG-style, naming at each step the RMM (what could go wrong) and the PRP (where and how). The sharpest risk point is the routing decision between single and dual approval.
• Test (Std 14.3). Design first: C9 is adequately designed. Then operating effectiveness: sample eight high-value payments from the ledger and re-derive each approval. Two of eight released on a single signature, both through the out-of-office fallback. That is S$53,986 of payments, one approver, dashboard green throughout.
• Finding F-01, five elements. Criteria (the authority matrix), condition (2/8 single-approved), root cause (the fallback routes around the control rather than to a deputy), effect (potential unauthorised payment), and significance, rated on the two-axis grid as a significant deficiency: reasonable possibility of recurrence, magnitude significant to the process but capped below entity materiality. What is rated is the potential misstatement, not the actual one.
• Report (15.1) and follow-up (15.2). Management reroutes the fallback to a deputy approver, the same eight-item test re-performs at 0/8 exceptions, and the finding closes. It closes not when the report was issued but when the fix was confirmed.

The numbers, where they come from, and where the limits are.

The process is synthetic and the ratings are illustrative. The 2/8 exceptions exist because I seeded a realistic failure mode into a deterministic engine. The demo proves the control architecture and the audit discipline, not that any real process has these numbers. The run is seeded, so you get identical transactions, hashes and findings on every click, which is the same reproducibility promise the methodology demands of evidence.

The methodology is what is real. The inherent-to-residual convention, the five-point scales and the impact-weighted heat map are COSO/Deloitte's documented practice. The engagement phases, RCM fields, four control types, design-vs-OE distinction and five-element finding are the IIA's 2024 Standards, with the templates sitting in the Standards' non-mandatory considerations as preferred practice, and the app says so. The walkthrough, RMM/PRP framing and two-axis severity grid are KPMG's ICFR handbook. The TACO classes, graduated oversight and identity-carrying immutable logs are KPMG's 2025 agentic-AI publication. Every element is footnoted in the app's methodology panel, and the one thing no firm publishes, a hard risk-tier-to-oversight-mode table, is labelled as our extension rather than a citation.

The honest boundary is this. A live RCM does not make risk ratings correct, because rating is judgement and a synthetic process cannot prove mine. What it does make them is explicit, consistent, and testable, and that is what separates a risk assessment from a decoration.

Run the workflow. Then audit it.

Click a step for its risk lifecycle, run the 47 transactions, tamper with the ledger and watch the chain locate the corruption, then walk the full engagement through to the closed finding. Download the RCM as CSV, or the workflow as importable n8n JSON.