Decisions are not tasks: modelling the choices you control separately from the outcomes you do not
Look closely at any real plan and you will find three different kinds of thing wearing the same task-shaped costume.
There is work: record the lessons, build the landing page. There are uncertainties the world resolves: does the review pass, does the deal close, does the supplier deliver on time. And there are uncertainties you resolve: which pricing tier, how much runway to commit, build it or buy it, lean launch or loud one.
Mainstream tools model the first kind and flatten the other two into it. The review becomes a task called "review" with a duration, as if passing were a matter of hours spent. The strategy choice becomes a task called "decide GTM approach", as if deciding were the work rather than the fork. Both flattenings destroy exactly the information a forecast needs, but they destroy it differently, which is why a planning language needs two distinct constructs.
Outcomes: uncertainty with a prior#
The world's uncertainties are modelled in TOL as outcomes: typed quantities (boolean, categorical, scalar) with a prior probability, produced by tasks and consumed by gates.
outcome approved: boolean { default_prior: 0.8 }An outcome is something you can estimate but not choose. The engine treats it accordingly: every Monte Carlo sample draws a value from the prior, and the futures fork. In 80% of simulated futures the plan proceeds down the approved branch; in 20% it lands somewhere else, and the completion spectrum reports both populations honestly (worked example here).
Decisions: uncertainty with an owner#
Your uncertainties are different in kind. There is no prior on "which tier will I pick", because you are not a random variable; you are the person the forecast is for. TOL gives these their own declaration:
decisions {
gtm: enum[lean, balanced, aggressive]
runway_months: integer in [3, 6]
}A decision does not get sampled. It gets swept. The engine evaluates the plan under every option (every enum value, every point on the integer range), holding the world's randomness fixed via common random numbers so the comparison is pure. The result is not one forecast but a family of them, indexed by the choices you could make. Picking is your job; the engine's job is showing what each pick buys, which becomes the Pareto frontier when the options trade off against each other.
The two constructs also interact, and this is where the modelling earns its keep. A decision can shift an outcome's prior:
outcome pmf_strong: boolean {
default_prior: 0.45
conditional_overrides: [
{ when: gtm = balanced; apply: { default_prior: 0.65 } }
{ when: gtm = aggressive; apply: { default_prior: 0.85 } }
]
}Read it as a causal claim: spending more on go-to-market raises the odds that product-market fit shows up. Whether 0.85 is the right number is a judgement you own, but the structure (choices influence chances, chances drive endings) is now in the plan, machine-checkable and forecast-bearing, instead of living in the gap between two slides.
Why the distinction changes behaviour#
A few things become possible the moment choices and chances stop impersonating tasks:
| With everything-as-tasks | With decisions and outcomes |
|---|---|
| "Decide GTM" sits on the timeline as 2 hours of work | The fork is structural: three futures, each fully forecast |
| Scenario analysis means duplicating the plan per option | The sweep enumerates the whole option space automatically |
| The risky review is a duration, so it always "passes" | The review is a prior, so 20% of futures take the rework branch |
| Commitment is implicit (someone edits the plan) | Committing a decision collapses the swept space, and the forecast re-conditions on the world you actually chose |
That last row matters operationally. Decisions in Topolog have a lifecycle: open decisions keep their whole option space alive in the analysis; committed ones narrow it. The plan always reflects what is still genuinely open, which is a quiet but real piece of plan change auditability: the history of what was decided, when, lives in the plan rather than in meeting minutes.
There is also a discipline benefit that has nothing to do with software. The act of writing decisions { } forces a team to name which uncertainties are actually theirs. A surprising amount of project anxiety turns out to be an unowned decision drifting around disguised as a risk. Naming it as a choice, with options and a deadline for committing, is often half the management.
Tasks are what you will do. Outcomes are what the world will do back. Decisions are where you still get a say. A plan that cannot tell the three apart can list your work, but it cannot advise your choices, and advising choices is what planning was supposed to be for. (For the cash dimension of those choices, see P(insolvency) and the earned forecast.)