Why a diligence completeness score should fall

A data room that reports itself most of the way complete is telling you how much the software matched, not how much is actually in the room. The number is worth trusting only if a person checking a row can make it fall. That requires confidence to be visible, and partial to be a real state.

Adoption is no longer the open question. Bain's 2026 M&A report, drawing on a survey of more than 300 M&A executives, found 45% of them now relying on AI tools, more than double the year before, and names diligence as an established use case rather than an emerging one. What that report does not settle is how you tell a good tool from a bad one. In a data room, that question gets decided by the completeness score, which is usually the least examined number on the page.

A completeness score is the output of a matching process. Something compares a list of requirements against a set of documents and reports how much of the list is answered. The single figure folds together:

• how much of the list the software found anything for at all;
• how much of what it found actually answers the requirement;
• how much of the requirement is genuinely satisfied.

Only the first is a property of the software. The other two are properties of the room. A score that only moves upward is usually measuring the first while presenting itself as the third, and those two come apart exactly where diligence is hardest.

Because a score produced by matching inherits the failure modes of matching, and matching is done by a system that has to choose.

If the only way to move a row is to upload a document, the number is tracking uploads rather than readiness. The room fills, the number rises, and nothing in that sequence requires anyone to have checked whether the document answers the line it was filed against. That is a progress bar, not a measurement.

The test is whether a person can lower it. A reviewer opens a row the system matched with low confidence, reads the document, and finds it does not answer the requirement. The reviewer downgrades the row. Complete loses a line, partial gains one, and a score weighted by criteria falls. Nothing was uploaded and nothing was deleted. The room did not change. The understanding of the room changed, and the number moved to reflect that.

A score with no path downward cannot represent the correction. It can only accumulate, which means it can only be right by accident.

A wrong match is worse than no match, because a wrong match hides work and a missing one advertises it.

A system that has to return something will return the nearest document available. The nearest document to a certificate of good standing can be a certificate that is genuine, current, and issued to a different entity than the one being diligenced. Nothing about it is fraudulent, and nothing about it answers the line. What makes the mistake hard to catch is that the document is genuine, not that it is unusual: the document exists, the requirement exists, and the two are not the same thing.

This is measurable, and it has been measured next door. Stanford RegLab's study of AI legal research tools found the leading products hallucinating between 17% and 33% of the time, on tools sold as having solved the problem, and concluded that the providers' claims were overstated. Those tools retrieve from a curated, well-structured corpus of published law. A data room is neither curated nor well-structured, and the answer is not published anywhere.

When a system will not assert a match, it should say so and hand the line to a person. That is not a gap in the product. It is the product declining to manufacture certainty it does not have. A vendor whose system never returns "no match" has not built a better matcher. It has removed the only signal that would have told you the matcher was unsure.

Because documents answer lines partially, and a binary state forces you to choose which error to make.

Take a line asking for three years of audited statements. A document arrives with two of them and no auditor letters. Mark the line done and the gap disappears from every view built on the checklist. Mark it not done and the work already delivered disappears with it. Neither is true, and both lose something the deal team needs.

Partial has to be a real state. A partially answered line earns partial credit, which is what criteria-weighted completeness means: the score reflects how much of each requirement is met rather than how many rows have a tick against them. Once partial exists, the chase list built on top of it can tell a line nobody has touched from a line that is one document short. Those are different conversations with different people.

That distinction is the point at which a data room stops being a filing cabinet. It is also the behavior due diligence automation has to have before its number tells you anything you could act on.

Ask what the number is made of, how it moves, and whether a person can move it.

• Can a reviewer lower it? Not "can I edit the checklist", which every tool allows. Can a person read a matched row, disagree with it, and watch the score fall as a result? And can they show you where that happened, and who changed the status and when?
• What happens when nothing matches? Does the system return its closest guess regardless, or nothing at all plus a note to a person? A system that always returns a match is telling you what it could reach, not what it found.
• Is partial a state? Take a line from your own checklist that a single document only partly answers, and ask how it gets scored. If every line is done or not done, the score is counting rather than weighing.

None of that is an unusual thing to ask. NIST's AI Risk Management Framework already sets the expectation that accuracy measurements "should always be paired with clearly defined and realistic test sets ... and details about test methodology". A completeness score is an accuracy measurement with a friendlier name, and the test set is your own checklist.

A vendor who cannot answer these is not necessarily selling something bad. They may never have been asked, and a number nobody has interrogated is not the same as a number that is wrong. From the outside you cannot tell those apart, which is the reason to ask before you are relying on the number rather than after.

Put the same questions to us, and to every tool you are weighing us against. They belong in every sell-side diligence evaluation, aimed at every tool in it, including the one already in the room. A number nobody is willing to have lowered is the one thing worth walking away from.

• Bain's 2026 M&A report bain.com
• Stanford RegLab's study of AI legal research tools reglab.stanford.edu
• NIST's AI Risk Management Framework airc.nist.gov