Judiciary Entity Map: How open source can make India’s courts legible

India’s judiciary comprises roughly 1,500 distinct institutional entities, ranging from constitutional courts and subordinate courts to central and state tribunals, quasi-judicial regulators, arbitration bodies, investigative agencies, and oversight bodies. No public, machine-readable map of how they connect has existed.

In this talk, we would like to present JEM (Judiciary Entity Map), a FOSS civic infrastructure project that addresses this gap. JEM is not designed to track case outcomes or judicial precedents. Rather, it maps how institutions are built: who appoints whom, who funds whom, appellate chains, complaint pathways, and digital infrastructure dependencies. Additionally, it helps document structural gaps, such as bodies that were legislated but never constituted, appointer-litigant loops, and vacancy crises.

Our goal is structural literacy: a dashboard-oriented view of institutional carrying capacity for administrators, litigants, journalists, researchers, and policymakers.

At the time of writing, JEM contains 1,117 entities and 1,882 relationships, covering all 25 High Courts, all states and UTs, central tribunals, quasi-judicial regulators, and the full appointment and funding details between them. It can be a tool that aids legal researchers to study the judicial system at large both in quantitative and qualitative manner.

Imagine you’re a journalist trying to access information about the Armed Forces Tribunal (AFT). If you want to know who appoints its members, who pays for it, or what your options are if you want to appeal a decision, you’re in for a challenge!

You’d probably have to sift through the Armed Forces Tribunal Act, dig into Ministry of Defence budget documents, and then—hidden in a Supreme Court judgment—find out that there’s no appeal to a High Court, only a direct Special Leave Petition (SLP) to the Supreme Court. To make things even trickier, the Ministry of Defence is also the main party appearing before the AFT. This isn’t just a rare or unusual situation. It’s actually how things work across most of India’s judicial system. The facts about how these bodies are set up are out there in public documents – the Constitution, various Acts, government Gazettes, and Department of Justice reports. However, all this information is scattered and disconnected, and not easily accessible to people or computers. No one has consolidated it into a single, simple, searchable map, which is what JEM aims to do.

Here is a proposed (read: provisional) outline of our talk:

1. The gap (4 minutes)

• Why “structural literacy” is distinct from legal databases like SCC or Indian Kanoon

• The difference between what courts decide and how courts are built

• Three concrete examples of structural gaps that are invisible without a map

• The AFT appointer-litigant loop; and

• The Mediation Council of India (legislated in 2023, still not constituted); and

• The Allahabad HC running at 50% vacancy while handling India’s highest case volume.

2. What JEM is, and what it isn’t (10 minutes)

• Scope: appointment chains, funding flows, appellate hierarchy, supervisory relationships, audit bodies, complaint pathways, digital infrastructure, case volume indicators, structural gaps

• Out of scope by design: case outcomes, individual judge names, editorial commentary

• The Independence Risk and Discretionary Power scores: algorithmic indicators of structural design, not conduct judgments

• Licenses: the data is CC0 (public domain), and the code is MIT-licensed

3. Technical architecture (5 minutes)

• Data layer: there are 1,100 hand-authored YAML files, one per entity, organised by cluster and typed relationship files (appointments.yaml, funding.yaml, etc.)

• Pipeline: validate.py (Pydantic v2 schema enforcement) → derive.py (algorithmic score computation) → build.py (compiles graph.json)

• Frontend: vanilla JS + D3, no build step, semantic zoom across four levels (L0 cluster constellations → L1 entity backbone → L2 sub-entities → L3 detail card with sources and score breakdown)

• Relationship lenses: toggle between Appellate Chain, Funding, Appointment, Supervisory, Audit, Complaints, Digital, Security views of the same graph

• Data quality as a first-class citizen: font weight and node border style encode verified / complete / partial / unverified / contested / Not_Constituted — honesty about what is and is not sourced is built into the rendering

• AI-assisted data entry: how a structured prompt + schema enforcement lets AI agents (such as Claude Code or Cursor) generate schema-valid YAML at scale, with maintainer validation as the gate

4. A live demo (5 minutes)

• Walk through the map at https://friedso.com/apps/jem/

• Show the Appellate Chain lens from a District Court up to the Supreme Court

• Show an Independence Risk score breakdown (e.g., CESTAT: MoF is both funder and primary litigant via CBIC)

• Show a Not Constituted entity (Mediation Council of India) and what the gap registry captures

5. Our call to action (5 minutes)

• How our contributions work: GitHub issues for data-quality upgrades, Pydantic validation as the automated gate

• What the community can do right now: source verification, judge strength data from vacancy reports, NJDG case volume data

• The roadmap: per-district NJDG numerics (v1.3), live NJDG API (v2.0), canvas renderer for 60fps at 500+ nodes

• Our invitation: fork it, mirror it, build on it! The code is FOSS and the data is permissively licensed, too.

1. Structural transparency is a distinct problem from legal information. Knowing how a court is built, i.e., who appoints its members, who funds it, and whether the funder is also the primary litigant, is different from knowing what it has decided. JEM is the first, to the best of our knowledge, open and machine-readable attempt to map this across India’s entire judicial ecosystem.

2. Open civic infrastructure can be built with minimal tooling. JEM’s entire stack is YAML source files, a three-script Python pipeline (validate → derive → build), and a vanilla JS/D3 frontend with no build step. The absence of framework complexity is a deliberate choice that makes the project forkable and auditable.

3. Data quality must be encoded, not assumed. JEM treats unverified, partial, contested, and Not_Constituted as first-class states rendered visually in the UI. Structural honesty about what is and is not sourced is more valuable than a complete-looking but unreliable dataset.

4. Algorithmic scores on institutional design are possible and useful. Independence Risk and Discretionary Power scores are derived from structural attributes (appointer = funder? appointer = primary litigant? complaint pathway exists?) and not from opinions. This approach can be applied to any institutional ecosystem.

5. AI-assisted data entry at scale requires schema discipline, not prompt magic. The key to generating 1,100+ schema-valid YAML entities with AI assistance was a strict Pydantic schema, a canonical prompt, and a human validation gate.