The premise
Governance exists to make autonomous workflows safe enough to trust and fast enough to be worth having. Uniform review does neither. It applies the same committee, the same cycle time, and the same paperwork to a workflow that proposes answers a human must approve (L1) as to one that proposes new workflows the system will run itself (L4). The L1 workflow is slowed for no reason. The L4 workflow gets approved without the guardrails it actually needs — because the committee that approves it was built for L1.
A tiered review model fixes this by matching the *depth of review* to the *autonomy of the workflow*. That's the whole idea. Everything else in this playbook is elaboration.
Why tiered review
Uniform review has two failure modes, and both are expensive. The committee that catches everything also blocks everything, so teams stop putting workflows through it — and governance becomes a paper practice. The committee that reviews nothing catches nothing, so the first L3 workflow that drifts by 30% runs unreviewed for six months, and everyone learns that governance is a formality.
Tiered review avoids both failures because it's honest about what each tier actually needs:
- L0 (suggest) doesn't need a review cycle. The human is the review — every output is acted on by a person. What it needs is a spot-check cadence to catch drift, and a kill switch in case the workflow itself breaks.
- L1 (approve) needs a threshold — if approval rate drops below a set level, the workflow's prompts need review. Approvers see everything; the review is the approval rate.
- L2 (exception) needs an exception taxonomy — what exception types exist, how often each fires, and who owns the response. Review what gets escalated, not what runs cleanly.
- L3 (self-improve) needs a ceiling — the specific range of self-tuning the workflow is permitted, evaluated monthly. Below the ceiling, no review. Above it, review required before the change takes effect.
- L4 (self-extend) needs all of the above, plus weekly review of *proposals* — the extensions the workflow wants to add — with an explicit checkpoint before any proposal enters production.
Notice that the review at each tier is a different *kind* of review — spot-check, threshold, taxonomy, ceiling, proposal. None of them is measured in "hours on the committee calendar." All of them are measured in whether they catch the failure each tier is capable of producing. That's the difference between governance and ritual.
The most useful governance conversation you can have is: for each workflow at each tier, what specific failure does the review actually catch? If the answer is "anything," the review isn't sized to the workflow. If the answer is specific — "it catches prompt drift when approval rate falls below 80%" — the review is real. Every workflow in your registry should have a specific answer to this question. If it doesn't, the review is theater.
The five autonomy tiers
The tiers, in order of increasing autonomy and increasing review requirement. They are cumulative: each tier includes the guardrails of all tiers below it, plus its own additional requirements.
Note the shape: the review changes kind at each tier, not just depth. L0's review is spot-checking. L1's is thresholding. L2's is taxonomy. L3's is ceiling monitoring. L4's is proposal queueing. If your review model is the same for all five, you have one tier and four labels.
The five-part review model
Every tiered review model has five parts. The five together make governance operational instead of aspirational. Any missing part turns the other four into documentation.
- Tier assignment Every workflow in the registry has an explicit tier (L0–L4). Not "medium risk" — a tier number. No workflow defaults to a middle tier; defaulting is how the L4 workflows get hidden inside L1 governance. Reviewed quarterly. A workflow that moves tiers triggers a review event — moving a workflow up is a decision, not a paperwork update.
- Review depth per tier For each tier, the specific review that gates advancement — named reviewer role, named criterion, named cadence. Not "appropriate review for the risk" — the actual review, in the actual terms. Written before L3 and L4 workflows exist, not after. A governance model that responds to a self-improving workflow's incident is not governance; it's a post-mortem.
- Tested kill switch One switch per workflow that stops it in production. Tested quarterly, with a documented result. A kill switch that has never been pulled is a document, not a control — and the test is what proves it's a control. For L3: separate kill switches for the workflow itself and for its self-tuning capability. A workflow that can't be stopped is broken; a workflow that can be stopped but can't be stopped from tuning itself is a slow ungoverned drift.
- Audit trail and reader What is logged, where it lives, retention period, and who reads what on what cadence. The last clause is the part most models skip — logs written and never read are theater. Named reader per tier: L0's spot-check is a single reviewer sampling on a schedule; L4's weekly proposal review is a committee reviewing every proposal. If the reader isn't named, no one reads.
- Review cadence per tier The specific periodic review, matched to the tier: quarterly for L0–L2, monthly for L3, weekly for L4. Named owner per cadence. Under-review is a failure; over-review is also a failure — it makes reviewers stop taking the review seriously. Reviewed for drift quarterly. A cadence that hasn't been held for two cycles is not a cadence — it's an aspiration.
Worked example
A regional bank with six AI workflows in production across the five tiers. Expand to see how the tiered review model maps onto a real portfolio.
Show the tiered review model for a regional bank's workflow portfolio
- Tier assignment W1 — Loan application summarizer (L0). Agent drafts summary; loan officer decides. No autonomous action. W2 — Fraud pattern alert generator (L1). Agent flags suspected fraud; fraud analyst approves before hold is placed. W3 — Customer service reply drafting (L2). Auto-sends for tier-1 categories; escalates exceptions to a human operator. W4 — Invoice exception triage (L2). Auto-routes exceptions within tolerance; escalates above-tolerance for review. W5 — Collateral valuation pre-check (L3). Self-tunes confidence thresholds within a defined band; quarterly ceiling review. W6 — New-workflow proposal agent (L4). Proposes new workflows based on observed patterns; every proposal handled by weekly review — nothing activated without explicit approval.
- Review depth per tier L0: Ops manager samples 20 summaries per month. Looks for: drift in summary length, tone, or accuracy vs. loan officer correction rate. L1: Fraud team tracks approval rate weekly. Below 85%: prompts reviewed. Below 75%: workflow paused for investigation. Above 95%: approved actions audited for rubber-stamping. L2: Weekly exception review by operations lead. Every exception category tracked; any category growing > 20% QoQ triggers root-cause analysis. L3: Monthly ceiling review by risk & transformation. Self-tune band is ±8% above baseline confidence threshold — any proposed change outside that band requires approval before activation. L4: Weekly proposal review by steering committee. Every proposal carries: evidence, proposed tier, proposed kill switch, proposed ceiling. Nothing activates without full proposal review.
- Tested kill switch All W1–W6: dashboards have a red "stop workflow" button. Owner: transformation office. Tested quarterly, results logged. W5 (L3): two switches — "stop workflow" and "freeze tuning." Freezing tuning is the important one for L3: the workflow continues running on its current thresholds but stops adjusting them. Both tested monthly. W6 (L4): three switches — "stop workflow," "stop proposals," and "stop activation." The last stops the mechanism that promotes approved proposals into production. All tested monthly, with quarterly drills that assume an emergency.
- Audit trail and reader What's logged: every workflow action, every approval, every self-tuning change, every proposal — in a versioned store with revertibility. Reader per tier: L0 — ops manager monthly. L1 — fraud team lead weekly. L2 — operations lead weekly. L3 — risk & transformation monthly. L4 — steering committee weekly. Retention: L0–L2 — 3 years. L3 — 7 years (self-tuning changes are auditable events). L4 — permanent, in a format that survives system re-architecture.
- Review cadence per tier L0: Monthly spot-check, quarterly threshold review. Owner: ops manager. L1 & L2: Weekly exception/threshold review, quarterly full audit. Owner: operations lead. L3: Monthly ceiling review, quarterly full audit including kill-switch drill. Owner: risk & transformation. L4: Weekly proposal review, quarterly full audit including a tabletop exercise of an autonomy incident. Owner: steering committee. Cross-tier: quarterly portfolio review — the transformation office confirms each workflow is still at the tier it claims to be. Tiers drift quietly when nobody checks.
The trap, in depth
Applying uniform review to L0 and L4 workflows. The same committee, the same cadence, the same paperwork. It reads as "consistent governance" and it functions as "governance that never catches what matters." The L0 review is theater — the human is already the review, so the committee adds nothing. The L4 review is missing — the guardrails that should catch a self-extending workflow aren't there because nobody wrote them for the workflow that just joined the portfolio as "another AI workflow."
1 · The uniform review cycle
One committee, monthly, all workflows. Symptom: the L0 workflows are on the agenda for thirty minutes each; the L4 proposal queue gets fifteen minutes at the end because everything above has run long. The governance is real but misrouted — the attention goes where the volume is, not where the risk is. Test: for any given workflow, is the review depth on the calendar different from the workflow below it in the registry? If not, the review is uniform.
2 · The missing tier assignment
Workflows are labeled "medium risk," "high impact," or "co-pilot" — but never L0–L4. Symptom: no workflow has a tier number, only an adjective. This is the most common form of the trap and the most insidious, because it feels thorough. Test: ask the person who owns a workflow what its tier is. If they answer with an adjective instead of a number, the tier hasn't been assigned — and the review that follows their adjective is theater.
3 · The never-pulled kill switch
A kill switch exists in the documentation. It has been documented for two years. It has never been pulled. Symptom: the answer to "when was this tested?" is "we documented it thoroughly." Test: ask for the test log. If there's no log of a successful test in the last 90 days, the switch is a document — a document that has to work exactly once, on the worst day.
4 · The write-only audit trail
Logs are written. Logs are stored. Logs are never read. Symptom: the only reference to the audit trail is in the compliance checklist. If nobody can name a specific finding from a specific review of a specific workflow's logs in the last quarter, the logs are storage, not governance. Test: ask for one example finding from the audit trail in the last 90 days. If nobody can produce one, the audit trail isn't doing any governing.
5 · The silent ceiling drift
An L3 workflow tunes itself within a "ceiling" nobody has re-checked. Symptom: the ceiling was defined at workflow launch, and it has never been re-measured since. The workflow's confidence threshold is now 15% higher than baseline — inside the original ceiling if the ceiling was ±20%, but outside the range the business would actually approve if asked today. Test: read the current self-tuning value. Compare it to what the business would approve today. If they differ by more than a rounding error, the ceiling is a rubber stamp.
The single most useful intervention is a specific exercise: pick one workflow in each tier and ask the tier's reviewer role to name, in one sentence, what specific failure this review would catch. If they can't answer in one sentence, the review is not sized to the tier — it's sized to the calendar. Fix the review before the next cycle, not after the next incident.
The second intervention: test the kill switch this quarter, not next. Even if the test is disruptive. Especially if the test is disruptive — the disruption is what proves the switch works, and it's what makes the org remember that going to L3 and L4 is a real decision. A workflow whose kill switch has been tested is a workflow the org trusts. A workflow whose kill switch has never been tested is a workflow the org is hoping about.
Quality bar — what "good" looks like
- Every workflow has a tier — L0 through L4 — in the registry. Not "medium risk." A number. Every workflow. No exceptions, paid tool seats excluded.
- Each tier has documented review depth in the tier's own terms — spot-check for L0, threshold for L1, taxonomy for L2, ceiling for L3, proposal queue for L4. Different kinds of review, not the same review at different lengths.
- Each tier has a named reviewer role and cadence. "The governance committee" is a name for a committee that will meet months from now. "Ops manager, monthly" is a name for a person with a calendar entry.
- Every workflow has a tested kill switch with a test log. Tested within the last 90 days for L0–L2, within the last 30 days for L3–L4. Test log names the tester, the date, and the outcome.
- Every audit trail has a named reader. Not "the audit team" — a specific role, on a specific cadence, with a specific finding format. If the trail is written for compliance and read by no one, it's storage.
- L3+ workflows have a documented ceiling and a drift detector. The ceiling is a number, not an adverb. The drift detector alerts when the workflow approaches the ceiling, not when it exceeds it.
- L4 workflows have a documented proposal review process. Every proposal has an owner, a review date, and a decision. No proposals activate without an entry in the decision log — including the proposals that were rejected, and why.
- The review cadence has been held for at least two consecutive cycles. A cadence that has never been met is a hypothesis, not a control.
Red flags — signals the review model isn't operating
- Same committee for L0 and L4. The review has to be different in kind at each tier, and different-in-kind usually means different people around different tables.
- No workflow has a tier number. Adjectives are not tiers. If the registry has "medium risk," the tier assignment hasn't happened.
- Kill switch exists only in documentation. Untested switches are documents. Ask for the last test log; if there isn't one in 90 days, the switch is hoping.
- Logs are written but never read. Ask for a specific finding from a specific log review in the last quarter. If the answer is a process description, no one is reading.
- L3 workflows without a ceiling number. Self-tuning without a ceiling isn't self-improvement — it's drift with a friendly name.
- "We'll add guardrails before we go to L4." This sentence is the tell. You are already at L4 — the workflow is behaving like L4 (proposing extensions) without the L4 guardrails, which means it's at L4 without governance. The guardrails are not a technical debt item; they're a governance debt item and they need to be paid before the next workflow runs.
- Quarterly review has been postponed twice. Two postponements means the cadence isn't real. Governance that defers itself is governance that doesn't exist.
What this sets up
A working tiered review model is what makes the Autonomate stage survivable. Without it, autonomy looks like uncontrolled risk and gets shut down — either explicitly by a nervous board, or implicitly by an incident that forces the org back to L1 for everything. With it, autonomy becomes a managed capability: specific workflows at specific tiers, with specific guardrails, on a specific schedule.
- The autonomy tier ladder itself. The L0–L4 progression depends on the review model existing before the workflow arrives at a new tier. You can't raise a workflow to L3 without a monthly ceiling review in place — that's not governance, that's wishful thinking.
- The decision log. Every review the model produces writes to the decision log. The log becomes the org's memory of why each workflow is at its tier, and what the ceiling was the last time it was set. Without the review model, the decision log has nothing worth logging.
- The coordination layer. L4 workflows (the coordination agent, specifically) propose new workflows. The tiered review model is what accepts or rejects those proposals. In the two-playbook sequence, governance at Autonomate is what limits what the coordination layer at Executize can do.
- The measurement plan. Every tier's review produces specific measurements. L3's ceiling review produces drift numbers. L4's proposal queue produces acceptance rates. These aren't separate from the measurement plan — they're what the measurement plan consumes.
Common questions
When does a workflow move from L1 to L2?
When two things are true: the workflow's approval rate has been above the threshold for at least two quarters, and the exception handling for L2 is documented before the workflow moves. The second condition is what most teams miss — L2's value is that exceptions are handled systematically. If the exception taxonomy doesn't exist yet, moving the workflow to L2 just moves it to a state where exceptions pile up unattended. The tier change is a governance decision; make it after the guardrails for the new tier exist, not in hope that they'll get written.
How often should the kill switch be tested?
Quarterly for L0–L2, monthly for L3–L4. The test can be a drill: pull the switch, verify the workflow stops within the expected SLA, restart the workflow, log the result. It's not a technical exercise; it's an organizational one — the drill tells the org that the switch works, and it tells the operator (via the drill) what to do when the switch has to be pulled for real. Drills are the difference between a control and a document.
What if the org doesn't have a risk function to sit on the review?
Then the tiered review model isn't ready — and this is a real blocker, not an inconvenience. If there's nobody who can review an L3 ceiling change or an L4 proposal, then the org shouldn't have L3 or L4 workflows. The correct response is to stay at L1–L2 while standing up the review capability, not to lower the governance bar to match the current team. For small orgs, the review may be external (consultant, fractional risk lead, advisory board member) — that's acceptable, as long as the person is named and has a calendar. Unnamed review is no review.
Do L3 self-improvements need approval?
Only above the ceiling. Below the ceiling, the workflow can tune itself without per-change approval — that's the point of L3. The ceiling itself is reviewed monthly, and changes to the ceiling require approval. So there are two boundaries: the workflow's permission to self-tune (bounded by the ceiling), and the org's permission to change the ceiling (requires the L3 review). Confusing the two — "we'll just approve each self-tuning change too" — collapses L3 back to L1, which is exactly what the tier system exists to avoid.
What if the audit trail reveals something we didn't review properly?
Then the audit worked. The audit trail's purpose is to reveal — that's what makes it governance and not compliance theater. If the answer is "we didn't review that properly," the correct response is: log the finding, correct the review for the next cycle, and ensure the workflow is paused at its current tier until the review catches up. The worst response is "the trail found something we don't want to talk about, so let's dump the trail." That's the moment governance becomes theater — it's the moment the trail stops being a control.