The Promise & the Limits

Start with what is actually true, because the promise is real and worth naming precisely. For the subset of rules that are clear, quantitative and checkable against model data - minimum corridor and door widths, maximum fire-exit travel distances, ramp slopes, setbacks, ground coverage, floor-space index, height limits, areas, required counts of fixtures or exits - automated checking delivers three genuine goods.

The first is speed. A check that takes a professional hours or days of careful, interruptible comparison runs in seconds against a structured model. Multiplied across a large building and a long project, that is not a marginal saving; it is the difference between checking once, late, under pressure, and checking continuously as a matter of routine.

The second is consistency. A human reading the same clause twice, or two examiners reading it side by side, can genuinely diverge - a width mis-added, a distance estimated differently, a clause recalled imperfectly. An encoded rule applied by an engine gives the *same answer every time*, on every element, without fatigue. For the mechanical comparison, that reproducibility is a real gain over human variability.

The third, and often the most valuable, is early feedback. Because the check is cheap and fast, it can run *early and often* during design, when a violation is still cheap to fix - a corridor widened on the screen, not demolished on site. Discovering a checkable failure at submission is expensive and demoralising; discovering it while the design is fluid is just part of the work. Coupled with this is self-checking: a designer can screen their own model before submission and clear the avoidable, mechanical rejections that otherwise waste weeks in the approval queue.

Notice what unites all three: they apply to the *checkable subset*, and they concern *finding likely issues*, not certifying compliance. Within that scope the value is not marginal or hypothetical - it is the field's real, present payoff, and it is why automated checking is worth learning and using. The promise, stated honestly, is powerful precisely because it is bounded: automate the mechanical, checkable comparison, and free skilled people from the drudgery of doing it by hand. The next section states, just as plainly, where that promise stops.

Now the other column, stated without softening, because the limits are where over-promising causes harm. First, ambiguity. A great deal of regulation uses open-textured, judgement-laden terms - 'adequate' ventilation, 'suitable' access, 'reasonable' provision - whose meaning is genuinely contested and context-dependent. These do not have a single testable condition; encoding them does not resolve the vagueness, it only buries a human choice inside the logic, where it looks like fact and may be wrong.

Second, performance rules. Many requirements set a goal, not a dimension - 'the structure shall safely resist the design loads', 'the means of egress shall be adequate for the occupant load' - and satisfying them needs engineering analysis and professional judgement, not a width comparison. A checking engine cannot run a structural or fire-engineering assessment; that is expert work.

Third, interpretation. Much of real compliance is deciding *which* rule applies, how a definition maps to this particular building, and how two rules in tension reconcile. This interpretive work is exactly what skilled examiners and designers do, and no current system does it reliably.

Fourth, garbage in, garbage out. The check is only ever as good as the structured model it runs on. If a room is mis-classified, a property missing, a wall the wrong type, the engine will confidently return a wrong result - and a confident green tick on bad data is more dangerous than no check at all. Related is automation bias: the human tendency to over-trust an authoritative-looking output and stop checking, which is precisely how automated checking causes harm rather than preventing it.

And fifth, the non-negotiable one: a check is not an approval. A 'pass' means only that the encoded rules the tool could evaluate found no flaggable issue in the data given - not that the design complies and never that it is approved. The encoded rule may be wrong or out of date; the uncheckable rules are untouched; the model data may be incomplete; and the authority, not the software, grants approval. The authoritative rule is always the actual code, byelaw or law - never its encoded version. These limits do not cancel the promise; they bound it, and knowing them is what separates competent use from dangerous faith.

Because the field is over-sold, you need a quick, repeatable way to test a claim - whether it comes from a vendor's brochure, a colleague's enthusiasm, or your own hope. Five questions do most of the work, and honest tools answer them plainly while over-promising ones dodge them.

One: which rules does it actually check? A credible tool is specific - it checks these quantitative, model-testable rules - and does not claim to check 'the whole code' or 'everything'. If a claim is vague about scope, assume the scope is narrow and the phrasing is marketing. The honest answer always describes a *subset*.

Two: is the encoding faithful and current? The tool runs an encoded version of the rule, not the rule; ask whether that encoding matches the current code and byelaw, and who keeps it up to date when the law changes. An encoding that drifts silently gives confidently wrong results, and 'compliance-washing' - the appearance of rigour without the substance - lives here.

Three: what model data does it rely on, and how does it fail? Every check rests on the structured model. Ask what properties it needs and - crucially - what it does when the data is missing, mis-classified or ambiguous. A trustworthy tool says 'could not determine' loudly; a dangerous one silently passes what it could not actually check.

Four: does a 'pass' claim compliance or approval - or only 'no flaggable issue in the data given'? This is the sharpest test. Any claim that a pass means the design is compliant, legal, or approved is wrong and should end your trust in the rest of the pitch. A pass is evidence of no *found* problem in a *subset*, nothing more.

Five: does it keep the professional and the authority accountable, or promise to replace them? The honest framing is augmentation - the tool assists accountable humans. Any promise to remove the plans-examiner, the professional of record, or the approval itself is the central over-promise of the field, and a reliable signal to distrust the claim. Run any pitch through these five and the honest tools separate cleanly from the over-selling ones - not because automated checking lacks value, but because its value is bounded, and the boundary is exactly what a good tool is candid about.

Hold the ledger and a single, disciplined stance falls out of it: automate the checkable, keep the judgement human, and never mistake a green tick for an approval. This is neither the vendor's position ('automatic compliance, no more manual checking') nor the sceptic's ('regulation is too messy, ignore the tools'). It is the practitioner's: use automated checking exactly where it is strong - the clear, quantitative, model-testable rules - to gain real speed, consistency and early feedback and to clear avoidable rejections; and refuse to let it near the work it cannot do - resolving ambiguity, running performance analysis, deciding which rule applies, or issuing an approval. The most valuable output of a good check is often the honest 'could not determine', because it points you precisely at where your judgement, and the authority's, must take over.

This matters especially on Indian ground, where both the promise and the limits are sharp. The promise is real and immediate: the quantitative development-control rules that dominate plan-scrutiny - setbacks, ground coverage, floor-space index, height, plot rules - are exactly the checkable kind, and online single-window and semi-automated scrutiny systems are advancing on them, with genuine potential to make approvals faster, more consistent and less arbitrary. The limits are equally sharp: much approval remains manual and discretionary with enormous local byelaw variation; the structured models richer checking needs are often absent because many submissions are still 2D; encoded byelaws across thousands of local bodies are hard to keep current; and the judgement-laden parts of compliance resist coding here as everywhere. So the honest Indian reading matches the general one: automated compliance is most immediately real for the quantitative development-control checks, is being actively advanced, and augments - never replaces - professional judgement and the approving authority.

Carry the ledger out of Module 0. The promise is genuine and bounded; the limits are real and non-negotiable; and every binding result - whether a design actually complies, the authoritative interpretation of any regulation, and legal responsibility - stays with the qualified professional of record, the approving authority, and the governing law (the National Building Code of India, the applicable local byelaws and development-control regulations, and the relevant IS standards). With the compliance problem understood - the rulebook, the read-and-run idea, the landscape, and now the promise weighed honestly against the limits - the course turns next to making the case for automation in detail: the real cost of manual checking, and where speed and early feedback truly pay.