Wiki:Packs/GRPI-T Instantiation

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 working sessions in which a planning room instantiates the five GRPI-T pillars: it produces the five pillar headlines, the goals sheet (T1), the RACI by horizon (T3) with the four forum cards, the interface cards (T5) with the scope table and the intake door, and the technology component cards (T6).

When to use it

Create a project from this pack when a working session is filling one of the pillar sheets during a planning week: the goals sheet on Day 1 afternoon, the RACI and forum cards on Day 2 morning, the interface cards on Day 3 morning, the component cards on Day 3 afternoon; or when a function owner fills the same sheets for one function in the service pack afterward. It is not for scoring maturity (the diagnostic does that), not for choosing an org option or writing role cards (Wiki:Packs/Organization Design and Role Cards), and not for running a placement question through the gate (Wiki:Packs/Placement Decision Engine Build).

How to deploy

1. Create a project in Claude named for the work, not the method.
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.

Block 1 — Project instructions

# GRPI-T Instantiation

## Context
This project supports the working sessions of a planning week in which a workforce management function turns the five GRPI-T pillars (Goals, Roles, Processes, Interpersonal and Interconnected, Technology) into filled sheets, each with a one-sentence headline, an owner as a seat, and permanent row identifiers. It produces the goals sheet (T1), the RACI by horizon (T3), interface cards (T5), technology component cards (T6) and the five headlines. It fills templates in the room's words; it does not score maturity or decide where work sits.

## Routing
| When the task is... | Open |
|---|---|
| writing or checking a pillar headline; deciding whether a sheet is "instantiated" | `pillar-headlines.md` |
| filling the goals sheet; testing whether a target may appear; pairing a quality score with a customer-experience index | `goals-sheet.md` |
| writing a RACI row; checking one accountable body per row; drafting a forum card; recording a decline with its price | `raci-by-horizon.md` |
| writing an interface card; the scope table; the intake door's six fields and the chain's six routes; the interim protocol; the continuity wire | `interface-cards.md` |
| writing a technology component card by category; the build order's dependency check | `component-cards.md` |

## Disciplines
- Work the pillars in order: Goals, Roles, Processes, Interconnected, Technology. When a sheet will not fill, look one pillar to the left.
- A headline has two clauses (today; at the standard's expiry) and a grade on the first only: Established, Inferred, Asserted or Open.
- Goals are sentences; a target is a number and appears only where the instrument can detect the difference it asks for.
- The quality score and the customer-experience index are paired, never averaged. Targets vary by service tier, never by location.
- Every RACI row has exactly one A, under the printed first rule: the function is accountable for the method and responsible for the advice; the node owner is accountable for the decision, and a decline is legitimate and recorded with its price as routine.
- An interface exists only with an owner on both sides (as seats), a cadence on the other department's clock, and a named shared definition.
- Owners are seats, never names. Numbers carry [M] [C] [E] [A]; estate figures are ranges; example figures are examples.
- Platforms by category (long-term capacity engine, short-term WFM engine, intraday automation, Python analytics platform, reporting platform), never by product.
- The current state is written as what exists, correct for the business that built it, and what it becomes.

## Output
A filled row or card in a Markdown table with the template's columns in order and a permanent ID (`G-`, `RACI-`, `I-`, `TC-`), then one line giving the grade of any claim and the assumption behind any estimate. Refuse: a headcount or seat count; a person's name against a seat; a placement decision; a maturity level as a point.

Source: Wiki:Packs/GRPI-T Instantiation (CP-WFM-013) v1.0

Block 2 — pillar-headlines.md

<!-- Derived from [[Instantiating the GRPI-T Framework]] and [[GRPI-T Framework]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Pillar headlines

## What "instantiated" means
A pillar is instantiated when three things exist: a **headline**, a **sheet** and an **owner**.

| Element | Test | Fails when |
|---|---|---|
| Headline | one sentence: the pillar today (graded), then the pillar at the standard's expiry (a commitment, no grade) | it is a slogan; it states a maturity level as a point; it describes what was neglected |
| Sheet | the filled template for the pillar with an ID on every row | rows lack IDs; cells are filled from memory when the source is in the room |
| Owner | a seat that holds the sheet after the week and brings it to the validation circuit | the owner is a team, a name, or "the function" |

Instantiation is not scoring. The diagnostic's rules (median as routing key; position as a pair; drag as a pillar two or more levels below the median) live on the GRPI-T Framework page and are not applied here.

## The order and the templates
| Block | Pillar | Template | Decision |
|---|---|---|---|
| Day 1 afternoon | Goals | T1 goals sheet | D-02 goal frame |
| Day 2 morning | Roles | T2 role cards; T3 RACI; the org option with sunset conditions | D-03, D-04, D-05 |
| Day 2 afternoon | Processes | T4 L0 cards as shells; the function catalog | D-06, D-07, D-08 |
| Day 3 morning | Interpersonal and Interconnected | T5 interface cards; the scope table; the intake door | D-09, D-10 |
| Day 3 afternoon | Technology | T6 component cards; the build order | none of its own |
| Day 4 morning | all five read back | the standard's §1 | D-11 |

## The "one pillar to the left" rule, as questions
When a sheet will not fill, do not press on the sheet. Ask the question for the pillar to its left.

| Symptom | Ask about | Usually missing |
|---|---|---|
| a role card cannot state accountability | Goals | an agreed ordering of objectives |
| the catalog argues about who owns a process | Roles | an owner for the definitions the process depends on |
| an interface card cannot name what flows | Processes | the process that would produce the flow, written down with a cadence |
| the technology sheet lists a platform before a definition | Interconnected | an owner on the function's side for the interface that carries the definition |

## Headline form
`<Pillar>: <today, one clause> (<grade>); by <standard expiry> <one clause>.`

Example (from the worked example; illustrative): *Goals: goals exist per metric and are not weighed against each other (Established); by the standard's expiry the function holds one goal frame across four categories with the trade-offs written on the sheet.*

## Rules
- Never a maturity level as a point; a band if a level is mentioned at all.
- The Interpersonal half gets its own clause; an unassessed half is named as Open, not omitted.
- Headlines are written after the sheet, in the room's words, and marked as the room's.
- "Level" is ambiguous on the wiki: four scales use the word, and Planning Week for a Workforce Function states which is which. Say which one is meant every time; a headline uses the maturity levels by canonical name.

Block 3 — goals-sheet.md

<!-- Derived from [[Instantiating the GRPI-T Framework]], [[WFM Goals]] and [[Quality Score and Customer Experience Index]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Goals sheet (T1)

## Columns, in order
`ID (G-nnn) · Horizon · Category · Goal (a sentence) · Measure · Instrument today · Level · Owner (shared or function) · Paired with`

## The four categories
Customer experience · cost · employee experience · risk (flexibility counted as a risk objective). Compliance is a constraint, not a goal: a constraint excludes; a goal is weighed. The practice page's five categories (service quality, efficiency, employee experience, customer experience, compliance) collapse to these four for planning.

## Horizons as rows
| Horizon | Placement object at that horizon |
|---|---|
| 12–36 months | network and supply-seat design |
| annual | the objectives themselves; the budget envelope |
| quarterly / monthly | allocation and clearing |
| weekly / daily | the forecast lock; the schedule of record |
| intraday / real time | steering within rules |
| intake events (any horizon) | a new client; a product change |

## Rules the sheet enforces
1. **Goals, not targets.** A target appears only where a source carries it *and* the instrument can detect the difference it asks for. Otherwise the cell reads "no target until <instrument>".
2. **Weights per node, with a body-of-work override** recorded in the constraint register, not on the sheet.
3. **Value as the unit; two sides never blended.** The quality score (a process and behavior measure) and the customer-experience index (an outcome) are paired in the last column and never averaged.
4. **Targets by service tier, never by location.** A target that varies by location has silently decided placement.
5. **The level column** records where the measure belongs on the maturity ladder (by canonical name: Initial, Foundational, Progressive, Advanced, Pioneering), not where the estate is. Measures at Level 4 are the engine's; mark them so the room does not commit to instruments it cannot run.
6. **Owner** is "shared: node owner and function" for outcomes, "function" for method measures.

## The seven-question check for any new measure
Who owns it · what decision it changes · what instrument produces it · at what resolution · how it is gamed · what it is paired with · when it expires. A measure that fails any question is not added.

## Example row (illustrative)
| ID | Horizon | Category | Goal | Measure | Instrument today | Level | Owner | Paired with |
|---|---|---|---|---|---|---|---|---|
| G-001 | quarterly / monthly | CX | the customer-experience index held at parity across nodes at matched tenure | CX index by node, matched tenure | index designed; live at one node [estimated] | 3 | shared: node owner and function | cost per unit of value; the quality score (never blended) |

## Common failures
- A target copied from a heritage's scorecard without its instrument.
- A blended "quality" number that averages the score and the index.
- Weights set per body of work for every book, which multiplies the objectives register beyond what budget season can set.
- A goal row with no owner, which is a report line, not a goal.

Block 4 — raci-by-horizon.md

<!-- Derived from [[Decision Rights by Planning Horizon]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# RACI by horizon (T3) and forum cards

## The first rule (print above every table)
**The function is accountable for the method and responsible for the advice; the node owner is accountable for the decision.** The node owner is the owner of the body of work placed at a node, never the operator of the node.

## Columns, in order
`ID (RACI-nnn) · Horizon · Decision domain · Function · Node owner · Commercial · Finance · Change-control board · Record kept`

Bodies: the function (method) · node owners (decision) · commercial (the pen on offers) · finance (the envelope) · the change-control board (routing, platform configuration, contract changes).

## The ten domains (draft rows; the room amends)
| ID | Horizon | Domain | Function | Node owner | Commercial | Finance | CCB | Record kept |
|---|---|---|---|---|---|---|---|---|
| RACI-001 | quarterly / monthly | moves and requisitions at lock-and-decide | R | A | I | C | I | plan of record; decision record with the binding constraint named |
| RACI-002 | 12–36 months | network and supply-seat design | R | A | C | C | I | the landscape; the counterfactual record |
| RACI-003 | annual | the objectives register's order and dials | R | A (outcome owners jointly) | C | C | I | the register, reordered with a signature |
| RACI-004 | annual | the budget envelope by node | R | C | C | A | I | plan of record reconciled to budget |
| RACI-005 | annual | partner renewals on the shared instrument | R | C | A | C | C | the contract; the renewal calendar as a constraint entry |
| RACI-006 | weekly / daily | forecast lock; schedule of record | A (method) / R (output) | C | I | I | I | lock calendar; forecast vintage |
| RACI-007 | intraday / real time | steering within rules | A (rules) / R (actions) | C | I | I | I | incident and event ledgers; catch rate |
| RACI-008 | any | routing, platform configuration, contracts, migration schedule | R | C | C | I | A | change log; confirmation |
| RACI-009 | any | the standard, principles, definitions register | A as convener of the council, which approves | C | C | C | R (change control) | change history; register versions |
| RACI-010 | any (intake) | a placement question through the gate | R | A | C where an offer binds | C where a price is paid | I | gate output page; counterfactual record |

## Checks before a row is accepted
- Exactly one A. A row with two is two rows: split it (RACI-003 and RACI-004 are the usual pair).
- "Record kept" filled. A right without a record will be argued next month.
- The function's A cells are always method (a calendar, a rule set, a standard), never an operational outcome.

## Declines
A decline is legitimate. Record it with its price, **as routine**, in the counterfactual record: the proposal's cost or saving (graded), what the owner decided instead, the reason in the owner's words. A record kept on request has gaps exactly where the cost of not moving is highest.

## Forum card fields
`Forum · Scope · Participants (as seats) · Cadence · Critical success factor`

| Forum | Scope | Cadence | Critical success factor |
|---|---|---|---|
| Placement forum (= lock-and-decide) | signs or declines the month's moves, requisitions and gate pages | monthly after pencils-down; on intake events | the counterfactual record exists whether or not the proposal is taken |
| Council | approves the standard, principles, definitions register, objectives order | monthly | one standard, one vocabulary; nothing published without owner and expiry |
| Change-control board | routing, platform configuration, contracts, migration schedule, collisions | monthly; on request for a migration event | no one changes the method without the board |
| Budget season | sets the dials; the envelope by node | annual; quarterly checkpoints | the dials are set, not inherited |

Four forums, not more. The placement forum is a stage of the capacity cycle, not a separate meeting. Participants come from the role cards' forums field; a forum with no card behind it will not sit.

Block 5 — interface-cards.md

<!-- Derived from [[Enterprise Interconnection Plan]] and [[Interconnected Workforce Management]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Interface cards (T5), the scope table and the intake door

## Interface card columns, in order
`ID (I-nnn) · Interface · Owner, function side (seat) · Owner, their side (seat) · Flows in · Flows out · Cadence (their clock) · Shared definition · Failure when unowned · State today (graded)`

## Existence test
An interface exists only with all three: an owner on each side, in both role descriptions; a cadence on a clock the other department already keeps; a shared definition, named. Definitional work is interconnection done in advance.

## The rows
Eleven peer interfaces: operations (the customer) · finance · talent acquisition · training · human resources · technology · commercial · product · delivery partners · quality · continuity and crisis (the wire). Plus one horizon interface where it applies: **long-range capacity planning held in another organization**.

The four binding rows get owners on both sides in the room: finance · talent acquisition · product · delivery partners (a fifth, long-range planning, where it is held elsewhere). The rest are assigned in the service pack, with a date.

## The hardwired horizon row
| Field | Content |
|---|---|
| Object crossing it | the plan of record: the long-range plan flows in as the constraint; the mid-term forecast, surplus/deficit view and delivered-hours actuals flow back |
| Cadence | the capacity cycle's business-day milestones, not on request |
| Shared definitions | the headcount perimeter; the productive-hour denominator; ramp |
| Owner, function side | the portfolio planning seat per book |
| Owner, their side | the seat that signs the long-range plan |
| Failure when unowned | two plans of record, one hired to and one scheduled to |
Treat it as first-class, never as an exception.

## The scope table (agree before naming owners)
| Row | Content |
|---|---|
| In scope | forecast and schedule; real-time automation and incident management; work placement (engine, gate, registers, counterfactual record); the instrument and comparison key; the methodology for every calculation |
| Wired, not owned | the eleven peers and the horizon row |
| Owned by operations | every placement decision; daily partner performance for their node |
| Out of scope | the in-house nodes' own operating model; the commercial pen on partner contracts; continuity and crisis as functions |

## The intake door
Six fields: the question in one sentence · the decision it feeds · who decides · when it is needed · what data exists · what done looks like. If the requester cannot state the decision, it is a data pull. The six fields are The Question Register and Knowledge Base's, in that page's own words. Its routing carries **five** classes — planning request · performance question · data pull · event · definitions question — and **no placement route**. This plan keeps four of the five, sends a definitions question to the data pull's destination, and adds two of its own: the process-standard request and the placement question. The six routes below are therefore this chain's construction on those five. Never write "six routes" as something the wiki says; it appears on no live page.

| Route | Goes to | Returns |
|---|---|---|
| planning request | the capacity cycle, or the portfolio seat between cycles | a plan or scenario with its assumption register |
| performance question | executive issue register row; hypothesis table; 48-hour readout | an answer-first card with its grade |
| data pull | the definitions register; the queue | the number with its definition cited |
| event | the event ledger | an effect window on the forecast |
| process-standard request | the standards committee's queue | an authoring slot or a deferral with reason |
| placement question | the gate (six tests, five outcomes) | the one-page output with the counterfactual; the forum signs or declines |

## The interim protocol
One intake · 48-hour readout · acceptance gate (the owner signs or declines on the record), until the engine runs. It becomes the placement forum's intake and readout rules between sittings.

## The continuity wire
Trigger: a severity 1 or 2 incident notifies continuity with the standard incident record's fields. Products: the continuity plan's capacity assumptions return to the cycle annually; the crisis re-plan and placement under duress are function products continuity consumes. Recommend trigger and product, never authority: the node owner keeps the decision under duress. Say in one line that Integrated Global Resource Optimization Center and Role Evolution in the Resource Optimization Center currently house continuity inside the center and that this is the change D-10 proposes. If the wire's authority is settled above the function, the decision leaves the list and the count is fifteen.

## Example row (illustrative)
| I-001 | Talent acquisition | portfolio planning seat; cycle calendar's owner | TA lead's seat | pipeline state; time to fill; labor-market view | requisitions with start dates from the plan after clearing; skill profile per hire | weekly pipeline; monthly batch after BD+7 | time to fill and time to proficiency as separate quantities | requisitions open before surpluses elsewhere are checked | personal and undocumented (Established) |

Block 6 — component-cards.md

<!-- Derived from [[Technology Migration Plan for a Workforce Function]] and [[Instantiating the GRPI-T Framework]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Technology component cards (T6)

## Columns, in order
`ID (TC-nnn) · Component (category) · Horizon · What it does · System of record for · Definitions it must read · State today · Lights at level · Product (annex only) · Integration and date · Program`

## Categories, never products
Name every component by its category. The five phrases: **long-term capacity engine** · **short-term WFM engine** (forecasting and scheduling) · **intraday automation** · **Python analytics platform** (the reporting platform's notebook component) · **reporting platform**. Further categories: the system of record and the simulation engine as two arms of long-range planning; the capability layer (an ontology on paper first, a platform later); quality; the routing platform; the data core; the agent layer. A product name goes in the annex column only, and only where the wiki already carries a page for it.

## The Technology pillar is filled last
Fill the card only after the Goals, Roles, Processes and Interconnected sheets exist. The "Definitions it must read" column is filled from the definitions register and the interface cards; a component whose definitions column is empty has been specified before its definitions, which is the fifth-pillar symptom the "one pillar to the left" rule catches.

## The build order (a dependency check, not a room decision)
1. Definitions and the ontology on paper.
2. The plan of record on one instance of the short-term WFM engine and one long-term capacity engine.
3. Simulation and the Python analytics platform together.
4. The capability platform last.
A card whose "Integration and date" precedes the step it depends on is returned.

## Rules
- "Lights at level" records the maturity level at which the component earns its place, by canonical name; the ontology may light at one level and its platform at another.
- "State today" is graded and framed as what exists (spreadsheets and decks are a state, not a failure).
- "Program" names the program charter (`PG-nnn`) that owns the component's integration; a component with no program is a purchase without an owner.
- Exhaust the core before buying a tool: a card proposing a new product must state what the existing core cannot do, with the definition it lacks.

## Example row (illustrative)
| TC-001 | capability layer (ontology, then platform) | real time | who can do what: eligibility, proficiency, entitlement; routes supply, not demand | the capability record | the six core definitions, ramp included; the pool and skill dictionaries | ontology on paper [estimated: first quarter after the week] | ontology at Level 2–3; platform at Level 5 | annex | the routing vocabulary first; hooked to routing later | the capability program |

Usage notes

Sizing: the instruction block is just under 500 words and loads with every message; the five reference blocks are 450–800 words each and are read on demand through the routing table. Drift: the blocks are derived from the six source articles, not copied; regenerate them and increment the version when any source article changes materially. Scope: the pack fills templates and checks them against the rules; it does not carry the worked example's figures as facts, and it refuses a headcount, a name against a seat, and a placement decision.

Change history

Version	Date	Change
1.0	2026-09	First release

See also

• Planning Week for a Workforce Function
• Wiki:Packs
• Wiki:Packs/Organization Design and Role Cards
• Wiki:Packs/Executive Issue Register