An inspector comes back from a site visit with dozens of photos, and then a longer task begins: sorting them, linking them to observations, and writing descriptions that can be reviewed. This is where I see a suitable place for artificial intelligence: an assistant for documentation that reduces this effort, not a substitute for engineering assessment.
A defined task before any talk of accuracy
In a concept for an inspection assistant, one could start by organising photos, linking them to the visit, and preparing an initial description of what is visible. Drawing conclusions about a structure's safety, or identifying the cause of a structural defect from a single photo, goes beyond what should be relied on in this way. Assessment needs context, on-site examination, data, and the professional responsibility of the specialist.
I would like the initial output to be editable and linked to the original photo. The inspector reviews the description, adds what was not in the frame, and corrects terminology where needed. AI thus becomes an aid to documentation, while the approved observation remains tied to the person who reviewed it and to the available evidence.
Capture quality is part of the trial
I propose simple photography instructions that state the purpose of each shot and ask for a general view plus a close-up of the detail when needed, while avoiding unnecessary personal data. It also helps to record the time and location of capture in the way approved for the task, keeping the original and preventing photos from different visits from being mixed up.
Testing should include poor lighting, blurred photos, obstructed elements, and varied angles. What matters is not just how many descriptions the system produces, but whether it can say that a photo is not enough, and whether it avoids treating an element's absence from the frame as evidence of its absence from the site.
Testing once is not enough. On 25 September 2026 the OpenAI changelog recorded a fix for an image-encoding bug that had affected the vision capabilities of the GPT‑6 Sol and GPT‑6 Luna models. In other words, a model's behaviour can change without any modification to our application, which is reason enough to retest after every update.
Criteria I suggest reviewing
- How closely the description matches what actually appears in the photo.
- How clearly the limits of the observation are stated, along with the parts that need on-site examination.
- The time the specialist needs to correct the draft.
- How stable the result is when the photo quality or the model version changes.
A limited trial could be run on photos cleared for use, comparing the drafts with observations written by specialists who have not seen the model's answer first. Errors are then reviewed according to their impact, rather than rolled into a single percentage that could hide a significant professional error.
Useful progress starts with a task that can be isolated and measured; the output is then linked to its context and to human review before it goes into any official report or action.