Who Writes the Code

Start by naming who could actually encode a rule, because each candidate changes what the encoding is and how far you can trust it. The first is the regulator - the authority that wrote the rule in the first place: a standards body, a municipal corporation, a national code committee. When the author of the rule also encodes it, the encoding can carry official standing and is, in principle, closest to the rule's intent. The catch is capacity: regulators, especially thousands of local bodies, rarely have the technical resources to produce and maintain high-quality machine-readable rules, so official encodings are the exception, not the norm.

The second is a software vendor - a company that builds and sells a compliance-checking tool. Vendors have the capacity regulators often lack, and much real automated checking today runs on vendor-encoded rules. But a vendor's encoding is shaped by the vendor's incentives and is frequently proprietary, meaning you cannot see how a rule was interpreted - only the verdict it returns. That opacity is the core risk of vendor encoding: you are trusting a private reading of the law you are not allowed to inspect.

The third is an open or community effort - encodings produced by a shared, often public, group of contributors, visible and correctable by anyone. The great strength here is transparency: an open encoding can be inspected, challenged, tested and fixed, so its interpretive choices are out where they can be argued with rather than hidden. The weakness is governance - who decides what the community's encoding says, how disputes are resolved, how quality and currency are maintained - and the fact that being open does not make an encoding authoritative or correct, only visible. In practice, real systems mix these: a vendor tool implementing a regulator's parameters, an open library a community maintains, an approval portal encoded by or for the authority. The point of naming them is not to crown a winner but to see that whoever holds the pen shapes the interpretation - and that you should always ask who did.

It is tempting to treat 'who encodes it' as a procurement footnote - surely a rule is a rule, whoever types it up. But because encoding is interpretation, the identity of the encoder is inseparable from the meaning of the encoded rule, in at least three ways. First, the encoder makes the interpretive choices we saw in earlier lessons - what 'clear width' is measured clear of, which spaces count, how an ambiguous term is resolved - and those choices become the rule everyone runs. Two different encoders can produce two defensibly different encodings of the same clause, and whichever one is in the tool you use is the one that governs your design. The encoder is, in effect, quietly interpreting the law on everyone's behalf.

Second, the encoder's position and incentives shape those choices. A regulator encoding its own rule is trying to express its intent. A vendor is also trying to build a sellable, defensible product, and may resolve ambiguities conservatively, or in ways that suit its tooling, or simply in whatever way was easiest to implement. None of this need be malicious to matter: incentives shape interpretation even in good faith, and when the interpretation is hidden inside a product, its slant is invisible to the people relying on it. Third, the encoder holds power over currency: whoever maintains the encoding decides when it is updated to match a changed byelaw, and a lag there silently governs designs by an outdated reading.

This is why the encoder's identity is a first-order question, not a detail. In effect, whoever writes the code exercises a slice of interpretive authority over the rule - authority that properly belongs to the law and those charged with applying it. Recognising that reframes how you should treat any checking tool: not as an oracle that tells you the rule, but as one party's interpretation of the rule, whose author, incentives and transparency you are entitled to ask about. The competent question is never just 'what did the check say?' but 'whose encoding said it, can I see how, and how current is it?'

The sharpest danger in rules as code is not a rule that is obviously broken - that gets noticed - but an encoding that is hidden, wrong, or quietly outdated, and still returns a clean, confident verdict. Consider a hidden encoding: a proprietary tool that reports 'pass' or 'fail' without showing how it read the rule. You cannot tell whether it measured width the way your authority does, whether it scoped the rule correctly, or whether it even covers the clause you care about. You are asked to trust a verdict whose reasoning is sealed - and because it looks authoritative, the temptation to trust it (automation bias) is strong. A hidden encoding does not remove the interpretive risk; it removes your ability to see it.

Consider a wrong encoding: an honest mistake - a misread threshold, a mis-scoped rule, a measurement convention that differs from the authority's. Because encoded rules are reused at scale, one wrong rule silently misleads every design that runs against it, passing things that should fail or failing things that should pass, all with the same tidy confidence. And consider an outdated encoding: correct when written, but not updated when the byelaw changed, so it now enforces a rule that no longer applies. In each case the failure is invisible at the point of use, because the tool still produces a clean result. That invisibility is what makes these encodings dangerous - the harm is not a visible error but a confident, wrong answer trusted as if it were the law.

These risks do not argue against rules as code; they argue for the disciplines the whole module has been building toward. Prefer transparent, inspectable encodings over opaque ones, so interpretive choices and errors can be seen and challenged. Insist on versioning and currency, so you know which edition an encoding implements and whether it is live. Keep a human reading of the actual rule in the loop, so a wrong or stale encoding can be caught rather than trusted. And never let the existence of a verdict substitute for the judgement of whether the design truly complies. The green tick is only ever as trustworthy as the encoding behind it - and if you cannot see the encoding, you cannot know how far to trust the tick.

All of this resolves into one boundary that never moves, and it is the anchor of the entire module. Whoever writes the code - regulator, vendor, or community - the encoded rule is never the authority. The authoritative, binding rule is always the actual law: the National Building Code, the applicable local byelaw and development-control regulation, the relevant IS standard, as they currently stand and as the approving authority applies them. The encoding is one reading of that law, made by some person or organisation, that can be inspected, questioned, corrected, or replaced without the law changing at all. When an encoding and the law disagree, the law wins - always - and the encoding is what was wrong.

This is why official encodings, where they exist, are so valuable: an encoding produced or adopted by the authority itself narrows the gap between the reading and the law, and gives everyone a shared, accountable interpretation. But even an official encoding is a tool that expresses the rule, not the rule, and even it can lag or err. So the practical discipline holds regardless of who wrote the code: treat every encoding as a maintained, versioned, contestable expression of a law that remains the real reference; prefer transparency so you can judge the reading; and keep the binding determination of compliance and the authoritative interpretation of any regulation with the qualified professional of record, the approving authority, and the governing law.

That is the honest place this module lands. Rules as code is genuinely powerful for the clear, quantitative subset of rules, and giving regulation an executable, machine-readable form delivers real speed, consistency and early feedback. But every encoding is an interpretation, made by someone with a position and incentives, and it can be hidden, wrong or out of date. So who writes the code matters enormously - and precisely because it does, the code is never allowed to become the authority. The law stays the law; the professional and the authority stay accountable; and the encoded rule earns its place only as a transparent, well-governed, always-secondary expression of a rule that lives, bindingly, elsewhere.