How checking works
What is guaranteed by derivation, what is checked afterwards, and what nothing checks at all.
Three different mechanisms, and the difference between the first two is the whole design.
① Derived — cannot go wrong
Nothing checks that the door on the plan matches the door on the elevation. There is no second place for it to be written down.
wall start and end points ridge height
opening x/y from "center" room areas
wall pieces around openings lot coverage and FAR
stall coordinates and ADA widths occupant load
egress routes and travel distance every 3D camera in the view railThis tier costs nothing at authoring time and covers most of the guarantee. An author cannot write a contradiction, because a contradiction needs two declarations.
② Validated — checked afterwards
validate() runs 73 rules over the compiled model and returns diagnostics. It
is a separate pass: it never mutates, never repositions and never fixes.
One code covers one question, not one measurement. Which geometric fact failed is in the message, where the reader acts on it.
Break the model below and watch it fire.
Four edits worth trying, and what each returns:
| Edit | Diagnostic |
|---|---|
Delete the inner line | room/unreachable — add a door between "Study" and "Living" |
Set win's head to 3.1 | opening/too-tall — lower head, or raise the storey height |
Set inner width to 6 | opening/overruns, with the legal range printed |
Change "level":"g" to "level":"first" | schema/reference — point "level" at an id declared in this file |
Every message names the entity, states the rule and proposes the fix, because the reader is usually the model that wrote the file. A diagnostic a model cannot act on does nothing.
Three classes of diagnostic
| Class | Example | Meaning |
|---|---|---|
error · schema | schema/reference, opening/too-tall | the model is not valid |
error · topological | stair/through-wall, room/overlap, level/stack | two derived sheets would disagree about the same building |
warning · advisory | room/unreachable, stair/no-void, site/setback | unusual, not impossible — named and released |
The generalisation worth stealing. A rule that only checks an object against itself will pass on models that are spatially absurd. Every entity needs at least one check relating it to something else.
That principle was learned the hard way. When spatial stair rules were added, four of the five multi-storey examples failed at once: a flight through a partition, two arriving inside bedrooms, one arriving in mid-air, and every one of them arriving under a solid slab with no opening to come up through. None of those drawings looked wrong.
③ Unchecked
A clean diagnostics file means the building is consistent, not that it is good. Whether the kitchen works, whether the entrance reads, whether the plan is worth building — none of that has a checkable constraint, so none of it is in scope.
The line the project draws:
If a thing has no hard architectural constraint, it does not belong in this library. Walls must close and doors must live in walls — checkable, so ours. "Is this layout attractive" is taste, so not ours.
The egress analysis stops at terminates: "exterior-door". It does not ask
what lies beyond that door. One gallery model passed every check while sending
129 occupants into a fenced yard with no gate.