How to prove your data is good without handing it over

You prove it in layers, and the records come last: a description and counts first, then measurements you make on your own systems, then a small de-identified sample under a signed confidentiality agreement, and the full data only once a licence says how it will be tested. Buyers are set up for this order. Nyne says a first inquiry can begin with a description of your systems, with no dataset upload. Polyshares' intake asks for record counts, not files or exports. eeko gives a first number with no upload and no access to your systems. Turing has a holder run its quality script on its own machine and upload only the CSV it produces, and on DataVendor buyers see metadata, redacted file trees and quality evidence, never the raw files, before they buy. The sample comes after, and the careful buyers put an agreement in front of it: Appen discusses nothing further until a mutual NDA is in place, and The General Data Company reviews a sample only after a confidentiality and data-processing agreement.

The order matters because proof costs something at every step. What a buyer has seen, it has: a company's records and code keep their protection as trade secrets under US federal law only while the company takes reasonable measures to keep them secret, and a sample sent without an agreement is the opposite of one. And what a holder claims, it promises: micro1 has the holder write the data manifest itself and can ask for everything it paid back if that manifest proves materially inaccurate, even after it accepted the data. So good proof is two things at once: as little of the data as will convince a buyer, and numbers exact enough to survive delivery.

This guide is for the founder, CEO or counsel of a company that holds records, code or other data a buyer has asked about, and that wants to show what it has without giving it away. It sets out what buyers mean by "good", five levels of proof from no records to all of them, which buyers accept each level on their own pages, what each level binds the holder to, how to keep the secret and the personal data safe while proving it, a worked example, and how proof works in a sale AIData.Broker runs. Every buyer term below links the record that holds the buyer's own words, read on its own page on 19 October 2026. What to export and in what order is covered in how to prepare company data for sale, and what a buyer's counsel checks in what AI buyers check before buying data.

This guide is research from public sources, not legal, tax or investment advice.

Contents

1. Why proof is the hard part of selling data
2. What buyers mean by "good"
3. Five levels of proof, from no records to all of them
4. Level 1: a description and counts
5. Level 2: measurements made on your own systems
6. Level 3: a de-identified sample, under a signed agreement
7. Level 4: controlled access for a deep review
8. Level 5: delivery, and the test that settles it
9. What every proof binds you to
10. Keeping the secret while you prove it
11. Worked example: a software company proves its records
12. How proof works in a sale we run
13. Questions people ask
14. What this means for you

1. Why proof is the hard part of selling data

Most things are sold by showing them. Data is the exception, because showing it is most of giving it. A buyer that has read a company's support tickets has learned much of what those tickets would teach its model, and a buyer that has cloned a repository has the repository. So the buyer cannot price data it has not seen, and the holder cannot let it see the data without losing part of what it is selling. Every buyer process in this market is a way around that problem, and each one draws the line between proof and delivery in a different place.

The line matters because the market prices almost nothing well without evidence. Buyers' public estimators, which run on a company's description alone, disagree so far that the same company gets estimates about twenty times apart. The ranges buyers advertise are ceilings, not averages: headline ceilings are not what deals pay. A holder that can show what its data is moves from the bottom of a wide range toward a figure. A holder that cannot is priced like the average of everything a buyer has already seen, which for data worth more than average is a loss. How buyers turn evidence into a number is the subject of how AI data buyers calculate an offer.

Two things buyers say on their own pages set the rule for the rest of this guide. First, volume is not quality: Nyne says more records do not automatically mean a higher offer, and SimpleClosure that a larger codebase does not automatically mean a more valuable one. The proof that counts is not "we have a lot" but evidence of the properties buyers pay for. Second, being private is part of the value: DataVendor will not list or estimate a public repository at all, since a buyer can already clone it. Data that leaks while it is being proved loses some of what made it worth buying, which is why the rest of this guide treats every disclosure as a cost to be paid only when it buys something.

2. What buyers mean by "good"

Before choosing how to prove quality, a holder needs to know what buyers count as quality, because almost all of it can be stated as a number. Buyers' pages are specific about what they reward and what they refuse, and the same handful of properties comes back from buyer to buyer. The words differ; the properties do not.

The table collects them, each with the buyer's own words and, in the last column, the evidence that shows it without sending a single record. That last column is the one to read.

Read down the last column and the method of this guide appears: almost every property a buyer pays for is a count or a share, and a count or a share can be computed where the data sits and sent on its own. The richness Sunset's chief executive described to Forbes, a Jira ticket tied to the commit that closed it, is a link a script can count. The value of connected systems, which Ooak's estimator showed as $85k to $121k with six tools against $16k to $22k with three, is a fact of the inventory. The volume that survives cleaning, which for code SimpleClosure found was roughly 37% smaller than the raw count, is a measurement.

What cannot be stated as a number is mostly texture: whether tickets are written well enough to learn from, whether threads read in order, whether the code is the kind a model improves on. Buyers judge texture by reading, and that is what a sample is for. It is also why the sample belongs late in the process: by the time a buyer reads it, the numbers should already have told it what to expect, and the sample's job is only to confirm them.

3. Five levels of proof, from no records to all of them

The buyers' processes, read side by side, fall into five levels of evidence. Each shows the buyer more, and each costs the holder more: in exposure, in time, and in what the holder is held to afterwards. The levels are not a fixed sequence every buyer follows. Some price at the first level, some will not name a figure before the third, and a few go straight to access. What the holder controls is how far it lets each buyer go, and on what terms.

The table sets out each level with the buyers whose own pages describe working at it. A buyer missing from a row is not one that refuses that level; its pages did not describe it in words we could cite.

Two patterns stand out. The first two levels give away nothing from the records, and between them they can carry most of what section 2 says buyers pay for. A holder that does them well gives a buyer enough to name a range, and a buyer that has named a range on that evidence has a reason to sign an agreement before it asks for more. The levels also differ in who does the work. At levels 1 and 2 the holder produces the evidence and chooses what it says; at levels 4 and 5 the buyer reads the data with its own tools and draws its own conclusions. The further the holder can carry a buyer on evidence it produced itself, the more of the process it controls.

The rest of this guide takes the levels in order. One rule runs through all of them: give every buyer the same evidence at the same time. A holder that sends its counts and measurements to several buyers at once gets ranges it can compare, and a holder that walks one buyer up to a sample before the others have seen anything is negotiating with a party that already knows more than its competitors.

4. Level 1: a description and counts

The first level is an inventory: the systems the company used, the years each covers, how much each holds in its own unit, how many people used it, and who can sign for it. Buyers ask for this in nearly the same words. Polyshares asks, for each system, how much data sits in it, how long you have used it and how many seats it has, and says an estimate from the admin console is enough. Grepped asks for total storage across all systems, the years it covers, where it lives and how fast you could provide an export or access. Turing accepts a rough count per system, from someone with admin authority. HUMXN asks what data you have, roughly how much history, and who owns it, with no upload.

None of this touches a record, and buyers answer it quickly. Labelbox's Prism produces a written quote within 48 hours from a map of the systems, Collinear usually quotes an initial range within a day, and eeko has a person reply inside one business day with a number. Halluminate tells companies making first contact: "No files are needed. Do not include confidential or sensitive information." ( Halluminate).

What a level 1 answer is worth

A figure from a description is a range, and the buyers that give one say so. Ooak's partner page is the plainest: its estimator gives a range, and "we never quote a number before counting". Mode reviews the systems and dates in scope, years of history, record volume and quality, and ownership before it makes a fixed offer. So level 1 does not end the proof; it decides which buyers are worth taking further, and it fixes the frame every later figure is checked against.

That last point is why level 1 deserves more care than it usually gets. Every count in the inventory becomes something the buyer will check later, at the sample, at access or at delivery. A count that shrinks at each later step costs credibility at each step, and a count that holds builds it.

How to make the description credible

Five habits separate an inventory a buyer trusts from one it discounts:

1. Count in each system's own unit, from the system's own admin console: messages, tickets, repositories, gigabytes. A unit the buyer can check against the system is worth more than a total it cannot.
2. Count net. Leave out what you will exclude (customers, channels, periods) and what will not survive cleaning. pre.dev's agreement lets it decide which files count, so a holder that has counted net first is never surprised by the buyer's number.
3. State the gaps before the buyer finds them. Grepped asks for known quality issues, gaps, duplication or bias in its intake. A gap the holder names is a fact about the data; a gap the buyer finds is a question about the holder.
4. Say where the sensitive data sits. Grepped asks holders to say where health, HR or children's records sit and to name the source of any bought or scraped content. Handshake has holders define which records are included and what sensitive information is excluded before they commit.
5. Write it once, as a datasheet. One document that every buyer receives keeps the evidence identical across buyers.

The datasheet is worth writing in the vocabulary buyers will need later. The EU AI Act asks providers of high-risk systems to document their training data "in terms of datasheets", covering the data's provenance, scope and main characteristics, how it was obtained and selected, and how it was cleaned. A holder's datasheet that already answers those headings answers questions the buyer will one day have to answer about its own model, and the datasheet builder walks through them. Ooak goes one step further and writes the holder's exclusions into the contract: anything you exclude is annexed to the contract before a single record moves.

5. Level 2: measurements made on your own systems

The second level is the one most holders skip, and it is where proof without disclosure does most of its work. The principle is simple: compute where the data sits, and send only the numbers. A script that reads a company's exports on the company's own computer can count everything section 2 lists (duplicates, links, outcomes, languages, bots, months with activity) and produce a page of figures that contains no record at all.

Buyers already use this for code. Turing has a holder download its QA script, run it locally against the repository, and upload the CSV output it produces; its same-day screen also asks for a screenshot of the running application alongside its other requirements, which proves the code runs without showing how. DataVendor's buyers decide from metadata, redacted file trees, quality evidence and taskset previews, never the raw files. Ooak counts volume, coverage and how deeply your tools connect with the holder before it gives a figure.

What to measure

The measurements worth producing are the ones that answer section 2, system by system:

The last row is easy to overlook. A count of the names, emails and account numbers a scan found, by type, tells a buyer how much de-identification the data needs and whether it is feasible, without showing any of them. Our sample terms define the measurements a valuation of ours produces in the same terms: records and words, the shares of duplicates, of linked records and of records that state a reason, the share in English, and the identifiers found by type.

Measurements a buyer can rerun

A measurement is only as good as its method, and a buyer has no reason to trust a number it cannot check. The fix is to make the method public to the buyer: name the script or tool, say what it counted and what it left out, and offer the buyer the right to rerun the same measurement on the delivered data. Turing's model works this way for code, with the buyer's own script run on the holder's machine. The effect is that the holder's figures and the buyer's acceptance test become the same calculation, which is the strongest proof there is and the one that protects the holder most at delivery (section 8).

Clean rooms

For structured data there is a further step: letting the buyer run its own questions on the data without seeing rows. In a data clean room such as AWS Clean Rooms, the company that contributes a table sets an analysis rule that decides how the table can be analysed, for example allowing only counts, sums and averages over groups above a minimum size, or only queries the company has reviewed. It suits tables (orders, tickets with fields, usage logs) far better than free text, and it takes engineering on both sides. None of the buyer pages in our records describes evaluating company records this way, but a holder with a large structured dataset can ask a buyer whether it will run its checks through one.

6. Level 3: a de-identified sample, under a signed agreement

The sample proves what numbers cannot: that the records read the way the measurements say. Most buyers ask for one before they commit to a figure. SuperAnnotate reviews a sample for volume, quality and uniqueness, then comes back with a valuation. Turing reviews a slice of the record to gauge scope, quality and rarity, usually within a week. Polyshares has someone read the anonymized sample before it prices the record, although the same company's intake says nothing leaves your systems until it has made an offer and you have accepted it. Troveo's guide says plainly that a buyer will usually want to evaluate a sample before committing.

No buyer we read gives a size. The words they use are "small", "representative" and "slice": Grepped asks whether you can provide a small representative sample, and DataVendor says a small representative sample also helps. In other corners of the market a sample is a product with a price: Claru sells video sample packs of 10 to 15 clips for $500 to $2,000, and AWS Data Exchange describes a sample as a small part of a product, intended to show what the entire data set is like, that subscribers can view before they subscribe. For company records, buyers expect the sample free, which makes its size the holder's decision. The right size is the smallest that lets a reader confirm the measurements, drawn from every system the measurements describe.

Five rules for the sample

1. After the rights review, never before. The legal guidance in our rights questions puts it directly: "Do not share sample data before this review, since a sample itself could be a disclosure". A sample drawn before the holder knows which customers, channels and people must stay out is a sample of things it may not have the right to share.
2. An agreement first. Appen discusses nothing further before a mutual NDA is in place, and The General Data Company reviews a sample after a confidentiality and data-processing agreement. Ask every buyer for the same order. The agreement should limit use of the sample to evaluating the purchase, bar passing it on and any attempt to identify people in it, and require deletion if no licence follows.
3. De-identified by the same method as the delivery. A sample cleaned by hand and a delivery cleaned by a pipeline are two different datasets. If the sample is to prove the delivery, it has to come from the same process.
4. Representative, matching the measurements. The sample should reproduce the level 2 figures: if the measurements say most tickets carry a resolution, so should the sample. A sample chosen to flatter is contradicted at delivery, and the holder then owns both the gap and the impression it made.
5. The same sample to every buyer. Sent at once, under the same terms, it gives comparable prices. Sent to one buyer first, it gives that buyer an advantage the others do not have.

The sample in the other direction

Proof runs both ways. Several buyers let the holder review what they made of its data before it goes further, and that review is the holder's proof that the buyer's de-identification works. micro1 says holders can review representative samples before use. SuperAnnotate prepares the data and you review a sample before it passes the data on. Ooak lets you review a sample before delivery, Appen has you approve a representative sample pack before anything is licensed, Centific shows you an anonymized sample before the data is used, and HUMXN has you approve the final dataset. Grepped sends a release summary and a period to object. Ask every buyer for this review in writing, whatever its page says.

The largest public records sale shows how much a checkable sample can weigh. In the Spirit Airlines bankruptcy, micro1's later proposal was higher than Google's winning bid, but it had micro1 de-identifying the records itself, together with an offer to give an independent reviewer a sample; the court's privacy ombudsman asked for further review because micro1 would not use an independent party, and the higher proposal had not displaced Google's months later. A de-identification an independent party has checked is proof both sides can rely on, and in that sale the structure of the check has so far counted for more than the price. The case is covered in selling customer data in bankruptcy.

7. Level 4: controlled access for a deep review

Some buyers will not move past a range without reading the source in place, and for code this is the norm. After its script, Turing asks for temporary access to the repository so its engineers can review it against their full checklist. pre.dev values code through a Git connection, where you pick only the repos you're willing to license and each gets a value and a grade in minutes. For company records, access usually means read-only connectors: Appen reads only the systems, teams, workflows and periods you name, with credentials scoped to the engagement; Centific connects read-only to the applications you choose, with the exclusions you set; Mode has your team sign in to the approved systems so that no passwords are handed over; and Magma's access is read-only and encrypted, scoped to what you approve.

Access is not neutral, for three reasons. Extraction makes a copy: a connector that reads a system usually writes what it reads somewhere else, and the copy outlives the review unless the agreement says otherwise. The software vendor may object: Corpus Bridge warns that since May 2025 Slack's API terms prohibit bulk export through the API and use of that data to train language models, and buyers' counsel ask how the data left each system. And pages disagree about what access means: Grepped's business page describes read-only access to the approved sources, while its agreement summary says data travels by the encrypted transfer method it specifies.

So access for a review is granted on terms, never by default. Before any credential is issued, settle in writing what is read, what is copied and where the copy is stored, who can see it, when access ends, and what is deleted if no licence follows. Keep the scope as narrow as the review needs: Scale says a partnership can begin with a very limited scope, and a review of one repository or one team's records proves most of what a review of everything would. Collinear's model is the one to ask for at the end: a one-time export, and any access you grant can be removed once the transfer is done.

8. Level 5: delivery, and the test that settles it

Every earlier level is a promise about the data; delivery is where the promise is tested, and the test is written into the licence. Nyne agrees use, data categories, volume, privacy constraints and acceptance criteria before anything is collected or transferred. micro1 has 30 business days after delivery to reject the data, with silence counting as acceptance, and owes nothing for any part it validly rejects. Appen pays on acceptance rather than submission. Grepped, if a dataset cannot be brought to its de-identification standard, delivers none of it and deletes or returns the data.

The holder's best protection at this level is the work it did at level 2. Write the acceptance criteria from your own measurements, computed the same way on the delivered data, with a stated tolerance: the share of records linked, the share with outcomes, the net count, the languages. Criteria written as numbers both sides compute the same way leave a buyer little room to reject on impression, and they turn the holder's proof into the buyer's test. eeko's delivery comes with a signed receipt of every record delivered, which settles what was handed over.

Delivery can itself be staged as proof. Scale releases data package by package, each with your sign-off, and a first package that passes acceptance is the most convincing evidence a holder can give for the rest. A holder unsure how its data will be judged can ask any buyer for the same structure: a first package, tested and paid, before the full delivery. How acceptance moves the payment date is set out in when AI data buyers actually pay.

9. What every proof binds you to

Every figure a holder uses to prove its data becomes a statement the buyer can rely on, and in the stricter licences a statement the buyer can recover money on. micro1's terms are the clearest example. The holder writes the data manifest, a written description of the data by sources, types, volumes and specifications. If micro1 finds it materially inaccurate, nothing is payable and the holder refunds what was paid, a right that survives acceptance; a claim for a latent defect or a mismatch with the manifest must come within 60 days of acceptance. The holder also warrants, unless the order form says otherwise, that the data holds no protected health information, biometrics, payment card or bank account data, or data about children.

Other buyers put the same weight on the holder's word in other ways. pre.dev's agreement has the holder warrant that the code holds no personal data, customer data, credentials, API keys or passwords, except as disclosed, and pre.dev may suspend or remove a codebase that turns out to hold undisclosed personal data or credentials. Troveo prepares for buyers a manifest documenting exactly what's included, which is what the buyer will check delivery against.

Four rules follow, and they apply at every level:

• Never send a number you cannot reproduce on the delivered data. If a figure depends on a judgment, say so beside it.
• Label each figure as measured or estimated. A count from an admin console and a count from a script are different kinds of evidence, and a buyer that knows which is which discounts neither unfairly.
• Count net, and say what was taken out. The buyer will take it out anyway.
• Disclose what you know is there. A warranty breached by something the holder knew about is the hardest kind to defend.

The full list of what a buyer's counsel checks, and the clause each answer feeds, is in what AI buyers check before buying data, and the licence as a whole in what a data licensing agreement covers.

10. Keeping the secret while you prove it

Proving quality without losing value is partly a legal question, and the law gives the holder a reason to be strict about it. Under US federal law, information is a trade secret only if its holder has taken reasonable measures to keep it secret and it draws value from not being generally known. The EU's Trade Secrets Directive sets the same test, with reasonable steps to keep the information secret among its conditions. A holder that sends records to a prospective buyer without a confidentiality agreement weakens exactly the protection it would rely on if that buyer used them. With an agreement in place, use beyond it is unlawful in the EU under Article 4(3) of the Directive and in the UK under the 2018 Regulations, which is what gives the holder a claim.

Some material should not be proved with at all, because it is not the holder's to show. The records of most companies hold other companies' confidential information, and buyers' counsel ask whether partner documents, pricing or material shared under an NDA are in the data. The General Data Company keeps current designs, prices and anything a competitor could use with the holder, and takes customer or supplier records only where no confidentiality agreement stands in the way. Troveo takes customer and employee personal information, third-party confidential material, credentials and anything under a contractual restriction out before delivery. What comes out of the delivery must come out of the sample first.

Personal data in a sample needs its own care, because de-identification does not always end the holder's duties. In EU law, whether data identifies someone is judged from the side of the party that holds it, and the Court of Justice held that for a controller's own obligations it is assessed from the point of view of the controller. A holder keeps the original records, so a sample it de-identified may still be personal data in its hands, and sending it abroad can then engage the GDPR's transfer rules. US state laws and employee records raise their own questions, covered in licensing data under the GDPR, employee emails and chats as training data and our de-identification standard.

11. Worked example: a software company proves its records

An example, not a real company. A software company of about 60 people, still operating, has eight years of Slack, Jira, GitHub, Google Drive and HubSpot. Two buyers have asked about its records, and it wants offers without sending anything it cannot take back.

Level 1. An afternoon in each admin console produces the inventory: messages, tickets, repositories and documents, each system's first and last year, seats, and the person with authority to sign. It lists what stays out (the channels shared with customers, the HR folders, two customers whose contracts forbid it) and writes the gaps it knows of (a year of Slack lost when the workspace changed plan). It goes to every buyer that fits at the same time, as one datasheet.

Level 2. A measurement tool run on the company's own computer reads the exports and returns a page of figures and nothing else: net counts after exact repeats, months with activity per system, the share of Jira tickets linked to a GitHub commit, the share resolved with a reason, the share of pull requests opened by bots, the share in English, and the identifiers found by type. The figures go to the same buyers, with a note on how each was computed. Two buyers return ranges; a third declines because the company's records are mostly not in the language it buys.

Level 3. The two buyers that named ranges sign the company's confidentiality agreement, which limits use to evaluation, bars onward disclosure and re-identification, and requires deletion if no licence follows. Each then receives the same sample: a small slice from every system, drawn after the rights review, de-identified by the same process the delivery will use, and checked against the level 2 figures before it goes. One buyer wants to read the code itself.

Level 4. The company grants that buyer read-only access to two repositories for a fixed number of days, with a written list of what may be copied and a deletion commitment. It does not open the whole organisation.

Level 5. The licence the company signs writes acceptance as numbers: the net counts and the linked and resolved shares from level 2, recomputed on the delivered data, within a stated tolerance. The first package is one year of records; the rest follows once that package is accepted and paid. At no point did a buyer hold more of the company's data than it needed for the decision in front of it.

12. How proof works in a sale we run

AIData.Broker acts as the holder's agent in the sale: the holder itself licenses or sells its data to the buyer, and we do not take ownership of it. The way a sale we run proves a holder's data follows the levels above, with the holder's records staying with the holder for as long as possible.

Counts and measurements are made on the holder's computer. For company records, our valuation measures the holder's exports on its own computer and sends us only its answers and the counts: figures, shares and month-level dates, with no names of people, file names, subjects or message text. Where the holder chooses to add a sample, our tool draws it and rewrites it on the holder's computer, replacing what identifies a person, before anything is sent. The sample is then checked again for anything that could still identify someone and measured, and its text is discarded when the request that carried it ends: no person reads it, and it is not shown or sent to a buyer. We do not attempt to identify anyone from counts, samples or measurements.

Buyers see the datasheet, and only after an undertaking. The mandate defines the Datasheet as the document describing the data (its source, contents, measured size, rights, personal data, format and delivery, the licence offered and its known limits) that the holder approves in writing before it goes to any buyer, and we pass it on labelled as the holder's statement, saying its figures come from the holder's own valuation and any sample it sent. Before a buyer has given a written undertaking, we describe the data only in terms that do not identify the holder. A buyer receives the datasheet only after it has undertaken in writing to use it only to evaluate the purchase, pass it on to no one but its own advisers, attempt to identify no one in it, and return or delete it, and every buyer that fits receives it at the same time, by the same deadline.

What a buyer asks for beyond that, the holder decides. A sample, a review with access or a staged first delivery is agreed between the holder and the buyer, under their own confidentiality agreement, and we help the holder set the terms this guide describes, starting with acceptance criteria written from its own measurements. The holder, or a provider it chooses, delivers the data to the buyer, and the buyer pays the holder. Our fee is a success fee, due only out of a sale: 12% of the first $250,000, 10% up to $1 million, 8% up to $3 million and 6% above $3 million. We run sales only for holders based in the United States, the United Kingdom and Canada; the full terms are on the pricing page and in how it works.

Questions people ask

Do I have to send a sample before I get an offer?

Not before a first range. Nyne, HUMXN, eeko, Corpus Bridge and Collinear all start from a description, and Labelbox's Prism writes a quote within 48 hours from a map of the systems. Most buyers do read a sample before a firm price, as Troveo says a buyer will usually want to, so send one only after a range, under a signed agreement, and the same one to every buyer.

Can a buyer use my sample without buying the data?

Without an agreement, very little stops it, and a sample shared freely also weakens the records' protection as trade secrets. With a confidentiality agreement limiting use to evaluation, use beyond it is a breach, and in the EU an unlawful use of a trade secret. Keep the sample small, de-identified and the same for every buyer, and ask for deletion if no licence follows.

Is a de-identified sample still personal data?

It can be, in the holder's hands. EU law judges identifiability from the point of view of the controller, and the holder still has the original records, so its own duties may continue, including the rules on transfers abroad. The GDPR guide covers what follows.

How big should a sample be?

No buyer we read publishes a size: the words are "small", "representative" and "a slice" ( Grepped, Turing). Make it the smallest sample that lets a reader confirm your measurements, drawn from every system they describe, and no larger. A sample that reproduces your level 2 figures proves more than a large one that does not.

Can a buyer check my data without me sending it?

Partly. Turing's code screen runs on your own machine and returns only a CSV, DataVendor's buyers decide from metadata, redacted file trees and quality evidence, and a clean room lets a buyer run approved queries on a table without seeing rows. For a deep review, most buyers then want read-only access, which should be time-limited and scoped.

What happens if my numbers turn out wrong?

It depends on the licence, and the strict ones are expensive. micro1 can ask for a refund of everything paid if the manifest was materially inaccurate, even after acceptance, and owes nothing for data it validly rejects. Count net, label what is estimated, and write acceptance criteria from figures both sides compute the same way.

Is a datasheet enough on its own?

It is enough to start, and it is the document every later step is checked against. On its own it is the holder's statement, so buyers price it as a range; measurements made on the data and a sample under agreement are what turn it into a figure. The datasheet builder covers the headings buyers' legal and research teams ask about.

What this means for you

Proving data is a sequence of small disclosures, each of which should buy something: a range, then a firmer figure, then a signed licence. In order:

1. Write the inventory and the datasheet first, from the admin consoles, counted net, with the gaps and the exclusions stated. The datasheet builder and the rights check cover the questions.
2. Measure on your own systems and send the figures, not the records: volume net of repeats, history, links, outcomes, bots, languages and identifiers found. Our valuation does this on your own computer for company records.
3. Send the same evidence to every buyer that fits, at the same time, and take the ranges as the basis for who goes further. The buyer match lists the buyers whose published rules fit.
4. Sign a confidentiality agreement before any sample, then send one small, de-identified, representative sample to each buyer still in. The de-identification tool removes people from records without them leaving your computer.
5. Grant access only on written terms: what is read, what is copied, when access ends, what is deleted.
6. Write acceptance as numbers from your own measurements, and stage the first delivery if you can. When an offer arrives, the offer check holds it against the market and the buyer's own terms.

The whole selling process, of which this is one part, is in how to sell company data to AI labs, and every buyer's published terms side by side in buyer programs compared.