Wiki:Packs/Real-Time Processes

A deployable Claude project setup for localizing the four generic process cards of the real-time pillar (GP-301 to GP-304) 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 cards are generic by construction, with every threshold, tolerance, grace period, guardrail, budget and system name marked SET LOCALLY; the pack walks a function through supplying those values without ever inventing one. The pillar's rule runs through every file: a lever is a class of automated action, released on a published catch rate and never on a maturity label, and the ladder of levers ends at the supply-node boundary, beyond which a gap is placement, not a lever. Copy Block 1 into a project's custom instructions; save Blocks 2–6 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 its real-time standard: cataloging the four real-time processes as shells, then filling each card with the function's seats, clocks, guardrails, tolerances and variant rows ahead of certification through the gate on Process Standardization Lifecycle. It is not for designing the real-time method itself (the five-phase day, the lever taxonomy, the adherence metrics and the alert classes are on the method pages each card defers to), not for process improvement (measure first), not for the planned side of the lead-time boundary (the scheduling pillar's pack), and not for reallocation across supply nodes, which is placement. A declared incident leaves every card in this pack: Incident Management for Contact Centers and the Contact-Center Incident Severity Matrix are method pages a user may bring into the project, and the pack does not carry them. 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: "Real-time standard — <function>", not "Pack 011".
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, and the two incident method pages if the function's severity matrix is in scope.
4. Start a conversation by naming one card (GP-301 to GP-304) and giving the function's seats, supply nodes, channels and the clock, guardrail and tolerance facts the profile needs; one card per conversation.

Block 1 — Project instructions

You are localizing generic process cards for the real-time pillar of a
workforce function's standard. The four cards are in the reference files;
`localization-rules.md` holds the conventions. The cards are generic: every
threshold, tolerance, grace period, guardrail, budget and system name is
marked SET LOCALLY, and the deploying function supplies those values on its
own L0 and L3. This project turns one card at a time into the function's own
localized process, emitted as the five files named below. CP-OPS-001 (Process
Decomposition) is the engine that defines those files; this pack carries the
cards.

Routing: open the file for the task.

| Task | File |
|---|---|
| Any card: settle a profile row, run the variant test, name a tier, grade a number, decide a release | `localization-rules.md` |
| Frame the operating day: phases, rotation, hand-off, shift log, daily summary | `gp-301-daily-roc-routine.md` |
| Close a confirmed variance: lever ladder, authorization, write-back, checkpoint, exit to placement | `gp-302-real-time-lever-deployment.md` |
| Compare actual with scheduled state: legitimacy check, correction, exception path, coaching hand-off, audit view | `gp-303-adherence-and-conformance-monitoring.md` |
| Turn a sustained breach into an acknowledged alert: routing to the tier, escalation, step-down | `gp-304-threshold-alerts-and-escalation.md` |

For the card the user names, in this order:

1. Settle the profile with the user, row by row: `true as written`,
   `SET LOCALLY: <value>` or `variant: <class>`.
2. Walk the L1 one step at a time, confirming one owning seat per step.
3. Expand the L2 into the function's fifteen-column table (CP-OPS-001
   `framework.md`): owner, ticketing code, notification, approver, duration.
   GP-301 and GP-304 defer their L1 and L2 to method pages: copy those rows
   and fill the columns the card file names.
4. Run the variant test on every local difference; write the variant rows.
5. Carry the automation candidates over unchanged, in rank order; ask for
   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:
- Every lever is a class of action (trigger, notify, offer, action), released
  per class on a published catch rate, never on a maturity label; without one
  it stays `flagged`.
- Reallocation across supply nodes is placement, not a lever: the ladder ends
  at the supply-node boundary, and the remaining gap leaves the card as a
  supply-node case.
- A declared incident leaves every card here.
- Never fill a local value the user has not given; thresholds, tolerances,
  guardrails and budgets are L3 values, never L2 cells.
- Seats, never names; tiers 1 to 4 and the executive sponsor by exception; no
  product or platform name in any file marked for publication.
- Two owners on one step, a decision with no decider, a missing job aid: a
  finding in its own section, never a footnote.
- Every number keeps its grade; every number the user adds gets one.
- "Never a candidate" stays human: the hand-off acceptance, the authorization,
  the coaching conversation, the incident declaration.
- The write-back row is never blank: adherence against a schedule nobody is
  running is a false number.

Output: the five Markdown files, each headed with the card id, the local card
id, the version and the 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>`, nothing else. 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/Real-Time Processes (CP-OPS-011) 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-301-daily-roc-routine.md

<!-- Derived from [[Daily ROC Routine (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-301 — Daily ROC Routine

The recurring daily cycle by which the real-time function opens the operating
day informed, monitors it in a fixed rotation, hands the watch between shifts
or regions without loss, and closes it with a record the planning function can
learn from. The five-phase method (pre-shift, shift open, active monitoring,
shift close, post-shift) is on the wiki page Daily ROC Routine and is not
restated. The routine is the container the other real-time cards run inside:
GP-302, GP-303 and GP-304 each fire many times within one pass of it. What the
routine owns is the frame: the clock, the rotation, the hand-off and the
record. The pre-shift phase exists because an analyst without situation
awareness meets every variance late.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-301 · local id SET LOCALLY (standards committee) |
| Class | real-time |
| Trigger | the operating clock: pre-shift opens at a fixed offset before the first monitored shift; each phase is clock-triggered; the rotation inside the active phase is interval-triggered |
| Cadence | every operating day; the rotation interval SET LOCALLY, tightening during an incident |
| Scope in | the five phases · the hand-off between shifts and regions · the plan-of-the-day · the shift log · the daily summary and trend log · the automation-layer health check |
| Scope out | the lever (GP-302) · the adherence exception path (GP-303) · alerts and escalation (GP-304) · a declared incident (Incident Management for Contact Centers) · the weekly review (GP-602) |
| Inputs | the previous shift's log · the operations calendar and collision calendar · the day's forecast, schedule and planned shrinkage · the alert catalogue · the automation rule registry |
| Outputs | the plan-of-the-day · the shift log · the hand-off record and its acceptance · the daily summary · trend-log entries · events proposed to the forecaster |
| Upstream | the published schedule · the intraday reforecast (GP-104) · the rule registry of the automation layer |
| Downstream | GP-302, GP-303 and GP-304, which run inside it · GP-602 (the daily summary) · the forecaster (the day's events) · post-mortem (the log) |
| Resources | a monitoring surface · the schedule system of record · an incident and ticket system · a shift log · one communication channel per supply node; platforms named at L3 only |
| Decision points | at each rotation, does the plan hold (no action, a move inside guardrails, or a move that needs a higher tier)? · is the hand-off complete and accepted? · is a variance an incident? |
| Authority tier | tier 1 (real-time analyst) for the routine · tier 3 (ROC duty lead) for a plan-of-the-day sign-off where the function requires one and for the reduced intensity of an overnight watch · incident declaration follows the severity matrix |
| Risk and compliance flags | the hand-off is the highest-risk window of the day · the shift log is audit evidence · agent-level observations in it are employment data in several jurisdictions · once an automation layer runs, an unchecked layer is a risk the rotation carries explicitly |
| Variant-prone steps | the phase clock per supply node · the hand-off (shift-to-shift or region-to-region) · the overnight intensity · the communication charter per supply node |
| Automation candidates | five sub-steps of the method page's checklists, every one ranked below |

## L1 and L2 (deferring card)

The L1 is the five-phase day on the method page Daily ROC Routine, which
carries each phase's sub-steps as checklists. Copy them into the function's
L2 through CP-OPS-001 and fill the columns the method page leaves open. The
rows this card owns:

| Column or row | Rule |
|---|---|
| Owning seat per sub-step | one seat; the real-time analyst inside guardrails by default |
| Duration | per sub-step; "Continuous" is legal for the rotation |
| Notification text and approver | SET LOCALLY |
| Join key | one per sub-step, carried to the L3 register |
| The guardrail boundary | the line between a move inside guardrails and one that needs a higher tier is an L3 value of GP-302; the rotation row reads "evaluate against the guardrails" and no more |
| The hand-off | two L2 rows, never one: the outgoing seat writes, the incoming seat accepts; a watch nobody accepted is unwatched |
| The hand-over order | status · watch items · changes made · open actions · forecast notes; a fixed-order protocol |
| Plan-of-the-day sign-off | a tier 3 row only where the function requires one (SET LOCALLY) |

## Variants

- **Statutory.** What a supply node's log may record about named agents is set by employment-data law and, in co-determination jurisdictions, by works-council agreement. A limit on the fields is a parameter of the log layout, SET LOCALLY. Where agent-level observations must be held by the supply node's supervisors rather than the center, the post-shift reconciliation changes owner there and takes a row, approved by the function head on legal advice.
- **Contractual.** A partner contract naming the hours and seat through which the partner is reachable parameterizes the operations touchpoint, SET LOCALLY. One under which the partner runs its own routine and reports through an interface replaces the touchpoint with a reporting step and takes a row, reviewed at renewal.
- **Structural.** A watch that passes between regions (follow-the-sun) hands off region to region: the hand-off rows gain a time-zone-stamped log and an acceptance by the receiving region's duty seat. A standing row, reviewed when the footprint changes, because it changes the owner and the position of the hand-off. A supply node with no overnight runs the phases on a shorter clock: no row.
- **Transitional.** A unit from a predecessor organization that keeps its own log format or severity rows maps them to the standard's under a row expiring at cut-over.

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

| Job aid | Anchored to | Form |
|---|---|---|
| The phase clock per supply node, with overnight intensity | all phases | work instruction |
| The pre-shift intelligence checklist and its sources | pre-shift | work instruction |
| The system-health validation list, including the automation layer | pre-shift | work instruction |
| The hand-off template, the acceptance record and the region-to-region form | shift open, shift close | work instruction |
| The monitoring rotation: order, refresh, what tightens it | active monitoring | work instruction |
| The communication charter per supply node | shift open, active monitoring | work instruction |
| The daily summary template and the trend log | post-shift | playbook |
| The watch when the monitoring surface or the alerting layer is down | active monitoring | runbook |

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

Classes are trigger, notify, offer, action; release is per class on a
published catch rate, never on a maturity label.

1. The system-health validation (pre-shift): deterministic checks against known endpoints; a seeded fault is either caught or missed.
2. The interval variance record (active monitoring): actuals written against reforecast and schedule each interval; trigger class; ranks after 1 because a seeded variance must be placed in live data rather than at an endpoint.
3. The daily summary draft (post-shift): in-plan and out-of-plan intervals, incident count and automation-health figures, computed; ranks after 2 because it is assembled from the interval records and inherits any miss in them.
4. The hand-off draft (shift close): status, watch items, changes made and open actions, assembled from the log; ranks after 3 because its verifier is the incoming seat's acceptance, so the catch rate needs an outcome record rather than a seeded input.
5. Event proposals to the forecaster (post-shift): the day's outages, releases and external events, each with an effect window; offer class; ranks last because its verifier is the forecaster, outside the real-time function.

Never a candidate: the hand-off acceptance, the act by which a person takes
the watch; and the rotation as a whole, because the routine builds the
competence the analyst needs on the day the automation cannot cope.

Block 4 — gp-302-real-time-lever-deployment.md

<!-- Derived from [[Real-Time Lever Deployment (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-302 — Real-Time Lever Deployment

Closes a confirmed intraday variance: choose the cheapest lever that will
close the projected gap, obtain the authority it needs, execute, write back,
validate at the next interval, record. The card owns its method; the lever
taxonomy (Real-Time Schedule Adjustment), overtime and voluntary time off,
the surplus direction (Variance Harvesting) and the expansion order
(Expanding Intraday Automation) are on their method pages. The card adds the
ladder by cost and reversibility, one seat per step, the exit to placement,
and the class of automated action each lever is.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-302 · local id SET LOCALLY (standards committee) |
| Class | real-time |
| Trigger | a confirmed variance from GP-304, or a projected gap from the intraday reforecast (GP-104); deficit or surplus |
| Cadence | event-driven, many times per operating day; each deployment bounded by a checkpoint at the next interval |
| Scope in | the ladder inside one supply node: selection, authorization, execution, notification, write-back, validation, capture; both directions |
| Scope out | detection (GP-304) · the reforecast (GP-104) · reallocation across supply nodes, which is placement at the intraday horizon governed as a routing change · queue priority adjustment, excluded for the same reason · a declared incident (Incident Management for Contact Centers) · a change that outlives the day (Schedule Maintenance) |
| Inputs | the variance record (direction, magnitude, persistence, projected window) · the staffing position by interval · lever availability · the guardrails and budgets (SET LOCALLY) · the constraint register |
| Outputs | the deployment record (lever, scope, time, authorizer, cost, outcome) · the updated schedule of record · notifications · the validation result · the capture row for the forecaster and the variance-capture measure |
| Upstream | GP-304 · GP-104 · the published schedule with its pooled off-phone budget (GP-201) · the rule registry of the automation layer |
| Downstream | GP-303 (measures against the written-back schedule) · GP-602 · the forecaster · overtime and time-off cost reporting · the overseer's catch-rate program · placement, when the ladder is exhausted |
| Resources | a schedule system of record with intraday write access · a notification channel to agents · the routing administration surface · an offer mechanism · the rule registry; platforms named at L3 only |
| Decision points | will the variance outlast the cheapest lever's window? · is the lever available? · inside tier-1 guardrails? · did it close the gap at the checkpoint? · is the remaining gap a supply-node gap? |
| Authority tier | tier 1 (real-time analyst inside guardrails) for rungs 1 to 3 and for rungs 4 and 5 inside the pre-authorized budget · tier 2 for offers beyond the budget, mandatory overtime and off-phone deferral beyond the budget · tier 3 for the incident declaration · tier 4 by exception when the day's cost line is exceeded |
| Risk and compliance flags | overtime premiums and hour thresholds · rest-break statutes bounding a break move · co-determination over changes to working time · fairness and income stability in time-off offers · an off-phone budget raided rather than delivered · a write-back failure, after which adherence measures a schedule nobody is running |
| Variant-prone steps | the break-move window · the overtime solicitation order · time-off caps · the exit to placement · the notification channel |
| Automation candidates | 13 L2 rows marked Y, every one ranked below |

## The ladder

Deploy the lowest rung that closes the projected gap; step up only when the
checkpoint shows it did not. Mandatory overtime and training recall sit above
the ladder at tier 2; they are not rungs.

| Rung | Lever | Direction | Cost | Reversible |
|---|---|---|---|---|
| 1 | break and lunch resequencing | deficit and surplus | none | within the day |
| 2 | off-phone activity move | deficit (defer), surplus (accelerate) | none in cash; opportunity cost against the off-phone budget | if re-placed the same week |
| 3 | skill rebalancing inside the supply node | deficit | none in cash; occupancy and quality effect on the receiving queue | at the next interval |
| 4 | voluntary time off offer | surplus | negative (saves hours) | not once the agent has left |
| 5 | voluntary overtime or shift extension offer | deficit | premium hours | not once worked |

The ladder ends at the supply-node boundary. A gap that remains when it is
exhausted leaves this process: moving work or supply between supply nodes is
placement at the intraday horizon, decided by the supply-node owner; it is
not a rung.

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

1. Receive the confirmed variance: direction, magnitude, persistence, projected window — real-time analyst.
2. Project the staffing position for the remaining intervals — real-time analyst.
3. Will the variance outlast rung 1's window? If not, rung 1 only; if so, open the ladder — real-time analyst.
4. Check availability at each rung, bottom up — real-time analyst.
5. Choose the lowest rung that closes the gap; record why the rungs above were not taken — real-time analyst.
6. Is the chosen rung inside tier-1 guardrails? If not, escalate with a one-line case — real-time analyst.
7. Authorize a lever outside the guardrails: a decision per lever, not a click — supervisor or team lead.
8. Execute the move and notify each affected agent and supervisor with the reason; a released rule class performs the step, the analyst owns it — real-time analyst.
9. Write the move back to the schedule of record so adherence, payroll and the next reforecast read it — real-time analyst.
10. Validate at the next checkpoint: has the position closed? — real-time analyst.
11. Did it close? Stand down and log; else step 5 one rung up; ladder exhausted or cause external, step 12 — real-time analyst.
12. Declare an incident, or hand the remaining gap to placement as a supply-node case — ROC duty lead.
13. Capture: the deployment row, the capture record, events proposed to the forecaster — real-time analyst.

## L2 step table

Thresholds, budgets and platform names are L3 values, SET LOCALLY. Sub-steps
without a duration take minutes.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Accept the variance record; confirm direction, magnitude and persistence are present | real-time analyst | GP-304 record | accepted variance, branch by direction | — | Y (trigger) | GP-302.1.1 |
| 2 | Extend the reforecast to end of day; compute the gap per interval against the net requirement | real-time analyst | actuals, reforecast, requirement | gap table | one interval | Y (computed) | GP-302.2.1 |
| 3 | Estimate the persistence window from pattern and matched events | real-time analyst | collision calendar, pattern library | window | — | N | GP-302.3.1 |
| 4 | List breaks and lunches not yet taken inside the movable window, and off-phone activities in the window with their move cost | real-time analyst | schedule of record, activity calendar, budget | rung 1 and 2 candidates | — | Y | GP-302.4.1 |
| 4 | List cross-trained agents whose home queue is at or above requirement | real-time analyst | skill matrix, positions | rung 3 candidates | — | Y | GP-302.4.2 |
| 4 | List agents eligible for time off or overtime within caps and hour thresholds (SET LOCALLY) | real-time analyst | eligibility rules | offer list | — | Y | GP-302.4.3 |
| 4 | Where the gap exceeds what rungs 1 to 5 can close, write the supply-node case for placement | real-time analyst | gap table, constraint register | placement case | — | N | GP-302.4.4 |
| 5 | Choose the lowest rung that closes the gap; record the rungs passed over | real-time analyst | 2.1, 4.x | selection | — | Y (offer) | GP-302.5.1 |
| 6 | Test the selection against the guardrails (SET LOCALLY); if outside, draft the case: what, by how much, how long, what was tried | real-time analyst | guardrails, 5.1 | inside, or a case | — | Y (draft) | GP-302.6.1 |
| 7 | Authorize with the decision recorded per lever | supervisor or team lead | case | signed authorization | window SET LOCALLY | N | GP-302.7.1 |
| 8 | Issue the move: break move, activity move, skill change or offer broadcast | real-time analyst | authorization | executed move | — | Y (action, per class) | GP-302.8.1 |
| 8 | Notify each affected agent and supervisor with the reason | real-time analyst | 8.1 | notification record | — | Y (notify) | GP-302.8.2 |
| 8 | Run the offer acceptance queue in the published order (SET LOCALLY) | real-time analyst | offer list | accepted list | — | Y (action, within budget) | GP-302.8.3 |
| 9 | Write the move to the schedule of record with its reason code; confirm the adherence, payroll and reforecast feeds received it | real-time analyst | 8.x | updated schedule, confirmation | — | Y | GP-302.9.1 |
| 10 | Compare the position at the checkpoint with the projected close | real-time analyst | actuals | validation result | one interval | Y (computed) | GP-302.10.1 |
| 11 | Stand down, step up one rung, or pass to step 12 | real-time analyst | 10.1 | branch | — | N | GP-302.11.1 |
| 12 | Declare the incident, or hand the supply-node case to placement | ROC duty lead | 4.4, 11.1 | severity row, or placement hand-off | — | N | GP-302.12.1 |
| 13 | Write the deployment row (lever, scope, cost, authorizer, outcome); propose events the day revealed | real-time analyst | all | log row, event proposal | — | Y (offer for the event) | GP-302.13.1 |

## Variants

- **Statutory.** Rest-break law fixes how far a break may move and the latest point it may be taken: a parameter of rung 1, SET LOCALLY. Where a works council's co-determination over temporary changes to working hours requires its consent to an overtime offer, step 7 gains a consent sub-step at that supply node and takes a row, approved by the function head on legal advice.
- **Contractual.** A collective agreement or partner contract that fixes the overtime solicitation order, or forbids time-off offers to a cohort, parameterizes 4.3 and 8.3. Supply a client contract dedicates is already excluded from rung 3 by the constraint register. A partner supply node where the center may not instruct agents directly routes step 8 through the partner's seat and takes a row, reviewed at renewal.
- **Structural.** A single-skill supply node has no rung 3; one with no pooled off-phone budget has no rung 2 in the surplus direction. Both are shell marks (NOT INVENTORIED at that supply node), not variants. A channel without an observable in-contact state runs the ladder on backlog and elapsed time; the gap computation at step 2 changes and takes a row.
- **Transitional.** A unit whose predecessor platform cannot accept an intraday write keeps a manual write-back under a row expiring at platform cut-over; automation effect `blocks` against candidates 2 and 7 to 10 until then.

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

| Job aid | Anchored to | Form |
|---|---|---|
| The guardrails per rung: scope, cost, hours, the movable window, the pre-authorized offer budget | steps 4 to 6 | work instruction |
| The ladder as the function runs it, with the rungs it does not have | step 5 | playbook |
| The escalation case format and the response windows per tier | steps 6 and 7 | work instruction |
| The offer broadcast: eligibility, order, caps, the agent-facing wording | steps 4.3 and 8.3 | work instruction |
| The write-back: reason codes and the feeds that must confirm | step 9 | work instruction |
| The checkpoint, the step-up rule and the exit to placement | steps 10 to 12 | playbook |
| The ladder when the schedule system cannot accept a write | step 9 | runbook |

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

Each lever is a class of automated action: trigger (detects and writes),
notify (tells a person), offer (proposes; a person decides at the action
gate), action (executes inside guardrails). Release is per class on a
published catch rate. The automation tiers on Real-Time Schedule Adjustment
are not the seat tiers of this profile.

1. Variance intake and position projection (1.1, 2.1): trigger and computed; a seeded variance either produces a record or does not.
2. Notification and write-back (8.2, 9.1): deterministic; after 1 because its errors show only once a lever has run.
3. The checkpoint comparison (10.1): computed; after 2 because it inherits the projection error of 2.1.
4. The availability lists (4.1, 4.2, 4.3): after 3 because three systems of record must agree before a miss can be attributed to the rule.
5. The ladder proposal and guardrail test with its case draft (5.1, 6.1): offer class; after 4 because the catch rate needs an outcome record at the action gate.
6. Event proposals to the forecaster (13.1): offer class; after 5 because its verifier is outside the real-time function.
7. Break and lunch resequencing (8.1, rung 1): the first lever to reach the action class, cost-free and reversible within the day; after 6 because an executed move changes the floor, so the rate is measured on the overseen pilot.
8. Off-phone activity move (8.1, rung 2): action class both directions, the off-phone budget as guardrail; after 7 because two directions must be seeded and a miss costs a budget.
9. Offer broadcast and acceptance queue (8.1 and 8.3, rungs 4 and 5): action class inside the pre-authorized budget, offer class to tier 2 outside it; after 8 because an accepted offer is irreversible, so the pilot must run long enough to seed acceptance errors. Only the broadcast and the queue are automated.
10. Skill rebalancing (8.1, rung 3): offer class until the routing change it implies has its own catch rate; last because the workforce rule and the routing rule must be measured together.

Never a candidate (five rows): the persistence estimate (3.1), judgment;
authorization (7.1), a gate that must produce a decision; the stand-down or
step-up (11.1), the analyst's reading of the checkpoint; the declaration and
the hand-off to placement (4.4, 12.1), which belong to the severity matrix,
tier 3 and the supply-node owner.

Block 5 — gp-303-adherence-and-conformance-monitoring.md

<!-- Derived from [[Adherence and Conformance Monitoring (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-303 — Adherence and Conformance Monitoring

Compares each agent's actual state with the scheduled one, separates
legitimate deviation from exception, corrects the schedule of record where
the schedule was wrong, hands individual patterns to the supervisor and
systemic patterns to the scheduler, and keeps an audit view that survives the
retirement of the scored metric. The card owns its method; the metrics are on
Adherence and Conformance, the codes on Activity-Code Consistency. The metric
is a signal before it is a verdict: low adherence often means the schedule is
wrong, so the legitimacy check and the correction sit ahead of the exception
path.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-303 · local id SET LOCALLY (standards committee) |
| Class | real-time, with a supporting tail: the period aggregate feeds the scheduling cycle and the weekly review |
| Trigger | continuous during staffed hours; the exception path triggers when a deviation exceeds the tolerance for longer than the grace period (both SET LOCALLY) |
| Cadence | refresh at the surface's interval (SET LOCALLY) · an interval read inside the rotation of GP-301 · a daily close · a period roll-up |
| Scope in | the comparison per agent and team · the legitimacy check · the schedule correction · the exception path in its ticket form and its rule-log form · the coaching hand-off · the audit view · the systemic read-back to scheduling |
| Scope out | the metric definitions, tolerances and targets (Adherence and Conformance) · the lever (GP-302) · the coaching conversation's content and any disciplinary step (Performance Management) · the activity-code set itself |
| Inputs | the schedule of record as written back by GP-302 · the agent state feed · the activity-code map · tolerances, grace and targets (SET LOCALLY) · the rule registry |
| Outputs | the live exception list · the rule log (or, before it, exception tickets) · the corrected schedule · the daily summary by agent, team and interval · the coaching hand-off record · the audit extract · the systemic-signal note to scheduling |
| Upstream | GP-201 and GP-202 · GP-302 (the write-back) · Activity-Code Consistency · the adherence row of the definitions register |
| Downstream | supervisors (coaching) · GP-602 · Shift Design and GP-201 (systemic signals) · GP-603 · the variance-capture measure |
| Resources | a real-time adherence surface · the schedule system of record · a rule log or a ticket system · an audit extract; platforms named at L3 only |
| Decision points | legitimate or an exception? · does it persist past grace? · does it move the interval's staffing position? · individual, team or schedule-design? · does a coaching hand-off follow? |
| Authority tier | tier 1 (real-time analyst inside guardrails) for monitoring, the legitimacy check and the schedule correction · tier 2 for every conversation with an agent · tier 3 for a change to tolerances · tier 4, through GP-601, to retire adherence as a scored metric |
| Risk and compliance flags | agent-state data is employment data: in the European Union, GDPR Article 88 lets Member States and collective agreements set specific rules for processing in employment, naming workplace monitoring systems; in Germany the works council has co-determination over technical devices that monitor behaviour or performance · adherence used as a discipline tool, and targets set high enough to be gamed, are the two failure modes |
| Variant-prone steps | who may see agent-level data · the tolerance and grace values · the hand-off path at partner supply nodes · the exception path during a platform transition |
| Automation candidates | 13 L2 rows marked Y, every one ranked below |

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

1. Load the schedule of record and the activity-code map; confirm the state feed is live — real-time analyst.
2. Compare actual with scheduled state per agent and team at each refresh — real-time analyst.
3. Raise the deviations that exceed tolerance and persist past grace — real-time analyst.
4. Is the deviation legitimate (an unwritten GP-302 move, a fault, an approved swap)? If so, step 5; if not, step 6 — real-time analyst.
5. Correct the schedule of record so the metric measures the schedule the agent was given — real-time analyst.
6. Act on the exception: ticket form, notify the supervisor and file; rule-log form, record, move the break or activity inside guardrails, update the schedule, tell the agent why; a released rule class performs the step, the analyst owns it — real-time analyst.
7. Does the deviation move the interval's staffing position? If so, hand to GP-302 — real-time analyst.
8. Aggregate at the daily close by agent, team and interval — reporting analyst.
9. Classify each pattern: individual, team, or schedule-design (one interval, many agents) — real-time analyst.
10. Hand off: individual patterns to the supervisor as a coaching record with evidence and no verdict; schedule-design patterns to the scheduler — real-time analyst.
11. Hold the coaching conversation and record its outcome; anything beyond coaching leaves this process — supervisor or team lead.
12. Produce the audit view: the compliance extract, separable from the scored metric, retained per policy — reporting analyst.
13. Roll up the period; read back to scheduling and the weekly review — reporting analyst.

## L2 step table

Tolerances, grace values and platform names are L3 values, SET LOCALLY.
Sub-steps without a duration take minutes.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Confirm the schedule version is the one agents received, the activity-code map matches the register, and the state feed is live | real-time analyst | schedule, version log, map, feed status | three confirmations | — | Y | GP-303.1.1 |
| 2 | Compare scheduled with actual state per agent at each refresh; roll to team and interval | real-time analyst | schedule, states | deviation list, team and interval view | continuous | Y (trigger) | GP-303.2.1 |
| 3 | Apply tolerance and grace (SET LOCALLY); raise only persisting deviations | real-time analyst | 2.1 | exception candidates | continuous | Y (trigger) | GP-303.3.1 |
| 3 | Suppress deviations already explained by a written-back move | real-time analyst | GP-302 log | net list | continuous | Y | GP-303.3.2 |
| 4 | Check each net deviation against moves, faults and approved swaps | real-time analyst | 3.2, swap log, fault log | legitimate or exception | — | Y (offer) | GP-303.4.1 |
| 5 | Write the correction to the schedule of record with a reason code | real-time analyst | 4.1 | corrected schedule | — | Y | GP-303.5.1 |
| 6 | Ticket form: notify the supervisor, file the exception, review at the daily close | real-time analyst | 4.1 | ticket | SET LOCALLY | N (retired by 6.2) | GP-303.6.1 |
| 6 | Rule-log form: record, act inside guardrails, update the schedule, tell the agent why | real-time analyst | 4.1, guardrails | log row | — | Y (action, per class) | GP-303.6.2 |
| 7 | Test the deviation's effect on the interval staffing position | real-time analyst | position | hand-off to GP-302, or none | — | Y | GP-303.7.1 |
| 8 | Aggregate the day by agent, team and interval | reporting analyst | 2.x to 6.x | daily summary | at close | Y | GP-303.8.1 |
| 9 | Test each pattern: individual, team, or interval-wide | real-time analyst | 8.1 | classification | at close | Y (offer) | GP-303.9.1 |
| 10 | Draft the coaching record (agent, pattern, intervals, evidence) and the scheduling note (interval, teams, suspected design cause) | real-time analyst | 9.1 | hand-off record, note | at close | Y (draft) | GP-303.10.1 |
| 11 | Hold the conversation and record the outcome | supervisor or team lead | 10.1 | outcome record | SET LOCALLY | N | GP-303.11.1 |
| 12 | Produce the audit extract: states, times, corrections, who saw what | reporting analyst | all | extract | at close | Y | GP-303.12.1 |
| 12 | Apply retention and access per the data policy (SET LOCALLY) | reporting analyst | 12.1, policy | retained extract | — | N | GP-303.12.2 |
| 13 | Roll up the period and read back to scheduling and the weekly review | reporting analyst | 8.1 series | period summary, read-back | per period | Y | GP-303.13.1 |

## Variants

- **Statutory.** Where a works-council agreement limits which fields the comparison may hold or who may see them, the field list is a parameter, SET LOCALLY. Where it removes the center's agent-level view entirely, steps 2 to 4 change owner at that supply node (the supply node's supervisors see the agent, the center sees the team) and take a row, approved by the function head on legal advice.
- **Contractual.** A partner contract under which only the partner's supervisors see agent-level data routes step 10 to the partner's named seat and takes a row, reviewed at renewal. A client contract that sets an adherence target is a parameter.
- **Structural.** A channel with no observable in-contact state cannot be measured as state-at-time; a conformance or output measure substitutes at steps 2 and 3 under a row until a time-accounting ledger exists for the channel. A self-scheduled pool where conformance is primary changes only which metric is primary: a parameter.
- **Transitional.** A supply node from a predecessor organization that keeps its ticket path (6.1) until the rule log is live there holds a row expiring at that date; automation effect `blocks` against candidate 8.

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

| Job aid | Anchored to | Form |
|---|---|---|
| The tolerance, grace and target values, by activity (SET LOCALLY) | steps 2 and 3 | work instruction |
| The activity-code map and its register row | step 1 | work instruction (method on Activity-Code Consistency) |
| The legitimacy checklist (moves, faults, swaps) and the reason codes | steps 4 and 5 | work instruction |
| The rule log layout and the guardrails per rule | step 6 | playbook |
| The retired ticket path, with a record of what retirement removed | step 6 | playbook |
| The coaching hand-off record and the scheduling note | step 10 | work instruction |
| The audit extract, its access list and retention | step 12 | work instruction |
| The watch when the state feed is down | steps 1 and 2 | runbook |

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

Classes are trigger, notify, offer, action; release is per class on a
published catch rate, never on a maturity label.

1. The comparison and the tolerance filter (2.1, 3.1): trigger class; a seeded deviation is either raised or missed.
2. The day-start confirmations (1.1): deterministic; after 1 because each confirmation reads a different system of record and is seeded separately.
3. Suppression of explained deviations (3.2): after 2 because a miss may belong to GP-302's write-back and must be attributed first.
4. The daily aggregate, audit extract and period roll-up (8.1, 12.1, 13.1): assembled, not decided; after 3 because each inherits any miss upstream.
5. The staffing-position test (7.1): computed; after 4 because it reads the position from GP-302, so an error may belong to either process.
6. The legitimacy check and schedule correction (4.1, 5.1): offer class; after 5 because the catch rate needs an outcome record; action class once published.
7. Pattern classification and the hand-off drafts (9.1, 10.1): offer and draft; after 6 because its verifiers sit in other processes.
8. The rule-log action (6.2): action class per rule; last because it changes the floor and must pass the overseen pilot. Until the rate is published the rule proposes and the analyst approves; after it, the ticket path (6.1) is retired, with a written record of what was retired and the risk its retirement removed.

Never a candidate (three rows): the ticket path (6.1), retired rather than
automated; the coaching conversation (11.1), a human act; retention and access
(12.2), policy. Retiring adherence as a scored metric is a tier 4 change to
the standard. Caution on candidate 8: supervisors of a reliable automation
drift toward assent; the overseer's error-injection program keeps the
analyst's approval at step 6 a decision rather than a click.

Block 6 — gp-304-threshold-alerts-and-escalation.md

<!-- Derived from [[Threshold Alerts and Escalation (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-304 — Threshold Alerts and Escalation

Turns a metric crossing a boundary into an acknowledged alert, routes it to
the seat with authority to respond, escalates when the response does not
recover the metric, and steps down when recovery has held. The method (alert
classes, configuration principles, the three-branch decision tree) is on Real
Time Threshold Alerts and Escalation Protocols and is not restated. An alert
is the front door of the real-time day: the trigger of GP-302, the entry
criterion of incident management when sustained and wide, a signal GP-301's
rotation reads between alerts. An alarm set is only as useful as the attention
it directs; one that fires more than its analysts can act on has trained them
to ignore it.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-304 · local id SET LOCALLY (standards committee) |
| Class | real-time |
| Trigger | a monitored metric crossing its boundary and staying there for the confirmation window (a sustained breach, never an instantaneous one); a recovery crossing triggers the step-down check |
| Cadence | continuous; the alert catalogue reviewed for false positives on a cadence the function sets (SET LOCALLY) |
| Scope in | generation · acknowledgement · routing to the tier · escalation up the tiers · the step-down · the alert log · the catalogue review |
| Scope out | the lever (GP-302) · the incident once declared (Incident Management for Contact Centers) · the severity matrix · the staffing-state codes, which classify what the operation has become rather than what crossed a line |
| Inputs | the metric feeds · thresholds per class and interval group (SET LOCALLY) · the confirmation window · the recipient map per class and tier · the staffing position · exogenous signals |
| Outputs | the alert record (class, metric, value, time, recipient, acknowledgement, response, outcome) · the escalation record · the step-down record · the false-positive register · catalogue change requests |
| Upstream | the monitoring surface · the intraday reforecast (GP-104) for predicted alerts · the metric rows of the definitions register |
| Downstream | GP-302 (the confirmed variance) · incident management (the declaration) · GP-303 (the adherence class) · Variance Harvesting (the log) · GP-602 · post-mortem |
| Resources | an alerting layer · one notification channel per tier · an alert log; platforms named at L3 only |
| Decision points | is the breach sustained? · which tier does the class map to? · has the autonomous response recovered the metric inside the step-up window? · is this an incident? · has recovery held for the step-down window? |
| Authority tier | by class, per the mapping below; the catalogue and its thresholds change only through GP-601 at tier 4 |
| Risk and compliance flags | alert fatigue · thresholds not calibrated by interval group · a class with no documented owner · the alert log is audit evidence, comparable to the incident record service-management standards require · notification wording sent to a partner supply node crosses a contract boundary |
| Variant-prone steps | the thresholds · the recipient map at partner supply nodes · the overnight tier map · predecessor alert sets |
| Automation candidates | five sub-steps of the method page's response sequence, every one ranked below |

## L1 and L2 (deferring card)

The L1 is the method page's response sequence: the alert fires on a sustained
breach; the recipient acknowledges inside the class's window; the decision
tree sends it down one of three branches (autonomous response, supervised
response, incident declaration); escalation follows when the response has not
recovered the metric or the class is above the recipient's authority; every
acknowledgement, action and escalation is logged. Copy the alert classes and
configuration principles into the function's L2 through CP-OPS-001, filling
owning seat, acknowledgement window, notification text and join key per row.
The rows this card owns:

| Branch on the method page | Tier | Generic examples | What the tier must produce |
|---|---|---|---|
| Autonomous response | tier 1, the real-time analyst inside guardrails | a warning-level service or queue alert; a team adherence alert; a low-occupancy alert answered by a time-off offer inside the budget | the lever chosen and the checkpoint set (GP-302) |
| Supervised response | tier 2, the supervisor or team lead | an alert whose answer is overtime, off-phone deferral beyond the budget, or a non-standard schedule change | a decision per lever, recorded |
| Incident declaration | tier 3, the operations manager or ROC duty lead | a sustained breach across queues, skills or supply nodes; a platform or facility cause; the ladder exhausted | the severity row and the incident record |
| Catalogue change | tier 4, the function head, through change control | a new class, a threshold change, a recipient change | the signed change record |
| Continuity trigger | executive sponsor, by exception | the row of the severity matrix that hands to business continuity | the activation decision |

The step-down is an L2 row of its own, owned by the real-time analyst, never
a footnote to recovery: a metric that has recovered because a lever is still
in place has not recovered. Three questions in order: has the metric held
inside its boundary for the step-down window (SET LOCALLY); is the cause
understood or the matched event closed; have the levers deployed against it
been returned or written back? Only then does the state step down; where it
had been escalated, the row carries the escalating tier's confirmation.

## Variants

- **Statutory.** Alert classes that name individual agents (the adherence class) inherit the statutory variants of GP-303 and carry the agent identifier only where that card's row permits: a parameter at most supply nodes, a row where the recipient changes.
- **Contractual.** A partner contract naming the seat the center may notify and the wording it may use parameterizes the recipient map and the verbiage, SET LOCALLY. One under which the partner runs its own alerting and reports breaches through an interface replaces generation with receipt for that supply node and takes a row, reviewed at renewal.
- **Structural.** An overnight watch with no tier-2 seat on duty maps the supervised branch to the duty lead directly: a standing row, reviewed when the watch structure changes. A channel without a queue alerts on backlog age rather than waiting count; its class list differs and takes a row.
- **Transitional.** A predecessor organization's alert set is mapped class by class onto the catalogue under a row expiring at cut-over, so that a breach counted on the old set counts on the new one.

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

| Job aid | Anchored to | Form |
|---|---|---|
| The alert catalogue: class, metric, threshold (SET LOCALLY), confirmation window, interval group, owner | generation | work instruction |
| The notification verbiage per class and per tier, with the partner-supply-node version | routing | work instruction |
| The acknowledgement and step-up windows per tier | routing, escalation | work instruction |
| The escalation path per branch | escalation | runbook |
| The step-down check: the three questions and the window | step-down | runbook |
| The false-positive review and the catalogue change request | catalogue review | playbook |
| The overnight recipient map | routing | work instruction |
| The manual rotation when the alerting layer is down | generation | runbook; the watch is GP-301's |

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

Classes are trigger, notify, offer, action; release is per class on a
published catch rate, never on a maturity label. Alert generation is the
oldest automated step in real-time operations; the risk is not that it fires
but that its output is trusted or ignored without a measured basis.

1. Alert generation on a sustained, correlated breach: trigger class; a seeded breach is either raised or missed, and the false-positive register is the catch rate's denominator.
2. Notification and routing to the tier recipient with the class's verbiage: notify class; after 1 because a seeded error in the recipient map can only be observed once an alert exists to route.
3. The predicted service-level alert from the reforecast: trigger class; after 2 because a prediction can be wrong in two directions, so the seeded set must hold misses and false alarms in known proportion.
4. The escalation case draft (what, by how much, for how long, what was tried): offer class, written with the evidence attached and sent by the analyst; after 3 because its verifier is the analyst at the action gate, so the catch rate needs an outcome record.
5. The step-down proposal: offer class; last because its known failure, stepping down a state a lever is still holding, can be seeded only by running a lever and withholding its write-back, the most expensive test on this list. The step-down decision itself is not a candidate until that catch rate is published.

Never a candidate (two steps): incident declaration, a tier-3 decision and
the severity matrix's trigger; a change to the catalogue, which is change
control, a versioned and reviewed act.

Usage notes

Sizing. Block 1 is about 590 words and loads with every message. Blocks 2–6 are retrieved as needed; the rules file is about 1,130 words and the four card files run 650 to 1,100 words of prose each plus their tables, the two cards that own their L2 (GP-302, GP-303) being the largest and the two deferring cards (GP-301, GP-304) the smallest.

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 lever is released as a class of action, never as a process.

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 and its class. The pack refuses to fill a value the function has not given, to name a person against a seat, or to name a platform in a file marked for publication. Two cards (GP-301, GP-304) defer their L1 and L2 to method pages the function copies through CP-OPS-001; the card files state which rows the card owns. A localized card is the function's; the generic card on the wiki does not change when a function localizes it.

Drift. Blocks 3–6 derive from the four 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 wiki card is the canonical version; a localized file is regenerated from it, not edited in place.

Scope. Nothing in the pack is specific to any organization, jurisdiction or platform. The works-council, rest-break and employment-data variants are examples of the classes, not a list of the jurisdictions a function operates in. The pack stops at the supply-node boundary and at the incident declaration: reallocation across supply nodes belongs to the placement pillar's pack, and the incident process to the two method pages named above.

Change history

Version	Date	Change
1.0	2026-10-16	First release: instruction block, localization-rules.md, and one reference file per real-time card (GP-301 to GP-304)

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 that defines the four artifacts and the fifteen-column table this pack fills
• Daily ROC Routine (generic process) · Real-Time Lever Deployment (generic process) · Adherence and Conformance Monitoring (generic process) · Threshold Alerts and Escalation (generic process) — the four cards
• Daily ROC Routine · Real-Time Schedule Adjustment · Adherence and Conformance · Real Time Threshold Alerts and Escalation Protocols — the method pages the cards defer to
• Incident Management for Contact Centers · Contact-Center Incident Severity Matrix — the method pages a user may bring for the incident process the cards hand to
• Expanding Intraday Automation — the four classes of automated action and the supply-node boundary
• Standard and Variant in Process Documentation · Decision Authority Tiers in Workforce Operations · Human Gates and Number Grades · Process Shells for a Workforce Standard — the conventions behind Block 2
• Wiki:Packs/Process Inventory and Shell Catalog — CP-OPS-008, the catalog the cards are shelled into before they are localized
• Wiki:Packs/Forecasting Processes · Wiki:Packs/Scheduling 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