Speed & Early Feedback

Begin with the obvious part. For the checkable subset - widths, distances, slopes, areas, setbacks, coverage, floor-space index, required counts - an automated check against a structured model is enormously faster than a human doing the same comparisons by hand. What might take a professional hours or days of careful, interruptible measuring and cross-referencing, a checking engine does in seconds, testing every relevant element at once and producing a report of passes, failures and can-not-determines. On raw throughput there is no contest, and for the mechanical part of checking that is a real saving in expensive time.

But raw speed, on its own, is the least interesting benefit, because a one-off fast check at the end of design does not change much - it just moves the same late verification a little earlier in the afternoon. If all automation did was produce the same submission-time check faster, you would save some hours and little else. The violations would still mostly be found late, on the expensive part of the cost curve, because you would still only check when the design was nearly done. Speed matters not for itself but because of what it removes: the *cost per check*. When each check is slow and effortful, checking is scarce, so you ration it. When each check is instant and effortless, checking becomes abundant, so you can spend it freely - and abundance is what unlocks the two gains that actually matter.

So hold speed in its proper place. It is genuine and worth having, but it is the enabler, not the prize. The prize is what you do with checks once they are cheap enough to run whenever you want: run them *early*, before decisions harden, and run them *often*, so no change goes unverified for long. Everything valuable about fast automated checking flows from turning an expensive, rationed act into a cheap, abundant one. The rest of this lesson is about those two consequences - early and often - because that is where the speed of the checkable subset stops being a convenience and starts changing how design actually happens. And it is worth saying once more, before we get carried away: faster is not the same as more correct, and none of this touches the rules that need judgement.

The first thing cheap checking buys is *early* checking, and this connects directly to the rising-cost curve from the cost lesson. Recall the shape: a quantitative violation costs almost nothing to fix on an early sketch and a great deal to fix once it is built, because what grows is not the violation but the amount of committed, coordinated work that must be undone. The violation is the same half-metre setback encroachment whether you find it on a napkin sketch or in poured concrete; only the price of correction rises. It follows that the single most valuable thing you can do about a checkable violation is *find it early* - move it to the cheap left-hand side of the curve.

Manual checking cannot do this, because it is too expensive to run early. You cannot afford to hand-check a rough massing sketch against the byelaw, so you do not; you wait until the design is developed enough to be worth the effort, by which time the cheap moment has passed. Automated checking of the checkable inverts this. Because it costs seconds, you can run it on the earliest structured model - the moment a massing has setbacks and a footprint, the moment a plan has corridors and rooms - and get an immediate read on the quantitative rules. A setback bust, an over-coverage, an under-width corridor, an over-long travel distance shows up while it is still a line to nudge, not a wall to demolish.

This is the idea software engineering calls *shift-left*: move checking as far toward the beginning of the process as you can, because defects caught early are defects caught cheap. Applied to compliance, shift-left means treating the checkable rules not as a final exam the design must pass at submission, but as constraints you can see and respect from the first sketch. It does not shift the judgement-laden rules left - those still need a professional's attention at the right stage - and it does not make an early pass an approval. But for the quantitative subset, shifting the check left is where the biggest money is saved, because it attacks the steep right-hand side of the cost curve by simply never letting violations get there. Speed is what makes early checking affordable; early checking is what makes speed pay.

The second thing cheap checking buys is *frequency*, and this is the subtlest and most powerful effect of all: it changes how you design, not just when you check. When a check is instant, you can run it after every meaningful change - move a wall and see at once whether the corridor still passes, add a floor and see immediately whether coverage or floor-space index is still legal, stretch a plan and watch the travel distances update. Compliance stops being a distant gate you approach with dread and becomes a live readout, always current, responding to your moves like a spellchecker underlining a word the instant you mis-type it.

A fast feedback loop of this kind does something to the design process that slow checking never can: it makes the constraints *visible while you are still deciding*. Instead of designing freely and then discovering at submission which rules you broke, you see the quantitative constraints respond as you work, so you internalise them and design within them from the start. You can also explore more boldly, because the cost of trying an option and finding it non-compliant has collapsed - test a layout, see it bust the setback, adjust, re-check, all in seconds. The tight loop encourages iteration; iteration is how design improves; so fast checking, applied well, does not just police design, it can *support* it, by making the checkable consequences of each move legible in real time.

This is why the biggest prize is early-and-often rather than merely fast. A single fast check is a convenience; a continuous fast feedback loop is a different way of working, in which the mechanical constraints are ambient and always-on, and the designer's attention is freed to spend on the parts that are not mechanical. The honest boundaries still hold, and matter more here than anywhere: the loop only covers the checkable rules, so it can lull you into thinking a design that keeps passing is compliant when the judgement-laden and un-encoded rules are untouched; a fast, frequently-green readout is a powerful magnet for automation bias; and a live pass is emphatically not a live approval. Used with that discipline, though, the fast feedback loop is the single most transformative benefit in this whole course - the point where automating the checkable stops saving time and starts changing how design is done.

Because speed and a live green readout are so seductive, this is exactly where an honest course must plant a warning. A faster check is not a more correct check, and the confidence a quick, continuous pass radiates is precisely the feeling that leads people astray. Everything gained here is real, but every gain is confined to the same narrow territory: the checkable subset, evaluated against the data in the model, using rules someone encoded. Speed does nothing to widen that territory - it just lets you traverse it more often.

Be concrete about what fast, early, frequent checking does *not* buy. It does not buy correctness of the encoded rules: if a rule was encoded wrongly or is out of date, running it a hundred times a day just gives you the wrong answer a hundred times, faster and more confidently. It does not buy coverage: the judgement-laden rules, the performance rules that need analysis, the rules that depend on facts not in the model - none of these enter the loop at all, so a perpetually green readout can coexist with serious unaddressed non-compliance. It does not buy data quality: the loop only sees what the model represents, so a mis-classified or missing element passes invisibly, fast. And it does not buy approval: the authority grants that, on the authoritative code and byelaw, never on the strength of a quick internal check.

The real hazard the speed introduces is psychological. A slow manual check is treated with appropriate caution; a fast, always-green automated readout invites you to stop looking - the essence of automation bias. The faster and more continuous the feedback, the stronger the pull to trust the tick and forget everything it does not cover. So the disciplined stance is to enjoy the genuine prize - early, often, continuous feedback on the checkable, which really does catch quantitative issues while they are cheap and really does change how you design - while holding three things firmly in mind: the loop covers only the checkable subset, a fast pass is only as good as the encoded rule and the model data, and it is never an approval. The professional of record and the approving authority remain fully accountable for whether the design actually complies, and the authoritative rule is always the real code, byelaw and IS standard, never its fast, green, encoded shadow.