A conditional decision needs an expiry rule

A conditional decision is usable only when the record names five things: the chosen direction, the condition, the person who verifies it, the verification deadline and the fallback if it fails.

Without those parts, “proceed if security approves” sounds like closure but behaves like an unresolved question. Some people start work, others wait, and nobody knows when waiting becomes a different decision.

Separate the decision from its gate

A condition should control whether a decision takes effect. It should not blur what the team chose.

Compare these two records:

We will probably run the pilot in October, subject to the data review.

We will run the pilot on 12 October if Mira confirms by 5 October that the data-handling review has no blocking finding. If she cannot confirm it, the pilot moves to the November window.

The second version contains a real decision and a real gate. A reader can tell what is planned, what must become true and which outcome follows from each result.

Do not attach several vague conditions to one sentence. “If legal, finance and the client are comfortable” hides three separate checks and may hide three different kinds of authority. Write each required approval or fact explicitly. If any one can stop the decision, say so.

Give the condition one verifier

“Pending approval” is incomplete because nobody is accountable for returning the answer to the record.

Name one person who will verify the condition. They do not have to perform all the underlying work. Mira might collect evidence from security and legal, but she owns the final statement that the launch condition has or has not been met.

The verifier needs a test they can actually apply:

• weak: “when the integration looks stable”;
• stronger: “when the failed import is reproduced, fixed and passes the agreed regression check”;
• weak: “if the client is happy”;
• stronger: “when the client sponsor approves the revised scope in writing”;
• weak: “provided the budget works”;
• stronger: “when finance confirms the additional spend fits the approved quarterly envelope.”

The test does not need to become a long acceptance document. It does need to produce an observable yes or no. If reasonable people could read the same evidence and reach opposite conclusions, the condition is not ready.

Put a deadline on verification

A due date for the eventual project is not a deadline for its gate. “Launch in October if approved” can sit untouched until the launch date is already lost.

Set the verification deadline early enough for the fallback to remain possible. Work backwards from the last responsible point, not from the day someone expects to remember the condition.

For example:

Priya will confirm supplier capacity by 3 October at 15:00. If capacity is not confirmed by then, Leon will release the reserved November slot and the team will use the internal rollout plan.

The exact time is useful when another commitment changes immediately afterwards. For a lower-stakes decision, a date may be enough. What matters is that the team knows when the condition stops waiting and starts producing a consequence.

Treat silence as a result only when the record explicitly says so. “If nobody objects by Friday, we proceed” may be legitimate for a reversible internal choice, but it is a poor substitute for an approval that policy, contract or risk ownership requires.

Define the fallback before leaving the room

Teams often record the preferred branch and leave the failed branch blank. That creates another meeting at exactly the moment time is shortest.

Choose a fallback while the relevant people are present. Common fallbacks include:

• move to a named later window;
• reduce the scope to a safe version;
• keep the current process unchanged;
• return the question to a named decision owner with new evidence;
• stop the work and release the people or budget attached to it.

The fallback should be an action, not “reassess.” If reassessment is genuinely required, specify who calls it, what question it answers and when it must happen.

A decision tree with ten branches usually signals that the room has not chosen enough. Record the one or two conditions that materially change the path. Everything else belongs in execution planning or risk tracking.

Control what can start now

A conditional decision creates a tempting grey area: the team wants to preserve momentum, but the commitment is not yet effective.

Divide the work into three groups:

1. safe preparation: useful in either outcome, such as drafting a checklist or gathering existing evidence;
2. reversible work: can start within an agreed cost or time limit and can be stopped without creating an external promise;
3. committed work: spending, customer communication or dependencies that assume the condition has passed.

Authorise the first two deliberately. Hold the third until verification.

For example, the team may prepare the pilot support guide before the data review is complete, but should not email participants that the pilot is confirmed. This distinction prevents a provisional plan from becoming irreversible through a series of small, unrecorded actions.

The action list should reflect the same boundary. “Prepare pilot guide” can be open now. “Send pilot invitations” should either remain blocked or carry the condition as a dependency.

Update the decision record when the gate resolves

Do not leave the original conditional sentence as the newest truth. When the verifier has an answer, append the result:

5 October — condition met. Mira confirmed the data-handling review has no blocking finding. The 12 October pilot may proceed.

Or:

5 October — condition not met. The review found an unresolved retention issue. The pilot moves to the November window under the fallback agreed on 28 September.

Preserve the original condition and the later result. Replacing the first entry with a clean final statement removes the reasoning that explains why work waited or changed.

In Scripta, teams can bring notes or a transcript into the workspace, review extracted decisions and action items, edit the wording and finalise the minutes. Keep the condition in the decision reasoning and turn verification into an owned action with a date. The product can help structure the record; a person still has to decide whether the evidence satisfies the gate.

This is also where a short meeting read-back helps. Ask the verifier to confirm the test and deadline, then ask the decision owner to confirm the fallback.

Use a six-line conditional decision record

Keep the format compact enough to use in an ordinary meeting:

Decision: Run the customer pilot on 12 October.

Condition: The data-handling review has no blocking finding.

Verifier: Mira.

Verify by: 5 October at 15:00.

If met: Leon sends the invitations and starts the pilot plan.

If not met: Move to the November window and keep the internal rollout.

Then state which preparation may begin before verification. Read the six lines back to the room and make the verifier and decision owner confirm their parts.

A conditional decision is not weaker than an unconditional one. It is often the honest response to material uncertainty. The discipline is to make the uncertainty operational: someone tests it, by a real time, and the team already knows what each answer means.