M&A due diligence for software: codebase provenance as a deal document — AI share, controls and gaps, priced with evidence

Last reviewed 2026-08-21 · 8 min read

Technical due diligence in software M&A now asks who and what wrote the codebase, how it was reviewed and what the gaps are. A recorded, verifiable development chain turns provenance into a deal document — AI share, review coverage, test evidence per release — so the risk is priced with evidence instead of discounted for uncertainty.

What it is

Technical due diligence in a software transaction used to be an architecture review and a licence scan: how is the system built, how much technical debt is there, are the open-source licences clean. AI- assisted development added a question that did not exist three years ago and that most sellers cannot answer: who — or what — wrote this codebase, and how was the machine-written part quality-assured?

Buyers care for concrete reasons. Code written by an agent and never reviewed by a human is an unknown defect and an unknown licence exposure. A product that embeds software with an unknown provenance carries that unknown into the buyer’s own liability under the recast Product Liability Directive and into the buyer’s documentation duties under the Cyber Resilience Act. And warranties about the codebase — ownership, originality, absence of infringing code — are only as good as the records behind them. When the record is missing, advisers do what they always do with uncertainty: they discount for it, in price, in escrow or in indemnities.

A recorded development chain changes the conversation. Instead of estimates and representations, the seller hands over a deal document: per-change authorship (human or agent, with tool and model), the human review that approved each change, the tests that ran and the releases that shipped — verifiable by the buyer’s own technical advisers without trusting the seller. Provenance becomes something that can be priced, not something that has to be assumed.

Who it applies to and when

Sellers of software companies and software-intensive businesses, acquirers and their technical and legal advisers, investors running diligence before a round, and — after closing — integration teams who inherit the asset and its obligations. The question appears at the point where a deal becomes serious: the data room, the technical diligence workstream, the warranty schedule.

There is no regulatory date, but the surrounding calendar is sharpening the question. From 9 December 2026 the Product Liability Directive makes software a product under strict liability, so an acquired product’s development record is part of the buyer’s own disclosure exposure. The Cyber Resilience Act’s documentation duties (full application 11 December 2027) travel with the product to whoever places it on the market. Buyers who know that will ask about provenance earlier and more precisely.

This topic is not part of our regulatory mapping — it is a transactional use of development evidence that draws on several regimes. The support section uses the mapping’s vocabulary and says where evidence stops and advice begins.

What it asks of your development process

For a seller, diligence readiness on provenance comes down to whether the development process left a record a stranger can check. The asks:

Authorship, per change, human or agent. Not “we use Copilot and Claude” but “these changes were authored by these agents, with these tools and models; these by people”. Git cannot provide it: the commit author is the human whose session the agent ran in.
Review linkage. For every agent-authored change, the human who approved it and when. This is the answer to “was the machine-written part quality-assured”, and it is the representation most sellers cannot evidence.
Test evidence and release scope. What each release contained, what tests ran, what the coverage looked like — release by release, because that is how the buyer’s engineers will sample.
Component and licence provenance. An SBOM and licence snapshot per release, so the open-source exposure is a fact rather than a scan on closing day.
Integrity the buyer can verify. The buyer’s advisers will, rightly, weigh a hash-chained, externally time-stamped record they can verify themselves far above a spreadsheet exported from the seller’s tools the week before.

For a buyer, the same record is the integration plan: which parts of the asset were machine-written and reviewed, where the gaps are, what has to be remediated before the product goes out under the buyer’s name and under the buyer’s CRA and PLD exposure.

The alternative is reconstruction — and reconstruction is what diligence discounts. Authorship that has to be inferred, reviews that have to be dug out of a tool’s history, tests that might have run: each is a representation the seller makes and the buyer prices as a risk. Evidence recorded while the work happened is the only kind that converts the risk into a number both sides can see.

For sellers there is a timing asymmetry worth understanding. Provenance evidence compounds: a record that covers three years of the codebase is worth far more in a data room than one that covers three months, and it cannot be backfilled. The cheapest moment to start recording is always now, and the most expensive moment to discover its absence is during diligence, when every unanswerable question becomes a line in the disclosure schedule. For buyers the same asymmetry is a negotiating fact: a target without provenance evidence is a target whose AI-authored share and review discipline must be assumed — and assumptions are priced.

What OLOBOLO evidence supports

OLOBOLO records development as it happens — authorship with actor type, tool and model; review decisions; test runs; sealed releases with SBOM and licence snapshots — in an append-only chain with RFC 3161 anchors, exportable as a canonical file the buyer’s team verifies with the open-source verifier. Release evidence reports summarise AI share, review coverage and test evidence per release. The table uses our mapping vocabulary; this is not a regulatory mapping — diligence is a transactional process, and valuation, warranties and IP conclusions belong to the advisers.

Diligence question	What you need to show	Chain evidence	Support
Who and what wrote the codebase?	Per-change authorship, human vs agent, tool and model, over the asset’s recorded history	`change.authored` with actor type and agent metadata; AI-share figure per release	Supports
Was AI-written code reviewed and tested?	Human approval and test evidence linked to each agent-authored change	`change.reviewed`, `test.evidenced` per change; review-coverage and test figures per release	Supports
What did each release contain, and is the licence exposure known?	Release scope with components and licences	`release.sealed` + SBOM and licence snapshot per release	Supports
Can the buyer trust the record?	Tamper-evident, time-anchored, independently verifiable	Hash chain + RFC 3161 anchors; canonical export + verifier	Supports
Valuation, IP ownership opinion, warranty drafting, indemnities, escrow	Legal and financial conclusions	—	Out of scope

One honest limit: the record covers what was recorded. Code written before recording began, or in repositories outside it, is not in the chain — the report says so, and a buyer should ask about coverage first.

Evidence, not a legal opinion: this maps what the chain supports as documentation — the advisers decide what the deal requires.

How to start

Record well before you sell. Provenance evidence is valuable in proportion to how much of the codebase’s history it covers; a record that starts in the data-room week covers nothing a buyer cares about.
Make agent authorship and human review explicit. Agents carry tool, model and session in commit trailers; reviewers’ approvals land as change.reviewed. That pairing is the diligence answer.
Seal releases with SBOMs. Each sealed release with its evidence report and component snapshot is a page of the deal document.
Put the export and the verifier in the data room. Let the buyer’s engineers verify the chain themselves. Provenance that can be checked is priced; provenance that must be believed is discounted.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

What does a buyer actually ask about AI-generated code in diligence?

Typically: what share of the codebase was written by AI tools, which tools and models, whether humans reviewed it before release, whether licence and IP provenance is clean, and whether the records can be trusted. The answers move price, warranties and escrow.

Can provenance be reconstructed for the deal?

Only partially and expensively. git authorship does not distinguish agent from human, review tools rarely keep linkable history, and anything reconstructed after the fact is exactly what a buyer's advisers discount. Evidence recorded while the work happened is the only kind that holds.

Does OLOBOLO give a valuation or an IP opinion?

No. It gives the record: who or what authored each change, what was reviewed and tested, what each release contained — verifiable by the buyer's team. Valuation, IP and warranty conclusions stay with the advisers.

Is this only for sellers?

No. Buyers use the same record after closing to integrate the asset, keep CRA documentation and product-liability evidence intact, and prove to their own insurers and auditors what they acquired.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.