AI training data isn’t a spreadsheet that happens to be large. It’s a collection of examples prepared for a particular task, with enough context to tell what each example represents. Turning business records into that collection can involve record linkage across systems, identifying outcomes and excluding information that wouldn’t have been available when a prediction was needed.
Start with the learning objective: what decision should the model support, and when? That question determines which records, outcomes and checks matter. ADP (Accord Data Partners) is independent of buyers and supports business introductions, but it never receives company datasets. Defining a usable collection is separate work for the data owner and any prospective buyer.
How do records become training examples?
For AI training data, an example needs a clear unit. It might be one order, one maintenance visit or one document, rather than every row exported from a system. The feature values describe what was known about that unit at the relevant moment. Decide on the unit first, or later joins may quietly count the same event several times.
Hypothetical worked example: a wholesaler wants to predict, when an order is accepted, whether it will miss its promised dispatch date. One example could contain the order’s acceptance date, available stock and promised dispatch window, followed by the actual outcome. This is an illustration of dataset design, not a claim that any business has built or sold such a collection.
The wholesaler’s order system and dispatch log may use different identifiers or update at different times. Someone must decide how to match them, which timestamp defines acceptance and how to treat amended promises. A field entered after dispatch might explain what happened, but it cannot fairly serve as an input to a prediction made at acceptance.
What does a label tell the model?
In supervised AI training data, the target label is the outcome the model is asked to predict. For the wholesaler, that could be whether dispatch happened after the promised date. A convenient field isn’t necessarily the right outcome: Google’s guide to dataset labels distinguishes a direct label from a proxy that only approximates the intended result.
Making labelled examples requires a dependable way to determine each outcome. A dispatch scan might supply it, provided the scan means the same thing across sites and periods. Orders with no scan need investigation, not an automatic “on time” mark. Otherwise the model learns the wholesaler’s recording gaps alongside its dispatch patterns.
Write an annotation rule for awkward cases before reviewing them at scale. Does a revised promise replace the original one? What if an order ships in two parts or is cancelled? Different answers define different prediction tasks. Record the chosen answer and sample disputed cases so that two reviewers aren’t assigning opposite outcomes to similar orders.
What changes when examples are unlabelled?
AI training data can also contain unlabelled examples: records with usable inputs but no confirmed answer to the proposed prediction. They may help explore patterns or support other learning methods, but they cannot directly tell a supervised model which orders missed their promise. Don’t count every usable order row as a completed example for that task.
An unlabelled collection might reveal common combinations of order size, stock position and dispatch window. That could help someone inspect how orders differ, without demonstrating which combinations predict lateness. The distinction matters when describing a collection to a technical team: “contains order histories” says much less than “contains order histories with verified dispatch outcomes”.
Before commissioning new labelling, ask whether the outcome already exists elsewhere. A dispatch timestamp may be held in a carrier feed or archive, though matching it back could be difficult. If the outcome genuinely wasn’t recorded, assess the cost and reliability of reconstructing it. Guessing from a status field may produce a different task.
Why does task coverage matter?
Useful AI training data needs case coverage that resembles the situations in which the model would be used. A wholesaler’s routine weekday orders may tell little about seasonal peaks, stock shortages or a newly opened depot. Make a short list of operating conditions that change the decision, then check whether the collection actually contains examples of them.
Sampling bias can enter before anyone builds a model. If the export contains only completed orders, cancelled or unresolved orders may disappear, even though they matter to the business question. Compare the proposed extract with the source system’s full population by period and status. Explain exclusions rather than assuming a large extract represents everything.
Also inspect class imbalance: late orders might be much less common than on-time ones. A model that nearly always predicts “on time” could then appear accurate while missing the cases you care about. Check performance on each outcome separately and decide whether the collection has enough relevant cases to assess the proposed task.
How do errors enter a collection?
Errors in AI training data often begin with source provenance. A dispatch date copied from a manual spreadsheet may have a different meaning from one generated by a warehouse scan. Note which system supplied each field and when its meaning changed. Without that trail, a strange result can be hard to trace back to the record that caused it.
Look for duplicate examples caused by repeated exports, order amendments or multiple scans for the same shipment. Duplicates can make a common situation seem more common and can distort later testing. Decide whether an amendment replaces an earlier record or represents a separate decision point, then apply that rule consistently rather than simply deleting matching rows.
A practical quality review combines automated checks with human inspection. Flag impossible dates, missing outcomes and values outside expected ranges, then read a sample of the underlying records. Ask whether the flagged pattern is an error or a real operating exception. Keep a note of corrections so that a later refresh applies the same reasoning.
Why must evaluation examples stay separate?
A separate evaluation split lets a team check how a model handles examples it did not learn from. For AI training data, that means setting aside suitable records before tuning decisions around model results. Google’s machine learning glossary explains training and evaluation terms; the business decision is which held-back records reflect the task you actually want to assess.
Test leakage happens when information from those held-back examples influences training or model choices. Target leakage can also happen within a row: including a final dispatch status as an input would give away the answer to an acceptance-time prediction. List when each input becomes known, and keep that list beside the proposed prediction time.
The split should respect how records relate to one another. Two scans from the same order belong together, not on opposite sides of a test. If the intended use concerns future orders, testing on a later period can expose changes that a random split might hide. The resulting score is evidence about that test, not a promise about every future period.
What should documentation explain?
Good collection documentation makes AI training data understandable without relying on the person who assembled it. State the unit of an example, the source systems, date range, field meanings, exclusions and method used to assign outcomes. Include known gaps, such as a depot that only began recording stock snapshots halfway through the period.
State the training objective in ordinary business terms as well as technical ones. “Predict missed dispatch promises at order acceptance” specifies an outcome and a decision time; “predict order problems” does neither. Describe what an output would help someone do and what it cannot establish. This gives a reviewer a way to challenge fields that don’t fit the task.
Keep versions of the extraction and labelling rules when systems or practices change. A new order status, for example, could alter which rows enter the collection without changing its filename. Note who can answer questions about the definitions and what remains unresolved. That makes a future refresh or technical assessment less dependent on guesswork.
How are business records different from a ready dataset?
AI training data that works technically isn’t automatically available to license. A data licence must be agreed directly between the business and buyer and should set out permitted use and limits. Check who has authority under existing contracts, along with confidentiality and copyright in source material. Business consent to an introduction does not answer those separate questions.
If you’re weighing up whether to sell your company data, keep the commercial conversation separate from dataset preparation. ADP provides a paid introduction course and a portal, not model engineering or a destination for your records. Its training data licensing guide covers the transaction. Neither an introduction nor a licence itself settles the lawful basis for processing personal data.
Pseudonymised records may still be personal data, so establish what can lawfully be processed before any proposed use. If you own business records and want to explore an introduction after checking their scope and your authority, ADP’s business information is a sensible next read. ADP can’t approve eligibility, offer a licence or promise earnings from AI training data.
Frequently asked questions
Does every training example need a label?
No. Some learning methods use unlabelled examples. But a supervised task, such as predicting whether an order will dispatch late, needs dependable outcomes for the examples used to teach and assess that prediction.
Can a spreadsheet of business records be used as a dataset?
Possibly, but its size alone tells you little. First define what one example represents, which fields were available at the decision time, how outcomes are checked and which records are missing or duplicated.
Does licensing a dataset settle data protection questions?
No. The business and buyer agree their own licence, but they must separately address the lawful basis and other requirements for any personal-data processing. Pseudonymisation alone does not necessarily remove those requirements.
