Why generic AI tools cannot tell you what they missed

Generic AI tools used for case analysis work the same way. The tool reads the firm's files, pulls the passages that look relevant to the question, and writes an answer from what it pulled. The work the lawyer sees is real analysis. The lawyer does not see what the tool did not pull.

The problem is quiet. The answer comes back fluent and confident. Nothing in it flags the document the tool never opened, the contradicting ruling the tool never surfaced, or the witness statement on the other side that the tool never considered. The tool cannot tell you what it missed, because it does not know it missed it.

The missed material is often the material that decides the matter. A contradicting affidavit buried in a discovery production. A prior inconsistent statement in a deposition transcript that undercuts the witness the memo just vouched for. A controlling appellate decision on a single element that never came up because the question was phrased around a different element. An analysis built without those reads complete on the page and is wrong in the file.

What generic AI tools share architecturally

Most AI tools sold for legal analysis run the same loop: an index over the firm's case files and research; a retrieval step that pulls top-k passages for a given question; a language model that writes an answer from the retrieved passages. The terms vary by vendor, but the architecture is the same.

The architecture has a quiet asymmetry. The retrieval step decides what the language model gets to see. The language model never asks "what did retrieval miss?" It cannot. It only sees what was handed to it.

In low-stakes domains, this is fine. In litigation, the missed material is what loses cases.

How structural reasoning is different

Kacti AI's Analyzer is built on a connected case model rather than on retrieved passages. The model defines what a complete answer looks like before any retrieval runs. For a litigation matter, this means:

• Which claims have to be proved.
• Which elements each claim requires.
• Which kinds of evidence each element accepts.
• Which witnesses speak to which events.
• Which documents support, undermine, or remain silent on each element.

That structure is not assembled by a retrieval step. It exists as the case model the Analyzer reasons over.

When the Analyzer answers a question, retrieval becomes a reasoning task guided by that structure rather than the other way around. The Analyzer can tell which elements have not been touched by any evidence. It can tell which witnesses have not been cross-checked against contradicting accounts. It can tell which authorities have been cited on one side and not the other.

The Analyzer reports two things together: what was found, and what could not be found.

A thin element is named as thin. A claim with no evidentiary anchor is named as unsupported. A contradiction between two witnesses is surfaced rather than smoothed into a single confident summary.

Why this matters in practice

The litigators we work with do not buy AI on benchmark scores. They buy on whether the tool surfaces what they would have missed. That is a different problem from what generic AI tools are built to solve.

Generic AI tools tell you what they found.

The Analyzer tells you what is there, what is missing, and where the case does not yet hold together.