The Ambiguity Problem

"Ambiguity" is a loose word for several distinct things a machine struggles with, and it helps to separate them. The most visible is judgement-laden or evaluative terms: "adequate", "suitable", "reasonable", "appropriate", "satisfactory", "sufficient", "proper". These words do not name a threshold; they name a *standard to be judged*. "Adequate ventilation" asks: adequate for what, in this room, for these occupants, in this climate? The rule deliberately declines to answer with a number and hands the assessment to a competent human.

A second face is vagueness proper - terms with fuzzy boundaries even when no evaluation is intended. When exactly does a "minor" alteration become a "major" one? When is a slope "gentle"? There is a clear core and a genuinely blurry edge, and cases fall in the blur. A third face is open texture: a term may be perfectly clear for the situations anyone anticipated and simply undetermined for a new one - a rule written before a technology or a building type existed does not tell you how it applies to that novelty, not because it is badly written but because no rule can anticipate everything. A fourth is context-dependence: the same word means different things in different settings. "Suitable access" for a warehouse and for a hospital are not the same standard, and the rule relies on the reader supplying the context. A fifth is semantic and referential ambiguity: a sentence that can be parsed two ways, or a term whose definition is itself partly qualitative or circular.

What unites these is that each requires a reader to *supply meaning the text does not fully fix* - by evaluating against a purpose, resolving a boundary, extending a rule to an unforeseen case, importing context, or choosing a reading. A prescriptive number leaves nothing to supply; that is why it automates. A judgement-laden term leaves the decisive step to a human by design; that is why it does not. For automated compliance the practical consequence is direct: whenever a rule turns on one of these words, the tool reaches the edge of what it can do. At best it can flag that the clause exists and route it to a person; it cannot pronounce on it. And building regulation is thick with such words, because so much of what we want from buildings - that they be safe, healthy, accessible, decent - is easier to state as a standard to be judged than as a number to be met.

The instinct of someone who wants to automate compliance is to treat every vague word as a defect - if only the code said "2.0 m" instead of "adequate", we could check it. But pause on why a skilled drafter chose the open word, because the reasons are good, and missing them leads to worse regulation, not better tools.

First, the future is unforeseeable. A rule must govern buildings, materials, uses and situations that did not exist when it was written. A fixed number bakes in the drafter's assumptions and breaks on the case they never imagined; an open term like "adequate" flexes to fit the novel case by referring to its purpose. Second, the purpose is what matters, not the proxy. "Adequate means of escape" ties the rule directly to the real goal - people getting out safely - whereas any specific number is only a proxy that is right for typical cases and wrong for some. When the proxy and the purpose diverge, the open term follows the purpose. Third, a fixed rule can produce absurd or unjust results. Rigid numbers applied literally to an odd case can demand something pointless or forbid something plainly fine; a judgement standard lets a competent human avoid the absurdity. Fourth, it delegates to expertise on purpose. "Suitable", "reasonable" and "adequate" are the law's way of saying: a qualified professional, and ultimately the authority, should judge this against the circumstances, because a central drafter cannot foresee them all. Fifth, over-specification is gameable and brittle - a rule reduced to a precise number invites designs that meet the letter and defeat the spirit, and shatters the moment reality steps outside its assumptions.

This is why legal systems everywhere are full of open-textured standards, and why the discipline of interpretation exists at all. Ambiguity is frequently the mechanism by which law stays humane, adaptable and tied to purpose. That does not mean all vagueness is virtuous - some really is careless drafting that clearer wording would improve, and reformers rightly push to sharpen rules that could be sharper without loss. But the crucial recognition for automated compliance is that a large, deliberate core of vagueness *cannot be engineered away without making the regulation worse* - more rigid, more gameable, blind to the unforeseen. The messiness is not always a bug to be fixed on the road to full automation; often it is the point. And a rule that has been forced into a fake precision just to please a checker is a rule that has quietly changed what the law requires - which is not a small thing to do by writing code.

The sharpest evidence that ambiguity is real, and not merely a gap awaiting a better definition, is that competent, honest, qualified people read the same clause and reach different, defensible conclusions - and there is often no fact of the matter that settles which is right. Two experienced plans-examiners can look at the same design against "suitable access for disabled persons" and disagree: one holds that a code-compliant ramp and door width satisfy it, the other that "suitable" means usable in practice - real wayfinding, real turning space for this building's actual users - and is not yet met. Both readings are competent. Both are defensible. The disagreement is not ignorance; it is genuine interpretive divergence about what an open term requires in a particular case.

This matters enormously for rules-as-code, because it dismantles a seductive assumption: that if we just wrote the encoding carefully enough, we would capture "the" correct meaning of the rule. For a genuinely ambiguous term there may be no single correct meaning to capture - only a range of reasonable interpretations among which a human authority chooses, exercising discretion, often guided by purpose, precedent and context. An encoding cannot make that choice legitimately; if it hard-codes one interpretation, it silently substitutes the programmer's reading for the authority's, and presents a contested judgement as if it were a settled computation. That is not automating the rule; it is quietly rewriting it, and hiding the rewrite behind a green tick.

This is what this course calls the interpretation gap, and it is the heart of why compliance resists automation. It is not that machines are too slow or too dumb, or that the software is immature. It is that a large part of applying regulation *is* interpretation - deciding what an open term means here, which of several rules applies, how conflicting requirements reconcile, whether an unforeseen case falls inside or outside a rule - and interpretation, where reasonable experts genuinely differ, is a human and institutional act, not a calculation. The legal system has a whole apparatus for it: qualified professionals who form a view, authorities who decide, and above them the machinery of appeal and, ultimately, the courts. A checking engine sits outside all of that. It can help by handling the determinate parts and by surfacing the ambiguous clauses for a human to judge - a genuinely useful division of labour. What it cannot do is close the interpretation gap, and any tool or vendor that claims to has either narrowed "compliance" to only its checkable slice or is misrepresenting what it does.

So what should a compliance-literate designer *do* about the ambiguity problem? Not despair of automated compliance - and not pretend the vagueness away. The competent response is a division of labour that respects the boundary.

First, automate the determinate and route the rest. The right role for a checker facing a rulebook full of mixed content is to run the clear, quantitative, prescriptive rules confidently, and - crucially - to *flag* the judgement-laden clauses rather than fake a verdict on them. A tool that says "corridor widths: checked; 'adequate ventilation': requires human assessment - here is the clause" is being honest and genuinely helpful; a tool that silently scores "adequate ventilation" as pass or fail is misleading. Surfacing the ambiguous clauses to the right human at the right time is itself real value; pretending to resolve them is the failure mode. Second, read a green tick for what it covers. A pass means the encoded, checkable rules found no flaggable issue in the data given - it says nothing about the judgement-laden requirements the tool could not evaluate, which may be exactly the ones that decide whether the building is truly safe and decent. Third, keep the interpretation with the people the law gives it to. Where a term is genuinely open, the reading that binds is the qualified professional's considered judgement and, above all, the approving authority's decision - not the programmer's encoded guess. If you must adopt an interpretation to proceed, hold it as provisional and confirm it with the authority.

There is also a forward-looking point worth holding honestly. Some ambiguity can and should be reduced - careless vagueness clarified, terms defined, quantitative content separated from qualitative - and better drafting can enlarge the checkable subset over time. Emerging work in computational law even explores encoding rules and their interpretation together. But a deliberate, purposeful core of open-textured standards will and should remain, because it is how regulation stays flexible, purposive and humane. The mature stance, then, is neither the technologist's dream of dissolving all ambiguity into code nor the sceptic's dismissal of automation as hopeless. It is to see clearly that regulation is part determinate and part judgement, to automate the first part rigorously, to surface and defer the second part honestly, and to keep the interpretation gap firmly in human hands - the qualified professional of record, the approving authority, and the governing law itself (the NBC, local byelaws and IS standards), whose reading of an ambiguous rule is the only one that binds. Get that right and you have the central insight of the whole course: know exactly which rules can be run, which must be judged, and why the human stays accountable for the difference.