Section 05

Court Coverage

Which courts come first, what reconnaissance of the old codebase reveals about each, and the migration hazards that must be resolved before any of it is trusted.

Priority courts

The agreed focus: Supreme Court, District Courts (eCourts), Tribunals, and the High Courts of Allahabad, Punjab & Haryana, Patna and Delhi, with High Courts leading.

Everything below was measured from the old tree rather than assumed. Several findings change the sequencing.

Three findings that change the plan

1. Punjab & Haryana has a clean public JSON API easiest, not hardest

The old repo contains a detailed reconnaissance set under phhc-skills/ — and it documents something valuable. The court runs a Next.js 14 frontend over a FastAPI + PostgreSQL backend at livedb9010.phhc.gov.in, and that backend is:

• Publicly accessible without authentication
• Not behind the bot protection. The PerimeterX/HUMAN script guards only the new.phhc.gov.in frontend domain
• Free of any captcha on the API path
• Free of the CSRF token requirement, which applies only to HTML navigation

No HTML parsing, no captcha model, no browser. This is the cheapest connector in the entire fleet and the strongest possible proof of the connector interface — which is why it should be first.

2. All district eCourts share one codebase and one captcha highest leverage in the fleet

The captured markup shows every district court portal running ecourtindia_v6 with Securimage, the open-source PHP captcha library — 175 and 112 references respectively across the old repos.

The consequence is large: district courts are not hundreds of integrations. They are one connector and one captcha model, parameterised by state and district. A single Securimage-trained model plausibly unlocks the majority of India's district judiciary at once — by far the best coverage-per-effort ratio available.

3. Patna High Court is three years stale — and is deferred out of M1

Of the priority courts, patna_hc was last touched 25 July 2023 — roughly three years ago — against a fleet where the other priority repos were updated within the last month. It also carries 9 Selenium files, the transport that costs 50–100× an HTTP call.

Decision: Patna is out of scope for now and moves to the M6 fleet migration. When it is picked up, it should be a fresh HTTP implementation rather than a port — migrating three-year-old Selenium code would preserve both the cost problem and the fragility.

Migration hazards in the old repositories

Note the recurring pattern: each rewrite created a new repository rather than replacing the old one. Version numbers in names are not reliable — ecourt-allahabad-2.0 is older than the unnumbered highcourt-allahbad. This is the clearest possible argument for the single-monorepo decision, where a connector has one location and a git history.

Benches are not separate courts

The old tree has highcourt-allahbad and highcourt-lucknow as separate repositories. They are one court — Allahabad High Court, sitting at Allahabad and at its Lucknow bench. The same applies to Punjab & Haryana High Court, which serves Punjab, Haryana and Chandigarh from a single seat.

This needs modelling properly, because it is user-visible: an advocate says "Allahabad High Court, Lucknow bench", not "Lucknow High Court".

court:
  id: allahabad-hc
  name: "High Court of Judicature at Allahabad"
  benches:
    - id: allahabad-hc.allahabad
      name: "Allahabad"
      base_url: "https://allahabadhighcourt.in"
    - id: allahabad-hc.lucknow
      name: "Lucknow Bench"
      base_url: "https://elegalix.allahabadhighcourt.in"
  connector: allahabad_hc        # one connector, bench as a parameter

One connector, bench as a parameter. The alternative — a connector per bench — is how the old system ended up with two repositories that must be fixed twice whenever the court changes anything shared.

The M1 four

Chosen to prove the connector interface against the widest possible variety, rather than to maximise court count. If the abstraction survives these four, it will survive the remaining sixty-six.

With Patna deferred, M1 is smaller and faster — a good outcome for the riskiest milestone in the plan. The four remaining courts still cover the four distinct connector shapes that matter: a clean API, a captcha-and-benches court, a parameterised multi-instance court, and a non-image captcha.

Delhi High Court is deliberately held back to M2 despite being a priority. It is a conventional HTTP-plus-image-captcha court, which by then will be well-trodden ground — it adds coverage rather than information, and M1's job is information.

Tribunals

Fourteen repositories of widely varying age — tribunals, tribunals-NGT, tribunals-itat, ngt, NCLT-services, NCLAT-services, DRT, DRT-2.0, DRAT-services, AFT-Delhi, aft-chandigarh, cgit, confonet2.0, vaad. Two are empty of Python entirely.

Tribunals are lower priority than the High Courts for M1 and belong in the M6 fleet migration, with one exception worth noting: DRT, reat-serveces and DRAT-services are the only three repositories appearing in any deployment manifest. That may indicate they are the most recently or carefully deployed services — or simply that the manifests were abandoned mid-use. Worth resolving during the live-server audit, since it is the only deployment evidence that exists.

Coverage roadmap

Coverage is never limited by subscription plan — see Tenancy, Roles & Plans. Restricting which courts a plan may track would make the product worse at its one job while saving nothing, since cost scales per matter rather than per court.