- A data manifest lists each dataset with its volume, dates, source, rights basis and privacy handling.
- It lets buyers assess interest and price before any sample is shared.
- The same manifest becomes the schedule to your license agreement.
The fields
| Field | What to enter |
|---|---|
| dataset_id | A short unique ID, such as DS-01 |
| name | Plain name: "Support tickets 2017 to 2025" |
| description | One or two sentences on what the data is |
| source_system | Where it lives: Zendesk, Slack, GitHub, file share |
| record_type | Ticket, message, file, recording, commit |
| record_count | Approximate number of records |
| size_gb | Approximate size |
| date_from, date_to | Date range |
| languages | Languages present |
| created_by | Employees, customers, contractors, users |
| rights_basis | Why you can license it: created by staff, terms of service, consent |
| personal_info | What personal information it contains |
| deidentification | Planned method |
| exclusions | What will be removed |
| format | Export format |
| sample_available | Whether a redacted sample can be prepared |
| notes | Anything a buyer should know |
How to fill it in
Count from system reports rather than exports, so nothing leaves your systems yet. Ranges are fine. Be candid about personal information and restrictions: buyers discount for surprises far more than for known issues.
Read the full guide: how to build a data manifest.
Read next
Questions
Do I need to export data to fill in a manifest?
No. Use counts and dates from system reports. The point of a manifest is to describe data before anything is moved.