Section 12

Live Display Board v2.0

A dedicated module, not a feature bolted onto the app: a screen a firm mounts in its office or a chamber corridor, showing who is listed where, today — updating on its own, with nobody logged into it.

Deferred to v2.0

Specified here in full so the domain model and pairing security are settled before it is built, but it ships after the v1 MVP — see Overview & Scope and Roadmap. Everything in this document assumes v1's matter tracking, notification, and multi-court practice scope (ORG_COURT) already exist, because the board is a read surface over that data — it introduces no new source of truth.

What it is

Physical court complexes already have a cause-list display board bolted to a wall — a screen or printed sheet nobody personalises. This module is that idea, run backwards: a screen the firm owns, showing only their matters, across every court and tribunal they practise in, grouped however the firm needs — by court, by assignee, by client.

The audience is whoever is in the room: a clerk checking who's due where before leaving for the complex, a partner glancing up mid-conversation, a client in the waiting area seeing their own case is accounted for. That last audience is why what the board shows gets its own section below.

Scope for v2.0

In scope	Explicitly not v2.0
Today's and tomorrow's listings, across every court in `ORG_COURT`	Historical playback or analytics on the board itself
Grouping by court, assignee, or client	Editing anything from the board — it is read-only by construction
Pairing a screen with a one-time code, no login	Per-viewer authentication on the screen
Tentative vs final labelling, matching the cause-list report	Push notifications originating from the board — alerts remain phone-first

Pairing, not login

A screen mounted in a corridor is a shared device with no natural owner and often no keyboard. Treating it like a user session — requiring sign-in, holding a personal token — is the wrong model: whoever can physically reach the screen can already see whatever it displays, so the access control question is which organisation's data appears here, not which person is watching.

sequenceDiagram
    actor Admin as Owner/admin (phone)
    participant API as API
    actor Screen as Board device (TV/browser)

    Screen->>API: GET /board/pair
    API-->>Screen: short pairing code, QR
    Admin->>API: enter code, choose board config
    API->>API: create BOARD_DEVICE, scoped to org
    API-->>Screen: long-lived board token (device-bound)
    loop every refresh interval
        Screen->>API: GET /board/{id}/state, board token
        API-->>Screen: current listings
    end

Fig 12.1 — Pairing a screen

The board token authorises a device to read one board's data — nothing else, no write paths, no other organisation's rows, enforced by the same row-level security every other tenant-scoped table uses. Revoking a device is the entire "logout" story: remove the BOARD_DEVICE row and the next poll gets rejected. No password to rotate, because there never was one.

"Realtime" does not mean websockets

The unit economics apply here too

A cause list changes once, maybe twice, a day. An order arrives a handful of times a week per matter. Nothing about this data justifies a persistent connection per screen, and every firm running boards in every office is exactly the kind of per-unit cost that the economic constraint already governs everything else in this system. A screen polling its own read path every 60–120 seconds is visually indistinguishable from push to a human reading it from across a room, and costs nothing beyond the request itself — no connection to hold open, no reconnect logic, no separate infrastructure.

Build it as polling. Revisit only if a real customer produces a real reason a two-minute lag matters — and be skeptical that one will, because the underlying events themselves don't happen faster than that.

The poll response is served from the same normalised matter/causelist tables everything else reads — see Domain Model — filtered by the board's ORG_COURT scope and grouping. No separate realtime pipeline, no fan-out service, no new failure mode to operate.

What the board shows

A board in a private office and a board visible to waiting clients are not the same product, even though they run the same code. The difference is one setting, not two builds.

Mode	Party names	Case numbers	Assignee names	Typical placement
Internal	Full	Full	Full	Staff-only room
Waiting area	Initials only	Item/court number only	Hidden	Client-visible reception

Default to the stricter mode

A board's placement changes over the life of a physical screen — offices get rearranged, a waiting area gets a monitor originally bought for the back room. Waiting area is the default for every newly paired device; an admin has to deliberately switch a board to Internal, not the other way round. Defaulting to the permissive setting is how a client's opponent's name ends up readable from a public sofa.

Example layout

┌────────────────────────────────────────────────────────────────┐
│  SHARMA & ASSOCIATES              Wed 12 Aug · updated 2 min ago │
├────────────────────────────────────────────────────────────────┤
│  PATNA HIGH COURT · Court 12                                    │
│  Item 4   CWJC/12345/2024   Kumar & Ors.        Priya Sharma   │
│  Item 17  CRWJC/889/2023    State vs. R***       Rahul Verma    │
├────────────────────────────────────────────────────────────────┤
│  PATNA DRT                                                      │
│  Item 2   OA/44/2024        Bank of I*** vs D*** Anita Desai    │
├────────────────────────────────────────────────────────────────┤
│  DISTRICT eCOURTS · Patna Civil Court                           │
│  Item 31  CS/210/2025       M*** vs N***          Unassigned  ⚠ │
└────────────────────────────────────────────────────────────────┘

Grouped by court first, because "which room do I need to be in" is the question a board answers before "which case." An unassigned listing carries the same warning marker as the workload view — the failure an agency buys this product to prevent looks the same whether it's on a phone or a wall.

Failure and staleness on a shared screen

A phone user sees a staleness banner and can act on it — refresh, call the court, check another source. A board has no one actively watching it moment to moment, which makes silent staleness worse, not better: a screen that freezes on yesterday's data looks identical to one showing today's.

Every render carries "updated N minutes ago", always, in the header — never omitted, never allowed to look current when it isn't.
If the board can't refresh for longer than 3× its interval, it shows a full-screen state: "Can't reach Clerkify — last known data from 8:14 am" — the same honesty rule as Case detail's stale banner, at board scale.
The device itself reports check-ins; an admin sees "last seen" per BOARD_DEVICE, so a screen that silently died in a corridor six days ago is discoverable without someone walking over to look.