Project 1 · Legacy payroll intelligence
Watch a mainframe payroll extract become an answer.
Four stages of the lifecycle, on real bytes, in your browser. A fixed-length payroll extract is decoded from its copybook, landed and reconciled, modelled into a star schema, and built into the reports a payroll director actually asks for.
Analysing the extract…
Project 2 runs the same four stages on real published data — 4,858,943 City of Chicago payroll records, where you can check every number against the source yourself.
Loading the dataset…
Every record below is invented for this demonstration. Nothing here derives from any client file, and the pension cap used is a parameter of the synthetic dataset rather than any jurisdiction's statutory figure. The Lab runs entirely in your browser: no file is uploaded, nothing is stored, and no server sees the data.
Stage 01 · Extract
The file does not describe itself.
Eighty bytes per employee record. No schema, no delimiters, no header. The meaning lives in a copybook held separately from the data — so the first thing to establish is that the copybook you were given is the one that describes these bytes.
Decoding…
Stage 02 · Land
Decoding is not the same as trusting.
Landing the data means reconciling it against the source, not just loading it. Every value now reads correctly, which says nothing about whether it is sound. This is the pass that finds what a load would otherwise carry into the warehouse and present as fact.
Reconciling…
We run this same reconciliation on legacy payroll, finance, HR and operational systems — the difference being that the exclusions and contribution errors are real, and somebody is already asking about them.
Book a free 30-minute call to talk about what is in yours.
Stage 03 · Model
The shape the records imply.
Flat files repeat employee attributes on every row, so the same question answered twice can disagree. A star schema fixes the grain and states each metric once.
Modelling…
Stage 04 · Build
The reports the model makes possible.
Each of these is a question the payroll office asks. The query behind every one is available beneath it, because a number you cannot trace is a number you cannot defend.
Building…
Ask · across every stage
The questions this actually gets asked.
Not a fifth stage — asking is what the previous four make possible. Two of these came from the payroll floor rather than from a brochure, and every answer is computed from the decoded data at the moment you open it.
Preparing…
The Lab · three projects
One proves the technique. One proves the numbers. One proves the judgement.
-
Project 1 — you are here
Legacy payroll intelligence
A fixed-length mainframe extract decoded from its copybook: EBCDIC text, packed decimal, zoned dates. Four stages, ending in the questions a payroll director actually asks.
-
Project 2
Public workforce & overtime intelligence
The same four stages over 4,858,943 payroll records the City of Chicago publishes. A pay gap that looks like 96.15× turns out to be 1.39× once part-year records are excluded.
-
Project 3
Budget against actual
The 2026 budget ordinance against payroll actuals — two City datasets that ought to reconcile and share no usable key. Joined as published they match zero rows; one stated rule takes them to 88.7%. What the remaining gap is — and what it is not.
Together they make one argument. Project 1 shows the file can be read, which a synthetic corpus can demonstrate and never verify. Project 2 shows the numbers are right, because anyone can re-issue the queries against the City and disagree. Project 3 is the part most engagements actually are: two systems describing the same thing, disagreeing, and a report due either way.
If this is your problem
Tell us what's stuck.
This ran on invented data. The same four stages run on yours. The first consultation is free.
This is the first Lab project. Others — healthcare operations, finance, inventory — will follow the same four stages. The extraction rules behind Stage 01 are open source and checked against the same fixtures as the tool that generates them: see estatemap.