Activity-Code Consistency

Part of the Planning Week chain · previous: Vendor Change Control for Routing · next: Planning Week for a Workforce Function Activity-Code Consistency is the scheduling section of a function's standard that requires every activity type (the states a post can be in: handling, available, break, training, coaching, meeting, absent, and the rest) to carry identical attributes across every node and platform instance before any cross-node report is treated as reliable. It has three parts: the dictionary of codes and their attributes, the mapping table that translates inherited configurations to the dictionary with an expiry date, and the check that runs before every cross-node comparison. It matters because shrinkage, occupancy, adherence and cost per hour are all computed from activity codes, and two nodes whose codes differ in one attribute produce numbers that look comparable and are not. The page produces section S-3.3.1 of the Standard on the ten-block template (template SS) and is worked in a session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003).

The page is shelf material and the last of the chain before it returns to the launch page. It restates nothing its neighbors carry: the activity dimension and the adherence event as data objects are on WFM Data Models and Schemas; the planned and unplanned categories of shrinkage and their arithmetic on Shrinkage; the regulatory rules that constrain when a code may be scheduled at all, as hard constraints on schedule generation rather than as an after-the-fact checklist, on Labor Compliance Scheduling; the two denominators that distinguish utilization from occupancy on Agent Utilization vs Occupancy Definitions and Tradeoffs. The definitions the codes roll up to are owned by The Definitions Register; the codes are configuration, held to the Standard by Systems Administration for WFM Platforms.

The vocabulary is the chain's: a node is a place work can sit: a hub (in-country depth), a service center (badged arbitrage at scale), a partner (speed, market access, flex), or automated; a seat is a post on the org chart (a director-graded or manager-graded box, its scope and its sunset condition); the intake door is the single entry for any ask, defined with its fields on The Question Register and Knowledge Base; Executive Issue Register carries the claim grades a question enters under.

Why identical attributes, not similar names

The rule is usually written for one organization at a time: activity types should carry the same attributes across it, because that is what makes organization-wide reporting mean anything. Stating it for an estate of several nodes and several platform instances changes what has to be true, and it changes the rule from one about names to one about attributes, because names are what a migration harmonizes first and attributes are what it leaves behind. Two instances can both have a code called Training and disagree on whether it is paid, whether it counts as available, whether it is planned or unplanned shrinkage, how adherence treats it, and which definition it rolls up to. A shrinkage report across the two is then a report of the disagreement.

The attributes a code must carry are fixed by the dictionary:

Attribute	Values	Why it must match
Class	productive · planned shrinkage · unplanned shrinkage · off-schedule · non-working	Shrinkage is computed from the class; a code in the wrong class moves the shrinkage figure by its whole duration
Paid	yes · no	Cost per hour and the billable view at a partner supply seat read it
Counts as available	yes · no	Occupancy's denominator is available time; utilization's is paid time; both read this attribute
Adherence treatment	in adherence · out of adherence · exempt	The adherence event on WFM Data Models and Schemas is generated from it
Rolls up to	a definition ID in the register (shrinkage, occupancy, handle time)	Every report cites the definition; a code with no roll-up is invisible to the report
Scheduled or state	scheduled activity · real-time state · both	Real-time adherence compares a scheduled activity to a real-time state; a code that is one and not the other cannot be compared
Owner and version	a seat; a version number and date	A change to a code's attribute is a change to every number computed from it, and is change-controlled

The dictionary rule is the conformed-dimension rule; the failure it prevents is the one Redman describes; the vocabulary is ISO 8000's; the categories the codes feed are the practitioner's.

The mapping table and its expiry

An inherited configuration is not rebuilt on the day the dictionary is issued. Each instance's existing codes are mapped to the dictionary in a mapping table: inherited code, instance, dictionary code, the attributes that differ, the treatment until the mapping closes (translate on read, or exclude from cross-node reports), and the expiry date on which the inherited code is retired or reconfigured. The expiry is the same kind of date as the Standard's "skeleton until": a mapping without one is a permanent translation layer, and permanent translation layers drift. On the chain the expiry of a mapping is tied to the retirement of the instance that carries it, which Systems Administration for WFM Platforms schedules.

The check

Before any cross-node comparison is published (a shrinkage comparison, an occupancy comparison, a cost per hour by node, a vendor scorecard row), the check runs: every code in every node's data for the period is either in the dictionary or in the mapping table with a treatment; every code the report reads has the attributes the report's definition requires; and no code in the period has changed attribute without a change record. A report that fails the check is published with the failing nodes excluded and the exclusion stated, or not published. The check is what turns the rule from a statement of intent into something with a result: a rule about attribute consistency that is never run is indistinguishable from not having the rule.

The ten blocks, filled

Purpose

Make the activity codes of every node and instance one dictionary with identical attributes, so that every cross-node number computed from them is comparable, and make any inherited difference visible, dated and closed.

Inputs

Each instance's activity-code configuration (interface row: Technology); the register's definitions for shrinkage, occupancy, handle time and adherence (from The Definitions Register); the regulatory rules that constrain when a code may be scheduled (interface row: Human resources; Labor Compliance Scheduling); a partner supply seat's code set (interface row: Delivery partners).

Outputs

The dictionary; the mapping table with expiries; the check's result per report; the change record for any attribute change; the configuration instruction to each instance under Systems Administration for WFM Platforms.

Roles

The standardization lead owns the dictionary; the definitions owner owns the roll-ups; the administrator configures the instances; the change-control board approves an attribute change; the real-time lead and the schedulers use the codes and raise a missing one through the intake door.

Method

The L1 flow is one page, twelve steps, four decisions.

L1 flow, section S-3.3.1 Activity-code consistency

#	Step	Owner	Next
1	Issue the dictionary: every code with its seven attributes, an owner and a version	standardization lead	2
2	Inventory every instance's and every partner seat's codes	administrator	3
3	Map each inherited code to a dictionary code; record the differing attributes, the treatment and the expiry	administrator; standardization lead	4
4	Is any inherited code unmappable (no dictionary code has its attributes)?	standardization lead	yes → 5 · no → 6
5	Open a register row: extend the dictionary or retire the code; decide with the definitions owner; version the dictionary	definitions owner	6
6	Before a cross-node report, run the check on the period's codes	the report's owner	7
7	Does the check pass for every node in the report?	the report's owner	yes → 8 · no → 9
8	Publish the report citing the dictionary version	the report's owner	10
9	Publish with the failing nodes excluded and the exclusion stated, or hold; raise the failure as a register row	the report's owner	10
10	Has a mapping reached its expiry, or has an attribute change been requested?	administrator	yes → 11 · no → 6
11	Retire or reconfigure the inherited code, or apply the attribute change through the board; increment the dictionary version; record the change	administrator; change-control board	12
12	Do any mappings remain open?	standardization lead	yes → 6 · no → End; one dictionary, no mappings, and the check has nothing left to translate

The L2 step table runs about twenty-five rows on the fifteen columns of Process Decomposition (L0–L3) and is produced by the pack. Its job aids are the dictionary template, the mapping table layout and the check procedure.

Metrics

Codes in the dictionary against codes in use (a proportion); mappings open and their ages against expiry; reports that passed the check; attribute changes with a change record. The first three belong to Level 3; a check that runs automatically on every extract belongs to Level 4.

Tools

The short-term WFM engine holds the codes in each instance; the data core holds the dictionary and the mapping table; the reporting platform runs the check; intraday automation reads the real-time state codes.

Controls

No attribute change without a change record; no cross-node report without the check; no mapping without an expiry; the acceptance gate the section passed.

Maturity

Level 1: codes are whatever the platform shipped with. Level 2: each instance has a curated set; cross-node reports harmonize names by hand each month. Level 3: one dictionary, mappings with expiries, the check before every comparison. Level 4: the check runs on every extract and the team raises the failure; a proposed attribute change is priced by its effect on every number. Level 5: one instance, no mappings; the dictionary is the configuration.

Node attribute and vendor paragraph

All nodes and every instance. A partner supply seat (a partner capacity block: one supplier, one body of work, one commercial form) has its codes mapped like an inherited instance's; the billable view under Forecast Lock Process reads the paid and available attributes; and a partner-held scheduling post uses the dictionary, not its own set, from the mapping's expiry.

Worked example

The chain's function ran two platform instances and one partner-held scheduling team. The dictionary was issued Thu 7 May 2026 with 38 codes [A]. The inventory found 41 codes on the first instance, 46 on the second and 29 at the partner seat [A]. The mapping closed 113 of 116 inherited codes [C]; three were unmappable: two heritage training codes that disagreed on the paid attribute (one instance paid classroom training and not online; the other paid both) and one partner code that counted a coaching state as available. A register row decided the training question with the definitions owner (both paid, planned shrinkage, rolling up to the shrinkage definition), and the partner's coaching code was mapped as not available with the difference stated on the partner's scorecard until its expiry. Every mapping on the second instance carried the expiry Wed 30 Jun 2027, the instance's scheduled retirement. The first cross-node shrinkage comparison in the June cycle (pencils-down Tue 9 Jun 2026) ran the check, passed for the hub and the first instance, and excluded the second instance's partner-served book with the exclusion stated; the shrinkage figure it carried, 30 percent [E], range 28 to 32, is the series' and the range is the point. The counts are the example's.

The artifact this page produces

Section S-3.3.1 on the ten-block template, template SS, the dictionary (rows keyed AC-nnn) and the mapping table. One filled example row of each:

Dictionary row

ID	Code	Class	Paid	Counts as available	Adherence treatment	Rolls up to	Scheduled or state	Owner (seat)	Version
AC-011	Training	planned shrinkage	yes	no	exempt	the shrinkage definition	both	standardization lead	1.0, Thu 7 May 2026

Mapping row, after the register row of step 5 resolved the paid attribute

Inherited code	Instance	Dictionary code	Attributes that differ	Treatment until closed	Expiry	Owner (seat)
Training-Online	second instance	AC-011	paid: no on the instance, yes in the dictionary	translate on read; flag on the cost report	Wed 30 Jun 2027	administrator

Produced in a working session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003); the filled set is part of blueprint v0.1.

What would change this

The section claims that attribute-level consistency is a precondition of any reliable cross-node report, and that a dictionary with mappings and a check delivers it. If a function ran the check for two quarters and the reports that passed it were disputed across nodes as often as the reports before it, the attributes in the dictionary would not be the ones that make numbers comparable and the dictionary would need different columns; if the check found nothing for two quarters, the mapping table would be doing the work and the check would be redundant. The check's results and the disputes at the cross-node reviews are the observation.

How this connects

• Previous in the chain: Vendor Change Control for Routing — the other configuration change the board owns
• Next in the chain: Planning Week for a Workforce Function — the launch page; the chain returns to it
• Held by: Systems Administration for WFM Platforms (one activity-code set as the administrator's custody; the instance retirement that dates the expiries)
• Rolls up to: The Definitions Register (the definitions the codes cite)
• Defers to: WFM Data Models and Schemas (the activity dimension and the adherence event) · Shrinkage (the categories and the arithmetic) · Labor Compliance Scheduling (codes as hard constraints) · Agent Utilization vs Occupancy Definitions and Tradeoffs (the two denominators)

Maturity Model Position

A curated code set per instance is Level 2 on the WFM Labs Maturity Model™; one dictionary, mappings with expiries and the check before every comparison are the Level 3 section this page defines, and they instantiate the fifth of the six standardizations Standardize Before You Automate requires — shared data definitions, agent states among them — before any process is handed to an agent team. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the documentation levels for its flow and the maturity Levels 1–5 in the Maturity block.

See Also

• Planning Week for a Workforce Function
• Anatomy of a ROC Standard
• The Definitions Register
• Systems Administration for WFM Platforms
• Standardize Before You Automate
• Human Gates and Number Grades — the number grades used on this page