The Data Layer Beneath Continuous Planning

The data layer beneath continuous planning explains why a planning process in which every horizon is a closed loop runs poorly when each platform's numbers are used unreconciled, and what the one data model it runs on instead has to contain. The argument is short. A loop is a measurement that changes a decision: the stock-management structure of system dynamics is a comparison of a measured stock with a desired one, acted on through a delay. Five loops at five horizons, coupled so that each informs the others, require that the measurement at every horizon be the same quantity, defined once, versioned, and traceable to the people, hours and contacts it was made from. Where each platform and each unit counts its own way, the loops are not reading one world; they are reading several, and the couplings between them carry translation error instead of information.

The page gives the requirement, the contract each loop places on the data, the layered model that meets it, and what breaks without it. It is the data companion to Workforce Planning as a Control System and to the generic process card Continuous Planning Cycle (generic process); the register of measures it reads is the one described on Workforce Data Definitions Framework.

Why one model

Four properties of a closed loop impose the requirement.

• A loop compares a measurement with a goal. The capacity loop compares the agents the plan wants with the agents it has, net of the supply line. If "agents it has" is a headcount from the people system in one unit and a seat count from the workforce platform in another, the gap is partly an artifact of the count. The "blended currency" failure in Capacity Planning Cycle, shrinkage applied to one side of a subtraction and not the other, is the same fault at a different grain.
• Coupled loops pass quantities between horizons. Variance routing decomposes a week's gap into level, mix, handle time, shrinkage and supply and hands each component to another loop. The decomposition is arithmetic on the capacity equation, and the arithmetic only holds if the handle time the short-term loop measured and the handle time the capacity loop planned on are the same measure at the same grain. Reconciliation across temporal hierarchies, the method that keeps daily, weekly and monthly forecasts coherent, assumes the series at every level are aggregations of one series.
• A learning loop needs the forecast that was made, not the forecast that is. Vintage learning scores each forecast at the horizon at which it was made. A forecast table that overwrites its previous version each refresh cannot be scored, and a loop that cannot be scored cannot learn; see Forecast Vintages.
• A ledger needs lineage. The assumption ledger recomputes the plan from named assumptions and records why each planned value was set. Every number in the compiled plan has to trace to the rows it came from and the dates they were set, which is only possible if the rows are data with identifiers and versions rather than cells in a workbook.

The requirement is therefore not "more data" or "better integration". It is one shape for people, time, work and intervals that every platform maps into, one definition per measure with its formula, grain, owner and version, and a version on every forecast and every plan. The platforms can keep changing beneath it; only their adapters change.

The contract each loop places on the data

The table states, for each loop and coupling of the control-system reading, what it reads, at what grain and refresh, which version field it depends on, and what it writes back. Measures are named generically; a function's register supplies the identifiers. The couplings carry the parent page's labels L1 to L5, which are not the documentation levels L0 to L3 of Process Decomposition (L0–L3).

Loop or coupling	Reads	Grain and refresh	Version field	Writes
B1 Interval correction	contacts offered and handled, handle time, occupancy, adherence, service level, queue age, backlog	15 minutes, near real time	none	interval actions, on the real-time platform
B2 Short-term reforecast	the above plus workload hours, the requirement, scheduled hours, overtime and time-off hours, planned and unplanned shrinkage	15 minutes for the forecast, person-day for hours; daily	forecast version on the requirement	hours-band changes, overtime and time-off offers; schedule changes after a published catch rate
B3 Pipeline-aware capacity	the requirement over the planning window (thirteen weeks is illustrative), headcount, full-time equivalents, attrition, ramp, paid and available hours, shrinkage, the supply-line stock, and the envelope with its authority bands	pool by week, weekly; monthly decision	forecast version; plan-of-record version	the plan of record by pool and week; requisitions and class starts; the gap net of the supply line
B4 Structural elasticity	the swing in the requirement over the planning window and the year by pool; workload by channel; contract corridors; the idle and overtime shares from routing	pool by quarter	contract version	the sized band per pool; the lever selection
B5 Finance envelope	paid hours and cost, headcount, the reconciled forecast over the window, the envelope	pool by month	plan-of-record version; budget version	the envelope and authority bands
L1 Vintage learning	every forecast vintage and the actuals it is scored against	horizon by vintage	forecast version	accuracy by horizon; retuned parameters
L2 Assumption ledger	the register's measures as current estimates; the planned values	assumption by week	estimate vintage; planned-as-of date	breach events with owner and persistence; the recompiled plan
L3 Variance routing	workload hours and their components, the requirement, scheduled and paid hours, headcount, the supply-line stock	pool by week, weekly	all of the above	the routed components; the variance-by-lever report
L4 Envelope feed-down	the envelope by pool and month	monthly	budget version	nothing; it is read by B3
L5 Anticipation	the hours-band limits; the contract corridors	as they change	contract version	the sized hire

Two objects in the table are often absent from a function's data, and both are small. The supply-line stock is one table: pool, week, decisions committed, requisitions open, offers accepted, people in training by graduation week, graduates by ramp week, expected attrition before landing, and the productive-equivalent total. Its sources are the recruiting system, the training calendar and the identity map. The assumption ledger is one table: assumption identifier, planned value and the date it was set, current estimate and its vintage, the tolerance band, the owner role, persistence, and dependents. Everything else in the table is a measure a definitions register already names.

The layered model that meets it

Read bottom up.

1. Landing. An untouched, append-only copy of each source, one schema per source, so that every number traces back to where it came from; the staging area of the dimensional-modelling tradition.
2. The single model. One person, one queue, one interval, one list of codes, whatever the source. This is where normalization happens: the identity map resolves each person's logins across systems, the problem master-data management calls entity resolution; interval lengths and time zones are lined up; the code map places every platform's activity codes and events on one list; the time ledger puts every paid hour of every person in exactly one bucket with a published residual. The supply-line stock and the assumption ledger live here.
3. Business-ready tables. Interval performance, adherence, forecast accuracy by vintage, the capacity plan, built once from the single model: the conformed facts and dimensions of the same tradition.
4. The semantic layer. Each measure defined once with its formula, grain, owner and version, and used everywhere: the definitions register implemented as data. The loops read from here and nowhere lower.
5. The knowledge layer. How things relate: clients, skills, languages, partners, service promises, process standards, and the certified record of what each person may do.
6. Access. Governed and logged routes in, through which reports and agents read.
7. Write-back. In this pattern write-back is typically gated and late: schedules before routing, each after a published catch rate.

Each platform connects through its own adapter, so that when a platform changes the change is confined, in principle, to its adapter. The layers go by several names in practice; the names do not matter, the separation does. In this pattern a new platform, an acquisition or a partner feed is added by mapping it: its export lands, its logins are added to the identity map, its codes are placed on the code map, and its adapter is tested against the standing tests before its numbers are published. Lineage, the ability to trace any published number to the records it was derived from, is what the separation is for.

What breaks without it

Each missing property produces a recognisable failure in the loops.

• No identity map. Headcount differs between the people system, the workforce platform and the partner's roster, so the capacity loop's gap carries a constant offset per unit that is argued about monthly and never resolved. The supply line cannot be built because a trainee in the training calendar is not the same person as a requisition in the recruiting system.
• No code map or time ledger. Shrinkage and occupancy mean different things per unit, so variance routing attributes to "shrinkage" what is a coding difference, and the structural loop sizes bands against a swing that is partly definitional.
• No version on the forecast. Vintage learning has nothing to score; the forecast cannot be audited and the forecast-credibility loop of Feedback Loops in Workforce Planning runs: a forecast that cannot be shown to have been right is overridden, and the overrides are what miss.
• No semantic layer. Each report carries its own formula, so the loops disagree with the reports leadership sees, and the loop with the weakest number loses the argument regardless of which was right.
• No ledger as data. The annual plan stays a number with a history, defended whole or abandoned whole, because the assumption that moved cannot be found.

Ownership

One common allocation assigns the meaning to the planning function (the definitions, the single model's semantics, the semantic layer and the knowledge layer), the pipes to the data function (capture, landing and the reporting layer), and capture at the source to the platform owners: where a platform cannot record how long a person spent on an item, no definition rescues it, and the time-capture requirement falls on them. Under that allocation write-back to the planning and workforce platforms belongs to the planning function and follows the gates. See Definitions and Source-of-Truth Change Control (generic process) for how a definition changes once it is in use.

Limitations

The layered model is a pattern, not a product, and the names of its layers vary; the page describes the separation, not a tool. The contract table states what the loops need at a minimum and omits the dimensions, client, skill, site, sourcing, that every measure is cut by in practice. The two new objects are described structurally; their sources differ by function and the hardest part of each is the identity map beneath it. And a data layer built to this pattern does not make the loops run; it makes them possible.

Maturity Model Position

At the lower levels of the WFM Labs Maturity Model™ the platforms' own numbers are the data layer and the workbooks between them carry the translation. The single model with a semantic layer, a version on every forecast and the time ledger with a published residual is the data foundation of Level 4: Planning in Distributions; the knowledge layer and gated write-back are what Level 5: Adaptive Orchestration runs on.

See Also

• Workforce Planning as a Control System
• Continuous Planning Cycle (generic process)
• Workforce Data Definitions Framework
• The Definitions Register
• Source of Truth Register
• Agent Time Accounting Model
• Reconciliation Tests for Time Accounting
• Forecast Vintages
• Variance Routing by Horizon
• Assumption Ledgers and the Continuous Annual Plan
• Hierarchical Forecasting