National Model Codes, Provincial Adoption and Local Requirements: How the Layers Fit Together

Executive summary

Canadian building regulation is layered. A model national code is developed and published nationally; provinces and territories adopt it with amendments and set effective dates; municipalities administer permits and add local submission requirements, policies and interpretations.

For anyone configuring digital review, the layering is not background context. It determines which requirement applies to which application, and it is the reason a rule set cannot be portable without configuration.

Why the layers matter operationally

Codes Canada develops and publishes the model national codes, including the National Building Code of Canada [1][2]. Model codes are not directly enforceable. Authority arises when a province or territory adopts a code, often with amendments, and states when it takes effect — Ontario’s building code and its update notices are a clear example [3][4].

The consequence is practical: two identical designs in two provinces can face different requirements, and the same design filed weeks apart in one province can be assessed against different editions during a transition period. Any statement that a system "checks the building code" is incomplete until the jurisdiction, edition and effective date are named.

The four layers, and who owns each

Part 9 and Part 3 of the code add a further division within a single jurisdiction: housing and small buildings are addressed prescriptively in ways that differ from the treatment of larger and more complex buildings, and the published user’s guide for Part 9 illustrates that difference [5].

What this means for configuring digital review

A rule in a digital review system is therefore not just logic. It is logic plus a scope statement: the jurisdiction it applies in, the adopted edition it derives from, the effective dates during which it is valid, the permit types it covers, and the local amendments applied to it.

Practically, this means every finding a system produces should be able to answer four questions: which requirement, from which edition, adopted where, and applicable to this application because of which project facts. If the system cannot answer them, the finding cannot be relied on in a regulatory context.

Implications for authorities having jurisdiction

Layer 3 is where most local friction lives, and it is the layer a municipality fully controls. Documented submission standards, published interpretations and stable naming conventions reduce deficiencies before any technology is involved, and they are the raw material a configuration exercise depends on.

During a code transition, the department needs an explicit position on which applications are assessed against which edition, and that position needs to be visible in both the applicant guidance and the configured rule set.

Implications for applicants and professionals

Designers working across municipalities carry the cost of layer 3 variation. Stating the assumed edition and jurisdiction on the drawings, and confirming local requirements before filing, avoids a class of deficiency that has nothing to do with design quality.

Where openBIM submissions are being considered, the same layering applies to information requirements: national and international standards provide the format, while the jurisdiction defines what must be present. NRC-published work on openBIM implementations for a Canadian roadmap is a useful orientation [6].

Risks, limitations and safeguards

• Treating the model code as enforceable text is a common and consequential error; only the adopted provincial or territorial code applies.
• Rule sets copied between jurisdictions without re-validation will produce confident, incorrect findings.
• Transition periods create genuine ambiguity; the department’s position must be documented rather than inferred.
• Reproducing substantial code text raises copyright issues. Paraphrase requirements and cite the official publication.
• Local interpretations that exist only in individual reviewers’ practice cannot be configured; they must be written down first.

PermitAssure perspective

PermitAssure treats jurisdictional configuration as a first-class part of the platform rather than a deployment detail. Rules carry their jurisdiction, edition, amendment set and validity dates, and findings state them. Where a provision is not configured, the platform reports that it is out of scope instead of implying coverage.