Case 01 ADAM ML and the Engineering Tool
The specialist left. The problem didn't.
A diagnostic service was well into development when the dedicated data science resource that had been driving the analytical logic became unavailable. Access to a replacement was limited. After months, the constraint was slowing the work past the point of viability.
The business need was unchanged. The specialist capacity to meet it was gone.
for 20 door files
for the top 50 doors
by onsite technicians
01 — What was built
A diagnostic engine, and the tool that proves it.
Using the Factory as the method, an application engineer without a traditional software-development background built a machine-learning implementation of the diagnostic algorithm and its runtime — plus the enablement tool used to create, analyse and validate the data workflow around it.
The engine turns established diagnostic logic into a practical software capability: the ingest layer, the runtime logic, and the application workflow needed to perform the analysis consistently and at scale. What had been a slow, specialist-heavy process became a testing-and-confirmation task of a few minutes.
What matters is not that the work used AI. It is that the work went through a governed process — defined roles, validation stages, traceability, controlled iteration.
That makes the output more reliable, more reviewable and more repeatable than informal prompt-driven experimentation. The value is not speed alone. It is dependable engineering progress.
ADAM ML algorithm & runtime
The diagnostic engine now used in production. Classifies door-level false-alarm root causes from access-control event data.
ADAM Engineering Tool v1.4.1
The tool built around the engine: ingest of raw source data, the workflow, and the door-data generation used to test changes and prove out enhancements at scale.
- Ingest Processes the raw access-control data used to test diagnoses.
- Validate Logic changes checked quickly, without specialist availability.
- Offload Reduces the load on both the engineer and the data science team.
02 — Evidence
Faster is not the claim. Credible is.
Speed alone would prove nothing — a fast wrong answer is worse than a slow right one. The diagnoses were validated against onsite technicians who confirmed them both in the system and at the doors themselves.
Confirmed by technicians at the door, not by internal self-assessment. That validation is what separates an interesting prototype from an operational capability. ADAM v1.4.1 · diagnostic engine in production use
The dedicated data science resource central to developing the analytical logic became unavailable, and fill-in access was limited. The bottleneck was specialist capacity, not the problem definition.
Rather than wait for the resource model to change, the capability was rebuilt under governance by the engineer who understood the domain — with the method supplying the discipline the missing specialist would otherwise have brought.
Manual analysis averaged 2 to 2.5 days for 20 door files. The same class of work now takes minutes for the top 50 alarm-producing doors — a change in scope as well as speed.
03 — Why the case matters
The case is not that one useful application got built.
The case is that a governed methodology allowed an application engineer without a traditional software-development background to build complex, high-value software that solved a real business problem created by a resource limitation.
That is a claim about the method, not about the tool. If it holds, it holds wherever expert knowledge is hard to scale through conventional resourcing — which is most places.
If the output could not be validated independently, or could not be reconstructed six months later, or degraded quietly when the engineer's attention moved elsewhere — the method would have failed regardless of how fast the first version arrived.
Field validation and the artifact record are what make the claim checkable rather than asserted.
Governance is what turned an interesting prototype into an operational capability.