Identify the governing basis
The phrase International Building Code may refer to a model code edition, not the exact rules governing a particular project. The jurisdiction may adopt an edition with amendments, related codes, administrative rules, and local interpretations. Record the applicable jurisdiction, adopted editions, project classification, and source of decisions. Confirm this basis with the responsible design professional and relevant authority. Do not assume that a model rule or generic software setting matches local requirements.
- Confirm jurisdiction and adopted editions
- Record relevant amendments and interpretations
- Identify the professional responsible for code analysis
Convert provisions into reviewable questions
Before checking a model, a qualified reviewer must interpret the relevant provision and identify its inputs, exceptions, thresholds, and required evidence. Some provisions concern measurable geometry; others rely on use, construction type, system performance, documentation, or professional judgment. A useful review schedule links each requirement to a location, source, input, method, responsible reviewer, and status. This prevents a software rule from being treated as a complete interpretation of a complex provision.
Assess whether model data is adequate
Automated checks depend on the accuracy and completeness of model categories, parameters, geometry, and relationships. A missing door rating, incorrect room classification, or outdated model revision can produce a false result even when the rule itself is configured correctly. Validate the source model and document known omissions before testing. Decide whether a result can be determined from the model or requires a drawing, specification, calculation, field condition, or other record.
- Check classifications and required attributes
- Confirm model revision and scope
- List evidence needed outside the model
Use automation with bounded claims
A rule based checker can identify candidate conditions such as a measured distance, count, or presence of a defined attribute. It cannot resolve every exception, conflicting provision, equivalency, or design judgment. Test rules on known examples, record units and thresholds, and review both flagged and unflagged cases. A negative result means only that the configured test did not identify a condition in the supplied data. It does not prove general compliance or guarantee acceptance by an authority.
Keep findings and decisions distinct
A finding should identify the observed model condition, the rule or project requirement being considered, the location, relevant revision, and evidence needed to assess it. The report should distinguish a confirmed issue, an item needing interpretation, a data gap, and a condition reviewed with no further action. Route interpretation to the authorized design professional and authority as appropriate. Do not present a software finding as an approved design resolution or close it merely because geometry changed.
Preserve an auditable record
A review record should retain the adopted basis, rule definitions, model versions, test date, scope, exclusions, reviewer, and disposition of each finding. If rules change, preserve the former result and explain why a later test differs. The record should be understandable to someone who was not present during the review. This is especially important when model data is exchanged among designers, contractors, reviewers, and authorities with different responsibilities.
- Retain rule sources and configuration
- Record reviewer and disposition
- Track changes between model revisions
Respect jurisdiction and professional responsibility
Code review is project specific and can involve life safety, accessibility, fire protection, structural, energy, and other disciplines. A general model review is not a substitute for required calculations, sealed documents, inspections, or authority decisions. The appointed professionals remain accountable for their work, and the authority having jurisdiction retains its statutory role. The handoff should identify the limits of the model based review and direct unresolved questions to the proper professional.
Handle updates as new reviews
A later model revision can change geometry, classification, or attributes that affect a prior check. Define which changes require a rerun and which findings need renewed professional review. Preserve earlier outputs rather than overwriting them, so the project record shows what was tested at each stage. If a rule or interpretation changes, document the authority and effective project decision behind the update. This keeps a sequence of bounded reviews from being misread as one continuing approval.