The targeted remediation. When an attorney spots a misfiled upload — or a pair that look swapped — this skill re-reads each PDF natively, identifies the correct target case from the bound content, proposes the move + rename + activity re-link, and executes the whole correction as one atomic, rollback-safe sequence. The API binding guard refuses the write if the proposed target doesn’t match the PDF’s applicant.
At the prompt:
aaicase> fix misfile on upload [UPLOAD-ID]
aaicase> uploads [ID-1] and [ID-2] are swapped
aaicase> upload [UPLOAD-ID] is on the wrong caseThe skill re-binds the suspect upload(s) by reading the PDF natively, compares to where they’re currently filed, and shows the diagnosis. The attorney approves; the skill executes the moves as a rollback-safe sequence; everything verifies.
It is the targeted remediation an attorney runs after spotting a specific problem — a filename that doesn’t match the case, a paralegal flagging a confused upload, a report that turned up on a case it doesn’t belong on. Not a firm-wide sweep.
| fix misfile | audit case | |
|---|---|---|
| Scope | 1–2 specific uploads | Every upload on a case |
| Triggered by | Attorney spotted a problem | Periodic file-integrity sweep |
| Cost | ~API budget (one or two binding extractions) | more for a 50-upload case |
| Time | ~3 minutes | ~5–10 minutes |
| Output | Targeted move proposal | Findings table across all uploads |
The relationship: audit case discovers misfiles you didn’t know about; fix-misfile corrects a specific one you already spotted. Either one ends in the same sequencer-based correction flow; they just enter the workflow at different points.
aai-bind downloads the PDF to a per-run mktemp -d dir (locked chmod 700), reads it natively with Claude vision, and produces an authoritative {applicant_last, applicant_first, claim_number, doc_date, doc_type} binding. The binding overwrites any prior binding in ~/.aaicase/queue/bindings.json./uploads/view/[ID] returns the upload’s current case_file_id and filename. /caseFiles/view/[CASE-ID] on the current case returns its applicant. Now the skill knows where the upload is vs. where it should be.merus-search on the bound applicant’s last name finds candidate cases. If multiple match, the skill narrows by first name + claim number, then asks the attorney to confirm if ambiguity remains.aai-sequence.mjs. The move + rename + activity re-link runs as one atomic operation with full rollback support.~/.aaicase/audit.log.2026-05-08-da-letter-qme-panel-strike-roe.pdf might actually be a Doe document with a misleading name. The binding is from PDF content via Claude vision — not text extraction, not filename parsing.
This is the same rule that runs through the rest of AAI — mail processing, audit, audit case — and it’s why fix-misfile works at all. If the skill trusted filenames, it couldn’t correct anything; the misfile would have a misleading filename by definition.
Re-binding always overwrites the cached binding. The skill never uses a stored binding for this correction — it has to know what the PDF says right now, not what it said the last time someone ran a binding.
MISFILE DIAGNOSIS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Upload #[UPLOAD-1]
PDF content (re-bound): DOE, JANE [doc: 2026-05-06 Subpoena Noncompliance]
Currently filed on: ROE #[CASE-ID-2] ← WRONG
Current filename: 2026-05-08-da-letter-qme-panel-strike-roe.pdf ← WRONG NAME
Should be filed on: DOE #[CASE-ID-1]
Upload #[UPLOAD-2]
PDF content (re-bound): ROE, MARIA [doc: 2026-05-08 Defense Panel Strike]
Currently filed on: DOE #[CASE-ID-1] ← WRONG
Current filename: 2026-05-06-subpoena-noncompliance-second-notice-doe.pdf ← WRONG NAME
Should be filed on: ROE #[CASE-ID-2]
DIAGNOSIS: classic swap — the two uploads have their cases (and filenames) crossed.
PROPOSED FIX:
1. ⭐ Move upload #[UPLOAD-1] from ROE #[CASE-ID-2] → DOE #[CASE-ID-1]
+ rename to: 2026-05-06-subpoena-noncompliance-sample-copy-doe.pdf
2. ⭐ Move upload #[UPLOAD-2] from DOE #[CASE-ID-1] → ROE #[CASE-ID-2]
+ rename to: 2026-05-08-da-panel-strike-defense-counsel-roe.pdf
3. ⭐ Also fix the linked activities (re-link each to the new case)
Activity [ACT-1] (currently on ROE) → DOE, with right tag
Activity [ACT-2] (currently on DOE) → ROE, with right tag
S. SKIP — don't change anything
Q. QUITThe diagnosis is descriptive, not prescriptive. The diagnosis tells you what the data says; the proposed fix tells you what AAI is about to do. Both stop and wait for the attorney’s green light.
Following the canonical approval flow (shared with process mail and process messages), the attorney can edit any field before approving:
After every edit, the proposal is re-shown with the updated values. Nothing writes until the final approval.
A misfile correction is a multi-step write. Moving an upload also means moving the linked activity. If the activity tag is wrong, the activity is soft-deleted and recreated with the right tag. None of these steps is safe to fail halfway through.
Every correction runs through aai-sequence.mjs. Each step has an args and an undo_args. If step 2 fails, the sequencer rolls back step 1. The case never lands in a half-corrected state where the upload moved but the activity didn’t.
For reassignment-style edits (the common case), the undo uses undo_args — the original case_file_id and filename captured before the move, so rollback is a single deterministic write. For delete-and-recreate steps (when the activity tag has to change), the undo uses undo_template — the new activity’s ID is captured from the response and templated into the undo.
aai-sequence prints structured JSON to stdout:
ok: true — all steps committedok: false + undone populated — failure cleanly rolled back; nothing in Merus from this attemptok: false + undo_errors or irreversible non-empty — rollback incomplete; surface for manual cleanup via bin/aai-undo.mjs --show <label>merus-fetch refuses any /uploads/edit write that would move an upload to a case whose applicant doesn’t match the stored binding.
The flow:
POST /uploads/edit/[ID] case_file_id=[DOE-CASE-ID].This is the safety property that motivated the skill in the first place: moving a misfiled upload to a case whose applicant doesn’t match would re-misfile it. The guard catches that. The same guard also enforces filename conventions — if the proposed filename doesn’t include the correct applicant’s last name, the write is refused.
After the sequence completes, the skill verifies in three ways:
/uploads/view/[ID] — confirm case_file_id now equals the correct target case and description matches the proposed filename./activities/index/[CORRECT-CASE-ID] — confirm the linked activity is on the new case with the right tags.aai-bind again — confirm the PDF content still maps to the applicant on the (now-correct) case. This catches the rare edge case where moving an upload somehow affected its content.The verify output:
FIX VERIFIED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✓ Upload #[ID-1] now on DOE #[CASE-ID-1] (was ROE)
Filename: "2026-05-06-subpoena-noncompliance-sample-copy-doe.pdf"
Re-bind: DOE (still matches)
✓ Activity #[ACT-1] reassigned to DOE #[CASE-ID-1] with tag [27960 Subpoena]
✓ Upload #[ID-2] now on ROE #[CASE-ID-2] (was DOE)
Filename: "2026-05-08-da-panel-strike-defense-counsel-roe.pdf"
Re-bind: ROE (still matches)
✓ Activity #[ACT-2] reassigned to ROE #[CASE-ID-2] with tag [47955 DA Letter]If verify fails on any step, the skill stops and shows expected vs. actual — the attorney decides whether to retry, accept, or quit.
/uploads/edit moves the upload without re-uploading. The PDF stays in Merus.
The reasoning is the same as audit case: a deleted upload is gone; a reassigned upload is restored to its correct home. Reassignment is reversible (the audit log records where it used to be); deletion is not. Integrity is restored by moving the record, not by erasing it.
This applies even when the misfiled upload looks like a clear duplicate. Reassign to the correct case; the attorney decides whether to use the Merus UI to clean up the duplicate outside AAI.
aai-bind couldn’t determine the applicant — rare, but happens with cover sheets, blank pages, heavily redacted documents. The skill stops and tells the attorney; they can supply the right case manually with an explicit override (logged loudly in the audit), or open the upload directly via read upload [id] and decide.
The re-bind matches the current case’s applicant. The skill responds: “Upload #X is already correctly filed on [case]. Nothing to fix.” The attorney may have suspected a misfile that isn’t there — common, and the skill confirms the file is clean rather than inventing a correction.
The skill does them one upload at a time. Each fix is independent and runs through its own sequence. A three-way swap is three separate runs, not one nested operation — this keeps each correction atomic and rollback-safe.
The current_case_file_id resolves to a deleted/archived case. The skill flags this and offers to move to the right case via the standard reassignment write. The orphan reference is the “wrong” side; the binding tells you the “right” side.
The skill prefers an in-place tag edit over the delete-and-recreate flow when most tags are correct. If all the tags need to change, the delete-and-recreate sequence runs; if just one or two are wrong among many, the activity is edited in place.
The merus-fetch binding guard rejected the proposed move because the target case’s applicant doesn’t match the upload’s bound applicant. This is the guard doing its job. Re-check the diagnosis — usually the proposed target case is the wrong case (the skill suggested one, the attorney edited it, the edit was wrong). Re-run the search by the bound applicant’s name to find the right case.
A later step in the sequence failed, so the earlier step was undone. The case is back in the state it was before. The skill tells you which step failed and why — usually a transient API issue (re-run) or a permissions issue (the API token doesn’t allow the specific edit). Check the audit log for details.
That shouldn’t happen — the sequencer either commits both or rolls back both. If you see this state, run aai-undo with the sequence label to fully revert, then re-run the fix.
The skill found the wrong linked activity (an upload can have multiple activities referencing it). Stop, run aai-undo to revert, and re-run the fix with the specific activity ID instead of letting the skill pick.
Unlikely but theoretically possible — the upload’s content somehow changed between the initial bind and verify. The skill stops and surfaces both bindings. If the verify-bind looks correct, the initial bind was wrong; if the verify-bind looks wrong, you may have a deeper Merus data issue. Either way, don’t accept the fix without understanding what changed.
Part of AAI for MerusCase — code-guarded AI case intelligence for California Workers’ Comp attorneys.