From Reading the Rulebook to Running It

To see why rules-as-code matters, name the problem it addresses. Building regulation is one of the largest, most fragmented bodies of rules a professional must navigate. A single project may be governed by the National Building Code of India (a vast document covering structure, fire, services, accessibility and more), the state and municipal building byelaws, the local development-control or development-plan regulations (setbacks, ground coverage, floor-space index, height limits), fire-service requirements, accessibility standards, environmental clearances, and various IS standards - each written separately, updated on its own schedule, and sometimes in tension with the others. No human holds all of it perfectly in mind.

And the way this mountain is checked is almost entirely manual. During design, the architect and consultants check their own work against the rules they can remember or look up - a laborious, interrupted process that competes with actually designing. At submission, a plans-examiner at the municipal authority or a fire officer reads the drawings and mentally re-runs the same checks from the outside, deciding whether to approve. Both sides are doing the same fundamentally human task: reading regulation, interpreting it, and comparing it clause by clause against a design. This manual process has three chronic weaknesses. It is slow - self-checking eats designer time, and approval queues can stretch for weeks or months, delaying projects and inflating cost. It is inconsistent - the same rule genuinely gets read differently by different professionals and different examiners, so compliance can feel arbitrary and outcomes depend on who checks. And it is error-prone - in a set of hundreds of drawings and thousands of clauses, a human inevitably misses things: an under-width corridor, an over-long travel distance to a fire exit, a ramp too steep for a wheelchair, a setback encroached by half a metre. Some of these are caught late at great expense; some are not caught at all and become safety risks. This slow, inconsistent, error-prone manual checking of a vast rulebook is exactly the problem automated compliance sets out to ease - not by removing the human, but by letting a computer handle the parts that are genuinely mechanical.

The core move of rules-as-code is to change what form a regulation exists in. Today a rule lives as prose written for humans: 'the minimum clear width of a corridor in an assembly building shall be 2.0 metres' or 'the travel distance to the nearest exit shall not exceed 30 metres'. A human reads that sentence, understands it, and applies it by hand. Rules-as-code adds a second form of the same rule: logic written for machines - a structured, unambiguous encoding that a computer can evaluate, such as (in effect) 'for every corridor in an assembly occupancy, check that clear_width is greater than or equal to 2.0 m; if not, flag it'. Now the rule can be *run*: point the computer at a structured digital model of the building, and it applies the encoded rule to every relevant element automatically.

This pairs with the other half of the field, automated code checking: the design must exist not only as drawings but as a structured, machine-readable model (typically a BIM model) in which a corridor knows it is a corridor and knows its width, a door knows its clear opening, a room knows its occupancy and area. When you have encoded rules on one side and a structured model on the other, a checking engine can compare them - reading each rule, finding the relevant elements in the model, testing the condition, and producing a report of what passes, what fails, and what it could not determine. The promise is compelling: checks that took a human hours or days run in seconds; they run the *same way every time* (consistency); and, crucially, they can run *early and often* during design, so a designer gets feedback while the design is still cheap to change, instead of discovering a violation at submission. This is the genuine, real core of automated compliance - and it already works well for the subset of rules that are clear, quantitative and checkable against model data. The rest of this course is about that subset, its boundaries, and the large, important territory of rules that lie beyond it.

No field in this area is more over-promised than 'automatic compliance', and an honest course draws the boundary sharply on page one. The genuine value is real: for clear, quantitative, checkable rules - minimum widths, maximum travel distances, ramp slopes, setback distances, area and coverage calculations, required counts of fixtures or exits - encoding and automatic checking work well and deliver real speed, consistency and early feedback. But a great deal of regulation is not like that, and cannot be reduced to code without loss. Many rules are ambiguous or use judgement-laden terms ('adequate' ventilation, 'suitable' access, 'reasonable' provision) whose meaning is genuinely contested and context-dependent. Many are performance-based ('the structure shall safely resist the design loads') and require engineering analysis and professional judgement, not a width check. Many require information not in the model or facts about the world (soil, neighbours, use in practice). Many involve interpretation - deciding which rule even applies, or how two conflicting rules reconcile - which is exactly the expert work a plans-examiner and a designer do, and which no current system does reliably. So a large, important part of compliance is inherently human, and pretending otherwise is dangerous.

And there is a second, non-negotiable boundary: an automated check is not a legal determination of compliance, and never an approval. When a checking tool reports 'pass', it means the encoded rules it could evaluate did not find a flaggable problem in the data it was given - not that the building is legal. The encoded rule may be wrong or out of date; the model data may be incomplete or mis-classified; the uncheckable rules are untouched; and the authority, not the software, grants approval. So the automated check is best understood as a powerful assistant that finds likely issues fast and early, radically reducing the mechanical burden and the rate of missed clauses - while the qualified professional of record and the approving authority remain fully accountable for whether the design actually complies. The competent stance is neither the vendor's ('automatic compliance, no more manual checking') nor the sceptic's ('regulation is too messy, ignore it'), but the disciplined one: automate the checkable, keep the judgement human, and never mistake a green tick for a legal approval.

This course builds automated-compliance literacy as a practical, honest design skill. You will start with the compliance problem - from reading the rulebook to running it, what rules-as-code means, the landscape, the limits (Module 0); then why automate compliance - the cost of manual checking, consistency and error, speed and early feedback, the caveats (Module 1); understanding building regulations - what codes are, how rules are written, prescriptive versus performance, the ambiguity problem (Module 2); rules as code - encoding a rule, the rule-as-code idea, machine-readable regulation, who writes the code (Module 3); automated code checking - model-based checking, how checking works, what can and cannot be checked, the tools (Module 4); the data it needs - the model as data, data quality and checkability, classification and standards, garbage in garbage out (Module 5); across compliance domains - accessibility, fire and life safety, zoning and planning, energy and sustainability (Module 6); in the real workflow - where it fits in design, self-checking before submission, the approval process, automated permitting (Module 7); building and governing the rules - translating law to logic, keeping rules current, who is accountable, open versus proprietary rules (Module 8); reality, limits and honesty - compliance-washing, the interpretation gap, when judgement is required, automation bias (Module 9); and practice and the future - the designer's role, getting started, India, becoming compliance-literate (Module 10).

One firm boundary runs through all of it. Automated compliance checking is a tool to help find likely issues and give early feedback - it is emphatically not a legal determination of compliance and not an approval. This course teaches the principles and design judgement, and defers every binding result - whether a design actually complies, the authoritative interpretation of any regulation, and legal responsibility for compliance - to the qualified professional of record, the approving authority, and the governing law itself (the National Building Code of India, the applicable local building byelaws and development-control regulations, and the relevant IS standards). The authoritative rule is always the actual code, byelaw or law, never its encoded version; any tool or rule named here is illustrative and fast-moving. Studio Matrx is free and not-for-profit, and this course is written to be rigorous and honest - not a compliance-automation sales pitch but a clear, critical grounding in rules-as-code, mindful of the Indian context where approvals are often manual and discretionary, where online single-window and common-application systems are emerging, and where the National Building Code and local byelaws govern. Understand the compliance problem, the read-and-run idea, the sharp line between the checkable and the judgement-laden, and above all that automation augments and never replaces the accountable professional and authority - and you will be able to use automated compliance where it genuinely helps and respect its limits everywhere else.