What makes a plan valid? Eighty invariants before you execute
Nobody ships a service whose only quality gate is "the diagram looked fine in the meeting". Yet that is the standard of rigour most plans get, and plans govern more spend than most services. The double standard exists for one reason: code has a compiler and plans, historically, have not. Validity in mainstream tools means the boxes saved without crashing.
Treat the plan as a program (the case for that) and the standard changes mechanically. Topolog's validator runs on every edit, the way a language server runs in your editor, and checks the plan against roughly eighty named structural invariants before it is allowed to drive execution. Each finding carries a code, a location, and a severity. "Valid" stops being a feeling.
What the invariants actually catch#
Eighty rules sound bureaucratic until you see what they are: each one is a way plans actually go wrong, named and made checkable. The big families:
Reachability and termination. Every task must lie on a path to a terminal state. Work that contributes to no ending is either unnecessary or missing its wiring, and both deserve a flag before you spend a week on it. Dependency cycles are rejected with the offending loop named (cycles are the one thing a schedule cannot survive; bounded loops get a first-class construct instead).
Branch coverage. Wherever the plan forks on an outcome ("approved = true" goes left), the branches must be exhaustive and mutually exclusive: every future has exactly one place to go. The classic silent failure here is the forgotten else: a review that can fail, feeding a plan with nowhere for failure to land. Humans miss this constantly because the happy path is the one they imagined; an exhaustiveness check does not have an imagination.
Cross-level coherence. A plan has zoom levels (milestones containing tasks), and the views must agree: a milestone-level edge needs leaf-level edges realising it, and leaf-level flow crossing between milestones needs the container edge declared. Without these checks, the executive view and the execution view quietly become two different plans, which is the polite description of how most steering-committee surprises are manufactured.
Probabilistic completeness. Every outcome a gate consumes needs a prior; every terminal verdict needs a calibrated probability. This family has teeth because of what consumes the plan: a Monte Carlo forecast over a plan with missing priors would have to invent numbers, and an invented prior is precisely the kind of silent default that turns a forecast into theatre. The validator refuses to let the gap hide. (One rule in this family deliberately resists any automatic default, because a defensible number requires judgement; the engine would rather block than guess.)
Cognitive structure. The advisory tier: levels exceeding the working-memory budget (Miller's law as lint), labels too long to render, structure that will read badly. Real, but never blocking.
Severity is part of the meaning#
The findings are tiered, and the tiers are load-bearing:
| Tier | Contract | Example |
|---|---|---|
| Hard error (execution) | The engine will not run this; the result would be wrong, not ugly | Cycle; non-exhaustive sentinel gates; missing prior on a consumed outcome |
| Warning (design mode) | Same checks, relaxed while you scaffold a draft | The same rules during early sketching |
| Advisory | True, useful, never blocking | An eight-child level; a label that will truncate |
The design/execution split deserves a sentence. Drafts are allowed to be broken: while you sketch, most violations surface as warnings so the tool stays out of your way. Promoting a plan to execution is the moment the contract hardens, exactly like the difference between code on a branch and code being deployed. Several dozen of the invariants exist precisely at that boundary.
Two properties keep the system honest at scale. Where a fix is mechanical (a missing container edge with an obvious source), the Problems panel offers a one-click quick fix; where the fix requires judgement (what to name the groups when splitting an oversized level), it deliberately does not, because a tool that auto-applies editorial decisions is making your plan worse while making your error count better. And every check is deterministic: same plan text, same findings, byte for byte, which is what lets validation gate automation. The same checks run identically on a plan typed by hand, imported from a file, or drafted by an AI, and that last case is where the validator quietly becomes the most important component in the product: it is the reason AI authorship can be trusted at all.
There is also an audit dividend. Because validity is recomputed from the source text, "what changed and is it still sound?" has a precise answer at any point in history: diff the text, re-run the checks. Plan change auditability falls out of the architecture rather than needing a feature.
The standard, portably stated#
Even without the tool, the checklist transfers. Before you commit to any plan, ask: does every piece of work lead somewhere? Does every branch have an else? Do the summary view and the detail view describe the same plan? Does every "it depends" have a probability attached, however rough? Does any level ask you to hold more than seven things in your head?
Five questions, ninety seconds, and they catch an embarrassing fraction of real plan failures. The other seventy-five invariants are why we let a machine do it.