How to specify a speech data project so it does not get rejected
Most rejected deliveries trace back to the specification, not the production. Here is the shape of a specification that leaves nothing to interpretation.
A rejected dataset is expensive for everyone. The buyer loses weeks, the producer loses the work, and the relationship usually ends. In almost every case we have seen, the root cause was fixed before a single hour was recorded — in the specification.
The problem is that specifications feel obvious to the person writing them. You know what you mean by "natural conversational speech." The producer has a different picture, and that difference does not surface until delivery.
Write down the number that actually constrains the project
Almost every specification leads with total hours, and almost every experienced producer treats that number as the least informative one on the page.
Hours are easy to produce and easy to pad. The number that determines whether a dataset is useful is distinct speaker count, because that is what decides whether a model generalizes beyond the people in the recording.
A dataset of 500 hours from 20 speakers and a dataset of 500 hours from 500 speakers are not variations on the same product. They support different models. Write the speaker count, and write the minimum, not the target.
Define the recording conditions precisely
"Studio quality" and "natural environment" are not specifications. They are categories, and within each one the variation is wide enough to change the result.
- If studio: sample rate, microphone type, and whether all sessions use the same equipment.
- If natural: the specific environments, and a target signal-to-noise ratio rather than the word "noisy."
- If mobile: device types, and whether the recording app is fixed across all speakers.
- In all cases: whether background speech from other people is permitted, and whether it should be transcribed if present.
Specify annotation depth as a separate line item
Transcription is not one thing. It ranges from a rough orthographic pass to a full phoneme-level alignment with prosodic markup, and the cost difference between those ends is large.
The details that most often get left out: how to handle filler words, whether to normalize numbers and dates, how to treat utterances that switch language mid-sentence, and what to do when a speaker is unintelligible.
Every one of those decisions has more than one defensible answer. The specification does not need to pick the best answer — it needs to pick one, so that all annotators pick the same one.
Ask for the guideline before production starts
A producer who has done this before will have a written annotation guideline, and will send it to you on request. Read it before you commit.
If it answers the questions above, you are working with someone who has run a real project. If it does not exist, the annotators are making those decisions individually, and your dataset will contain all of their different answers.
Build in a pilot batch
The single highest-leverage clause in any data contract is a pilot batch that you can reject.
A pilot of a few hours costs little, and it surfaces every misalignment while there is still time to fix it. Specifications that looked complete on paper usually turn out to have two or three gaps, and a pilot finds them at a fraction of the cost of finding them at delivery.