Engineering artefacts for the data room: what goes in which folder

The engineering artefacts an investor should request for the data room are the ones that let a reviewer confirm a fact without asking the target to describe it: repositories and their history, the architecture as drawn by the team for its own use, the record of incidents, the delivery metrics the pipeline already produces, security reports from third parties, the open source inventory, twelve months of cloud invoices, and the engineer roster with ownership. Everything else the target might add is a presentation.

This page is for the investor side: what to ask for, how to organise the request, and how to read what arrives. The founder assembling the room should read the engineering data room in the preparation guide, which covers the same folders from the other side. Reveneau's diligence request uses the eight folders below and asks, for every folder, for the artefact that already existed before the deal and for read access to the system it came from, because a document written for the reviewer proves that the company can write documents.

For how the artefacts are used once they arrive, read how to run technical due diligence and the pillar guide.

Why does the standard data room have no engineering folder?

The standard data room has no engineering folder because the guidance investors and founders follow was written for financial and commercial review. a16z's The Insider's Guide to Data Rooms (Justine Moore, 2022-08-25) lists five categories to include: the pitch deck, the cap table, historical P&L and burn, usage data, and LTV/CAC and payback period. It lists five to leave out unless asked: org chart and team bios, three to five year projections, tax returns and legal documents, board minutes, and market sizing. Code, architecture and engineering documentation appear in neither list.

Y Combinator's A Guide to Seed Fundraising goes further for the earliest stage: "Do not spend too much time developing diligence documents for a seed round. If an investor is asking for too much due diligence or financials, they are almost certainly someone to avoid." Both pieces of advice are sound for their purpose, and both leave the technology unexamined. Matt Van Itallie's TechCrunch prep checklist of 2022-10-26 is the closest published list of technical items, with seven categories: product roadmap, code quality, intellectual property, security, development process, engineering team contributions, and DevOps. The folder structure below covers those and adds cloud cost and data handling.

What goes in each folder?

Eight folders cover a technical review. The table names each one, what belongs in it, and what it proves to the reviewer. The third column is the one to keep in mind when a target asks why a folder matters.

Folder	What goes in it	What it proves
1. Codebase	Read access to every repository; an inventory of repositories with language, size, owner and last commit date	Whether the company knows what it owns, and whether the reviewer can read the asset being bought
2. Architecture	The current architecture diagram as the team uses it, with its last-updated date; the infrastructure definition (code, if any); the list of external services and APIs	Whether the system as drawn matches the system as deployed, and where the single points of failure are
3. Reliability	The incident log for twelve months with duration and root cause; the on-call rota; the disaster recovery plan and the date it was last tested	Whether reliability is measured or assumed, and whether recovery is a capability or a document
4. Delivery	Deployment frequency, change lead time, change fail rate and time to recover, pulled from the pipeline; the code review policy; the test suite and its last runs	Whether the team ships at the pace the plan assumes, using DORA's four keys as the yardstick
5. Security and compliance	The last external penetration test report and remediation status; current certification reports; the access list for production; the secrets policy; the incident and breach history	Whether the security claims in the deck have documents behind them
6. Open source and IP	A component inventory with licences in SPDX identifiers, or a software bill of materials; the written open source policy; the last scan output; contractor and employee IP assignment agreements; a list of AI-generated portions and the review process for them	Whether the company owns what it sells and whether any licence obligation attaches to the proprietary code
7. Cloud and cost	Twelve months of cloud invoices by account and service; commitment contracts with end dates; cost per unit of usage over the year	Whether the cost of running the system moves with revenue or faster than it
8. Team	The engineer roster with role, start date, location, employment type and systems owned; attrition over twenty-four months; the hiring plan	Where key-person risk sits and whether the team in the plan is the team in the building

Folder 6 deserves a note on format. CISA describes a software bill of materials as "a nested inventory, a list of ingredients that make up software components", and SPDX identifiers (version 3.29.0 of the list was released 2026-09-16) are the standard short names for licences. A target that can produce an inventory in that form has tooling; one that produces a spreadsheet typed by hand has a project. Morgan Lewis's note of 2026-06-05 lists inventories and scans among the things buyers ask about, and observes that scans often find issues that have to be fixed before closing. Open source licence due diligence covers what to do with the inventory.

How should the request be worded?

Word the request as a list of artefacts that already exist, plus access grants, with a covering note that says documents produced for the review will be treated as claims. The note changes what arrives.

Three phrasings help. First, ask for the artefact "as currently used by the team", which rules out the diagram redrawn for investors. Second, ask for "read access to" rather than "an export of", because an export can be edited and a live system cannot. Third, ask for the date on everything: the last-updated date of the diagram, the last-run date of the tests, the last-tested date of the recovery plan. A date is the cheapest verification there is.

Send the request alongside the questionnaire, which asks the questions the artefacts answer, at least a week before the interviews. Keep the request to the folders your thesis depends on; a seed deal does not need folder 7 in full, and a buyout of a platform business needs every row. Scope by stage sets the depth.

What does an empty folder mean?

An empty folder means the company does not track that thing, and the gap is a finding in its own right rather than an administrative delay. A company with no incident log has incidents it cannot describe. A company with no licence inventory has licence obligations it does not know about. A company with no delivery metrics has a pace nobody has measured.

Distinguish three cases when a folder comes back empty. The artefact exists and was withheld: ask again, and treat continued refusal as a red flag, because a team that hides problems in diligence hides them after close. The artefact does not exist and the company says so: record it, price it, and move on, since a truthful gap is a normal finding. The artefact was written last week to fill the folder: read it as a claim, verify it against the system, and note in the report that it was produced for the review.

The third case is the one to watch. A recovery plan dated the week of the request has never been tested. A licence inventory assembled by hand for the reviewer has never been scanned. Both are better than nothing and neither is a record.

How should the reviewer read what arrives?

Read each artefact for consistency with the others before reading it for content. The roster in folder 8 should match the commit history in folder 1. The incident log in folder 3 should match the change fail rate in folder 4. The commitments in folder 7 should appear in the invoices. Where two artefacts disagree, the disagreement is the finding, and it is usually more informative than either artefact alone.

Then read for what is absent. A twelve-month incident log with no entries longer than an hour is either an excellent system or an incomplete log; the delivery metrics will say which. A penetration test report with every finding marked remediated and no re-test is a report about the past.

Finally, write into the report which folders were complete, which were partial and which were empty, in the scope and access section, so a reader in a year knows what the review could and could not have seen. The data room is the evidence base for every finding in the document, and the document is only as good as the room was.