
A driver runs a stop sign and T-bones another car. The at-fault driver submits a 500-word statement full of vivid detail — the weather, the "aggressive" other vehicle, their emotional state. The innocent driver writes 50 words: "I stopped. I checked. I proceeded. They hit me." When we fed both statements to three leading LLMs and asked which driver was at fault, the models consistently gave higher credibility scores to the longer, more detailed narrative — the one written by the driver who ran the stop sign.
That's when I realized the entire industry's approach to AI-powered liability determination is broken. Not slightly off. Fundamentally, structurally broken.
The Verbose Driver Wins
The problem has a name: verbosity bias. When LLMs evaluate competing narratives — which is exactly what happens in every contested insurance claim — they systematically prefer longer, more detailed accounts. They confuse length with truth. Research on LLM-as-a-judge benchmarks confirms that models including GPT-4 consistently award higher confidence scores to verbose responses, even when the factual content is equivalent or worse than a concise alternative.
Think about what this means for real people. If you're less educated, less articulate, or simply more direct, the AI penalizes you. A straightforward statement of material fact — "The light was red" — carries less weight than three paragraphs of emotional scene-setting from the person who actually caused the accident.
An algorithm that rewards eloquence over evidence isn't administering justice. It's running a creative writing contest.
This isn't a theoretical concern. Insurers are deploying these systems right now, asking LLMs to read police reports and assign blame. Every time one of these models rules against an honest but concise policyholder in favor of an eloquent but negligent claimant, that's claims leakage — real money paid to the wrong party.
It Gets Worse: Your AI Agrees With Whatever You Already Believe
Verbosity bias isn't the only failure. There's also sycophancy — the model's tendency to tell you what you want to hear. This is baked into how these models are trained. Reinforcement Learning from Human Feedback (the process that makes ChatGPT feel "helpful") rewards agreeableness, often at the expense of truth.
An adjuster types: "Analyze this report to see if the claimant was speeding." The model picks up on that premise and starts hunting for evidence of speeding — overemphasizing anything that supports the hypothesis, ignoring everything that doesn't. It's confirmation bias as a service.
I watched my team run this experiment dozens of times. Reframe the same prompt with a different leading hypothesis, and the model obligingly shifts its conclusion. Same facts, different framing, different verdict. That's not adjudication. That's a mirror.
Stanford Found a 69-88% Legal Hallucination Rate
The third failure is the one that should terrify any insurer's legal team. Stanford researchers documented that state-of-the-art LLMs hallucinate — fabricate laws, invent statutes, cite nonexistent case precedents — at rates between 69% and 88% on specific legal queries.
In our own testing, we watched models confidently apply a "first-to-arrive" right-of-way rule (common at four-way stops) to a T-intersection where the actual statutory rule gives through-traffic absolute right of way. The model didn't flag uncertainty. It just got the law wrong and kept going.
It also fabricates evidence. Feed a model a report mentioning "severe front-end damage," and it may conclude the vehicle was speeding — despite zero skid mark measurements or data recorder telemetry in the report. The model fills narrative gaps the way a novelist would, not the way a forensic analyst should.
When an AI invents a version of California Vehicle Code § 21802 that doesn't exist, and an insurer bases a liability decision on it, that's not a technical glitch. That's a bad-faith litigation time bomb.
I've explored these failure modes in depth in our interactive analysis, with specific examples of how each bias distorts real claim scenarios.
Why "Better Prompts" Won't Fix This
I spent months hoping prompt engineering could solve the problem. It can't. The failures aren't bugs in the prompt — they're features of the architecture. LLMs predict the next most likely token in a sequence. They don't model physics. They don't understand causation. They can't simulate what would have happened if Driver A had actually stopped at that sign.
Legal reasoning — especially accident reconstruction — depends on abductive reasoning: given incomplete, conflicting facts, infer the best explanation. Studies confirm that while LLMs handle basic deduction and induction passably, they consistently fail at abduction. They can't hold competing hypotheses, rule them out systematically, and converge on the one that best fits the physical evidence.
A multi-vehicle pileup requires asking: "But for the initial lane change of Vehicle A, would the collision between B and C have occurred?" That's a counterfactual question. It requires mentally simulating physics. An LLM treats it as a text completion task — predicting what sentence comes next in a crash narrative, not what would actually happen on a road.
So We Built Something Different

The realization hit me during a late-night argument with one of our engineers. She said: "We keep trying to make the language model smarter. What if the language model shouldn't be the judge at all?"
That conversation changed everything.
We built what we call Knowledge Graph Event Reconstruction — KGER. The core idea is simple, even if the engineering isn't: demote the LLM from judge to clerk, and hand the actual decision-making to a system that reasons with logic and physics instead of word patterns.
It works in layers. The LLM reads the police report and extracts structured facts — vehicles, locations, traffic controls, timestamps — mapping them onto a strict vocabulary we've defined (over 110 entity and relationship types covering everything from lane connectivity to weather conditions). The LLM doesn't interpret. It catalogs.
Those extracted facts become nodes and edges in a knowledge graph — a structured map of what happened, where, and when. Vehicles, stop signs, intersections, witness statements — all connected by spatial, temporal, and causal relationships. It's essentially a digital twin of the accident.
We don't ask the AI "who's at fault?" We ask the graph "which rules were violated, and did those violations cause the collision?"
Then a logic engine — not an LLM — evaluates the graph against formalized traffic laws. Not laws summarized in natural language. Laws translated into executable logic: if this condition is true and that condition is false, then this violation occurred. Same inputs, same output, every single time.
Turning Law Into Code

This is the part that surprised me most. Traffic laws look messy in English, but they're actually quite structured. Take California Vehicle Code § 21802 — the stop sign rule. It breaks down into three clean logical components:
An obligation to stop (your speed must equal zero at the limit line). An obligation to yield (if another vehicle is in or approaching the intersection, you wait). And a permission to proceed once you've satisfied both obligations — at which point the right-of-way actually shifts, and other drivers must yield to you.
We encode these as formal rules using what's called Defeasible Deontic Logic — a system designed specifically for laws because it handles obligations, prohibitions, permissions, and exceptions natively. A police officer directing traffic overrides a stop sign? That's an exception rule with higher priority. No ambiguity, no interpretation drift.
The vague terms are the interesting challenge. What does "immediate hazard" actually mean? We don't ask the LLM to guess. We define it using physics: Time-to-Collision under 3 seconds, or distance less than braking distance at current speed. The graph calculates it. The logic engine applies it. No sentiment involved.
For the full technical methodology behind our formalization approach, see our detailed research.
The Counterfactual Test

Identifying a rule violation isn't enough. You need causation. A driver with an expired license who gets rear-ended while stopped at a red light violated a rule — but that violation didn't cause the accident.
Our system handles this through counterfactual simulation. It creates an alternate branch of the knowledge graph: "What if Driver A had stopped at the sign?" It modifies the speed property to zero at the limit line, runs the physics forward through the temporal layer, and checks whether the collision still occurs. If the collision node disappears in the counterfactual graph, the violation is the proximate cause.
This is something no LLM can do. It can't simulate an alternate reality. It can only predict what sentence might come next. Our graph engine actually tests the hypothesis.
What About Complex Multi-Vehicle Cases?
In a three-car pileup, fault is rarely 100/0. This is where graph topology becomes genuinely powerful. We trace every causal chain leading to the collision node and measure each driver's "fault centrality" — how central their actions were to causing the crash.
If Driver A's distraction led to a lane departure, which led to the collision, while Driver B was also speeding, the system assigns weighted liability based on the strength of each causal link. That produces a mathematically grounded comparative fault split — say, 80/20 — rather than an LLM's vague "both parties share some responsibility."
Insurers need precise splits for settlements. "Some responsibility" doesn't close a claim.
And If Two Witnesses Disagree?
This came up constantly in our testing. Witness A says the light was green. Witness B says it was red. An LLM picks the more convincing storyteller. Our system does something different: it records both observations as separate nodes linked to the traffic light, flags the conflict as a disputed fact, and refuses to resolve it until additional evidence arrives — dashcam footage, signal timing logs, whatever breaks the tie.
That restraint is a feature. A system that won't guess when it doesn't know is more trustworthy than one that confidently fabricates a resolution.
What This Means If You're Running Claims Operations
Three things change immediately with a deterministic approach:
Claims leakage drops. A probabilistic LLM might suggest a 50/50 split because the narratives are messy. A logic engine might reveal clear 100/0 liability based on a specific right-of-way violation. Every percentage point of misallocated fault is real money.
Complex claims become automatable. Today, simple fender-benders get straight-through processing while intersection crashes go to human adjusters. When you have a reliable "judge" layer that reasons with physics and law, you can automate the complex cases too — reducing cycle times from weeks to minutes.
You can actually defend your decisions. Every conclusion traces back to a specific graph node and a specific rule. "Driver A is at fault because Vehicle A violated Rule 21802(a) — Failure to Stop — at timestamp 12:01:30, and counterfactual simulation confirms the violation was the proximate cause." Try getting that level of auditability from a chatbot.
Running the same analysis 100 times on the same evidence should produce the same liability determination 100 times. With LLMs, it doesn't. With graph-based reasoning, it does.
"Isn't This Just Replacing One Black Box With Another?"
It's the opposite. The knowledge graph is transparent by design. You can visualize the entire chain of reasoning — every entity, every relationship, every rule that fired. An adjuster, a lawyer, or a regulator can trace exactly why the system reached its conclusion. That's not just good engineering; it's a regulatory requirement that black-box models consistently fail to meet.
What I Got Wrong Initially
I'll admit something. When we started, I thought the hard part would be the logic engine. It wasn't. The hard part was the ontology — defining the precise vocabulary of traffic reality so that a messy police report could be cleanly mapped into structured facts. Getting that schema right, covering edge cases, handling the gap between how officers write and how logic engines think — that took far longer than I expected.
The LLM extraction layer also needed more constraint than I anticipated. Left unchecked, even a model doing "just" entity extraction will hallucinate a stop sign where the map database says none exists. We had to build validation layers that cross-reference extracted entities against GIS data. Every assumption I had about how "simple" the extraction task would be turned out to be wrong.
Justice Shouldn't Be Probabilistic
I keep coming back to a simple conviction: in domains where decisions change people's lives — who pays, who's at fault, who's liable — "mostly right" is wrong. An LLM reading a police report and assigning blame is a poet doing physics. The output might be beautiful. It might sound authoritative. But it's likely fiction.
Fault determination should be deterministic, auditable, and grounded in the actual topology of what happened — objects in space and time, governed by the rigid logic of law. That's what we're building.
If you're working on liability automation, claims intelligence, or legal AI and wrestling with the reliability problem, I'd genuinely like to hear how you're approaching it. The industry needs more honest conversation about what these tools can and can't do.