Wiki:Packs/Cross-Cutting Governance Processes

From WFM Labs
Pack
ID CP-OPS-014
Name Cross-Cutting Governance Processes
Domain OPS
Blocks 1 instruction + 7 reference
Version 1.0
Source Standards Governance and Change Control (generic process) · Weekly Forecast-vs-Actual Review (generic process) · Compliance Review for Workforce Operations (generic process) · Report Publication (generic process) · Time and Production Accounting Audit (generic process) · Definitions and Source-of-Truth Change Control (generic process) · Standard and Variant in Process Documentation · Decision Authority Tiers in Workforce Operations · Human Gates and Number Grades · Process Decomposition (L0–L3) · Process Shells for a Workforce Standard
Planning-week block Day 4 morning (the standard's owners and dates; the cross-cutting sections of the catalog)

A deployable Claude project setup for localizing the six cross-cutting governance cards of a workforce function's standard: the standards committee's own change control (GP-601), the weekly forecast-vs-actual review (GP-602), the compliance review (GP-603), report publication (GP-604), the time and production accounting audit (GP-605) and the change control for definitions and sources of truth (GP-606). Each card arrives generic, with its local values marked SET LOCALLY and its automation candidates flagged; the pack walks a function through settling each profile row, confirming each owner seat, writing the variant rows and emitting the four decomposition artifacts plus a variant file. Copy Block 1 into a project's custom instructions; save Blocks 2–8 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function is deploying the governance section of its standard: a standards committee to charter or re-charter, a weekly review to put on a calendar, a compliance programme to give a sampling rule and a findings register, a report catalog to put under a publication gate, an accounting audit to run before capacity standards are agreed, or a definitions register to put under change control. The pack carries the cards; Wiki:Packs/Process Decomposition (CP-OPS-001) is the engine that emits the L0–L3 artifacts, and the two are used in the same project. It is not for authoring the standard's prose sections (Wiki:Packs/ROC Standard Authoring), for cataloging processes not yet documented (Wiki:Packs/Process Inventory and Shell Catalog), or for the pillar processes the governance cards sit around, which the sibling packs carry. In a planning week it serves the Day 4 morning return, when the cross-cutting sections of the catalog are issued with an owner and a date.

How to deploy

  1. Create a project in Claude named for the work, not the method: "Governance cards for the function standard", not "Process localization".
  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; upload framework.md from CP-OPS-001 beside them.
  4. Start a conversation by naming the card (GP-601 to GP-606) and the function's pillars, sites, supply nodes and partners; have the standard's section owner present for the L1 walk.

Block 1 — Project instructions

You are localizing generic process cards for the cross-cutting governance
pillar of a workforce function's standard: the processes that govern the
standard itself, close the weekly loop between the planning pillars, test the
operation against its obligations, publish its reports, audit its time and
production accounting, and control its definitions. The cards are in the
reference files; `localization-rules.md` holds the conventions. CP-OPS-001
(`framework.md`) is the engine that emits the artifacts; this pack carries
the cards.

Routing — open the file the task names:

| Task | File |
|---|---|
| Any card: marks, the variant test, tiers, grades, the release rule | `localization-rules.md` |
| The standards committee's sitting: batch, queue, gate, baseline, sweep | `gp-601-standards-governance-and-change-control.md` |
| The weekly thirty-minute forecast-vs-actual review and its action log | `gp-602-weekly-forecast-vs-actual-review.md` |
| The compliance review of schedules, time records and placements | `gp-603-compliance-review-for-workforce-operations.md` |
| Publishing a catalogued report: citations, grades, gate, distribution | `gp-604-report-publication.md` |
| The time and production accounting audit and its gap register | `gp-605-time-and-production-accounting-audit.md` |
| A change to a definition, a source-of-truth row or a lineage card | `gp-606-definitions-and-source-of-truth-change-control.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.
4. Run the variant test on every local difference and write the variant rows.
5. Carry the automation candidates over unchanged 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; write SET LOCALLY with
  the owning seat instead.
- Never name a product in any file marked for publication.
- Surface two owners on one step as a finding, not a footnote.
- Keep the card's grade on every number; a figure the user supplies enters
  at the grade the user states, [A] if none is stated.
- The rows a card marks "never a candidate" stay human.
- GP-601 governs the standard's text and GP-606 the numbers it computes on;
  a request touching both is two changes, logged separately.
- Tier words only: tier 1 analyst seat inside guardrails · tier 2 supervisor
  or team lead · tier 3 operations manager or ROC duty lead · tier 4
  function head · executive sponsor by exception.
- Seats, never names, in every owner, approver and signatory field.
- One card per conversation.

Output: the five Markdown files, each headed with the card id, the local
card id, version and date, every L2 row carrying its documentation join key
so a job aid, a ticket and a variant row can cite it; 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, to emit an
L2 with an unowned step or an ungraded number, or to publish a file that
names a platform.

Source: Wiki:Packs/Cross-Cutting Governance Processes (CP-OPS-014) 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-601-standards-governance-and-change-control.md

<!-- Derived from [[Standards Governance and Change Control (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-601 — Standards Governance and Change Control

The standards committee's recurring sitting as change-control board: table
the intake batch, re-rank the queue, sit the acceptance gate, baseline what
was approved, read the sweep list, publish the compliance report. Lifecycle
steps are cited by ID (1.1 screen · 1.2 author · 1.3 peer review · 2.1 gate
· 2.2 deploy · 3.1 review · 3.2 conformance). One holder of the standard;
one record of what changed.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-601 · local id assigned at deployment |
| Class | supporting |
| Trigger | the sitting calendar; between sittings, an intake-door request, an expired package, an odd case from 3.1 |
| Cadence | SET LOCALLY (fortnightly in the first wave, monthly after, is typical [A]); sweep annually against expiry |
| Scope in | every catalog package; new/modify requests; queue and deferred log; gate sittings; baselines; variant admissions; the sweep |
| Scope out | authoring and peer review (1.2, 1.3); process content; conformance certification (methodology steward); improvement work; GP-606 |
| Inputs | intake batch (six fields per request); catalog with wave ranks and expiry; gate checklist; odd-case log and catch rates; variant register |
| Outputs | ranked queue; gate response per package (approved · conditionally approved · not approved); baseline and change record; sweep list; compliance report; deferred log |
| Upstream | intake door; process owners; overseer; legal partner and works-council liaison; placement function (a new supply node) |
| Downstream | training lead; automation analyst; catalog and pillar packs; every card's local copy; executive issue register by exception |
| Resources | catalog and queue register; versioned repository; gate checklist; board calendar; change record. Platforms at L3 only |
| Decision points | queue entry; minor modify; re-rank; gate response; go/no-go; certify or remediate |
| Authority tier | minor modify to L2/L3: tier 2 (process owner) · major request admitted: tier 3 (standardization lead, chair) · a version of the standard: tier 4 (function head for new; the L0's approvers for modify) · compliance-finding closure: tier 4 · scope change: executive sponsor by exception |
| Risk and compliance flags | two copies of one process; an expired package still cited; machine-track build on an ungated L2; a variant admitted on preference; a migration lead certifying the standard it is measured against |
| Variant-prone steps | gate docket where a works council must see a working-time change; deployment calendar at a partner supply node; sweep cadence under a client audit cycle |
| Automation candidates | six L2 rows marked Y (ranked below) |

## L1 flow (one owner seat per step)

1. Table the intake batch since the last sitting (standardization lead).
2. Screen and class (1.1): queue, deferred log with review date, or minor modify? (standards committee)
3. Route minor modifies to their process owners for the tier 2 edit (standards committee).
4. Re-rank: does the batch change the wave order, given that the agent team's first processes stay in wave one? (standards committee)
5. Name process owner and two peer reviewers, as seats, per new package (standards committee).
6. Record authoring and review status (1.2, 1.3) on each L0 (standardization lead).
7. Sit the gate (2.1): approved, conditionally approved or not approved? (approvers named on the L0)
8. Baseline each approved package; write the change record (standardization lead).
9. Hand baselines to the two deployment tracks (2.2); set go/no-go dates (process owner).
10. Table odd cases and catch rates from 3.1: does any need a modify request? (process owner)
11. Sweep: which packages expire next cycle, which have expired? (methodology steward)
12. Conformance check (3.2): certified at a band, or remediation owned and dated? (methodology steward)
13. Publish the compliance report; expired packages re-enter the next batch as modifies (standardization lead).

## L2 step table

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Assemble the batch; return incomplete requests | standardization lead | intake log | batch | before the sitting | Y | GP-601/1.1 |
| 2 | Search the catalog for an existing package or shell | standards committee | catalog | match or none | minutes [A] | Y | GP-601/2.1 |
| 2 | Score importance and volume (scales SET LOCALLY); class new/modify, major/minor | standards committee | request; scales | classed request | one sitting | N | GP-601/2.2 |
| 3 | Record the minor modify, process owner as editor | standards committee | minor modify | routed edit | minutes [A] | N | GP-601/3.1 |
| 4 | Propose a re-rank from scores and dependency pulls | standardization lead | scores; dependencies | proposed order | before the sitting | Y | GP-601/4.1 |
| 4 | Confirm the order under the leadership constraint; publish | standards committee | proposal | ranked queue | one sitting | N | GP-601/4.2 |
| 5 | Fill the L0 people block; set the authoring window | standards committee | queue | people block | one sitting | N | GP-601/5.1 |
| 6 | Record status on each L0 | standardization lead | owners' reports | status rows | minutes [A] | N | GP-601/6.1 |
| 7 | Circulate package and checklist; open the turnaround clock | standardization lead | package | gate sitting | five business days [E] | N | GP-601/7.1 |
| 7 | Record the response; carry conditions on the L0 with owner and date | approvers named on the L0 | checklist | gate response | one sitting | N | GP-601/7.2 |
| 8 | Issue version; store baseline; write change record (what, why, who, effective date) | standardization lead | approved package | baseline; record | same day [A] | Y | GP-601/8.1 |
| 9 | Hand baseline to training lead and automation analyst; schedule go/no-go | process owner | baseline | two track plans | one sitting | N | GP-601/9.1 |
| 10 | Draft a modify request per unabsorbed odd case | process owner | odd-case log | modify requests | per review cadence | Y | GP-601/10.1 |
| 11 | List packages by expiry; flag expiring and expired | methodology steward | catalog | sweep list | before the sitting | Y | GP-601/11.1 |
| 12 | Check flagged packages against the conformance ladder; record band or remediation | methodology steward | sweep list; audit record | compliance report | per validation cadence | N | GP-601/12.1 |
| 13 | Publish; route expired packages into the next batch | standardization lead | report | published status | same day [A] | N | GP-601/13.1 |

## Variants

- **Statutory.** Works council co-determining working time: consultation step between 6 and 7, owned by the works-council liaison; variant row.
- **Contractual.** Notice period before a process change at a partner supply node: parameter of step 9, SET LOCALLY, no row.
- **Structural.** Repository without versions: manual version log at step 8; variant row reviewed each sweep.
- **Transitional.** A predecessor organization's board still approving its packages: variant row expiring at the cut-over.

## L3 register

| Job aid | Anchored to | Form |
|---|---|---|
| Intake form, six fields | step 1 | work instruction |
| Importance-by-volume screen, two scales | step 2 | work instruction |
| Queue register, wave-rank rule | step 4 | work instruction |
| Gate checklist, three responses, turnaround clock | step 7 | work instruction |
| Version-numbering and baseline rule | step 8 | work instruction |
| Two-track deployment plan, go/no-go record | step 9 | playbook |
| Odd-case intake, "revised together" rule | step 10 | playbook |
| Expired-package runbook | steps 11 to 13 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)

1. Catalog check (2.1): deterministic; misses visible at the next sitting.
2. Sweep list (11.1): as deterministic, but errors surface only at the validation cadence.
3. Baseline and change record (8.1): clerical; a wrong record is found only when read.
4. Intake batch (1.1): an incomplete request is caught by the requester's reply, not a rule.
5. Re-rank proposal (4.1): the board's final order is the only measure of its error.
6. Odd-case draft (10.1): its error is a request the owner declines, a judgment, not a catch.

Never a candidate: the gate (7.2), a named seat's commitment to drive adoption and accept audit; the screen (2.2), a judgment the board owns.

Block 4 — gp-602-weekly-forecast-vs-actual-review.md

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

The weekly thirty-minute [A] review at which forecasting, scheduling and
real-time compare the forecast of record with actuals by driver (volume,
handle time, shrinkage, attendance), attribute each signal variance to the
function that owns it, and decide what changes: the one point where the
three pillars' feedback loop closes on a calendar. Not the accuracy
measurement (GP-106), not the reforecast (GP-103), not incident learning.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-602 · local id assigned at deployment |
| Class | both |
| Trigger | first business day after the week's actuals close |
| Cadence | weekly; thirty minutes [A]; closed week against the vintage in force at schedule build, coming two weeks against the latest |
| Scope in | every queue and client portfolio; the four drivers; noise test; attribution; decisions; action log |
| Scope out | accuracy measures (GP-106); the reforecast; incident learning; intraday steering (GP-301) |
| Inputs | forecast by vintage; actuals by driver on register definitions; event log; post-lock variance log; adherence summary; stairstep where kept; last week's log |
| Outputs | attributed variance table with grades; decisions; action log (owner seat, date); items routed to reforecast, schedule maintenance, lever policy, collision calendar, or logged out of scope |
| Upstream | real-time (GP-301); scheduling (GP-202); forecasting (GP-103); definitions register |
| Downstream | GP-103 (trigger); GP-202; GP-302; GP-106 (stairstep); collision calendar; post-mortem for an incident |
| Resources | forecast store with vintages; reporting view by driver; event log; action log; a standing slot with the three leads. Platforms at L3 only |
| Decision points | signal or noise; owning function; reforecast; schedule change; lever-policy change; incident |
| Authority tier | chair at tier 3 (planning lead or ROC duty lead) · reforecast inside the lock threshold at tier 1 (forecaster) · locked-month change via exception path at tier 4 · lever policy at tier 3, tier 4 where committed cost changes |
| Risk and compliance flags | attribution read as blame (function, never person); acting on common-cause variation; a partner's billable hours changed is change control; a schedule change inside a notice window carries predictability pay |
| Variant-prone steps | driver set where a channel has no in-contact state; attendance under works-council limits; schedule change inside a notice window; lever policy at a partner supply node |
| Automation candidates | six L2 rows marked Y (ranked below) |

## L1 flow (every row in the pack; only signal rows discussed)

1. Assemble the pack by driver per queue, each number graded (reporting analyst).
2. Do both sides cite the same register entry and version? (reporting analyst)
3. Walk the four drivers in order, signal rows only (planning lead, chair).
4. Outside the noise band? If not, recorded, not discussed (planning lead).
5. Read the event log and post-lock variance log per signal (real-time lead).
6. Forecast, schedule, steering, or incident? Chair decides after hearing the three leads (planning lead).
7. Recurring signature? Forecast input, response library or collision calendar? (forecasting lead)
8. Reforecast? Inside the lock threshold the forecaster acts at tier 1; above it, the exception path (forecaster).
9. Change to coming weeks' schedules? (scheduling lead)
10. Lever-policy change: overtime, voluntary time off, skill rebalancing, break resequencing? (real-time lead)
11. Write the action log: item, owner seat, date, closing observation (planning lead).
12. Close last week's actions, age open ones, publish (planning lead).

## L2 step table

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Pull the vintage in force at schedule build and actuals by driver per queue; carry grades | reporting analyst | forecast store; reporting view | pack | minutes [A] | Y | GP-602/1.1 |
| 1 | Attach stairstep and last week's log | reporting analyst | stairstep; log | full pack | minutes [A] | N | GP-602/1.2 |
| 2 | Confirm entry ID and version both sides; withhold mismatches | reporting analyst | pack; register | checked pack | minutes [A] | Y | GP-602/2.1 |
| 3 | Walk drivers in order; signal rows only; keep to the slot | planning lead | pack | walked pack | thirty minutes [A] | N | GP-602/3.1 |
| 4 | Compare with the noise band per driver and queue (SET LOCALLY) | planning lead | pack; band | signal or noise per row | before the slot | Y | GP-602/4.1 |
| 5 | Read both logs for the signal's queue and days | real-time lead | two logs | context | inside the slot | N | GP-602/5.1 |
| 6 | Propose attribution; hear the three leads; decide | planning lead | context | attributed row | inside the slot | Y | GP-602/6.1 |
| 6 | Route an incident to post-mortem; drop from attribution | planning lead | attributed row | routed item | minutes [A] | N | GP-602/6.2 |
| 7 | Test recurrence against prior weeks' tables | forecasting lead | tables | recurring or not | inside the slot | Y | GP-602/7.1 |
| 7 | Choose destination; record | forecasting lead | recurring signature | routed item | inside the slot | N | GP-602/7.2 |
| 8 | Compare with the lock threshold (SET LOCALLY); act or route to the exception path | forecaster | variance; threshold | reforecast trigger or exception item | minutes [A] | N | GP-602/8.1 |
| 9 | Raise a schedule change request with reason and, inside a notice window, pay estimate | scheduling lead | attributed row | change request | minutes [A] | N | GP-602/9.1 |
| 10 | Raise a lever-policy change with reason and cost effect | real-time lead | attributed row | policy change | minutes [A] | N | GP-602/10.1 |
| 11 | Write each action with closing observation | planning lead | decisions | action log | inside the slot | N | GP-602/11.1 |
| 12 | Age open actions; close observed ones; publish | planning lead | last week's log | published log | minutes [A] | Y | GP-602/12.1 |

## Variants

- **Statutory.** Works council restricting individual attendance review: team aggregate in the review, individual follow-up to the supervisor; variant row owned by the works-council liaison. Fair-workweek notice window: step 9 parameters, SET LOCALLY, no row.
- **Contractual.** Lever-policy change altering a partner's billable hours follows the contract's change-control clause: SET LOCALLY, no row.
- **Structural.** Asynchronous channel with no observable handle time: work-item throughput replaces the driver; variant row reviewed quarterly.
- **Transitional.** A client portfolio from a predecessor organization on its own forecast calendar: variant row expiring at the cut-over.

## L3 register

| Job aid | Anchored to | Form |
|---|---|---|
| Pack template, grade column, vintage stamp | step 1 | work instruction |
| Thirty-minute agenda, driver order, signal-only rule | step 3 | work instruction |
| Noise band per driver and queue | step 4 | work instruction |
| Attribution decision tree | step 6 | playbook |
| Recurring-signature test, three destinations | step 7 | playbook |
| Reforecast-trigger rule, exception-path routing | step 8 | work instruction |
| Schedule change and lever-policy change forms | steps 9 to 10 | work instruction |
| Action log layout, closing-observation rule | steps 11 to 12 | work instruction |
| Missed-review runbook | steps 1 to 12 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)

1. Pack assembly (1.1): deterministic; a wrong pack is caught in the room the same week.
2. Definitions check (2.1): a missed mismatch is found only when two numbers disagree later.
3. Noise-band flagging (4.1): a signal flagged as noise is seen only if someone reads the undiscussed rows.
4. Action-log ageing (12.1): a mis-aged action is noticed only when its owner is asked.
5. Recurrence test (7.1): misses are invisible until the signature recurs again.
6. Attribution proposal (6.1): the chair's decision is the only measure of its error.

Never candidates: steps 8, 9 and 10, each changing what the floor does or the business commits to; the review's value is deciding fewer things, with reasons.

Block 5 — gp-603-compliance-review-for-workforce-operations.md

<!-- Derived from [[Compliance Review for Workforce Operations (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-603 — Compliance Review for Workforce Operations

The periodic review testing published schedules, time records and placement
decisions against labour law, collective agreements and works-council
rulings, client contract terms, and audit requirements. It produces findings
with owner and remediation date and an evidence trail, and is where a local
difference found in operation becomes a variant row or a preference finding.
Shape: a management-system audit. Obligations live on the obligation
register, never in the card.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-603 · local id assigned at deployment |
| Class | supporting |
| Trigger | review calendar; by event, a changed obligation, a new supply node or client, a grievance, an audit notice |
| Cadence | sample monthly, full quarterly is typical [A] (SET LOCALLY); external audit cycle as set by certifier or contract |
| Scope in | schedules and change logs; time records (hours, rest, breaks, overtime); overtime and voluntary time off distribution; placements; predictability- and premium-pay record; findings, remediation, evidence |
| Scope out | legal interpretation; building a compliant schedule (GP-201); payroll; the external audit itself; disciplinary matters |
| Inputs | obligation register (source, jurisdiction, effective date); schedule as published and every change with timestamp and reason; time records; variant register; placement gate record; prior findings |
| Outputs | findings register (class, severity, owner, date); remediation plan; evidence pack; variant requests and preference findings to GP-601; attestation |
| Upstream | legal and HR partners; works-council liaison; placement function; certification calendar |
| Downstream | GP-201, GP-202 (constraints); GP-302 (lever limits); GP-601; payroll; executive issue register for statutory exposure |
| Resources | obligation register; schedule change log; time-record extract; sampling rule; findings register; evidence repository with retention rule. Platforms at L3 only |
| Decision points | in scope; deviation or documented exception; severity; breach, missing variant or preference; escalation or disclosure |
| Authority tier | review at tier 3 (compliance lead) · closure and severity at tier 4 (function head) · statutory exposure to the executive sponsor by exception · interpretation always with the legal partner |
| Risk and compliance flags | a review without a sampling rule proves nothing; an unowned finding recurs; time records are personal data; back-pay and premium-pay liabilities; grievance exposure where scheduling is a mandatory bargaining subject |
| Variant-prone steps | sampling rule by jurisdiction; works-council access to findings; client audit rights over sample and format; retention period |
| Automation candidates | seven L2 rows marked Y (ranked below) |

## L1 flow (one owner seat per step)

1. Any obligation changed? Refresh the register on legal notices (compliance lead).
2. Which sites, supply nodes, periods and rules are sampled? (compliance lead)
3. Extract schedule, change log and time records (reporting analyst).
4. Working-time rules met: daily and weekly rest, average hours over the reference period, consecutive days, breaks? (compliance analyst)
5. Changes inside a notice window, and was the pay generated and paid? (compliance analyst)
6. Overtime and voluntary time off offered in the agreement's order? (compliance analyst)
7. Work placed only where statute and contract permit the construct? (placement and vendor lead)
8. Finding, or documented exception on the variant register? (compliance lead)
9. Severity, and breach, missing variant or preference? Legal partner advises (compliance lead).
10. Route: breach to remediation owner and date; missing variant to GP-601; preference to the process owner (compliance lead).
11. Assemble the evidence pack (compliance analyst).
12. Statutory exposure (executive sponsor, by exception) or disclosure to a works council or client? (function head)
13. Attest; close remediated findings; age open ones (function head).

## L2 step table

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Collect obligation changes; update register rows | compliance lead | partners' notices | current register | one sitting | N | GP-603/1.1 |
| 2 | Apply the sampling rule (SET LOCALLY); include open findings' areas | compliance lead | register; rule | sample | one sitting | N | GP-603/2.1 |
| 3 | Extract schedule, changes (timestamp, reason, approver), time records; restrict access | reporting analyst | systems of record | schedule, change, time sets | minutes [A] | Y | GP-603/3.1 |
| 4 | Test daily and weekly rest, average hours over the reference period, consecutive days (SET LOCALLY) | compliance analyst | schedule set; rules | deviations | hours [E] | Y | GP-603/4.1 |
| 4 | Test break placement and duration (SET LOCALLY) | compliance analyst | schedule set | deviations | hours [E] | Y | GP-603/4.2 |
| 5 | Compare change timestamps with the jurisdiction's notice window | compliance analyst | change set | in-window changes | hours [E] | Y | GP-603/5.1 |
| 5 | Confirm pay obligation generated and reached payroll | compliance analyst | in-window changes; payroll extract | deviations | hours [E] | N | GP-603/5.2 |
| 6 | Reconstruct offer order from the offer log | compliance analyst | offer log; order rule | deviations | hours [E] | Y | GP-603/6.1 |
| 7 | Compare placements with gate record and permitted constructs | placement and vendor lead | gate record; register | deviations | one sitting | N | GP-603/7.1 |
| 8 | Match deviations to the variant register; close documented exceptions by variant ID | compliance lead | deviations; variant register | findings | one sitting | Y | GP-603/8.1 |
| 9 | Grade severity (SET LOCALLY); class cause on legal advice | compliance lead | findings | classed findings | one sitting | N | GP-603/9.1 |
| 10 | Open remediation row (owner, date, verification evidence) or route to GP-601 with finding ID | compliance lead | classed finding | remediation row or routed item | minutes [A] | N | GP-603/10.1 |
| 11 | Assemble pack: scope, sample, tests, results, findings, sign-offs; file under retention | compliance analyst | all above | evidence pack | hours [E] | Y | GP-603/11.1 |
| 12 | Test statutory exposure and disclosure thresholds (SET LOCALLY) | function head | classed findings | exceptions; disclosures | one sitting | N | GP-603/12.1 |
| 13 | Verify closure evidence; attest; age the rest | function head | remediation rows; evidence | attestation | one sitting | N | GP-603/13.1 |

## Variants

- **Statutory.** Works council with the right to monitor compliance: disclosure step after 12 owned by the works-council liaison; variant row. Working-time changes themselves are GP-201's variant.
- **Contractual.** Client audit right fixing sample and evidence format: parameters of steps 2 and 11, SET LOCALLY, no row.
- **Structural.** Time records in a partner's system: step 3 takes a partner extract with its own lineage; variant row reviewed quarterly.
- **Transitional.** A predecessor organization's calendar and findings register until the cut-over; findings then transfer, row expires.

## L3 register

| Job aid | Anchored to | Form |
|---|---|---|
| Obligation register layout and sources | step 1 | work instruction |
| Sampling rule | step 2 | work instruction |
| Extraction queries, access restriction | step 3 | work instruction |
| Working-time test checklist per jurisdiction | step 4 | work instruction |
| Notice-window and pay-obligation test | step 5 | work instruction |
| Offer-order test | step 6 | work instruction |
| Severity scale; breach · variant · preference tree | step 9 | playbook |
| Evidence pack template, retention rule | step 11 | work instruction |
| Audit-notice runbook | steps 2 to 11 | runbook |
| Statutory-exposure escalation path | step 12 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)

1. Rest-interval test (4.1): statutory minima explicit and checkable by hand; the reference-period average is SET LOCALLY and released separately.
2. Notice-window test (5.1): the window differs by jurisdiction; a wrong one is found only when pay is disputed.
3. Break test (4.2): break length is left to national law or agreement, so parameterized per site first.
4. Extraction (3.1): an incomplete extract hides deviations rather than producing them.
5. Variant match (8.1): a stale variant register makes a correct match wrong.
6. Offer-order test (6.1): an agreement counting refusals differently per classification may block it under its variant row.
7. Evidence pack assembly (11.1): its error, an omission, is found only by the auditor.

Never candidates: classification (9.1), interpretation the legal partner holds; attestation (13.1), a signature by the person accountable.

Block 6 — gp-604-report-publication.md

<!-- Derived from [[Report Publication (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-604 — Report Publication

The cycle by which a function publishes its catalogued reports, each
answering a standing question for named seats. Every number cites its
register entry and version and carries a grade; the issue leads with its
answer; a report publication gate releases, holds or withdraws it;
distribution is by seat; a sweep retires reports nobody reads. This gate is
distinct from the schedule publication gate and the register-review gate: it
releases a recurring issue of a catalogued report.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-604 · local id assigned at deployment |
| Class | supporting |
| Trigger | report calendar, per report; a register version change affecting its entries; the sweep date |
| Cadence | per report as the catalog row states; readership and retirement sweep quarterly [A] (SET LOCALLY) |
| Scope in | every catalogued report; citation and grade per number; answer layer; gate; distribution by seat; readership; retirement |
| Scope out | new-question intake; one-off answers; the definitions; the data pipeline; a wallboard refreshed without a publication act |
| Inputs | catalog row (question, owner seat, cadence, entries, distribution seats, last-read date); register at current version; numbers with grades; previous issue; readership record |
| Outputs | published issue (answer layer, grade column, citations, version stamp); publication record; distribution; readership record; retire/merge/keep decisions; updated catalog |
| Upstream | definitions register; the processes whose outputs reports carry (vintages, schedules, event logs, GP-602's table); data platform |
| Downstream | every seat on a distribution list; governance committee cadence; executive issue register where a first-layer sentence names a decision |
| Resources | report catalog; reporting platform with governed semantic layer; publication record; seat-keyed distribution lists; readership measure. Platforms at L3 only |
| Decision points | current entry cited; grade present; one-sentence answer; release, hold, withdraw; which seats; retire, merge, keep |
| Authority tier | routine issue: tier 1 (reporting analyst) · hold or withdrawal: tier 3 (reporting lead) · issue naming a decision or finance commitment: tier 4 (function head) · superseded-entry issue held by the register owner · executive sponsor by exception |
| Risk and compliance flags | an ungraded number reads as measured; two definitions of one metric; an issue reaching the wrong seat (personal data, partner terms); undeclared superseded entry; an unread report still costing an analyst's morning |
| Variant-prone steps | distribution under works-council or contract restriction; calendar at a partner supply node; retention rule |
| Automation candidates | eight L2 rows marked Y (ranked below) |

## L1 flow (report owner = catalog row's seat: reporting analyst for routine, function head for decision-bearing)

1. Open the issue from its catalog row (reporting analyst).
2. Pull the numbers with grades (reporting analyst).
3. Every number cites a register entry by ID and current version? A mismatch is held and referred; if released, the issue says so (reporting analyst).
4. Every number graded, computed figures no better than their weakest input? (reporting analyst)
5. Write the first layer: one actionable sentence with its grade; name the signals; hold the detail (report owner).
6. Name the observation that would change the answer (report owner).
7. Gate: release, hold or withdraw? The holder produces an amended figure, a reason or a decision per flagged row, never a bare approval (report owner).
8. Stamp the version; write the publication record (reporting analyst).
9. Distribute by seat, never a person (reporting analyst).
10. Record readership (reporting analyst).
11. Sweep: which reports had no reader and answer no standing question? (reporting lead)
12. Retire, merge or keep; update the catalog; announce where each retired question is now answered (reporting lead).

## L2 step table

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Read the catalog row; confirm period and question unchanged | reporting analyst | catalog | opened issue | minutes [A] | N | GP-604/1.1 |
| 2 | Pull each number with grade, cited entry, required pairing | reporting analyst | ledger or platform; register | paired number set | minutes [A] | Y | GP-604/2.1 |
| 3 | Compare cited versions with the register's current | reporting analyst | number set; register | matches; mismatches | minutes [A] | Y | GP-604/3.1 |
| 3 | Hold a mismatch; refer to register owner; note superseded version if released | reporting analyst | mismatch | held or annotated number | same day [A] | N | GP-604/3.2 |
| 4 | Check computed grades against inputs; downgrade; reject ungraded numbers | reporting analyst | number set; formulas | graded set | minutes [A] | Y | GP-604/4.1 |
| 5 | Draft the answer sentence with claim grade (established · inferred · asserted · open) | report owner | graded set | first layer | inside the issue window | Y | GP-604/5.1 |
| 5 | Name two to five signals; link each to its number | report owner | first layer | middle layer | inside the issue window | N | GP-604/5.2 |
| 6 | Name the overturning observation | report owner | first layer | change line | minutes [A] | N | GP-604/6.1 |
| 7 | Route to the gate holder by class | reporting analyst | issue | gate sitting | same day [A] | N | GP-604/7.1 |
| 7 | Produce gate output per flagged row; release, or refer for hold or withdrawal | report owner | issue | gate response | inside the turnaround (SET LOCALLY) | N | GP-604/7.2 |
| 8 | Write publication record; stamp version | reporting analyst | released issue | record | minutes [A] | Y | GP-604/8.1 |
| 9 | Resolve seats to holders; apply restricted classes | reporting analyst | catalog row; seat map | distribution | minutes [A] | Y | GP-604/9.1 |
| 10 | Record opens, drill-downs, questions per seat class | reporting analyst | readership measure | readership record | continuous | Y | GP-604/10.1 |
| 11 | List reports with no reader and no standing question | reporting lead | readership record; catalog | sweep list | before the sweep | Y | GP-604/11.1 |
| 11 | Confirm with owners whether an obligation requires the report | reporting lead | sweep list | confirmed list | one sitting | N | GP-604/11.2 |
| 12 | Retire, merge or keep; update; announce | reporting lead | confirmed list | decisions | one sitting | N | GP-604/12.1 |

## Variants

- **Statutory.** Works council co-determining performance-monitoring devices: a report carrying individual figures from one is approved by the works-council liaison between 7 and 9; variant row. Other distribution restrictions are contractual.
- **Contractual.** Client-prescribed scorecard format, cadence and recipients: parameters of the catalog row, SET LOCALLY, no row.
- **Structural.** Numbers from a partner platform off the semantic layer: carried as [A] with a lineage note; variant row reviewed quarterly.
- **Transitional.** A predecessor organization's report set in parallel: variant row expiring at the cut-over; the sweep closes it.

## L3 register

| Job aid | Anchored to | Form |
|---|---|---|
| Catalog row and fields | step 1 | work instruction |
| Ledger pull, grade-carry rule, citation check | steps 2 to 3 | work instruction |
| Grade arithmetic | step 4 | work instruction |
| Layered answer template | step 5 | work instruction |
| Gate checklist, "must produce" rule | step 7 | work instruction |
| Publication record; seat-keyed distribution list with restricted classes | steps 8 to 9 | work instruction |
| Readership measure | step 10 | work instruction |
| Retirement sweep, announcement form | steps 11 to 12 | playbook |
| Withdrawn-report runbook | step 7 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)

1. Citation check (3.1): deterministic; a miss is visible on the next register change.
2. Grade check (4.1): arithmetic once formulas are stated; a wrong formula statement makes a correct check wrong.
3. Publication record (8.1): clerical; an error is found only when read back.
4. Distribution (9.1): a stale seat map misdirects an issue before anyone notices.
5. Ledger pull (2.1): an omitted number does not announce itself.
6. Readership record (10.1): an open is not a read; its error cannot be measured.
7. Sweep list (11.1): inherits the readership record's error and adds the catalog's.
8. Draft first layer (5.1): the owner writes the grade and change line, the gate holder signs; an ungraded answer reads as established.

Never candidates: the gate (7.2), since a report naming a decision commits the function and supervision decays into assent unless the supervisor must produce something; retirement (12.1), since readership measures opens, not need.

Block 7 — gp-605-time-and-production-accounting-audit.md

<!-- Derived from [[Time and Production Accounting Audit (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-605 — Time and Production Accounting Audit

The audit establishing, per channel and system, where every minute of agent
time and every unit of production is captured, how, where it lands in the
time ledger and at what grade; classifying every gap as *not collected*,
*partially collected* or *collected but misallocated*; running the tests
that detect asynchronous work hidden in voice states; and handing a signed
gap register, proposed source-of-truth (ST) rows, proposed
definitions-register (RG) changes and a materiality-ordered agenda to the
capacity standards workshop. It starts from what the capacity model consumes
and works back to the instruments, never the other way.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-605 · local id assigned at deployment |
| Class | supporting |
| Trigger | the framework's adoption (first full pass); then a platform change, a channel launch, a cohort migration, a reconciliation test failing on two consecutive runs, or the annual review of the standard |
| Cadence | a full pass typically once a year [A]; a channel-scoped pass on each trigger; SET LOCALLY |
| Scope in | every capture point on every emitting system (telephony, workforce-management, case and email tools, chat, desktop capture where one exists, payroll for paid time): what is captured, how, its ledger bucket, its grade; the gap register; the blended-agent tests; the proposed ST rows and RG changes; the workshop agenda |
| Scope out | adopting any definition or source (the workshop; GP-606); reconfiguring a platform; the requirement mathematics |
| Inputs | ledger template; code dictionary; current RG and ST versions; a configuration export per platform instance; the model inventory; the test definitions T-01 to T-06; a sample period of paid, scheduled, logged-in and state time |
| Outputs | capture-point inventory; ledger mapping sheet; signed gap register; test results with their residuals; proposed ST rows and RG changes; agenda in materiality order; audit log with the next pass dated |
| Upstream | the definitions register and its owner; the platform owners; the capacity model, whose needs set the scope |
| Downstream | the capacity standards workshop; GP-606; platform administration; GP-102 stage 3; the data quality gates for planning inputs |
| Resources | ledger template; a configuration export per platform class; the analytics platform for the tests; a sampling capability where no instrument exists; the registers. Platforms at L3 only |
| Decision points | does every bucket on every channel have a capture point; which class is a gap; is it material; stand-in source, definition change or configuration request |
| Authority tier | runs at the data and analytics lead's seat, who signs the gap register; no tier on the real-time ladder; any change to the standard the audit proposes is signed by the function head (tier 4) at the workshop, never by the audit |
| Risk and compliance flags | a desktop capture instrument records conduct and performance and in several jurisdictions is subject to works-council co-determination; observational studies of named agents carry the same flag; payroll time is personal data; a partner-held platform's logs are contractual, not owned |
| Variant-prone steps | desktop capture (statutory); partner-held platforms (contractual); predecessor instances scheduled for retirement (transitional); the sampling method where no instrument exists (structural) |
| Automation candidates | nine L2 rows marked Y (ranked below); the classification of a gap is never one |

## L1 flow (the decisions that protect the audit are steps 6, 9 and 10)

1. Open the audit: fix channels, systems and sample period; pull the ledger template, code dictionary and current RG and ST versions (data and analytics lead).
2. Build the capture-point inventory per channel and system, every state, timer, counter and timestamp, from configuration exports supplied by the platform owners, not from memory (data and analytics lead).
3. Record per capture point what is captured, by what instrument class, at what resolution and refresh (platform owner).
4. Map each capture point to its ledger bucket and its RG entry, or record *no bucket* or *no definition* (data and analytics lead).
5. Grade each capture point: a source grade and the number grade it can support (data and analytics lead).
6. Does every ledger bucket on every channel have at least one capture point? An uncovered bucket is *not collected*; a bucket claimed by two systems is *collected but misallocated* and goes to T-04; an availability bleed is *collected but misallocated* for voice and *not collected* for email in-work time (data and analytics lead).
7. Run the reconciliation tests T-01 to T-06 on the sample period (data and analytics lead).
8. Run the blended-agent tests on every cohort working more than one channel: first T-06, items closed per available-idle hour, then focus time against state time where an instrument exists, then the idle residual against asynchronous volume (data and analytics lead).
9. Classify each gap, with the evidence from steps 6 to 8 beside it (data and analytics lead).
10. Is the gap material? Which models consume the number, and what does the weakest-input rule do to their grade? An immaterial gap is logged, not remedied (capacity planning lead).
11. Draft the remedies: a proposed ST row with stand-in source and grade per material gap; an RG change where the definition is the gap; a configuration request where the instrument is (data and analytics lead).
12. Sign the gap register, stating the sample period, the cohorts tested and the gaps left immaterial (data and analytics lead).
13. Draft the workshop agenda from the signed register in materiality order, proposals attached; hand it to the workshop's chair (data and analytics lead).
14. Close the audit: log it, open each proposal through GP-606, date the next pass (register's owner).

## L2 step table

Durations are typical for one channel-scoped pass [A], SET LOCALLY. Rows key by job aid.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Fix scope: channels, systems, cohorts, sample period | data and analytics lead | the model inventory | scope sheet | 2 h | N | audit scope sheet |
| 1 | 1.2 Pull ledger template, code dictionary, register versions | data and analytics lead | the registers | audit baseline | 1 h | Y | audit scope sheet |
| 2 | 2.1 Export the configuration of each platform instance in scope | platform owner | the instance | raw export | 1 day each | Y | inventory pull instruction |
| 2 | 2.2 Compile the exports into one inventory, one row per capture point | data and analytics lead | raw exports | capture-point inventory | 1 day | Y | inventory template |
| 3 | 3.1 Record instrument class, resolution and refresh per row | platform owner | the inventory | described inventory | 2 h per system | N | inventory template |
| 4 | 4.1 Map each row to a ledger bucket or mark *no bucket* | data and analytics lead | inventory; ledger | mapping sheet | 1 day | N | ledger mapping sheet |
| 4 | 4.2 Map each row to an RG entry or mark *no definition* | register's owner | mapping sheet; RG | mapping sheet | 2 h | N | ledger mapping sheet |
| 5 | 5.1 Assign a source grade and the number grade it supports | data and analytics lead | mapping sheet | graded inventory | 2 h | N | grading work instruction |
| 6 | 6.1 Test bucket coverage per channel; list uncovered and doubly claimed buckets | data and analytics lead | graded inventory | coverage list | 1 h | Y | coverage test notebook |
| 7 | 7.1 Extract the sample period's paid, scheduled, logged-in and state time | data and analytics lead | the sources named in the inventory | ledger extract | 1 day | Y | test runbook |
| 7 | 7.2 Run T-01 to T-06 and record each result with its residual | data and analytics lead | ledger extract | test results | 2 h | Y | test runbook |
| 8 | 8.1 Identify blended cohorts and their available-idle hours | real-time lead | roster; state data | cohort list | 1 h | Y | blended-agent test playbook |
| 8 | 8.2 Run T-06 per cohort, then focus against state time, then residual against volume | data and analytics lead | cohort list; item counts; focus time where it exists | bleed estimate, graded | 2 h | Y | blended-agent test playbook |
| 9 | 9.1 Classify each gap with its evidence | data and analytics lead | coverage list; test results; bleed estimate | draft gap register | 1 day | N | gap register template |
| 10 | 10.1 Trace each gap to the models that consume the number | capacity planning lead | draft gap register; model inventory | materiality column | 2 h | N | model inventory |
| 10 | 10.2 Decision: material or immaterial, with the grade effect stated | capacity planning lead | materiality column | ranked gap register | 1 h | N | gap register template |
| 11 | 11.1 Draft a proposed ST row per material gap: stand-in source, grade, known gaps | data and analytics lead | ranked register | ST proposals | 2 h | N | ST proposal form |
| 11 | 11.2 Draft RG changes where the definition is the gap | register's owner | ranked register | RG proposals | 2 h | N | RG proposal form |
| 11 | 11.3 Raise configuration requests where the instrument is the gap | platform owner | ranked register | request list | 1 h | N | configuration request form |
| 12 | 12.1 Review and sign the gap register | data and analytics lead | ranked register; proposals | signed register | same day | N | gap register template |
| 13 | 13.1 Assemble the agenda in materiality order with proposals attached | data and analytics lead | signed register | workshop agenda | 2 h | Y | workshop agenda template |
| 14 | 14.1 Log the audit; open proposals through GP-606; date the next pass | register's owner | signed register; agenda | audit log entry | 1 h | N | audit log |

## Variants

- **Statutory.** Where a desktop capture instrument or an observational study is subject to works-council co-determination, the inventory step (2) and the focus-time test (8.2) run only on the terms agreed, typically on aggregated data; the works-council liaison owns a variant row on both steps and the function head approves it. With no agreement the focus-time test is marked *not run* and the bleed estimate falls to [A].
- **Contractual.** A partner-held platform whose logs cannot be exported supplies its capture points as a partner report, graded *named owner*: a parameter of step 5, SET LOCALLY, no row. Where the contract gives no access at all, 2.1 cannot run and a variant row records the partner's attestation as the input, owned by the placement and vendor lead.
- **Structural.** A tool that emits no state and no timer is not a variant; it is what the audit exists to find, and lands as *not collected*. A platform that cannot export its configuration changes 2.1's input to a transcription by the platform owner: an L3 difference, no row.
- **Transitional.** A predecessor platform instance with a dated retirement is inventoried at the state level only and tested once; a variant row carries the exclusion with an expiry at the retirement date.

## L3 register

Names only; the content is the function's. The residual below which a gap is immaterial and the sample period's length are L3 values marked SET LOCALLY.

| Job aid | Anchored to | Form |
|---|---|---|
| The inventory pull instruction per platform class, with the export object named | step 2 | work instruction |
| The inventory template and the ledger mapping sheet | steps 2 to 4 | work instruction |
| The grading work instruction: source grade to number grade | step 5 | work instruction |
| The test runbook: extract, run T-01 to T-06, record, with the pass bands | steps 6, 7 | runbook |
| The blended-agent test playbook: which cohorts, which tests, how to read a residual | step 8 | playbook |
| The gap register template and the three classes with their evidence rules | steps 9, 10, 12 | work instruction |
| The ST and RG proposal forms and the configuration request form | step 11 | work instruction |
| The workshop agenda template and the hand-off to the chair | step 13 | work instruction |
| The audit log and the trigger table | step 14 | work instruction |

## Automation candidates (ranked by ease of publishing a catch rate)

1. The capture-point inventory pull (2.1, 2.2): a deterministic read of each platform's configuration; first because an omitted capture point is visible the moment a platform owner reads the inventory.
2. The reconciliation tests (7.1, 7.2) and the coverage test (6.1): computations on the ledger extract with stated pass bands; the overseer checks inputs and bands, not arithmetic. After the inventory pull because a test's catch rate can only be published once the inventory it reads is itself released.
3. The blended-agent test computations (8.1, 8.2): computed; the reading of the result stays with the data and analytics lead. After the reconciliation tests because T-06 consumes their available-idle time, so its errors cannot be separated from theirs until theirs are published.
4. The baseline pull (1.2) and the agenda assembly (13.1): deterministic reads and assemblies of register versions and the signed register; last because each runs once per pass, so the sample from which a catch rate is published accrues slowly.

The classification of a gap (9.1) is never a candidate: deciding whether a capture point is *partially collected* or *collected but misallocated* means reading what the instrument was built to count against what the ledger needs, a judgment with no ground truth to publish a catch rate against. The materiality decision (10.2) and the signature (12.1) are gates: a person must produce a decision per row.

Block 8 — gp-606-definitions-and-source-of-truth-change-control.md

<!-- Derived from [[Definitions and Source-of-Truth Change Control (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-606 — Definitions and Source-of-Truth Change Control

The one change control shared by the definitions register (`RG-nnn`), the
source of truth register (`ST-nnn`), the definition cards and the lineage
cards (`LN`): propose, review, version, adopt, forward only. Candidate →
Preferred; the previous version Superseded; an uncited definition Retired;
nothing deleted. Carry rule: a number computed on the old version keeps its
grade as a value of that version and is [A] read as a value of the new one;
history is never restated. GP-601 governs the standard's text; this card the
numbers it computes on.

## Profile

| Field | Generic value |
|---|---|
| Card | GP-606 · local id assigned at deployment |
| Class | supporting |
| Trigger | a proposal from any seat; a platform, channel or cohort change invoking the carry rule; a GP-605 finding; a quarantine row needing a new RG or ST version |
| Cadence | on demand, batched to a review slot (SET LOCALLY; fortnightly is typical [A]); emergency path for a dated platform cut-over |
| Scope in | every RG entry, ST row, definition card, lineage card; versions, effective dates, signatories, history; the grade a number carries on the new version |
| Scope out | the standard's text (GP-601); activity-code configuration; the audit (GP-605); the workshop, whose outputs enter as proposals |
| Inputs | proposal with reason; current version; lineage query result; carry-rule assessment; parallel-run result where required |
| Outputs | new version with effective date; adoption record; change-history row; re-version list with committed dates; re-grade notice to consuming models and reports |
| Upstream | GP-605; capacity standards workshop; quarantine register; platform migrations; forecast-value-added reviews finding a definitional cause |
| Downstream | every citing lineage card; plan of record; GP-604 (reports cite the version); GP-602 (actuals on the new definition from its effective date) |
| Resources | two registers, two card sets; lineage query; change log; review slot. Platforms at L3 only |
| Decision points | correction, extension or new object; alters a signed plan; parallel run and length; adopted, declined, returned |
| Authority tier | proposal at any tier · review at tier 3 by the register's owner with the data and analytics lead as co-owner · adoption at tier 4 by the function head, convening the signatories · a change moving a signed plan to the executive sponsor by exception |
| Risk and compliance flags | one-signatory adoption creates the two-definitions trap; retrospective change destroys the record of what a plan was signed on; a contractual definition is a variant, never a replacement; agent-level time instruments face co-determination and data-protection rules |
| Variant-prone steps | signatory set under works-council or contract say; parallel-run length; emergency-path approver |
| Automation candidates | ten L2 rows marked Y (ranked below) |

## L1 flow (one owner seat per step)

1. Log the proposal: object, reason, claimed reports and models (register's owner).
2. Correction, extension or new object? New objects start as Candidate (register's owner).
3. Run the lineage query to the plans and reports ending each chain (data and analytics lead).
4. Alters a number in a signed plan of record? Tell the plan's owner before review (register's owner).
5. Review against register fields, card fields, one-source rule, ST conflict rule (register's owner; co-owner reviews).
6. Parallel run? Where a load-bearing number moves, both versions report side by side for a stated period (SET LOCALLY; one planning cycle is typical [A]) (register's owner; consuming-model owners review).
7. Draft the new version: number, effective date, previous kept; open the history row (register's owner).
8. Assess the carry rule: values [A] on the new version; models dropping grade until re-measured (data and analytics lead).
9. Adopted? Adopt, decline with reason, or return to 5 (function head, convening signatories, tier 4).
10. Publish; notify every consumer the query named, including GP-604 (register's owner).
11. Re-version lineage cards by committed date; a late card is a quarantine row (card owner, per card).
12. Close the record; log lessons for GP-605 (register's owner).

## L2 step table

Thresholds and system names never appear here; they are set at L3.

| Step | Sub-step | Owner | Inputs | Outputs | Duration | Automation candidate | Join key |
|---|---|---|---|---|---|---|---|
| 1 | Log proposal, reason, claimed impact; confirm current version | register's owner | proposal; registers | change record opened | same day [A] | Y | change record id; RG/ST/LN id + version |
| 2 | Classify | register's owner | proposal; current version | classification | minutes [A] | N | change record id |
| 3 | Query first-order consumers | data and analytics lead | lineage cards | card list | minutes [A] | Y | LN ids |
| 3 | Walk the chain to plans and reports | data and analytics lead | card list | impact list with end points | hours [A] | Y | LN ids; plan version; report ids |
| 4 | Check against signed plans; notify the plan's owner | register's owner | impact list; plan register | plan-impact flag; notice logged | same day [A] | Y | plan version; change record id |
| 5 | Review the register fields | register's owner | draft; current version | review note | one review slot [A] | N | RG/ST id |
| 5 | Check one-source and conflict rules (ST); validation rule and instrument class (cards) | data and analytics lead | ST row or card draft | finding or clear | within the slot [A] | N | ST id; card id |
| 6 | Decide parallel run and length | register's owner | impact list; grade assessment; owners' review | decision (SET LOCALLY) | within the slot [A] | N | change record id |
| 7 | Draft version with effective date; open history row | register's owner | review note | draft version; history row | hours [A] | Y | RG/ST/LN id + new version |
| 8 | List values that are [A] on the new version | data and analytics lead | impact list; grades | re-grade list | hours [A] | Y | LN ids; ledger versions |
| 8 | Compute consuming models' output grades | data and analytics lead | re-grade list; lineage cards | output-grade list | hours [A] | Y | LN ids |
| 9 | Convene signatories over draft, re-grade list, parallel-run result | function head | draft; re-grade list; parallel-run result | adopt / decline / return | one review slot [A] | N | change record id |
| 9 | Record adoption with every signature | register's owner | decision | adoption record | minutes [A] | N | RG/ST/LN id + version |
| 10 | Update registers and cards; announce effective date and re-grade to every consumer | register's owner | adoption record; impact list; output-grade list | published version; notices logged | same day [A] | Y | RG/ST/LN id + version; report ids |
| 11 | Re-version the lineage card | card owner | published version | re-versioned card | by committed date (SET LOCALLY) | N | LN id + version |
| 11 | Track late cards; raise quarantine rows | register's owner | card dates | quarantine rows | weekly [A] | Y | LN id; quarantine row id |
| 12 | Complete history row; close; log lesson | register's owner | all above | closed record; lesson | minutes [A] | Y | change record id; GP-605 audit id |

## Variants

- **Statutory.** Works council co-determining monitoring devices, which reaches a desktop work-item timer or focus-time instrument: instrument class constrained; the liaison joins the signatories for cards reading agent-level time; variant row, function head on legal advice.
- **Contractual.** A client's own billing definition of handle time or service level: a named variant beside the register entry, owned by the placement and vendor lead, never a replacement; billing cites the variant, the plan computes on the register; variant row.
- **Structural.** An instance that cannot emit a field the instrument class assumes: ST extraction path parameterized, SET LOCALLY, no row; the gap in the known-gaps field.
- **Transitional.** A predecessor organization's unit on its own definition: variant row expiring at the cut-over; its numbers then [A] on the shared definition.

## L3 register

| Job aid | Anchored to | Form |
|---|---|---|
| Proposal form; change-record template | step 1 | work instruction |
| Lineage query procedure | step 3 | work instruction |
| Review checklist | step 5 | work instruction |
| Parallel-run procedure and reporting template | step 6 | playbook |
| Carry-rule assessment; re-grade template | step 8 | work instruction |
| Adoption record; signature block | step 9 | work instruction |
| Emergency path for a dated cut-over | steps 1 to 10 | runbook |
| Re-version tracker | step 11 | work instruction |

## Automation candidates (ranked by ease of publishing a catch rate)

1. Re-version tracker (11, tracking row): a date comparison; every miss visible the following week.
2. Logging the proposal (1): reads free text; a wrongly cited object is caught only at review.
3. Closing the record (12): completeness is checked against the whole record, a cycle to audit.
4. First-order lineage query (3, first row): only as current as the cards' inputs fields, which step 11 maintains.
5. Chain walk (3, second row): each added end point is another place an omission can hide.
6. Plan-impact check (4): bounded by the currency of the plan register.
7. Drafting the version (7): a mis-copied field is caught only by the signatories.
8. Publishing (10): writes the objects of record, the costliest error to reverse.
9. Re-grade list (8, first row): the version boundary must be read correctly for every value.
10. Output-grade computation (8, second row): compounds the re-grade list with the weakest-input rule across the chain.

Never a candidate: adoption (9), a signature by the function head with the signatories whose client portfolios the registers make comparable; a definition adopted by a rule is a private definition with a version number.

Usage notes

Sizing. Block 1 is about 560 words and loads with every message; Blocks 2–8 are retrieved as needed and total about 11,260 words, the localization rules at about 1,130, the four live-card blocks between about 1,440 and 1,520 each, and the two register cards (GP-605, GP-606) at about 2,460 and 1,760, the largest because their L2 tables carry 22 and 18 rows. Every L2 row is carried because the join keys are what a job aid, a ticket and a variant row cite.

Output. The pack emits five Markdown files per card: the L0 cover with the settled profile, the L1 flow, the fifteen-column L2 table in the layout of CP-OPS-001 framework.md, the L3 register and the variant rows. The four decomposition files transfer to a workbook by the layout in CP-OPS-001 Block 4; the variant rows transfer to the parent standard's variant register.

Localizing. Every SET LOCALLY mark and every grade in the card blocks is carried from the wiki card. The pack will not fill a local value it has not been given, will not name a product in a file marked for publication, and will not mark a candidate released without catch-rate evidence; a function that wants a candidate released brings the catch rate, not the maturity label. Two seams run through the six cards and the pack enforces both: GP-601 governs the standard's text and GP-606 the definitions its numbers compute on, and a finding from GP-603 or GP-605 becomes a variant row or a proposal only through the card that owns that register.

Drift. Blocks 3–8 derive one-to-one from the six cards 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.

Scope. Nothing in the pack is specific to any organization, industry, jurisdiction or platform; jurisdictions' values, thresholds, calendars and system names are the deploying function's and live at L3.

Change history

Version Date Change
1.0 2026-10-16 First release: instruction block, the localization rules and six card blocks (GP-601 to GP-606)

See also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Wiki:Packs/Cross-Cutting_Governance_Processes&oldid=5588"