Construction AI does not usually fail by inventing things
A model that invents a clause is easy to catch, because the clause does not exist. A model that quotes the right clause from the wrong revision produces something that survives every check a firm has, and is wrong.
What were the answers to the previous five questions?
1. Why is "check for hallucination" the wrong instruction to give a construction team?
Because it directs attention at fabrication, which is rare and easy to spot, and away from context failure, which is common and hard to spot. A team told to watch for invented facts will pass a confident, correctly cited answer drawn from a superseded revision.
2. In what three ways can an AI output be entirely factual and still wrong on a live project?
It quotes the standard form where your contract has been amended. It answers from the drawing revision that was current until last Tuesday. It states a settlement position that is reasonable on these facts and inconsistent with the position the firm is running on three other live disputes.
3. Who in a construction business is best placed to catch a context failure, and why is it not the IT department?
The QS who knows the contract was amended, the design lead who knows which revision is current, the planner who knows the logic was changed without agreement. Catching these requires knowing how construction information behaves, which is a professional competence and not a technical one.
4. How would you test an AI system for the superseded document failure mode before deploying it?
Deliberately give it a superseded drawing alongside the current one and ask a question the two answer differently. A system that answers confidently without flagging the conflict has failed. Build the same trick into the golden test set for every category.
5. What should "human must verify" say for a use case involving contractual terminology?
Confirm the term used matches the defined term in this specific contract rather than general usage, and that the mechanism named is the one the contract actually provides. Not "confirm the output is accurate".
What are the eight categories?
Wrong contractual terminology, a missed project amendment, a superseded document, a conflict with company policy, the wrong specification revision, an unrecognised statutory requirement, a misread approval status, and an unsupported statement of responsibility.
Worked briefly, in the form they take on site:
| Failure | How it presents | What verification must actually check |
|---|---|---|
| Wrong contractual term | A delay called force majeure in correspondence when the contract provides something narrower. Under JCT, force majeure is itself a listed Relevant Event and gives time only, with money running separately through Relevant Matters. NEC4 has no force majeure at all, and a compensation event carries time and money together | That the term is the defined term in this contract, and that time and money have not been merged where the contract separates them or split where it does not |
| Missed amendment | A notice assessed as compliant against a 14 day period when the amendment made it 7, and it is late | That the model had the amended contract and any Z clauses, and that the period runs from the event the contract says it runs from, in the units the contract uses |
| Superseded document | A design query answered from a revision superseded a fortnight ago, with no uncertainty flagged. Superseded containers do not vanish: they move to the archive state and are retained deliberately, and a CDE export reads the archive alongside the live set unless somebody filtered it | Two separate checks. That the container is the latest revision, and that its status code permits the use being made of it. A container can be current and still be shared for comment only |
| Policy conflict | A settlement position reasonable on the facts and inconsistent with the firm's standing approach elsewhere | That the position matches the company line across live matters |
| Wrong specification revision | Materials compliance passed against an earlier revision with a lower fire rating requirement | That the clause cited matches the current live revision |
| Unrecognised regulatory trigger | A design review on a higher-risk building in England that misses a material change of use, which is expressly a major change under the change control regulations: the client must apply to the Building Safety Regulator and the work must not start until it is granted. On infrastructure the same shape appears as work begun against an undischarged consent | That a competent person has checked for regulatory triggers outside the scope given, and in the right jurisdiction |
| Approval status | A rejected subcontractor rate cited as the agreed commercial position | That the document or position cited is approved, not draft or rejected |
| Unsupported responsibility | Causation and an agreed programme asserted in a redrafted email | That any causation or responsibility claim is established fact, not inference |
| Reconciled ambiguity | Two boreholes contradict each other and the answer smooths them into one sensible reading. Under NEC4 an ambiguity within the Site Information is interpreted in the Contractor’s favour, so reconciling it quietly destroys an entitlement | That contradictions in the source were surfaced rather than resolved. A system that tidies a conflict has concealed the question |
What do all eight have in common?
The model reasoned correctly from information that was incomplete, and produced fluent output that concealed exactly how incomplete it was. There is no moment of obvious error to catch.
This has a direct consequence for who does the checking. Fabrication can be caught by anyone careful. A superseded revision can only be caught by someone who knows which revision is current, and a missed amendment only by someone who knows the contract was amended. Human in the loop only works if the human retains and applies precisely the expertise these failures require, which is the argument from part three arriving from a different direction.
It also explains why hallucination dominates the conversation. It has a clean story: the system said X, X is false, therefore check facts. The eight above each require understanding something about how construction information behaves, and that is harder to put on a slide. It is also why they are the ones that actually happen.
How do you build the check into the way work is done?
Three points in the cycle, none of which is a reminder to be careful.
- Before deployment. Build a golden test set from a completed project: a hundred to two hundred real events with known correct outcomes, including deliberately difficult cases in each of the eight categories. Measure precision and recall before anyone relies on the system, and record which matters more here: a notice trigger agent that is highly precise and catches a third of the triggers is worse than useless, because it has taught you to trust it. This needs no technology to produce and it is the most valuable asset in the whole programme.
- During operation. Sample outputs against the eight categories rather than checking generically whether they look right. Ten outputs a month, checked against a specific list, surfaces real weakness faster than ad hoc spot checking ever will.
- After an incident. Classify it against the eight. Over a year that tells you which category your particular deployment is weak in, which is the only basis on which to strengthen anything.
The single behavioural change that catches the most is to move the team from asking for answers to asking for evidence. Not "is this a variation" but "identify the contractual provisions, correspondence and records relevant to whether this is a change, and show the sources". Not "are we delayed" but "compare the programmes, identify movement to critical activities and show which records support the apparent causes".
Related reading while the module settles: hallucination risk in professional documents and which AI model for construction teams.
That completes the control module. The next four parts put it to work, starting with the discipline that touches every other one. part 8, the project manager who compressed the work, not the thinking follows a project manager through a single Wednesday morning.
What five questions should you be able to answer now?
Attempt these before tomorrow. Each has a defensible answer, and each is answered at the top of the next part.
- What is the difference between using AI to make a decision and using it to compress the work that precedes a decision?
- A revised programme lands. What should you ask for, and what should you not ask for?
- Why does a specific, constrained request produce better evidence than an open question?
- What is the risk of a structured, authoritative looking output, and what habit counters it?
- Which decisions in a project manager's week should be explicitly marked as human only?
Which sources is this part built on?
Every figure quoted above resolves to one of these. Each was checked before publication.