The number-one fear in legal AI is hallucination. Every buyer has read about the sanctioned brief, the invented citation, the confident answer that pointed at a case that does not exist. So you would expect the companies selling into that fear to compete on showing their work: how retrieval is built, how answers are grounded, how often the grounding itself is wrong. Mostly, they do not.
We spent part of this month reading the public engineering writing of the legal-AI field, roughly 25 companies and a few independent engineers, looking for genuine technical content. Not product PR, not model-launch co-marketing, not a "90% accurate" number with no method behind it. Architecture, retrieval, evaluation, agent mechanics, with real numbers and honest failure stories. This post is what we found, who does it well, and why we think transparency is the cheapest durable trust signal a legal-AI vendor has. We are one of the small vendors here, and this is a survey, not a scoreboard, so where others publish deep work we say so plainly.
The short version: almost nobody does it
Of the roughly 25 companies we checked, only about four run a sustained, deep-technical engineering blog. Another four or so publish occasional genuine content. The remaining fifteen-plus publish essentially zero real engineering. That is somewhere around 15 to 20 percent doing any real engineering writing, and under 10 percent doing it consistently.
This is not just our impression. The Stanford HAI and RegLab study of legal AI (Magesh et al., "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools", summary) found that leading tools still hallucinate a meaningful share of the time, on the order of 17 to 34 percent in their testing, and, just as important for this post, that the sector "remains alarmingly opaque: the tools we study provide no systematic access, publish few details about their models, and report no evaluation results at all." Opacity is the default. Transparency is the exception.
That is the whole argument in one line: in a market whose central fear is the machine making things up, the willingness to show how you prevent it is rare, and rare is valuable.
The field sorts cleanly into three tiers by what its public writing actually contains, not by how much of it there is.
| Transparency tier | Signature move | Examples from the scan |
|---|---|---|
| Deep and sustained | Ongoing architecture, retrieval, and evaluation posts, with real numbers and named failure stories | Harvey, Hebbia, Thomson Reuters TR Labs, Isaacus |
| Occasional but genuine | A handful of real systems posts among mostly product content, plus standout independents | Remedy Legal, EvenUp, DeepJudge, and independent engineers like Partha Chakraborty |
| Product only | Prolific publishing that stays on positioning and features and rarely touches internals | The remaining fifteen plus, for example Legora |
The rest of this post walks each tier in turn.
The four who genuinely show their work
Credit where it is due. A handful of companies write real engineering, and their posts are worth your time whether or not you ever buy from them.
Harvey (harvey.ai/blog) runs the deepest and most sustained legal-AI engineering blog we found, roughly 15 to 20 substantial posts. They have written about their enterprise RAG design across multiple data tiers, an agentic search loop, how they secure embeddings at scale, on-demand vision for legal documents, and why they built their own agent runtime, and they open-sourced a legal agent benchmark. Harvey is a large, very well-funded company selling into BigLaw, so a lot of what they describe is scale-driven in a way a small team would not need. That does not make the writing any less generous. When a company that size publishes its retrieval evaluation and its security reasoning, it raises the bar for everyone.
Hebbia (hebbia.com/blog) writes opinionated systems posts, roughly 10 to 15 of them. "Goodbye, RAG" argues that classic top-k retrieval structurally fails on hard reasoning queries and lays out their alternative in detail. Their multi-agent redesign post is unusually honest about why their first "god agent" failed, overloaded tooling and context bloat, and what the rebuild fixed. They also publish the parts most companies hide, like a distributed request scheduler built because they consume enormous token volume. Some of that is only relevant if you operate at their scale, and they say so. The candor about what broke is the valuable part.
Thomson Reuters / TR Labs runs a separate machine-learning engineering blog (medium.com/tr-labs-ml-engineering-blog), 10-plus posts, alongside the CoCounsel and Casetext story. The standout for me is "Teaching Claude to Read Tracked Changes," a build log of four failed approaches before one that moved accuracy from 20 percent to 93 percent. That is exactly the shape of an honest technical post: it leads with the failures and puts the numbers first. Their writing on test-driven prompt engineering, decomposing a task into many individually tested prompts with gold-standard answers, is the most transferable, least scale-dependent lesson in the entire field, and they gave it away.
Isaacus (isaacus.com/blog) is the most research-forward of the group, 8 to 12 posts plus open datasets and papers. Their "Legal RAG Bench" work makes a point every buyer should internalize: retrieval sets the ceiling on legal-RAG quality, and a large share of what looks like hallucination is actually a retrieval failure, the model was grounded but grounded on the wrong passage because the right one was never retrieved. That distinction reframes the whole hallucination conversation, and they published the benchmark to back it.
We are not going to pretend we out-engineer these four. On several axes they are ahead of us, and on the ones that are scale-driven they should be. Our point is narrower and, we think, fairer: they chose to show their work, and that choice is the exception, not the rule.
The middle, and the honest independents
A second tier publishes real but occasional technical content.
Remedy Legal has a numbers-first post titled "From 82% to 99.8%: How hybrid search improved our legal agents" that walks through exactly why keyword signals rescue the identifier queries that pure embeddings miss.
EvenUp's "Building Trustworthy, Scalable Document AI for Legal Tech" is a genuine systems-thinking piece on extracting structured facts once and querying the record instead of re-retrieving on every question. DeepJudge runs an architecturally opinionated series on unified, permission-aware firm indexing, marketing-leaning but with real design claims. These are worth reading, and they are the minority.
Then there is a pattern worth naming without any snark: some of the best legal-retrieval writing anywhere comes from individuals, not vendors. Partha Chakraborty's three-part series on structure-first, high-precision legal retrieval (parthac.me) is more detailed than almost any company blog we read, cataloging the silent failure modes of naive hybrid search on legal corpora and sketching a multi-plane retriever to fix them. An independent engineer writing on a personal site out-wrote most of the funded vendors on their own core problem. That should tell you how low the bar for vendor transparency currently sits.
And plenty of well-funded companies publish a great deal and disclose almost nothing technical. Legora, a major competitor whose Tabular Review overlaps our own Document Matrix, publishes prolifically, but it is almost entirely product and positioning content, thin on internals. That is a legitimate choice, and their product writing is polished. It is just a different choice from showing the engine. The lesson we take from it is not that they are wrong, it is that volume of content is not the same as depth, and a buyer should not confuse the two.
Why transparency is a trust signal, not a giveaway
The usual objection to an engineering blog is that you tip off competitors. We think that fear is mostly misplaced in this market, for a simple reason: the moat in legal AI is corpus, evaluation, and distribution, not the fact that you use hybrid search and reranking, which everyone arrives at anyway. Harvey and Hebbia publish their architectures and it has not hurt them. You can describe the shape of a system honestly while keeping the tuning, the weights, and the prompts to yourself.
The deeper reason to publish is that transparency is hard to fake. A "verified" badge costs nothing and proves nothing. A post that says "here is exactly what our verifier checks, here is the hard case it is engineered to handle, and here is how we measure it" cannot be written by a team that has not actually built and measured the thing. In a market where the Stanford finding is that vendors "report no evaluation results at all," publishing your evaluation is a costly signal in the economic sense: it is expensive to send unless it is true. That is precisely why the opaque incumbents are unlikely to match it, and why a small vendor can compete on it.
The mechanism is worth drawing out, because it is the whole reason transparency survives as a signal at all.
A badge separates no one, because the honest and the hopeful can both display it. A post that names what its verifier checks, the hard case it is engineered to handle, and how it is measured is one only a team that did the work can write, which is exactly what makes it worth reading.
None of this is a claim that anyone else's product hallucinates or is bad. The Stanford numbers are about the sector, not any single named product, and the point cuts at us too. Our stance is complement, not replace, and inform, not attack. The best outcome of a survey like this is that more of the field publishes, because a buyer who can read the engineering is a buyer who can tell grounding from a badge, and that is good for everyone building honestly.
What you can do with this
You do not need to take any vendor's word, including ours. Here is a short test you can run against any legal-AI company you are evaluating.
-
Ask them to point you at their engineering writing. Not a product page, not a press release, an actual post that describes how retrieval or grounding works, with a number in it. Four companies in this field can do this immediately. Most cannot.
-
Ask for a failure story. "Show me a post where you got something wrong and fixed it." The credible ones lead with the 20-percent-to-93-percent arc. The tell of a weak one is that every published number only goes up and to the right.
-
Ask what "verified" actually computes, and what their false-positive rate is. A real answer names what is checked against what. A badge with no method behind it is a liability shield, not an architecture.
-
Ask whether they publish any evaluation results at all. Stanford's finding is that most do not. The ones who do are handing you the rubric to check them with, which is exactly the behavior you want from a tool you are going to rely on in front of a court.
If a vendor answers all four concretely, they are doing serious work, whatever their size.
What we will and will not publish
Choosing transparency is not the same as publishing everything, and it should not be. Here is our line, so you can see that the openness is principled rather than reckless.
We publish the shape of the architecture: how retrieval is composed, how grounding and citation checking work, what our verifier checks, and the honest failure classes, including bugs we caught by attacking our own output. We publish real numbers from our own evaluation and name the third-party research we lean on, like Stanford HAI, so you can check us.
We do not publish the tuning: the exact weights, thresholds, prompt text, and reranker settings that are ours to keep and that would rot the moment we changed them. We do not name our own model or infrastructure vendors in customer-facing writing, because that is a supplier relationship, not a trust signal, and disclosing it helps no one you are trying to protect. And we do not publish anything on the security surface, authentication, tenant and matter isolation, abuse controls, because that is the one place where obscurity genuinely is a defense, and writing about it would trade your safety for our transparency points.
That is the deal. Show the engine, keep the keys. In a field where the default is to show neither, we think that is the honest middle, and this blog is us holding to it.
