What is measured, what is judged, and what it cannot tell you

Levels of evidence

Every finding in the memo is labelled with where it came from, because the three sources carry different weight.

1. AI dependence

The question is how much of the product's AI is the company's own work and how much is calls to another company's model.

What the scanner measures

• Model provider SDKs and API clients in use (OpenAI, Anthropic, Google, AWS Bedrock, Azure, LangChain and others)
• Prompt templates and hard-coded model calls
• Signs of the company's own model work: training and fine-tuning code, evaluation suites, feature and data pipelines, custom inference serving
• Caching in front of model calls

From these it reports a wrapper ratio: the share of AI-related code that is API calls and prompt handling rather than the company's own model and data work.

How to read it

A high ratio suggests little proprietary model work. It does not prove the product has no moat, since the value may sit in data, distribution or workflow rather than in models. The memo says which, and the session tests it.

2. Cost to run

AI products can look profitable at pilot scale and lose money per customer at volume. The scan looks for the patterns that make cost grow faster than usage.

• Model calls with no token limit, and retry loops with no ceiling or backoff
• Network clients with no timeout
• Model calls with no caching layer in front of them
• Reserved GPU instances in infrastructure code with no idle shutdown

How estimates are made

Estimates are arithmetic on the target's own configuration at published list prices, with the inputs shown. For example, two H100 GPUs rented around the clock at RunPod's list price of $3.49 per GPU-hour (September 2026) cost about $61,000 a year. Whether that is waste depends on how busy they are, which the scan cannot see.

The buyout tier reads cloud and model-API invoices from the data room, which replaces estimates with actual spend. The memo always says which basis a number uses.

3. Maintainability and key-person risk

A small team shipping quickly with AI assistants can leave code nobody on the team fully understands. What matters to a buyer is whether the people who stay can explain and change it.

What the scanner measures

• Each author's share of the changes, and how concentrated authorship is overall
• Hotspots: files that change often and are also complex
• Functions that call AI models and have no test that exercises them
• Very large commits with little review history, flagged for follow-up

Author concentration is also reported as normalised entropy, a supporting number where 0 means one author and 1 means work spread evenly:

Normalised entropy depends on team size. With one author at 80% of changes it is about 0.72 in a two-person team and 0.41 in a ten-person team, so the memo reports the top author's share directly and uses entropy only for comparison.

What it does not do

It does not claim to identify code written by AI assistants. Commit size alone proves nothing, since vendored code, generated files, migrations and squash merges also make large commits. Co-author trailers from AI tools are counted where present, but they are optional and often switched off, so their absence means nothing.

4. Licences

Open-source dependencies

Copyleft obligations depend on how the product reaches customers, so the memo records both the licence and the delivery model.

• GPL obligations attach when software is distributed: installed software, mobile apps, SDKs, on-premises deployments. Running GPL code only on your own servers usually triggers nothing.
• AGPL adds an obligation when a modified version is offered to users over a network: those users must be offered its source code. Whether that reaches the surrounding code is a question for counsel. The acquisition itself does not trigger disclosure.
• SSPL and similar source-available licences are not open source and carry their own terms.

Model weights

• Weights under CC BY-NC are licensed for non-commercial use only. Using them in a paid product needs another licence or a replacement.
• OpenRAIL-M licences allow commercial use but carry use-based restrictions that pass to downstream users.
• Llama models carry Meta's community licence: attribution and naming requirements, an acceptable use policy, a separate licence for companies above 700 million monthly active users at the version's release date, and limits on EU-based companies using the multimodal Llama 3.2 and Llama 4 models.

EU AI Act, as of September 2026

Obligations for providers of general-purpose AI models have applied since 2 August 2025. Most application companies build on such models rather than provide them, and a company that fine-tunes a model generally becomes a provider only if the modification uses more than a third of the original training compute. Following the 2026 amendments, obligations for high-risk systems apply from 2 December 2027, or 2 August 2028 for AI inside regulated products such as medical devices. The memo flags where a target may fall into these categories; it does not give a legal view.

5. Security and data exposure

• Personal or customer data passed to model providers, and whether data processing agreements are referenced
• User input placed into prompts without separation or filtering
• Credentials and API keys committed in the scanned files
• Reliance on a single model provider with no fallback
• Dependencies with no pinned version, which can change underneath the product without anyone noticing

This is a code-level review, not a penetration test or an infrastructure audit.

6. Data handling

The scanner runs on the target's machine, reads the repository and its git history, and writes one file. It makes no network connections, so it can be run with networking switched off.

What the bundle contains

• Counts, scores and ratios for each area
• Relative file paths for flagged files, and names of dependencies, SDKs and licences
• The commit it scanned, the date range of the history, and commit counts
• Author IDs replaced by salted hashes, so concentration can be measured without names or email addresses
• A fingerprint of the scanned files: a SHA-256 hash over the hash of each file
• The scanner version and the time it was sealed

What it never contains

• Source code, code snippets or file contents
• Full credential values. A credential it finds is recorded by file, type and a masked form showing only its first six and last four characters.
• Author names or email addresses

Encryption, with no password to share

Each deal gets its own key pair. The target receives only the public half, a short string, and the bundle is sealed to it with HPKE (RFC 9180), using X25519 and AES-256-GCM. Only the holder of the deal's private key can open it, and nobody has to pass a password around or type one on a command line. Any change to the bundle, including its header, makes it fail to open.

Read exactly what you send

The scanner can write a readable copy of the exact content it seals. The bundle records that copy's SHA-256, so the target's engineer can confirm with a standard sha256sum that what they read is what they are sending.

Author IDs

Each author's email becomes a keyed hash. The key is random, stays on the target's machine and is never in the bundle, so a list of the company's engineers cannot be matched against the IDs. They are pseudonymous rather than anonymous, since the target can link them, and are handled as personal data.

Verifying the scanner

The scanner reaches the target through the deal's data room as a signed release: a Docker image and a Python package, checksums, a software bill of materials and a one-page run sheet. The checksums are signed with the key published at /keys/release-signing.pub and checked offline with ssh-keygen. The run sheet runs the container with networking off and the repository mounted read-only, and the scanner ships its own tests so the target's team can run them first.

Matching the code after closing

Running codeprovenance fingerprint on the code delivered at closing gives the same hash as the bundle if the files are the ones that were scanned. It cannot show that the scanned repository was the one in production, and any legitimate change after the scan will change it. Use it as one check among several.

7. Technical session

The buyout tier includes a 90-minute video session with the target's technical lead and the engineers who own the flagged code. I choose the modules in advance from the scan's hotspots and untested AI-calling code.

• Engineers walk through the code and explain how it behaves when a model call times out, returns malformed output or costs more than expected.
• I ask them to work without AI assistants for the session. The target can decline, and the memo records it.
• The memo reports what was asked, how the team answered, and what it means for key-person risk.

The session informs the buyer. It does not by itself trigger any contract term; that is for the parties to agree.

8. Limits

• The target chooses what to scan and runs the scanner itself. The memo states which repositories and commit were scanned.
• Scans read code, not running systems. Actual cost, traffic and uptime need billing and monitoring data.
• Static analysis produces false positives. Findings that would change a deal decision are checked by hand before they go in the memo.
• Cost ranges are engineering estimates with the assumptions shown, not quotes.