How to Write a Proprietary Dataset Sourcing Brief

An AI dataset sourcing brief translates a research goal into records a supplier can recognize and evaluate. Define the task, one usable example, the relationships it needs and the evidence that would make it acceptable. Then separate essential requirements from preferences and unresolved questions.

This guide is for AI research, data acquisition and procurement teams seeking proprietary data through owners or intermediaries. It is not a listing of datasets available from DataNexx. The template and worked example are illustrative, and no specification here establishes permission to collect or transfer data.

Start with the task, not a broad category

“We need healthcare data” or “we need manufacturing data” leaves too much unexplained. Describe what the model must do and the evidence needed to assess that behavior. For example, extracting fields from a report differs from predicting an outcome or reconstructing a multi-step workflow.

State whether the intended use is training, evaluation, retrieval, research or another purpose. Explain the output you want without sharing confidential model details unnecessarily. Our AI-company sourcing overview explains how a defined request fits an initial DataNexx discussion.

Define one usable example

Specify the unit: a document, an encounter, an instrument run, an engineering revision or a connected case. State which components must belong to the same example and how that relationship could be demonstrated.

A million rows are not necessarily a million independent examples. Repeated exports, versions and related records can inflate counts. Ask suppliers to explain their counting units and duplication rules rather than demanding a headline volume that has no shared definition.

For connected histories, say what must be known at the time of the task and what is a later outcome. Information recorded after an event should not accidentally appear in inputs meant to represent the earlier decision. This is especially important when dividing related cases across training and evaluation sets.

Copy this sourcing-brief template

Replace the prompts with your requirements. Keep unresolved points visible. This worksheet is a starting point for discussion, not an order or a binding acceptance agreement.

Brief field	What to specify	Useful distinction
Intended task	What the model should do and how success will be assessed	Training versus evaluation versus retrieval
Unit of example	What constitutes one usable case	Cases versus rows, files and versions
Required components	Inputs, context, labels and outcomes	Essential versus optional
Relationships	Which records must connect and how	Verified linkage versus inferred association
Coverage	Countries, languages, sectors and historical period	Required coverage versus preferred diversity
Quality	Completeness, readability, measurement context and known errors	Disqualifying gaps versus acceptable missingness
Outcomes	What counts as a label and how it was established	Administrative status versus verified result
Format	Native files, exports, schemas and documentation	Existing format versus requested conversion
Scale	Target usable examples and counting method	Available archive versus proposed licensed subset
Rights and use	Intended recipients, purposes and restrictions	Existing authority versus review still required
Prior exposure	Publication, prior licensing and known overlaps	Exclusive, nonexclusive or unknown status
Sample review	Scope, reviewers, secure access and decision process	Initial evaluation versus production use
Commercial process	Timing, responsible contacts and negotiable terms	A planning assumption versus an agreed commitment

The W3C DCAT 3 vocabulary provides a reference for describing datasets and their distributions. A dataset description and a particular file delivery are not the same thing. You do not need a DCAT implementation to write a useful brief; the practical point is to distinguish the collection from its formats, versions and access arrangements.

Explain missingness before setting thresholds

Name the fields and relationships your task cannot work without. Describe which missing values are acceptable and which would prevent evaluation. Avoid a blanket requirement such as “fully complete data” without explaining what completion means.

Ask suppliers to distinguish information never collected, information outside the extract and information lost during migration or conversion. A blank field should not automatically become a negative label. Record known coverage changes so that reviewers can interpret the sample rather than judge it against an unstated expectation.

Make acceptance criteria observable. “Every evaluated example includes a readable report and its documented method version” is clearer than “high-quality scientific data.” Set numerical thresholds only when your team has chosen them for the actual task; there is no universal threshold that makes all proprietary datasets suitable.

Ask what the outcome actually proves

A closed ticket, paid invoice, analyst sign-off and successful retest are different outcomes. State the evidence your intended use needs, and allow suppliers to explain what their records actually establish.

For a laboratory task, raw signals without linked methods may suit a different question from reviewed reports with no raw output. The laboratory inventory guide can help a supplier describe those layers. For operational tasks, use the connected-company data guide to discuss the relationships across systems.

Do not ask a supplier to invent labels retrospectively and call them original outcomes. If annotation or expert review must be commissioned, treat that as additional work with its own scope, evaluation and rights.

Worked example: a laboratory result-review brief

Hypothetical example: an AI team wants to evaluate whether a system can identify missing context in laboratory result packages. This is a fictional research brief, not a buyer request or a claim about DataNexx inventory.

• Task: flag result packages whose supporting context is incomplete for a defined review checklist.
• Unit: one result package with its linked method version and available QC context, not every file counted separately.
• Required inputs: a result representation, units and qualifiers, method reference and a description of the available run and control links.
• Outcome evidence: a recorded reviewer decision and its meaning, where retained. Cases without such decisions remain a separate group rather than receiving assumed labels.
• Coverage: supplier to describe the actual matrices, methods, countries and periods. Research team to identify which are in scope after initial review.
• Evaluation design: related runs and revisions grouped together so that near-duplicate histories do not cross the intended split.
• Initial step: review an approved descriptive inventory; agree a small representative sample and permitted review process only after technical and rights questions are addressed.

This brief is specific about the task while leaving genuine unknowns open. It does not require a laboratory to expose client records or make a licensing commitment in its first reply.

Make rights and prior exposure part of the brief

Describe the proposed use accurately, including which organizations would receive access and whether model training, redistribution or derived outputs are contemplated. Ask the supplier who can authorize the relevant subset and which contractual or confidentiality limits need review.

A claim of ownership, a public download link or an NDA is not a complete rights assessment. Record whether material has been published, licensed before or obtained from another party. Unknown overlap should remain unknown; it should not be relabeled as exclusive.

The FAIR principles identify provenance and clear usage conditions as important for reuse. They do not require unrestricted access. Our data licensing principles explain the separation between technical provenance and permission. This guide is general preparation advice, not legal advice.

Agree a sample-review process without premature commitments

Explain what reviewers will check and who will make the technical decision. Agree the sample scope, permitted recipients and uses, access controls, retention and any deletion obligations for the specific exchange. Do not imply a universal retention period or a right to train on samples supplied only for evaluation.

Ask for a representative sample, not only hand-picked successes. If practical constraints limit selection, document them. Report what the sample does and does not show, and avoid extrapolating a small selected sample into guaranteed archive-wide quality.

Keep delivery checks separate from commercial acceptance. A file opening successfully does not establish coverage, rights or fitness for the intended task. Any later contract should define the actual licensed scope and acceptance process.

Send a brief that a supplier can answer

Finish with a short list of essential requirements, preferences and open questions. Give the supplier a way to respond with partial coverage rather than forcing a misleading yes or no. Avoid requesting unnecessary conversion work before you know whether the archive fits.

Send DataNexx your dataset requirements with a high-level brief. If you are the owner preparing the other side of the conversation, describe your archive instead. Do not include sensitive raw records, confidential examples or credentials in an initial form. A clear brief improves qualification; it does not guarantee availability, price or a transaction.