Garbage In, Garbage Out

State the claim as bluntly as possible: automated checking cannot be more correct than its input. The checker is a faithful machine. Given a model, it selects elements by class, reads properties, applies the encoded rules, and reports pass, fail or cannot-determine. Nowhere in that loop does it consult the real building, the designer's intent, or the actual code text; it consults only the data in the model. So the quality of its verdict is bounded, above, by the quality of that data. A brilliant checking engine over a mis-classified, incomplete model produces confident nonsense; a modest engine over a clean, complete model produces something you can act on. The engine is not where correctness comes from - the data is.

This reframes what an automated check actually certifies. When a tool passes a corridor-width rule, it is really asserting something narrow: 'among the elements I was able to identify as corridors, each carried a clear_width value that I read, in the unit I assumed, and none was below the minimum I was given.' Every clause of that sentence is a claim about the data. If an escape corridor was not identifiable as a corridor, it was not among the elements checked; if a width was missing, it was not read; if the unit was wrong, the comparison was wrong. The pass is true of the data and can be entirely false of the building. The check never had access to the building - only to a data-model of it, which may or may not faithfully represent reality.

The same holds in the failing direction. A flood of fails may say nothing about the design and everything about duplicated geometry or mis-tagged elements. In both directions the verdict is a statement about the model's data first, and about the building only to the extent the data is true. This is not a limitation to be engineered away; it is the nature of computing over a representation. You cannot check the world; you can only check a model of the world, and the check inherits every error in that model. That is the honest core of this module, and everything practical - validation, standards, ownership - follows from taking it seriously rather than wishing it away.

The specific danger of garbage-in is not error but confidence. A crashed tool warns you; a tool that computes cleanly over bad data does not. It returns a result that has exactly the same appearance as a correct one - the same green tick, the same tidy report - because from the tool's point of view nothing went wrong: it applied the rules to the data and found what it found. The wrongness lives entirely in the gap between the data and the building, a gap the tool cannot see. So bad data does not look like bad data on screen. It looks like a clean pass.

This is where the theme of automation bias becomes acute. Humans systematically over-trust confident automated output, and the more authoritative and clean the presentation, the stronger the pull. A crisp report with a row of green ticks radiates competence, and the natural response is to relax - to assume the tool has handled it. But that reflex is exactly inverted from what safety requires, because the confident, clean pass is precisely the output a garbage-in error produces. The cases where the data is worst and the risk highest can be the ones where the tool looks most reassuring, since a mis-classified element simply drops out of the check silently rather than announcing itself. Over-trust is therefore not a minor human factor bolted onto a technical system; it is the mechanism by which garbage-in actually causes harm. The false pass only hurts someone if it is believed.

The honest consequence is a specific stance toward the green tick. A pass must be read as a conditional, data-dependent statement - 'no flaggable issue was found in the data I was given, for the rules I could evaluate' - and never as a verdict on the building. That means treating 'cannot determine' results as seriously as fails, asking what the tool actually tested (its coverage) rather than only whether it passed, and reserving trust for results whose underlying data has been separately assured. It also means resisting the emotional pull of a clean report, which is a learned discipline, not a natural instinct. None of this makes automated checking useless - used with this discipline it genuinely catches real issues fast. It makes automated checking safe to use, by refusing to let a confident output substitute for confidence in the data behind it. And it keeps the boundary firm: a check, however clean, is never an approval, and whether the design truly complies stays with the accountable humans.

If a check cannot rise above its data, then data quality is not one task among many in an automated-checking workflow - it is the foundation the whole workflow stands on. Picture the stack: results at the top, the checking engine and encoded rules beneath, the classification and property standards beneath that, and at the very base the quality of the model data. Weaken the base and everything above it is unreliable, no matter how good it is - a sound engine and sound rules over unsound data produce unsound results. This is why the earlier lessons insist that data validation must come before design checking: you assure the foundation before you build the verdict on it.

Calling data quality a precondition has a sharp practical meaning: it must be planned for and resourced up front, not discovered as a problem at the end. In practice this is exactly backwards from how it is often treated. Because modelling for compliance is unglamorous - classifying elements correctly, populating the right properties in the right units, keeping to agreed standards - it is easy to defer, skimp, or assume it will 'sort itself out', and then to run a checker over whatever model exists and trust the ticks. That is the failure mode this whole module is written against. The correct order is to decide which rules you need to run, provision the data those rules require to a fitness that lets them resolve cleanly, validate that the data actually meets that bar, and only then read the design check as meaningful.

There is also a design-judgement point here that goes beyond process. Because good data is fit-for-the-rules rather than maximal, deciding what data quality the project needs is itself a professional judgement: which checks matter, what classification and properties they require, what level of detail is enough. That judgement cannot be automated - it is part of the human work that frames the automated part. So data quality is not merely a chore that precedes the clever bit; it is a considered decision about what the model must be able to answer, made by people who understand both the rules and the design.

And the Indian reality makes the point concrete rather than abstract. Where many submissions are still 2D and structured models thin, the binding constraint on useful automated checking is almost always the data, not the tool - which is precisely why treating data quality as a precondition, and reaching a basic, achievable fitness for the quantitative development-control checks, is the realistic first step. Skip it, and a checker over poor data does not give you cheap compliance; it gives you expensive false confidence.

A precondition that no one owns is a precondition that fails. The final and most important move in this module is to insist that data quality is not an ambient property that arises on its own - it is a responsibility that must be assigned to accountable people, and named as such. If everyone assumes someone else is ensuring the corridors are classified and the widths populated in the right units, no one is, and the checker will faithfully compute over the gaps. So the honest question about any automated-checking workflow is not only 'is the data good?' but 'who is answerable for it being good?'.

This matters because responsibility for the data sits inside the larger accountability the whole course insists on. Automated checking augments, never replaces, the accountable humans: the qualified professional of record, the approving authority and the governing law. Data quality is where that accountability becomes concrete and daily. The professionals who author and coordinate the model are responsible for the data being fit for the checks run on it; reading a green tick without having assured the data behind it is not diligence, it is abdication dressed as technology. The tool cannot be blamed for a false pass produced by data someone was supposed to own and did not - the tool did exactly what it was told. Responsibility does not transfer to the software; it stays with the people, precisely because the software is only a faithful function of the data they provide.

This also clarifies the relationship between data quality and the boundaries repeated throughout the course. A check is never an approval - and one reason is that a pass is only a statement about data that accountable humans, not the tool, are responsible for. The authoritative rule is always the actual code and byelaw, never the encoded version - and even a rule correctly encoded is only as good as the data it runs against, which again is a human responsibility. So the module's honest through-line closes here: automated checking is genuinely useful for the checkable subset, but only over data that is correct, complete, consistent and fit for purpose, and that data does not maintain itself - someone must own it. Whether the design actually complies, the authoritative interpretation of every regulation, and legal responsibility for both remain with the qualified professional of record, the approving authority and the governing law - the National Building Code of India, the applicable local development-control regulations and the relevant IS standards - and the quiet, unglamorous discipline of owning the data is where that accountability is either honoured or quietly betrayed.