The model form: what Florence Nightingale would make of 157 registers

This is the first weekly one. The two before it, in May, were fortnightly Friday wraps; from here it is every Monday: what changed in the last seven days. Wednesday is a partner system, Friday is one long argument. You can subscribe to just this series if the other two are not for you.

I want to start somewhere other than a changelog, because this week had one idea running through all of it, and the idea is about a hundred and seventy years old.

---

The form, not the figures

Florence Nightingale arrived at the barrack hospital at Scutari in 1854 and found something worse than dirt and worse than overcrowding. She found the registers.

They did not agree with each other. There was no settled way to record a death, so the same man could be counted differently depending on which book you opened, or not counted at all. The hospital was producing numbers constantly and could not answer a simple question about itself.

What she did with that is the famous part. The polar area diagrams she drew in 1858 showed, in a shape nobody could argue with, that the British Army was losing far more men to preventable disease than to Russian guns. It is one of the most effective pieces of persuasion ever drawn.

But the diagram was the consequence. The fight was over the form.

Because Nightingale had seen the deeper problem: it was not just Scutari. No two hospitals recorded the same facts the same way. One counted a patient on admission, another on discharge. One classified a death by the disease, another by the ward. Put two hospitals side by side and you learn nothing, not because the data is missing but because the two sets of numbers are not describing the same things.

So with William Farr, the statistician who had built England's system of death registration, she proposed a model form. A standard set of hospital statistics with an agreed classification, put to the International Statistical Congress in London in 1860. Not better analysis. Not more collection. One shape, used by everyone.

It did not last. A handful of London hospitals took it up and within a few years the practice had lapsed. Uniform hospital statistics took the better part of a century to actually arrive, and a great deal of what could have been learned in the meantime simply was not.

I think about that failure a lot, because civil construction is sitting precisely where those hospitals were.

Every contractor in this country records site diaries, timesheets, plant hours, variations, progress claims. Every one of them records those things in a different system, in a different shape, under different field names, with a meaningful fraction of it in a spreadsheet only one person understands. The data exists. It is not comparable - not between two companies, and usually not between two of your own projects.

Everything below is us building the model form.

So what is a register?

A register is a collection of facts we derive from the systems you already run. Site diary entries. Timesheet lines. Plant hours. Aged payables. Tender notices.

You ask for the register, not the system. When you ask Demiton what the site diary said last week, you are naming a register, and it is our job to work out which connectors, computations and documents feed it. A register can be filled by more than one system at once, which matters the moment you run Business Central on one contract type and Xero on another.

The register format is the shape those facts take once they land. That is the model form. A timesheet entry has the same shape whether it arrived from Assignar, from a payroll export, or from a PDF somebody scanned, because the shape was decided before any of them turned up.

Until Thursday, the list of them lived only in our code, which made the honest answer to "can Demiton hold X?" a conversation rather than a page.

There is now a page. The register catalogue lists all 157 registers across 11 domains, each with a plain description of what one record on it actually is:

• 97 Available - filled today from connected systems, uploads, or our own public data
• 30 Declared - written, and filling as soon as a source produces its first record
• 30 Planned - defined as a shape, ahead of the connector that will fill it

Look at those last two numbers for a second. Sixty of the 157 have nothing filling them yet, and we wrote the shape anyway. That is not backlog. That is the method. Nightingale wrote the form before the hospitals used it, because a form you design after the fact is just a description of whatever you happened to collect.

Underneath the catalogue, the schema itself became versioned this week, and Postgres is now the authority on it. Every fact we write carries the version of the shape it was checked against, so a register that changes cannot quietly poison what was already stored. Nightingale never got that part. She had one shot at a form and no way to revise it without losing the comparability she had spent a decade arguing for.

Why one shape beats more data

This is the bit that is easy to nod along with and hard to believe until you have watched it happen.

Integration stops being bespoke. When a new system arrives, the question is not "what schema do we build for it?" It is "which of these 157 shapes does it fill?" Almost always, most of the answer already exists. Connecting a system becomes a mapping exercise against shapes that are already written, already versioned, and already being read by something.

Everything downstream works on day one. A report that reads timesheet entries does not know or care that you just switched payroll providers. It was never written against KeyPay. It was written against the register. Connect something new and every existing report, every Studio answer and every Ask Demiton tool works against it immediately.

Comparison becomes possible. Two projects running two different site diary systems can finally be put side by side, because both landed on the same register. This is Nightingale's actual point, it is the slowest of these to pay off, and it is the only one that eventually changes an industry rather than a company.

Being wrong gets cheaper. Shapes can be revised, and versioned facts mean you always know which records were written under which version. Nothing has to be re-derived from scratch to work out what you are looking at.

The form was for the disease

It is easy to tell the Nightingale story as one about statistics. She would not have. The form was never the point. The point was that men were dying of things that did not have to kill them, and nobody could see it, because the records could not be added up. She counted so that the preventable could be prevented.

A civil job has its own preventable diseases, and they kill margin rather than men. We count six:

• Rework - the inspection failed, and the next stage was already built on top of it.
• Missed claims - the extra work was real, and the notice went in three days late.
• Disputes - it went to a lawyer, and the record for that week is empty.
• Weather - it rained for four days, and nobody claimed it.
• Cost drift - nobody saw the job drift until the final account.
• Lapsed compliance - the insurance lapsed the week the client checked.

None of those is bad luck. Every one of them was sitting in a register somewhere - an NCR, an instruction, a missing diary, a rain gauge, a cost line, an expiry date - in a shape nothing could read across. That is Scutari again.

So this week Demiton was reorganised around preventing them. The homepage now says exactly that and nothing else. Pricing is now set by how much work you have under protection, not by seats or systems. And inside the app there is a new protection surface: every disease, a board of your projects against all six, the watches that are armed, the alerts they raise, and a proof tab that records a cure actually firing.

The cures roll out one disease at a time, starting with lapsed compliance: every certificate and insurance expiry counts down at 90, 30 and 7 days, with the renewal attached. It has not fired on a live job yet, and we will not call it live on the homepage until it has. When it does, you will read about it here first.

The registers are what make any of this possible. You cannot warn anyone about a missed notice window if the instruction and the contract clause live in two systems that disagree about what a date is. Nightingale needed the form before she could draw the diagram. We needed 157 of them before we could name six diseases.

Demiton for Android is live

Nightingale is remembered as the Lady with the Lamp, doing her rounds of the wards at night. The records that mattered were made at the bedside, not in an office afterwards.

The site is our bedside. As of this week, Demiton for Android is live on Google Play. Ask your connected systems a question from the ute, the site office or the crib hut: where a piece of plant has been working this month, who was on site on a given day, what the site diary recorded last week. It uses the same login as the web app, so there is nothing new to set up.

Getting it there took one last round of fixes. The chat composer keyboard fix landed on the fifth attempt, this time verified failing before it was verified passing. Chats are titled again and row actions are findable.

Why our answers come back as MCP Apps

Standardising what we store only gets you halfway. The other half is the shape of the answer.

We could have invented a Demiton panel format, rendered it beautifully in our own app, and left every other surface with a wall of text. Instead we use MCP Apps: an interactive bundle served as a ui:// resource over the Model Context Protocol, which is an open standard and not ours. Any host that speaks MCP knows how to display one without knowing the first thing about us.

There are eight now - a project dashboard, a P&L viewer, a fuel claim viewer, and new this week, margin watch. Ask a question scoped to a view and the answer arrives as that panel, with real numbers in it, rather than as prose you have to re-read twice.

Same argument as the registers, one layer up. One shape for a rendered answer instead of one per surface. The margin panel is not a Studio feature we will port to other clients later. It is a bundle any MCP host can render, and Studio happens to be one of them.

Getting the first one working meant fixing a chain where each broken link hid the next: the question could not be scoped to a view at all, the panel then rendered empty while looking perfectly healthy doing it, and the underlying numbers were on the wrong register. Four backend defects only surfaced because we refused to accept a panel showing a plausible shape instead of a real figure.

A form is only worth the filling

Nightingale's model form would have been worthless if the ward clerks had filled it in badly, and this week gave us a sharp reminder of the same thing.

A form harvest reads its records a page at a time. One Assignar form we read runs to 65 pages, and page 3 returns a 500 from the source API. Pages 4 through 65 are perfectly fine. Our reader used to stop at the first failure - so everything past the broken page was never collected, and the sweep reported success.

Incomplete data that looks complete is the worst outcome on the menu. It is the thing Nightingale was actually fighting, dressed up in modern clothes.

It now skips an unavailable page and keeps going, bounded so a genuinely dead endpoint cannot spin forever, and any sweep that skipped something reports itself as partial. You get every record that exists and you are told the result is incomplete.

We also found that harvests running in the background worker were not loading the register format at all - only the API process was seeding it - so facts written by a scheduled harvest went in with no version stamp and no validation. A standard that nothing enforces is a wish. The worker seeds it now.

Announcing forge

forge is our build agent. It takes an item off our own backlog, writes the code, runs the tests, and pushes a branch.

It did its first real work this week. Sentry caught a production error: provisioning an intake email failed when Business Central returned an opportunity number as an integer instead of a string. That went onto the backlog as a work item, forge picked it up, fixed it, verified it, and pushed a branch. The fix is on main.

Two things it deliberately cannot do. It cannot merge - its branches land on staging and a human approves the pull request. And it is owner-only: forge is not in any customer's tool catalogue, and it is not a feature we are selling you. It is us, building us, in public.

Why Azure AI Foundry

We compared four places a coding agent could run, and the deciding property was that we own the image.

A hosted agent on Azure AI Foundry is our own container, built by us and pushed to our own registry. The toolchain inside it - Playwright, uv, the Python and Node versions, all of it - is ours to set. Every managed alternative we looked at fixes the base image, and an agent that cannot run our real test suite cannot verify its own work. A build agent that cannot check itself is just a very fast way to generate plausible code, which is the last thing this platform needs.

Second: same subscription, same Entra tenant, same compliance story we already tell our customers. No new vendor enters the data flow, and there is nothing extra to explain in a security review.

Third, and this is the one that matters most to us: it authenticates with a managed identity, not an API key. There is no agent credential sitting somewhere waiting to be rotated or leaked, and every action it takes traces to a system identity. Identity First is our first rule, and we do not get to suspend it because the actor is a machine.

The cost is metered on Azure rather than free on somebody else's subscription. We took that trade knowingly, with budget alerts at 50, 80 and 100 percent wired to a channel we actually read rather than an inbox we do not.

Also this week

• We were blind on this site. Error tracking had been configured on the marketing site since launch and had never sent a single event - the environment flag it gated on was never set, so the SDK silently did nothing. Zero errors, zero traces, ninety days. Fixed, along with browser performance tracing that had never been registered at all.
• Security. pnpm went from 10.12.1 to 10.34.5 in the build agent image, clearing 14 high-severity advisories, and npm came out of that image entirely - 11 more, and nothing calling it. Eight of ten outstanding Dependabot advisories cleared.
• A tenant could be invisible to itself. Facts carry the environment of the connector that produced them, but every read path defaulted to production, so an organisation whose connectors were set to demo wrote facts it could not read back. Reads are now scoped to the environments a tenant actually has.

What's next

Wednesday is the first Partner Showcase: Assignar, the video, and what actually comes across the wire when you connect it. Friday is the first Long Read, on why we built our own identity resolution instead of buying one. And somewhere in the next few weeks, the first cure fires on a real job, and it goes on the record.

Nightingale's form lapsed because the people filling it in had nothing to gain from it. Ours has to earn its keep every week, for the contractor filling in the diary as much as for the person reading the report, and the way it earns its keep is by stopping one of those six diseases before it reaches the final account. If you run a system you think should be one of those 157 registers, tell us. The shape is the cheap part. Knowing which shapes matter is not.