Wiki:Packs/Technology Plan

Pack
ID	CP-WFM-016
Domain	WFM
Version	1.0
Blocks	1 instruction + 6 reference
Source	Technology Migration Plan for a Workforce Function · The Definitions Register · Launching an Analytics Notebook Platform · Expanding Intraday Automation · Systems Administration for WFM Platforms · Technology Journey from Level 2 to Level 5 · the T6 component card is also derived, for the GRPI-T sheet, in Wiki:Packs/GRPI-T Instantiation's component-cards.md
Planning-week block	Day 3 afternoon (technology and data)

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 technology block of a planning week and the working session that produces its artifacts: the technology component cards by category, the dated build order, the definitions register v0, the integration-by-when table, and the four sub-plan shells (notebooks, intraday expansion, systems administration, and the engine's shell, which points at Wiki:Packs/Placement Decision Engine Build for the engine itself).

When to use it

Use this pack on Day 3 afternoon of a planning week, and in the weeks after it when a sub-plan owner turns a shell into a plan. It produces category-level plans: component cards that name no product, a build order with its reasons, register entries with their questions, and shells with owners as seats. Do not use it to select a platform (WFM Technology Selection and Vendor Evaluation is that work), to build the placement engine (use CP-WFM-008), to migrate a book (use CP-OPS-004), or to author the Standard's toolset section (use CP-OPS-003). It does not decide anything: the build order is presented as settled and the block takes no decision of its own.

How to deploy

1. Create a project in Claude named for the work, not the method (for example "Technology plan — planning week").
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 template you are filling: a component card, the build order, a register entry, the integration table, or a sub-plan shell.

Block 1 — Project instructions

# Technology Plan

## Context
This project produces the technology chapter of a workforce planning
function's operating-model blueprint: a component map by category, a
four-step build order, a definitions register v0, an integration-by-when
table, and four sub-plan shells. Every box is a system category, never a
product. The plan moves the function from tools bought for good reasons,
each with its own definitions, to the same tools on one data core reading
one set of definitions. The build order is settled and is presented, not
debated; the session fills templates and states reasons.

## Routing
| When the task is… | Open |
|---|---|
| Fill a component card; place the placement band; state the build order or its reasons | `build-order.md` |
| Draft or review a definitions register entry; the six core definitions; the two traps | `definitions-register.md` |
| Open or fill the notebook platform shell; the first three notebooks; notebook governance | `notebook-platform-launch.md` |
| Inventory rules; assign an action class; state the catch-rate condition; the overseer | `intraday-automation-expansion.md` |
| Configuration to the standard; instance strategy; the change-control board; access and retention | `systems-administration.md` |
| Date an integration; fill the integration-by-when table; open the engine shell | `integration-by-when.md` |

## Disciplines
- Name every platform by category: long-term capacity engine, short-term
  WFM engine, intraday automation, reporting platform, Python analytics
  platform (the reporting platform's notebook component). Never a product.
- The long-range horizon has two arms: a system of record that stores, a
  simulation engine that calculates and stores nothing. Never merge them.
- Ontology on paper before any platform; exhaust the core before buying
  a tool. The decision layer of any engine is never delegated.
- One definition per metric. Every number cites a register entry by ID
  and version, or is marked as citing none.
- Grade every number: [M] measured · [C] computed · [E] estimated with a
  range · [A] asserted. A computed figure inherits its weakest input.
  Nothing carried across a channel, platform or cohort change is [M].
- Owners are seats, never names. Dates are proposals until a platform
  program confirms them, and say so.
- No action class is released on a maturity level; it is released on a
  published catch rate for that class.
- Say what would change the answer on every card and every shell.

## Output
A filled template per request, in the template's columns, with grades on
every number and a one-line "what would change this". Refuse to produce:
a headcount number or seat count; a person's name against a seat; a
product recommendation or vendor ranking; a placement decision; a release
of any action class without a catch rate. Where an input is missing,
return the row with the field blank and an owner, never a guess.

Source: Wiki:Packs/Technology Plan (CP-WFM-016) v1.0

Block 2 — build-order.md

<!-- Derived from [[Technology Migration Plan for a Workforce Function]] and [[Technology Journey from Level 2 to Level 5]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The component map and the build order

## The component card (T6)

One row per component. Columns, in order:

| Column | Rule |
|---|---|
| ID | `TC-nnn`, permanent |
| Component (category) | Long-term capacity engine · simulation engine · capacity and headcount plan · short-term WFM engine · intraday automation · capability layer · quality platform · contact platform (ACD) · data core · reporting platform · Python analytics platform · the agent layer. Never a product |
| Horizon | 12–36 months · annual/quarterly · weekly/daily · intraday · real time · data and insight · cross-cutting |
| What it does | One line; verbs, not features |
| System of record for | What this component alone is authoritative for; "nothing, it reads" is a valid answer |
| Definitions it must read | Register entry IDs |
| State today | In place · partial · not in place, with a grade; "two instances" and "differing definitions" are states worth recording |
| Lights at | The maturity level at which it is standard (see table below); may be in use earlier |
| Product (annex only) | Left blank on the card; named in the plan's annex if at all |
| Integration and date | The crossing this component depends on and its proposed date |
| Program | The program (PG-nnn) that builds or connects it |

## Where each component lights

| Component | Standard at | Note |
|---|---|---|
| Short-term WFM engine | Level 2; on the core at 4 | At Level 2 this is what leadership calls WFM |
| Reporting platform | Level 2 to 3 | Describes and explains what happened |
| Contact platform | Level 2 | Static skill profiles; limited attribute depth; its caps are constraints on placement |
| Intraday automation | Level 3 | Where the data core stops being optional |
| Capacity and headcount plan | Level 3 | Agreed with finance |
| Quality platform | Level 3 | Capability evidence flows up |
| Long-term capacity engine (plan of record) | Level 4 | In use from Level 2; one core at 4 |
| Simulation engine | Level 4 | Separate from the plan of record |
| Python analytics platform | Level 4 | Introduced at 3; standard at 4 |
| Data core | In progress from 2; complete at 4 | The thing that cannot be bought |
| Capability layer | Ontology at 2–3; platform at 5 | Record first, engine last |
| The agent layer | Assistants at 3; automation layer at 4 | Ledgers, not sheets |

## The placement band

Placement lives in three boxes at three horizons (simulation: network
design; capacity plan: skill and site allocation; capability layer:
real-time routing of supply) and is named in none. Draw the engine as a
band across the three with the gate as its interface. The engine is built
with CP-WFM-008; this pack only opens its shell.

## The build order (four steps, settled)

| Step | Build | Reason | Depends on |
|---|---|---|---|
| 1 | The definitions register with the capability ontology on paper | Every later component reads them; a migration cannot land without them | The register's owner and signatories (a decision on Day 4 morning) |
| 2 | The plan of record on one core (the long-term capacity engine as system of record, iterating with finance) | The spreadsheet is where the reconciliation argument with finance lives | Step 1; the headcount perimeter agreed with finance |
| 3 | Simulation and notebooks together | They share the analysts; the engine prices what the notebooks model | Step 2 |
| 4 | The capability layer as a platform, inside intraday automation, hooked to routing | Only after the ontology has run by hand in the gate for two quarters | Steps 1–3; the ontology exercised by hand |

The rule beneath the order: exhaust the core before buying a tool. The
measurement layer is what a platform bids for; the decision layer is
never delegated.

## Three orderings reconciled

Functions usually hold three orders at once: capability layer before
simulation; simulation before attribute routing; definitions before
everything. They agree once "capability layer first" is read as "the
ontology on paper first, inside the definitions program". State that
reading in the room and the debate closes.

## The Technology headline

One sentence the room agrees, in the GRPI-T sheet's Technology row. A
usable form: "The same tools on one core reading one set of definitions;
the ontology on paper before any platform." Do not add a product, a
date or a number to it.

## Failure modes to check a card against

- The core defines the estate: one platform's interval, state and skill
  constructs became the enterprise data model by default.
- Two arms bought as one: a plan of record expected to simulate.
- Automation without a write-back: intraday automation bought before the
  contact platform can act on its decisions.
- Dashboards mistaken for analytics: a richer report in place of a
  notebook in which models are built.
- The skills matrix mistaken for the capability record.

## What would change the order

A function that bought the capability platform or the simulation engine
first, on a vendor's definitions, and produced comparable cross-node
numbers without a later definitions program. Record it if found; the
order becomes four parallel programs rather than a sequence.

Block 3 — definitions-register.md

<!-- Derived from [[The Definitions Register]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The definitions register (RG)

One adopted definition per metric, versioned, with its instrument, its
resolution, what it is read beside, and who signed it.

## The entry (ten fields)

| Field | Holds | Rule |
|---|---|---|
| ID | Permanent, e.g. `AHT-01` | Never reused; a changed definition is a new version, not a new ID |
| Definition | One plain sentence, then the formula | Numerator and denominator by channel |
| Instrument | Source system, field, instrument version | The version is part of the definition |
| Resolution | Per contact · per interval · per cohort and tenure band; the smallest detectable difference | A comparison below resolution is noise reported as a finding |
| Pairing | What the number must be read beside | Occupancy with service level; handle time with handled volume; quality score with the customer-experience index; never blended |
| Owner | The seat that answers questions | Informs; does not adopt |
| Signatories | The leaders whose books the entry makes comparable, jointly | Jointly, because the comparison is between them |
| Version · effective date | Which version applies from when | Corrections apply forward only; history is never restated |
| Carry rule | Whether the number survives a channel, platform or cohort change | It does not: [A] in the new state until re-measured |
| Change history | Propose · review · version · adopt, with dates | A change without a row is a defect |

## The six core definitions and the question each must settle

| ID | Definition | The question |
|---|---|---|
| `OCC-01` | Occupancy | Numerator and denominator by channel; after-contact work in or out; blended and concurrent agents |
| `AHT-01` | Handle time | Talk + hold + after-contact work, or the platform's field; per contact or per case; transfers; on a session channel, elapsed time or agent work (hold both fields; adopt one) |
| `SHR-01` | Shrinkage | Planned vs unplanned; is ramp time shrinkage or productive; denominator (paid, scheduled, logged hours) |
| `CON-01` | Contact | One contact across voice, chat, email and case; is a follow-up on an open case new; the unit the forecast counts in |
| `ATT-01` | Attrition | Voluntary, involuntary, regretted; annualization; tenure bands |
| `RMP-01` | Ramp | Time from seat to proficient on the shared instrument; proficient per work group; the depth-discount curve by cohort. Carry from v0 at grade Open with an owner and a date |

The capability ontology (who can do what: eligibility, proficiency,
entitlement, evidence and decay) sits beside the register, not inside
it; CP-WFM-002 carries its dictionary. Same program, same signatories.

## Change control

1. **Propose** — any seat, with the reason and the reports affected.
2. **Review** — owner and co-owner, against the ten fields.
3. **Version** — a new version with an effective date; the previous kept.
4. **Adopt** — the signatories, jointly.

Adoption test: the first report, notebook and platform configuration
cite entries by ID and version. A register nothing reads is a document.

## Ownership options (a Day 4 decision, not this pack's)

- Sole: a named seat under the placement function.
- Co-owned with the analytics function (recommended in the source
  article's example): the co-owner holds instrument and lineage; the
  function holds definition and pairing; neither changes an entry alone.

## The two traps the register catches, and how

**Two definitions.** A comparison across two entries reads as a change
in the operation. First act on any comparison: confirm both sides cite
the same ID and version. Example [illustrative]: contacts per
transaction "up 35 percent" when one side is `CPT-01` at 0.42 [M] and
the other a legacy report's `CPT-02` at 0.31 [M] on the same days; no
change on one definition.

**Composition.** A single correct definition still hides a change when
the blend of two cohorts is flat while each moved. The register's
answer is the resolution field: an entry at "per cohort and tenure
band" obliges every report reading it to carry the split. Example
[illustrative]: a blend flat at 442 → 441 seconds while one cohort fell
430 → 405 and the other held at 470; the mix moved toward the slower
cohort. Decompose within-cohort vs composition before reporting.

## What a definition must state to be adopted

Numerator, denominator, channel treatment, instrument and version,
resolution, pairing, carry rule, owner, signatories. An entry missing
any one is at grade Open, with an owner and a date, and may be cited as
Open. It may not be cited as adopted.

Block 4 — notebook-platform-launch.md

<!-- Derived from [[Launching an Analytics Notebook Platform]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Launching the notebook platform

The Python analytics platform is the reporting platform's notebook
component. The launch is the decision to use it as the function's
modeling surface under governance, not a procurement.

## Where it sits

- Reads the data core through governed definitions: every notebook cites
  register entries by ID and version in a header cell.
- Sits beside the simulation engine, not in place of it; the two share
  the analysts and are built together (build-order step 3).
- Writes dispatches, not ledgers: a notebook output is derived and
  regenerated, never hand-edited; a notebook that writes into a ledger
  is a pipeline and belongs in the reporting platform's scheduled jobs.

## The first three notebooks

| Notebook | Proves | Feeds |
|---|---|---|
| A variance decomposition (volume · handle time · mix · supply; within-cohort vs composition) | The platform reads the core on the register's definitions at cohort resolution | The register review; the composition check on any blend |
| A ramp curve (handle time and quality against tenure, by cohort; curve or level shift) | The platform can compute `RMP-01` | Supply cards' tenure depth; the structural/transitional tag |
| A placement case priced by hand (the gate's pooling-cost and coverage-floor tests via the Erlang B recursion, arithmetic shown) | A verdict-bearing table travels with its method | Step 5 of the engine build path; the gate's priced outcome |

None is a report. Each must be re-runnable by a second analyst.

## Six governance rules, enforced where possible

| Rule | Enforced by |
|---|---|
| Definitions header in cell one | Review before promotion; the governed metric layer refuses uncited fields |
| Version control in a text representation | The repository integration |
| Restart and run all before commit | Review; a rendered output that differs from a clean run is discarded |
| Parameterized runs (date, book, cohort) | The platform's parameter injection |
| Grades on every published number; mixed-grade tables say so in the caption | Review; the reporter agent where one runs |
| No production pipelines in notebooks | The promotion path |

## The promotion path

Exploratory (one analyst, one question) → governed (header, clean run,
in the repository) → promoted (logic refactored into a scheduled job on
the reporting platform; the notebook becomes the job's documentation).
The schedule runs the job, not the notebook.

## Ownership and the first deliverable

Owner: the analytics-automation track holder (a seat). Co-owner: the
analytics function that holds the reporting platform and the warehouse
entitlement; where the register is co-owned, the same co-ownership
covers the platform. First deliverable is not a notebook: it is the
confirmed entitlement (warehouse access and notebook execution for
named analysts). Without it the plan is a diagram.

## Measures (counts, never headcount)

- Notebooks with a definitions header (target: all).
- Notebooks promoted to scheduled jobs.
- Analyst hours moved from spreadsheet to notebook, from the analysts'
  own time records [M], never asserted.

## The sub-plan shell (SP) row

`SP-nnn` · Notebooks · owner (seat) · first three deliverables
(entitlement; three governed notebooks; first promotion) · depends on
build-order step 1 (the register) and step 3 · measures above · quarter.

## What would change this

A function whose analysts adopted notebooks without these rules and
whose models were re-run a year later by a second analyst to the same
results on the same definitions. If found, the governance is a cost and
the launch should be lighter.

Block 5 — intraday-automation-expansion.md

<!-- Derived from [[Expanding Intraday Automation]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Expanding intraday automation

From pockets to a layer, in an order set by how well the work is
specified, never by what the platform can do.

## Step one: the rule inventory

| Field | Holds |
|---|---|
| Rule | What it does, one sentence |
| Trigger | Signal, threshold, and which system's definition of the signal |
| Action class | Trigger · notify · offer · action (below) |
| Guardrail | The bounds inside which it acts without a person |
| Owner and metric | The seat, and the metric the rule is tied to; no orphaned automations |
| Acceptance rate | Share of offers accepted, where it offers; a low rate is a design signal |

Expect the pockets to disagree with each other and with the short-term
WFM engine about what a state is. That is the definitions problem in
the real-time layer; map every trigger to a register entry.

## The expansion order

| Class | The machine… | Admitted when the work is… | Evidence required |
|---|---|---|---|
| Trigger | Detects and records | Anything | A control chart separating special from common cause |
| Notify | Tells a named person with evidence attached | Documented to L1 (one-page flow) | The alert classes and escalation tree |
| Offer | Proposes; a person accepts or declines; a decline is a timing signal | Documented to L2 (step table) with the step's owner; not yet through the acceptance gate | An acceptance rate, published per rule |
| Action | Executes inside guardrails and writes back | Highly specified: L2 written before the interaction, L2 through the acceptance gate, step ownership and active-voice criteria met | A catch rate published for the class of action |

L1/L2 are the documentation levels of process decomposition (L0 cover
sheet · L1 flow · L2 step table · L3 job aids), not maturity levels.
The two acceptance-gate criteria that are the entry test for automation
are the criteria that admit work to the action class: the standards
committee's queue and the release list are one list.

## The catch-rate condition (state it; never name a level)

An action class is released when a catch rate has been published for
it: the proportion of known errors the routine verification detects,
where known errors are those seeded by deliberate error injection plus
those found by independent deep verification of a random sample;
reported per process per period with the injection rate and sample
size beside it. The wiki places gate-free execution at more than one
maturity level; take no position. Evidence releases the gate.

## The real-time team writes first

Where an agent team joins the day: monitor (interval variance records),
detector (breaches and patterns matched to events, a proposed
severity), issuer (incidents with evidence attached; event proposals
with effect windows; reoptimization proposals carried to the action
gate where a real-time analyst decides). That is trigger and notify by
agents, offer with a person at the gate; action waits for the catch
rate the gate's outcome record produces. Its first value is what it
writes: incidents that arrive with evidence, and the day's events
reaching the forecaster.

## Cross-node reallocation is placement

Moving supply between nodes (hub · service center · partner ·
automated) during the day is placement at the intraday horizon, not a
lever. The engine recomputes where supply should sit when a trigger
fires; intraday automation executes inside guardrails the constraint
register sets; the node owner decides; the function owns the method. A
move crossing a partner boundary is also a routing change under vendor
change control. Inside one node, the ordinary levers apply.

## The overseer

For every released class: the accountable person each rule's identity
resolves to; runs error injection and sampling; reviews the exception
queue; decides whether the class is still fit to run without a person.
Sized by exceptions and stakes, not rule count. Often the real-time
analyst who becomes the automation orchestrator.

## The sub-plan shell (SP) row

`SP-nnn` · Intraday · owner (the real-time standards seat; first
overseer per released class) · first three deliverables (inventory with
triggers mapped to register states; expansion order applied to every
rule; first action class released on a published catch rate) · depends
on build-order step 1 (state definitions) and step 4 (cross-node) ·
measures: acceptance rate per offering rule; catch rate per released
class with injection rate and n; days-to-detection · quarter.

## What would change this

An estate that released action classes on platform capability alone,
without catch rates or L2 documentation, and whose incident record over
a year shows no class of error the human check would have caught.

Block 6 — systems-administration.md

<!-- Derived from [[Systems Administration for WFM Platforms]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Systems administration as method

The platform executes the function's definitions; it never supplies
its own. Administration is the method that holds that true, whoever
staffs it (central team, planning seats, or partly the vendor).

## Configuration to the standard: nothing configured that is not in it

| Object | "One" means | Definition lives in | Two of them breaks |
|---|---|---|---|
| Activity-code set | Identical attributes per activity type across the estate (paid? available? which shrinkage category?) | The activity-code dictionary; the shrinkage entry | Cross-node shrinkage and occupancy |
| Skill and pool dictionary | One skill taxonomy with a mapping from each heritage's; pools indexed on work attributes, not reporting lines | The capability ontology; the object inventory | Fungibility; the engine's supply cards |
| Lock calendar | One forecast-lock and publication calendar with partner lead times, a year ahead, owned | The forecast lock process; the capacity cycle's pencils-down date | Two clocks per book; partners get two versions |

Everything else (shift templates, tolerances, bid rules) is derived
from the Standard's process sections, not administrator discretion.

## The change-control board owns configuration

Configuration changes are method changes in a technical coat. The board
(one of the four forums) decides; the administrator proposes and
executes; the log holds requester, assessment, authorization, schedule,
outcome. Two classes with their own rules: routing or allocation changes
touching a partner node (vendor change control); any book's migration
schedule (the largest configuration change in most quarters).

## The release calendar as an interface with IT

Three calendars collide: the vendor's releases, the technology
function's change windows and freezes, the planning function's locks
and peaks. Make the release calendar a named interface with an owner
on each side and a cadence; record releases and locks on the collision
calendar; a release changing a definition-bearing object is a board
item; a release in a freeze is declined with its price recorded; no
rollback, no release.

## Instance strategy: reconcile in place or build fresh

Prefer a fresh instance built to the Standard, for three reasons stated
as inference: (1) a book cannot move between instances without shared
definitions of gates, skills and pools, and building to the Standard is
how they become real; (2) activity types need identical attributes
before any cross-node report is reliable, and several inherited
configurations cannot be reconciled in place without becoming a fresh
configuration anyway; (3) the fresh instance stops re-fragmentation
once the standardization seat has finished migrating the largest book.
First book: a clean one already on the platform of record, never the
book in the middle of a migration.
Charter the instance as a program with a seat, a first-90-days list and
named dependencies (register; activity-code dictionary; release
calendar; the standards committee's first process documents).

## Access, audit, retention

- Access: least privilege by seat, granted for a purpose, reviewed on a
  cadence; the administrator's rights the most reviewed.
- Audit: the board's log joined to the platform's configuration history.
- Retention: the governance tiers (operational · analytical ·
  compliance) for schedules, forecast versions, state events;
  configuration versions kept for the life of the instance.

## Moving further books

Each further book by the book-migration runbook (CP-OPS-004): cleanest
first, the migrating book last; each move a board item; each move's
adapter rejection log is the administration backlog.

## The custodian

The administrator holds the three objects, executes board decisions,
keeps the release calendar with IT, runs the access review, and is the
first to notice a method change in disguise. The competency belongs on
every planning seat's role card; where held by a vendor, custody is
contracted and the board's authority written into the agreement.

## The sub-plan shell (SP) row

`SP-nnn` · Administration · owner (the program seat for the instance;
the board as configuration owner) · first three deliverables (the
configuration standard from the Standard's toolset section; the
activity-code dictionary v1 and the release calendar agreed; the first
clean book live) · depends on build-order step 1 and step 2 · measures:
method changes through the board (all); books on the instance by
quarter; access reviews on cadence; adapter rejections closed · quarter.

## What would change this

A multi-heritage estate that reconciled two or more instances in place,
under change control, and produced cross-node reports on one definition
within a planning year with no fresh instance.

Block 7 — integration-by-when.md

<!-- Derived from [[Technology Migration Plan for a Workforce Function]] and [[Placement Engine Build Path]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The integration-by-when table and the sub-plan shells

## The table

One row per technical crossing. The interface register (the
interconnection plan) holds owners on both sides; this table holds the
crossing and the date by which it reads the shared definitions. Every
date is a proposal [A] until the platform program confirms it; the
caption says so.

| Column | Rule |
|---|---|
| Integration | The crossing, named by the two components and what crosses |
| By | A date or a quarter; the worked example's, never an estate's, unless the estate has supplied one |
| Depends on | The build-order step, the register entry, or the prior integration that must exist first |

## The generic rows, in dependency order

| Integration | Depends on |
|---|---|
| The register read by the first report with lineage | Register v1 |
| The agent layer's file adapter reading and writing the short-term WFM engine's forecast file on one book | The book's ledgers; the planner gate on |
| The plan of record on the long-term capacity engine, iterating with finance | The headcount perimeter agreed with finance |
| Quality scores by node on one instrument version, into the data core | Instrument coverage on every channel; quality score paired with the customer-experience index, never blended |
| The capability ontology as the routing vocabulary, exercised by hand in the gate | Supply cards per pool |
| Simulation and notebooks feeding the gate's pooling-cost and coverage-floor tests | The plan of record on one core |
| A fresh instance of the short-term WFM engine live for its first (clean) book | The register; the activity-code dictionary; the migration schedule as a change-control item |
| The capability layer specified as a platform inside intraday automation | The ontology exercised by hand for two quarters |
| The capability layer hooked to routing on attributes | The platform build; the contact platform's constraint surface confirmed |

Rules: file adapters first at every boundary; an interface replaces a
file only where latency requires it (the daily forecast load does not).
A field that maps to no register entry is refused at the boundary and
logged; the rejection log is the definitional backlog.

## The sub-plan shell (SP)

| Column | Rule |
|---|---|
| ID | `SP-nnn` |
| Sub-plan | Engine · notebooks · intraday · administration |
| Owner (seat) | A seat, never a name |
| First three deliverables | Dated; each one an artifact, not an activity |
| Depends on (build-order step) | 1–4 |
| Measure | Counts the sub-plan produces; never headcount |
| Quarter | The example's, or the estate's if supplied |

## The engine shell

This pack opens the engine's shell only. The engine itself (constraint
register, gate tests, supply cards, recompute, build specification) is
built with CP-WFM-008. The shell's first three deliverables, generically:
register v1 with a hand-kept trigger log for one quarter; supply cards
for one book's pools; the six tests computed on one live question.
Depends on build-order step 1 for the register and ontology, step 3 for
the engine itself. Measures: counterfactuals recorded per gate run;
cannot-run results with a named input; decisions that went stale, from
the trigger log.

## Worked example rows [illustrative]

The source article's example places register v1 at the end of a
first-quarter front-load, the agent layer's forecast-file adapter on one
book at the ladder's beta rung, the plan of record on one core in the
following year's first cycle, and the fresh instance's first book about
five quarters after the planning week. Use the shape, not the dates.

Usage notes

Sizing. The instruction block is about 470 words; the six reference blocks total roughly 4,500 words, within a Claude project's knowledge budget with room for the estate's own component inventory and register as additional files.

Drift. Reference blocks are derived from the Source articles, not copied. When any Source article changes materially (the build order, the register's fields, the expansion order, the instance strategy), regenerate the affected block and increment the version.

Scope. The pack fills templates and states reasons. It selects no platform, decides no placement, releases no action class and builds no engine; each of those has its own pack or its own page.

Change history

Version	Date	Change
1.0	Sep 2026	First release

See also

• Planning Week for a Workforce Function
• Wiki:Packs
• Wiki:Packs/Placement Decision Engine Build — the engine the shell points at (CP-WFM-008)
• Wiki:Packs/Agent Capability Ontology — the ontology beside the register (CP-WFM-002)
• Wiki:Packs/Book Migration — the runbook for each book (CP-OPS-004)