Interrogating a Stereotype

I had what I thought was a reasonably clever idea for AI in law enforcement, so I did what I now do with most of my reasonably clever ideas. I ran it past a frontier model and asked it to tell me why I was wrong.

The idea was this. Take an LLM. Feed it everything known about a suspect — psychological profile, complete criminal history. Set the scenario as the crime under investigation, or a plausible next crime. Then have the investigating officer interrogate the model while it plays the suspect. The hoped-for payoff is insight into the suspect’s behaviour and a faster resolution of the case.

On the surface it sounds like an automated, interactive version of what behavioural analysts already do. Build a profile, run the “what would he do next” exercise, probe it with questions.

The critique that came back was better than the idea.

The problem

The core objection is simple once stated. An LLM given a profile and a rap sheet will produce a fluent, coherent, psychologically plausible character. It will answer every question in character, confidently, with rich detail.

None of that detail comes from the suspect.

It comes from the model’s training data — the accumulated mass of crime fiction, true crime writing, case studies and news coverage that describes what criminals-like-this tend to say. You are not interrogating the suspect. You are interrogating a stereotype wearing the suspect’s file.

Worse, the setup is a confirmation-bias engine. The profile you feed in encodes the investigators’ existing theory of the suspect. The model performs that theory back at them, convincingly, and every session makes the theory feel more validated. Tunnel vision is already a leading cause of wrongful convictions. This tool would manufacture pseudo-corroboration on demand.

And the inputs are shaky to begin with. Empirical reviews of offender profiling put its predictive validity barely above chance for specific behavioural predictions. So the pipeline is: weak input, plausible confabulation layered on top, delivered through an interactive format that makes it all feel authoritative.

Fluency mistaken for accuracy. The oldest trap in the LLM book.

The failure mode here is not a badly worded email. It is a search warrant aimed at the wrong shed.

The flip

So I flipped it. What if the investigator used the model the other way round — not to confirm the suspect’s guilt, but to find how the suspect could be eliminated from the investigation?

This turns out to be structurally better, and the reason is worth spelling out. The roleplay version asks the model to confirm a theory. The elimination version asks it to attack one. Falsification is the correct epistemic direction, and it targets the single biggest systemic failure in investigations: premature commitment to a suspect.

In practice it looks like this. Feed in the evidence set and ask the awkward questions. What would have to be true for this person to be innocent? What alternative explanations account for the same evidence? Which pieces of the case are load-bearing, and what single check would knock each one over? What exculpatory evidence should exist if he didn’t do it, and has anyone actually gone looking for it?

That last question is the killer. Investigations routinely fail to search for evidence of absence, because nobody is incentivised to. A tool that generates “here are seven things you would expect to find if your theory is wrong, go and check them” is genuinely useful. And it does not require the model to be right about anything. It only requires the model to be thorough, which is the one thing these systems are reliably good at.

The error asymmetry works in your favour too. In the confirmation version, a hallucinated output points a warrant at an innocent person. In the elimination version, a hallucinated output sends a detective to verify an alibi. The failure mode is wasted legwork, not wrongful targeting. Every hallucination gets filtered through real-world verification before it can do damage.

Two caveats.

First, false exoneration is still a live risk. If the model produces a fluent innocence narrative, the same fluency-equals-credibility trap operates in reverse, and a lazy or overloaded detective might drop a line of inquiry without doing the checking. The discipline has to be: the model writes the test plan, humans run the tests, and only an executed check eliminates anyone.

Second, there is a selection problem. If elimination analysis is optional, it will get run on the suspects investigators are lukewarm about and skipped for the one everyone is sure of. Which is exactly backwards. The suspect who most needs adversarial scrutiny is the one everyone is confident in. To work, the falsification pass would need to be procedural — every named suspect, before resources escalate, no exceptions.

The principle

Same model. Same data. Opposite epistemic posture. One version is net-negative, the other net-positive with guardrails.

The general principle that falls out of this is worth keeping. In investigative AI, the model should only ever be allowed to generate work, never conclusions. “Check the timeline against the toll records” is safe output. “He did it because of his mother” is not. The interrogation roleplay violates that boundary by construction. The elimination version respects it naturally, because every output is a task, not a verdict.

There is a secondary benefit for the agencies themselves. “We generated and checked twelve alternative explanations before charging” is a far stronger position at trial, and in any later review, than the current state of ad hoc and undocumented alternative-suspect diligence.

My original idea optimised for feeling like a breakthrough. Which, I now think, is precisely what an investigation under pressure does not need.