Self-Checking Before Submission

Strip away the hype about automatic permits and city-scale digital twins, and the use of automated compliance that is genuinely, widely useful to a practising designer today is the simplest one: running the checks on your own model, yourself, before you submit. It is unglamorous, and it is where the value is real and present.

The reason it matters is the shape of the submission cycle. When a design goes to the approving authority with mechanical errors still in it - an under-width corridor, an escape route a few metres too long, a setback encroached, a required count short - those errors come back as objections, often after a wait of weeks. The design is then reworked under deadline pressure, resubmitted, and the clock starts again. Every avoidable objection is a full round-trip of delay and cost, and many of these objections are for exactly the kind of clear, quantitative issue an automated check finds in seconds.

Self-checking closes that gap. Before the drawings leave your office, you point a checking tool at your structured model and let it evaluate the quantitative rules - widths, travel distances, ramp slopes, setbacks, coverage, floor-space index, height, required counts. The flags come back privately, while the issues are still yours to fix cheaply, and you correct them before anyone at the authority ever sees them. The submission that goes out is cleaner, the objections that come back are fewer, and the whole cycle shortens.

Crucially, this is available now and does not depend on the authority having any automation at all. It works even where approval is entirely manual and discretionary, because it is something you do to your own model on your own side of the fence. In the Indian context - where plan-scrutiny centres on precisely the quantitative development-control parameters that automate well, and where approval queues are a real cost - self-checking those parameters before submission is one of the most immediately worthwhile things automated compliance offers. It is not the future of permitting; it is the present of good practice, and it asks only that you check the checkable before you ask someone else to.

The single most important thing to be clear about is what a self-check is and is not. It is quality assurance - a private step you take to raise the quality of your own submission - and it is not, in any sense, an approval. Blurring that line is where self-checking goes wrong.

Quality assurance is a familiar idea in every serious discipline: before you hand work to someone who will judge it, you check it yourself against the standards you can, to catch your own mistakes. A pre-submission compliance check is exactly this, applied to the codeable rules. It is you auditing your own model so that fewer errors survive to the authority. Like any QA step, it improves the odds of a clean review; it does not replace the review, and it carries no authority of its own.

The distinction has teeth. When your self-check comes back clean, it means only that the encoded rules your tool could evaluate found no flaggable issue in the data you gave it. It does not mean the design complies, and it certainly does not mean it is approved. The encoded rule might be wrong or out of date; your model data might be incomplete or mis-classified; the judgement-laden and performance rules are untouched; and, decisively, the authority has not yet looked at it and is the only party that can grant a permit. A green self-check is a well-prepared submission, not a decided one.

This is why the framing matters so much in practice. A designer who treats a clean self-check as 'we are compliant' is setting up both false confidence and, potentially, a hard conversation with a client when the authority raises objections the tool never considered. A designer who treats it as 'we have removed the mechanical issues we could find, and now the real review begins' has it right. The self-check reduces the rejections and rework caused by avoidable, checkable errors - a genuine and valuable effect - while leaving the determination of compliance and the grant of approval exactly where they belong: with the qualified professional of record, the approving authority, and the governing code. QA on your side; approval on theirs; never the two confused.

The concrete payoff of self-checking is fewer objections and fewer round-trips, and it is worth being precise about how that payoff arises, because it explains both the value and the limits.

A large share of the objections that come back from plan-scrutiny are for clear, quantitative reasons: a dimension below a minimum, a distance above a maximum, a ratio out of bounds, a count short. These are exactly the issues an automated check catches reliably, because they are unambiguous comparisons against numbers in the model. Every one of them that you catch and fix before submission is one fewer objection, one fewer rework cycle, one fewer multi-week wait. Across a project, and across a practice, that compounds into real savings of time, cost and the relationship with the authority - reviewers who receive consistently clean submissions spend less effort on avoidable defects.

There is a quieter benefit too: consistency. Manual self-checking is patchy - a tired professional at the end of a long project will not re-verify every corridor width and every travel distance by hand, and some slips get through. An automated self-check runs the same way every time, tireless and complete over the rules it encodes, so the mechanical defects that depend only on model data are caught systematically rather than by luck. This is the same consistency advantage the whole field offers, harnessed privately for your own QA.

But the limits are the same too, and honesty requires stating them. Self-checking reduces the rejections caused by checkable errors; it does nothing about objections that arise from judgement, interpretation, missing information, or the authority reading a discretionary rule differently than you did. It cannot promise a first-time approval, because much of what an authority weighs is outside the codeable subset. And it is only as good as your model data - a check on a model where rooms are mis-classified or widths are wrong will happily pass real violations or flag phantom ones. So the accurate claim is specific and defensible: self-checking systematically removes the avoidable, quantitative defects that cause a meaningful share of rejections and rework, shortening the cycle - while the judgement-laden objections, and the decision itself, remain with the humans and the authority.

To use self-checking well you must hold a clear, honest map of its reach - what it reliably catches, and the several distinct ways it can miss - because over-trusting a clean run is how a self-check causes harm rather than good.

What it catches is the checkable subset, and catches it well: under-width corridors and doors, over-long travel distances to exits, ramps too steep, setbacks and coverage and floor-space-index and height breaches, missing required counts of fixtures or exits. Wherever a rule is a clear comparison against a number that the model actually carries, an automated self-check finds the violation fast, consistently and completely. That is a real and valuable reach.

Now the ways it misses, which matter more. First, the rule may be encoded wrongly or be out of date - the tool checks its version of the rule, not the actual byelaw, so a mis-encoded or stale rule gives a confident wrong answer. Second, the data may be bad: garbage in, garbage out means a mis-classified room, a missing property or a wrong dimension makes the check meaningless, silently passing real violations or raising false ones. Third, whole categories of rule are simply out of scope - the judgement-laden terms ('adequate', 'suitable', 'reasonable'), the performance clauses that need engineering analysis, the facts not in the model, and the interpretive question of which rule even applies. A self-check touches none of these. Fourth, and underneath all of them, is the human hazard of automation bias: reading a clean run as 'we are fine' and relaxing the scrutiny that the uncheckable rules still demand.

The disciplined stance follows directly. Run the self-check for what it is genuinely good at - removing the avoidable, quantitative defects before submission - and read a clean result narrowly: 'the encoded checkable rules found nothing on this data', no more. Keep checking the encoding against the real code, keep the model data honest, and keep the judgement-laden work firmly with the professionals. Held this way, self-checking is the most useful, most practical tool in the whole field today - a private QA step that quietly shortens the submission cycle - precisely because you never mistake it for the approval it is not. Next we follow the drawings across the fence, into the formal approval process itself.