Wiki:Packs/Scheduling Processes

From WFM Labs
Pack
ID CP-OPS-010
Name Scheduling Processes
Domain OPS
Blocks 1 instruction + 5 reference
Version 1.0
Source Process Standardization · Schedule Build and Publish (generic process) · Schedule Maintenance (generic process) · Time-Off Allotment Planning (generic process) · Self-Scheduling and Flexible Workforce Administration (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 four generic process cards of the scheduling pillar (GP-201 to GP-204) 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, calendar, approver and system name marked SET LOCALLY; the pack walks a function through supplying those values without ever inventing one. 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 scheduling standard: cataloging the four scheduling processes as shells, then filling each card with the function's seats, calendars, bands and variant rows ahead of certification through the gate on Process Standardization Lifecycle. It is not for designing the scheduling method itself (the shift catalogue, the optimisation, the allocation mechanism and the time-off mathematics are on the method pages each card defers to), not for process improvement (measure first), and not for the real-time side of the lead-time boundary, which belongs to the real-time pillar's pack. 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: "Scheduling standard — <function>", not "Pack 010".
  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-201 to GP-204) and giving the function's seats, sites, channels and the plan-of-record facts the profile needs; one card per conversation.

Block 1 — Project instructions

You are localizing generic process cards for the scheduling pillar of a
workforce function's standard. The pillar's four cards are in the reference
files; `localization-rules.md` holds the conventions. The cards are generic:
every threshold, calendar, approver and system name is marked SET LOCALLY,
and the deploying function supplies those values on its own L0 and L3. This
project turns one card at a time into the function's own localized process.
CP-OPS-001 (Process Decomposition) is the engine that defines the output
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` |
| Build and publish the schedule of record: requirement, window, generate, three checks, approve, publish, exception window | `gp-201-schedule-build-and-publish.md` |
| Keep a published schedule current: time off, swaps, overtime, VTO, exceptions, versions | `gp-202-schedule-maintenance.md` |
| Set the time-off allotment, blackout calendar, rebalance and year-end close | `gp-203-time-off-allotment-planning.md` |
| Administer self-scheduling, open-shift pools, flex pools and the gap-fill ladder | `gp-204-self-scheduling-and-flexible-workforce-administration.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-202 defers its L1 and L2 to its method page:
   copy that page's rows and fill the columns the card file names.
4. Run the variant test on every local difference and write the variant rows.
5. Carry the automation candidates over unchanged, in the card's rank order,
   and ask for the function's catch-rate evidence per class before marking
   any as released.
6. Emit `L0-cover.md` (identity + profile), `L1-flow.md`,
   `L2-step-decomposition.md`, `L3-register.md` and `variants.md`.

Disciplines:
- Never fill a local value the user has not given; leave the mark and its seat.
- Never name a product or platform in any file marked for publication.
- Two owners on one step, a decision with no decider, a job aid that does not
  exist: a finding, in its own section, never a footnote.
- Seats, never names. Tier vocabulary only: tiers 1 to 4, executive sponsor
  by exception.
- Every number keeps its grade; every number the user adds gets one.
- A step the card marks "never a candidate" stays human.
- The schedule of record is a commitment: publication timestamp, notice
  period, version history and the lead-time boundary to the real-time pillar
  are never left unresolved: each is a value the user gives or a SET LOCALLY
  entry in the findings.
- A rule-set or allotment change that touches a statutory or
  collective-agreement term routes through GP-603 before GP-601 (GP-204
  step 4).
- The eligibility decision on an individual and the assignment rung of the
  gap-fill ladder stay human (GP-204's never-a-candidate list).
- One card per conversation.

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

Source: Wiki:Packs/Scheduling Processes (CP-OPS-010) 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-201-schedule-build-and-publish.md

<!-- Derived from [[Schedule Build and Publish (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-201 — Schedule Build and Publish

Turns the requirement for a scheduling period into a schedule of record:
requirement in, catalogue and rule set confirmed, window, generate and
assign, three checks, approval, publication with its notice period,
exception window. The card owns L1 and L2; step methods are on Employee
Scheduling, Schedule Optimization, Shift Design and Schedule Bidding and
Preference Based Scheduling. Publication is where a plan becomes a
commitment: the notice period starts at the timestamp.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-201 · local id SET LOCALLY |
| Class | strategic: a planned batch process with lead time, never run inside the day |
| Trigger | GP-103 releases the period's requirement on the build calendar; event-driven rebuild on a new-hire class or a restructure |
| Cadence | once per scheduling period (one or two weeks typical [A]); the bid cycle on its own calendar, SET LOCALLY |
| Scope in | requirement intake · catalogue and rule-set confirmation · window · generation and assignment · three checks · approval · publication · exception window |
| Scope out | the requirement (GP-103) · the optimisation method · change after the window (GP-202) · the allotment (GP-203) · self-scheduled claims (GP-204) |
| Inputs | interval requirement by skill group · roster with contract hours, approved time off, training calendar · shift catalogue · bids or preferences · rule set · activity-code dictionary |
| Outputs | version 1 of record with timestamp and notice period · coverage, fairness and compliance reports · exception log |
| Upstream | GP-103 · GP-203 · GP-505 (skill mix) · Shift Design · HR partner · definitions register |
| Downstream | GP-202 (the version active at window close) · GP-303 · GP-301 · payroll and time systems · GP-602 |
| Resources | scheduling engine · roster of record · bid portal · rule register · activity-code dictionary; platforms at L3 only |
| Decision points | catalogue adequate? · coverage in band? · fairness in band? · compliance pass? · approve to publish · grant or defer an exception |
| Authority tier | build and the coverage and fairness reports at tier 1 (scheduler) · compliance check owned by the compliance lead · approval to publish at tier 3, because it starts the notice period · an unreachable coverage band or a works-council objection at tier 4 |
| Risk and compliance flags | notice-period statutes and predictability pay · rest, hours and break rules as hard constraints, never after-the-fact checks · collective-agreement bid order · the timestamp as auditable record · retention of every version |
| Variant-prone steps | notice period and change premium · allocation mechanism · a pre-publication review step · publication channel · exception-window length |
| Automation candidates | eleven L2 sub-steps in seven groups |

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

1. Receive the requirement by interval and skill group; reconcile to the plan of record — scheduler.
2. Refresh availability: roster roll-forward, contract hours, approved time off, training calendar — scheduler.
3. Is the catalogue adequate to the requirement's shape? If not, raise a catalogue change through Shift Design first — scheduling lead.
4. Confirm the rule set in force: statutory, contractual, local — scheduling lead (compliance lead contributes).
5. Open and close the bid or preference window on the calendar — scheduler.
6. Generate from the catalogue against the requirement — scheduler.
7. Assign named staff by the allocation mechanism in force — scheduler.
8. Coverage within band in every interval? If not, iterate 6–7 or raise the residual to the capacity planner — scheduler.
9. Fairness report within band by cohort? — scheduling lead.
10. Compliance check passed on rest, hours, breaks and agreement rules? A failing schedule is never published — compliance lead.
11. Approve for publication — operations manager (tier 3).
12. Publish with the notice period; stamp the time; version 1 of record — scheduler.
13. Run the exception window: errors become versions, hardship defers to GP-202; hand over the version active at close — team lead (scheduler contributes).

## L2 step table

Durations typical [A]; "½ day" is half a business day; "incl." means inside
the row above. Keep the join keys when expanding to fifteen columns.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Load requirement; reconcile to plan of record and definitions register | scheduler | requirement; plan | reconciled requirement; discrepancy note | ½ day | Y | 201-01a |
| 1 | Raise an out-of-band discrepancy to the capacity planner | scheduler | discrepancy note | resolution or accepted variance | SET LOCALLY | N | 201-01b |
| 2 | Roll roster forward: starters, leavers, contract changes | scheduler | roster | availability base | ½ day | Y | 201-02a |
| 2 | Apply approved time off and the training calendar | scheduler | approvals; calendars | net availability | incl. | Y | 201-02b |
| 3 | Compare catalogue coverage curve to requirement shape | scheduling lead | catalogue; requirement | adequacy finding | ½ day | Y (comparison) | 201-03a |
| 3 | Raise a catalogue change where inadequate | scheduling lead | finding | change request | SET LOCALLY | N | 201-03b |
| 4 | Confirm statutory, contractual and local parameters | scheduling lead; compliance lead | rule and variant registers | period rule set | 1 day | N | 201-04a |
| 5 | Open window, notify, close on calendar | scheduler | catalogue; eligible roster | bids or preferences | SET LOCALLY | Y | 201-05a |
| 6 | Run generation against requirement and rule set | scheduler | net availability; catalogue; rule set | candidate schedule | 1 day | Y (the check loop) | 201-06a |
| 7 | Assign named staff by the allocation mechanism | scheduler | candidate; bids | assigned schedule | incl. | Y | 201-07a |
| 8 | Coverage report by interval and skill group | scheduler | assigned schedule; requirement | coverage report | minutes | Y | 201-08a |
| 8 | Out-of-band gap: iterate or escalate the residual | scheduler; capacity planner | coverage report | revision or escalation | SET LOCALLY | N | 201-08b |
| 9 | Fairness report by cohort | scheduling lead | assigned schedule; history | fairness report | minutes | Y | 201-09a |
| 9 | Out-of-band fairness: re-weight and re-run, or accept with reason | scheduling lead | fairness report | decision record | SET LOCALLY | N | 201-09b |
| 10 | Compliance check as hard constraints | compliance lead | assigned schedule; rule set | pass or fail with failing rows | minutes | Y | 201-10a |
| 11 | Review the three reports; approve or return | operations manager | three reports | approval record | ½ day | N | 201-11a |
| 12 | Publish on channel; stamp time; set version 1 | scheduler | approved schedule | version 1; publication record | minutes | Y | 201-12a |
| 13 | Triage exceptions: error, hardship, other | team lead | requests | triaged log | window, SET LOCALLY | N | 201-13a |
| 13 | Correct errors as a new version; defer hardship to GP-202 | scheduler | triaged log | version n; handover note | incl. | N | 201-13b |

## Variants

- **Statutory.** Notice period and change premium: parameters of step 12, SET LOCALLY; rest, hours and break rules: parameters of step 10. Works-council co-determination over working time inserts a review step between approval and publication: works-council liaison owns, function head approves, a row.
- **Contractual.** An agreement fixing allocation order parameterizes step 7, no row. Client-dedicated named staff leave the pool through the constraint register, SET LOCALLY.
- **Structural.** No bid portal: preferences by survey, step 5 varied with a review date. A partner-held scheduling seat on its own engine publishes through the function's channel under a row until catalogue and rule set are shared.
- **Transitional.** Schedules exported and re-keyed by hand from a predecessor organization's platform: a row expiring at cut-over, automation effect `blocks` on the publication candidate.

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

| Job aid | Anchored to | Form |
|---|---|---|
| Build calendar: offsets from requirement release to publication | steps 1–12 | work instruction |
| Requirement reconciliation query and discrepancy band | step 1 | work instruction |
| Availability refresh checklist and sources | step 2 | work instruction |
| Catalogue adequacy test | step 3 | work instruction |
| Rule register layout and period confirmation | step 4 | work instruction |
| Window procedure and allocation mechanism in force | steps 5, 7 | playbook |
| Three report templates and their bands | steps 8–10 | work instruction |
| Approval pack and publication record | steps 11–12 | work instruction |
| Exception window: triage categories, handover to maintenance | step 13 | playbook |
| Rebuild path when a check fails after the last calendar offset | steps 8–12 | runbook |

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

1. Compliance check (201-10a): hard constraints; every known error is enumerable.
2. Coverage report (201-08a): computed against a requirement with its own grade; catch rate published net of forecast error.
3. Reconciliation, availability refresh, catalogue comparison (201-01a, 02a, 02b, 03a): cross-system reads; a mismatch between systems needs a reconciliation sample first.
4. Fairness report (201-09a): cohorts change with the function's design; republished at every change.
5. Publication and notification (201-12a): errors visible outside the function; longer observation window.
6. Window procedure (201-05a): errors surface through complaints; slower to establish.
7. Generate-and-check loop (201-06a, 07a): judged against a benchmark schedule the function must first build.

Never a candidate: approval to publish (201-11a), a signature that starts a
notice period; the hardship exception (201-13b), a judgement about a person.

Block 4 — gp-202-schedule-maintenance.md

<!-- Derived from [[Schedule Maintenance (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-202 — Schedule Maintenance

Keeps a published schedule current between publication and the operating
day: time-off requests, swaps, planned overtime, voluntary time off (VTO)
and exceptions, each tested against coverage, fairness and the rule set, and
every approved change written as a new version of the schedule of record.
The method (five event types, the lead-time boundary, the coverage-impact
test, version control) is on the wiki page Schedule Maintenance and is not
restated. Typically the pillar's highest-volume process by event count [A]
and the one most often run by hand; it guards against approving without a
coverage test and measuring adherence against a stale version.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-202 · local id SET LOCALLY |
| Class | strategic: planned, with lead time; a request inside the lead-time boundary is GP-302's |
| Trigger | handover of the version active at the close of GP-201's exception window; then each event as it arrives, until the boundary passes it to GP-302 |
| Cadence | continuous within the period; a daily pass typical [A]; the boundary is a parameter (rule of thumb one day), SET LOCALLY |
| Scope in | the five event types · coverage-impact test · approval · version write · fairness queues · maintenance log |
| Scope out | build and publication (GP-201) · the allotment (GP-203) · self-scheduled claims and the open-shift pool (GP-204) · same-day change (GP-302) · the adherence measurement |
| Inputs | active version · requirement and reforecast · allotment and balances · fairness queues · rule set · event requests |
| Outputs | approval or decline with reason per event · a new version per approved change · maintenance log by event type · fairness-queue state · handover at the boundary |
| Upstream | GP-201 · GP-203 · GP-103 (demand side of the coverage test) · HR partner (balances, protected leave) |
| Downstream | GP-303 (reads the version active) · GP-302 at the boundary · payroll · GP-602 (reads the log as a build-quality signal) |
| Resources | scheduling system with version history · request portal · allotment and balance ledger · fairness queues · rule register; platforms at L3 only |
| Decision points | passes the coverage test? · within allotment and balance? · within the rule set? · who is next in the queue? · inside the boundary (then not this process)? |
| Authority tier | approvals inside rule set and allotment at tier 1 (scheduler) · breaching the coverage band or exceeding the allotment at tier 2 · planned overtime binding cost, and any mandatory overtime, at tier 3 · a change to the rule set at tier 4 through GP-601 |
| Risk and compliance flags | protected leave is a legal determination, never a capacity decision · a swap must leave rest, hours and skill rules satisfied · overtime out of contractual order is a grievance · a change inside a notice period may carry a premium · adherence against a stale version is a false number |
| Variant-prone steps | approval tier per event type · overtime and VTO queue order · swap restrictions · lead-time boundary · response-time commitment |
| Automation candidates | six L2 sub-steps |

## L1 and L2 (deferring card)

The L1 event cycle and the L2 decomposition per event type are on the method
page Schedule Maintenance. Copy both through CP-OPS-001 and fill the columns
the method page leaves open. The rows this card owns:

| Column to fill | Rule |
|---|---|
| Owning seat per event type | one seat per event type; the scheduler inside guardrails by default |
| Ticketing code | SET LOCALLY |
| Coverage standard the test runs at | SET LOCALLY; the pass band is an L3 value |
| Approver per event type | the tier in the profile, written as a seat |
| Response-time commitment | SET LOCALLY; late responses are the dominant trust failure |
| Lead-time boundary row | never blank: it is the line between this card and GP-302 |
| Decline reasons | each decline reason is an L2 row of its own |

## Variants

- **Statutory.** Rest, hours and break rules: parameters, no row. A change premium inside a notice period: parameter of the approval step, SET LOCALLY. Protected leave: the generic exception path, no row; the HR partner determines. Works-council co-determination over temporary hours inserts a consultation step before any planned overtime offer: liaison owns, function head approves, a row.
- **Contractual.** An agreement fixing overtime order (equalization, seniority, inverse seniority) and swap restrictions parameterizes the queue and the swap test, no row. A client ban on VTO for dedicated staff: constraint-register entry, SET LOCALLY.
- **Structural.** No version history in the scheduling system: versions written to a dated export, the version step varied and reviewed each cycle. A back-office channel with a daily requirement tests coverage at day level: a parameter.
- **Transitional.** Approvals still by email from a predecessor organization: a row expiring at portal cut-over, automation effect `blocks` on candidates 1 to 3.

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

| Job aid | Anchored to | Form |
|---|---|---|
| Event-type register: definitions, approver tier, response-time commitment | all event types | work instruction |
| Lead-time boundary and handover to the real-time function | classification step | work instruction |
| Coverage-impact test: standard, inputs, pass band | coverage test | work instruction |
| Time-off request path against allotment and balance | time-off events | work instruction |
| Swap verification checklist: skill, rest, hours, coverage, contractual order | swap events | work instruction |
| Planned overtime and VTO offer procedures and their queues | overtime and VTO events | playbook |
| Exception path for protected leave and hardship | exception events | runbook |
| Version write and maintenance log layout | every approved change | work instruction |
| Weekly read of the log as a build-quality signal | log review | playbook (feeds GP-602) |

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

1. Coverage-impact test: arithmetic on the active version and the reforecast, run before a human sees any request; every other candidate depends on it.
2. Swap approval within the rule set: adds the rule set to the arithmetic; catch rate from declined-then-overturned cases, a cycle to accumulate.
3. Time-off auto-approval within allotment, balance and notice horizon (outside any: routed, not declined): reads the balance ledger, a second system of record; ledger reconciliation sample first.
4. Overtime and VTO offers: gap computed, offer distributed in the fixed queue order, acceptances written; opening an offer stays at tier 3 until the proposal's catch rate is published. A queue-order error is a grievance, counted outside the function and later.
5. Version write and log entry: mechanical, but a catch rate exists only once the approvals above produce changes.
6. Weekly log summary by event type: errors of classification, caught only when GP-602 reads the log.

Never a candidate: mandatory overtime (it compels a person and, in a
unionized unit, follows the agreement's procedure); the protected-leave
determination (a legal finding about an individual); a decline of a request
that passes every test (judgement, a tier 2 act with a stated reason).

Block 5 — gp-203-time-off-allotment-planning.md

<!-- Derived from [[Time-Off Allotment Planning (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-203 — Time-Off Allotment Planning

Decides how much time off a workforce function can release in each week of
the year, publishes the allotment, allocates the primary demand through a
window, holds an exception path for protected leave and hardship, and
rebalances mid-year when the plan or the forecast moves. The card owns L1
and L2; the time-off artifacts and allocation mathematics are on Time-Off
Management, the shrinkage arithmetic on Shrinkage. Time off is the one
planned-shrinkage component that is owed: every accrued hour will be
scheduled, paid out or lost.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-203 · local id SET LOCALLY |
| Class | strategic: the annual cut is a planning decision, the weekly grid a scheduling input |
| Trigger | signature of the annual plan of record (GP-101); the monthly plan (GP-102) for the rebalance; the leave-year boundary for the close |
| Cadence | annual cut · weekly grid · monthly consumption read · mid-year rebalance (SET LOCALLY; one scheduled rebalance with an exception trigger typical [A]) |
| Scope in | entitlement liability · annual allotment curve · weekly grid by unit and skill group · blackout calendar · primary allocation window · exception path · rebalance · year-end close and carry-over |
| Scope out | accrual policy and the balance ledger (HR partner's) · the rolling request path after the window (GP-202) · the shrinkage target (GP-101, GP-102) · the protected-leave determination (HR partner) |
| Inputs | plan of record with its planned-shrinkage line · demand forecast by week · entitlement base per person · statutory minimum leave and carry-over rules · collective-agreement terms · last year's consumption and fairness metrics |
| Outputs | allotment curve · weekly grid · blackout calendar with rationale · allocation results with reasons · exception log · rebalance record · year-end close and fairness report |
| Upstream | GP-101 · GP-102 · GP-103 (rebalance signal) · HR partner · definitions register |
| Downstream | GP-201 (reads the grid as availability) · GP-202 (draws it down) · GP-603 (audits the trail) · finance (leave liability) |
| Resources | capacity model with the shrinkage line · balance ledger · request and allocation portal · the forecast · blackout calendar; platforms at L3 only |
| Decision points | plan absorbs the liability? · curve inside the shrinkage line? · request inside allotment and balance? · protected leave or hardship? · plan moved enough to re-cut? |
| Authority tier | grid and allocation run at tier 1 (scheduler) · an exception above allotment at tier 2 · blackout calendar and rebalance at tier 3 · the annual cut, committing service and cost, at tier 4 |
| Risk and compliance flags | statutory minimum leave and carry-over · protected leave as a hard constraint outside the allotment · collective-agreement order in vacation bidding · co-determination over leave principles · late responses as the dominant trust failure · the leave liability on the balance sheet |
| Variant-prone steps | leave year and carry-over rule · allocation mechanism · a consultation step before publication · notice horizons by request class · response-time commitment |
| Automation candidates | eleven L2 sub-steps in six groups |

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

1. Receive the planned-shrinkage line for time off and the entitlement base — capacity planner.
2. Roll up the entitlement liability from the ledger: hours owed, accruing, expiring — capacity planner (HR partner contributes).
3. Does the plan absorb the liability within the shrinkage line? If not, raise the gap to GP-102 before cutting — capacity planner.
4. Shape the annual allotment curve inverse to the forecast, with the blackout calendar and its rationale — capacity planner.
5. Convert the curve to the weekly grid by unit and skill group — scheduler.
6. Confirm the allocation mechanism and the notice horizons by request class — scheduling lead (compliance lead contributes).
7. Approve the annual cut and the calendar — function head (tier 4).
8. Publish the calendar; open the primary allocation window — scheduler.
9. Run the allocation; issue every result with its reason inside the response-time commitment — scheduler.
10. Release the unallocated allotment to the rolling path in GP-202 — scheduler.
11. Is an out-of-allotment request protected leave or hardship? Protected leave is approved outside the allotment and the grid adjusted; hardship goes to tier 2 — team lead (HR partner contributes).
12. Read consumption against allotment and balances against liability monthly — capacity planner.
13. Has the plan or the forecast moved beyond the band? If so, re-cut, re-publish, record — capacity planner; approved at tier 3.
14. Close the leave year: spike forecast and pre-release — capacity planner; carry-over and fairness report — scheduling lead.

## L2 step table

Durations typical [A]; "½ day" is half a business day.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Extract the shrinkage line and entitlement rules in force | capacity planner | plan of record; rule register | planning base | ½ day | N | 203-01a |
| 2 | Roll up hours owed, accruing and expiring | capacity planner | balance ledger | liability roll-up | ½ day | Y | 203-02a |
| 2 | Reconcile the roll-up to headcount of record | capacity planner; HR partner | roll-up; headcount | reconciled liability | ½ day | Y | 203-02b |
| 3 | Compare liability to shrinkage line; raise an out-of-band gap | capacity planner | liability; shrinkage line | finding; escalation | SET LOCALLY | N | 203-03a |
| 4 | Compute the weekly release curve inverse to the forecast | capacity planner | forecast by week; liability | draft curve | 1 day | Y | 203-04a |
| 4 | Overlay blackouts; write the rationale per blackout | capacity planner | draft curve; event calendar | curve with blackouts | ½ day | N | 203-04b |
| 5 | Allocate the curve to units and skill groups as seats per day | scheduler | curve; roster | weekly grid | 1 day | Y | 203-05a |
| 6 | Confirm mechanism, horizons, response-time commitment | scheduling lead; compliance lead | rule and variant registers | year's parameters | ½ day | N | 203-06a |
| 7 | Present the cut: curve, grid, blackouts, liability, fairness history | function head | the pack | approval record | ½ day | N | 203-07a |
| 8 | Publish calendar; open window; notify | scheduler | approved pack | open window | SET LOCALLY | Y | 203-08a |
| 9 | Run the allocation in the mechanism in force | scheduler | requests; grid | provisional results | minutes | Y | 203-09a |
| 9 | Issue each result with its reason inside the commitment | scheduler | provisional results | approvals and declines | SET LOCALLY | Y | 203-09b |
| 10 | Mark the residual grid open to rolling requests | scheduler | results; grid | residual grid to GP-202 | minutes | Y | 203-10a |
| 11 | Classify an out-of-allotment request: protected, hardship, other | team lead; HR partner | request | classification | SET LOCALLY | N | 203-11a |
| 11 | Approve protected leave outside allotment; adjust grid | HR partner; scheduler | classification | grid adjustment | 1 day | N | 203-11b |
| 12 | Read consumption against allotment, balances against liability | capacity planner | ledger; grid; log | monthly read | ½ day | Y | 203-12a |
| 13 | Test plan and forecast movement against the rebalance band | capacity planner | plan; reforecast | re-cut trigger | minutes | Y (the test) | 203-13a |
| 13 | Re-cut, re-publish, record the rebalance | capacity planner; operations manager | trigger; step 4 inputs | revised curve and grid; record | 2 days | N | 203-13b |
| 14 | Forecast the year-end spike; pre-release allotment | capacity planner | balances; expiry rules | pre-release | 1 day | Y | 203-14a |
| 14 | Apply carry-over; close the year; publish fairness report | scheduling lead; HR partner | ledger; results | close record; report | 1 day | N | 203-14b |

## Variants

- **Statutory.** Minimum leave, leave year, carry-over and payout rules: parameters of steps 1 and 14, SET LOCALLY. Protected leave: the exception path of step 11, no row; the HR partner determines. Works-council co-determination over leave principles inserts a consultation step between cut and publication: liaison owns, function head approves, a row.
- **Contractual.** Vacation by seniority fixes the step 9 mechanism: a parameter. A client coverage floor through its own peak: a blackout with rationale, a parameter of step 4.
- **Structural.** A ledger not integrated with scheduling: roll-up reconciled by hand, step 2 varied and reviewed at each cut. A partner supply node planning its own leave: a contractual coverage floor instead of a grid, a row reviewed at renewal.
- **Transitional.** A predecessor organization's different leave year: a row expiring at the first harmonized close.

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

| Job aid | Anchored to | Form |
|---|---|---|
| Allotment calendar: cut, window, rebalance, close dates | steps 1–14 | work instruction |
| Liability roll-up query and reconciliation to headcount | step 2 | work instruction |
| Curve computation and release band | step 4 | work instruction |
| Blackout rationale template and annual blackout review | step 4 | playbook |
| Grid layout by unit and skill group | step 5 | work instruction |
| Allocation window procedure and mechanism in force | steps 8–9 | playbook |
| Exception path: protected leave, hardship, the tier 2 decision | step 11 | runbook |
| Monthly read and rebalance test | steps 12–13 | work instruction |
| Year-end close: spike forecast, pre-release, carry-over, fairness report | step 14 | playbook |

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

1. Allocation run (203-09a): deterministic under a stated mechanism; every declined-then-overturned result is a countable error.
2. Liability roll-up and reconciliation (203-02a, 02b): queries across the HR partner's ledger and the roster; a reconciliation sample first.
3. Weekly grid and release curve (203-05a, 04a): arithmetic on a graded forecast; catch rate net of forecast error; the blackout overlay stays human.
4. Publish, issue results, release the residual (203-08a, 09b, 10a): mechanical; errors surface through complaints, slower to establish.
5. Monthly read and rebalance test (203-12a, 13a): the trigger is computed, the re-cut decided; a trigger error shows only at the next cut.
6. Year-end spike forecast (203-14a): one observation per year.

Never a candidate: the annual cut (203-07a), a signature committing service
and cost; the protected-leave determination (203-11a, 11b), a legal finding
about an individual; the blackout rationale (203-04b), because an agent
cannot sign a reason.

Block 6 — gp-204-self-scheduling-and-flexible-workforce-administration.md

<!-- Derived from [[Self-Scheduling and Flexible Workforce Administration (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-204 — Self-Scheduling and Flexible Workforce Administration

Administers the parts of a schedule that people choose rather than receive:
eligibility, the rule set, the claimable catalogue and its tiered windows,
the open-shift pool, the gap-fill ladder when choice leaves coverage short,
and the periodic fairness review. The card owns L1 and L2; mechanisms and
evidence are on Autonomy and Schedule Self-Service, the model spectrum and
activation logic on Self-Scheduling and Flexible Workforce Models. The value
comes from the rule set and the gap-fill logic, not the portal; a rule set
is a process artifact with an owner, a change control and a review.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-204 · local id SET LOCALLY |
| Class | both: eligibility and rule-set work is planned; the pool and flex activation run close to the day |
| Trigger | the requirement and the fixed-roster build (GP-201) leave the claimable residual; a rule-set change request; the fairness-review calendar |
| Cadence | windows per scheduling period (weekly typical at Level 3 [A]) · pool continuous · eligibility register on each roster change · fairness review quarterly (SET LOCALLY) |
| Scope in | eligibility register · rule set · claimable catalogue · tiered windows · validation of picks, swaps, releases · open-shift pool · gap-fill ladder to flex activation · fairness review · revealed-preference capture |
| Scope out | the fixed-roster build (GP-201) · maintenance of committed shifts (GP-202) · same-day levers (GP-302) · contract forms (HR partner) · the well-being evidence |
| Inputs | requirement less fixed roster · roster with contract type and standing · rule set · premium structure · flex-pool register and triggers · last review's fairness metrics |
| Outputs | eligibility register · versioned rule set · claimable catalogue · validated commitments in the schedule of record · pool state and ageing · gap-fill record · fairness report · revealed-preference file |
| Upstream | GP-201 · GP-103 (variance signal for activation) · HR partner · Shift Design |
| Downstream | GP-202 and GP-303 (commitments as schedule of record) · GP-302 at the ladder's last rung · GP-601 (rule-set changes) · GP-602 (preference file) |
| Resources | self-service portal with rule validation · rule register · catalogue · flex-pool register · fairness metrics; platforms at L3 only |
| Decision points | eligible? · rule change touches a statutory or contractual term? · pick passes the rule set? · coverage at the floor after the windows? · which rung? · structural hole or equity breach? |
| Authority tier | validation and the pool at tier 1 (scheduler) · an eligibility change on an individual and the assignment rung at tier 2 · flex activation and a premium above the cap at tier 3 · the rule set and the fairness design at tier 4 |
| Risk and compliance flags | a claimed shift is a published schedule under notice-period statutes · access-to-hours rules favouring existing part-time staff · guaranteed-hours obligations accruing over a reference period · co-determination over working time · agreement swap restrictions · premium races |
| Variant-prone steps | eligibility criteria · rung order · premium cap · window tiers · a consultation step before a rule-set change · the reference-period review |
| Automation candidates | thirteen L2 sub-steps in seven groups |

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

1. Confirm the model scope per unit: self-scheduling, flex pool or fixed roster — scheduling lead.
2. Maintain the eligibility register on each roster change — scheduling lead owns (team lead maintains).
3. Maintain the rule set: minimum picks, weekend minimum, rest and hours, change buffer, commitment rule, skill floors, premium structure — scheduling lead (compliance lead contributes).
4. Does a proposed rule change touch a statutory or agreement term? If so, route through GP-603 before GP-601 — compliance lead.
5. Build the claimable catalogue from the requirement less the fixed roster — scheduler.
6. Open the pick windows in tiers; close each on the calendar — scheduler.
7. Validate every pick, swap and release; accept or reject with reason — scheduler, inside guardrails.
8. After close, does coverage meet the floor? If not, run the ladder: pool, capped premium, flex activation, assignment by fairness rule, overtime through GP-202 — scheduling lead.
9. Administer the open-shift pool: post, claim, release, age the unclaimed — scheduler.
10. Activate the flex pool on its triggers; notify in register order — real-time lead, approved at tier 3.
11. Write every commitment to the schedule of record as a version — scheduler.
12. Run the fairness review on the calendar: shift distribution by cohort, window outcomes, premium concentration, swap access, activation equity — scheduling lead.
13. Structural hole or equity breach? If so, raise a catalogue or rule-set change — scheduling lead.
14. Capture the revealed-preference file for the next catalogue and the reforecast — scheduler.

## L2 step table

Durations typical [A]; "½ day" is half a business day.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Confirm the model per unit from the plan of record | scheduling lead | plan; model register | period scope | ½ day | N | 204-01a |
| 2 | Apply the criteria to each roster change | team lead | roster change; criteria | register update | minutes | Y (the test, not the criteria) | 204-02a |
| 2 | Decide a contested eligibility case | team lead | case | decision with reason | SET LOCALLY | N | 204-02b |
| 3 | Hold the rule set as a versioned register | scheduling lead | rule register | current version | continuous | N | 204-03a |
| 4 | Screen a rule change for statutory or contractual touch | compliance lead | change request | routing decision | 1 day | N | 204-04a |
| 5 | Subtract the fixed roster from the requirement by interval and skill | scheduler | requirement; fixed roster | residual | minutes | Y | 204-05a |
| 5 | Cut the residual into claimable shifts from the catalogue | scheduler | residual; catalogue | claimable catalogue | ½ day | Y | 204-05b |
| 6 | Open each tier, notify, close | scheduler | catalogue; eligibility register | picks | SET LOCALLY | Y | 204-06a |
| 7 | Validate a pick, swap or release against the rule set | scheduler | request; rule set | accept or reject with reason | seconds | Y | 204-07a |
| 7 | Review rejections for rule errors | scheduler | rejection log | corrections; rule defects | daily | N | 204-07b |
| 8 | Compute coverage against the floor after close | scheduling lead | commitments; requirement | gap by interval and skill | minutes | Y | 204-08a |
| 8 | Issue the capped premium offer as a rung | scheduling lead | gap; premium structure | offer record | SET LOCALLY | Y | 204-08b |
| 8 | Decide the move to the next rung; record it | scheduling lead | gap after offer; ladder order | gap-fill record | SET LOCALLY | N | 204-08c |
| 9 | Post, claim and release in the pool | scheduler | pool; eligibility register | pool state | continuous | Y | 204-09a |
| 9 | Age the unclaimed; alert at the band | scheduler | pool state | ageing alert | continuous | Y | 204-09b |
| 10 | Test the activation triggers | real-time lead | reforecast; variance band | activation proposal | minutes | Y (the proposal) | 204-10a |
| 10 | Approve activation; notify in order | operations manager; real-time lead | proposal; flex register | activation record | SET LOCALLY | N | 204-10b |
| 11 | Write commitments as a version | scheduler | accepted commitments | schedule of record | minutes | Y | 204-11a |
| 12 | Assemble the fairness report by cohort | scheduling lead | commitments; history; cohorts | report | 1 day | Y | 204-12a |
| 13 | Decide hole or breach; raise the change | scheduling lead | report | change request | SET LOCALLY | N | 204-13a |
| 14 | Capture picks, order, unclaimed and clearing premium | scheduler | window and pool logs | preference file | minutes | Y | 204-14a |

## Variants

- **Statutory.** Under a predictive-scheduling statute a claimed shift is a published schedule: notice period and premium are parameters of step 11, SET LOCALLY. An access-to-hours rule fixes the rung order: a parameter of step 8. A guaranteed-hours obligation adds a reference-period review after step 14: HR partner owns, function head approves, a row. Co-determination over working time inserts a consultation step before any rule-set change: a row.
- **Contractual.** Agreement swap restrictions parameterize step 7. An agreement prohibiting an open-shift marketplace sets the unit's row to `blocks` against candidates 3 and 5, and 4 where the windows are marketplace windows. Client-dedicated named staff are ineligible: a parameter of step 2.
- **Structural.** No portal: windows by hand, steps 6, 7 and 9 varied with a review date. A partner supply node running its own flex pool supplies capacity under a contractual floor and does not enter the ladder: a row reviewed at renewal.
- **Transitional.** Legacy flexible-contract terms from a predecessor organization: premium structure kept under a row expiring at renegotiation.

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

| Job aid | Anchored to | Form |
|---|---|---|
| Eligibility criteria and contested-case procedure | step 2 | work instruction |
| Rule register layout, version and change path | steps 3–4 | work instruction |
| Residual computation and catalogue cut | step 5 | work instruction |
| Window calendar and tier design | step 6 | playbook |
| Validation rules as test cases, expected reason per rejection | step 7 | work instruction |
| Gap-fill ladder: rung order, premium cap, activation triggers, assignment rule | steps 8, 10 | playbook |
| Pool procedure and ageing band | step 9 | work instruction |
| Fairness review template, cohorts and bands | step 12 | playbook |
| Response when a shift never clears or a breach is found | step 13 | runbook |

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

1. Pick validation and eligibility test (204-07a, 02a): rules and criteria evaluated per request; every rejection overturned on review is a countable error.
2. Residual, catalogue cut and post-close coverage (204-05a, 05b, 08a): arithmetic on a graded requirement; catch rate net of forecast error.
3. Pool and ageing alert (204-09a, 09b): errors surface through claims and complaints, not a check.
4. Window procedure and commitment write (204-06a, 11a): errors visible outside the function where a claimed shift is a published schedule; longer observation window.
5. Premium offer within the cap (204-08b): the offer is issued, the move to the next rung (204-08c) is not; a wrong-order or over-cap offer is a cost and, in a unionized unit, a grievance.
6. Activation proposal (204-10a): a mistimed proposal is known wrong only once the day has run.
7. Fairness report and preference file (204-12a, 14a): errors of cohort definition, caught one review per quarter.

Never a candidate: the eligibility decision on an individual (204-02b); the
assignment rung, which mandates a person to a shift they did not choose; the
rule set itself (204-03a), because it is the standard, and a standard that
rewrites itself cannot be certified.

Usage notes

Sizing. Block 1 is about 585 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 about 1,050 to 1,600 words each, the three cards that own their L2 (GP-201, GP-203, GP-204) being the largest because each carries a twenty-row 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.

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, or to name a platform in a file marked for publication. 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, predictive-scheduling and protected-leave variants are examples of the classes, not a list of the jurisdictions a function operates in.

Change history

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

See also

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