The Rule-as-Code Idea

The core of the rule-as-code idea is a change not in what a rule says but in what form it exists in. Today, a regulation lives as prose: sentences in the National Building Code, clauses in a municipal byelaw, provisions in an accessibility standard. Those sentences are the rule, and applying them means a human reads, interprets and compares them to a design. Rules as code adds a second form of the same rule - a structured, explicit encoding that a computer can evaluate directly. The prose still exists and, crucially, remains authoritative; the code sits beside it as an executable expression of it. Where the prose is read and remembered, the code is read and run.

This second form changes what you can do with a rule. Prose must be re-read and re-applied by every professional on every project, from memory or by looking it up, which is slow and inconsistent. An executable rule can be applied by pointing it at a structured model: the machine finds the relevant elements, tests the encoded condition, and reports the result - the same way every time. One careful encoding can then be reused across thousands of projects, by designers self-checking, by tools giving early feedback, and in principle by authorities screening submissions. The rule stops being something each person must hold in their head and becomes a shared, runnable artefact.

It helps to see this as regulation gaining a computable expression, in the same spirit that a law or a tax rule might be expressed as a formula rather than only a paragraph. For the subset of building rules that are clear and quantitative - widths, distances, slopes, setbacks, counts, areas - this is genuinely powerful: those rules already behave like formulas, and giving them a second executable form lets a design be checked against them instantly and early. But notice the quiet word doing all the work: 'expression.' The code is an expression of the rule, produced by someone who had to decide what the rule means precisely enough to run. That decision is where both the power and the danger live, and the rest of this lesson follows it.

The idea of expressing rules as executable logic is broader than buildings, and it helps to know the movement it belongs to. Under names like rules as code, law as code, and computational law, governments, researchers and technologists have explored giving legislation and regulation a machine-readable, executable form - so that the same authoritative rule that people read could also drive software, be tested for contradictions, and be applied consistently. Building compliance is one domain of this larger effort; tax, benefits and regulatory reporting are others where the same instinct appears.

The stated goals are worth naming because they are genuinely attractive. First, unambiguous rules: prose tolerates vagueness, but an executable encoding forces a single, explicit meaning, which can surface hidden contradictions and gaps in the original drafting. Second, testable rules: if a rule can be run, it can be checked against examples, so you can ask 'does this design pass?' and get a definite, repeatable answer instead of a contested opinion. Third, reusable rules: encode a regulation once and every tool, designer and possibly authority can run the same logic, rather than each re-implementing their own reading. Some proponents add a fourth ambition - that rules be drafted as code and prose together from the start, so the two never drift apart.

These goals are real advantages for the right rules, and it is fair to be excited about them. But each goal carries a shadow that this course insists on naming. 'Unambiguous' means someone removed the ambiguity - by choosing an interpretation. 'Testable' means testable against the encoding, which may not match the law. 'Reusable' means one interpretation propagates everywhere, so a mistake or a slanted reading scales too. The movement's honest edge, which its best thinkers stress, is that encoding a rule is a legislative-grade act of interpretation dressed as a technical one. The goals are good; the discipline is remembering that reaching them means someone decided what the rule means, and that decision must stay visible, contestable and accountable - never hidden inside a tool that simply returns a verdict.

When a rule is clear, quantitative and checkable against model data, giving it a second executable form pays off in ways worth being concrete about. The first benefit is speed: a check that would take a human minutes per clause across hundreds of drawings runs in seconds against the whole model. The second is consistency: the encoded rule applies identically every time and to every project, removing the drift where the same clause is read differently by different people on different days. The third, and often the most valuable in design, is early feedback: because the check is cheap to run, you can run it repeatedly while the design is still fluid, catching an under-width corridor or an over-long escape route when moving a wall costs nothing, instead of discovering it at submission when it costs a redesign.

There is a fourth benefit that is easy to overlook: a single, shared expression of the rule. When a regulation is encoded once, openly and well, everyone checking against it runs the same logic - designers, reviewers, and in the best case the authority - which can reduce the arbitrariness where compliance depends on who happens to examine your drawings. In the Indian context this matters: the quantitative development-control checks that dominate plan-scrutiny (setbacks, ground coverage, floor-space index, height limits) are exactly the clear rules the idea suits, and online approval systems that screen these parameters are a real, growing example of rules-as-code in practice, with genuine potential to make approvals faster and less discretionary.

Hold all of this as the honest upside. The rule-as-code idea is not hype for the checkable subset; it delivers real speed, consistency, early feedback and shared logic, and dismissing it as impossible is as wrong as over-selling it. The discipline is scope: these benefits are real precisely where the rule is clear and quantitative and the model data is good, and they evaporate - or turn harmful - when the same confident machinery is pointed at rules that are ambiguous, performance-based or interpretive. Knowing where the benefits genuinely apply is the whole skill, and it is inseparable from the risk the next section names.

Now the risk that runs through the entire module, stated plainly. To give a rule a second, executable form, someone must decide exactly what it means - precisely enough that a machine can run it with no further judgement. That deciding is interpretation, and it happens once, up front, before anyone runs the tool. The prose rule may have been deliberately open, or genuinely contested, or simply vague at the edges; the encoder must nail it down anyway. Whatever they choose is then frozen into the code and applied literally, at scale, to every project the tool touches. The computer adds no interpretation of its own - it faithfully executes the interpretation already baked in.

This is why 'unambiguous' is a double-edged word. An encoded rule is unambiguous in operation - it always does the same thing - but that operational certainty can disguise an interpretive choice that was contestable, or even wrong. A confidently wrong encoding produces confidently wrong verdicts, and because it comes from a tool it can carry an unearned air of authority. The danger is sharpest exactly where the idea is weakest: when the confident machinery of rules-as-code is stretched over rules that are ambiguous, performance-based, or need facts outside the model, the encoding does not remove the judgement - it hides it, resolving a genuine question of interpretation silently, in code, where no one debates it.

The competent response is not to reject the idea but to hold it honestly. Treat every encoded rule as one reading of the regulation, made by a person, that can be right, out of date, or reasonably-but-differently interpreted from the authority's view. Insist that encodings be transparent and inspectable, so the interpretation is visible and contestable rather than buried. And keep the binding judgement of what a rule truly requires with the qualified professional, the approving authority and the actual code - because the authoritative rule is always the prose law, never its executable expression. The rule-as-code idea is powerful and worth using; it is also, at its core, a way of interpreting law, and it must be governed as one. Who does that interpreting is the question the next lessons turn to.