Skip to the main content
Pewter

Articles · AI labs and data buyers

How to Write a Business Data Request for AI Training

Pewter Data · Published November 12, 2026 · Updated November 12, 2026

What should a buyer specify?

Start with the task the data must support, then name the records needed to observe the input, the decisions and the outcome. Include the sector, workflow, date range, minimum useful coverage, exclusions and the test that would make a sample worth pursuing. “We need business email” is too broad to qualify a source.

Lead with a testable use case

Say what the model or evaluator should learn or measure. For example: “We want to test whether freight dispatch records show how a team handled delivery exceptions from first alert through resolution.” That question points to a workflow and an outcome. It does not assume a particular seller or dataset exists.

If the goal is long-horizon agent work, say so. A long-horizon task takes a person hours or days and many steps that depend on each other, and METR's research tracks model progress by the length of task a model can finish. State the task length you are targeting in hours of human effort. Say also whether the records are for training, for a reinforcement learning (RL) environment or for a held-out evaluation set, because each asks different things of a source.

Describe the record chain

List the source types you need together: messages, tickets, orders, documents, system events or revisions. Say which fields or identifiers would let your team connect a case across those sources. Specify whether you need raw records for your own processing or task-shaped examples with a prompt, evidence and an outcome. The choice changes how a sample should be prepared.

Researchers call a case followed from the first request to its recorded outcome a trajectory. If you are building an RL environment, say which part you need the source to supply. One widely used description splits an environment into the surrounding company material, working copies of the software and tasks with verifiers. Business records supply the first of those; the other two are built separately.

State the minimum acceptable coverage

Give a useful range for years, cases, documents or volume, and identify the kinds of variation that matter: ordinary cases, exceptions, failed attempts and completed resolutions. If a requirement is a hard minimum, label it. If it is a preference, say so. Ask for measured counts rather than treating company size or storage volume as a proxy for usable examples.

Propose the evaluation boundaries

Propose categories to exclude, the people who may inspect a sample, where they may inspect it, the allowed evaluation use and the retention period. The owner must approve the agreed scope in writing. Whether the source can grant those rights must be checked separately. A seller's ability to export records is not proof of authority to license them, and de-identification does not settle every contractual restriction.

Include the commercial and delivery constraints

Say whether you seek evaluation access only or a later training license. Name your preferred license term, exclusivity, delivery format and timeline, while leaving price and final terms for negotiation. These preferences help qualify a source; they do not grant rights or commit an owner. Our formats article explains the difference between raw records and task-shaped examples.

Define the decision before requesting a sample

Write down what you will check: completeness of a case, linkage across records, duplicate rate, usable volume, permission evidence and any task-specific benchmark. Define what result would lead to a larger evaluation, what would stop the process and who decides. A sample can indicate fit for a use case; it cannot by itself prove model improvement.

For a practical sample review framework, read How to Evaluate a Business Records Sample for AI Training. Then use the buyer request form to send the task and constraints.

Frequently asked questions

What is a long-horizon task, and why name it in a data request?

A long-horizon task takes a person hours or days and many steps that depend on each other. Naming the task length you need tells a source whether its records hold enough complete cases, from first request to recorded outcome, to be worth sampling.

Should a data request ask for raw records or task-shaped examples?

Say which one you need. Raw records suit a team that does its own processing. Task-shaped examples carry a prompt, the evidence and an outcome. The choice changes how a sample should be prepared.

Can a data request ask for records to build an RL environment?

Yes. Name the workflow and the systems it runs through. Business records can supply the realistic company material an environment is built around. The working copies of the software and the tasks with verifiers are built separately.

How specific should the coverage requirement be?

Give a useful range for years, cases, documents or volume, and say which requirements are hard minimums and which are preferences. Ask for measured counts, because company size and storage volume do not show how many usable examples exist.

Does sending a data request commit the buyer or the owner?

No. The preferences in a request help qualify a source. They do not grant rights or commit an owner, and the owner must approve any agreed scope in writing.

Use the buyer request form to ask for a scoping conversation. Paste your brief into “What data do you need?” The form says Pewter uses your submitted details only to reply to you; settle what may later be shared with prospective sources before sourcing begins.

Send a data request

General information, not legal advice. This article describes how to write a buyer brief; it is not a promise of source availability, rights or measured model performance.