Wiki:Packs/Source of Truth Design Workbook

A deployable Claude project setup for producing a workforce function's source of truth design workbook: the one working document that lists the processes the function measures and the keys they share, defines every planning number with its numerator and denominator written apart, maps each number to the system, table and field it is taken from, specifies the person and queue records every fact joins through, holds targets as data, inventories the reports, and carries the change log once adopted. Two of its parts are the outputs a definitions workshop must settle first: the metric register (every measure defined, sourced and owned) and the code map (every activity code in one of four tiers); the rest follows in a second phase. The pack also drafts the supporting documents a workshop needs: the pre-read, the review requests, the session tables and the recaps. The pack reads whatever the function already has, a definitions list each unit wrote, an activity-code export, a person list, a report list, and turns it into the workbook's tabs, tab by tab, marking every local value the user has not supplied. It extends Wiki:Packs/Data Definitions and Source of Truth (CP-WFM-023), which writes the card and the source row for one number at a time; this pack builds the document those rows live in. Copy Block 1 into a project's custom instructions; save Blocks 2–7 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function is about to run, or has just run, a definitions and time-accounting workshop and needs the design document the workshop fills and the data team builds from: before the workshop, to pre-fill the workbook from what each unit has already written and to draft the pre-read and the review requests; during it, to type the room's decisions into the right tab with the right columns; after it, to turn the adopted version into the reference tables and the report decisions. It is not for deciding what a definition should be, which is the signatories' act through GP-606; not for the capture-point audit, which Wiki:Packs/Time and Production Accounting Audit (CP-WFM-024) runs; and not for writing one number's full card, which CP-WFM-023 does better. It pairs with both: 024 finds the gaps, 023 writes the cards, 025 holds the whole design in one place and keeps it under change control.

How to deploy

1. Create a project in Claude named for the function's workbook, not the method: "Source of truth design — <function>", not "Pack 025".
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 own material as further files: the definitions each unit has written, the activity-code export with its flags, the person list, the queue list, the report list. The pack reads them; it never invents them.
4. Start the first conversation with the local overlay: the unit names, the owner seats, the workshop dates, the decisions already taken and the tabs to pre-fill. Then ask for one tab at a time.

Block 1 — Project instructions

You are building the source of truth design workbook for the user's
workforce function: one working document, in tabs, that holds the
processes measured, the keys they share, every planning number with its
numerator and denominator written apart, the source system and field of
each, the person and queue records, targets as data, the report inventory
and the change log. The reference files hold the structure, the rules and
the templates. The content is the function's: read what the user uploads
(unit definitions, code exports, person and queue lists, report lists) and
place it; never invent a value, a system or an owner.

Routing:

| Task | File |
|---|---|
| Tab list, groups, fill order, the column template, governance after v1 | `workbook-structure.md` |
| The process-by-key matrix and how to read it | `process-key-matrix.md` |
| Dictionary rows: numerator, denominator, source field, quality check, steward, grade; the starter set | `metric-dictionary.md` |
| Person record, queue record, forecast group, site, date and interval, activity-code flags, history rules | `conformed-dimensions.md` |
| Systems inventory, targets as data, report inventory and the keep, merge, retire decision, the governance group | `systems-targets-reports.md` |
| The four tiers, the code map, planned and unplanned shrinkage | `conformed-dimensions.md` (section 4) |
| Supporting documents: pre-read, review request, reminder, data requests, session working table, recap | `workshop-kit.md` |

Working order, one tab per conversation unless the user asks otherwise:

1. Read the overlay the user pastes first: units, seats, dates, decisions
   taken, tabs to pre-fill, which tabs are in this phase. Treat it as the
   only source of local values.
2. The two core outputs first. The metric register: Dictionary (one row per
   measure per scope; unit rows carry the unit's formula as written, grade
   [A]; proposed rows carry numerator and denominator apart, a grain, a
   quality check and a steward seat) and Sources (one source of record per
   measure). The code map: Activity codes (flags from the export, never
   from memory; a tier and a shrinkage type for each code) and Ledger (the
   four tiers and the sum-to-paid test).
3. Every row of Dictionary, Sources and Activity codes carries three review
   columns: session, review (agree, change, disagree) and review note.
4. Systems, Requests, Decisions, Open items: the run tabs that support the
   core.
5. Second phase, unless the overlay brings them forward: Chain and Matrix,
   People and Queues, Horizons, Targets, Reports, Practices. Mark them
   LATER and grey until then.
6. Emit each tab as a CSV block with a one-line header note, ready to paste
   into a workbook; then `open-items.md` listing every blank the user owns.
7. Supporting documents on request, from `workshop-kit.md`.

Disciplines:
- Numerator and denominator are separate cells. A single formula cell is
  refused.
- One definition, one id; one source per metric; conflicts recorded in the
  row, never averaged.
- Every row carries a grade: [M] measured, [C] computed, [E] estimated,
  [A] asserted. What the user has been told is [A].
- Never fill a threshold, extraction path, tenant name or owner the user
  has not given: write SET LOCALLY with the seat.
- Seats, never names. Never a product name in anything marked for
  publication; a system is a category and an instance label.
- Policies the units wrote (bidding, swaps, exception handling) are not
  numbers: park them on the Practices tab with the standard that owns them.
- After adoption, every change is a Change log row with a version, an
  effective date and an owner, through GP-606, forward only.
- A blank cell with an owner is a finding, not a failure. Say so.
- Draft, review, decide: every row is drafted before the sessions; each
  owner marks their rows; no reply by the review date counts as agree; the
  sessions take only the rows marked change or disagree.
- Every paid minute lands once, in one of four tiers; the tiers add up to
  paid hours or the report does not go out. Ready time a queue needs to
  meet its service level counts in Tier 1; only the excess is leak.

Source: Wiki:Packs/Source of Truth Design Workbook (CP-WFM-025) v1.1

Block 2 — workbook-structure.md

<!-- Derived from [[Source of Truth Design Workbook]] (wiki.wfmlabs.org), version of Tue 20 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The Workbook: Structure, Fill Order and Governance

One working document, in tabs, that designs the data a workforce function's
capacity model, schedules, reports and automation all read. It models the
desired end state even where the data is not yet available, and records the
gap instead of hiding it. The registers (RG definitions, ST sources) are two
of its tabs; the workbook is the document they live in.

## 1. The method in four moves

| Move | What happens | Who | Tabs produced |
|---|---|---|---|
| 1 List the processes and the keys | Name the processes measured; name each one's context (the dimensions); cross-reference processes with the keys they share; prioritize for a phased build | The workshop, data lead present | Chain, Matrix |
| 2 Define the numbers | One row per number: numerator, denominator, unit, grain, quality check, steward; the attributes and hierarchies of each dimension; the business keys that join | The workshop, each number's owner present for its session | Dictionary, People, Queues |
| 3 Map every number to its source | Source system per fact and dimension; business keys to source tables and fields; metrics to source fields with the formula of every computed metric | The workshop with the platform owners; the data team completes | Systems, Sources, the source columns of the Dictionary |
| 4 Build, test, govern | Load flow and detailed mapping; report inventory; adopt; change control | The data team; the signatories | Reports, Change log, the reference tables |

Inside each move, the work runs in three steps. Draft: the data team and
the workforce function draft every row from what exists today. Review: each
owner marks their rows agree, change or disagree, with one line on why; no
reply by the date counts as agree. Decide: the sessions take only the rows
in disagreement and settle them; each session ends with owners and dates
for anything still open. The sessions hold disputes, not data entry.

Move 3 is where programmes stall: a definition is agreed and nobody writes
the field. Put the platform owner in the room for move 3 and leave an owned
blank where the field is not known. A number with no mapped source is still
designed; its grade is [A] until the mapping lands.

## 2. The tabs, in groups

| Group | Tab | One row is |
|---|---|---|
| Run | Requests | One data pull the workbook needs: what, who owes it, by when, status |
| Run | Decisions | One decision: question, recommendation, who decides, status, date |
| Run | Open items | One question, objection, parked topic or risk, with an owner |
| Run | Change log | One change after adoption: version, tab, row, change, reason, owner, effective date |
| Model | Chain | One stage of the planning model: question, numbers, target source, grain, owner seat, how each unit does it today, grade |
| Model | Matrix | One process against every shared key (see process-key-matrix.md) |
| Model | Systems | One system: type, units served, what it holds, grain, refresh, where it lands today, owner seat, grade |
| Model | Sources | One ST row per metric per channel per unit, extended with table and field |
| Model | Dictionary | One number per scope (see metric-dictionary.md) |
| Time | Activity codes | One code per tenant with the system's flags, its tier (1 to 4), its shrinkage type, counts-as-workload, rolls-up-to |
| Time | Ledger | The four tiers every paid minute falls into, and the tests that run on every load |
| Time | Capture points | One place time is or is not captured: gap class, path to close, owner |
| Keys | People | One attribute of the person record (see conformed-dimensions.md) |
| Keys | Queues | One attribute of the queue record |
| Plan | Horizons | One forecast horizon: question, grain, engine, owner seat, decision fed, accuracy measure, version written at hand-off |
| Plan | Targets | One target as data: scope, unit, channel, metric, value, threshold, period, basis, source document, effective date |
| Reports | Reports | One report, dashboard or working spreadsheet: platform, owner, cadence, audience, metrics, subject areas, conflicts, decision |
| Reports | Practices | One policy or practice that is not a number, parked to the standard that owns it |

The metric register (Dictionary, Sources) and the code map (Activity codes,
Ledger) are the core: every report reads from them, and they are settled
first. The run tabs support them. Chain, Matrix, People, Queues, Horizons,
Targets, Reports and Practices are the second phase; keep them in the
workbook, marked LATER and greyed, until the core is version 1.

Give each group a tab colour. Rows whose first cell starts with EXAMPLE are
examples and are styled as such; they are deleted when real rows exist.

## 3. The column template for a mapped number

Every fact and dimension specification carries three column groups, so the
data team builds from the workbook without a second document.

| Group | Columns | Rule |
|---|---|---|
| Definition | column name · display name · description · unknown member | Every dimension has an unknown member; a fact row never drops on a failed lookup |
| Source | source system · source table · source field · source data type · quality check · data steward · example values · slowly-changing type · load rule · comments | System is a category and an instance label; the load rule is a sentence a tester can execute |
| Target | data type · size · precision · key · foreign key to · nullable · default | Filled by the data team in move 4 |
| Review | session · review (agree, change, disagree) · review note | On Dictionary, Sources and Activity codes; owners filter to their seat and their session |

A quality check is a rule a load can run: "only 0 or 1", "between 0 and
100", "answered plus abandoned equals offered". A steward is a seat.

## 4. Fill order before, during and after a workshop

Before (draft and review): pre-fill from what is on file. Systems from what
is known; the Dictionary's unit rows from the definitions each unit has
written (grade [A]) beside the proposed rows; Activity codes from the
export, flags included. Tag every row with the session that settles it.
Send each owner their rows with a review date, typically a week before the
first session [A]; fold the replies in and list the rows in disagreement
per session.

During (decide): the sessions are short and few, typically three of two
hours [A]: sources, definitions, the code map. Each runs the same shape:
recap of what was agreed without discussion (10 minutes), the rows in
disagreement, biggest first (70), decide (30), owners and dates (10). The
room types into the Decided column. Off-topic items go to Open items.
Policies go to Practices.

After: within a day of each session, send the updated workbook and the
open rows with owners and dates. On the last day the core becomes version 1
and the master. Every later change is a Change log row (version, effective
date, owner) through GP-606. A written-objection window, typically two to
three weeks [A], lets those not in the room object to v1 in writing. SET
LOCALLY: the session dates, the review date, the adoption date, the
objection window, the register owner seat.

## 5. What the workbook does not do

It replaces no system: each stays the system of record for what it owns;
the workbook says which is the source of truth for which number, and the
data platform lands it once. It does not decide what a definition should
be. It carries no local value the user has not given. It is not finished
when the workshop ends: move 4 finds what the sources will and will not
yield, and that is recorded, not hidden.

Block 3 — process-key-matrix.md

<!-- Derived from [[Conformed Dimensions for Workforce Data]] (wiki.wfmlabs.org), version of Tue 20 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The Process-by-Key Matrix

The matrix lists every process of the planning model as a row and every
shared key as a column, and marks which keys each process needs on every one
of its rows. It is filled first, before any metric is defined, because it
tells the function which dimensions must be conformed before any fact can be
built.

## 1. Marks

- X: the process needs the key on every row.
- B: the join is many-to-many and goes through a bridge table (a contact
  that opened several cases; a queue serving several clients).
- blank: not needed.

## 2. The generic matrix

Rows are the ten stages of the planning chain. A function adds rows for its
own processes (queue management, partner reporting) and columns for keys of
its own (cost centre, client, forecast version).

| Process | Person | Date | Interval | Queue | Forecast group | Pool | Channel | Unit | Client | Site | Partner flag | Activity code | Forecast version |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 Demand | | X | X | X | X | | X | X | B | | X | | |
| 2 Workload | X | X | X | X | X | | X | X | B | X | X | | |
| 3 Requirement | | X | X | X | X | X | X | X | | | X | | X |
| 4 Paid supply | X | X | | | | | | X | | X | X | | |
| 5 Productive supply | X | X | X | | | X | | X | | X | X | X | |
| 6 Plan and budget | | X | | B | X | X | X | X | | X | X | | X |
| 7 Schedule | X | X | X | B | X | X | | X | | X | X | X | |
| 8 Intraday | X | X | X | X | X | X | X | X | | X | X | X | |
| 9 Actuals | X | X | X | X | X | X | X | X | B | X | X | X | |
| 10 Learn | | X | X | X | X | | X | X | | | X | | X |

## 3. How to read it

Down the columns. A key with an X in most rows is a dimension to conform
first; person and queue are always the busiest. A key with an X in one row
only can wait. A column the function cannot populate for a process it
marked X is a finding: the process cannot be joined to the others until it
can.

Across the rows. A process with a blank where a sibling has an X will not
reconcile with that sibling on that key; say so on the Chain tab rather than
pretending the join exists.

## 4. Filling it with the user

1. Confirm the row list: the ten stages plus the function's own processes.
2. Confirm the column list: the keys above plus any the function's finance
   or client reporting needs (cost centre, contract).
3. For each row, ask which keys every record of that process carries today
   [A], and which it must carry. Mark the target; note the gap on the Chain
   tab's "today" columns.
4. Order the dimension build from the busiest column down. SET LOCALLY: the
   build order and the owner seat per dimension.

## 5. Why a bridge and not a second row

A call that opened three cases is one call; a queue serving twelve clients
is one queue. Duplicating the fact row to carry each case or client
multiplies the volume. The bridge keeps the fact at its grain and lets the
many-to-many join be counted correctly, with an allocation weight where the
function wants one (SET LOCALLY).

Block 4 — metric-dictionary.md

<!-- Derived from [[The Definitions Register]], [[The Data Definition Card]] and [[Source of Truth Register]] (wiki.wfmlabs.org), version of Tue 20 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The Metric Dictionary Tab

One row per number per scope. A scope is a unit of the function as it
computes the number today, or "Proposed v1" for the definition the workshop
settles. Unit rows sit next to the proposed row, so the discussion starts
from what people actually compute.

## 1. Columns

| Column | Holds | Rule |
|---|---|---|
| id | the register id (RG- code) for a proposed row; the unit's own id for a captured row | never reused |
| name | the number as the function calls it | one name per concept; a name with two meanings is two rows |
| scope | a unit, a partner, or Proposed v1 | |
| numerator | what is counted or summed | a separate cell, always |
| denominator | what it is divided by | a separate cell, always; blank only for a count |
| formula as written | the unit's formula verbatim, for captured rows | never edited; grade [A] |
| source system | category and instance label | never a product name in anything published |
| source table or field | the table, report or field | SET LOCALLY until the platform owner supplies it |
| grain | interval, day, item, person-day, month, horizon | |
| quality check | a rule a load can run | "0-100%", "> 0 seconds", "answered + abandoned = offered" |
| steward | a seat | |
| grade | [M] [C] [E] [A] | captured rows are [A] |
| status | current · blank: ask · proposed · draft · open · v1 adopted · retired · hand-off | |
| maps to | the proposed row a captured row resolves into | |
| note | the decision it waits on; the difference from siblings | |
| session · review · review note | the session that settles it; the owner's agree, change or disagree; one line on why | no reply by the date is agree |

## 2. The discipline

- Numerator and denominator apart. "Same name, different denominator" is the
  commonest disagreement: shrinkage on paid hours and shrinkage on scheduled
  hours are two numbers; adherence over scheduled minutes and adherence over
  in-plus-out minutes are two numbers.
- One source per metric. A second system that also emits the number is a
  line in the note, with the test that measures the difference, not a second
  source.
- Captured rows are evidence. A unit's formula is recorded as written, even
  when it is wrong, because the gap between rows is the agenda.
- A blank captured row is "blank: ask": the unit has no written definition,
  which is itself a finding.
- Policies are not numbers. Bidding rules, swap rules and exception handling
  go to the Practices tab.

## 3. The register

Every single measure the capacity model or a report reads, grouped the way
the capacity model reads them: what arrives, how long it takes, the hours
available, how those hours are used, the service that results; planning
and cost last. A function adds measures of its own; it does not drop one
without a row saying why. Local thresholds are SET LOCALLY.

Headcount, FTE, attrition, ramp, overtime, repeat contacts and the planning
and cost measures sit on the human-resources and finance systems of record.
They are listed from the start so the register is complete, and usually
settled in follow-on sessions with those functions once the operational
core holds.

### Conventions every measure uses

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Time and calendar | timestamps stored in coordinated universal time, reported in site local time | (rule) | interval; the week stated | two reports that cut the day differently disagree on every number |
| Business hours | one calendar per queue | (rule) | queue | response targets measured on the wrong calendar |

### Demand: what arrives

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Contact | one customer request in one channel; an email thread is one item, credited to the sender | (count) | item | last-closer credit and transfer legs inflate counts |
| Contacts offered | contacts that reach a queue for a person | (count) | interval | contacts a bot completes counted as offered |
| Contacts handled | offered contacts a person answered or completed | (count) | interval | |
| Transfers | handled contacts passed to another queue | contacts handled | interval | the receiving leg counted as a new contact; it adds workload, not a contact |
| Bot and self-service containment | contacts the bot or self-service completes | contacts started | day | no clear line where person-handled demand begins |
| Outbound and callbacks | outbound calls and callbacks, with their own handle time | (count) | interval | hidden inside inbound handle time |
| Backlog and age | open email and case items at a stated time; age in business hours | (count) | day | snapshot time not stated |
| Repeat contacts | contacts from the same customer, same reason, within the window | contacts handled | week | no customer key across channels |

### Workload: how long it takes

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Handle time, live | talk + hold + after-contact work (voice); session time (chat) | contacts handled | contact | follow-up work inside or outside |
| Handle time, email and cases | focus time across every touch on the item | items closed | item | elapsed time is never handling time |
| Follow-up work | work on a contact after it closes, on its own code | (hours) | person-day | lost to an "other" code; it is Tier 1 |
| Chat concurrency | chats open at once per person | agent-intervals | interval | targeted rather than measured |
| Production | units of work completed, contacts and transactions, credited to the person who completed them | (count) | person-day | transaction work with no record of who did it |
| Standard time | agreed minutes per transaction type, for work with no timer | (minutes) | transaction type | never re-sampled |
| Workload hours | volume × handle time (÷ concurrency for chat) | (hours) | interval | the number the capacity model starts from; its inputs must be on this tab |

### Supply: the hours available

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Paid hours | hours paid | (sum) | person-day | own from the paid-hours record; partner from invoice |
| Scheduled hours | hours on the published schedule, by activity | (sum) | person-day | schedule version not stated |
| Available hours | paid hours minus Tier 3 | (sum) | person-day | the denominator of U2 and U3 |
| Shrinkage | paid hours not in work or ready: Tiers 2 and 3, plus lateness, downtime and unaccounted time | paid hours | person-day | paid or scheduled as the denominator; occupancy × (1 − shrinkage) must equal in-work over paid |
| Planned shrinkage | the part known when the schedule is built | paid hours | person-day | |
| Unplanned shrinkage | the part that is not: sick time, no-shows, lateness, downtime | paid hours | person-day | sick time with no allowance line |
| Overtime and time off offered | hours added or released against the schedule | (hours) | person-day | paid and unpaid mixed |
| Headcount | people with an active assignment on the date | (count) | day | own and partner on one basis |
| FTE | contract hours | standard full-time hours for the country | day | standard hours vary by country |
| Attrition | leavers, annualised | average headcount | month | voluntary and involuntary mixed |
| Ramp | new hires' handle time by week since start | tenured handle time | week | a curve, not a single number |

### How the hours are used

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Occupancy | in-work time | in-work time + ready time, live queues only | interval | read alone, without the service level it bought |
| Financial utilization (U1) | Tier 1 | paid hours | day | published as "utilization" with no name |
| Operational utilization (U2) | Tier 1 | available hours | day | |
| Operational utilization with readiness (U3) | Tier 1 + Tier 2 | available hours | day | |
| Schedule adherence | minutes in the scheduled state | minutes scheduled | person-day | tolerance window |
| Conformance | hours worked | hours scheduled | person-day | confused with adherence |
| Contacts per paid hour | contacts handled | paid hours | month | both inputs must be defined on this tab |

### Service: what the customer gets

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Service level, voice | contacts answered within the threshold | contacts offered minus abandons before the short-abandon threshold | interval | the denominator: offered, answered, or offered minus short abandons |
| Service level, chat | sessions accepted within the threshold | sessions offered to a person after any bot | interval | bot-handled sessions |
| Service level, email and cases | items answered within the threshold in business hours | items eligible (excluding junk and auto-replies) | day | business-hours calendar per client |
| Average speed of answer | total queue time of answered contacts | contacts answered | interval | |
| Abandon rate | abandons after the short-abandon threshold | contacts offered | interval | the threshold |

### Planning and cost

| Number | Numerator | Denominator | Grain | Trap |
|---|---|---|---|---|
| Staffing requirement | hours needed to meet the service target, one method per channel | (hours) | interval | the method not named on the forecast |
| Forecast accuracy | absolute error, volume and handle time separately | actual | horizon by week | one blended error hides which input moved |
| Schedule quality index | absolute difference between required and scheduled staff | required staff | interval | |
| Excluded day | a flag on the day and queue, with the reason; both numbers kept | (flag) | day | omitting the day loses it |
| Cost per productive hour | fully loaded cost | Tier 1 hours | month | cost basis |
| Cost per contact | fully loaded cost | contacts handled | month | the contact definition |

## 4. From a captured row to a proposed row

1. Group captured rows by name across units.
2. Write the numerator and denominator of each as the unit computes it.
3. Where they differ, name the difference in one line each.
4. Draft the proposed row; put the losing variants in the note as named
   variants if any unit must keep one for now (SET LOCALLY: which, until
   when).
5. Mark the captured rows "maps to" the proposed id.

Block 5 — conformed-dimensions.md

<!-- Derived from [[Conformed Dimensions for Workforce Data]] and [[Agent State Taxonomy and Activity Codes]] (wiki.wfmlabs.org), version of Tue 20 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The Shared Keys: Person, Queue and the Smaller Dimensions

A dimension is conformed when every fact that uses it uses the same key,
the same attributes and the same history. The person and queue records are
the two a function usually lacks.

## 1. The person record (identity map)

| Attribute | Holds | Rule |
|---|---|---|
| person key | one surrogate key per person across every system | generated; never reused |
| system identifiers | human-resources id; workforce-management login, one per tenant; telephony login; case-tool user; chat user; the partner's own id for a partner worker | business keys; a person in two tenants carries both |
| partner flag | own employee or partner seat | on the same record from day one, so headcount, paid hours and attrition share one basis |
| unit, client portfolio, cost centre, country, site, time zone | planning context | country drives standard hours and consultation rules; cost centre kept as original and current |
| supervisor chain | supervisor, manager, director, function head | hierarchy as data |
| role, employee type, FTE, status | agent, team lead, analyst; permanent, temporary, contractor; the FTE fraction; active, leave, left | FTE = contract hours over the country's standard |
| dates | hire; class start; nesting start and end; first day on live work; leaving date and reason | ramp and attrition read these; leaving reason splits voluntary from involuntary |
| skills and languages | eligibility | feeds pools and placement rules |
| validity | effective start, effective end, current flag, change reason | type 2: a change of site or supervisor closes a row and opens another |

## 2. The queue (contact type) record

| Attribute | Holds | Rule |
|---|---|---|
| queue key, id, name | surrogate key per validity period; the routing's business key; the planning name | the id never changes; the name may |
| status | active, dormant, retired, candidate to drop | a dormant queue still taking volume is a finding |
| unit, client, service type | the segment; the client where client-specific; the product or service | many clients on one queue is a bridge |
| pool type, pool | dedicated, designated or shared; the eligibility pool served from | |
| channel, routing points | voice, email, chat, transaction; every routing point feeding the queue | many to one |
| forecast group | the group or contact-type set the queue rolls up to | some stand alone; sets are a bridge |
| service threshold, service target, short-abandon threshold | seconds or hours; percent; the abandon exclusion | per queue; SET LOCALLY; the value lives on the Targets tab |
| hours of operation, time zone | when open | effective-dated |
| owner seat | who answers for the queue | no owner is a finding |
| validity | effective start, effective end, current flag, change reason | type 2: a consolidation closes rows and opens one; history is not restated |

## 3. The smaller dimensions

- Forecast group: name, channel, set membership; a set is a bridge.
- Site: address, time zone, hours, own or partner, site leader seat;
  effective-dated.
- Date: calendar and fiscal calendar; work-day and holiday flags; current
  period flags.
- Interval: the quarter-hour of the day; the ledger in coordinated universal
  time, local time derived per site. SET LOCALLY: the interval length if
  not fifteen minutes.
- Channel, direction: small stable lists.

## 4. Activity codes and the four tiers

One row per code per tenant. The first group of columns comes from the
workforce-management system's export and is never retyped: paid, available,
personal, overtime, uses a seat, open type, code type. The second group is
the function's mapping: tier, shrinkage type (planned, unplanned or not
shrinkage), counts as workload (yes or no), rolls up to (which dictionary
row), adherence treatment, share of time, owner and version.

| Tier | What it is | Typical codes |
|---|---|---|
| 1 Doing the work | customer-facing or customer-serving time | talk, hold, after-contact work; chat and email focus time; follow-up work; the ready time a queue's service level needs |
| 2 Getting ready | enabling work that builds capability | training, coaching, team meetings, one-to-ones |
| 3 The cost of being human | time paid because people are people | breaks, lunch, paid leave, public holidays; sick time up to the plan's allowance |
| 4 The leak | cost with no output | unaccounted time, lateness, no-shows, system downtime on its own code, sick time above the allowance, idle beyond what the service level needs, catch-all codes until explained |

Every minute lands once; the four tiers add up to paid hours or the report
does not go out. Ready time splits: the part the queue needs to meet its
service level (required readiness, from the queue model at the target) is
Tier 1, the excess is Tier 4; until the queue model can run per interval,
report ready time as its own line and the leak both ways. A code whose
share of time exceeds a threshold (SET LOCALLY, typically five percent
[A]) and whose name ends in "other" is a catch-all: split or retire. The
older layered ledger (paid, scheduled, logged in, state by code, productive,
in work) remains the reconciliation waterfall of
[[Reconciliation Tests for Time Accounting]]; a function that runs it adds
a ledger-layer column.

## 5. Rules that hold everywhere

- Every dimension has an unknown member; a failed lookup is kept, pointed
  at it and counted by a test, never dropped silently.
- History is type 2: effective start, effective end (open-ended while
  current), current flag, change reason.
- A many-to-many join is a bridge, not a duplicated row.
- Both keys are stored: the generated surrogate and the source's business
  key.
- Seats, not names, own dimensions and attributes.
- No product names in anything published: a source is a category and an
  instance label.

Block 6 — systems-targets-reports.md

<!-- Derived from [[Report Inventory and Rationalization]] and [[Source of Truth Design Workbook]] (wiki.wfmlabs.org), version of Tue 20 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Systems, Targets and Reports

Three tabs that turn the design into something the operation can see: the
systems the numbers come from, the targets the numbers are judged against,
and the reports that show them.

## 1. The Systems tab

One row per system in the estate, including the ones nobody calls a system:
personal spreadsheets, finance files, partner files.

| Column | Holds |
|---|---|
| system | category and instance label (a telephony platform, unit A; the workforce-management system, tenant 2) |
| type | telephony; workforce management; case or email tool; chat; planning; data platform; reporting layer; human resources; finance; partner-run |
| units served | which parts of the function |
| what it holds | the facts and dimensions it is or could be the source of |
| grain | call, event, item, 15-minute interval, person-day, month |
| refresh | continuous, daily, weekly, manual |
| landing today | where its data goes now, if anywhere |
| owner seat | who answers for it |
| grade | [A] when told, [M] when shown |
| notes | migrations under way; licences ending; what it cannot emit |

Ask each seat what it opens on a Monday morning; the answer is usually a
spreadsheet that is on no catalogue and is the figure leadership acts on.

## 2. The Targets tab

Targets are data, not slide footnotes. One row per scope, metric and
period, with where the target comes from.

| Column | Holds |
|---|---|
| scope | all queues; a client; a service tier; a site |
| unit, channel | |
| metric | the dictionary id |
| target, threshold | the percent and the seconds or hours; SET LOCALLY |
| period | interval, day, month, contracted monthly |
| basis | client contract; internal; regulatory; service offer |
| source document | the contract or policy the target is taken from |
| effective from, owner seat, grade | |

A target with no source document is [A]. A metric with targets at two
thresholds for two clients is one dictionary row and two target rows.

## 3. The Reports tab

One row per report, dashboard or working spreadsheet that carries a
planning number: report; platform (category); unit; owner seat; cadence;
audience; metrics shown (by dictionary id); subject areas that feed it;
what it conflicts with; the decision; grade.

The decision, taken once per report and recorded with the date and the seat:

| Decision | When |
|---|---|
| keep | its numbers already read the register's sources, or it serves an audience nothing else serves (client-facing, regulatory) |
| merge | the same metrics to overlapping audiences; the survivor reads the register's sources, the others point to it for a notice period, then stop |
| retire | the number is wrong by definition (a channel mix that can exceed one hundred percent because contacts are double-credited), or the audience has gone |
| automate | a manual export or hand-built report the platform can produce on schedule; the manual step is the risk |
| land it | a report that exists in a system and has never been delivered |

Rationalization follows the source of truth, never the other way round.
Once the Dictionary and Sources tabs say what a number means and where it
comes from, every report showing it is rebuilt to read that source, and a
report showing a different number for the same name is a conflict to
resolve, not a second opinion.

## 4. Governance after version 1

- The workbook is the master from its adoption date (SET LOCALLY). The
  register owner is a seat.
- Every change is a Change log row: version, tab, row, change, reason,
  owner, effective date. Forward only, through GP-606.
- A standing data governance group, monthly or more often during a build
  [A], reviews proposed metrics against the Dictionary and refuses a new
  metric that duplicates an existing one under another name.
- Data stewards, one seat per subject area, answer for their rows.
- A new report, or a new metric on an existing one, enters through intake:
  it cites a dictionary id or proposes one, names the source row it reads,
  and names the audience.
- The report inventory is re-run on a cadence (SET LOCALLY; typically
  annually [A]).

Block 7 — workshop-kit.md

<!-- Derived from [[Source of Truth Design Workbook]] and [[Occupancy and the Three Utilizations]] (wiki.wfmlabs.org), version of Thu 22 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# The Workshop Kit: Supporting Documents

The documents that carry draft, review, decide. Each is short, written for
the people who own the rows, and drafted from the workbook, never ahead of
it. Seats, not names, in anything that leaves the function's own team.
Dates, owners, session times and thresholds are SET LOCALLY.

## 1. Writing rules for every document

- Say what is being agreed and what is asked. No section on why the work
  is needed and no statements about what is wrong today: the readers know,
  and a list of faults reads as blame.
- Every ask has a seat, a date and a format.
- No reply by the date counts as agree; say so once, in bold.
- Lists of measures come from the Dictionary tab, in its order; never a
  shorter list in the document than in the register.

## 2. The pre-read (about ten minutes to read)

| Section | Holds |
|---|---|
| In one minute | five lines: the goal; the four things standardized (definitions, time accounting, sources, ownership); the two outputs; draft, review, decide; the sessions and the version-1 date; then a boxed ask: what, by when, no reply is agree |
| 1 What we standardize | the four things, one line each, and which output each lands in |
| 2 What we will produce | the metric register and the code map; one example row each, marked "format, not a decision"; where they live in the workbook |
| 3 The measures in the register | the full list from the Dictionary, grouped as in metric-dictionary.md section 3: measure, the proposed definition in one line, the session that settles it; later measures listed and marked |
| 4 How we will work | draft, review, decide; a table of sessions: when, the question, what it settles |
| 5 What we need, by the review date | a table: seat, what they send |
| 6 Not in these sessions, and what comes next | the parking lot; the follow-on sessions with finance and human resources on their systems of record |
| Appendices | the sessions in detail (sources; the code-map groups with proposed tiers); the four tiers |

## 3. The review request (cover note)

Subject: your rows for the definitions sessions, by <review date>

> Attached is the pre-read for the definitions sessions on <dates>. Your
> rows are in the shared workbook: filter the steward column to <seat>.
> Mark each row agree, change or disagree in the review column, with one
> line on why. It takes about an hour. Please finish by <review date>. No
> reply by then counts as agree. Join the session that covers your rows:
> <session list>.

## 4. The reminder (two working days before the review date)

> A reminder that reviews are due <date>. <n> of your <m> rows are marked so
> far. Rows left blank count as agree.

## 5. A data request (one per request)

| Field | Holds |
|---|---|
| What | the extract, export or answer, in one line |
| Format | file type, grain, period covered |
| Used for | the dictionary or source rows it fills, by id |
| Owed by | a seat |
| Due | a date; hard dates in bold |
| Send to | the register owner seat, workforce lead copied |

Every request is a row on the Requests tab with its status.

## 6. The session working table

One table per session, built from the rows marked change or disagree:
measure (id) · today, by unit · proposed · what is disputed, in one line ·
decided · owner and date if not decided. Biggest disagreement first. The
Decided column is typed live.

## 7. The recap (within a day of each session)

Three parts: decided (row, decision, effective date); open (row, owner,
date); the updated workbook. After the last session: version 1 of the
register and the code map, the decision records, and the date written
objections close.

Usage notes

Sizing. Block 1 is about 700 words; the reference blocks run 700 to 1,950 words each and total about 6,600. A project carrying all seven plus a function's own uploads (a definitions list, a code export, a person list) stays well inside a project's knowledge limit; a full workbook emitted tab by tab across several conversations is the intended use, not one conversation for all eighteen tabs.

Output. Each tab is emitted as a CSV block with a one-line note above it, so it pastes into a spreadsheet unchanged; `open-items.md` lists every blank the user owns. The pack never emits a workbook with values it was not given; a cell it cannot fill is blank, with the seat that owns it, and that blank is reported as a finding.

Localizing. The first message in the project is the function's overlay: unit names, owner seats, workshop dates, decisions already taken, tabs to pre-fill. Every SET LOCALLY mark in the blocks is resolved from that overlay or from the user's uploads, never from the model's memory. Thresholds, extraction paths, tenant names and adoption dates are always local.

Drift. The blocks are condensed from the source pages as of Thu 22 Oct 2026. When a source page changes its field list or its rules, the block that derives from it is re-derived and the pack version is raised; a project built on an earlier version keeps working but should replace the changed block.

Scope. The pack builds and maintains the design document. It does not decide definitions (the signatories do, through GP-606), does not run the capture-point audit (CP-WFM-024), and does not write one number's full card and lineage (CP-WFM-023). It assumes the function has, or is about to run, a definitions workshop and a data team to build from the result.

Change history

Version	Date	Change
1.0	Tue 20 Oct 2026	First release: Block 1 plus five reference blocks derived from the three design pages and the register pages.
1.1	Thu 22 Oct 2026	Draft, review, decide: review columns on the register and code map, the session shape and fill order. The register and the code map named as the core outputs; other tabs a second phase. The starter set replaced by the full register (46 measures) grouped by the capacity model, with shrinkage and occupancy aligned to Occupancy and the Three Utilizations. The four tiers and shrinkage type on the code map. New Block 7, workshop-kit.md, for the pre-read, review request, reminder, data requests, session table and recap. A project on 1.0 replaces Blocks 1, 2, 4 and 5 and adds Block 7.

See also

• Workforce Data Definitions Framework
• Wiki:Packs/Data Definitions and Source of Truth (CP-WFM-023)
• Wiki:Packs/Time and Production Accounting Audit (CP-WFM-024)
• Source of Truth Design Workbook
• Occupancy and the Three Utilizations
• Conformed Dimensions for Workforce Data
• Report Inventory and Rationalization
• The Definitions Register · Source of Truth Register
• Wiki:Packs