If most building rules were drafted more clearly, could far more of them be automated?

For a meaningful share, yes - and that is exactly the argument behind the "rules as code" and better-regulation movements. A great deal of regulation is hard to encode not because the underlying requirement is inherently unmeasurable, but because it was written for human readers exercising judgement: terms left undefined, several requirements folded into one sentence, exceptions buried in prose, quantitative and qualitative content mixed together. If future rules separated the quantitative from the qualitative, defined their terms precisely, stated exceptions explicitly and put one requirement per clause, a larger portion of the checkable core could be encoded faithfully and checked automatically. Some jurisdictions and standards bodies are experimenting with drafting rules and their machine-readable version together. But two honest cautions apply. First, this is largely a future direction, not today's reality - most existing building regulation, including much of what governs Indian projects, was not drafted this way and will not be re-drafted soon. Second, better drafting cannot dissolve genuine ambiguity: some requirements are deliberately open-ended ("adequate", "reasonable") because they must flex to circumstances a drafter cannot foresee, and clarifying them away would make the regulation worse, not better. So clearer drafting can expand the codeable subset - it cannot make all regulation codeable, and the authoritative meaning still rests with the actual law and the approving authority.

Why do exceptions cause so much trouble for automated checking specifically?

Because an exception can invert the outcome, and inverting an outcome silently is the worst kind of error a checker can make. A base rule might say a corridor must be at least 2.0 m wide; an exception might say "except in existing buildings undergoing minor alteration" or "provided an equivalent alternative is accepted by the authority". An encoding that captures the base rule but misses the exception will then confidently *fail* a design the code actually permits - or, if the exception is a stricter one it missed, *pass* a design the code forbids. Exceptions are especially dangerous for three reasons. They are often physically separated from the base rule - in a later subclause, a different section, or a referenced standard - so an encoder working from one clause may never see them. They can be nested and conditional, so following them correctly means tracing several branches. And some exceptions hand discretion back to a human ("unless the authority is satisfied that..."), which no automated check can resolve at all - the answer genuinely depends on an official's judgement. This is why a responsible checker must either encode the exceptions faithfully or clearly flag that it has not, and why you should never read a "pass" as covering a rule whose exceptions the tool may have quietly dropped. When an exception turns on discretion, the binding call belongs to the approving authority, not the software.

Lesson 2.2

Automated Compliance & Rules-as-Code/Module 2 · Understanding Building Regulations

Lesson 2.2 · Understanding Building Regulations

How Rules Are Written

Open any single regulation and you find the same moving parts - a scope that says when it applies, a condition, a quantitative threshold, defined terms, cross-references to other clauses and exceptions that override the base rule; learning to dissect this anatomy is the skill that tells you, clause by clause, how much of a rule a machine can actually check and where the human work begins

12 min Interactive lessonFree · open lessonByAmogh N P· Architect & interior designer

The hook

The topic of a rule barely tells you whether you can code it. How the rule is written tells you almost everything.

Two rules can be about exactly the same thing - a corridor width, say - and yet one is trivial to encode while the other defeats a machine completely. The difference is not the subject; it is the *drafting*. A rule that names one clear condition, one measurable threshold and a precisely defined term reads almost like code already. A rule that hides a judgement word, folds three requirements into one sentence, leans on an undefined term and buries an exception in a subclause cannot be reduced to logic without a human deciding what it means.

That is why anyone serious about automated compliance has to learn to read a regulation the way an engineer reads a mechanism: by taking it apart. In this lesson we dissect the anatomy every regulation shares - the scope or applicability that says *when* the rule bites, the condition, the quantitative threshold at its core, the defined terms it depends on, the cross-references that send you to other clauses, and the exceptions that override the base rule. Learning to spot these parts, and to see which of them are clean and which are slippery, is the practical skill that lets you look at any clause and say, with reasons, how much of it a computer could check and where the human work begins. It is the difference between encoding a rule faithfully and encoding a confident mistake.

A rule = scope + condition + THRESHOLD + defined terms + cross-refs + exceptions. Threshold codes easily; the rest is where it breaks. How it is WRITTEN beats what it is ABOUT.

The parts

The anatomy every regulation shares

Pick up almost any building regulation and, under the prose, you will find the same recurring parts. Learning to name them turns a wall of legal text into a diagram you can reason about.

First, scope or applicability: the part that says *when* and *to what* the rule applies - "in an assembly building", "for buildings above 15 metres", "where the occupant load exceeds 50". Scope is a gate; if the model does not tell you a building is an assembly building, you cannot even know the rule bites. Second, the condition: the logical test itself, usually of the form "for every X of this kind, check that some property holds". Third, the quantitative threshold: the measurable core - "clear width shall be not less than 2.0 m", "travel distance shall not exceed 30 m". This is the part that looks and behaves most like code: a number, a comparison operator, a unit. Fourth, defined terms: words the code fixes precisely somewhere else - "clear width", "assembly building", "habitable room", "travel distance" - each carrying a technical meaning that may differ sharply from everyday usage. Fifth, cross-references: pointers to other clauses - "as required by the fire section", "in accordance with the relevant IS standard" - so that no rule stands fully alone. Sixth, exceptions and provisos: the "except where...", "provided that...", "unless..." clauses that override or modify the base rule under stated circumstances.

A single sentence of regulation often contains all six at once. "In an assembly building [scope], the minimum clear width [defined term] of a corridor shall be 2.0 m [threshold], except where a greater width is required by the occupant-load provisions of the fire section [exception plus cross-reference]." To check that rule correctly a machine must resolve every part - identify assembly corridors, know what clear width means, apply the number, follow the cross-reference, and honour the exception. Miss any one and the check is wrong: skip the exception and you pass a corridor that should fail; ignore the definition and you measure the wrong dimension. The anatomy is not academic. It is the checklist of everything an encoding has to get right, and the map of where an encoding most easily goes wrong.

Zoom

One rule dissected: a single sentence of regulation often carries scope, condition, quantitative threshold, defined terms, cross-references and exceptions at once - and a faithful check must resolve every part, not just the number.

The core

Thresholds and conditions - the codeable heart of a rule

At the centre of a checkable rule sits its quantitative threshold: a value, a unit and a comparison. "Not less than 2.0 metres" becomes, in effect, width >= 2.0. "Shall not exceed 30 metres" becomes distance <= 30. "At least one exit per..." becomes a count with a minimum. This is the part of regulation that translates into logic almost transparently, because a number compared against a measured quantity is exactly what a computer is built to do. When people say rules-as-code "works", this threshold-and-condition core is overwhelmingly what they mean.

But even here, precision matters more than it first appears, and the details are where encodings quietly break. Units and rounding: is it metres or millimetres, and does 1.999 m fail or pass? The measurement basis: "clear width" is not the same as "nominal width" - a doorway's clear opening excludes the door leaf, the frame and any projecting hardware, so the property the rule tests must be the *right* measured property, not merely a plausible one. The comparison direction: a minimum and a maximum are opposite tests, and confusing them inverts the result. The quantifier: "every corridor" versus "any corridor" versus "the main corridor" changes which elements are tested and how a failure is reported. A rule that reads simply in prose - "corridors shall be at least 2.0 m wide" - still forces a dozen small, precise decisions before it becomes a correct check.

The condition wraps the threshold in a scope: *for the elements this rule applies to*, test the threshold. So the full codeable pattern is "for every element matching the scope, evaluate whether the measured property satisfies the threshold, and flag those that do not". Written that way, the rule is genuinely runnable - and this is the honest heart of automated compliance, the subset that delivers real speed, consistency and early feedback. The craft is in getting the scope right (which elements?), the property right (which measurement?), the threshold right (which number, which direction, which units?), and the reporting right (what exactly failed?). Get those four right and the machine earns its keep. Get any of them wrong and the tool produces a confident, precise, wrong answer - which is more dangerous than no answer at all, because it invites the automation bias that makes people trust the tick.

Zoom

How each part of a rule affects codeability: the quantitative threshold encodes cleanly, scope and definitions depend on the model and precise wording, cross-references and exceptions are tricky, and a judgement word cannot be checked at all.

The friction

Defined terms, cross-references and exceptions - where coding gets hard

If thresholds are the codeable heart of a rule, the surrounding tissue is where automated checking meets friction. Three parts in particular decide how hard - or impossible - a rule is to encode.

Defined terms are deceptively dangerous. A code's technical definition of a word can diverge sharply from ordinary use, and the whole rule turns on it. "Clear width" excludes obstructions; "habitable room" has a precise meaning that determines which rooms trigger light-and-ventilation rules; "assembly building" and "occupant load" carry definitions that decide whether a stricter rule applies at all. If your encoding uses a looser or different meaning than the code's own definition, every check downstream inherits the error. And some definitions are themselves partly qualitative - defined in terms of *use* or *character* rather than a clean measurement - which pushes part of the rule out of the machine's reach. Cross-references knit the code into a web: a corridor rule points to the fire section, which points to an occupant-load table, which points to a use classification, which points to an IS standard. To evaluate one rule correctly a checker may have to follow a chain of others, and a broken or out-of-date link anywhere along the chain corrupts the result. Encoding a rule in isolation, without its references, is a classic way to encode it wrongly.

Exceptions and provisos are the most treacherous of all, because they invert outcomes. "The minimum width shall be 2.0 m, except in buildings of Group X, provided that an alternative is agreed with the authority." An encoding that captures the base rule but misses the exception will *fail* designs the code actually permits, or *pass* ones it forbids - and exceptions are often buried, nested, or scattered across the document. Worse, some exceptions hand discretion back to a human ("unless the authority is satisfied that..."), which no check can resolve. The lesson for automated compliance is blunt: the threshold is the easy part; the definitions, the reference web and the exceptions are where faithful encoding actually lives or dies. A tool that quietly ignores them is not simplifying the rule - it is checking a different, wrong rule that happens to share a sentence with the real one.

Zoom

Why it matters

Why drafting decides codeability - and what that means for you

Put the parts together and a single conclusion emerges that is easy to miss: whether a rule can be automated is decided less by *what* it regulates than by *how it is written*. Two rules about the same corridor can sit at opposite ends of the codeability scale. One says: "In an assembly building, a corridor shall have a clear width of not less than 2.0 m." Clean scope, defined term, single measurable threshold - it encodes almost directly. The other says: "Corridors shall be of adequate width for the safe and convenient movement of occupants, having regard to the character of the building." Same topic; but "adequate", "convenient" and "having regard to the character" are judgements, not measurements, and no honest encoding can turn them into a check. The subject is identical. The drafting is worlds apart.

This has three practical consequences. First, for reading rules: before you or a tool tries to encode a clause, dissect it - find the scope, the threshold, the definitions, the references, the exceptions - and ask which parts are clean quantities and which are judgement, undefined, or discretionary. That five-minute dissection tells you, with reasons, how much of the rule is genuinely checkable. Second, for trusting tools: when a checker reports on a rule, ask *which part* it actually evaluated. Often a tool checks the tidy threshold and silently drops the messy exception or the qualitative definition - so its "pass" covers less of the rule than it appears to. Third, for the future of regulation: a growing movement argues that if we want rules that machines can help check, we should *draft them that way from the start* - separating the quantitative from the qualitative, defining terms precisely, stating exceptions explicitly, writing one requirement per clause. That is a hopeful direction, but it is not today's reality: most building regulation was written for human readers exercising judgement, and it shows.

The discipline to carry forward is to treat every rule as a mechanism with parts, and to be honest, part by part, about which the machine can check and which it cannot. And the boundary is never yours alone to draw finally: the authoritative meaning of any clause - its defined terms, its exceptions, how its cross-references resolve - belongs to the actual code and the approving authority that interprets it, not to any encoding of it. Next we look at a distinction that cuts across all of this: prescriptive rules versus performance rules.

Zoom

The same requirement drafted two ways: a structured clause (one condition, explicit scope, a single defined threshold, explicit exceptions) checks cleanly, while a tangled one (vague scope, judgement words, several rules per sentence, buried exceptions) needs a human - drafting, not topic, decides codeability.

Verify-this: dissect the clause before you trust the check

sources evolve · verify the current edition

Find all six parts

Reading a rule for coding

Scope, condition, quantitative threshold, defined terms, cross-references, exceptions - resolve every part, not just the number. Missing the exception or the definition means checking a different, wrong rule. Modules 3.1, 4.3.

Right property, units, direction

Getting the threshold right

A threshold is only correct with the right measured property (clear vs nominal width), units, rounding, comparison direction (min vs max) and quantifier. Small errors give precise wrong answers. Modules 3.1, 5.2.

Ask which part the tool checked

Reading an automated result

Tools often evaluate the clean threshold and drop the exception or qualitative definition, so a pass covers less of the clause than it seems. Always ask what the check actually covered. Modules 4.3, 9.2.

The clause's meaning is the law's

Who fixes what a term means

Defined terms, exceptions and how cross-references resolve are settled by the actual code and the approving authority, never by an encoding. Drafting for machine-readability is a hope, not today's default. Modules 8.1, 8.2.

Hands-on workshop

Just three real clauses and a notebook. No software - this workshop trains your eye to read a rule's anatomy by hand. Binding interpretation of any clause stays with the professional, the authority and the actual code.

Workshop - dissect three real clauses into their anatomy

The fastest way to learn how much of a rule a machine can check is to take real clauses apart by hand. In this workshop you dissect three regulations into their component parts and judge, part by part, what is codeable and what is not.

Given & goal

Goal: fluency in reading a rule's anatomy and judging its codeability
Inputs: three real building rules (mix a clean quantitative one, one with an exception, one with a judgement word) + a notebook
Time: ~45 minutes

1Pick three clauses: one clean quantitative rule (a width, distance or slope), one with an explicit exception or cross-reference, and one containing a judgement word like "adequate" or "suitable".
2Label the anatomy: for each clause, mark the scope/applicability, the condition, the quantitative threshold (if any), the defined terms, the cross-references, and the exceptions.
3For the clean rule, write the check: express the threshold as plain-language logic ("for every X, test property >= value"), and note the exact property, units and comparison direction it needs.
4For the exception rule, trace the branches: write out how the answer changes when the exception applies, and note what model data or human decision you would need to know whether it applies.
5For the judgement rule, mark the gap: identify precisely which word or phrase a machine cannot evaluate, and write one sentence on what a human must decide - flagged as reasoning.

You’ll walk away with
A one-page dissection of three clauses: each labelled with its anatomy, the clean rule written as logic with its property/units/direction, the exception rule traced through its branches, and the judgement rule's uncodeable fragment named - with a short note on how the drafting, not the topic, drove your verdict. Framed as reasoning; keep it.

The worked example

Three altitudes on the same idea

Read the band that fits you — or all three.

For the architectUsing automated checking for early feedback and self-checking - while you and the authority stay accountable

Learn to dissect a clause into its parts - scope, condition, threshold, defined terms, cross-references, exceptions - because that dissection tells you, faster than any tool, how much of the rule is genuinely checkable and where your judgement is still required. When you rely on an automated check, ask which part of the rule it evaluated: most tools check the clean threshold and quietly drop the exception or the qualitative definition, so a green tick may cover far less of the clause than it looks. Watch the defined terms especially - "clear width", "habitable room", "occupant load" carry technical meanings that decide which rule applies and what gets measured, and an encoding that uses a looser meaning is wrong everywhere downstream. Follow the cross-references, honour the exceptions, and confirm units and the measurement basis. The reward is real: for cleanly drafted quantitative clauses, encoding is faithful and the early feedback is worth having. But the authoritative meaning of any clause - its terms, its exceptions, how its references resolve - is the actual code as interpreted by the approving authority, never your encoding of it, and you stay accountable for compliance.

For the interior designerWhere automated rule-checking helps interiors (accessibility, fire, egress) and where judgement is required

The interior rules you deal with - door clear widths, corridor and aisle widths, ramp slopes, exit counts and travel distances, accessible-toilet provisions - are mostly built around clean quantitative thresholds, which is exactly why they encode and check well. But the same anatomy that makes them checkable also hides the traps. A "clear width" is not the nominal door size - it excludes the leaf, frame and hardware - so a check is only right if it measures the property the rule actually names. An exception ("except in existing buildings", "provided the authority agrees") can flip whether your layout passes, and tools often miss it. A defined term like "accessible route" or "place of assembly" decides whether a stricter rule even applies. So when a checker clears your plan, treat it as an early flag on the threshold, not proof the whole rule is satisfied, and read the clause's definitions and exceptions yourself. Coordinate binding accessibility, fire and egress compliance with the qualified professionals, the authority and the governing code - your skill is knowing which parts of a rule the check really covers and which still need a human eye.

For the studentHow regulations become machine-readable rules - and why many rules resist being coded at all

The single most useful habit in this whole field is learning to take a regulation apart into its anatomy - scope, condition, quantitative threshold, defined terms, cross-references, exceptions - and to see which parts are clean logic and which are human judgement. Practise it on real clauses: find the number and its comparison direction and units (the codeable heart), then hunt for the defined terms (does the code's meaning differ from everyday use?), the cross-references (what other clauses does this rule depend on?), and the exceptions (what overrides the base rule, and does any of it hand discretion to a human?). You will quickly see the central truth of rules-as-code: whether a rule can be coded depends far more on how it is *written* than on what it is *about*. Two rules on the same subject can be worlds apart in codeability. This is also why some reformers want future regulation drafted for machine-readability from the start - quantitative separated from qualitative, terms defined, exceptions explicit. Understanding rule anatomy is what lets you judge any clause honestly, and it is a distinctive, rigorous skill few designers have.

Misconception check

“If a rule is about something measurable - a width, a distance, a slope - then it is straightforward to encode and a tool can check it reliably.”

The measurable core of such a rule is indeed codeable, but the topic being quantitative does not make the whole rule straightforward, and assuming it does is how encodings quietly go wrong. Every regulation has an anatomy beyond its threshold: a scope that decides when it applies, defined terms that fix what its words actually mean (a code's "clear width" is not the nominal size; its "habitable room" or "assembly building" carries a precise definition that determines whether the rule even bites), cross-references that chain it to other clauses and standards, and exceptions that override the base rule under stated conditions. A faithful check must resolve all of these, not just the number. Miss the exception and you fail designs the code permits or pass ones it forbids; use a looser meaning than the code's own definition and every downstream result inherits the error; ignore a cross-reference and you check the rule in a broken vacuum. On top of that, even the threshold itself demands care - the right units, the right rounding, the right measurement basis, the right comparison direction, the right quantifier - each a chance for a precise, confident, wrong answer. And many quantitative-looking rules also contain a genuinely qualitative fragment ("adequate", "suitable", "having regard to...") that no encoding can turn into a check. So the honest position is that measurability is necessary but not sufficient: a rule is only as codeable as the *least* codeable part it needs, and the way it is written - not merely its subject - decides how much a machine can truly verify. The authoritative meaning of any clause remains the actual code as interpreted by the approving authority.

Try it

Do it yourself

No software needed - reason it through.

1Name the six recurring parts of a regulation and say what each one contributes.
2Why can two rules on the same topic - say corridor width - differ enormously in how codeable they are?
3What can go wrong if an encoding captures a rule's threshold but ignores its exception?
4Why is a code's defined term (like "clear width") a hidden trap for automated checking?
5When a tool reports a rule as passed, why should you ask which part of the rule it actually evaluated?

Take this with you

The one line to carry out

Every regulation has an anatomy - scope, condition, quantitative threshold, defined terms, cross-references and exceptions - and whether a rule can be automated depends far more on how it is written than on what it is about: the threshold is the codeable heart, but the definitions, the reference web and the exceptions are where faithful encoding lives or dies, so a tool's pass may cover only the tidy part while the real, authoritative meaning of the clause stays with the actual code and the approving authority.

Take it further

References & further reading

Peer-reviewed journals & authoritative standards

01Regulation — Wikipedia - Regulation, 2026.
02Statutory interpretation — Wikipedia - Statutory interpretation, 2026.
03Formal specification — Wikipedia - Formal specification, 2026.
04Decision table — Wikipedia - Decision table, 2026.
05Building code — Wikipedia - Building code, 2026.

Recap

Under the prose, every building regulation shares the same anatomy: a scope or applicability that says when the rule bites, a condition, a quantitative threshold at its core, defined terms that fix precise technical meanings, cross-references that chain it to other clauses and standards, and exceptions that override the base rule under stated conditions. The quantitative threshold - a value, a unit and a comparison - is the codeable heart, translating almost transparently into logic, and it is overwhelmingly what people mean when they say rules-as-code works; but getting even the threshold right demands the correct measured property, units, rounding, comparison direction and quantifier. The surrounding parts are where automated checking meets friction: defined terms whose technical meaning diverges from ordinary use (and if the encoding uses a looser meaning, everything downstream is wrong), cross-references that must all be followed, and exceptions that invert outcomes and are often buried or hand discretion back to a human. The decisive lesson is that whether a rule can be coded depends far more on how it is written than on what it regulates - two rules about the same corridor can sit at opposite ends of the codeability scale, one a clean measurable threshold, the other a judgement ("adequate width... having regard to the character of the building"). So dissect every clause before trusting any encoding of it, ask which part a tool actually evaluated, and remember that the authoritative meaning of a clause - its terms, exceptions and references - is fixed by the actual code and the approving authority, never by its encoded copy.

Carry forward →

Dissecting a rule reveals a deeper fault line running through all regulation: some rules tell you exactly what to do, others tell you what to achieve. That distinction - prescriptive versus performance - decides more about codeability than any other. We turn to it next.

The author

Amogh N P

Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.

More about Amogh →