Data Lineage Card for Planning Models
The data lineage card for planning models is the versioned record, one per planning model, that lists every input the model consumes by its definition (RG-nnn), its source (ST-nnn) and its grade, every transform applied between input and model, the model's method and version, and every output with the plans, reports and other models that consume it. It matters because a capacity requirement is the end of a chain, volume through handle time through shrinkage through the requirement arithmetic, and a change to any link moves the number at the end without leaving a mark on it. The card is the object through which GP-606 finds every model a changed definition touches, and through which a planner reading a requirement can see which input bounds its grade. It is part of the Workforce Data Definitions Framework and carries the weakest-input rule of Human Gates and Number Grades from the cell to the model.
Lineage in the data-warehousing literature is the record of where a value came from and what was done to it on the way, maintained as metadata beside the data rather than reconstructed afterwards,[1] and the database literature distinguishes where provenance, which source rows a value was drawn from, from why provenance, which rows and rules caused it to be what it is.[2] The card holds both for a planning model: where each input was read from, and by what transforms and formula the output follows.
Why a model needs a card
A planning model in a workforce function is rarely a single formula. A multichannel requirement, assembled as Multichannel Capacity Model Assembly describes, reads voice volume and handle time per interval, email items and handling time per day, chat sessions with a concurrency factor, shrinkage from the time ledger and a service goal per channel, and applies transforms before any of them reach the arithmetic: an interval re-basing, a transfer de-duplication, a backlog carry-forward, a concurrency adjustment. Each transform is a place where a number can be changed by a rule nobody wrote down. Without a card, the model's grade is whatever its author says, and a change to a definition is discovered when a plan moves and no one can say why. WFM Data Governance and Quality describes lineage as a governance discipline across the estate and Living Ledgers the per-client-portfolio ledgers an agent team writes; the card sits between them, the lineage of one model, re-versioned when the model or any consumed register row changes, and cited by the model's outputs.
The card template
| Field | Holds | Rule |
|---|---|---|
| Card id | LN-nnn, issued by the register's owner |
Never reused; a changed model is a new version of the same card |
| Model | Name, purpose, the method page it implements, the planning horizon it serves | The method is linked, never restated; a model with no method page documents its method on the card |
| Version and effective date | The model version and when it took effect | Increments when the method, the input set, a transform, or the version of any consumed RG or ST row changes; forward only, previous versions kept |
| 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 · the transform applied before the model reads it | Every input cites both registers; an input that cites neither is quarantined under Data Quality Gates for Planning Inputs |
| Transforms | Each step between source and model, named, with its owner and whether it is deterministic or judgmental | A judgmental transform caps the output at [E]; a deterministic transform is an automation candidate |
| Outputs | One row per output: name · grade · unit · the plans, reports and models that consume it (by LN id where a model) | The output grade is the weakest input grade, after any judgmental cap |
| Tests | The reconciliation tests on Reconciliation Tests for Time Accounting the inputs must pass before the model runs for a period | Named by test 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 same signatories as the registers, jointly, because a model is a definition applied |
| Change history | Every proposal, review and adoption | The audit trail, shared in form with the registers |
The weakest-input rule, extended
Human Gates and Number Grades states the rule for a single computed figure: it inherits the weakest grade among its inputs, and an output computed from inputs that are all [M] is [C], never [M], because it is produced by a formula rather than read from a ledger. The card extends the rule along a chain. A model's output grade is the minimum over its inputs' grades (and [C] where every input is [M]), where an input that is itself another model's output carries that model's output grade. A judgmental transform, a manual adjustment or an analyst override, caps the output at [E] with the adjustment's range recorded, whatever the inputs' grades. A model with any [A] input produces [A] outputs and may inform a proposal but not carry a plan, unless the [A] input is accompanied by an [E] range from its owner, in which case the output is [E] on that range.
The rule has a consequence a function usually finds uncomfortable on first application: a multichannel requirement computed from measured voice inputs and an estimated email handling time is [E] as a whole. The card may carry channel-level output rows so that the measured part is visible, but the requirement a plan is signed on is one number with one grade, the weakest link's. This is how the measurement gap on an asynchronous channel becomes a visible property of the capacity plan rather than a footnote.
Versioning
A model version is a tuple: the method, the input set with each input's RG and ST versions, the transforms, and the parameters. A change to any element is a new version with an effective date, and every output the model produces cites the version that produced it. Previous versions are kept, not overwritten, so that a plan signed on version 3 can be re-run on version 3 after version 4 is adopted, which is the condition for explaining a plan variance as a model change rather than an operational one. The reproducibility literature's rules apply directly: record every transform, keep every version of the inputs and the code, and make the output cite them.[3]
Parameters that are legitimately local, a target service level, a shrinkage allowance, a concurrency ceiling, are SET LOCALLY per Standard and Variant in Process Documentation, recorded on the card with an owner and read from the local register at run time; a change to one is a logged parameter change, not a model version. A change to the formula that consumes it is a version.
Reading the chain
Cards chain. The email requirement model's output is an input to the multichannel assembly model, whose output is an input to the monthly capacity plan on Capacity Planning Cycle. A change to AHT-02, the asynchronous handle-time definition, is traced by reading every card whose inputs cite it, then every card whose inputs cite those cards' outputs, until the chain reaches a plan or a report. That traversal is step 3 of GP-606, and it is deterministic, which makes it an automation candidate of that process. Lineage tracing of this kind, from a warehouse view back through its transforms to the source rows, has a settled algorithmic treatment,[4] and the data-management literature places the resulting dependency map under metadata management as the artifact impact analysis reads.[5]
Worked example
Card LN-003, the multichannel requirement model, version 2, effective Thu 16 Oct 2026, owned by the capacity planning lead. Inputs (synthetic): voice offered volume per interval, CON-01 v1, ST-002, [M]; voice handle time, AHT-01 v1, ST-001, [M], transform "transfer de-duplication on the second platform instance, deterministic"; chat sessions per interval, CON-01 v1, ST-011, [M]; chat focus time, AHT-01 v1 for chat, ST-013, [M] from the platform session log; chat concurrency, CCY-01 v0, ST-012, [M] from the platform session log; shrinkage, SHR-01 v1, ST-010, [E], range 28 to 32 percent [E]; and the email requirement by week, the output of LN-004, [E]. LN-004, the email requirement and backlog model, reads email items received per day, CON-01 v1, ST-006, [M], and handling time per item, AHT-02 v0 (ST-007: source grade named owner; [E]), range 6.5 to 8.5 minutes [E]; its output is therefore [E], and LN-003 inherits the grade through it rather than reading ST-007 itself. Tests: T-01 sum-to-paid on the ledger inputs before each run; T-05 item-count against time on LN-004's handling-time input weekly. Outputs: requirement by channel by week, [E]; blended requirement by week, [E], consumed by the plan of record and by LN-005, the schedule-build demand file. The card's grade line reads "[E]: bounded by the email requirement from LN-004 (AHT-02 via ST-007: source grade named owner; [E]) and by shrinkage (ST-010, [E])", which tells the planning lead at the plan signature which two measurement programs would bring the requirement to [C] on measured inputs. Change triggers: AHT-02 and ST-007 through LN-004; SHR-01, ST-010, CCY-01, ST-012, ST-013 and the others cited directly.
Maturity Model Position
Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a written list of what each planning model reads and what it feeds is Level 2 work. A card per model with graded inputs, a version per change and a grade line on every output is the Level 3 form, and the form an agent team needs before it can run a model, because an agent cannot be checked against a model whose inputs are unlisted. At Level 4 the card's input grades and ranges are the parameters of the distribution the plan is expressed in.
See Also
- Workforce Data Definitions Framework — the hub: the ledger, the definitions and the sources every model computes on
- Source of Truth Register — the ST rows every input cites; where a derived metric's source lives
- The Definitions Register — the RG rows every input cites
- The Data Definition Card — the card's lineage field points back here
- Data Quality Gates for Planning Inputs — what an input must carry to appear on the card
- Reconciliation Tests for Time Accounting — the tests field
- Definitions and Source-of-Truth Change Control (generic process) — GP-606, which reads the change triggers
- Multichannel Capacity Model Assembly — the model the example card describes
- Human Gates and Number Grades — the weakest-input rule the card extends
References
- ↑ Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley, ch. 19 (ETL subsystems: audit, lineage and dependency). ISBN 978-1-118-53080-1.
- ↑ Buneman, P., Khanna, S., & Tan, W.-C. (2001). "Why and Where: A Characterization of Data Provenance". In Database Theory — ICDT 2001, Lecture Notes in Computer Science 1973, 316–330. Springer. doi:10.1007/3-540-44503-X_20.
- ↑ Sandve, G. K., Nekrutenko, A., Taylor, J., & Hovig, E. (2013). "Ten Simple Rules for Reproducible Computational Research". PLoS Computational Biology 9(10), e1003285. journals.plos.org.
- ↑ Cui, Y., & Widom, J. (2003). "Lineage tracing for general data warehouse transformations". The VLDB Journal 12(1), 41–58. link.springer.com.
- ↑ DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.). Technics Publications, ch. 12 (Metadata Management), lineage and impact analysis. ISBN 978-1-63462-234-9.
