Lesson 4.3Lesson 4.3 · Automated Code Checking
What Can & Cannot Be Checked
The sharpest, most useful skill in the field: telling apart the rules a machine can genuinely check from the rules that need missing data, external facts, engineering analysis or human interpretation - and knowing checkability is a spectrum
The most valuable thing a compliance-literate designer can do is look at a rule and know, instantly, whether a machine can check it at all.
Everything in this course converges on one judgement: given a real building rule, can it be checked automatically, or does it need a human? Get that right and automated checking becomes a precise tool you point at exactly the right rules. Get it wrong and you either waste effort trying to code the uncodeable, or - far worse - trust a machine on rules it was never able to evaluate. The boundary is not mysterious; it follows from how the pipeline works. A check can only run a rule that reduces to finding elements, reading a property, and testing a condition against present data. The moment a rule needs something outside that shape, it slides out of reach.
This lesson builds a practical taxonomy of checkability. On the checkable side sit the geometric and quantitative rules - minimum widths, maximum distances, slopes, areas, coverage, counts - that are the staples of everyday development-control and life-safety scrutiny and that automate genuinely well. On the other side sit four families of rules that resist coding: those that need data not in the model, those that depend on facts about the real world, those that require engineering analysis, and those that turn on interpretation and judgement. Between the poles is a spectrum, not a switch: a rule can be partly checkable, and can move toward the checkable end as your model improves - or stay stubbornly human no matter how good the data. Learning to place a rule on that spectrum is the sharpest skill in the field.
Checks well: widths, distances, slopes, areas, counts (codeable rule + present data). Resists: missing data / external facts / needs analysis / needs interpretation. It is a SPECTRUM - and a clean run != the whole code.
What checks well: geometric and quantitative rules against present data
Start with the rules automated checking genuinely serves, because the good news is real. A rule is cleanly checkable when it reduces to the pipeline's shape: identify a set of elements, read a property that is present in the model, and test it against a definite condition. This describes a large and important body of everyday regulation. Dimensional minimums and maximums: a corridor's clear width shall be at least so many metres, a door's clear opening at least so wide, a ramp's slope no steeper than a stated gradient, a stair's riser and tread within limits. Distances: the travel distance to the nearest exit shall not exceed a stated length. Areas, coverage and ratios: ground coverage, floor-space index, minimum room areas, window-to-floor ratios. Counts: the required number of exits, sanitary fixtures, or accessible parking bays for a given occupancy.
What these share is decisive. Each names elements a model can carry as typed objects; each turns on a property that is quantitative and either stored or derivable from geometry; and each specifies a clear, unambiguous condition. There is no interpretation to do - 1.5 m either is or is not at least 1.8 m - so the machine's tireless, repeatable comparison is exactly the right tool. These are also, not coincidentally, the rules that dominate Indian plan-scrutiny: the setbacks, coverage, FSI and height limits of development-control regulations, and the widths, distances and counts of life-safety provisions, are overwhelmingly of this quantitative kind. That is why automated development-control checking has genuine traction even where richer modelling is rare.
Be precise about the condition for checkability, though, because it has two halves. The rule must be *codeable* - reducible to scope, property, comparison and threshold - and the data must be *present and correct* in the model. Both are required. A perfectly codeable width rule is useless if corridors are not modelled as corridors; a perfectly modelled corridor is untestable if the rule it must satisfy is a matter of judgement. The checkable rules are precisely those where a codeable rule meets present, trustworthy data. Get both and you have the field's genuine, demonstrated value: fast, consistent, early verification of the mechanical, quantitative backbone of compliance. Everything else in this lesson is about the rules that fail one of those two halves.
Four families of rules that resist coding
Now the honest half. A great deal of regulation cannot be run through the pipeline, and it fails for four distinct reasons worth naming, because each fails differently. The first family needs data not in the model. A rule may be perfectly quantitative - a fire door of a given rating, a material of a stated property - yet be uncheckable simply because that property was never captured. This family is not uncheckable in principle; it is uncheckable in practice until the data exists, and it is the family that moves as models improve. It is also the source of most cannot-determine verdicts.
The second family depends on facts about the real world that no model holds. Whether the soil can bear the foundation, what the neighbouring building actually is, how the space will be used in practice, whether a site-specific hazard exists - these are facts about the world, not properties of the design, and a checker has no access to them. No amount of modelling brings the soil report or the neighbour's use into the file.
The third family requires engineering analysis or specialist judgement. Performance rules - 'the structure shall safely resist the design loads', 'the smoke-control system shall maintain a tenable environment' - are not comparisons against a stored property; they demand simulation, calculation and a qualified professional's assessment. A checker can confirm that a structural model exists, but not that the structure is safe; that is an engineer's determination.
The fourth, and deepest, family turns on interpretation and judgement. Rules riddled with terms like 'adequate', 'suitable', 'reasonable' or 'appropriate' have no single machine-testable meaning; their content is settled by context and expertise. And above the individual rule sits the interpretive work of deciding *which* rule even applies to this case, and how two rules that seem to conflict reconcile - exactly the expert reasoning a plans-examiner and a designer perform, and which no current system does reliably.
Naming the four families is practical, not academic. Missing data can be fixed by better modelling; external facts require bringing in information from outside; analysis requires the right specialist and tools; interpretation requires human judgement that will not be automated away. Knowing which kind of uncheckable you face tells you what to do about it - and tells you, crucially, when the honest answer is that a machine simply cannot help.
Checkability is a spectrum, and rules can move along it
It is tempting to sort every rule into a clean 'checkable' or 'not' box, but the truth is a spectrum, and treating it as one makes you far more useful. At one end sit the cleanly runnable rules: a codeable condition meeting present, trustworthy data. At the other end sit the purely human rules: interpretation, performance and judgement that no data completeness will ever reduce to a comparison. In between lies a wide middle band of partly checkable rules - codeable in form but needing data you do not yet have, or checkable only for a component of the rule while another component needs a human.
What makes the spectrum a working tool is that rules can move along it. A rule that is uncheckable today because a property was never modelled becomes checkable the moment that data is captured - it slides toward the checkable end as your model improves. This is the productive kind of uncheckability: it is an argument for better modelling and data standards, and it is exactly the territory Module 5 addresses. Much of what looks uncheckable is really under-modelled. Conversely, no improvement in data moves a genuinely interpretive or performance rule; 'adequate ventilation' does not become codeable because you added more properties. Those rules are anchored at the human end.
This reframes the taxonomy into a diagnosis with an action attached. For a rule near the checkable end: run it, and trust the verdict as far as you trust the data. For a partly-checkable rule blocked by missing data: decide whether capturing that data is worth it, and until then treat the rule as a cannot-determine that needs a human. For a rule anchored at the human end: do not try to code it, do not pretend a green run covered it, and route it to the professional judgement it requires. The skill is not memorising a fixed list of checkable rules; it is looking at any rule and placing it on the spectrum, naming why it sits there, and knowing what - if anything - would move it. That single judgement, exercised honestly, is what lets you use automated checking exactly where it earns its place and no further, and it is the through-line that keeps the green tick from being mistaken for coverage of the whole rulebook.
Using the boundary honestly - the danger of the invisible gap
The taxonomy earns its keep by preventing a specific, dangerous error: mistaking the checked rules for the whole rulebook. When a self-check comes back clean across the rules a tool could run, it is easy to feel the design is compliant. But a clean run says nothing about the uncheckable rules - the performance clauses, the judgement-laden terms, the rules blocked by missing data, the interpretive question of which rule applies. Those rules did not fail; they were never evaluated. The gap between 'passed the checkable rules' and 'complies with the code' is invisible in the report, and automation bias makes it easy to forget the gap is there at all.
Using the boundary honestly means keeping that gap visible. Before trusting any checking result, ask what fraction of the *relevant* rules the tool could actually run - and treat the remainder as explicitly open, routed to human judgement rather than silently assumed satisfied. A mature checking practice maintains, in effect, two lists: the codeable rules the machine handles, and the uncheckable rules a human must still assess, deliberately and on the record. The automated report covers the first list; it must never be read as covering the second.
This is also where the honest India-aware picture sharpens. The quantitative development-control rules that dominate plan-scrutiny sit squarely on the checkable side, which is genuinely encouraging - automating them offers real speed and consistency, and reduces the room for arbitrary or discretionary handling of what should be a mechanical check. But the deeper compliance judgements, the performance assessments, and the interpretation of byelaws that vary enormously across thousands of local bodies remain human, and pretending a tool has covered them would be exactly the compliance-washing this course warns against.
So hold the discipline. Place each rule on the spectrum; run the ones that a codeable rule and present data make genuinely runnable; treat missing-data cases as fixable-if-worth-it cannot-determines; route performance and interpretation to the accountable professional; and never let a clean run across the checkable subset stand in for compliance with the whole code. The taxonomy is not a way to shrink the human's job to the leftovers - it is a way to aim automation precisely and keep human judgement exactly where regulation genuinely requires it. The qualified professional of record, the approving authority and the actual law remain accountable for the whole rulebook, checkable and uncheckable alike.
Checkable = codeable rule + present data
What checks well
Geometric and quantitative rules (widths, distances, slopes, areas, coverage, counts) with the data modelled. Both halves are required. Modules 4.1, 5.2.
Four families of uncheckable
Why a rule resists coding
Missing data, external real-world facts, needs engineering analysis, or needs interpretation and judgement. Each fails differently and needs a different response. Modules 2.4, 9.2.
Checkability is a spectrum
Rules can move along it
Missing-data rules slide toward checkable as the model improves; interpretation and performance rules stay anchored at the human end. Diagnose, then act. Module 5.2.
The invisible gap
The danger to guard against
A clean run covers only the checkable rules; the uncheckable ones were skipped, not satisfied. Keep two lists and route the human-anchored rules to judgement. Modules 9.1, 9.4.
Workshop — build a checkability map of real rules
The taxonomy only becomes yours when you use it on real, messy rules. In this workshop you will place a set of genuine building rules on the checkability spectrum, name why each sits where it does, and - crucially - say what, if anything, would move it toward the checkable end.
Just a set of real rules and somewhere to draw a line - no software needed, because the skill is judgement about rules, not running a tool; the tools come in lesson 4.4, and binding compliance always stays with the professional, the authority and the actual code.
Goal: turn the taxonomy into a working diagnostic you can apply on sight Inputs: 8-10 real rules across domains + a notebook or a printed spectrum line Time: ~50 minutes
- 1Gather 8-10 real rules spanning domains: some dimensional (widths, slopes, setbacks, coverage), some performance ('shall safely resist'), some judgement-laden ('adequate', 'suitable'), and some needing outside facts (soil, neighbour, use in practice).
- 2Place each rule on a line from 'cleanly checkable' to 'purely human', and for each name the reason: codeable-and-data-present, missing-data, external-fact, needs-analysis, or needs-interpretation.
- 3For every rule you did NOT place at the cleanly-checkable end, write what (if anything) would move it left: which property to model, which fact to bring in, which specialist to involve - or 'nothing, it is anchored human' and why.
- 4Split your rules into two explicit lists: the ones a checker could genuinely run, and the ones a human must assess regardless. Note how a clean run on the first list would look if mistaken for the whole.
- 5Write a reflection: roughly what fraction was cleanly checkable, how many were merely under-modelled versus permanently human, and why keeping the two lists separate guards against the invisible gap - flagged as reasoning.
You’ll walk away with
A one-page checkability map: 8-10 real rules placed on the spectrum with a named reason each, a 'what would move it' note for the non-checkable ones, an explicit split into machine-runnable and human-only lists, and a reflection on the invisible gap. Keep it - it is the practical core of the whole course.
Three altitudes on the same idea
Read the band that fits you — or all three.
Your most valuable compliance skill is placing any rule on the checkability spectrum and acting on where it sits. Cleanly checkable rules - widths, distances, slopes, setbacks, coverage, FSI, counts - are the quantitative backbone of development-control and life-safety scrutiny, and you should run them early and often, trusting each verdict as far as you trust the model data behind it. But keep two lists in practice: the codeable rules the tool handles, and the uncheckable ones a human must still assess - performance clauses needing engineering analysis, judgement-laden terms ('adequate', 'suitable'), rules blocked by missing data, and the interpretive question of which rule applies. The danger is the invisible gap: a clean run across the checkable subset is not compliance with the whole code, because the uncheckable rules were never evaluated, only skipped. Make that gap explicit, route the human-anchored rules to the professionals and the authority, and remember the authoritative rule is always the actual NBC provision, byelaw or IS standard.
In interiors the checkable and uncheckable sit side by side within the same requirement, so the taxonomy is a daily tool. Accessibility and egress carry genuinely checkable parts - accessible-route and door clear widths, wheelchair turning space, ramp slopes, aisle and corridor widths, exit counts, travel distances - that a well-modelled fit-out lets a checker verify early. But the same domain is full of the uncheckable: whether a route is actually usable, whether wayfinding is legible, whether 'adequate' provision has been made, whether the space works for a real person with a real impairment. Those are judgement, not comparison, and no model completeness reduces them to a test. Run the checkable dimensions to catch the under-width door or the too-steep ramp early; then treat the passing check as a floor, not proof of genuine accessibility, and keep the human judgement the domain demands. Binding fire, egress and accessibility compliance stays with the qualified professionals, the authority and the code.
The one skill to master here is telling, at a glance, whether a rule can be checked by a machine - and why. Checkable rules reduce to the pipeline's shape: find elements, read a present property, test a clear condition - so geometric and quantitative rules (widths, distances, slopes, areas, coverage, counts) check well, and they happen to be the staples of everyday scrutiny. Uncheckable rules fail in four distinct ways: they need data not in the model, they depend on facts about the real world, they require engineering analysis, or they turn on interpretation and judgement ('adequate', 'suitable', which rule applies). And checkability is a spectrum, not a switch: missing-data rules can slide toward checkable as the model improves, while interpretation and performance rules stay anchored at the human end no matter how good the data. Learn to place any rule on that spectrum, name why it sits there, and say what would move it - and never mistake a clean run across the checkable rules for compliance with the whole code.
“As modelling and software keep improving, eventually almost every building rule will become checkable - the set of rules a machine cannot check is just a temporary gap that better data and cleverer tools will close.”
Do it yourself
No software needed — reason it through.
- 1State the two conditions a rule must meet to be cleanly checkable, and why both are required.
- 2Name the four families of uncheckable rules and give one example of each.
- 3Explain why checkability is a spectrum and which family of rules can move along it - and which cannot.
- 4What is 'the invisible gap', and why does a clean run across the checkable rules not mean the design complies?
- 5Take one judgement-laden rule ('adequate' or 'suitable') and explain exactly why no better data makes it codeable.
The one line to carry out
Peer-reviewed journals & authoritative standards
- 01Performance-based building design — Wikipedia — Performance-based building design, 2026.
- 02Statutory interpretation — Wikipedia — Statutory interpretation, 2026.
- 03Constraint satisfaction — Wikipedia — Constraint satisfaction, 2026.
- 04Floor area ratio — Wikipedia — Floor area ratio, 2026.
Knowing which rules can be run, you are ready to look at what runs them. Next we survey the categories of checking software - model-checking platforms, rule-authoring environments and authority permit systems - how to judge them, and why the human still reads every report.
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 →