UAI Execution Blueprint

What this page is. The strategic execution blueprint for the Unified AI Interface (UAI) — “The UPI for AI.” It sets out the vision, the value proposition for each stakeholder, the trust architecture at a conceptual level, the governance model, the market-driven compute strategy, and the pilot rollout plan.

Relationship to the engineering docs. This blueprint is the normative strategic source. Section 4 below summarises the trust architecture; the engineering High-Level Design and the per-service Low-Level Designs build the implementation on top of it.

Unified AI Interface (UAI)

Unified AI Interface — India’s Protocol Infrastructure for AI Interoperability.

The UPI for AI: following the UPI model of open standards, government rails, and market innovation.

1. The Vision

India’s ambitious IndiaAI Mission envisions a comprehensive AI ecosystem to drive inclusive growth and sector-wide transformation. The Unified AI Interface (UAI) is conceived as India’s next Digital Public Infrastructure (DPI), designed to do for Intelligence what UPI did for Payments.

Historically, AI adoption in government and enterprise has been hampered by silos. Ministries build isolated chatbots, startups struggle to access public datasets, and citizens are forced to navigate fragmented applications. The UAI creates a unified, interoperable network that connects these islands.

Instead of building a monolithic “Super App” or a central “Government AI Cloud,” UAI adopts a decentralized architecture. It functions as a Digital Notary: a thin, invisible layer that enables any application (Seeker) to discover and securely transact with any AI model or data source (Provider).

1.1 Core Philosophy

• Unbundled: Intelligence is separated from the application. A chatbot in Andhra Pradesh can use a translation model from Chennai and a soil database from Delhi instantly.
• Market-Driven: The government does not run the compute or models; it creates the marketplace where private innovation competes to serve public needs.
• Privacy-First: The architecture enforces “Accountability without Surveillance.” The network validates the authority to access data without seeing the content of the data.
• UX Sovereignty: The UAI defines the protocol, not the product. Citizen and enterprise UX/workflows are owned entirely by market participants, ensuring that the government builds the rails while the private sector innovates on the experience.

1.2 The UPI Parallel: A Conceptual Map

To understand the UAI’s role, it is helpful to map its components directly to the UPI ecosystem.

2. What is the Unified AI Interface (UAI)?

Technically, the UAI is not a “platform” or a “server” in the traditional sense; it is a Protocol and a Trust Network. It serves as the digital rail that allows independent AI agents to talk to one another.

2.1 The “Internet of Agents” Architecture

Just as the internet (HTTP) allows any browser to talk to any website, the UAI allows any Seeker Agent (e.g., a WhatsApp bot) to talk to any Provider Agent (e.g., a Database or LLM) without custom integration.

• Decoupled Control & Data Planes:
  • The Control Plane (The UAI’s Job): The UAI manages discovery (“Who has soil data?”), identity (“Is this really the Agri Ministry?”), and authorization (“Is this user allowed to see this?”).
  • The Data Plane (The Market’s Job): The actual query (“What is the pH of my soil?”) and the response flow directly peer-to-peer between the Seeker and the Provider. The UAI does not see, store, or process this data payload.

2.2 Core Technical Primitives

The system is built on three cryptographic primitives that replace the need for a central middleman:

1. Decentralized Identifiers (DIDs): Every agent on the network is assigned a unique, verifiable identity (like a digital passport), using the did:webvh method. Each agent publishes a hash-chained, signed history of its DID document, so past signatures can be verified even after keys rotate. This ensures that a “Fake Customer Care Bot” cannot impersonate the State Bank of India.
2. Verifiable Credentials (VCs): These are digital badges issued by authorities. The Ministry of Health can issue a VC to a private AI model certifying it as “Safe for Medical Advice.” The UAI network checks this badge before letting the model interact with patients.
3. Unified Interaction Schemas: The network speaks a common language. Whether an agent is booking a hospital bed or selling fertilizer, the request structure (Intent) and response structure (Fulfillment) follow a standardized JSON schema, ensuring radical interoperability.

2.3 What UAI Is NOT

To clarify the scope and avoid misconceptions, it is critical to state what the UAI is not:

• UAI is NOT a chatbot or voice assistant: Those are Seeker agents built by private companies or ministries; UAI is the rail they run on.
• UAI is NOT a cloud computing platform: IndiaAI Compute provides the raw GPU power; UAI provides the logical protocols to access it.
• UAI is NOT an AI model marketplace: AIKosh catalogs the models; UAI enables them to interoperate and be “hired” for tasks.
• UAI is NOT a data repository: Ministries and departments along with AIKosh retain full custody of their datasets. UAI only logs the transaction metadata (receipts) for audit.
• UAI is NOT replacing existing government apps: It makes them interoperable, allowing them to “talk” to each other without expensive integration.
• UAI is NOT vendor lock-in: It prevents lock-in by using open protocols, allowing any compliant agent to join or leave the network.

2.4 “Day in the Life” User Stories

The abstract architecture translates into tangible benefits for citizens through seamless, invisible orchestration.

Farmer Ramesh (Agriculture)

• Problem: Ramesh finds his crop failing but doesn’t know why. He needs advice, money, and insurance, which usually requires visits to three different offices.
• UAI Solution:
  1. Photo: Ramesh sends a photo of the crop to the Kisan e-Mitra bot on WhatsApp.
  2. Diagnosis: The bot (Seeker) sends the image to an AI Vision Agent (Provider) which diagnoses “Stem Borer.”
  3. Claim: The bot triggers an “Insurance Claim Agent” which pulls his policy details from the PMFBY database.
  4. Credit: The bot connects to a “Credit Agent” to approve an emergency micro-loan for pesticides.
• Benefit: A complex, multi-agency workflow completed in 5 minutes on a smartphone.

Citizen Priya (Govt initiative)

• Problem: Priya needs a caste certificate urgently for a job application. The manual process takes 3 days of running between departments.
• UAI Solution:
  1. Request: Priya types “Get Caste Certificate” into the Mana Mitra WhatsApp bot.
  2. Verification: UAI validates her identity and issues a read:certificate token.
  3. Fetch: The bot instantly queries the Revenue Department Database Agent.
  4. Delivery: The certificate is generated and sent to her WhatsApp.
• Benefit: Service delivery in 30 seconds vs. 3 days.

Doctor in PHC (Health)

• Problem: A doctor in a rural Primary Health Center (PHC) sees a patient with fever but has no access to their past medical history.
• UAI Solution:
  1. Query: The doctor speaks into the ABDM app: “Show me the last 6 months of history for this patient.”
  2. Auth: UAI requests patient consent (OTP/Biometric).
  3. Retrieval: UAI fetches records from the disparate hospital agents where the patient was previously treated.
  4. Insight: The doctor sees a drug allergy alert in the history and prescribes safe medication.
• Benefit: Life-saving decisions made with complete data.

3. Value Proposition for the Ecosystem

The UAI is designed to align the incentives of three critical stakeholders: Government Ministries, AI Innovators, and Indian Citizens.

3.1 For Government Departments & Ministries (The “Seekers”)

• Indemnified Innovation: Ministries often hesitate to deploy AI due to fear of “hallucinations” (errors) and legal liability. In the UAI model, the Ministry acts as a Seeker, requesting services from certified Providers. While the Ministry retains user-facing responsibility, the UAI framework mandates that all commercial Model Providers carry Professional Indemnity Insurance. The “Verifiable Credential” certifies that the provider is insured, creating a financial safety net that indemnifies the Ministry against technical failures.
• Instant Legacy Upgrade: Ministries with older databases (e.g., PM-KISAN, Land Records) do not need to rebuild their systems. By deploying a small “Sidecar Adapter,” their legacy database becomes an AI-compatible “Provider Agent,” instantly accessible to modern voice and chat interfaces across the network.
• Data Sovereignty: Data never leaves the Ministry’s control to sit in a central cloud. The UAI facilitates a direct, encrypted connection between the user and the Ministry database.

3.2 For AI Startups & Model Builders (The “Providers”)

• Distribution at UPI Scale: Startups currently struggle to sell to the government due to complex procurement. UAI creates a unified registry. Once a startup registers its model (e.g., a new Indic language LLM) on UAI, it becomes instantly discoverable by every government application connected to the network.
• Fair-Market Revenue: Instead of competing with free credits from global tech giants, startups get paid for every inference. The government creates a “Compute Credit” system where usage is metered and paid for, creating a sustainable business model for Indian AI innovation.
• Standardization: Startups write their API once (using the UAI Protocol) and it works for every Ministry and State Government, eliminating custom integration costs.

3.3 For Citizens (The Beneficiaries)

• Unified Access: A farmer does not need 10 different apps for weather, seeds, and subsidies. They can use a single interface (e.g., WhatsApp) that “seeks” answers from all relevant Ministry agents in the background.
• Privacy Assurance: The UAI’s “Notary Model” ensures that the government platform does not store conversation history. Citizens get the benefits of AI assistance without the risk of state surveillance of their queries.

4. Technical Architecture: The Notary Model

The UAI 3.0 architecture adopts a layered design to create an open network for AI. It aims at building a “gateway” that facilitates discovery and trust.

The engineering High-Level Design expands this section into the concrete service shape, interaction lifecycle, and architectural decisions.

4.1 Unbundling the Stack: Seekers and Providers

We define the two primary actors in the UAI Network:

• User Agents (UAI-Seekers): These are consumer-facing applications (e.g., Kisan e-Mitra, WhatsApp bots) that capture user intent. They do not hold the intelligence; they seek it.
• Service Agents (UAI-Providers): These are the “intelligence nodes” — LLMs (BharatGen, Bhashini), Data Oracles (AgriStack, Soil Health Card DB), or Transaction Bots (Booking Agents). They provide the fulfillment of the intent.

4.2 Layer 1: The Registry (Discovery & Identity)

The foundation is a verifiable registry, functioning similarly to a phonebook.

• Decentralized Identifiers (DIDs): Every agent is assigned a DID.
• Capability Ledger: Instead of a static catalog, the Registry hosts a live ledger of capabilities (e.g., “I am an Agent that can read X-Rays”).
• Discovery Protocol: When a User Agent (Seeker) broadcasts an intent (“I need to check crop health”), the Registry returns a list of authorized Service Agents (Providers) capable of fulfilling that intent.

4.3 Layer 2: The Trust Protocol (Delegation Tokens)

This is where UAI architecture focuses on Authority.

• The Notary Role: Before a Seeker contacts a Provider, it requests a Delegation Token from the UAI Trust Server.
• Scope Negotiation: The token specifies exactly what the Seeker is allowed to do (e.g., scope:read:soil_data).
• Direct Interaction: Once the token is issued, the Seeker sends the request directly to the Provider. The UAI does not see the payload. The Provider validates the token locally (Zero-Knowledge Validation) and processes the request.

4.4 Layer 3: The Transaction Log (Receipts & Accountability)

To ensure governance without surveillance, we implement Receipt Logs.

• The Receipt: After an interaction, the Provider generates a cryptographic receipt containing the Transaction ID, Token Hash, and a Hash of the Interaction.
• Asynchronous Logging: This receipt is pushed to the UAI’s Immutable Audit Log. This provides Non-Repudiation proof that the interaction occurred without the UAI ever storing the private data.

4.5 Layer 4: Adjudication (Grievance Redressal)

To protect consumers in a decentralized network, UAI integrates an Issue & Grievance Management (IGM) layer, modeled on ONDC standards.

• Dispute Logging: If a transaction fails or an AI model causes harm (e.g., incorrect advice), the user can flag the “Transaction ID” from their Seeker App.
• ODR Integration: The protocol connects to third-party Online Dispute Resolution (ODR) providers. These ODR agents can pull the “Receipt Log” to verify the transaction details (e.g., “Did the bank agent actually approve the loan?”) and facilitate automated or human-mediated resolution.
• UAI’s Role: UAI does not adjudicate outcomes or correctness. It only provides cryptographic evidence (receipts) to ODR systems. The UAI platform acts strictly as a witness to the interaction, not the judge of its quality.

4.6 Action-Based Risk Framework

The UAI blueprint will adopt an Action-Based Risk Framework. Risk is determined by the nature of the permission (Scope) requested in the Delegation Token.

The UAI’s role is to ensure that an agent claiming to be the “Ministry of Health Agent” is actually authorized by the Ministry of Health (Enforcing Authority). It does not guarantee that the medical advice given by the agent is 100% correct (Adjudicating Correctness).

Trust Mechanism:

• Trust Registry: Linkage of DIDs to Real-World Identities using Verifiable Credentials (VCs).
• Example: The Ministry of Health issues a VC to a chest X-ray model provider. The VC states: “Authorized to Read X-Ray Data for TB Screening.”
• Enforcement: When the model provider requests a Delegation Token to access a patient’s record, the UAI checks for this valid VC. If the model hallucinates a diagnosis, the liability lies with the model provider and the certifier, not the UAI platform. The UAI’s liability is limited to ensuring the cryptographic handshake was valid.

Liability Mechanism:

• Authority: The UAI guarantees that the agent had the right to speak (via VCs).
• Correctness: The UAI does not guarantee that the medical advice given is correct. If the model hallucinates, liability lies with the Model Provider.
• Insurance Mandate: To operate as a Tier 3 Provider (High Risk), the provider must hold valid Professional Indemnity Insurance. The presence of this insurance is verified cryptographically via the Verifiable Credential before a token is issued.

4.7 Implementation Stack

The UAI control plane is built as a single Go codebase, backed by PostgreSQL and Redis. Cryptographic primitives follow open standards: W3C DIDs (did:webvh) and Verifiable Credentials, Ed25519 signatures, and JSON Canonicalization (RFC 8785). Integration is through two Go kits: a Seeker SDK for consumer-facing agents and a Provider Kit for intelligence nodes, each shipping with templates and a conformance suite. Bridge adapters connect UAI to existing agent protocols such as MCP and A2A.

5. Governance

5.1 Governance Model: Separation of Regulator and Operator

To secure the pilot, the governance structure must replicate the NPCI model, separating the Regulator from the Operator. The execution will leverage the existing structure of the Digital India Corporation / IndiaAI Mission while establishing a dedicated, specialised project execution team led by Avataar.

MeitY’s Role (The Regulator): MeitY functions as the “RBI of AI.” It defines the National Data Governance Framework Policy (NDGFP), sets the standards for “Action-Based Risk” classifications, and provides sovereign guarantees for the Trust Registry.

5.2 The Three-Tier Committee Structure

To balance strategic oversight with operational velocity, the governance framework is divided into three tiers:

This structure insulates the core engineering team, ensuring that the architecture adheres to being “minimalist and scalable.”

5.3 Execution Model & IP Framework

• Execution: Avataar acts as System Integrator for UAI.
• Transition: Post-pilot, the Digital India Corporation / IndiaAI Mission team takes over operations.
• IP Ownership: All code, protocols, and documentation are open-source and owned by the Government of India.
• Avataar Role: Technical execution, partner integration.
• MeitY Role: Governance, policy, ministry coordination, budget approval.
• Precedent: Similar to NPCI’s early execution model where private partners built systems under RBI oversight.

6. Ecosystem & Market-Driven Compute Strategy

This UAI blueprint proposes a Market-Driven Compute model to ensure sustainability and scalability.

6.1 The Compute Marketplace

Instead of the IndiaAI Mission buying thousands of GPUs, the UAI leverages a marketplace for compute already put in place by AIKosh.

• Providers: Cloud service providers (AWS, Google, Azure), Indian data centers (Yotta, CtrlS), and specialized AI startups register their compute endpoints in the AI Kosh registry.
• Bidding: When an agent requires inference, it broadcasts a bid. Compute providers respond with availability and spot pricing.
• Settlement: The Delegation Token includes a “Compute Credit” attribute. To ensure “Compute Credits” translate into real revenue, the UAI Foundation will designate a Central Clearing House (similar to NPCI for UPI).

6.2 Incumbent Management Strategy

Large tech incumbents (Google, Microsoft, OpenAI) present both a resource and a threat to sovereign AI. The “Notary Model” creates a specific containment and engagement strategy:

• The “Bring Your Own Model” (BYOM) Protocol: Incumbents are encouraged to register their models (e.g., GPT-5, Gemini 3) in the UAI Registry. However, they must adhere to the Protocol: they must accept UAI Delegation Tokens and generate UAI Receipt Logs.
• Data Sovereignty Enforcement: The Delegation Token for sensitive scopes (Tier 2/3) will include a geo-fence claim. If a Microsoft agent attempts to process a read:health_records token on a server outside India, the transaction fails (enforced by the Data Provider at the edge).

Standardization as a Moat: By forcing incumbents to speak the UAI Protocol (rather than using their proprietary APIs), the IndiaAI Mission can prevent vendor lock-in. Switching from GPT-5 to BharatGen becomes a matter of changing a DID in the registry, not rewriting application code.

7. Pilot Partners & Use Cases (The “Steel Threads”)

These are the specific flows that will prove the system works.

7.1 Primary Pilot: Ministry of Agriculture (Krishi Saathi / BharatGen)

• Role: The “Anchor Tenant” & Impact Showcase.
• Configuration:
  • Seeker Agent: Krishi Saathi (Vision model of BharatGen).
  • Provider Agent A: PM-KISAN Database (Status Check).
  • Provider Agent B: PM Fasal Bima Yojana (Insurance DB).
  • Provider Agent C: Bank Agent.
• User Flow (Distress to Relief):
  1. Farmer uploads a photo of a failed crop via Krishi Saathi (Voice/Image).
  2. BharatGen Vision Model analyzes the image and confirms crop damage.
  3. Seeker requests UAI Token for Insurance Claim (Write Action).
  4. UAI verifies farmer identity (Provider A) and issues a token.
  5. Seeker auto-files claim with PM Fasal Bima Yojana (Provider B).
  6. Seeker connects to a Bank Agent (Provider C) for emergency credit to buy pesticides.
• Outcome: A seamless, multi-agent workflow solving a critical farmer distress scenario in minutes.

7.2 Secondary Pilot: Andhra Pradesh State Govt (Mana Mitra)

• Role: The “State Model” (Federal Structure).
• Configuration:
  • Seeker Agent: Mana Mitra (WhatsApp).
  • Provider Agent: Revenue Department Database (MeeSeva).
• User Flow: Citizen types “Caste Certificate Status” → Mana Mitra requests read:certificate token → UAI Notary verifies → Revenue DB returns status.

7.3 Secondary Pilot: Ministry of Health (ABDM)

• Role: The “High-Risk/Privacy” Test.
• Configuration:
  • Seeker Agent: Tele-consultation Bot.
  • Provider Agent: ABDM (Health ID).
• User Flow: Patient requests ABHA profile → UAI enforces biometric/OTP auth → Token issued with scope:read:profile → Profile fetched.

8. Pilot Success Metrics

To ensure the pilot’s effectiveness beyond just transaction volume, we will track the following key performance indicators (KPIs).

9. Risk Mitigation Register

We acknowledge that a project of this scale and speed carries significant risks. The following register outlines the top risks and specific mitigation strategies.

Risk 1: Ministry integration delays (legacy systems incompatible)

• Probability: HIGH
• Impact: HIGH
• Mitigation Strategy:
  • Build adapters for 3 fallback ministries (Commerce, MSME, Tourism) in parallel.
  • Month 3 checkpoint: If Agriculture delayed >4 weeks, pivot to fallback.
  • Hire legacy integration specialist consultant.

Risk 2: Security breach exposes citizen data

• Probability: MEDIUM
• Impact: CRITICAL
• Mitigation Strategy:
  • DRDO/C-DAC security audit in Month 4 (mandatory go/no-go gate).
  • Bug bounty program to find vulnerabilities pre-launch.
  • Cyber insurance policy for pilot phase.
  • Incident response plan with <4 hour notification to MeitY.

10. Conclusion: The Invisible Infrastructure

UPI was launched in April 2016 with just 21 banks and 0.09 million transactions in the first three months. Today, UPI processes 21+ billion transactions monthly and has become a global model for real-time payments.

UAI can follow this trajectory by maintaining rigorous discipline on three principles:

1. Protocol, not platform: Government defines standards, market provides services.
2. Lean core, vibrant ecosystem: a small core team coordinates hundreds of market participants.
3. Pilot-driven validation: Prove value with Agriculture and State Department before national scale-up.

The pilot is not about building a complete AI infrastructure. It’s about proving the protocol works for select high-impact use cases, demonstrating interoperability across government systems, and showing that market participants can build competitive solutions on the same rails. This helps to build the Trust, Protocol, and Registry layers as a stable foundation.

This blueprint delivers a system that is:

1. Scalable: Because compute is distributed to the market.
2. Safe: Because risk is managed via cryptographic tokens, not content surveillance.
3. Sovereign: Because it runs on open Indian protocols, ensuring no single corporate entity controls the nation’s intelligence.

This is the path to a truly “Atmanirbhar” & “Viksit” AI ecosystem.