India has built five national data utilities in fifteen years. Banking got UPI on top of NPCI. Identity got Aadhaar. Tax got GSTN. Logistics got FASTag. Capital markets got the demat stack on NSDL and CDSL. Each one is a public data layer that did not exist a generation ago and now sits under an entire industry, compounding productivity for every business and every citizen that touches it.
Law is the sixth. It is also the most overdue. More than 5 crore cases sit pending across Indian courts, according to the National Judicial Data Grid (NJDG), roughly 5.4 crore as of May 2026, a figure the NJDG refreshes daily. Hundreds of millions of pending and decided matters touch litigants, lenders, employers, banks and counterparties across the economy. Roughly 20 lakh advocates are enrolled with the Bar Council of India, of whom an estimated 17 lakh actively practise. And they all serve them through twenty five plus government portals that do not search across each other, do not expose structured data, and were never built for cross court intelligence.

This post is about what changes when that data spine finally exists, and why the firm that builds it sets the floor for every legal AI product, every enterprise risk tool and every lawyer workflow that gets built on top.
What is an Operating System for Indian Law
The Operating System for Indian Law is a single structured data layer over every Indian court, order, advocate and judge, refreshed daily and exposed through a lawyer interface, an enterprise API and an agent layer, so any application or AI model can read the corpus that twenty five plus government portals keep scattered today.
An operating system is not a website. It is not a search box. It is the layer that decides what every application above it can do.
For law in India, that layer needs four things at once. It needs a single structured view of every court, every order, every party, every advocate, every judge, refreshed daily and linked across portals. It needs an interface that the roughly 17 lakh practising bar will use every day, on a phone, in their working language. It needs developer access through APIs so banks, BGV providers, insurers and legaltech founders can build their own products on top. And it needs an agent layer that lets large language models, including Claude, GPT, Gemini and the new wave of legal AI agents, read the corpus natively.
That stack is what we mean when we say Operating System for Indian Law. The data layer pays for itself through enterprise API revenue. The interface layer earns lawyer subscriptions. The agent layer earns its keep by becoming the default substrate for every legal AI built in India. And the OS as a whole accrues a data moat that compounds with every order uploaded, every cause list parsed, and every case file pinned by a paying lawyer.
This is not theoretical. The pieces exist. They just have not been wired together by a single team until now. eCourtsIndia is wiring them.

India already built five data utilities. Law is the missing sixth.
The pattern is consistent. Each Indian data utility solved the same shape of problem. A national activity already happened. It already produced data. The data was scattered, unstructured and useless at population scale. Until a public or public adjacent layer aggregated, structured and standardised it, the applications on top could not work.
UPI is the cleanest example. Banking transactions already happened in 2014. They just happened on dozens of incompatible bank rails. NPCI built one layer of standardisation. Within four years, every fintech, every kirana QR sticker and every household money transfer ran on it. The application layer did not invent the activity. It removed the friction in the data layer.
Aadhaar did the same for identity. GSTN did it for indirect tax. FASTag did it for highway tolling. NSDL and CDSL did it for share ownership. In each case, the data utility came first, the explosion of applications came second, and the productivity gains compounded for a decade after.
Law has not had its UPI moment. The eCourts Mission Mode Project, run by the Supreme Court of India’s e-Committee and the Department of Justice, has done the heavy public lifting since 2007. Over 29,000 courts now run on the eCourts Case Information Software (CIS). NJDG aggregates pendency data. Phase III’s Rs. 7,210 crore outlay between 2023 and 2027, per the Press Information Bureau, will fund AI tools, OCR, paperless courts and integrated services. The government has built and is still building the public backend.
What it was never built to do is the application layer. The eCourts portal lets you look up one case at a time, behind a captcha, on a schema that varies by court. It was not built for cross court search, bulk access, structured APIs, lawyer productivity, vernacular AI, or agent integration. That is correct. It is a public records system, not a SaaS product. The UPI parallel holds here too. NPCI does not build the consumer fintech apps. Razorpay, PhonePe, BharatPe, Cred and a thousand others do.
The Operating System for Indian Law sits in that same complementary slot. Public foundation underneath. Private experience layer on top. That is the relationship we believe in and the relationship the Phase III vision document explicitly invites.
Why the data layer is the hardest part
Anyone can build a legal AI prompt wrapper. Almost no one can build the data layer underneath it.
Indian court data is broken in ways that do not exist in the United States or the United Kingdom. All 25 High Courts publish in their own schemas. Seven hundred plus district complexes publish in dozens of regional variants. Orders arrive as scanned PDFs in Hindi, Marathi, Tamil, Telugu, Bengali, Kannada, Gujarati, Odia and Punjabi. Cause lists change overnight and republish at five in the morning. Parties are spelt three different ways in three different filings. The same advocate appears with three different name variations across three benches. A single CNR survives a transfer, the case number does not. None of this is documented in one place.
Building the structured layer means solving all of that simultaneously. Harvesting from every portal. Surviving the rate limits and captchas. Running OCR on scanned vernacular orders that often pre date the digital era. Normalising schemas across courts. Resolving entities so that one petitioner does not show up as four. Linking orders to the case, the bench, the judge, the advocate and the party. Keeping everything fresh. Doing it at scale without breaking when one of twenty five portals changes a field name on a Tuesday morning.
You cannot scrape your way to this. You have to build a pipeline that treats every court as a first class data source and every record as a permanent canonical object. That pipeline is not glamorous. It is the entire moat.
Once it exists, the application layer above it can be built in weeks. Without it, the application layer cannot be built at all. That is why Indian legaltech has spent two decades shipping search across Supreme Court and High Court orders only. The cost of going wider into the district tier was too high for any one product company to absorb. Someone had to build the spine first.

What sits on top of a court data OS
Once the layer is in place, three product surfaces become possible at the same time.
The AI Lawyer. A single workflow product for the practising advocate. Unified search across the Supreme Court, all 25 High Courts and district courts across 800+ districts, plus tribunals. Cause list and hearing tracker. Lawyer, judge and litigant profiles, cross linked. AI Clerk for case file management and hearing prep. Over the next two years, AI drafting, AI research and AI filing layered on top of the same spine. The destination is a lawyer running their full working day, including the parts that used to require a junior at the bar library or a clerk at the court, inside one product. We wrote about how this looks for a solo advocate practising across nine courts in One Advocate, Nine Courts, One Claude Window.
The Enterprise API. The same structured data exposed to BFSI, BGV, RegTech, insurance, fintech and corporate legal teams as a clean JSON API plus an MCP server. Banks check borrower litigation exposure before disbursing a loan. NBFCs flag fraudulent applicants. BGV providers replace manual vendor checks with API calls. Insurers detect parallel claims. Corporate legal teams monitor portfolio risk. The use cases were always there. The product class was waiting on the data layer. We covered the migration path for product teams in From Scrape to SLA: Why We Moved Off services.ecourts.gov.in to the eCourtsIndia API.
The Agent Substrate. The most quietly important layer. Anthropic’s Model Context Protocol has become the default way agentic LLMs connect to external data. By exposing court data as an MCP server, the platform becomes the substrate that every legal AI agent in India can call, regardless of which model it runs on. Claude can read it. GPT can read it. Gemini can read it. A startup building a vernacular bail bot can read it. A General Counsel running a portfolio brief from Claude Desktop can read it. This compounds. The more agents that depend on the substrate, the more deeply it sits underneath the category. Our primer for legal teams on this shift is in MCP 101 for Legal Teams: The New Plumbing Between Claude, ChatGPT, and Indian Court Data.
Three product surfaces. One spine.
Three buyer pools, one spine
The Operating System for Indian Law makes money from three structurally different buyer pools without splintering its engineering team.
The practising lawyer is the largest. About 17 lakh practising advocates out of roughly 20 lakh enrolled, on a price point that has to start small and grow with the workflow. Industry surveys in 2025 found a large majority of legal professionals already using or planning to use AI within the year. That tells us adoption is not the bottleneck. Product, price and language are.
The enterprise buyer is the most lucrative on a per account basis. Banks, NBFCs, insurers, BGV firms, RegTech vendors, legaltech platforms, fintech lenders and corporate legal teams. Around fifteen hundred organisations in this band, each spending real money today on manual litigation checks, paralegal time and patchwork vendor relationships. An API replaces line items in their existing budgets, not net new wallet share.
The developer and the agent are the long tail. Every legal AI startup in India needs court data to make their product useful. The default path today is to scrape, fail at scale and burn engineering quarters on data plumbing. The shortcut is to call an API. The accelerator is to call an MCP server and let the agent compose the workflow itself.
Each pool funds the spine. The spine compounds for each pool. The lawyer surface increases data freshness and case file richness, which improves enterprise outputs. Enterprise revenue pays for vernacular OCR investment, which makes the lawyer product work in Bengaluru’s Kannada district complexes and Patna’s Hindi sessions courts. Agent traffic surfaces edge cases that improve schema quality for everyone.
This is the part that gets missed in the pitch room. The three product lines are not three different bets. They are three monetisation surfaces of one asset.
What stops a foreign player from doing this
Harvey AI is valued at eleven billion dollars on a hundred and ninety million dollar ARR, per Reuters in March 2026. Legora is at five point six billion per TechCrunch in April 2026. These are remarkable companies. They are also irrelevant to the Indian market in the way that matters most.
Their corpora are English language, common law in the American or British sense, and structured around appellate research and contract review. They do not have Hindi OCR. They do not know what an Order XXXVII summary suit is. They cannot show you the cheque bounce orders passed by a particular judge of the Allahabad High Court Lucknow Bench, in the language those orders were written. They cannot pull a CNR. They do not own a single piece of structured data from a Tier 2 district court in Maharashtra. They will not build that, because the unit economics of building India coverage from a US base are punishing.
The same is true for the global research incumbents. Westlaw, LexisNexis and the rest were built on common law research, not Indian trial court workflows.
The winning Indian Operating System for Law is local by necessity. Local courts, local procedure, local language, local price points. Built by a team that understands the difference between a writ petition and a writ appeal at the Madras High Court, and between a Sessions Court and a Special Court in Mumbai. That is not a brand line. It is a structural truth about the moat.
The window is now
Three things make this moment different from any previous attempt.
First, the public foundation is finally in place. eCourts Phase II’s CIS rollout means the underlying digital data exists, even when its surface presentation is rough. Phase III’s outlay is committed. Twenty plus years of public investment have moved the field to where the private application layer can finally sit on top of something stable.
Second, the AI layer is ready. Goldman Sachs estimated in 2023 that AI could automate forty four percent of legal work over the next four to five years. Industry surveys show a large majority of legal professionals already using or planning to adopt AI. The model layer has commoditised enough that the moat shifts decisively to proprietary structured data plus distribution.
Third, the global comparables have run the playbook. Harvey, Legora and the CaseText acquisition by Thomson Reuters in 2023 at six hundred and fifty million dollars have shown what the ceiling looks like for a vertical legal AI company in a Western market. India has more practising lawyers, more pending matters and a larger underserved population than any of those markets. The category ceiling here is higher. It just needs the data spine to exist first.
That window does not stay open forever. Once one team builds the structured data layer, the cost of replication for a second team is twelve to eighteen months of focused engineering. Once that team also has daily lawyer engagement, paying enterprise contracts and a live MCP server in the field, replication becomes economically unattractive for any incumbent or new entrant. The next eighteen months decide who owns the category.
We are building that team and that layer at eCourtsIndia.
What this means for eCourtsIndia
The Operating System for Indian Law has three layers. Public records underneath, private experience in the middle, agent substrate above. We do not build the public layer. We do not need to. We build the experience layer and the agent substrate, sitting respectfully on top of the public foundation, and we let three buyer pools fund the spine that compounds for each one.
TL;DR
- India built UPI for payments, Aadhaar for identity, GSTN for tax and FASTag for tolls. Law is the only large industry still missing its national data spine.
- The bottleneck has never been adoption. Industry surveys in 2025 found a large majority of legal professionals already using or planning to use AI within the year. The bottleneck is structured court data that AI can actually read.
- The Operating System for Indian Law is the data layer underneath, the lawyer interface on top, and the agent substrate that lets any LLM call the spine natively.
- Three buyer pools, one spine. Lawyer subscriptions, enterprise APIs, agent traffic. Each pool compounds the data moat for the others.
- The category ceiling has been proven globally by Harvey, Legora and the CaseText acquisition. The Indian ceiling is higher because the unserved bar is larger. The window to build the spine closes in eighteen months.
Sources
- National Judicial Data Grid pendency dashboard, accessed May 2026
- Bar Council of India / Law Ministry estimate of practising bar size, about 17 lakh out of roughly 20 lakh enrolled
- Bar Council of India enrolment statistics, approximately 20 lakh
- Press Information Bureau release on eCourts Phase III, Rs. 7,210 crore outlay
- Secretariat / ACEDS 2025 Global Artificial Intelligence Report on legal AI adoption
- Goldman Sachs report on AI and the future of legal work, 2023, 44 percent automation estimate
- Reuters reporting on Harvey AI valuation, March 2026
- TechCrunch reporting on Legora funding round, April 2026
- Thomson Reuters acquisition of CaseText, June 2023, USD 650 million
- All court coverage figures verified against the eCourtsIndia structured data index
Read next: MCP 101 for Legal Teams and From Scrape to SLA: Why We Moved Off services.ecourts.gov.in.
Frequently Asked Questions
What is the Operating System for Indian Law?
It is a single structured data layer covering every court, order, party, advocate and judge in India, refreshed daily and linked across twenty five plus government portals. On top sit a lawyer interface, an enterprise API and an agent layer that any large language model can call. You can search live case data directly at ecourtsindia.com/search.
How is this different from the government eCourts portal?
The eCourts portal is a public records system that lets you look up one case at a time behind a captcha, on a schema that varies by court. It was never built for cross court search, bulk access or agent integration. The Operating System for Indian Law sits on top as the private experience layer. We explain the plumbing in MCP 101 for Legal Teams.
What can enterprises do with the eCourtsIndia API?
Banks, NBFCs, insurers, background verification firms, RegTech vendors and corporate legal teams use it to check borrower litigation exposure before disbursing a loan, flag fraudulent applicants, detect parallel insurance claims and monitor portfolio risk. The same structured court data is delivered as clean JSON plus an MCP server. Developers can start at ecourtsindia.com/api.
Can lawyers research a judge or advocate before a hearing?
Yes. The platform builds lawyer, judge and litigant profiles that are cross linked to the underlying cases, so you can see how a bench has decided similar matters or what an opposing advocate has argued before. That turns scattered portal lookups into one view. You can research any judge at ecourtsindia.com/judge before your next hearing.
Why can a foreign legal AI company not just build this for India?
Companies like Harvey and Legora are built on English language common law, appellate research and contract review. They have no Hindi OCR, cannot pull a CNR and own no structured data from a Tier 2 district court. The unit economics of building India coverage from a US base are punishing. We cover the data problem in From Scrape to SLA.
