The two things being separated
A review is doing two jobs that need different handling. There is conformance — does this meet the standard we said we hold — and there is judgment — is this the right call for this client. The first is checkable and delegable; the second is not.
Businesses that never separate them route everything to the most senior person, because that person is the only one who can do the second job. They then spend most of their review time doing the first, which anybody could have done, and it is why review feels so disproportionately expensive.
So the system's job is to make conformance mechanical and to route only genuine judgment upward. In practice that shifts something like eighty percent of review volume off the senior person, and the remaining twenty percent gets better attention.
There is a third thing that gets conflated and should not: review is not the same as coaching. A gate that also carries development feedback slows down and gets avoided, and a business that needs both should run them on different clocks — conformance at the gate, coaching in a scheduled conversation where nobody is waiting on a release.
The architecture, part one: the standard
Stage zero, and it is not optional: a written standard per deliverable type. Three to seven criteria, each binary and checkable by someone who did not do the work. Not is this good — does it include the named sections, does it match the agreed scope, are the figures traceable to a source, has it been through the specific check that caught last quarter's error.
The criteria come from your own failure history rather than from first principles. Go back through the last twenty things that went wrong at a client and ask, for each, what check would have caught it. That produces a list that is short, specific and defensible, and it is why generic quality checklists never get used — they were not derived from anything anybody remembers.
The standard has an owner and a review date, because criteria that never change stop reflecting the work. A quarterly pass asking what got through and what criterion would have caught it is what keeps the list alive.
Then the deliberate scope limit: the standard covers conformance only. Anything requiring a view about whether this is the right approach for this client is out of scope by design, and gets routed rather than checked.
The architecture, part two: the gates
Stage one is self-check, triggered by the author declaring the work ready. They run the standard themselves and record it. This stage catches a surprising proportion of issues at zero cost, purely because a written list makes visible what a person was going to skip.
Stage two is peer conformance review, triggered by the self-check completing. Someone other than the author runs the same standard. Owner: any peer, and the rotation matters — a fixed reviewer becomes a second bottleneck and stops seeing the work freshly. Output is pass, or fail with the specific criterion named.
Stage three is the routing decision, and this is the gate that saves the senior person's time. Two questions: does this deliverable meet a defined risk threshold — first delivery to a new client, anything client-facing above a value line, anything touching a known-sensitive area — and did the author flag a judgment question. Yes to either routes to senior review; no to both releases.
Stage four is senior review, and it is scoped explicitly to judgment. The conformance has already been checked, so this reviewer is reading for whether it is the right call, which is a fifteen-minute job rather than an hour.
Stage five is the failure return path, with the criterion named and a re-entry point rather than a restart. Stage six is the record: what failed, at which criterion, on which deliverable type. That record is the only source of process improvement in the system.
The failure edges
The first: criteria that are not binary. Is the writing clear is not a criterion, it is a taste question wearing a checkbox, and two reviewers will disagree. Every criterion has to have an answer that two competent people would give identically.
The second: the founder reviews everything anyway. The routing rule exists and gets ignored, usually with the reasoning that it is quicker to just look. That is true per item and false in aggregate, and it is how a review system becomes documentation of a process that is not running.
The third: a review with no defined turnaround. Work sitting in review is work not delivered, and unowned queues grow. Each gate needs a time bound and a defined escalation when it is exceeded.
The fourth: no failure record. Without it, the same criterion fails forty times and nobody notices that the underlying process — not the reviewer, the process — is producing that failure reliably. The record is what turns review from a filter into a feedback loop.
The fifth, and the most damaging culturally: review used as a performance signal. The moment failed reviews are read as individual shortcomings rather than as process output, authors optimize for passing rather than for quality, and the self-check stage becomes theatre.
Where the standards live, and how the record is used
The standards belong wherever the work happens, attached to the deliverable type rather than filed centrally. A checklist in a separate quality folder is a checklist nobody opens; the same three criteria attached to the task, visible when the author marks it ready, get run. Notion or the project tool, not a document repository.
The routing rule needs to be mechanical rather than remembered. New client, value above a line, sensitive area, or an author-raised judgment flag — those four conditions can be evaluated from fields the work item already carries, which means the routing happens automatically and the founder receives only what genuinely qualifies.
The failure record is the part that pays over time. Six months of which criterion failed on which deliverable type produces two kinds of finding: criteria that never fail and can be retired, and criteria that fail constantly, which are almost never a reviewer problem. A criterion failing forty percent of the time is telling you the upstream process reliably produces that defect, and the fix belongs there rather than at the gate.
What done looks like, and what it takes to build
Done is client-facing work leaving the business without the founder having read it, at a quality level nobody is nervous about, with a record of what fails and why.
The checklist: a written standard per deliverable type derived from real failures; a self-check stage; a peer conformance stage with rotation; a written risk threshold that routes to senior review; a judgment-only senior stage; a return path naming the failed criterion; time bounds on each gate; and a failure record reviewed quarterly.
The build is short — one to two weeks of workflow — and the standards are the real work. Writing three to seven genuine criteria for your main deliverable takes a couple of hours of thinking and is the part that determines whether any of it functions.
The prerequisite is that the founder is willing to let something go out that they have not seen. That is not a technical prerequisite and it is the one that decides the outcome. A system that routes correctly into a founder who reads everything anyway has changed nothing except the number of steps.
Separate conformance from judgment: conformance is checkable by anyone against written binary criteria, and only genuine judgment should route to the senior person.