Lesson 0.2Lesson 0.2 · The Compliance Problem
What Rules as Code Means
Rules-as-code does not rewrite the law - it gives a regulation a second, machine-readable form so a computer can evaluate the checkable part, while the authoritative rule stays the words in the actual code and the judgement stays human
A regulation is words on a page that a person reads. What if the same rule also existed as logic a computer could run - with the words on the page unchanged?
In the first lesson we watched compliance shift from read-and-remember to read-and-run: a rule stops being something a human carries in their head and becomes something a computer can evaluate against a structured model. That is the picture. This lesson slows down and defines, precisely and honestly, what rules-as-code actually means - because the phrase is used loosely, and the loose version ('the law becomes software') is wrong in a way that matters.
The key insight is small and clarifying: rules-as-code gives a rule a second FORM, not a new meaning. The regulation still exists as prose written for people - that prose is still the law. Rules-as-code adds, alongside it, a machine-readable expression of the same requirement: structured logic a computer can run. One rule, two forms. Getting this straight tells you exactly what the approach can do (make the checkable part runnable) and what it cannot do (change the law, resolve ambiguity, or grant an approval).
One rule -> TWO forms: prose (for humans, the law) + logic (for machines, runnable). Changes what you can DO with it, not what it MEANS. Encoding an ambiguous rule just hides a human choice inside the code.
A second form of the same rule
A regulation, at bottom, is language. Today a building rule exists in exactly one form: prose written for humans - 'the clear width of a corridor in an assembly building shall not be less than 2.0 metres', 'the travel distance to the nearest exit shall not exceed 30 metres'. A qualified person reads that sentence, understands what it demands, and applies it by hand to a drawing. That single prose form is all a rule has ever had.
Rules-as-code adds a second form of the very same requirement: a structured, executable encoding - logic a machine can evaluate. This is not a translation into another human language and it is not a plain-English paraphrase. It is a re-expression of the checkable content into variables, conditions and thresholds that a computer can run: 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'. The prose stays exactly where it was; the logic is placed beside it. When people say machine-readable regulation, this second form is what they mean - the same rule, now runnable.
Why does a second form matter so much? Because form determines what you can do with a rule. A prose rule can only be read and applied by a human. An encoded rule can be pointed at a structured digital model and evaluated automatically, on every relevant element, in seconds. Nothing about the requirement changed - a corridor still has to be 2.0 m - but the rule can now be *run* rather than only *remembered*.
Two cautions belong here from the start. First, only the checkable content of a rule re-expresses cleanly: a numeric threshold against a measurable property. The ambiguous, contextual or performance parts of regulation resist a faithful second form, which is why not all of a code can be coded - the theme of this whole course. Second, the two forms are only useful if they genuinely say the same thing; if the encoding drifts from the prose, the encoding is simply wrong. So the honest way to picture rules-as-code is modest and precise: one requirement, expressed twice - once for people to read, once for machines to run - with the human prose remaining the thing that actually governs.
What the second form changes - and what it does not
It is easy to over-read what a machine-readable form buys you, so name both sides squarely. What the second form genuinely changes is executability and everything that flows from it. A rule that could only be read can now be run: checks that took a professional hours happen in seconds; they run the *same way every time*, so two people (or two examiners) no longer quietly disagree on a width; and they can run *early and often* during design, when a violation is still cheap to fix, instead of surfacing at submission. It scales - the same encoded rule sweeps every corridor, door and room in a large model without tiring. This is the real, useful shift: from read-and-remember to read-and-run.
What the second form does not change is just as important, and more often forgotten. It does not change the meaning or scope of the regulation - a well-made encoding is neither stricter nor looser than the clause it expresses. It does not change the authoritative text: the words in the code and the byelaw remain the law, and the encoding has no legal authority of its own. If the encoded logic and the actual clause ever disagree, the clause wins and the encoding is defective - never the other way round. It does not change who decides: interpretation stays with the professional and the authority, and approval stays with the authority. And, crucially, it does not resolve ambiguity. If the prose is genuinely vague ('adequate ventilation'), the encoding cannot make the vagueness disappear; it can only make a *choice* about what the vague term means - and that choice is itself an interpretation, which may be contested or wrong. Encoding a fuzzy rule does not sharpen the law; it hides a human judgement inside the code where it is harder to see.
There is also a quiet failure mode: drift. Codes and byelaws are revised on their own schedules; an encoded rule can silently fall out of date, so that a green result reflects last year's rule. All of this points to one discipline: treat the second form as a powerful convenience and a tool, and treat the actual law as the source of truth - always.
Rules as code is a movement - law and regulation made runnable
Rules-as-code is bigger than building codes; it is a broad movement, running across government and law, to give legislation and regulation a machine-consumable form. The same idea appears in tax rules, social-benefit eligibility, licensing and permits, and planning and zoning: wherever a public rule is applied at scale, there is pressure to express its logic so software can apply it consistently, power digital services, and even be tested for contradictions before it is enacted. The related academic and industry fields carry names worth knowing - computational law (representing legal rules so machines can reason over them), legal informatics, and regulatory technology (regtech), which applies this thinking to compliance itself.
Within the movement there is a genuine debate about *how far* to take it. A cautious version keeps code strictly downstream: humans write the law in prose, and separate people later encode the checkable parts, with the prose always authoritative. A more ambitious version argues for co-drafting - authoring the human rule and its logical expression together, so the two are consistent by construction and the law is 'digital-ready' from the start. Each has trade-offs, and each runs into the same wall: a great deal of law is deliberately open-textured, written to be interpreted case by case, and forcing it into rigid logic can distort or ossify it. That tension is not a bug to be engineered away; it is a feature of how law does its work.
Applied to building codes, the domain is unusually favourable *and* unusually hard at the same time. Favourable, because so much of building regulation is already numeric and geometric - the development-control rules (setbacks, ground coverage, floor-space index, height limits) and the dimensional minimums (widths, distances, slopes) are precisely the quantitative content that takes a faithful second form. Hard, because the performance and judgement-laden parts resist coding as stubbornly here as anywhere. India shows the movement concretely: online single-window building-approval and common-application systems, and semi-automated scrutiny of drawings against byelaw parameters, are rules-as-code applied to development control - real momentum, on exactly the checkable rules that suit it, while the authoritative byelaw and the accountable authority remain in charge.
From remembering to running - what it means in practice, and its edge
Bring it down to the desk. In practice, rules-as-code means that instead of carrying regulations in your head and comparing them by hand to a drawing, you - or the approving authority - point a checking engine at a structured model and read a report. The encoded rules run against the model; the report says what passed, what is flagged, and what the tool could not determine. Because the check is cheap and fast, you can run it *early and often*, catching an under-width doorway or an over-long escape route while the design is still fluid, and self-checking before submission to reduce avoidable rejections. That is the everyday meaning of 'read-and-run': the mechanical comparison becomes a button, not a week.
But the edge of the idea has to be held as firmly as the idea itself, because this is exactly where over-promising begins. First, only the codeable subset takes a faithful second form; the ambiguous, performance-based and interpretive rules do not run, and pretending they do is where harm starts. Second, the encoding is a *claim about* the rule, not the rule - it can be wrong, incomplete or out of date, and the authoritative rule is always the actual code, byelaw or law. Third, a run is not a verdict: a pass is not a legal determination of compliance and never an approval - it means only that the encoded rules the tool could evaluate found no flaggable issue in the data given. Fourth, garbage in, garbage out: the whole check rests on the quality of the structured model, so a confident green result on bad data is worse than no check at all.
So the real skill that this definition unlocks is discriminating: knowing which rules genuinely have a faithful machine-readable form and which are being force-fit into one; reading a report as evidence to act on, not as a certificate; and keeping every binding result - whether a design actually 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). We have defined *what* rules-as-code means; next we map the landscape it lives in, then weigh its promise honestly against its limits.
One rule, two forms
What rules-as-code actually adds
A machine-readable logical expression of a rule's checkable content, placed beside the human prose - not a rewriting of the law. Only the quantitative, checkable content re-expresses faithfully. Modules 3.1, 3.3.
The authoritative rule is the law
Encoding versus the actual regulation
The binding rule is always the actual code, byelaw or law - the NBC India, local byelaws/DCR, IS standards - never its encoded version, which has no authority of its own and may be wrong or out of date. Modules 3.4, 8.2.
Encoding does not resolve ambiguity
Open-textured rules
Encoding a vague clause hides a human interpretation inside the logic; it does not sharpen the law. Ambiguous, performance and interpretive rules resist a faithful second form. Modules 2.4, 9.2.
A run is not an approval
What a 'pass' on the second form means
Only that the encoded rules the tool could evaluate found no flaggable issue in the data given - not compliance and never an approval. The authority approves, not the software. Modules 7.3, 9.1.
Workshop — give a rule its second form, and name what is lost
The fastest way to understand rules-as-code is to make a second form yourself and watch where it holds and where it breaks. In this workshop you will take two real rules - one clean and quantitative, one open-textured - and try to give each a machine-readable expression, then write down honestly what the encoding preserves and what it distorts.
Just two real rules and a notebook - no software. This workshop is about seeing what a second form captures and what it cannot, by hand; the engines and tools come later, and binding compliance and interpretation always stay with the professional, the authority and the actual code.
Goal: feel what a machine-readable form of a rule captures and what it cannot Inputs: two real rules (one dimensional, one judgement-laden) + a notebook Time: ~40 minutes
- 1Pick two rules from a source you can access: one clearly quantitative (a corridor or door width, a travel distance, a ramp slope, a setback) and one open-textured (an 'adequate ventilation' or 'suitable access' clause, or a performance requirement).
- 2Encode the quantitative one in plain machine logic: write it as 'for every <element>: check <property> <comparison> <threshold>; else flag', and list the model data it needs (the element must know what it is and carry the property).
- 3Try to encode the open-textured one the same way, and stop when you hit the wall: write down the choice you were forced to make to turn the vague term into a testable condition, and who should really be making that choice.
- 4For each rule, write two lines: what the encoding PRESERVES faithfully, and what it LOSES or DISTORTS - and note that for the quantitative rule the prose and logic say the same thing, while for the open-textured one the logic quietly adds an interpretation.
- 5Write a short reflection: state in your own words that the encoding is a second form of the rule (not a new law), that the authoritative rule stays the actual clause, and that a pass on the logic would not be an approval - flagged as reasoning.
You’ll walk away with
A one-page exercise: two rules, one cleanly encoded with its data needs, one shown breaking against an open-textured term with the hidden interpretation named, plus a two-line preserve/lose note for each and a short reflection that the law stays authoritative and a run is not an approval. Keep it; the encoding modules build real method on this feel.
Three altitudes on the same idea
Read the band that fits you — or all three.
For you, rules-as-code means a subset of the code you already work to gains a second, runnable form - and that is genuinely useful, provided you never confuse the encoding with the law. The quantitative rules that dominate development control and life safety (setbacks, coverage, FSI, height, corridor and door widths, travel distances, ramp slopes) are exactly the ones that take a faithful machine-readable form, so a structured model lets you run them for fast, consistent, early feedback and self-check before submission. But the encoded rule is only a claim about the byelaw or the National Building Code; it can be wrong or out of date, it cannot resolve a vague clause, and a pass is not an approval. Treat the second form as an instrument on your workbench, read its report as evidence, and keep the authoritative rule as the actual code - while you and the approving authority remain accountable for whether the design truly complies, and how any regulation should be interpreted.
In interiors, the rules that most affect your work - accessible route and door clear widths, wheelchair turning space, ramp slopes, corridor and aisle widths, exit counts and travel distances, washroom accessibility provisions - are precisely the checkable ones that get a clean second form. So rules-as-code means those quantitative requirements can be run against a structured model and flagged early, before an under-width doorway or an over-long escape route becomes an expensive rebuild. But much of what makes an interior genuinely accessible and safe is judgement that resists coding: is the route actually usable, is the wayfinding legible, does the space work for a real person? A machine-readable width check cannot answer those, and an automated pass is not an approval or a guarantee of real accessibility. Use the second form to catch the measurable issues early, and coordinate binding fire, egress and accessibility compliance with the qualified professionals, the authority and the governing code - the actual rule, never its encoding, is what governs.
The cleanest mental model to carry from this lesson is one rule, two forms: the human prose that is the law, and a machine-readable logical expression of its checkable content placed beside it - not a rewriting of the law into software. Understand that this is one instance of a broad movement (computational law, legal informatics, regtech) to make legislation and regulation runnable, and that a real debate exists over whether code should be strictly downstream of the prose or co-drafted with it. Understand, too, why so much law resists a faithful second form: it is deliberately open-textured, written to be interpreted, and forcing it into rigid logic distorts it. Building codes are a favourable case for the quantitative parts (numeric, geometric development-control and dimensional rules) and a hard case for the performance and judgement parts. You are not expected to build encoders; you are expected to know exactly what 'machine-readable regulation' does and does not mean, and why the authoritative rule always stays the actual law.
“Rules as code means the law is being rewritten as software - so the code becomes the rule, and if your model passes the software, you have satisfied the regulation.”
Do it yourself
No software needed — reason it through.
- 1In one sentence, what does rules-as-code add to a regulation - and what does it leave unchanged?
- 2Explain 'one rule, two forms' with an example, and say which form is authoritative.
- 3Name two things a machine-readable form changes and two things it does not.
- 4Why does encoding an ambiguous clause not resolve its ambiguity - where does the judgement go?
- 5Rules-as-code is a broad movement: name one other domain it appears in, and say why building codes are a favourable case for the quantitative parts.
The one line to carry out
Peer-reviewed journals & authoritative standards
- 01Rules as code — Wikipedia — Rules as code, 2026.
- 02Computational law — Wikipedia — Computational law, 2026.
- 03Formal specification — Wikipedia — Formal specification, 2026.
- 04Statutory interpretation — Wikipedia — Statutory interpretation, 2026.
- 05Building code — Wikipedia — Building code, 2026.
Now that we know precisely what rules-as-code means, we can see the whole field it sits in - who the players are, what pieces make an automated check work, and where the practice is heading. Next: the compliance landscape.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →