The case pack
What the colleague actually sees: a two-line summary, four status chips, the regulatory clocks, a recommended action from a decision table the model can only select from, and an appendix where every conclusion is one click from its evidence.
Everything upstream exists to produce one screen. The case pack is what a colleague opens, and it is designed around a single claim: they should never have to investigate, only verify.
Five parts
1. A two-line summary. The only free-text the model writes for a human. It is scored against a rubric by a calibrated judge model in evaluation, and it is the only component where an LLM judge is used at all.
2. Four status chips. Classification · Documentation · Verification · Flags. Each is solved, needs review, or failed, rolled up from its finding under the platform’s fixed rule. A chip is a summary of evidence, never a claim on its own.
3. A deadlines panel. The regulatory clocks that apply, anchored on the moment the correspondence was received, not processed. The jurisdiction is fixed; the specific timelines and the state-level variations are config, agreed with compliance, so the panel can change without a release. The intent axis from classification (dispute, complaint, both, a query, a cease-and-desist, a data request, litigation) is what selects which clocks start.
4. A recommended next action. From a deterministic decision table keyed on four things: the intent, the verification outcome, the documentation outcome, and the highest flag severity. The model selects and justifies the action from the table; it does not invent one. The table lives in config, versioned, compliance-approved, and its key stays stable across taxonomy changes so evaluation results remain comparable release to release. Whether a documentation failure overrides everything else is a policy question in the table, not a branch in the code.
5. The evidence appendix. Every conclusion (every extracted value, every comparison, every flag) links to its highlighted source: the page and region of the letter or statement, or the warehouse field. The platform rule that a conclusion without a citation renders as an unverified suggestion is enforced here, visibly.
Write-back
The case pack is stored and served through an API for the review surface. Separately, a tools-only agent relays the conclusions back into the document management system as keywords on the case’s documents, so that the existing workflows there (the ones that route work to queues and teams today) pick up the results without anyone building a new integration on that side. This is advisory metadata a human still verifies, not an action. The field-to-keyword map is versioned config; the write is idempotent on case and pipeline version; a failure degrades the case to needs review with a diagnostic, never silently; every write is audited with the source field and its citation.
The override loop
What the colleague does next is the most valuable data the system produces. Every confirmation and every correction is captured per component into a label store. The override rate per component is the production metric; override reasons are reviewed weekly and drive the backlog; the labels refresh the golden set. A blind audit of confirmed cases runs alongside, because a case pack good enough that colleagues stop reading it is a risk the metric can’t see.
Non-goals, held
No autonomous customer-facing response. No automatic hold or account action: the system recommends with evidence; execution stays with the colleague and the downstream workflows. Non-English correspondence is detected and routed to a manual queue. Each of these is a place where an obvious “next feature” was explicitly written down as not this version, so that scope could be defended in a review rather than negotiated in a sprint.