AI defect diagnostics: where accuracy is lost in images
Manual inspection of structures does not scale physically: kilometers of spans, hundreds of joints, sites that are accessed once a year.
An engineer walks the route and records what is visible from hand level, while some defects remain outside the frame — behind an element, in shadow, above eye level.
Threshold algorithms, which are set as the first stage, break down on real images. Brightness threshold and frame differencing confidently catch glare, shadows from reinforcement, formwork marks, and installation markings — hence false positives.
A thin crack, meanwhile, blends into the background: contrast is low, the edge is blurred, and the survey is conducted at an angle.
The cost of error is asymmetric. A missed defect means the crack grows to the point where repair is not local but involves replacing a section. False positives erode trust: the operator stops opening the alert, and the system works formally but not in practice.
Therefore, AI defect diagnostics is not reduced to a single rule.
Analysis of structural images is divided by surface types and survey conditions, the model is trained on annotations of real defects taking into account angle and lighting, and thresholds are set according to the acceptable miss rate — which is specified by the customer, not the developer.
Below is how it works: from data preparation and annotation to scenarios where the system sends an image for manual review instead of an automatic verdict.
Measurable effect: inspection speed and completeness of findings
Recognition completeness no longer depends on who exactly went to the site.
The model annotates frames by class — crack, corrosion, spall, exposed reinforcement — and gives the engineer a list of candidates with confidence scores, while the trigger threshold is configured separately for each class.
A miss costs more than a false positive, so for critical classes the threshold is lowered, and extra marks are removed during review in seconds.
Survey time is reduced not by walking faster, but because the decision is made on site. Previously the cycle looked like this: capture, return, review images in the evening, follow-up questions to the crew the next day.
Now annotation happens directly as the engineer moves, the engineer sees which angles are missing and captures them while standing at the structure. On a medium-sized site this saves hours; on an extended one, a whole shift.
Repeat visits arise from two causes: an incomplete set of angles and questionable frame quality. A mandatory list of capture points together with sharpness and lighting checks at the moment of capture closes both.
The share of sites that require returning for re-capture drops by a factor — along with it goes the crew's second trip and repeat access approval.
A unified defect log changes the very framing of control.
Each entry is a location reference, class, geometry, and date; at the next survey the system matches it with the previous one and shows not "there is a crack" but how much its opening has grown over the elapsed interval. This is how deterioration dynamics emerge — the very reason surveys are conducted.
Operating modes: on-site capture or archive review
Where the images come from determines both model accuracy and the amount of engineers' work. A capture protocol during inspection provides a homogeneous stream: fixed angles, predictable lighting, and linkage to a structural element. On such data the model less often confuses a defect with glare, shadow, or a repair mark.
An archive of images from previous periods is a fast way to build volume, but the frames there are heterogeneous: different cameras, angles, and scales.
Therefore, at the start we calculate what share of the archive is suitable for automatic processing and what goes to manual annotation by engineers.
| Option | When it fits | Limitations |
|---|---|---|
| Capture according to protocol | New site, scheduled inspections | Requires capture discipline and staff training |
| Image archive review | A large photo array has already been accumulated, a quick start is needed | Different angles, no scale, some defects are not visible |
| Hybrid mode | There is an archive, but disputed joints need additional capture | End-to-end linkage of frames to the element is required |
| Manual annotation | Rare defect class, few examples | High labor intensity for engineers, low speed |
In practice, the hybrid mode turns out to be the working compromise: the archive provides statistics on typical defects, while the capture protocol covers what is indistinguishable in old frames.
All options rely on one scheme of linkage to a structural element, so they can be mixed and connected gradually, without rebuilding an already assembled system.
How AI diagnostics is built: implementation stages
The implementation stages go from auditing current control to handing over protocols — and the order here is critical.
If image annotation begins before defect classes are agreed upon, the annotated array will have to be redone, and that is the most labor-intensive part of the work.
- Control audit. We analyze how defects are detected now: who makes the decision, based on what features, how many checks an image undergoes before a conclusion.
- Agreement on defect classes. We fix a closed list: crack, spall, corrosion, exposed reinforcement, leak, deformation. Each class has a formal feature and a "normal / acceptable / critical" boundary so that assessment does not depend on shift.
- Image annotation. Frames from real sites under different lighting and angles are annotated according to the agreed classes; disputed and irrelevant ones are marked separately and reviewed with an expert engineer.
- Training. The model is trained on the annotated array, and part of the data is held out in advance — otherwise validation will show memorization rather than performance.
- Model validation. A run on held-out images and sites that were not in training, comparison with engineers' conclusions for each class: where similar classes are confused, where a human is needed.
- Protocol handover. Capture instructions, annotation rules, result processing procedure, score dispute protocol, and a retraining plan for new features.
The model remains a filter, not a verdict: low-confidence frames go to manual review — this is built into the process, not an exception.
Training image sets, models, and annotation protocols
The project result is not only a working service but also a package with which your team continues work without us. Below is what exactly remains with the customer, in what form, and with what reproducibility guarantees.
- Annotated image sets — defect frames with region coordinates and class, grouped by structure types and capture conditions.
- Data quality passport — for each set: volume, class distribution, share of frames with incomplete annotation, and gaps in capture conditions.
- Trained model — weights and inference settings, trigger thresholds by class, report on the validation sample with misses and false alarms separated.
- Annotation protocol — what counts as a defect, how to draw region boundaries, how to resolve disputed frames between annotators, and what to do with uncertain cases.
- Pre-annotation and validation scripts — format control, rejection of duplicates and corrupted files, automatic recalculation of metrics after the set is updated.
- Scheme for linking images to structures — how the element identifier and capture date are linked to the frame so the defect is tracked over time.
- Instructions for engineers — angle, lighting, and capture scale, frame formatting, procedure for an uncertain model response.
- Retraining procedure — on what data and with what metrics a new model is allowed to produce results.
Case study: defect control for reinforced concrete structures
Before implementation, defect control at a precast concrete plant relied on monthly inspections: an engineer walked the work sections, photographed cracks and spalls, and reports were filed in folders by date.
Up to a month passed between a crack appearing and being recorded, some areas fell out of inspection — the walkthrough physically did not cover the entire work front — and cracking in support zones was discovered after the fact.
How the flow is built
Capturing became continuous: frames come from inspections and from contractor crews, the system annotates them and leaves only areas with signs of cracking for review — empty and duplicate frames are filtered out before a person sees them.
The engineer receives a short queue: suspicious area, linkage to a structural element, and its history.
Decisions of "defect" or "false positive" are returned to annotation, and the model is periodically retrained on site images — in our implementation experience, this is exactly what provides robustness under its own angles and lighting.
Metrics before and after
Response to a new crack decreased from weeks to 1–2 days: the image stream is continuous. The share of frames reaching the engineer decreased by about six times — selection of suspicious areas is automatic, and the rest is closed without manual review.
Misses on the validation sample became less frequent: inspection no longer depends on whether a specialist reached a specific work section, and reinforced concrete structures under high load are captured frequently on schedule.
How photo-based defect detection differs from manual inspection
Manual inspection remains primary where a human makes the decision. An engineer sees the assembled joint, assesses gaps and traces of leakage — this does not get into the frame.
Automated analysis does not cancel the inspection; it removes the repetitive visual part from the engineer.
Cracks, spalls, corrosion spots, exposed reinforcement — features that are described formally and recognized reliably from an image.
Here automated analysis replaces continuous inspection: similar joints are checked identically, without fatigue and different lighting at the end of a shift.
Replacing inspection is valid under three conditions: the surface is observable, the defect has a formal feature, and capture follows one scheme with linkage to joint marking.
Then images in a series are compared with each other, and instrumental control shows defect growth over the period, not just presence in the frame.
Areas of responsibility are separated by protocol, not by interface. The model outputs a ranked list of candidates with linkage to the element and a confidence score — this is a draft defect statement.
The defect category and scope of work are confirmed by the engineer's conclusion: the algorithm does not sign the act.
Some tasks remain with instruments: hidden joints, seams under coating, internal cavities — the camera does not look there, and analysis only suggests where to go with measurement.
We bring the set of recorded features into line with standards (GOST and departmental regulations), so that the engineer's conclusion relies on a traceable set of images.
Technical concerns: accuracy, annotation, integrations
We describe capture requirements as a short checklist for the inspector, not as "perfect photos": the object entirely in frame, without blur, with a known reference for scale.
We train the model on images from real inspections — different lighting, shadows, glare, oblique angles. This provides robustness: in the presence of interference the system does not issue a false diagnosis but lowers confidence and sends the frame to the engineer.
Defect classes are not a constant: the reference list changes. We maintain annotation as a managed set, train a new category on accumulated images, and check previous ones on a held-out sample — this is how we catch degradation after retraining.
We deliver the result into the current control process: label, region in the image, confidence, and inspection priority.
Images are taken with a phone under different lighting — will the model cope?
Yes, if training was done under similar conditions. We normalize frames to a unified form, and add overexposure, noise, and shadows from structures to the sample.
If a condition goes beyond the known ones, the system marks the frame as unreliable instead of making a false inference.
What if defect classes are revised?
We migrate annotation to the new reference list, retrain the model, and run the validation set — checking whether previous classes have degraded. Rebuilding the solution is not needed: the annotation scheme and model weights change.
How will the result integrate into our control process?
The output arrives where engineers already work: inspection queue, marked regions in the image, export to reporting. Manual review is reduced by filtering out areas that are clearly serviceable.
Let's discuss the task and return with an estimate and plan
The initial review begins not with choosing a model but with inputs: the more precisely we understand the defect classes, capture conditions, and where the system will operate, the fewer assumptions there are in the timeline estimate. Below is what to send for the initial review and in what form we return with a work plan.
- Example images — 30–50 photos for each defect type: both clear and disputed frames, including poor light, glare, camera tilt, and blur. From them it is immediately clear whether the classes can actually be separated or the capture needs to change.
- A list of defects with descriptions of what counts as normal, what is critical, and what is an acceptable deviation. The annotation and trigger threshold depend on this boundary.
- Where the data will be stored and where the model should run: the customer's closed environment, cloud, or on-site capture. This determines the architecture and hardware requirements.
- Integration points: where the result goes — to an accounting system, mobile application, report, or operator interface.
- The cost of error in both directions: a missed defect and a false positive. This sets the target metrics we lead the system toward.
- Who on your side annotates and validates the result, how many people and hours you are ready to allocate. Annotation is the longest part of the project.
- Constraints on timeline and scope: whether we launch a pilot on one structure type or immediately across the entire fleet.
We return with a work plan: stages, the result of each stage, metrics by which we consider the goal achieved, and a timeline estimate with the assumptions it depends on.
If inputs are insufficient, we will say what to collect before starting, instead of building risks into the estimate.
