How driftless plans

How work gets planned

Planning starts with an outcome someone wants, and it decomposes in fixed steps until every piece of work is testable. Each artifact in the chain exists so the next one can be checked against it.

• Conviction becomes an initiative. A product direction is recorded as an initiative: the problem, the goal, and the boundaries of what is in and out of scope, in one place.
• Initiatives carry paired specifications. Every capability area in an initiative has a product specification (the behavior, the acceptance criteria a user can verify) and a technical specification (the architecture that delivers it), paired one to one. The pairing is enforced, by gate check, so no capability ships without a buildable design behind it and no design exists without a capability it serves.
• Work decomposes into linked tasks. Each spec pair decomposes into tasks, and every task carries testable acceptance criteria and links to the specification sections it implements. Dependencies between tasks are recorded as explicit links, which drive execution order: a task that depends on another does not start until its dependency ships.
• Traceability runs both directions. From any task you can reach the specification it implements, and from any specification section you can reach the tasks that deliver it. Nothing in the plan is an orphan, and no orphan work can enter the build.

The chain ends where planning should end: at tasks whose acceptance criteria are specific enough that an agent, or a human, can prove completion rather than claim it.

How the plan changes

Before implementation starts, automated gates check the specifications themselves. The gates run the same way on every initiative, and their findings are the mechanism by which the plan changes.

• Integrity gates. Deterministic checks verify the structure: every product section has a paired technical section and vice versa, every section pair has at least one linked task, every task links to its source sections, and every task carries acceptance criteria with real descriptions. These checks are computed, so their verdicts are reproducible.
• Collision and consequence gates. Further checks read the content: does this design conflict with a sibling initiative's architecture, contradict its own product specification, duplicate work specced elsewhere, or leak implementation detail into a product document? And if the design is wrong, what does it cost, and can the builder actually build it? Findings name the exact section and the exact problem.
• Findings drive remediation, not reprimands. A failed gate does not stop the initiative; it rewrites it. Sections get relinked to the tasks that implement them, leftovers from earlier drafting get removed, product language gets separated from technical mechanism, and missing dependencies get added. Then the gate re-runs against the revised plan.
• Verification-time changes revise the sequence too. The plan is also revisited after gates: a blocked task gets resequenced, a dependency link gets re-set when scope shifts, and execution results that contradict the plan's assumptions feed back into it. The plan is expected to move when the evidence says so; the system is built for that rather than pretending plans are static.

A real replanning, end to end

The following trace is one recorded sequence from the task board, scrubbed to capability level: no task identifiers, project names, or section titles from the private board appear. The full decision log with timestamps and authors is retained on the board, and this account is verifiable against it.

1. The setup. A multi-feature initiative had completed specification: several product sections, each paired with a technical specification, and a set of tasks linked to the sections they implement. A gate run was executed against the whole initiative before any implementation began.
2. What the gate returned. The run passed most of the plan and failed parts of it, with findings naming each problem: an implementation mechanism (a caching design, with its storage and timing details) had been written into a product specification where only the behavior belonged; an interface naming in one technical section broke a platform-wide convention used by its siblings; a product specification promised behavior its paired technical section described differently; and a boundary note about a shared credential store was missing, leaving a blast radius undocumented. Separately, the structural checks failed on one section pair: a technical specification section had no paired product section, and no tasks were linked to it, and one task in the initiative linked to no source sections at all.
3. The plan changed. The findings rewrote the plan. The mechanism detail was folded out of the product specification into the technical one, leaving the product document stating only the behavior and its acceptance criteria. The inconsistent route was renamed to the platform convention, and the implementing task's description was updated to match. The display contract was aligned so the product promise and the technical design said the same thing. The missing boundary note was written into the affected technical sections. And the traceability gaps were closed: the unpaired section was paired and the orphan task was linked to its source sections.
4. The re-run. The gate ran again against the revised plan. Every remediated finding now passed, with the record showing the check had been remediated and re-verified: the contamination finding, the convention conflict, the paired-specification conflict, and the missing consequence analysis all flipped to pass. One section still held a structural failure, the unpaired section and its missing task links, which kept that part of the gate red and queued the next remediation pass. That is the loop working as designed: findings that were fixed pass; findings that remain are named and drive the next change.
5. What it protected. The failing findings were caught before any code was written against the flawed plan. The cheapest possible point to discover that a product document had absorbed an implementation detail, or that a section had no tasks behind it, is before the first commit, and that is exactly where the gate put it.

This is a genuine mid-flight strategy change driven by an intermediate result: the gate's findings were the input, the rewritten specifications and relinked tasks were the revised plan, and the re-run verified it. The initiative is expected to hold this bar: a gate run that finds nothing leaves the plan standing, and one that finds something rewrites it.

Where decisions live

Every plan change described above is recorded, not recalled.

• Findings are recorded with their run. Every gate run stores its findings per section: the gate, the check, the status, the detail naming the problem, and the timestamp. Findings the next run resolved are marked as remediated rather than erased, so the revision history of the plan stays readable.
• Decisions carry author and timestamp. When a human decides how the plan should change, the decision is recorded on the task board with who made it and when, and the affected specifications are updated to state the decision directly.
• Tasks record their own trail. Status changes, comments, and acceptance-criteria evidence accumulate on each task with timestamps, so any published trace can be walked against the recorded history rather than trusted on assertion.

Direction stays with people: the gates surface what needs to change, and people decide what the plan becomes. What the system guarantees is that the change is visible, attributed, and verifiable after the fact.