Encoding a Rule

Automated compliance begins with a humble act: taking one rule a person can read, and turning it into something a machine can evaluate. Start with a real example, of the kind that fills every building byelaw and the National Building Code: 'the minimum clear width of a corridor in an assembly building shall be 2.0 metres.' A qualified human reads that and, drawing on training and context, knows roughly what to do. They know what a corridor is; they know 'clear width' means the unobstructed dimension, measured between finished faces, not counting a projecting column or a swinging door; they know an 'assembly building' is a defined occupancy class - a place where people gather in numbers; and they know 2.0 metres is a minimum, a floor below which the design must not fall. The sentence works because a human mind quietly fills every gap in it.

A computer fills no gaps. It cannot 'know what a corridor is' - it can only test properties of elements in a structured model. So to check this rule automatically, each piece of that implicit understanding must be rebuilt as an explicit, testable statement. The encoding must spell out, with no room left for interpretation, which elements the rule concerns, which property of them it constrains, how that property is measured, what value it must satisfy, and in which situations the rule applies at all. This is what encoding a rule really is: not translating English into another language, where meaning is presumed to survive, but reconstructing a human understanding as a precise logical structure a machine can run.

Through this whole lesson we carry this single corridor rule from prose to machine logic and watch what the passage demands and what it quietly costs. Every rule ever run against a model made exactly this journey - from a sentence a person interprets to a structure a machine evaluates - and understanding that journey is the foundation of rules-as-code. It is also where the honesty of this course begins: the moment you start to encode, you are already making choices. The rest of this lesson is about seeing those choices clearly, so you neither dismiss automated checking as useless nor over-trust it as if the encoded rule were the law itself. It is neither. It is a careful, revealing, and fallible reconstruction.

Look closely at what a machine needs, and the single sentence resolves into distinct parts - the anatomy of an encoded rule. First, the scope: when does the rule apply at all? Here, only in an 'assembly' occupancy, so the encoding needs a condition - the element belongs to a space whose occupancy classification equals 'assembly' - and if that is false, the rule is simply not relevant. Get the scope wrong and you either check corridors the rule never governed or miss ones it did. Second, the element: which object in the model does the rule test? A 'corridor' - which means the model must contain objects identified as corridors, not anonymous spaces or a bare run of walls. Third, the property: which measurable attribute is constrained? The 'clear width' - a specific, defined dimension that must exist as data on the element or be computable from its geometry. Fourth, the operator and threshold: what relationship must hold? Clear width must be greater than or equal to 2.0 metres; the operator and the value together form the testable condition.

Put together, the encoded rule reads, in effect: 'for every element that is a corridor AND whose space has occupancy = assembly, check that clear_width is greater than or equal to 2.0 m; if not, flag it as a potential non-compliance.' That skeleton - scope, element, property, operator, threshold, and an action on failure - underlies nearly every quantitative rule you will ever encode. A door clear width, a ramp slope, a travel distance to an exit, a setback, a floor-space ratio: each decomposes the same way - which elements, which property, which comparison, which value, under which conditions.

This is exactly why clear, quantitative rules are the ones that automate well: they already have this shape latent in them, and encoding mostly means making it explicit. But notice what the encoding assumes - that the model actually carries the data the rule reads: a corridor that knows it is a corridor and knows its clear width. If that data is missing or mislabelled, the cleanest encoding returns a wrong or empty answer. The anatomy is only half the story. The model must speak the same structured language the rule expects, or there is nothing to test. Encoding and the structured model are two halves of one mechanism, and neither works alone.

Now the honest half. The corridor rule looked mechanical, and its core comparison genuinely is - but even here, encoding forces a string of decisions the prose left comfortably vague, and each decision is an interpretation. Take 'clear width.' Clear of what? A structural column that intrudes into the corridor? A handrail? A door that swings into the space? A skirting, a pipe, a wall-mounted fire extinguisher? The code and its commentary may answer some of these, but the encoder must pin down one precise measurement rule - and if they choose differently from how a plans-examiner would, the automated result and the official view diverge. Take 'corridor.' The model must decide which spaces count; a lobby that widens into a passage, an open route with no walls, a space used for circulation but labelled 'foyer' - each is a classification judgement that decides whether the rule fires at all. Take 'assembly building': occupancy classification is itself interpretive, and mixed-use buildings blur it.

So three things happen in every encoding, and it is vital to see them. First, hidden decisions are forced into the open - the encoder must resolve ambiguities the prose tolerated, and those resolutions are choices, not facts. Second, meaning can be narrowed or lost - a rule whose spirit is 'people must move and escape comfortably' becomes, in code, a single width number, which captures much but not all of the intent; a corridor that meets the number but is cluttered, badly lit or oddly shaped can satisfy the encoding and still fail the purpose. Third, the measurement convention becomes load-bearing - how the property is computed from the model can change the pass or fail outcome as much as the threshold does.

None of this makes the encoding useless. The corridor-width check is genuinely valuable and catches real problems fast. It means the encoded rule is a *model* of the regulation, not the regulation itself - a faithful but lossy representation whose fidelity depends on choices the encoder made. That is why the authoritative rule always remains the actual byelaw and code, read by an accountable human, and why a clean automated 'pass' is a useful signal and never a final verdict on whether the design complies.

Step back from the single clause to the principle it teaches. Encoding a rule is not a neutral act of translation, like rendering a sentence from one language into another where the meaning is presumed to survive intact. It is a chain of decisions, each of which fixes something the prose left open. Where does the rule apply? Which elements does it govern? What exactly is measured, and how? What counts as the boundary of an element, or the moment a space becomes a corridor? Every one of these is answered by a person - the encoder - and the machine then executes their answers with perfect, literal obedience. The computer never interprets; it only applies the interpretation someone already baked in. This is the single most important idea in rules-as-code, and the rest of this module builds on it: encoding is interpretation, performed once, up front, by whoever writes the code, and then frozen into the tool.

That has three practical consequences to carry forward. First, the quality of an automated check is bounded by the quality of the encoding, which is a human, fallible, contestable artefact - it can be wrong, out of date, or reasonable-but-different from the authority's reading. Second, transparency matters enormously: if you cannot see how a rule was encoded - what it assumed, how it measures, where it applies - you cannot judge whether to trust its verdict, which is why open, inspectable encodings are far safer than opaque ones. Third, accountability cannot move to the software: a 'pass' or 'fail' is the tool reporting the consequence of someone's interpretation against your model data, not the law speaking.

The competent designer treats an encoded rule the way a good engineer treats any model - as a powerful, revealing simplification, used with full awareness of its assumptions - and keeps the binding judgement of what the rule really requires with the qualified professional, the approving authority and the actual code. Encode the checkable, yes; but never forget that you encoded it, and that the encoding is a claim about the rule, not the rule.