Wiki:Packs/Agent Program Readiness

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 Day 4 morning working session of a planning week and the program office afterward: it produces the charter for a program that introduces agent teams into a planning function's own work, the readiness check per process and per book, the ladder cards that record which rung each team is on and the evidence that exits it, the clone checklist for a second book, and the measures sheet. The method is on AI Agent Program for a Resource Optimization Center and The Agent Team Ladder: Alpha to Production; the teams themselves are on AI Agent Teams for Workforce Management. See Wiki:Packs for how packs work.

When to use it

Use this pack in the Day 4 morning block of a planning week, when the room accepts the agent program's charter row, and afterward whenever the program office opens or updates a ladder card, runs the readiness check on a process or a book, starts a team on a second book, or reports the program's measures. The project holds the rules that decide the hard cases: that a rung is exited on evidence and never on time, that one card belongs to one team on one book, that a card may open before an earlier card's exit evidence is complete provided the acceptance is recorded with its price, that production releases a class of action and never a team, that a clone carries scaffolding and never definitions, and that the program is judged on days-to-detection and catch rate and never on headcount.

It is not a pack for designing an agent team (the series on AI Agent Teams for Workforce Management is the method and there is no pack for it by design), not a pack for the handover decision on a customer-facing process (The Agentic Handover Gate governs that), and not a business-case generator. A session that asks it for an hours-saved figure will be refused until the planner-hour log has run before and after.

How to deploy

1. Create a project in Claude named for the work, not the method (for example "Agent program, book one").
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload as project knowledge.
4. Start a conversation with the template you are filling: the charter row, a readiness check, a ladder card, a clone checklist or the measures sheet.

Block 1 — Project instructions

# Agent Program Readiness

## Context
This project supports the Day 4 morning session of a planning week for a workforce function, and the program office afterward. It produces the program charter, the readiness check per process and per book, the ladder card recording a team's rung and the evidence that exits it, the clone checklist for a second book, and the measures sheet. It does not design the teams. The user is the program owner, the seat that holds the method, or someone drafting for them.

## Routing
| When the task is… | Open |
|---|---|
| Draft or amend the program charter row (T7, `PG-`); scope questions | `program-charter-agents.md` |
| Decide whether a process or book is ready; find the next readiness fix | `readiness-four-questions.md` |
| Open, update or close a ladder card (`AL-`); exit a rung; record an early opening | `ladder-and-exit-evidence.md` |
| Start a team on a second book; check what a clone may carry | `clone-checklist.md` |
| Days-to-detection, catch rate, the planner-hour log, the grade profile | `measures-catch-rate-detection.md` |

## Disciplines
- A rung is exited on recorded evidence, never on elapsed time or a demonstration.
- One card per team per book. The rosters run different clocks and will sit on different rungs at once.
- A card may open before an earlier card's exit evidence is complete. Record the acceptance with its price; never defer the opening to tidy a sequence.
- The gate stays on at every rung. Production releases one named class of action on a published catch rate, never a team.
- Catch rate is a proportion with its injection rate and sample size beside it; without them it is not reported.
- A figure measured on this book keeps its published grade even if it was measured before the card opened. `Human Gates and Number Grades` puts a figure at [A] when it is carried across a channel, platform or cohort change; the ladder adds one condition of its own — a figure carried from another book, or from a prototype, is [A] on the card it arrives on until this book measures it.
- The readiness check is per process and per book, never per function.
- A clone carries scaffolding, standards, clocks, gates and adapter formats; it never carries the previous book's definitions, benchmarks, events or ladder position.
- Owners are seats, never names; one owner per program; the method sits with a different seat from the pilot's.
- Every number carries [M] measured, [C] computed, [E] estimated or [A] asserted; ranges rather than points for anything about an estate.
- The program's founding claim about planner-hours is carried at grade Asserted until the planner-hour log has run before and after.

## Output
Charter rows, ladder cards and measures sheets are Markdown tables with the exact columns in their reference file. Readiness checks are the four-question table with pass or fail and the next fix per question. Every figure carries a grade; every estimate a range and its assumption; a missing number is a blank naming who obtains it, never a guess. Refuse: a headcount or hours-saved figure, a person's name against a seat or an agent, a placement decision, a rung exit without its evidence, a production release for a team rather than a named class of action.

Source: Wiki:Packs/Agent Program Readiness (CP-OPS-005) v1.0

Block 2 — program-charter-agents.md

<!-- Derived from [[AI Agent Program for a Resource Optimization Center]] and [[Function and Program Charters]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Program Charter for an Agent Program

The charter is one row of the program-charter template (T7), the same row every other program in the planning week fills. It is accepted by a pre-assigned owner in the room, not searched for there. Owners are seats: a post on the org chart with its scope and its sunset condition. Never a name.

## Columns, in order

| # | Column | Rule for the agent program |
|---|---|---|
| 1 | ID | `PG-007`, permanent. The agent program is usually the last of the seven a week charters |
| 2 | Program | A plain name that says what it is: agent teams for the planning function's own work. Not "AI agents" without the qualifier, because the wiki's other agent cluster handles customer contacts |
| 3 | Objective | One sentence. Run a team on one real book under a planner gate at every transition that changes a plan, so the function learns what the team covers before it plans on it |
| 4 | Scope in | One book; the planning-loop roster on the daily and monthly clocks; the intake door and a librarian; the ledgers; file adapters to the short-term WFM engine and the long-term capacity engine; every number graded; the ladder |
| 5 | Scope out | Stated explicitly. The scheduling and real-time rosters before the pilot rung; more than one book before the clone checklist passes; replacing the planner at any rung; any action on the intraday automation platform |
| 6 | Owner (seat) | One seat with an analytics-and-automation transformation track. The method (gate, grades, ladder exit evidence) is held by the seat that owns placement, not by the program |
| 7 | First 90 days | Three items: choose the book (the room's decision); populate its ledgers from the platforms' exports; run the daily clock with the gate on and publish the first catch rate |
| 8 | Dependencies | The definitions register; the first-wave L2 tables for the steps the agents run; a file interface to the short-term WFM engine or the standard instance's adapter |
| 9 | Decision needed | Which book carries the pilot. Rules carried and not voted: the planner gate stays on; the program is judged on detection and catch rate, never on headcount |
| 10 | Measures | Days-to-detection of a level shift; catch rate per process per period (proportion, injection rate, n); register questions answered as graded cards inside two business days; carried assumptions labeled (all) |
| 11 | Risks | Judged on hours freed before detection; a book with two definitions of one metric; vocabulary adopted without practice change |
| 12 | Lanes | The roadmap lanes the program delivers into; the definitions lane is its entry condition |
| 13 | Arc | Arc 1 as assistants (Level 2 to 3); Arc 2 as the automation layer on the function's own work (Level 3 to 4) |

## The two rules the charter carries

1. **The planner gate stays on.** At every rung a named person signs anything that changes a plan, and the gate is enforced in the file format: an unsigned version is not loaded. A gate that asks for a click is not a gate; the gate request asks the planner to confirm or amend each changed assumption.
2. **Judged on detection and catch rate, never on headcount.** The program produces evidence about what a team covers; what the function does with freed planner-hours is a placement decision made later on that evidence. The charter carries no headcount number, no seat count and no transition chart.

## The founding claim, and how to write it

Sponsors usually state the program's value as a large multiple on planner-hours. Write it on the register at grade Asserted, name the planner-hour log as the observation that would move it, and do not carry it as a benefit in any business case until the log has run before and after. What the program can state once the first rung is exited is narrower: the team runs every step of the L2 table every day, and the daily note's grade profile moved from one share of [M] figures to another.

## Choosing the book (the room's decision)

| Option | Argument for | Argument against |
|---|---|---|
| A clean book already on the short-term WFM engine with one definition per metric | The team's second design principle is met on day one; the pilot is judged on the team, not on the book | The book may be too quiet to produce a level shift to detect inside the first quarter |
| The migrating book | The migration produces the level shifts, the carried figures and the two-definitions cases the team exists to catch; a prior run may already exist | Every figure carried across the platform change is [A]; the team inherits the migration's problems as its baseline; the pilot can be blamed for the migration |

Record the choice with its reason and its risk on the decision record. Whichever book is chosen, the second book's clone is the program's real test.

## Worked example row (illustrative; the example's dates, not a recommendation)

| ID | Program | Objective | Scope in | Scope out | Owner (seat) | First 90 days | Dependencies | Decision needed | Measures | Risks | Lanes | Arc |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PG-007 | Agent teams for the planning function's own work | run the three rosters on one real book with a gate at every transition that changes a plan, and clone onto a second | one book on three clocks; the intake door; the ledgers; file adapters; the ladder cards | more than two books; replacing the planner at any rung; any action on the intraday automation platform | the planning director seat with the analytics-and-automation track; method held by the placement seat | set the next rung per roster; run the clone checklist on the second book; publish a catch rate per roster | the definitions register; first-wave L2 tables; a file interface | D-13 (the second book, and the next rung per roster) | days-to-detection; catch rate (proportion, injection rate, n); cards inside two business days | judged on headcount; a book with two definitions of one metric; vocabulary without practice | L-001, L-002 | Arc 1 |

Accepted Thu 23 Apr 2026 in the example's planning week, around work already running; first ninety days to Tue 30 Jun 2026. The three ladder cards on the first book are already open at that point — the planning loop at pilot, scheduling and real time at beta — and the week sets the next rung for each and the clone onto a second book. The dates are the example's and are illustrative.

## What this block does not do

It does not design the team (see the AI Agent Teams series on the wiki), does not size an overseer (sized by exceptions and stakes per the overseer page, re-set each cycle), and does not produce a business case; the economics are reported in the wiki's ordinary automation-economics form with the scaffolding and the overseer's time on the cost side.

Block 3 — readiness-four-questions.md

<!-- Derived from [[Agent Team Readiness for a Planning Process]] and [[The Agent Team Ladder: Alpha to Production]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The Readiness Check: Four Questions, Per Process and Per Book

Run this on one process (the short-term loop, the monthly cycle, the schedule check, the real-time watch) on one book, in about an hour, with the planner who owns the process and the book's ledgers open. It is the entry condition for alpha and is re-run on every book a team is cloned onto. A function is not ready; a process on a book is.

## The four questions

| # | Question | Passes when | Fails when | Next fix if it fails |
|---|---|---|---|---|
| 1 | **Definitions.** Is every metric the process reads or writes a record in the definitions register, with formula, source system and owner? | Every column in the process's inputs and outputs cites a record; no two records share one name | A column called AHT with no record; two definitions of one metric in circulation; a report and a platform that disagree by a definition | Open the register entries; retire the duplicate; reject the column at load until it cites a record |
| 2 | **Process.** Is the process documented to L0–L3, with an L2 step table whose tools column names the systems each step touches? | An L0 with an owner; an L1 flow; an L2 table with owner, tools, duration and approval per step; L3 job aids named | The process lives in one analyst's spreadsheet; the "step table" is a checklist without owners or tools | Fill the L0 as a shell with a "skeleton until" date; run the process by hand for one cycle and log every deviation; the deviations are the real table |
| 3 | **Cycle.** Does the process run on a stated clock with a calendar that says what is due when and what waits for what? | A daily, weekly or monthly clock with business-day offsets; the process's place on it written | The process runs "when the data arrives" or "when finance asks"; no one can say what yesterday's run consisted of | Put the process on the function's one calendar; write the offsets; name the owner of the clock |
| 4 | **Register.** Is there a register with an intake discipline where the questions the process raises are opened, graded and filed? | A register with permanent IDs, a hypothesis table and graded findings; someone owns it | Questions answered in email from memory; the same question answered twice in a month with different numbers | Open the register with its first row before the team's first run; name its owner |

Record each answer as pass or fail with the evidence looked at, and a next fix with an owner and a date for every fail.

## What the result means

| Result | Meaning for the ladder |
|---|---|
| All four pass | The process on this book may enter alpha. Proceed to the ladder card |
| 1 and 2 pass; 3 or 4 fail | An assistant may help the planner run it; the planner is the clock and the register. Not a team |
| 1 fails | Nothing else is evaluated. A definition cannot be reconstructed after the first bad plan; fix it first |
| 2 fails | The team would run the specification's author's assumptions. The permission map is read from the L2 tools column and nothing beyond it |

## Cross-walk (so the check is not a second gate)

| Question | Function-level standardization it applies per process | Handover-gate test it feeds |
|---|---|---|
| 1 Definitions | data definitions | test 1 (documented) needs it |
| 2 Process | process documentation | test 1 (documented) |
| 3 Cycle | interfaces with owners and cadences; the clocks | — |
| 4 Register | an owned objective register (sibling) | — |

## Per-book re-run for a clone

Before a clone enters alpha on a second book, ask the four questions again with the second book's ledgers open. Two answers change most often: question 1, because a second book's definitions are its own and a record with the same name and a different formula is a different definition; and question 4, because the second book's register starts empty. A clone that does not pass question 1 is not a defect; it is the program's most useful output, because it names the next definitions the register needs. Record the failure on the clone checklist and on the decision record as a validation item with an owner.

## How functions fool themselves (check these before recording a pass)

- The definitions exist in a glossary no column cites. Question 1 asks whether the columns cite records. Reject a column without a record and see what breaks.
- The L2 table was written for an audit, not the work. Run it by hand for one cycle; log every deviation.
- The cycle is a calendar of meetings. A meeting takes a decision; a cycle produces the pack the meeting reads.
- The register is an issue log. An issue log holds things being resolved; a question register holds things being answered, with a hypothesis table.
- Readiness is claimed for the function. It is per process and per book.

## Worked example (the chain's example; illustrative)

Short-term voice reforecast, migrating corporate client book, checked in February 2026 before the Mon 2 Mar go-live. Q1: a narrow fail; contacts per transaction had two records, CPT-01 and CPT-02, cleared when the owner retired CPT-02 the following week. Q2: L0 and L1 exist; three blank cells in the L2 tools column filled in an afternoon; pass. Q3: daily at 07:00, note by 09:00, load by 10:00, on a calendar; pass. Q4: an issue log and no question register; fail; the register opened with Q-001 on Mon 23 Feb. Declared ready Mon 2 Mar. The monthly cycle passed all four; the intraday reforecast did not pass Q2 and stayed with an assistant. The check is re-run per book: when the team is cloned onto a second book, the four questions are asked again with that book's ledgers open, before its card is opened at alpha.

Block 4 — ladder-and-exit-evidence.md

<!-- Derived from [[The Agent Team Ladder: Alpha to Production]], [[The Agentic Handover Gate]] and [[Human Gates and Number Grades]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The Ladder Card and Exit Evidence

One card per **team per book**; one row per rung that team on that book has entered. A rung is exited when its exit evidence is recorded on the row and the named signers have signed. Elapsed time exits nothing; a demonstration exits nothing.

A program's three rosters run different clocks and earn different evidence, so they will normally sit on different rungs at the same moment. A later card may open before an earlier card's exit evidence is complete. When it does, the opening is **not deferred**: the acceptance is written on the card with its price, in the form "for <period>, <what was relied on> rested on <what was incomplete>."

## Card columns (template AL), in order

| # | Column | Rule |
|---|---|---|
| 1 | ID | `AL-nnn`, permanent; one card per team per book |
| 2 | Book | The book of business, named as the profile ledger names it |
| 3 | Team | planning loop · scheduling · real time |
| 4 | Rung | alpha · beta · pilot · production (production rows name the class of action) |
| 5 | Entered | Date the rung's entry conditions were recorded; where the rung opened early, the recorded acceptance sits in this cell |
| 6 | Exit evidence required | Copied from the rung table below at entry, so the exit is known before the rung starts |
| 7 | Exit evidence observed | Filled as evidence lands, each item with its grade and its ledger reference; `open` with an owner until then |
| 8 | Catch rate (proportion, injection rate, n) | Per process per period; never a proportion alone |
| 9 | Days-to-detection | Business days from the first day a level shift is present in the data to the day the output names it; `open` until one exists |
| 10 | Clone source | The card this book was cloned from, or `none`; what was carried is listed on the clone checklist |

Grades follow the measuring source. A figure measured on **this** book keeps the grade the measuring page or ledger published it at, including when it was measured before the card was opened. A figure carried from another book, from another channel, platform or cohort, or from a prototype is [A] on the card it arrives on.

## The four rungs

| Rung | What the team does | Entry condition | Exit evidence required | Who signs the exit |
|---|---|---|---|---|
| **Alpha** (shadow) | Runs its clock beside the planner; writes every ledger; publishes nothing; the planner's output stays the version of record | Readiness check passed for this process on this book; every ledger column cites a definition; an owner for every agent | 20 consecutive runs completing every step with no unexplained block; the team's output reconciled against the planner's each time; every carried assumption labeled; zero ungraded cells at load | The planner who owns the book; the program owner |
| **Beta** (gated) | The gate for this clock is on; the team's proposal is the version a person confirms or amends; the version of record is the team's; the overseer runs error injection and sampled deep verification | Alpha exited; overseer named; injection rate and sample size published before the first injected error | A first catch rate with injection rate and n; 30 consecutive runs with the gate exercised on each; the grade profile measured against the planner-hour log baseline | The person at the gate and the overseer; recorded by the program owner |
| **Pilot** (the whole clock) | The clock runs end to end on one real book as the version of record, including the long-cycle steps the earlier rungs only sampled; the clone onto a second book is run | Beta exited, **or** opened with a recorded acceptance; the clone checklist run on the second book | A record traceable to a real catch (a stale forecast version, an unmatched event, a contract-rule breach); the long-cycle step run once under its own gate; the second book's alpha exited on its own definitions with no carried benchmark | The seat that owns the clock, with the overseer |
| **Production** (released, by class) | For one named class of action the format no longer requires a signature, and the overseer's sampling replaces the approver for that class only | Pilot exited; the class named; its catch rate published for it, per the release condition; the format change versioned; a reversal condition and a re-verification date logged | Continued catch rate per period; reversal never silently skipped; re-verification date met | The seat that holds the method, on the overseer's evidence |

## Rules that decide hard cases

- **Production is per class of action, never per team.** "The reforecast proposal on unchanged assumptions" is a class; "the forecasting team" is not. One team may hold a released class and a gated class at the same time.
- **The release condition is evidence, not a level.** A catch rate published for the class releases the gate. This is stated once on [[Human Gates and Number Grades]]; the wiki's level pages agree with it. Never restate it as a rule of this pack, and never state a level.
- **A stricter entry condition is the function's, and is labeled so.** A function that wants the catch rate held for a second period before the signature goes records that on the card as its own condition. It is never presented as the release condition.
- **A card may open early; the acceptance is written down.** Never hold a roster back to tidy a sequence. Record what was relied on, what was incomplete, and for how long.
- **The person at the gate stays practiced.** At beta the signer amends assumptions; at pilot the signer signs the long-cycle output; at production the signer signs everything outside the released class.
- **A blocked run is not a failure; an unexplained one is.** The coordinator's run log names the blocking check; a run blocked by the evaluator for an unlabeled carried assumption is the system working.
- **A reversal is a return to the previous rung's format**, recorded on the card with its reason. The card never loses a row.
- **Durations are ranges with assumptions, never promises.** Alpha on a book with clean definitions: about one month [estimated]; on a book with two definitions of one metric, the month goes to the register instead, which is correct.

## Reconciling the rungs to the handover gate's five tests

| Test | Where the ladder produces its evidence |
|---|---|
| 1 Documented | Alpha entry: the readiness check reads the L2 table; the permission map is its tools column |
| 2 Instrumented | Alpha: every objective the process serves has a graded column; a blank with an owner is the honest state of an objective with no instrument |
| 3 Measured here | Beta: the catch rate is measured on this book's work with this book's definitions; anything carried from another channel, platform, cohort or book is [A] |
| 4 Overseen first | Beta then pilot: error injection and sampled verification run through beta; each team publishes a catch rate for its own clock before its pilot card closes |
| 5 Reversible and logged | Production: a versioned format change with a reversal condition and a re-verification date |

The five outcomes of the placement check, which the handover gate applies, apply at every rung exit too: pass · fail · fail unless a stated price is paid · pass until a stated date · cannot run. The ladder borrows them and defines none of its own. An exit that cannot be tested is recorded as *cannot run*, naming the definitional or data gap that stopped it.

## Worked example cards (the chain's example; the dates are illustrative)

| ID | Book | Team | Rung | Entered | Exit evidence required | Exit evidence observed | Catch rate (proportion, injection rate, n) | Days-to-detection | Clone source |
|---|---|---|---|---|---|---|---|---|---|
| AL-001 | the migrating corporate client book | planning loop | beta | Mon 2 Mar 2026 | first catch rate with n; 30 gated runs; grade profile vs the February log | 25 gated runs to Fri 3 Apr with a first catch rate published; thirtieth run Fri 10 Apr 2026 | 9 of 10 (6 injected, 4 by deep verification of a 5 percent sample) [C from the overseer's log] | open | none |
| AL-001 | the migrating corporate client book | planning loop | pilot | Fri 27 Mar 2026 — accepted early: for two weeks a plan of record was signed on a loop whose catch rate was one period old | long-cycle step under its own gate with a decline priced; a record traceable to a real catch; the clone run on the second book | phase 2 plan of record signed Fri 27 Mar, one move declined and priced; clone open | as above | open | none |
| AL-002 | the migrating corporate client book | scheduling | beta | Thu 26 Mar 2026 | first catch rate for the checker with n; 30 gated checks | a check record catching a schedule built on a superseded forecast version | open | open | none |
| AL-003 | the migrating corporate client book | real time | beta | Wed 8 Apr 2026 | first catch rate on the detector's severities with n; an outcome record per gate request | first incident issued under the action gate; proposal carried, not executed | open | open | none |
| AL-004 | the second book | planning loop | alpha | inside the front-load closing Tue 30 Jun 2026 | as AL-001 alpha; the readiness check re-run on this book; its own baseline measured here [M] | open; carried-benchmark test at its own migration window, Mon 14 Sep 2026 | open | open | AL-001 |

No card is at production. The first production candidate is named and left undated: the reforecast proposal on unchanged assumptions, whose release waits on its own published catch rate.

Block 5 — clone-checklist.md

<!-- Derived from [[The Agent Team Ladder: Alpha to Production]] and [[Living Ledgers]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The Clone Checklist

A clone is the same team started on a second book, on a new card of its own. Run this before that card is opened at alpha. The checklist has three parts: what is carried, what is never carried, and what is re-run. A clone that does not pass is not a program that has gone wrong; a book that cannot be cloned onto is a book whose definitions are not in the register, and the failure names the next definitions the register needs.

## Part 1: carried (copy, then confirm each line)

| # | Item | Confirm |
|---|---|---|
| 1.1 | Every agent's identity and rules, unchanged, with the second book's owner named per agent | |
| 1.2 | The coordinator's clock order: daily, weekly, monthly, the intake door | |
| 1.3 | The evaluator's rules: no unlabeled carried assumption; every number graded; no rung-1 finding written as cause; every definition cited; the decomposition sums to the miss | |
| 1.4 | The ledger schemas and their header conventions (the definitions block each ledger cites) | |
| 1.5 | The grade rules ([M][C][E][A]; a computed figure inherits its weakest input; carried is [A]) | |
| 1.6 | The signature block format on the forecast version, the plan, the schedule, the card and the action proposal | |
| 1.7 | The intake door's fields and routes; the answer-card format | |
| 1.8 | Every gate on: planner gate, register review, plan signature, publication gate, action gate | |
| 1.9 | The adapters' mapping-file format and rejection log, with the second book's own mappings to be filled | |
| 1.10 | The overseer's method: injection rate and sample size to be published before the first injected error on this book | |

## Part 2: never carried (confirm each is absent from the second book's ledgers)

| # | Item | Why | Confirm absent |
|---|---|---|---|
| 2.1 | The first book's definitions | A record with the same name and a different formula is a different definition; the second book's columns cite its own register entries | |
| 2.2 | The first book's benchmarks: shrinkage, occupancy, contacts per transaction, handle-time baselines | Anything carried from another book is [A] on this one; the card says so if it is used at all | |
| 2.3 | The first book's events and effect windows | The intelligence ledger starts empty; the scout proposes this book's own events; a go-live window from the first book explains nothing here | |
| 2.4 | The first book's open register rows, hypothesis tables and cards | Questions are per book; a structural tag on the first book's driver is a hypothesis on the second, not a finding | |
| 2.5 | The first book's forecast versions and assumption registers | The second book's first version is proposed from its own demand ledger; its assumption register starts with its own rows | |
| 2.6 | The first book's ladder position, catch rate and days-to-detection | The clone enters at alpha; its catch rate is measured on this book | |
| 2.7 | The first book's planner-hour log and grade-profile baseline | The second book's planner logs two weeks before the clone's alpha begins | |

## Part 3: re-run on the second book

| # | Step | Owner | Done |
|---|---|---|---|
| 3.1 | The readiness check, four questions, with the second book's ledgers open | the planner who owns the book | |
| 3.2 | The definitions audit: every column in the second book's ledgers cites a register entry | the data engineer, with the register owner | |
| 3.3 | The profile ledger filled: channels, service targets, sites and delivery arrangements, the phase and event calendar | the librarian, on the planner's instruction | |
| 3.4 | The planner-hour log, two weeks, before alpha | the planner | |
| 3.5 | A new card `AL-nnn` opened at alpha for this team on this book, clone source named | the program owner | |
| 3.6 | The carried-benchmark test scheduled: the date on which this book's own baseline would be contradicted by a carried figure if one had leaked (a go-live, a migration phase, a season) | the program owner | |

## The carried-benchmark test

The clone's first real test is an event on the second book that a carried baseline would misread. A migration window is the usual one: a clone that inherited the first book's post-go-live handle time as its baseline would report the second book's go-live as normal. Schedule the test in 3.6; when it arrives, the note must name the shift from this book's own baseline [M], and the card records the day it did.

## How clones guide consolidation

Report, book by book, the outcome of Part 3.2. A book whose columns cannot cite the register cannot be cloned onto; list the definitions it lacks and hand the list to the definitions register's owner as validation items with dates. Over a dozen books this list is the function's consolidation order, produced by the program's mechanics rather than chosen by anyone. Do not choose which books to standardize; report which ones cannot yet be run on the standard.

## Worked example (illustrative)

The chain's example runs the clone from the pilot rung of `AL-001`, the planning-loop team's card on the first book, inside the front-load closing Tue 30 Jun 2026. Part 2 confirms the first book's 452-second handle-time baseline [M] is absent from the second book's ledgers; the second book's own baseline is measured on that book [M]. Part 3.6 schedules the carried-benchmark test for the second book's own migration window, Mon 14 Sep 2026. Card `AL-004` opens alpha with clone source `AL-001`. The dates are the example's and are illustrative.

Block 6 — measures-catch-rate-detection.md

<!-- Derived from [[AI Agent Program for a Resource Optimization Center]], [[The Agent Overseer]] and [[A Roadmap Pattern for Agent Teams in WFM]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The Measures Sheet: Catch Rate, Days-to-Detection, the Planner-Hour Log

The program is judged on two measures and instrumented by two more. None is headcount, and none is hours saved. The sheet is one row per process per period; the two instruments have their own small tables.

## 1. Catch rate

**Definition.** The proportion of known errors in a process's output that the routine verification step detects, where the known errors are those seeded by deliberate error injection plus those found by independent deep verification of a random sample. Reported per process per period, always with the injection rate and the sample size beside it.

| Field | Rule |
|---|---|
| Process | One process (the reforecast proposal, the plan draft, the schedule check, the incident issue) |
| Period | The reporting period; monthly is usual |
| Known errors (n) | Injected + found by deep verification of the sample |
| Detected | Of the known errors, those the routine verification step caught |
| Catch rate | Detected ÷ known errors, as a proportion [C] |
| Injection rate | Injected errors as a share of runs in the period; published before the first injection |
| Sample | Size and selection rule of the deep-verification sample |
| Grade | [C] from the overseer's log; never [E] |

Rules: publish the injection rate and sample size before the first injected error; a catch rate without them is not reported. The body term is "error injection", never "planted errors". A catch rate from another book, a prototype or a prior run is [A] on this card. The catch rate is the evidence that exits beta and that releases a class of action at production; it is measured by the overseer, who is sized by exceptions and stakes, not by agent count.

## 2. Days-to-detection

**Definition.** Business days from the first day a level shift is present in the data to the day the daily note names it as a shift (not as a single-point excursion). Computed [C] from the demand or supply ledger and the notes; the onset day is the later-confirmed onset, which may itself move as evidence lands.

| Field | Rule |
|---|---|
| Shift | What moved: handle time, offered contacts, productive hours, contacts per transaction |
| Cohort or channel | Where it moved |
| Onset (data) | First day present in the data, as later confirmed; grade it |
| Named (note) | The day the note called it a shift |
| Days-to-detection | Business days between, [C] |
| Rule that fired | The control-chart rule (single point beyond limits; a run of points beyond a lower threshold; a trend) |
| Confirmed by | The register row or event that confirmed it, if any |

Rules: a shift the note called on the second day and confirmed on the third is recorded at the day it was called, with the confirmation noted. Detection depends on the rules and the data, not on the checking; a good catch rate does not make detection fast, and the two are reported separately. Where no shift has occurred in the period, the row is a blank with an owner, never a zero. A prototype's day-2 or day-3 detection on synthetic data with a recorded answer key is an illustration of the mechanism, [A] on any real sheet.

## 3. The planner-hour log (instrument; run before the program plans on anything)

For one process, each planner logs for two weeks: minutes per day on each step of the L2 table; which steps were skipped when time ran short; which figures in the output were carried rather than measured.

| Result | How it is read |
|---|---|
| Coverage | The share of the L2 table's steps run on a typical day [C]; usually below what the function believed |
| Grade profile | The share of figures in the output that are [M] rather than [A] [C] |
| Hours by step | Minutes per step per day [M from the log] |

The team's first claim is not "it saves N hours" but "it runs every step every day and the output's grade profile moved from this to that", which the ledgers can score. The hours claim comes after, from the same log repeated with the team running. A function that skips the log will credit the team with hours it never freed and blame it for a coverage gap it inherited.

## 4. The grade profile (instrument; per period)

The share of figures in the daily note, the plan and the cards that are [M], [C], [E] and [A]. Reported against the planner-hour log's baseline. Movement from [A] to [M] is the program's cleanest early evidence; movement toward [E] with ranges stated is also progress on a book whose figures were previously asserted points.

## What the sheet refuses

- A headcount number or an hours-saved figure as a measure of the program.
- A catch rate without its denominator, or a proportion stated to more precision than n supports.
- A days-to-detection figure for a shift that was matched to a known event (that is an event match, not a detection).
- Any figure carried from a prototype or another book as anything but [A].

## Worked example rows (the chain's example; illustrative)

| Process | Period | Known errors (n) | Detected | Catch rate | Injection rate | Sample | Grade |
|---|---|---|---|---|---|---|---|
| Reforecast proposal, migrating book | Mon 2 Mar – Fri 3 Apr 2026 | 10 (6 injected, 4 found by deep verification) | 9 | 0.9 [C from the overseer's log] | 6 in 25 runs | 5 percent of runs, random | measured on this book; keeps its published grade on AL-001 |

Grade profile of the daily note over the same period: from 40 percent [M] to 85 percent [M] [C from the log]. Planner-hour log, February 2026: the reforecast's L2 steps run in full on 6 of 10 days, with the handle-time assumption carried on every one of them. Days-to-detection: blank with the planner as owner until the second book's migration window, Mon 14 Sep 2026, produces the first shift the program can date on its own card.

Usage notes

Sizing. The instruction block is about 490 words and loads with every message; the five reference files total about 4,200 words and are retrieved as needed. One book's ladder card, its readiness checks and its measures fit comfortably in a session; a program running several books keeps one session per book, because the cards must never share rows.

The card is the master. A Claude project holds no state between conversations. The ladder card, the clone checklist and the measures sheet live in files the program office keeps, in the workspace's ledger convention, and are supplied at the start of every session; the session ends by emitting the updated card in full.

Evidence, not time. The pack refuses to exit a rung whose exit evidence is not on the card, and refuses a production release for a team rather than for a named class of action. These refusals are the pack's purpose and are written to hold even when the user is in a hurry.

Grades. Every figure carries [M], [C], [E] or [A]; every estimate carries a range and its assumption; a number the session does not have is a blank with an owner. Anything carried from a prototype, a prior run or another book is [A] on the card until this book measures it.

Drift. The blocks derive from the five source articles in the infobox. A material change to any of them, and in particular to the release condition stated on Human Gates and Number Grades or the catch-rate definition on The Agent Overseer, is the trigger to regenerate the affected block and bump the version.

Scope. Nothing in the pack is specific to any organization. Seats, books, dates and the platforms' names are filled in the session's files, never in the blocks; platforms are referred to by category (the short-term WFM engine, the long-term capacity engine, intraday automation).

Change history

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

See also

• Planning Week for a Workforce Function — the week whose Day 4 morning block this pack serves
• Wiki:Packs — inventory and how packs work
• Wiki:Packs/Charter and Program Launch — CP-WFM-012, the other six program charters and the function charter
• Wiki:Packs/Process Decomposition — CP-OPS-001, the L2 tables the readiness check's second question reads
• Wiki:Packs/Executive Issue Register — CP-OPS-002, the register the program's founding claim is entered on