Six gates between a working demo and a production system

The demo works. The customer nods, asks for a small change, and the project enters a corridor that can last two months without anyone being able to say which step is stuck. That corridor is not a polishing phase. It is six gates, and each gate asks a question the previous one cannot answer.

Six gates, six kinds of evidence

Sample. Does it run on the customer's data, not on a file that lives on the FDE's laptop? The evidence is one end-to-end run on an untouched export, with the row count and the date written down. The failure signature is a demo file nobody can trace to a system of record.

Quality. Is it right on the cases the customer actually has? The evidence is a test set built before the build was tuned against it, scored in three classes: normal, should-refuse, and boundary. "We tried ten questions and it did well" is not a test set.

System. Does it survive the customer's environment? The evidence is three checks performed in order — data flow, permissions, and the failure path back. A successful API call belongs here only as a starting point; the response proves the request arrived, not that the action happened.

User. Does a named group of real users complete the real task without the FDE in the room? The evidence is a short list of names, a defined task, and their own record of what they did. Satisfaction scores are not evidence; they measure the demo, not the workflow.

Operations. Can someone other than the builder detect a failure and stop it? The evidence is an alert that fired in a test, a rollback actually executed, and a runbook with a reachable owner.

Value. Did a number in the agreed metric table move, over a window long enough to be a trend? The evidence is that metric, on the customer's data, with the exclusion rules applied as written before the window opened.

Gate	Question it answers	Evidence that passes	Failure signature
Sample	Is this the customer's data?	One run on an untouched export, date and row count recorded	A demo file with no source
Quality	Is it right on hard cases?	Pre-written test set, three case classes, scored	Ten friendly questions
System	Does it hold here?	Data flow, permissions, fallback — in that order	A 200 from the API
User	Do real people finish?	Named users, defined task, their own record	A demo re-run for a new audience
Operations	Can someone else stop it?	Alert fired, rollback executed, owner named	"We would notice"
Value	Did the number move?	Agreed metric, customer data, window respected	Anecdotes from two users

The stall sits between quality and user

Gates one to three are engineering work. The FDE can do them alone, and can show them. Gates four to six need someone else's calendar, someone else's authority, and someone else's data. When a project stalls, the demo is re-run, because it is the only gate that keeps answering yes.

The tell is a version number that climbs while the user list stays empty. A prototype at v14 with zero named users is not progress; it is a loop with better typography.

The quality gate has a second, quieter problem: it cannot be passed by the builder alone. If the same person writes the test set and the code, the test set inherits the same blind spots. The gate opens when someone who did not build it has tried to break it and failed.

Gates are not phases

The public 0–4 roadmap allots time: up to two weeks of preparation, two to four weeks of diagnosis, one to two months of pilot, two to four months of production, four to twelve months of expansion (《2026 中国 FDE 人才白皮书》, p.19). Mapping one gate to one phase is tempting, and wrong.

A pilot can fail the sample gate in its first week and the value gate in its eighth. A production phase can start with the operations gate still open, which is exactly how a system goes live with nobody able to stop it. Gates are reviews that cut across phases. Two consequences follow. A gate can fail twice, and the second failure should be a stop decision rather than another sprint. And when the timeline and the gates disagree, the gates win; the honest response is to renegotiate the date, not the evidence.

Give every gate a person who can say no

A gate without a gatekeeper is a status update. Before the build starts, write three things for each gate: the artefact that counts as evidence, the role that reviews it, and the date of the review. If the reviewer is the FDE, the gate is a self-assessment. If the artefact is a slide, the gate is a story.

The reversal test is simple: describe the observation that would make you fail. If you cannot name a concrete one — a row that is wrong, a user who gave up, an alert nobody saw — the gate does not exist.

Expect the value gate to be the weakest. It needs a window of at least four weeks, the same length the four-week rule uses, and it is the only gate whose failure is not the FDE's to fix alone. A system can pass the first five gates and still change nothing, because the process around it did not move. That is a real outcome and should be recorded as one.

The checklist to run before the next demo

Answer in writing, before the customer sees anything:

1. Which gate are we claiming, and with which artefact?
2. Who reviewed it, and could that person have said no?
3. Which gate is next, and what evidence would it require?
4. If that gate fails, do we narrow the scope, move the date, or stop?

A demo is an input to the sample gate, not an output of the project. The first-week prototype exists to earn that first piece of evidence, and the seven-day sprint is the shortest cycle that can produce two of the six. Treating one good demo as progress on all six is the most common way a project spends two months looking busy in the same corridor.