What a technical read is actually for
An investment committee can read a P&L without help. What it cannot read from a data room summary is whether the product that produced those revenues can be rebuilt, defended, priced and sold to the next customer without one specific person in the room. That is the job of a technical read on an AI company. It is a structured search for the distance between what the company says its system does and what the company's artifacts prove its system does. In the work our team does across federal and commercial engineering, that distance is almost never fraud. It is an accumulation of shortcuts that were reasonable at the time and expensive later.
Six things carry the weight. Model claims. Data rights and provenance. Reproducibility. Key-person concentration. Infrastructure cost at scale. And the boundary between a demonstration and a system. Everything else in a technical read hangs off those six. A read that produces a long list of code-style observations and no position on those six has not done the job.
A good read ends in three documents: a findings list with severity ratings, a mapping from each finding to a price or terms implication, and a set of questions to put directly to management. The last one matters more than buyers expect. Half the value of a technical read is knowing which four questions to ask on the next call and being able to tell, from the answer, whether the person answering has looked.
Where technical diligence findings cluster
Editorial weighting of where findings concentrate, drawn from practitioner reading and public sources. Illustrative, not a measured statistic.
Start with a claim inventory, not a code review
Opening a repository first is the most common mistake in AI diligence. Code is infinite and time is not. Start instead by extracting every factual claim the company has made in the deck, the website, the sales collateral, the statements of work, and the last two board packages. Put each one in a row. Next to it, write the single artifact that would settle it. Then request those artifacts by name.
The inventory does two things. It converts a vague engineering review into a finite list with an end state, and it surfaces the claims that map to no artifact at all. Those are the findings. A company that says "our extraction is 94% accurate" and cannot name the test set, its size, its provenance, or the decision threshold behind the number has told you something important, and it took twenty minutes to learn.
Model claims: the number is not the evidence
Accuracy alone is close to meaningless. Ask for six things alongside every headline metric: the base rate of the positive class, the class balance of the test set, the decision threshold, the provenance and date range of the test data, the sample size, and an interval around the estimate. A 94% figure on a set where 92% of records are negative is a coin flip with good manners.
Contamination is the quiet killer. If a model was trained on scraped web data and evaluated on a public benchmark, assume overlap until someone proves otherwise. Ask for a temporal split: train on records through a cutoff date, test only on records created after it. Ask whether any test record, or a near-duplicate of one, appears in training. Then run the evaluation yourself on data the company has never seen. Nothing in a technical read is worth more than one clean run on an instrument the seller did not build.
When two systems are compared, insist on a confidence interval or a paired test. A bootstrap interval or McNemar's test on paired predictions takes an hour and answers the only question that matters: is the gap real or is it noise? A difference whose interval crosses zero is a tie, no matter how it was drawn on the slide. Then ask the tail question. What are the failure modes, what is the cost of a false positive in the customer's workflow, and who reviews the output before it becomes an action?
Data rights and provenance: the question that can void the asset
For every dataset that touched training, ask where it came from, under what license, on what date, and who approved it. Non-commercial terms are the frequent trap. A large volume of public research data carries research-only or CC BY-NC conditions that prohibit exactly the use a commercial product makes of it. Scraped corpora carry the terms of the sites they came from. A dataset labeled "public" is not the same as a dataset licensed for the company's business.
Customer data is the second trap. Read the customer agreements for the clause that grants, or fails to grant, the right to train on customer content, and the clause that says whether the resulting model weights belong to the vendor or to the customer. Companies routinely train a shared model on data they only had the right to process for one account. That is a remediation cost, a churn risk, and in regulated sectors a reportable event. Where health data is involved, confirm the de-identification method against 45 CFR 164.514(b), which offers Safe Harbor removal of the eighteen identifiers or an expert determination on file. Ask to see the determination.
Third, ask whether any model was trained on outputs from a frontier vendor's API. Most frontier providers' terms restrict using their outputs to develop a competing model. A distilled student model built that way is an asset with a defect in the chain of title, and the defect is usually documented in the company's own commit history. Last, ask what happens when a customer demands deletion. Removing a row from a database is trivial; removing its influence from trained weights generally is not. The honest answer is a retraining cadence with a cost attached, and a company that has one has thought about this.
The contract lines that decide who owns the model
In every customer agreement: the data-rights clause, the assignment-of-work-product clause, and the training-grant clause. In every employment and contractor agreement: the invention assignment and the prior-inventions schedule. If any contributor to the core system never signed one, the company does not cleanly own its own code, and that is a closing condition rather than a footnote.
Federal revenue changes the ownership math
If any revenue came from a government contract, the data rights question has a second layer with its own rulebook. Civilian agency work runs on FAR 52.227-14, Rights in Data, whose alternates govern limited rights in data and restricted rights in software. Defense work runs on DFARS 252.227-7013 for noncommercial technical data and DFARS 252.227-7014 for noncommercial computer software. SBIR and STTR deliverables run on DFARS 252.227-7018, whose protection period now runs twenty years from award under the current SBIR/STTR Policy Directive.
The mechanical risk is markings. Rights are asserted through legends applied at delivery and through the assertions table submitted with the offer. Deliverables handed over without the correct legend can be treated as delivered with unlimited government rights, which means the government may release them to anyone, including a competitor. Ask for the delivery log and look at what was actually stamped on what was actually sent. Unmarked delivery is the cheapest way a company has ever given away its core asset.
Patents follow Bayh-Dole at 35 U.S.C. 200 through 212, implemented by the standard patent rights clause at 37 CFR 401.14. A subject invention must be disclosed to the agency within two months of the contractor's own notification, title must be elected within two years of that disclosure, and the reporting runs through iEdison. A missed election window can forfeit title to the United States. Pull the iEdison record and compare it against the invention disclosures in the company's files. This check takes an afternoon and occasionally changes a valuation.
Reproducibility: can the company rebuild its own product?
Here is the test we like best because it cannot be talked around. Take an engineer who has never seen the system, give them a clean machine, the repository, and the documentation, and ask them to reproduce the currently shipped model to within a stated tolerance. Time it. A healthy company does this in a day because it already does it in continuous integration. A fragile one discovers that the shipped weights came from a notebook on a laptop in March.
What makes the rebuild possible is unglamorous: training data under version control with content hashes, pinned dependency versions, container image digests rather than floating tags, seeds recorded, the full training configuration in source control next to the code, and an artifact registry that maps each released model to the exact commit and dataset that produced it. Add a model card in the style of Mitchell and colleagues and a datasheet for each dataset in the style of Gebru and colleagues, and a buyer can read in an hour what would otherwise take a month of interviews.
Reproducibility is also a commercial requirement, not only an engineering virtue. Regulated buyers increasingly ask a vendor to demonstrate that a given output can be regenerated from a given input and model version months later. Companies that cannot do this lose deals in review, and the loss shows up in the sales cycle length long before anyone names the cause.
Key-person risk is a code question before it is an HR question
Every deck says the team is the differentiator. The diligence version of that sentence is a measurement. Pull the commit history for the last twelve months and compute, per core module, the share of changes authored by a single person. When one contributor owns more than roughly two-thirds of the changes in the modules that produce revenue, the acquirer is buying an option on that person's calendar.
Then follow the credentials rather than the org chart. Who holds root on the cloud organization, the domain registrar, the model registry, the code-signing keys, and the production database? Who is named on the customer relationships? In federal work, personnel security clearances attach to individuals and facility clearances attach to organizations, so neither transfers because a cap table changed. Ask which named individuals hold what, and whether the facility clearance survives the transaction structure being contemplated.
Close the loop on paper. Every employee, contractor, intern and advisor who touched the core system should have a signed invention assignment with a prior-inventions schedule. Missing assignments are common, quietly fatal, and fixable before signing far more cheaply than after. Then ask the commercial question: which of these people are in the deal, on what retention terms, for how long, and what does the model look like if the top two leave in month seven?
Infrastructure cost at scale is where the gross margin lives
Ask for twelve months of cloud bills at line-item granularity. Not the summary, not the finance team's allocation, the actual detail export. Then map spend to units sold and compute the fully loaded cost of one unit of the thing the company charges for. Most operating models we see understate this, and the understatement is systematic rather than random.
The recurring causes are worth naming. Input and output tokens price differently, and a workload that grew its context window quietly repriced itself. Retrieval systems hold vector indexes in memory, and memory is billed whether or not anyone queries. Training and evaluation runs, staging environments, and idle reserved capacity are real cost and often sit outside the unit economics. Data egress is charged on the way out. And GPU utilization is the multiplier over everything: a fleet running at 30% utilization costs twice per unit what the same fleet costs at 60%, so ask for measured utilization rather than provisioned capacity.
Then test the forward case. Reserved and committed-use pricing is far below on-demand, and a company that models committed rates while actually running on-demand has a gap that widens with growth. Ask what the cost curve does at ten times current volume, what breaks first, and what the plan is when it does. The answer separates teams that have run production systems from teams that have run pilots.
| The claim | The artifact that settles it | What a weak answer looks like |
|---|---|---|
| "Our model is 94% accurate" | The evaluation suite run on a held-out set the reviewer chooses, with N and an interval | One number on a slide with no test-set description |
| "We own our training data" | A source-by-source license inventory with dates, terms and approver | "It's all public data" |
| "The system is reproducible" | A clean-machine rebuild that matches the shipped artifact digest | A README and a wiki page |
| "Gross margin is 78%" | Twelve months of line-item cloud bills mapped to units sold | A blended cost assumption in a spreadsheet cell |
| "No key-person risk" | Commit distribution by module plus signed assignments for every contributor | An org chart |
| "We are compliant" | The signed SSP and POA&M, or the control evidence itself | A grid of framework logos on the website |
Security and compliance findings that stall deals in legal
Ask what regulated data classes the system touches and what happens to them. If Controlled Unclassified Information is in scope, the marking and handling rules sit at 32 CFR 2002, the control baseline is NIST SP 800-171, and defense contracts carry DFARS 252.204-7012 with its 72-hour cyber incident reporting obligation. The CMMC program rule at 32 CFR part 170 and its acquisition clause have been phasing into defense solicitations, so the relevant question for a defense-exposed target is which level applies and what the assessment status is today.
Two smaller checks pay for themselves. Section 889 of the FY2019 NDAA, implemented at FAR 52.204-25, prohibits certain covered telecommunications equipment and services, and the representation is made by the company. Confirm it was made accurately. Separately, generate a software bill of materials and read the license column. AGPL-3.0 components and non-commercial-licensed models inside a proprietary product are a remediation item with a known cost, and they are far easier to find before closing.
Where the company sells internationally or employs engineers outside the United States, walk the export posture: ITAR at 22 CFR parts 120 through 130 for defense articles and technical data, and the EAR for everything else, including encryption software classified under ECCN 5D002. For AI governance, buyers now ask about NIST AI RMF 1.0 and ISO/IEC 42001:2023 by name. A target that has mapped its practices to one of them will close enterprise deals faster than one that has not.
If federal revenue is in the model, check eligibility before you sign
A financing or an acquisition can quietly delete a revenue line. SBIR and STTR eligibility rules at 13 CFR 121.702 require the concern to be at least 51% owned and controlled by one or more individuals who are U.S. citizens or permanent residents, or by other qualifying small businesses. There is a separate SBIR-only path allowing majority ownership by multiple venture capital operating companies, hedge funds or private equity firms at agencies that have elected to use it, with no single such entity holding more than 50%. STTR has no equivalent path. The company must also keep its registration current in the SBIR company registry.
Size status is the other tripwire. Affiliation rules can aggregate an investor's portfolio into the target's employee count, and 13 CFR 121.404 requires recertification within 30 days of a merger, acquisition or sale. An asset transaction generally requires a novation under FAR subpart 42.12 before the government recognizes the successor in interest, which takes time and is not guaranteed. If set-aside services revenue is material, check performance against the limitations on subcontracting at 13 CFR 125.6. Model all of this against the proposed structure before the term sheet is signed rather than after.
Demo or system: seven questions that separate them
The most useful hour in a technical read is the unscripted one. Ask to see the system run on a record the reviewer picks, live, with no preparation. Everything below follows from that.
- Does it run end to end without a human preparing the input first?
- Does it work on a record the reviewer chooses, right now, on the call?
- What happens when the input is malformed, empty, oversized or hostile?
- What is p95 latency under concurrent load, not median latency on an idle box?
- What is the rollback path when a model update degrades output quality?
- Who gets paged at two in the morning, and what did the last three incidents cost?
- What work was deferred to make this demonstration possible?
The last question is the one that gets honest answers, because every engineering team has a deferral list and most are relieved to be asked about it. A team that produces theirs in thirty seconds is a team that runs a real system. A team that says there is nothing deferred has either an extraordinary product or a communication problem, and the next ten minutes will tell you which.
How we run the read
Five-day technical assessment
Our team runs these reads the way we build systems, which is the reason the findings are specific enough to negotiate against. We are an SBIR and STTR shop building production AI, ML, data and cloud systems, led by a former professor in technology who ranks in the top 200 of more than 200,000 on Kaggle and holds seven cloud certifications, with twenty years of production federal delivery across five consulting firms. Behind that sits a standing bench of named engineers, licensed professional engineers and domain specialists across defense, health, energy, transportation and public-sector data, so a read that turns into a regulated-domain question gets answered by someone who works in that domain.
Common objections
We already commissioned a code review. Is this the same thing?
No. A code review answers whether the code is well written. A technical read answers whether the business claims are supported by the artifacts, which is a different question with a different method. Static analysis will not tell you that the training set carries non-commercial terms, that the eval set overlaps with training, or that the operating model prices inference at half its measured cost.
The company will not let us run its model on our data.
That is negotiable more often than buyers assume, and the shape of the refusal is itself information. A reasonable middle path is a supervised session where the company runs its own evaluation suite against a sealed set the reviewer brings, with the reviewer watching. If even that is refused, record it as an unresolved finding with a severity attached and let the committee price it.
Will this slow the deal down?
A focused read runs in a week alongside financial and legal work, so it rarely sits on the critical path. What does slow deals is discovering a data-license problem or a missing invention assignment after exclusivity, when the only remaining options are a repapering exercise or a walk.
Frequently asked questions
At minimum: the model card or its equivalent, the evaluation suite and results with test-set descriptions, a dataset inventory with licenses, twelve months of line-item cloud billing, the standard customer agreement, employment and contractor IP assignments, and read-only repository access. Those seven items support most of the findings.
By constructing a held-out set the company has not seen, running the vendor's evaluation suite against it, and reporting results with a confidence interval and a paired test where two systems are compared. A benchmark supplied by the seller measures the seller's preparation, not the system.
Data-license defects that require retraining, missing invention assignments from a core contributor, inference cost understated enough to change gross margin by more than a few points, and a single-person dependency in a revenue-producing module. Those four carry quantifiable remediation costs, which is what makes them negotiable.
It usually makes it more attractive, because federal contracts are durable and the follow-on pathways are real. The diligence caution is narrower: confirm data rights markings, patent reporting under Bayh-Dole, and whether the proposed ownership structure preserves SBIR and small-business eligibility.
Five business days for a focused read on a single product, longer where multiple product lines, regulated data classes or federal contract vehicles are in scope. Scope is set on the first call so the timeline is known before work starts.
Bottom line
Technical diligence on an AI company is not an opinion exercise. Each of the six load-bearing questions has an artifact that settles it, and the artifacts either exist or they do not. Ask for them by name, run one clean evaluation on an instrument the seller did not build, read the license column and the billing detail, and count the commits. What remains after that is a defensible view of what is being bought and at what price.
The ask. If you are evaluating an AI company, send read-only data room access, or just the four artifacts that carry the most weight, to [email protected]: the model card or equivalent, the evaluation suite with test-set descriptions, the dataset license inventory, and twelve months of line-item cloud billing. You will get a scope confirmation and a fixed fee within one business day, and a written assessment with a severity-rated findings list and the questions to put to management within five business days. If the read is out of scope for us, you will hear that in the same day rather than a week later.