Reporting
Objects — Event · Case state · Task — read live over the Record
Reporting is how a deployment sees the operation. Because state and the full event history are one queryable store, reporting reads the operation live — off the same record the work runs on, never a nightly export to a separate warehouse. A deployment runs a standard set of reports and dashboards and lets a privileged user query the store directly for an ad-hoc cut; both read current state, so where every case is, who holds it, and how long it has sat is answerable for the whole operation at once, in real time.
Live, off the record
Every queue movement, status change, assignment, actor, and dwell time is already an append-only event on the case across its whole lifetime. Reporting reads that store directly, so the figures a governing statute or reporting regime asks for are captured as the work happens rather than reconstructed after it. There is nothing to reconcile between a “real” store and a reporting copy — audit, retention, and analytics all read the same case-keyed events.
The standard reports
The platform-provided baseline is a set of reports and dashboards rendered in the application and queryable as the operation runs. They cover what every adjudication operation watches:
| Report | What it shows | Read by |
|---|---|---|
| Throughput | Cases opened vs. closed per period, broken down by case type and lane | Operation lead, supervisor |
| Age in each step | How long cases sit at each workflow step — median, 75th, 95th percentile | Operation lead, supervisor |
| Overdue cases | Cases past their workflow deadline, grouped by assignee and step | Supervisor, operator |
| Queue depth and aging | Open task count per queue and the oldest item’s age in each | Supervisor |
| Reviewer load | Open tasks per assignee, broken down by status (assigned, in progress, on hold) | Supervisor |
| Distribution outcomes | Distribution runs over time — what got assigned, by lane and assignee, with the lever set on each | Operator, operation lead |
| Decisions per issue type | Disposition breakdown by issue type and category | Operation lead, quality reviewer |
| Session dispositions | Held / no-show / withdrawn / postponed rates by session type | Operation lead |
| Work-product evaluations | Author scores over time along the deployment’s defined factors | Quality reviewer, supervisor |
| AI disposition rates | Per-model accept / edit / reject rates for each suggestion kind (Issue, Task, relevance) | Operation lead, operator |
Quality and oversight
Quality review is a task that scores an author’s work product along defined factors; those scores read back here, so complexity and quality per reviewer sit on the same record as the work — not a spreadsheet on the side. An operator reads the operation itself: the configuration changes recorded over a period, the distribution runs that completed or errored, and the integration adapters reporting healthy or failing.
Ad-hoc, over live state
Beyond the standard set, a privileged user queries the store directly for a cut the standard reports don’t carry — a slice by party, by issue type, by adapter, by any data element the operation categorizes by. Because the query runs over live state, the answer is current as of the moment it’s asked.
Integrate or provide
The reporting tool itself is integrate-or-provide. A deployment binds the reporting port to a BI tool it already runs — the port serves reads (current state and the event stream) on a pull schedule the tool sets, and exposes the data elements the operation categorizes by so the BI tool’s dimensions match what authors and operators see — or it uses the platform’s own reports and dashboards. Either way the source is the one live record. Role-tailored dashboards put the high-level numbers in front of the people who run the operation, gated by the role each holds.