The Compliance Landscape

Automated compliance is a small ecosystem, and the roles are distinct even when the software makes them feel blurred. Start with the designers - architects, structural and services engineers, interior designers. They use automated checking mostly for *self-checking*: running the encoded rules against their own model to get early feedback and to catch missed clauses before they submit. This is where automation pays off first, because it shortens the loop between a design decision and knowing whether it breaks a checkable rule. But the designer's role is not only to run a tool; it is to remain the professional of record - accountable for the design, its interpretation of the code, and everything the tool could not check.

Second, the authorities and plans-examiners - municipal building departments, fire officers, and the like. They sit on the other side of the table: they scrutinise the submitted design and, crucially, they *grant the approval*. Automation can help an examiner triage submissions and re-run the mechanical checks quickly, but the decision to approve is theirs, backed by legal authority. No checking engine approves anything; a report is input to the examiner's judgement, never a substitute for it.

Third, the checking-software vendors - the firms that build the engines and, very often, do the laborious work of *encoding rules* from the codes and byelaws into logic the engine can run. Their role is powerful and quietly consequential: if their encoding is faithful and current, everyone benefits; if it is wrong, incomplete or out of date, every user inherits the error, usually without knowing. That is why the encoding is a claim about the rule, never the rule itself.

Fourth, the standards bodies - the organisations that write the actual codes (the National Building Code of India, the IS standards) and the local authorities that issue byelaws and development-control regulations, plus the bodies that define the data formats a model uses to be machine-readable (open formats such as IFC for BIM). They are the source of the authoritative rules and of the shared vocabulary that makes any of this interoperable. Four roles, one principle: the tools and vendors assist, but the design and the approval stay with accountable humans - the professional and the authority.

Underneath the players are four moving parts, and an automated check only works when all four line up. The first is the structured model. Automated checking cannot read a picture; it needs a design held as data, in which each element carries meaning and properties - a corridor that knows it is a corridor and knows its clear width, a door that knows its clear opening, a room that knows its occupancy and area. In practice this is usually a BIM model exported to an open format (IFC) so different tools can read it. Without this structured form there is nothing for a rule to run against - a plain 2D drawing or a 'dumb' geometry file is not enough.

The second piece is the encoded rules: the checkable clauses of the code expressed as logic the engine can evaluate - thresholds, conditions and comparisons against model properties. Only the quantitative, checkable subset of the code takes this form faithfully; the ambiguous and performance rules do not, and an honest rule set says so rather than pretending to cover everything.

The third piece is the checking engine - the software that brings the other two together. It reads each encoded rule, finds the relevant elements in the structured model, tests the condition on each, and records the outcome. This is the 'running' in read-and-run: a mechanical, tireless comparison of rule to model, element by element, across the whole building.

The fourth piece is the report - the output that a human actually uses. A good report does not just say 'pass' or 'fail'; it distinguishes what passed, what is flagged as failing (and where, and why), and - critically - what the engine could not determine, because a property was missing, an element was mis-classified, or the rule was outside what it can check. That third category is the honest heart of a good report: it tells you where the automation stopped and human judgement must take over. Read as a whole, the pieces form a pipeline - structured model plus encoded rules, run through the engine, producing a report - and the report is evidence for a professional and an authority to act on, never an approval in itself.

The third layer of the map is time: where the practice has come from and where it is heading. The starting point, still the default across much of the world, is manual checking - a human reads the drawings and compares them clause by clause to the code, on both the design side and the approval side. It is slow, inconsistent and error-prone, exactly as Lesson 0.1 described, but it has one great advantage: a skilled human can handle the ambiguous and interpretive rules that no machine can.

The next stage is model-based checking: encoded rules run against a structured model, so the checkable subset is handled automatically while the design is still in progress. This is where the field's real, present value lives. Designers self-check; some authorities use it to accelerate the mechanical parts of scrutiny. It does not remove the human - it removes the *drudgery* of the mechanical comparison, and frees the human to focus on judgement.

The furthest stage, still partial and emerging almost everywhere, is automated permitting: wiring model-based checks directly into the official approval workflow, so a submission is screened automatically against the quantitative byelaw parameters before (or alongside) human examination. Even at its most advanced, this automates *screening*, not *approval* - the authority remains the decision-maker, and the uncheckable rules still need people.

It is important to place this honestly, especially in India. Much of the world, India included, sits early on this path. On one hand there is real momentum: online single-window building-approval systems, common application forms, and semi-automated scrutiny of drawings against development-control parameters (setbacks, ground coverage, floor-space index, height) are spreading, tied to ease-of-doing-business and Digital India goals - and those quantitative development-control checks are precisely the checkable kind that suit automation. On the other hand, the obstacles are real: much approval remains manual and discretionary, with enormous local byelaw variation; the structured models that rich checking needs are often absent, because many submissions are still 2D drawings, not BIM; and keeping thousands of local rule sets encoded and current is a large governance task. So the trajectory is genuine but uneven - moving toward automation on the checkable parts, while the professional, the authority and the actual byelaw stay in charge.

Put the three layers together and the landscape stops being a list and becomes a system - one whose weakest link decides how well the whole thing works. The players, the pieces and the trajectory are interdependent: a brilliant checking engine is useless without a structured model to read; a faithful set of encoded rules is worthless if the standards body revises the code and no one updates the encoding; an authority cannot lean on automated screening if submissions arrive as flat 2D drawings. Automated compliance is only as strong as its weakest piece, and in most of the world today that weakest piece is the *data* - the structured model that many projects simply do not produce yet.

This systems view also tells you where the honest limits sit, so you can read any part of the landscape critically. The pieces only ever handle the checkable subset of the code; the report's most valuable line is often 'could not determine', which marks the boundary where automation stops and judgement begins. The players include vendors whose encodings can silently drift from the law, which is why the authoritative rule is always the actual code and byelaw, never the tool's version. And the trajectory, even at 'automated permitting', automates *screening* and never *approval* - the authority decides, and the uncheckable rules remain human work. None of this diminishes the field; it locates it. Used well, the landscape delivers genuine speed, consistency and early feedback on the mechanical part of compliance, and frees skilled people for the judgement only they can do.

So carry the map, not a slogan. Know who does what (designers self-check, authorities approve, vendors encode, standards bodies write the rules and formats); know the four pieces that must line up (structured model, encoded rules, checking engine, report); and know where the practice actually is (early on a real path from manual, through model-based, toward automated permitting, with data the usual bottleneck and India moving on the checkable development-control parts). And keep every binding result - whether a design complies, how a regulation should be interpreted, and legal responsibility - 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 landscape in hand, the next lesson can weigh its promise honestly against its limits.