I have read a lot of technology due diligence reports, and the weak ones fail in the same way. They describe the system accurately and then stop.
You finish forty pages knowing the languages, the cloud provider, the repository count and the test coverage, and you still cannot say whether the thing in front of you supports the investment case or quietly undermines it.
Reports on AI companies now fail in a second way, and it is more expensive. They keep AI as one section among six, somewhere after architecture and before cost. That arrangement made sense when AI was a feature. It does not when the AI is the investment case, because the section that should decide the deal is sitting in the middle of the document with a paragraph of its own.
A report is not an inventory. It exists to help a small number of people make one decision under time pressure. Everything in it should be arranged around that.
What the report is for
Technology is often central to the investment thesis and difficult to assess from the outside. A clean demo can hide a fragile platform. A large engineering team can conceal weak throughput. A credible AI story can amount to little more than a vendor API and a presentation.
So the report has one job: to tell the investor what is real, what is risky, and what can create value. Every section should be readable as an answer to one of those three.
That framing also decides what gets left out. Findings that do not change the decision, the price or the first hundred days belong in an appendix, or nowhere.
The six sections, and what each must answer
The claim check. Does the AI do what the pitch says it does? Not whether the company uses AI — everyone does — but whether the specific claim driving the valuation survives contact with the product. If the deck says the system handles seventy per cent of support conversations, the question is seventy per cent of what, measured how, and what happens to the other thirty. This section is written last and read first, and a surprising number of reports do not contain it at all.
Where the intelligence actually sits. The easiest section to fake and the one that decides defensibility. The question is not whether the company uses a model. It is which part of the result belongs to the company. A thin layer over a model provider is a feature. What can be defended is usually the corpus they assembled, the evaluation set built from their own failures, the workflow depth earned by sitting inside a customer's process, and the feedback loops that make those improve with use. Ask what happens to the product, and to gross margin, if the underlying model becomes ten times cheaper or ten times better. If nobody has thought about it, that is your finding.
Evaluation, or how anyone knows it works. The section most reports still do not have. A company that cannot measure its own output quality cannot improve it deliberately, cannot tell improvement from luck, and cannot tell you whether last quarter's progress was real. Ask to see the evaluation set and who chose the cases. Ask what the pass rate was three releases ago. Ask what happens in the pipeline when quality drops — whether a regression blocks a deploy the way a failing test does, or whether somebody notices later. A team that evaluates on examples it chose has not evaluated anything.
Architecture, scale and the cost of inference. Will this hold at the volumes in the plan, and what breaks first? Good analysis names the component that becomes the constraint, the load at which it becomes one, and roughly what it costs to move that ceiling. For an AI product, add the constraint that is new: inference cost and rate limits are production dependencies, and cost per action is a margin question rather than an infrastructure one. A business whose unit cost rises with usage and whose price does not is not a software business yet.
Data, permissions and the agent's boundary. What could stop a deal, lose a customer or trigger a regulator? Separate what is genuinely dangerous from what is merely untidy. For an AI company the sharpest questions are about the corpus and the boundary: where the training or retrieval data came from and whether they had the right to use it, whether a user's permissions survive retrieval or are flattened the moment content is embedded, and which decisions an agent may take alone. An agent acting with a human's credentials is a privilege escalation with a product manager.
The engineering organisation, and the debt it is accruing. Can these people deliver the plan? Headcount is the least interesting number. Look at throughput against what was promised, where the key-person risk sits, and whether there is technology leadership above the team or only within it. Then ask the question that is new: how much of the code is generated, and who reads it. Volume delivered is inventory until someone has reviewed it, and debt now accumulates at the speed writing has become cheap.
How to tell a weak report
A few tells, all of them quick.
- It watched the demo. The clearest sign. A report that describes what the system did in a scripted session has observed a performance, not tested a claim.
- It accepted the benchmark. Vendor or self-reported numbers on public benchmarks say little about behaviour on this company's actual traffic.
- It has no view on model dependency. If the report does not say what happens when the provider changes price, policy or model, it has not assessed the business it is looking at.
- It has no view at all. Findings listed without weight, so every issue looks equally important and none looks urgent.
- It grades rather than explains. A maturity score out of five tells you nothing you can act on. What was scored, against what, and what would move it?
- It avoids the people question. Assessing an engineering organisation means forming a view about individuals, which is uncomfortable and necessary.
- Its recommendations have no sequence. Twenty improvements with no order is a wish, not a plan.
The page that matters
The executive summary should be one page, and it should take a position.
Three things belong on it. What is real, stated plainly, including the parts of the company's own story that did not survive contact with the code. What is risky, ranked, with what each risk would cost and when it would land. And what can create value, which is the part most reports skip entirely, because it requires the author to have an opinion about the business rather than only the system.
For an AI company there is a fourth line, and it is usually the one the committee reads twice: whether the intelligence in this product is the company's or rented, and what that is worth.
If that page cannot be written without hedging, the diligence is not finished.
After the deal
The most valuable thing a report can do is survive the transaction.
A diligence exercise builds an understanding of the company that is expensive to acquire and easy to throw away. If the findings are written so they can become a first hundred days plan, with owners and a sequence, the work pays twice. If they are written to close a deal and then be filed, the new owners will rediscover the same issues more slowly and at greater cost.
For an AI company the first hundred days has an obvious opening item, and it is rarely the model. It is the evaluation baseline, taken before anyone starts improving anything — because an improvement measured against itself proves nothing, and the new owners will want to know by month six whether the thing they bought is getting better.
Write the report so the person holding it in month four still finds it useful.