AI developers buy business data to help a system perform a particular job. A team building an accounting assistant might need examples of invoice disputes and how people resolved them. A software team might need bug reports linked to code changes and test results. The buyer is looking for evidence relevant to that job, in a form its team can use.
For a business owner, the first question is what the company’s files can show. For a buyer, it is what the model needs to learn or demonstrate. A productive licensing discussion connects those two descriptions. This guide explains how to make that connection, assess a sample and decide whether a larger deal is worth pursuing.
Start with a specific task
A useful request names an action, the information available when it happens and the result that counts as success. “Accounting data” is a broad category. “Examples of how staff resolve invoices that disagree with purchase orders” is a task a company can investigate.
Ask whether the buyer wants examples for training, testing or reference. Training uses examples to shape a model’s behavior. Testing checks its performance. Reference material can be supplied to an application while it answers a question. The same source material may support several purposes, but the packaging, review and permission requirements can differ.
A buyer should also describe the setting. Language, industry, software system, document age and the kinds of exceptions encountered can change whether a source fits. A system used by a small wholesaler may face different cases from one used by a multinational distributor.
Define what one example includes
Choose a unit that matches the task. It might be a completed support case, a contract revision, an accounting exception or a software fix. Then identify the files and fields required to understand that unit. A thousand files might describe ten complete cases, or a thousand unrelated fragments.
The following are hypothetical examples of buyer requests. They illustrate possible data packages, rather than available SnowRock inventory.
| Business task | One example could include | Important question |
|---|---|---|
| Resolve an invoice exception | Invoice, purchase order, reviewer notes and final resolution | Can the buyer reconstruct why the reviewer chose that resolution? |
| Fix a software defect | Issue report, relevant code, reviewed change and test outcome | Was the change actually accepted and tested? |
| Answer a support request | Customer question, applicable policy, response and resolution | Which policy version applied at the time? |
| Review a contract clause | Draft clause, reviewer comments and approved revision | What review criteria and permissions apply? |
| Diagnose equipment trouble | Reported symptom, technician findings, repair and final test | Are measurements and outcomes linked to the same job? |
Keep the context that explains the decision
A final answer often leaves out the difficult part of a job. An approved refund shows what happened. The original request, the policy, an exception approval and the agent’s explanation show why it happened. That sequence can help a buyer judge whether the example teaches the behavior it needs.
Context also prevents misleading interpretation. A code change may look correct until the reviewer sees a failing test. A financial adjustment may make sense only under the accounting policy used that year. Preserve dates, document relationships and relevant constraints when the proposed use needs them.
Give related files a stable identifier, such as a case number that remains consistent throughout the delivery. Document what each field means and which values may be missing. If an identifier is replaced during preparation, maintain the relationships the buyer needs without disclosing an unnecessary original identifier.
Check accuracy, coverage and missing information
A buyer should inspect whether the files open, text is readable, tables parse and related items connect. These basic checks establish usability. They do not establish that every decision in the data was correct. A qualified reviewer may still need to judge the content.
Coverage is a separate question. A support archive consisting mostly of password resets may be a poor source for a product intended to handle billing disputes. A software history dominated by minor formatting changes may contain little evidence about debugging. Break the proposed delivery into the kinds of work the buyer actually needs.
Keep uncertain and unsuccessful cases identifiable. A missing outcome should remain marked as missing. A disputed decision should not become a confident answer merely because someone cleaned the file. The paper Datasheets for Datasets recommends documenting how a dataset was created, what it contains and where its use is limited. Those facts make gaps easier to discuss.
Use a sample to make the next decision
Before preparing an entire archive, agree on a small sample and the questions it must answer. There is no universal sample size for a business-data deal. A first inspection can reveal format problems; demonstrating model performance may require a larger and differently designed test.
For a hypothetical invoice project, the parties might inspect 40 completed cases covering price mismatches, missing purchase orders, duplicate submissions and disputed receipts. The number is an example. The reason for the mix is to expose different kinds of work, including difficult cases, before committing to extraction at scale.
Write the review decision down. A sample can pass, need a specific correction or fail the task requirements. “Interesting data” is too vague to guide the next payment or delivery.
- Can the reviewer follow each case from its input to its recorded result?
- Which required elements are present, absent or unreliable?
- How much human work is needed to prepare another batch?
- What would make the buyer accept, revise or reject the proposed source?
Protect the buyer’s ability to test the model
Google’s machine-learning guidance explains why training examples and final test examples must remain separate. Repeatedly adjusting a model against the same test can make the test less informative. Duplicates across the two sets can also make performance look stronger than it is.
For business records, a duplicate may appear in several forms. A support message might be copied into a summary. A contract amendment might repeat most of its parent agreement. The buyer should decide how related examples are grouped before dividing the data. Depending on the task, that may mean separating by customer, project, time period or another relevant relationship.
Ask the buyer to own this evaluation design. The company can describe where records overlap and how they were created. It should not promise that a particular file count or random split proves the model will work in production.
Establish which information can be included
The person managing a business system may be able to export it without having authority to license everything inside it. A project folder can contain company work, customer material and licensed third-party content. The proposed package needs a review of those different sources.
Begin with the business owner or authorized decision maker and identify who must approve the intended use. Ask about customer agreements, confidential information and personal information that may appear in the files. WIPO’s trade-secret guidance highlights the need to manage both a company’s own confidential information and information received from others.
An initial company description can usually be prepared without distributing the underlying files. Before sharing a sample, agree who will receive it, what they may do with it and what will happen after review. The company and buyer can then resolve specific restrictions against a concrete proposed use.
Prepare a profile the buyer can assess
A short profile should describe the company’s work, the relevant data, the systems holding it and the people responsible. Estimate the date range and number of complete examples. Distinguish an estimate from a count checked in the system. Name known gaps, such as scanned documents or outcomes held in another application.
Include one explanation of how a complete example fits together. That is more helpful than listing every software subscription the company owns. Explain whether someone who understands the work is available to answer questions during sample review.
The buyer can use this profile to assess relevance before either side spends heavily. Preparation cost matters: a source needing manual reconstruction may have different economics from one with consistent case identifiers. Ask who will do that work and whether the budget covers it.
Agree the next step with SnowRock
SnowRock helps companies and AI buyers find a suitable match, coordinates introductions and supports the deal process. A buyer can commission a defined sourcing assignment. The company decides whether to license its data and agrees its payment with the buyer. SnowRock’s buyer-paid introduction or sourcing fee is separate.
The next step should have a clear output: a company profile, a scoped sample or a written explanation of why the source does not fit. Proceed when the task, permission path and preparation effort make sense together. If they do not, change the request before paying to prepare a larger delivery.