Rules as Code in India

The most visible momentum in Indian rules-as-code is the shift of building approval online. Over the past decade many states and cities have moved building-permission from a physical, file-based process toward online building-permission systems and single-window portals, where an applicant submits drawings and documents digitally, the application is routed to the relevant departments, and the status is tracked through the system rather than through corridors. This is part of a broader e-governance and Digital India push, and it is driven hard by an ease-of-doing-business agenda in which the time and predictability of construction permits is a headline metric. The direction of travel is real and substantial: approval is becoming more digital, more trackable, and in intent more time-bound.

Some of these systems go further than digitising paperwork - they attempt automated or semi-automated scrutiny of the submitted drawings against the byelaw parameters. Where implemented, software reads the submitted plan and checks quantitative development-control rules - setbacks, ground coverage, floor-space index, height, plot-size and road-width conditions - flagging where the design breaches them, so a human scrutiny officer starts from a machine-generated report rather than measuring by hand. This is genuine automated compliance in the Indian context, applied to exactly the rules for which it works best. It promises faster, more consistent scrutiny and less scope for arbitrary variation on the quantitative parameters.

But hold the honest boundary from the start. Digitising the process is not the same as automating the judgement, and an online portal that routes and tracks an application is a workflow improvement, not a compliance engine - the two are easy to conflate. Even where automated scrutiny of quantitative parameters runs, it covers the checkable subset and hands the rest, and the decision, to human officers. And crucially, a portal accepting a submission or a scrutiny module reporting no breach is not an approval: the authority grants approval, on the authoritative rule, which is the actual byelaw and the National Building Code as the authority interprets them. The momentum is real and worth understanding precisely - online permission, single-window routing, automated parameter scrutiny - but each of these is a step in a still-human, still-accountable process, not its replacement.

There is a deep, fortunate match between how Indian plan-scrutiny actually works and what automated compliance is good at - and understanding it is the key to a realistic Indian view. Indian development-control regulations centre on a handful of quantitative parameters that must hold for almost every building: setbacks (the minimum distances the building must keep from each plot boundary), ground coverage (the maximum share of the plot the footprint may occupy), floor-space index or FAR (the maximum ratio of total built floor area to plot area), height limits (often tied to the abutting road width and the zone), and plot and road conditions. These are the parameters a scrutiny officer measures on nearly every submission, and they are, without exception, clear numeric rules - a measured value compared against a threshold set by the byelaw for that plot and zone.

That is precisely the checkable kind. A setback is a distance to compare; coverage is an area ratio to compute and compare; FSI is a floor-area ratio to compute and compare; a height limit is a number to compare. None requires interpretation of a judgement-laden term or an engineering performance analysis - they require correct measurement and correct application of the right threshold. So the very rules that dominate Indian plan-scrutiny are the ones automation runs fast, consistently and reliably, given correct data. This is why automated scrutiny in Indian permission systems concentrates on exactly these parameters, and why the fit is genuine rather than hype: the workload of Indian scrutiny is heavily weighted toward the quantitative development-control checks, and that workload is squarely inside the checkable subset.

The honest caveats stay attached even here. The checks are only as good as the data: if the plot boundary, footprint or floor areas fed to the system are wrong or mis-measured, the parameter checks are wrong - garbage in, garbage out applies fully. Selecting the right threshold is itself an act of interpretation - which zone, which use, which byelaw provision governs this plot - and getting that wrong makes a correct calculation check against the wrong number. And these quantitative checks, however well automated, are a subset: fire, structure, services, accessibility and the judgement-laden provisions of the byelaw and NBC remain, much of it human. Still, the match is the most important fact about rules-as-code in India: its plan-scrutiny leans on exactly the rules automation checks best, which is why the momentum has real substance and a real place to land.

A rooted view of rules-as-code in India must give the obstacles their full weight, because they are as real as the momentum. First, much of building approval in India remains manual and, honestly, discretionary. Even where portals exist, significant parts of the process depend on human officers exercising interpretation - and, in places, on informal practice that formal digitisation does not automatically dissolve. Automating the quantitative parameter checks narrows the room for arbitrary variation on those parameters, which is a real gain, but it does not by itself transform a discretionary culture into a rule-bound one. That is a governance and reform question, not a software feature.

Second, byelaws vary enormously. India has thousands of urban local bodies, and building byelaws and development-control regulations differ across states, cities and even categories of area, each updated on its own schedule. There is no single national rulebook to encode: the National Building Code is a recommendatory model code that states and local bodies adopt and adapt, and the binding development-control rules are local. So encoding rules-as-code for India is not one task but thousands, and keeping any encoded rule-set current and correct against a shifting, fragmented body of local law is a large and continuing governance burden - a stale encoded rule that no longer matches the amended byelaw is worse than none, because it misleads while looking authoritative.

Third, the structured data is often missing. Rich automated checking wants a structured, machine-readable model in which elements carry meaning; a great many Indian submissions are still 2D drawings, not BIM models. Automated scrutiny systems that work from 2D submissions can extract and check the quantitative parameters, but they cannot check what a 2D drawing does not carry, and the deeper model-based checking that the rest of this course describes is not available without the structured model. Fourth, the judgement-laden and performance parts of Indian regulation resist coding exactly as they do everywhere - 'adequate', 'suitable', structural performance, which provision applies - and no Indian system resolves them automatically. Naming these realities is not pessimism; it is the accuracy a compliance-literate Indian designer needs to see the field clearly rather than through a brochure.

Put the momentum and the limits together and a clear, hopeful, non-hype path appears - one worth an Indian designer's confidence precisely because it is honest. Rules-as-code in India is most immediately and genuinely real for the quantitative development-control checks that plan-scrutiny already centres on: setbacks, coverage, floor-space index and height. These are being automated within online permission and single-window systems, driven by a real ease-of-doing-business push, and the fit is authentic because these are the checkable rules. For a designer, the practical consequence is concrete and available now: structure your submissions well, self-check exactly these quantitative parameters against the applicable local byelaw before you submit, and you will catch the breaches that would otherwise return your file - working with the grain of where Indian automation is heading.

The hope is warranted but bounded. Automated scrutiny of the quantitative parameters can make approval faster, more consistent and less arbitrary on those parameters - a real public good in a system where predictability and time have been genuine pain points. Approval digitisation is likely to deepen, more scrutiny modules to appear, and structured submissions to grow slowly as BIM adoption rises. But this will augment, not replace, the professional and the authority: it depends on better structured data than most projects currently produce, on the enormous governance work of keeping thousands of local byelaws correctly encoded and current, and on reform of the discretionary and manual parts that software alone does not touch. And the boundary never moves: the authoritative rule in India is always the actual byelaw and the National Building Code as the authority interprets them, never the encoded version; an automated scrutiny 'no breach' is not an approval; and binding compliance, interpretation and legal responsibility stay with the qualified professional of record, the approving authority and the governing law. Held this way, rules-as-code in India is neither a revolution nor a mirage - it is a real, growing tool, strongest exactly where Indian scrutiny is most quantitative, that a compliance-literate designer can use today while respecting everything it does not yet do.