Programs
One approved specification can span many plans across many services. The workstream graph is persisted and scheduled — not rendered into a prompt and discarded.
What used to happen to a large objective#
A big goal produced a convincing plan with a workstream graph and a milestone roadmap. Both were rendered into prose for the planning prompt and then thrown away. There was no scheduler, no persisted workstream state, and no code path that ever built the second milestone.
A program is the layer that fixes it. It is what lets one approved specification span many plans, in dependency order, across many services, until the whole product exists.
How a program behaves#
- Dependency-ordered
- Units are scheduled against the graph, and overlapping units are merged before anything is scheduled rather than colliding later.
- Serial branch topology
- Deliberately serial, so the history stays reviewable and merges stay comprehensible.
- A blocked unit does not end the program
- Work that can proceed proceeds; remediation units are raised for what cannot.
- Budgeted
- A program carries its own budget, so a long build cannot quietly become an open-ended one.
- Resumable
- State is durable, so a crash resumes rather than restarts.
The gates still apply, per unit
A program does not bypass approval. Every unit passes the same gates, and shipping still requires current evidence — a program is a scheduler, not an exemption.
Common questions
Can I stop a program partway?
Yes, and controls exist on every surface — the command line, the dashboard and Telegram.