Model-Based Code Checking

The defining move of model-based code checking is what the computer is pointed at. A drawing is a *representation* meant for human interpretation: lines, symbols and numbers that a trained person reads as walls, doors and dimensions. The meaning lives in the reader's head, not on the sheet. A machine handed the same sheet sees geometry with no semantics - it cannot reliably tell a corridor from a car ramp, or know that '1500' is a width in millimetres rather than a room number. Early attempts to automate compliance by getting software to 'read the drawing' foundered on exactly this: recovering meaning from a picture is hard, brittle and error-prone.

A structured model removes the guessing. In a Building Information Model the design is a database of objects: this is a Wall, that is a Door with a clear opening of 0.9 m, this is a Room whose occupancy is Assembly and whose area is 240 square metres, that is a Corridor whose clear width is 1.5 m. Each element is explicitly typed and carries properties as data. The building is not a picture to be interpreted; it is a set of facts to be queried. Checking then becomes something a computer is genuinely good at: for a rule about corridor width, find every element of type Corridor, read the clearWidth property, and test it against the required value.

This is why the field is called model-based checking rather than drawing-based checking. The design must first be authored - or converted - into structured form, most often exchanged through an open model format so different tools can read it. The pay-off is that the same reliable machinery that made spreadsheets and databases trustworthy now applies to compliance: no interpretation, just lookup and comparison. The catch, which the rest of the module keeps returning to, is that everything now depends on the model being complete, correctly typed and correctly valued. A drawing that merely looks right can hide a mislabelled corridor; a model that is checked exposes exactly what was - and was not - captured as data. The shift from picture to model is what makes automatic checking possible at all.

In a traditional workflow the drawings *are* the deliverable, and compliance is judged against them. In a model-based workflow the drawings become one view produced from an underlying model, and it is that model - the structured data - that the checker actually reads. This is a subtle but important reframing. When a rule is run, it is not run against the plan you print; it is run against the objects and properties in the model from which the plan was generated. The sheet a human reviews and the data a machine checks are two faces of the same source.

That has real consequences. First, the check sees only what the model contains. If a corridor was drawn as a plain region rather than modelled as a Corridor with a width property, a human might still read it correctly on the printed plan, but the checker cannot test it - the object it needs is simply not there. The model, not the drawing, defines the checkable reality. Second, because the model is data, the same building can be checked repeatedly, automatically, as it changes: move a wall and the corridor's width property updates, and the next run reflects it. Third, the model is a single source of truth that many rules can interrogate at once - accessibility, fire, area and coverage rules all read the same door, room and corridor objects.

Understanding that the model is the checked thing reshapes how you work. It means the effort shifts upstream: to be checkable, the design must be modelled deliberately, with elements correctly classified and the properties the rules need actually populated. It means a 'pass' is a statement about the model, not directly about the building - the model may faithfully represent the design, or it may not. And it means the honest boundary is sharp: the checker verifies that the *data given* satisfies the *rules encoded*, which is a genuinely useful thing, but it is not a verification that the real building complies. The professional who authors and stands behind the model, and the authority who approves, remain accountable for that. The model is what gets checked; the building is what must actually comply.

When a checkable rule meets a well-formed model, model-based checking delivers three things manual review struggles to. The first is automation: the tedious, mechanical comparison - is every corridor wide enough, is any travel distance too long, does any ramp exceed the maximum slope - runs without a human tracing each element by hand. What took hours of careful, interruptible attention runs in seconds. The value is not that the machine is clever; it is that the machine is tireless and does not skip element 47 of 200 because it was distracted.

The second is repeatability. A human checking the same drawing twice, or two humans checking it, can reach different results; a rule run against a model produces the *same* verdict every time, for every element, in the same way. That consistency is quietly transformative: it turns a check from a matter of who reviewed it into a matter of what the rule and the data say. It also makes regressions visible - re-run after a change and you see exactly what newly passes or fails.

The third, and often the most valuable, is earliness. Because the check is cheap to run, it can run early and often during design, not only at submission. A designer can self-check a schematic model, see that a corridor is 100 mm short or an escape route too long, and fix it while it costs a mouse-drag rather than a redesign after rejection. Feedback moves from the end of the process, where changes are expensive, to the middle, where they are cheap.

These are real, demonstrated benefits for the checkable subset of rules - the quantitative development-control and life-safety checks (setbacks, coverage, widths, distances, slopes, counts) that dominate everyday plan-scrutiny, in India as elsewhere. But hold the promise honestly. Every benefit above is a benefit *of running the encoded rules on the model given*. It says nothing about the rules that cannot be coded, nothing about whether the model faithfully represents the building, and nothing about legal approval. Automatic, repeatable and early is a large gift for the mechanical part of compliance - and precisely because it is so convenient, it invites the automation bias this course keeps warning against. Use the speed; keep the scepticism.

It helps to state plainly what you are and are not getting. A model-based check is an automated, repeatable evaluation of encoded, checkable rules against the structured data in a model. Within that scope it is genuinely powerful and worth doing. But four honest boundaries travel with it, and a competent designer keeps all four in view.

First, it checks the model, not the building. The verdict describes the data supplied. If the model is incomplete, mis-classified or wrongly valued - a corridor left as a generic region, a width entered in the wrong unit, an occupancy unset - the check is checking the wrong thing, and can pass a non-compliant design or flag a compliant one. Garbage in, garbage out is not a slogan here; it is the operating condition.

Second, it checks only the codeable rules. The rules a checker runs are the clear, quantitative ones. The judgement-laden terms ('adequate', 'suitable'), the performance clauses needing analysis, the questions of which rule applies and how conflicts reconcile - none of these are touched by a model-based check. A green run across the coded rules says nothing about the large, important body of regulation that stayed human.

Third, a pass is not an approval. The check reports that the encoded rules it could evaluate found no flaggable issue in the data given. It is not a legal determination that the design complies, and it is emphatically not the authority's permission to build. The approving authority grants approval; the software does not.

Fourth, the authoritative rule is the real code, not its encoding. The encoded rule may be wrong, simplified or out of date relative to the actual National Building Code provision, the local byelaw or development-control regulation, or the IS standard it claims to represent. When they disagree, the law wins, and a human must catch the divergence.

Hold those four together and model-based checking sits in its proper place: a fast, consistent, early assistant that removes mechanical burden and surfaces likely issues, while the qualified professional of record, the approving authority and the governing law remain fully accountable for whether the design truly complies. That is not a hedge; it is the correct engineering stance toward a useful but partial tool.