What is a planning language?
A planning language is a formal notation for writing plans down as text, the way a programming language writes computation down: tasks, dependencies, uncertain durations, decision points, and possible endings, all expressed with precise syntax and semantics. Because the plan is a program rather than a picture, machines can do real work with it: check its structure, compute its schedule, simulate its outcomes, and diff its versions.
TOL (Total Orchestration Language), the language inside Topolog, is one example; a fragment reads like this:
task t_review "Final review" { agent: me; estimate: 4h cv 0.3; produces: [approved] }
edge e1 t_review -> s_live { carries: null; gate: approved = true }A task with an owner, an uncertain duration, and an outcome; an edge that routes the plan to a success state when the outcome lands true. Everything a drag-and-drop tool stores as opaque database rows, here as eight readable lines.
What qualifies a notation as a planning language#
| Property | Why it is required |
|---|---|
| Formal syntax | Unambiguous parsing: one text, one meaning |
| Dependency semantics | The text encodes a planning graph, not just a list |
| Uncertainty as data | Estimates carry spread; branches carry probability |
| Checkable validity | A validator can reject malformed plans before execution |
| Executable meaning | Schedules and forecasts are computed from the text, not asserted beside it |
The practical consequences follow from text-ness: plans can be version-controlled, diffed line by line, reviewed like code, copied between projects, exported without a vendor's permission, and authored by anything that writes text, including the LLM you already pay for.
The property worth being strict about: totality#
A planning language faces one deep design choice: how powerful to be. TOL is deliberately total: every valid plan provably terminates. There are no unbounded loops; repetition exists only as bounded iteration ("retry until approved, at most six times"). The restriction is what buys exhaustive analysis: because every plan halts, the engine can simulate all of it, enumerate its endings, and verify roughly eighty structural invariants without hitting the halting problem. A Turing-complete planning language would be strictly more expressive and strictly less knowable; for plans, knowable wins. SQL and spreadsheet formulas made the same trade, which is partly why they are everywhere.
This is also the design that makes AI authorship safe: a model can draft fluently in the language, and a deterministic validator judges the draft, because the language was built to be judged (the full argument).
Do you have to write it?#
No, and this is the most misunderstood part. A planning language is an interchange and verification layer, not an obligation: Topolog's visual canvas, inspector panels, and AI builders all read and write TOL on your behalf, the way design tools write file formats you never open. The text is there for the moments that need precision (the diff before the deadline conversation, the review of an AI draft, the migration you have not needed yet), and its existence is what makes those moments cheap.