A language model can stand up a cost allocation in two days. A finance team then defends that allocation in front of operations, sales, and an auditor for the next six months. The gap between those two timelines is the whole argument of this post: the model is the cheap part now, and validation is where the work moved.
What changed when the model got fast?
For most of our 25 years, building the model was the bottleneck. Mapping activities, interviewing process owners, estimating time equations, wiring up drivers. Months of it. Validation was almost a formality at the end, because by the time you had built the thing by hand you understood it intimately.
That order has flipped. A model can now appear in days, assembled by someone who never sat with the process owners and cannot tell you why a particular driver was chosen. The artefact looks the same. The understanding behind it does not exist yet. Validation is no longer the formality at the end. It is the place the missing understanding has to be rebuilt.
Why does fast construction make validation harder, not easier?
A hand-built model carries its own audit trail in the heads of the people who built it. Ask why setup cost is allocated by batch and someone remembers the argument they had about it in March.
A fast model carries no such memory. It will give you a setup allocation, and it will sound confident, and there is no one in the room who fought for that choice. So validation cannot lean on recollection. It has to independently reconstruct whether the choice was right: does this driver reflect real consumption, does the total reconcile, does the margin survive a stress test. That is slower than rubber-stamping a model you built yourself, and it should be.
There is a second, subtler problem. A model you build by hand teaches you the business while you build it. You discover that two product lines you assumed were similar consume setup time very differently, and that discovery quietly changes how you read every later number. A model handed to you finished skips that education. You inherit the conclusions without the apprenticeship, which means the first time you genuinely understand the business is during validation, under time pressure, with a result already on the table that everyone in the room would prefer to believe.
Where should the engineering hours go now?
After the model exists. Concretely:
– Reconciliation first. Before debating any single allocation, confirm the model’s totals tie to the ledger. A model that does not reconcile is not worth arguing about line by line. – Driver scrutiny next. Walk the handful of allocations that carry the most cost and ask whether the driver reflects how the resource is actually consumed. Most of the risk sits in a small number of large pools. – Stress and drift last. Push the assumptions, then decide how often the model gets re-checked. A model is a photograph of a business at one moment, and businesses move.
This is the logic behind running validation as a distinct, independent step rather than a closing checkbox. We describe how we sequence it in /how-we-work/.
How does this connect to regulation?
Lightly, but it is worth saying. The EU AI Act pushes organisations toward being able to show that an AI-influenced system was checked, documented, and governed. A cost model that quietly drives pricing or investment decisions is exactly the kind of system that benefits from a defensible validation record. Slow validation is not only good engineering. It happens to be the paper trail you want when someone asks how the number was checked. The organisations that will struggle are the ones treating an AI-generated cost model as a finished answer rather than a draft that has to be defended. A validation step produces, almost as a by-product, the documentation a regulator or an auditor will eventually ask for: what was checked, what was found, what was accepted and why.
Is fast model construction a bad thing?
No. We use these tools and we are glad the construction got cheap. Cheap construction means you can build three candidate models and compare them, which used to be a luxury. The mistake is treating the speed of construction as if it were the speed of trust. It is not. The model is ready in two days. The trust is earned over the months you spend proving it, defending it, and watching whether it still holds as the business moves underneath it. We have seen models that were technically correct on delivery quietly drift out of usefulness within two quarters because no one owned the re-check. The construction was never the risk. The risk is treating a fast first draft as a settled fact.
Takeaway: budget for validation as the main event, not the wrap-up. If construction took two days, that is information about construction, and tells you nothing about whether the model is right. Start with reconciliation, scrutinise the largest pools, and keep a record. More on the validation step at /ai-profitability/.