Masterplanning with Computation

Start with what a masterplan really is, because the word is used loosely. A masterplan is not a building design blown up to city size; it is a long-range spatial framework - a set of decisions about structure that will outlast the people who make it. It fixes the arterial and local street network, the pattern of blocks and plots, the distribution of densities and building heights, the location and size of open space and civic amenity, the mix and zoning of land uses, and the phasing by which all of it is built. In India this framework is a statutory instrument - a development plan or master plan prepared by a development authority under state town-planning law - and it is given teeth by the applicable development-control regulations (DCR) and the National Building Code of India, which translate the plan's intent into buildable rules.

Computation touches this framework at specific, bounded points, not everywhere. It is powerful in the analysis and exploration phase: reading the site and its context from data, generating and comparing structural options, testing how a proposed network or density performs, checking a scheme against the rules. It is genuinely weak - and must stay out - at the point of binding choice: deciding whose land is rezoned, which community bears a cost, what a place is *for*. The mistake that ruins computational masterplanning is collapsing those two phases, letting the tool that was good for exploration silently make the choices that belong to people.

So the correct mental model is a layer, not a throne. Underneath sits the political and statutory reality: an authority, a public, a body of law, a set of affected communities. On top of it, computation is an evidence-and-exploration layer that makes that human process better informed - faster at seeing consequences, wider in the options it can weigh, more consistent in applying rules. A masterplan made this way is still a human masterplan; computation has simply given its authors sharper eyes. The danger begins the moment the layer is mistaken for the plan itself - the moment a beautifully rendered generative output is treated not as one studied option among many but as *the answer*, and the deliberation, negotiation and democratic sanction that should surround it are quietly skipped because 'the model has already worked it out'.

Be concrete about what computation actually does well in a masterplan, because vague enthusiasm is how the trap is sprung. There are three genuine jobs.

Informing options. Faced with a large site, a team can use parametric and generative methods to produce and compare many structural options - different street grids, block sizes, density distributions, open-space networks - far more than a hand could draw, each analysed the same way. This is real value: it widens the field of what gets considered before a direction is chosen, surfaces configurations no one would have thought to sketch, and lets a team argue from a studied set rather than a favourite. The discipline is that these are *options to inform a human choice*, not a ranked list whose top row is the decision.

Testing scenarios. Once a direction exists, computation lets you ask what-if rigorously. What if density rose toward the transit corridor? What if the plan were built in three phases instead of one? What if car use fell and the road reservation shrank? A parametric model re-forms the whole plan as you turn each knob, and analysis shows the consequence for daylight, walking distances, network connectivity or cost. Scenario testing is perhaps the single most defensible use of computation in masterplanning, because it keeps the human firmly in the loop asking the questions while the machine handles the consequences.

Coordinating rules. A masterplan carries thousands of interacting constraints - setbacks, road widths, FAR limits, ground coverage, fire access, the DCR line by line. As the plan changes, keeping all of them consistent by hand is error-prone and slow. Computation can hold the rule set and flag where a proposal breaks it, so the team spends its judgement on design rather than book-keeping. This is humble, unglamorous and hugely valuable - and notice it is fundamentally a *checking and consistency* role, not a design-authorship one.

Across all three, the pattern is the same: computation is strongest where the work is exploration, consequence-tracking and consistency, and it earns its place there. What it must never do is convert that strength into authority over the choices - of value, equity and public purpose - that these three jobs only ever *inform*.

Now the shadow, and it is a long one. The deepest failure in the history of planning is the technocratic grand plan: the conviction that a sufficiently expert authority, working from above with the best available tools, can conceive a whole city rationally and impose it on the ground for people's own good. The twentieth century ran this experiment repeatedly - the modernist superblock, the cleared and rebuilt quarter, and in India the planned capital of Chandigarh, magnificent in conception and, at street level, often at odds with how Indian urban life actually works. The lesson urbanism drew, painfully, was that a city conceived whole by expert reason and imposed from above tends to be rigid, exclusionary and blind to the fine-grained, unplanned, informal life that makes cities live.

Computational masterplanning is a spectacularly efficient new way to make exactly this mistake - and worse, to hide it. The old grand plan at least announced itself as one authority's vision, contestable as such. A generative masterplan wraps the same imposition in the language of data and optimization, so the political choice inside it - this density, this displacement, this idea of who the city is for - is presented as a neutral technical output. 'The algorithm says' becomes the most effective way yet invented to launder a contestable decision as an objective one. The optimization trap does the rest: the model optimizes the measurable - density, cost, travel time, a walkability score - and quietly sacrifices the unmeasurable community, memory and mixture that no metric holds, producing a plan that scores beautifully and would be desolate to live in.

In India the danger is acute for a specific reason: a vast share of the real city is informal and organic - the dense old quarter, the settlement that houses millions - and this fabric rarely fits a model's tidy categories of plot, use and road. A naive generative masterplan can therefore literally *not see* it, treating occupied, living, load-bearing urban fabric as empty land to be optimized, and 'clearing' on paper what is in truth people's homes and livelihoods. The plan will look clean, rational and efficient. It will also erase the most vulnerable city there is, and do it with a clear technical conscience. That is the failure this lesson exists to name.

What does it look like to use computation in masterplanning well? The governing idea is a strict separation between *exploring* and *deciding*, held for the whole project. Computation lives entirely on the exploring side. It reads the site, generates and analyses options, tests scenarios, coordinates rules, and - crucially - makes its assumptions and its blind spots legible, so the human process can weigh them. The deciding side stays entirely human, political and democratic: which option, at what cost to whom, serving what public purpose, is settled by the planning authority through the statutory and participatory process, answerable to the affected communities and bound by law.

Several habits keep that separation honest. Treat every computational output as *one studied option, not the answer* - always carry a set, never a single winner, so the choice visibly remains open. State what the model optimized for and, explicitly, what it could not see - the informal city, the intangible qualities, the equity questions - so no one mistakes a partial metric for the whole good. Never let a render's polish substitute for scrutiny; a photorealistic generative masterplan is an argument dressed as a fact, and deserves harder questioning, not less. And keep the affected people in the room from the start, not shown a finished plan at the end - the subject of the next lesson.

In the Indian statutory frame this means computation feeds, but never replaces, the master-plan or development-plan process: it can strengthen the evidence base a development authority works from, sharpen the options put to public objection and consultation, and check schemes against the DCR and NBC - while the sanctioning of the plan remains a legal and political act of the authority and the democratic process, not an output of the model. Binding decisions about land use, rezoning, displacement and equity are deferred, without exception, to that authority, that process, those communities and that law.

Hold this and computation becomes what it should be in masterplanning: a way to make a difficult human undertaking better informed, more transparent and more rigorously explored - a sharper set of eyes for the planners, the public and the authority who must still, together, decide. Forget it, and the same tool becomes the most efficient machine ever built for imposing an abstract order on a living city and calling the imposition science.