The earned forecast: gating project success on the bank balance, not optimism

Here is a forecast that should worry you: a plan reporting 90% probability of success while its own cash simulation shows the balance going negative in four futures out of five. Both numbers can be simultaneously true in any tool that defines success as "the tasks completed". The tasks did complete. The company just was not there to see it.

The bug is in the definition. If staying solvent is genuinely a condition of your project succeeding (for a startup, an agency, a self-funded launch, it usually is), then a forecast that ignores the balance when deciding which futures count as wins is not optimistic. It is answering a different question than the one you asked.

Success is a definition, and you own it#

In TOL, a plan's endings are explicit objects called sentinels, tagged success, partial, or failure. Which futures reach which sentinel is decided by gates, and gates are where the definition of success actually lives. Most gates test outcomes ("approved = true"). The earned forecast comes from one addition: a gate can test the simulated bank balance directly.

sentinel s_profitable "Shipped and solvent" { end_state: success }
sentinel s_bankrupt "Ran out of cash" { end_state: failure }

edge e_win t_final -> s_profitable {
  carries: null
  gate: account.balance.trajectory.last >= 0gbp
}
edge e_bust t_final -> s_bankrupt {
  carries: null
  gate: account.balance.trajectory.last < 0gbp
}

account.balance.trajectory.last is the end balance of the current Monte Carlo sample, the same per-future ledger replay described in the P(insolvency) article. Each simulated future arrives at the end of the work, looks at its own bank account, and files itself under the ending it actually earned. The two gates are complementary, so every future lands exactly once, and P(success) now means something specific: the probability that the work completes and the money holds.

That is the whole mechanism. No second model, no reconciliation between a schedule view and a finance view. One simulation, with solvency wired into the scoring.

What changes when you wire it in#

The before-and-after on the same plan is the clearest way to see the point:

The third row is where strategy gets interesting. Once success is balance-aware, time and money start trading against each other inside one number. A decision that stretches the schedule but flattens the burn can genuinely improve the odds, and the decision sweep will show it, because every swept option is scored by the same solvency-aware definition. Optimising for "probability of actually winning" quietly stops you optimising for "earliest plausible ship date", which is the optimisation that kills cash-constrained projects.

Revenue makes it a model, not a budget#

A detail that elevates this beyond burn-down arithmetic: the account is credited as well as debited, and credits can be gated on outcomes. The milestone payment arrives only in the futures where the client signs off; the launch revenue scales with whether the launch went well. Income, like everything else in the plan, is uncertain and conditional, and the balance trajectory inherits that honesty. A plan that books optimistic revenue as a certainty would just be optimism wearing a ledger.

Where the line is#

Worth stating plainly: this is a model of project finances, not an accounting system. It will not reconcile your bank feed, handle VAT, or replace your bookkeeper. The numbers in it are planning assumptions (costs with spread, revenue with conditions) whose job is to make the forecast decision-grade, and the usual honesty rules apply: write ranges you would defend and let actuals correct you.

But "model" is not a diminishment. The question that decides cash-constrained projects (will the money outlast the work?) is precisely a question about interacting uncertainties over time, which is precisely what a Monte Carlo plan engine is for. Define success the way you actually mean it, and the forecast stops grading your project on a curve.