Getting Started with Automated Compliance

The first step of getting started with automated compliance is not a compliance step at all - it is a modelling habit. A check can only run on data, so before any rule can be applied, your model has to carry the information the rule needs, in a form a computer can read. That means moving beyond geometry that merely looks right to a model where elements carry meaning: a corridor that is classified as a corridor and knows its clear width, a door that knows its clear opening, a room that knows its occupancy and area, a wall that knows its fire rating. This is the difference between a drawing and a structured model, and it is the single biggest determinant of whether automated checking will work for you. Garbage in, garbage out is not a warning about exotic failures; it is the ordinary result of feeding a semantically thin model to a checker.

The good news is that structuring for checkability is mostly good modelling discipline you should want anyway, and you can build it incrementally. You do not need a perfect, fully-classified model to begin - you need the specific properties that the specific rules you plan to check depend on. If you want to check corridor widths, corridors must be identifiable and carry a width; if you want to check setbacks, the building footprint and plot boundary must be present and correctly placed. Start by picking two or three checks you care about, then make sure the model carries exactly what those checks read. That keeps the effort proportionate and the payoff immediate.

Two cautions make this honest. First, classification is a judgement in itself - deciding that a space is a corridor rather than a lobby, or which occupancy a room falls under, is exactly the kind of interpretation a human must get right, and the check will faithfully apply the rule to whatever you declared. Second, a well-structured model is necessary but not sufficient: it makes checking possible, not automatic, and it does nothing for the rules that cannot be coded regardless of data. So structure the model as the foundation, keep it proportionate to the checks you actually intend to run, and remember that you are making the building legible to a rule - not delegating the decision about what the building is. Get this foundation right and everything downstream becomes possible; skip it and no tool will help you.

With a model that carries the right data, the second step is to run the simplest, clearest quantitative rules you can - and to run them yourself, before you submit. Begin with the rules that are unambiguously checkable: minimum corridor and door clear widths, setbacks from the plot boundary, ground coverage, room and plot areas, floor-space index, ramp slopes, exit counts and travel distances. These are the rules with a number and a comparison - is this measured value at least, or at most, the required one - and they are exactly where automated checking is fast, consistent and reliable. Deliberately leave the judgement-laden and performance rules alone for now; trying to automate 'adequate ventilation' at the start is how people conclude, wrongly, that automated compliance does not work.

The purpose of these self-checks is early, cheap feedback and a cleaner submission. Run them while the design is still fluid so a flagged under-width corridor can be widened before it is frozen, and run them again just before submission as a final sweep for the boring errors that get sets returned: the doorway that lost fifty millimetres when a partition thickened, the escape route that grew too long when a core moved, the coverage that crept over the limit as the footprint grew. A plans-examiner should not be the one to first notice these; a self-check should. That is the concrete, immediate return on getting started - fewer avoidable rejections and less rework.

Keep the discipline honest. Read every flag rather than silencing it - a fail is a prompt to look, and might be a false fail from a mis-classified element. Give every pass a second glance - it can be a false pass from missing data or a rule that was not actually encoded. Treat 'undetermined' as a signpost to human review, not noise. And log what you checked, because a self-check is only as trustworthy as the list of rules behind it. Above all, hold the boundary: this is a self-check, a rehearsal you run for your own benefit. It reduces returned submissions and catches missed clauses early; it is not, and never becomes, an approval. The authority approves, on the authoritative rule - the actual code and byelaw - and your clean self-check is simply evidence you took to the door, not the decision made at it.

Getting started with automated compliance is not only about your model and your checks - it is about the specific approval system you submit into, which varies enormously and determines what automation can and cannot do for you. Before investing in tools or workflows, learn the concrete facts of your jurisdiction: What form must a submission take - structured model, or 2D drawings, or both? Which checks, if any, does the authority itself run automatically, and which remain a manual, human review? What are the exact parameters they scrutinise - the setbacks, coverage, floor-space index and height limits set by the local byelaw or development-control regulation? What are the submission formats, naming conventions and documentation they require? These are not incidental details; they decide whether your self-checking connects to the real approval at all, or runs entirely on your own side of the fence.

This matters especially because there is often a gap between what you can check in your model and what the authority accepts as a submission. Many authorities still take 2D drawings, not structured models, so your rich internal self-check may have no direct channel into their process - it makes your submission cleaner, but the authority re-checks in its own way. Some authorities run automated or semi-automated scrutiny of specific quantitative parameters against the byelaw; knowing which ones lets you pre-empt exactly those checks. And in every case the authoritative rule is the local byelaw and the National Building Code as the authority interprets them - not your encoded version, which may lag or differ. Learning the local reality keeps your effort aimed at what actually helps.

The practical move is simple: find out, for your city and building type, the actual submission requirements and the actual scrutiny process, ideally from the authority's published rules and from professionals who submit there regularly. Match your self-checks to the parameters that matter locally, format your submission the way the authority wants it, and understand where human review takes over. This is unglamorous homework, but it is what separates automated compliance that reduces your rejections from automation that runs in a corner disconnected from the decision that counts. The approving authority and the governing byelaw define the target; getting started means learning that target precisely rather than assuming a generic one.

The final principle of getting started is restraint: expand your use of automated compliance only into the places where it genuinely earns its keep, and no further. It is tempting, once the first self-checks work, to try to automate everything - every rule, every domain, the whole byelaw - but that ambition is where cost balloons and value thins out. Encoding rules, maintaining them as byelaws change, keeping models rich enough to check, and validating that the encoding is correct all take real effort, and that effort only pays back on rules that are clear, quantitative, frequently checked, and error-prone by hand. Grow toward those; leave the rest.

A good rule of thumb: add a check when the rule is unambiguous, the mistake it catches is common and costly, and the data to check it is already in your model or cheap to add. Corridor and door widths, setbacks, coverage, areas, exit provisions - these repay automation because you check them on every project, they have clear numeric thresholds, and humans miss them in large drawing sets. Extending into a new domain (say, from planning geometry into fire egress or accessibility) is worthwhile when that domain has its own body of clear quantitative rules you check repeatedly. But resist encoding rules that are rarely used, genuinely ambiguous, or that need data your models will not realistically carry - the maintenance burden outlives the benefit, and a stale or wrong encoded rule is worse than none, because it looks authoritative while misleading.

Growing selectively also means growing honestly about the boundary. Every expansion should sharpen, not blur, your sense of which rules are checkable and which are not: as you automate more of the quantitative subset, the judgement-laden and performance rules that remain human should stand out more clearly, not get quietly swept into a false sense of total coverage. The mature user of automated compliance runs a lean, well-maintained set of high-value checks, knows exactly what they cover and what they do not, and treats every result as evidence for a human decision. That is the destination this on-ramp leads to - not a system that checks everything, but a designer who checks the right things well, keeps judgement human, and defers every binding result to the qualified professional of record, the approving authority and the governing law. Start small, stay honest, and grow only where the tool truly helps.