Wiki:Packs/Data Definitions and Source of Truth

A deployable Claude project setup for producing the data discipline beneath a workforce capacity model: for any number a function brings, a metric, a model input or a report figure, the pack finds or drafts its definition card (RG-), names the one source-of-truth row it is taken from (ST-), places it on the time ledger, names the reconciliation tests (T-01 to T-06) it must pass and the grade it may carry until it does, and records which lineage cards (LN-) consume it. The reference blocks carry the card and row templates, the ledger, the asynchronous and concurrent workload models and the test suite of the Workforce Data Definitions Framework, condensed for a model to read; the registers themselves are the function's, and the pack fills rows in them rather than keeping a parallel register. Copy Block 1 into a project's custom instructions; save Blocks 2–6 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function has to say, for each number its capacity model consumes, what the number means, where it is taken from, which minute of the ledger it reads and what test it has passed: when a register is being drafted from v0, when a report figure and a model input disagree, when an asynchronous or chat channel is being brought onto the same model as voice, or when a change to a definition or a source has to be traced to every plan it moves. It is not for running the capture-point audit or the standards workshop, which Wiki:Packs/Time and Production Accounting Audit (CP-WFM-024) carries, not for the requirement arithmetic itself, which stays on the channel method pages, and not for deciding what a definition should be, which is the signatories' act through GP-606. It pairs with CP-WFM-024: the audit finds the capture points and the gaps; this pack writes the cards, rows, ledger placements and tests the gaps resolve into. Where the function is in a planning week, it serves the register v0 drafted on Day 3 afternoon by The Definitions Register and extends it.

How to deploy

1. Create a project in Claude named for the function's registers, not the method: "Capacity model data definitions — <function>", not "Pack 023".
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload it as project knowledge; add the function's current RG and ST registers, if any exist, as further files so the pack extends rather than re-numbers them.
4. Start a conversation with one number: its name as the function uses it, where it appears, the channel, and what the user knows of the system it comes from; one number, or one model's input list, per conversation.

Block 1 — Project instructions

You are producing the data discipline beneath a workforce capacity model
for the user's function. For any number the user brings (a metric, a model
input, a report figure) you find or draft its definition card, name its
source-of-truth row, place it on the time ledger, and name the tests it
must pass and the grade it can carry until it does. The reference files hold the templates, rules and cluster ids; the registers
(RG-, ST-, LN-) are the function's own: fill rows in them, never a parallel
register.

Routing:

| Task | File |
|---|---|
| Find or draft a definition card (RG- code, formula, unit, instrument class, validation rule, lineage) | `definition-card.md` |
| Name the ST- row and its source grade; write an LN- card; run the gate and the quarantine | `source-of-truth-register.md` |
| Place a number on the ledger: tier, bucket, primary system; SHR-01, OCC-01, AHT-01, AHT-02 as tier ratios | `time-ledger.md` |
| Asynchronous or concurrent work: AHT-02, the five instruments and their biases, chat focus time, CCY-01 | `async-workload-model.md` |
| Tests T-01 to T-06, their cadence, the grade a failure leaves | `reconciliation-tests.md` |

For each number, in this order:

1. Find or draft its definition card from `definition-card.md`: RG- code,
   formula, unit, instrument and instrument class, validation rule, lineage.
2. Name its source-of-truth row from `source-of-truth-register.md`: ST- code,
   system of record, the one instance, extraction path SET LOCALLY, refresh,
   owner seat, source grade.
3. Place it on the time ledger of `time-ledger.md`: the tier and bucket it
   reads. For asynchronous work apply `async-workload-model.md`: AHT-02 is
   the count and the time, Σ touches, elapsed ≠ handling.
4. Name the tests from `reconciliation-tests.md` the number must pass
   (T-01 to T-06) and the grade it can carry until it passes.
5. Emit `definition-cards.md`, `source-rows.md`, `ledger-map.md` and
   `tests-to-run.md`.

Disciplines:
- One definition, one code; split a code only when the unit or the
  instrument class changes.
- One source per metric; conflicts published with their test, never
  averaged.
- An [A] with no range cannot carry a plan; no grade exceeds what the
  source grade permits.
- Never fill an extraction path, tolerance or plausibility range the user
  has not given: SET LOCALLY, with the seat.
- Never name a product in anything marked for publication.
- A definition or source change goes through GP-606, forward only.
- Seats, never names. Every number carries a grade.
- Elapsed time is never handling time; a concurrency limit is never a
  measured concurrency.

Output: the four Markdown files, each headed with function, register
version and date, plus a findings section: every unresolved
SET LOCALLY with its seat, every quarantined number and the check it failed,
every source conflict, every card with an empty source or lineage field.
Refuse to draft a card for a number the user has not described, to assign a
grade the source grade does not permit, or to publish a file that names a
platform.

Source: Wiki:Packs/Data Definitions and Source of Truth (CP-WFM-023) v1.0

Block 2 — definition-card.md

<!-- Derived from [[The Data Definition Card]] (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 Data Definition Card

The full form of a definitions register entry: the ten fields of the RG row
(id, definition, instrument, resolution, pairing, owner, signatories, version
and effective date, carry rule, change history) extended with the formula,
the unit, the instrument class, the source row, the validation rule and the
lineage. The register (`RG-nnn`) stays the index; the card is the entry in
full. Both change only through GP-606, forward only.

## 1. Fields

| Field | Holds | Rule |
|---|---|---|
| Id | the metric code and version (`AHT-02 v1`), the RG number beside it | never reused; a changed definition is a new version |
| Name | the metric, qualified by channel where the channel changes the definition | handle time on voice and handling time on an asynchronous channel are two cards: the unit and the instrument class differ |
| Definition | one plain sentence | the sentence leads; the formula follows |
| Formula | numerator, denominator and summation, every term named | every term is itself a card or a ledger bucket (`time-ledger.md`) |
| Unit | what one of the number is: seconds per handled contact, minutes per item fulfilled, percent of logged-in time | a number without a unit cannot be rolled up |
| Instrument | carried from the register: the system, the field, the instrument's version | unchanged |
| Instrument class | platform state timer · work-item timer · desktop focus-time instrument · time-and-motion sample · statistical inference | a class, never a product; the biases per class are in `async-workload-model.md` |
| Resolution | per contact, per touch, per interval, per cohort | a comparison below resolution is noise, reported as a finding |
| Source | the one ST row the number is taken from | exactly one; the card's grade ceiling is the row's source grade |
| Validation rule | the test (T-01 to T-06) the number must pass, and the plausibility range outside which a value is quarantined | range SET LOCALLY; a card with no validation rule has no way to fail |
| Lineage | the LN cards that consume the metric | derived; the list GP-606 reads to find what a change moves |
| Pairing | what the number must be read beside | carried from the register |
| Owner | the seat that answers questions about the card | a seat, never a name |
| Signatories | the seats that adopted it, jointly | a card signed by one seat is a private definition |
| Version and effective date | which version applies from when | forward only; previous versions kept |
| Carry rule | whether the number survives a channel, platform or cohort change | [A] in the new state until re-measured |
| Change history | every proposal, review and adoption | shared in form with the registers |

## 2. The core codes and when a code is split

The register's six core definitions, each with an RG number in the
register's own sequence: `OCC-01` occupancy · `AHT-01` handle time · `SHR-01`
shrinkage · `CON-01` contact · `ATT-01` attrition · `RMP-01` ramp. The code
with a version is what a report, a model or a ledger cites.

`AHT-01` states its formula "by channel" and is not split per channel.
`AHT-02` (`RG-008`), handling time on an asynchronous channel, is split out
because the split is in the unit and the instrument class, not in the
formula's terms: seconds per handled contact read from a state timer, against
minutes per item fulfilled summed over touches read from a work-item timer.
One code carries one unit. Split a code when the unit or the instrument class
changes; never when only the channel label does.

## 3. The triangle: card, ST row, LN card

Each cites the other two.

- The card's source field cites one ST row; the ST row's metric field cites
  one card; the LN card's inputs cite both.
- A change to any corner is traced to the other two in one step, which is why
  the three share one change control (GP-606) and one set of signatories.
- A card with an empty source field is a definition without a number: carried
  at grade Open with an owner and a date, as the register carries ramp.
- A card with an empty lineage field is a number nobody uses: a finding for
  the audit (GP-605), not a defect in the card.

## 4. Why the instrument class is the field that matters

On voice the instrument is the telephony platform's state timer, and the
definition and the instrument agree without effort. On email and case work
there is typically no in-work state: the item has an open time and a close
time, the agent's time is spread across touches separated by pends, and the
work is often done inside a voice available or auxiliary state, where it
appears on the ledger as idle. The register's instrument field ("the case
tool's work-item record") reads as if an instrument exists. The instrument
class forces the question: a timer on the touch, a focus-time instrument on
the desktop, a sample, or an inference? Each answers to a different source
grade and bias. On chat the instrument must separate session elapsed time
from agent focus time, or the card defines a number that doubles under
concurrency.

Drafting rule: for an asynchronous or concurrent number, never accept the
instrument field as proof that an instrument exists. Ask which class; grade
accordingly; name T-05 as the validation rule and T-06 beside it on any
blended seat.

## 5. Filled example (synthetic, graded [E])

| Field | Value |
|---|---|
| Id | `AHT-02 v0` (RG-008) |
| Name | Handling time, asynchronous channel (email and case) |
| Definition | The agent work time spent on one item from first open to close, summed across touches, excluding the time the item waits in queue or pends between touches |
| Formula | HT_item = Σ touch duration_k over the item's touches; elapsed time (close − arrive) held as a second field, never blended |
| Unit | Minutes per item fulfilled |
| Instrument | The case tool's work-item record, touch-timer field, instrument version stated at adoption; until then, the time-and-motion sample's handling-time field |
| Instrument class | Work-item timer, reconciled to a time-and-motion sample; until the timer exists, the sample alone |
| Resolution | Per touch; per item; per interval by close time; per cohort and tenure band |
| Source | `ST-007` (v0: the sample, source grade named owner; v1 target: the timer with the sample, system of record) |
| Validation rule | T-05 item-count against time: items closed × handling time per item against in-work time for the channel, ratio within tolerance of 1.0, two-sided, tolerance SET LOCALLY; a value outside the plausibility range (SET LOCALLY) is quarantined |
| Lineage | `LN-004` email requirement and backlog; through it, `LN-003` multichannel requirement |
| Pairing | Read with items closed and backlog age; never beside voice handle time as one blended figure |
| Owner | The definitions owner (a seat) |
| Signatories | The forecasting lead for asynchronous channels and the data and analytics lead, jointly |
| Version · effective | v0 · Thu 16 Oct 2026 (proposed); v1 target at the timer's adoption |
| Carry rule | [A] in any new case tool, channel or cohort state until re-measured |
| Change history | v0 drafted Thu 16 Oct 2026; adoption pending the signatories' review slot |

What the card refuses: elapsed time as handling time (the commonest
substitution on an asynchronous channel; it overstates the requirement by the
pending time); an undeclared instrument (the sample is named as the standing
source until the timer is adopted, so every figure computed on it is [E] with
the sample's range); and work done inside a voice state going unseen (T-05 is
the validation rule, so the contamination is a test failure rather than an
invisible inflation of availability).

## 6. Blank template (one per number; emit into `definition-cards.md`)

```
Id: <CODE-nn vN> (RG-nnn)
Name:
Definition:
Formula:
Unit:
Instrument:
Instrument class:
Resolution:
Source: ST-nnn (source grade: system of record | named owner | implied | unattributed)
Validation rule: T-0n; plausibility range SET LOCALLY — <seat>
Lineage: LN-nnn, ...
Pairing:
Owner: <seat>
Signatories: <seats, jointly>
Version · effective: vN · <date> (proposed | adopted)
Carry rule: [A] in any new channel, platform or cohort state until re-measured
Change history:
```

A field the user cannot fill is left blank with the seat that will fill it,
never guessed and never set to a default.

Block 3 — time-ledger.md

<!-- Derived from [[Agent Time Accounting Model]] and [[Agent State Taxonomy and Activity Codes]] (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 Time Ledger

The ledger in which a function accounts for every paid minute of its agents:
six nested tiers from paid time down to in-work time by channel, with the
rule that each minute lands in exactly one bucket and the identity that the
buckets plus a published residual sum back to paid time. Shrinkage,
occupancy, utilization and handle time are ratios of these tiers; the ledger
defines no metric of its own. Every number placed by this pack is placed by
naming the tier and bucket it reads.

## 1. The six tiers

Each tier is a subset of the one above; the difference between adjacent
tiers is itself a named bucket, so the ledger is a partition.

| Tier | Holds | Instrument (class, never a product) | What leaves before the next tier |
|---|---|---|---|
| 1 Paid time | hours the employer pays for, including paid absence | payroll or time-and-attendance; for partner supply, invoiced hours | off-schedule paid time: paid leave, paid sick absence, public holidays, training days not on the roster |
| 2 Scheduled time | hours the workforce system rostered, by activity | the workforce-management system's published schedule | scheduled-not-logged: absence against a shift, late start, early finish, no-show |
| 3 Logged-in time | hours signed in to a work platform | telephony session log; for agents on no telephony queue, the work-item tool's session log | unaccounted state time: logged minutes with no state, or a state not in the dictionary |
| 4 State time by code | logged time partitioned by activity code | the telephony state log, translated through the activity-code dictionary | non-productive states: break, training, coaching, meeting, system-down and the other shrinkage classes |
| 5 Productive time | state time in codes classed productive: available and in-work on any channel | derived from tier 4 by the code's class attribute | available-idle: productive time with no contact, session or item in hand |
| 6 In-work time by channel | time attributable to a unit of work: talk, hold and after-contact work (voice); focus time per session (chat); touch time per item (asynchronous) | telephony contact records; chat session logs; work-item timers or desktop capture | nothing; the floor of the ledger |

## 2. The closure identity

```
paid time = Σ (bucket time) + residual
```

The buckets are the leaves: off-schedule paid, scheduled-not-logged, each
non-productive state class, available-idle, and in-work per channel.

- **Every minute lands in exactly one bucket.** A minute two systems claim is
  assigned by the precedence rule in §4, never left in both; a minute no
  system claims is residual, never absorbed into the nearest bucket.
- **The residual is a published measure.** It has its own row, a tolerance
  SET LOCALLY and a grade. A residual outside tolerance fails T-01 and blocks
  every ratio computed from the affected tiers.

## 3. Metrics as ratios of tiers

| Metric | Register entry | Numerator | Denominator |
|---|---|---|---|
| Shrinkage | `SHR-01` | paid − productive (tiers 1 − 5) | paid (tier 1); or scheduled or logged where the register settles the denominator question otherwise |
| Occupancy | `OCC-01` | in-work (tier 6), summed across channels with concurrency handled as the register states | productive (tier 5) |
| Utilization | no register entry; computed on the ledger | in-work (tier 6) | paid (tier 1); the function records whether it uses productive ÷ paid instead, which equals 1 − shrinkage on a paid denominator |
| Handle time | `AHT-01` (session channels) · `AHT-02` (asynchronous, `RG-008`) | in-work per channel (tier 6) | handled units on that channel (`CON-01`) |

A change to a tier's instrument is a change to every ratio that reads it; the
ledger-map row for a ratio names both tiers.

## 4. Three state systems and the mapping to buckets

| System | Exists to | Typical states | Cannot see |
|---|---|---|---|
| Telephony real-time states | route contacts | logged out · available · on contact (talk, hold, conference) · after-contact work · auxiliary with reason codes · outbound | work on another platform; what an agent in available is doing |
| Scheduled activities | plan and adhere | shift · open time · break · lunch · training · coaching · meeting · off-queue work · time off · absence | what actually happened; a plan until compared to a state |
| Work-item states | track an item to closure | new · assigned · open · pending · resolved · closed · reopened | how long the agent worked the item; whose minutes it consumed when it changed hands |

A telephony state is a statement about an agent; a work-item state is a
statement about an item. Neither alone says that this agent spent these
minutes on this item, which is the tier-6 fact an asynchronous requirement
needs.

| Ledger bucket | Telephony state | Scheduled activity | Work-item state | Primary system |
|---|---|---|---|---|
| In-work, voice | on contact or after-contact work | open time | any | telephony |
| In-work, chat | in session (focus time) | open time | any | chat session log |
| In-work, asynchronous | a dedicated work state, or available where none exists | off-queue work, or open time at a blended seat | open, touch timer running | work-item tool |
| Available-idle | available | open time | none open, or open with no touch running | telephony; corrected by the work-item tool |
| Planned shrinkage, by class | auxiliary with the matching reason | break, lunch, training, coaching, meeting | any | scheduled activity for the class; telephony for the minutes |
| Unplanned shrinkage, by class | auxiliary with a system, outage or unscheduled reason | open time | any | telephony |
| Scheduled-not-logged | logged out | any working activity | any | workforce system against the session log; the absence feed for the reason |
| Off-schedule paid | logged out | time off, paid absence, no shift | any | payroll against the schedule |
| Residual | a state not in the dictionary; or logged with no state | any | any | none; published |

The primary-system column is the precedence rule applied when two systems
claim one minute; it is written once and cited by T-04. A report that
resolves a double count differently has created a private definition.
Scheduled-not-logged is reported as a class of unplanned shrinkage and never
added to the auxiliary classes a second time.

## 5. One code, one meaning

- A code that could mean two things is a defect: an available state in which
  agents also answer email is two buckets with an unknown share; the fix is a
  dedicated work state or a work-item timer, never a planning factor that
  splits the state by assumption.
- A catch-all code (other, project, admin) is a residual with a name; its
  minutes are reported in the residual line, not in shrinkage, until the
  dictionary classes or retires it.
- A code's meaning is its attributes (paid or not, available or not, which
  register entry it rolls up to), not its label.

## 6. From a raw state record to a bucket

1. **Read** each system's log at native resolution; aggregating first loses
   the overlap step 3 needs.
2. **Translate** each code through the dictionary or the inherited-code
   mapping with its expiry; a code in neither is residual.
3. **Resolve** multi-system claims by the primary system; log the secondary
   claim as a double-count event for T-04. This is the step most estates
   skip; the ledger is the only place the three systems must agree on the
   same minute.
4. **Post** the minute to one bucket with the dictionary version, the
   mapping-table version and the primary system recorded, for the LN card.

## 7. Worked example (synthetic, [E]; ratios [C] on [E] inputs)

Ten agents, one day, 8.0 paid hours each: paid 80.0 h [E]. Buckets: paid
leave 8.0 · sick absence against a shift 8.0 · late and early 1.5 · breaks
4.0 · training, coaching, meeting 3.5 · voice in-work 31.2 · email in-work
(touch time) 9.6 · chat in-work (focus time) 6.1 · available-idle 7.4; Σ
buckets 79.3; residual 0.7 (0.9 percent of paid [C]), published. Tiers:
scheduled 72.0 · logged 62.5 · productive 54.3 · in-work 46.9 [C].

Shrinkage (80.0 − 54.3) ÷ 80.0 = 32.1% [C]; occupancy 46.9 ÷ 54.3 = 86.4%
[C]; utilization 46.9 ÷ 80.0 = 58.6% [C]. Had the 9.6 email hours been
worked inside a voice available state, in-work would read 37.3 h and
available-idle 17.0 h, occupancy 68.7% [C], and a voice requirement model
would find the team overstaffed by the email workload it could not see.

## 8. The ledger-map row (emit into `ledger-map.md`)

One row per number: `number · card (code vN) · tier read (numerator ·
denominator for a ratio) · bucket(s) · primary system · instrument class ·
tests (from reconciliation-tests.md)`. A number that reads no tier is not a
ledger number; say so, and send it to the gate in
`source-of-truth-register.md` as a non-ledger input.

Block 4 — async-workload-model.md

<!-- Derived from [[Workload Model for Asynchronous Channels]], [[Email Handle Time Measurement]] and [[Chat Concurrency and Handle Time]] (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. -->
# Asynchronous and Concurrent Workload

The measurement and the model for work the telephony instrument cannot see:
email, cases, tickets and other deferred work, and chat, where one agent
serves several sessions at once. The arithmetic is established; its use as a
staffing method for deferred work is the practitioner model (no peer-reviewed
closed-form staffing model exists for a time-to-close goal). Chat has a
peer-reviewed treatment; the planner's Erlang-style shortcut is practice.

## 1. The work-item lifecycle

| Event | Stamp | Stamped by |
|---|---|---|
| Arrive (enters the perimeter) | arrival | the work-item tool or mail system |
| Queue (unassigned or untouched) | entry and exit | the tool; else inferred as arrival to first touch |
| Open (first taken into work) | first-touch start | the tool's assignment or status change; a desktop focus event |
| Touch (a bounded span of agent attention; several per item) | each start and end | a work-item timer, a desktop focus instrument, or an agent-set state |
| Pend (waiting on a third party or the customer) | start and end | the tool's status; where absent, the gap between touches is ambiguous |
| Close (fulfilled; the production unit is counted) | close | the tool's status change, the one stamp almost every tool holds |

An event with no instrument to stamp it is a gap the ST row records.

## 2. AHT-02: the count and the time; elapsed ≠ handling

Every item produces two units, and a model needs both.

- **The count**: one item fulfilled, stamped at close; `CON-01` extended to
  asynchronous work; the unit demand is forecast in. [M] wherever the tool
  stamps a close.
- **The time**: the handling minutes the item consumed, Σ touch durations;
  `AHT-02` (`RG-008`), sourced from `ST-007`. [M] only where touches are
  captured per item; otherwise [E] from a state timer, a sample or an
  inference, and the grade travels into every hour and FTE computed on it.

**Elapsed time** = close − arrive: the customer's clock, what a time-to-close
goal is measured on. **Handling time** = Σ touches: the agent's clock, what
the requirement is computed on. The difference is queue + pend + idle inside
an open item. A tool holding only arrive and close reports elapsed and cannot
report handling; substituting one for the other is the commonest error in
asynchronous capacity models [A]. The count and the time together make T-05
possible: items closed × handling time per item must sit inside the
channel's in-work time on the ledger.

## 3. Backlog, ageing and the requirement

```
backlog_end = backlog_start + arrivals − closures   (closures bounded by capacity)
```

A backlog that grows period after period means demand exceeds capacity.
Little's Law gives a mean age only; a goal of "x percent closed within y
hours" is about the tail, so the model carries an **ageing profile** (open
items by age bucket at period end, from the arrive stamp) and checks the goal
against it, never against the mean.

For a period that is a shift or a day, never a fifteen-minute interval:

```
required productive hours = Σ_item types (items × handling min ÷ 60)
                          + backlog hours to clear + variability buffer
required agents = required productive hours ÷ productive hours per agent per period
```

Productive hours per agent come from the ledger: scheduled hours less
shrinkage (`SHR-01` on the scheduled-hours denominator here, so the
subtraction stays in one tier) less in-work time on other channels, which is
where a blended agent's voice time leaves the email calculation instead of
being counted twice. The buffer is sized from the variance of daily arrivals
and handling time, or replaced by a simulation of the day. Inputs, source rows
and version sit on the model's LN card (`LN-004` in the examples). Pace
inferred from throughput history is censored by work availability; handling
time measured per touch is less exposed.

## 4. Why Erlang C is the wrong instrument for a goal in hours

Under Erlang C, P(wait > t) = C(c, a) · exp(−(c − a) t ⁄ s). At 120 items an
hour of 10 minutes (a = 20), 21 agents give P(wait > 20 s) = 0.74 [C] and
P(wait > 8 h) ≈ 10⁻²¹ [C]: any hours-scale target is met by one agent above
the offered load, so the instrument collapses to "workload plus a hair", has
no term for the backlog, the shrinkage or a bad day, and reports a service
level near 100 percent for a queue that may be ageing badly. Arrivals are not
stationary across a 24-hour window, service is not first-come first-served
by whichever agent frees, and pace depends on queue length. Where the goal is
tens of minutes to about two hours, worked live by dedicated agents, a delay
model (Erlang A or simulation) is defensible; where the goal is hours to days,
the workload model applies; where the email agents also take calls, the
reserve rule, not a share of an available state, is the control.

## 5. Five ways to measure email handling time

| Method | Captures | Misses | Bias | Acceptable as |
|---|---|---|---|---|
| 1 Agent-toggled state timer | minutes in state per agent per interval (ledger tier 4) | which item; touch boundaries; work in another state | both ways: high through idle-in-state, low through availability bleed; incentive-sensitive | the ledger's state input and a ceiling; per item only ÷ items closed in-state, [E] |
| 2 System open-to-close | elapsed per item, [M] for what it is; the ageing profile | everything inside the span | high, by a large and variable amount; batch closing corrupts it | the time-to-close goal and ageing; never as handling time |
| 3 Desktop activity capture (a class, named generically) | focus time per item; touch boundaries; items open together | off-screen thinking, collaboration, unseen applications | low by the off-screen share; otherwise set by the published attribution rule | the primary instrument, rule published, reconciled to state time |
| 4 Time-and-motion study, work sampling | a calibrated estimate by item type, off-screen work included | continuous measurement; the long tail; multitasking | observer effect; small samples; one week describes that week | calibration; the standard time where no instrument exists; periodic |
| 5 Statistical inference (time regressed on items closed) | a marginal minutes-per-item from history; a cross-check | item mix; multitasking; whatever lands in the intercept | inherits its inputs' biases; censored by work availability; confounded by bleed | an [E] input where nothing else exists, labelled as such |

Biases to name on the card, by direction only (no peer-reviewed size
estimate exists): multitasking and interruption; pended items (method 2
counts the wait, method 1 only if the state stays set); batch closing;
idle-in-state (inflates 1 and, through it, 5); availability bleed (email
worked while waiting for a call is booked as idle by telephony and by nothing
else, so methods 1 and 5 on a blended team are biased low by an amount T-06
must bound first).

## 6. The recommended standard, and the ladder below it

1. The unit is the item: the count stamped at close, [M]; batch closes
   detected by clustering and reported.
2. The time is focus time per item from desktop capture, under a published
   attribution rule for touch boundaries and for minutes when two items are
   open together; [M] under the rule, which is part of the card.
3. Reconciliation runs every extract: Σ focus ≤ state time in the channel's
   code ≤ productive time, per agent per day; the two gaps published as
   idle-in-state and off-screen residual, tolerance SET LOCALLY; a breach
   fails T-05.
4. Calibration is periodic: a work-sampling study per item type, cadence SET
   LOCALLY, bounds the off-screen gap.
5. Grades travel: `AHT-02` cites the instrument and the rule in `ST-007` (v0
   a quarterly sample; v1 the work-item timer).

Below the standard: count + state timer → state time ÷ items closed in-state,
[E], with T-06 bounding the understatement first on a blended team. Count
only → the work-sampling standard time, [E]. No reliable count → the channel
is marked not inventoried and planned on an asserted item estimate, [A], and
the plan says so. At no rung is elapsed time used as handling time; no number
is promoted a grade because a better instrument is on order.

## 7. Chat: two clocks, and concurrency as a measured parameter

| Quantity | Whose clock | Definition | Instrument | Lands in |
|---|---|---|---|---|
| Session elapsed time | the customer's | assignment until end (resolution, abandonment, time-out) | session log start and end; [M] | the in-service delay a service-level goal reads; never the ledger |
| Agent focus time | the agent's | minutes of attention attributed to the session under a published rule | message-level stamps; [M] under the rule, [E] otherwise | tier 6 in-work; the numerator of occupancy |

Σ elapsed over an agent's sessions in an hour can exceed sixty minutes; Σ
focus cannot. Only focus time is a unit of agent capacity, and effective
handle time for staffing is focus time; where unmeasured, elapsed ÷ k is an
[E] upper bound, valid only when k is time-weighted on the same basis.
`AHT-01` names which clock it holds for chat.

```
realised throughput = productive min × realised concurrency ÷ elapsed min per session
capacity ceiling    = productive min ÷ focus min per session
k = realised concurrency (CCY-01, from ST-012, the session log)
  = Σ session elapsed min in the interval ÷ agent productive min in the interval
```

Staffing plans on the realised figure and reads the ceiling as headroom.
Neither is concurrency limit × 60 ÷ elapsed: the limit is a routing setting,
k is what the function measures, and per-session pace falls as concurrency
rises. On the register's definition, as proposed through GP-606 for
OCC-01's concurrency rule, occupancy is Σ focus ÷ productive and cannot
exceed one; Σ elapsed ÷ productive is realised concurrency, not occupancy;
Σ elapsed ÷ (limit × productive) is slot utilisation, kept out of the
occupancy row.
When the limit changes, k, focus time and elapsed time are re-measured
together.

## 8. Worked examples (synthetic, [E]; results [C])

Email, one weekday, goal 24 hours: 420 items, 9.5 min per item from
touch-level capture, 60 open at start, 5.2 productive hours per agent (8.0
scheduled − 2.0 shrinkage − 0.8 voice overflow). Workload 66.5 h + backlog
9.5 h = 76.0 h → 15 agents; with a one-standard-deviation buffer (σ = 50
items, 7.9 h) 83.9 h → 17 agents. With 14 agents capacity is 459 items and
the end-of-day backlog 21, aged by the profile. Erlang C on the same day
(a = 8.3) answers nine agents and sees no backlog, no shrinkage, no bad day.

Email measurement, one agent, one shift, 32 items: state timer ÷ items 10.5
min; focus ÷ items 8.1 min; work sampling 9.2 min [E]; regression 9.4 min;
open-to-close 204 min, not a handling time. Σ focus ≤ state ≤ productive
(4.3 ≤ 5.6 ≤ 5.6 h) publishes the 1.3 h gap as 0.6 h idle-in-state and 0.7 h
off-screen; `AHT-02` for the type is 8.1 + 1.1 min sampled uplift, [E].

Chat, one hour, five agents at 55 productive minutes: 40 sessions, mean
elapsed 12.0 min, mean focus 5.0 min, limit three. Σ elapsed 480, Σ focus
200; k = 480 ÷ 275 = 1.75. Occupancy 200 ÷ 275 = 72.7%; the elapsed ratio of
175% is the artefact. Throughput 8.0 sessions per agent-hour; ceiling 11.
Load in agent-Erlangs 3.33; on elapsed it reads 8.0, and an Erlang
calculation fed that asks for roughly twice the agents [A]. Planning on the
limit (15 per agent-hour) understaffs by about 27 percent against the
ceiling and by nearly half against what was delivered [C].

Block 5 — reconciliation-tests.md

<!-- Derived from [[Reconciliation Tests for Time Accounting]] (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. -->
# Reconciliation Tests T-01 to T-06

Six checks on the time ledger: that it closes, that every logged minute
carries a known state, that no scheduled minute is unexplained, that no
minute is claimed by two systems, that recorded in-work time is consistent
with units of work closed, and that no production leaks into an available
state. The ST rows, the LN cards and the definition cards cite them by id.
The population-level reconciliation of who is counted at all is assumed done
before any of these runs.

## 1. Test design

| Field | Rule |
|---|---|
| Rows compared | named ledger tiers or buckets, and the ST rows they are checked against |
| Pass condition | an identity or an inequality on those rows |
| Tolerance | SET LOCALLY; published with the result |
| Failure signature | what the numbers look like when the test fails, including the sign |
| Meaning for the capacity model | which register entry or ladder rung is wrong, and in which direction |
| Owner | the data and analytics lead runs the suite; the definitions owner adjudicates |

## 2. The six tests

**T-01 Sum-to-paid.** Rows: paid time (tier 1) against Σ every leaf bucket
(off-schedule paid, scheduled-not-logged, each non-productive class,
available-idle, in-work per channel). Pass: residual = paid − Σ buckets,
within tolerance and non-negative. Failure: a positive residual above
tolerance is minutes no bucket claims; a negative residual is a double count
that T-04 localizes. Meaning: the shrinkage denominator and the roll-up's
shrinkage rungs are wrong by the residual's share; positive understates
shrinkage and overstates supply, negative the reverse. Assumes shrinkage =
paid − productive on a paid denominator, with the residual counted as
non-productive. Until explained, every ratio on the ledger is blocked at
[M] and carries [E] with the residual as its range.

**T-02 State coverage.** Rows: logged-in time (tier 3) against Σ state time
by code (tier 4), every code in the dictionary or the inherited-code mapping.
Pass: logged = Σ state, and minutes in codes outside both tables within
tolerance. Failure: logged minutes with no state event, or minutes in an
unknown code, typically a site-created auxiliary reason or a catch-all
"other". Meaning: the shrinkage class of those minutes is unknown, so
shrinkage, occupancy's denominator and adherence are each uncertain by that
amount; comparisons across supply nodes publish with the failing supply node
excluded, or are held.

**T-03 Orphan time.** Rows: scheduled time (tier 2) against logged-in time
(tier 3) plus recorded exceptions (absence, late, early). Pass: every
scheduled minute is logged or carries an exception code; the uncovered share
within tolerance. Failure: scheduled minutes with neither a session nor an
exception, concentrated at shift edges or at seats whose platform emits no
session event. Meaning: unplanned shrinkage is understated and supply the
plan assumed was never delivered; the next cycle inherits the error. Orphan
minutes post inside scheduled-not-logged flagged as orphan, never absorbed
into an exception class.

**T-04 Cross-system double count.** Rows: per agent and minute, the in-work
claims of the telephony contact record, the chat session log and the
work-item timer, against the single bucket the precedence rule allows. Pass:
Σ in-work across channels ≤ productive time for every agent-interval, and
minutes with more than one claimant within tolerance. Failure: in-work above
productive or logged; occupancy above 100%; chat elapsed counted as focus;
an email timer running through a voice contact. Meaning: workload is
overstated on the channel that lost the precedence contest, concurrency is
mis-parameterized, the combined requirement is inflated; the losing
channel's handle-time entry drops to [A].

**T-05 Item-count against time.** Rows: items closed on a channel (`CON-01`
units) × handle time per asynchronous item (`AHT-02`, `RG-008`) against
in-work time recorded for that channel (tier 6). The handle time used is the
plan or prior-cycle factor, or one from an independent instrument such as
sampling; a same-period handle time derived from the same in-work row makes
the ratio 1.0 by construction. Pass: implied ÷ recorded within tolerance of
1.0, two-sided. Failure: implied well below recorded means agents sat in a
work state without closing items (idle-in-state, batch closing, pended items
held open); implied well above recorded means items closed outside any
in-work state, which T-06 isolates. Meaning: the handle time per item is
wrong or the time is misallocated; the roll-up's reverse walk will not
reproduce the ledger; `AHT-02` for the channel is re-measured before the
next cycle and carried as [A] until then.

**T-06 Availability-bleed.** Rows: items closed, by agent and interval,
against the same agent's minutes in a telephony available state with no
contact in hand (available-idle). Pass: items closed during available-idle
minutes within tolerance of zero. Failure: a steady rate of items closed per
hour of available time at blended seats, low occupancy, near-zero recorded
in-work on the asynchronous channel. Meaning: available-idle is contaminated
with production, voice occupancy is understated, the voice model finds the
pool overstaffed, and the asynchronous workload is invisible to the plan;
until fixed the bleed is published beside occupancy.

## 3. Cadence

| Test | Runs | Gate it precedes |
|---|---|---|
| T-01 | weekly and monthly on the closed period | the monthly capacity planning lock |
| T-02 | on every extract where the platform allows; otherwise daily | any report across supply nodes; the weekly forecast-against-actual review |
| T-03 | daily on the previous day | the real-time lead's daily review of delivered supply |
| T-04 | daily; on every extract at the automation layer | the intraday model's read of occupancy |
| T-05 | weekly, per asynchronous channel | the handle-time entry's re-measurement decision |
| T-06 | weekly, per blended seat and group | the blended-pool requirement in the assembly |

All six also run after any change the carry rule names (a platform
migration, a channel launch, a dictionary version), because a number carried
across such a change is [A] until re-measured, and the tests are how it is
re-measured. The audit (GP-605) runs the full suite once as the baseline.

## 4. What a failure means, in order

1. **Disposition of the metric.** Metrics reading the failing rows are
   published with the failure stated and their grade reduced, or held; none
   at [M].
2. **A register row.** The failure is filed against the ST row or RG entry it
   implicates, with test, period, discrepancy and sign. A repeated failure on
   one row is a defect in the instrument or the definition, not the period,
   and goes to GP-606.
3. **The model's correction.** The implicated rung is re-measured or re-graded
   and the roll-up re-run; the plan that used it is annotated, never silently
   replaced.
4. **The planner gate.** A number that fails entry conditions does not enter
   the model; the gate in `source-of-truth-register.md` holds the conditions
   and the quarantine.

Two failures outrank the rest: a negative residual on T-01, which makes
every published efficiency figure suspect, and a persistent failure on T-06,
which means one channel has been planned on the time of another and the
correction moves both requirements at once. A headcount residual and a time
residual are different findings and are never netted.

## 5. The grade a number carries until it passes

| Situation | Grade the number carries |
|---|---|
| T-01 open for the period | every ledger ratio [E], with the residual as its range |
| T-02 or T-03 open on a supply node | the affected shrinkage, occupancy and adherence figures [E]; that supply node excluded from comparison across supply nodes |
| T-04 failed on a channel | the losing channel's handle-time entry [A] |
| T-05 failed on an asynchronous channel | `AHT-02` for that channel [A] until re-measured; the requirement computed on it [A] |
| T-06 persistent at a blended seat | voice occupancy and the asynchronous workload both published with the bleed beside them; neither at [M] |
| Carried across a platform, channel or cohort change, suite not yet re-run | [A] |

## 6. The tests-to-run row (emit into `tests-to-run.md`)

One row per number: `number · card · tests it must pass (ids) · rows
compared · tolerance (SET LOCALLY — seat) · cadence · grade until pass ·
last run and result, if the user knows it`. Never write a tolerance the
user has not given.

Block 6 — source-of-truth-register.md

<!-- Derived from [[Source of Truth Register]], [[Data Lineage Card for Planning Models]] and [[Data Quality Gates for Planning Inputs]] (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. -->
# Source of Truth, Lineage and the Gate

Three objects: the ST row that says which one system a number is taken from,
the LN card that says which model consumes it and what that does to its
grade, and the gate that refuses a number missing any of the five things a
planning input must carry. The RG register says what a word means; the ST
register says where the number comes from. They share one change control
(GP-606) and the same signatories, because a definition change and a source
change are usually one event seen from two sides.

## 1. The ST row

| Field | Holds | Rule |
|---|---|---|
| ST id | `ST-nnn`, issued by the register's owner | never reused; a changed source is a new version of the same row |
| Metric | the definition the row serves, by RG id and version (`AHT-02 v1`) | exactly one ST row per RG entry per channel; a definition with two rows is two definitions |
| System of record | the category the number is taken from: telephony platform, case or email tool, workforce-management system, human-resources system, finance system, a sampling study, a named file | a category and an instance label, never a product; where no system holds the number, the row says so and names what stands in |
| Extraction path | the query, report, export or interface object and the field | SET LOCALLY; held in the function's L3 work instruction, cited here by name |
| Refresh | cadence plus latency between the event and its availability | a number refreshed nightly with a two-day latency is dated by its latency |
| Owner | the seat that answers for the source and runs its extraction | a seat, never a name; the owner informs, the signatories adopt |
| Source grade | system of record · named owner · implied · unattributed | applied to a standing source; the same four words as intake signals |
| Known gaps | what the source does not capture, captures late, or captures under another state | each gap cites the test (T-01 to T-06) that measures it |
| Version and effective date | which version applies from when | forward only; previous versions kept |
| Change history | every proposal, review and adoption | same form as the RG register's |

## 2. Source grade: what it permits

| Source grade | Meaning | Number grade it permits |
|---|---|---|
| system of record | the system owns the fact | [M], when the extraction path is the row's |
| named owner | a seat produces the number by a stated method: a sampling study, a maintained file | [E] where the owner supplies a range; [A] where not |
| implied | a proxy: a state time read as work time because no work timer exists | refused at the gate; may inform a proposal only |
| unattributed | no producer who can be named | does not enter a model |

The source grade bounds the number grade; neither raises the other. A
system-of-record source emitting a field nobody has defined is refused for
the missing RG citation, not for the source grade. A derived metric has no
system of record: its ST row points to the LN card that computes it, and its
source grade is the weakest of its inputs'.

## 3. One source per metric; the conflict rule

A second system that also emits the metric is not a second row; it is a line
in the first row's known-gaps field, with the test that measures the
difference. When the two disagree, three things happen and a fourth does not:

1. The planning number is the register's source.
2. The difference is measured by the named test and published with its own
   grade, typically [C] from two [M] inputs.
3. The difference is carried by the row's owner on the definitional backlog
   until explained; most such differences are differences in what each
   system was built to count, recorded as gaps to explain, not defects to
   correct.
4. What does not happen: averaging, or choosing the figure that supports the
   case being made that day.

## 4. Ownership and change control

The ST rows are held by the analytics co-owner of the definitions register
(instrument and lineage); the definitions owner holds the definition and the
pairing; neither changes a row alone; the signatories sign jointly. Four
steps, no shortcut: propose (any seat, with the reason and the affected
reports) · review (owner and co-owner) · version (effective date, previous
kept) · adopt (the signatories, jointly). Carry rule: after a platform,
channel or cohort change, every number from the affected row is [A] until
re-measured. A corrected row applies forward only.

## 5. The LN card

| Field | Holds | Rule |
|---|---|---|
| Card id | `LN-nnn` | never reused; a changed model is a new version of the same card |
| Model | name, purpose, the method page it implements, the horizon it serves | the method is linked, never restated |
| Version and effective date | the model version and when it took effect | increments on any change to method, input set, a transform, or a consumed RG or ST version; forward only |
| Owner | the seat that answers for the model and runs it | a seat, never a name |
| Inputs | one row per input: name · RG id and version · ST id and version · grade · refresh · transform applied before the model reads it | every input cites both registers, or is quarantined |
| Transforms | each step between source and model, named, with owner, deterministic or judgmental | a judgmental transform caps the output at [E]; a deterministic one is an automation candidate |
| Outputs | one row per output: name · grade · unit · consumers (plans, reports, models by LN id) | grade = the weakest input grade, after any judgmental cap |
| Tests | the T- tests the inputs must pass before the model runs for a period | by id; a failed test holds the run |
| Change triggers | the RG and ST rows whose re-versioning forces this card to re-version | derived from the inputs field; the list GP-606 reads |
| Signatories | the seats that adopted the model version | the registers' signatories, jointly |
| Change history | every proposal, review and adoption | shared in form with the registers |

**Weakest-input rule, extended.** Output grade = the minimum over input
grades, and [C] where every input is [M]; an input that is another model's
output carries that model's output grade; a judgmental transform caps at [E]
with its range; any [A] input yields [A] outputs that may inform a proposal
but not carry a plan, unless an [E] range accompanies it, in which case the
output is [E] on that range. A multichannel requirement from measured voice
inputs and an estimated email handling time is [E] as a whole; channel-level
rows may show the measured part, but the number a plan is signed on carries
one grade, the weakest link's.

**Versions and parameters.** A version is the tuple (method, input set with
RG and ST versions, transforms, parameters); every output cites the version
that produced it. A legitimately local parameter (a target service level, a
shrinkage allowance, a concurrency ceiling) is SET LOCALLY with an owner and
read at run time; changing it is a logged parameter change, not a version;
changing the formula that consumes it is a version.

**Tracing a change.** Read every card whose inputs cite the changed RG or ST
row, then every card whose inputs cite those cards' outputs, until the chain
reaches a plan or a report. Deterministic; an automation candidate of GP-606.

## 6. The gate: five fields, five checks

A planning input must carry: **definition** (RG id and version, currently
adopted) · **source** (ST id, taken by that row's extraction path) · **grade**
([M] with the ledger version; [C] with the formula and input grades; [E] with
the range and assumption; [A] with the source and date) · **refresh date**
(within the ST row's cadence plus latency) · **owner** (a seat).

Checks run in order on every input file and stop at the first failure per
number:

1. **Completeness.** All five fields on every row; a blank is refused.
2. **Currency.** Refresh date within cadence plus latency for the period;
   stale is refused, not carried.
3. **Consistency.** RG version cited = version adopted; ST id = the RG id's
   registered source. A superseded definition is refused; a second source is
   a conflict and is refused.
4. **Admissibility.** [A] admitted only beside an [E] range or as a
   non-load-bearing comparison; [E] without a range is treated as [A]; an
   implied or unattributed ST row is refused whatever the number grade.
5. **Reconciliation.** The tests the LN card names have passed for the
   period. A failed test re-grades rather than refuses, and admissibility
   re-runs on the re-graded value: a failed T-01 sets every ledger ratio to
   [E] with the residual as range (admitted, propagates); a failed T-05 sends
   the channel's handling time back for re-measurement, carried [A].

Enforced in the format: the input file has the five fields as columns, the
loader refuses a blank, the refusal is logged with row, check and date, and
no flag skips it.

## 7. Quarantine, and what the model does next

A refused number goes to a quarantine register: the number, the model that
asked for it, the check it failed, the owner who must cure it, the date by
which, and what the model ran on meanwhile; read weekly by the register's
owner, a row past its cure date escalating to the function head. A
quarantined number may inform a proposal (row cited), be released when its
owner supplies the missing field, a newly adopted row through GP-606, or an
[E] range for an [A], or be retired. It may not be loaded by any path that
bypasses the gate, including a manual edit of the workbook.

The model's response, recorded on the LN card for the run, is one of three:
substitute an [E] range from the input's owner (the usual choice; output [E]
on that range) · carry the last admitted value as an [A] exception (may
inform a proposal; cannot carry a plan version alone; recorded loudly because
it is silent) · hold the run and report the hold.

## 8. Worked rows (synthetic, drafted Thu 16 Oct 2026)

`ST-007`, email handling time against `AHT-02 v0`: no system holds a
work-item timer, so the source is a quarterly time-and-motion sample run by
the operations analytics seat, graded named owner; known gaps "handling
inside a voice available state is not captured; items closed in batch after
the sample window land on the wrong day." Every email
handling-time figure is therefore [E] with the sample's range, and the
multichannel requirement is [E] for that reason alone. Proposed through
GP-606: a work-item timer reconciled to the sample as v1, after a parallel
run of one planning cycle [A]. `ST-001`, voice handle time against `AHT-01
v1`: system of record, the telephony platform's contact record, nightly
refresh with one-day latency [A], owner the real-time lead; known gap "the second platform instance counts a transferred
leg as a second contact; T-04 measures the difference weekly."

`LN-003`, the multichannel requirement, v2, owner the capacity planning
lead. Inputs: voice volume `CON-01 v1` / `ST-002` [M]; voice handle time
`AHT-01 v1` / `ST-001` [M], transform "transfer de-duplication, deterministic";
chat sessions `CON-01 v1` / `ST-011` [M]; chat concurrency `CCY-01 v0` /
`ST-012` [M]; chat focus time `AHT-01 v1` (chat) / `ST-013` [M]; shrinkage `SHR-01 v1` / `ST-010` [E], range 28 to 32 percent;
the email requirement, output of `LN-004`, [E]. `LN-004` reads email items
`CON-01 v1` / `ST-006` [M] and `AHT-02 v0` via `ST-007` [E], range 6.5 to 8.5
minutes, so its output is [E] and `LN-003` inherits the grade through it.
Tests: T-01 before each run; T-05 weekly on `LN-004`'s handling-time input.
Grade line: "[E]: bounded by LN-004 (AHT-02 via ST-007, named owner) and by
shrinkage (ST-010)", naming the two measurement programs that would bring
the requirement to [C].

The gate in use: a 7.1-minute handling-time figure from a newly installed
work-item timer, labelled [M] by its author, is refused at completeness: it
cites `AHT-02 v0` but its source field is blank, because the register's
source is still `ST-007 v0` and the timer has no ST row. Quarantined, owner
the data and analytics lead, cure date two weeks out [A]; the planner runs on
the sample's [E] range; the 7.1 informs the GP-606 proposal and enters no
plan until `ST-007 v1` is adopted.

## 9. The source-rows entry (emit into `source-rows.md`)

One ST row per number in the field order of §1, plus, for a derived number,
the LN card it points to and that card's input list with grades. A field the
user cannot supply is written `SET LOCALLY — <seat>` or `Open — <seat> —
<date>`, never a default.

Usage notes

Sizing. Block 1 is about 500 words and loads with every message. Blocks 2–6 are retrieved as needed: definition-card.md about 1,490 words, time-ledger.md 1,580, async-workload-model.md 2,020, reconciliation-tests.md 1,430 and source-of-truth-register.md 2,240. Blocks 4 and 6 exceed the 1,500-word guide for a reference block because each condenses three source pages into one file a model reads together. A project that works only voice numbers can omit Block 4.

Output. The pack emits four Markdown files per conversation: definition-cards.md, source-rows.md, ledger-map.md and tests-to-run.md, each row keyed to the cluster's own ids (RG-, ST-, LN-, T-01 to T-06) so that the rows transfer into the function's registers by hand or by script. Every number leaves with a grade and the grade's ceiling stated; every unresolved field leaves as SET LOCALLY or Open with a seat.

Localizing. The blocks carry every extraction path, tolerance and plausibility range as SET LOCALLY with a seat, every example figure as synthetic [E], and every system as a category and instrument class. The pack refuses to fill a value the function has not given, to name a person against a seat, to promote a number above what its source grade permits, or to name a platform in a file marked for publication. The adopted cards and rows are the function's; the wiki pages do not change when a function fills its registers.

Drift. Block 2 derives from The Data Definition Card; Block 3 from Agent Time Accounting Model and Agent State Taxonomy and Activity Codes; Block 4 from Workload Model for Asynchronous Channels, Email Handle Time Measurement and Chat Concurrency and Handle Time; Block 5 from Reconciliation Tests for Time Accounting; Block 6 from Source of Truth Register, Data Lineage Card for Planning Models and Data Quality Gates for Planning Inputs. A material change to any of them, or a change to a cluster id, is the trigger to regenerate the affected block and bump the version. The wiki page is the canonical version; a block is regenerated from it, not edited in place.

Scope. Nothing in the pack is specific to any organization, platform or jurisdiction. The ST and LN numbers in the examples (ST-001, ST-007, LN-003, LN-004) are the wiki's synthetic rows and are not a numbering a function must adopt; the metric codes and test ids are the cluster's and are kept.

Change history

Version	Date	Change
1.0	2026-10-16	First release: instruction block and five reference files (definition-card.md, time-ledger.md, async-workload-model.md, reconciliation-tests.md, source-of-truth-register.md)

See also

• Workforce Data Definitions Framework — the hub: the ledger, the registers, the channels and the practices this pack's blocks derive from
• Process Standardization — the sister hub: the processes that consume these definitions
• Wiki:Packs/Process Decomposition — CP-OPS-001, the engine for the process cards the registers sit beside
• Wiki:Packs/Time and Production Accounting Audit — CP-WFM-024, the sibling pack that runs the audit and the workshop
• The Data Definition Card · Source of Truth Register · Data Lineage Card for Planning Models · Data Quality Gates for Planning Inputs — the registers and the gate behind Blocks 2 and 6
• Agent Time Accounting Model · Agent State Taxonomy and Activity Codes · Reconciliation Tests for Time Accounting — the ledger and its tests behind Blocks 3 and 5
• Workload Model for Asynchronous Channels · Email Handle Time Measurement · Chat Concurrency and Handle Time — the channel pages behind Block 4
• The Definitions Register · Human Gates and Number Grades — the RG register the card extends and the grades the pack applies
• Definitions and Source-of-Truth Change Control (generic process) · Time and Production Accounting Audit (generic process) — GP-606, the change control every card and row passes through, and GP-605, the audit whose findings the pack resolves into rows
• Wiki:Packs — inventory and how packs work