Automated Code Checking: Pre-Screen or Auto-Approve? BCA Evidence

The Mechanism

The mechanism of automated code checking is often mischaracterized as a failure of semantic understanding; in reality, the rule engines function with high reliability on geometric predicates. The workflow begins when an architect exports an Industry Foundation Classes (IFC) file conforming to established standards from authoring tools like Revit or ArchiCAD. Before evaluation, the checker validates the model against a specific Model View Definition (MVD), ensuring the exchange contains only the entities required for the target check. Once validated, a rule set—such as Solibri's code-checking rules or Singapore's FORCHECK rules for egress and fire compartmentation—evaluates each requirement as a computable predicate against the model graph. This process does not "read" the building code; it executes spatial queries defined by the MVD.

What remains computable is strictly bounded by geometry and topology. For instance, building codes mandate minimum door clear widths. In the model, this maps to a geometric query on IfcDoor entities that calculates the unobstructed opening dimension based on frame parameters and swing arcs. Similarly, corridor widths, stair riser/tread geometry, travel distances to exits, and room-area program checks resolve to precise calculations on IfcSpace, IfcStair, and IfcWall entities. These checks are deterministic: if the query returns a value below the threshold, the engine flags a violation. The limitation lies not in the engine's ability to measure, but in the fraction of code clauses that can be reduced to such queries without natural-language interpretation.

Rule authoring occurs via mvdXML schemas or proprietary rule languages, guided by buildingSMART's Information Delivery Manual (IDM) process. The IDM framework rigorously defines which code clauses are "computable." Analysis indicates that typically only a small fraction of a code chapter's clauses are geometrically checkable without resorting to ambiguous text parsing. The remaining majority involve prescriptive materials, administrative procedures, or subjective performance criteria that require human judgment. Consequently, the automated layer serves exclusively as a pre-screening filter. It identifies dimensional non-compliance with high throughput, allowing human reviewers to focus on the complex, non-geometric clauses that constitute the bulk of regulatory nuance.

The speed advantage emerges from eliminating redundant manual verification. According to Singapore's CORENET e-PlanCheck pilot reporting, plan-review cycle time was reduced for compliant submissions. This gain occurred because the automated pass eliminated the first round of human markups on dimensional rules, allowing examiners to proceed directly to substantive review rather than re-measuring what the software had already verified. However, this efficiency does not transfer liability. In every deployed system, including CORENET and Solibri-based US pilot offices, the automated result generates a flagged report. A certified plans examiner must manually confirm, sign, and issue the final determination. The software never issues the correction letter itself, preserving the legal chain of custody while accelerating the mechanical portion of the review.

The Evidence

Singapore's Building and Construction Authority (BCA) established the operational baseline for automated code checking through CORENET e-PlanCheck, where mandatory electronic submission paired with the FORCHECK engine delivered a headline reduction in review turnaround for compliant IFC submissions. This figure remains the single most-cited metric in the field, yet it masks a critical dependency: the speed gain materialized only after the jurisdiction enforced strict model-quality gates and defined liability protocols that shifted verification responsibility to the submitting party. Without these institutional scaffolds, the rule engines function as high-fidelity geometric predicates rather than autonomous compliance arbiters.

US federal assessments corroborate the technical capability while highlighting the quality threshold required to unlock it. According to NIST's GCR series on rule-based checking, including the Design Review and Checking framework developed during the 2010s, researchers found that automated systems could catch a significant portion of geometric code violations before human review. However, this detection rate applied exclusively to models meeting rigorous IFC quality standards; when submittals lacked semantic consistency or contained broken geometry, the false-positive rate spiked, eroding reviewer trust. The US Government Accountability Office (GAO) subsequently noted that jurisdictions attempting to scale these tools without parallel investments in model validation infrastructure saw diminishing returns, reinforcing the conclusion that software reliability is necessary but insufficient without process discipline.

International adoption patterns reveal how liability structures dictate efficiency gains. Norway's Statsbygg and participating municipalities mandated IFC-based checking on public projects, achieving reported review-time savings. These figures lag behind Singapore because Norwegian reviewers retained full manual verification duties, using the automated output strictly as a pre-screening layer to flag potential non-compliance. This approach aligns with the canonical decision rule: automated checking serves as a filter for human reviewers, never as the final compliance determination. The lower efficiency gain reflects a conservative risk posture where departments prioritize legal defensibility over cycle-time compression, accepting higher labor costs to maintain direct oversight of every compliance assertion.

The divergence between documented performance and US deployment rates constitutes the central puzzle of current building technology policy. Industry surveys conducted by buildingSMART and the AIA consistently place US jurisdictional adoption of automated checking below a low percentage, despite the clear time-savings evidence from Singapore and Norway. This gap persists not because the technology fails to understand code—rule engines reliably check geometric and clearance rules—but because the institutional layer remains unresolved. Departments face liability ambiguity, IFC model-quality failures in practice, and disputes over rule interpretation that outweigh the speed gain for most building officials.

Vendor-side data offers insight into where value accrues when adoption occurs. Solibri case studies, now part of Nemetschek, report that design-firm-side clash-and-code checks catch egress and clearance violations an average of several design iterations earlier than manual review. This shift moves cost discovery from the permitting phase back into the design process, reducing rework expenses for developers. However, this benefit requires design firms to invest in pre-submission validation tools, creating a misalignment where the financial incentive falls on the private sector while the regulatory bottleneck remains unaddressed. Until jurisdictions standardize IFC quality requirements and publish written liability protocols, the adoption ceiling will likely hold, leaving the majority of plan reviews reliant on legacy manual workflows.

Pre-Screen vs. Auto-Approve

The deployment decision for automated code checking is not a technology procurement; it is a liability allocation problem. Jurisdictions face three distinct models, and the risk exposure between them differs by an order of magnitude. Model A relies on voluntary pre-screening where submissions are accepted without algorithmic validation. Model B mandates pre-screening but retains the human plans examiner as the sole authority for compliance determination. Model C attempts automated approval for a narrow subset of rules, typically geometric or clearance checks. The choice among these dictates whether the department accelerates review or assumes uninsurable risk.

For the current year, Model B is the only viable path for US jurisdictions. It captures the majority of the speed advantage demonstrated by mature systems like Singapore's CORENET e-PlanCheck while preserving the legal structure that allows professional errors-and-omissions insurers to underwrite plan examination. Under Model B, the rule engine functions strictly as a pre-screening layer that flags potential non-compliance for human reviewers. This aligns with the canonical requirement that automated tools never serve as the compliance determination. The plans examiner remains the legal determination of record, which is the structural condition any US jurisdiction has successfully insured.

Model C fails because it collides with foundational legal doctrines. Municipal immunity statutes generally protect discretionary acts of government officials, but they do not extend to algorithmic outputs. Furthermore, professional-engineer stamping requirements mandate a licensed seal on compliance determinations; an automated pass cannot carry this seal. To implement Model C, a jurisdiction would need either a statutory change transferring liability to software vendors or an insurer willing to underwrite algorithmic determinations at scale. Neither mechanism exists in the current regulatory landscape. The failure of early pilots was rarely due to the rule engines' inability to parse geometric predicates; Solibri Model Checker and similar tools execute spatial logic reliably. The collapse occurred at the institutional layer: the absence of model submittal standards, unclear liability assignment, and the lack of legal status for an automated pass.

Published accuracy metrics for automated code checking measure the rate at which violations are flagged, not the rate at which they are missed. This distinction creates a false-pass risk that skews perceived reliability. A door tagged with a specific width in a Revit schedule may pass an automated check if the model geometry matches the tag, yet fail in the field because the element uses an incorrect IfcDoorType mapping that obscures critical attributes like fire rating or hardware type. The checker validates the model as submitted; it cannot detect discrepancies between design intent and constructability when the semantic layer is misaligned. Consequently, the true error rate remains unknown, and reliance on published precision figures without verifying model fidelity introduces latent compliance gaps.

What the Data Doesn't Tell You

The degradation begins before rule execution. Independent analyses of Revit-to-IFC export workflows, including NIST round-trip studies and academic validation projects, demonstrate that a notable percentage of semantic data relevant to code rules is lost or misclassified during translation. Attributes such as occupancy tags, fire-resistance ratings, and door hardware specifications frequently drop out or map to generic categories. When the input model lacks these properties, the rule engine operates on degraded data, producing results that reflect export artifacts rather than building performance. This translation loss means the checker's output is only as valid as the IFC quality gate preceding it; without strict schema enforcement, the automation amplifies errors rather than resolving them.

Computational limits further constrain the speed gains claimed by early adopters. Only roughly a minority of International Building Code Chapter 10 (means of egress) clauses can be expressed as pure geometric predicates. The remainder relies on intent-based language—terms like "readily apparent," "adequate," or "judged by the authority having jurisdiction"—that no current rule engine resolves algorithmically. The headline reduction in review time applies exclusively to this computable slice of the code. For complex jurisdictions, the majority of review effort involves judgment calls regarding spatial experience, accessibility nuances, and renovation ambiguities that software cannot touch. In US mixed-use and adaptive-reuse pilots, where existing-condition data is often incomplete, the actual time savings are significantly lower than those reported in standardized high-rise portfolios.

The primary barrier to US adoption is not technological capability but institutional liability. No US court has ruled on whether a jurisdiction that relies on an automated pass owes a legal duty when a design later fails inspection, and no A/E professional-liability carrier has published underwriting guidance for algorithmic compliance determinations. This regulatory silence forces departments to treat automated checks as advisory pre-screening tools rather than definitive approvals. The canonical decision rule mandates that agencies never use automation as the compliance determination and must establish written liability protocols before deployment. Until carriers define coverage boundaries and courts clarify duty-of-care standards, the risk exposure outweighs the efficiency gains for most building departments, keeping adoption rates well below a low threshold despite the proven speed benefits in controlled environments.

A multi-story office tower in a mid-size US jurisdiction governed by the International Building Code (IBC) illustrates why automated code checking functions as a liability amplifier rather than a replacement when deployed without structural safeguards. The project was submitted as an IFC 4 file exported from Revit and processed against a Solibri egress rule set targeting door widths, corridor dimensions, stair geometry, travel distance, and exit-stair capacity. This configuration mirrors the technical baseline of CORENET e-PlanCheck but operates within a US legal environment where model submittal standards lack the mandatory rigor required to guarantee semantic fidelity.

Worked Case

The automated engine evaluated computable egress predicates against the IFC geometry in approximately four minutes. It returned six flags: two corridor segments measured against a requirement triggered by building code provisions for occupant loads; one door swing encroaching a clear egress path; and three stair doors with a specific clear width failing the minimum threshold. A manual first-round review of these specific geometric items historically consumed an estimated duration across two prior similar projects. With the automated run plus examiner verification of the six flags requiring only a fraction of that time, the geometric slice saw a substantial reduction. Since geometric checks constitute a significant portion of total review hours, this yielded a net reduction in full-review time, aligning with the headline efficiency gains observed in mature jurisdictions.

However, the critical failure mode emerged during the same run. The model's fire-rated corridor walls carried no `IfcFireRating` property following the IFC export. Consequently, the firewall continuity rule silently skipped those elements, generating no flag despite a potential code violation. The plans examiner caught the omission manually during the verification pass. This gap demonstrates that rule engines reliably check geometric predicates but cannot infer missing semantic data; the software does not fail because it "cannot understand the code," but because the institutional layer—specifically the model quality gate—allowed a structurally incomplete submission through. This outcome validates the canonical decision rule: automated outputs must remain pre-screening flags subject to human determination of record, as the liability for silent skips rests entirely with the submitting party and the reviewing authority's acceptance protocols.

The practical consequence of this workflow became apparent during the design iteration phase. Because the automated tool isolated the six egress violations immediately, the architect corrected them within a short iteration cycle rather than enduring a lengthy resubmission loop. The permit was issued notably earlier than the jurisdiction's median, providing the concrete, project-level definition of faster processing. Yet this speed gain is irrelevant if the department lacks a written liability protocol to absorb the risk of missed semantic errors like the missing fire rating. Without an IFC model-quality gate enforced before the rule engine runs, the speed advantage is offset by the exposure of undetected non-compliance, explaining why adoption stalls among US building departments.

Rule 1 mandates a strict separation of concerns: automated checking functions exclusively as a pre-screening layer that flags potential non-compliance for human review, never as the compliance determination. The canonical decision rule requires a named plans examiner to sign the determination of record; if procurement or legal counsel discusses auto-approval mechanisms, operations must halt immediately until statutory authority and professional liability insurance structures are resolved. This prevents the common myth that software failures stem from an inability to understand code—institutional layers regarding model submittal standards and liability assignment are the actual failure points. A robust protocol must explicitly state that an automated flag triggers a mandatory human verification step, preserving the engineer's seal and the jurisdiction's legal standing.

Five Rules for Adopting Automated Code Checking in

Rule 2 enforces a hard gate on model quality before any rule engine executes. Submissions must pass an IFC validation check against the required Model View Definition (MVD) alongside a semantic checklist verifying critical attributes such as fire ratings, door types, and space classifications. According to current technical standards, a model failing this gate is routed directly to manual review rather than attempting automated processing, eliminating misleading passes caused by incomplete geometry. This gate ensures that the computational engine receives data with sufficient fidelity to evaluate geometric predicates reliably, preventing the "garbage in, garbage out" scenario that has historically eroded trust in digital plan review systems.

Rule 3 restricts the scope of automation to the computable slice of the code—geometric predicates that can be enumerated and verified algorithmically. Effective deployments limit rule sets to door widths, corridor dimensions, stair geometry, travel distances, and room areas. Departments must budget reviewer time for the remaining majority of code clauses involving performance-based design, material specifications, and nuanced interpretations that the engine cannot process. By isolating these computable elements, jurisdictions can capture efficiency gains without overpromising on the system's capabilities, ensuring that the automated workflow complements rather than replaces complex engineering judgment.

Rule 4 shifts performance metrics from cycle-time reduction to accuracy control during the initial adoption phase. For the first year, departments should track the false-pass rate by sampling a portion of submissions that receive an automated clean bill of health for full manual re-review. If the sampled false-pass rate exceeds a low threshold, the model gate must be tightened before expanding the rule set. This feedback loop prioritizes reliability over speed, ensuring that the system identifies genuine violations without generating noise that overwhelms staff. Continuous monitoring of this metric allows for iterative refinement of both the submission standards and the rule logic based on real-world performance data.

Rule 5 aligns the deployment scope with building stock characteristics where speed gains are most predictable. Pilots should target new-construction projects with standardized occupancy types, such as office towers and residential high-rises, where geometric regularity supports consistent automated analysis. Conversely, renovations and mixed-use existing-conditions projects should be excluded initially, as pilot data indicates that the complexity of retrofitting code requirements into digital models causes the projected efficiency gains to collapse. Starting with well-defined project types establishes a reliable baseline for performance measurement before attempting to tackle more complex development scenarios.

Rule 5 aligns the deployment scope with building stock characteristics where speed gains are most predictable. Pilots should target new-construction projects with standardized occupancy types, such as office towers and residential high-rises, where geometric regularity supports consistent automated analysis. Conversely, renovations and mixed-use existing-conditions projects should be excluded initially, as pilot data indicates that the complexity of retrofitting code requirements into digital models causes the projected efficiency gains to collapse. Starting with well-defined project types establishes a reliable baseline for performance measurement before attempting to tackle more complex development scenarios.