Forced-Commitment Decision Systems¶

This section defines the decision system used when decisions are made under conditions of low strategy clarity and low commitment safety.

In this regime, teams are required to commit before uncertainty can be fully resolved, and reversing decisions is expensive, political, or slow.

The decision system used here exists to prevent confident failure under pressure.

Gates in the Forced-Commitment Decision System¶

In this regime, decisions are not only authoritative — they are irreversible or costly to reverse. For this reason, the system uses explicit decision gates.

A gate is a mandatory decision checkpoint where: - assumptions are tested against reality - authority is exercised explicitly - proceeding without resolution is disallowed

Gates are not stage milestones. They exist to prevent commitment from advancing faster than decision clarity.

The Four Gates¶

The reference implementation of this system uses four gates.

Each gate answers one non-negotiable question:

Gate 1 — Framing Gate
Do we agree on what decision we are actually making?
Gate 2 — Strategy Gate
Is there a coherent strategic bet with explicit trade-offs?
Gate 3 — Commitment Gate
Are we willing to commit capacity under known constraints and risks?
Gate 4 — Integration Gate
Are authority, ownership, and failure recovery unambiguous?

Failure at any gate blocks progression.
Skipping a gate is a system violation, not an efficiency gain.

Each gate enforces the existence and validity of a specific decision contract:

Framing Gate
Ensures the decision under consideration is explicit and bounded.
Strategy Gate
Requires a valid Strategy Contract decision statement.
Commitment Gate
Requires a valid Delivery Permission Contract decision statement.
Integration Gate
Requires a valid Integration Contract decision statement.

A gate cannot pass if its corresponding decision statement does not exist.

Decision Regime Context¶

This decision system applies when:

strategy is unclear, contested, or incomplete
delivery pressure exists regardless of uncertainty
commitments create downstream obligations
stopping or reshaping work is costly

In this context, learning alone is insufficient.
A decision system must force clarity before commitment, even when that clarity is uncomfortable or incomplete.

Primary Decision Failure This System Prevents¶

The Forced-Commitment Decision System exists to prevent one dominant failure:

Allowing work to proceed without an explicit, testable strategic bet and delivery permission.

This failure typically appears as:

delivery starting “to learn faster”
discovery embedded inside irreversible execution
scope defended due to sunk cost
governance absorbing conflict that should have been resolved at decision time

The Forced-Commitment Decision System¶

In this framework, the Forced-Commitment Decision System is implemented as a contract-based system composed of three complementary contracts:

a Strategy Contract
a Delivery Permission Contract
an Integration Contract defining authority boundaries and recovery paths

Each contract is authoritative only within its boundary.
Together, they form a closed decision system.

The Strategy Contract¶

Purpose¶

The Strategy Contract exists to prevent commitment without a coherent, constrained strategic bet.

It does not generate ideas or visions.
It determines whether a strategy exists at all.

A strategy is considered valid only if it:

can be expressed explicitly
makes trade-offs visible
can be rejected or refined

Authority¶

The Strategy Contract has authority over:

direction
prioritization of the first bet
strategic exclusions

It has no authority over:

delivery timing
resource commitment
execution sequencing

When to Use This Contract¶

Use the Strategy Contract:

when proposing a new initiative
when delivery is blocked or challenged
when stakeholders disagree on the first commitment
when discovery feels broad, slow, or unbounded

Do not use it:

to justify decisions already made
to produce roadmaps
as a documentation exercise

If the contract cannot be completed, strategy does not yet exist.

Required Decision Statement¶

A valid forced-commitment decision must be expressible as a single decision statement.

We are committing to {STRATEGIC BET}
in order to achieve {INTENDED OUTCOME},
accepting {EXPLICIT TRADE-OFFS AND RISKS}.
This commitment is invalid if {DISCONFIRMING CONDITION} occurs,
in which case {RECOVERY OR STOP ACTION} will be taken.

If this statement cannot be written:

strategy is not yet coherent
commitment is premature
the decision system has failed

Documentation without this statement does not constitute a decision.

The Delivery Permission Contract¶

Purpose¶

The Delivery Permission Contract exists to protect delivery capacity by determining whether work may enter delivery now.

It is a permission system, not a methodology.
Passing the contract does not guarantee success.
It guarantees clarity before commitment.

Authority¶

The Delivery Permission Contract has authority over:

whether work may enter delivery
whether scope is independently deliverable
how investment risk is declared

It has no authority over:

defining strategy
expanding scope to compensate for risk
bypassing failed strategic decisions

When to Use This Contract¶

Use the Delivery Permission Contract:

before work enters a delivery backlog
before committing cross-team or long-running work
when execution pressure is high

If the contract fails, delivery must stop, reframe, or return to strategy clarification.

Required Decision Statement¶

A valid delivery permission decision must be expressible as:

We are permitting delivery of {SCOPE OR BET SLICE}
under {DECLARED CONSTRAINTS AND DEPENDENCIES},
accepting {ACKNOWLEDGED DELIVERY RISKS}.
Delivery permission is revoked if {REVOCATION CONDITION} occurs,
in which case {STOP, CONTAINMENT, OR REPLAN ACTION} will be taken.

If this statement cannot be written:

delivery permission has not been granted
execution pressure must not override this failure
delivery must not proceed

Wanting delivery is not the same as authorizing delivery.

The Integration Contract¶

Purpose¶

The Integration Contract defines how the Strategy Contract and the Delivery Permission Contract work together without merging or overriding each other.

It answers one question only:

When a strategy or initiative fails, which decision system is responsible, and what happens next?

Authority Boundaries¶

The Strategy Contract decides whether a strategic bet exists.
The Delivery Permission Contract decides whether that bet may enter delivery now.

Neither contract substitutes for the other.

Valid System States¶

Only a small number of system states are valid:

no strategy, no delivery
strategy defined, delivery blocked
strategy defined, delivery permitted

Any state where delivery proceeds without a valid strategy is a system failure.

Required Decision Statement¶

A valid integration decision must be expressible as:

If {STRATEGY FAILURE CONDITION} or {DELIVERY FAILURE CONDITION} occurs,
decision authority rests with {NAMED ROLE OR BODY},
and recovery will proceed via {EXPLICIT RECOVERY PATH},
without retroactive reassignment of blame or authority.

If this statement cannot be written:

authority boundaries are ambiguous
escalation will default to governance
accountability will fragment under pressure

Failure Semantics¶

Failure is expected and informative.

Failure means:

assumptions are unresolved
scope is too large
risk posture is unclear
trade-offs are being avoided

Failure does not justify:

escalation to governance
bypassing the decision system
compensating with process or reporting

The correct response to failure is to return to the appropriate contract.

Commitment Threshold¶

Forced-commitment decisions are subject to the Minimum Viable Commitment rule.

If a required stakeholder is in non-compliance:

delivery permission must not be granted,
forced commitment must not proceed,
escalation must follow the defined decision system.

Execution under unresolved non-compliance is not a delivery risk.
It is a decision failure.

Relationship to Other Parts of the Framework¶

Interaction with Contextual Drivers¶

Contextual Drivers explain why uncertainty and constraints exist.
They do not authorize commitment.

The Forced-Commitment Decision System governs whether commitment is allowed despite those drivers.

Interaction with Stable Rules¶

This system directly enforces rules related to:

clarity before commitment
explicit trade-offs
reversibility where possible
transparency of authority

Violations here cannot be repaired downstream.

Interaction with Governance Contracts¶

Governance contracts do not replace this decision system.

When governance is used to resolve issues that belong here, it indicates a decision failure upstream.

Interaction with Practices and Tools¶

Delivery and discovery practices may operate only after this decision system permits commitment.

Practices may not be used to:

weaken decision constraints
justify bypassing failed contracts
normalize unclear commitments

Misuse Patterns¶

This system is commonly misused when:

applied as heavy governance in low-risk contexts
treated as a one-time approval ceremony
reduced to templates to “fill in”
bypassed under time pressure

Misuse typically results in confident execution of the wrong thing.

Key Takeaway¶

The Forced-Commitment Decision System exists to ensure that:

when commitment is unavoidable, it is at least deliberate, explicit, and owned.

It does not remove risk.
It prevents risk from being hidden.