In a traditional FDD, the numbers move down a chain: working files feed the databook, databook tables feed the slides, and the slides plus the team's findings become the report. Each handoff adds manual work. When a number changes upstream, the downstream files have to be refreshed and checked again.
On a buy-side engagement, we set up an experiment: give AI as much of the FDD as it could handle. We would maintain one live deal model; AI would generate every deliverable from it through skills — written methods for each recurring task. Nothing would leave the team without review.
What we actually built was a data model
A live deal model is a single working copy of the deal. Ours was, in engineering terms, a set of versioned, keyed tables. Ingested numbers kept their source references; derived numbers kept the transformations that produced them. It held the standardized financials, the operating data and the KPIs, alongside what usually lives in people's heads and inboxes: what management said about a number, proposed adjustments and open items.
Alteryx workflows and Python scripts handled the transformations; AI read the raw files and drafted the mappings, and we confirmed them: close to a thousand trial-balance accounts to one chart of accounts; general-ledger lines to the management accounts; legal entities to the group structure. The scattered inputs were standardized and harmonized into a single source of truth for the deal's numbers. Our job was designing the structure. AI did a growing share of the building, and we checked what it built. New information entered the model once.
We had to redesign the project folder first
A typical FDD project folder is designed for people. Experienced team members know where to look and which file is current. Now it had to serve people and AI at once. For AI, none of that unwritten knowledge exists. The obvious answer, a software repository, did not fit either: our users are not programmers, and our files are workbooks, decks and PDFs, not code.
So we designed a structure both could read. The folders follow the engagement's own phases, so people navigate by habit; the same structure is written down as instructions, so AI navigates by reading. Original sources stayed read-only, in the formats people open every day; next to them sat their machine-readable extracts, for AI. Standardized data, process state and generated outputs each had their own place, and outputs never mixed with sources. The workspace kept its own record — versions, open items, the history behind important changes — without programming tools. The AI steps ran inside the engagement's approved data boundary, under the same access and retention controls as everything else.
A shared drive stores files. An AI-native workspace stores files, instructions, state and history.
The IRL ran as a live input loop
We generated the first information request list from the scope; from then on, AI compared data room updates against outstanding requests and flagged missing periods, silently replaced versions and open questions. Over the engagement, the data room grew to a few thousand documents.
After each management or expert session, we linked its transcript to the questions it answered. When an answer raised a new question or needed written support, we put it back on the IRL.
We wrote onto it what the analysis needed; AI read from it what to fetch and check; and whatever entered the model arrived tied to its request. Across the data room, emails and session transcripts, the IRL was the key to where everything came from. Every new file and every management answer could change what the project knew, what it still needed and what had to be recalculated.
The deliverables became views of the model
New information was validated, standardized and reconciled into the model before reaching a databook tab or dashboard. A skill generated each view. For working capital, the skill named the data to draw on, the checks to run before the numbers could be trusted — the same checks we would run by hand — and the point where it stopped for a person.
Once the data model and the skill had matured, a databook rebuild was one automated run that took tens of minutes and, as a rule, came out reconciled; exceptions went to review. The formatting still needed human hands — the skill is not that polished yet. The dashboard used the same data, so no second set of numbers could drift.
The report is where the work stands today. In our experiments, skills could already draft report slides from structured data and analysis. We are now working on keeping evidence, narrative, reviewer decisions and approved manual edits connected to the model.
A human correction should improve the source of the report, not only the current PowerPoint file.
People decided what was material, challenged management's explanations and approved every adjustment and every output. The project stopped losing its state at human handoffs.
What we want to build next is the deal graph
Rebuilt as a graph, the model would hold entities, accounts, periods, adjustments, contracts, management answers and evidence as nodes, with the professional substance in the edges — this adjustment supported by that clause, explained by that answer, approved by that reviewer. The tables would keep producing the schedules; revenue by customer by month is a query on rows. The graph would add each number's chain: a reviewer could follow it from the schedule back to the calculation, the evidence and the approval.
Financial, commercial and tax diligence each rebuild the same picture of the target today; if the graph works, they could read from one. And the model would not expire with the deal: the same graph that answered the diligence questions would be the baseline the first hundred days run on. Carve-outs run on transaction-level data, at volumes still handled with manpower today; that is where a standardized model would matter most. All of that is still ahead of us. But the data room of the future is a database, not a folder of PDFs.
The production work is shifting from doing the analysis to designing the model it runs on and refining the skills that run it. Once both are mature, one more analysis is one more run, and AI can run many in parallel. From there, how much analysis a deal gets depends on what the model covers and what the skills can do. The problem we keep coming back to is how a deal model carries its structure forward — the mapping logic, the checks — while its contents stay behind with the engagement. We have not solved that yet.
The final deliverable can be stored as a file. The links among evidence, calculations and decisions are harder to preserve. Keeping those links changed more for us than any single automation did. We stopped treating the deliverable as the project.
Notes on the stack
Extraction. Python parsing and LLM extraction made data room documents machine-readable; the extracts kept source references. Next: extraction writing into staging, with validation before anything enters the model.
Standardization. Account mapping ran as Alteryx workflows plus AI-suggested mappings, confirmed by a person. Next: mapping logic carrying over between deals as patterns, while the data stays behind.
The store. Today: rebuildable, diffable keyed tables. Next: a property graph for the relationship layer, so that provenance — number to evidence to explanation to approval — becomes a query; and an index over the source documents, so AI reads the page itself.
The views. The databook renders to Excel and the dashboard to HTML; in our experiments, report slides render to PowerPoint. Next: HTML views reading live from the graph.