A working four-stage workflow I designed and built. Two stages write the document, a third scores it against a fixed rubric, and a fourth revises anything that fails. The rubric is derived from a production PRD I wrote for a system that replaced a multi-week manual process - so the bar is real work, not theory.
Most teams' AI adoption stalls at the same place: the chat window.
Getting a first draft out of an LLM is easy. Trusting it is the hard part - and at the organizational level, a draft nobody trusts creates review work instead of removing it. Teams try it, get output that varies wildly run to run, and quietly go back to doing it by hand. That reads as "AI didn't work here," when the real problem is that a prompt was deployed where infrastructure was needed.
So I built the alternative and made it run: document generation treated like any other internal service, with defined contracts between stages, an automated quality gate, a bounded self-correction loop, and logging on every call - so the workflow can be trusted, monitored, and improved over time.
Stages one and two write it. Stage three judges it. Stage four fixes it. Each is a separate model call with a defined input/output contract, and no stage sees more context than it needs.
Structured intake becomes an opportunity framing: segments, three candidate opportunities with validation questions, and a chosen path.
The synthesis becomes a full structured PRD - goals, non-goals, user stories, testable requirements, metrics, risks - as validated JSON.
An independent reviewer call scores the draft against a five-criterion rubric. Threshold: 4 of 5 on every criterion. Nothing passes on vibes.
Failures trigger one automated revision against the reviewer's specific feedback, then re-evaluation. Anything still flagged routes to a human.
The draft never ships directly. The eval gate is the point.
The six criteria below are not invented. They are the standard I held my own work to on a partner onboarding system that replaced a multi-week manual qualification process - a document with field-level CRM mapping, a defined retry and fallback path for when the analytics integration failed, acceptance criteria written as a branching end-to-end flow, and deferred scope named explicitly rather than left implicit.
Encoding that standard into an automated gate is the whole idea. An organization's quality bar usually lives in the heads of its most experienced people; this makes it explicit, versioned, and applied to every draft the same way. The reference the pipeline uses describes structure and rigor only - no thresholds, system names, or internal identifiers.
| Eval criterion | What the reviewer call checks |
|---|---|
| Problem clarity | The problem is specific and evidenced, not a solution wearing a problem costume. |
| Testable requirements | Every functional requirement can be verified true or false at release. |
| Measurable metrics | Success metrics have numbers and targets, not aspirations. |
| Explicit scope | Non-goals meaningfully bound the launch, and deferred work is named rather than left implicit. |
| Failure handling | Bounded retries, a defined terminal state, internal alerting, and a fallback path when the primary integration is unavailable. |
| Acceptance criteria | An end-to-end flow with explicit success and failure branches that a QA engineer could follow. |
Each stage has a structured JSON contract. Stages are independently testable and swappable - the model behind any stage can change without touching the others.
Quality is enforced by an automated rubric, not by hoping the prompt was good. The revision loop is bounded at one pass so the system fails toward humans, never toward infinite spend.
Every call is logged with stage, latency, and token usage. A workflow you can't monitor is a workflow you can't improve - or defend when someone asks what it costs.
A three-minute walkthrough, including a run where the first draft fails the gate and the revision loop corrects it automatically - with the score movement visible criterion by criterion.
Or run the live pipeline yourself - enter any internal workflow problem and watch each stage execute, including the eval gate's verdict. (Requires a free Claude account, since the pipeline makes live model calls.)
A demo proves the pattern. The real product work is turning the pattern into shared capability.