Machine-Readable Regulation

It is tempting to think a regulation is machine-readable once it exists as a digital file - a PDF of the byelaw, say, that you can search and copy from. It is not. A PDF is readable by a human on a screen; the computer sees a bag of characters with no idea which are a rule, which a heading, which a footnote, or what any of them mean. Machine-readable, in the sense automated compliance needs, means something much stronger: the rule is represented so that a program can identify its parts, understand their types, and evaluate its condition without a human interpreting anything at run time.

Concretely, that means a rule must be broken into explicit, labelled components - the same anatomy from lesson 3.1, now made into data a machine can parse. Which occupancy does this apply to? Which element does it govern? Which property, in which units? What comparison, against what value? A machine-readable rule states each of these as a distinct, typed field, not as a clause a reader must untangle. It also means the terms the rule uses point to definitions the machine can resolve: 'clear width' is not a phrase to be understood but a defined, computable quantity; 'assembly' is not a word but one value in a defined set of occupancy classes.

The contrast with prose is the whole point. Prose is optimised for a human reader: it is compact, it relies on shared background, it tolerates - even uses - ambiguity, and it trusts the reader to bring judgement. Machine-readable form is optimised for a program: it is explicit, typed, defined, and structured, because the program brings no judgement at all. Neither is 'better'; they serve different readers. The mistake that wastes real effort is assuming that digitising the prose - scanning it, searching it, even neatly reformatting it - has made it machine-readable. It has not. Making a regulation machine-readable is a restructuring of the rule into an explicit, defined, typed, versioned form, and it is that restructuring, not the file format, that lets a computer evaluate it. Everything else in this lesson unpacks what that restructuring requires.

A machine-readable rule needs several ingredients working together, and it is worth naming them because a gap in any one breaks the whole. The first is structure: the rule must be split into parseable parts - scope, element, property, operator, value, action - rather than left as one flowing sentence. Structure is what lets a program find the pieces it must evaluate instead of guessing at grammar. The second is unambiguous definitions: every term the rule leans on must be pinned to a single, explicit meaning. What exactly is a corridor? How is clear width measured, and clear of what? What units - metres, millimetres? Which occupancy classes exist, and what puts a space in one? Prose can leave these to a trained reader; a machine-readable rule cannot, so the definitions must travel with the rule, resolvable by the program.

The third ingredient is a format: a defined, consistent data representation that software can actually read and exchange - typed fields, explicit units, references between rules and definitions - so that different tools interpret the same encoded rule the same way. This is where interoperability lives: without a shared, well-defined format, every tool invents its own, and an encoded rule cannot move between them. A machine-readable regulation, done well, is not just structured for one program but expressed in a form many programs can consume consistently, ideally leaning on shared classifications and vocabularies rather than private ones.

Underneath these sits a demand the prose rarely made explicit: the rule must connect to a shared understanding of the things it talks about. A width check is meaningless unless 'the model' and 'the rule' agree on what a corridor, a door, a room, an occupancy actually are - a common vocabulary of building elements and properties. This is why machine-readable regulation is entangled with the data standards of the model it will check against: the rule's defined terms and the model's classifications have to line up, or the rule finds nothing to test. Structure, definitions and format make a rule readable in principle; agreement with the model's vocabulary makes it runnable in practice. Both are real work, and both are places the effort quietly fails when skipped.

There is one ingredient of machine-readable regulation that is easy to forget and dangerous to skip: versioning. Regulations are not fixed. The National Building Code is revised; municipal byelaws and development-control regulations are amended, sometimes frequently and locally; IS standards are updated and occasionally withdrawn and replaced. A rule that was correct last year may have a different threshold, a different scope, or no force at all this year. For a human reading the prose this is manageable - they check which edition applies. For a machine running an encoded rule it is invisible unless the version is part of the data.

So a properly machine-readable rule must carry, as explicit fields, which regulation and edition it encodes and from when it is in force - and, ideally, which version it was superseded by. Without this, an encoded rule is a claim with no date on it: the tool confidently checks a design against a threshold that may already have changed, and returns a clean 'pass' that is quietly out of date. This is not a corner case. Because encoded rules are reused across many projects and tools, a stale encoding scales its staleness - one wrong, un-versioned rule can silently mislead every design that runs against it, and no one sees the error because the tool still returns a tidy verdict.

Versioning also underwrites accountability and trust. When a rule is versioned, you can ask the essential questions: which edition of the byelaw does this check implement, when was it last updated against the source, and does it match what the authority is actually applying today? A machine-readable regulation without versioning cannot answer those, and an answer you cannot get is a risk you cannot manage. This is one of the strongest practical reasons the authoritative rule must always remain the actual, current code and byelaw: the encoded version can drift, and only by keeping the live regulation as the reference can that drift be caught. Treat any encoded rule you rely on as suspect until you know its version and its currency - and treat versioning not as metadata bookkeeping but as a first-class part of what 'machine-readable' has to mean.

Put the ingredients together and you can see the size of the gap between an ordinary paragraph of regulation and a form a machine can evaluate. Take a real prose clause - 'adequate means of egress of suitable width shall be provided from every assembly space for the occupant load' - and try to make it machine-readable. You must define 'adequate' and 'suitable' (or admit they cannot be defined and mark the rule as not fully checkable), fix how occupant load is determined, decide which elements are 'means of egress', settle the units and the formula relating width to load, structure it all into typed fields, and stamp it with a version. What looked like one sentence becomes a substantial piece of structured, defined, versioned data - and part of it, the 'adequate' and 'suitable', may not cross the gap at all, because it was judgement in the first place.

This is why machine-readable regulation is genuine, ongoing human work, not a one-time conversion you can automate away. Someone must do the structuring, resolve or flag every definition, choose the format, align the terms with the model's vocabulary, and maintain the versioning as the source changes. Every one of those steps involves the interpretive choices of the previous lessons, which is why the gap is not just technical but governance-laden: bridging it means deciding what the rule means and keeping that decision current and transparent.

The Indian context makes the gap concrete. Byelaws vary enormously across thousands of urban local bodies, are amended on their own schedules, and are often published as prose documents, not structured data; many building submissions are still 2D drawings rather than structured models with a shared vocabulary. So while the quantitative development-control rules are exactly the kind that could be made machine-readable - and approval-digitisation is steadily doing this for parameters like setbacks, coverage and FSI - the honest picture is that most regulation is not machine-ready today, and making it so is a large, distributed effort. Knowing the gap keeps you realistic: automated checking reaches only as far as regulation has actually been made machine-readable, and the authoritative rule remains the live prose code, bridged to machine form by accountable humans.