Uncertainty-Gated Development

Definition

Uncertainty-Gated Development (UGD) is a development style that splits
a system by part, not by task type — designing and building the known
parts upfront, waterfall-style, while tracking the unknown parts and
resolving them in parallel, never letting one wait for the other.

Agile is a methodology for uncertainty.
Waterfall is a methodology for certainty.
If you can accurately judge what is actually uncertain, you can apply
both, part by part, within the same system.

Essence

The essence of UGD is not simply telling known from unknown.

It is separating known and unknown, tracking both, and advancing
implementation of the known in parallel with resolution of the unknown.

Scrum says: don't put anything unresolved into a Sprint — exclusion,
not separation. UGD says: separate them, and keep both in motion at once.
While the known part is being built, the unknown part is not set aside —
it stays tracked, running alongside.

It doesn't matter what kind of unknown it is — something knowable just
by asking, or something that doesn't yet exist in the world at all.
Either way, the response is the same: move on the known now, record
the unknown, and let it run in parallel.

Strengths

• Low waste. Parts that don't need to be agile aren't rebuilt later.
• Higher quality. Designing after the fact means working within
  constraints that already exist. Designing upfront means choosing
  the best shape within the full coherence of the whole.
• A design record persists, so intent survives even if the implementer changes.
• Because the unknown is tracked rather than excluded, known-side
  implementation never has to stall waiting for it to resolve.

Trade-offs

• Misjudging what's actually uncertain is costly. If a part
  designed as "certain" turns out not to be, the cost of discarding
  and rebuilding that part's design can be high.
• Requires an architect's judgment as a precondition. Hard to apply
  across a team; works best when one person can make the call.

Distinguishing Features

• The known side is designed and built waterfall-style, not iterated
  in sprints.
• No timebox. Work closes on completion of a condition, not a fixed cycle.
• Assumes a single architect's judgment as the operating premise.
• Fits naturally with AI coding agents — known work maps to what AI
  executes well; unknown work maps to what still needs human exploration.

Design what can be known. Track what can't. Never let one wait for the other.