The Interpretation Gap

Start with the distinction the whole lesson turns on. The text of a rule is a string of words; the meaning of a rule is what those words require of a specific design in a specific situation. For some rules the two nearly coincide: 'the minimum clear width of this corridor shall be 2.0 metres' says something whose meaning, in almost any context, is just 'measure the clear width; it must be at least 2.0 m.' There is little gap, which is exactly why such rules automate well. But a great many rules are not like that. 'Adequate natural ventilation shall be provided' does not carry its meaning on its face. Adequate for what - a naturally cool climate or a humid one, a classroom of forty children or a store-room, a hospital or a garage? The word is a placeholder that a competent human fills in by reading it against the building, the occupancy, the climate and the purpose the rule is trying to serve.

This openness is not confined to a few soft words. It runs through regulation because rules must be general - written once to govern an unbounded variety of buildings the drafters could not enumerate. A rule specific enough to leave no gap for one building would be wrong for the next; so drafters use terms that travel ('suitable', 'where necessary', 'having regard to') and rely on a reader to particularise them. The gap between text and meaning is the space in which that particularising happens.

An automated check operates only on the text-facing side. It can test whether a number in the model satisfies a number in the rule. It cannot supply the meaning of an open term, because that meaning is not in the text to be extracted - it has to be constructed, by a person, for this case. Feed 'adequate ventilation' to a checker and one of two things happens: either someone has quietly replaced the open term with a hard proxy ('at least 5 percent of floor area as openable window'), which checks the proxy and not the rule and may be right in one context and wrong in another; or the rule simply cannot be evaluated and is silently skipped. Neither is interpretation. The gap remains, and a human still has to cross it.

The natural engineer's instinct is that ambiguity is a defect - if only the rules were written precisely, the gap would close and everything could be coded. This lesson resists that instinct, because in regulation ambiguity is doing essential work, and removing it would make the rules worse, not more codeable.

Consider what an open term buys. 'Adequate' lets one rule govern a school, a hospital, a warehouse and a home, each getting what is actually appropriate rather than a single number that fits none of them well. It lets the rule keep working as building types, technologies and expectations change, without redrafting for every case. It lets a human apply the purpose of the rule - the safety or amenity it exists to secure - to situations the drafters never imagined. A fully precise rule cannot do any of this: it is brittle, it is wrong at the edges, and it must be constantly rewritten. Drafters use open language deliberately, trading mechanical certainty for adaptable judgement, because buildings and their uses are too varied for a finite list of numbers to capture. The 'imprecision' is a feature that carries the rule's intelligence.

There is a deeper point. Some requirements cannot be specified in advance even in principle, because whether they are met depends on facts and combinations that only exist once the particular design is in front of you. Whether access is 'suitable' depends on where things are, who uses them and how they move - properties of the whole, in context, not of any single measurable attribute. You could try to enumerate every sub-condition, but you would never finish, and the list would still miss the case that matters. This is why the gap is permanent rather than merely current: it is not that we have not yet written the rules precisely enough, but that the meaning of a general rule in a particular case is not the kind of thing that can be fully pre-computed. It has to be judged. So the honest way to read an open term in a code is not 'the drafters were lazy' but 'the drafters delegated a judgement to a competent human on purpose' - and that delegation is exactly what a machine cannot receive.

Crossing the interpretation gap is not vague hand-waving; it is a disciplined professional skill with a real structure, and naming that structure shows why it resists automation. At least four kinds of interpretive work sit inside it.

First, which rule even applies. Before any check can run, someone must classify the situation: is this an assembly building or a business one, a mercantile occupancy or an institutional one? That classification often turns on how the building will actually be used, which is a judgement about the world, not a field in the model - and it changes every downstream limit. Get it wrong and you have run the right check on the wrong rule. Second, what an open term means here: particularising 'adequate', 'suitable' or 'reasonable' for this building, drawing on the rule's purpose, the context, and accumulated professional understanding of what has counted as adequate before. Third, how conflicting rules reconcile. Real projects routinely trip requirements that pull against each other - a fire rule wants a door to swing one way, an accessibility or security rule wants something else; two byelaws overlap; a general provision and a specific one both apply. Deciding which governs, and how to satisfy the underlying intents together, is interpretation of exactly the kind courts and expert bodies do, and no checker performs it. Fourth, spirit versus letter: recognising when a design meets a rule's words while defeating its purpose (or, conversely, misses the letter while fully serving the intent) - a judgement about what the rule is for.

This is the same work that statutory interpretation names in law: text alone underdetermines outcome, so a competent reader brings purpose, context, precedent and structure to decide what the rule requires here. It is precisely the work a plans-examiner and a designer do when they disagree, argue and settle a hard case. It is knowledge-intensive, contextual, contestable and accountable - someone stands behind the reading and can be held to it. An automated tool can support this work (surfacing the relevant clauses, flagging a possible conflict, showing the numbers), and that support is genuinely useful. But it cannot be the one who decides, because deciding requires understanding the situation and the purpose, not just matching text to data. Interpretation stays human because it is the part of compliance that was always human.

Putting the pieces together gives the central claim of this course its sharpest form: the interpretation gap is the permanent boundary of automated compliance, and the mature response is not to pretend the boundary will dissolve but to work skilfully on both sides of it. On one side lie the rules whose text nearly is their meaning - clear, quantitative, checkable - where automation delivers real speed, consistency and early feedback, and should be used to the full. On the other lie the open, performance-based and interpretive rules, where the meaning must be constructed for the case by an accountable human, and where a tool can assist but never decide. The skill this whole course teaches is knowing, for any given rule, which side of the line it sits on - and never letting a tool's silence about the second kind be mistaken for compliance with it.

Why call the boundary permanent, not just current? Because it does not come from today's tools being immature but from the nature of general rules applied to particular cases: the meaning of an open term in context is constructed, not extracted, and cannot be fully pre-computed for cases the drafters could not foresee. Better models and richer data move the line a little - they make more facts checkable and more proxies available - but they cannot abolish the gap, because the gap is where judgement lives, and judgement is what general rules deliberately delegate to humans. A checker that appears to have closed the gap has usually just hidden it, by silently swapping an open requirement for a hard proxy that may be right here and wrong next door.

Working honestly with the boundary has practical shape. Use automation confidently for the checkable side. For the interpretive side, treat any tool output as a prompt to think, not an answer: read the actual rule, particularise it for this building, resolve conflicts deliberately, and record the reasoning. And keep the two boundaries that never move: an automated check is not a legal determination of compliance and never an approval, and the authoritative rule is always the actual code, byelaw or law - the National Building Code of India, the local building byelaws and development-control regulations, the relevant IS standards - never its encoded version. Whether a design actually complies, the authoritative interpretation of any regulation, and legal responsibility all rest with the qualified professional of record, the approving authority and the governing law. The gap is theirs to cross; the tool only helps them see it.