Wiki:Packs/Process Inventory and Shell Catalog

From WFM Labs
Pack
ID CP-OPS-008
Name Process Inventory and Shell Catalog
Domain OPS
Blocks 1 instruction + 6 reference
Version 1.0
Source Process Standardization · Process Inventory for a Workforce Function · Process Decomposition (L0–L3) · Monthly Capacity Planning Cycle (generic process) · Standard and Variant in Process Documentation · Decision Authority Tiers in Workforce Operations · Runbooks, Playbooks and Work Instructions · Process Shells for a Workforce Standard
Planning-week block Day 2 afternoon (the function catalog and its shells), ahead of Wiki:Packs/Process Decomposition

A deployable Claude project setup for producing a workforce function's process inventory: the catalog rows of its parent standard, one per process the function runs, each placed under a section, classed, owned by a seat, dated, and tied to the generic process card or existing method page it will be localized from. The pack walks the six pillars and the twenty-nine generic process cards of Process Inventory for a Workforce Function, passes every candidate through the intake screen, and marks each row GP-card, shelf page or NOT INVENTORIED. Copy Block 1 into a project's custom instructions; save Blocks 2–7 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function, typically one formed from several regions or predecessor organizations, has to say which processes it owns before it documents any of them: on the day its standard is issued with an owner and a date against every section, when a certifier asks for a process list, or when a request arrives that may or may not be a process the function already holds. It produces the catalog and the record of why each row is there; it does not document a process. Pair it with Wiki:Packs/Process Decomposition (CP-OPS-001), the engine that turns a catalog row into an L0 shell and then into the four artifacts, and with Wiki:Packs/ROC Standard Authoring (CP-OPS-003), which places the finished catalog in the standard's section 2. It is not for localizing a card; the pillar packs (CP-OPS-009 to CP-OPS-014, publishing alongside) carry the cards of one pillar each. In a planning week it serves the Day 2 afternoon block, before the shells are written.

How to deploy

  1. Create a project in Claude named for the function, not the method: "Workforce function inventory", not "Process cataloging".
  2. Paste Block 1 into the project's custom instructions.
  3. Save each remaining block as the filename in its heading and upload it as project knowledge.
  4. Start a conversation with the function's description: pillars in scope, supply nodes (sites and partners), channels, client contracts, and the section numbering of its standard if one exists.

Block 1 — Project instructions

You are building a workforce function's process inventory: the catalog rows
of its parent standard's section 2, one per process the function runs,
before any process is documented. `taxonomy.md` holds the pillars,
sections, certification items, 29 cards and 11 shelf pages;
`intake-screen.md` holds the four screening questions.

Routing:
| Task | Open |
|---|---|
| Walk the pillars; place a candidate; name its card or shelf page | taxonomy.md |
| Screen a candidate (four questions); write the row marks | intake-screen.md |
| Settle what class, trigger, cadence or owner means | l0-profile.md |
| Parameter, variant or preference? | standard-variant.md |
| Which seat signs a decision; the tier vocabulary | authority-tiers.md |
| Which L3 form a process's job aids take | l3-forms.md |

Method, in order:
1. Take the function's description: pillars in scope, supply nodes (sites
   and partners), channels, client contracts. One question at a time;
   propose pillar and section placements only.
2. Walk the six pillars in taxonomy order; for each of the 29 cards and 11
   shelf pages, ask whether the function runs it.
3. Add the candidates the user names that no card covers. Pass every
   candidate through the four questions of `intake-screen.md` in order;
   record the answers.
4. Mark each surviving row GP-card (a generic card exists), shelf page (an
   existing method page is the card; a conversion) or
   `NOT INVENTORIED — <seat> · by <date>` (asserted by a predecessor
   organization, not confirmed). A candidate screened out goes to the
   deferred log with its reason, never dropped.
5. Fill each row's eight fields: Section (§3.n) · Process · Class · Owner
   (a seat) · Skeleton until (a date) · Mark · Card id · Local id. Class
   (strategic · real-time · both · supporting) comes from the card; the
   owner and the date come from the user.
6. Emit `catalog.md` (the rows, by section) and `inventory-decisions.md`
   (one row per candidate: the four answers, the mark, the reason).

Rules:
- Never fill a local value the user has not given. Where the user has not
  given an owner or a date, write `SET LOCALLY — owner not given` /
  `SET LOCALLY — date not given`; never propose one.
- Seats, never names. One owner per row; two claimants is a finding.
- A lens, a register or a partner function's process is not a row
  (`taxonomy.md`); point to the process that reads it.
- Do not document a process (no abstract, L1 or L2); that is the Process
  Decomposition pack's work.
- Never name a platform or product in either file.
- One process under two names is the failure the inventory exists to
  prevent; when question 2 finds one, merge and record.

Output: `catalog.md`, one table per section in the standard's order, a
count line by mark at the top; `inventory-decisions.md`, one row per
candidate. Refuse to emit either with an unmarked empty cell.

Source: Wiki:Packs/Process Inventory and Shell Catalog (CP-OPS-008) v1.0

Block 2 — taxonomy.md

<!-- Derived from [[Process Inventory for a Workforce Function]] and [[Process Standardization]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. The card table follows the hub's inventory on Process Standardization; the pillar, section and COPC mapping follows Process Inventory for a Workforce Function. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Taxonomy: pillars, sections, certification items

The inventory is a taxonomy, not documentation: it says which processes
exist and where each sits; how a process runs belongs to its card and to the
L0-L3 decomposition. One process under two names drifts; one owner per
process prevents it.

## Pillars to sections to certification items

| Pillar | Catalog sections of the parent standard | COPC item | What the pillar owns |
|---|---|---|---|
| Forecasting | §3.1 forecasting · §3.2 capacity planning | Forecasting, Staffing and Scheduling | the demand and supply outlook at every horizon; the requirement; the gap; the lock; accuracy governance |
| Scheduling | §3.3 scheduling | Forecasting, Staffing and Scheduling | the schedule of record from build to retirement; time-off allotment; flexible-workforce administration; activity codes |
| Real-time | §3.4 real-time performance and automation · §3.6 incident management | Forecasting, Staffing and Scheduling (its real-time requirement) · Corrective Action | the operating day; levers; adherence; alerts and escalation; incidents and their learning loop |
| Work placement | §3.7 work placement · §3.10 routing and the capability layer | Vendor Management | the placement decision through the gate; the scorecard cycle; sourcing under uncertainty; loans and trades; routing change control |
| Continuity interface | the continuity wire, which leaves from §3.6 | Business Continuity | the ROC side of the wire: crisis trigger and re-plan, placement under duress, judgmental forecasting in crisis, platform degradation and buffer staffing, skill-mix review |
| Cross-cutting | §3.5 intake and the register · §3.8 reporting and analytics · §3.9 data definitions and governance · §3.11 business improvement | Managing Change · Compliance · Reporting and Data Integrity | the standard's own change control; the weekly forecast-vs-actual review; compliance review; report publication; the data audit and the registers' change control |

Where a pillar spans two sections, settle each row's section with the user;
the shelf-page placements below are the convention's own.

## What is not a process

- **A lens is not a process.** The capability layer (§3.10) has no
  trigger, cadence or product, so no row; the rows are the placement
  decision that reads it (GP-401) and the routing change control. The
  definitions register is likewise an instrument; only its change control
  (GP-606) is a row.
- **Business continuity is a partner function.** Continuity owners own
  preparedness and activation; the workforce function owns its side of the
  wire and inventories only that. Contact-center security is a link, not a
  row.
- **Vendor management is not a function.** Every section carries a vendor
  paragraph for the partner supply node; supplied work is the same process
  on another supply node, and the scorecard review belongs to the placement
  function (GP-402).

## The 29 generic process cards

Class vocabulary: strategic · real-time · both · supporting. "Method on"
names the page that documents the method; "the card" means the card owns its
L1 and L2. The local id (P-nnn) is assigned at deployment, never on a card.

| Pillar | Card | Class | Method on |
|---|---|---|---|
| Forecasting | GP-101 Annual Strategic Workforce Planning Cycle | strategic | the card; frame on Workforce Planning Calendar and Annual Planning Cycle |
| Forecasting | GP-102 Monthly Capacity Planning Cycle | strategic | Capacity Planning Cycle |
| Forecasting | GP-103 Weekly Rolling Reforecast | both | the card; method on Reforecast and Rolling Forecast Methodology |
| Forecasting | GP-104 Intraday Reforecast | real-time | Intraday Reforecasting Methods |
| Forecasting | GP-105 Supply and Attrition Forecasting | strategic | the card; models on Workforce Forecasting |
| Forecasting | GP-106 Forecast Accuracy Governance | supporting | the card; metrics on Forecast Value Added in Workforce Management |
| Scheduling | GP-201 Schedule Build and Publish | strategic | the card; sequence on Employee Scheduling, generation on Schedule Optimization |
| Scheduling | GP-202 Schedule Maintenance | both | Schedule Maintenance |
| Scheduling | GP-203 Time-Off Allotment Planning | strategic | the card; definitions on Time-Off Management |
| Scheduling | GP-204 Self-Scheduling and Flexible Workforce Administration | both | the card; evidence on Autonomy and Schedule Self-Service |
| Real-time | GP-301 Daily ROC Routine | real-time | Daily ROC Routine |
| Real-time | GP-302 Real-Time Lever Deployment | real-time | the card; levers on Real-Time Schedule Adjustment |
| Real-time | GP-303 Adherence and Conformance Monitoring | real-time | the card; metrics on Adherence and Conformance |
| Real-time | GP-304 Threshold Alerts and Escalation | real-time | Real Time Threshold Alerts and Escalation Protocols |
| Work placement | GP-401 Placement Decision Through the Gate | strategic | the card; tests on The Placement Gate |
| Work placement | GP-402 Vendor Performance Review Cycle | supporting | the card; a process of the placement function, not a vendor-management function |
| Work placement | GP-403 Sourcing Decision Under Imperfect Data | strategic | Sourcing Strategy Under Imperfect Data |
| Work placement | GP-404 Loan and Trade Between Internal Pools | both | the card; cost treatment on Call-Sharing Models and Cost Allocation |
| Continuity interface | GP-501 Crisis Trigger and Re-Plan | both | the card; activation itself is the partner's |
| Continuity interface | GP-502 Placement Under Duress | real-time | the card |
| Continuity interface | GP-503 Judgmental Forecasting in Crisis | both | Judgmental Forecasting |
| Continuity interface | GP-504 Platform Degradation Runbook and Buffer Staffing | real-time | the card |
| Continuity interface | GP-505 Cross-Training and Skill-Mix Review | strategic | Cross-Training and Skill Mix Strategy |
| Cross-cutting | GP-601 Standards Governance and Change Control | supporting | the card; the gate on Process Standardization Lifecycle |
| Cross-cutting | GP-602 Weekly Forecast-vs-Actual Review | both | the card |
| Cross-cutting | GP-603 Compliance Review for Workforce Operations | supporting | the card; law on Labor Law and Scheduling Compliance |
| Cross-cutting | GP-604 Report Publication | supporting | the card; format on Answer-First Reporting |
| Cross-cutting | GP-605 Time and Production Accounting Audit | supporting | the card; the framework on Workforce Data Definitions Framework |
| Cross-cutting | GP-606 Definitions and Source-of-Truth Change Control | supporting | the card; registers on The Definitions Register |

Counts: 6 forecasting · 4 scheduling · 4 real-time · 4 work placement ·
5 continuity interface · 6 cross-cutting = 29 [C].

## The 11 shelf pages

Existing pages that already serve as generic processes (an L1, mostly an
L2). No card duplicates them; each is cataloged as a conversion, and the
row's card id is the page title.

| Section | Shelf page | Role |
|---|---|---|
| §3.1 forecasting | Three-Step Forecast Build | the build |
| §3.1 forecasting | Forecast Lock Process | the lock |
| §3.1 forecasting | Forecast Collision Calendar | the event calendar |
| §3.3 scheduling | Activity-Code Consistency | the codes the schedule is written in |
| §3.6 incident management | Event, Incident and Problem in Contact Centers | definitions |
| §3.6 incident management | Contact-Center Incident Severity Matrix | controls |
| §3.6 incident management | Incident Management for Contact Centers | the twelve-step process |
| §3.6 incident management, shared with §3.11 | Post-Mortem and RCA for Workforce Operations | the learning loop |
| §3.10 routing | Call-Sharing Models and Cost Allocation | cost treatment of shared work |
| §3.10 routing | Vendor Change Control for Routing | routing change control |
| §3.5 intake | Work Intake for Planning and Analytics Teams | the single intake door |

## Nine certification items: seven map, two do not

Seven map directly: Forecasting, Staffing and Scheduling to the first three
pillars; Managing Change to GP-601 and the change-control board; Corrective
Action to Post-Mortem and RCA and GP-602; Vendor Management to GP-402 and the
vendor paragraph of every section; Business Continuity to GP-501; Compliance
to GP-603; Reporting and Data Integrity to GP-604, GP-605 and GP-606 with the
definitions register.

Two map to no row, deliberately. **Transaction Monitoring** belongs to the
quality function: the workforce function consumes its outputs but owns no
monitoring or calibration process. **Technology Management** belongs to
systems administration and the change-control board; the toolset section
names capabilities, never products. A function that inventories either
documents another function's process; the second screening question fails
at the first audit.

Block 3 — l0-profile.md

<!-- Derived from [[Process Decomposition (L0–L3)]] and [[Monthly Capacity Planning Cycle (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The L0 process profile: sixteen fields and the rule for each

L0 is a form. Its identity fields say what a document is: procedure name,
organization, document ID and type, category, owner, document home,
publication and expiration dates, a two-to-three-sentence abstract (purpose
and scope, no steps), authors, peer reviewers, approvers, keywords, revision
history. Every field is filled or explicitly marked, because an empty field
is indistinguishable from a forgotten one.

The **process profile** extends L0 with the facts a standards committee
needs before any step is drawn. A catalog row is the profile's first four
fields plus an owner and a date; the rest is filled when the shell becomes a
card.

## The sixteen fields

| # | Field | Rule | Generic example (GP-102 Monthly Capacity Planning Cycle) |
|---|---|---|---|
| 1 | Card | the generic id `GP-nnn`; the local card id `P-nnn` is assigned by the standards committee at deployment and never appears on the generic card | GP-102 · local id assigned at deployment |
| 2 | Class | exactly one of strategic · real-time · both · supporting, the function catalog's vocabulary; a horizon term (tactical, operational) is not a class | strategic; its monthly horizon is tactical in the decision-rights vocabulary |
| 3 | Trigger | what starts a run: a calendar point, a boundary, a degradation past a written entry condition, a request through change control | the business-day calendar: stage 1 opens on the first business day after the demand actuals close |
| 4 | Cadence | how often, or "continuous"; the horizon is a local value | monthly, on a rolling horizon SET LOCALLY (twelve to eighteen months is typical [A]) |
| 5 | Scope in | what the process covers, stated so the abstract can be written from it | every business unit and supply node the function plans; demand, supply and requirement at unit level; the gap; the clearing decisions; the lock |
| 6 | Scope out | what it hands to another process, each named | the forecasting method; the hiring process after a requisition is raised; the weekly reforecast |
| 7 | Inputs | what a run consumes, as artifacts | the short-term forecast and its lock; the roster and its roll-forward; attrition and hiring assumptions; the constraint register; last month's plan of record and its variance |
| 8 | Outputs | what a run produces, as artifacts with a signature where one is required | the plan of record with its signature; the surplus and deficit table per unit; the clearing decisions and the requisitions they raise; the variance review |
| 9 | Upstream | the processes and functions whose outputs it consumes | the enterprise demand forecast; finance's budget envelope; the placement function's constraint register; the definitions register |
| 10 | Downstream | the processes and functions that consume its outputs | scheduling (the requirement by week); recruiting (requisitions); finance (the committed cost line); the real-time function (the staffing floor) |
| 11 | Resources | categories only: a capacity model, a roster system of record; never a product name, which belongs at L3 | a capacity model with a plan of record; a roster system of record; the forecast; the constraint register; the committee calendar |
| 12 | Decision points | each decision as a question, with its exception path | the clearing decision (move before hire); the lock decision (pencils down); the exception path when a unit's gap exceeds the band the plan can absorb |
| 13 | Authority tier | the tier at which each decision point is signed, in the five-tier vocabulary of `authority-tiers.md`; where the decision belongs to a supply-node owner, write "advice at tier n; decision per the decision-rights table" | stage decisions at tier 1 (the forecaster inside the lock calendar); the lock at tier 4 (function head); a gap outside the band to the executive sponsor, by exception, through the decision-rights table |
| 14 | Risk and compliance flags | what the process binds: finance, recruiting, a statute, a client contract | headcount commitments that bind finance; requisitions that bind recruiting; a plan signed on unreconciled definitions |
| 15 | Variant-prone steps | the steps whose values are expected to differ by country, site or vendor (`standard-variant.md`) | the calendar offsets; the clearing rules where contracts dedicate supply; the approval tier where a works council must see a hiring plan |
| 16 | Automation candidates | a count, equal to the number of L2 rows flagged Y, each listed on the card | five L2 sub-steps on the GP-102 card [C] |

## Filled twice

A generic card fills the profile generically, with local values marked SET
LOCALLY. The deploying function fills those values at deployment on its own
L0 and records its exceptions in the variant register against the card. The
profile does not replace the identity fields; it sits beside them.

## Major and minor change

A change to **trigger, scope, authority tier or class** is a major change
and reopens L0 approval. Any other profile change is minor and is recorded in
the revision history. The same line divides the intake screen's fourth
question (`intake-screen.md`).

## For a catalog row

A row needs fields 1 and 2 from the card and nothing more from the profile;
it adds the section (§3.n), the owner (a seat) and the skeleton-until date,
both from the user. Where the card defers its method to another page, the
row still cites the card. Where no card exists and a shelf page serves, the
row cites the page title and the class the taxonomy gives it.

Block 4 — standard-variant.md

<!-- Derived from [[Standard and Variant in Process Documentation]] (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. -->
# Standard and variant

One generic process; a register of local exceptions. A function that copies
a process per location holds five or six versions that differ in a handful
of steps, cannot compare them across regions, cannot certify once, and
cannot automate. A variant is the explicit, bounded cost of standardization,
governed through a named process owner.

## Four classes

A variant belongs to one class; the class decides who approves it and how
long it may stand.

| Class | Example | Who approves | Review |
|---|---|---|---|
| Statutory | working-time, rest-break and predictability-pay rules; works-council co-determination over the start, end and weekly distribution of working time | the function head (tier 4), on legal advice | when the law changes |
| Contractual | a client contract that dedicates agents, fixes a service construct or forbids overflow; a vendor contract that prices a different unit | the placement and vendor lead (a tier 3 seat of the placement pillar) | at contract renewal |
| Structural | a site with no night shift; a channel with no real-time state; a platform that cannot emit an event the standard assumes | the process owner, at whatever tier that seat holds | when the structure changes |
| Transitional | a unit migrating from a predecessor organization that still runs its old step until a dated cut-over | the standards committee | at the stated expiry, never extended silently |

**Local preference is not a class.** A step a site runs differently because
it always has, with no statutory, contractual, structural or transitional
reason, is a compliance finding at lifecycle step 3.2, not a variant.

## The variant register row

| Field | Rule |
|---|---|
| Variant ID | `V-nnn`, issued by the standards committee |
| Process and steps | the card and the L1 or L2 steps modified; each modified step listed |
| Scope | the countries, sites, vendors, channels or client contracts it applies to, named as classes where the standard is published outside the function |
| Class | statutory · contractual · structural · transitional |
| The difference | what the step does differently, in the same active voice and ownership form as the generic step |
| Owner | a seat, never a name; the seat accountable for the local value |
| Approved by | the approving seat for the class, and the date |
| Expiry or review | transitional variants expire; the others carry a review date |
| Automation effect | blocks · parameterizes · does not touch, against any automation candidate flagged at L2 |

The generic process does not change when a variant is added. The affected L2
row carries `SET LOCALLY — <seat>`, which says a value exists, is local, and
where it lives. Thresholds, calendars and system names are never written
into the generic step; when six copies exist, none is the controlled one.

## The variant test (four questions, in order, every class)

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)? A parameter is SET LOCALLY and
   needs no variant row.
3. If a different step is required, 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 the variant? Every row names its retirement condition,
   even "the statute changes".

The test is asymmetric by design: easy to add a parameter, hard to add a
variant, because every variant is a branch an automation rule must carry
and the overseer must verify separately.

## Variants and automation

An automation candidate flagged at L2 is released for the generic step
first, then for each variant whose automation effect reads
*parameterizes*, and never for a variant whose effect reads *blocks* until
the variant is retired or the rule is rewritten. The catch rate is published
per class of action and per variant, not per process.

## Worked example

A generic schedule-build process publishes fourteen calendar days before the
first shift. Three local differences arrive:

| Difference | Class | Outcome |
|---|---|---|
| a statute requires publication twenty-one days ahead with predictability pay for later changes | statutory | a parameter of the publication step: SET LOCALLY, no variant row |
| a works council must receive the draft and may object within five working days | statutory | a new decision step between build and publish: variant row, works-council liaison as owner, function head as approver |
| a migrating unit still builds on its old platform; schedules are exported and re-keyed by hand | transitional | variant row, expiry at the platform cut-over date, automation effect *blocks* against the publication candidate until then |

## For the inventory

The screen's second and fourth questions use this test. A request that is a
parameter of an existing process is a minor modify; one that adds or moves a
step with its own owner is a major modify; one with its own trigger and
cadence is a new row. A request that is a preference is neither a row nor a
variant.

Block 5 — authority-tiers.md

<!-- Derived from [[Decision Authority Tiers in Workforce Operations]] (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. -->
# Decision authority tiers

A five-rung ladder of seats at which each decision point of a process is
signed. The tiers name positions on a ladder, not job titles: what makes a
seat tier 1 is that its decisions are bounded by guardrails a higher seat
published. A decision sits as low as the seat whose error is cheapest to
reverse [A]; one accountable seat per decision. Write the tiers exactly as
below; never a role word such as "planner" as a tier, never a board or a
committee as a tier.

## The five tiers

| Tier | Seat | What it signs | What bounds it |
|---|---|---|---|
| 1 | the pillar's analyst inside guardrails: real-time analyst, forecaster inside the lock calendar, scheduler inside the published rules, the desk that runs loans and trades | actions inside published guardrails, from an approved cascade; no approval sought | the guardrails, held as SET LOCALLY values in the L3 job aids |
| 2 | supervisor or team lead | actions the guardrails exclude by definition, on the analyst's recommendation; minor changes to L2 and L3 | the pillar's budget for the day or week |
| 3 | operations manager or ROC duty lead | actions that cross a queue, skill, site or supply node; incident ownership at the top severity rows; a reforecast outside the band the schedule can absorb | the plan of record; the decision-rights table |
| 4 | function head | the mid-term and long-range locks, the plan of record, the build parameters, a statutory variant, a version of the standard | the executive sponsor's envelope; the statute |
| 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 | by exception only; every exception recorded with its price |

A seat may always take a lower tier's decisions and never a higher tier's.
An analyst who takes a tier 2 action because the supervisor was unreachable
has taken an unsigned action, and the record says so.

## Variants map to tiers

Statutory: function head, tier 4, on legal advice. Contractual: the
placement and vendor lead, a tier 3 seat. Structural: the process owner at
its own tier. Transitional: the standards committee, which sits outside the
ladder because it governs the standard, not the operation.

## Three instruments, kept separate

- **Staffing colour codes** (Blue, Green, Yellow, Red, Black) classify what
  the operation has become; triggers and actions per code are SET LOCALLY.
  Typical mapping [A]: Blue and Green held at tier 1; Yellow at tier 1 with
  tier 2 informed; Red at tier 2 with tier 3 owning the ticket; Black run by
  the tier 3 duty lead with tier 4 informed. Written once, in the job aid.
- **The severity matrix** classifies what happened; values SET LOCALLY.
  Severity decides who is told and how fast; the tier decides who may act.
  Severity 1 or 2 fires the continuity wire and is owned at tier 3, tier 4
  among those notified.
- **The tier** is a sign-off, not a state: read from the card's profile,
  never from the wallboard.

## Tiers and the action gate

A rule is written against a class of action, the class carries the tier of
the seat whose decision it replaces, and the rule is released into that
tier, never above it. A rule that proposes break moves is released into
tier 1 when its catch rate for that class is published, and stays a proposal
above it whatever the catch rate, because evidence about break moves says
nothing about mandatory overtime. The tier names the seat whose verification
work instruction produces the catch rate.

## Tiers and decision rights by horizon

The function is accountable for the method and responsible for the advice;
the supply-node owner is accountable for the decision. A tier names the seat
inside the function that signs the function's method or advice. Where the
decision-rights table makes the supply-node owner accountable (a hiring
plan, a placement, a clearing move), the profile reads "advice at tier n;
decision per the decision-rights table". The exception tier is a route, not
a sixth decision body.

## Typical decisions by pillar (illustrative, [A]; every cell SET LOCALLY)

| Pillar | Tier 1 | Tier 2 | Tier 3 | Tier 4 | Exception |
|---|---|---|---|---|---|
| Forecasting | apply a confirmed, sized signal inside the lock calendar | a judgmental override outside the model's band, reason recorded | a reforecast that moves the weekly requirement outside the schedule's band; the short-term lock, signed by the seat that owns the client portfolio | the mid-term and long-range locks; the plan of record | a gap outside the band the plan can absorb |
| Scheduling | swaps, time-off inside the allotment, break moves inside the rules | a time-off exception beyond the allotment; a shift change inside the notice period | re-publication after the lock; the week's overtime plan | the build parameters; the allotment plan | a collective-agreement or works-council change |
| Real-time | break resequencing, skill rebalancing inside guardrails, voluntary time off inside budget | mandatory overtime; pulling agents from off-phone activity | cross-site or cross-skill routing change; incident ownership at severity 1 or 2; partner overflow | suspending a service construct for the day; a standing guardrail change | one client's service traded against another's |
| Work placement | a loan inside pre-agreed terms | a trade between internal pools inside the day's cap | a sourcing recommendation through the gate, as advice; a contractual variant | the gate's outcome as advice; the scorecard findings | a placement that changes the network design |
| Continuity interface | receive the wire's notification; run the degradation runbook's first steps | confirm the crisis staffing state | the crisis re-plan; placement under duress proposed | the re-plan signed as the product to the continuity owner; the judgmental override | moving work across supply nodes where the wire's authority was left unsettled |
| Cross-cutting | publish a report on its calendar with its grades | a minor change to L2 or L3 | a major change request admitted to the queue | a version of the standard; closure of a compliance finding | a finding with statutory exposure |

The judgmental override appears at tier 2 under forecasting and at tier 4
under the continuity interface; the difference is crisis. Inside the normal
cycle an override is a bounded correction a team lead can sign; under the
wire it is the input to the re-plan and is signed where the re-plan is.

## Escalation and step-down

Escalate one tier when any of three conditions holds: the action taken has
not produced its expected effect inside the window SET LOCALLY for it; the
action now required is above the current tier by definition; or situations
compound so the tier's scope no longer covers the whole. One tier at a time,
except where the card's profile names a direct route.

Step down only after the **reverse check**, recorded: the triggering metric
has recovered and held for the window set locally; reversing the levers
deployed is projected not to reopen the gap; no dependency remains open (a
partner activation inside its notice period, a pending reforecast, an
unclosed incident record). A step-down that fails any part is a new
escalation. One tier at a time; the seat that escalated is told; the record
carries both the escalation and the return.

## For the inventory

A catalog row carries no tier. The tier enters when the shell becomes a card
(profile field 13). Use this file to keep the vocabulary exact when the user
describes who signs what, and to flag a process whose decisions have no
stated tier as a finding for the committee.

Block 6 — l3-forms.md

<!-- Derived from [[Runbooks, Playbooks and Work Instructions]] and the process types of [[Process Inventory for a Workforce Function]] (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. -->
# The three L3 forms

An L3 job aid takes one of three forms. Thresholds, screenshots and named
systems live at L3 and nowhere above, so that L0 to L2 stay stable across
platform changes; a function whose aids have no fixed form ends up with
twenty-page playbooks nobody opens during an incident and one-line work
instructions that hide the threshold in someone's head.

| Form | Situation | Is the next step known before the situation starts? | Reader | Process type served |
|---|---|---|---|---|
| Work instruction | a recurring operations step: a query, a reconciliation, a publication, a verification | yes, always; deterministic | the seat that runs the step, including a new occupant on day one | operations; the steps of a change |
| Playbook | a situation with more than one legitimate response: a volume spike, a mass absence, a gap outside the band | the options are known, the choice is not; a decision rule picks | the seat at the tier that may choose | break/fix where judgement is needed; the exception path of an operations process |
| Runbook | a degradation or a one-time scripted change: a platform outage, a cut-over, an instance consolidation | yes, as a sequence with a verification at each step and a way back | the seat that holds the degradation, at the tier the entry condition names | break/fix; method of procedure |

The middle column sorts an aid: next step known and the same every time is a
work instruction, and a playbook written for it is padding; options known but
choice situational is a playbook, and a work instruction written for it hides
a decision in a step; a failure or a pending change, each step verified and
reversible, is a runbook. A playbook may hand off to a runbook; a runbook may
call a work instruction; a work instruction never calls either.

## Four process types decide the form

| Type | Trigger | Typical L3 form | Example |
|---|---|---|---|
| Operations | a calendar, a shift or an interval boundary | work instruction | the monthly capacity cycle; report publication |
| Break/fix | a degradation past a written entry condition | runbook, with a playbook where options exist | platform degradation; incident management |
| Change | a request through the change-control board | the change record and a work instruction per step | routing change control; standards change control |
| Method of procedure | a dated, rarely repeated event executed to a script | runbook with verification and rollback at every step | a client portfolio's cut-over to the shared calendar; a platform instance consolidation |

Record the type against every catalog row where the user can state it; it
is read later as the review cadence of the row's job aids.

## Anchoring

Every L3 document anchors twice, both as fields on the document: upward to
the section number of the parent standard it details, and sideways in the
Applicable Documentation column of the L2 step table (the L2-to-L3 join
key), in every row that depends on it. "What breaks if this aid changes" is
a search of the join-key column; "which standard does this aid implement"
is the section number. An L2 row that reads SET LOCALLY names, in its join
key, the aid where the local value lives.

## Minimal templates (a function may add fields, never remove these)

**Work instruction** `WI-nnn`: ID and title (verb and object) · anchored to
(section; L2 rows) · trigger and owner (a seat) · preconditions · steps
(numbered; one actor, one verb, one object; screenshot beside its step) ·
values (thresholds, codes, calendars, tolerances, each with its grade and its
SET LOCALLY owner) · systems (the named platform and screen) · definition of
done · review (date, and the trigger that forces an earlier one).

**Playbook** `PB-nnn`: ID and situation (entry criteria written) · anchored
to · owner and tier · options table (option · condition · cost · tier
required · time to take effect) · decision rule (ordered; the first option
whose condition holds; what to do when none holds) · communications and
timer · exit and hand-off · last exercised and review.

**Runbook** `RB-nnn`: ID and degradation · entry condition and the tier that
may open it · anchored to · owner and tier · pre-checks · steps with a
verification per step · rollback per step, and the point past which rollback
is unavailable, named · exit condition and the reverse check · record at
closure · last invoked and review.

The options table is the field most often omitted and most often regretted:
a playbook without options is a work instruction followed into the wrong
response; one without a decision rule returns to the analyst the judgement
it existed to pre-make.

## Review cadence by form

Work instruction: at each platform release that touches its screens and at
the standard's annual expiry. Playbook: after every use at the top severity
rows and at least quarterly. Runbook: after every invocation and, where it
has not been invoked, by an annual tabletop exercise, because a runbook that
has never run is a guess. An L3 revision updates the register row without
reopening L0 approval; an expired aid is reported by the lifecycle's
compliance step as an expired package is.

## The catch-rate verification step is a work instruction

The step that produces an automation rule's catch rate is recurring and
deterministic, so it is written as a work instruction: steps are the sample
and the comparison; definition of done is the period's catch rate published
per class of action and per variant; the review trigger is a change to the
rule's specification. A catch rate only one person can produce is not
published.

## The "Level" collision

L3 here is the third documentation level of the L0-L3 decomposition. It is
unrelated to maturity level 1 of the maturity model, whose starter
templates are work instructions without a parent standard.

Block 7 — intake-screen.md

<!-- Derived from [[Process Inventory for a Workforce Function]] (intake section) 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. -->
# The intake screen and the catalog row

A request arrives through the function's single intake door (Work Intake for
Planning and Analytics Teams) and is screened by the standards committee at
the catalog check of the lifecycle. Every candidate for the inventory, a
generic card the function may run, a shelf page, or a process the user
names, passes the same four questions in order. The product is a queue
position or a deferred-log row; nothing is refused silently, because a
request that vanishes returns under a new name and the second question then
fails.

## The four questions

| # | Question | What it asks | Outcome |
|---|---|---|---|
| 1 | Importance by volume | How much depends on the process (a service commitment, a cost line, a statute, a client contract) and how often it runs? | low on both: stays practice; deferred log, with the reason. The same screen ranks the first wave |
| 2 | Already catalogued? | Does a card exist under another name, or is the request a step of a process the inventory holds? A process has its own trigger and cadence; a re-run of another process's steps under a new name does not | yes: becomes a modify request against the existing row; the duplicate is struck and the merge recorded |
| 3 | New or modify? | A new card, or a change to an existing card? | new: a row with a skeleton-until date; modify: a change request against the row |
| 4 | Major or minor? | Major alters the L1 flow, ownership, or the profile's trigger, scope, authority tier or class, and reopens L0 approval; minor alters L2, L3 or another profile field and is recorded in the revision history | major: the committee's queue; minor: the owner's revision history |

Worked instance of question 2 (illustrative): a predecessor organization's
"weekly reforecast" was struck from one inventory because it proved to be a
re-run of the forecast build, not a process with its own trigger; the weekly
rolling reforecast (GP-103), which has both, stayed.

## The three row marks

Every row carries exactly one source mark. The marks parallel the shell
marks of the Process Decomposition pack and hand over to them.

| Mark | Meaning | Card id in the row | What happens next |
|---|---|---|---|
| `GP-card` | a generic process card exists; the function will localize it | `GP-nnn` | the shell is written from the card's profile; the pillar pack localizes it |
| `shelf page` | an existing method page already serves as the generic process; cataloged as a conversion | the page title | the shell's status reads `Shell (conversion)`; the page is the card |
| `NOT INVENTORIED — <seat> · by <date>` | the process is asserted by a predecessor organization, not confirmed | none | allowed for one committee sitting only; then it is a shell or it is struck |

A candidate screened out at question 1 takes no mark: it is a deferred-log
row, with the reason and the seat that may reopen it.

## The catalog row (the standard's section 2)

| Section | Process | Class | Owner (seat) | Skeleton until | Mark | Card id | Local id |
|---|---|---|---|---|---|---|---|
| §3.n | the process name as the card or shelf page gives it | strategic · real-time · both · supporting | a seat, never a name; one per row | a date; missing it is a compliance fact | GP-card · shelf page · NOT INVENTORIED | `GP-nnn` or the page title | `P-nnn`, assigned by the committee at deployment; blank until then |

Rules for the row: the class comes from the card and is not re-decided per
function; the owner and the date come from the user and are never
invented; a row whose owner is a committee or a board has no owner; the
first wave is the set of rows small enough to pass the acceptance gate
inside the first quarter, and the processes the first agent team will run
stay in it; everything else takes a quarter-end skeleton-until date.

## The decisions row (`inventory-decisions.md`)

| Candidate | Source | Q1 importance by volume | Q2 already catalogued? | Q3 new or modify | Q4 major or minor | Mark or deferred | Reason |
|---|---|---|---|---|---|---|---|
| the name as it arrived | card walk · shelf page · user-named · intake door | the dependency and the frequency, in the user's words | the existing row it duplicates, or none | new · modify | major · minor · n/a | the mark, or "deferred" | one line; for a merge, the row merged into |

One row per candidate, including every card the function does not run
("deferred: the function has no partner supply nodes" is a reason). The file
is the committee's record; without it the catalog cannot say why a process
is absent, and the absence returns as a new request.

## Count line for `catalog.md`

Rows by mark, computed from the table [C]: `GP-card n · shelf page n ·
NOT INVENTORIED n · deferred n`. The sum of the first three is the number of
sections the standard must issue with an owner and a date.

Usage notes

Sizing. Block 1 is about 500 words and loads with every message; Blocks 2–7 total about 6,700 words and are retrieved as needed; Block 2 is the largest at about 1,500, most of it the card table.

Output. The pack emits two Markdown files: catalog.md, the rows of the standard's section 2 by section with a count line by mark, and inventory-decisions.md, one row per candidate with its four screening answers and the reason it is in, merged, deferred or marked. Both transfer to a spreadsheet by hand or by script. The catalog is the input to Wiki:Packs/Process Decomposition, whose Block 5 writes an L0 shell per row, and to Wiki:Packs/ROC Standard Authoring, which places it in the standard.

Localizing. The taxonomy and the card list are generic and do not change per function; what the function supplies is which rows it runs, under which section, owned by which seat, by which date. The pack refuses to fill an owner, a date or a local value the user has not given, to name a person against a seat, or to write an abstract, an L1 or an L2 for any row.

Drift. Blocks 2–7 derive from the eight source pages in the infobox. A material change to any of them, in particular a new card in the inventory or a change to the profile's field list, is the trigger to regenerate the affected block and bump the version.

Scope. Nothing in the pack is specific to any organization. The industry is a global service business; supply nodes, channels and client contracts are the function's own.

Change history

Version Date Change
1.0 2026-10-16 First release: instruction block plus six reference files (taxonomy, L0 profile, standard and variant, authority tiers, L3 forms, intake screen)

See also

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