01 / Project brief
Start with the decision, not the volume.
‘We need more data’ is a starting point, not a specification. Describe what should become possible after the project: comparing model candidates, improving recognition of specialist terms, supporting a new locale, or delivering searchable transcripts. The intended use determines which examples matter and what a useful output looks like.
Separate the immediate deliverable from the longer-term ambition. A pilot may establish whether a labeling rubric is workable; it does not need to solve every production requirement. Name the person who will approve that pilot and the evidence they need to make the next decision.
- Decision
- What will you choose, change or release using the result?
- Consumer
- Which person, pipeline or application receives the files?
- Boundary
- What is explicitly outside this first phase?
02 / Project brief
Describe the data you actually need.
A headline quantity can hide a coverage gap. Break the source material into the conditions that affect your task: modality, locale, domain, participant profile, recording environment, device and content length. Distinguish must-have coverage from useful variation.
Supply representative examples when you are authorized to share them. Include difficult material, not just the clearest sample. Label synthetic, collected and existing material separately so the team does not mistake one source for another. Document exclusions such as unsupported languages, unrelated domains or unusable recordings.
| Brief field | What to specify |
|---|---|
| Source & modality | Audio, text, images, video or documents; existing material versus new collection. |
| Coverage | Locales, speaker or participant characteristics, domains and environmental conditions. |
| Unit of work | File, segment, utterance, image, document, interaction or conversation. |
| Constraints | Permitted use, access restrictions, exclusions and dependencies. |
| Volume | Target units and an agreed way to count usable, rejected and replacement items. |
03 / Project brief
Make the quality bar observable.
Define acceptance in terms a reviewer can apply. ‘High quality’ does not tell someone whether to preserve a hesitation, flag an uncertain name or reject an ambiguous label. Provide a small set of accepted examples, rejected examples and borderline cases with the reasoning behind each decision.
Agree how uncertainty should be represented. A reviewer should not have to invent a speaker identity or choose a label when the evidence is insufficient. Set a route for questions, a process for resolving disagreement and a way to update the guidance without silently changing previously delivered data.
- Task rules
- Define labels, formatting, timestamps and the treatment of missing or unclear information.
- Review depth
- Identify which work needs specialist review and which checks can be automated.
- Acceptance
- Agree the evaluation method, sample design, critical defects and correction process.
04 / Project brief
Design the handoff before production.
Ask the receiving team to open a sample delivery before you scale the work. A linguistically sound transcript can still fail a pipeline if its timestamps use the wrong unit, identifiers change between exports or required metadata disappears.
Specify the file format, schema, identifier rules, naming convention and versioning approach. Keep source IDs connected to annotations and review records. Define how corrections are delivered: a replacement batch, a patch file or a new version with a change log. Include who confirms receipt and who signs off.
| Deliverable | Acceptance question |
|---|---|
| Primary files | Can the destination system parse and use the output? |
| Metadata manifest | Can every item be traced to its source and coverage attributes? |
| Review record | Are unresolved issues, correction reasons and approval states visible? |
| Delivery notes | Are limitations, exclusions and version changes explained? |
05 / Project brief
Use a pilot to expose ambiguity.
Choose a pilot that reflects the intended production mix, including difficult examples. Before work starts, agree what a successful pilot will establish: workable instructions, an acceptable output schema, feasible coverage or a clearer estimate of review effort.
Review the pilot jointly. Resolve disagreements, update the rubric and record any scope changes. Keep a version of the agreed specification with the approved examples. If a material assumption changes later (such as a new locale, device or use case) revisit the relevant checks instead of assuming the old approval still applies.