Lesson 1.2Lesson 1.2 · Why Automate Compliance
Consistency & Error
Two different failures haunt manual checking - inconsistency, where equally competent people read the same rule and reach different answers so outcomes feel arbitrary, and plain error, where a clause is simply missed in a mass of drawings - and automating the checkable subset attacks both, because a machine applies the same encoded rule the same way every time and never gets tired of looking
Two people who both know the code can look at the same drawing and disagree about whether it complies. And one tired person can miss a clause entirely. Those are different failures - and automation helps with both.
When manual checking goes wrong, it goes wrong in two very different ways, and it helps enormously to keep them apart. The first is inconsistency: two equally competent professionals, or two plans-examiners at the same authority, read the same rule and the same drawing and reach different conclusions - one passes it, one objects. Nobody made a mistake in the ordinary sense; they simply interpreted a rule, or measured a borderline case, differently. The outcome starts to feel arbitrary, as though compliance depends on who happens to check.
The second failure is error: a clause that clearly applies is simply not checked at all. In a submission of hundreds of drawings governed by thousands of provisions, a human inevitably overlooks things - a corridor whose width nobody re-measured after a late change, a fire-exit travel distance that was never recomputed, a setback encroached by half a metre in one corner. This is not disagreement; it is an omission, and it is exactly the kind of failure that surfaces late and expensively. Automating the checkable subset attacks both failures at once, but for different reasons: it is consistent because a machine applies the same encoded rule identically every time, and it is thorough because it never tires of checking every element. This lesson separates the two, and is careful about where automation genuinely helps and where it cannot.
Two failures: INCONSISTENCY (same rule, different answers) + ERROR (applied rule, never checked). Machine = deterministic (cures 1st) + exhaustive (cures 2nd). But only within encoding + data. Not an approval.
Inconsistency - the same rule, different answers
The first failure is that manual checking is not reproducible. Give the same drawing and the same rule to two competent professionals, and you will not always get the same verdict. This happens for reasons that are not anyone's fault. Some rules use language that genuinely admits more than one reading - 'adequate', 'suitable', 'where practicable' - and reasonable experts differ on what it requires here. Some involve a measurement at a boundary, where one person calls a 2.98-metre corridor a pass against a 3.0-metre rule and another calls it a fail. Some depend on how you classify the thing being checked - is this space a corridor or a lobby, an assembly occupancy or a business one - and the rule that applies, and therefore the answer, changes with the classification.
The result is that compliance can feel arbitrary. The same design might be objected to by one examiner and waved through by another; a resubmission after a personnel change can get a different reading; two firms checking the same rule reach different internal standards. This is corrosive in a way that goes beyond any single project: it undermines trust in the process, invites the suspicion that outcomes turn on who checks rather than what the rule says, and in some contexts opens the door to discretion being applied unevenly. In the Indian setting, where a great deal of approval is manual and locally variable across thousands of urban local bodies, inconsistency is a well-known feature of the landscape.
It is important to be precise about which inconsistency automation can cure. Where the rule is clear and quantitative - a definite width, distance, slope or area tested against a definite threshold - encoding it removes the variance entirely: the machine computes the same number and applies the same comparison every time, so two runs, two firms, two moments give the identical answer. That is a genuine gain in fairness and predictability. But where the inconsistency comes from real ambiguity or from a judgement about classification, automation does not resolve it - it only relocates it, into the choices made when the rule was encoded and when the model was classified. Those choices can be made consistent and written down, which is itself valuable, but they are still human judgements. So automation cures the inconsistency that came from mechanical variance, and makes visible - rather than eliminates - the inconsistency that came from genuine interpretation.
Error - the clause nobody checked
The second failure is different in kind. Here there is no disagreement about what the rule means; the rule simply was not applied, because a person missed it. In a real submission the sheer volume defeats exhaustive human attention: hundreds of sheets, thousands of rooms, doors, corridors and dimensions, and a rulebook spread across the National Building Code, local byelaws and several IS standards. To check every applicable rule against every relevant element, by hand, without ever skipping one, is beyond what a tired human reliably does - especially near a deadline, especially after the design has changed and dozens of earlier checks silently became stale.
The characteristic errors are omissions: a corridor narrowed by a late wall move that nobody re-measured; a fire-exit travel distance that grew past the limit when a partition shifted; a required light-and-ventilation area that a room lost when it was subdivided; a setback quietly encroached in one corner of a complex plot; a ramp that ended up a fraction too steep. Each is individually obvious once pointed out - which is exactly what makes them frustrating - but each was buried in a mass of information where no one happened to look. These are the violations that ride the rising-cost curve into late discovery, because nothing catches them early.
This is the failure automation is best suited to, and for a simple reason: a machine does not get bored, does not run out of attention, and does not skip the boring three-hundredth corridor. Point an encoded rule at a structured model and it checks *every* element the rule applies to, exhaustively and identically, in seconds - and it re-checks them all the instant the design changes, so a check never goes stale unnoticed. For the checkable subset, this converts 'we probably checked most of them' into 'every one was tested', which is a real and important gain in thoroughness. The honest caveat is that the machine can only catch what its encoded rules cover and what its model data represents: a rule not encoded is not checked, and an element mis-classified or missing from the model is invisible to the check. So automation dramatically reduces the missed-clause error within its coverage, while creating a new responsibility - making sure the coverage and the data are complete - that is itself human work.
Inconsistency = same rule, two answers (interpretation). Error = a rule that applied but nobody checked (omission). Different failures - both eased by automating the checkable.
Why manual checking is inconsistent and error-prone
It helps to understand why these two failures are structural, not a matter of carelessness or poor training. They arise from the nature of the task. Manual checking asks a human to do two things that humans are, respectively, variable at and unreliable at. The first is *interpretation*: reading regulatory language, some of it genuinely open-textured, and deciding what it requires in this case. Human interpretation is legitimately variable - it draws on experience, context and judgement, which is exactly why we value expert judgement for the hard cases, but also why two experts differ. That variability is a feature when the question is genuinely a matter of judgement and a bug when the question actually has one right mechanical answer.
The second is *exhaustive mechanical comparison*: taking every applicable quantitative rule and testing it against every relevant element, without ever tiring, skipping, or losing track after a change. Humans are simply not built for this at scale. Attention is finite, boredom is real, working memory is small, and the rulebook plus the drawing set together far exceed what one mind holds at once. So omissions are not moral failures; they are the predictable output of asking a limited cognitive system to do unlimited, monotonous, error-intolerant bookkeeping.
Seeing the task this way explains why one tool helps both failures, and why it helps them differently. A machine is *deterministic* - it applies the same encoded rule the same way every time - so it removes the mechanical variance that caused the curable part of inconsistency. And a machine is *tireless and exhaustive* - it checks every element without boredom or memory limits - so it removes the omissions that caused error. Crucially, the machine is good at exactly the half of the task humans are bad at (tireless mechanical comparison) and silent about exactly the half humans are valuable at (genuine interpretation). This is the deepest reason automation and human judgement are complements rather than rivals: they are strong and weak on opposite halves of the checking task. The design principle that follows is to give the mechanical, checkable half to the machine, precisely because that is where human inconsistency and error concentrate, and keep the interpretive half with the professional, precisely because that is where human judgement is irreplaceable.
How automating the checkable improves both - and its limits
Put the two failures together and the value of automating the checkable subset becomes precise. Against inconsistency, a machine offers *determinism*: for a clear quantitative rule, it computes the same result every time, for every user, in every run, so the mechanical variance that made outcomes feel arbitrary disappears. Two firms checking a setback, two examiners screening coverage, the same file checked twice - all get the identical answer. Against error, a machine offers *exhaustiveness*: it tests every relevant element against every encoded rule and re-tests on every change, so the clause nobody happened to check is checked. Together these turn 'probably consistent, probably complete' into 'provably the same rule applied to provably every element' - within the encoded, checkable subset. That is a real quality-assurance gain, and it is the honest core of why we automate.
But the limits must be stated as plainly as the gains, or the lesson becomes the very over-promise this course warns against. Determinism is only as good as the encoded rule: if the rule was encoded wrongly or is out of date, the machine will be consistently, reproducibly wrong - a worse trap in some ways than human variance, because it wears the mask of objectivity. Exhaustiveness is only as good as the coverage and the data: a rule not encoded is silently unchecked, and an element missing or mis-classified in the model is invisible, so 'every element passed' can hide 'the element that mattered was not in the model'. And neither property touches the interpretive failures at all: where inconsistency comes from genuine ambiguity, automation relocates the judgement into the encoding rather than resolving it. Above all, the deterministic green tick is a magnet for automation bias - the human tendency to over-trust a confident machine and stop looking. So the correct reading is disciplined: automating the checkable genuinely improves consistency and reduces missed clauses for the rules it covers, which is worth a great deal - but it is a quality-assurance aid, never a guarantee and never an approval, and the professional and the authority remain accountable for the interpretation, the coverage, the data and the final judgement of compliance.
Inconsistency vs error
Two distinct failures
Inconsistency = the same rule read differently (interpretation, borderline measurement, classification). Error = a rule that applied but nobody checked (omission). Keep them separate. Lesson 1.1; Module 2.4.
Determinism
The consistency gain and its limit
A machine applies the same encoded rule identically every time - curing mechanical variance. But a wrongly encoded or outdated rule is consistently wrong; genuine ambiguity is relocated, not resolved. Module 3.4; Module 9.2.
Exhaustiveness
The completeness gain and its limit
A machine tests every element and re-tests on change - curing missed clauses within coverage. But an un-encoded rule or missing/mis-classified data is invisible to the check. Module 5.2; Lesson 1.4.
Automation bias
The hazard of the green tick
A confident deterministic pass invites over-trust and stopping looking; it is a quality-assurance aid, never an approval. The professional and authority stay accountable. Lesson 1.4; Module 9.4.
Workshop - reproduce the two failures by hand
The best way to believe in the two failures is to reproduce them. In this workshop you will deliberately provoke inconsistency and error on a small set of rules, then reason about which an encoded check would cure and which it would only relocate.
A small drawing, a handful of rules, and ideally a second person. No software - this workshop is about feeling the two failures directly; encoded rules and engines come later, and binding compliance stays with the professional, the authority and the actual code.
Goal: feel the difference between inconsistency and error, and where automation helps Inputs: 5-6 real rules (some clear, some vague) + one small drawing + two people if possible Time: ~45 minutes
- 1Pick 5-6 rules: include some crisply quantitative (a corridor width, a travel distance, a ramp slope) and some open-textured (adequate ventilation, suitable access, a classification-dependent rule).
- 2Provoke inconsistency: have two people (or yourself on two different days) judge the design against each rule independently, and record where the answers differ and why - ambiguity, a borderline measurement, or a classification choice.
- 3Provoke error: check the full set against a busy drawing under a short time limit, then check again slowly; note any clause you missed the first time, and what made it easy to overlook.
- 4Classify each disagreement and each miss: would a deterministic encoded check have removed it (mechanical variance, omission), or only relocated it into how the rule was encoded or the model classified (genuine interpretation)?
- 5Write a one-paragraph reflection - flagged as reasoning - on which failures automation genuinely cures, which it only makes visible, and why the confident green tick would still need a human behind it.
You’ll walk away with
A one-page log: the rules, where two readings disagreed (and why), which clause was missed under time pressure, a column marking each as curable-by-automation or only-relocated, and a reasoning paragraph on the limits - not a compliance verdict.
Three altitudes on the same idea
Read the band that fits you — or all three.
Two failures cost you differently, and automation helps each in its own way. Inconsistency - a rule read one way by your team, another by the examiner, another on resubmission - makes outcomes feel arbitrary and drives objection cycles; for clear quantitative rules (widths, distances, setbacks, coverage, floor-space index) encoding removes that mechanical variance so everyone gets the same answer. Error - a clause missed in a mass of drawings after a late change - is what rides the cost curve into expensive late discovery; a machine checks every element exhaustively and re-checks on every change, so stale checks do not survive unseen. Use automated checking as a quality-assurance layer over the checkable rules: self-check exhaustively and deterministically before submission. But hold the limits firmly - a consistently applied wrong or outdated encoded rule is a subtle trap, missing or mis-classified model data hides real violations, and a green tick invites automation bias. You and the approving authority remain accountable for interpretation, coverage, data and the final judgement of whether the design actually complies; the authoritative rule is always the real code and byelaw.
In interiors the two failures show up as inconsistent readings of accessibility and egress rules, and as missed checks after fit-out changes. Is this a corridor or a lobby? Does this count as an accessible route? Different people answer differently, and the applicable width or provision shifts with the answer - that is inconsistency, and for the clearly quantitative parts (door and route clear widths, turning space, ramp slope, aisle widths, exit counts and travel distances) an encoded check gives one reproducible answer. Meanwhile a late layout change quietly narrows a doorway or lengthens an escape route and, under deadline, nobody re-checks - that is error, and a machine that re-tests every element on every change catches it while it is still a line on a plan. Treat automated checking as an early quality-assurance aid for the checkable interior rules, not a verdict: whether a route is genuinely usable is judgement, a pass is not an approval, and binding fire, egress and accessibility compliance stays with the qualified professionals, the authority and the governing code (NBC India, accessibility standards).
Learn to separate the two ways manual checking fails, because they are genuinely different and automation helps each for a different reason. Inconsistency is when equally competent people apply the same rule and reach different answers - from ambiguous language, borderline measurements, or how a space is classified - so outcomes feel arbitrary. Error is when a clause that clearly applied was simply not checked, an omission buried in a mass of drawings. A machine helps the first because it is deterministic (the same encoded rule, applied identically every time) and the second because it is exhaustive and tireless (it checks every element and re-checks on every change). The deep insight is that the machine is strong at exactly the mechanical half of checking humans are weak at, and silent about the interpretive half humans are valuable at - which is why they are complements, not rivals. Hold the honest limits too: determinism only helps if the encoded rule is right, exhaustiveness only helps if coverage and data are complete, genuine ambiguity is relocated not resolved, and the confident green tick invites automation bias. A check improves quality; it is never an approval.
“Automated checking is just faster manual checking - it does the same comparisons quicker, so its real value is speed. Consistency and completeness are basically the same thing as being fast, and a fast automated pass means the design has been fully and correctly checked.”
Do it yourself
No software needed - reason it through.
- 1Distinguish inconsistency from error in manual checking, with a concrete example of each.
- 2Why can two competent professionals reach different verdicts on the same rule and drawing without either being careless?
- 3Explain why a machine helps inconsistency (determinism) and error (exhaustiveness) for different reasons.
- 4Give the honest limit on each gain: when is determinism dangerous, and when does exhaustiveness miss something real?
- 5Why are automation and human judgement complements rather than rivals on the checking task?
The one line to carry out
Peer-reviewed journals & authoritative standards
- 01Model checking — Wikipedia - Model checking, 2026.
- 02Automation bias — Wikipedia - Automation bias, 2026.
- 03Quality assurance — Wikipedia - Quality assurance, 2026.
- 04Statutory interpretation — Wikipedia - Statutory interpretation, 2026.
Consistency and completeness are two of the three great gains from automating the checkable. The third, and the biggest prize, is speed - not just faster checking, but checking early and often, so issues surface while they are still cheap to fix. That is 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 →