How would I actually catch a false pass, if it looks exactly like a real pass?

You catch it not by staring harder at the design check but by checking the DATA separately, before you trust any pass - which is exactly why data validation is a distinct first stage. A false pass is produced by a specific data fault: an element that should have been tested was mis-classified so the rule never selected it, a needed property was missing so the rule had nothing to evaluate, or a unit slip made a bad value look compliant. Each of those is detectable by data-quality checks that ask questions about the model itself rather than about the building rules: does every space that a human would call a corridor carry the corridor classification? does every corridor carry a clear_width value at all? are all lengths in the expected unit and within a sane range? are there elements with no classification, or duplicates? A good checking workflow runs these quality checks first and reports coverage - how many elements of each class it found, how many were missing key properties, how many it could not determine - so that a 'pass' comes with evidence of what was actually tested rather than a bare tick. The honest discipline is to never read a pass in isolation: read it together with the coverage and the validation report, and treat 'cannot determine' results as seriously as fails. And even a pass backed by clean validation is not a legal approval - it means the encoded rules found no flaggable issue in a model you have assured is trustworthy, while whether the design actually complies stays with the qualified professional of record, the approving authority and the governing code and byelaws.

Is this data-quality problem specific to India, or is it universal?

The principle is completely universal - a check anywhere is only as good as the data it runs on, and false passes and false fails from mis-classification, missing properties, unit mismatches and wrong level of detail happen in every context. But the shape of the problem does differ, and India has some specific realities worth naming honestly. In places with mature, widely-adopted structured-modelling practice and agreed data standards, the data is more likely to reach a fitness where automated checking is reliable, though even there poor data quality is a common and serious cause of failed or misleading checks. In India, the more immediate constraint is often upstream of data quality altogether: many submissions are still 2D drawings rather than structured models, so the question is frequently not 'is the model's data clean?' but 'is there structured data at all?'. Where structured models do exist, the same four faults apply, and unit handling deserves particular care given mixed conventions. The encouraging part is that the quantitative development-control checks that dominate Indian plan-scrutiny - setbacks, ground coverage, floor-space index, height - need a relatively modest, achievable level of data (an accurate plot, footprint, floor areas and height), so reaching basic data fitness for those checks is a realistic first target rather than a distant ideal. The uniform lesson, India or anywhere, is that data quality is a precondition someone must own, not a detail that takes care of itself - and that no level of data fitness converts a check into a determination of compliance, which always rests with the professional, the authority and the actual byelaw and code.

Lesson 5.2

Automated Compliance & Rules-as-Code/Module 5 · The Data It Needs

Lesson 5.2 · The Data It Needs

Data Quality & Checkability

A structured model is necessary but not sufficient - a check runs on the data it is given, so the model must be correctly classified, complete in the properties each rule needs, consistent in its units and at the right level of detail; when any of that is missing the check does not fail loudly, it fails silently, returning a false pass that hides a real violation or a flood of false fails that trains everyone to ignore the tool, which is why data quality is the quiet centre of whether automated checking helps or harms

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

The hook

The most dangerous automated check is not the one that fails. It is the one that passes on data that was quietly wrong.

Imagine two identical-looking checking runs on two models of the same building. Both finish in seconds; both show a reassuring green tick against the corridor-width rule. In the first model, the corridors are correctly classified and each carries an accurate clear_width, so the pass is real. In the second, one escape corridor was accidentally modelled as a generic space with no width property - so the width rule never found it, never tested it, and reported nothing wrong. The tick is identical. The buildings are not. The second model has an under-width escape route that the check silently waved through, and nobody was warned, because the tool did exactly what it was told: it checked the data it was given, and the data hid the problem.

This is the uncomfortable heart of automated compliance. A structured model, as the last lesson showed, is what makes checking possible - but a structured model is not automatically a checkable one. A check runs on the data, and if that data is mis-classified, incomplete, inconsistent in its units, or at the wrong level of detail, the check does not throw an obvious error. It fails silently: a false pass that hides a real violation, or a flood of false fails that buries the real ones and teaches everyone to distrust the tool. This lesson is about what actually makes a model checkable, and about the quiet, unglamorous discipline of data quality - the thing that most decides whether automated checking helps or harms, and the thing most often neglected.

Green tick over bad data = FALSE PASS (real violation hidden). Messy data over good design = FALSE FAIL flood (tool ignored). Validate the DATA before you trust the check.

The four pillars

What makes a model checkable

Being a structured model is the entry ticket, not the finish line. Four properties of the data decide whether a rule can actually be run against it well, and it helps to name them as pillars.

Correct classification. Every element must be tagged as what it genuinely is, in a way the rule recognises: a corridor classified as a corridor, an escape door as an escape door, a habitable room as a room of that occupancy. A rule finds the elements it should test by their class, so a mis-classified element is invisible to the rule - present in the model, absent from the check. Classification is the hinge on which everything else turns.

Complete properties. Classification tells the rule which elements to test; properties give it the values to test. A minimum-width rule needs each corridor to actually carry a clearwidth; an occupant-load rule needs each space to carry an occupancy and an area; an accessible-door rule needs a clearopening. If the property is absent, the rule has nothing to evaluate - and whether that shows up honestly depends on the engine and the next pillars.

Consistent units. A number without a trustworthy unit is a trap. If the rule expects metres and the property holds millimetres, 1200 is read as 1200 m and sails past a 2 m minimum; if a genuine 1.2 m is read as millimetres, a perfectly good corridor is failed. The value can be arithmetically 'right' and still produce a wrong result because the unit was assumed rather than known. Consistent, declared units across the model are not a nicety; they are a correctness condition.

Right level of detail. The model must be detailed enough to answer the rule, but not so cluttered that it drowns the rule in noise. Too coarse, and the rule cannot resolve the thing it needs (a door with no defined opening cannot be width-checked). Too fine or messy, and spurious geometry produces false flags. The right level of detail is 'enough to answer the applicable rules, cleanly' - and it differs by rule.

The sharp lesson is that these are not separate nice-to-haves; a weakness in any one silently degrades the check. And crucially, the degradation is quiet: a model can look complete, render beautifully, and still be uncheckable in ways only a data audit would reveal. That is why serious automated checking always begins with checking the data, not the design.

Zoom

The four pillars that hold up automated checking. A model is checkable only when its elements are correctly classified (a corridor tagged a corridor, so a rule can find it), its properties are complete (the value a rule reads - clear_width, occupancy, area - is present), its units are consistent (1.2 m stored as 1.2 m, not 1200 in a guessed unit) and its level of detail is right (enough to answer the rule without drowning it in false noise). Remove any one pillar and the check does not fail loudly; it fails silently, as a wrong pass or a flood of wrong fails, both of which mislead.

Checkable = correct CLASSIFICATION + complete PROPERTIES + consistent UNITS + right LEVEL OF DETAIL. Weaken one and the check fails - quietly.

The faults

The four data faults - and how each one breaks a check

Turn the four pillars over and you get the four faults, each with its own signature failure. Naming them precisely is what lets a designer anticipate and catch them.

Mis-classification is the most insidious because it makes an element invisible to the rule that should test it. If an escape corridor is modelled as a generic space, or a fire door as an ordinary door, the width rule or the fire-rating rule simply never selects it - it iterates over corridors, this element is not a corridor as far as the data is concerned, so it is never tested. The result is a false pass with no warning: the tool reports no problem because it never looked at the element at all. Nothing in the run says 'I skipped something'.

Missing properties leave the rule with the right element but no value to test. A correctly classified corridor with no clear_width cannot be width-checked. A well-behaved engine will report 'cannot determine' - honestly flagging that it lacked the data - but a careless engine, or a careless reading of one, may silently skip the element or default it, turning a gap into an apparent pass. The honesty of how missing data is handled is itself a quality issue.

Unit mismatch is the quiet arithmetic trap from the last section: the number is present and even plausible, but the unit the model stored is not the unit the rule assumed. Millimetres read as metres cause a gross false pass; metres read as millimetres cause an absurd false fail. Because the value looks reasonable, this fault is easy to miss and hard to spot after the fact.

Wrong level of detail breaks checks at both ends. Too coarse and the rule cannot resolve what it needs. Too fine, messy or duplicated and the model throws spurious geometry that trips rules and produces a flood of false fails - and a flood of false fails is not a harmless nuisance: it trains the user to dismiss flags wholesale, so the one real violation in a hundred spurious ones gets ignored along with the noise. Alarm fatigue is a genuine safety failure mode, not just an annoyance. Together these four faults explain why 'the model passed' is a claim about the data at least as much as about the design.

Zoom

The four data faults and their signature failures. Mis-classification makes an element invisible to the rule that should test it, so it passes by omission - a silent false pass. A missing property leaves the rule with nothing to test: an honest engine says 'cannot determine', a careless one skips it and dresses a gap as a pass. A unit mismatch turns a plausible number into a wrong result - 1200 read as metres passes a 2 m minimum, or 1.2 read as millimetres fails a fine design. Wrong level of detail breaks checks at both ends: too coarse to resolve, or so noisy that a flood of false flags trains the user to ignore all of them.

Silent failure

False passes and false fails - why poor data fails silently

The defining danger of data-quality faults is that they do not announce themselves. A crashed program is obvious; a check that runs cleanly to a confident, wrong answer is not. It is worth holding the two silent failure modes side by side, because they fail in opposite directions and each is harmful in its own way.

A false pass is a green tick over a real violation. The design genuinely breaks a rule, but the data hid the breach - the element was mis-classified so the rule never tested it, or the property was missing and got skipped, or a unit slip made a bad value look compliant. This is the more dangerous of the two, because it produces exactly the outcome the whole exercise was meant to prevent - an uncaught non-compliance - while wearing the reassuring appearance of a successful check. Worse, it feeds automation bias: the greener the ticks, the more everyone trusts them, so a false pass is precisely the case where over-trust does the most harm.

A false fail is the mirror image: the design is actually fine, but bad or messy data triggers a flag anyway - a duplicated wall, a stray line read as an obstruction, a unit misread the other way. A few false fails waste time. A flood of them does something worse: it destroys the credibility of the tool. When most flags are noise, people stop reading them, and the rare true flag drowns in the false ones. So a model that produces false fails is not 'being cautious' - it is quietly disabling the check by exhausting the human who has to triage it.

The conclusion is uncomfortable but clean: a passing check is only as trustworthy as the data behind it has been made trustworthy. You cannot read a green tick as 'compliant' unless you have separately assured that the elements the rule should have tested were correctly classified, carried the right properties in the right units, at a detail the rule could resolve. This is why data validation - checking the model against quality rules before checking the design against building rules - is a real and necessary first stage, not a formality. And it is why none of this displaces the human boundary the course keeps: even a clean pass on well-validated data is not a legal approval, and whether the design truly complies stays with the qualified professional of record, the approving authority and the governing code and byelaws.

Zoom

Two silent failures, side by side. A false pass is a green tick over a real violation, hidden because the data mis-represented the design - the most dangerous outcome, because it produces the very uncaught non-compliance the check was meant to prevent, and automation bias makes over-trust worst exactly here. A false fail is good design flagged by bad data; a flood of them destroys the tool's credibility, so people stop reading flags and the rare real one is lost. Neither announces itself - the tool looks like it is working - so a passing check is trustworthy only once the data behind it has been assured, and a check is never an approval.

Level of detail

Enough, not everything - fitness for the rules you need to run

It is tempting to conclude 'more data is always better', but that is not quite right, and the nuance matters for real practice. The goal is not a maximally detailed model; it is a model fit for the rules you actually need to run. The right level of detail is defined by the questions the applicable regulations ask, not by how much modelling effort you can pour in.

Concretely, checkability is rule-relative. To run development-control checks - setbacks, ground coverage, floor-space index, height - the model needs an accurate plot boundary, a footprint, floor areas and a height, and very little else; modelling every furniture fitting adds nothing to those checks and may add noise. To run egress checks it needs corridors, doors, stairs and exits that carry the right properties and connectivity, but not necessarily fine finishes. To run accessibility checks it needs doors with clear openings, routes with gradients and turning spaces. So 'good data' is not an absolute standard; it is fitness-for-purpose, and the purpose is the specific rules in scope. A model can be richly detailed and still uncheckable for a given rule because it lacks the one property that rule reads - and can be sparse yet perfectly checkable for the rules it was prepared for.

This reframes data quality as a design decision made up front: decide which rules you want to be able to run, and provision exactly the classification and properties those rules need, at a detail that lets them resolve cleanly without generating noise. It also explains why 'level of development' or 'level of detail' agreements exist in structured-modelling practice - they are, in effect, contracts about how much and what kind of data each element must carry at each stage, so the model is fit for the checks intended at that stage.

And it names, honestly, the Indian reality one more time. Where many submissions are still 2D drawings and structured models are thin or absent, the binding constraint on automated checking is rarely the sophistication of the tool - it is whether the data reaches even a basic fitness for the quantitative development-control checks that plan-scrutiny already centres on. That is genuinely achievable data, and a sensible first target. But fitness of data never converts a check into a determination: it makes the check meaningful, while whether the design actually complies, and the authoritative reading of every rule, remain with the professional, the authority and the actual code - the National Building Code of India and the local development-control regulations - not with the model, however well made.

Verify-this: assure the data before you trust the check; a pass is never an approval

sources evolve · verify the current edition

The four checkability pillars

What makes a model checkable

Correct classification, complete properties, consistent units and a level of detail fit for the rules in scope. Weaken any one and the check degrades silently. Modules 5.1, 5.3.

Data validation before design checking

Order of operations

Check the model against data-quality rules first, then check the design against building rules. A passing design check over unvalidated data is not trustworthy. Module 5.4.

A pass reflects the data, not the law

What a green tick means

A pass means the encoded rules found no flaggable issue in the data given - it can be a false pass hiding a real violation. Never an approval; whether the design complies stays with the professional, the authority and the code and byelaws. Modules 7.3, 9.1.

Hands-on workshop

Just one element record, one rule and a notebook - no software needed. The point is to predict silent failures by hand so you never read a green tick as 'compliant'. Real validation tools come later, and binding compliance always stays with the professional, the authority and the actual code.

Workshop - inject four faults and predict how each check fails

The way to internalise silent failure is to break a good model on paper and predict the exact wrong result each break produces. In this workshop you take one small, correct element record and introduce each of the four data faults in turn, predicting whether the check gives a false pass, a false fail or an honest 'cannot determine'.

Given & goal

Goal: predict the specific failure each data fault causes
Inputs: one correct corridor record (class=Corridor, clear_width=1.8 m, occupancy=Assembly, is_egress_route=true) + a rule (assembly escape corridors >= 2.0 m) + a notebook
Time: ~45 minutes

1Baseline: run the rule in your head on the correct record. 1.8 m against a 2.0 m minimum - it should FAIL honestly, a true fail. Note that as your reference.
2Inject mis-classification: change the class from Corridor to Space. Predict what the width rule does now (it never selects the element) and what result the user sees - and label it (false pass by omission).
3Inject a missing property: delete clear_width. Predict the honest engine result (cannot determine) versus the careless one (silent skip), and say why how missing data is handled is itself a quality issue.
4Inject a unit mismatch: store 1800 with the rule assuming metres. Predict the result (1800 m passes a 2 m minimum - a gross false pass) and note how plausible the wrong number looks.
5Inject wrong level of detail: duplicate the corridor so two overlapping elements exist. Predict the effect (double flags / spurious fails) and write a short reflection on how a flood of false fails disables the check by exhausting the reviewer - framed as reasoning.

You’ll walk away with
A one-page fault table: the four injected faults, the predicted check result for each (false pass / false fail / cannot determine), why it is silent, and a reflection that data validation must precede design checking - framed as reasoning, not a compliance determination.

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

Before you trust any automated check, assure the data it ran on - because a structured model is not automatically a checkable one, and its failures are silent. The four things that decide checkability are correct classification (elements tagged as what they are, so the rule can find them), complete properties (the value each rule reads is actually present), consistent units (metres stored as metres, not millimetres read as metres), and a level of detail fit for the rules in scope. Weaken any one and you get a false pass that hides a real violation or a flood of false fails that trains your team to ignore the tool. So make data validation a deliberate first stage - check the model against quality rules before you check the design against building rules - and provision the classification and properties for exactly the rules you want to run. Read a green tick as 'no flaggable issue in this data', never as 'compliant'. Whether the design actually complies stays with you, the approving authority and the governing code and byelaws; automated checking only earns trust on data you have made trustworthy.

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

Interior checks - accessible doors, corridor and aisle widths, egress, occupant load - are only as reliable as the interior data, and interiors are where mis-classification and missing properties creep in easily. A door modelled as a plain panel with no clear_opening cannot be accessibility-checked; a circulation space mis-tagged as a room is skipped by the width rule; an occupant-load check needs each space to carry occupancy and area in consistent units. Because these faults produce silent false passes, an accessibility tick over thin interior data can hide a genuinely unusable route. So model interiors for the specific checks you need - doors that carry clear openings, routes that carry gradients and turning space, spaces that carry occupancy and area - at a detail that answers the rule without flooding it with finish-level noise. And keep the honest boundary: even a clean pass is not proof of real accessibility, which is a human judgement about whether a route works. Coordinate binding fire, egress and accessibility compliance with the qualified professionals, the authority and the governing code; your job is interior data good enough to make the checkable issues visible early.

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

The subtlest and most important idea in automated checking is that poor data fails a check silently - and understanding the four failure modes marks out a genuinely compliance-literate designer. Learn what makes a model checkable: correct classification (so a rule can find the element), complete properties (so it has a value to test), consistent units (so the value means what the rule assumes), and a level of detail fit for the rule in scope. Then learn the two silent failures they cause: a false pass, where a real violation is hidden because the data mis-represented it - the most dangerous outcome, and the one automation bias makes worse - and a false fail, where good design plus messy data floods the user with wrong flags until they stop trusting the tool. The key insight is that 'the model passed' is a claim about the DATA as much as the design, so data validation must come before design checking. And the boundary still holds: even a clean pass on good data is not a legal approval, with the professional, the authority and the actual code staying accountable. This is systems thinking that employers and studios genuinely value.

Misconception check

“If the automated check runs cleanly and comes back with a pass, the design meets that rule - after all, the computer looked at the model and found no problem. A green tick from a working tool means the model is compliant on that rule.”

This is the trap at the centre of this lesson, and it is exactly how automated checking causes harm. A check runs on the data it is given, and it cannot pass judgement on data it never received or received wrongly - so a clean pass has two very different meanings that look identical on screen. If the model is correctly classified, complete in the needed properties, consistent in units and detailed enough, the pass is real. But if the data is faulty, the same green tick can be a FALSE PASS that hides a genuine violation: an escape corridor mis-classified as a generic space is never selected by the width rule, so it is never tested and 'passes' by omission; a corridor with no clear_width property gives the rule nothing to evaluate and may be silently skipped; a width stored in millimetres but read as metres makes 1200 look like 1200 m and sail past a 2 m minimum. In every case the tool did exactly what it was told and reported no problem - because the data, not the design, hid the breach. The mirror failure is the false fail, where good design plus messy data floods the user with spurious flags until they learn to ignore all of them, real ones included. Both failures are SILENT: nothing crashes, nothing warns. That is why a passing check is only as trustworthy as the data behind it has been separately made trustworthy - data validation (checking the model against quality rules) must come before design checking (checking the design against building rules). Over-trusting the green tick is automation bias, and a false pass is precisely the case where it does the most damage. Read a pass as 'the encoded rules found no flaggable issue in this data', never as 'compliant' - and remember a check is never an approval, with whether the design truly complies staying with the qualified professional, the authority and the governing code and byelaws.

Try it

Do it yourself

No software needed - reason it through.

1Name the four things that make a model checkable, and give one example fault for each.
2Explain, with an example, how a mis-classified element produces a false pass with no warning.
3Why is a false pass more dangerous than a false fail - and how does automation bias make it worse?
4Why does a flood of false fails disable a check rather than merely annoy the user?
5What does 'data validation before design checking' mean, and why must it come first?

Take this with you

The one line to carry out

A structured model is only checkable if its data is correctly classified, complete in the properties each rule reads, consistent in units and at a level of detail fit for the rules in scope; weaken any one and the check fails silently - a false pass that hides a real violation (the most dangerous outcome, worsened by automation bias) or a flood of false fails that trains everyone to ignore the tool - so a passing check is trustworthy only after the data is, data validation must come before design checking, and even a clean pass is never an approval, with the professional, the authority and the actual code staying accountable.

Take it further

References & further reading

Peer-reviewed journals & authoritative standards

01Data quality — Wikipedia - Data quality, 2026.
02Data validation — Wikipedia - Data validation, 2026.
03Automation bias — Wikipedia - Automation bias, 2026.
04Quality assurance — Wikipedia - Quality assurance, 2026.

Recap

A structured model makes checking possible, but it does not make it reliable - a check runs on the data it is given, so whether the result is trustworthy depends on the quality of that data. Four pillars decide checkability: correct classification (elements tagged as what they are, so a rule can find them), complete properties (the value each rule reads is present), consistent units (metres stored as metres, so a plausible number is not silently misread), and a level of detail fit for the rules in scope (enough to resolve the rule, not so cluttered that it generates noise). Turn each pillar over and you get a fault - mis-classification, missing property, unit mismatch, wrong level of detail - and each breaks a check in its own way. The defining danger is that these failures are silent: nothing crashes, and the tool looks like it is working. They produce two opposite harms. A false pass is a green tick over a real violation, hidden because the data mis-represented the design - the most dangerous outcome, and the one automation bias makes worse, since greener ticks invite more trust. A false fail is good design flagged by messy data; a flood of false fails destroys the tool's credibility and trains people to ignore flags, so the rare real one drowns in noise. The conclusion is that 'the model passed' is a claim about the data at least as much as the design, so data validation - checking the model against quality rules - must come before design checking, and 'good data' is fitness-for-purpose, provisioned for the specific rules you need to run. In India, where many submissions are still 2D and structured models thin, reaching basic data fitness for the quantitative development-control checks is the sensible first target - and even a clean pass on good data is never a legal approval, with whether the design complies staying with the professional, the authority and the governing code and byelaws.

Carry forward →

Correct classification and consistent properties only work if everyone means the same thing by a corridor, a door, a fire rating. The next lesson is about the shared classification systems and standards that let rules and models speak the same language.

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 →