Plan

Write the actions, in order. One question: how will it be actioned? Sub-items are fine, and so is discovering that the answer is longer than expected.

A plan is revisable, and revising it is not failure. It is a route, not a promise; the promise was made elsewhere — on the commitment axis — and is not renegotiated by discovering the route is longer.

Touch

Touch is what a change reaches — the parts of the system it alters, and whatever depends on them. Declared by the plan, because listing what will change has already listed what is reached.

Touch decides what a change must satisfy. The wider it reaches, the more standards come into scope. That is derived from the change itself, never judged: nobody rules a change small enough to skip something.

Where touch can also be derived, a mismatch between derived and declared summons a verifier. The change reached further than it was intended to, which is a surprise rather than a schedule.

Where touch cannot be computed at all, it attracts maximum rigour, never minimum. A derivation over code nothing covers returns an empty set — which would point the incentive exactly the wrong way, and give the least-verified work the least care.

Done when: the actions are ordered, and the touch is declared.

Verified when: someone who did not write it confirms that following it would make the specifications pass. If it might not, the plan is not finished.