The skill nothing else does: read every document on the case, end to end, and produce the findings list an experienced attorney would produce after an afternoon with the physical file. About four minutes. Money found, deadlines surfaced, body parts cross-checked, defense mistakes flagged.
At the prompt:
aaicase> audit DoeThe skill first confirms before starting (“This will read all documents on the case and may take several minutes. Proceed?”) because it is the heaviest run in the system — downloading every PDF on the case, reading each one, then cross-referencing what was found against what Merus knows.
The output is organized exactly the way an experienced attorney organizes their own audit notes: urgent findings first (deadlines, violations, missing filings), then data discrepancies, then missing data, then recommendations. Every finding cites a specific upload ID and page number so the attorney can verify in seconds.
This matters because Workers’ Comp documents are full of things text extraction breaks on: scanned medical records, handwritten doctor notes, signature blocks, checkbox forms, stamped exhibits, two-column QME reports, redacted carrier letters, and faxes-of-faxes that have been through three printers. A text extractor returns garbage from any of those; the audit reads them like a person reads them.
It also means the audit catches things that text-based tools cannot: a checkbox marked “permanent and stationary” on a PR-4 form, a stamp showing a denial date, a body diagram with a circled lumbar region. Those signals carry case value. They don’t survive a pdftotext pass.
This is a CI-guarded architectural rule in the codebase. Any commit that re-introduces a text-extraction dependency fails the build.
If you give it a name, the skill resolves to a case ID first via merus-search. Then a single bash block fires five parallel fetches:
/caseFiles/view/[CASE-ID] → header, applicant, comments
/tasks/index → open tasks (filtered to case)
/events/index → events (filtered to case)
/activities/index/[CASE-ID] → every activity
/parties/view/[CASE-ID] → all partiesRequired: case + tasks + events + activities. Optional: parties. If parties fails, the audit notes “parties cross-reference skipped” and continues.
Then the document phase. For each upload on the case:
which gs before attempting).mktemp -d and locked to owner-only permissions (chmod 700).At the end, the temp directory is deleted. Nothing about the case lives on disk after the audit completes.
Five categories of findings, computed by comparing what each document said against what Merus knows:
| Category | Examples |
|---|---|
| Data integrity | Wrong ADJ number on a document vs. Merus, dates in the future, stale or missing case-comments summary, parties mentioned in documents but not in the Merus parties list. |
| Body parts | Doctors treating body parts that aren’t in the Application for Adjudication — amended application needed. |
| Money on the table | UR/IMR denials never appealed, LC 4610 timing violations (no UR response within 5 business days → treatment presumed authorized), missing TD on a case with active work restrictions, IMR denials on the wrong diagnosis. |
| Deadlines | QME reports received in the last 30 days without an objection filed (8 CCR 31.5(a)), defense DORs without our response, calendar events with no follow-up activity. |
| Defense mistakes | Late UR responses, defense advocacy letters to QME without our counter-letter, carrier paying wrong TD rate, defense subpoenas we were never served copies of. |
This is the single highest-value check the audit does. The Application for Adjudication lists the body parts at issue. Medical records over the life of the case routinely document treatment for other body parts that emerged later — a knee injury that later affected the back, a shoulder injury that produced neck symptoms, a foot injury that produced a knee compensation pattern.
If the application says “low back, right knee” and the audit finds the PTP treating the cervical spine and left shoulder, the audit flags it. That’s an amended application. That’s also a direct increase in case value — PD ratings on body parts not in the application are not recoverable.
Attorneys catch this sometimes. They don’t catch it consistently. The audit catches it every time, on every case it runs against.
Every UR or IMR denial in the activity feed gets cross-referenced against subsequent activities for an appeal filing. If there was a denial and no appeal within the 30-day IMR window (LC 4610.6), the audit flags it — with the date of the denial, the deadline that passed, and the upload ID for verification.
An RFA followed by no UR decision within 5 business days creates a presumption the treatment is authorized. The audit walks every RFA-to-UR pairing in the documents and flags any pair that violates the timing. This is one of the most reliable money-finders in the practice.
If the medical records show a current work restriction and the activity feed shows no TD activity, the audit recommends a demand for retroactive TD plus LC 5814 penalties — with the date the work restriction started so the demand can be computed.
IMR decisions are tied to specific diagnosis codes. If the IMR denied treatment for diagnosis A but the PTP’s request was for diagnosis B, that’s an appealable error. The audit reads both documents and pairs them up.
The audit looks for the procedural fouls defense attorneys routinely make:
The audit ends with two write-back steps:
A comprehensive case summary written into CaseFile.comments. Capped at 10,000 characters; if the audit is longer than that, the summary is truncated with a pointer back to AAI for the full version.
If comments already exist, the skill stops and shows them to the attorney first — with an explicit question: “The case already has comments — overwrite them with the new summary, or append?” The audit will not silently overwrite the attorney’s existing case summary.
One task per actionable finding. Every task starts with a verb (CALL, FILE, DEMAND, PREP, OBJECT) and includes specific names, dates, and references. Tasks are assigned to the case’s attorney_responsible by default; if no attorney is set on the case, the skill asks the user who to assign to. No “VERIFY (auto)” or “Review filed orphan” noise — that pattern is what the audit exists to clean up, not produce.
| Health check | Audit | |
|---|---|---|
| Time | ~60 seconds | ~4 minutes |
| Source data | Merus API (header, tasks, events, activities, parties, injuries) | Every PDF on the case, read natively, plus the same Merus data |
| Finds | Staleness, exposure flags, ethics gaps, milestone misses, pre-computed SOL/5410 deadlines | Misfiles, body-part mismatches, every leverage point, defense mistakes, missing follow-ups — with page-cited evidence |
| Writes back | Nothing (read-only) | Updates case comments, creates action tasks |
| Run before | Any client call, status conference, reassigning a case | Taking over a case, preparing for trial, large settlement push, after a long period of inactivity |
If a health check raises a serious flag, an audit is the natural next step — same case, deeper look.
Despite the names, these are different skills:
The audit is about case strategy. The audit case is about file integrity. Both belong in the toolkit; they are not substitutes.
The audit will still run, but expect 6–10 minutes instead of 4. Files over 50 MB are flagged and the skill asks before reading them. The audit completes even if some large files are skipped — it just notes them in the findings.
The skill needs gs to split very large PDFs. Install with brew install ghostscript (mac) or winget install ArtifexSoftware.GhostScript (Windows). Then re-run.
It shouldn’t have. The skill is built to stop and ask before overwriting existing comments. If this happens, it’s a bug worth reporting. Your previous comments are in the case’s activity history — comments edits are logged as activities and can be restored from there.
Most often the body part in question is in a PDF that wasn’t in the first 5 pages of any document. Re-run with the “read full documents” option if you have a specific report in mind, or open that upload directly with read upload [id].
The parties endpoint timed out or returned an error. The rest of the audit ran. If you want the parties check, just re-run — transient API issues are the usual cause.
Part of AAI for MerusCase — code-guarded AI case intelligence for California Workers’ Comp attorneys.