How to review a cited case file
What arrives in your queue, how to read fact outcomes and citations, when to request a correction from the applicant, and how to close a case so the decision holds up later.
For operators, adjusters, and reviewers
What arrives in your queue
By the time a case reaches you, the agent has already done the intake work. The applicant filled out the form, uploaded documents, and answered follow-up questions. The agent extracted every fact your workflow asked for, attached evidence to each one, and ran the verification checks you configured. Your queue shows the result: cases ready for review, cases still waiting on the applicant, cases the agent is still processing, and cases you have completed.
Open a case that is ready for review and you get one workspace: the facts on one side, the source documents on the other. You review a structured case file where every claim points back to its source, so the raw document pile stays where it belongs, underneath the citations.
Reading fact outcomes
Every fact in the case file lands in exactly one of three states. There is no fourth state and no hidden sub-status.
- Resolved. The agent found a value and backed it with evidence. These facts are ready to accept as they stand.
- Needs input. The agent found something but cannot commit to it alone. Two documents may disagree, or the value may be plausible but unconfirmed. The card shows the candidate value and the question the agent is asking. You resolve it: approve the candidate or correct it.
- Failed. The agent could not resolve the fact and says so plainly, with the reason. A failed fact is never silently dropped. It sits in the case file until you or the applicant supply what is missing.
Work the exceptions, not the file. Resolved facts have already earned their status. Your attention belongs on the needs-input and failed cards, which the workspace surfaces as the blocking items between you and completion.
What a citation means
Every extracted fact carries its evidence: the exact quote from the source, the document it came from, and the page it sits on. Click the citation and the document viewer jumps to the highlighted passage. When a fact is corroborated across several documents, the card carries all the supporting spans and you can page through them.
This is the contract of the review. You never have to take the agent's word for a value. If the quote supports the value, you have confirmed the fact in seconds instead of re-reading the document. If it does not, that is your signal to correct it.
Where the agent flags disagreement
When a fact is collected on the form and confirmed against the documents, the card reports whether the two agree. A match is a strong signal. A mismatch shows you both values and how far apart they are, so a claimed amount that does not match the invoice arrives as a flag rather than a silent overwrite. These are the cards worth opening first.
Verification results sit alongside the facts as their own cards. Each one shows what the connected system returned, in that system's own words, so you weigh the answer rather than inherit a verdict.
Approving and correcting facts
For any fact that needs your judgment, you have two moves: approve the value as it stands, or correct it. A correction asks you for the new value and your reasoning. Both actions are recorded as a manual review with your identity, your rationale, and the timestamp, and they become part of the fact's provenance alongside the document evidence. A corrected fact is a resolved fact, and the case file shows who resolved it and on what basis.
Requesting a correction from the applicant
Some gaps only the applicant can close. When a document is unreadable, the wrong type, or expired, the case file flags it and the applicant can be asked to resubmit, in plain language, without exposing anything about your internal checks. Those are the only failure types that reach the applicant on their own. Everything else goes through you: use the request-information command to ask for specific facts or documents, and the agent handles the follow-up on your behalf.
One boundary is absolute. Verification results never reach the applicant. Which systems you check against, and what those checks found, stays inside your team. The applicant only ever sees a request for information, never the reason your systems raised it.
Completing a case
When every blocking item is cleared, you complete the case. Completion is a recorded decision, not a status flip: the case file, the fact outcomes, the evidence, and your review actions are captured as an immutable decision record. Every operator command along the way is already in the audit log with the actor and timestamp attached, from approvals and corrections through to assignments and escalations.
If something surfaces later, a completed case can be reopened, and the reopening is itself recorded. Nothing is ever silently edited after the fact. That is what lets you stand behind the case file in an audit: the trail from applicant submission to final decision is complete, cited, and permanent.
A working rhythm
- Open the next case that is ready for review.
- Scan the blocking items: needs-input and failed facts first.
- Check each citation against its value. Approve or correct.
- Open anything the agent flagged as a mismatch.
- Read the verification results.
- Request applicant input only for what genuinely requires them.
- Complete the case. The audit trail writes itself.
Most cases take minutes, because the reading, chasing, and cross-checking happened before the case reached you. Your time goes to the judgment calls.