Plans that update themselves: recalibrating forecasts from completion events, not time tracking
Every plan is wrong within a week of being written. That is not a criticism of planners; it is the definition of a forecast meeting reality. The real test of a planning system is not whether the plan survives contact (it will not) but what updating it costs, because that cost decides whether the plan stays alive or becomes the PDF everyone politely ignores.
In most tools the cost is brutal: a slipped task means manually dragging every downstream bar, and so the plan gets reconciled weekly at best, in the Sunday-night ritual every project lead knows. A newer generation of calendar AI tools (Motion, Reclaim, and friends) fixed the dragging by auto-rescheduling your task list into your calendar, which is genuine progress. But rescheduling when you work is the easy half. The hard half is updating what the future looks like: the finish distribution, the odds, the downstream commitments. For that, the system needs to model dependencies and uncertainty, not just free slots.
The only status report is "done"#
Topolog's execution loop is built around one event type. You pick up a task, you work, you mark it done. No timesheets, no percent-complete sliders, no status fields. That austerity is a design position: every other status input is either derivable (the time a task took is the gap between pickup and done), unreliable (percent complete is famous for spending a month at 90), or a tax on the people doing the work.
A completion event does three jobs at once, mechanically:
It advances the frontier. The dependency graph recomputes what is now unblocked; your execute board updates without anyone curating it.
It re-anchors the forecast. The Monte Carlo engine drops the simulated version of the completed work, replaces it with the actual, and re-runs the remaining plan from today. Slips and beats propagate through every downstream quantile immediately: the spectrum, the threads view, the cash trajectory, all of them, because they are all computed from the same object.
It teaches the model your pace. The estimate said six hours; the completion record says nine. One such pair is an anecdote. A growing set of them is a calibration signal, and the engine treats it as one.
Learning your exchange rate#
The calibration layer is the quietly radical part. Per area of work, the system compares your estimates to your actuals and maintains a multiplier between them, applied Bayesianly: it engages only once there is real evidence (eight or more completed observations in a category, so one catastrophic Tuesday does not rewrite your profile) and it sharpens as evidence accumulates.
This is the systemic fix for the planning fallacy (the research and the argument): bias is corrected with measured evidence, while the honest randomness of work stays expressed as estimate ranges. You keep estimating in your natural units; the system learns what your units mean. Chronic optimists get scaled up, sandbaggers get scaled down, and the well calibrated converge to a multiplier of one. Nobody is judged; everybody is corrected.
| Input | Old world | This world |
|---|---|---|
| Task slipped | Drag every downstream bar | Mark it done late; everything downstream recomputes |
| Task beat the estimate | Nobody updates anything; the slack evaporates silently | The beat propagates; downstream quantiles tighten |
| "How long do your tasks really take?" | A retro opinion | A measured, per-area multiplier in the model |
| Status meeting | Reconcile three stale views | Read the recomputed one |
Why this beats the calendar ceiling#
The calendar AI generation hits a ceiling for a structural reason: a calendar knows your time but not your work's shape. It can move tasks into slots, but it cannot know that the slipped task just delayed four downstream pieces across two people, that the rework branch is now 30% more likely, or that the finish distribution moved a week right. Those are properties of a dependency graph under uncertainty, not of a week grid.
The dependency-first system subsumes the calendar trick (your painted availability is exactly the constraint the scheduler packs work into) and then answers the questions the calendar cannot: not just "when will I work on things?" but "when will this be done, with what probability, and what should I do today to maximise it?". Rescheduling is a feature. Re-forecasting is the product.
The cumulative effect after a few weeks is hard to convey until you have felt it: the plan is just true. Open it any morning and it reflects everything that has happened and everything the system has learned from it, without anyone having performed maintenance. The Sunday ritual does not get faster. It gets deleted.