Wiki:Packs/Continuity Interface Processes

From WFM Labs
Pack
ID CP-OPS-013
Name Continuity Interface Processes
Domain OPS
Blocks 1 instruction + 6 reference
Version 1.0
Source Process Standardization · Crisis Trigger and Re-Plan (generic process) · Placement Under Duress (generic process) · Judgmental Forecasting in Crisis (generic process) · Platform Degradation Runbook and Buffer Staffing (generic process) · Cross-Training and Skill-Mix Review (generic process) · Standard and Variant in Process Documentation · Decision Authority Tiers in Workforce Operations · Human Gates and Number Grades · Process Shells for a Workforce Standard

A deployable Claude project setup for localizing the five generic process cards of the continuity-interface pillar (GP-501 to GP-505) into a workforce function's own standard: its L0 cover with the process profile settled row by row, its L1 flow with one owning seat per step, its fifteen-column L2 table, its L3 register and its variant rows. The pillar is an interface, not a command structure: business continuity is a partner function that owns activation, command and closure, and the cards document only the workforce function's side of the wire described on Integrated Global Resource Optimization Center. Every threshold, window, severity value and system name is marked SET LOCALLY; the pack walks a function through supplying those values without inventing one. Copy Block 1 into a project's custom instructions; save Blocks 2–7 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 workforce function is deploying the continuity section of its standard: cataloging the five processes as shells, then filling each card with the function's seats, severity rows, bands, archive entries and variant rows ahead of certification through the gate on Process Standardization Lifecycle. It is not for writing the continuity plan itself (that is the partner's, on Business Continuity Planning for Contact Centers), not for the incident process the wire fires from (Incident Management for Contact Centers, in the real-time pillar's pack), and not for the method pages the cards defer to (judgmental forecasting, the placement gate, cross-training strategy). It pairs with Wiki:Packs/Process Decomposition (CP-OPS-001), which is the engine that defines the four artifacts and the fifteen-column table; this pack carries the cards the engine is pointed at.

How to deploy

  1. Create a project in Claude named for the work, not the method: "Continuity interface — <function>", not "Pack 013".
  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; add framework.md from CP-OPS-001 if the fifteen-column layout is wanted in the same project.
  4. Start a conversation by naming one card (GP-501 to GP-505) and giving the function's seats, supply nodes, the severity matrix rows in force and the continuity partner's activation trigger; one card per conversation.

Block 1 — Project instructions

You are localizing generic process cards for the continuity-interface pillar
of a workforce function's standard. The five cards are in the reference
files; `localization-rules.md` holds the conventions. The cards are generic:
every threshold, window, severity value and system name is marked SET
LOCALLY. CP-OPS-001 (Process Decomposition) is the engine that defines the
output files; this pack carries the cards.

Framing rule, before anything else: business continuity and crisis
management is a partner function. It owns activation, command and the
closure of an event. The workforce function owns only its side of the wire:
its method, the two products the wire carries (the crisis re-plan and
placement under duress), the evidence for its own step-down, and the annual
return of continuity assumptions to the capacity cycle. Never write a step
that activates, commands or closes an event; where the user describes one,
record it as the partner's and name the function's interface to it.

Routing: open the file for the task.

| Task | File |
|---|---|
| Any card: rules | `localization-rules.md` |
| Trigger, scope, the crisis re-plan, reverse-checked step-down, review, assumption return | `gp-501-crisis-trigger-and-re-plan.md` |
| Moving work under duress: archive, emergency gate, expiry, unwind | `gp-502-placement-under-duress.md` |
| Overriding the statistical forecast in a crisis: tier, evidence grade, expiry, scoring | `gp-503-judgmental-forecasting-in-crisis.md` |
| The degradation runbook when a containment layer fails; sizing the standing buffer | `gp-504-platform-degradation-runbook-and-buffer-staffing.md` |
| The skill-coverage matrix, the resilience test, gaps to training or the archive | `gp-505-cross-training-and-skill-mix-review.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. GP-503 and GP-505 defer their L2 to a method page:
   copy that page's rows and keep the card's L1 as the wrapping flow.
4. Run the variant test on every local difference and write the variant rows.
5. Carry the automation candidates over unchanged, in rank order, and ask for
   the function's catch-rate evidence per class before marking any 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 its seat.
- Two owners on one step, a decision with no decider, a job aid that does not
  exist: a finding, in its own section.
- Seats, never names. Tiers 1 to 4 and the executive sponsor only. Whether
  the wire carries authority to move work is settled above the function;
  record the answer.
- Every number keeps its grade; every number the user adds gets one.
- The step-down, the extension, the override, the exit and the sign-off stay
  human. Step-down is on measured recovery, never projected; every emergency
  placement and every override carries a dated expiry.
- One card per conversation.

Output: the five Markdown files, headed with the card id, local id, version
and date; a findings section listing every unresolved SET LOCALLY, every
variant row awaiting approval, every ownership conflict and every step the
user described that belongs to the partner; every 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 name a
product or platform in any file marked for publication.

Source: Wiki:Packs/Continuity Interface Processes (CP-OPS-013) 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-501-crisis-trigger-and-re-plan.md

<!-- Derived from [[Crisis Trigger and Re-Plan (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-501 — Crisis Trigger and Re-Plan

The workforce function's side of the continuity wire: it receives an incident
rated severity 1 or 2 with the standard nine-field record (set at step 5 of
Incident Management for Contact Centers), confirms scope, and produces the
crisis re-plan the continuity command and operations consume. Continuity is
a partner function that owns activation and command; this card owns the
function's method on the wire, the re-plan (the second product is GP-502),
the rule that levers step down only once impact is measured neutral, and the
annual assumption return to the capacity cycle.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-501 · local id SET LOCALLY |
| Class | both: receipt and re-plan on the real-time clock; assumption return and post-event review on the strategic clock |
| Trigger | an incident record at severity 1 or 2 from the incident process; or an activation notice from the continuity owner for an event the incident process did not originate |
| Cadence | event-driven; the re-plan re-issued at the severity row's update cadence (SET LOCALLY); the assumption return once a year in stage 1 of the capacity cycle |
| Scope in | receipt · scope confirmation · the re-plan (demand under the event, supply lost and recoverable, requirement by supply node, levers) · communication to the continuity command · the reverse check · the post-event review · the assumption return |
| Scope out | the activation decision and the command structure · the incident process · the placement lever's mechanics (GP-502) · the forecast override (GP-503) · platform degradation (GP-504) |
| Inputs | the nine-field record · the live picture of capacity, capability and constraint · the scenario catalog · the configuration archive (GP-502) |
| Outputs | the crisis re-plan, signed, with expiry · situation report · step-down record with evidence · post-event review · assumption pack |
| Upstream | real-time desk · continuity owner · forecasting seat · placement seat |
| Downstream | continuity command · operations leaders (who own the outcomes) · scheduling · the capacity cycle · post-mortem and RCA |
| Resources | incident ledger · roster and capability record · a capacity model that re-runs in hours · a report channel that survives the primary platform; platforms at L3 only |
| Decision points | record complete? · what is in scope? · which event class? · do the levers exceed the tier? · impact confirmed neutral? |
| Authority tier | receipt at tier 1 (real-time analyst) · scope confirmation and levers inside the configuration archive at tier 3 (ROC duty lead) · levers outside it at tier 4 · a changed client commitment to the executive sponsor by exception; whether the wire carries authority to move work is settled above the function |
| Risk and compliance flags | emergency schedule changes under working-time law · overtime caps · works-council rights over temporary hours · client notification clauses · a step-down on projected rather than measured recovery |
| Variant-prone steps | notification where a works council must see an emergency schedule · recoverable supply at a single-site supply node · the lever menu where a contract forbids overflow |
| Automation candidates | seven L2 sub-steps |

## L1 flow (owner seat per step; decisions are questions)

1. Receive the trigger: the record at severity 1 or 2, or the activation notice — real-time analyst.
2. Is the record complete on its nine fields? If not, correct it; the clock does not stop — real-time analyst.
3. Confirm scope: supply nodes, client portfolios, channels and languages affected, and those confirmed unaffected — ROC duty lead.
4. Which event class does the record map to, and does the archive hold an entry for it? — capacity planner.
5. Estimate demand under the event by channel and horizon, through GP-503 — forecasting lead.
6. Count supply lost and supply recoverable by supply node, with time to recover — ROC duty lead.
7. Compute the revised requirement by supply node at the crisis service target, and the gap — capacity planner.
8. Choose the levers: staffing posture, overtime and time-off reversal, skill collapse, routing fallback, placement under duress, partner surge — ROC duty lead.
9. Do the levers exceed the duty lead's tier? If yes, to the function head; if a client commitment changes, to the executive sponsor — ROC duty lead.
10. Issue the re-plan and situation report to the continuity command and operations — continuity liaison, the function's seat on the wire.
11. Re-estimate and re-issue at the row's cadence until the step-down criterion is met (loop to 5) — real-time analyst.
12. Is the impact confirmed neutral? Service, backlog, supply and platform all measured inside band for the step-down window — ROC duty lead.
13. Step down: unwind levers, expire emergency placements, record the evidence; the continuity owner closes activation on its side — ROC duty lead.
14. Run the post-event review with an independent moderator; feed the catalog, the archive, the collision calendar and the problem record — process owner.
15. Return the continuity plan's capacity assumptions to the capacity cycle once a year — capacity planner.

## L2 step table

Thresholds, windows and system names read SET LOCALLY.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Log receipt with timestamp and zone | real-time analyst | record or notice | receipt entry | minutes | N | receipt checklist |
| 2 | 2.1 Test the nine fields; return if any is missing | real-time analyst | record | pass, or return naming the field | minutes | Y | receipt checklist |
| 3 | 3.1 Draft and confirm the scope sheet with supply-node owners | ROC duty lead | record; routing state | confirmed scope | SET LOCALLY | N | scope sheet |
| 4 | 4.1 Map the record to an event class and archive entry | capacity planner | scenario catalog | event class; entry or gap | minutes | N | event-class table |
| 5 | 5.1 Request the graded demand estimate (GP-503) | forecasting lead | scope; event class | demand by channel and horizon | SET LOCALLY | N | override request form |
| 6 | 6.1 Count supply lost from roster and platform state | ROC duty lead | roster; platform health | supply lost [C] | SET LOCALLY | Y | supply sheet |
| 6 | 6.2 Count supply recoverable and time to recover | ROC duty lead | archive entry; capability record | supply recoverable [E] | SET LOCALLY | N | supply sheet |
| 7 | 7.1 Compute requirement and gap by supply node at the crisis target | capacity planner | demand; supply; target | requirement and gap [C] | SET LOCALLY | Y | re-plan template |
| 8 | 8.1 Draw levers from the menu in tier order | ROC duty lead | gap; menu; archive | lever set with tier per lever | SET LOCALLY | N | lever menu |
| 9 | 9.1 Obtain tier 4 sign-off where any lever requires it | function head | lever set | signed re-plan | SET LOCALLY | N | re-plan template |
| 10 | 10.1 Issue re-plan and situation report at the row's cadence | continuity liaison | signed re-plan | report; issue log | per cadence | Y (draft) | situation-report template |
| 11 | 11.1 Re-run steps 5 to 7 on new actuals | real-time analyst | actuals | revised re-plan | per cadence | Y (compute) | re-plan template |
| 12 | 12.1 Measure the four signals over the window; decide | ROC duty lead | actuals | reverse-check record | SET LOCALLY | Y (measure only) | reverse-check sheet |
| 13 | 13.1 Unwind levers in reverse order; expire placements | ROC duty lead | lever set; expiry register | unwind record | SET LOCALLY | N | unwind checklist |
| 14 | 14.1 Review on the nine fields and the re-plan versions | process owner | records | findings; problem record; revisions | within SET LOCALLY days | N | review agenda |
| 15 | 15.1 Compile the plan's capacity assumptions and the year's variance | capacity planner | plan; reviews | assumption pack | annual | Y (draft) | assumption return form |

## Variants

- **Statutory.** Works-council co-determination over temporary hours inserts a notification step between 8 and 10 for an emergency schedule change: liaison owns, function head approves, a row. Overtime caps and rest minimums: parameters of the lever menu, SET LOCALLY.
- **Contractual.** A client contract forbidding overflow or fixing a notification clause parameterizes steps 8 and 10 through the constraint register: SET LOCALLY, no row.
- **Structural.** A single-site supply node with no remote-work capability has no recoverable supply at 6.2: varied, reviewed at each annual return until the capability exists.
- **Transitional.** A predecessor organization's crisis cell still receiving the trigger: a parallel notification under a row until the dated cut-over.

## L3 register (names only; the content is the function's)

| Job aid | Anchored to | Form |
|---|---|---|
| Receipt checklist and nine-field completeness test | steps 1–2 | runbook |
| Scope sheet and supply-node-owner confirmation list | step 3 | runbook |
| Event-class table and archive index | step 4 | work instruction |
| Crisis re-plan template, with grades on every number | steps 5–9 | work instruction |
| Lever menu with the authority tier per lever | steps 8–9 | playbook |
| Situation-report template and cadence per severity row | steps 10–11 | work instruction |
| Reverse-check sheet: four signals, bands and window | step 12 | runbook |
| Unwind checklist | step 13 | runbook |
| Post-event review agenda | step 14 | playbook |
| Assumption return form | step 15 | work instruction |

## Automation candidates (ranked by how easy a catch rate is to publish)

1. Completeness check (2.1): deterministic; a missing field is the commonest cause of a late re-plan [A].
2. Supply-lost count (6.1): a query against roster and platform state; after #1 because its catch rate depends on the roster being reconciled first.
3. Requirement computation (7.1): arithmetic on graded inputs; after #2 because it inherits #2's output and its weakest grade.
4. Re-run at cadence (11.1): the same arithmetic under time pressure; after #3 because fewer checks run between versions.
5. Reverse-check measurement (12.1): four signals against four bands; after #4 because the bands are set locally per supply node, so one catch rate does not carry across the estate.
6. Situation-report draft (10.1): prose, whose errors are counted by review rather than by rule.
7. Assumption pack (15.1): once a year, so a catch rate accrues slowly.

Never a candidate: the step-down decision (12.1's decision, not its
measurement), where the signer produces the evidence rather than approves a
proposal, and closing the event is the continuity owner's; the post-event
review, which belongs with the people who worked the incident.

Block 4 — gp-502-placement-under-duress.md

<!-- Derived from [[Placement Under Duress (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-502 — Placement Under Duress

Moves work between supply nodes when a severity 1 or 2 event has removed
part of the supply or the demand picture: the second product of the
continuity wire, called by GP-501 step 8. Continuity is placement under
duress, a changed constraint set answered by re-deriving placement rather
than executing a static binder. The partner decides activation and holds
command; this card owns its method: the archive of configurations
pre-computed per event class, the placement gate run in its emergency form,
a dated expiry on every emergency placement, and the unwind.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-502 · local id SET LOCALLY |
| Class | both: the placement on the real-time clock; the archive refresh on the strategic clock |
| Trigger | a crisis re-plan (GP-501) that calls the placement lever; the archive refresh on its cadence |
| Cadence | event-driven; archive refreshed quarterly against the current constraint register (SET LOCALLY; quarterly typical [A]) and after every post-event review |
| Scope in | the archive · the emergency gate · the placement order · the expiry register · the unwind · the archive refresh |
| Scope out | activation and command (continuity owner's) · the routine gate (GP-401) · routing-change mechanics (Vendor Change Control for Routing) · contract negotiation |
| Inputs | the re-plan · the archive entry for the event class · constraint register and supply cards (Placement Engine Architecture) · capability record (skills, languages, permissions) · expiry register |
| Outputs | gate output page in emergency form · placement order (what moves where, from when, until when) · expiry entry · unwind order · archive revision and recompute-log entry |
| Upstream | GP-501 · the placement function's register and cards · the capability record |
| Downstream | supply-node owners receiving the work · routing change control · real-time desk · continuity command (informed) · GP-501 step 13 (the unwind) |
| Resources | archive · constraint register · capability record · routing change path · expiry register; platforms at L3 only |
| Decision points | archive entry exists? · pre-run tests still current? · a never-suspended test fails? · move exceeds the tier? · extend or unwind at expiry? |
| Authority tier | moves inside the archive at tier 3 (ROC duty lead) · moves outside it or across a contractual boundary at tier 4 · a changed client promise to the executive sponsor by exception; all of this where leadership has given the wire authority to move work, otherwise the order goes as a proposal to operations and the continuity command |
| Risk and compliance flags | contractual eligibility (consent, data residency, service credits) · language viability · data-access permissions at the receiving supply node · cross-border employment rules · an emergency placement that outlives its event |
| Variant-prone steps | the gate where works-council notice precedes a move · the order where a client requires consent · the routing step where a partner platform is not integrated |
| Automation candidates | eight L2 sub-steps |

## L1 flow (owner seat per step; decisions are questions)

1. Receive the placement call from the re-plan with scope and gap by supply node — placement lead.
2. Does the archive hold a configuration for this event class? If not, run the emergency gate from the register and log the archive gap — placement lead.
3. Load the entry: bodies of work, destination supply nodes, routing changes, pre-run tests with dates — placement analyst.
4. Are the pre-run tests still current against the register's dates? Re-run any stale row — placement analyst.
5. Run the emergency gate: contractual eligibility and language viability always; continuity in reversed form (does the move concentrate surviving work on one supply node); pooling cost, coverage floor and construct fit suspended and recorded as suspended-by-policy, never silently skipped — placement analyst.
6. Does a never-suspended test fail? If yes, the move is unavailable; return to the re-plan for another lever — placement lead.
7. Set the expiry: date and time on every emergency placement, with a review before it — placement lead.
8. Does the move exceed tier 3? If yes, to the function head; if a client promise changes, to the executive sponsor — ROC duty lead.
9. Issue the order to supply-node owners and raise the routing change where the wire has authority; otherwise as a proposal to operations and the continuity command — placement lead.
10. Confirm the move landed: routing, capability record, receiving supply node's acknowledgement — real-time analyst.
11. At the review before expiry: is the re-plan still active? If yes, extend with a stated reason and new date; if no, unwind — placement lead.
12. Unwind: reverse the routing change, return the work, confirm, close the order — placement lead.
13. Record the outcome in the recompute log; revise the archive entry — placement analyst.
14. Refresh the archive on cadence: re-run every entry's tests against the current register and cards — placement analyst.

## L2 step table

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Log the call with the re-plan version | placement lead | re-plan | placement call entry | minutes | N | order template |
| 2 | 2.1 Look up the event class in the archive index | placement lead | event class | entry, or gap logged | minutes | N | archive index |
| 3 | 3.1 Load bodies of work, destinations, routing changes, pre-run tests | placement analyst | archive entry | loaded configuration | minutes | N | archive entry template |
| 4 | 4.1 Compare each pre-run test's date to its register rows | placement analyst | entry; register | current or stale per test | minutes | Y | currency check |
| 4 | 4.2 Re-run stale tests | placement analyst | register; cards | refreshed results | SET LOCALLY | Y (compute) | gate checklist |
| 5 | 5.1 Read contractual eligibility per body of work and destination | placement analyst | register | pass or fail, clause cited | minutes | Y (lookup) | gate checklist |
| 5 | 5.2 Test language viability at each destination | placement analyst | capability record | pass or fail per language | minutes | Y (compute) | gate checklist |
| 5 | 5.3 Record suspended tests as suspended-by-policy | placement analyst | — | output page rows | minutes | N | gate checklist |
| 6 | 6.1 Decide availability of the move | placement lead | output page | available, or returned to GP-501 | minutes | N | gate checklist |
| 7 | 7.1 Set expiry and review date; enter in the register | placement lead | order | expiry entry | minutes | N | expiry register |
| 8 | 8.1 Sign at tier 3, or obtain tier 4 sign-off where required | ROC duty lead; function head | order; output page | signed order | SET LOCALLY | N | order template |
| 9 | 9.1 Issue the order, or the proposal where the wire carries no authority; raise the routing change | placement lead | signed order | order issued; change raised | SET LOCALLY | Y (draft) | order template |
| 10 | 10.1 Verify routing, capability record and acknowledgement | real-time analyst | routing state; record | landed, or exception | SET LOCALLY | Y (verify) | landing checklist |
| 11 | 11.1 Review before expiry; extend with reason or unwind | placement lead | re-plan status | extension entry or unwind order | minutes | N | expiry register |
| 12 | 12.1 Reverse the routing change; return work; confirm; close | placement lead | order | closed order | SET LOCALLY | N | unwind checklist |
| 13 | 13.1 Write the recompute-log entry; revise the archive | placement analyst | outcome | log entry; revision | SET LOCALLY | Y (draft) | recompute log |
| 14 | 14.1 Re-run every entry's tests; retire entries that fail | placement analyst | register; cards | refreshed archive; gap list | per cadence | Y (compute) | archive refresh procedure |

## Variants

- **Statutory.** Data-residency and cross-border employment limits are register entries the eligibility test reads: SET LOCALLY, no row. Works-council notice before work moves inserts a step between 8 and 9: liaison owns, function head approves, a row.
- **Contractual.** A client that forbids overflow: a register entry, no row. A client requiring consent before relocation: a consent step before step 9 under a row, reviewed at renewal.
- **Structural.** A destination whose partner platform takes no routing change from the function: step 9 varied to a manual hand-off through the partner's oversight owner, with a review date.
- **Transitional.** A predecessor organization's archive still in its old form: a row expiring at the first refresh on the shared register.

## L3 register (names only; the content is the function's)

| Job aid | Anchored to | Form |
|---|---|---|
| Archive index and entry template | steps 2–3 | work instruction |
| Currency check against register dates | step 4 | work instruction |
| Emergency gate checklist: suspended-by-policy, never suspended, reversed | step 5 | runbook |
| Expiry register and its review alarms | steps 7, 11 | work instruction |
| Placement order template and tier table | steps 8–9 | work instruction |
| Landing checklist | step 10 | runbook |
| Unwind checklist | step 12 | runbook |
| Archive refresh procedure and gap log | steps 13–14 | playbook |

## Automation candidates (ranked by how easy a catch rate is to publish)

1. Currency check (4.1): a date comparison; a stale pre-run test is the commonest way an archive entry fails [A].
2. Eligibility lookup (5.1): a clause read from the register; after #1 because it depends on the register row being current.
3. Language-viability computation (5.2): coverage against the capability record; after #2 because the record drifts between refreshes.
4. Stale-test re-run (4.2): after #3 because it can re-run any of the six tests, so no single catch rate covers it.
5. Archive refresh (14.1): the same re-run on a calendar across every entry; after #4 because errors accumulate before anyone reads the result.
6. Landing verification (10.1): routing and record state against the order; after #5 because routing state is read from platforms that differ per supply node.
7. Order draft (9.1): a document whose errors the signer finds, not a rule.
8. Recompute-log entry (13.1): written after the event; a miss is cheap and slow to detect.

Never a candidate: the extension decision (11.1), the point at which an
emergency placement becomes a permanent one, and a split pool acceptable for
a week is paid for every week it outlives its event; the availability
decision (6.1), because a hard constraint excludes and never lowers a score,
and the signer must see the clause.

Block 5 — gp-503-judgmental-forecasting-in-crisis.md

<!-- Derived from [[Judgmental Forecasting in Crisis (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-503 — Judgmental Forecasting in Crisis

The demand estimate a workforce function produces when a severity 1 or 2
event has made its statistical forecast invalid. The method is on the wiki
page Judgmental Forecasting and is not restated; this card adds the
operating process the crisis demands: who may override at which horizon,
what grade of evidence an override must carry, how long it stands before
the baseline returns, and how it is scored afterwards. It supplies step 5 of
GP-501. Judgmental adjustments are as likely to worsen a forecast as improve
it unless they are large, documented and made on information the model could
not have; a crisis is the case where the model certainly lacks the
information and the pressure to adjust is highest, so the override is both
permitted and governed.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-503 · local id SET LOCALLY |
| Class | both: the override on the real-time clock; the scoring on the strategic clock |
| Trigger | a demand estimate requested by GP-501; a containment collapse under GP-504; or the forecasting lead's declaration that the model is invalid on the entry criterion (actuals outside the model's interval for a run of consecutive intervals, SET LOCALLY) |
| Cadence | event-driven; re-evaluated at the severity row's update cadence; scored at the post-event review and again in the quarterly review of GP-106 |
| Scope in | the model-invalid declaration · freezing the baseline · evidence and its grades · the override tier by horizon and size · the expiry · the scenario set · the scoring · the adjustment of override authority |
| Scope out | the method (the concept page) · the routine override outside a crisis · the re-plan that consumes the estimate (GP-501) · the intraday reforecast in normal operation (GP-104) |
| Inputs | the stored baseline · incident record and scope · signals with a source grade · the scenario catalog's event class · the collision calendar |
| Outputs | override record (baseline, adjustment, grade, tier, expiry, reason) · scenario set with the override as base · expiry notice · paired score per override, adjuster and event class |
| Upstream | GP-501 (the request) · real-time desk (signals) · continuity command (event information through the liaison) |
| Downstream | GP-501 step 7 (the requirement) · scheduling · GP-106 · Forecast Value Added |
| Resources | forecast system of record with versioning · override log · signal intake · scoring workbook; platforms at L3 only |
| Decision points | model invalid? · evidence graded well enough for the tier? · renew, revise or expire? · adjust authority? |
| Authority tier | tier 1 (real-time analyst) for the intraday horizon inside a band, SET LOCALLY · tier 3 (operations manager or ROC duty lead) for the day-to-week horizon or outside the band · tier 4 for an override that changes the plan of record or a client commitment · executive sponsor by exception |
| Risk and compliance flags | an override made under stakeholder pressure rather than on evidence · an override carried past its event · a client-contracted forecast lock · an [A] size carrying a plan, which the number-grade rule forbids |
| Variant-prone steps | the authorization step where a client contracts the forecast · the baseline step for a channel with no statistical model · the tier table for predecessor-organization forecasters |
| Automation candidates | five L1 steps |

## L1 flow (owner seat per step; decisions are questions)

The card carries no L2 table; its sub-steps are the method's (Judgmental
Forecasting; paired-evaluation arithmetic on Forecast Value Added in
Workforce Management). Copy the method's L2 through CP-OPS-001 and keep this
flow as the crisis wrapper.

1. Is the model invalid? Test the entry criterion, or accept the GP-501 request as the declaration — forecasting lead.
2. Freeze and store the unadjusted baseline, versioned, before any adjustment is discussed — forecast analyst.
3. Name the tier the override will need, from its horizon and its size relative to the baseline — forecasting lead.
4. Collect the evidence: each signal with its source grade in words, the queues it names, a direction and a size with a range; a signal missing any of the three stays proposed — forecast analyst.
5. Is the evidence graded well enough for the tier? An [A] size with no range may carry an intraday override at tier 1 and nothing larger; a re-plan requirement needs an [E] with a range — forecasting lead.
6. Build the scenario set with the override as base case and bounds above and below — forecast analyst.
7. Set the override's expiry: hours or days by event class (SET LOCALLY), after which the baseline returns unless renewed — forecasting lead.
8. Authorize at the tier named in step 3; the signer writes a reason, not a click — the seat at that tier.
9. Issue the estimate, graded, to GP-501 and the real-time desk — forecast analyst.
10. At each cadence: does the evidence still hold? Renew with new evidence, revise, or let it expire — forecasting lead.
11. At expiry: the baseline returns, or the event enters the collision calendar as a known event with its own adjustment — capacity planner.
12. Score each override against its stored baseline by the paired method, per override, adjuster and event class; pass the scores to GP-106 — forecast analyst.
13. Adjust override authority on the scores: retain, retrain or remove — function head.

## Variants

- **Statutory.** None known; the class takes no row.
- **Contractual.** A client whose contract fixes a forecast lock, or supplies the forecast: a client-notification step between 8 and 9 under a row owned by the account seat, reviewed at renewal; the lock itself is on Forecast Lock Process.
- **Structural.** A channel with no statistical model (typically an asynchronous backlog) has no baseline to freeze at step 2; the override is the forecast, and the step is varied with a review date until a model exists.
- **Transitional.** Forecasters from a predecessor organization keep their former override tier under a row until certified on the shared tier table, with an expiry the standards committee dates.

## L3 register (names only; the content is the function's)

| Job aid | Anchored to | Form |
|---|---|---|
| Entry criterion sheet: the model-invalid test and its run length | step 1 | work instruction |
| Baseline freeze procedure in the forecast system | step 2 | work instruction |
| Tier table by horizon and size band | steps 3, 8 | work instruction |
| Override request form and the evidence-grade table | steps 4–5 | work instruction |
| Scenario-set template per event class | step 6 | playbook |
| Expiry defaults by event class and the override log | steps 7, 10, 11 | work instruction |
| Paired-scoring workbook | step 12 | work instruction |
| Authority review agenda | step 13 | playbook |

## Automation candidates (named at L1; ranked by how easy a catch rate is to publish)

1. Baseline freeze (step 2): a versioned save; an override made before the baseline is stored cannot be scored.
2. Entry-criterion detector (step 1): actuals against the model's interval over a run length; after #1 because the run length is set locally and a false trip is known only in hindsight.
3. Override log and expiry alarm (step 7): a register with dates; after #2 because a missed expiry is detected only when a stale adjustment turns up in a later forecast.
4. Scenario-set computation given an override (step 6): arithmetic on the base case; after #3 because its inputs are [E] figures whose ranges a person supplied.
5. Paired scoring (step 12): the comparison is computed, the authority decision is not; last because a score is publishable only once the event has closed and the actuals are in.

Never a candidate: the override itself (step 8), because an automated
override is a model, and the method's premise is that the adjuster holds
information the model does not; the authority adjustment (step 13), because
a forecaster's track record under pressure is the only evidence that
separates information from bias.

Block 6 — gp-504-platform-degradation-runbook-and-buffer-staffing.md

<!-- Derived from [[Platform Degradation Runbook and Buffer Staffing (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-504 — Platform Degradation Runbook and Buffer Staffing

The event in which an automation or AI containment layer degrades or fails
and the contacts it was resolving return to the human queue. Two parts share
one card because one sizes the other: the runbook, from entry condition
through severity mapping, buffer activation, routing fallback, communication
and verification to exit; and the standing buffer policy, sized from the
containment at risk and the platform's recovery time. The card owns its
method and draws on AI Containment Rate and Its Workforce Implications and
AI Agent Failure Modes and Recovery. A degradation at severity 1 or 2 fires
the wire and calls GP-501; continuity remains the partner that owns
activation. The buffer exists because the circuit-breaker pattern assumes a
fallback, and a human queue is staffed hours in advance or not at all.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-504 · local id SET LOCALLY |
| Class | both: the runbook is real-time; the buffer policy is strategic, re-sized each capacity cycle |
| Trigger | the entry condition from monitoring: containment by interval below its band for a run of intervals, the circuit breaker open, or a platform health alert from the platform owner (values SET LOCALLY) |
| Cadence | event-driven runbook; the buffer re-sized monthly from the failure record inside the capacity cycle and re-based annually |
| Scope in | entry · discrimination from a mix shift · severity mapping · returning load · buffer activation · routing fallback · communication · verification · exit · review · buffer re-size |
| Scope out | diagnosis and repair of the platform (platform owner) · the breaker's own thresholds · the supervision ratio · the incident process this runbook runs inside |
| Inputs | containment by interval and its forecast · breaker state · the automated supply node's supply card and drift terms · buffer policy · roster · severity matrix |
| Outputs | incident record (nine fields) · buffer activation and routing fallback orders · communications · verification and exit records · buffer-size recommendation |
| Upstream | platform owner's monitoring · automation overseer · real-time desk |
| Downstream | the human queues and their supply-node owners · GP-501 at severity 1 or 2 · GP-302 · the capacity cycle · post-mortem and RCA |
| Resources | monitoring feed · routing control at contact-type grain · incident ledger · a buffer roster of cross-trained agents · the sizing model; platforms at L3 only |
| Decision points | degradation or mix shift? · which severity row? · inside the buffer or beyond it? · containment back at baseline for the exit window? |
| Authority tier | entry and record at tier 1 · buffer activation at tier 2 or 3 by the lever's own tier · levers beyond the buffer through GP-501 · the half-open test is the platform owner's call with the ROC duty lead's concurrence · a changed client commitment to the executive sponsor by exception |
| Risk and compliance flags | contacts trapped between the two supply nodes (an escalation loop) · a human-handling clause in a client contract · overtime and rest rules on the buffer · an exit taken before containment is confirmed |
| Variant-prone steps | the fallback step on a platform without contact-type routing · communication where a client contracts a human-handling service level · the buffer where a works council governs emergency schedule changes |
| Automation candidates | eight L2 sub-steps |

## L1 flow (owner seat per step; decisions are questions)

1. Detect the entry condition: containment below band for the run length, the breaker open, or a platform alert — automation overseer.
2. Is this platform degradation, or a contact-mix shift that lowers containment with the platform intact? Check the intent mix and health telemetry — automation overseer.
3. Open the incident record and map the severity, using containment at risk as the impact parameter; at severity 1 or 2 the wire fires and GP-501 opens — real-time analyst.
4. Compute the returning load by interval: offered volume × containment lost × the share of contained contacts that return to a human rather than abandon × handle time under escalation enrichment — real-time analyst.
5. Is the returning load inside the standing buffer? If not, the re-plan's levers are called — ROC duty lead.
6. Activate the buffer: cross-trained agents to the returning queues, off-phone pulls cancelled, overtime offered, time off reversed, in that order — ROC duty lead.
7. Apply the routing fallback: graceful degradation by contact type where supported, full fallback where the breaker is open; confirm the human queue is receiving — real-time analyst (platform owner contributes).
8. Communicate per the severity row: supply-node owners, operations, the continuity owner at severity 1 or 2, the customer-messaging request — real-time analyst.
9. Verify: human-queue service and backlog inside band at the degraded target, no escalation loop, buffer attendance — real-time analyst.
10. Is containment back at baseline for the exit window after the half-open test? Step down on measured recovery, never projected — ROC duty lead, on the automation overseer's measurement.
11. Exit: restore routing in stages, release the buffer, close the record with the nine fields — real-time analyst.
12. Review: the platform owner's post-incident review and the function's post-event review on one timeline — process owner.
13. Re-size the buffer from the record: update the failure-duration distribution and the containment at risk; recommend the size to the capacity cycle — capacity planner.

## L2 step table

Buffer sizing (13.1) is the card's own arithmetic: capacity in reserve equals
the returning load at a chosen percentile of the failure-duration
distribution, net of the levers the function can raise inside the recovery
time, at the degraded service target; percentile and target SET LOCALLY.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Compare containment by interval to its band; read breaker state and alerts | automation overseer | monitoring feed | entry fired, timestamp and zone | per interval | Y | entry-condition sheet |
| 2 | 2.1 Compute intent-mix and health-telemetry deviation from baseline | automation overseer | telemetry | deviation figures | minutes | Y (compute) | discrimination checklist |
| 2 | 2.2 Decide: degradation, or mix shift routed to the reforecast | automation overseer | deviation figures | decision | minutes | N | discrimination checklist |
| 3 | 3.1 Open the record; set severity on containment at risk | real-time analyst | matrix; load estimate | record at a severity row | minutes | Y (propose) | severity mapping table |
| 3 | 3.2 Notify per the row; fire the wire at severity 1 or 2 | real-time analyst | record | notifications sent | minutes | N | severity mapping table |
| 4 | 4.1 Compute returning load by interval and queue [C] | real-time analyst | volume; containment lost; return share [E]; enriched handle time [E] | load by interval | minutes | Y | returning-load calculator |
| 5 | 5.1 Compare load to the buffer; decide | ROC duty lead | load; buffer roster | inside, or GP-501 called | minutes | N | buffer policy |
| 6 | 6.1 Raise levers in policy order | ROC duty lead | buffer roster; lever menu | activation order | SET LOCALLY | Y (propose) | buffer activation checklist |
| 7 | 7.1 Change routing by contact type or in full | real-time analyst; platform owner | fallback map | routing changed | SET LOCALLY | N (the breaker does it; the human verifies) | fallback runbook |
| 7 | 7.2 Confirm the human queue is receiving | real-time analyst | queue state | receipt confirmed | minutes | N | fallback runbook |
| 8 | 8.1 Send communications per the row | real-time analyst | templates | sent log | minutes | Y (draft) | communication templates |
| 9 | 9.1 Measure service, backlog, loop count, attendance | real-time analyst | actuals | verification record | per interval | Y (measure) | verification criteria |
| 10 | 10.1 Concur in the platform owner's half-open test; read the overseer's containment measurement over the exit window; decide | ROC duty lead | test result; actuals | exit decision | window SET LOCALLY | N | exit checklist |
| 11 | 11.1 Restore routing in stages; release buffer; close with nine fields | real-time analyst | order; record | closed record | SET LOCALLY | N | exit checklist |
| 12 | 12.1 Joint review on one timeline | process owner | both records | findings; problem record | within SET LOCALLY days | N | review agenda |
| 13 | 13.1 Update the failure-duration distribution and containment at risk; compute the size at the percentile | capacity planner | records; policy | buffer size [C] | monthly | Y (compute) | sizing model |
| 13 | 13.2 Recommend the size to the capacity cycle; re-base annually | capacity planner | size; cost | recommendation | monthly | N | sizing model |

## Variants

- **Statutory.** Overtime caps and rest minimums on the buffer: parameters, SET LOCALLY. Works-council co-determination over temporary hours inserts a notification step between 5 and 6, before activation: liaison owns, function head approves; where the agreement provides an emergency exception the step becomes a notification immediately after activation and the row says so.
- **Contractual.** A partner's surge clause: a parameter of the lever menu, no row. A client human-handling service level: a client-notification step at step 8 under a row, reviewed at renewal.
- **Structural.** A supply node with no automated layer does not run the card: marked not inventoried on the shell. A platform that cannot route by contact type: step 7 varied to all-or-nothing fallback, with a review date.
- **Transitional.** An automated supply node migrating platforms carries two breaker definitions under a row expiring at cut-over.

## L3 register (names only; the content is the function's)

| Job aid | Anchored to | Form |
|---|---|---|
| Entry-condition sheet: bands, run length, breaker states | step 1 | work instruction |
| Discrimination checklist: degradation versus mix shift | step 2 | runbook |
| Severity mapping table for degradation events | step 3 | work instruction |
| Returning-load calculator with graded inputs | step 4 | work instruction |
| Buffer policy and buffer roster | steps 5–6 | playbook |
| Fallback runbook per platform | step 7 | runbook |
| Communication templates per severity row | step 8 | work instruction |
| Verification criteria and exit checklist | steps 9–11 | runbook |
| Joint review agenda | step 12 | playbook |
| Sizing model and its annual re-base | step 13 | work instruction |

## Automation candidates (ranked by how easy a catch rate is to publish)

1. Entry detection (1.1): thresholds against a feed already measured by interval; the onset-to-detection gap is the one gap the function can shorten without touching the platform.
2. Returning-load computation (4.1): arithmetic on graded inputs; after #1 because two inputs, the return share and the enriched handle time, are [E].
3. Buffer re-size (13.1): the same arithmetic over the failure record; after #2 because it runs monthly, so a catch rate accrues slowly.
4. Discrimination computation (2.1): deviation from baseline; after #3 because the baseline moves with the contact mix, which is the thing being tested.
5. Verification measurement (9.1): four signals against bands; after #4 because the bands are set locally per supply node.
6. Severity proposal (3.1): the matrix applied to the load; after #5 because the load is [E] and a person sets the row.
7. Buffer activation proposal (6.1): inside the guardrails of GP-302; after #6 because it proposes changes to people's schedules, where a miss costs more than a wrong number.
8. Communication drafts (8.1): prose, whose errors are counted by review rather than by rule.

Never a candidate: the exit decision (10.1) and the routing restoration it
authorizes, because the platform under suspicion is the one whose signals
would drive an automated exit, and supervisors of a reliable system reduce
their vigilance precisely when it degrades; the discrimination at step 2,
because a mix shift and a degradation call for opposite responses. The
buffer is a standing cost rather than an overtime line because the staffing
curve is convex: each added contact on an already-loaded operation costs
more than the last.

Block 7 — gp-505-cross-training-and-skill-mix-review.md

<!-- Derived from [[Cross-Training and Skill-Mix Review (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-505 — Cross-Training and Skill-Mix Review

The periodic review by which a workforce function checks that its skill mix
can survive the events its continuity partner plans for. The method (the
designed skill graph, the pooling-benefit arithmetic, the investment
decision, the currency policy) is on the wiki page Cross-Training and Skill
Mix Strategy and is not restated. The card adds the review between annual
decisions: the refresh of the skill-coverage matrix from the capability
record, the resilience test that asks which event classes the current mix
survives and names the binding skill where it does not, the hand-off of gaps
to the training plan, and the cadence. Continuity is a partner function; the
review is the function's standing contribution to preparedness, and its
output feeds the configuration archive of GP-502. A modest, deliberately
connected cross-training pattern captures most of the benefit of full
flexibility; its value lies in which links exist, not how many.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-505 · local id SET LOCALLY |
| Class | strategic |
| Trigger | the review calendar; a post-event review (GP-501 step 14) that finds a coverage gap; an archive refresh (GP-502 step 14) that retires a configuration for want of a skill |
| Cadence | matrix refresh and resilience test quarterly (SET LOCALLY; quarterly typical [A], matching the method page's quarterly graph audit); the full review annually, feeding GP-101 |
| Scope in | capability-record refresh and reconciliation · matrix roll-forward · resilience test per event class · gap ranking · currency enforcement · training hand-off · archive request · sign-off |
| Scope out | the investment decision and its valuation (method page) · training delivery (training function) · multi-skill scheduling · the placement decision a gap may call for |
| Inputs | capability record (skills, languages, proficiency, currency dates) · roster and the attrition forecast (GP-105) · demand by skill · the scenario catalog's event classes · the configuration archive · post-event findings |
| Outputs | refreshed skill-coverage matrix (skill by supply node by proficiency by currency) · resilience report (pass, fail with the binding skill named, or cannot-run per event class) · ranked gap list · training hand-off · archive change request · stale-edge list (an edge is a link between an agent and a skill) |
| Upstream | the capability record's steward · GP-105 · the scenario catalog · GP-501 and GP-502 |
| Downstream | training lead · GP-502 (the archive) · GP-101 (annual strategy) · scheduling (Multi-Skill Scheduling) |
| Resources | capability record as a queryable object · roster · a coverage model that can remove a supply node or a share of supply and re-route · training calendar; platforms at L3 only |
| Decision points | record current enough to run? · any critical skill or language below floor under any event class? · training, or placement and archive change? · sign |
| Authority tier | refresh and test at tier 1 (analyst seat) · training-or-placement routing at tier 3 (the placement lead sits at that tier) · hand-off and archive request at tier 4 · a hand-off that changes a partner's scope to the executive sponsor by exception |
| Risk and compliance flags | training obligations in collective agreements · works-council consultation on training measures · client-dedicated agents who may not be cross-trained onto other client portfolios · a matrix reporting skills nobody has used in months |
| Variant-prone steps | the hand-off where a works council is consulted · the reconciliation where a partner holds its own skill records · the matrix where dedication forbids a link |
| Automation candidates | five L1 steps |

## L1 flow (owner seat per step; decisions are questions)

The card carries no L2 table; its sub-steps are the method's. Copy the
method's L2 through CP-OPS-001 and keep this flow as the review wrapper. The
resilience test in step 5 is the card's own instrument and reuses the
outcome vocabulary of The Placement Gate, so a cannot-run is recorded rather
than skipped.

1. Open the review on the calendar or on a trigger, naming the event classes in scope — capacity planner.
2. Refresh the capability record: skills, languages, proficiency and currency per agent and per supply node, reconciled to the roster — workforce analyst.
3. Is the record current enough to run? If the share of stale edges exceeds the limit (SET LOCALLY), the review returns cannot-run and the data fix comes first — capacity planner.
4. Roll the matrix forward to the horizon: apply the attrition forecast and the training pipeline's scheduled output — workforce analyst.
5. Run the resilience test per event class: remove the supply the class removes (a supply node, a platform, a share of headcount), re-route per the archive, test whether every critical skill and language keeps its floor at the crisis service target — workforce analyst.
6. Does any critical skill or language fall below floor under any class? Name the binding skill per failing class — capacity planner.
7. Rank the gaps by exposure (the class's likelihood and impact from the scenario catalog) and by lead time (time to proficiency) — capacity planner.
8. List stale edges for refresher or removal under the currency policy — team leads.
9. Is each gap a training gap or a placement gap? A gap no training can close in the lead time goes to the archive as a configuration change — placement lead.
10. Hand off the training plan: skill, count, supply node, proficiency target, need-by date back-computed from the ramp — capacity planner, to the training lead.
11. Sign the review: the hand-off, the archive request and the stale-edge list — function head.
12. Publish the matrix and the resilience report; log the review; feed the annual strategy — capacity planner.

## Variants

- **Statutory.** Works-council consultation or co-determination over vocational training measures inserts a consultation step at the hand-off (step 10): liaison owns, function head approves, a row.
- **Contractual.** Client-dedicated agents forbid certain links in the matrix: a constraint-register entry read at step 5, SET LOCALLY, no row. A partner that cross-trains at its own discretion: step 10 varied to a request through the partner's oversight owner, under a row reviewed at renewal.
- **Structural.** A supply node whose routing cannot distinguish skills at the matrix's grain: step 5 varied to test at the coarser grain, with a review date.
- **Transitional.** A predecessor organization's skill records in another system: a reconciliation step at step 2 under a row expiring at the record cut-over.

## L3 register (names only; the content is the function's)

| Job aid | Anchored to | Form |
|---|---|---|
| Capability-record extract and its reconciliation to the roster | step 2 | work instruction |
| Currency limit and the cannot-run rule | step 3 | work instruction |
| Matrix layout and the roll-forward procedure | step 4 | work instruction |
| Resilience test procedure, with the event classes and the removal each implies | steps 5–6 | playbook |
| Gap ranking sheet | step 7 | work instruction |
| Currency rule and the stale-edge list | step 8 | work instruction |
| Training hand-off form | step 10 | work instruction |
| Review calendar and sign-off record | steps 1, 11 | work instruction |

## Automation candidates (named at L1; ranked by how easy a catch rate is to publish)

1. Record extract and reconciliation (step 2): a query against the system of record; skill-record drift is the review's commonest finding [A].
2. Stale-edge list (step 8): a date comparison against the currency rule; after #1 because it reads the currency dates the extract supplies.
3. Matrix roll-forward (step 4): arithmetic on the attrition forecast and the pipeline; after #2 because the attrition forecast is [E].
4. Resilience test computation (step 5): deterministic given the archive and the floor; after #3 because it depends on the archive being current, which GP-502 refreshes on its own cadence.
5. Hand-off form draft (step 10): assembled from the ranked gaps; last because its errors are found by the signer, not by rule.

Never a candidate: the sign-off (step 11), which commits training budget and
may change where work sits; the training-or-placement decision (step 9),
because routing a gap to the archive changes the function's placement rather
than its training, and the cross-training pattern and the coordination
policy that deploys it are separate design choices evaluated together. The
gap ranking is computed, but its exposure weights come from the scenario
catalog, which a person maintains.

Usage notes

Sizing. Block 1 is about 590 words, the framing rule included, and loads with every message. Blocks 2–7 are retrieved as needed; the rules file is about 1,130 words and the five card files run about 1,250 to 1,800 words each, the three cards that own their L2 (GP-501, GP-502, GP-504) being the largest because each carries its full step table.

Output. The pack emits the five localized files per card in Markdown, structured so that the L2 transfers to the fifteen-column workbook of CP-OPS-001 by hand or by script. Every automation candidate leaves the project marked flagged or released on evidence, never silently released; every emergency placement and every override leaves with a dated expiry.

Localizing. The cards carry every local value as SET LOCALLY with a seat, every variant class with its approver, and every candidate with its rank. The pack refuses to fill a value the function has not given, to name a person against a seat, to name a platform in a file marked for publication, or to write an activation, command or closure step for the workforce function: those are the continuity partner's, and a localization that contains one has crossed the wire.

Drift. Blocks 3–7 derive from the five card pages in the infobox and Block 2 from the four convention pages; a material change to any of them is the trigger to regenerate the affected block and bump the version. The severity matrix and the scenario catalog are the function's own and change on their own cadence; the cards reference them by name and never carry their values.

Scope. Nothing in the pack is specific to any organization, jurisdiction or platform. The works-council, data-residency and human-handling variants are examples of the classes, not a list of the jurisdictions or contracts a function operates under.

Change history

Version Date Change
1.0 2026-10-16 First release: instruction block with the partner-function framing rule, localization-rules.md, and one reference file per continuity-interface card (GP-501 to GP-505)

See also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Wiki:Packs/Continuity_Interface_Processes&oldid=5587"