Translating Law to Logic

Start by killing the comfortable metaphor. Encoding a regulation is not like photocopying it into a new format; it is like translating a poem into another language - the meaning has to be re-expressed, and something is always chosen and something is always at risk of being lost. A clause of building regulation is written in natural language, for humans, to be read with professional judgement and in context. Executable logic is the opposite: precise, literal, context-free, and unforgiving of ambiguity. Bridging that gap forces a series of decisions that the prose never made explicit.

Consider a clause as ordinary as 'every habitable room shall have a window of adequate area for light and ventilation'. To run it, an encoder must answer questions the sentence leaves open. What counts as a habitable room here - is a large kitchen included? What is 'adequate' - ten percent of floor area, a daylight-factor threshold, or something else? Does area mean glazed area or opening area? What about a room lit by a shaft or a skylight? Does a borrowed-light arrangement qualify? Each answer is a choice. Write it one way and a design passes; write it another and the same design fails. The prose tolerated this ambiguity because a human reader resolves it with judgement; the code cannot, so the encoder resolves it in advance, once, for everyone the rule will ever touch.

This is why 'translating law to logic' deserves the word translation. A good translator is faithful but must still decide; a careless one distorts. The encoder is choosing a single interpretation from a space of defensible readings and freezing it into a rule that will be applied mechanically and at scale. That is powerful when the choice is sound and the clause is genuinely quantitative. It is dangerous when the clause is judgement-laden and the choice is presented as if it were the law itself. The competent stance is to treat every encoded rule as an interpretation that carries an author, an assumption and a date - and to keep asking whether that reading still matches the actual regulation, which remains the only authoritative source.

If encoding is interpretation, it helps to name exactly where the choices and losses hide, because they are not random - they cluster in predictable places. Learn to spot them and you can tell a safe encoding from a risky one.

The first is judgement-laden language. Words like 'adequate', 'suitable', 'reasonable', 'sufficient' and 'appropriate' are doing real work in the law: they let a human weigh context. To encode them you must replace the judgement with a fixed proxy - usually a number - and that proxy is a choice, not the rule. The second is defined terms and scope: which rooms count as habitable, which buildings as assembly occupancy, which routes as means of egress. Get the scope wrong and the rule checks the wrong elements. The third is exceptions and provisos - the 'except where', 'unless', 'subject to' clauses that qualify the main rule. These are easy to drop when simplifying a clause into clean logic, and dropping them makes the encoded rule stricter or looser than the law. The fourth is thresholds and tables: the exact number, and the exact conditions under which each number applies, often scattered across tables, footnotes and cross-references that must be assembled correctly. The fifth is silence and conflict: what the clause does not say, and how it reconciles with another clause that points the other way - which the encoder must decide even though the law left it to interpretation.

Each of these is a place where meaning can leak out between the prose and the logic. Sometimes the loss is harmless simplification; sometimes it changes the outcome. A dropped proviso can fail a compliant design; a mis-set threshold can pass a non-compliant one; a mis-scoped term can check corridors that were never meant to be corridors. And crucially, the leak is invisible at run time - the checker reports a confident pass or fail with no hint that the underlying reading was contestable. This is why reading the encoded rule back against the source clause, proviso by proviso, is not pedantry but the core quality discipline of the field. The authoritative rule is the clause as written; the encoding is only as trustworthy as its fidelity to it.

If every encoded rule embeds an interpretive choice, the sharp question is: who gets to make it, and does their choice carry any authority? This is a governance problem, not a technical one, and rules-as-code often gets it backwards - the choice is made quietly by whoever happens to write the code, and then applied to everyone as if it were settled law.

Think about who could be doing the encoding. It might be a software vendor's engineer with no legal standing, working from a reading of a code they did not write. It might be a domain consultant hired by that vendor. It might be the regulator itself, encoding its own rules - the strongest case, because then the interpretation carries the authority of the body that made the rule. It might be an open community of practitioners. These are very different in legitimacy. When the regulator publishes an authoritative encoding alongside the prose, the interpretation has standing and can be relied on more safely. When a private vendor encodes a public rule in a black box, the interpretation has no legal authority at all - it is one company's opinion, applied at scale, and a design that 'passes' has satisfied that opinion, not the law.

This matters because interpretation is exactly the work the law assigns to accountable humans: the professional of record who must certify the design, and the approving authority who must decide compliance. An encoded rule cannot inherit their authority just by being run on a computer. So the honest position is layered. Where a rule is clean and quantitative and the encoding is faithful, the interpretation is low-stakes and the tool is a genuine help. Where the encoding embeds a contestable reading of a judgement-laden or conflicting clause, that reading must be visible, attributable and open to challenge - and it never displaces the authority's own interpretation. In India, where byelaws are adapted locally and interpreted by the sanctioning authority, this is acute: an encoded reading of a setback or use-classification rule is a convenience for the designer, but the local body's interpretation of its own byelaw governs. Ask, always: whose reading is this, what is it based on, and who actually has the authority to decide? Defer the binding interpretation to the professional, the authority and the law.

It would be easy to treat all this as philosophy. It is not - a wrong or contested encoding is a concrete way for automated compliance to cause harm, and the mechanism is worth stating plainly. An encoded rule is applied mechanically, at scale, and with an air of authority. If the reading behind it is wrong, every design it touches is checked against the wrong rule, and the error is delivered as a confident pass or fail that discourages a second look. Automation bias does the rest: a green tick is trusted, a red flag is fixed to, and few users go back to the source clause to check whether the encoded reading was even correct.

The failure modes are two-sided and both are bad. A too-strict encoding - a dropped exception, a proxy number set high, a scope drawn too wide - fails designs that actually comply, wasting effort, forcing needless changes, and quietly teaching designers to distrust and route around the tool. A too-lenient encoding - a missing condition, a threshold set low, an exception invented - passes designs that do not comply, which is worse, because it manufactures false confidence about safety-relevant matters like egress, fire separation or accessibility, and the miss may surface only when something goes wrong in the real building. A contested encoding is different again: it may be neither clearly right nor clearly wrong, but it resolves a genuine ambiguity one way and then hides that it made a choice - so a design's fate turns on an unexamined reading no one agreed to.

The defences are not exotic, but they must be deliberate. Keep the encoded rule traceable to the exact source clause, so any result can be checked back against the law. Make interpretive choices explicit and reviewable rather than buried in code. Prefer to flag genuinely judgement-laden clauses for human decision instead of forcing a false number. Version and date every rule so you know which reading was applied. And treat every automated result as provisional evidence, not a verdict - the design actually complies only when the accountable professional and the approving authority say so, measured against the real regulation. The encoded rule is a fast, fallible reading; the law is the rule. Never let the shadow stand in for the thing.