How we work
Most engagements end where the third one starts
Map, build, run is a three-phase delivery model. Map finds what your systems hold and where they contradict each other. Build produces the layer, its knowledge base, its evaluation harness and its controls together. Run stays after go-live, measured on held-out data against a measure agreed before the build started.
Map: what your systems actually hold
We map what your systems actually hold, where they contradict each other, and which rules exist only in people's heads. You get a scope, a measure, a delivery plan — and an honest list of what we would not build.
What ends the phase
- A scope
- A measure
- A delivery plan
- An honest list of what we would not build
The fourth one is the deliverable nobody else publishes. A mapping exercise that finds only opportunities has not been done properly.
Build: four things, built together
The layer, the knowledge base it reads from, the evaluation harness it is judged against and the controls around it, built together. Retrofitting any one of those is what makes a project late.
The four are the intelligence layer the build produces, the knowledge base your own team corrects, the evaluation harness it is judged against, and the audit trail and autonomy controls built in the same phase. Retrofitting any one of them is what makes a project late.
Run: we stay after go-live
We stay after go-live. Measured on held-out data, monitored in production, corrected by your own team through the knowledge base. If the number did not move, we say so.
- Measured on held-out data
- Monitored in production
- Corrected by your own team through the knowledge base
The measure is agreed before the build starts
The chrome on that panel says sample workload, and it stays there. It is an illustration of the shape a measure takes, not a result from a named engagement — we have no client we may name and no outcome we may attach to one.
What held-out data means here
Data the layer was not built or tuned against. The measure is reported on that, not on the examples used to build it.
It matters because a demo on clean data, which production data is not. Anything can be made to work on the cases it was shown. Held-out data is the only version of the question worth asking.
Who owns the measurement
Assurance. Owns the evaluation harness, the red-teaming and the held-out measurement. Reports the result whether or not it is the one anyone wanted.
Solution architecture owns where the boundary sits between what the layer decides and what a person decides. Integration and data engineering connects it and hands it over documented well enough that your team can run it without us. The roles on every engagement. Your people are on it too — that part is not optional.
These are roles, not people. Names and photographs go here once we publish them.
Why your people are on the engagement
MIT, State of AI in Business 2025 reports that pilots blending internal staff with outside experts succeeded 67% of the time, against 22% for IT-only builds. That is the evidence for the staffing model, and it is the only statistic on this page.
MIT's figure, not ours, cited by report name, group and year rather than linked — the report's original URL now redirects to a group page that no longer lists it, and linking a mirror as if it were the source would undercut the point.
How long does it take?
Answered in phases, because no honest number exists to give. Map ends when there is a scope, a measure and a delivery plan you have signed off. Build ends when the harness reports against that measure on held-out data. Run has no end date by design — that is the point of the third phase.
No week or month range is published anywhere on this site, because none exists in any source behind it. A duration invented to fill this heading would be the same error the whole page argues against. It publishes when somebody who has run a phase supplies real ranges.
Questions
Straight answers.
What is map build run delivery?
A three-phase model. Map establishes what the systems hold and where they contradict each other. Build produces the layer, its knowledge base, its evaluation harness and its controls together. Run continues after go-live, measured on held-out data against a measure agreed beforehand.
How do you know if an automation actually worked?
Against a measure agreed before the build started, reported on data the layer has not seen. Assurance owns the harness and the held-out measurement and reports the result whether or not it is the one anyone wanted. If the number did not move, we say so.
What is held-out data in an evaluation harness?
Data the system was not built or tuned against, kept back so the measurement is a test rather than a demonstration. Anything can be made to work on the cases it was shown; a result on held-out data is the only version of the question worth asking.
How long does an automation engagement take from scope to run?
Answered in phases rather than weeks, because no honest duration figure exists to publish. Map ends at a signed-off scope, measure and delivery plan. Build ends when the harness reports on held-out data. Run has no end date, which is the point of it.
What happens after go-live?
The engagement continues. The result is measured on held-out data, the layer is monitored in production, and your own team corrects it through the knowledge base rather than through us. Most engagements in this category end where this phase starts.
Start here
Bring us one workflow.
Tell us the process that crosses the most systems. You get a scope, a measure and a delivery plan back — and a straight answer if we think it is not worth building.
Get in touch