Two review modes, never mixed
The same document checks answer two different questions, is the audit sample clean and is this account ready for legal, and running them under one configuration produces false rejections.
The records system has two customers with two questions.
The audit question: over this month’s sample, is the rules engine letting through accounts whose required documents are missing or wrongly indexed? The reviewer wants to know that the documents exist and are the right type. A balance that differs from the system of record is not an audit failure; the account was never being released on that basis.
The pre-legal question: is this account, now, ready to be placed? Every one of a dozen data points on the documents has to agree with the system of record, and the claimed balance has to be supported by an acceptable statement. Here a balance mismatch is exactly the failure being hunted.
The source material for this project, the team’s own process notes, warned explicitly that mixing the two produces false rejections: an audit run with pre-legal checks fails accounts for reasons that are not audit reasons, and the reviewer stops trusting the tool. So the mode became a first-class parameter, and the rule is that the two are separate configurations that never share a run.
What differs
| Audit mode | Pre-legal mode | |
|---|---|---|
| Presence + exceptions | yes | yes |
| Document-type authenticity | optional | yes |
| Field extraction | no | yes, with full evidence |
| Reconciliation against the system of record | never | yes, per approved rule |
| Balance support | never | yes |
| Verdict | pass / fail / review on presence and type only | pass / fail / review on everything |
Two orchestrators implement this. The audit orchestrator composes presence and, when enabled, type classification. The pre-legal orchestrator composes all five checks in parallel and assembles the full verdict. They share every component; they differ only in what they compose and in the config they load.
How it’s enforced
Not by convention. A work item carries its mode, the idempotency key includes the use case, and the evaluation suite has a mode-separation gate: on the golden set, an audit-mode run must never fail an account on a balance or a field comparison. If a change to a shared component causes an audit run to emit a reconciliation result, the suite fails the merge.
Why this is the most important decision in the project
Because it is the one that would have been easiest to skip. One orchestrator with a couple of flags would have worked on day one. The failure mode (accounts failing for reasons that don’t apply to the question being asked) would have appeared slowly, in the override data, as reviewers learned to ignore a category of fail. By then the tool’s credibility is gone and no metric recovers it. Separating the modes cost a second thin orchestrator and a gate. That is cheap insurance against the way these systems actually die: not by being wrong, but by being wrong in a way people learn to work around.