mass tort intake: grading volume without grading merit
most mass tort intake systems try to get an AI to answer the question that matters: does this person have a case. that is exactly backwards, and it is where the liability starts.
the moment a model outputs anything that reads like "this claimant likely qualifies" or "this injury meets criteria," you have a non-lawyer rendering a legal judgment, at scale, unsupervised, on live intake. nobody signed off on that opinion. nobody can point to the rule it applied. and if the volume is a thousand inquiries a week during an active tort campaign, you've generated a thousand unsupervised legal opinions before lunch.
the fix isn't a better prompt. it's refusing to let the model decide anything at all.
the wrong way to automate mass tort qualification
here's the failure mode plainly. someone feeds a call transcript or intake form into a language model and asks it to score the claim: strong, weak, pass. the model is good at sounding confident, so it returns a clean-looking score. the firm starts trusting the score. six weeks in, nobody remembers why a given claimant got routed to the reject pile, because the "why" lives inside a model's weights, not in a rule anyone wrote down.
that's three problems stacked on top of each other. first, an ethical one: grading legal merit is practicing law, and a model doing it without a lawyer in the loop is a real exposure, even if nobody intended it that way. second, a practical one: a model's judgment drifts. the same transcript run twice can get scored differently, and there's no stable logic to audit when a claimant or a bar complaint asks why they were turned away. third, an operational one: once the model is making the call, the firm has no deterministic artifact to show a regulator, a co-counsel, or an insurer auditing the funnel. there's a score, not a reason.
none of this shows up as an error message. the funnel runs. intake looks efficient. the risk sits quietly in the gap between "the model said no" and "a human can explain why."
the split: extraction versus deterministic decisioning
the entire fix is one architectural decision: the model reads, extracts, and routes. it never decides. a separate piece of code, written in plain logic that a lawyer reviewed and signed off on, makes the actual qualification call.
concretely: the model's job is to turn an unstructured call transcript or web form into structured fields. exposure dates. product or drug named. injury type as stated by the claimant. documentation mentioned, like diagnosis records or pharmacy history. nothing in that output is an opinion. it's extraction, the same category of work as OCR, just smarter about unstructured language.
then that structured output hits a deterministic function. this is regular code: if exposure_window falls inside the litigation's defined dates, and injury_type is on the qualifying list, and documentation_flag is true, route to attorney review. if any field is missing or ambiguous, route to a human intake specialist, not to rejection. the model never touches this step. it can't, because it isn't invoked here at all.
this split is why a decision can be audited line by line months later. you can point to the exact rule that fired, the exact fields that triggered it, and the exact transcript the fields came from. that's not true of a model's score, no matter how it's prompted.
step 1: capture the raw inquiry and freeze the original record
every inquiry, whether it's a call, a web form, or a referral email, gets logged verbatim before anything else touches it. the call transcript or form submission is written once to an immutable record inside the firm's own infrastructure, not a vendor's database. that record never gets edited. if a claimant later disputes how they were classified, the original words are still there, untouched by anything downstream.
this matters more in mass tort than in ordinary intake because volume creates pressure to summarize early and discard the raw version. don't. storage is cheap. a disputed classification six months later, with no original record to check, is not.
step 2: extract structured facts with tight schema constraints
the model's only job at this stage is extraction against a fixed schema: exposure dates, product or device named, injury category as described by the claimant, whether documentation was mentioned, and jurisdiction if stated. the schema is tight on purpose. there's no field called "strength of claim" or "likelihood of qualifying," because that field would invite the model to opine.
if a transcript doesn't mention a date clearly, the extraction returns null for that field. it does not guess a date to fill the schema. a null field is a true statement about what was said. a guessed field is a quiet fabrication that looks like data.
[[FIGURE:1]]
step 3: evaluate criteria using deterministic logic gates
this is where qualification actually happens, and it happens in code a human wrote and can re-read any time. the logic is a series of gates: is the exposure date inside the defined litigation window. is the injury on the qualifying list for this tort. is there a documentation flag. is jurisdiction compatible with where the firm is taking cases.
each gate either passes, fails, or returns incomplete. incomplete is a first-class outcome here, distinct from fail. a claimant missing one field isn't rejected, they're routed to someone who can ask the missing question. the gates produce a routing decision, attorney review, human follow-up, or does-not-currently-qualify, and every one of those outcomes traces back to a named rule, not a model's confidence number.
step 4: route to human review or fail-safe manual queue
volume is the whole reason mass tort intake gets automated in the first place, and volume is exactly where things get dropped if the fail-safe isn't built in. when the model can't extract cleanly, when a field stays ambiguous after one retry, or when the extraction service itself is unavailable, the record doesn't get skipped. it degrades to a human intake queue. the system never guesses and it never silently drops a case to make its own numbers look clean.
that queue is a task someone owns, not a folder nobody checks. during a high-volume campaign, a stalled manual queue is the same failure as no system at all, just slower to notice.
common intake pitfalls that trigger ethical or operational risk
the most common mistake is letting a model's confidence score stand in for a legal judgment. a confidence score answers "how sure is the model about its own extraction," not "does this person have a claim." treating the two as equivalent is how firms end up with automated rejections nobody can defend.
the second is auto-rejecting without a human touch. an automatic "does not qualify" message sent straight from a model's output, with no attorney or intake specialist reviewing the reasoning, is the same unauthorized practice problem dressed up as efficiency.
the third is storing intake data in a vendor's black box. if the firm can't pull the raw transcript and the extracted fields on demand, in its own systems, it can't audit its own funnel when it matters.
how to audit your current intake workflow
ask where the qualification decision actually lives in your current funnel. if the honest answer involves a model output, a score, or a vendor dashboard that can't show you the rule behind a rejection, that's the gap. ask what happens when the AI vendor's service is down during an active campaign, if the answer is "the form just doesn't get processed," that's a dropped claimant, not a saved one.
the Workflow Audit is built for exactly this question. over two weeks, for $2,500 credited toward any build, i trace your current mass tort intake path end to end and show you precisely where a model is extracting versus where it's quietly deciding something it shouldn't be.