Where It Fits in Design

The instinctive way to use a compliance checker is as a final gate: finish the design, then run the check, or leave it entirely to the authority at submission. It feels tidy - checking is a distinct step, done once, at the end. But it is the costliest possible arrangement, and understanding why is the key to placing automated checking well.

The reason is the cost-of-change curve. A design problem is cheap to fix when the design is still an idea and expensive when it has hardened into built form. Early on, moving a wall or widening a corridor is a few minutes of redrawing. By detailed design, the same change ripples through structure, services, schedules and coordinated drawings. At submission, a flagged violation can mean redrawing a whole package under deadline pressure. On site, it can mean demolition and rebuilding. A compliance issue is exactly this kind of problem: an under-width corridor or an over-long escape route found at concept costs almost nothing to correct, while the same issue found at the approval gate - or after - can be ruinous.

So a late gate maximises the cost of every issue it finds, precisely because it finds them late. It also wastes the single greatest advantage automated checking offers over manual checking: not just accuracy, but speed and repeatability that make it feasible to check constantly. A human plans-examiner can realistically check a design in full only a few times; an automated check of the quantitative rules can run every time the model changes, at negligible cost. Confining that capability to one final run throws its main benefit away.

There is an honest caveat even here. A late gate at least checks a complete design, whereas early checks run on partial, evolving models and can be noisy or premature. That is a real trade-off, not a reason to keep checking to the end - it is a reason to check continuously and read early results as provisional. The goal is to move the checkable feedback as early as it can usefully go, so that when the design reaches the real gate - the authority - there are few surprises left. The gate still exists; it is just no longer where you discover your problems.

'Shift-left' is a phrase borrowed from software engineering, where teams learned that finding a defect at release is far more expensive than finding it while writing the code, and so moved testing 'left' - earlier - and made it continuous rather than a final phase. The same logic transfers cleanly to compliance. Instead of one check at submission, run small automated checks throughout design, so that the checkable rules are evaluated again and again as the model evolves and a violation surfaces within minutes of the change that caused it.

What can shift left? Exactly the subset this course keeps returning to: the clear, quantitative, model-checkable rules. In the Indian context these are the development-control parameters that dominate plan-scrutiny - setbacks, ground coverage, floor-space index, height limits, plot rules - together with corridor and door widths, egress travel distances, ramp slopes, required counts and areas. These are cheap to re-run and give unambiguous feedback: this dimension either meets the number or it does not. Running them early turns compliance from a late verdict into a stream of small, actionable nudges.

Making this practical does not require a heavyweight tool. Even a simple habit helps: at the end of each design session, run the quantitative checks your model supports and glance at the flags. Many BIM environments and checking tools can run a rule-set on demand or on save, so the feedback arrives while the design is still in your hands. The point is frequency and earliness, not sophistication - a rough check often beats a perfect check once.

Two honesties keep shift-left grounded. First, early models are incomplete, so early checks are indicative, not definitive; a 'pass' on a half-built model means little, and you must expect the picture to change. Second, shift-left applies only to the checkable subset - the judgement-laden and performance rules do not move left, because no automation resolves them; they still need the professional, later and throughout. Shift-left is not 'automate compliance early'; it is 'get fast, early feedback on the part that can be run', so the expensive surprises are wrung out long before the authority ever sees the drawings.

Design is a loop: propose, evaluate, revise, repeat. Fitting automated checking into that loop means treating a compliance run as one more source of evaluation alongside structure, cost, daylight, buildability and - above all - design intent. The model changes, the checker flags what it can, the designer weighs the flags with everything else, and the design moves on. Used this way, compliance feedback is a quiet, useful input that keeps the checkable rules satisfied as the design develops.

But there is a real hazard, and it is a hazard of psychology, not technology: letting the checker start to drive the design. When a tool hands you a crisp green tick, it is tempting to optimise for the tick - to shape the plan around whatever most easily passes the encoded rules, and to treat 'no flags' as 'good design'. That is automation bias, and it quietly narrows architecture. The checker only sees the codeable, quantitative slice of what makes a building good. It cannot see whether a space is generous, whether a route is legible, whether light falls well, whether the building belongs to its place. Optimise only for what the checker measures and you will design only what the checker measures.

The discipline is to keep the checker as a guardrail, not a generator. Guardrails stop you leaving the road; they do not choose your destination. A compliance check should confirm that the quantitative constraints are respected and warn you when they are not - and then get out of the way of the actual design decision, which is the designer's synthesis of many concerns the tool knows nothing about. A green tick is a floor, not a ceiling: it says 'no flagged violation in the checkable rules on this data', which is necessary but nowhere near sufficient for a good, compliant, approvable building.

Held this way, the loop is powerful: continuous checking removes the drudgery of remembering every dimension and frees attention for judgement, while the designer stays firmly in charge of the design. The moment the flags start dictating form, the tool has quietly changed from servant to master - and the fix is not a better tool but a clearer head about what compliance checking is for.

Fitting checking into design is as much a matter of habit and honesty as of software. A few practical principles make it work without over-promising.

Start small and quantitative. You do not need a complete rule-set or a perfect model to begin. Pick the handful of parameters that most often cause trouble on your projects - setbacks, coverage, FSI and height in the Indian development-control context, plus corridor widths and egress distances - and get those checking early and often. A narrow check that runs constantly beats a comprehensive check that runs once.

Treat early results as provisional. Because early models are partial and their data is still thin, an early check speaks about the model as it stands, not the building as it will be. Read a pass as 'nothing flagged yet, on incomplete data' and a flag as 'look here', and re-run as the model matures. This is the garbage-in, garbage-out discipline applied to timing: the check is only as good as the data available when it runs, and early data is deliberately incomplete.

Keep the human judgement in the loop from the start. Shift-left moves the checkable feedback earlier; it does not move the judgement-laden and performance rules at all, and it does not move accountability. The professional of record still owns whether the design complies, from concept onward, and the approving authority still owns the decision. Early automated checking simply means fewer of the mechanical issues survive to the point where they are expensive - it does not shrink the human's responsibility, and a clean early run is emphatically not an early approval.

Done with these disciplines, compliance checking becomes what it should be: a background instrument that catches the checkable slips early, keeps the numbers honest as the design grows, and lets the designer spend attention where it matters - on the large questions of quality, meaning and fitness that no rule can encode. The next lesson takes the most concrete, present-day form of this: the designer running the checks on their own model as a deliberate quality-assurance step before submitting to the authority.