The Designer's Role

Start by being precise about the division of labour, because most trouble with automated compliance comes from blurring it. A checking engine owns one thing: applying encoded rules to the data in a model and reporting where the condition it was given is or is not met. That is genuinely useful, and it is genuinely narrow. Everything else stays with people - and the biggest share stays with you, the designer of record.

You own the model. The check runs on what your model says, not on the building you have in mind, so if a corridor is not classified as a corridor, or a wall is missing its fire rating, the tool checks the wrong thing or nothing at all. You own the interpretation. A result is evidence, not a verdict: a 'pass' means only that the encoded rules the engine could evaluate found no flaggable issue in the data you gave it, and turning that into 'the design complies' is your judgement to make, informed by everything the tool never saw. You own the decision and the signature. When you stamp a drawing or submit a design, you are asserting your professional judgement that it is fit and lawful - the software makes no such assertion and answers to no one.

And you own the parts of regulation the tool cannot touch at all: the judgement-laden terms, the performance requirements that need engineering analysis, the questions of which rule applies and how conflicts reconcile. These are not edge cases; they are the substance of professional practice. The checking engine simply falls silent on them, and silence is easy to mistake for a pass.

The cleanest way to hold this is a single sentence: the tool assists, the professional decides, the authority approves, the law governs. Automated checking sits inside your process as a fast, mechanical helper; it does not sit above it as an oracle. Keeping that hierarchy clear is not modesty or caution for its own sake - it is what makes automated compliance safe to use. The moment a designer starts treating the engine's output as the answer rather than an input, they have quietly handed away the one thing they cannot delegate: responsibility for the result. Your job is to use the assistant hard, and never let it become the decider.

Now the upside, used properly. The single most valuable thing automated checking gives a designer is not a final verdict - it is early, cheap, repeatable feedback. Manual compliance checking is expensive enough that it tends to happen late: you self-check near submission, and the authority checks after that, so a violation surfaces when the design is nearly frozen and fixing it is costly. A checking engine inverts that economics. Once your model carries the right data, running a quantitative rule costs almost nothing, so you can run it early and often - while the plan is still loose, while walls can still move, while a corridor can still be widened by a hundred millimetres without a redesign. That is where automated checking earns its keep: catching the checkable mistakes when they are still cheap to fix.

Use it as a self-check, not a scorecard. Before you show a scheme to a consultant or submit it to an authority, run the clear quantitative rules you can - minimum corridor and door widths, exit travel distances, ramp slopes, setbacks, ground coverage, required counts - and treat every flag as a prompt to look, not a defect to silence. Good self-checking finds the boring, avoidable errors that would otherwise waste a plans-examiner's time and get your submission returned: the doorway that lost fifty millimetres when a partition thickened, the escape route that grew too long when a core moved. These are exactly the errors humans miss in a mass of drawings and machines catch instantly.

Two disciplines keep this honest. First, run early - the value collapses if you only check at the end, because then the tool is confirming a frozen design rather than shaping a fluid one. Second, log what you actually checked, because a self-check is only as trustworthy as the list of rules behind it, and 'I ran the checker' means nothing without 'here is what it did and did not cover'. Used this way, automated checking makes you faster and more thorough on the mechanical rules and frees your attention for the judgement that only you can supply. It is a rehearsal you run for yourself - not the performance, and never the review that the authority alone conducts.

A check is only ever as good as the model beneath it - garbage in, garbage out is not a slogan here, it is the daily reality. So half the designer's skill in automated compliance is upstream: preparing a model the tool can actually check. That means elements are classified for what they are (a corridor knows it is a corridor, a door knows its clear opening, a room knows its occupancy and area), the properties the rules need are present and correct, and the units and references are the ones the rules assume. A beautifully drawn model that is semantically thin - geometry without meaning - is unrunnable; the engine either checks the wrong thing or reports 'undetermined' across the board. Preparing for checkability is a design habit, not an afterthought: as you model, you are also making the building legible to a rule.

Downstream, the second half of the skill is reading results critically instead of trusting them. Every result falls into one of three buckets, and each needs a different reflex. A 'fail' is usually a genuine issue to fix - but sometimes a false fail from a mis-classified element or a wrongly encoded rule, so investigate the cause before you touch the design. A 'pass' is the dangerous one: it can be a false pass because the data was incomplete, an element was mis-typed, or the rule you cared about was never encoded at all - so a pass earns a second look, not relief. And 'undetermined' or 'not checked' is where the tool is telling you, honestly, that this is human territory - missing data, or a judgement-laden rule it cannot evaluate.

The critical reader always asks three questions of any result: Did the check run on correct data? Is the encoded rule the right, current rule? And what did the check not cover at all? None of these is answered by the colour of the tick. This is the antidote to automation bias - the well-documented tendency to over-trust an automated output simply because it is automated and looks authoritative. A green screen feels like permission; it is only a report about a subset of rules on the data you happened to provide. Treating every result as a claim to be tested, rather than a fact to be accepted, is what separates a designer who uses the tool from one the tool quietly misleads.

Everything in this lesson converges on one line the designer must not cross: you can delegate the mechanical checking, but never the judgement, and never the responsibility. Automated compliance is safe and powerful exactly as long as it stays an assistant to an accountable professional. It becomes dangerous the moment it starts to function as a substitute for one - and that shift rarely announces itself. It creeps in through convenience: the checker becomes the last word, a pass becomes 'done', and the questions the tool cannot answer stop being asked because the screen was green.

Guard against it deliberately. Keep judgement explicit in your process: after the checks run, you still ask whether the design is actually safe, usable and lawful, including on everything the tool never evaluated - the adequacy of a route, the reasonableness of a provision, the performance the model cannot test, the interpretation of which rule governs. Treat 'undetermined' and 'not checked' as the most important part of the report, not the part to scroll past. And never let a tool's output be the thing you point to when asked why you decided as you did; the reason must be your reasoning, with the check as one input among many. Remember too that the check is never an approval - the authority grants that, on the authoritative rule, which is always the actual code, byelaw or law and never its encoded version, which may be wrong or out of date.

This is not a counsel of distrust. Use automated checking hard - it will make you faster, more consistent and less likely to miss a checkable clause than any unaided human. But use it as what it is: a rehearsal, a self-check, an early-warning system for the mechanical subset of the rules. The professional who prepares a checkable model, runs it early, reads the results critically, keeps the judgement human, and defers every binding result to the qualified professional of record, the approving authority and the governing law is using the tool exactly right. The one who lets the green tick decide has outsourced the one thing that made them a professional. Keep that line bright, and the tool serves you; blur it, and you serve the tool.