The Approval Process

To see what automation changes, first picture the approval process as it actually is. When a design is submitted for permission, it enters plan-scrutiny: an examiner at the approving authority - and often several, across departments such as planning, fire and structural - reviews the drawings and documents against the applicable regulations and decides whether the design may be built. In the Indian context this typically means a municipal or development authority checking against the local building byelaws and development-control regulations, with fire and other clearances handled by their respective authorities, and the National Building Code and IS standards in the background.

What does the examiner do? Partly, mechanical checking: reading off dimensions and comparing them to the byelaw - are the setbacks met, is the ground coverage within limit, is the floor-space index and height within bounds, are corridor widths and travel distances adequate, are required provisions present. This is the same quantitative comparison a designer does when self-checking, run from the outside. But the examiner also does something more: they interpret. They decide which rules apply to this building and this plot, how ambiguous provisions should be read, how conflicting requirements reconcile, whether a discretionary allowance is warranted, and whether the design meets the intent of rules that are not reducible to a number. And they carry authority: their decision, within the powers granted to them, is what makes the permission legally real.

This process has well-known strains, which are precisely the ones automation is offered to relieve. It can be slow - queues of submissions, multiple departments, back-and-forth over objections, all measured in weeks or months. It can be inconsistent - two examiners, or the same examiner on two days, may read the same discretionary rule differently. It can be error-prone - a missed clause in a large submission. And, honestly, in some contexts it carries discretion that shades into arbitrariness, where outcomes depend too much on who reviews and how. Understanding these strains is important, because they explain both the genuine appeal of automating parts of scrutiny and the reason automation cannot simply replace it: the mechanical strains are automatable, but the interpretive judgement and the statutory authority at the heart of the process are not.

Set against that picture, what automation does becomes clear and bounded. It changes the mechanical layer of scrutiny, and it leaves the interpretive and statutory core untouched.

What it genuinely changes: speed, on the quantitative parameters, an automated pre-scan can verify setbacks, coverage, floor-space index, height, widths and distances in seconds rather than hours, clearing the routine checks so human examiners spend their time on what needs judgement. Consistency: the same rule is applied the same way to every submission, reducing the day-to-day and examiner-to-examiner variation that makes approval feel arbitrary. Completeness: an automated check does not tire or skip, so fewer clauses in the checkable set are simply missed. Transparency: when the checkable parameters are scrutinised by an explicit, published rule-set, applicants can see the criteria and even self-check against them beforehand, which reduces surprise objections and, at its best, curbs the discretion that shades into arbitrariness. These are real improvements, and they map exactly onto the strains of manual scrutiny.

What it does not change is everything that makes scrutiny more than parameter-matching. It does not perform the interpretation - deciding which rules apply, reading ambiguous provisions, reconciling conflicts, weighing whether a design meets the intent behind a rule. It does not evaluate the performance rules that need engineering analysis, or the facts not in the model. And, decisively, it does not confer approval: automation can inform and accelerate the authority's decision, but the decision remains the authority's to make, within its statutory powers. A green result from the authority's own automated scrutiny is an input to approval, not the approval itself.

The honest summary is that automation moves the routine, quantitative work off the examiner's desk - a genuine gain in speed, consistency and completeness - while leaving the judgement and the authority exactly where they were. This is why the mature framing is 'semi-automated scrutiny': the machine handles the checkable parameters and flags the rest for human review, and the human retains interpretation and the decision. Anyone promising that automation will replace plan-scrutiny wholesale is either misunderstanding what scrutiny is or overselling what checking can do.

The most important single point in this lesson is a boundary that must never blur: approval is granted by the authority, never by the software. It is worth stating plainly and holding firmly, because the entire honesty of automated compliance rests on it.

An automated check - whether run by the designer as a self-check or by the authority as part of scrutiny - produces a result: pass, fail, or undetermined, on the encoded rules it could evaluate against the data it was given. That result is information. Approval is something else entirely: it is a statutory decision by an accountable body, exercised within legal powers, that permits a building to be constructed. No amount of green ticks adds up to that decision; only the authority can make it. The checking engine has no legal standing, carries no accountability, and cannot be held responsible for an outcome - which is exactly why it cannot be the thing that approves.

This boundary holds even in the most automated systems imaginable. Suppose an authority ran fully automated scrutiny of every checkable parameter and issued a permit on a clean result. Even then, the approval would be the authority's act - the authority has chosen to delegate a decision to a rule-set it owns and is accountable for, and it remains answerable for the outcome, the correctness of the encoded rules, and everything the automation could not check. The software is the instrument; the authority is the decider and the responsible party. The moment we imagine the software itself 'approving', we have lost the thread of who is accountable when the encoded rule was wrong, the data was bad, or a judgement-laden requirement was quietly ignored.

For the designer, the practical consequence is a discipline of language and expectation. Never tell a client that a design is 'approved' because a check passed, or that a self-check has 'cleared' the building. A check has prepared the submission; the authority approves it. Whether the design actually complies, the authoritative interpretation of any rule, and the legal permission to build all rest with the qualified professional of record, the approving authority and the governing law - the National Building Code, the local byelaws and development-control regulations, and the applicable IS standards - never with the checking tool, whose encoded rule is only ever a fallible copy of the real one.

Pulling the threads together, the approval process is best understood as a chain of accountable humans and institutions, with automation running alongside as an instrument that informs them but bears none of the responsibility. Being clear about who is accountable for what is the whole point.

The qualified professional of record - the architect or engineer who signs the submission - is accountable for the design and its compliance: for exercising professional judgement, for the parts of regulation that cannot be coded, and for not hiding behind a green tick. A self-check helps them find mechanical issues, but it does not transfer their responsibility to a tool. The approving authority is accountable for the scrutiny and the decision: for interpreting the rules, for exercising discretion lawfully, and for granting or refusing permission - and where it uses automation, for the correctness of the rule-set it relies on and for everything the automation did not check. The law itself - the byelaw, the development-control regulation, the National Building Code, the IS standard - is the authoritative rule, and the encoded version used by any tool is only a copy that may be wrong or out of date. The checking software sits below all three: a fast, tireless, consistent instrument for the checkable parameters, with no judgement, no authority and no accountability of its own.

This chain is what keeps automated compliance honest at the gate. Automation can make the routine scrutiny faster, more consistent and more complete, and it can make the criteria more transparent so applicants know what they are being judged against - all real gains, and especially valuable in a context like India's where speeding and de-arbitrariness of approvals is a genuine public good. But it augments the accountable humans; it never replaces them. The professional still owns the design, the authority still owns the decision, and the law is still the rule. Keep that chain clear and automation is a powerful ally at the approval stage. Blur it - let the tool seem to interpret, or approve, or carry the responsibility - and you have built exactly the dangerous illusion this course exists to dispel. The next lesson looks at the frontier where authorities push automation furthest - automated and semi-automated permitting - and holds it to the same honest standard.