6. Gates, Risk Registers, and One-Page Truth

Requirement quality is the floor. Gates, risk rows, and one-page status are the synchronization mechanism that keeps requirements, decisions, and evidence in one shared view across all functions.

Tuesday, 10:45 a.m., gate slides on the projector, whiteboard in the corner still covered in someone else's diagram from the session before.

The gate deck looks clean. The room still cannot answer one simple question: what changed since last gate that alters risk to launch.

If the team cannot produce that answer in two minutes from the gate record, the program is performing confidence, not making decisions.

Gate reviews: decision points, not slide events

A gate is useful only if it closes explicit decisions.

Minimum output of every gate:

1. decision taken (go/hold/re-scope),
2. owner for each follow-up action,
3. date and criteria for closure,
4. artifact delta list — what controlled records changed as a result.

The artifact delta list is the implementation trail: thermal limit revised from 85 °C to 78 °C | supplier re-qual opened | thermal risk row closed | schedule baseline updated to rev 4. Without it, a decision taken in the room has no verified follow-through.

No decision, no gate. Just a meeting.

Not every gate is a decision gate. A readiness review confirms that planned next-phase inputs are in place — no controlled value needs to change. An evidence review surfaces test or analysis results without forcing a decision yet — useful when the data is new and the team needs to absorb it before proposing a change. An alignment meeting reconciles cross-tier expectations without triggering a baseline change. A regulatory or customer staging gate moves a formal record forward in a controlled lifecycle. All of these have legitimate jobs. The rule "no decision, no gate" applies specifically to events on the program plan named "gate" that are expected to change a controlled baseline, requirement, or release — when those events happen but no controlled value changes, the gate is mislabeled. Rename it accurately: call it a review, write down what it produces, and stop treating it as a gate.

Risk register: from decorative list to control tool

Most risk registers fail because they track nouns, not decisions.

A usable risk row needs:

• risk statement,
• risk category (schedule / technical / regulatory — name it explicitly),
• owner,
• likelihood/impact basis,
• trigger signal,

A trigger signal names the specific observable condition that forces an action. Example: "any chamber run exceeding 77 °C" — if that reading appears, the thermal risk row escalates to a gate hold regardless of where the schedule stands. Without a named trigger, a risk row stays yellow indefinitely — acknowledged but never forcing action.

• mitigation action,
• decision date,
• current status with evidence link.

If "owner" is a team name and "status" is a color, the register will look active and behave inert.

Risk is not monolithic. A schedule risk — supplier lead-time uncertainty, tariff exposure, a dependency that has not been confirmed — moves through procurement decisions, buffer management, and contract terms. A technical risk — a thermal margin built on a back-of-envelope assumption, a structural calculation awaiting simulation, a supplier process not yet characterized at production rate — moves through testing, simulation, and supplier qualification. The mitigation actions for each are different, the owners are different, and the trigger signals are different. A register that collapses both under a single color produces the worst outcome: owners who are unclear on what kind of action will actually reduce the risk, and leadership reading one signal that covers two completely different problem types.

Each mitigation action should be specific enough that completing it demonstrably reduces the stated risk. When the action closes, the row carries the evidence — test data, simulation result, supplier Cpk, confirmed lead time — not just a status color flip. That evidence is what makes the risk register a decision artifact rather than a status decoration.

Risk register: bad row vs decision-grade row

One-page truth: executive view tied to source records

The one-page status is not a summary slide. It is the control surface for shared truth.

Minimum one-page sections:

1. current state vs target (what moved this week),
2. top risks and triggers,
3. decision log deltas,
4. critical dependencies and slips,
5. asks/escalations with owners.

Every line should trace to a source artifact. If leadership cannot drill down from line to record, confidence will exceed reality.

A one-page status that traces every line to a live record is the artifact that lets an executive leave for the weekend without anxiety. Not because the program has no risk — every hardware program has risk — but because the risk is named, owned, and visible in the register. The exec does not need to call because the register will surface what would otherwise surprise them. An engineering lead who has built a traceable one-page is an engineering lead whose exec has something reliable to read.

The one-page can live in any shared location that supports a stable link and a named owner: a wiki page, a version-controlled doc, a live dashboard, a weekly-refreshed slide. The format does not determine quality. What determines quality is whether each line links to a live source record — test result, risk row, decision entry, schedule baseline — and whether a reader can follow that link to verify the claim without asking anyone.

One-page status: bad line vs traceable line

Bad:

Thermal: 🟡 On track — team working the issue

Good:

Thermal: limit revised to 78 °C per chamber | thermal risk row closed at gate | supplier re-qual in progress | Cold-plate extrusion: 11-day slip, recovery in schedule rev 4

Update rhythm that keeps it honest

Cadence matters more than formatting.

Recommended rhythm:

• risk register refreshed at least weekly by owners,
• one-page refreshed on fixed cadence before leadership touchpoints,
• gate packets pulled from live records, not rebuilt from memory.

Late updates are not neutral. They create drift by definition.

Failure mode: deck replaces record

A deck works fine as the one-page status surface if it is updated by its owners on a fixed cadence, links to source records rather than restating them, lives at a permanent shared link, and is accessible to every tier. The failure mode is not the format.

When any artifact — deck, wiki, dashboard, or shared doc — stops holding the current state and becomes the thing teams optimize for narrative coherence:

• decisions disappear after the meeting,
• risk ownership blurs,
• status reflects what the room agreed to say, not what the records show,
• and escalations arrive as surprises.

The fix is not a different format. The fix is that whatever format carries the one-page must trace every line to a live record — and the tool holding that record must not be ephemeral. Specs need revision control so two people cannot be working from different versions of the same requirement. The one-page needs a stable, shared link so no one has to ask where it is. Data citations belong in a traceable location — a linked ticket, a controlled test record, a versioned log — not in a chat thread or an email chain. If the team has to reconstruct a decision by searching message history, the information was stored in the wrong place.

Practical install in two weeks

Week 1:

• standardize risk row format,
• assign owner to every active high-impact risk,
• define trigger rules for top 10 risks.

Week 2:

• rebuild one-page from risk + decision records,
• run next gate using artifact delta list,
• reject items that cannot trace to source.

Before Gate G3, the thermal risk row listed "supplier CpK pending" with no decision date, and the one-page line still read "launch confidence: green." The decision had been deferred through two prior gate cycles — each cycle the row stayed yellow and no action date was set. After the gate decision to hold the launch lot and fund gauge redesign, the row gained an owner and a decision date and the one-page delta changed to "launch at risk until CpK ≥ 1.33 evidence dated 2026-05-12." The decision, once it carried a named decision date, closed in one meeting. Gauge data collected two weeks later confirmed the launch lot would have produced a 12% first-pass yield miss at the customer — a containment action that would have cost more than the gate hold. - Old process: risk rows deferred with no action date; one-page status held green while risk rows stayed yellow through two consecutive gate cycles.

• Artifact changed: each risk row required a named owner and a decision date before the gate could proceed; one-page delta updated to a named risk statement with an evidence date.
• Measured improvement: the decision closed in one meeting once it carried a decision date; a 12% first-pass yield miss caught before the launch lot shipped.
• Cost of the gap: two prior gate cycles where risk rows deferred without action — the yield miss that would have materialized as a customer containment action.

Status is not forecast

Gates and one-page truth tell you what is true now. They cannot tell you when it will be done. Whether the evidence they need at the next gate will exist — whether the test coverage was designed to produce it — was decided before this gate opened.