20 Documents vs 1 Story

A founder I work with called me a few weeks ago. First proper raise. A couple of angels already in, but now a lead investor was doing real due diligence. They wanted a data room.

What the founder had: three versions of the pitch deck (unclear which was current), a financial model that hadn’t been updated since the last pivot, a cap table living in a Google Sheet with manual edits and no version history, customer metrics scattered across Stripe, a dashboard, and a half-finished spreadsheet. No data room. No index. No coherent story connecting any of it.

Twenty documents that needed to tell one story. The investors where waiting for the access to the data room in 3 days. And the founder was also trying to close a engineering hire and fix a production bug that was burning a key PoC customer.

If you’ve ever raised a first round, you know this feeling. The investor asks for “standard DD materials” like it’s a thing you just have somewhere. The reality is you’re Frankensteining documents together at midnight, trying to remember if the ARR number on slide eight matches the model, which you think matches Stripe, but honestly you haven’t checked since you changed the pricing two months ago.

Most founders grind through this alone. We didn’t. Here’s what happened.

Most founders treat the data room as a filing exercise. Find the documents. Name them something reasonable. Upload them. Done. This is how you end up fielding awkward questions in the DD meeting that you could have answered in advance — if the documents had agreed with each other.

Here’s what I’ve learned from sitting on both sides of the table: the investor isn’t checking whether you have the documents. They’re checking whether you have the understanding.

Your pitch deck isn’t just slides. It’s your thesis about why this market, why now, why you. Your financial model isn’t just numbers. It’s your assumptions made explicit and testable. Your metrics sheet isn’t just data. It’s proof that you know which numbers matter and which are vanity.

When the deck says TAM is €2B but the model assumes 0.3% penetration after five years, and the customer list has twelve names — the investor doesn’t see a filing problem. They see fragmented thinking. Three documents that individually looked fine but collectively told three different stories about the same company.

That’s what DD actually tests. Not your ability to produce documents. Your ability to produce coherent documents. Which requires coherent thinking about your own business.

In The Judgment Machine, I wrote about decomposing judgment into layers — some that tolerate formalization, some that resist it. A data room is judgment formalized. And the challenge isn’t writing fifteen documents. It’s making twenty documents express one coherent understanding of the business.

Rather than the founder grinding through each document solo, hoping the numbers would align across fifteen files, we set up two AI agents with distinct roles. One writes. One verifies. They never do each other’s job.

Here’s the workflow, step by step.

Before generating a single document, we sat down and wrote plain-language instructions describing what the data room needed to achieve. Not templates. Not “write a pitch deck.” Instructions.

The difference matters. The typical approach is: “Update the financial model.” What we wrote instead was closer to:

Revenue figures must match across deck slide 8, model tab ‘Revenue’, and the Stripe export. The model is the source of truth — everything else derives from it. If the deck says €100K ARR, the model better show €100K ARR, and the monthly breakdown better add up to that number.

TAM/SAM/SOM on the deck must trace to the market sizing tab in the model. No hand-waved numbers. If the deck claims a €2B market, there needs to be a tab that shows the math.

Cap table must reflect the current state post-SAFE conversions. Not “pre-money” from six months ago. The actual current table, with the actual terms, including the angels.

Customer names in the case studies must match the logos on the deck and the entries in the pipeline sheet. If a logo appears on slide fourteen, there better be a case study to back it up.

These instructions aren’t clever. They’re specific. And specificity is what makes the difference between AI that produces plausible-looking documents and AI that produces consistent documents.

The writer agent drafts and revises all documents following those instructions. It produced updated deck narrative sections, revised financial model commentary and labels, a clean metrics summary derived from the source data, a reconciled cap table, customer case study write-ups, a competitive landscape overview, and a data room index that cross-referenced everything.

Let me be clear about what’s happening here. The AI doesn’t understand fundraising. It doesn’t know why this particular investor cares about net revenue retention more than logo count, or why the cohort analysis matters more than the headline growth rate. That judgment — understanding what this investor would actually probe, and what story the numbers needed to tell — came from me, sitting with the founder, working through what the investors will be looking for and the DD review would look like.

What the AI does is follow instructions precisely and generate consistent output across twenty documents faster than any human can. When you tell it “use this ARR figure everywhere, derived from the model, never from the dashboard,” it actually does. Every time. Across every document.

Humans are creative, contextual, and terrible at mechanical consistency across fifteen files. AI is the opposite. That’s the division of labor.

A second agent — completely separate from the writer — audits every document against a checklist of requirements. It doesn’t write anything. It only verifies.

The output looks like this:

Check Document Evidence Status Revenue figures consistent across deck + model Deck slide 8, Model ‘Summary’ tab Both show €100K ARR, quarterly breakdown matches Addressed Cap table reflects post-SAFE state Cap table v3, SAFE agreements folder All 3 SAFEs converted at correct caps Addressed Customer logos match case studies Deck slide 14, Case Studies folder 6/6 logos have corresponding write-ups Addressed Burn rate / runway consistent Deck slide 18, Model ‘Cash’ tab Deck says 14mo runway, model shows 13.2mo at current burn Partial

Every check mapped to specific evidence. Status assessed. Gaps flagged.

Why a separate agent? Because the person who writes a document is the worst person to verify it. They know what they meant. They see the intent, not the output. A dedicated reviewer — whether human or AI — reads what’s actually on the page.

Before sending anything, we ran a systematic audit across four dimensions:

Coverage mapping. Do we have everything the investor asked for? Every document on their checklist accounted for.

Document coherence. Do the numbers agree across documents? Does the deck’s growth narrative match the model’s assumptions? Does the runway figure on slide eighteen trace to the cash flow tab?

Structure integrity. File naming, folder structure, version numbering, data room index accuracy.

Prohibited content. No draft watermarks. No internal notes (”ask Sarah about this number”). No employee compensation details in the wrong folder. No customer names that shouldn’t be there.

This is where it got interesting.

The writer agent produced solid documents. The reviewer confirmed the numbers were consistent. Everything looked clean.

Then the red team caught fourteen issues across the package. Three were critical.

Critical issue one: The pitch deck still had “DRAFT — Not for Distribution” in the footer of every slide. Every single slide. Footer text in eight-point font. The kind of thing you stop seeing after the fourth review because your eyes skip footers entirely. This was the “final” version that was about to go into the data room. An embarrassing, entirely preventable error that a human reviewer almost certainly would have missed after reading the same deck for the fifth time.

Critical issue two: The financial model’s “Summary” tab showed €100K ARR. The “Revenue Detail” tab — one tab over, same spreadsheet — showed €50K. What happened was straightforward: the founder had manually updated the summary tab after a strong month, overwriting the formula with a hardcoded number. The detail tab was still formula-driven from the source data. The formula was right. The manual override was wrong. One cell. That’s all it takes to crater your credibility in a DD meeting. The investor opens the model, checks if the summary matches the detail, and it doesn’t. Now every other number in the room is suspect.

Critical issue three: The data room folder labelled “Legal” contained a draft employment agreement with a specific salary figure visible. Not the investor’s business at this stage. Not something you want in the data room at all. But it was in the same folder as the incorporation documents and the IP assignment agreements, and nobody had checked what else had ended up in there. It’s the digital equivalent of leaving a confidential document on the printer.

Beyond the critical issues, the coherence review caught more. The deck used “MRR” in two places and “ARR” everywhere else — same underlying metric, different time period, and the reader has no way to know which is intended. The model’s assumptions page listed 15% monthly churn, but the formula in the retention tab used 12%. One customer case study named a company that hadn’t signed an NDA yet. The data room index listed a “Board Minutes” folder that was empty.

Every single one of these errors is something I’ve seen in real data rooms. Probably more than once. They’re not AI failures. They’re founder-under-pressure failures — the exact mistakes you make when you’re shipping a product, managing a team, and building a data room at two in the morning. They just got caught before the DD call instead of during it.

The system caught the mechanical 80%. Metric inconsistencies across documents. Stale figures. Draft markers that should have been removed. Cross-reference mismatches. Version conflicts between tabs in the same spreadsheet.

The remaining 20% was judgment. Knowing that this investor cares about net revenue retention more than logo count. Understanding that “we’ll be profitable in eighteen months” needs a model tab that actually shows the path — not a deck slide that asserts it. Recognising that the founder’s strongest case study wasn’t even in the deck because they thought a pilot with a ten-person company didn’t matter — but for this investor, that pilot demonstrated exactly the integration depth they evaluate.

That’s domain knowledge. That came from sitting with the founder, understanding the business, and thinking through what the DD conversation would actually look like. The AI didn’t provide any of that. The AI made sure it was expressed consistently across all documents.

In Many Interfaces, One Intelligence Layer, I wrote about the pattern emerging across technology: shared intelligence, plural surfaces. The data room turned out to be this pattern in practice.

The company’s story — the market thesis, the product advantage, the growth trajectory, the unit economics — was encoded once. It flowed through different document types: the pitch deck, the financial model, the metrics summary, customer case studies, the cap table, the data room index. Same intelligence. Different surfaces.

Change the surface — from deck to model to case study to cap table — and the underlying story stays consistent. That’s the point. The intelligence layer is the company’s understanding of itself. The interfaces are the document types the investor needs to see. The red team verifies that the translation between them didn’t introduce contradictions.

Every founder raising a round faces some version of this. The documents differ. The investors differ. The pattern doesn’t.

Encode what matters in clear instructions. Let AI handle the mechanical consistency across documents. Use a separate agent to verify. Red-team before you send. Keep the domain judgment — the part that requires understanding what the investor actually cares about and what story the numbers should tell — human.

The hard part isn’t the AI. The hard part was sitting with the founder long enough to understand what the real story is. Which numbers matter. How the documents should reference each other.

AI turned what would have been three weeks of late nights into a focused couple of day sprint. But only because someone knew what to tell it.

S.