There is a tendency to frame the next phase of artificial intelligence in India as a model problem: which model is more capable, how much compute we have, whether we can build sovereign LLMs, and how quickly AI can be deployed across government and enterprise.
But implementation is revealing a more fundamental constraint.
AI can only reason over the India that our data describes. And the India described by our foundational datasets is often very different from the India that exists on the ground.
This is particularly visible in urban systems. Before an AI system can predict, recommend or automate anything useful, it has to answer deceptively basic questions: What is this place? Where exactly is it? Is the “Sector 68” in one database the same location as the “Sec-68, SAS Nagar” in another? Does this property correspond to this utility connection? Is this road segment still where the map says it is?
These are not edge cases. They are the foundation on which everything else has to operate.
The problem underneath the AI problem
Over the course of working with urban datasets, we have tried approaching this problem from several directions.
The obvious starting point was existing geospatial data. In theory, this should provide the common spatial layer against which other government information can be organised. In practice, many datasets are noisy, incomplete or substantially out of date. In some cases, the underlying information has not been systematically updated for years, occasionally decades.
A city, meanwhile, does not wait for its map to catch up.
Roads change. Settlements expand. Properties are subdivided. Informal addresses become formal ones. New landmarks appear and old ones disappear. Administrative boundaries and naming conventions evolve.
The second approach was to work with management information systems already being used by government departments. These datasets are often much more current, but they were built for a different purpose. An MIS is generally designed to record transactions: a grievance was filed, a bill was generated, a connection was issued, a payment was received.
It knows what happened. It does not necessarily know where it happened with sufficient spatial precision.
Worse, the same entity may be represented differently across systems. The address in a grievance database may not correspond neatly to the address in a property database, which may not correspond to the representation of that location on a GIS layer.
So we tried a third approach: triangulation. Could utility databases, property records, transaction systems and other administrative datasets collectively tell us where something was, even when no single database contained a reliable location?
Conceptually, yes. Practically, this proved much harder.
The datasets are siloed not merely institutionally, but structurally. Different identifiers, spellings, abbreviations, administrative hierarchies and update cycles mean that records which describe the same physical place frequently do not align sufficiently to be joined deterministically.
India has enormous amounts of data. What it often lacks is correspondence between data.
What happens when AI meets an Indian address?
Addressing makes this problem unusually tangible.
We have been experimenting with geocoding and reverse geocoding using Google APIs, combined with substantial preprocessing of the underlying data. Raw address strings first have to be denoised and parsed. We have built LLM-based parsers to interpret inconsistent address structures, expand or reconcile abbreviations, separate landmarks from localities and turn semi-structured text into something a geocoder has a reasonable chance of understanding.
In relatively structured urban environments such as Mohali, this works surprisingly well.
But move to a city such as Amritsar—or into less formally structured neighbourhoods—and performance deteriorates quickly.
The reason is important.
An address is not merely a coordinate written badly. Indian addresses frequently encode a local understanding of place: a colony, a chowk, a market, a religious institution, a shop, a person’s name, a lane known by convention, or a landmark that may never have existed in an authoritative spatial database.
To a resident or a delivery driver, the location may be perfectly intelligible.
To a conventional geocoder, it may barely exist.
Perhaps the ground should teach the map
Some of the most interesting addressing infrastructure in India today does not begin with an authoritative map. It begins with repeated successful interactions with the physical world.
Delivery and logistics systems operate in precisely this environment. They encounter hyper-local addresses continuously. A driver finds a location. A delivery succeeds or fails. Landmarks and access patterns are encountered repeatedly. Over millions of transactions, a usable representation of the city can emerge from the bottom up.
In less structured environments, this approach can work substantially better than assuming that a clean foundational spatial database already exists.
That distinction matters for AI.
The traditional model of digitisation was:
First create a clean canonical database. Then build applications on top of it.
But AI potentially allows a different model:
Observe messy reality continuously, use multiple signals to interpret it, establish confidence through repeated interactions, and progressively construct the canonical layer.
The data layer stops being a static prerequisite for intelligence. Intelligence becomes part of the process by which the data layer itself is created.
Chennai shows both the solution and the problem
There are Indian examples of addressing becoming substantially more structured. Chennai is instructive precisely because getting there required sustained effort over many years: standardising, reconciling and progressively cleaning the representation of addresses and urban locations.
Historically, that was what solving a foundational-data problem looked like. Institutions painstakingly created order first; digital systems benefited later.
But India cannot reasonably wait two decades for every city to undertake the same exercise before deploying intelligent systems.
Nor should it have to.
The technological shift is that we now have tools capable of interpreting ambiguity rather than merely rejecting it. An LLM can recognise that two badly formatted addresses probably describe the same place. A computer-vision system can recognise a building or road from imagery. A delivery record can provide evidence that an address resolves to a particular area. Utility connections, property records, grievances, satellite imagery, street imagery and human interactions can each contribute weak signals.
Individually, none may constitute ground truth.
Collectively, they can begin to create it.
India needs data drivers, not just data platforms
This may be one of the more important distinctions for the next generation of Indian AI infrastructure. We tend to talk about data platforms: repositories into which GIS layers, MIS databases, sensor feeds and departmental datasets can be integrated.
Integration is necessary, but it is not sufficient.
Putting five inconsistent datasets in the same data lake does not make them consistent.
What India needs alongside these platforms are data drivers. These are systems capable of continuously interpreting, reconciling and improving foundational data using evidence from multiple sources.
A data driver should be able to say:
These three records probably refer to the same property. This address is likely located here. This GIS feature appears stale. This utility connection provides another signal. This delivery interaction increases our confidence. This satellite observation contradicts the existing map. A human should verify this particular case.
In other words, the system should not assume the existence of perfect ground truth. It should produce increasingly reliable ground truth as a consequence of use.
That is a very different architectural philosophy.
It means confidence scores rather than false certainty. Provenance rather than silent overwriting. Multiple competing observations rather than a single supposedly authoritative database. Human verification where uncertainty remains high. And continuous updating rather than periodic data-cleaning exercises.
The Indian AI stack may have to begin below the model
This has implications far beyond addressing. The same problem appears in properties, roads, water networks, municipal assets, grievances, environmental monitoring and almost every other domain in which AI is expected to interact with the physical world.
A sophisticated model sitting on top of a poorly resolved representation of reality will produce sophisticated answers to the wrong questions.
That is why India’s AI challenge cannot be reduced to building better models.
At the application layer, we need agents and intelligent workflows. At the model layer, we need language, vision and reasoning capabilities. But beneath both sits something less glamorous and arguably more consequential: the machinery that continuously converts India’s noisy physical and administrative reality into machine-readable context.
For countries with mature, frequently updated foundational datasets, this layer can sometimes be taken for granted.
India does not have that luxury.
But that constraint may ultimately become an advantage.
If we can build systems that reason through noisy, contradictory and incomplete data—systems that become better representations of reality through every transaction—we will have built the infrastructure that allows AI to understand India.
And that may be the real foundational model India needs.