DPI Deep Dive — Wednesday | October 14, 2026
Focus layer: L3 — Documents & Data Exchange (DigiLocker, API Setu, eSign and related public data infrastructure)
Coverage period: 7–14 October 2026 (08:30 IST to 08:30 IST)
Executive summary
The week’s signal is not a new DigiLocker feature or published API standard, but a wider view of India’s data-exchange layer: document wallets and service portals for citizens, geospatial data for government planning, and shared sandboxes for AI experimentation. Three official releases and one government explainer published 9–12 October connect these developments.
Display is not deployment. MeitY’s India Mobile Congress pavilion grouped DigiLocker, Entity Locker and API Setu with DPDP messaging, but announced no new integration or technical safeguard. The GatiShakti explainer gave dataset and API counts while leaving questions of freshness, provenance and access open. A science-portal redesign highlighted discoverability; an AI-for-Good workshop proposed interoperable sandboxes. The shift is from digital documents to governed reuse: who may use authoritative records, how errors are corrected, and who is accountable when reuse causes harm.
1. At IMC, MeitY presents the building blocks—but not a new data-exchange promise
A Ministry of Electronics and Information Technology pavilion at the India Mobile Congress (IMC), held 7–10 October in New Delhi, featured Aadhaar, DigiLocker, UMANG and Entity Locker. The same 9 October PIB release described an API Setu booth demonstrating API-based integration and information exchange, a UX4G display on citizen-centred design, and a booth explaining the Digital Personal Data Protection (DPDP) framework.1
This is a useful snapshot of how the government wants the public to understand its stack. Identity, document access, service discovery, organisational records and API interoperability appear as neighbouring pieces rather than isolated apps. The citizen-facing path is easy to imagine: prove who you are, retrieve an issued record, and present it to a service that needs it. But the release is a report of what visitors could see, not evidence that these products were newly connected, or that a particular API was launched. It provides no endpoint, data schema, issuer count, adoption figure or implementation timetable.
That restraint is important. A demonstration can make interoperability legible, but a booth is not an interoperability test. In practice, systems need shared definitions for fields and document status; clear allocation of responsibility between the original issuer and any locker or verifier; and rules for authenticating a request, limiting its scope, recording access and correcting errors. The release’s reference to DPDP is evidence that data protection was part of the display—not evidence that every flow in the showcased services has been assessed against the law or that a person can inspect and contest every downstream use.
The citizen’s question is not only whether a record can be fetched: does the organisation need it, is there an alternative when the network or account fails, and can stale or mismatched records be corrected without a portal maze? A useful next disclosure would show one concrete flow, including roles, permissions, logs and redress.
2. GatiShakti’s data layers show how exchange moves beyond the document wallet
A PIB explainer published on 12 October, marking five years of the PM GatiShakti National Master Plan, described a common GIS-based planning platform spanning 58 central ministries and departments and all 36 States and Union Territories. It reported more than 23,493 data layers as of 12 October and access to 230 approved datasets through the PM GatiShakti Public platform. The explainer says the datasets support tasks such as site-suitability analysis, connectivity mapping, alignment planning and compliance checks.2
It also described two distinct access mechanisms that should not be collapsed into one. Since October 2025, selected non-sensitive datasets have been available to private-sector users through a query-based analytics mechanism. Separately, the Unified Logistics Interface Platform (ULIP) was reported to connect 46 government systems across 12 central ministries through 142 APIs, as of July 2026. The figures come from the government explainer; they are not a live independent audit of every dataset or API.
This is data exchange at planning scale: road, logistics and power projects may need transport, land, utility and environmental layers. A shared geospatial view can expose conflicts early. The explainer says the platform helped revise the Pune–Bengaluru Expressway alignment, reducing forest overlap by 19%—a government-reported outcome, not an independently assessed causal estimate.2
The impressive-looking layer count is not, by itself, a quality measure. It does not tell a planner—or the public—how recently each layer was updated, whether its boundary or classification is complete, which agency is accountable for it, or how a user can flag a wrong feature. Nor does “approved dataset” explain which fields are withheld, the conditions attached to reuse, or what appears in the public interface versus the internal planning environment. Query-based access can be a sensible way to protect sensitive information, but a user still needs to know what is excluded and why.
ULIP’s API total is similarly a measure of connectivity, not necessarily of semantic consistency or dependable service. Forty-six systems may exchange information while using different identifiers, update schedules and definitions. The policy value comes when agencies can trace a decision back to source data, identify the version used, and correct the record that produced a bad result. That is a cross-layer connection: logistics APIs link to commerce and transport, while geospatial data can shape sectoral infrastructure and local land-use outcomes. The governance test is whether the efficiencies of joined-up planning are matched by provenance, correction and public scrutiny.
3. DST’s multilingual portal treats discoverability as part of public information infrastructure
On 9 October, the Department of Science and Technology launched redeveloped websites for DST and the Ministry of Science and Technology. PIB says the portals follow the Digital Brand Identity Manual 3.0 and Guidelines for Indian Government Websites and Apps 3.0, offer information in 22 languages through Bhashini, and provide accessibility options including adjustable text, high contrast and screen-reader compatibility. The stated design includes a structured scheme-and-opportunity finder and a central repository for guidelines, policies, notifications, reports and forms.3
This is not a personal-data exchange system, and it should not be described as one. Its relevance to L3 is the public side of information flow: a document or government programme has little practical value if people cannot locate the authoritative version, understand who qualifies, or use the interface with their language and accessibility needs. A searchable, structured portal can reduce the cost of finding a grant or official notification—especially when the same information is otherwise scattered across divisions and pages.
The announcement also describes a modular content-management system, future integration with external science-and-technology applications, and security measures including TLS, cybersecurity assessments and CERT-In guidance. These are claims in the department’s launch release, not published results of an independent security or accessibility audit. No benchmark for translation quality, task completion, broken-link rates or update latency is provided there. That gap does not negate the redesign; it defines what should be measured after launch.
A practical public-service standard would test more than whether a language selector exists. Are the current application instructions and deadlines available consistently in each language? Do screen readers announce document titles and form controls correctly? Can a visitor distinguish a current notification from an archived one? When the English source changes, how quickly do translated versions follow? These are mundane publishing questions, but they determine whether “digital access” is real. In this sense, Bhashini and the portal’s document repository connect the data-exchange layer to inclusion: data can move between systems and still fail citizens if the public cannot find or interpret the result.
4. The AI-for-Good sandbox puts reusable data on the next infrastructure agenda
A Department of Telecommunications–International Telecommunication Union workshop at IMC on 9 October set out an AI for Good Lab framework with three pillars: readiness and policy, skills development, and public AI infrastructure. The third pillar was described as standards-based, interoperable AI sandbox environments for testing, validating, scaling and reusing locally relevant solutions. The release says India is one of ten pilot countries and will bring a model of shared compute, open datasets and DPI into cross-regional learning.4
This is an adjacent development rather than a new DigiLocker or API Setu service. Its connection to L3 is direct, though: a sandbox that is meant to support reuse needs data that can be accessed under clear terms, with known provenance and enough context to test whether a system works beyond a polished demo. Open datasets, sectoral registries and digital public services could all become inputs, but the PIB release does not specify which datasets, sandbox operators, technical controls, or rules for onward use are in scope. It records a framework and workshop outcome, not a production deployment.
The safeguard question is therefore more specific than “is the AI responsible?” Can a sandbox use synthetic or suitably minimised data where real personal records are unnecessary? Who approves access, retains logs and reviews the results? Can a model be tested for performance across languages and communities before it is allowed to influence a public service? If a prototype is reused, does the next institution inherit the same documentation, limitations and redress arrangements—or only the code?
The event ties several DPI layers together: communications provide connectivity, data exchange supplies inputs, sectoral programmes define high-impact uses, and security and privacy rules set the boundaries. Shared infrastructure may lower the cost of experimentation, but reuse also multiplies the consequences of a bad dataset or hidden assumption. Publishing a sandbox specification and an evaluation protocol would turn the week’s broad promise into something citizens, researchers and public agencies can assess.
Trends and implications
Across these releases, the data layer is expanding in three directions: portable records for people and organisations; joined-up information for government planning; and reusable data for AI experiments. These systems should not be treated as interchangeable. DigiLocker’s issuer-backed documents, API Setu’s service integration, GatiShakti’s GIS layers and an AI sandbox have different users, legal bases and failure modes. Their common requirement is accountable exchange: a named source, a defined purpose, bounded access, traceable reuse and a route to correction.
A convenient interface can make data look more authoritative than it is. An API response may be stale; a document can preserve an issuer’s error; a map can omit unrecorded realities; a model can reproduce those defects at scale. Judge interoperability not by connection counts alone, but by whether providers remain accountable and people can challenge resulting decisions.
What to watch
The 7–14 October sources announce showcases, a platform explainer, a website relaunch and a workshop framework—not a new national API specification or DigiLocker/eSign rollout. Watch for technical documentation and version histories, dataset update dates and source ownership, API availability, query-access conditions, privacy/security assessments, and usable correction routes. These are accountability checks, not government-announced deadlines.