A law firm's daily mail arrives as a wall of scanned paper — hundreds of pages, dozens of documents, all mixed together. This system reads it the way a person would, decides what each piece is, files it on the right case, and when a medical report comes through, it computes the permanent-disability rating and shows its work. Here's how, and why it isn't like anything else that does this.
In workers' compensation, the mail is the case. Utilization-review denials, medical-legal reports, hearing notices, benefit letters, records bundles — the file moves forward through paper, and deadlines run whether anyone opened the envelope or not.
A single day's mail can be a 2,000-page scan holding forty separate documents for forty different clients, from a dozen different senders, in no particular order. Someone has to pull each one apart, figure out what it is, find the right case, file it correctly, calendar any deadline, and flag anything that needs a lawyer. It's the work that quietly eats an afternoon and where a missed page becomes a missed deadline.
Then there's the sharpest task of all: when a doctor's rating report arrives, someone has to turn the medical impairment into a permanent-disability percentage — a lookup-table computation that decides what the claim is worth. Firms have used rating software for this for twenty years. It works, but it's a closed box: you type in numbers, it hands back a number, and the derivation is invisible.
This system does both jobs — the sorting and the rating — and it does them in a way that is auditable at every step.
The scanner finishes a batch: 2,094 pages. Inside are 43 separate documents — a denial for one client, an approval for another, a delay letter, a hearing notice, a 1,438-page records bundle, several medical-legal reports — for forty-odd different people, from a handful of different claims administrators, the review organization, and the appeals board, in whatever order they fed the scanner.
By the time anyone opens it, the system has already gone document by document: separated the stack, read each piece, matched it to the right case, filed it under a conforming name, calendared the deadlines, assembled the appeal packets for the denials that qualify, and left each case manager a task explaining what arrived and what needs doing. What waited on a desk was a wall of paper. What's there now is forty-three handled items and a short list of the ones that need a lawyer's eye.
Everything starts with reading, and the reading is different from what most "AI document" tools do.
Native reading — no OCR, no text-scraping
Most tools run optical character recognition: they guess at the letters, produce a noisy text transcript, and reason over that. This system hands the actual page images to the model and lets it read them directly — the way a person reads a scanned letter. A smudged fax, a stamped signature, a handwritten note in the margin, a table that OCR would scramble — it sees all of it in context. There is no lossy transcription step to introduce errors.
On top of that native read sits the principle that governs the whole system:
Reading a document is judgment — what kind of letter is this, whose case, what's the determination. That belongs to the model. But a rating, a deadline, a filename that has to follow a standard — those must be exact, so they belong to code. The two are kept strictly apart. The model never "estimates" a rating; code never guesses what a document means. Blurring the two is how you get an answer that's confident, plausible, and wrong — and this system is built specifically not to do that.
Why native reading earns its keep shows up in the cases a text-scrape would fail. A 1,438-page bundle arrived that, on a keyword scan, looked like many patients — different reference numbers on interior pages, even another person's caregiver log filed as evidence. Reading it in context, the system recognized it correctly as one client's complete records submission and filed it whole, on the right case. Or the everyday task of building an appeal: the client's signed HIPAA authorization and representative form sit buried inside a 25-page intake packet — on page 6 in one client's file, page 20 in the next, somewhere else again in the third. The system finds them by reading what each page is, not by counting to a fixed page number. OCR gives you noisy letters; this gives you meaning.
A scanned batch goes through the same sequence, one document at a time, start to finish before moving on. Each step is tagged by who does it — model reads and judges, code computes exactly, human confirms.
The day's scan is one giant PDF. On-device vision detects the separator cover sheets between documents and cuts the stack into individual files — with a fail-loud guard: if it can't find clean boundaries, it refuses rather than lumping documents together.
2,094-page batch → 43 documentsNative read of the actual pages. It pulls out who the document is about, the claim and case numbers, the sender, the determination — exactly as written.
It searches the case-management system by the injured worker's name, then confirms the match by claim number, date of injury, and employer. If it isn't confident, it stops and flags — it never guesses which case a document belongs to.
An e-served copy may already be on the case. It checks the matter's recent documents so the same letter isn't filed twice.
Under the governing rules: is this an approval, an appealable denial, an administrative matter that belongs at the appeals board, a delay letter, a records bundle? This is judgment about the content, not just filing.
Uploaded to the right case with a filename that follows the firm's naming standard (claim number, never the client's name), tagged, and — for legal mail — any hearing or deadline placed on the calendar for the handling attorney.
The matter's case manager gets a task and an email explaining what came in and what needs doing — written to be checked, not trusted. For an appealable denial, it assembles the entire appeal packet and sends it to the filing service before the deadline.
Proven at real scale
This isn't a demo. It has processed two live production batches end-to-end against the firm's real case system — 2,094 pages / 43 documents and 863 pages / 86 documents — including a single 1,438-page records bundle it correctly recognized as one client's file, and roughly two dozen full appeal packets it assembled and filed with the state's filing service.
It's easy to say a tool "understands" a document. Here's the concrete version — the judgment calls it makes that separate reading from sorting:
Filing a document is the easy part. Knowing which clock it starts is not. A denial can carry a 30-day appeal window, or a 10-day one when the dispute is only about a drug's formulary status — and getting that wrong forfeits the client's appeal. Some denials look appealable but aren't; some toll the clock because a required form wasn't enclosed; some belong at the appeals board on an entirely different timeline. The system reads the determination to decide which rule applies, and when a deadline is short, uncertain, or looks like the formulary trap, it treats it as a fail-safe: flag it, don't quietly assume. A missed deadline is the one error that can't be undone, so the system is built to be loud about them.
Here is where the two halves of the system meet — and it's the part that's genuinely novel.
When the mail pipeline reads an incoming document and recognizes it as a medical-legal rating report — a QME or AME evaluation that assigns a whole-person impairment — it doesn't just file it. It hands the facts it read straight into the rating engine. The same read that sorted the mail becomes the input to the computation. The document arrives; a filed rating and a plain-English breakdown come out the other side.
One continuous motion
Read the report → extract the impairment, method, and any pain add-on or apportionment → pull the age and occupation from the case file → validate the inputs for the classic extraction traps → compute the rating against the state's tables → write the attorney an email that shows every step. No re-keying, no separate rating program, no copy-paste between systems.
To see why that's worth anything, picture the same task without it. A rating report comes in. Someone has to notice it's a rating report and not one of the forty other things in the batch; open it; find the impairment number, the whole-person figure, the method the doctor used, and any pain or apportionment; open a second program — or a rating service — and re-type all of it; look up the client's age and job in the case-management system and type those too; read back a number; and then compose an email explaining what it means. Every hand-off is a chance to transpose a digit, grab the superseded figure instead of the current one, or use the age today instead of the age at injury. It's careful, slow work that a busy desk does under time pressure — which is exactly when those mistakes happen.
The system collapses that whole round-trip into the read it was already doing. The document that got sorted is the document that gets rated; the facts don't leave the machine to be re-entered, so there's nothing to transpose. And critically, the rating that comes out is the same file you'd get from the standalone engine — the pipeline doesn't do a rougher version of it. When a report flows through the mail, we do the rating exactly the way the dedicated rating tool does, because it is the same engine.
The rating rules are public and fixed — California's 2005 Schedule for Rating Permanent Disabilities, an 89-page book of lookup tables built on the AMA Guides, 5th Edition. The problem was never what the rules are; it's that applying them by hand is slow and the software that automates them is a black box. The engine is the opposite of a black box.
A rating is written as a string — this is the state's own format:
16.01.02.03 – 5 – [1.4]7 – 340F – 7 – 7% PD
impairment WPI earning-cap occupation age finalThe engine reproduces that string exactly, and every step is a real table lookup, not a guess:
| Step | What happens | Authority |
|---|---|---|
| Impairment → whole person | Regional values (upper-extremity, hand, leg, foot, finger) convert to whole-person impairment first | AMA Guides 5th Ed. |
| Future earning capacity | ×1.4 for injuries on/after 1/1/2013, or the FEC-rank table before that | Labor Code 4660 / 4660.1 |
| Occupation | Job title → occupation group → variant letter → adjusted rating | Schedule §§3–5 |
| Age | Age at injury adjusts the rating up or down by band | Schedule §6 |
| Multiple impairments | Combined Values Chart, with same-limb impairments combined at the regional scale first | Schedule §8 / Guides |
| Apportionment · prior awards | Non-industrial reduction, prior-award subtraction, statutory caps | Labor Code 4663 / 4664 |
It handles the hard cases a real rater faces — psychiatric ratings from a GAF score, the pain add-on and its per-injury cap, the statutory bar on certain post-2013 add-ons, continuous-trauma dates, the conclusive total-disability presumptions — and it converts the final percentage into weeks and dollars. Twenty-one distinct rating operations, all deterministic.
It flags what isn't its call
The engine does the legal math; the physician does the medicine. Whether grip strength is even ratable, whether two impairments add or combine, whether a rating survives an objection — those are the doctor's and the attorney's calls, under the Guides. The engine computes exactly once those are settled and flags the cases where the choice isn't its to make. It also refuses to rate on a missing age, and it catches the extraction traps a real report contains — a regional value fed as whole-person, a pain add-on already baked into the total, a rating a supplemental report already superseded.
A supplemental medical-legal report withdrew an earlier 12% grip-strength rating as unreliable and re-rated a forearm nerve at 5% whole-person. Here's the engine's read on the operative 5%:
16.01.02.03 – 5 – [1.4]7 – 340F – 7 – 7% PD ≈ 21 weeks, ~$6,090.
The part that matters: because the report withdrew the earlier 12%, the engine shows both, side by side —
The withdrawal is worth roughly 9 PD points and ~$10,000.
It doesn't argue the grip rating should have stayed — that's the attorney's call. It surfaces the opening: here's the swing, here's where the money is, worth a look. And every number in that email is computed by the same code, so it can never drift from the math.
Two kinds of tools already exist near this problem. Neither does what this does.
| Dimension | Rating programs firms use | This system |
|---|---|---|
| Gets its inputs | A person types them in by hand | Reads them off the report itself |
| Shows its work | A final number; derivation hidden | Every step of the rating string traced — WPI → 1.4/FEC → occupation → age — each a checkable table lookup |
| Bad inputs | Computes whatever you typed, silently | Flags the extraction traps before it computes — pain double-counted, a superseded figure, exam age vs. age at injury, apportionment sign, CT date-of-injury — and refuses on a missing age |
| Connected to the mail | No — a separate, standalone program | The mail feeds it directly |
| Verification | "Trust the vendor" | Matched to 8 independent professional ratings to the digit, plus a 15,840-rating consistency sweep with zero errors |
| Where it runs | A subscription cloud | Local, on the firm's own files |
| Whose tool it is | Often built and hosted by the other side of the aisle | Built for this firm, running on this firm's machines |
There's a quieter reason a standalone rating calculator can be the wrong choice, and it has nothing to do with features. Several of the best-known rating tools in this field are built and hosted by the defense — the same side the firm argues against. They're login-required cloud platforms: to rate a case, you type your client's impairment figures, apportionment, and the operative numbers into the other side's system.
Even assuming nothing is ever misused, that's the wrong default for an applicant's advocate. A rating is a position — the highest defensible number for the client — and a tool authored from the defense perspective is calibrated to read the schedule the way the defense reads it, not to press for the client. And the case data, by design, leaves the firm and lands on someone else's server. This system inverts both: it runs locally, on the firm's own machines, so a client's figures never leave the building, and it's built to work the case from the applicant's side. Nothing is submitted to anyone.
You could ask a general-purpose AI to "rate this report." It would give you a number — and sometimes it would be wrong, confidently, with no way to tell. That's the exact failure this system is engineered against. Here the AI never computes the rating; it only reads. The computation is deterministic code checked against the state's own worked examples. An AI that reads like a person but computes like a calculator is a different kind of tool than an AI that does both by guessing.
That's the real novelty, and it runs through the whole system, not just the rating: it reads natively instead of scraping, it separates judgment from computation, it fails loud instead of guessing quietly, it shows its work instead of hiding it, and it runs on the firm's own machine instead of shipping the client's file to someone else's cloud.
"Deterministic" only means reproducibly the same — not correct. Correctness had to be earned, and this is the part a black box can't show you.
Every rating it produces is framed, explicitly, as an estimate to verify against a formal rating — never a final determination. That honesty is the point. A tool whose job is to be checked should make itself easy to check, and should say plainly where its judgment ends and the attorney's begins.
Step back and the design is one idea applied everywhere. A person reads a document with judgment; a calculator computes a number with certainty. Most software collapses those into one — it either scrapes text and reasons over the noise, or it lets a model produce numbers it can't stand behind. This system keeps them separate on purpose, and hands each half to the thing that's actually good at it.
That single choice is why it can read a smudged fax and still be exact about a deadline; why it can sort forty documents by meaning and still refuse to guess which case one belongs to; why it can rate a medical report and still show every step so an attorney can check it. Reading and computing are different jobs. Doing each one honestly — and never pretending one is the other — is the whole thing.