On many projects, QA/QC arrives too late—when a model is about to be published, drawings are ready for issue, or installation has already started. A late review may still detect defects, but the cost of correcting them increases because other disciplines, decisions and deliverables now depend on the faulty information.
The problem is not simply the absence of a checklist. It is a break in continuity between the engineering decision, the information that describes it, the coordination process that validates it, the construction work that implements it, and the tests that prove it performs as intended.
At SORA, we therefore approach QA/QC as a system of prevention, verification, evidence and closure across the full delivery flow:
Engineering → Information → Coordination → Construction → Commissioning → Handover
QA and QC are different—and both are necessary
Quality Assurance acts before and during production. It establishes requirements, methods, responsibilities, acceptance criteria and controls intended to reduce the likelihood of defects.
Quality Control verifies the output. It checks models, documents, calculations, interfaces, installations and system functions against agreed criteria, and preserves objective evidence of the review.
QA without QC may define a sound process without proving the quality of its result. QC without QA tends to become a late search for problems that have already moved downstream.
The real cost of an error that travels
A small inconsistency can propagate across a project. Equipment may change in the engineering design while the model retains an earlier version, a drawing carries a different reference, the electrical feed is no longer adequate, and the associated point is missing from the BMS point list. Each team may have reviewed its own file while the overall solution remains inconsistent.
Effective QA/QC must therefore test relationships, not only individual objects:
- requirements against deliverables;
- models against documentation;
- calculations against selection and representation;
- coordination against constructability;
- electrical equipment against feeds, protection and controls;
- sequences of operation against points, alarms, graphics and functional tests;
- approved design against as-built information and final handover.
This is the purpose of technical continuity: preventing a decision from losing meaning, traceability or quality as it moves from one project stage to the next.
An integrated, modular toolkit
To make this approach repeatable, we developed the first version of the SORA Integrated QA/QC Toolkit, a downloadable Excel resource containing 75 controls across six modules. The current spreadsheet interface is in Spanish; an English interface has not been published yet.
- Information governance: requirements, responsibilities, delivery planning, status, revisions, authorization and traceability.
- BIM models: coordinates, categories, parameters, classification, level of information, model health, federation, IFC and IDS where applicable.
- Coordination and constructability: clashes, maintenance clearances, access, physical continuity, interfaces and issue closure.
- Documentation and deliverables: registers, drawings, cross-references, calculations, package integrity, final files and as-built reconciliation.
- Electrical engineering: design basis, loads, conductors, raceways, protection, short circuit, grounding, routing, circuits, testing and final records.
- BMS/BAS/EPMS: sequences, point lists, architecture, capacity, interoperability, interfaces, naming, alarms, point-to-point checks, functional testing, EPMS data integrity and database backups.
The modules can be used together or tailored to a specific exchange. Teams may activate all controls, justify those that do not apply, and add project-specific checks derived from the contract, local regulations, manufacturer requirements and client standards.
Evidence is part of the control
Ticking a box does not prove that a review took place. Every control in the toolkit connects:
- an acceptance criterion;
- a verification method;
- required evidence;
- a result;
- finding severity;
- corrective action;
- ownership and due date;
- closure and reverification.
This turns "it looks correct" into a traceable decision: compliant, noncompliant, not applicable or pending—with enough evidence to support the conclusion.
A release gate, not a decorative percentage
The dashboard summarizes progress by module and applies a straightforward release rule:
- if no controls are active, the result is SCOPE NOT CONFIGURED;
- any open nonconformity produces DO NOT RELEASE;
- if there are no open nonconformities but applicable checks remain pending, the review is INCOMPLETE;
- only when an active scope exists and there are no pending checks or open nonconformities is the package READY FOR RELEASE.
"Ready" does not automatically mean "authorized." Release remains the decision of the responsible person under the project's governance process. The dashboard makes the basis for that decision visible.
What international standards inform the toolkit?
The structure draws on internationally recognized management and verification principles:
- ISO 19650-2 for information management during the delivery phase;
- ISO 19650-4 for processes and decision criteria related to information exchanges;
- ISO 9001 for process-based quality management, documented evidence, measurement, corrective action and improvement;
- buildingSMART IDS for machine-interpretable information requirements and IFC-based checking;
- buildingSMART IFC Validation for IFC syntax, schema and normative-rule conformance;
- the ISO 16484 series as a reference for building automation and control functions, documentation and interoperability.
One distinction matters: validating an IFC file does not prove that it satisfies every project-specific requirement. IFC validation checks the technical conformance of the file, while IDS can support checks of computable information requirements. Contractual, engineering, electrical and regulatory rules still need to be defined and verified for the specific project and jurisdiction.
The toolkit does not certify compliance with any standard. It also does not replace professional review, field testing, commissioning or approval by the relevant authority.
How to use the resource
- Configure the project, information exchange and responsible roles.
- Determine which controls apply to the scope.
- Perform preventive QA controls before production advances.
- Execute QC checks and attach objective evidence.
- Record nonconformities and corrective actions.
- Reverify closure; a response is not the same as a verified correction.
- Consult the release gate before publishing, issuing, constructing, testing or handing over information.
The toolkit provides the most value when used throughout delivery and at planned exchange points—not only at the end of the project.
References
Does your organization need a tool adapted to its processes?
Tell us about the context, roles, deliverables and controls you need. SORA can help structure a tailored technical solution and define the right scope.
Discuss a tailored tool →Tags
