Actions, tasks, and the lifecycle

An action is the canonical unit of roadmap work. It is what an approved recommendation becomes, and it carries the work all the way from a plan to a verified result.

The lifecycle

An action moves through a defined sequence of states rather than a vague done or not-done. It starts unscheduled, becomes planned, then scheduled once it has dates, moves into in progress, and can be blocked. When the work is finished it reaches work complete, then awaiting evidence, and finally verified once its outcomes are proven. An action can also be cancelled. The states only move forward on real events; work complete is deliberately not the same as verified.

Tasks and dependencies

An action breaks down into tasks, each with its own lightweight status, and tasks can be assigned to the people doing the work. Actions can also depend on one another, so a blocker has to reach its required state before the work it gates can proceed. This keeps parallel streams honest about what is actually ready to start.

Outcomes and verification

Every action carries one or more intended outcomes, each with a baseline and a target. An action verifies only when its required outcomes are actually met, measured against real data such as the current CAMP maturity. Optional outcomes never block verification, and an action never verifies itself on activity alone.

Verification is earned per outcome, not assumed from a checkbox. An action reaching work complete means the team believes it is done; reaching verified means the outcome data agrees.

Verified outcomes are also what credit participation on the Team and My Work surfaces. To see how work arrives here, revisit turning decisions into roadmap actions.