Every serious buyer of code-as-training-data runs some version of the same rubric. Ours grades on five axes: production history, completeness, runnability, rights cleanliness, and domain specificity — and the rest of the market has converged on roughly the same shape. Here is what each axis really means, and what you can do about it before you ask for a quote.
1. Production history
The question behind the axis: did this code ever matter? Years of commits, bug fixes referencing real incidents, version tags, dependency upgrades over time — these are things you cannot fake retroactively, which is exactly why they carry the most weight. A five-year-old repo with 3,000 commits from a shipped product will beat a 100,000-line greenfield dump every time.
What you can do:nothing retroactively, and that's the point. But don't squash-rebase your history away before selling — the history is a large part of what's being bought.
2. Completeness
Source alone is a fraction of the value. Tests define correctness. CI config defines the build. Migrations tell the data story. READMEs and inline docs carry intent. Buyers building training tasks need all of it — a bug fix is only a training example if the test that catches the bug exists.
What you can do: make sure the repo is self-contained. If your CI lives in a separate config repo or your docs live in a wiki, fold what you can into the tree before appraisal.
3. Runnability
Can a stranger clone it, install dependencies, and get a passing test suite? Repos that can be stood up become agent environments — software an AI can be trained inside, attempting tasks and getting scored — and environment-grade repos are the most valuable tier of this entire market.
What you can do: this is the highest-leverage prep. A working build-and-test path documented in the README, pinned dependency versions, and any required services stubbed or containerized can move a repo up a full pricing tier.
4. Rights cleanliness
The fastest way to lose a deal is a rights problem discovered late: an employer with a claim, a co-author who never assigned rights, copied-in GPL source. Buyers check; the good ones check hard. We covered the full checklist in How to sell your code without losing it.
What you can do:know your answer to "who wrote this, under what agreement?" before anyone asks. If contributors are involved, get assignments in writing first.
5. Domain specificity
Training corpora are drowning in web apps and starved of everything else. Logistics optimization, medical-device firmware, exchange connectivity, geospatial pipelines, legacy-language systems — code from thin-data domains commands a scarcity premium. This axis also explains why "boring" internal tools sometimes outprice polished consumer apps: the training value is in what models haven't seen.
What you can do: say what the code does in plain terms when you submit. The appraiser can read the code, but domain context — what industry, what scale, what problem — sharpens the quote.
The one thing not on the rubric: size
Line count correlates with price only weakly, and buyers treat it with suspicion because it's the one metric a seller can inflate. A tight, tested, shipped 20K-line service routinely outprices a sprawling 500K-line monorepo of generated boilerplate. Quality of signal, not quantity of text.
Want the rubric run against your repo? Get an instant estimate — a senior engineer reviews it and you get a firm quote in about two business days.