Guide

How to prepare for technical due diligence: a founder's guide

Preparing for technical due diligence means assembling, before an investor asks, the evidence that your software does what your deck says, that your team can keep building it, and that nothing in the code, the licences or the security posture will surprise anyone after the money moves. This guide is written for founders and CTOs raising a round or selling the company. It covers what a technical review asks for, what to put in the engineering data room, how to present your architecture and roadmap, how the review changes from seed to Series B and at a sale, what changes when the code was written by AI, and a day-by-day checklist for the two weeks before the review starts.

Published September 17, 2026. Editorial.

Key takeaways

A technical review is a search for risk to the investment and a test of whether your description of the system matches the system. Prepare by running the review on yourself first, months ahead, so every finding in the room is one you already know.
Investors send a list. Matt Van Itallie's 2022 TechCrunch checklist has seven headings: product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps. Answer each heading with an artefact, then a sentence, in that order.
The standard fundraising data room has no technical folder. a16z's 2022 guide names five core components and none of them is engineering. The engineering data room is the folder you build yourself, and this guide says what goes in it.
Match the preparation to the stage. Y Combinator's seed guide tells founders not to spend too much time on diligence documents for a seed round; by Series B the reviewer expects incident history, a dependency inventory and a roadmap with costs.
A known problem with a plan reassures a reviewer. The same problem discovered as a surprise costs you the trust that every later answer depends on. Disclose the serious items in your own words before the reviewer finds them.
If AI wrote most of your code, the reviewer's question is how you know it works. Reveneau's answer for its own builds is an evaluation suite written from the specification, run on every change, with the run history kept as evidence. Show yours, or show your review trail.
Time spent on diligence changes outcomes for the investor. Wiltbank and Boeker's 2007 study of 1,137 angel exits found a 5.9X overall multiple where diligence ran above the 20-hour median against 1.1X below it. Expect the review to be thorough and prepare for it that way.

Preparing for technical due diligence is the work of assembling, before anyone asks, the evidence that your software does what your deck says it does, that the team can keep building it after the round closes, and that nothing in the code, the third-party licences or the security posture will surprise the investor after the money has moved.

This guide is for the people on the receiving end of the review: founders, CTOs and heads of engineering at a company that is raising a seed, Series A or Series B round, or that is being acquired. Investors run the review; you prepare for it. The investor's method is written up in our guide to technical due diligence, and every page here points at the matching page there, so that when a reviewer sends you this guide you are both reading from the same script.

A note on what this guide is. Reveneau builds software for startups with AI writing the code and an evaluation suite, written from the specification, deciding whether each change ships, and we also prepare companies for a technical review by running the review on them first. Everything below is the method we use for that preparation. None of it requires you to hire anyone, and most of it is work a small team can do in two weeks if it starts with the right list.

The short version

If you read nothing else on this page, this is the answer to "how do I prepare for technical due diligence":

Get the investor's list early and answer every item with an artefact, then a sentence. A reviewer who receives a folder of real documents spends the review reading, and one who receives a slide deck spends it asking.
Run the review on yourself first, months ahead. Use the same checklist the reviewer will use. Fix the serious findings, write down the rest with a plan and a date.
Build the engineering data room. The standard fundraising data room has no technical folder, so you make one: architecture, dependencies and licences, security evidence, process evidence, team and roadmap.
Present the architecture you have, at three levels of zoom, with the decisions that produced it and the parts you would change. Never present the architecture you wish you had.
Match the depth to the stage. A seed investor wants to see the product working and the founders able to explain it. A Series B reviewer wants incident history, a dependency inventory and a roadmap with costs.
Disclose the serious problems in your own words before the reviewer finds them. A known problem with a plan is a line item; the same problem as a surprise is a trust problem.
If AI wrote the code, show how you know it works: the test or evaluation suite, its run history and the review trail on the pull requests.
Brief the team. The engineers in the room should know what the reviewer will ask, who answers what, and that the correct response to a question nobody can answer is "we will find out and send it today".

What technical due diligence is, from your side of the table

A technical due diligence review is a structured look at your technology, run by or for an investor or acquirer, to find risk that would threaten the money about to go in. The reviewer is usually an outside engineer or firm that the investor trusts. They read the code, the architecture, the security evidence, the dependencies, the process and the team, and they write a report with findings graded by severity.

Three things follow from that definition, and each one changes how you prepare.

The reviewer is looking for risk, and the style of your code is beside the point. The reviewer is asking whether the system can grow to the size the deck promises, whether it can be maintained by people other than the ones who wrote it, whether it is secure enough for the customers it holds data for, and whether the licences on the code you did not write allow you to sell what you are selling.

The reviewer is also testing your account of the system. Every claim in the deck and the data room is a statement the reviewer can check against the repository. A deck that says "fully automated deployment" and a repository with a deploy script last run by hand in March is a finding, and the finding is about the deck. The single most damaging outcome of a review is a gap between what the founders said and what the reviewer found, because it puts every other claim under suspicion.

The reviewer has a list, and it is not a secret. Matt Van Itallie, the founder of the codebase analytics firm Sema, published a preparation checklist in TechCrunch on 26 October 2022 with seven headings: product roadmap, code quality, intellectual property, security, development process, engineering team contributions, and DevOps [1]. The day before, he published the eight questions a reviewer is trying to answer [2]. The lists reviewers use differ in detail and agree in shape. Our page on what a technical review asks for walks through the list heading by heading, and the investor's version is the technical due diligence questionnaire.

How to prepare, step by step

The preparation is seven steps. The first four are the ones most founders skip and the ones that decide the review.

Get the list. Ask the investor, before the review is scheduled, what their reviewer will want to see. If they do not have a list, use the seven headings above and the investor-side technical due diligence checklist. Put the list in a spreadsheet with one row per item, an owner, and a status.
Run the review on yourself. Months before the raise if you can, two weeks before if you cannot. Go through every row and answer it honestly, with the artefact that proves it. Where there is no artefact, write "none" rather than a sentence that describes what you intend to build.
Sort the findings into fix, disclose, and accept. Fix the serious items you can fix in the time you have: the single engineer who is the only person who understands the billing system, the secrets in the repository history, the copyleft dependency in a product you distribute. Disclose the serious items you cannot fix in time, in your own words, with a plan and a date. Accept the rest and write it down; a reviewer expects technical debt and is reassured by a list of it.
Build the engineering data room. One folder per heading, real artefacts in each, a one-page index at the top that says what is where and what is missing. The page on the engineering data room gives the folder structure and the contents of each folder.
Prepare the architecture walkthrough and the roadmap. Three diagrams at three levels of zoom, the decisions behind the shape of the system, and a roadmap for the next twelve months that says what the money buys. Presenting your architecture to investors and a technical roadmap for a fundraise cover both.
Brief the team. Tell every engineer who might be in the room what the review is, what the reviewer is likely to ask, who answers which topic, and what to do when nobody knows the answer. Reviewers interview engineers separately from founders, and the interviews are where the gap between the deck and the system shows up first.
Run the review as a walkthrough. Open with the index, the known problems and the plan for each. Then let the reviewer read. Answer every request the same day. The two-week checklist turns steps 2 to 7 into a day-by-day plan.

What to check, heading by heading

The seven headings below follow Van Itallie's 2022 checklist [1], because it is the most complete public list, and because a reviewer who did not write their own list has probably read it. Under each heading is what the reviewer is trying to learn and what you should have ready.

Product roadmap. The reviewer wants to know whether the team works on what the company says matters. The checklist asks for the process you use to collect user and customer feedback, a sample of that feedback, the last twelve months of product management data (tickets, for example) split between new features and maintenance, and the roadmap for the next twelve months [1]. Have the ticket export ready and the split computed, because the reviewer will compute it if you do not.

Code quality. This heading covers testing, refactoring needs, static analysis, third-party code, and the architecture description with diagrams [1]. The reviewer's underlying question is whether the codebase is something a team can keep building on at the speed the plan requires. The investor-side page on assessing code quality explains what a reviewer measures; our page on what investors look for in a startup's codebase turns that into what to have ready.

Intellectual property. The list asks for an overview of the IP, evidence of domain ownership, inbound and outbound licences, how third-party code with copyleft licences is handled, and IP assignment and confidentiality agreements for every employee and contractor who touched the code [1]. Morgan Lewis's June 2026 note on open-source diligence in M&A lists six areas of inquiry, from whether the company has a written open-source policy to whether it maintains an approval process for copyleft-licensed software, and explains the concern plainly: proprietary code packaged with copyleft code and shipped to customers can be required to be made public, "which would diminish the commercial value almost immediately" [6].

Security. The checklist asks for incidents within the past three years, security scan reports, how access to the code repository is authenticated, recent penetration tests and audits, standards such as SOC 2, what customer data is accessed, and a legal assessment of GDPR and CCPA compliance [1]. The investor-side page on assessing security and compliance covers what the reviewer does with these.

Development process. How many version control systems are in use, development activity by repository over the last twelve months, and whether the team is coached on commit hygiene, unit test additions and linking commits to tickets [1]. A reviewer reads the commit history for this heading and rarely needs to ask.

Engineering team contributions. A list of current and former developers, which of them matter most to the codebase, and how the company would manage if the most important ones left [1]. This is where single-person risk is found, and it is the finding that most often makes it into the report's first page. The investor-side page on assessing the engineering team describes how a reviewer maps knowledge to people.

DevOps. Licence compliance for purchased software, the list of engineering tools, a description of the infrastructure with its budget, the on-premises and cloud split, and planned improvements with their costs [1]. The reviewer is checking that the cloud bill in the model matches the infrastructure in the account.

What reviewers measure about how you ship

Two of the headings above, code quality and development process, are where reviewers increasingly ask for numbers rather than descriptions. The numbers most often asked for are DORA's software delivery metrics, which the DORA research programme defines as change lead time (from commit to running in production), deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate [8]. DORA describes the first three as throughput measures and the last two as instability measures.

Being able to compute them from your deployment log and your incident log for the last quarter is enough, as long as you can also say the numbers out loud without looking them up. A team that deploys weekly with a 5 percent change fail rate and a team that deploys twice a year with a 40 percent change fail rate are both describable in one sentence, and a reviewer will believe the sentence if the logs are in the data room.

Common mistakes

Presenting the system you wish you had. The reviewer reads the repository. Any gap between the deck's architecture and the repository's architecture is a finding about the deck, and it costs more than the gap itself. Present what exists, and separately present what you plan to change and why.

Hiding known problems. A serious problem that you disclose is a line item with a plan. The same problem found by the reviewer is a trust problem, and it makes them re-check every other claim. Disclose first. The investor-side page on technical due diligence red flags lists what a reviewer treats as serious, and it is a good list to read as a list of things to disclose.

Over-preparing at seed. Y Combinator's guide to seed fundraising says plainly: "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." [4] At seed, a working product, a clean repository and a founder who can explain the system are the preparation. The page on how technical diligence changes by stage says where the line moves at Series A and Series B.

A data room with no technical folder. a16z's 2022 guide to data rooms, written by Justine Moore, names five core components: pitch deck, cap table, historical P&L and burn, usage data, and LTV/CAC with payback period [3]. It has no engineering category at all. That is the standard founders copy, so the standard fundraising data room arrives with nothing for the technical reviewer to read. Build the engineering folder separately.

Numbers that disagree with each other. The same a16z guide lists its red flags for a data room: numbers that are inconsistent with the deck, numbers that are inconsistent across tabs, limited historical data, and selectively presented metrics [3]. Every one of those applies to technical claims too. If the deck says 99.95 percent uptime, the status page and the incident log should say the same.

Treating AI-written code as something to hide. If a large share of your code was written with AI tools, the reviewer will ask, and the answer "we do not know how much" is the finding. Know the share, show the review trail, and show the tests or evaluation suite that decided each change was safe to merge. The page on preparing an AI-written codebase for review covers this, and the investor's view is at diligence on an AI-written codebase.

No owner. Preparation that belongs to everyone belongs to nobody. Name one person who owns the list, the folder and the schedule, and give them the authority to pull engineers off other work for two weeks.

What it costs and how long it takes

The investor normally pays for the review itself. Your cost is preparation time, plus any outside help you bring in to run the review on yourself first.

Two vendors publish figures for what a technical review costs the party paying for it, and both are the vendors' own numbers. MEV, a software firm that sells the service, states on its own page (updated 5 August 2026) that its technical due diligence engagements "typically range from $5,000 to $30,000" and that a review "usually takes around 2-4 weeks, depending on how complex the system is" [15]. Papermark, a data room vendor, publishes a rate table (updated 19 August 2026) that puts specialist technical due diligence firms at $300 to $600 per hour and Big Four technology advisory at $400 to $700 per hour [16]. Neither figure is a market study; treat them as two price lists. The investor-side page on what technical due diligence costs has the fuller picture.

How much time an investor spends matters to you because it predicts how deep the review goes. Robert Wiltbank and Warren Boeker's November 2007 study for the Angel Capital Education Foundation, covering 539 angel investors and 1,137 exits, found the median length of due diligence before an angel investment was 20 hours, with a mean of 60 [5]. It also found that outcomes differed with the time spent: exits where the investor's diligence ran above the 20-hour median returned an overall multiple of 5.9X, against 1.1X below it, and 65 percent of the below-median exits returned less than 1X against 45 percent above. The top quartile, over 40 hours, returned 7.1X [5]. Investors who have read that study spend more hours, and a founder should prepare for the investor who has.

For your own preparation, plan two weeks of one person's time at half capacity to build the data room and run the self-review at seed or Series A, and more for a Series B or a sale, where the dependency inventory and the security evidence take longer to assemble. The two-week checklist is built on that assumption.

Preparing for a sale

An acquisition review is a fundraising review with the severity turned up, because the buyer will own every problem. Morgan Lewis's June 2026 note on technology M&A describes technical diligence as having become "critical alongside legal and financial review", with a focus on data rights, IP and inventor ownership, and open-source compliance, and describes transaction documents evolving to include AI and data compliance representations, special indemnities, special escrows and staged investments [7]. Each of those is a clause that turns an unresolved technical finding into money held back from the seller. The page on preparing for a sale covers the seller's review, and the investor-side page on sell-side technical due diligence is the buyer's view of the same work.

Where Reveneau fits

We work on both sides of this. We build software for early-stage companies with AI writing the code and an evaluation suite deciding what ships, which means the companies we build for arrive at their first technical review with the evidence a reviewer wants already in the repository: a specification, the evaluations derived from it, and the run history of every change. If you are building with us, that is described at Build with Us for startups. We also prepare companies for a review by running it on them first, using the same list the investor's reviewer will use, and helping them fix what can be fixed in the time available. Either way, the aim is the one this guide keeps returning to: a review with no surprises in it, where every finding is one you disclosed.

The pages that follow take each part of the preparation in turn. Start with what a technical review asks for if you have a review scheduled, and with what investors look for in a startup's codebase if you are months out and want to know what to fix first.

Explore the guide

Start here

What a technical review asks for, and how to answer instead of just listing

A technical review asks for evidence under seven headings: product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps. That is the structure of Matt Van Itallie's preparation checklist, published in TechCrunch on 26 October 2022, and most reviewers' lists follow the same shape. The mistake founders make is answering each heading with a description of what the company does. A reviewer wants the artefact first (the ticket export, the licence inventory, the scan report), then one sentence that says what the artefact shows and what you are doing about it. This page goes through the list heading by heading and says what to hand over, and what a good answer looks like when there is nothing to hand over.

What investors look for in a startup's codebase

Investors look for five things in a startup's codebase: whether the tests would catch a broken change, whether anyone besides the author can change each core system, whether the third-party code carries licences that allow the product to be sold, whether changes reach production safely and often, and whether the code the reviewer reads matches the architecture the founders described. Those five map to Matt Van Itallie's eight reviewer questions of October 2022, to DORA's software delivery metrics, and to the open-source areas of inquiry Morgan Lewis listed in June 2026. This page says what each one looks like from inside the repository, what a reviewer measures, and which of the five to fix first when there is time to fix only one.

What to show

The engineering data room: which artefacts go in which folder

An engineering data room is the folder of technical evidence a founder hands to an investor's reviewer, organised so that every item on the reviewer's list has a place and every place has a real artefact or a dated note saying why it is empty. The standard fundraising data room does not include one: a16z's guide of 25 August 2022 names five core components (pitch deck, cap table, historical P&L and burn, usage data, and LTV/CAC with payback period) and no technical category at all. This page fills that gap with seven folders that follow the headings a reviewer uses, the contents of each, the five things to leave out, and the one-page index that lets the reviewer start reading in the first ten minutes.

Presenting your architecture to investors

Presenting your architecture to investors means showing the system you have, at three levels of zoom, with the decisions that produced it and the parts you would change, in a form the reviewer can check against the code. The three levels are the top three of Simon Brown's C4 model: the system in its context, the containers it is made of, and the components inside the containers that matter for the deal. The decisions are recorded as architectural decision records, each capturing one decision with its rationale and consequences. The rule that decides whether the presentation helps or hurts is that every box on every diagram must exist in the repository, because the reviewer will look for it there.

A technical roadmap for a fundraise

A technical roadmap for a fundraise is a twelve-month plan that says what the engineering team will build with the money being raised, what share of the team's time goes to maintenance and technical debt, and how the team's measured delivery capacity supports the dates. It is the document a reviewer reads most closely after the code, because it connects the round to the product. Matt Van Itallie's TechCrunch checklist of 26 October 2022 asks for the roadmap for the next twelve months alongside twelve months of ticket history split between new features and maintenance, and his seventh reviewer question asks how much finance invests in preventing technical debt. This page gives the roadmap a shape that answers all three at once.

By situation

What changes in technical diligence from seed to Series A to Series B

Technical diligence changes by stage in depth, in who runs it, and in what counts as a finding. At seed, the review is often an hour with a technical partner or an angel, the product is the evidence, and Y Combinator's seed fundraising guide tells founders not to spend too much time on diligence documents. At Series A, an outside reviewer or a technical partner spends days in the repository and expects tests, a dependency inventory and a team map. At Series B, the review runs for weeks, covers three years of incident history, computes delivery metrics from the logs, and reads the roadmap against the plan the round funds. This page says what changes at each stage from the founder's side, so that preparation matches the review instead of overshooting at seed or undershooting at Series B.

Preparing an AI-written codebase for review

Preparing an AI-written codebase for review means being able to answer four questions with evidence: what share of the code was generated, what reviewed each generated change before it merged, what test or evaluation run decided it was safe to ship, and what a security scan of the current code finds. Generated code is normal in 2026. The finding is a share nobody measured, or a measured share with no trail behind it. Veracode's report of 30 July 2025 found 45 percent of AI-generated code samples failed security tests across more than 100 models, and its spring 2026 update found the rate unchanged, so a reviewer who knows those figures will ask how you caught the failures. This page says what to have ready and, for teams that build the way Reveneau does, what an evaluation suite proves.

Preparing for a sale: the seller's technical review

Preparing for a sale means running the buyer's technical review on your own company first, because at a sale every unresolved finding becomes a clause. Morgan Lewis's note of 1 June 2026 on technology M&A describes technical diligence as having become critical alongside legal and financial review, with a focus on data rights, IP and inventor ownership and open-source compliance, and describes deal documents evolving to carry AI and data compliance representations, special indemnities, special escrows and staged payments. Each of those is money held back from the seller against a technical finding. This page is the seller's preparation: the review to run on yourself, the findings that turn into clauses, the ones you can close before the buyer arrives, and how to present the ones you cannot.

Checklist

The two weeks before a technical review: a preparation checklist

The two weeks before a technical review are enough to build the engineering data room, run the review on yourself, fix what can be fixed in ten working days, disclose the rest with a plan, and rehearse the walkthrough, if one person owns the work at half capacity and follows a list. This page is that list, day by day, with nothing held back for a download. It follows the seven headings of Matt Van Itallie's preparation checklist published in TechCrunch on 26 October 2022, adds the reconciliation pass that a16z's data room guide of 25 August 2022 makes necessary, and ends with the rehearsal. Print it, assign a name to each day, and start on day one with the investor's list in hand.

Common questions

How do I prepare for technical due diligence?

Prepare for technical due diligence by getting the investor's list early, running the review on yourself with that list, fixing the serious findings, disclosing the ones you cannot fix in time, and building an engineering data room with a real artefact for every item. Matt Van Itallie's TechCrunch checklist of 26 October 2022 gives the seven headings most reviewers use: product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps.

What does a technical due diligence reviewer look for?

A technical due diligence reviewer looks for risk to the investment: whether the system can grow to the size the deck promises, whether people other than its authors can maintain it, whether it is secure enough for the data it holds, whether the third-party licences allow the product to be sold, and whether the founders' description matches the repository. Van Itallie's 25 October 2022 list of eight questions is the shortest public statement of what the reviewer is trying to answer.

How far ahead should a startup start preparing for technical due diligence?

Start preparing for technical due diligence months before the raise if you can, and two weeks before the review if you cannot. The fixes that matter most, such as removing single-person knowledge of a core system or replacing a copyleft dependency, take weeks. Two weeks is enough to build the data room and run the self-review with the seven-heading checklist Van Itallie published in TechCrunch in October 2022, which is why this guide's checklist is built on that timeline.

Does a fundraising data room need a technical section?

Yes, and the standard template does not have one. a16z's guide to data rooms, written by Justine Moore on 25 August 2022, lists five core components: pitch deck, cap table, historical P&L and burn, usage data, and LTV/CAC with payback period. There is no engineering category. A technical reviewer therefore receives nothing unless you build a separate engineering folder with architecture, dependencies and licences, security evidence, process evidence, team and roadmap.

Should I hide known problems before technical due diligence?

No. Disclose known problems in technical due diligence before the reviewer finds them, with a plan and a date for each. A disclosed problem is a line item in the report; the same problem found by the reviewer is a gap between your account and the system, and it makes them re-check every other claim. a16z's 2022 data room guide lists numbers that are inconsistent with the deck as its first red flag, and the same rule applies to every technical claim.

How much preparation does a seed round need for technical due diligence?

A seed round needs light preparation for technical due diligence. Y Combinator's guide to seed fundraising, by Geoff Ralston, says: "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." A working product, a clean repository, no secrets in the history and a founder who can explain the system are the seed-stage preparation.

What metrics do investors ask for about engineering process?

Investors and their reviewers most often ask for DORA's software delivery metrics: change lead time from commit to production, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, as defined on dora.dev. Compute them from the deployment log and the incident log for the last quarter, put the logs in the data room, and be able to say the numbers without looking them up; a dashboard is optional.

How much does technical due diligence cost and who pays?

The investor normally pays for technical due diligence; the founder pays with preparation time. Two vendors publish their own prices. MEV states its engagements typically range from $5,000 to $30,000 and take 2 to 4 weeks (page updated 5 August 2026). Papermark's rate table (updated 19 August 2026) puts specialist technical firms at $300 to $600 per hour and Big Four technology advisory at $400 to $700 per hour. Both are vendor price lists, so treat them as such.

How long does an investor spend on due diligence?

It varies by investor type, and the only measured figure for angels is old. Wiltbank and Boeker's November 2007 study for the Angel Capital Education Foundation, covering 539 angels and 1,137 exits, found a median of 20 hours of due diligence per investment and a mean of 60. Exits with above-median diligence returned an overall 5.9X against 1.1X below the median, so investors who know the study tend to spend the hours, and founders should prepare for that.

What changes in technical due diligence when the code was written by AI?

When the code was written by AI, the reviewer asks what share was generated, what reviewed it, and how you know it works. Veracode's 30 July 2025 report found 45 percent of AI-generated code samples failed security tests across more than 100 models, so the reviewer will look for a security scan and a test or evaluation suite with run history. Reveneau's own builds keep an evaluation suite derived from the specification and the run record of every change as that evidence.

What is the biggest mistake founders make in technical due diligence?

The biggest mistake founders make in technical due diligence is presenting the system they wish they had. The reviewer reads the repository, so any gap between the deck's architecture and the real one becomes a finding about the deck, and that finding costs more than the gap. Van Itallie's eighth question in his 2022 TechCrunch list, whether the leadership is ready to learn and grow, is the reviewer's test of how you handle that gap when it appears.

How is preparing for a sale different from preparing for a funding round?

Preparing for a sale is preparing for a funding round with every finding priced. Morgan Lewis's 1 June 2026 note on technology M&A describes technical diligence as critical alongside legal and financial review, and describes deal documents now carrying AI and data compliance representations, special indemnities, special escrows and staged payments. An unresolved technical finding at a sale becomes money held back from the seller, so the seller runs the full review first and closes what can be closed.