Business data for AI agents
How to write an AI dataset requirements brief
Last updated /Business data for AI agents
An AI dataset requirements brief is a document your team can use to reject a candidate. It names the intended use, the industry, the modality, how much history you need, the geography, the schema you can accept, what must be excluded, and the acceptance criteria for a sample. If a profile or a sample misses a line, the answer is no. A paragraph that says high-quality enterprise data for agents is not a brief. It cannot be failed, so it cannot be sourced against.
Writing the brief does not mean Big Data/Little Guy, or anyone else, has a holder who matches it. We will not imply that. The sourcing sequence around the brief is how a buyer sources proprietary business data. Choose the record type before you fill schema lines, using how a buyer chooses among business record types. The work those records might teach is how business data trains AI agents to do real work.
Why a searchable need is narrower than a vision
Matching is a comparison between your sentences and a description a holder allowed. Vague sentences match everything and therefore nothing. Narrow sentences match rarely, which is the point. A brief that admits a miss saves both sides from a sample that was never going to be usable. Put the miss in writing before anyone collects files.
Fields worth forcing into the open
- Intended use. Train, evaluate, or both. Say what decision the system must get right. Do not say improve our model.
- Industry and setting. The job, not a list of every vertical you might enter later.
- Modality. Text notes, structured events, documents, or a mix. If you need audio, say so, and expect consent limits you do not control.
- Historical depth. A range you could actually use. A demand for all history is not a depth.
- Geography and language. Where the work happened and which languages your pipeline can accept.
- Schema. The fields you will read, including the outcome field. If you cannot name the outcome field, you are not ready to evaluate completeness.
- Exclusions. Credentials, payment instruments, direct identifiers, another party's content, and anything your counsel has already banned.
- Acceptance criteria. What a sample must show, and the condition that fails it: missing endings, duplicate rates you will not tolerate, labels that leak the answer, or a provenance story you cannot trace.
What not to put in the brief
Production secrets, example customer records, or a demand that the holder break their own exclusions to satisfy your schema. Also leave out a promise, to yourself or to us, that a match will be found. The buyer request can carry the brief. It does not convert the brief into supply. The profile review overview is what happens if a description exists to compare. The marketplace page explains matching. None of them guarantee a fill.
Briefs that look serious and cannot be used
- Every field optional. Then every candidate passes and you learn nothing.
- Schema copied from your internal warehouse, including columns no holder should have.
- Acceptance criteria that are really model metrics. Accuracy of your system is not a property of their file. Diligence of the file is how to diligence a business dataset before licensing.
- Hidden exclusions. If identifiers must be absent, say so in the brief, not after a transfer.
- A single brief covering unrelated uses. Split train and evaluate if the permissions and the slices differ.
How we read a brief
Unlockt, LLC operates Big Data/Little Guy. We can compare a brief with profiles holders have approved for discussion. If nothing resembles it, we should say so. We should not soften a failed line to keep a search alive. Send the brief through the request form. If you are a holder checking your own shelves, that is the free data value check, a different door.
A later license is still your counsel's document. Questions to take them are questions buyers should ask counsel before a training license. We will not treat a completed brief as evidence that those questions were answered.
Questions people ask
Does a finished brief mean you can source it?
No. It means we can compare it with descriptions that exist. The comparison can fail. Failure is a valid outcome.
How long should the brief be?
Long enough that a sample can fail a named line. A page of slogans is too short. A dump of your whole taxonomy is too loose.
Should I include an example row from production?
No. Describe the fields. Do not paste live customer or employee rows into a request.
Can one brief cover every modality?
Only if each modality has its own exclusions and acceptance line. Otherwise split them.
Who signs off inside our company?
Someone who can say the use is real and someone who can say the exclusions are mandatory. A brief owned by nobody will be waived at the first inconvenience.
Where does the brief go next?
Into the sourcing sequence: type check, then a sample only if a profile is close. Do not request delivery of a full archive to test the brief.
Describe the data you need
Tell us the use, the records, and the limits. A request is not a promise that a matching dataset is available.
Tell us what data you need