Skip to content

Launch or Commitment Readiness Gate

Governance gate — instantiates Reference-Class Planning Calibration

A checkpoint that refuses to let a date, budget, or scope promise go public until the calibrated forecast, its scope trace, and its reserves have been reviewed and acknowledged.

Calibration is worthless if the organization can walk straight past it and promise the optimistic number anyway. Launch or Commitment Readiness Gate is the point where the archetype stops being analysis and becomes governance: a checkpoint that a project must pass before any date, budget, or scope commitment becomes public and binding, and that will not open until specific evidence is present and acknowledged. Its defining move is withholding permission — it does not estimate, size a reserve, or select a class; it verifies that those things were done and forces a named decision-maker to accept the calibrated forecast, with its uncertainty and reserves intact, on the record. It is the difference between "we know the honest number" and "we have committed to the honest number." Where sibling mechanisms produce the calibration, this one refuses to let a promise outrun it.

Example

A consumer-electronics company is about to announce a ship date for its next flagship phone at a press event — the single most expensive promise it will make all year. A Launch or Commitment Readiness Gate stands between the program team and that announcement. To pass, the team must present a defined commitment object: exactly what "shipping" means (units in retail, not units off the line), the quality bar (yield and certification thresholds), the excluded scope (the two features deferred to a point release). It must show the forecast expressed as a range with its reference class named, and a reserve tied to that range. And it must reconcile the current promise against the scope ledger — every feature added or cut since the last gate — so nobody can later hide an overrun by quietly having changed what was being built. At the review, manufacturing's data shows yield still below the bar with a wide tail. The gatekeeper does not renegotiate the forecast; the gate simply does not open. The public date slips two weeks rather than becoming a promise the calibrated evidence cannot support. The decision, and who made it, is recorded.

How it works

  • Define the pass criteria in advance. The gate lists what must be present to commit — a defined object, a calibrated range, a reserve, a clean scope reconciliation — so passing is a checklist against evidence, not a vibe.
  • Fix and freeze the commitment object. What is being promised (deliverable, done-condition, quality bar, exclusions) is stated explicitly, so later slippage cannot be laundered as "the goal changed."
  • Reconcile against the scope ledger. The current promise is checked against the running record of scope changes since the last gate, keeping the forecast comparable to the thing actually being committed.
  • Withhold or grant, on the record. A named authority either accepts the calibrated forecast as-is or the gate stays shut; the decision and the acknowledged uncertainty are logged. The gate never improves the number — it only refuses promises the number cannot support.

Tuning parameters

  • Gate stringency — how much evidence, and how calibrated, is required to pass. A hard gate blocks optimistic commitments but slows fast-moving, low-stakes work; a soft one keeps velocity but leaks un-calibrated promises.
  • Stakes threshold — which commitments must pass at all. Gating only large, irreversible, or public promises focuses the friction where it pays; gating everything breeds rubber-stamping.
  • Gatekeeper authority — whether the reviewer can actually hold a launch. A gate whose keeper cannot say "no" to a sponsor is theater.
  • Reversibility weighting — how much a commitment's reversibility loosens the bar. Easily-unwound promises can pass on lighter evidence; irreversible ones demand the full calibration.

When it helps, and when it misleads

Its strength is that it is where the calibration is finally enforced: it directly answers the archetype's core danger — that a forecast becomes a commitment while it is still an optimistic story — by making the acknowledgment of uncertainty a precondition of the promise. Framed as a stage-gate, it gives an organization a defined moment to kill or hold a commitment on evidence rather than momentum.[n1]

It misleads when it becomes a formality: a gate that always opens, or whose criteria can be satisfied with a confident slide deck rather than a calibrated range, provides false assurance and may be worse than no gate, because it stamps optimism with governance's authority. It also misleads when it is mistaken for the calibration itself — a gate cannot fix a bad forecast, only refuse to promise one, so an organization that gates diligently but never improves its estimates just blocks the same projects repeatedly. The guarding discipline is to keep the pass criteria evidence-based and the gatekeeper genuinely empowered to withhold, while ensuring the calibration work happens upstream in the sibling mechanisms rather than being expected of the gate.

How it implements the components

  • commitment_gate — its core function: a checkpoint that blocks a public promise until the calibrated forecast and its consequences are acknowledged by a named authority.
  • forecast_object_definition — it requires and freezes an explicit statement of what is being committed to, so overruns cannot be hidden as definition changes.
  • scope_change_ledger — it reconciles the promise against the running record of scope changes, keeping the commitment comparable to the calibrated forecast.

It does not size the reserve it checks for (contingency_buffer_policy) — that is the Contingency Reserve Formula; the gate verifies a reserve exists and is evidence-linked, but does not compute it. Nor does it build the base-rate distribution (base_rate_distribution) it expects the forecast to rest on; that is the Historical Project Outcome Database.

Editorial Notes

Form Classification

Form family: Decision, Gate & Allocation

Rationale: The checkpoint makes a bounded release-or-hold disposition before date, budget, or scope commitments become public.

Nearest alternative: Assessment, Review & Assurance — Forecast, trace, and reserves are reviewed, but authorization to commit is the gate's defining output.

Review outcome: Adjudicated after independent review; high confidence.

Origin Attribution

Primary origin: Organizational & Management Science

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Project governance developed stage gates that withhold public schedule, budget, or scope commitment until required evidence is acknowledged.

Related originating lineages:

Review resolution: Both independent reviews place the primary lineage in organizational_management. The queued differences (alternate_origin_disagreement) concern secondary metadata rather than primary provenance. The final retains engineering_design, statistics_experimental_design only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] A stage-gate is a governance checkpoint between phases of a project at which a defined authority decides whether it may proceed, using pre-agreed pass criteria; the pattern gives an organization explicit, evidence-based moments to hold or kill a commitment instead of letting momentum carry it.