Skip to content

Process Status Dashboard

A live status monitor — instantiates Transparency for Accountability

Shows each item's current stage in a process, continuously refreshed, so anyone affected can see where a decision stands without having to ask.

A Process Status Dashboard exposes, for every item moving through a process, exactly which stage it currently sits at — and keeps that view current. Its distinguishing claim among transparency mechanisms is positional and temporal: it answers "where is this right now?" for the affected party, and its value collapses the moment it goes stale. It is not the reasons behind a decision and not the permanent record of the outcome; it is the live map of position in the flow. It also sits pointedly apart from an observability-style monitor: it displays a declared, disclosed stage that the process owner commits to, not an internal state inferred from signals.

Example

An applicant for a restaurant build-out used to phone the municipal permit office weekly to ask where things stood. The dashboard shows the pipeline — Received → Zoning review → Plan check → Inspections → Issued — with her application pinned at "Plan check, entered 12 days ago, ~5th in the reviewer's queue, last updated this morning." When it stalls, the stall is visible to her and to the office's own managers; nobody has to place a call to discover that plan check has been sitting untouched for three weeks. The dashboard shifts the burden of chasing status off the applicant and puts quiet delay on display.

How it works

A shared, published stage model; every item tagged to exactly one stage; status driven automatically from the system of record rather than hand-typed; each tile timestamped with "last updated" and, where possible, an expected next step or ETA. The distinguishing discipline is freshness-by-construction: the dashboard reads from the operational system so a status can't drift from reality. It shows position, deliberately not rationale — the "why" lives elsewhere.

Tuning parameters

  • Stage granularity — a few coarse phases vs. many fine steps. Finer shows more but invites gaming and clutter.
  • Refresh latency — real-time vs. daily batch. Fresher is more trustworthy but costs integration.
  • Role-scoped views — what the public sees vs. staff. A broad public view builds trust; too much can expose private detail or queue-jumping.
  • Expected-time display — showing ETAs or queue position. Powerful accountability, but a missed ETA becomes its own complaint.
  • Staleness alarms — flagging items not updated within a window. Surfaces neglect, but needs a real owner to act on the flag.

When it helps, and when it misleads

Its strength is eliminating "where is my thing?" churn, exposing bottlenecks and quiet stalling, and moving the cost of chasing status off the affected party. A visible stall is a stall someone must answer for.

Its failure mode is that a status field is only as honest as what drives it. If stages are advanced by hand, a case can be marked "in review" while nothing happens — a green board that manufactures a false sense of motion. The classic misuse is the reassurance dashboard: bright status decoupled from the underlying work, run to look responsive rather than to be inspectable. The discipline is to drive every stage from the system of record and stamp "last updated" on everything, so staleness shows itself rather than hiding.[^radiator]

How it implements the components

  • process_stage_visibility — its core: each item's current stage, exposed against a shared, published model.
  • timeliness_and_update_cadence — the continuous refresh and the "last updated" stamp that keep the view honest; a stale dashboard implements nothing.

It does not record why a decision was reached (that is the Reason-Giving Template) or hold the durable index of outcomes (the Public Decision Log); the exhaustive, machine-readable event trail behind the status belongs to Audit Trail Export.

  • Instantiates: Transparency for Accountability — it makes process stage visible in real time, the position half of meaningful visibility.
  • Consumes: the system of record behind the process — it renders status, it does not decide it.
  • Sibling mechanisms: Public Decision Log · Audit Trail Export · Reason-Giving Template · Freedom-of-Information Response Workflow · Independent Oversight Portal · Plain-Language Transparency Report · Public Comment & Question Channel