A defensible technical diligence report contains six things: a written record of the architectural decisions the target has taken and the alternatives it rejected, a named departure-risk read on the people the system load-bears on, a cost envelope at three times current volume on the existing terms, a list of model and vendor lock-in exposures, the change history of the system the team is most cagey about, and an explicit list of what the principal is choosing not to know. Anything thinner than that is a stack inventory dressed as a verdict. Anything longer is usually a consultancy padding its hours.
We are writing this note for the partner who has never had to sign one. The first time a senior investor reads a technical diligence report under their own name, the question is rarely what does this report say — it is whether the report is the right shape to defend in front of an IC, in front of a co-investor, and, eighteen months from now, in front of an operator who has had to live with the asset. The shape of a diligence report matters more than its conclusion. A report that ends in proceed but cannot defend its reasoning is worth less than a report that ends in do not proceed and can.
What a defensible report contains
The six elements above are not a checklist a senior reader runs through once. They are the working spine of the document, and the pages spent on each one are roughly proportional to where the asset is fragile.
The architectural-decision record is the first section because everything else is downstream of it. A senior diligence does not list the components in the stack — it names the decision behind each load-bearing component, the date the decision was taken, and the alternatives that were rejected at the time. The most useful version of this section is the one that records, against each major decision, what the team says it would do today if it were starting again. We would build it the same way is occasionally true and more often a pose. We would do three specific things differently is almost always the honest answer, and the more useful one for the principal.
The departure-risk read is the section the deck never contains and the section a serious diligence will not omit. It names, by role and by system, the person whose departure the asset would not survive cleanly. It names the second person who could read the same code without an introduction, or notes plainly that there is no second person. It separates documentation that exists from documentation a team intends to write, which is to say, documentation that does not exist. The departure question is the single most predictive question in a technical diligence, and the one the management team has most often not been asked.
The cost envelope is the section the management team likes least, because it is the section where a present-tense story has to be defended in a future-tense market. The diligence reads the existing infrastructure terms, the existing model contracts, and the existing per-call economics, and then runs the same system at three times current volume. The point of the exercise is not the precise number. The point is to surface the contracts and the model choices that were sensible at last year's load and ruinous at this year's. AI vendors are not utilities yet. The diligence treats them as the variable they still are.
The model and vendor lock-in section is adjacent to the cost envelope and answers a distinct question: what happens if the vendor changes the terms. Which model the system is load-bearing on. Which vendor terms are negotiated and which are off-the-shelf. What the migration cost would be if the model is deprecated, repriced, or the vendor is acquired by a party the target would prefer not to be paying. This section is short because it has to be, and is usually the section a senior counsel on the IC will read first.
The change history is the section the team is least eager for the diligence to write. It pulls the commit log of the part of the system the team is most cagey about, reads who has touched it and when, and reads what they wrote when they touched it. The fragile system is not always the one the team flags. It is sometimes the one the team has stopped touching because the cost of touching it has become invisible to them. The commit log surfaces that. The deck does not.
The closing section — what the principal is choosing not to know — is the one that earns the report. Every diligence has it. Most diligences do not name it. A clean report writes the list explicitly, in plain English, and asks the principal to confirm that the listed items are an acceptable cost of proceeding. This is not a cover for the diligence shop. It is a transfer of judgment, in writing, from one senior reader to another, with the limits of the read named.
What the absences tell you
A diligence report is read in two directions. The first reading is forward — what did the team find. The second reading is in negative space — what did the team not look at, and what does that tell you about either the asset or the diligence shop.
A report with no departure-risk section is, in our experience, a report written by a shop that has not yet been asked to defend its reads in a real exit. A report with no cost-envelope section is a report written for the target rather than for the investor. A report that does not name what the principal is choosing not to know is a report that is, quietly, asking the principal to absorb its own omissions on the principal's signature. The absences are the tell.
The other absence to read is in the management team's posture. A target that has prepared a defensible architectural-decision record before the diligence opens is a different asset from one that has to construct it under the diligence's questions. Neither posture is disqualifying. They are different prices, and the diligence report should say so plainly.
A diligence is not a verdict. It is a written transfer of judgment from one senior reader to another, with the limits of the read named.
The studio's stance
We write technical diligences we are willing to defend three years later, in a room full of people who have had to live with them, and we decline diligences whose terms compromise the read. We do not also broker the deal. We do not take a position in the target's stack. We do not take a follow-on engagement to fix the things our own diligence flagged unless the principal explicitly asks for it under a fresh letter — and even then, we prefer to hand the work to a builder we trust rather than to be the studio that found the problem and is then paid to solve it.
The diligence the principal can fully trust is the one written by a reader with no interest in what happens after the memo is filed. That is the only kind of diligence we will sign our name to. The partner who has never had to sign one before should, in our view, ask for that shape from whomever they engage — and decline to sign anything narrower.