"Add AI to our inspections" usually arrives as one requirement. Underneath it sit five separate technical problems, each with its own data needs, and scoping them as one project is how inspection budgets go wrong.

I work on inspection software at Dev Station, and this is the breakdown we use when a team asks for "AI inspection". The full article with diagrams is on our site: What Is AI Inspection? Two Industries, Five Stages.

The five stages

Every inspection, on a factory line or out in the field, runs through schedule and dispatch, capture, judge, record, and act and audit. Here is what a model does at each one.

1. Schedule and dispatch. An optimisation problem with no images involved. The model ranks which assets are worth a visit, so it needs inspection history and failure outcomes. It fails when that history still lives in paper folders.

2. Capture. On-device checks for framing, focus, glare and missing required shots, run while the inspector is still standing at the asset. Cheap to build. Everything downstream gets better input.

3. Judge. Classic vision: defect or not, within tolerance or outside it. You need labelled examples of every condition you want flagged, including rare ones, and collecting the rare cases sets the timeline.

4. Record. A text problem. Language models draft findings, fill standard wording and assemble the certificate. Risk stays low because a person reads it before it leaves.

5. Act and audit. No model here. This stage is a data design problem: log what the model saw, what it suggested, and what the inspector decided, at the moment it happens.

A decision log record

The audit stage is the one engineers most often skip. A minimal record per judgement looks something like this:

{ "inspection_id": "INS-2026-0412", "asset_id": "ANCHOR-17", "image_ref": "s3://evidence/INS-2026-0412/03.jpg", "model_version": "defect-clf-1.8.2", "model_suggestion": { "label": "corrosion", "confidence": 0.81 }, "inspector_decision": "pass", "override_reason": "surface staining, no section loss", "inspector_id": "competent-person-042", "recorded_at": "2026-11-12T09:41:07Z" }

Write it as the work happens. Reconstructing it later from emails does not survive an audit.

Where the payback sits

Capture guidance and report drafting pay back fast and need little data. Judgement pays back slowly and needs a lot. Scheduling needs a digitised history most teams do not have yet.

On a testing platform we built for work at height anchor systems, the reporting cycle dropped by 70 percent with automated certificate generation alone. No model judged anything.

If you are scoping inspection software for a UK or US operator, the full guide includes a one-week exercise for finding your slowest stage: https://dev-station.tech/what-is-ai-inspection/