Drafting inspection reports before the inspector gets back to the van
Inspectors were spending their evenings writing up the day's sites from memory and a camera roll. We built an offline-first capture app and a vision model trained on their own defect taxonomy that drafts the report during the visit.
- Organization
- Facilities inspection contractor
- Building surveying · ~30 field inspectors · UK & Ireland
The shape of the system
What this demonstrates
Reports draft the same day as the visit, from photographs taken during the walk rather than reconstructed from memory that evening
Photographing becomes a tap during the walk, automatically tagged to asset, location and job
The inspector always corrects and signs off before anything issues — there is no auto-issue path
Every correction feeds back into the model, so it tracks the way this specific firm words its findings over time
01/The problem
A surveyor would visit three or four sites a day, photograph everything, and then write the reports at home that evening — or, realistically, on the weekend. Reports went out several days after the visit, and the company could not invoice until they did.
Quality varied with fatigue. A report written days after the site visit inevitably lost detail, and the photographs, filed by camera timestamp, were tedious enough to match back to findings that some findings simply went unphotographed. That mattered: a finding without a photograph is a finding a client can argue with.
Signal was the constraint nobody could design around. Plant rooms, basements and rural sites routinely had none, so any solution requiring connectivity at the point of capture was dead on arrival.
02/Approach
We treated this as an offline problem before an AI problem. The capture app was built to function entirely without connectivity — full local storage, background sync when a connection returns, and no operation that blocks on the network. We tested it in a basement car park before we trained a single model.
For the vision side, the client had years of archived reports with matched photographs. That archive was the asset. We used it to train detection against their actual defect taxonomy — the categories their reports already use and their clients already accept — rather than a generic damage-detection model that would have produced findings nobody could file.
Active learning kept labelling proportionate: rather than labelling everything, we had two senior surveyors label the examples the model was least certain about, concentrating expert time where it actually changed the model.
03/What we built
- 01
An offline-first progressive web app for capture, working one-handed and in gloves, with photographs automatically tagged to asset, location and job without any typing.
- 02
A YOLO-based detection stack fine-tuned on the client's archive, covering their defect categories — cracking, corrosion, water ingress, missing fixings, blocked egress and the rest of their standard schedule.
- 03
Severity classification against the client's own grading scheme, with the model's confidence shown to the inspector rather than hidden behind a clean-looking answer.
- 04
A drafting service that writes findings in the language of the standard, places the photographic evidence, and produces the client's existing branded report template as a PDF.
- 05
A review interface where the inspector corrects and signs off — always, with no auto-issue path — and where every correction is captured as a labelled training example.
- 06
A quarterly retraining pipeline fed by those corrections, so the model measurably tracks the way this particular firm words its findings.
04/Outcome
Reports now leave the same day as the visit instead of days later, which moved invoicing forward correspondingly — a direct working-capital effect for a firm of this size.
Evidence density rose because photographing became part of the walk rather than an admin task afterwards. More than one client remarked on the improvement unprompted, which was not something the project set out to achieve.
Inspector adoption was fast, which we attribute almost entirely to the offline-first decision — the previous system had failed on exactly that point, and the field team had long memories about it.
05/What went wrong
Detection accuracy on corrosion severity was genuinely poor at first. Closer inspection showed the senior surveyors themselves did not agree with each other consistently on the same photographs either — we had been chasing a ceiling that did not exist. The fix was product, not model: the app now presents severity as a suggestion with the two most likely grades, rather than a single confident answer.
Every engagement has one of these. A case study without it is a brochure.
06/Detail
Stack and services drawn on
Built with
- YOLO
- PyTorch
- ONNX Runtime
- FastAPI
- PWA
- Postgres
Recognise this problem?
We start every engagement by measuring what the manual process actually costs. That first week tells you whether the rest is worth doing.