Wira Delta Indonesia

Review Gates

The 5 Human Review Gates (G1-G5)

A gate is a deliberate checkpoint where a responsible person decides one thing before the work moves on. Between gates, AI agents work inside the documents the gates approved.

The Gate Walk: One Decision Per Gate

WDI Method structures delivery into five gates. Each gate decides one thing. At G1 to G4 you read one rendered page; at G5 you read the spec's RTM rows. You answer a short checklist, and one "no" on a starred question holds the gate.

Gate Decides Skill What You Read Owner Decision
G1: Problem What the problem is, whose it is, and why it earns work /wdi-problem .what-rendered/_product-brief/brief.md Approve the problem framing
G2: Product What is built, and how it feels to use /wdi-product
/wdi-ux (optional)		 .what-rendered/_prd/<slug>/prd.md Approve the functional promises (FR)
G3: Blueprint The whole picture of the product, once per product /wdi-blueprint .how-rendered/blueprint.md Approve the architecture spine
G4: Component How one component is built (skipped at mode: catalog) /wdi-component .how-rendered/<pc>/SDD-<pc>.md Approve the software design
G5: Release Whether it is done and proven /wdi-build The spec's RTM rows in .control/generated/ and each ticket's test evidence Accept the spec as done, or send it back

Two Fields That Never Merge: Mode vs. Risk Accepted

Both fields belong to the owner, and neither is derived from the other. One sets how deep the documents go; the other sets how hard the review is.

Field 1: Mode

How Deep Do the Documents Go?

mode sets how deep each component's documents go:

  • catalog (default): nothing beyond the blueprint, and G4 is skipped.
  • outline: full flows for up to 3 use cases, local business rules, a decision summary.
  • guarded: adds a Failure Behaviour section for every boundary and third-party integration documents.
  • deep: adds robustness analysis, a contract per endpoint, a data dictionary, flow diagrams, and state machines.

Field 2: Risk Accepted

How Hard Is the Review?

risk_accepted sets how hard the review is:

  • high (you accept a lot of risk): the baseline structure and prose lenses.
  • medium: adds the edge-case lens.
  • low: adds the edge-case lens, and the code needs two reviewers who are not the builder.

Why the Two Stay Separate:

If one field set both, the only way to get a thin document would be to write more risk into the risk record than you actually accept.

Refine, Do Not Advance

One "no" on a starred (★) checklist question holds the gate. When a rendered page at G1, G2, G3, or G4 does not convince you, do not approve the gate with the plan to fix it later.

Refine the document and run the gate again. Each skill owns a named set of files, so re-running it with your feedback changes only the document it owns. You then re-read the updated page.