Wiki:Packs/ROC Standard Authoring

Pack
ID	CP-OPS-003
Name	ROC Standard Authoring
Domain	OPS
Version	1.0
Blocks	1 instruction + 5 reference
Source	Anatomy of a ROC Standard · Three-Step Forecast Build · Forecast Lock Process · Incident Management for Contact Centers · Process Decomposition (L0–L3)
Planning-week block	Day 2 afternoon (the catalog and the first filled section) · Day 4 morning (front matter, §2 owners and dates, the expiry)

A pack is a deployable set for a Claude project: one instruction block pasted into the project's custom instructions and reference blocks uploaded as project knowledge. This pack supports the working sessions in which a workforce function authors its standard: the front matter with an expiry, the §2 function catalog with a seat and a date against every section, any §3.x section in the ten fixed blocks from an L1 flow and a named L2 table, and the §4 toolset, §5 metrics and §6 validation clause. The document pattern is on Anatomy of a ROC Standard; the process decompositions a section is built from are produced with Wiki:Packs/Process Decomposition (CP-OPS-001).

When to use it

Create a project from this pack when a function is issuing or revising its standard: on Day 2 afternoon of a planning week, when the room agrees the function catalog and fills the first strategic section; on Day 4 morning, when the Standard v0.1 is issued with its owner, approvers, expiry and a seat and a date against every section; and in the weeks after, when the standards committee authors the shelf sections (Forecast Lock Process, Forecast Collision Calendar, Call-Sharing Models and Cost Allocation, Vendor Change Control for Routing, Activity-Code Consistency and the incident set) against the same template. The artifact it produces is the Standard front matter and §2 catalog (template SD) and its §3.x sections on the ten-block template (template SS), each keyed by its section number and pointing at the L0 card that decomposes it, which is produced with Wiki:Packs/Process Decomposition.

It is not for decomposing a process (that is CP-OPS-001), not for deciding which processes exist or in what order they are documented (that is the room's decision, on Process Shells for a Workforce Standard and Process Standardization Lifecycle), and not for the practice standard itself, which is the Future WFM Operating Standard.

How to deploy

1. Create a project in Claude named for the work, not the method: "Forecasting standard sections", not "Standard authoring".
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 section or the front-matter block you are filling, and the L0 card and L1 flow if they exist.

Block 1 — Project instructions

Paste this into the project's custom instructions. It loads with every message in the project, so it is deliberately short.

# ROC Standard Authoring

## Context
This project authors a workforce function's standard in the pattern the wiki page Anatomy of a ROC Standard defines: expiring front matter, a §2 catalog with a seat and a date against every section, §3 sections in ten fixed blocks, a §4 toolset whose products sit in an annex, §5 metrics in two bands, and a §6 validation clause with an owner, a cadence and a scale. It serves Day 2 afternoon of a planning week (the catalog; the first filled section) and Day 4 morning (front matter; §2 owners and dates; the expiry).

## Routing
| When the task is… | Open |
|---|---|
| The cover block, approvals, change history, glossary, the expiry | `standard-front-matter.md` |
| §2: functions, class, seat, "skeleton until" date, nested sub-sections, accommodated variations | `function-catalog.md` |
| Any §3.x section: the ten blocks, the L1 flow, naming the L2 table and job aids | `section-ten-blocks.md` |
| §4, §5, §6; planning a certification; reviewing a section at expiry | `validation-and-expiry.md` |
| Seeing a finished section before writing one | `worked-section-short-term-forecast.md` |

Open one. If the question is answerable without any of them, answer it.

## Disciplines
- Ten blocks, always, in the fixed order; an empty block reads `SHELL — owner <seat> · fill by <date>`, never nothing.
- The Method block carries an L1 flow, decisions as questions, ten to fifteen steps being the healthy range Process Decomposition (L0–L3) gives; it names the L2 table and job aids, never reproduces them.
- Owners are seats, never names; approvers are titles.
- Products appear only in the §4 annex; the body names capabilities: long-term capacity engine, short-term WFM engine, intraday automation, Python analytics platform, reporting platform, data core, event ledger, register.
- Every number carries a grade: [M] measured, [C] computed, [E] estimated with a range, [A] asserted. A number carried across a channel, platform or cohort change is [A].
- Every metric names its instrument, resolution and pairing; quality and customer-experience measures are paired, never blended.
- Vendor governance is not a section; every section carries a node attribute and a vendor paragraph.
- Conformance is a maturity level, stated as a band until a certification has run.
- Every empty field carries an owner and a date; every accommodated variation carries an expiry.
- Cite the wiki's method pages by title instead of restating them.

## Output
A section or a front-matter block as Markdown under the reference files' headings, ready to paste into the Standard's document home; tables for the catalog, the L1 flow and the metrics rows; a list of the blocks still empty, each with its owner and date. State the grade of every number and the seat of every owner. Refuse a headcount number, a person's name against a seat, a placement decision, or a product name outside the annex; name the page or forum that owns it instead.

Source: Wiki:Packs/ROC Standard Authoring (CP-OPS-003) v1.0

Block 2 — standard-front-matter.md

Save as standard-front-matter.md. Derived from Anatomy of a ROC Standard: the cover block, the control pages, the expiry rule and the issue act.

<!-- Derived from [[Anatomy of a ROC Standard]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Standard front matter

The front matter is a form. Every field is filled or marked empty in one of three forms: `SHELL — owner <seat> · fill by <date>`, `SET LOCALLY — <seat>`, or `NOT INVENTORIED — <seat> · by <date>`. No other form. An empty field is indistinguishable from a forgotten one.

## Cover block

| Field | Rule | If empty |
|---|---|---|
| Title | `<Function> Standard`; no platform, no estate identifier | — |
| Abstract | 2–3 sentences: what the document is, who it binds, where the method pages it cites live; written last | `SHELL — owner <seat> · fill by <date>` |
| Point of contact | A seat, never a name; usually the methodology steward | — |
| Contributors | Seats, listed by section | — |
| Release version | 0.1 on first issue; increments on every change-controlled edit; never a "v2" file | — |
| Release date | The issue date | — |
| **Expiry** | Twelve months from issue; the review trigger | — |
| Approvers by title | The function's leader; the council; a finance partner for §5 | — |
| Confidentiality | Internal for the document; the cited method pages are public | — |

## Control pages, in order

1. **Document approvals** — one row per approver: title, decision, date.
2. **Change history** — version · description of change · date · seat; starts at 0.1.
3. **References** — the wiki's method pages cited by title; the document never restates them.
4. **Index keywords** — the function's vocabulary terms.
5. **Glossary** — starts from the planning-week vocabulary (global ROC, node, node owner, seat, supply seat, service tier, the gate, the registers, the capacity cycle, L0–L3, the intake door, shell).
6. **Contents · list of figures · list of tables** — the figures list starts with the operating-model ring, the capacity cycle and the severity matrix.

## Setting the expiry

- The expiry is what forces the annual review. A standard without one is reviewed when someone remembers.
- The expiry of an *accommodated variation* (§1) equals the "skeleton until" date of the section that replaces it.
- At expiry the §6 owner runs certification, the change history gains a row, the version increments, and a new expiry is set. The document is never re-issued as a new file.

## The issue act (the planning week's decision D-11)

Issuing v0.1 is one act with four parts, taken together or not at all:
1. the owner (a seat) and the approvers (titles);
2. the expiry;
3. the §2 catalog with a seat and a date against every section, filled or skeleton;
4. the accommodated variations, each with its expiry.

A skeleton with owners and dates is a standard. A skeleton without them is a wish list, because nothing in it names who would make it false.

## Checklist before issue

- [ ] Every cover field filled, or empty in one of the three forms with a seat and, where the form takes one, a date
- [ ] Expiry set, twelve months out
- [ ] Approvals block has one row per approver
- [ ] Change history starts at 0.1
- [ ] References cite pages by title; nothing restated
- [ ] Glossary carries every vocabulary term used in the body

Block 3 — function-catalog.md

Save as function-catalog.md. Derived from Anatomy of a ROC Standard and Process Decomposition (L0–L3): the classes, the generic catalog, the nesting rule and the accommodated variations.

<!-- Derived from [[Anatomy of a ROC Standard]] and [[Process Decomposition (L0–L3)]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# §2 The function catalog

One row per function: ID, section, function, class, owner (a seat), skeleton-until date, lifecycle status. A section's ID is its section number, `S-3.1`, `S-3.1.2`. That is not the same object as the L0 process card that decomposes it, which is keyed `P-nnn` and produced with the Process Decomposition pack (CP-OPS-001); one card can stand behind two sections.

## Classes

| Class | Meaning | Test |
|---|---|---|
| strategic | sets the plan | its output is consumed by a lock |
| real-time | steers against the plan | its clock is the interval or the day |
| both | one function with a strategic and a real-time step | name which steps are which |
| supporting | serves the other functions | it has no plan and no steer of its own |

## The generic catalog

| § | Function | Class |
|---|---|---|
| §3.1 | Forecasting (long-range, mid-term, short-term) | strategic; short-term is both |
| §3.2 | Capacity planning and the monthly cycle | strategic |
| §3.3 | Scheduling | both |
| §3.4 | Real-time performance and automation | real-time |
| §3.5 | Intake and the register | supporting |
| §3.6 | Incident management, with the continuity wire | real-time |
| §3.7 | Work placement: the gate, the registers, the forum | both |
| §3.8 | Reporting, metrics and analytics | supporting |
| §3.9 | Data definitions and governance | supporting |
| §3.10 | Routing and the capability layer | real-time in operation; strategic in design |
| §3.11 | Business improvement and best-practice sharing | supporting |

Add a function only when it has its own L1 flow and its own owner. Remove nothing from the eleven without recording why in the change history.

## Two rules

1. **Vendor governance is not a function.** No section. Every section carries a *node attribute* (which nodes the function runs on) and a *vendor paragraph* (what changes when the node is a partner supply seat: contract mechanism, billable view, oversight standard, comparability clause, change control, renewal calendar).
2. **Nesting.** A function with more than one distinct process nests them: §3.1.1, §3.1.2, §3.1.3 under §3.1, each a full ten-block section. Nothing is inherited silently; a block identical to the parent's says "as §3.1".

## Catalog row template

```
| ID | § | Function | Class | Owner (seat) | L0 card | Skeleton until | Lifecycle status |
| S-3.n | §3.n | <function> | <class> | <seat> | <P-nnn, if one exists> | <Day Mon YYYY> | skeleton · authoring · peer review · gate · deployed · under review |
```

Lifecycle status follows the seven-step lifecycle on the wiki page Process Standardization Lifecycle; a section is "deployed" only after the acceptance gate.

## Accommodated variations (§1)

List every place a heritage still runs its own method:

```
| Variation | Where | Replaced by section | Expiry |
| <heritage method> | <node / instance> | §3.n | <date = that section's skeleton-until> |
```

## Owner and date rules

- Owner is a seat. "The standardization lead", "the definitions owner", "the real-time lead", "the placement lead", "the methodology steward" are seats; a name is not.
- The skeleton-until date is a working day, calendar-checked, and is the same date as the expiry of any variation the section replaces.
- Sequence the dates: a section whose inputs come from another section is dated after it.

## Worked catalog (example only; dates are the example's)

The planning-week example issued eleven rows and no filled section on Thu 23 Apr 2026, with the first three sections (S-3.1.1 three-step build, S-3.1.2 lock, S-3.1.3 collision calendar) dated Fri 25 Sep 2026 for the short-term step and Thu 31 Dec 2026 for the mid-term step, and the routing and activity-code sections (S-3.10.1, S-3.10.2, S-3.3.1) dated Wed 31 Mar 2027. Three accommodated variations were listed: two heritage forecast calendars expiring Tue 9 Jun 2026 and one heritage activity-code set expiring Wed 30 Jun 2027.

Block 4 — section-ten-blocks.md

Save as section-ten-blocks.md. Derived from Anatomy of a ROC Standard, Three-Step Forecast Build, Forecast Lock Process and Process Decomposition (L0–L3): the ten blocks, the L1 conventions, how the L2 is named, the self-check.

<!-- Derived from [[Anatomy of a ROC Standard]], [[Three-Step Forecast Build]], [[Forecast Lock Process]] and [[Process Decomposition (L0–L3)]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# §3.x The ten-block section

Every section has the same ten blocks in the same order. The Method block is where the content lives; the other nine frame it. Write all ten; an empty block reads `SHELL — owner <seat> · fill by <date>`, or `SET LOCALLY — <seat>` where the content belongs to the node, or `NOT INVENTORIED — <seat> · by <date>` where the inventory has not yet been done. No other form.

## The blocks

| # | Block | What it carries | Length |
|---|---|---|---|
| 1 | Purpose | What the function is for, in scope terms | one paragraph |
| 2 | Inputs | What arrives, from which interface, on what cadence; cite the interface register row (Operations, Finance, Recruiting, Training, HR, Technology, Commercial, Delivery partners, Quality) | 3–6 lines |
| 3 | Outputs | What leaves, to whom, in what form | 3–6 lines |
| 4 | Roles | Who does it (role catalog); who owns the method (the function); who owns the decision (the RACI row) | 3–5 lines |
| 5 | **Method** | The L1 flow (table); the L2 table named with its row count and column standard; the method pieces kept from earlier standards; the job aids named | the L1 table + one paragraph |
| 6 | Metrics | The function's scorecard rows, each with instrument, resolution, pairing, and the maturity level it belongs to | 3–6 rows |
| 7 | Tools | Platform-neutral capabilities; the annex maps them to products | 2–4 lines |
| 8 | Controls | The acceptance gate passed; the catch rate if any step is automated; the change-control path | 3–5 lines |
| 9 | Maturity | One line per level, 1 to 5; "today" as a band | 5 lines |
| 10 | Node attribute and vendor paragraph | Which nodes; what differs at a partner supply seat | 2–5 lines |

## The L1 flow

- Numbered whole steps, integers only. Process Decomposition (L0–L3) gives ten to fifteen as the healthy range: more suggests the process wants splitting, fewer suggests steps are hiding sub-processes. Nine is not a defect if no step is hiding one.
- Decisions are questions in bold with their own step number; branches are written as "yes → n · no → m".
- Every step has an owner (a seat or a role) and a next step; the last step's next is End.
- Iteration is drawn as a loop back to a numbered step, never implied.
- One page; readable in thirty seconds by someone who will never read the L2.

```
| # | Step | Owner | Next |
|---|---|---|---|
| 1 | <verb phrase> | <seat> | 2 |
| 2 | **<question>?** | <seat> | yes → 3 · no → 5 |
| … | | | |
| n | <verb phrase> | <seat> | End |
```

## Naming the L2 table

The Method block names the L2 table and does not reproduce it:

> "The L2 step table runs about <n> rows [E] on the fifteen columns of Process Decomposition (L0–L3) and is produced with CP-OPS-001. Its job aids are <list>."

The fifteen columns: L1 step ID · L1 step name · step description · L2 step ID · L2 step (how) · dependent steps · tools · ticketing code · owner (group, function) · ticket status · applicable documentation (the L2→L3 join key) · notification required · approval required · approvers · duration.

## Rules that apply to every block

- Products only in the §4 annex. Body vocabulary: long-term capacity engine · short-term WFM engine · intraday automation · Python analytics platform · reporting platform · data core · event ledger · register.
- Every number carries [M], [C], [E] with a range, or [A]. Nothing carried across a channel, platform or cohort change is [M], per Human Gates and Number Grades.
- Metrics are paired, never blended: a quality score with a customer-experience index; an outcome with its cost per unit of value.
- Owners are seats. Decisions belong to the node owner; the method belongs to the function.
- Cite the wiki's method pages by title; restate nothing they carry.
- A section that automates any step states the catch rate that released that class of action and the gate it was released from, in the terms Human Gates and Number Grades states and the wiki's level pages agree on.

## Section register row

Each finished section is recorded once:

```
| ID | Section | Class | Owner (seat) | Blocks filled | L1 steps | L2 rows | Gate status | Skeleton until |
| S-3.n.m | §3.n.m <name> | <class> | <seat> | n of 10 | n | ~n [E] | skeleton · peer review · passed | <date> |
```

## Self-check before peer review

- [ ] Ten blocks present, in order; every empty one in one of the three forms, with a seat
- [ ] L1: decisions as questions, every step owned, every branch resolves to a step or to End, every approval step carrying a refusal outcome
- [ ] L2 named with a row count and the job aids listed
- [ ] No product name in the body
- [ ] Every number graded; every estimate has a range
- [ ] Every metric has instrument, resolution, pairing and a level
- [ ] Node attribute and vendor paragraph written
- [ ] Nothing restated that a cited page carries

Block 5 — validation-and-expiry.md

Save as validation-and-expiry.md. Derived from Anatomy of a ROC Standard and Incident Management for Contact Centers: the platform-neutral toolset and its annex, the two metric bands, the certification clause and what happens at expiry.

<!-- Derived from [[Anatomy of a ROC Standard]] and [[Incident Management for Contact Centers]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# §4 Toolset · §5 Metrics · §6 Validation and certification

## §4 Toolset (platform-neutral)

Name capabilities in the body; map them to products in an annex that can be replaced without reissuing the document.

| Capability | What it holds for the Standard |
|---|---|
| long-term capacity engine | the annual envelope; the long-range lock |
| short-term WFM engine | forecasts and schedules of record; the short-term lock; activity codes per instance |
| intraday automation | the capacity state; real-time state codes; the steer |
| Python analytics platform | decompositions, control charts, the checks |
| reporting platform | the calendar views, the logs, the scorecard |
| data core | the ledgers: demand, supply, forecast (with vintages), events, definitions, the register |
| the register | the intake door's rows and the decision record |

Keep here, as a job aid, the eight lifecycle facts the wiki page Incident Management for Contact Centers requires at closure: incident start · incident detected · fix agents engaged · customer impact · probable cause · mitigation · incident diagnosed · incident repaired. The Standard adds one requirement of its own: every timestamp among them carries its zone, because a bare clock time reads differently at every node. The same list is the close-out record, the post-mortem agenda and every notification.

**Annex template**

```
| Capability | Product (this estate) | Instance(s) | Owner (seat) | System of record for |
```

## §5 Metrics (two bands)

**Outcome band** (what the operation is for): a quality score paired with a customer-experience index; cost per unit of value; the commercial value tier where earned. Paired, never blended.

**Operational band** (how the function is running), channel-neutral: contact rate · offered · handled · abandoned · handle time · speed of answer · resolution · service level · transfers.

Every metric row:

```
| Metric | Band | Definition ID (register) | Instrument | Resolution | Paired with | Level it belongs to |
```

The six core definitions (occupancy, handle time, shrinkage, contact, attrition, ramp) are the definitions register's, cited by ID, never redefined in the Standard.

## §6 Validation and certification

| Element | Rule |
|---|---|
| Owner | the methodology steward (a seat) |
| Cadence | annually against the expiry; per function when a section leaves skeleton status |
| Scale | the five-level ladder of the WFM Labs Maturity Model: 1 Initial · 2 Foundational · 3 Progressive · 4 Advanced · 5 Pioneering; one line per function; a band until the first certification |
| Checked | process use to the L2 · toolset and configuration to the annex · the register's readout times · the severity definitions · the cross-node reviews taking place · activity-code check results · lock-calendar adherence |
| Record | one row per function per certification: level, evidence, gaps, next date |

**Certification row**

```
| § | Function | Level certified | Evidence read | Gaps | Owner (seat) | Next certification |
```

## At the expiry

1. Run §6 for every function that has left skeleton status.
2. For every section still marked `SHELL`, confirm the owner and re-date or escalate; a section past its date with no owner is the first finding.
3. For every accommodated variation past its expiry, retire it or re-date it with a reason in the change history.
4. Regenerate the annex against the platforms in use.
5. Increment the version, add the change-history row, set the next expiry.

## What certification must refuse

- A level stated as a point for a function that has not been certified: it is a band.
- A "conforms / does not conform" verdict: the scale is the ladder.
- A product name in the body: it belongs in the annex.
- A headcount figure of any kind: the Standard governs method, not size.

Block 6 — worked-section-short-term-forecast.md

Save as worked-section-short-term-forecast.md. Derived from Three-Step Forecast Build and The Short-Term Forecasting Loop with an Agent Team: one finished section, abridged, with the worked example's figures labeled as an example.

<!-- Derived from [[Three-Step Forecast Build]] and [[The Short-Term Forecasting Loop with an Agent Team]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. Every figure below belongs to the wiki's worked example and is not a fact about any estate. -->
# Worked section: S-3.1.1, §3.1.1 Three-step forecast build (the short-term step)

An example of a finished section, abridged. Use it to see the shape; do not copy its numbers.

**Purpose.** Produce, at each of three horizons, the forecast of volume, handle time and shrinkage by book and channel that the next horizon and the schedule of record are built on, and score each horizon against what arrived so the miss is attributed to a layer and a horizon.

**Inputs.** The lock handed down from the step above; reconciled actuals by channel and interval (interface: Operations); the collision calendar and the event ledger (Operations, Technology, Commercial); the driver refresh from the capacity cycle's stage 1; the definitions register.

**Outputs.** A versioned forecast per horizon with assumption register, lineage and vintage; the lock, published on the lock calendar; the loaded file for the short-term WFM engine; the variance decomposition when a register row is open.

**Roles.** Forecaster builds; the planner who owns the book approves at the gate; the standardization lead owns the method; the node owner consumes and decides.

**Method.** L1, thirteen steps, four decisions:

| # | Step | Owner | Next |
|---|---|---|---|
| 1 | Open the build for the horizon due | forecaster | 2 |
| 2 | Read the lock handed down from the step above | forecaster | 3 |
| 3 | Pull the baseline from the engine on the register's definitions | forecaster | 4 |
| 4 | **Has any driver fallen outside its historical pattern?** | forecaster | yes → 5 · no → 6 |
| 5 | Apply the driver adjustment; name the driver; register the assumption with its grade | forecaster | 6 |
| 6 | Read the collision calendar for this horizon's window | forecaster | 7 |
| 7 | Apply each event's adjustment with its effect window and grade | forecaster | 8 |
| 8 | **Does the build breach the envelope handed down?** | forecaster | yes → 9 · no → 11 |
| 9 | Raise a variance through the lock door of the step above; hold this build | forecaster | 10 |
| 10 | **Does the owner of the horizon above accept the breach?** | step above's owner | yes, the envelope moves → 11 · no → 3, rebuilt inside the envelope, refusal recorded |
| 11 | Version the forecast with lineage and vintage; register every assumption | forecaster | 12 |
| 12 | **Planner gate: approved?** | planner | yes → 13 · no → 3, reason recorded |
| 13 | Publish the lock to the step below and to every interface on the lock calendar | standardization lead | End |

The L2 step table runs about forty rows [E] on the fifteen columns and is produced with CP-OPS-001. Job aids: export procedure · reconciliation checklist · vintage retrieval · decomposition method · control limits.

**Metrics.** Accuracy by layer (baseline, driver, event) and by horizon from vintages (Level 3); share of revisions with a registered assumption (Level 3); days to detection of a level shift (Level 4). Instrument: the vintage table; resolution: interval and day; paired with: the supply-side miss.

**Tools.** Long-term capacity engine (long-range); short-term WFM engine (short-term and the loaded file); Python analytics platform (decomposition, control chart); data core; event ledger.

**Controls.** Every number cites a definition and a grade; nothing carried across a platform or channel change is [M]; planner gate on any version that changes a plan; the acceptance gate passed.

**Maturity.** 1: a single inherited number. 2: per-heritage forecasts on platform field definitions; one accuracy figure. 3: three steps on one definition set; accuracy by layer; vintages; yesterday scored daily. 4: the agent team runs the short-term step; regime detection automated; planner approves. 5: reforecast on trigger within governance bounds.

**Node attribute and vendor paragraph.** All nodes, per book. At a partner supply seat the lock carries the billable view; a partner-held forecaster post is transitional until automated; its output is scored on the same instrument and vintages.

## What the example's numbers illustrate (example only)

- The mid-term step for July 2026 locked Tue 9 Jun 2026 (BD+7); the short-term step for the week of Mon 6 Jul was version 2026-06-24.v1, locked Fri 26 Jun 2026.
- The baseline carried handle time 452 s [M]; the pre-migration 412 s stayed in the lineage relabeled "carried" [A]. That relabeling, not the number, is the point.
- One driver outside its pattern (the partner cohort's ramp) was registered at [E]; one event (a release, Thu 9 Jul, two-day window [A]) was applied.
- Scored in August: volume miss 1.4 percent [C], handle-time miss 0.6 percent [C], read from the vintage; the event layer over-adjusted, the baseline did not.

## Common faults the example avoids

- Adjusting for a recurring driver already inside the baseline (double count).
- A short-term build that changes the locked month's total (a breach, not a forecast).
- Overwriting the forecast on refresh (no vintage, no attribution).
- A carried number presented as measured after a channel, platform or cohort change.

Usage notes

• Sizing. Block 1 is under 500 words and loads with every message. Blocks 2 to 6 total about 3,600 words and are retrieved when the routing table sends the model to them. One section per conversation is the comfortable unit; the front matter and the catalog fit in one.
• Articles before blocks. Every block derives from the source articles in the infobox. A material change to any of them is the trigger to regenerate the affected block and bump the version; check the version and date before assuming a working copy is current. The block files are the single source, and the bordered blocks on this page are generated from them.
• Scope. The pack is method only. Owners are seats, products live in the annex, and the worked example's figures are the wiki's example and not a fact about any estate. Nothing in the pack is specific to any organization; the local catalog, seats, dates and annex are the user's and are never written into the blocks.
• What it refuses. A headcount number, a person's name against a seat, a placement decision, a product name outside the annex.

Change history

Version	Date	Change
1.0	2026-09-17	First release: instruction block plus five reference files, derived from the five source articles

See also

• Planning Week for a Workforce Function — the week this pack serves on Day 2 afternoon and Day 4 morning
• Anatomy of a ROC Standard — the document pattern
• Wiki:Packs/Process Decomposition — CP-OPS-001, which produces the L0 card, the L1 flow and the L2 table a section is built from
• Wiki:Packs/Executive Issue Register — CP-OPS-002, the intake door §3.5 routes through
• Wiki:Packs — inventory and how packs work