Wiki:Packs/Forecasting Processes

A deployable Claude project setup for localizing the six generic process cards of the forecasting pillar into one workforce function's standard: the annual strategic planning cycle, the monthly capacity planning cycle, the weekly rolling reforecast, the intraday reforecast, supply and attrition forecasting, and forecast accuracy governance. Each card is carried as a reference file condensed from its wiki page, with its profile, L1 flow, L2 rows, variant classes, L3 register and ranked automation candidates; a shared rules file holds the SET LOCALLY mark, the variant test, the tier vocabulary, the number grades and the catch-rate release rule. The pack produces, per card, the function's own L0 cover with its profile settled, its L1 flow with owning seats, its L2 step table, its L3 register and its variant rows. Copy Block 1 into a project's custom instructions; save Blocks 2–8 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function has a catalog row for a forecasting process and must turn the generic card into its own documented, certifiable process: on the day a section of its standard is due, when a certifier asks for the L2 of a process the function runs, or when a region or predecessor organization's version of the process has to be reconciled with the standard as variants rather than as a second copy. It is not for building the forecast itself, for choosing a forecasting method, or for writing a card the wiki does not carry; and it does not decide what the function's processes are, which is Wiki:Packs/Process Inventory and Shell Catalog (CP-OPS-008). Wiki:Packs/Process Decomposition (CP-OPS-001) is the engine: its fifteen-column L2 table, its L0 form and its shell marks are what this pack's output is written into. This pack carries the cards. Sibling packs carry the other pillars: CP-OPS-010 scheduling, CP-OPS-011 real-time, CP-OPS-012 work placement, CP-OPS-013 the continuity interface, CP-OPS-014 cross-cutting governance.

How to deploy

1. Create a project in Claude named for the function's work, not the method: "Forecasting section localization", not "Process cards".
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload it as project knowledge.
4. Start a conversation naming the card (GP-101 to GP-106), with the function's catalog row for it and, for GP-102 and GP-104, the method page or the function's own copy of the L1 and L2.

Block 1 — Project instructions

You are localizing generic process cards for the forecasting pillar of a
workforce function's standard. The pillar's six cards are in the reference
files; `localization-rules.md` holds the conventions. The cards are generic:
every threshold, calendar, approver and system name is marked SET LOCALLY,
and the deploying function supplies those values on its own L0 and L3.
GP-102 and GP-104 defer their L1 and L2 to method pages; the user brings
those pages or the function's own copy. Three shelf pages are methods the
user may bring, not cards to decompose: Three-Step Forecast Build, Forecast
Lock Process and Forecast Collision Calendar.

Routing: open the file for the task.

| Task | File |
|---|---|
| Any card: profile rows, the variant test, tiers, grades, releases | `localization-rules.md` |
| The annual envelope, scenario set, budget submission, posture, long-range lock | `gp-101-annual-strategic-workforce-planning-cycle.md` |
| The monthly refresh, clearing, plan-of-record lock | `gp-102-monthly-capacity-planning-cycle.md` |
| The weekly refresh inside the locked month, the planner gate, the hand-off | `gp-103-weekly-rolling-reforecast.md` |
| The same-day revision on a trigger, the hold decision, the ROC hand-off | `gp-104-intraday-reforecast.md` |
| The roster roll-forward, attrition by cohort, ramp, the supply vintage | `gp-105-supply-and-attrition-forecasting.md` |
| Scoring, the stairstep, bias, corrective action, release and withdrawal | `gp-106-forecast-accuracy-governance.md` |

For the card the user names, in this order:

1. Read its profile with the user and settle each row as `true as written`,
   `SET LOCALLY: <value>` or `variant: <class>`.
2. Walk the L1 one step at a time, confirming the owning seat per step.
3. Expand the L2 rows into the function's own fifteen-column table
   (CP-OPS-001 `framework.md`), filling owner, ticketing code, notification,
   approver and duration. For GP-102 and GP-104 copy the method page's rows
   and fill the columns the card file names.
4. Run the variant test on every local difference and write the variant rows.
5. Carry the automation candidates over unchanged, in the card's rank order,
   and ask for the function's catch-rate evidence per class before marking
   any as released.
6. Emit `L0-cover.md` (identity + profile), `L1-flow.md`,
   `L2-step-decomposition.md`, `L3-register.md` and `variants.md`.

Disciplines:
- Never fill a local value the user has not given; leave the mark and seat.
- Never name a product or platform in any file marked for publication.
- Two owners on one step, a decision with no decider, a job aid that does not
  exist: a finding, in its own section, never a footnote.
- Seats, never names. Tier vocabulary only: tiers 1 to 4, executive sponsor
  by exception.
- Every number keeps its grade; every number the user adds gets one.
- A lock, a signature and a gate decision are never candidates; a step the
  card marks "never a candidate" stays human.
- The month's total belongs to GP-102 and the mid-term door; a weekly or
  intraday step that would change it raises a variance, never an edit.
- Scores go to GP-106; the measure set is SET LOCALLY per horizon and client
  portfolio, never invented.
- One card per conversation.

Output: the five Markdown files, each headed with the card id, the local card
id, version and date; a findings section listing every unresolved SET
LOCALLY, every variant row awaiting approval and every ownership conflict;
every automation candidate marked `flagged` or `released on evidence:
<reference>`. Refuse to localize a process the function has not described,
to set a local value by inference, or to publish a file that names a
platform.

Source: Wiki:Packs/Forecasting Processes (CP-OPS-009) v1.0

Block 2 — localization-rules.md

<!-- Derived from [[Standard and Variant in Process Documentation]], [[Decision Authority Tiers in Workforce Operations]], [[Human Gates and Number Grades]] and [[Process Shells for a Workforce Standard]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Localization Rules

The conventions every card file in this pack follows and every localized
artifact must keep. Read before the first card.

## 1. SET LOCALLY

A generic step never carries a threshold, a calendar, a system name, a
notification value or a named approver. Where the step needs one, the row
reads `SET LOCALLY — <seat>`: a value exists, it is local, and the seat named
holds it. The deploying function fills it on its own L0 and L3, never on the
generic card.

- A profile row settled with the user reads exactly one of `true as written`,
  `SET LOCALLY: <value>` or `variant: <class>`.
- Never fill a SET LOCALLY value the user has not given; leave the mark and
  its seat.
- A local value changes nothing above it. Trigger, scope, class and authority
  tier are the card's; changing any of those reopens L0 approval. A local
  value does not.
- Platforms are named at L3 and in the user's own artifacts only, never in a
  file marked for publication.

## 2. The variant test (ask in order, for every local difference)

1. Does the generic step fail here, or does the site prefer another way?
   Preference is not admitted.
2. Can the difference be expressed as a parameter of the generic step (a
   threshold, a calendar, an approver tier)? Then it is SET LOCALLY and takes
   no variant row.
3. If a different step is needed, does it change the step's owner, its inputs
   or outputs, or its position in the flow? Only then is it a variant.
   Otherwise it is an L3 work-instruction difference, held in the local job
   aid.
4. What would retire it? Every row names its retirement condition, even "the
   statute changes".

The test is asymmetric by design: a parameter is cheap; a variant is a branch
that every automation rule must carry and the overseer must verify separately.

## 3. The four variant classes

| Class | What it is | Approver | Expiry or review |
|---|---|---|---|
| statutory | law or regulation in a jurisdiction | function head (tier 4), on legal advice | review date |
| contractual | a client contract or a collective agreement | placement and vendor lead (a tier 3 seat of the placement pillar) | reviewed at renewal |
| structural | a site, platform or channel that cannot run the generic step | the process owner, at that seat's tier | review date |
| transitional | a predecessor organization's way, kept until a dated cut-over | the standards committee | expires; the date is mandatory |

A variant row carries: `V-nnn` · process and steps modified · scope (as
classes where published outside the function) · class · the difference, in
the same active voice and ownership form as the generic step · owner seat ·
approved by and date · expiry or review · automation effect (`blocks` ·
`parameterizes` · `none`).

## 4. Authority tiers (write only these)

| Tier | Seat | Signs |
|---|---|---|
| 1 | the pillar's analyst seat inside guardrails (scheduler, forecaster, real-time analyst, placement analyst) | actions inside published guardrails; no approval sought |
| 2 | supervisor or team lead | actions the guardrails exclude, on the analyst's recommendation; minor L2 and L3 changes |
| 3 | operations manager or ROC duty lead | actions that cross a queue, skill, site or supply node; incident ownership at the top severity rows |
| 4 | function head | the lock, the plan of record, build parameters, a statutory variant, a version of the standard |
| exception | executive sponsor | a gap outside the band the plan can absorb; one client's service traded against another's; a change to the standard's scope |

A seat may take a lower tier's decision, never a higher tier's. Never write
"planner tier"; never make a board or a committee a tier. Where the decision
belongs to a supply-node owner under the decision-rights table, write
"advice at tier n; decision per the decision-rights table".

## 5. Number grades

Every number carries a bracket: `[M]` measured · `[C]` computed · `[E]`
estimated · `[A]` asserted. A computed figure is never better than its weakest
input. Nothing carried across a platform, channel or cohort change is [M] in
the new state; it is [A] until measured there. An [A] figure may inform a
proposal but may not by itself carry a plan. Prefer "typically" + [A] over
invented precision. Keep every grade the card carries; give every number the
user supplies a grade.

## 6. One owner per step

Each L1 step and each L2 row has exactly one owning seat; seats, never names.
Where a card writes two seats ("scheduler; capacity planner"), the first owns
and the second contributes; confirm this with the user. Two seats claiming one
step, a decision with no decider, or a named job aid that does not exist is a
finding, reported in its own section. Decision steps are questions.

## 7. The catch-rate release rule

An automation candidate is flagged at L2 (at L1 on a deferring card). It is
released per class of action on a published catch rate: the proportion of
the rule's known errors that the verification step detects, published per
class and per variant, never per process and never on a maturity label. A
rule is released into the tier of the seat whose decision it replaces, never
above it. Release order: the generic step first; then each variant whose
automation effect reads `parameterizes`; never a variant whose effect reads
`blocks` until it is retired or the rule rewritten. Carry the card's ranked
list over unchanged; ask for the function's catch-rate evidence per class
before marking any candidate released; a candidate without evidence stays
`flagged`. A step the card names as never a candidate stays human in every
localization.

## 8. Vocabulary

Class: strategic · real-time · both · supporting. L3 forms: work instruction ·
playbook · runbook. Lifecycle status: `Shell` · `1.1 approved` · `1.2
authoring` · `1.3 in peer review` · `2.1 submitted` · `2.1 approved` · `2.1
conditionally approved` · `2.1 not approved` · `2.2 deploying` · `Live` ·
`3.1 under review` · `Certified L<n>` · `Expired`. Dates as "Thu 16 Oct 2026".
Write "client portfolio" for a set of client contracts, "supply node" for a
site, partner or platform that supplies capacity, and "predecessor
organization" for an organization absorbed by merger or acquisition.

Block 3 — gp-101-annual-strategic-workforce-planning-cycle.md

<!-- Derived from [[Annual Strategic Workforce Planning Cycle (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-101 Annual Strategic Workforce Planning Cycle

Once a year the enterprise plan becomes a long-range demand envelope, a
supply posture, a hiring plan and a budget submission, locked as the
baseline plan of record GP-102 refreshes inside. Sequence rule: volume
forecast, then headcount model, then budget, then hiring authorization.
Not restated: Strategic Workforce Planning; Workforce Planning Calendar and
Annual Planning Cycle; Three-Step Forecast Build (the long-range step);
Forecast Lock Process (the long-range lock is the budget submission).

## Profile
| Field | Generic value |
|---|---|
| Card | GP-101 · local id by the standards committee |
| Class | strategic; the annual row of Decision Rights by Planning Horizon |
| Trigger | finance publishes the budget timetable, months before the fiscal year (SET LOCALLY; nine to twelve typical [A]) |
| Cadence | annual; quarterly checkpoints may reopen named assumptions; horizon beyond the fiscal year (SET LOCALLY; twelve to thirty-six months typical [A]) |
| Scope in | demand envelope by month and client portfolio; supply posture (supply nodes, sourcing mix, partner seats); hiring plan and class calendar; scenario set; budget submission; lock calendar; baseline plan of record |
| Scope out | the monthly refresh (GP-102); the forecasting method; a single placement decision (GP-401); recruiting after a class is authorized; the schedule bid |
| Inputs | enterprise plan and drivers; last year's envelope and variance; long-horizon supply forecast (GP-105); collision calendar; finance's guidance; network design; definitions register |
| Outputs | signed envelope (volume, handle time, shrinkage, staffing by month and client portfolio); approved headcount; hiring plan with class dates; posture; scenario register; lock calendar; baseline plan of record |
| Upstream | enterprise strategy and finance; placement (network design, constraint register); human resources; the supply forecast |
| Downstream | the monthly cycle; recruiting; training; finance; placement; scheduling |
| Resources | long-range capacity model; roster of record; scenario set; committee calendar; finance's format; platforms at L3 only |
| Decision points | inside finance's guidance? which scenario is plan of record? add or exit a supply node? approved, cut or returned? quarterly variance beyond the band? |
| Authority tier | tier 1 forecaster and planner inside the cycle calendar; tier 2 the owning planner signs each client-portfolio input; tier 4 function head signs plan case, posture, budget and the envelope lock; executive sponsor by exception for a supply node added or exited and the budget approval itself |
| Risk and compliance flags | headcount binds for a year; a site decision carries consultation duties; a hiring or reduction plan may go before a works council; partner seats bind under contract; an [A] attrition rate enters only with a range or a tier-4 logged acceptance |
| Variant-prone steps | fiscal calendar offsets; consultation; partner notice periods; finance's format |
| Automation candidates | four L2 sub-steps (four ranks) |

## L1 flow (owner seat per step; offsets SET LOCALLY)
1. Publish the cycle calendar, owners, partner deadlines, lock calendar — standardization lead
2. Score last year's envelope against actuals by layer; log lessons — forecaster
3. Collect the enterprise-plan drivers from business partners by the deadline — planner
4. Build the long-range demand envelope by month and client portfolio — forecaster
5. Roll supply forward on the long horizon through GP-105 — supply planner
6. Compute the staffing requirement and gross hiring need by class, ramp-adjusted — planner
7. Decision: requirement inside finance's guidance? No → step 8 adds a reduction case — planner
8. Build the scenario set: conservative, plan, stressed, plus any reduction case — planner
9. Choose the plan case with a stated reason — function head
10. Set the posture from the placement lead's proposal. Decision: add or exit a supply node? Yes → executive sponsor; no → function head — function head
11. Decision: does any jurisdiction require consultation first? Yes → run it; no → record none — works-council liaison
12. Sign and submit the budget in finance's format — function head
13. Decision: approved as requested? Cut or returned → re-run 6 to 10 inside the approved envelope, one iteration (SET LOCALLY) — planner
14. Sign the long-range lock on the planners' signed inputs; stamp the vintage; publish the baseline plan of record — function head
15. Quarterly: compare year-to-date with the envelope. Decision: variance beyond the band (SET LOCALLY)? Yes → variance on the long-range lock; no → note — planner

## L2 step table (durations typical business days [A], SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Publish calendar, owners, deadlines | standardization lead | finance's timetable | cycle calendar | 2 BD | N | cycle calendar |
| 2 | 2.1 Score last year's envelope by layer | forecaster | last vintage, actuals | scoring sheet, lesson log | 3 BD | Y | prior-year scoring template |
| 3 | 3.1 Collect and grade drivers; enter events on the collision calendar | planner | partner submissions | graded driver list | 10 BD | N | driver intake form |
| 4 | 4.1 Run the long-range baseline | forecaster | driver list, history | baseline | 3 BD | N | long-range build instruction |
| 4 | 4.2 Apply driver and event adjustments with reasons | forecaster | baseline, calendar | envelope draft | 2 BD | N | long-range build instruction |
| 5 | 5.1 Call the supply roll-forward | supply planner | roster, curves | supply vintage | 3 BD | Y | GP-105 hand-off |
| 6 | 6.1 Compute requirement and hiring need | planner | envelope, vintage, register | requirement table | 2 BD | Y | requirement computation instruction |
| 7 | 7.1 Test against guidance; flag a reduction case | planner | table, guidance | inside or outside; flag | 1 BD | N | envelope test |
| 8 | 8.1 Assemble the scenario set | planner | envelope, levers, flag | scenario register | 3 BD | Y | scenario register layout |
| 9 | 9.1 Choose the plan case with reason | function head | scenario register | plan case | 1 BD | N | scenario register layout |
| 10 | 10.1 Propose supply node and seat changes | placement lead | gap, constraint register | posture proposal | 5 BD | N | posture proposal template |
| 10 | 10.2 Decide the posture; route an add or exit upward | function head | proposal | posture; escalation | 2 BD | N | posture proposal template |
| 11 | 11.1 Run consultation where required | works-council liaison | hiring or reduction plan | consultation record | SET LOCALLY | N | consultation pack |
| 12 | 12.1 Assemble the submission | planner | requirement, posture, plan case | submission pack | 3 BD | N | budget submission pack |
| 12 | 12.2 Sign and submit | function head | submission pack | signed submission | 1 BD | N | budget submission pack |
| 13 | 13.1 Record the decision; open a re-run if cut | planner | finance's decision | approved envelope | 1 BD | N | budget submission pack |
| 14 | 14.1 Sign the envelope lock; stamp the vintage | function head | approved envelope, signed inputs | locked vintage | 1 BD | N | lock pack |
| 14 | 14.2 Publish the plan of record | standardization lead | locked vintage | baseline plan of record | 1 BD | N | lock pack |
| 15 | 15.1 Test year-to-date against the band; raise a variance if breached | planner | actuals, envelope | checkpoint note; variance | 2 BD | N | quarterly checkpoint template |

## Variants
- Statutory: works-council consultation before a hiring plan, reduction or site change → row at step 11, owner works-council liaison, approver function head; a submission record-keeping period is a parameter, SET LOCALLY.
- Contractual: partner notice periods and minimum commitments enter through the constraint register → SET LOCALLY, no row.
- Structural: a unit with no long-range model (spreadsheet envelope) varies step 4 under a row reviewed each cycle; a different fiscal year changes only the offsets.
- Transitional: a predecessor-organization unit on its own budget cycle keeps a row until its first shared fiscal year, dated by the standards committee; automation effect `blocks` ranks 1 and 3.

## L3 register (variance band and re-run count SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| Cycle calendar: fiscal offsets, owners, partner deadlines | 1, 14 | work instruction |
| Driver intake form and grading rule | 3 | work instruction |
| Prior-year scoring template and lesson log | 2 | work instruction |
| Long-range build instruction (engine, resolution, reasons) | 4 | work instruction; Three-Step Forecast Build |
| Requirement and hiring-need computation | 6 | work instruction; Capacity Planning Methods |
| Scenario register and choice record | 8, 9 | playbook; Scenario Planning and Contingency Staffing |
| Posture proposal template (add, grow, shrink, exit) | 10 | playbook |
| Consultation pack | 11 | work instruction |
| Budget submission pack in finance's format | 12, 13 | work instruction |
| Quarterly checkpoint template | 15 | work instruction |
| Envelope-breach exception path | 15 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Prior-year scoring (2.1): computed against closed actuals; every miss is countable.
2. Supply roll-forward (5.1): GP-105's first-released query on a longer horizon; after 1 because its catch rate is published on GP-105's cadence, not this cycle's.
3. Requirement and hiring-need computation (6.1): deterministic given the register and ramp curves; after 2 because an input error shows only once the roll-forward's rate is known.
4. Scenario-set assembly (8.1): the model runs the cases; last because a wrong case is caught only at the human choice in step 9, once a year.

Never: the envelope lock (14.1) and the budget signature (12.2) commit
people and money; the posture decision (10.2), whose consequences are
outside the model's data; the consultation step (11.1), a legal act.

Block 4 — gp-102-monthly-capacity-planning-cycle.md

<!-- Derived from [[Monthly Capacity Planning Cycle (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-102 Monthly Capacity Planning Cycle

The monthly cycle that refreshes demand and supply, computes the
requirement and the gap per business unit, clears the gap by internal moves
before external hiring, locks a plan of record and learns from last month's
variance. A deferring card: the six-stage method at L1 and L2 is on
Capacity Planning Cycle and is not restated. Every other function's numbers
pass through it once a month, so a standards committee usually certifies it
first. Its closing meeting is a decision meeting that commits the
organization to one set of numbers, not a status review.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-102 · local id by the standards committee |
| Class | strategic; its monthly horizon is tactical in the terms of Decision Rights by Planning Horizon |
| Trigger | the business-day calendar: stage 1 opens on the first business day after demand actuals close |
| Cadence | monthly, on a rolling horizon (SET LOCALLY; twelve to eighteen months typical [A]) |
| Scope in | every business unit and supply node the function plans; demand, supply, requirement at unit level; the gap; the clearing decisions; the lock |
| Scope out | the forecasting method (Three-Step Forecast Build); hiring after a requisition is raised; the weekly reforecast (GP-103) |
| Inputs | the short-term forecast and its lock; the roster and its roll-forward; attrition and hiring assumptions; the constraint register; last month's plan of record and its variance |
| Outputs | the plan of record with its signature; the surplus and deficit table per unit; the clearing decisions and the requisitions they raise; the variance review |
| Upstream | the enterprise demand forecast; finance's budget envelope; placement's constraint register; the definitions register |
| Downstream | scheduling (requirement by week); recruiting (requisitions); finance (committed cost line); real time (the staffing floor the plan commits) |
| Resources | capacity model with a plan of record; roster system of record; the forecast; constraint register; committee calendar; platforms at L3 only |
| Decision points | the clearing decision (move before hire); the lock decision (pencils down); the exception path when a unit's gap exceeds the band the plan can absorb |
| Authority tier | stage decisions at tier 1 (the planner inside the cycle calendar); the client-portfolio inputs signed at tier 2 by the planner who owns each; the lock at tier 4, the function head; a gap outside the band escalates to the executive sponsor by exception, per Decision Authority Tiers in Workforce Operations |
| Risk and compliance flags | headcount commitments bind finance; requisitions bind recruiting; a plan signed on unreconciled definitions is the composition trap of the definitions register |
| Variant-prone steps | calendar offsets; clearing rules where contracts dedicate supply; the approval tier where a works council must see a hiring plan |
| Automation candidates | five L2 sub-steps (five ranks) |

## L1 and L2 (deferred to the method page)
The L1 is the six-stage cycle on Capacity Planning Cycle: 1 demand refresh
· 2 supply roll-forward · 3 requirement and gap · 4 clearing · 5 lock and
decide · 6 execute and learn. That page carries the L2 of each stage. Copy
both into the function's L1 and L2 artifacts (CP-OPS-001) and fill the
open columns: owning seat per sub-step, ticketing code, notification text,
approver, duration.

Rows this card owns beyond the method:
- The band a gap may sit in before escalation and the pencils-down
  business day are L3 values, SET LOCALLY in the L2 row.
- "Gap outside band: escalate" is an L2 row of its own with an owner, not
  a footnote; every decision branch is written that way.
- Where a works council must see a hiring plan or reduction, a decision
  step is inserted between clearing (stage 4) and lock (stage 5).
- In the APQC classification the cycle is a Level 3 process under group
  7.1 with its stages as Level 4 activities; the documentation levels used
  here are a different axis.

## Variants
- Statutory: a works council must see a hiring plan or reduction before it is committed → decision step between clearing and lock; owner works-council liaison, approver function head.
- Contractual: a client contract dedicating supply removes it from the clearing pool; the clearing step is parameterized by the constraint register → SET LOCALLY, no row.
- Structural: a unit with no roster system of record rolls supply forward from a headcount file; the roll-forward step varied, reviewed each cycle until a system of record exists.
- Transitional: a predecessor-organization unit on its own cycle and calendar keeps a row until its first month on the shared calendar, dated by the standards committee.

## L3 register
| Job aid | Anchored to | Form |
|---|---|---|
| Calendar of business-day offsets per stage | stages 1–5 | work instruction |
| Demand-refresh checklist (sources, cut-off, sign-off) | stage 1 | work instruction |
| Roster roll-forward query and reconciliation to the headcount of record | stage 2 | work instruction; Headcount Reconciliation in Service Operations |
| Requirement computation and its parameters | stage 3 | work instruction; Capacity Planning Methods |
| Clearing rules and the constraint register layout | stage 4 | playbook |
| Lock pack: what the signatory sees, the signature record | stage 5 | work instruction |
| Variance review template and lesson log | stage 6 | playbook |
| Exception path when a gap exceeds the band | stages 3–5 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Roster roll-forward (stage 2): a deterministic query against the system of record; its catch rate is easiest to publish.
2. Requirement computation (stage 3): deterministic given the definitions register; the overseer checks inputs, not arithmetic.
3. Surplus and deficit table (stage 3): assembled, not decided.
4. Clearing proposal (stage 4): an agent may propose moves within the constraint register; the clearing decision stays human until the proposal's catch rate is published.
5. Variance review draft (stage 6): the plan-to-actual comparison is computed; the narrative is reviewed.

Never: the lock (stage 5), the plan signature gate; a signature is a human
act by definition.

Block 5 — gp-103-weekly-rolling-reforecast.md

<!-- Derived from [[Weekly Rolling Reforecast (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-103 Weekly Rolling Reforecast

The weekly cycle that refreshes the short-term forecast on last week's
actuals, applies the events and signals now known, redistributes the locked
month across weeks and intervals without changing its total, and hands the
requirement to scheduling. Every departure from the engine is a logged
layer with a reason; a week past its lock cannot be rewritten; the month's
total cannot change from inside the week. Not restated: Reforecast and
Rolling Forecast Methodology; Three-Step Forecast Build; Forecast Lock
Process; scoring is GP-106.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-103 · local id by the standards committee |
| Class | both: consumes a strategic lock, feeds the real-time steer |
| Trigger | first business day after the prior week's actuals close (SET LOCALLY) |
| Cadence | weekly; horizon two to six weeks by interval [A] (SET LOCALLY); the short-term lock sits at a published offset before the first shift it protects |
| Scope in | short-term forecast by interval per client portfolio; handle time; event overlay and accepted signals; redistribution inside the locked month; the vintage; the hand-off |
| Scope out | the month's total (GP-102, the mid-term door); intraday (GP-104); accuracy review (GP-106); schedule build (GP-201); lever decisions (GP-302) |
| Inputs | last week's actuals at the register's definitions; the locked month; last week's vintage; collision calendar; the week's signals; lock calendar; adjustment threshold table (SET LOCALLY) |
| Outputs | the new vintage with every layer stored; requirement by interval; adjustment log (reason, size, signer); variance log for any post-lock change; hand-off note |
| Upstream | GP-102; the collision calendar; the intelligence feed; real time's variance notes |
| Downstream | scheduling (maintenance, overtime and voluntary-time-off planning); real time (the steer baseline); GP-106 |
| Resources | short-term engine; vintage store; collision calendar; adjustment log; hand-off channel; platforms at L3 only |
| Decision points | update left the noise band? overlay or signal applies? week past its lock? adjustment above threshold? redistribution changes the month? version released? |
| Authority tier | tier 1 forecaster builds and adjusts inside the threshold; tier 2, the planner who owns the client portfolio, signs an adjustment above threshold, a variance on a locked week, and the lock; a change to the month's total is a variance to the mid-term door's owner, not this process's decision |
| Risk and compliance flags | a recency-driven upward edit; a layer merged into the published number; a late release pushing schedule changes inside a statutory notice window; a forecaster who is also the approver |
| Variant-prone steps | release day versus schedule-publication notice; partner hand-off views; client portfolios on a different close or without interval actuals |
| Automation candidates | seven L2 sub-steps (five ranks) |

## L1 flow (owner seat per step; 8, 9, 10 protect what is locked)
1. Close the week's actuals, complete at the register's definitions and graded — data steward
2. Score last week's vintage by layer; record for GP-106 — forecaster
3. Re-fit the engine; produce the statistical update — forecaster
4. Decision: update outside the noise band (SET LOCALLY)? No → carry the record; yes → new baseline — forecaster
5. Apply the event overlay from the collision calendar, each event graded — forecaster
6. Review signals; each accepted one becomes an adjustment with a source — forecaster
7. Reforecast handle time separately from volume — forecaster
8. Decision: any week past its lock? Yes → a change is a variance, signed by the owning planner — forecaster
9. Decision: any adjustment above threshold? Yes → reason and planner's signature — forecaster
10. Decision: does redistribution change the locked month's total? Yes → stop; variance to the mid-term door's owner — forecaster
11. Compute the requirement by interval on the register's shrinkage and occupancy — forecaster
12. Planner gate: decision per client portfolio, accept or amend with reason — planner
13. Sign the lock at the lock moment; stamp the vintage; release with the hand-off note — planner
14. Acknowledge; state the maintenance actions triggered; the ROC duty lead records the steer baseline — scheduling lead
15. Close the logs; note lessons for GP-106 — forecaster

## L2 step table (durations typical [A], SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Completeness and grade check | data steward | source feeds | closed week | 2 h | Y | actuals close checklist |
| 2 | 2.1 Score last vintage by layer | forecaster | vintage, actuals | layer scores | 1 h | Y | layer scoring template |
| 3 | 3.1 Re-fit; produce the update | forecaster | closed week, record | statistical update | 1 h | Y | engine run instruction |
| 4 | 4.1 Test against the noise band; carry or replace | forecaster | update, record, band | baseline | 30 min | Y | noise band table |
| 5 | 5.1 Apply events touching the horizon, graded | forecaster | collision calendar | overlay layer | 1 h | Y | overlay instruction |
| 6 | 6.1 Accept or reject each signal with a source | forecaster | intelligence feed | signal layer, log | 1 h | N | signal review log |
| 7 | 7.1 Update handle time by client portfolio | forecaster | handle-time actuals | handle-time layer | 1 h | N | handle-time instruction |
| 8 | 8.1 Test each week against the lock calendar | forecaster | version, lock calendar | open or locked | 15 min | N | lock calendar |
| 8 | 8.2 Enter a locked-week change in the variance log; sign | planner | change, reason, size | variance entry | same day | N | variance form |
| 9 | 9.1 Test each adjustment against the threshold | forecaster | log, threshold table | inside or above | 15 min | N | adjustment reason form |
| 9 | 9.2 Document the reason; sign | planner | adjustment | signed adjustment | same day | N | adjustment reason form |
| 10 | 10.1 Sum the weeks against the locked month | forecaster | version, locked month | inside or breach | 15 min | N | month-breach runbook |
| 10 | 10.2 Raise a variance to the mid-term door's owner | forecaster | breach, reason, size | variance entry | same day | N | month-breach runbook |
| 11 | 11.1 Compute the requirement by interval | forecaster | version, register | requirement | 30 min | Y | requirement instruction |
| 12 | 12.1 Review per client portfolio; accept or amend | planner | version, logs | gate record | same day | N | planner gate pack |
| 13 | 13.1 Sign the lock; stamp the vintage | planner | gated version | locked vintage | 15 min | N | lock pack |
| 13 | 13.2 Send the hand-off note, with partner views where contracted | forecaster | vintage, requirement | hand-off note | 30 min | Y | hand-off note template |
| 14 | 14.1 Acknowledge; state maintenance actions | scheduling lead | hand-off note | acknowledgement | same day | N | hand-off note template |
| 14 | 14.2 Record the steer baseline | ROC duty lead | hand-off note | steer baseline | same day | N | hand-off note template |
| 15 | 15.1 Close logs; note lessons | forecaster | logs | closed week | 30 min | N | weekly close checklist |

## Variants
- Statutory: a notice period with predictability pay forcing an earlier release day is a parameter of step 13, SET LOCALLY; a works council informed weekly of forecast-driven schedule changes → notification step after 13, a row owned by the works-council liaison.
- Contractual: a partner contract fixing a weekly forecast delivery parameterizes 13.2 → SET LOCALLY, no row.
- Structural: no interval-level actuals (an asynchronous channel) → daily resolution, steps 3 and 11 varied under a row with a review date; a different weekly close changes only the offset.
- Transitional: a predecessor-organization engine that cannot store layers keeps a row until cut-over; automation effect `blocks` ranks 2 and 3.

## L3 register (noise band, threshold, release offset SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| Weekly calendar: close, build, gate, lock, release offsets | 1, 8, 12, 13 | work instruction |
| Actuals close checklist and grade rules | 1 | work instruction |
| Noise band and adjustment threshold table | 4, 9 | work instruction |
| Engine run instruction | 3 | work instruction; Three-Step Forecast Build |
| Overlay instruction against the collision calendar | 5 | work instruction |
| Signal review log and acceptance rule | 6 | playbook |
| Variance form for a locked week | 8 | work instruction; Forecast Lock Process |
| Adjustment reason form; separation of builder and approver | 9 | work instruction |
| Planner gate pack | 12 | work instruction |
| Hand-off note template with partner views | 13, 14 | work instruction |
| Month-breach exception path | 10 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Actuals close check (1.1): deterministic completeness test; every miss visible the same week.
2. Layer scoring (2.1): computed once actuals close; after 1 because it is only as good as the close.
3. Statistical update and noise-band test (3.1, 4.1): engine output released on the earned-learning rule of Forecast Value Added in Workforce Management, replacing the record only where it has beaten it before; after 2 because that rule needs several weeks of layer scores.
4. Event overlay (5.1): deterministic given window and grade; after 3 because a wrong overlay is caught only when the event's week is scored.
5. Requirement computation and hand-off packet (11.1, 13.2): computed and assembled; last because errors are caught by scheduling's acknowledgement, not a rate of their own.

Never: the lock (13.1). The planner gate (12.1) only under the earned
auto-approval rule, per client portfolio, within a published tolerance.
Signal acceptance (6.1) not yet; per client portfolio once the feed's catch
rate is published. The week may redistribute but not breach the month: the
time-fence logic of master scheduling.

Block 6 — gp-104-intraday-reforecast.md

<!-- Derived from [[Intraday Reforecast (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-104 Intraday Reforecast

The event-driven revision of the rest of the day's forecast when actuals
have left the band around the forecast of record, handed to the real-time
function for the lever decisions of GP-302. It revises the prediction; the
response to a queue is another process. A revised forecast is only worth
producing while there is still time to act on it. A deferring card: the
reforecast-or-hold test, the three methods and configuration are on
Intraday Reforecasting Methods; the calculations and downstream chain on
Intraday Reforecasting and Real-Time Forecast Updates. The one forecasting
process consumed inside the real-time section of the catalog.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-104 · local id by the standards committee |
| Class | real-time |
| Trigger | a sustained deviation of actual volume or handle time from the forecast of record beyond a band for a number of consecutive intervals (both SET LOCALLY), or a known causal event, raised by a threshold alert (GP-304) or the ROC's monitoring rotation |
| Cadence | event-driven within the day; not before a minimum of actuals has accumulated and not after no lever can still act (both SET LOCALLY); capped per day at a count the function sets |
| Scope in | revised interval forecast for the rest of the day for the affected client portfolios; volume and handle time separately; requirement and gap by interval; the hand-off; the reforecast log |
| Scope out | the lever decision (GP-302); the alert architecture (GP-304); anything beyond today (GP-103); the incident process; scoring (GP-106) |
| Inputs | the day's forecast of record by interval (GP-103's vintage); actuals to the current interval; the alert or rotation note; the cause note; the band, minimum-actuals and cap table; the intraday curve |
| Outputs | the revised forecast stamped as an intraday version; recomputed requirement and gap; hand-off note with cause class and action lead time; log entry (time, trigger, method, lead time) |
| Upstream | GP-103; GP-304; the monitoring rotation; the incident process when the cause is an outage |
| Downstream | the daily ROC routine and GP-302; GP-106 (reforecast accuracy scored separately from the morning forecast); Variance Harvesting |
| Resources | real-time monitoring feed; the platform's reforecast function or a ratio model; staffing model; vintage store; ROC channel; platforms at L3 only |
| Decision points | reforecast or hold? cause known and temporary? volume, handle time, or both? lead time for a lever? release as information or as a recommended action set? |
| Authority tier | tier 1, the real-time analyst inside guardrails, raises, produces and releases; a reforecast whose implied adjustment is major in the daily ROC routine's split goes to tier 3, the ROC duty lead, before release; the forecast never goes above tier 3, though the lever may escalate under GP-302 |
| Risk and compliance flags | same-day schedule changes inside a statutory notice window; over-reaction to noise; a reforecast released without action authority |
| Variant-prone steps | band and cap; hand-off where a partner runs its own real-time desk; platforms that cannot reforecast handle time; client portfolios with no real-time state |
| Automation candidates | four sub-steps (four ranks); the L2 rows are the method pages' stages |

## L1 and L2 (deferred to the method pages)
Copy the stages into the function's L1 and L2 artifacts (CP-OPS-001):
detect the trigger · the hold test · the cause check · run the method ·
the handle-time stage · recompute the requirement · release.

Rows this card owns beyond the method:
- Band, consecutive-interval count, minimum actuals and daily cap are
  written SET LOCALLY.
- "Hold" is a decision branch with an owner and a logged reason; an
  unlogged hold cannot be scored.
- The release stage carries the minor-or-major split; a major implied
  adjustment goes to the ROC duty lead first.
- Volume and handle time are reforecast separately.

## Variants
- Statutory: where same-day changes trigger predictability pay or notice, the reforecast is unchanged and the hand-off note flags a restricted action set: a parameter of the release stage, SET LOCALLY; the lever restriction belongs to GP-302.
- Contractual: a partner site with its own real-time desk receives the reforecast as a notification, not an action set; the release stage changes output and recipient → variant row, owner placement lead, reviewed at renewal.
- Structural: no observable real-time state (an asynchronous channel) is a scope exclusion on the catalog row, not a variant; a platform that cannot reforecast handle time varies that stage, run by hand on a ratio, reviewed when the platform changes.
- Transitional: a predecessor-organization feed not yet on the shared platform raises the trigger by hand from site reports; row expiring at cut-over, automation effect `blocks` rank 1.

## L3 register (band, count, minimum actuals, cap SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| Band, interval count, minimum-actuals and daily-cap table | trigger, hold test | work instruction |
| Reforecast-or-hold checklist | hold test | work instruction; Intraday Reforecasting Methods |
| Cause classification list (outage burst, campaign, external event, supply break, unknown) | cause stage | work instruction |
| Method per client portfolio; validation of the platform's reforecast against a ratio baseline | method stage | work instruction |
| Handle-time reforecast and requirement recomputation | handle-time, requirement stages | work instruction; Erlang C |
| Hand-off note: cause class, lead time, information or action set | release stage | work instruction |
| Reforecast log layout | every stage | work instruction |
| Minor-or-major release rule and the duty-lead path | release stage | playbook; Daily ROC Routine |
| Reforecasting when the monitoring feed is dark | trigger stage | runbook |

## Automation candidates (ranked by ease of publishing a catch rate; each named by its L1 stage)
1. Trigger detection (detect the trigger): deterministic given band and count; every missed or false trigger is visible the same day.
2. Statistical reforecast (run the method): a ratio adjustment first, the platform's method only after validation against the ratio baseline; after 1 because its catch rate is the reforecast accuracy GP-106 scores, which takes weeks of days.
3. Requirement and gap recomputation (recompute the requirement): deterministic given the staffing model and the register; after 2 because it is conditional on the forecast it is computed from.
4. Hand-off packet and log entry (release): assembled, not decided; last because errors are caught by the ROC's acknowledgement.

Not candidates: the cause check, because whether a hot morning is an
outage burst or a campaign is not in the feed; and the release of a major
adjustment, the stage before the costliest error. A release inside
guardrails, a minor adjustment, may be released whole once the chain's
catch rate is published.

Block 7 — gp-105-supply-and-attrition-forecasting.md

<!-- Derived from [[Supply and Attrition Forecasting (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-105 Supply and Attrition Forecasting

Projects the headcount a function will have at each future period: the
roster of record rolled forward with attrition by cohort, the hiring
pipeline discounted by ramp, internal moves, leave and return, published as
effective FTE with bands and graded assumptions. The supply side of the
capacity gap: GP-102 stage 2 monthly, GP-101 step 5 annually. Separate from
demand because supply is a stock-and-flow model of people, not a time
series; run on demand's cadence so the gap is never stale. Not restated:
Workforce Forecasting; Employee Attrition and Turnover.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-105 · local id by the standards committee |
| Class | strategic |
| Trigger | the roster of record closes for the month, at a business-day offset (SET LOCALLY) ahead of stage 2; out-of-cycle on a class cancelled or short, or attrition beyond a band (SET LOCALLY) |
| Cadence | monthly on the capacity cycle's horizon; quarterly curve refresh; annually on the long-range horizon for GP-101 |
| Scope in | opening balance by cohort, skill, pool, status; attrition by cohort; pipeline by class; ramp; promotion, transfer, pool moves; leave and return; net effective FTE with bands; last vintage's accuracy |
| Scope out | the demand forecast; requirement and gap (GP-102 stage 3); the hiring decision; the retention program; the reconciliation method itself |
| Inputs | roster of record; finance's headcount of record; separations and leave records; recruiting's pipeline (class dates, sizes, acceptance); training's cohort schedule and graduation actuals; definitions register; curve library |
| Outputs | the supply vintage (effective FTE by cohort by period, bands at quantiles SET LOCALLY; P50/P80/P95 typical [A]); assumptions sheet with a grade per assumption; class-graduation projection; last vintage's score with error attributed; hand-off to stage 3 |
| Upstream | human-resources system of record; recruiting; training; placement for partner seats (hours, not heads) |
| Downstream | GP-102 stages 2 and 3; GP-101 step 5; scheduling; GP-505 (skill mix); GP-106 |
| Resources | roster of record; cohort-projection model; curve library (survival per segment, ramp per skill); reconciliation query; platforms at L3 only |
| Decision points | roster reconciles? curves inside refresh window? pipeline matches plan? any [A] with no [E] range? out-of-cycle trigger fired? |
| Authority tier | supply planner builds (tier 1); the planner who owns the client portfolio signs the assumptions sheet and the vintage (tier 2); a vintage on an [A] attrition rate with no range is blocked and enters only with a range or a tier-4 (function head) logged acceptance |
| Risk and compliance flags | individual-level predictors fall under data-protection law, so the forecast works on cohorts and risk scores never leave human resources; works councils may have a say in predictive analytics; partner rosters are the partner's |
| Variant-prone steps | roster source with no system of record; partner seats as hours; leave categories by jurisdiction; ramp where training is partner-run |
| Automation candidates | eight L2 sub-steps (six ranks) |

## L1 flow (owner seat per step; cohort level throughout)
1. Close and reconcile the roster to the headcount of record. Decision: within tolerance (SET LOCALLY)? No → hold for the data steward's correction — supply planner
2. Build the opening balance by cohort — supply planner
3. Decision: curves inside their refresh window? No → refresh from last quarter's exits and graduation actuals — supply planner
4. Forecast attrition by cohort: survival curve per segment (product-limit estimator) and the labor-market modifier; grade each assumption — supply planner
5. Load the hiring pipeline; training's cohort schedule and pipeline attrition as a sub-step — recruiting liaison
6. Apply ramp: each class to effective FTE by period, net of pipeline attrition — supply planner
7. Forecast internal flows: promotions, transfers, pool moves — supply planner
8. Forecast leave and return at cohort level — supply planner
9. Run the cohort projection with bands (quantiles SET LOCALLY; P50/P80/P95 typical [A]) — supply planner
10. Decision: any [A] with no [E] range? Yes → obtain a range or send to the function head for a logged acceptance — supply planner
11. Score last period's vintage against the actual roster; attribute error to attrition, pipeline, ramp or flows; record for GP-106 — supply planner
12. Planner gate: decision per client portfolio — planner
13. Stamp the vintage; hand to stage 3; publish the pool to scheduling and the partner-seat view to placement — supply planner
14. Decision: out-of-cycle trigger fired (SET LOCALLY)? Yes → re-run 4 to 9 for the affected cohorts; re-issue through the gate — supply planner

## L2 step table (durations typical business days [A], SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Pull the roster at the close | supply planner | system of record | roster extract | 0.5 BD | Y | roster close query |
| 1 | 1.2 Reconcile to the headcount of record; hold on a breach | supply planner | extract, finance's count | reconciled roster | 1 BD | Y | reconciliation instruction |
| 2 | 2.1 Assemble the opening balance by cohort | supply planner | roster, cohort table | opening balance | 0.5 BD | Y | cohort definition table |
| 3 | 3.1 Test curve currency; refresh if due | supply planner | exits, graduates | curves of record | 2 BD | Y | curve library instruction |
| 4 | 4.1 Apply survival curve and market modifier; grade each | supply planner | balance, curves | attrition layer | 1 BD | N | attrition assumptions sheet |
| 5 | 5.1 Confirm class dates, sizes, acceptance | recruiting liaison | requisition log | pipeline sheet | 1 BD | N | pipeline intake form |
| 5 | 5.2 Confirm cohort schedule and pipeline attrition | training lead | training calendar | cohort sheet | 1 BD | N | pipeline intake form |
| 6 | 6.1 Convert each class to effective FTE on its ramp curve | supply planner | pipeline, ramp curves | ramp layer | 0.5 BD | Y | ramp application instruction |
| 7 | 7.1 Enter promotions, transfers, pool moves | supply planner | rates, planned moves | flows layer | 1 BD | N | flows instruction |
| 8 | 8.1 Enter leave and return by cohort | supply planner | leave records (cohort) | leave layer | 0.5 BD | N | leave and return profile table |
| 9 | 9.1 Run the projection with bands | supply planner | all layers | vintage draft | 0.5 BD | Y | projection run instruction |
| 10 | 10.1 Test every assumption for an [A] with no range; obtain or escalate | supply planner | assumptions sheet | graded sheet | same day | N | assumptions sheet |
| 10 | 10.2 Accept or refuse an ungraded assumption with a logged reason | function head | escalated assumption | logged acceptance | same day | N | assumptions sheet |
| 11 | 11.1 Score last vintage; attribute error | supply planner | last vintage, actual roster | score sheet | 1 BD | Y | vintage scoring template |
| 12 | 12.1 Review sheet and vintage; decision per client portfolio | planner | vintage, sheet, scores | gate record | 1 BD | N | planner gate pack |
| 13 | 13.1 Stamp the vintage | supply planner | gated vintage | stamped vintage | 15 min | N | hand-off instruction |
| 13 | 13.2 Assemble the hand-off to stage 3, scheduling, placement | supply planner | stamped vintage, sheet | published vintage | 0.5 BD | Y | hand-off instruction |
| 14 | 14.1 Test out-of-cycle triggers; re-run affected cohorts | supply planner | trigger table, events | re-issued vintage | SET LOCALLY | N | out-of-cycle runbook |

## Variants
- Statutory: a restriction on employee-level predictors changes nothing at cohort level (parameter on step 4 inputs, SET LOCALLY); works-council consultation before predictive attrition analytics → row at step 4, market modifier only, owner works-council liaison.
- Contractual: a partner seat contracted as hours → row at steps 2 and 9: opening balance a committed-hours block, attrition inside the price; owner placement lead, reviewed at renewal.
- Structural: no roster system of record → step 1 from a headcount file, reviewed each cycle; partner-run training with no graduation actuals → ramp curve at [A] under a row at step 3.
- Transitional: a predecessor-organization human-resources system not yet migrated → row expiring at cut-over; automation effect `blocks` ranks 1 and 2.

## L3 register (tolerance, refresh window, quantiles, out-of-cycle band SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| Roster close query and reconciliation instruction | 1 | work instruction; Headcount Reconciliation in Service Operations |
| Cohort definition table (tenure bands, pools, statuses) | 2 | work instruction |
| Curve library instruction: refresh window, fitting, acceptance | 3 | work instruction; Survival Analysis for Workforce Attrition; Speed to proficiency curve |
| Attrition assumptions sheet with grades | 4, 10 | work instruction |
| Pipeline intake form for recruiting and training | 5 | work instruction |
| Ramp application instruction | 6 | work instruction |
| Flows and leave-and-return profile tables | 7, 8 | work instruction |
| Projection run instruction with the band quantiles | 9 | work instruction |
| Vintage scoring template | 11 | work instruction |
| Planner gate pack | 12 | work instruction |
| Out-of-cycle trigger path | 14 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Roster pull and reconciliation (1.1, 1.2): a query and a sum against finance's count; a miss is caught the same day by the count it failed to match.
2. Opening balance (2.1): deterministic given the cohort table; after 1 because a wrong balance is caught only once the roster is reconciled.
3. Ramp conversion and cohort projection (6.1, 9.1): computed, the overseer checking the assumptions sheet; after 2 because errors are countable only when the next roster closes.
4. Hand-off assembly (13.2): after 3 because errors are caught by the receiving stage's acknowledgement.
5. Vintage scoring (11.1): after 4 because its catch rate needs several periods of scored vintages.
6. Curve refresh (3.1): fitting is computed, acceptance stays human; last because a curve fitted on a small cohort can move the forecast further than the drift it corrects, an error a quarter or more in showing.

Never: the planner gate (12.1) and the stamp (13.1); the escalation of an
ungraded assumption (10.1, 10.2), which exists so a person must produce a
range or a reason. The attrition layer (4.1) is deliberately not listed:
the hazard depends on tenure, unit and labor-market conditions the model
does not observe.

Block 8 — gp-106-forecast-accuracy-governance.md

<!-- Derived from [[Forecast Accuracy Governance (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-106 Forecast Accuracy Governance

Scores every published forecast at the horizon it was used for, attributes
error to the step that produced it, flags systematic bias, assigns and
verifies corrective actions, and decides on that evidence which forecasting
automation candidates are released or withdrawn. It governs GP-101 to
GP-105, which record the scores it reviews. The weekly forecast-versus-
actual review (GP-602) is its first rung: that card scores one week with
the floor; this one scores the month and sets the measures the weekly
review reports. Only a measured step can be kept or removed on evidence.
Not restated: MAPE WAPE and Forecast Bias; Forecast Accuracy Metrics;
Forecast Value Added in Workforce Management; Forecast Bias Detection and
Correction.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-106 · local id by the standards committee |
| Class | supporting |
| Trigger | the month's actuals close and the weekly scores are on file, at a business-day offset (SET LOCALLY); quarterly review with the annual checkpoint; out-of-cycle when a bias flag exceeds a band (SET LOCALLY) |
| Cadence | weekly scores arrive; the month is scored and reviewed monthly; release and withdrawal quarterly |
| Scope in | measure set and benchmark per horizon; stairstep per process; bias monitor; adjustment and reforecast logs; corrective action register; release and withdrawal of forecasting candidates on their catch rate; the accuracy report |
| Scope out | metric definitions; forecasting methods; the weekly review's agenda; bias-correction mathematics; adherence and schedule measures; individual performance management |
| Inputs | every vintage with layers and decision date; actuals at the register's definitions; weekly scores; adjustment logs (GP-103), reforecast logs (GP-104), supply scores (GP-105); bias threshold table (SET LOCALLY); the catch-rate ledger |
| Outputs | monthly accuracy report, a stairstep per process at the horizon used, by client portfolio and segment; bias flag list with root cause; action register (owner, due date, proving measure); release and withdrawal decisions; measure-set change log; quarterly summary |
| Upstream | every forecasting process; the vintage store; the weekly review |
| Downstream | the forecasting processes; GP-601 (changes to the standard); the standards committee; GP-604 (the published report) |
| Resources | vintage store; scoring routine; bias monitor; action register; committee calendar; platforms at L3 only |
| Decision points | layer difference real or noise? bias cause data, structural or organizational? which correction? remove a layer adding nothing? catch rate meets the release condition, or a released rule fallen below it? measure set changes? |
| Authority tier | scoring at tier 1 (forecaster); decision per flagged item at tier 2, the planner who owns each client portfolio, in a review the standardization lead chairs; release and withdrawal at tier 4 (function head) on the standards committee's recommendation; a measure-set change goes through GP-601 |
| Risk and compliance flags | accuracy as an individual's performance measure invites sandbagging; scoring at a horizon not used; a layer merged into the published number; a partner accuracy clause on a non-register definition |
| Variant-prone steps | benchmark for a client portfolio with no history; partner accuracy clauses; client portfolios too small for percentage measures |
| Automation candidates | eight L2 sub-steps (five ranks) |

## L1 flow (owner seat per step; steps are scored, never seats)
1. Confirm the scoring base: actuals closed, weekly scores filed, every vintage stored with layers and decision date — data steward
2. Score the month: every vintage at the horizon used, per client portfolio and segment — forecaster
3. Build the stairstep per process, layer against layer and against the naive benchmark — forecaster
4. Decision: each layer's difference larger than noise under the paired test? If not, record "no measurable value" — forecaster
5. Run the bias monitor by segment against thresholds (SET LOCALLY) — forecaster
6. Decision: any segment in breach? Yes → root-cause item classed data, structural or organizational before any correction — forecaster
7. Review adjustment and reforecast logs against outcome; a repeated adjustment is flagged for the model — forecaster
8. Score the supply vintage separately; attribute its error — supply planner
9. Monthly review: the owning planner produces a decision per flagged item: keep, correct, remove, escalate — standardization lead
10. Assign corrective actions with owner, due date and proving measure — planner
11. Decision, quarterly: catch rate meets the release condition, or a released rule fallen below it? Release or withdraw on the committee's recommendation, with reason — function head
12. Publish the report, answer-first, to the function head and standing forums — standardization lead
13. Close the loop: verify last month's actions moved the flag; log lessons; raise change requests through GP-601 — forecaster

## L2 step table (durations typical business days [A], SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Check actuals closed, scores filed, vintages stored | data steward | vintage store, actuals, weekly scores | scoring base | 0.5 BD | Y | scoring base checklist |
| 2 | 2.1 Score each vintage at the horizon used | forecaster | base, measure set | score table | 1 BD | Y | scoring routine instruction |
| 3 | 3.1 Build the stairstep per process | forecaster | score table | stairstep | 0.5 BD | Y | stairstep template |
| 4 | 4.1 Run the paired test per layer; mark unmeasurable gains | forecaster | stairstep | tested stairstep | 0.5 BD | Y | significance test instruction |
| 5 | 5.1 Compute bias measures by segment against thresholds | forecaster | score table, thresholds | flag list | 0.5 BD | Y | bias monitor layout |
| 6 | 6.1 Open a root-cause item per breach, classed | forecaster | flag list, logs | root-cause items | 2 BD | N | root-cause protocol |
| 7 | 7.1 Compare each adjustment with its outcome; flag repeats | forecaster | logs | adjustment review | 1 BD | N | adjustment review template |
| 8 | 8.1 Score the supply vintage; attribute error | supply planner | supply vintage, roster | supply score | 1 BD | Y | vintage scoring template |
| 9 | 9.1 Circulate the review pack | standardization lead | steps 2 to 8 | review pack | 1 BD | Y | monthly review pack |
| 9 | 9.2 Produce a decision per flagged item | planner | review pack | decision record | 0.5 BD | N | monthly review pack |
| 10 | 10.1 Enter each action with owner, date, proving measure | planner | decision record | action register | 0.5 BD | N | corrective action register |
| 11 | 11.1 Compare each catch rate with the release condition; list rules below it | standardization lead | catch-rate ledger | recommendation list | 1 BD | N | release and withdrawal form |
| 11 | 11.2 Decide release or withdrawal with reason | function head | recommendation list | signed decision | 1 BD | N | release and withdrawal form |
| 12 | 12.1 Assemble the report, answer-first | standardization lead | review outputs | draft report | 0.5 BD | Y | report template |
| 12 | 12.2 Review the narrative; publish | standardization lead | draft report | published report | 0.5 BD | N | report template |
| 13 | 13.1 Verify last month's actions against their proving measure | forecaster | action register, scores | closed or carried | 0.5 BD | N | corrective action register |
| 13 | 13.2 Raise change requests to the standard | forecaster | lessons, change log | change requests | as needed | N | GP-601 intake |

## Variants
- Statutory: no step changes; where an accuracy figure is part of a regulated report, the retention period of vintages and scores is a parameter, SET LOCALLY.
- Contractual: a partner accuracy clause → row at steps 2 and 12: scored on the contract's measure beside the register's, never instead; owner placement lead, reviewed at renewal.
- Structural: a client portfolio too small for percentage measures takes a scale-free measure (parameter, SET LOCALLY); one with no history for a naive benchmark → row at step 3, scored against the forecast of record only, reviewed at its first full year.
- Transitional: predecessor-organization vintages not stored with layers are scored on the total only, row expiring at cut-over; automation effect `blocks` rank 3.

## L3 register (measure set, bias thresholds, release condition SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| Measure set per horizon and client portfolio, with benchmark | 2 | work instruction; MAPE WAPE and Forecast Bias |
| Scoring base checklist | 1 | work instruction |
| Scoring routine and stairstep template | 2, 3 | work instruction; Forecast Value Added in Workforce Management |
| Significance test instruction | 4 | work instruction; Model Evaluation and Validation |
| Bias threshold table and monitor layout | 5 | work instruction; Forecast Bias Detection and Correction |
| Root-cause protocol: data, structural, organizational | 6 | playbook |
| Adjustment review template | 7 | work instruction |
| Monthly review pack and decision record | 9 | work instruction |
| Corrective action register | 10, 13 | work instruction |
| Release and withdrawal form with catch-rate evidence | 11 | playbook; Human Gates and Number Grades |
| Report template | 12 | work instruction; Answer-First Reporting |
| Out-of-cycle review path on a bias breach | trigger | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Scoring base check (1.1): deterministic; a missing vintage or unclosed month is caught the day it occurs.
2. Vintage scoring (2.1, 8.1): computed, the right answer defined by measure set and actuals; after 1 because a score is only as good as its base.
3. Stairstep and paired test (3.1, 4.1): computed, the test itself a rule; after 2 because it consumes the scores and its errors need months of layers to surface.
4. Bias monitor (5.1): a tracking signal and bias ratio against thresholds; after 3 because a false flag is known only after its root-cause item closes.
5. Report assembly (9.1, 12.1): assembled, the narrative reviewed; last because errors are caught by the reader.

Never: the decision per flagged item (9.2), a gate that must produce a
verdict; release and withdrawal (11.2), the gate governing every other
gate, since a rule cannot certify its own release; root-cause
classification (6.1), because organizational causes are not in the data
the monitor reads. The measure set is a parameter per client portfolio, not
one figure for the operation.

Usage notes

Sizing. Block 1 is about 580 words and loads with every message. Blocks 2–8 are retrieved as needed: the rules file is about 1,100 words; the four full cards (GP-101, GP-103, GP-105, GP-106) run from about 1,750 to 1,900 words each, and the two deferring cards (GP-102, GP-104), whose L1 and L2 live on their method pages, about 1,100 to 1,200. In a full card the L2 step table, carried in full so that nothing has to be fetched from the wiki during a session, is roughly half the words.

Output. The pack emits the five Markdown files per card that Wiki:Packs/Process Decomposition defines, with the profile on the L0 cover, the L2 in the fifteen-column form and the variant rows in the register layout of Standard and Variant in Process Documentation. The card files condense the wiki pages and do not restate the method pages; for GP-102 and GP-104 the L1 and L2 are copied from Capacity Planning Cycle and the two intraday pages, which the user brings.

Localizing. Every SET LOCALLY in a card file is a value the function holds; the pack writes the mark with its seat and never a number the user has not given. The "typical" figures in the profiles are the card's, graded [A], not the function's. A local difference goes through the four-question variant test before it becomes a row; preference is a compliance finding. GP-103 step 14 and GP-105 step 5 each name a second seat for a sub-step; the L2 rows separate them, one owner each.

Drift. Blocks 2–8 derive from the twelve source pages in the infobox. A material change to any card page, to the variant convention, to the tier ladder or to the release rule is the trigger to regenerate the affected block and bump the version. The six card pages were read on Thu 16 Oct 2026.

Scope. Nothing in the pack is specific to any organization, platform or jurisdiction. The forecasting method itself (engine choice, layer arithmetic, measure selection) is out of scope; the pack localizes the process around it.

Change history

Version	Date	Change
1.0	2026-10-16	First release: instruction block, the shared localization rules, and one reference file per forecasting card (GP-101 to GP-106)

See also

• Process Standardization — the hub: conventions, the inventory of generic process cards and the pillar packs
• Wiki:Packs/Process Decomposition — CP-OPS-001, the engine whose L0 form and fifteen-column L2 this pack writes into
• Wiki:Packs/Process Inventory and Shell Catalog — CP-OPS-008, the catalog rows this pack localizes against
• Annual Strategic Workforce Planning Cycle (generic process) — GP-101
• Monthly Capacity Planning Cycle (generic process) — GP-102, with its method on Capacity Planning Cycle
• Weekly Rolling Reforecast (generic process) — GP-103
• Intraday Reforecast (generic process) — GP-104, with its method on Intraday Reforecasting Methods
• Supply and Attrition Forecasting (generic process) — GP-105
• Forecast Accuracy Governance (generic process) — GP-106
• Three-Step Forecast Build · Forecast Lock Process · Forecast Collision Calendar — the shelf pages the pillar uses as method pages
• Wiki:Packs/Scheduling Processes · Wiki:Packs/Real-Time Processes · Wiki:Packs/Work Placement Processes · Wiki:Packs/Continuity Interface Processes · Wiki:Packs/Cross-Cutting Governance Processes — the sibling pillar packs
• Wiki:Packs — inventory and how packs work