Living Ledgers
Living ledgers are the versioned data structures an agent team reads and writes in place of the spreadsheets a planning function keeps today. A ledger is a file, or a small set of files, that holds one kind of planning object, cites the definition of every metric it carries, is appended rather than overwritten, and records every write with who made it and why. The claim of this page is that the ledgers, not the agents, are what make an agent team auditable: a team that writes into spreadsheets inherits every property of spreadsheets, including the one that makes a forecast unauditable the moment it is refreshed. This page lists the ledgers, states the rules they share, and gives the three lifecycles that decide what is kept.
Why not spreadsheets
A planning spreadsheet has four properties that a ledger reverses. It overwrites: the refresh replaces the previous forecast, so the number a hiring decision was made against is gone by the time the decision can be evaluated, the defect Forecast Vintages describes.[1] It carries definitions implicitly: a column called AHT means whatever the analyst who built the sheet meant, and two sheets with the same column name can hold different quantities, the definition gap of Data Synthesis Before Decision.[2] It mixes findings with inference: a measured actual and a carried assumption sit in adjacent cells with the same formatting. And it has no log: a cell changed by hand is indistinguishable from one computed.
An agent working over such a sheet cannot be checked, because there is nothing to check it against. The ledgers exist so that there is.
The ledgers
| Ledger | Holds | Lifecycle | Who writes |
|---|---|---|---|
| Profile | The book of business: client, contract, channels, service targets, sites and delivery arrangements, the phase and event calendar | Ledger | Librarian, on human instruction |
| Definitions | One record per metric: name, formula, source system, owner, change history | Ledger | Librarian; every change gated |
| Demand | Daily and interval actuals by channel: offered, handled, handle time, service level, speed of answer, abandoned; transactions; the population served | Ledger | Data engineer |
| Forecast | Versioned forecasts by horizon, each with an assumption register and lineage: short (one to six weeks, daily and interval), mid (three to eighteen months, weekly), long (the annual plan, monthly) | Ledger and archive | Forecaster; variance by post-analyst |
| Supply | Scheduled, staffed and productive hours; shrinkage; occupancy; headcount by cohort and tenure; delivery arrangement | Ledger | Data engineer |
| Events | The intelligence ledger: go-lives, outages, weather, holidays, client events, product changes, business asks; each typed, dated, with an effect window and a grade | Ledger | Scout proposes; a person confirms |
| Questions | The register: one row per question, a hypothesis table, graded findings, the answer card; the knowledge base | Ledger | Librarian opens; causal analyst fills; planner grades |
| Plans | Requirement hours to FTE to roster shape to gap; scenarios; the export in the enterprise planning platform's shape | Ledger and archive | Capacity planner; signed by a person |
| Reports | Daily note, weekly review, register report, run logs | Dispatch | Reporter, coordinator |
| Change log | Every write to any ledger: what, by whom (agent or person), why | Ledger | Coordinator |
Ledgers are tabular files with a short header block naming the definitions they cite; reports are prose. The format is deliberately plain so that a planner can open any ledger without the agent team.
- Append, never overwrite. A refreshed forecast is a new version keyed by the interval it forecasts, the date and time it was made and the layer or method that produced it, the schema Forecast Vintages gives. A re-pulled actual is a new version too; the first-recorded actual is kept, because a forecast should be judged against the number that existed when it was made.[1]
- Every number cites a definition. A column that cannot be traced to a record in the definitions ledger is rejected by the data engineer at load. This is the control that catches one metric with two definitions in circulation.
- Every number carries a grade. [M], [C], [E] or [A], per Human Gates and Number Grades. A ledger cell is never ungraded.
- Every assumption is registered. A forecast version carries its assumption register: each assumption, its value, its grade, its source, and the version in which it entered. An assumption carried from a previous version is relabeled as carried, not re-presented as measured.
- Every write is logged. The change log is the audit trail; a ledger without a matching log entry is a defect the evaluator raises.
The last three rules together are what let a claim in the register be scored later, the property without which a planning function cannot revise what it believed.[3]
The three lifecycles
| Lifecycle | Rule | Applies to |
|---|---|---|
| Ledger | Appended and kept; the record of what was known and decided | Profile, definitions, demand, supply, events, questions, change log; the current forecast and plan versions |
| Dispatch | Derived from ledgers and regenerated on demand; never edited by hand; a dispatch that disagrees with its ledgers is discarded, not corrected | Reports, notes, exports |
| Archive | Older versions moved out of the working set on a retention rule but never deleted within it | Forecast and plan versions past their evaluation window |
The dispatch rule matters more than it looks. A report edited by hand becomes a second source of truth that drifts from the ledger beneath it, the green-over-red condition Data Synthesis Before Decision describes. Regenerating reports from ledgers makes the drift impossible rather than merely discouraged. Retention follows the forecast-version row on WFM Data Governance and Quality: current plus ninety days in the operational (hot) tier, two years in the analytical (warm) tier for accuracy trending; that page's own use of the word archive names a different object from this series' archive lifecycle. The warehousing literature's treatment of history, in which a changed attribute is a new row with its own validity dates rather than an update in place, is the same idea in a different tradition.[4]
Worked example
On the series example's third day, Wednesday 4 March 2026, the forecast ledger receives a new version. Its assumption register carries twelve rows; two of them changed. The voice handle-time row reads: previous value 412 seconds, source "pre-migration average, carried," grade [A]; new value 452 seconds, source "demand ledger, 2 to 3 March, definition AHT-01," grade [M]. The volume row is unchanged and still reads [C] with its driver model cited. The change log records two writes: the forecaster's proposal and the planner's approval, with the approval carrying the planner's name and the timestamp. Nearly four weeks later, when the phase 2 cohort arrives and someone asks what handle time the phase 2 sizing assumed, the answer is one lookup: the plan version of 27 March cites forecast version 2026-03-25.v1, whose register gives the row, its grade and its provenance.
The same question asked of a spreadsheet would have been answered from memory.
What would change this
The ledger set is a design proposal drawn from a prototype; the rules are supported by the forecasting-evaluation and data-warehousing literatures. A function that ran an agent team over a governed database with equivalent versioning and logging would satisfy the rules without files, and this page would then describe the schema rather than the format. The rule that most needs field confirmation is the dispatch rule: whether planners will accept reports they cannot edit.
How this connects
The ledgers are element 7 of The Agent Team Model and the surface every other page writes on. The forecast ledger's versioning is Forecast Vintages made operational; the questions ledger is developed on The Question Register and Knowledge Base; the events ledger on The Intelligence Feed; the plans ledger on Long-Term Planning Agents and the Plan of Record. The definitions ledger is the file form of the shared definitions Standardize Before You Automate names as its fifth standardization, and its governance is the standing machinery of WFM Data Governance and Quality.
Maturity Model Position
Versioned forecasts and explicit definitions are Level 3 work on the WFM Labs Maturity Model™; Reforecast and Rolling Forecast Methodology places version tracking there. Ledgers with assumption registers, grades and a change log are what Level 4 planning reads from, because a distribution cannot be planned on inputs whose provenance is unknown. The ledgers are also the cheapest of the series' elements to build: a stamped nightly extract appended to a folder is a ledger, and it starts the history on the day it is written.
See Also
- The Agent Team Model — the pattern the ledgers serve
- Human Gates and Number Grades — the grade every cell carries
- The Question Register and Knowledge Base — the questions ledger in detail
- The Intelligence Feed — the events ledger in detail
- Forecast Vintages — the versioning schema the forecast ledger uses
- Data Synthesis Before Decision — the definition, register and inference gaps the ledgers close
- WFM Data Governance and Quality — retention and the standing definitions machinery
References
- ↑ 1.0 1.1 Croushore, D., & Stark, T. (2001). "A real-time data set for macroeconomists". Journal of Econometrics 105(1), 111–130. doi:10.1016/S0304-4076(01)00072-0.
- ↑ Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study. ISBN 0-911379-01-0.
- ↑ Tetlock, P. E., & Gardner, D. (2015). Superforecasting: The Art and Science of Prediction. Crown. ISBN 978-0-8041-3669-3.
- ↑ Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley. ISBN 978-1-118-53080-1.
