Dataset Specifications

What a delivery contains

A Sonexis delivery is scoped to your brief. Illustrative delivery structure. Availability and licence terms are confirmed against each buyer requirement.

One worked example

What a delivery can contain

Each delivery is scoped around the buyer's model, language mix, use case, speaker requirements, metadata needs, QA depth and delivery format. Field names and depth are agreed per project.

Files and audio: WAV, linear PCM. Sample rate and bit depth confirmed per project against the buyer specification. Delivered technical properties are stated per file rather than claimed in general.
Transcripts: Speaker-labelled where scoped, with timestamp depth agreed per project. Script and code-switching conventions are stated per language.
Speaker structure: One-speaker or two-speaker structure is stated per item. For two-speaker material this covers speaker attribution, turn segmentation, an overlap flag where simultaneous speech occurs, and the channel information for the delivered files — each as delivered, not as a general property. Diarisation and channel separation appear only where the delivered material carries them. For three-or-more-speaker requirements these fields are agreed at scoping and appear only where the scoped material supports them.
Metadata: Language, dialect or accent group, speaker ID, scenario type, recording environment, duration and QA status.
Provenance and rights evidence: Origin, collection route, rights-holder, licensing authority and permitted use — each labelled as independently verified, internal record, or not established. Consent references cover the agreed data use.
QA and evaluation: Technical integrity and checksum verification, language confirmation, speaker-structure review, transcript-to-audio review, and what happened to material that failed.
Dataset Passport: The record of what was reviewed, what was established, and what was not. Part of the delivery, not an optional extra.
Known limitations: What was not checked, how large the reviewed sample was, and what remains unknown. Published with the delivery, not disclosed on request.
Delivery manifest: One row per item, with checksum. Secure delivery method agreed before any sample or pilot is shared.
Licence reference: The licence the delivery is made under, identified in the package. A buyer licence never exceeds the rights actually held on the supply side, and the permitted use is written rather than implied.
Acceptance and remediation: Acceptance criteria are agreed before delivery, so acceptance is a test rather than an opinion. Where delivered material fails those criteria, the correction path — what is re-worked, re-reviewed or withdrawn, and on what timeline — is agreed in the same document.

How a delivery becomes licensable

A delivery becomes licensable when its evidence clears review.

The structure above is an illustrative specification, drawn from a Sonexis-controlled demonstration rather than from an offer.

Where a dataset clears provenance, rights, consent, metadata and quality review and is available against your brief, it is shared privately with a Dataset Passport and controlled sample access. Where suitable reviewed supply is not found, the requirement is met through managed sourcing or buyer-funded collection.

See what a Dataset Passport records →

Illustrative delivery structure

One example of how a delivery is shaped

A schema illustration, so you can see the shape of a delivery before discussing a requirement.

delivery/
├── audio/                 WAV, specification confirmed per project
├── transcripts/           speaker-labelled, timestamp depth per scope
├── metadata.json          language, speaker, scenario, environment, QA status
├── manifest.csv           one row per item, with checksum
├── PASSPORT.md            provenance, rights, consent, verification scope
└── LIMITATIONS.md         what was not checked, and what remains unknown

Field names and depth are agreed per project. The Passport and limitations documents are part of the delivery, not an optional extra.

See a worked Dataset Passport →

Discuss a requirement

If the shape of a delivery fits what you need, tell us the requirement. We check whether suitable existing data exists and can be licensed, then run managed sourcing, and respond with the next practical step.

Submit a requirement

Hold data you can lawfully license? Apply to supply human datasets.