The DD Evidence Matrix

Every diligence process generates two things at once. It generates findings, which are what the IC memo talks about. And it generates a paper trail behind those findings, which is what the seller expects you to be able to reconstruct if a claim breaks after close.

The trail matters more than the finding.

A finding without a trail is an opinion. A finding with a trail is a defensible conclusion. In an environment where multiple deal team members chase parallel workstreams under time pressure, where the seller drip-releases evidence across a four-to-eight-week window, and where senior investors want to know at Week 3 whether they are still underwriting the same deal they scoped at LOI, the ability to reconstruct why every conclusion was reached is what makes the DD process falsifiable.

The DD Evidence Matrix is the operational artefact that holds the trail.

What it is

A single tracker mapping every material diligence question through the evidence requested, the source that produced it, the named owner who confirmed it, the provenance code, the conclusion, the transaction consequence, and the post-close observable that will eventually validate or falsify the conclusion.

It is a spreadsheet. Nothing more elaborate.

Every matrix row is a test of an investment thesis or a sub-assumption. If a question cannot be traced back to something the IC memo will underwrite, the question does not belong in the matrix. This linkage is what separates a diligence tracker from a compliance checklist.

Its job is to convert the Question Banks companion asset from a set of things to ask into an evidence-backed decision system that survives IC scrutiny and post-close audit.

Column architecture

Every row is one underwriting question and its downstream evidence and decision chain. The columns are:

Question ID. Cross-referenced to the Question Banks. Every question in the matrix comes from the bank; questions that emerge during DD get added to both.

Workstream. WS01 through WS14. Some questions cut across two workstreams; you pick the primary owner.

AI Power Chain layer. Layer 1 through Layer 6 if the question is layer-specific. Blank if not. This tag surfaces which questions concentrate where the AI infrastructure exposure centres.

Question. The specific ask, written the way it will be posed to management, counsel, or the data room. General questions produce general answers. Precise questions surface where evidence does not exist.

Evidence requested. The specific document, data set, or interview named. "Financials" falls short of an evidence request. "Monthly revenue by top-20 customer for FY2024 and YTD FY2025, unadjusted, from the ERP export" is an evidence request.

Source location. Data room folder, filename, interviewee name, URL of the SEC filing, or third-party source. If the same question gets answered through three sources, list all three; triangulation matters.

Named owner. The DD team member accountable for the row. Not a firm. Not a team. A person. Ambiguous ownership is where evidence chains rot.

Status. One of: Requested / Received / Verified / Contradicted / Blocked / Waived. Each state brings a downstream discipline; the next section covers this.

Provenance. P, D, or I. P for Public evidence disclosed in filings, press releases, or verified reporting. D for Derived analysis: framework-applied inference from public or seller-provided inputs. I for Illustrative assumptions chosen to demonstrate mechanics; not a claim about the target. A material finding entering the IC memo must hold P or D. I findings remain pending until upgraded.

Finding. The conclusion the row supports. One sentence. Precise. If the evidence does not support a specific conclusion, the finding is "insufficient evidence, promote to Deep tier" or "waived, out of scope per WS01".

Decision impact. What the finding changes. Valuation adjustment, R&W construct, escrow slot, condition precedent, financing covenant, walk, or accept. Findings without decision impact do not belong in the IC memo; consider whether they belong in the matrix.

WS14 observable. The specific post-close data point that would test the finding. If a finding cannot be tested post-close, ask whether the finding was really a finding or a plausible assertion.

Twelve columns. Every material claim in the IC memo maps to a row with an explicit evidence state: Verified, Contradicted, Waived, or explicitly Insufficient.

The provenance discipline

Provenance is where the matrix does its most valuable work.

An IC memo that reports "customer concentration is 42% top-3 by revenue" holds different weight depending on whether that number came from a management assertion, a management-provided customer schedule, an ERP export, an audit workpaper, or a customer-by-customer contract review. All five are answers. The evidence quality varies across them.

The three provenance codes force the DD team to be explicit:

P (Public). Evidence a third party can independently verify. SEC filings, press releases, rating agency reports, regulatory disclosures, court records, standards documents. If it comes from a filing whose CIK you can name, it is P.

D (Derived). A conclusion the DD team constructed by applying the framework to a mix of public and seller-provided evidence. Bottom-up TAM built from customer-level revenue plus published customer capex is D. QoE reconstruction from ERP data plus revenue recognition analysis is D. The distinction from P is that a third party asked to reproduce the number would need to see your workpaper.

I (Illustrative). Assumption-based figures used to demonstrate framework mechanics or to fill a gap that could not be evidenced within the DD window. An I is a promise: you owe the IC an explicit note that this number sits outside the target's number.

Provenance is source-type, not evidence weight. Within P, a 10-K ranks above a press release. Within D, an ERP-based reconciliation ranks above an inferential model with three management assumptions. The provenance code tells the IC where the number came from; the analyst's workpaper tells the IC how much confidence to place in it. Institutions that want the confidence dimension made explicit can add a separate evidence-quality column to the matrix. The P/D/I code is the minimum, not the ceiling.

The rule: no I in the IC memo without a caveat. The IC deserves to know which conclusions rest on assumptions the DD team could not confirm. Failure to distinguish P, D and I is how DD reports transmit false precision to the IC.

A worked example: CoreWeave DDTL 3.0

The framework calibration case study on the CoreWeave $2.6bn DDTL entered 28 July 2025 (SEC filing crwv-20250728) landed AMBER: a high uncontracted-principal share above the framework threshold, covered by an unconditional parent guarantee at Unrated at DDTL 3.0 (Ba2 / BB+ ratings apply to the subsequent DDTL 5.5 facility in the 2026 SEC filing). That verdict rests on the following matrix rows.

Eleven rows. That is the deal, decomposed into an auditable chain from question to observable.

Some of what these rows reveal:

The AMBER verdict is Row 06 (uncontracted principal above threshold) partially offset by Row 09 (parent recourse covers). Take away Row 09 and the verdict flips to RED. That decomposition is what the matrix is for.

Row 08 is the row that reads Accept but generates a post-close observable. Findings you accept at close still need to be monitored, because the underlying facts move. This is where matrices with no WS14 column stop being useful past close.

Row 10 has no WS14 observable because it resolves at close. Not every row generates a post-close item. The matrix should not force one where none exists.

The provenance codes are heterogeneous. Some rows are P outright (05, 09, 10). Some are D built from public inputs (01, 03, 04, 06, 08). Some are mixed P/D where public disclosure is partial (02, 07). No I appears in this matrix; illustrative rows would be marked and would trigger the IC caveat.

Running the matrix during a live DD

Week 1. WS01 delivers the scoping output; the matrix is instantiated with the questions that survive scoping. Rows in the Question Banks that stay inactive for this deal stay in the bank, out of the matrix. A 250-question bank commonly scopes down to a matrix of roughly 60 to 100 rows for a Standard-tier transaction.

Week 2. Evidence requests go out. Every row is either Requested or Waived. Ownership is assigned. Rows without a named owner do not move; the DD lead sweeps ownership assignments daily until every row has a person against it.

Week 3. Findings begin to land. Rows move from Received to Verified as evidence is checked against source. Provenance codes are applied at Verified, not before. A row that arrives with a finding but no provenance code falls short of Verified.

Week 4. The matrix has enough coverage to generate the interim IC read. Rows still in Requested or Blocked at end of Week 4 are flagged for the Deep tier decision: escalate the request through senior deal-team channels, waive the row explicitly with IC awareness, or extend the DD window.

Weeks 5 through close. Late-arriving evidence changes prior rows. This is the moment the matrix earns its keep: a schedule delivered in Week 5 can flip a provisional Amber to a confirmed Red, which restructures the IC memo. Rows are versioned; the deal team can reconstruct which conclusions were held at each decision point.

Post-close. The matrix extends into WS14. Every row with a WS14 observable becomes a monitoring line in the 100-day validation dashboard. Rows validate or falsify. Falsified rows feed back into WS01 on the next deal, recalibrating scoping and depth allocation.

Common failure modes

The matrix remains exposed to the failure patterns that kill unstructured DD.

Answer without evidence. Management asserts a number; the row records the assertion; no source is captured. The row appears complete because the finding is populated. At IC, the assertion is treated as evidence. Discipline: no Verified without a source citation.

Evidence without answer. The data room delivers fifty files responsive to a question; none directly answer it. The DD team spends the week reading around the question instead of naming that the question stands unevidenced and escalating. Rule: if verification is exceeding the materiality-adjusted diligence budget for the row, escalate to Waive or Deep tier. For typical mid-market rows the budget lands around four analyst-hours; for thesis-critical rows it is unbounded until IC directs otherwise.

Provenance drift. A finding enters as I, gets used in workpapers, gets cited across other rows, and by Week 3 has been promoted to D or P without an evidence upgrade. This is quiet corruption. The fix: every promotion from I to D or D to P is a documented event with the specific evidence that supported the promotion.

Owner ambiguity. The row lists the workstream but not a person. Three team members assume someone else has it. The row does not move for two weeks. Fix: the DD lead reviews owner assignments daily in Week 1.

Late-arriving evidence changes prior findings. Week 5 evidence flips a Green to an Amber; the IC memo has already been drafted; the deal team debates whether to update the memo or discount the finding. Rule: memo drafts are versioned against matrix state; findings that flip after memo draft trigger an escalation event, never a quiet edit.

Contradicted evidence not reconciled. Management says on-time delivery is 95%. ERP export shows 87%. Customer interviews indicate 82%. The DD team picks the number that best supports the writing they want to do; naming the contradiction and resolving it stays the harder discipline. Rule: contradictions get a Contradicted status and stay Contradicted until reconciled. The finding is the reconciled number plus the reconciliation logic that produced it, cited to sources. Where reconciliation stays out of reach within the DD window, the finding is the range, the IC memo reports the dispersion, and a WS14 observable is designed to close the gap post-close.

Matrix rot. Week 1 discipline is high; by Week 4 team members stop updating status codes because everyone already knows what the state is. By Week 6 the matrix does not reflect reality. The fix: a ten-minute daily standup against the matrix, not the memo.

When to abandon the matrix

Not every transaction warrants the full matrix apparatus. Two situations argue for a lighter touch.

Screen-tier reviews. A pre-LOI look intended to inform whether to pursue the deal further does not need a 60-row matrix. A one-page findings sheet against ten to fifteen questions is sufficient. The full matrix is a Standard-tier and Deep-tier tool.

Repeat targets. A follow-on investment in an existing portfolio company where the DD team already has the historical matrix from the original transaction does not rebuild from scratch. It updates the prior matrix with what has moved and re-runs the WS14 observables to confirm the base state is still what it was.

The matrix is a discipline, not a bureaucracy. When the discipline generates more paper than signal, the matrix is being used wrong.

Where this connects

The Evidence Matrix operationalises the Question Banks by giving every question a place to land, an owner, and a downstream observable. It closes the loop the Due Diligence framework opens: findings become auditable rows, rows become IC-memo conclusions, IC-memo conclusions become post-close observables, and post-close observables feed the next scoping decision.

Related work: Post-close validation and the DD improvement loop (WS14), The scoping decision (WS01), CoreWeave DDTL 3.0: the AMBER worked example.