AI Adoption GuideConstructionInspect
Defect Root Cause Classification
LLM classifies defects by root cause, including design, material, and workmanship, across the project defect log to surface systemic issues.
Construction processBidAwardPlanMobilizeBuildInspectHandoverClose
By Don, DoneThat’s AI coach · updated
A proposed bucket is not a root-cause finding
The useful output is a proposed cause bucket (design, material, or workmanship) plus cites back to the defect record. Quality still owns the call. If the log does not contain enough evidence to support a bucket, the field stays empty. An empty field is correct when notes, photos, and location data do not point to a cause.
Do not treat the bucket as a liability finding. Commercial teams can use the sort to see whether defects are clustering. They cannot use an unconfirmed bucket as the basis for a backcharge, a withholding, or a claim.
Construction defect logs already live in project systems such as Procore and Autodesk platforms. The classification job is to read those records as they stand, not to fill gaps with a plausible story. Pair this sort with the open defect aging monitor so aging and cause stay separate jobs.
How to classify the log into design, material, and workmanship
Walk each open and recently closed item. Extract only what the record itself states. Map those statements to one of three buckets when the evidence supports it. Leave the rest unclassified.
For each item, read the identifier, location, description, trade, date raised, status, linked photos or markups, inspector notes, and any referenced drawing, specification clause, or test result. Procore and Autodesk hold those fields in different layouts. Read the fields. Do not assume the platform has already decided a root cause.
A description that says "water staining at window head, Level 4, Grid C" is a symptom. A note that says "sealant omitted at head flashing, photo 14" is workmanship evidence. A note that says "head flashing detail omitted from architectural set Rev C" is design evidence. A note that says "sealant batch failed adhesion test, lab report attached" is material evidence.
Assign at most one primary bucket when the cites are consistent. If the record points in two directions, do not pick the more convenient one. Flag the conflict and leave the primary bucket empty, or record both candidates as unresolved for quality.
Cite the fields you used: the item identifier plus the specific note, photo reference, drawing number, or test result. Without a cite, the bucket is an opinion. Hand the proposed buckets to quality. Quality confirms, rejects, or returns the field to empty. Confirmation is a human step. The model does not close the item and does not notify a subcontractor.
Workmanship means the installed work does not match the issued detail or the specified method, and the record shows that mismatch. Design means the issued information is wrong, missing, or conflicting, and the record points to a drawing, specification, or RFI. Material means the product as supplied failed a stated requirement, with a test, batch, or supplier note in the log.
A photo of a stain is not a root cause. Use AI defect detection from site photos to add records to the log, then classify only when those records contain cause evidence. Aging is not a cause. An item can sit for months and still have no support for a bucket.
One leak, three buckets, one empty field
This is an illustrative walkthrough of a single log item, not a project case study.
A commercial fit-out raises item D-441: "leak at Level 2 tea point, staining on ceiling tile below." Trade tagged plumbing. The photo shows a wet tile and a copper pipe above the ceiling. The description is one sentence. The inspector left no drawing reference.
If you stop there and bucket it as workmanship, you have invented a cause. The log shows a leak and a pipe. It does not show who installed what, whether the joint was specified, or whether the pipe is the product that was ordered.
Now add three different record states, one at a time. Only one would be true for a given item.
State A, workmanship: the plumber's close-out note on the same item says the compression fitting at the branch was not tightened, and the joint was re-made. Photo 2 shows the fitting before the remake. Proposed bucket: workmanship. Cites: D-441 note already stored in the log, plus photo 2. Quality still walks the ceiling and confirms the joint was the leak path.
State B, material: the same item later attaches a supplier notice that the batch of fittings was withdrawn for a cracked olive. Proposed bucket: material. Cites: D-441 attachment (the supplier notice) and the batch number recorded on the item. Quality confirms the withdrawn batch matches what is in the ceiling. If the notice is for a different SKU, the bucket goes back to empty.
State C, design: an RFI linked on the item states that the tea-point waste was detailed to run through an unventilated ceiling void with no tray, contrary to the hydraulic engineer's mark-up on Rev B. Proposed bucket: design. Cites: D-441 linked RFI and drawing Rev B mark-up. If Rev B does not show the conflict the note claims, you do not invent a design error. Empty stays empty.
If none of A, B, or C is in the log, the correct output is no bucket. Clustering every Level 2 leak into workmanship because leaks are often workmanship is the failure this method exists to stop.
Failure modes that turn a useful sort into a fight
Calling every leak workmanship. Water follows gravity. The presence of water does not identify the installing trade as the cause. If the log only records the symptom, classification stops.
Using the bucket as a backcharge. A proposed workmanship tag is not entitlement, not a variation, and not proof the subcontractor is in default. Keep this sort away from variation claim entitlement analysis until quality has confirmed the cause and contracts has confirmed the clause. Mixing the two is how a helpful dashboard becomes a dispute exhibit.
Inventing a design error the drawing does not show. A model will complete a plausible sentence such as "flashing not detailed." If the issued section shows the flashing, the bucket is wrong even if the flashing failed on site. The cite must be to the drawing that is actually in the record. If nobody attached the drawing, you cannot complete the design story from general knowledge of how windows should be detailed.
Reject a bucket from the trade tag alone, from the loudest email rather than the record, from the first item at a grid applied to the whole location, or from filling empty fields so a dashboard looks complete.
Systemic issues are the reason to classify at all. Confirmed items that share a cite, the same missing flashing detail or the same omitted sealant step, let quality raise a design query or change a hold point. Those patterns need confirmed buckets, not a forced complete set. Feed lessons learned knowledge base extraction only after quality accepts the cause. Do not write a lesson from an unconfirmed bucket.
What quality confirms before the bucket sticks
Quality confirms that the cite exists in the defect record and means what the proposal says it means. A photo of a stain is not a photo of a loose fitting.
Quality confirms that the bucket matches the evidence type. If the evidence is mixed or missing, the field stays empty.
Quality confirms that the bucket is not being used as a finding. The item remains a defect until someone inspects the close-out. Classification does not assign blame, does not start a backcharge, and does not replace the inspection.
Items with empty buckets stay visible until someone adds a note, a photo, or a drawing reference that can support a cause. Items with confirmed buckets can be grouped so the quality lead sees clusters instead of a flat log. The commercial lead can look at those clusters to decide where to put attention. If a cluster later becomes a claim, the claim file needs the drawings, the contract, and the inspection record, not the proposed bucket from the model.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first