Vision on field photos: drafting the finding for review

A turnaround produces thousands of photos. A CUI program produces tens of thousands. Most of them are never looked at again after the shift they were taken on, and the ones that are get reviewed by a tired inspector at the end of a twelve-hour day. Vision models can look at every one of them the same way, at any hour, and propose what they show. The question for an integrity program is not whether the model can spot corrosion in a photo. It is what happens to that proposal: whether it becomes a finding by itself, or becomes a draft that a qualified person reviews, revises, and signs. This paper argues for the second, and describes what the draft and the record must carry for it to work.

What can a vision model actually see in a field photo?

A vision model applied to inspection photos does a bounded set of things well:

• Classify a visible condition. General corrosion, pitting, coating breakdown (blistering, disbondment, chalking), staining that indicates CUI, mechanical damage, missing insulation or cladding, leaks or weeps, supports and clamps out of position.
• Localize it. Where in the frame the condition is, and, with a reference visible, roughly how extensive.
• Describe it. A plain description an inspector can start from.
• Compare. Given two photos of the same component from different dates, note what changed.
• Read. Tags, nameplates, gauges, and marked-up drawings in the frame.

It also has clear limits. It cannot measure wall thickness from a photo. It cannot see under coating or insulation; it can only flag the external indicators that the CUI program already looks for. It can be fooled by lighting, wet surfaces, shadows, and unfamiliar equipment. And it has no idea what the component is unless the photo carries that context. Everything that follows depends on treating the model's output as a well-informed first draft from someone who has never been to your site, which is what it is.

Why should the model draft the finding rather than file it?

The inspector of record owns the classification and the disposition. Under API 510, API 570, and API 653 the inspection is performed and evaluated by a qualified inspector; the standards do not contemplate a finding that no qualified person evaluated. That settles the compliance question. The practical argument is stronger:

• Coverage without abdication. The model gives every photo a first pass, including the routine ones nobody reviews. The inspector's attention goes to the photos where the model saw something, and to a sample of the ones where it did not.
• Consistency. The same condition gets the same proposed classification whether it was photographed at 08:00 or 03:00, by a senior inspector or a helper.
• Speed at the right step. A populated draft (classification proposed, location proposed, description drafted, photo attached) is faster to correct than a blank finding is to write. The time saved is the inspector's, and it goes back into judgment.
• Correctability. When the model is wrong, the inspector fixes it before it becomes a record, and the fix is itself data about the model.

A finding that the model files without review has the opposite properties: it enters the asset history with a classification nobody qualified has confirmed, it feeds the RBI, and it is discovered, if at all, at the next event. Drafting is the design that gets the coverage without the liability.

What should a drafted finding carry?

The draft has to give the inspector enough to decide quickly, and the record has to keep enough to show what happened. A drafted finding carries:

• The asset context. Asset node, component, and inspection the photo was captured against. Inherited from the photo, not inferred by the model.
• The evidence. The photo or video segment, with capture time, author, and location if recorded.
• The proposal. Classification from the site's own finding taxonomy, proposed severity, a description, and, where it applies, the suspected damage mechanism.
• The uncertainty. A confidence indication, and an explicit statement of what could not be determined (extent, depth, condition under coating).
• Alternatives. Where two classifications are plausible, both, so the inspector chooses rather than accepts.
• The review state. Draft, awaiting review, confirmed, revised, or rejected, with the reviewer's identity and time.

After review, the record shows the model's proposal and the inspector's final values side by side, or at least the fact and content of each change. That is what lets an auditor answer "who classified this finding" with the inspector's name, and what lets the site measure how often the model needed correcting and on what. The visual inspection workflows this drafts into are described on the intelliINSPECT page, and the coating-specific ones on intelliPAINT.

Where does the inspector stay in the loop?

At three points, and the design should make each of them explicit rather than assumed.

Before the draft is visible as a finding. The model's output lands as a draft, in a state that the asset history, the RBI inputs, and any report exclude. Nothing downstream consumes a draft.

At review. The inspector sees the photo, the proposal, and the context, and takes one of a small number of actions: confirm as proposed, revise (change classification, severity, description, mechanism) and confirm, or reject with a reason. Each is a recorded transition with identity. Rejections with reasons are as valuable as confirmations, because "not corrosion, it is product staining on the cladding" is what the model most needs to learn about your site.

At sign-off. The finding enters the record with the inspector as its author of record. The workflow that governs findings generally (submit, approve, reject, hold, and owner sign-off) applies exactly as it would to a finding typed from scratch. The model never holds a role in that workflow.

The model is a drafter, which is a role that already exists in most programs: the helper who fills in the form and the inspector who checks and signs. The difference is that the drafter is consistent, tireless, and wrong in predictable ways that can be measured.

How does video condition assessment fit?

Video is where coverage arguments become strongest. A walk-down clip along a pipe rack, a drone pass around a column, or a crawler run through a duct produces minutes of footage that no inspector will scrub frame by frame. Video condition assessment applies the same analysis across the clip:

• Segmenting the footage into stretches of similar condition and flagging where condition changes.
• Proposing candidate findings at timestamps, each with a still, a proposed classification, and a location in time along the run.
• Summarizing the condition along the run, so the inspector reads a list of candidates rather than watching the clip.

The same rules apply. Each candidate is a draft. The inspector confirms, revises, or rejects. The clip stays attached to the asset as evidence, and the confirmed findings reference their timestamps in it. Where the video was captured against a specific asset or run in the inspection app, the candidates inherit that context; where it was not, the inspector has to place them, which is slow enough that it argues for capturing in context in the first place. Video captured in the platform's field app runs up to 120 seconds per clip by default, which suits component-level capture and encourages clips that are attributable to a place.

How do you evaluate the model before trusting its drafts?

Vendor benchmarks on public images are irrelevant to your site. The evaluation that matters is on your own photos:

1. Assemble a labeled set of site photos with inspector-confirmed classifications, covering your equipment, your coatings, your lighting, and your typical false alarms (staining, shadows, wet insulation).
2. Run the model and measure agreement with the inspector's classification, missed conditions, and false alarms, by condition type.
3. Check the calibration. When the model says it is confident, is it right more often? If not, the confidence indication is noise and should not be shown.
4. Track the correction rate in production as a running score: what fraction of drafts are confirmed unchanged, revised, or rejected, by condition and by site.
5. Repeat whenever the model changes.

A model that is right often enough to save the inspector time, and wrong in ways that the review step catches, earns a place as a drafter. A model whose drafts are corrected most of the time costs more attention than it saves. The evaluation tells you which you have. The broader AI layer this analysis belongs to is described on the Spectra page.

How intelliSPEC handles it

Spectra's vision analysis reads photos and performs video condition assessment on footage. Photos and video captured in the field app bind to the component and the inspection at capture time, so what the model looks at is already placed on the asset rather than sitting in a camera roll.

A finding proposed by Spectra is a create action, and create and update actions through the AI layer require approval by default, so a proposed finding becomes a record only when a person with the role approves it. The platform's workflow transitions (submit, approve, reject, hold, resume, reopen, and owner sign-off) carry the identity of the person who acted. Findings are structured records with classification, severity, location, and status as fields, and damage mechanisms are first-class records that the API 580/581 RBI scoring reads, so a confirmed finding changes what downstream sees while a draft changes nothing. The CUI wizard family (visual, suspect area, insulation removal, NDE UT, advanced NDE, repairs, recoat, ITP, and frequency assessment) is where CUI indicators drafted from photos are followed through.

Spectra runs groundedness and red-team evaluation suites. Approval requests escalate after 5 minutes and expire after 10, mutations are written to an undo log, and every record change is an event in the hash-chained audit trail with actor and timestamp, never auto-deleted. That is the rule that keeps a drafted finding from becoming a filed one without a signature.