I think it is worth checking what the field was given before deciding why something was built wrong. A wall in the wrong position is visible. The superseded drawing that led to it may be much less visible, particularly after the conversation has moved on to who is paying to put it right.
That does not mean workmanship never causes rework. It means the investigation needs to follow the information as well as the installation. A team can follow an instruction carefully and still produce work that no longer matches the design the reviewer has in front of them.
FMI / PlanGrid, Construction Disconnected (2018): poor data and miscommunication drive about half of US rework, an estimated $31.3B a year. The same research says teams spend about 14 hours a week (35% of their time) on rework, conflict resolution and looking for information. It does not establish that every problem starts in a model, but it gives us a reason to look beyond the people holding the tools.
The version gap
Imagine an architect moving a column on Tuesday while the subcontractor is preparing work from an earlier export. The updated drawing arrives, but the installation instruction still refers to the previous position. Nobody needs to be careless for that gap to exist; it can sit between otherwise reasonable processes.
The change then reaches other work. A duct run needs reviewing, the ceiling layout may need adjusting and the team responsible for containment needs to know whether its route is still available. Finding those dependencies after work starts leaves fewer options than finding them while the proposal is being reviewed.
On a reference campus we use, a requested 1.0 m cabinet exceeds the governing 0.92 m spec limit by 0.08 m. The shared long-lead product covers 96 cabinets across 6 halls. A review before fabrication can consider the order, governing drawing and install plan together, without assuming that every cabinet has already been built or needs replacing.
A revision guard is useful here because it connects the revised sheet to the elements and packages it affects. The project team can see what needs reviewing before issuing further instructions, rather than rely on everyone recognising the implications of a new file arriving.
Giving the field a reviewable instruction
An alert alone is not enough. The recipient needs to know what changed, which source now governs and whether the change has been approved for construction. A proposed revision and an instruction to build are different things, and the record should make that difference clear.
This is the work described on our platform page: keeping changes connected to their sources and affected elements so the responsible people can inspect them. Criad supplies the context; the engineer and project team decide the response. A measurement or comparison can support that decision without taking responsibility for it.
When rework does happen, that history also helps people understand the sequence without relying entirely on memory. It will not settle every disagreement, but it can make the discussion fairer to the field team. I think starting with the information they actually had is a reasonable place to begin.