Design error checking: A layered method for engineers

TL;DR

• Design errors are expensive: a survey of 139 projects put direct and indirect design error costs at 6.85% and 7.36% of contract value, on average.
• Checklists alone do not work. Research on design error causation finds no single strategy and calls for individual, project and organizational measures together.
• Check in sequence: general model quality, core information, code compliance, then constructability, and define severity criteria before the first clash report.
• AI is useful where the work is reading and cross-referencing documents, provided it cites its sources, states its assumptions and leaves the decision to a licensed reviewer.

Why design errors survive review

Most firms already review their designs. Errors still reach the site, which suggests that the review is the weak point and not the absence of one. The usual explanation, an individual who missed something, does not survive contact with the literature. A paper in the Journal of Performance of Constructed Facilities classifies design errors by cause and concludes that they stem from interdependent failures of people, organization and project process, and that practitioners struggle to learn from them while a project is still running.

The same research is blunt about the popular remedy. Relying solely on organizational checklists is insufficient, because the environment an organization creates directly determines how accurately its engineers can work. Time pressure, unclear scope, late information and thin handovers produce errors that no checklist item names.

There is also the problem of the designer’s own mind. A 2020 paper in Structural Engineering International argues that design review is the most effective mechanism for addressing human factors, noting that subconscious and hindsight bias shape design decisions, and that a well-tuned collaboration between the design engineer and a reviewer who also inspects on site is what neutralizes them. A designer reviewing their own work tends to see what they intended to draw.

The financial stakes explain why the topic deserves more than a final-week skim. The questionnaire study cited above found direct and indirect costs of roughly 7% of contract value each, and found that they did not vary significantly with procurement method or project type. These are perceptions reported by practitioners, not audited ledgers, and the study itself notes that actual costs remain relatively unexplored. Even so, a figure of that size on a large contract is hard to dismiss as noise.

What a design error looks like in practice

It helps to separate the categories, because each is caught by a different kind of check.

Error type	Typical example	Best caught by
Model integrity	Missing elements, duplicates, wrong object types	Automated model checks
Information	Inconsistent parameters between schedule and drawing	Cross-document comparison
Compliance	Dimension or load assumption violating a code clause	Clause-by-clause review against the source
Hard clash	Duct physically intersects a beam	Clash detection
Soft clash	Maintenance access or clearance zone violated	Rules plus engineering judgment
Assumption	Soil parameter carried over from another site	Independent reviewer reading the basis of design

The hard and soft distinction matters more than it appears. Practitioners treat a hard clash as a physical intersection and a soft clash as a violation of clearance, accessibility or maintenance space. The New Zealand BIM Handbook makes the practical point that severity criteria should be defined early, in the BIM Execution Plan. Whether a pipe through a partition wall is critical or negligible is a project decision, and if nobody makes it, an automated check produces a flood of false positives that trains reviewers to ignore the report.

Set the standard before you check against it

The handbook’s guiding principle is short: model to a standard, check to a standard. Quality control, it argues, should not be a late catch-all activity. Protocols for checking compliance belong at the project outset, and when the modeling standard and the checking protocol are misaligned, teams pay in rework and miscommunication during coordination.

In practice that means deciding, before the first model exchange:

1. Which standards and codes apply, and which edition of each.
2. What each discipline must deliver at each stage, and in what format.
3. Which checks are automated, which are manual, and who owns each.
4. What counts as critical, major and minor, and what response time each severity gets.
5. Where findings are logged and how closure is verified.

This list looks bureaucratic. It is also the cheapest part of the whole process, and the one most often skipped when a schedule is already tight.

A layered sequence for checking designs

Singapore’s Building and Construction Authority points to a hierarchical order in its BIM essential guide: general quality checks first (missing elements, duplicates), then core information validation, then code compliance, and finally constructability and maintainability checks, using intelligent objects and color-coded visualization to expose flaws in design intent. The logic is that each layer is pointless if the one beneath it is unsound. Checking code compliance on a model with duplicate walls produces confident, wrong answers.

Layer 1: Model hygiene

Confirm that elements use the correct object types, that nothing is duplicated or missing, and that each discipline model is internally consistent before it is federated. This layer is almost entirely automatable and should never consume engineering hours.

Layer 2: Core information

Check that the data the downstream work depends on is present and coherent: levels, grids, materials, classification codes, and the parameters quantity and cost work will read. Accuracy of inputs governs everything after them, a point made just as forcefully for building performance models in guidance on improving energy model accuracy, where weak input data quietly undermines every calculated output.

Layer 3: Code compliance

Here the work becomes interpretive. A reviewer must find the governing clause, read it in context, and compare it to what the design actually says. This is slow, document-heavy and error-prone for people, because a project can carry hundreds of pages of specifications and several overlapping codes. It is also where traceability matters most: a finding without a clause reference cannot be reviewed.

Layer 4: Constructability and maintainability

Can it be built in the sequence assumed, reached for maintenance, and inspected? This layer relies most on experience and benefits from the contractor’s and operator’s input. Soft clashes live here.

For infrastructure owners, public agencies publish worked procedures along the same lines. The Abu Dhabi municipality, for example, issues a BIM QA/QC checklist for infrastructure projects requiring checks on every submission before it is shared on the common data environment. The jurisdiction differs from the United States, but the principle of gating submissions is universal.

Keep the independent reviewer

A layered sequence reduces the load on reviewers but does not replace them. Three habits keep the review honest.

• Separate the checker from the author. The bias research above is the reason. A fresh reader has no memory of what the drawing was meant to say.
• Make assumptions explicit. An error often hides in a quietly inherited input, such as a soil parameter or a load case. A design basis that lists assumptions turns a hidden error into a reviewable line.
• Capture lessons during review, not after. The causation research describes a lack of situated learning, meaning the ability to learn from mistakes while the project is live. Findings logged by category, discipline and cause let an organization see its own recurring weaknesses instead of re-living them.

With an independent reviewer in place, the question becomes how to give that reviewer more time for judgment and less for transcription.

Where AI fits in design error checking

The honest answer is that AI is strongest on the layers that consume the most hours and the least judgment: reading, cross-referencing and comparing. A 2026 paper in the International Journal of Construction Management proposes that an effective AI error detection system needs three components: large language models for semantic analysis, an LLM-OCR approach for context-aware ingestion of drawings and documents, and retrieval-augmented generation for reasoning grounded in cited sources. The paper presents a conceptual framework with proof-of-concept validation, so it describes a direction and not a finished industry standard.

The retrieval component is the point that matters for reviewers. A model that flags a conflict but cannot show where in the specification or code it found the requirement hands the engineer a new thing to verify from scratch. A flag with a citation can be accepted or rejected in seconds.

This is also where rule-based tools reach their ceiling. A hard-coded rule finds the clash it was written to find. It does not notice that a spec section, a drawing note and a bill of quantities disagree about the same element, because that disagreement lives in prose and tables, not in geometry.

Three tests separate useful automation from a liability:

1. Traceability. Every finding links to the passage, drawing region or model element it came from.
2. Stated assumptions. The system records what it assumed, so the reviewer can judge it as they would a colleague’s work.
3. Human sign-off. The output is a reviewed deliverable, not an authorization. Our own view on keeping a licensed engineer in the loop is set out in our piece on AI for BIM and the 30% rule.

Our perspective

We build Yesper as an AI civil engineer for construction and infrastructure, and design error checking is where the difference between a general chatbot and domain-built software is easiest to see. A general model can summarize a clause. It struggles when the task is to produce a geotechnical report from raw CPT protocols, derive quantities from a BIM model, or put a dozen tenders in three currencies on one comparable basis. Those are the tasks where errors hide, because they are long, multi-step and unforgiving of a single wrong unit.

So we design around the review. Yesper writes down its assumptions so that an engineer can inspect them the way they would a colleague’s, and it works with source verification and full traceability, so a finding can be traced to where it came from. Customers report saving 50 to 95 percent of the time on project work, and report better quality as well, because errors that human reviewers had missed get caught. Those are customer-reported results, and we treat them as a reason to keep the process honest, not a reason to remove the reviewer.

We also think the industry asks the wrong question. The debate over whether AI can find errors misses the sharper one: whether an organization’s review process can absorb what AI finds. A tool that surfaces two hundred undifferentiated flags is worse than none. Severity criteria, clear ownership and a closure record are what turn detection into fewer errors on site. Our write-ups on design review automation and engineering compliance checks go into how we handle that.

Putting a layered check into your workflow

A realistic rollout does not start with a software purchase. It starts with the habits above.

1. Audit your last two projects. Classify the errors found late by the four layers. If most sat in layer 3, you have a document-reading problem. If most sat in layer 1, you have a modeling standard problem.
2. Write the checking protocol alongside the BIM Execution Plan. Include severity definitions.
3. Automate layer 1 and the reading portion of layers 2 and 3. Keep humans on interpretation and layer 4.
4. Require citations for every automated finding. No source, no flag.
5. Log findings by cause. Review the log quarterly and feed it back into the standard.

Teams working on quantities can apply the same discipline downstream: errors in the model flow straight into takeoffs, which is why we describe auditable BIM quantity takeoff as a verification problem first and a speed problem second.

See it on real engineering work

If your organization is a contractor, consultancy or infrastructure operator looking to bring AI into daily review and compliance work, Yesper is built for exactly that: project document search, regulatory compliance checks, error detection, deliverable creation and configurable agents for different project roles, with integrations into the tools your teams already use. You can find out more about the company on the About page or reach the platform at app.yesper.ai.