Getting started
How to read an AI buyer's data request
By SourceX Editorial · Updated
Short answer
An AI buyer's data request is a specification: it says what the model developer will use records for, which record types and fields it needs, how much history, in what format, what must be excluded and whether it wants exclusivity. Read the use and exclusivity fields first, because they decide whether the rest is worth answering.
Key takeaways
- The intended-use field tells you what the buyer may do with your records and shapes every other term.
- Exclusivity raises price but limits who else you can license to, so read it before volume or format.
- Volume is usually counted in complete units, such as resolved tickets or closed jobs, not raw table rows.
- Exclusions in a request are a floor; your own carve-outs for customers, privilege and secrets still apply.
- Send clarifying questions before estimating effort, because first requests are often written broadly.
What a buyer's data request usually contains#
A buyer's data request usually contains the same core fields whatever the industry: intended use, record types, volume, history and freshness, format, required metadata, exclusions, privacy standard, exclusivity and delivery. Some arrive as a formal specification; others are a few paragraphs in an email.
For a COO, the request is a translation exercise. Each field has to be mapped to a system the company runs, a team that would do the work and a restriction someone in legal will raise.
- Intended use: training, fine-tuning, evaluation or a mix.
- Record types: tickets, job records, order exceptions, code reviews, project correspondence.
- Volume and history: how many complete records, over what span of years.
- Freshness: whether recent records or ongoing refreshes are required.
- Format and structure: file type, threading, required fields and linkage.
- Exclusions and privacy: what must be removed or never sent.
- Commercial shape: exclusivity, term, field of use and delivery method.
Illustrative: an annotated request sent to a distributor#
Illustrative: the request below is fictional and simplified, phrased the way a developer building an operations assistant for distributors might write it. The right-hand column shows how the COO of a fictional industrial distributor running Epicor for orders and a separate WMS read each line.
The COO found that exception notes lived in the WMS while order and customer fields lived in Epicor, so the request implied a join her team had never built. She answered for the years where both systems overlapped, declined exclusivity across all of distribution, and proposed exclusivity limited to one product vertical. The developer agreed to continue with a scoped fit check on that basis.
| Field | What the request says | How to read it |
|---|---|---|
| Intended use | Training and evaluation of a model that helps resolve order exceptions | Two uses; evaluation sets are often held to stricter quality standards |
| Record types | Order exceptions with resolution notes, linked to the order and shipment | Needs ERP and WMS records joined, not exception notes alone |
| Volume | Stated as a minimum number of resolved exceptions | Count only closed exceptions that carry a written resolution |
| History and freshness | Several recent years, with a preference for ongoing refreshes | A refresh commitment means recurring work and a longer relationship |
| Format | One record per exception in JSON lines, with linked records nested | Your team builds the joins; flat CSV exports may not be enough |
| Required metadata | Timestamps, exception category, resolution code, role of each actor | Roles, not names; check whether categories were used consistently |
| Exclusions | No personal data, no customer names, no pricing | A minimum; add your own carve-outs for restricted customers |
| Exclusivity | Exclusive within the distribution vertical for the license term | Blocks other licenses in that vertical, so it should be priced accordingly |
| Delivery | Secure transfer or encrypted drive | Data stays in your storage until an approved release |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Read intended use and exclusivity before anything else#
Intended use and exclusivity are the two fields that decide whether a request deserves a detailed answer, because they set what the buyer may do with your records and what you give up in return. Read them before volume or format.
Use language varies. Training means records shape a model's weights; evaluation means records test a model, often without training it; fine-tuning narrows an existing model for a task. A request that says only AI development is too broad to approve and should be narrowed in the license.
Exclusivity can be total, limited to a vertical or field of use, or limited in time. Under the SourceX Enterprise Data Value Framework, exclusivity increases price, but it also removes options. Ask what scope the buyer actually needs before treating exclusivity as a given.
How to interpret volume, history and freshness#
Volume, history and freshness describe how much complete work the buyer needs and how current it must be. Buyers usually count complete units, such as a resolved ticket thread, a closed job with its invoice, or a merged pull request with its review, rather than rows in a table.
Before answering, count your own units the same way. A helpdesk may hold many tickets, but only some carry a written resolution; an ERP may hold years of orders, but exception notes may start only after a process change. Report what is complete and say where the gaps are.
Freshness requests ask for recent years or a recurring feed. A refresh obligation turns a one-time export into a process someone inside the company has to own.
Format, linkage and metadata requirements#
Format and linkage requirements tell you how much engineering a request implies. A request for threaded records with nested context, such as a ticket with its linked bug and release, means joining data across systems before export.
Required metadata deserves a line-by-line check. Category and status fields help only if staff used them consistently, and actor fields usually need to be converted from names to roles during preparation. If a field the buyer wants was never captured, say so rather than reconstructing it.
Ask for a sample schema or a small synthetic example if the request does not include one. It removes most of the ambiguity about structure before anyone writes an export script.
Exclusions, privacy and what the request leaves out#
Exclusions in a buyer's request set a minimum standard, not the full list of what your company will remove. Buyers commonly ask for personal data and customer names to be stripped; your own review adds restricted customers, privileged communications, credentials and secrets, and anything covered by an NDA.
Notice what the request does not say. Silence on retention, deletion, sublicensing or use by affiliates is not agreement; those terms are settled in the license. A request is an opening statement of needs, and the license is where your conditions are written.
Questions to send back before you estimate effort#
Clarifying questions sent before any effort estimate save the most time, because first requests are often drafted for a category of supplier rather than for your company. Keep them short and specific.
- What exactly counts as one record for your volume figure?
- Is this for training, evaluation or both, and for which model or product?
- Which fields are required and which are nice to have?
- Is exclusivity required, and if so, in which field and for how long?
- Do you need ongoing refreshes or a single delivery?
- What de-identification standard do you expect, and will you accept a documented sample review?
- How will delivered records be stored, retained and deleted?
How SourceX handles buyer requests#
SourceX reads buyer requests against supplier fit using the SourceX five-step transaction. In Supply, a request is matched to companies whose record types and history fit, using metadata only; in Rights, exclusions and permitted use are settled; Preparation removes personal and confidential details; Approval leaves every scope decision with the supplier; Delivery follows only after release authorization.
Each approved package is documented in a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization, so the final scope can be compared against what the request originally asked for.
Frequently asked questions
Do buyers expect a full answer to every field?
No. A first response usually confirms which record types you hold, the span of history and the obvious restrictions, and flags fields you cannot meet. Partial fits are common, and a buyer would rather learn early that a field was never captured than discover it at delivery.
Should we send a sample with our first response?
Usually not. A first response can be built from metadata: system names, years, counts of complete records and known restrictions. Samples come later, after rights review and preparation, and only with your approval, so nothing sensitive leaves before you have decided to proceed.
What if the request asks for data we would never license?
Say so plainly and offer what you can. Declining one field, such as pricing history or a particular customer segment, rarely ends the conversation if the core records fit. Being clear early also prevents preparation work on records that would be pulled later.
Who inside the company should review a request?
The COO or operations lead maps record types and effort, IT or the CTO confirms exports and formats, counsel reads use, exclusivity and privacy terms, and the CFO looks at the commercial shape. The CEO decides whether to proceed.
How is a request different from the license itself?
A request describes what the buyer wants. The license is the binding agreement that sets permitted use, scope, exclusivity, term, deletion, payment and your exclusions. Nothing in a request commits you, and the signed license can differ substantially from the original ask.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.