How Checking Works

A check begins with an encoded rule - the machine-readable form built in Module 3. The first stage is to parse it: the engine reads the rule's structure and works out what it is actually asking. A rule like 'the clear width of a corridor in an assembly occupancy shall be at least 1.8 m' decomposes into parts the engine can act on: a scope (which elements it governs - corridors, and only in assembly occupancies), a property to inspect (clear width), a comparison (greater than or equal to), and a threshold (1.8 m). Parsing turns a statement into an executable test with named ingredients. If the rule is written in a structured rule language or a decision table, this stage is clean; if it was captured loosely, ambiguity here is the first place a check can go wrong.

The second stage is to find the relevant elements - to select, from the whole model, exactly the objects the rule governs. This is a query against the model's structure: return every element of type Corridor whose occupancy is Assembly. Everything downstream depends on this selection being right, and it is more fragile than it looks. If a corridor was authored as a generic region rather than typed as a Corridor, it will not be selected, and the rule will silently never test it - a false sense of safety. If occupancy is unset, the engine cannot tell whether the assembly condition applies. The scoping stage is where model quality and rule precision first meet: the rule can only check the elements it can find, and it can only find the elements the model correctly declares.

Together these two stages define the *population* of the check: what is being tested and against which elements. A good engine is transparent about both - it can tell you how many elements a rule matched, which is itself diagnostic. If a corridor-width rule matched zero elements in a building full of corridors, that is not a pass; it is a warning that the model is not carrying corridors as the rule expects. Reading how many elements a rule found, before reading how many passed, is one of the habits that separates a critical user from someone who trusts a colour.

With the relevant elements selected, the engine moves to extract the properties the rule needs. For each corridor found, it reads the clear-width value; for a travel-distance rule, it may read or compute the path length to the nearest exit; for a coverage rule, it reads areas and the plot boundary. Extraction sounds trivial but carries real subtlety. Some properties are stored directly as data (a door's clear opening was entered by the modeller); some must be derived by the engine from geometry (the actual clear width between two walls, the length of an escape path around obstacles). Derived properties are more powerful and more error-prone: a small modelling quirk can change a computed distance. And every property carries units and assumptions that must match the rule - a width in millimetres tested against a threshold in metres, if mishandled, produces nonsense that looks like a confident verdict.

The fourth stage is to test the condition: apply the comparison the rule specified to the property value. Is 1.5 m greater than or equal to 1.8 m? No - so this corridor fails the rule. Is 2.1 m greater than or equal to 1.8 m? Yes - so this one passes. For a single numeric threshold this is a simple comparison; real rules can be compound (a width that depends on occupant load, a distance limit that changes with sprinkler protection), so the test may combine several extracted values through logic. The important thing is that this stage is genuinely mechanical and reliable *when the inputs are sound*: given the right elements and correct property values, the comparison is exactly the kind of thing computers do without error or fatigue.

This is the heart of why automated checking works for the codeable subset. The mechanical comparison that a tired human might mis-add or skip across two hundred corridors is run identically for every one. But notice where all the risk has moved: not into the comparison, which is trustworthy, but into the stages before it - did the engine find the right elements, and did it extract the right values with the right units and assumptions? The test is only as good as what feeds it, which is why the report must distinguish a genuine fail from a case where the engine could not get a trustworthy value at all.

The final stage turns per-element results into a report a human can act on. For every rule and every element it governs, the engine records an outcome, and an honest engine records three possible outcomes, not two. Pass: the condition was tested on a trustworthy value and held. Fail: the condition was tested and did not hold - this corridor really is too narrow in the model. And cannot determine: the engine could not reach a trustworthy verdict, because the property was missing, the element was mis-classified, the units were ambiguous, the value fell outside what the rule anticipated, or the rule itself was not fully codeable.

The cannot-determine verdict is the single most important thing an honest checker produces, and the easiest to get wrong. The dangerous failure mode is a tool that collapses three outcomes into two - that treats 'I could not find a width' as a pass because it found nothing to flag. That silent pass is exactly how automated checking causes harm: it converts an unanswered question into false reassurance, and a designer or examiner reading a clean report never learns that a whole set of elements was never actually tested. A good report instead surfaces every cannot-determine as loudly as every fail, because both demand human attention - the fail to fix or justify, the cannot-determine to complete the data or accept that the rule needs a human.

Reading a report well, then, is a skill in itself. Do not read the pass count first; read the cannot-determine list and the matched-element counts, because those tell you how much of the rulebook was genuinely evaluated and how much quietly slipped through gaps in the model. A rule that matched zero elements, a property that was missing on half the doors, a derived distance the engine flagged as uncertain - these are not clean results, they are open questions. The competent stance is to treat the report as a structured to-do list of flags and unresolved questions that narrows a vast rulebook to what needs a human's eyes, not as a verdict on the building. The engine's honest 'I cannot tell' is worth more than a confident answer built on data it did not have - and a pass, remember, still describes only the data given and is never an approval.

Step back and the pipeline explains both the power and the fragility of automated checking in one picture. The power is concentrated in the test stage and its repetition: a clear comparison, run identically over every relevant element, tirelessly and in seconds. That is a genuine advance over a human tracing hundreds of elements by hand, and it is why the codeable, quantitative rules - widths, distances, slopes, areas, counts, the staples of development-control and life-safety scrutiny - are checked so well. Nothing about the comparison is fatigued, inconsistent or forgetful.

The fragility lives everywhere else. Parsing can misread a loosely written rule. Element-finding can miss objects the model failed to classify, so a rule silently tests nothing. Property extraction can read a wrong unit, or derive a distance that a modelling quirk distorted. And the codeability of the rule caps the whole thing: a pipeline can only ever run rules that reduce to a scope, a property, a comparison and a threshold - the judgement-laden and performance rules never enter it at all. The comparison is trustworthy; the inputs and the rule's very codeability are where error enters.

This is why the report's three verdicts matter so much, and why an honest engine is transparent about matched-element counts and cannot-determine cases: they expose the fragile stages instead of hiding them behind a confident colour. It is also why the human is not optional. Someone has to read the report critically - to ask whether a rule found the elements it should have, whether a pass rests on trustworthy values, whether the cannot-determines point to missing data or to rules that were never codeable - and someone accountable has to decide what the results mean for the design. The pipeline narrows a vast rulebook to a short, structured list of flags and open questions with real speed and consistency; it does not, and cannot, close them. The qualified professional of record and the approving authority do that, and the authoritative rule remains the actual code, not the encoded version the engine happened to run.