Wiki:Packs/Two-Arc Roadmap

A pack is a deployable set for a Claude project: one instruction block pasted into the project's custom instructions and reference blocks uploaded as project knowledge. This pack supports the Day 4 afternoon working session of a planning week, which produces the two-arc roadmap: the lane table (T8), the first-quarter front-load with owners and dates (decision D-15), the value timeline, the dependency order as a ratification, and the validation circuit (D-16).

When to use it

Create a project from this pack when a leadership room is laying its strategy on a page into lanes and quarters, when a director is filtering the master roadmap to their own view, when a function owner is filling sections 11 and 13 of The Function Service Pack, or whenever a proposed date needs testing against the dependency order. Do not use it to draft the strategy itself (Wiki:Packs/Strategy on a Page), to charter a program (Wiki:Packs/Charter and Program Launch), or to sequence the agent program's own rungs, which A Roadmap Pattern for Agent Teams in WFM carries and this pack cites.

How to deploy

1. Create a project in Claude named for the work, not the method (for example "Roadmap, Day 4 afternoon").
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload as project knowledge.
4. Start a conversation with the lane table, the front-load list, or a date to test.

Block 1 — Project instructions

# Two-Arc Roadmap

## Context
This project supports the Day 4 afternoon block of a planning week for a workforce function, which produces the two-arc roadmap: a lane table (T8) over eight quarters with one star per lane, the first-quarter front-load list with owners and dates (decision D-15), the value timeline on a shared axis, and the dependency order ratified rather than voted. It also produces a director's filtered view. The roadmap is the strategy on a page in a second view; the project checks that the two views carry the same content and never lets them drift.

## Routing
| When the task is… | Open |
|---|---|
| Building or checking the lane table: lanes, owners, programs, quarter cells, stars, bar fill, the agent row | `lane-table.md` |
| Writing or trimming the first-quarter front-load; checking the six foundations; dating against the two external clocks; D-15 and D-16 | `front-load-list.md` |
| Placing value markers; deciding plain versus tailed; refusing a figure without its source | `value-timeline.md` |
| Testing any proposed date against the dependency order; mapping steps to lanes; explaining why a milestone cannot precede another | `dependency-order.md` |

## Disciplines
- The roadmap is the strategy on a page sorted; a star's words are the outcome cell's words, verbatim, or the page is corrected first.
- The dependency order (definitions → comparability → governance → contracts → automation → engine) is an order of dependence, not of start; every lane starts in the first quarter.
- A later step's milestone is never dated before the milestone it depends on.
- Seven lanes; the agent program is a cross-cutting row, not a lane.
- Owners are seats, never names; lanes 4 and 7 are line work with no program wrapper and say so.
- Quarters are the unit; dates inside the front-load quarter are proposals until the validation circuit closes.
- No figure on the value timeline without its source and grade; value-unit milestones, not only savings.
- No director's roadmap is separately authored; a director's view is the master filtered to their rows.
- Every number carries [M][C][E][A]; ranges, not points.

## Output
The lane table in the T8 shape; the front-load list with #, deliverable, owner (seat), date, depends-on; the value timeline as a list of markers with type and source; a dependency check for every proposed date (pass, or the milestone it must follow). Refuse to produce: a headcount or seat count; a person's name against a seat; a placement decision for any tile or lane; a savings figure without a graded source; a lane star that differs from the strategy page's cell; a date that precedes its dependency.

Source: Wiki:Packs/Two-Arc Roadmap (CP-WFM-015) v1.0

Block 2 — lane-table.md

<!-- Derived from [[The Two-Arc Roadmap]] and [[Strategy on a Page]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The lane table (T8)

One page: an arc band above eight quarterly columns; seven lanes as side tabs; a bar per lane for steady-state work; one star per lane for the completion event; value markers on a companion timeline sharing the axis.

## The arcs
- Arc 1, consolidate and standardize: maturity Level 2 to 3 by hand. Four quarters.
- Arc 2, automate: Level 3 to 4 by engine. Four quarters.
Bar fill is shaded by maturity level and switches from dotted to solid where the engine takes over.

## The seven lanes (generic)
| ID | Lane | Delivered by | Owner (seat) | Dependency step |
|---|---|---|---|---|
| L-001 | Definitions and comparability | the definitions-register program; the migration as forcing function; the agent program (definitions in use) | the definitions owner | definitions → comparability |
| L-002 | Process and capacity cycle | the program office (standards committee); the agent program (first components); the platform-instance program | the placement seat as steward; the portfolio planning seats for the cycle | governance → automation |
| L-003 | Governance and decision rights | line work; the program office administers the protocol and forums | the function's leader; the placement seat for the change-control board | governance |
| L-004 | Partner contracts and supply-seat portfolio | line work on the renewal calendar; the definitions program supplies the comparability clause | the placement seat; the contracts seat | comparability → contracts |
| L-005 | Capability ontology | the ontology program | the placement seat; the definitions owner in the paper phase | definitions → engine |
| L-006 | Simulation and placement engine | the long-term capacity engine extended into simulation; the ontology program (supply side); the hand-run gate | the placement seat; the portfolio planning seat for the platform | contracts → engine |
| L-007 | Organization design and role evolution | line work with the people function; the platform-instance program supplies the sunset condition | the function's leader; the people partner | governance → automation |
| (row) | The agent program | cuts across L-001, L-002, L-006; owns none | the portfolio planning seat that owns the pilot book | automation |

## Cell rules
- A cell is one milestone sentence, an observable event. Empty cells are allowed; a bar runs through them.
- The star cell is the arc's completion event and must be word-for-word the outcome cell on the strategy page.
- A dotted bar marks work approved in direction but not yet dated.
- Lanes reconcile to programs: a lane with no program or line-work owner will not move; a program with no lane has no star.

## Generic star sentences (Arc 1 / Arc 2)
| Lane | Arc 1 star | Arc 2 star |
|---|---|---|
| L-001 | one question, one answer: one instrument across all nodes; the first matched-tenure comparison run | every output carries its evidence |
| L-002 | Stage 1 complete: the top processes at L2; "highly specified" defined and tested | the cycle runs itself; people check |
| L-003 | decisions computed, owners sign: the first budget-season dial setting under the model | governance runs on the counterfactual record |
| L-004 | consolidated supply seats, one yardstick: the first renewal on the shared instrument | supply seats judged on the automation path |
| L-005 | supply described, not assumed: the ontology is the routing vocabulary | routes supply, not demand |
| L-006 | the gate runs on paper: one placement case priced by hand as the worked example | placement computed, explained, signed |
| L-007 | same people, clearer structure: the transition structure in place; sunset conditions printed | judgment realigned to new job classes |

"L2" here is the documentation level of the process standard (L0 cover sheet · L1 flow · L2 step table · L3 job aids), not a maturity level.

## A director's view
Filter the master to the director's rows (lanes owned, programs carried, front-load items with their seat) and retitle. Never author a second roadmap.

## Output shape
| ID | Lane | Owner (seat) | Programs | Q1 | Q2 | Q3 | Q4 ★ | Q5 | Q6 | Q7 | Q8 ★ | Dependency step | Value marker |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

## Example, labeled as one
A worked example's eight quarters ran Q2 2026 through Q1 2028 with stars in Q1 2027 and Q1 2028; L-001's owner was the definitions owner and its programs PG-001, PG-004 (forcing function) and PG-007 (definitions in use). Illustration only; an estate's quarters are its own.

Block 3 — front-load-list.md

<!-- Derived from [[The Two-Arc Roadmap]] and [[Function and Program Charters]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The first-quarter front-load (D-15) and the validation circuit (D-16)

The quarter after the week is front-loaded so that the foundations every later quarter depends on exist before the second quarter opens. A list, not a bar: each item with an owner (a seat), a date inside the quarter, and what it depends on by ID.

## The six foundations
| # | Foundation | Owner (seat) | Depends on |
|---|---|---|---|
| 1 | the definitions register's first version: the six core definitions (occupancy, handle time, shrinkage, contact, attrition, ramp), signed jointly | the definitions owner | D-12 |
| 2 | the standards committee chartered and sitting, with its queue | the placement seat (chair) | D-06 |
| 3 | the intake door and the executive register live; the weekly report derived | the methodology steward; the program office | D-09, D-14 |
| 4 | the capability ontology on paper; the cardinality test run on returned pool data | the placement seat; the definitions owner | pool data returned |
| 5 | the agent team on one book, planner gate on | the portfolio planning seat that owns the book | D-13 |
| 6 | the platform-instance program chartered; its first book chosen | the standardization lead | D-13, D-14 |

Every later star depends on these six. They are not struck.

## Typical further items (staffable, strikeable)
Organization option to the people function with sunset conditions printed; interim placement protocol live and the ownership map published; supply-seat cards carrying one use each and the renewal calendar read as a constraint-relaxation schedule; the gate hand-run on two or three live questions with the constraint register opened; the capacity cycle on one calendar published a year ahead; the migration's measurement model settled before its next phase.

## Decision D-15
Ratify the list: strike what cannot be staffed and say which quarter absorbs it. The dependency order is a ratification, not a vote. Read two external clocks first: the first partner renewal (lane L-004 is dated against it) and the commercial function's pricing milestone (L-001's value marker is dated against it). Both are actions for the program office.

## Decision D-16
The validation circuit: who corrects the room's answers (the directors, the finance function, the operator of the service-center node for the node taxonomy), and by when. Nothing on the roadmap is settled until it has run. Two weeks is a working duration.

## Checks on any item
1. Observable on its date.
2. Inside the front-load quarter.
3. Owner is a seat.
4. Depends-on is an ID, not prose.
5. If it depends on a foundation not yet dated, written "after <foundation>, by <date>."

## Output shape
| # | Deliverable | Owner (seat) | By | Depends on | Status (kept / struck → quarter) |
|---|---|---|---|---|---|

## Example, labeled as one
A room kept twelve items, the six foundations non-negotiable, all dated inside the quarter after the week; one further item (title harmonization across three heritages) was struck as unstaffable and absorbed by the following quarter; the circuit closed two weeks after the week. Illustration only.

Block 4 — value-timeline.md

<!-- Derived from [[The Two-Arc Roadmap]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The value timeline

A companion page sharing the lane table's axis and lane order, so a reader flips between "what is done when" and "what value lands when" without reorienting.

## Marker types
| Marker | Meaning | Example |
|---|---|---|
| plain circle | a one-time benefit or event | the first recorded decline with its price (the counterfactual record exists) |
| circle with a tail | a benefit that starts and continues accruing | consolidation of partner blocks by body of work; a serviced body of work automated with a published catch rate |
| dated marker | a reminder the roadmap must not forget | the Standard's expiry, one year after issue |

## Rules
- Value-unit milestones, not only savings: a comparison both sides accept; a decline recorded with its price; one instrument live at one node; a catch rate published.
- No figure travels without its source and grade. A savings figure with no producible artifact is [A] asserted and is not drawn as a number; draw the marker and name the source that will produce the figure.
- Where several figures for the same benefit are in circulation and unreconciled, draw one marker and record the reconciliation as an open item, never an average.
- A marker sits in the quarter the value lands, not the quarter the work starts.
- The consolidation marker names supply seats (partner capacity blocks), never director seats or posts.

## Generic markers by arc
| Quarter | Marker | Type |
|---|---|---|
| Arc 1, early | the first recorded decline with its price | plain |
| Arc 1, mid | consolidation of supply seats by body of work begins | tailed |
| Arc 1, star | performance-based allocation becomes possible (one yardstick) | plain |
| Arc 2, early | the first serviced body of work reaching the automated band with a published catch rate | tailed |
| Arc 2, mid | value per unit rising while cost falls (the value-based path) | tailed |
| Arc 2, star | exposure falls: residual complexity placed by depth, not rate | plain |

## Output shape
| Quarter | Lane | Marker | Type (plain / tailed / dated) | Source of any figure, with grade |
|---|---|---|---|---|

## Example, labeled as one
A timeline carried three markers with no figures: a plain marker in the second quarter for the first recorded decline; a tailed marker from the fourth quarter for consolidation of partner blocks; a tailed marker from the fifth quarter for the first automation with a catch rate. Illustration only.

Block 5 — dependency-order.md

<!-- Derived from [[The Two-Arc Roadmap]], [[The Case for Operating Model Planning]] and [[Vendor Ecosystem Restructuring Agenda]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The dependency order

> definitions → comparability → governance → contracts → automation → engine

An order of dependence, not of start. Every lane starts in the first quarter (the standard is built concurrently with the climb, never serialized behind it). What the order fixes: a later step's milestone is never dated before the milestone it depends on.

## Why each step depends on the one before
| Step | Depends on | Because |
|---|---|---|
| comparability | definitions | an instrument cannot compare two nodes on a metric the nodes define differently |
| governance | comparability | a forum that signs placements needs one yardstick or it signs opinions |
| contracts | governance and comparability | a comparability clause cites an instrument; a renewal signed before the instrument is live protects the wrong thing |
| automation | governance and contracts | the acceptance gate (a governance body) admits the documentation an agent runs on; automation clauses (gain-share, data, model ownership) must be in the contract before a partner post is automated |
| engine | everything | the engine reads registered definitions, supply cards on one instrument, and constraints from signed contracts; **its build runs in parallel from the first quarter**, and only its running at the annual horizon is dated after the hand-run year |

The chain's order is stated on The Case for Operating Model Planning; the reasoning by tier is on Vendor Ecosystem Restructuring Agenda, which also builds the placement engine in parallel with the decisions rather than after them. This block applies both; it restates neither.

## Steps to lanes
| Step | Lane(s) whose star it is |
|---|---|
| definitions | L-001; L-005 (supply-side definitions) |
| comparability | L-001 |
| governance | L-003; L-002 (the standards committee is a governance body) |
| contracts | L-004 |
| automation | L-002 (first automated components); the agent row |
| engine | L-006 |
L-007 sits beside the order; its star is dated against governance and automation.

## The date test
For any proposed milestone:
1. Name its step.
2. Name the milestone it depends on (the previous step's, in its lane or another).
3. Is the dependency dated the same quarter or earlier? Pass. Later? Fail: move the proposed milestone or explain why the dependency is not binding for this milestone (rare; record the reason).

| Proposed | Step | Depends on | Check |
|---|---|---|---|
| a renewal signed on the shared instrument | contracts | one instrument live at one node (comparability) | must be the same quarter or later |
| the first automated component with a catch rate | automation | the acceptance gate live; the first five step tables through it (governance) | must be later |
| the engine at the annual horizon | engine | a year of hand-run gate pages; the constraint register; supply cards | its build is Arc 1; its annual-horizon running is Arc 2 |

## Common misorderings, and what they cost
- Contracts before comparability: a clause that cites an instrument that does not exist; renegotiated at the next renewal.
- Automation before governance: several versions of one process automated; the odd-case loop has no owner.
- Engine before definitions: cannot-run on most tests; the register fills with missing inputs the hand-run would have found for free.
- Comparability before consolidation: an instrument affordable for one node and not the others; comparisons at unmatched tenure.

## Output shape
For every proposed date: the row above (proposed · step · depends on · check), and a one-line reason for any exception.

## Example, labeled as one
A room proposed an automation clause in the third quarter and the comparability clause in the fourth; the check did not pass and the automation clause moved to the fifth quarter, drafted early and signed at the next renewal. Illustration only.

Usage notes

• Sizing. Block 1 is 449 words and loads with every message. Blocks 2 to 5 total about 2,500 words and are retrieved only when the routing table sends the model to them.
• Drift. The reference blocks are derived from the two chain pages and the three existing pages named in the infobox; when any changes materially, regenerate the blocks and increment the version. The dependency order is stated on The Case for Operating Model Planning and reasoned tier by tier on Vendor Ecosystem Restructuring Agenda; the block follows both.
• Scope. Method only. No estate data; the quarters and stars in the examples are a worked illustration, never an estate's.
• Two views. This pack and Wiki:Packs/Strategy on a Page produce one content in two views; when the two disagree, the strategy page is corrected first and the roadmap follows.

Change history

Version	Date	Change
1.0	2026-09-17	First release: instruction block plus four reference blocks

See also

• Planning Week for a Workforce Function
• The Two-Arc Roadmap — source for Blocks 2 to 5
• Work Placement Landscape — the transitions the lanes carry
• The Case for Operating Model Planning — the dependency order, stated
• Vendor Ecosystem Restructuring Agenda — the reasoning beneath it, tier by tier
• Wiki:Packs/Strategy on a Page — the same content in its first view
• Wiki:Packs/Charter and Program Launch — the programs under the lanes
• Wiki:Packs