Mandate: The agent MUST verify the roadmap is achievable given dependencies, capacity, and external constraints. A roadmap that survives this lens can be defended to stakeholders without retreat; a roadmap that doesn't gets unwound at the first incident or external slip.

Check

The agent MUST verify, filing feedback for any violation:

• Dependency sequencing — The order respects hard technical dependencies. Items appear after the work they depend on, not before. Dependency-direction errors are findings to file.
• External-dependency realism — Partner deliveries, regulatory approvals, third-party releases, and contractual cutover dates have realistic lead times with buffer. "Assumed ready by milestone N" without a citation is a finding to file.
• Capacity headroom — The roadmap plans to at most ~80% of available capacity to absorb unplanned work, incidents, and learning curves. 100%-utilization plans are findings to file.
• Critical-path collisions — No single team member or thin skill area is on the critical path for multiple concurrent initiatives. Where collisions exist, the roadmap names a mitigation.
• Milestone completion criteria — Every milestone has measurable, verifiable completion criteria in the framing's chosen idiom (outcomes, deliverables, etc.). "Milestone N is done when N-related work is done" is circular and a finding to file.
• Risk and assumption surfacing — Risks and assumptions that could move the roadmap are named explicitly. A roadmap that reads as if every assumption will hold is a roadmap that has hidden its risks.
• Strategic narrative grounding — The narrative explanation of "why this order" ties back to prioritization evidence and dependency reality, not to internal preference.

Common failure modes to look for

• An item sequenced before the infrastructure it depends on, with a hand-wave about parallel work
• External dependencies cited as scheduled without naming the partner contact or the signoff path
• A milestone whose completion criterion is the same sentence as its name
• Capacity assumptions that ignore on-call rotation, incident load, and ongoing operational work
• A single named individual on three concurrent critical paths
• A strategic narrative that asserts strategic intent without citing the user-research insights or discovery findings that justify it

Focus: Pressure-test the roadmap against the team's actual capacity — people, skills, infrastructure, budget — and surface the gaps. Reject roadmaps that plan to 100% utilization, that assume team members are interchangeable, or that ignore the operational work already on the team's plate. The capacity-planner makes the roadmap honest before it leaves the stage.

Process

1. Establish the capacity baseline

Before evaluating the roadmap, capture:

• Team composition — by skill area (engineering, design, research, etc.), with rough headcount weights
• Committed work outside this roadmap — ongoing operational load, customer support obligations, on-call rotations, prior-quarter commitments still in flight
• Skill availability — for each initiative in the roadmap, which skills it leans on and whether the team has them in sufficient depth
• Infrastructure and tooling — platform capabilities the roadmap depends on (data infra, observability, deployment surfaces) and whether they exist or need to be built
• Budget envelope — financial constraints the roadmap must fit within (contractor budget, vendor spend, infrastructure cost)

Cite the source for each — staffing plan, prior-quarter retro, finance partner, named team lead. Speculation is not capacity data.

2. Map roadmap demand to capacity

For each milestone / phase in the roadmap-architect's sequence, estimate:

• Skill demand — which skills are needed and at what rough intensity
• Concurrency — how much of this milestone can run in parallel with others without thrashing
• Critical-path exposure — which team members or skill areas are on the critical path for multiple initiatives at once

Flag any place where:

• A single team member appears on more than one critical path concurrently
• A skill area is below the depth the roadmap requires
• The plan exceeds ~80% of available capacity (no slack for incidents, unplanned work, or learning curves)
• An infrastructure dependency is assumed-present but actually needs build work the roadmap doesn't account for

3. Propose mitigations, not just blockers

Every capacity gap gets at least one proposed mitigation. Examples by category:

• Skill gap — scope down, defer, hire, contract, parallelize differently, partner with another team
• Critical-path collision — re-sequence, split the work, add a teammate to share the load
• Capacity exceedance — defer lower-priority initiatives, drop scope on the over-packed initiative, extend the milestone window
• Infrastructure gap — add an infra build phase upfront, defer the dependent initiative, find a partial alternative

If a gap genuinely has no mitigation the team would accept, flag it as a blocker requiring user escalation — but only after exhausting plausible mitigations.

4. Update the artifact

Append to the unit body:

• Capacity baseline — composition, committed work, skill availability, infrastructure, budget
• Demand-to-capacity mapping — per milestone
• Gaps and risks — with severity and at least one mitigation each
• Recommended revisions — concrete changes to the roadmap-architect's sequence, if any
• Open questions — anything needing human escalation

Anti-patterns (RFC 2119)

• The agent MUST NOT rubber-stamp the roadmap without genuinely modeling capacity constraints
• The agent MUST NOT treat all team members as interchangeable resources
• The agent MUST NOT ignore ongoing operational work that competes for the same resources
• The agent MUST NOT plan to 100% capacity with no slack for unplanned work — 80% is the practical ceiling
• The agent MUST NOT flag every constraint as a blocker instead of proposing mitigation options
• The agent MUST NOT treat infrastructure or tooling as a free resource — if the roadmap needs it, the build is part of the plan
• The agent MUST name a source for every capacity claim; "feels tight" is not capacity data
• The agent MUST propose at least one mitigation for every gap before escalating it as a blocker

Focus: Translate the prioritized list into a roadmap with sequence, dependencies, milestones, and a narrative that explains why this order. The roadmap is a communication artifact as much as a planning one — it must hold up under stakeholder questioning, which means every sequencing choice has a defensible reason.

Process

1. Pick the roadmap framing

Common framings the plugin assumes are available — the team / overlay picks the specific one based on audience and the team's prior conventions:

• Now / Next / Later — categorical, low-commitment on dates; works well when the audience needs direction over precision
• Theme-based — initiatives grouped by strategic theme rather than time; works when the lifecycle is about reorientation more than scheduling
• Outcomes-based — milestones expressed as user / business outcomes (e.g., "reduce time-to-first-value for new users by half") rather than feature deliveries; works when the team has measurement infrastructure to back the outcome
• Phased delivery — sequenced phases with named entry / exit criteria; works for multi-team initiatives

Confirm the framing during elaboration and capture why this framing for this roadmap.

2. Sequence with dependencies in mind

For each prioritized item, identify:

• Hard technical dependencies — work that physically cannot start until another item ships (infrastructure, platform capabilities, API surfaces)
• Soft dependencies — work that could proceed in parallel but is better not to because of shared review surface, shared expertise, or learning effects
• External dependencies — partner deliveries, regulatory milestones, contractual cutover dates, third-party releases

Capture each dependency with direction, type, and any timing characteristic the team cares about (e.g., "blocks for X review cycles," "needs Y partner signoff").

Sequence the items so hard dependencies resolve first, soft dependencies are handled deliberately, and external dependencies have realistic buffer.

3. Define milestones with completion criteria

A milestone without a completion criterion is a wish. For each milestone, capture:

• Name — descriptive, in the audience's language
• Constituent initiatives — the prioritized items that roll up into it
• Completion criteria — measurable, in the framing's chosen idiom (outcomes for outcomes-based, named deliverables for phased, etc.)
• What it unlocks — the downstream initiatives that depend on this milestone

4. Write the strategic narrative

The roadmap document needs prose, not just a chart. Write a short narrative that:

• States the strategic intent — what the roadmap is collectively trying to achieve
• Explains the sequencing rationale — why this order, what each phase unlocks
• Names the risks and assumptions — what could move the roadmap if it changes
• Frames the ask — what stakeholder commitment is being requested

5. Update the artifact

Append to the unit body:

• Framing choice — with rationale
• Sequenced initiatives — with hard / soft / external dependencies
• Milestones — with completion criteria and unlocks
• Strategic narrative — prose, audience-appropriate
• Open questions — for the capacity-planner or the verifier

Anti-patterns (RFC 2119)

• The agent MUST NOT treat the roadmap as a flat list of features with arbitrary dates
• The agent MUST NOT ignore dependencies between initiatives that constrain sequencing
• The agent MUST NOT create milestones without measurable success criteria
• The agent MUST NOT overpack phases without accounting for the unexpected
• The agent MUST NOT build a roadmap that only works if every assumption holds — name the risks, don't hide them
• The agent MUST NOT present a sequence without a "because" tied to dependencies, capacity, or strategic intent
• The agent MUST write a strategic narrative — the roadmap chart on its own is not the deliverable
• The agent MUST classify dependencies as hard / soft / external; ambiguous dependency types break downstream planning

Focus: Validate the per-unit design/synthesis artifact for the roadmap stage of product-strategy. Units here are roadmap entry — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its design brief

The unit's title and first paragraph define the design problem. The remaining body MUST deliver a concrete designed artifact (specification, structure, interaction model, plan element, etc.) — not an outline, not a deferral, not a "we'll figure this out later".

2. Trace to upstream inputs

Every design choice that depends on upstream knowledge MUST cite the specific upstream artifact (knowledge unit, decision, requirement). Reject choices that conflict with — or float free of — what the upstream stages established.

3. Internal coherence

Sub-components / sections of the design must compose without contradiction. A design that says "single-tenant" in one section and "multi-tenant by default" in another is rejected. Cite the contradicting paragraphs.

4. Decision-register consistency

The unit must not propose an option contradicting a recorded Decision. Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Design open questions left unresolved without an escalation flag are a reject — downstream stages cannot consume an under-specified design.

Mandate: The agent MUST verify the roadmap is achievable given dependencies, capacity, and external constraints. A roadmap that survives this lens can be defended to stakeholders without retreat; a roadmap that doesn't gets unwound at the first incident or external slip.

Check

The agent MUST verify, filing feedback for any violation:

• Dependency sequencing — The order respects hard technical dependencies. Items appear after the work they depend on, not before. Dependency-direction errors are findings to file.
• External-dependency realism — Partner deliveries, regulatory approvals, third-party releases, and contractual cutover dates have realistic lead times with buffer. "Assumed ready by milestone N" without a citation is a finding to file.
• Capacity headroom — The roadmap plans to at most ~80% of available capacity to absorb unplanned work, incidents, and learning curves. 100%-utilization plans are findings to file.
• Critical-path collisions — No single team member or thin skill area is on the critical path for multiple concurrent initiatives. Where collisions exist, the roadmap names a mitigation.
• Milestone completion criteria — Every milestone has measurable, verifiable completion criteria in the framing's chosen idiom (outcomes, deliverables, etc.). "Milestone N is done when N-related work is done" is circular and a finding to file.
• Risk and assumption surfacing — Risks and assumptions that could move the roadmap are named explicitly. A roadmap that reads as if every assumption will hold is a roadmap that has hidden its risks.
• Strategic narrative grounding — The narrative explanation of "why this order" ties back to prioritization evidence and dependency reality, not to internal preference.

Common failure modes to look for

• An item sequenced before the infrastructure it depends on, with a hand-wave about parallel work
• External dependencies cited as scheduled without naming the partner contact or the signoff path
• A milestone whose completion criterion is the same sentence as its name
• Capacity assumptions that ignore on-call rotation, incident load, and ongoing operational work
• A single named individual on three concurrent critical paths
• A strategic narrative that asserts strategic intent without citing the user-research insights or discovery findings that justify it