By Malay Baral, Founder & CTO, AdiOS Platform Private Limited
NOSM and AdiOS are not separate conversations. NOSM defines India's sovereign OS mission. AdiOS is a working sovereign AI OS stack built on a hardened Ubuntu-derived base, Nix declarative provisioning, and Rust-native substrate services. This post maps where the two align, where AdiOS goes further, and what India should standardize next.
"NOSM defines the national OS mission. AdiOS is a working sovereign AI OS stack for the AI era. India needs both."
The Question Behind Both Missions
India has been building software for four decades. Yet an Indian hospital can still run clinical decision support on a foreign model. The model may be trained in the United States. Its terms may be written in California. Its audit trail may be controlled by a company that reports to no Indian authority.
Every Indian bank deploying AI for credit scoring is exposing customer financial behavior to inference infrastructure it does not own, cannot inspect, and cannot audit for bias.
This is not a data residency problem. Moving a foreign model to an Indian data centre does not make the inference sovereign. The OS it runs on is still foreign. The audit framework is still foreign. The ability to revoke, inspect, or modify the stack still belongs to someone else.
Sovereignty means the intelligence runs on your premises. It runs under your architectural rules. You enforce every policy. You own every audit record. No external party can override the stack.
That is the problem both NOSM and AdiOS are trying to solve. They are solving it at different layers of the same stack. This post is the alignment map.
Part One: What NOSM Actually Is
The National Operating System Mission emerged from a high-level brainstorming session in May 2025. C-DAC Chennai and IIT Madras led the session. Academia, government, and industry stakeholders participated. Major Indian software and cloud providers were also involved. As of May 2025, NOSM had been discussed as a mission concept. A formal notified mission had not yet been announced in the public domain. A published budget had not yet appeared either.
What the C-DAC and IIT Madras session established is a direction and a set of objectives:
Figure 1: NOSM objectives (synthesized from public session outcomes)
BharOS: The Clearest NOSM Artefact
BharOS is an Android-compatible, privacy-focused mobile OS developed by JandK Operations, an IIT Madras-incubated firm backed by the Pravartak Technologies Foundation and DST. It carries no default Google services, uses a controlled private app distribution system, and is actively deployed in Indian government and enterprise contexts.
BharOS proves the model works at the mobile layer. NOSM's mandate is to generalize this across every OS layer and form factor.
NOSM's Technical Scope
Figure 2: NOSM technical scope (synthesized)
Part Two: What AdiOS Actually Is
AdiOS is India's first sovereign AI operating system. It is a NOSM-aligned sovereign AI OS stack. It uses a hardened Ubuntu-derived base, declarative Nix provisioning, and Rust-native substrate services. The AdiOS control plane, substrate services, and platform components are Rust-native. As of April 2026, the platform has 87 components, 318K+ Rust lines of code, 7,400+ tests, 93 ADR files, 96 spec directories, 9 patent claims, and 24 enforced compliance rules + 397 documented frameworks.
Where AdiOS Sits in the OS Stack
AdiOS is not a kernel-from-scratch project. It does not try to replace Linux device drivers, POSIX compatibility, or the hardware enablement work that mature Linux distributions already provide.
But AdiOS is also not just an application layer. It is a sovereign OS stack built from a hardened Ubuntu-derived base, declarative Nix provisioning, and Rust-native substrate services. The substrate is part of the product. It covers identity, mesh, policy, sync, hardware abstraction, inference, and compliance enforcement.
So AdiOS overlaps with NOSM at the sovereign OS platform layer. The stance is not "we do not compete." The stance is sharper. AdiOS is a candidate NOSM-aligned implementation for the AI era. NOSM defines the national mission and certification direction. AdiOS provides a working sovereign AI OS stack that runs on today's Linux base and can migrate toward future NOSM-certified substrates.
The Core Premise: Sovereignty as Architecture
Most AI deployments treat sovereignty as a configuration option. You turn on data residency. You enable encryption at rest. You check a compliance box in a dashboard.
AdiOS treats sovereignty as an architectural invariant. Six platform invariants cannot be configured away by any administrator, developer, or API consumer:
Figure 3: Six platform invariants: structural, not configurable
The Circular Loop: Why Intelligence Compounds
Most AI deployments extract. Every API call to a foreign LLM starts from zero organizational context. The model does not learn your domain. It does not remember your workflows. It takes your data and returns a response. The organization retains nothing.
AdiOS is designed around the opposite principle:
Figure 4: The Circular look: Knowledge compounds
Part Three: The Layer Stack
The relationship between NOSM and AdiOS is most clearly expressed as a vertical stack. They own adjacent layers with a defined overlap zone:
Figure 5: Layer stack: NOSM and AdiOS ownership zones
Part Four: Where They Agree
Sovereignty is Architecture, Not Configuration
Both programs reject the idea that sovereignty can be achieved by configuring an existing foreign platform. You cannot achieve AI sovereignty by wrapping a foreign model in a proxy. You cannot achieve OS sovereignty by enabling a privacy toggle in an Android build controlled by Google.
Sovereignty must be enforced at a layer that cannot be overridden by downstream developers. For NOSM, this is the kernel and system services. For AdiOS, this is the sentinel policy ring and the offline-first data layer.
Offline-First is Non-Negotiable
India's connectivity is uneven. A bank branch in rural Rajasthan, a health kiosk in Andhra Pradesh, a defence forward operating base in Ladakh: none can depend on continuous connectivity for core operations.
But this is not uniquely Indian. A Dutch municipality running a community services platform must stay operational when a fibre cut isolates a district. A mining operation in a remote jurisdiction must process sensor data when satellite uptime is limited.
Offline-first is a sovereign design requirement, not a frugal computing compromise. AdiOS's CRDT-based sync layer treats offline as the baseline state, not an exception. NOSM's embedded and IoT scope reflects the same architectural premise.
RISC-V as the Long Horizon
IIT Madras's Shakti RISC-V program is currently India's most visible and mature indigenous CPU design program for silicon sovereignty. A domestically designed and fabricated processor eliminates the ARM licensing dependency from the trust chain.
AdiOS's hardware abstraction layer provides the bridge that will make Shakti support possible without re-engineering the platform when Shakti processors move from research into production-grade deployment.
Indic Languages as Infrastructure
Both programs treat Indic language support not as localization but as foundational infrastructure. A sovereign AI that cannot operate in Telugu, Tamil, Hindi, or Bengali is not sovereign for most of India's population.
Under the IndiaAI Mission, Sarvam AI has been selected to build India's sovereign large language model. The focus is Indic-first. That makes it a natural target for AdiOS's sovereign model router on the Indic inference path. Sarvam AI does not compete with AdiOS. It is a capability that AdiOS orchestrates. The router decides when to use Sarvam AI. It also decides when to use a local quantized model. It can choose a domain-specific fine-tuned model from the platform marketplace.
Part Five: Where They Differ
Difference 1: The Application Layer Problem
NOSM's mandate ends at OS and system services. Its output is a trustworthy platform on which others can build. It does not address what applications those others will build.
Enterprise organizations will not migrate to a sovereign OS unless the capabilities they need are already available, proven, and compliant on day one of deployment. The application and AI governance layers must be solved alongside the OS layer, not after it.
AdiOS addresses this with domain packs and substrate services. These are pre-built, compliance-ready layers for BFSI, Healthcare, Agriculture, Defence, Government, and Pharma. They run on the AdiOS OS stack today. They can also run on future NOSM-certified distributions.
Difference 2: AI Governance
NOSM's published objectives mention AI in passing. The primary focus is OS security, reliability, and Indic language support. AI agent identity, AI governance, and knowledge compounding are not in scope.
This gap will widen as every enterprise deploying a sovereign OS immediately asks: where does the AI run? Which data does it access? Who authorized it? How do its decisions get audited?
AdiOS answers all four from the platform layer. The sentinel policy ring enforces AI governance policies. The identity layer issues DIDs to AI agents. The Circular Loop governs how AI-generated knowledge is promoted, validated, and compounded across the organization.
NOSM needs an AI governance specification. AdiOS is a working reference implementation of one.
Difference 3: Machine-Executable Compliance vs. Stated Goals
NOSM discusses compliance as an objective. It does not specify how compliance is enforced mechanically at runtime.
AdiOS enforces compliance with 24 enforced + 397 documented compliance frameworks on every operation. A stated compliance goal verified by a quarterly audit is a different thing from a compliance invariant verified on every API call. Regulated enterprises need the latter.
Difference 4: Timeline Reality
NOSM is a multi-year government mission whose budget, timeline, and governance are still being formed. Full-scale outputs are realistically 3 to 5 years away.
AdiOS is in production development today. Enterprises cannot wait 5 years for a sovereign OS certification before beginning their AI sovereignty journey. They need a deployable sovereign AI OS stack now. It must run on existing infrastructure. It must also have a defined migration path to NOSM-certified substrates as those become available.
Difference 5: Governance Model
NOSM is government-led, with academia as the primary technical driver and industry as a participant. AdiOS is startup-led with a commercial product built on an open research architecture.
These governance models are complementary. NOSM sets standards and certification frameworks. AdiOS competes in the market to build the best implementation of those standards. The relationship is analogous to how Linux kernel governance (open community) and Red Hat (commercial distribution) coexisted productively for two decades.
Part Six: The Structured Comparison
Figure 6: Structured comparison across 14 dimensions
Part Seven: AdiOS is Designed for India, Built for Any Jurisdiction
This point deserves its own section because it is misunderstood.
AdiOS was designed to solve India's regulatory reality: DPDP Act 2023, RBI FREE-AI framework, SEBI guidelines, ABDM certification, iDEX defence requirements. These are the compliance anchors baked into the first set of 24 enforced + 397 documented frameworks in adios-regionkit.
But the architecture is jurisdiction-agnostic. The adios-regionkit component maps a deployment's jurisdiction to its applicable rule set at provisioning time. The sentinel policy ring enforces that rule set on every operation. The rule set is a configuration. The enforcement mechanism is not.
A Netherlands public sector deployment loads a different rule set:
Figure 7: Same architecture, different jurisdistional rule sets
Public sector IT organizations in the Netherlands, Germany, Singapore, and the Gulf Cooperation Council face the same structure. Their AI models may be trained on foreign data. They may be governed by foreign terms. They may be auditable only by foreign entities. The regulatory vocabulary differs. The architectural requirement does not.
AdiOS is designed for India's needs because India's needs are specific and immediate. It is applicable globally because sovereignty as architecture is a universal requirement.
Part Eight: The Three Sovereign Waves
Figure 8: Three waves with NOSM and AdiOS milestones per wave
Part Nine: The Ecosystem Map
Figure 9: Complete India sovereign tech ecosystem
Part Ten: What India Must Build Next
The alignment map reveals three gaps that no existing program addresses.
Gap 1: Machine-Executable Certification
NOSM will eventually certify OS distributions. But today, certification is a document. A compliance attestation is a legal declaration. Neither can be verified programmatically by a deploying enterprise.
India needs a certification standard where compliance claims are expressed as verifiable rules that a runtime enforcement layer can check continuously. AdiOS's 24 enforced + 397 documented sentinel controls are a working reference implementation of what this looks like.
The recommended certification levels:
Figure 10: Proposed certification levels for India's sovereign OS mission
Gap 2: An AI Agent Identity Standard
Every enterprise deploying a sovereign OS will run AI agents on it within 18 months. Those agents need: cryptographic identities (DIDs), scope-limited authorization credentials (VCs), append-only audit trails, and revocation mechanisms.
AdiOS has implemented all four. India needs a national standard for AI agent identity that NOSM-certified OS deployments must enforce. The DID-VC architecture and the sentinel audit format in AdiOS are available as a reference.
Gap 3: A Sovereign Procurement Signal
The most powerful signal the Indian government can send is procurement policy. A mandate that new government IT deployments must evaluate NOSM-aligned OS platforms before selecting foreign alternatives would create an immediate market.
This is not protectionism. It is what every government that takes digital sovereignty seriously already does. Security and compliance certification schemes that heavily influence procurement decisions include FedRAMP in the United States, EUCS in the European Union, and BSI IT-Grundschutz in Germany.
India's equivalent should specify OS sovereignty criteria. It should also specify AI governance criteria. That means DID/VC for agents and a mandatory audit trail. It should define data residency and on-premises enforcement. It should require machine-executable compliance demonstration, not declarative attestation.
NOSM provides the technical framework. AdiOS provides a production reference implementation. The procurement mandate creates the market.
Closing: The Convergence That Must Happen
NOSM will remain incomplete if it stops at the kernel layer. It cannot wait for AI applications to emerge later. Those applications need an AI intelligence and governance layer from day one. Enterprises must be able to deploy that layer on NOSM-certified substrates.
AdiOS is designed to be that stack. It is built in India. It is built for India's specific regulatory reality. It combines an Ubuntu-derived base, Nix declarative provisioning, Rust-native substrate services, and AI governance at the operating layer. The architecture applies beyond India. It fits any jurisdiction where sovereignty means running intelligence on your own premises. It means your own rules. It means cryptographic proof of every action.
The two programs are not parallel tracks. They are converging. The brainstorming sessions will become mission documents. The mission documents will become certification standards. The standards will create a market. That market will validate years of engineering. It will also validate India's first sovereign AI operating system as a production reality.
India's software sovereignty moment is not coming. It is here. The question is who builds the stack it runs on.
Originally published on LinkedIn on April 25, 2026.