Building Litigation Analytics on Indian Court Data

Show a litigation dashboard to a partner who has practised for twenty years and you will get one of two reactions. Either a question about how a number was computed, which is the beginning of a useful conversation, or a polite nod and no further engagement, which means the product is dead and nobody has said so. The second reaction is far more common, and the reason is almost always the same. The dashboard was designed by looking at an American product and then hunting for Indian data to fill it.

That order is backwards. Indian court records have a specific structure, published by registries with specific conventions, with specific and highly uneven gaps. Any analytics layer built on them either starts from that structure or spends its life computing plausible numbers that nobody who knows the domain will trust.

This piece works from the fields upward. What a case record actually carries, which aggregations those fields honestly support, which ones they do not support no matter how confidently a chart renders them, and the denominator problems that quietly corrupt both. The useful discipline is being able to say, for every tile on the screen, exactly what population it was computed over.

Start From the Fields, Not From the Chart

A case record returned by a court data API is not a blank canvas. It is a specific set of fields, and the analytics you can honestly build are a function of exactly those fields. On the CourtMesh API a call to GET /cases/:id returns the record without analysis, and the fields that matter for aggregation fall into four groups.

Note what is not on that list. There is no field for who won. There is no field for the relief granted in rupees. There is no field marking a judge as plaintiff friendly or defendant friendly. Those things are not missing because the API withholds them. They are missing because registries do not publish them, and any product that displays them has derived them from something, which means the question is what, and with what error rate.

The Metrics the Data Actually Supports

These are the aggregations that survive scrutiny from someone who knows the domain, provided you state the population clearly and accept the caveats attached to each.

Time from registration to disposal

The core temporal metric, and the one firms genuinely want. Compute it as the interval between registrationDate and decisionDate, restricted to a single court and a single case type, over records where both dates are present and disposalNature is non empty. Report it as a median with an interquartile range rather than a mean, because Indian disposal distributions have long tails and a mean tells you almost nothing about what your matter will do.

Prefer registrationDate to filingDate as the start point. Filing and registration are distinct events, the gap between them is a registry function rather than a judicial one, and filingDate is missing more often. If you use filingDate anywhere, label the metric differently, because filing to disposal and registration to disposal are two different numbers and mixing them across courts produces a chart that is wrong in a way nobody can see.

Listing frequency and procedural tempo

caseHistory gives you the sequence of listings for a matter. From it you can honestly compute the number of listings before disposal, the median gap between consecutive listings, and how that gap varies by court and case type. This is one of the few metrics that speaks directly to what litigation actually feels like, and it is far more useful to a general counsel budgeting counsel time than an outcome prediction ever was.

Distribution of disposal natures

Group disposed matters by disposalNature within a court and case type and you get the real shape of how matters end there. The essential discipline is to preserve the registry's own vocabulary as the base layer and treat any mapping into your own categories as a separate, versioned, visible transformation. Disposal vocabularies vary across registries, and a mapping that folds Disposed Off, Dismissed as Withdrawn and Disposed of as Infructuous into one bucket called Dismissed has destroyed the only thing the field was telling you.

Volume by act and section

The acts and sections fields let you count matters by statutory provision. Section 138 of the Negotiable Instruments Act 1881 is the obvious and most valuable case, because the volume is enormous and highly concentrated in the magistracy, so counts by establishment and by year carry real signal. The same works for matters under section 34 of the Arbitration and Conciliation Act 1996, for proceedings under the IBC 2016, and for applications under Order 39 of the CPC 1908. Two caveats: the fields are populated unevenly, so a lower count may mean fewer matters or thinner metadata, and a matter can carry several provisions, so counts by section sum to more than the number of matters.

Pendency and stage distribution

For live matters, caseStatus and caseStage give you a distribution of where a portfolio sits: how many at evidence, how many at arguments, how many awaiting orders. Combined with nextHearingDate this is the most operationally useful view for an in house team, because it answers what is coming rather than what happened, and it does not require you to infer anything.

The Metrics That Cannot Be Supported

This is the section that costs a vendor a sale and earns them a client. Some of the most demanded charts in legal analytics cannot be built honestly on Indian court records, and building them anyway is how a product acquires a reputation among the people whose opinion actually moves it.

Why judge win rates do not work

There is no outcome field. To compute a win rate you must first decide what winning means, then infer it from disposalNature or from the text of the judgment. Both inferences are unreliable. A petition dismissed as infructuous is not a loss. A matter disposed of in terms of a settlement has no winner. An appeal partly allowed defies the binary entirely. Interim relief granted while the main matter continues is not an outcome at all. Then compound that with assignment: judges do not receive a random sample of matters. They receive rosters. A judge sitting on a bail roster and a judge sitting on a company roster have incomparable populations, and any comparison of their rates measures the roster, not the judge.

There is also a professional dimension that sits above the statistics. A metric that ranks judges by outcome invites use as a forum shopping input, is inevitably wrong at the individual matter level, and is difficult to defend in front of the profession it purports to describe. The technical objection is that the number is unsound. The practical objection is that even a sound version would be the wrong artefact to publish.

Why prediction is worse than it looks

Outcome prediction on this corpus fails before the modelling begins, because the label is the problem. If your label is derived from an inference over disposalNature, then your model is learning to predict your inference, not the outcome. Its accuracy figure is a measure of internal consistency and nothing more. A prediction product that has not been evaluated against a held out set of matters with independently verified outcomes has not been evaluated. Most have not been.

The question to ask any litigation analytics vendor is not how accurate the model is. It is what the label was, who assigned it, and over what population. Most demonstrations end there.

The Denominator Problems

Every number on a litigation dashboard is a ratio, and in this domain the numerator is usually fine and the denominator is usually wrong. Four failures account for most of it.

How to Assemble It Without Burning Your Budget

The mechanics matter, because analytics work is bulk work and bulk work on court data is throughput constrained. An API key on the CourtMesh API is allowed 10 requests per minute, so the shape of your pull decides whether your dashboard refreshes in an hour or in a fortnight.

1. Aggregate from search, not from per case fetches. POST /search/cases returns up to 100 records per page, and each record already carries the case fields your metrics need. Pull the population with paged searches sliced by court and by year, and reserve GET /cases/:id for the individual records a user actually opens.
2. Slice narrowly enough to finish. A keyword search is allowed up to 90 seconds before it returns 408. Partition by court and year, or by date range using fromDate and toDate where a court is large, and persist the cursor after every page so a crash costs one page rather than the run.
3. Store the raw record before you transform it. Keep the registry vocabulary intact in your warehouse and layer your normalisation on top as a versioned view. When somebody disputes a number in six months, you need the original value to answer with.
4. Compute a coverage figure alongside every metric. For each tile, record how many matters were in scope, how many had the required fields, and what fraction was therefore excluded. Ship that number on the tile, not in an appendix.
5. Refresh pending and decided matters on different schedules. A decided matter is immutable and never needs re fetching. Pending matters move at the tempo of hearings, so a weekly or per listing refresh is sufficient and a polling loop is not.
6. Reserve the AI endpoints for depth, not for volume. Semantic search at POST /search/cases/semantic and the analysis at GET /cases/:id/analysis consume AI credit and run against a corpus far smaller than the keyword index. They are the right tools for enriching a shortlist, and the wrong tools for computing a population statistic.

What Firms Actually Open Twice

The final test of a litigation dashboard is not whether it demos well. It is whether anybody opens it in week three. The tiles that survive have one property in common: they answer a question somebody was already asking, with a number they can act on.

For a disputes practice, that is typically the tempo view. How many of our matters are listed in the next three weeks, in which courts, at which stage. Which matters have not been listed in ninety days. Which matters are approaching a limitation boundary under the Limitation Act 1963. None of these requires an inference, and all of them change what somebody does that afternoon.

For an in house team, it is exposure and tempo together. Matters by business unit, by court, by stage, with the count of matters whose next hearing falls inside the reporting period, and the distribution of how long comparable matters in the same court and case type have historically taken. That last figure is a planning input, not a prediction, and framing it as a planning input is the difference between a metric a general counsel uses and one they quietly stop trusting.

For anyone doing diligence, the useful output is volume and pattern rather than prediction: how many matters, in which forums, under which provisions, at what stages, with what proportion still live. That is a description of exposure, it is fully supported by the published fields, and it is what the person reading the report actually needed.

Notice that none of these is a prediction and none requires a judge level statistic. Indian litigation analytics does not fail because the data is too poor to support useful products. It fails because it keeps trying to build the American product. Start from what the registries publish, be explicit about what is missing, and the honest dashboard turns out to be more useful than the impressive one. The field reference for every endpoint is at the API documentation, and the coverage behind it is set out at the API overview.