Section 15
Roadmap
Milestones ordered by risk retired, with acceptance criteria. Estimates assume two engineers.
MVP definition
The smallest thing an advocate would pay for: track cases in a handful of courts, and reliably tell me when something changes. Not 70 courts. Not AI. Not analytics.
Picking the first courts by user concentration rather than technical ease is the right call — you want the MVP to be usable by a real cohort, not merely demonstrable.
Milestones
Monorepo, CI, Docker Compose local, Postgres schema with org_id and row-level security from the first migration, phone OTP auth, session and token design, secret management, OpenTelemetry.
Accepts when: a new engineer clones and has the stack running in under an hour; CI blocks a commit containing a secret; and the cross-tenant access test suite passes against every endpoint.
Tenancy and authentication belong in M0, not later. Retrofitting org_id and row-level security onto an existing schema means touching every table, every query, and every test — and the migration is exactly where isolation bugs hide. It is dramatically cheaper as the first migration than as the fortieth.
The Connector interface, court registry with bench support, scheduler, worker pool, golden-file tests, canaries, circuit breakers. Captcha solve path with the per-court model registry, porting the existing PaddleOCR work.
The four courts, selected for variety rather than count — see Court Coverage: Punjab & Haryana (clean JSON API), Allahabad (captcha + two benches), District eCourts (parameterised, highest leverage), Supreme Court (arithmetic captcha). Patna is deferred to M6.
Accepts when: four courts poll on schedule; a deliberately broken parser is caught by CI within one commit and by the canary within one hour; captcha acceptance rate is tracked per court.
Two things to run in week one of M1, because both can change the plan while it is still cheap to change:
1. The live-server audit. No manifest records which of the old repositories are actually deployed. Establish that before reimplementing anything — see Court Coverage.
2. The eCourts audio-captcha experiment. A day of work that could remove per-court captcha model training for a large share of the fleet. A positive result changes the M1 captcha scope materially.
Add/verify matters, change detection, hearing history, notification fan-out across WhatsApp, push, and email with delivery tracking. Delhi High Court added, plus one court that genuinely requires transport: browser. Includes the hearing date precedence columns and the reconciliation prompt from day one — not a later addition once next_hearing already has data in it.
Accepts when: a change at a court reaches the user's phone within the poll window; every notification has a recorded delivery status; browser transport works end to end with per-court concurrency honoured; and a user-set override date is never overwritten by a subsequent poll.
Browser transport moved here because Patna — which was carrying it in M1 — is deferred. All four M1 courts are HTTP, so nothing exercises the browser path. Treat it as a gate before M6: ~15 of the old repos still drive Selenium, and discovering that path is broken partway through a 66-court migration would be expensive.
Template-driven cause-list extraction with validation, LLM fallback for novel layouts, the template registry, matching with confidence levels, per-user PDF spanning every court in ORG_COURT, tentative-vs-final labelling (Flow 6), R2 storage, WhatsApp and email delivery.
Accepts when: users receive an accurate personalised cause list before the court day begins, covering every court they practise in in one document; a revised final list produces a distinct, clearly labelled report rather than overwriting the tentative one; and a page failing validation emits nothing rather than emitting suspect entries.
Flutter app on the new API, Next.js web and admin, Razorpay, onboarding, trials. Agency features: invitations, roles, assignment, bulk import, workload view. Request signing and app attestation.
Accepts when: an individual can sign up, pay, add cases and receive alerts unaided; and a firm can import cases in bulk, invite staff, and assign work. This is the MVP ship point.
Failed-captcha capture, perceptual-hash dedupe, the AI research queue, human review tool, shadow evaluation and promotion. The cause-list template editor with side-by-side PDF overlay.
Accepts when: a broken court captcha or a changed cause-list layout can be repaired by an operator — without an engineer and without a deploy.
Remaining ~66 courts onto the framework. Mechanical once M1 holds, and far cheaper once M5 ships. Parallel run with canaries as the cut-over gate.
Accepts when: every court is on the new framework with a green canary, and the old fleet is switched off.
Port the AI service, run a model bake-off on a real corpus, add confidence gating and human review.
Accepts when: summaries meet an agreed accuracy bar and no model-derived date is ever presented as authoritative.
Dependency graph
flowchart LR
M0[M0 Foundations
tenancy + auth] --> M1[M1 Connectors
+ captcha + 4 courts]
M1 --> M2[M2 Matter tracking]
M2 --> M3[M3 Cause lists
+ PDF parsing]
M3 --> M4[M4 Apps + agencies
MVP SHIP]
M1 --> M5[M5 Learning loops
+ review tooling]
M3 --> M5
M1 --> M6[M6 Fleet migration]
M5 -.makes cheaper.-> M6
M2 --> M7[M7 AI order review]
Fig 14.1 — Milestone dependencies
M6 and M7 branch off early and run in parallel with the critical path to M4, so a third engineer added at M1 has useful, non-blocking work immediately.
The dotted edge is a sequencing judgement rather than a hard dependency. M6 migrates ~66 courts; M5 builds the tooling that lets an operator fix a court without an engineer. Doing M5 first makes M6 substantially cheaper and means the fleet stays maintainable afterwards. Running M6 first is possible but pays the manual cost 66 times over.
Version roadmap
| Version | Theme | Contents | Rough timing |
|---|---|---|---|
| v1.0 | Reliable tracking | M0–M4 — core courts, captcha, alerts, cause lists, apps, agencies, payments | ~6 months |
| v1.5 | Coverage | M5–M7 — learning loops, full fleet, AI summaries | ~9 months |
| v2.0 | Practice tools | Client management, invoicing, per-case document vault, case settings, live display board, calendar sync — see Domain Model for the entities, specified now and deferred deliberately | ~10 months |
| v3.0 | Intelligence | Case-law search, outcome analytics, drafting assistance | ~18 months |
Principal risks
| Risk | Impact | Mitigation |
|---|---|---|
| Court sites block scraping | Critical | Respectful rate limits, per-court concurrency, identifiable user agent, cached results. Engage registries where possible. |
| Courts adopt reCAPTCHA | Critical | Not solvable in-house or affordably. Mitigation is commercial — official feeds, registry agreements — plus a product that can mark a court manual-only without breaking. See Captcha Pipeline. |
| Cause-list layout variance exceeds estimate | High | M3 is the least predictable milestone. Validate on the five M1 courts' real PDFs before committing the estimate; treat a template editor as in-scope, not optional. |
| Connector abstraction proves wrong | High | M1 proves it on four courts before committing 70 |
| Cross-tenant data leak | Critical | RLS from the first migration, CI isolation suite, external penetration test before the first agency customer |
| Poll cost exceeds revenue | High | CONNECTOR_RUN makes cost per court visible from M1; prefer HTTP over browser; adaptive poll frequency |
| Migration stalls mid-way | Medium | Parallel run; old fleet stays live until each court's canary is green |
| AI produces a wrong hearing date | High | Never authoritative, always attributed, confidence-gated |
| Rebuild delivers no new features for months | Medium | Genuine and unavoidable. Ship M4 as a real product to a real cohort rather than treating v1 as a migration. |
The one to watch
The last risk is the one that kills rebuilds. Four months of engineering with nothing shipped is where teams lose nerve, and the usual failure mode is abandoning the rebuild half-done — leaving two systems to maintain instead of one. M4 exists as a ship point for exactly this reason: it is a real product for a real cohort, not a checkpoint.
Open decisions
| Decision | Needed by | Status |
|---|---|---|
| Which courts for M1 | start of M1 | Settled — see Court Coverage |
| Which old repos are actually deployed | week 1 of M1 | Open — needs a live-server audit; no manifest exists |
| Does eCourts audio captcha work | week 1 of M1 | Experiment — one day, potentially large scope change |
| AI summary accuracy bar | start of M7 | Open — a practising advocate decides, not engineering |