Audit ready QA/QC automation for construction: ISO 19650 and ISO 9001

What QA/QC automation looks like in construction

Automation only works when the information it checks is structured in a way a machine can actually read. That is the function ISO 19650 guidance assigns to Exchange Information Requirements and Project Information Requirements: they translate a client’s needs into a level of information need that can be tested, not just described in a specification narrative. Without that translation, “automation” tends to mean a person manually re-checking a PDF against a checklist, which is not automation at all.

The data layer beneath that translation is IFC and the Model View Definitions and Information Delivery Manuals that constrain it. buildingSMART’s guidance frames IFC datasets, MVDs, and IDMs as the practical mechanism for partially automating quality checks, because they let a rule engine test a model’s contents against a defined schema rather than against a reviewer’s memory of the specification.

Document control sits alongside this. ISO 9001:2015 clause 7.5 requires documented information, drawings, specifications, inspection and test plans, to be identified, approved, distributed, and retained so the correct version is available where it is needed. Automated workflows that enforce version gating are, in effect, ISO 9001 document control executed by software rather than a document controller working through a register by hand.

In practice, the rule types that get automated cluster into a few categories:

• Metadata and naming checks: file names, revision codes, and title block data validated against a project’s naming convention.
• Completeness checks: confirming that a required drawing, certificate, or test result exists for a given milestone.
• Calculation validation: cross-checking quantities, loads, or dimensions against source data for basic arithmetic errors.
• Clash and coordination checks: testing a federated model for geometric conflicts between disciplines, a workflow described in more detail elsewhere.

A practical implementation checklist: From requirements to production

Automation deployed without sequencing tends to produce a rule engine nobody trusts. The order matters more than the tooling.

1. Set EIR/PIR and delivery milestones first. No rule set should be written before the information requirements it is meant to enforce exist in machine-testable form.
2. Build a master requirements register. A spreadsheet or database listing every deliverable, its required metadata, and its acceptance criteria becomes the source rules are written against.
3. Map your inputs. IFC exports, PDFs, scanned drawings, inspection and test plans, and lab results each require different extraction methods before a rule can run.
4. Pilot on one deliverable. Test the rule set on a single drawing package or coordination model, tracking false positives so thresholds can be tuned before wider rollout.
5. Integrate into the Common Data Environment. Rules should run where documents already live, enforcing a single source of truth through version gating rather than a parallel checking system.
6. Assign ownership. Someone owns the rule library, someone reviews automated failures, and an escalation path exists for disputed flags.
7. Measure and iterate. Track time saved, error volume caught, and pass rates, then expand the rule set once the pilot’s numbers hold up.

Pro Tip: Tune false-positive rates on a low-stakes deliverable before automating anything tied to payment milestones or regulatory sign-off.

Skipping the pilot step is the most common failure mode. A rule set built for one deliverable type rarely transfers cleanly to another without adjustment, and teams that scale before tuning end up with reviewers ignoring flags altogether, which defeats the purpose of automating in the first place. A compliance matrix built directly from tender documents is one example of a narrow, well-bounded pilot that produces an immediately checkable output.

Where automation fits against DQC, ITR, and acceptance

Quality assurance and quality control are distinct functions, and automation sits inside both without replacing either. QA concerns the process, whether the right steps were followed. QC concerns the product, whether the deliverable itself meets specification. USACE’s quality management guidance describes Design Quality Control and Independent Technical Review as mandatory layers precisely because they require engineering judgment that a rule engine cannot replicate.

Automated checks do useful, narrower work within that structure:

• Catching routine errors (missing metadata, unresolved clashes, calculation mismatches) before a document reaches a human reviewer.
• Producing a traceable record of what was checked, against which rule version, and with what result.
• Closing the volume of checking that DQC and ITR reviewers would otherwise spend on repetitive verification, freeing that time for genuine technical judgment.

The recommended sequence, then, runs automated checks first, closes DQC review on what remains, and reserves ITR and any agency acceptance sampling for the judgment calls automation is not built to make. FHWA’s guidance on acceptance and independent assurance is explicit that automated or contractor-generated QC data does not substitute for an agency’s own independent verification sampling. Traceable rule outputs matter here for a plain reason: when a dispute arises over a rejected pour or a delayed acceptance, the record of what was checked and by which rule version is the evidence that determines liability.

Governance, records, and audit readiness for automated QA/QC

An automated check that leaves no trace is worse than no automation at all, because it creates a false sense that verification happened. Agency manuals are specific about what a record needs to contain, and automation should produce the same evidence a human inspector would.

At minimum, retain:

• Input source: the exact document, model version, or dataset a rule ran against.
• Rule identifier and version: which check ran, and under which iteration of the rule library.
• Timestamp and reviewer identifier: when the check ran, and who closed or overrode the result.
• Outcome and corrective action: pass, fail, or flag, and what happened next.

Caltrans’s Quality Assurance Manual and comparable agency manuals recommend electronic materials management systems and documented inspection records with defined retention periods, precisely so this evidence survives long enough to support an audit years after the work closed. Automated flags should map directly to inspection and test plan line items and contract acceptance criteria, and a nonconformance workflow needs to define when a flag triggers a stop-work order versus a routine note to the quality assurance manager. Retention and retrieval practices that leave records searchable, rather than buried in an email archive, are what separates an audit-ready system from a compliant-looking one.

Perspective: How sector-grade AI agents change QA/QC workflows

The received wisdom in construction technology circles is that general-purpose AI models will eventually absorb every document-heavy task, QA/QC included. That premise understates how domain-specific the failure modes are. A model that has not been built around construction data structures tends to produce plausible-looking output that fails the moment complexity rises, a geotechnical report from raw CPT protocols, or a quantity takeoff from a genuinely messy BIM model, is not a task a generalist tool handles reliably.

Sector-built AI agents change the calculation because they encode the rules described earlier directly into a workflow and expose their assumptions the way a colleague would explain a judgment call, rather than presenting a black-box answer. Yesper is used by engineering and infrastructure organizations and reports substantial customer time savings on project work, alongside catching errors human reviewers missed. The lesson for any team evaluating automation, Yesper’s or otherwise, is that outputs are only as trustworthy as the evidence and rule version attached to them. An AI-generated compliance matrix or quantity schedule is a starting point for review, not a substitute for the reviewer’s sign-off.

How Yesper helps teams put this playbook into production

Building the checklist above from scratch, requirements register, rule engine, CDE integration, governance workflow, takes sustained engineering effort most teams would rather spend on projects. Yesper is built specifically for construction and infrastructure work: it searches project documents, runs rule-based regulatory compliance checks, extracts quantities directly from BIM models, and produces outputs with the source evidence attached so a reviewer can verify them the way they would a colleague’s work.

Contractors, engineering consultancies, and infrastructure operators already use it across teams rather than as a single-desk tool. To see how the platform fits into an existing CDE and document workflow, visit Yesper’s company page or explore the technical architecture behind its integrations.

Key standards and guidance referenced

The playbook above draws on published standards and agency guidance rather than informal practice, and readers implementing it should consult these directly:

• ISO 19650 guidance (UK BIM Framework) on defining machine-testable information requirements.
• ISO 9001:2015 clause 7.5 on document control and documented information.
• Caltrans’s Quality Assurance Manual and USACE’s quality management directive on agency roles, records, and acceptance.
• buildingSMART’s IFC and COBie guidance on machine-interpretable data structures.