Compliance-washing: Hype vs Reality

Compliance-washing has a recognisable vocabulary, and learning to hear it is the first defence. The tell is totalising language attached to a partial capability. 'Fully automatic compliance' collapses a narrow set of encoded checks into the entire legal fact of compliance. 'Upload and get approved' fuses two completely different things - a software result and a statutory approval granted by an authority - as though the second flowed automatically from the first. 'Checks against all the regulations' implies exhaustive coverage of a vast, fragmented, frequently-updated body of rules that no product actually encodes in full. 'No more manual checking' promises the disappearance of exactly the human judgement the rest of this course shows to be irreducible. Each phrase is not quite a lie - the tool does something real - but each is engineered to make you infer far more coverage, far more authority, and far more finality than the tool possesses.

The visual grammar reinforces it. A single green tick stands in for a report that should distinguish pass, fail and 'cannot determine'. A stamped-drawing image borrows the authority of an approval the software cannot grant. Time claims ('weeks to minutes') quietly compare the tool's narrow slice against a human's whole job, as if they covered the same ground. Testimonials speak of 'peace of mind' and 'certainty' - emotional words that displace the sober truth that a check reduces some risk on some rules and touches nothing else.

Why does this language sell so well? Because the pain is real - manual checking genuinely is slow, inconsistent and error-prone, and approval queues genuinely are painful - and because compliance is frightening enough that a promise to make it simply go away is enormously attractive. Buyers want the reassurance; sellers supply it. The result is a market where the honest, bounded description of a genuinely useful tool ('encodes a defined set of quantitative rules and flags likely issues in structured model data, as an early-warning assistant') is commercially outcompeted by the dishonest, unbounded one. Recognising the vocabulary of the over-promise is what lets you value the real tool underneath it without swallowing the myth wrapped around it.

Strip away the language and look at what a compliance checker really does, and the coverage is far narrower than the marketing implies - not because the tools are bad, but because that narrow slice is the honest extent of what automated checking can do well. It evaluates a defined set of rules that someone has encoded - typically the clear, quantitative ones: minimum widths, maximum travel distances, ramp slopes, setbacks, ground coverage, floor-space index, required counts. It runs them against the specific data your model happens to carry, and only that data. It cannot touch the judgement-laden terms ('adequate', 'suitable'), the performance rules ('shall safely resist the design loads'), the facts not in the model, or the pervasive interpretive work of deciding which rule applies and how conflicts reconcile. So the real coverage of even a good tool is a subset of a subset: the encoded rules, intersected with the data present, intersected with the rules that are codeable at all.

Three gaps sit under every over-stated claim. First, the encoding gap: only rules someone bothered to encode, to a particular edition, are checked - everything else is silently absent, and 'no issues found' says nothing about rules the tool never looked at. Second, the data gap - garbage in, garbage out: if a corridor is not classified as a corridor, or carries no width, the rule cannot fire, so a clean report can mean a compliant design or a mis-modelled one, and the tool often cannot tell you which. Third, the authority gap: a software 'pass' is not a legal determination and never an approval - it means only that the encoded rules the tool could evaluate found no flaggable problem in the data it was given. The authority grants approval; the software never does.

This is the honest shape of the thing, and it is still genuinely valuable. A tool that reliably catches a handful of common, expensive, quantitative mistakes early - before submission, while the design is cheap to change - earns its place many times over. The point is not that automated checking is worthless; it is that its real worth lives inside sharp boundaries, and compliance-washing works precisely by painting over those boundaries so you cannot see where the tool's competence stops and your own irreducible responsibility begins.

The antidote to compliance-washing is not cynicism - the tools are real - but disciplined scepticism: a habit of turning a vague claim into concrete evidence by asking questions the marketing avoids. Six questions do most of the work.

First, which rules, exactly? A credible tool can name the specific provisions it encodes and the edition of the code or byelaw they come from. 'All the regulations' is not an answer; a rule list is. Second, what data must the model carry, and what happens when it is missing? A trustworthy tool tells you its data requirements and, crucially, distinguishes 'checked and passed' from 'could not check - data absent'. A tool that silently treats missing data as a pass is worse than no tool. Third, what does 'pass' actually mean here, and does the tool ever say 'cannot determine'? Honest tooling reports three outcomes, not two; a product that only shows green and red is hiding the most important category. Fourth, how are the encoded rules kept current when a byelaw changes - who updates them, how fast, and how would you know the tool is running a stale rule? Fifth, who is accountable if the tool is wrong, and does the approving authority actually accept its output, or is it purely an internal aid? Sixth, and decisively: if you cannot get clear answers to the first five, treat the claim as marketing rather than evidence, and price the tool accordingly.

Notice what these questions do. They convert an emotional promise ('certainty', 'peace of mind') into checkable facts (a rule list, a data spec, a three-state report, an update process, an accountability line). They also reset the relationship: you are not buying compliance, you are buying a bounded assistant whose boundaries you now understand. The best vendors welcome these questions because a well-built tool has good answers; the compliance-washers deflect them, because the whole strategy depends on the boundaries staying invisible. In India, add one more: does it match the specific local byelaw and development-control regulation that actually govern your plot, given how much these vary between urban local bodies - a tool tuned to one city's rules may be simply wrong for another. Ask, and let the evidence, not the adjectives, decide.

The goal of this lesson is not to make you distrust automated compliance - that would be its own error, throwing away a genuinely useful capability - but to let you hold two true things at once: the tool is real and worth using, and the claim wrapped around it is usually inflated. The competent stance sits between the vendor's hype and the sceptic's dismissal. The hype says 'automatic compliance, no more manual checking'; that is false and dangerous. The dismissal says 'regulation is too messy, automation is snake oil'; that is also false, and it wastes real speed, consistency and early feedback on the checkable rules. The disciplined position is to automate the checkable to reduce the mechanical burden and catch missed clauses early, keep the judgement firmly human, and never mistake a green tick for a legal approval.

What does an honest claim even look like, so you can recognise the rare good one? It is bounded and specific: 'this tool encodes the following quantitative development-control and life-safety rules, to this edition, and flags likely issues in a structured model; it reports pass, fail and cannot-determine; it is an early-warning aid, not an approval, and the professional and authority remain accountable.' That sentence sells less well than 'automatic compliance' - and it is the one you should want to hear, because it tells you exactly what you are getting and exactly what you still owe.

And the two non-negotiable boundaries hold no matter how polished the tool. An automated check is not a legal determination of compliance and never an approval; the authoritative rule is always the actual code, byelaw or law - the National Building Code of India, the local building byelaws and development-control regulations, the relevant IS standards - never its encoded version, which may be wrong or out of date. Whether a design actually complies, the authoritative interpretation of any regulation, and legal responsibility all stay with the qualified professional of record, the approving authority and the governing law. Read the claim critically, demand the evidence, use the tool for exactly what it is - and keep the accountability, always, with the humans the law holds responsible.