A quality engineer walks a floor near substantial completion and the work is full of small failures and a few large ones: a misaligned door, a missed firestop penetration, a slab that is out of tolerance, a finish that does not match the approved sample. Two documents come out of that walk. The punch list catalogs the items that must be fixed before closeout, and the non-conformance report, the NCR, documents work that does not conform to the contract documents, often with a suggested root cause so the same failure does not recur. AI now generates both: computer vision reads the jobsite capture and proposes punch items, and generative AI drafts NCRs with suggested root causes, a large time saving on tedious QA documentation. But two things make this dangerous at face value. The root-cause suggestion is a candidate, not a finding, because correlation is not causation, and the punch items are reads that can be false positives or false negatives against the actual state of the work. An NCR on a structural deficiency is a different animal from a punch item on a paint scuff. This lesson is about building the NCR-and-punch generation so the AI proposes and the human verifies, with the verification proportioned to the consequence, because the QA decisions are the human's and a wrong root cause or a missed structural non-conformance is not a documentation error but a quality failure.

What the AI Generates and Why It Helps

QA documentation near closeout is high-volume and tedious, which is exactly where AI's drafting and reading capabilities earn their place. On the punch-list side, computer vision reads the jobsite capture, the same 360 capture used for progress, and proposes punch items: it flags the misaligned door, the unfinished caulk joint, the missing cover plate, the deviation from the approved condition, producing a candidate punch list across the captured areas faster and more comprehensively than a human walk-and-write. On the NCR side, generative AI drafts the non-conformance report: given an identified non-conformance, it writes the description, references the relevant specification section, and proposes a root cause, the explanation of why the failure occurred, drawn from patterns in the data. Together these turn the QA engineer's documentation burden, walking, photographing, writing up each item, into a review-and-verify task on AI drafts.

The value is the same value AI provides across the program: it processes the volume and drafts the documentation so the human does not start from a blank page on every door and every penetration. A closeout punch list can run to hundreds of items, and writing an NCR with a researched root cause is slow, so the AI's draft is a real acceleration of the QA paperwork, letting the engineer concentrate judgment on the items that matter rather than the mechanics of documentation.

But the value comes with the engine's characteristic limits, and the limits are where this lesson lives. The computer-vision punch read has the same ceiling as the progress read: it reads visible, clear conditions well and ambiguous ones poorly, so it produces false positives, flagging something acceptable, and false negatives, missing something that is not. The generative root cause is a plausible explanation, not a verified finding: it is drawn from correlation in the data and may be wrong about why the failure occurred. So the AI's drafts are candidates, the punch items candidate deficiencies and the root causes candidate explanations, and the QA engineer's job is to verify them, because the documentation that goes into the record and drives the corrective action is the human's quality judgment, not the AI's draft.

The Root-Cause Suggestion Is a Candidate, Not a Finding

The most seductive part of the AI's output is the root cause, because a confidently written explanation of why a failure occurred reads like a finding, and it is not. The model proposes a root cause by pattern: it has seen that a certain deficiency often accompanies a certain condition, so it suggests that condition as the cause. But correlation is not causation, and the suggested cause may be a co-occurring factor, a plausible-but-wrong story, or a surface symptom rather than the actual root. An NCR that records the wrong root cause is worse than useless: it directs the corrective action at the wrong target, so the same non-conformance recurs because its actual cause was never addressed, and the record now contains a false account that can mislead the next person who reads it.

So the root-cause suggestion has to be treated as a candidate the human investigates, not a finding to record. The QA engineer takes the AI's suggested cause as a hypothesis to check against the actual conditions, the sequence of work, the people involved, the materials used, and confirms it, refines it, or replaces it with the actual root cause their investigation finds. This is decide-then-draft inverted into investigate-then-record: the AI drafts a candidate cause, the human determines the real one, and the NCR records the human's verified root cause. The suggestion gives the investigation a starting hypothesis, which can speed it, but does not substitute for it, because a root cause is a causal claim and the AI cannot establish causation from correlation.

A generative root cause is a hypothesis drawn from correlation, not a finding established by investigation, so the QA engineer takes it as a starting point to check, never as the cause to record, because an NCR with the wrong root cause sends the corrective action at the wrong target and the failure recurs.

This matters most where the root cause drives a real corrective action with real cost. If an NCR's root cause is recorded wrong and the corrective action follows it, the project spends money fixing the wrong thing while the actual cause persists, so the recurrence the NCR was supposed to prevent happens anyway. The AI's root cause is the cheapest part to draft and the most dangerous to record unverified, because its wrongness is not visible in the document, a wrong cause reads as confidently as a right one, and only the human's investigation can tell them apart. This is the metric-as-signal discipline applied to causation: the suggestion signals where to look, the human determines what is true.

Punch Items Must Be Verified Against Reality

The computer-vision punch read produces candidate deficiencies, and like any vision read it has false positives and false negatives against the actual state of the work, so the punch items must be verified before they drive rework. A false positive is the vision flagging something acceptable as a deficiency: a finish the model reads as flawed that is within tolerance, a condition that looks wrong from the camera angle but is correct. If false positives go onto the punch list unverified, the project chases needless rework, wasting money and eroding the trades' confidence in the punch list. A false negative is the vision missing a real deficiency: a defect the model did not recognize, a condition the capture did not show clearly, which is the more dangerous error because a missed deficiency does not get fixed and passes into the finished building.

So the punch verification runs both directions, and the false-negative is the one to hunt. A false positive is caught when the trade or the QA engineer looks at the item and sees it is acceptable, so it costs a verification look and is corrected before rework, an annoyance but recoverable. A false negative, the missed deficiency, is not on the list to be caught, so it can pass through unless the human's own inspection finds it. The verification therefore cannot rely on the vision's list alone; it has to include the human's inspection of the areas and conditions the vision reads poorly, where the missed deficiency hides. The QA engineer verifies the candidate punch items against the actual conditions, removing the false positives and, critically, inspecting for the false negatives the vision did not flag, because the punch list's purpose is to catch the deficiencies before closeout and a missed one defeats that purpose.

The verification against reality is the QA engineer's quality judgment, irreplaceable for the same reason the super's walk was on the pay app: the actual state of the work is the ground truth, and the vision only infers it from imagery. The engineer knows the finish the vision flagged matches the approved sample, knows the slab edge the vision read as clean is actually out of tolerance where the capture did not show it, so the inspection corrects the vision's read in both directions. The candidate punch list accelerates the documentation, but the verified punch list is the one that drives the rework, because a punch list is a quality instrument and its items are quality findings the engineer owns, not vision reads taken at face value.

The QA Decisions Are the Human's

Underneath both the root-cause and the punch verification is a single principle: the QA decisions are the human's. Whether a piece of work conforms to the contract documents, whether a deficiency exists, what its root cause is, whether it must be corrected, these are quality judgments the QA professional makes, not the AI. The AI drafts the documentation, reads the capture, proposes the causes, but the determination of conformance and non-conformance is the human's quality call, because the human is accountable for the quality of the work to the owner, the designer, and the building's future occupants, and that accountability cannot be delegated to a drafting and reading tool.

This locates the AI correctly as the QA engineer's assistant, not replacement. The temptation, under closeout pressure, is to let the AI's drafts stand as the QA record, treating the candidate punch list as the punch list and the suggested root causes as the findings, but that delegates the quality judgment to a tool that cannot make it, so the record becomes a set of unverified reads and plausible guesses rather than the engineer's verified findings.

So the principle keeps the engineer in responsible charge of the quality. The AI's drafts are inputs to the engineer's QA decisions, but the decisions, conformance, deficiency, root cause, correction, are the engineer's, made on the actual conditions and recorded as the engineer's findings. This is the responsible-charge principle applied to QA: the human owns the consequential determinations, the AI assists with the documentation, and the verification is how the engineer converts the AI's candidates into their own verified findings.

Proportion the Verification to the Consequence: Structural NCR vs Cosmetic Punch

QA items are not equal in consequence, and the verification should be proportioned to the consequence, which is the consequence-proportioned verification discipline applied to QA. A structural NCR, a slab out of tolerance, a missed firestop, a weld that does not meet spec, carries a consequence that can reach the life-safety gate: the non-conformance affects the building's structural integrity or fire protection, so its verification demands rigor, the QA engineer confirming the non-conformance, investigating the true root cause, and driving the correct corrective action, because getting it wrong can leave a structural or fire deficiency in the building. A cosmetic punch item, a paint scuff, a minor finish blemish, carries a low consequence, so it can be verified lightly: if the vision flags it and it is wrong, the cost is small, and if it is missed, the harm is cosmetic.

So the verification effort goes where the consequence is highest. The structural, fire-protection, and code-related non-conformances get close verification of both the deficiency and the root cause, because an error there can leave a serious defect in the finished building and a wrong root cause means a serious failure can recur. The cosmetic and minor finish items get a lighter touch, because the AI's false positives and false negatives there are cheap to absorb. This proportioning lets the QA engineer use the AI's comprehensive drafting across hundreds of items while concentrating their irreplaceable judgment on the high-consequence non-conformances where the verification protects the building, rather than spreading it thin across every paint scuff.

The proportioning also sorts the two documents by their typical stakes. The NCR tends toward the higher-consequence end, because a non-conformance is by definition a failure to meet the requirements and its root cause drives a corrective action, so NCRs generally warrant close verification, especially the structural, fire, and code-related ones. The punch list tends toward the lower-consequence end, cataloging finish and completion items, though it can contain high-consequence items too. So the proportioning is by the item's actual consequence, not just the document type: a structural item on a punch list gets the rigor it demands, and a cosmetic note on an NCR gets a lighter touch, with the verification always tracking the consequence of the specific item.

The Applied Problem: Build the NCR-and-Punch Generation Step

Here is the exercise. Build the NCR-root-cause-and-punch-list auto-generation step. Specify the AI generation: the computer-vision read proposing candidate punch items, and the generative drafting of NCRs with suggested root causes. Specify the verification: the QA engineer's check of each candidate punch item against the actual conditions (removing false positives, inspecting for the false negatives the vision missed) and investigation of each suggested root cause as a hypothesis to confirm, refine, or replace. Specify the proportioning: close verification of the high-consequence non-conformances (structural, fire, code) and a lighter touch on cosmetic items, tracking the specific item's consequence. Specify the ownership: the QA decisions, conformance, deficiency, root cause, correction, are the human's, recorded as the engineer's verified findings.

Produce two things. First, the generation-step design: the AI drafting the punch list and the NCRs as candidates, the QA engineer verifying the punch items against reality and investigating the root causes, the consequence-proportioned verification concentrated on the high-stakes non-conformances, and the ownership that makes the verified documents the engineer's QA record. Build it so a project could run the capture and the drafting, verify the candidates, and produce a punch list and a set of NCRs the engineer owns. Second, the candidate-and-consequence analysis: why the root cause is a candidate from correlation and not a finding, so its wrongness sends the corrective action astray, why the punch items must be verified against reality with the false negative as the dangerous error, why the QA decisions are the human's, and why the verification is proportioned to the consequence so a structural NCR gets rigor and a cosmetic punch item gets a lighter touch.

The professional who masters this gets the AI's speed on the tedious QA paperwork without inheriting its failure modes, the false reads and the plausible-but-wrong causes, into the quality record, because the human verifies the punch items against the actual work, tests the root causes against the actual conditions, concentrates the rigor on the high-consequence non-conformances, and records their own verified findings. That is the candidate-and-verify discipline applied to QA: the AI proposes, the human determines, and the punch list and NCRs that go into the record are the engineer's quality findings, proportioned in rigor to what each item can cost the building.

Key Takeaways

• QA documentation near closeout is high-volume and tedious, so AI earns its place: computer vision reads the jobsite capture and proposes candidate punch items, and generative AI drafts NCRs with suggested root causes, turning the engineer's walk-and-write burden into a review-and-verify task across hundreds of items.
• The root-cause suggestion is a candidate from correlation, not a finding from investigation: the model proposes a cause by pattern, but correlation is not causation, so the suggested cause may be a co-occurring factor or a plausible-but-wrong story, and an NCR with the wrong root cause sends the corrective action at the wrong target so the non-conformance recurs.
• The root cause is the cheapest part to draft and the most dangerous to record unverified, because its wrongness is invisible in the document (a wrong cause reads as confidently as a right one), so the engineer takes it as a hypothesis to investigate and records their own verified cause, the metric-as-signal discipline applied to causation.
• The computer-vision punch read produces false positives (flagging acceptable work, chasing needless rework) and false negatives (missing real deficiencies that pass into the finished building), and the false negative is the dangerous error because a missed deficiency is not on the list to be caught, so the verification must include the human's inspection of the areas the vision reads poorly.
• The punch items and root causes must be verified against reality, the actual state of the work, because the vision only infers it from imagery and the generative cause is a guess: the QA engineer corrects the vision's read in both directions and tests the cause against the actual conditions, producing the verified findings that drive the rework.
• The QA decisions are the human's: conformance, deficiency, root cause, correction are quality judgments the QA professional owns, because the human is accountable for the quality to the owner, the designer, and the building's occupants, so the AI is the engineer's assistant and the verification converts its candidates into the engineer's findings.
• The verification is consequence-proportioned: a structural NCR (slab tolerance, firestop, weld) can reach the life-safety gate and demands rigorous verification of the deficiency and the root cause, while a cosmetic punch item (paint scuff, minor blemish) gets a lighter touch, with the rigor tracking the specific item's consequence, not just the document type.
• The artifact: build the NCR-and-punch generation step (AI drafts candidates, engineer verifies punch items against reality and investigates root causes, consequence-proportioned rigor, human ownership of the QA decisions), so the AI's speed is captured without the false reads and plausible-but-wrong causes entering the quality record, the candidate-and-verify discipline applied to QA.