Structural Engineer Inspection Report: Photos and Notes to a Draft With AI

Number every photo on site, tie each note to a photo ID, then have AI describe only what is visible and draft the observations section from that register. The engineer writes the opinion, checks every sentence against its photo, and signs: AI never decides cause, severity or safety.

A photo shows pixels, not structure. A model cannot see behind finishes, cannot tell whether a crack is moving, and cannot read a width unless a scale is in the frame. The workflow below keeps what was seen apart from what the engineer concludes, and every example describes an invented sample site, not a real one.

Follow me on Instagram@sagnikteaches

Capture rules that decide how good the draft can be

The draft can only be as good as the record. Most of the work is done before anyone opens an AI tool, and these habits cost a few minutes on site:

Connect on LinkedInSagnik Bhattacharya

• Shoot each defect in a sequence. A wide shot that shows where it is, a mid shot with context, and a close-up with a scale in frame, such as a ruler or a crack-width comparator card. Add a fourth from another angle if the first three could be misread.
• Say or type the photo ID with a note straight away. "P014, rear elevation, above kitchen window, stepped crack, 5 mm on the card at the head." A note made an hour later is a guess.
• Fix a viewpoint convention. "Left and right as seen standing outside, facing the elevation." Without it, left and right are the commonest silent error in any draft.
• Photograph what you could not reach. A loft hatch painted shut, a locked outbuilding, a wall hidden by stored items. These photographs become your limitations paragraph.
• Keep location tagging off, and keep people and neighbouring properties out of frame where you can.
• Talk in observations. "I can see a crack 5 mm wide on the card" is reusable. "That looks bad" is not.

A one-line template at the top of the field notes keeps the convention and the access details with the job:

Subscribe on YouTube@sagnikteaches

Site ref: ____  Date/time: ____  Weather: ____  Access given by: ____
Convention: left and right as seen from outside, facing the elevation
Photo | Location (elevation, floor, room) | What I see (facts only) | Measurement and tool | Not accessed / limits

Build the photo register before any AI sees the report

Copy the photos into a job folder and rename them P001, P002 and so on in capture order. Zero-padded IDs matter later, when you search for them. Then build a register, one row per photo or group of photos, in a spreadsheet or a Word table. Voice notes can be typed from dictation or transcribed by a tool, but compare the result with what you meant before it goes in the register. Here is an illustrative slice for an invented two-storey house:

The register is the single source of truth for everything that follows. It holds the engineer's facts, measurements and "not accessed" entries. The AI works from it and may not add to it.

Stage 1 prompt: describe the photo and nothing else

Upload a batch of eight to ten photos, each with its ID, and ask for neutral descriptions. The point of this stage is to find out what a reader would see, and to give the engineer something to compare against their own note. A model's description of a photo is a cross-check on your note, not a replacement for it.

Describe what is visible in each attached photo for an inspection record.
Photo IDs are in the file names. Convention: left and right as seen standing outside, facing the elevation.

Rules
- Describe only what you can see. No cause, no severity, no advice, no safety opinion.
- Use "appears to" for anything uncertain.
- Do not estimate widths or distances. If a scale is in the frame, say what you can read from it and how sure you are.
- For each photo give: (1) Visible; (2) Cannot be determined from this image; (3) Things that could be mistaken for defects, such as shadows, paint lines, reflections and stains.
- 90 words or fewer per photo.

An illustrative response for P003: "Visible: a brick wall in stretcher bond with a stepped diagonal crack running from the top corner of a window opening through the mortar joints. A printed comparator card lies against the wall near the top of the crack. Cannot be determined: the reading on the card, because the print is not legible at this resolution; whether the crack is old or recent; whether the wall is out of plumb. Possible confusions: a shadow under the window soffit and a paint edge near the sill."

The engineer compares that with the register. The description agrees on the crack and its path, and it cannot read the card, so the 5 mm figure comes from the site note and not the image. If the model had written "approximately 5 mm", the engineer would strike it, because no legible scale supported it. A description that adds anything the register lacks is a flag, not a finding: either the note was incomplete or the model invented it, and you need to know which.

Vision traps: what looks like a defect and may not be

Models describe what is plausible, not always what is there. These are the confusions to watch for in the Stage 1 output and in your own reading of the photos:

Left and right deserve their own line. A model has to guess your viewpoint, and a wrong guess is easy to make and easy to miss. Put the convention in every prompt and check each orientation word in the draft against your notes.

Stage 2: draft the observations in observation-only wording

Now give the model the register, not the photos, and ask for the observations section. Observation-only wording says what was seen, measured or not accessed, and stops there. Use "was observed", "appeared", "was measured", "was not accessible". Avoid "failed", "defective", "unsafe", "structurally sound", "caused by" and anything that predicts. Those words are opinions, and opinions belong to the engineer.

An illustrative before and after shows the job. The engineer's raw note reads "crack bad over kitchen window, prob settlement, 5mm". The draft the model returns from the register is: "A diagonal stepped crack, up to 5 mm wide (measured with a crack-width card, P003), was observed in the rear elevation brickwork above the kitchen window, narrowing to under 1 mm near ground level (P007). The cause was not determined at this inspection." The words "bad" and "prob settlement" are gone, the measurement has a photo reference, and the last sentence says what the report is not claiming. If the engineer does want to offer a view on cause, that sentence goes in the discussion section, in the engineer's words.

Draft the OBSERVATIONS section of a structural inspection report from the register below.
Use only the register. Observation-only wording: was observed, appeared, was measured, was not accessible.
Never use: failed, defective, unsafe, sound, caused by, due to, will, risk of.
Give each observation a number and cite photo IDs in brackets after every sentence, for example (P003).
Keep every measurement exactly as written, with the tool where given.
After the observations, output two lists:
1. Observations NOT made (areas in the register marked not accessed).
2. Conflicts: any place where two register rows or a row and its photo description disagree.
Do not write a discussion, conclusion or recommendation.

Register:
[paste rows]

The second list is the most useful one. A conflict list such as "P014 notes 2 mm; the Stage 1 description says hairline" is a prompt to look at the photo again. Treat the list as a to-do for the engineer.

After the draft comes back, run a find on the banned words. A quick check for "caused", "due to", "failure", "unsafe", "sound" and "will" catches most slips before a human reads a line. The wider rule for what AI may and may not touch in structural work is in ChatGPT for structural engineers: what is safe and what never is.

Limitations the draft must carry

The limitations section should not be written fresh each time. Keep your firm's standard wording, agreed with your insurer and your solicitor, and have the draft add only the job-specific list from the register's "not accessed" rows. Here is a blank version and an illustrative filled one for the sample:

Standard (firm's wording, do not edit):
This report is based on a visual inspection of the parts of the building accessible on [date].
No part of the structure was opened up; no testing or calculations were carried out unless stated.
Photographs are a record of conditions on the day and are not measurements.

Job-specific (from the register):
- Roof space: not accessed; hatch painted shut (P030).
- Foundations below ground: not inspected.
- [other rows marked not accessed]

For the sample, the job-specific part reads: "The roof space was not accessed because the hatch was painted shut (P030). Foundations below ground were not inspected." Compare that with a vague version: "Some areas were not accessible." The vague line says nothing a reader can use and hides what you did not see. Specific limits protect the client's understanding and the engineer.

Similar discipline appears in the mould inspection report template with findings, photos and limits, which makes a good comparison for how another trade words the same boundary.

The traceability check: no photo, no sentence

Once the observations are drafted, check them against the register with a short list of rules. Each is mechanical, so a junior colleague can run them and the engineer can read the result.

1. Every observation sentence cites at least one photo or note ID. A sentence with no reference is either from memory or from the model, and neither belongs in the record.
2. Every cited ID exists in the register and shows what the sentence says it shows.
3. Every photo is accounted for. Photos not cited in the observations go to the appendix as a record, or the engineer decides they reveal a missed observation.
4. Numbers and units match the register. Millimetres stay millimetres. A "5 mm" that became "5 cm" is the classic slip.
5. Orientation words match. Check every "left", "right", "front", "rear", "upper" and "lower" against your convention.
6. The limitations list matches the "not accessed" rows and nothing is listed as inspected that the register says was not.

Rule 3 can be run with a spreadsheet formula. Put the draft's sentences in column H and the photo IDs in column A. Then in column B, this works in both Excel and Google Sheets, because COUNTIF accepts wildcards:

=IF(COUNTIF($H$2:$H$80,"*"&A2&"*")=0,"Not cited","Cited")

Zero-padded IDs (P003, not P3) stop "P3" matching inside "P30". Anything marked "Not cited" goes to the engineer with the register line beside it. Run the same check in reverse by listing the IDs each sentence cites and confirming that each exists.

The check finds gaps; the engineer decides what they mean. A photo of a downpipe discharging against a wall, never mentioned in the draft, could be irrelevant or could be the cause of the staining. Only a person who stood there can say which.

What stays with the engineer

The draft covers description. Everything below remains the engineer's, and no prompt should reach into it:

• The discussion of what the observations may mean, including cause.
• Severity, urgency and any statement about safety.
• Conclusions and recommendations, with their timing and conditions.
• Decisions on further investigation, monitoring or specialist advice.
• The final read of the whole report against the photos, and the signature.

There is one safe use of AI beyond description: asking what the record lacks. Give the model the register and the draft observations and ask, "What would a reviewer want to see that this record does not contain?" It might point out that there is no photo of the other end of the same wall, no note on the age of the extension, and no record of the drains. Every item is a prompt for the engineer to think about, not a conclusion, and the engineer decides what, if anything, to go back for.

A short sign-off list closes the process. Before signing, confirm that: every observation sentence traces to the register; the numbers and orientation words were checked against the notes; the banned words search is clean; the limitations list matches what was not accessed; the discussion and recommendations are the engineer's own words; and the prompts, outputs and register are saved with the job. For the sibling workflow of writing the client-facing front page, see the plain-English summary you can check, which uses the same traceability idea on a finished report.

A worked example from capture to sign-off, with times

Here is an invented site and illustrative numbers, to show what the workflow costs and where the corrections land. An engineer inspects a two-storey semi-detached house with rear cracking. The visit produces 62 photos and nine voice notes, and the report needs observations, limitations and recommendations.

That is about two hours and forty-five minutes in the office. Writing the same report from raw photos and notes might take four hours, but the saving is the least interesting number. The count of corrections is the better measure of whether the workflow is working. In this sample the engineer fixed six things in the draft: two left and right slips, a shadow described as a crack, a width the model had estimated, a "caused by" that crept into one observation, and a date typed in the wrong order. None was dramatic. Every one would have gone into a signed report if the traceability check had been skipped.

Keep a log of those corrections across jobs. If the same kind of slip recurs, change the prompt or the capture habit that caused it. If the log goes quiet, check that the checks are still being done, not that the model has become perfect.

For the field-capture side of this workflow in other trades, AI in the construction field: photos, voice notes and punch lists and using AI in surveying: site notes and photos to a draft report offer ideas you can adapt, and drafting a schedule of condition from photos uses a similar register-first approach.

Privacy, uploads and which plan to use

Photos of a client's building are client data. Strip location data (turn off tagging at capture), keep names and addresses out of file names, and leave people and neighbouring properties out of frame. Upload only what the stage needs: Stage 1 needs the photos, while Stage 2 needs only the text register.

Client photographs belong in a business workspace, not a personal chat account. On ChatGPT Business, Claude Team and Microsoft 365 Copilot, business content is not used for training by default, whereas a personal plan usually needs a privacy toggle switched off, and its name keeps changing. Expect about $20 a seat a month on annual billing for the first two ($25 month to month), with at least two seats. Upload caps differ by assistant and plan, and the figures I found are in the questions below. A phone photo is often several megabytes, so a batch of eight to ten images with their IDs stays comfortably inside them; recheck the vendor's help page if a batch is refused.

Keep the originals in your own storage and save the prompts, outputs, register and checks with the job. If a client or insurer asks how a report was produced, that file is the answer. It is also sensible to ask your professional indemnity insurer whether it has views on AI-assisted drafting before you use this routinely, and to mention in your terms of engagement that drafting tools are used under the engineer's review.

Questions engineers ask about photo-to-report drafting

Can AI measure a crack width from a photo?

Only if a legible scale is in the frame, and even then the engineer should record the measurement on site with a gauge or comparator and treat the image as a record. A model estimating width from a photo with no scale is guessing. Tell it never to estimate, and put the measured figure from your notes into the register yourself.

How many photos can I upload in one go?

Limits change, so check the current help pages. When I checked in early November 2026, claude.ai took 20 images per message at up to 10 MB each, and ChatGPT's file-upload FAQ gave free plans three uploads a day, paid plans up to 80 files in three hours and images up to 20 MB each. A practical batch is eight to ten photos with their IDs per request.

Can AI tell me whether a crack is structural?

No, and it should be told not to try. A photo cannot show whether a crack is moving, what is behind the finish, or how load travels through the wall. Classifying cracks is the engineer's judgement from the site, the measurements and the history. Use AI for neutral description and for finding gaps in the record, never for severity or cause.

What about location data and people in the photos?

Turn off location tagging in the camera for client sites, keep people and neighbouring properties out of frame where you can, and avoid client names in file names. Phones often embed location in the file, and you may be uploading to a third-party service. Use a business plan whose defaults do not train on your content, and keep the originals in your own storage.

Further reads

• Roof Inspection Reports: Photos to a Customer-Ready Report With AI — The same photo-to-report idea for roofs, with customer wording.
• Chimney Inspection Report: Can AI Turn Camera Findings Into Plain English? — Turning camera findings into plain English for a client.
• Can AI Write an Architect's Snagging List From Site Photos? — Site photos turned into a numbered list of items.
• Damp Survey Report: Write Findings and Quote Lines With AI — Write findings and quote lines from a damp survey.
• Thermal Imaging Survey Report: Turn Scans Into Plain-English Findings — Another image-heavy report where findings need careful wording.
• AI for Consulting Engineers: Fee Proposals and Reports, Not Calculations — Fee proposals and reports for engineers, without calculations.
• Turning On-Site Voice Notes Into Job Sheets and Quotes With AI — Voice notes on site turned into structured job sheets.
• Architect Site Visit Report: Notes and Photos to a Clear Report With AI — A worked notes-to-report example for architects: observation, instruction and action columns, photo captions, and a rule that keeps unseen items out.
• Sewer Camera Inspection Reports: From Defect List to Customer Summary — How a drain survey firm turns coded camera findings into a customer summary with AI, with a prompt, a worked defect list and the surveyor's checks.
• Structural Engineer Fee Proposal: Scope and Assumptions Drafted With AI — A worked fee proposal with stages, assumptions, exclusions and variation rates, plus prompts that draft and stress-test each section.
• Can AI Help Write an Arborist Report? What Stays With the Arborist — Use AI to turn tree survey notes into a readable report draft while measurements, risk ratings and advice stay with the arborist.
• Fire Door Inspection Report: AI Drafting and What You Must Record — AI can tidy the layout and wording of a fire door report from your notes. The findings, measurements and sign-off stay with the inspector.
• Loss Adjuster Software: Claim Files and Reports, and Where AI Fits — What a small adjusting firm needs from claims software, with verified prices and a clear line on where AI drafts and the adjuster signs.
• Using AI in Environmental Consulting: Draft Site Report Sections — Prepare site-report sections from controlled notes and lab results, with a traceable check of every number and conclusion.
• How Engineering Firms Are Using AI: Six Jobs and Their Limits — Six jobs engineering firms give AI, rated for effort and risk, with the evidence behind each and the uses to leave alone.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Anthropic's vision documentation and OpenAI's file-uploads FAQ, read in early November 2026, and vendor privacy defaults recorded for ChatGPT Business, Claude Team and Microsoft 365 Copilot. The site, photos, notes and register entries are invented samples, not from any real project.