DP16 — Roadmap & Milestones
Patches and comments are scoped to the whole document family, not to a single revision. When you open a revision, highlights show what still applies to that revision body; anything anchored to text a later revision removed is listed as needing re-anchoring, and anything that can no longer be merged at all is marked obsolete. See all patches.
Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.
# DP16 – Roadmap and Milestones
*Honest, resourced, and revisable commitments about what gets built, when, and with what evidence*
<!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->
## 1. Purpose of This Draft
This roadmap system layer ensures that coordination signals remain trustworthy under uncertainty, incentives, and scale rather than degrading into narrative management.
## 6. Milestone Framework
DP16 requires that milestones be structured objects rather than sentences on a slide. A milestone that cannot be classified, scoped, resourced, and closed is a narrative claim, not a commitment.
### 6.1 Milestone anatomy
Every milestone carries:
- a persistent identifier that survives reorganization and renaming - scope (in-scope, out-of-scope) and explicit completion criteria - commitment class and confidence level - dependency references with control and certainty classification (5.1) - assurance gates that must clear before completion (5.2) - funding state and maintenance ownership (5.8, DP17) - an accountable owner and a next review date - evidence links once claimed complete (5.3)
Failure mode: **unbounded milestone**, where completion is a matter of interpretation.
### 6.2 Commitment classes
Public roadmap language must remain proportional to class:
- **exploratory:** under investigation; no delivery implied - **committed:** scoped, owned, and resourced; delivery expected within a stated window - **funded:** committed with secured resources and named maintenance ownership - **blocked:** committed but held by an identified dependency - **deprecated / withdrawn:** intentionally stopped, with rationale retained
Failure mode: **class inflation**, where exploratory work is communicated in committed language.
### 6.3 Status transitions and triggers
Transitions between classes are events, not edits. Each transition records who decided, why, what changed, and who is affected, and where material, triggers notification and governance review (5.4, DP3).
Failure mode: **silent transition**, where status changes without a record.
### 6.4 Completion and partial completion
Completion requires evidence proportional to the claim. Partial delivery is represented as partial, with the remaining scope carried forward under the same identifier rather than absorbed into a success statement.
Failure mode: **rounding up**, where partial work is reported as delivered.
### 6.5 Milestone receipts and comparison views
Each closed milestone produces a receipt linking claim to artifacts (docs, code, tests, audits, attestations), and roadmap views allow comparison of committed versus current versus delivered state over time (DP15 linkage).
Failure mode: **unverifiable closure**, where completion cannot be independently checked.
## 7. Phased Rollout
Roadmap honesty depends on distinguishing stages of maturity. DP16 requires explicit phases with entry and exit criteria so that demonstrations are not mistaken for deployed capability.
### 7.1 Phase ladder
- **research:** feasibility and risk exploration; no external reliance expected - **prototype:** demonstrable behavior in controlled conditions; not for dependence - **pilot:** limited real participants, bounded scope, monitored, reversible - **limited production:** available with declared constraints and support commitments - **general availability:** broadly usable with assurance, support, and maintenance in place - **sustained / maintained:** funded upkeep, security response, and deprecation policy
Failure mode: **phase skipping**, where pilots are marketed as general availability.
### 7.2 Entry and exit criteria
Movement between phases requires satisfying declared gates, typically including security and privacy review (DP15), safety and containment posture for AI capability (DP11, DP13), governance readiness (DP3), accessibility, operational support, and funding for the next phase (DP17).
Failure mode: **gate erosion**, where criteria are waived under schedule pressure without record.
### 7.3 Reversibility and rollback
Each phase declares how it can be paused, narrowed, or withdrawn, including participant notification, data handling on withdrawal, and preservation of records.
Failure mode: **irreversible rollout**, where problems cannot be contained without breaking dependents.
### 7.4 Communication rules per phase
Public claims are bounded by phase. Demonstrations, benchmarks, and previews are labeled with phase, evaluation context, and known limitations, and cannot imply availability that does not exist.
Failure mode: **demo-to-production drift**, where audiences reasonably infer capability that is not deployed.
### 7.5 Cohort and zone sequencing
Where rollout proceeds by community, zone, or region, sequencing and selection criteria are published, along with what earlier cohorts are expected to absorb in risk and what later cohorts gain.
Failure mode: **invisible experimentation**, where participants do not know they are the pilot.
## 6.8. Governance, Accountability, and Agency Surfaces
DP16 requires that roadmap signals are not only visible but **actionable and contestable** within governance processes.
- **non-actionable transparency**, where information is visible but cannot be used to influence outcomes - **accountability gaps**, where no actor is responsible for correcting misleading signals - **participation fatigue**, where communities lack effective recourse and disengage
## 7.9. Incentives and Power Analysis
Roadmaps sit inside powerful incentive fields. Teams, funders, partners, contributors, and communities often benefit in the short term from optimistic claims, compressed timelines, and selective disclosure of risk. DP16 exists because those incentives do not naturally produce truth.
A critical failure mode is credibility arbitrage, where actors gain near-term benefits from inflated claims while distributing long-term costs to contributors and communities.
## 8.10. Community Signals Informing DP16
Community signals consistently show that people do not expect perfect prediction. They expect honesty, memory, and respect for the planning burdens created by public commitments.
DP16 treats these signals as design inputs. Roadmap systems should make uncertainty legible, show dependency reality, and allow communities to distinguish delay caused by honest learning from delay caused by misrepresentation.
## 11. Evaluation Criteria
Roadmap integrity is measurable. DP16 evaluates whether signals were reliable, not whether predictions were perfect.
### 11.1 Forecast and variance measures
- **variance distribution:** planned versus actual delivery windows, reported without post-hoc rebasing - **explained variance ratio:** share of slips accompanied by published rationale - **re-forecast timeliness:** interval between a dependency change and public timeline update
### 11.2 Dependency and resourcing accuracy
- **dependency disclosure rate:** share of blocking dependencies identified before commitment - **control classification accuracy:** how often "controlled" dependencies proved external - **funding-label accuracy:** how often committed work was actually resourced (DP17)
### 11.3 Evidence and memory measures
- **receipt coverage:** share of completed milestones with verifiable evidence links - **changelog completeness:** share of material changes with recorded author, rationale, and impact - **history integrity:** absence of silent removals; prior states remain retrievable
### 11.4 Assurance visibility
- **assurance ratio:** proportion of roadmap surface allocated to security, privacy, safety, and accessibility work - **gate adherence:** share of phase transitions that satisfied declared criteria - **capability claim accuracy:** alignment between stated AI readiness and evaluated capability (DP11)
### 11.5 Thresholds, triggers, and ratings
Evaluation must be consequential:
- integrity ratings attach to roadmap segments and are visible alongside milestones (Section 6, Section 8) - breaching thresholds (repeated silent changes, missing receipts, sustained unexplained variance) triggers governance review - correction, reclassification, or withdrawal is required where claims were misleading
Failure modes:
- **accuracy scoring that punishes honesty**, discouraging early disclosure of uncertainty - **metric gaming** through milestone splitting or scope shrinkage - **unowned measurement**, where results are published but change nothing
## 12. Implementation Patterns
These patterns make roadmap integrity operational rather than aspirational. They are illustrative, not mandated.
### 12.1 Roadmap item registry
A structured store where each milestone is a record with stable identifier, class, scope, dependencies, assurance gates, funding state, owner, and evidence links. Public views render from the registry, so presentation cannot drift from the underlying record.
### 12.2 Dependency graph with propagation
Dependencies are modeled as edges with control and certainty attributes. When a dependency changes state, downstream milestones are flagged automatically for re-forecast rather than silently retaining old dates.
### 12.3 Dual-track board
A single view presents feature work and assurance work with shared status vocabulary and linked gates, making deferral of security, privacy, or accessibility visible instead of invisible.
### 12.4 Milestone receipt store
Completed milestones publish receipts referencing documentation, releases, test results, audits, or attestations (DP15), with permanent addresses so future readers can verify past claims.
### 12.5 Change feed and targeted notification
Material roadmap changes emit an append-only public feed entry and notify affected communities, partners, and dependents, converting silent pivots into observable events.
### 12.6 Confidence and integrity badges
Roadmap segments display confidence level, funding state, and integrity rating derived from measured history, giving readers a calibration signal at the point of reading.
### 12.7 Retrospective and pre-mortem templates
Standard formats capture planned versus actual, dependency shifts, distinctions between uncertainty, error, and misrepresentation, and the specific planning changes adopted in response.
### 12.8 Public status surface
A durable status page maps current phase, known blockers, open risks, and next review dates, so participants do not need to reconstruct state from announcements.
Anti-patterns to avoid:
- roadmaps maintained only in slides or marketing pages - status conveyed exclusively through release announcements - private trackers whose public rendering is manually curated - date changes applied by editing history rather than recording transitions
## 9.13. Non-Goals and Explicit Boundaries
DP16 does not aim to eliminate uncertainty or impose rigid planning. It defines what roadmaps are **not allowed to become**.
- **methodology masking**, where process language obscures lack of commitment - **selective disclosure**, where only favorable information is surfaced - **narrative protection**, where truth is suppressed to maintain external perception
## 10.14. Minimum DP16 Alignment (Non-Normative) (Non-Normative)
Minimum alignment is the point at which roadmap signals are **reliable enough to coordinate real work**. The aim is not perfection, but to avoid systematically misleading participants.
- **Aspirational drift:** commitments implied without binding scope or resourcing - **Dependency illusion:** plans rely on unresolved external conditions without disclosure - **Assurance invisibility:** security/safety work omitted from visible planning - **Historical erasure:** past commitments disappear without record - **Signal inflation:** capability claims exceed operational reality
## 11.15. Open Questions and Future Work
DP16 leaves several questions open because roadmap integrity depends on context, maturity, and governance capacity. The goal is not to impose one planning methodology, but to define the integrity conditions that any credible method must satisfy.
These questions should mature through future ML-Drafts, reference implementations, and governance experiments. DP16 should not freeze roadmap practice too early; it should make roadmap integrity inspectable while methods evolve.
## 12.16. Relationship to Other Desirable Properties
DP16 is a cross-cutting property because roadmap integrity affects whether other desirable properties can be trusted over time.
- **DP3: Adaptive Governance.** Governance needs accurate roadmap signals to sequence decisions, allocate attention, and adjust priorities. If roadmap changes are silent, governance becomes reactive and legitimacy suffers. - **DP7: Interoperability.** Interoperability depends on shared timelines, version expectations, and dependency clarity. Roadmap drift across systems can break integration even when protocols are sound. - **DP9–DP10: Builder and learner expectations.** Contributors and learners invest time based on public signals. Roadmap integrity protects that investment from being misdirected by hype or vague commitments. - **DP11–DP15: AI, security, and provenance alignment.** Capability claims, safety gates, audits, provenance systems, and security posture all require visible sequencing. DP16 ensures assurance work is not hidden behind feature marketing. - **DP17: Financial sustainability.** Milestones must reflect funding and maintenance reality. Unfunded commitments should be labeled as contingent rather than presented as guaranteed delivery.
If DP16 fails, other DPs can appear stronger than they are. A system may claim future privacy, future AI safety, future security, or future interoperability while coordinating present action around promises that are not structurally accountable.
## 13.17. Foresight and Failure Design
DP16 assumes delays, failures, and shifting conditions. It does not treat change as failure. It treats untracked, unexplained, or strategically obscured change as failure.
A mature roadmap system does not avoid failure. It makes failure learnable, bounded, and repairable.
## 14.18. Path Toward ML-RFC
Advancement from ML-Draft to ML-RFC requires demonstrating that roadmap integrity can be operationalized across real initiatives, not merely described.
Promotion to ML-RFC should require evidence that participants can compare commitments over time, verify milestone outcomes, and understand why material changes occurred.
## 15.19. Closing Orientation
DP16 is where the meta-layer demonstrates respect for time.
Published: 2026-08-08
Pages: 10 | Words: 4650
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.
Published: 2026-08-05
Pages: 10 | Words: 4634
What changed:
Numbered section headings and cross-reference fixes for collaborative review
Published: 2026-08-04
Pages: 10 | Words: 4634
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.