Launching an Analytics Notebook Platform
Part of the Planning Week chain · previous: Placement Engine Build Path · next: Expanding Intraday Automation
Launching an analytics notebook platform is the act of standing up the Python analytics platform, the reporting platform's notebook component, as the surface on which a workforce planning function's analysts build and inspect models rather than read reports about them, under governance from the first day. It matters because the modeling a mature function depends on (elasticity, attribution, capability scoring, the pricing of placement cases) is done today in spreadsheets that hide their assumptions, and a notebook adopted without governance reproduces the spreadsheet's defects in a new format. The page produces the notebook platform's sub-plan shell (SP-002) and is worked in a session with Wiki:Packs/Technology Plan (CP-WFM-016).
The page is walked on Day 3 afternoon as the fourth chapter of Technology Migration Plan for a Workforce Function, ten minutes. It is a launch, not a tutorial: Jupyter Notebooks for WFM Analysis describes what a notebook is, its cells and kernel, its common workflows and its limits, and Reporting Automation and Self Service Analytics describes how a notebook becomes a scheduled report; neither is restated here.
Where the platform sits
The Python analytics platform is not a fourth platform to procure. It is the notebook component the reporting platform already carries, and the launch is the decision to use it as the function's modeling surface rather than as a convenience for one analyst. Three placements follow from that.
It reads the data core through governed definitions. A notebook that queries a warehouse table by column name has adopted whatever that column means; a notebook on this platform cites entries of The Definitions Register by ID and version in a header cell, and its outputs carry the entry's pairing. The reporting platform's governed metric layer is where that citation is enforced, and the notebook inherits it rather than re-implementing it.
It sits beside the simulation engine, not in place of it. The build order on the technology plan places simulation and notebooks together because they share the analysts; the simulation engine calculates the cases the arithmetic cannot price, and the notebook is where the arithmetic and the model are written, compared and explained. The two are separate components of the ecosystem per Technology Journey from Level 2 to Level 5, which places the notebook as standard at Level 4 (Advanced) beside the plan of record and the data core it depends on.
It writes dispatches, not ledgers. In the living-ledger pattern of Living Ledgers, a ledger is appended and kept, and a dispatch is derived from ledgers and regenerated on demand, never edited by hand. A notebook is a dispatch generator: it reads ledgers, or the data core that holds them, and produces a rendered output that can be thrown away and regenerated. A notebook that writes back into a ledger is a pipeline, and pipelines belong in the reporting platform's scheduled jobs, not in a notebook.
The first three notebooks
A platform is launched by the first things built on it, and the three below are chosen because each exercises one property the platform must have and each produces something the planning week needs.
| Notebook | What it does | The property it proves | The artifact it feeds |
|---|---|---|---|
| A variance decomposition | Decomposes a forecast miss into volume, handle time, mix and supply, and a handle-time change into within-cohort and composition components[1] | The platform reads the data core on the register's definitions, by cohort, at the resolution the register states | The register review of a question; the composition-trap check on any blended figure |
| A ramp curve | Fits handle time and quality against tenure by cohort, and states whether a cohort shows a curve or a level shift | The platform can compute the register's ramp entry (RMP-01), the definition most functions lack |
The supply cards' tenure depth; the structural-or-transitional tag on a driver |
| A placement case priced by hand | Prices the pooling-cost and coverage-floor tests of the gate for one live proposal with the Erlang B recursion, and shows the arithmetic beside the answer | The platform can carry a verdict-bearing table with its method attached, so that a challenge is answered by the notebook rather than by its author | Step 5 of Placement Engine Build Path; the priced outcome of The Placement Gate |
None of the three is a report. Each is a model another analyst can re-run, which is the property a computational notebook exists to give: a publishing format for a reproducible workflow rather than a scratchpad.[2]
Governance from the first day
The evidence on notebook practice is not reassuring: a large-scale study of publicly shared notebooks found that most could not be re-executed as saved, and of those that could, a minority reproduced their own results, with out-of-order execution and unpinned environments the leading causes.[3] A workforce function launching the platform therefore adopts six rules before the first notebook, and enforces them in the platform where it can.
| Rule | What it means here | Where it is enforced |
|---|---|---|
| A definitions header | Every notebook's first cell cites the register entries it reads, by ID and version; a notebook without one is not promoted | Review before promotion; the governed metric layer refuses uncited fields |
| Version control in text form | Notebooks are stored in a repository in a text representation that diffs cleanly; the rendered output is not the source of record | The platform's repository integration |
| Restart and run all | A notebook is committed only after a clean top-to-bottom run; hidden state is the defect the rule exists to catch | Review; a rendered output that does not match a clean run is discarded |
| Parameterized runs | Dates, books and cohorts are parameters, so the same notebook runs on the next book; a notebook that hard-codes its case is a one-off | The platform's parameter injection |
| Grades on outputs | Every number a notebook publishes carries [M], [C], [E] or [A], per Human Gates and Number Grades; a table mixing grades says so in its caption | Review; the reporter agent, where an agent team runs it |
| No production pipelines in notebooks | A notebook that must run unattended is refactored into the reporting platform's scheduled jobs, where the batch-processing discipline of the data-systems literature applies:[4] a notebook is interactive by design and fragile unattended | The promotion path below |
The rules are the scientific-computing community's ordinary practice (write programs for people, make incremental changes, use version control, plan for mistakes) applied to a planning function.[5]
The promotion path. A notebook has three states. It is exploratory when one analyst is asking a question; it is governed when it carries the header, passes a clean run and is in the repository; it is promoted when its logic is refactored into a scheduled job on the reporting platform, at which point the notebook becomes the documentation of the report rather than the report. WFM KPI Hierarchy and Reporting Cadence describes scheduled notebooks by cadence; the rule here is that the schedule runs the job, not the notebook.
Who owns it
The platform has one owner as a seat and one co-owner. The owner is the analytics-automation track holder in the planning function, who decides what is built and reviews promotion. The co-owner is the analytics function that holds the reporting platform, the warehouse entitlement and the governed metric layer; where the function's definitions register is co-owned with that function (the worked example's D-12), the same co-ownership covers the notebook platform, because the register is what the notebooks read. The first deliverable of the sub-plan is not a notebook: it is the confirmation that the entitlement exists, warehouse access and notebook execution for named analysts, because without it the plan is an architecture diagram.
Measures for the sub-plan are counts the platform produces: notebooks with a definitions header (all of them); notebooks promoted to scheduled jobs; analyst hours moved from spreadsheet to notebook, measured by the analysts' own time records rather than asserted. None is a headcount.
Worked example
On Day 3 afternoon, Wednesday 22 April 2026, the room opens SP-002 with the analytics-automation track holder as owner and the analytics function as co-owner, and sets the entitlement confirmation for Friday 15 May 2026 [A]. The first three notebooks are the series example's own questions. The variance decomposition re-runs the phase 2 miss: 92 percent handle time, 8 percent volume [C], and the cohort split beneath the flat blend, in-house 430 to 405 seconds and partner 470 held [M], with the register row Q-004 cited. The ramp curve fits the two cohorts against tenure and finds the in-house curve and the partner level shift the row already tagged, now with the curve's shape recorded against RMP-01. The placement case prices the email-to-voice transfer of 22 FTE [M] declined on Friday 27 March 2026, running the pooling-cost test with the training lead time as its dated constraint, and shows that the recorded price was the right one. The three are governed by Wednesday 30 September 2026 [A], the same date the first report reads the register with lineage, and the variance decomposition is the first promoted to a scheduled job in Q1 2027.
The artifact this page produces
The sub-plan shell (SP), one row for the notebook platform. One filled example row:
| ID | Sub-plan | Owner (seat) | First three deliverables | Depends on (build-order step) | Measure | Quarter |
|---|---|---|---|---|---|---|
| SP-002 | Notebooks | The analytics-automation track holder; co-owned with the analytics function | Entitlement confirmed (Fri 15 May 2026); three governed notebooks (variance decomposition, ramp curve, placement case) by Wed 30 Sep 2026; first promotion to a scheduled job (Q1 2027) | Step 1 (the register the notebooks cite); step 3 for the platform as standard beside simulation | Notebooks with a definitions header (all); notebooks promoted; analyst hours moved from spreadsheet, measured | Q2 2026 to Q3 2027 (the example's quarters) |
Produced in a working session with Wiki:Packs/Technology Plan (CP-WFM-016); the filled set is part of blueprint v0.1.
What would change this
The page claims that a notebook platform launched without a definitions header, text-form version control and a promotion path reproduces the spreadsheet's defects, and that the three first notebooks prove the platform. The observation that would overturn it is a function whose analysts adopted notebooks without those rules and whose models were re-run by a second analyst, a year later, to the same results on the same definitions. If that function exists, the governance is a cost rather than a precondition and the launch should be lighter.
How this connects
- Previous in the chain: Placement Engine Build Path — step 5 of the path is priced here
- Next in the chain: Expanding Intraday Automation — the rule telemetry the notebooks read once the layer is running
- Also: Technology Migration Plan for a Workforce Function (the parent chapter; build-order step 3) · The Definitions Register (the header every notebook carries) · AI Agent Program for a Resource Optimization Center (the agent team's post-analyst and causal analyst write on this surface)
- Defers to: Jupyter Notebooks for WFM Analysis (what a notebook is and its limits) · Reporting Automation and Self Service Analytics (the promotion tooling and self-service governance) · WFM KPI Hierarchy and Reporting Cadence (scheduled notebooks by cadence) · Data Visualization for WFM (the charts the notebooks publish) · Enterprise Data Platform (the platform the data core runs on) · Hypothesis Testing with Agent Teams (the decomposition the first notebook performs)
Maturity Model Position
Four scales on this wiki use the word level; the launch page states which is which. This page uses the WFM Labs Maturity Model™'s Levels 1–5. Notebooks for ad hoc work are introduced at Level 3 on the WFM Labs Maturity Model™ and become standard at Level 4 beside the dashboards, when the plan of record and the data core they depend on exist; Technology Journey from Level 2 to Level 5 records the distinction. The launch on this page is Level 3 work with Level 4 governance, done early so that the first Level 4 models have a surface to be built on; at Level 5 the analyst works with a code-executing model beside them on the same surface, and the dashboards are the published view of what the notebooks found.
See Also
- Planning Week for a Workforce Function
- Python for Workforce Management — the language ecosystem the platform runs
- ML Pipeline Architecture for WFM — where a promoted model goes after the notebook
- Living Ledgers — the dispatch lifecycle a notebook output belongs to
- Simulation Software — the simulation engine's category, beside the notebook
References
- ↑ Kitagawa, E. M. (1955). "Components of a Difference Between Two Rates". Journal of the American Statistical Association 50(272), 1168–1194. doi:10.1080/01621459.1955.10501299.
- ↑ Kluyver, T., Ragan-Kelley, B., Pérez, F., Granger, B., Bussonnier, M., Frederic, J., Kelley, K., Hamrick, J., Grout, J., Corlay, S., Ivanov, P., Avila, D., Abdalla, S., Willing, C., & Jupyter Development Team (2016). "Jupyter Notebooks – a publishing format for reproducible computational workflows". In Positioning and Power in Academic Publishing: Players, Agents and Agendas (ELPUB 2016), 87–90. IOS Press. doi:10.3233/978-1-61499-649-1-87.
- ↑ Pimentel, J. F., Murta, L., Braganholo, V., & Freire, J. (2019). "A Large-Scale Study About Quality and Reproducibility of Jupyter Notebooks". 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), 507–517. doi:10.1109/MSR.2019.00077.
- ↑ Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media, ch. 10 (batch processing). ISBN 978-1-4493-7332-0.
- ↑ Wilson, G., Aruliah, D. A., Brown, C. T., Chue Hong, N. P., Davis, M., Guy, R. T., Haddock, S. H. D., Huff, K. D., Mitchell, I. M., Plumbley, M. D., Waugh, B., White, E. P., & Wilson, P. (2014). "Best Practices for Scientific Computing". PLoS Biology 12(1): e1001745. doi:10.1371/journal.pbio.1001745.
