Roadmap Updates
CanonicalPurpose
Roadmap updates communicate progress, changes, delays, and priorities.
Required Content
- Current phase
- Completed work
- Changed assumptions
- Blockers
- Next priorities
- Risks and dependencies
Guardrails
Roadmap updates should not promise fixed delivery dates unless dates are confirmed.
Draft Roadmap Rules
Roadmap updates should separate intent, active work, validated work, blocked work, and approved release scope. A planned item is not an implementation commitment and a completed local validation is not a publication or production approval.
Roadmap updates should record:
- request or sprint identifier;
- current maturity state;
- blockers and decision owners;
- validation evidence;
- production/execution state;
- next recommended request;
- changes from the prior roadmap.
Publication Boundary
Roadmap pages must not imply production readiness, financial performance, governance approval, or legal/compliance approval unless the supporting evidence is referenced and approved for publication.
Roadmap State Model
| State | Documentary Meaning |
|---|---|
| Planned | Direction exists, but implementation is not confirmed |
| Accepted | Scope is governed for future work |
| In progress | Work has started; delivery and activation are not implied |
| Blocked | A named dependency prevents progress |
| Delivered | The defined artifact exists |
| Verified | Evidence confirms the stated result within a named context |
| Deferred | Work remains valid but is not scheduled for execution |
Every update names its owner, dependency, evidence date, and next decision. Items do not move directly from planned to verified without delivery and verification evidence. Closed requests, commits, or repository existence do not automatically change public product maturity.