# Datasheet: [Dataset name] [version]

> Complete datasheet for a dataset used to train, evaluate or benchmark
> machine learning systems. It answers, in order, the questions a careful
> consumer of the data would ask: why it exists, what is in it, how it was
> collected and processed, what it should and should not be used for, how
> it is distributed and who maintains it. The section structure follows
> Gebru et al. (2021), *Datasheets for Datasets*. Replace every
> `[bracketed]` value and every answer marked *Example*.

<!--
Guidance: How to use this template
- Answer each question in full sentences. "N/A" is acceptable only with a
  reason, for example "N/A: the dataset contains no data about people".
- Write the datasheet while the dataset is being created, not afterwards.
  Collection details are lost quickly.
- The audience is both the creators (to reflect on choices) and consumers
  (to decide whether the data fits their task). Do not hide limitations.
- Questions about people (privacy, consent, sensitive attributes) apply
  whenever any record relates to an identifiable individual, directly or
  indirectly.
-->

## Document control

<!-- Guidance: Tie the datasheet to one exact dataset version so that results can be reproduced. -->

| Field | Value |
|---|---|
| Document ID | [DS-DATASET-001] |
| Dataset name | [Dataset name] |
| Dataset version | [2.0.0] |
| Datasheet version | [0.1] |
| Status | [Draft / In review / Approved / Published / Deprecated] |
| Owner | [@data-owner] |
| Classification | [Internal / Confidential / Public] |
| Last updated | YYYY-MM-DD |
| Persistent identifier | [DOI or registry URI], checksum `sha256:[hash]` |
| Related documents | [Model cards using this dataset], [DPIA], [Data contract] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Dataset owner | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Privacy officer | [@name] | [Decision] | YYYY-MM-DD |
| Responsible AI reviewer | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record dataset releases and material changes to the answers. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft during collection |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Published with dataset 2.0.0 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added removal of 312 records after deletion requests |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Motivation](#1-motivation)
2. [Composition](#2-composition)
3. [Collection process](#3-collection-process)
4. [Preprocessing, cleaning and labelling](#4-preprocessing-cleaning-and-labelling)
5. [Uses](#5-uses)
6. [Distribution](#6-distribution)
7. [Maintenance](#7-maintenance)
8. [Privacy, consent and data protection summary](#8-privacy-consent-and-data-protection-summary)
9. [References and glossary](#9-references-and-glossary)

## 1. Motivation

<!-- Guidance: Explain why the dataset was created. The answers reveal the assumptions baked into it. -->

### 1.1 Purpose

**Why was the dataset created, and was there a specific task or gap in mind?**

[Answer. Example: "To train and evaluate a classifier that detects urgent
customer support tickets. No public dataset covered support tickets with
urgency labels in our product domain."]

### 1.2 Creators

**Who created the dataset, and on behalf of which organisation?**

[Answer. Example: "The Support Analytics team (four engineers, two
annotation leads) at [Organisation]."]

### 1.3 Funding

**Who funded the creation of the dataset? Name the grant or budget if any.**

[Answer. Example: "Internal budget of the Customer Operations division,
project code CO-2026-07."]

### 1.4 Other comments

[Any other context on motivation, for example a prior dataset this one
replaces and why.]

## 2. Composition

<!-- Guidance: Describe what the dataset contains so consumers can judge whether it fits their task. Be explicit about people-related content, sensitive data and known gaps. -->

### 2.1 Instances

**What does each instance represent? Are there several types of instance?**

[Answer. Example: "Each instance is one support ticket: subject, body,
channel, product area, creation time and an urgency label. There is one
instance type."]

### 2.2 Size and sampling

| Question | Answer |
|---|---|
| How many instances are there in total, per type? | *Example:* 334 000 tickets; 30 000 urgent |
| Is it all possible instances or a sample? | *Example:* A sample: all English tickets from 18 months, excluding spam |
| If a sample, how was it drawn and is it representative? | *Example:* Complete within the period; under-represents chat, which launched late in the period |

### 2.3 Data fields

| Field | Type | Description | Missing values | Example |
|---|---|---|---|---|
| `ticket_id` | string | Pseudonymous identifier | None | `T-8f31c2` |
| `subject` | string | Ticket subject, PII masked | 2% empty | `Cannot log in after update` |
| `body` | string | Ticket body, PII masked, truncated at 4 000 characters | None | `Since this morning ...` |
| `channel` | enum | email, web, chat | None | `web` |
| `label_urgent` | boolean | Consensus urgency label | None | `true` |
| [field] | [type] | [Description] | [Rate] | [Example] |

### 2.4 Labels and targets

**Is there a label or target for each instance? What is it and how reliable is it?**

[Answer. Example: "Binary urgency label from two annotators with lead
adjudication; agreement before adjudication was kappa 0.81."]

### 2.5 Missing information, relationships and splits

| Question | Answer |
|---|---|
| Is any information missing from instances, and why? | [Answer] |
| Are relationships between instances explicit (for example threads, same customer)? | *Example:* `thread_id` links follow-up tickets; customer identity removed |
| Are there recommended splits? | *Example:* Time-based: train to YYYY-MM, validation next 2 months, test last 3 months |
| Are there errors, noise or redundancies? | *Example:* About 4% near-duplicate tickets during incidents |
| Is the dataset self-contained or does it link to external resources? | *Example:* Self-contained; attachment links removed |

### 2.6 Confidential and sensitive content

| Question | Answer |
|---|---|
| Could any data be confidential (legal privilege, contracts, non-public communications)? | [Answer] |
| Could any data be offensive, insulting, threatening or cause anxiety if viewed? | *Example:* Yes, about 1% of tickets contain abusive language |
| Does the dataset relate to people? | *Example:* Yes, customers who wrote tickets |
| Does it identify subpopulations (age, gender, region)? How? | *Example:* No explicit attributes; language can be inferred |
| Can individuals be identified, directly or in combination with other data? | *Example:* Possible from free text despite masking; treated as personal data |
| Does it contain special category data (health, ethnicity, religion, sexuality, biometrics, criminal records, financial data)? | *Example:* Incidental mentions of health in about 0.3% of tickets |

### 2.7 Coverage summary

Summarise how the dataset is distributed over the characteristics most
likely to affect models trained on it. Consumers use this table to decide
which groups or conditions they must evaluate separately.

| Characteristic | Category | Share of instances | Share in target population | Gap |
|---|---|---|---|---|
| Channel | *Example:* Chat | 6% | 21% (current traffic) | Under-represented |
| Language background | *Example:* Second-language writers (estimated) | 14% | 18% | Slightly under |
| Period | *Example:* Incident days | 9% | 7% | Slightly over |
| [Characteristic] | [Category] | [%] | [%] | [Gap] |

## 3. Collection process

<!-- Guidance: Explain how the raw data was obtained, by whom, when, and under which permissions. Consumers need this to judge bias and lawfulness. -->

### 3.1 Acquisition

| Question | Answer |
|---|---|
| How was the data acquired: directly observed, reported by subjects, inferred or derived? | *Example:* Directly observed: exported from the ticketing system |
| What mechanisms or procedures were used (hardware, software API, manual curation)? | *Example:* Nightly export via the ticketing API, validated by row counts |
| If sampled, what was the sampling strategy? | [Answer] |
| Who was involved in collection and how were they compensated? | *Example:* Employees as part of normal duties |
| Over what timeframe was the data collected? Does it match the creation time of the content? | *Example:* YYYY-MM to YYYY-MM, same as ticket creation |

### 3.2 Ethical review

**Was any ethical review process conducted? Give the outcome and a link if possible.**

[Answer. Example: "Reviewed by the Responsible AI board on YYYY-MM-DD,
approved with conditions: PII masking and a 24-month retention limit."]

### 3.3 Data about people: notice and consent

| Question | Answer |
|---|---|
| Was the data collected from the individuals directly or from third parties? | [Answer] |
| Were individuals notified about the collection? How? | *Example:* Privacy notice section 4 states tickets may be used to improve support tools |
| Did individuals consent? How was consent requested and recorded? | *Example:* Not consent-based; legal basis is legitimate interest, with an assessment on file |
| Is there a way to revoke consent or object? | *Example:* Deletion and objection requests remove the ticket at the next release |
| Has a data protection impact assessment been done? | *Example:* Yes, DPIA-2026-11 |

## 4. Preprocessing, cleaning and labelling

<!-- Guidance: Describe every transformation between raw data and the released dataset, and whether the raw data is still available. Labelling instructions belong here too. -->

### 4.1 Processing steps

| Step | What was done | Tool and version | Records affected |
|---|---|---|---|
| 1 | *Example:* Removed spam and internal test tickets | Rules in `filters.yml` v3 | 12 400 removed |
| 2 | *Example:* Masked emails, phone numbers, names | NER model [name, version] plus regex | All |
| 3 | *Example:* Truncated body at 4 000 characters | Pipeline v2.1 | 1.8% |
| 4 | *Example:* Deduplicated exact copies within 1 hour | Hash on normalised text | 3 100 removed |
| [n] | [Step] | [Tool] | [Count] |

### 4.2 Labelling

[Annotator pool, guidelines version, training, quality control, agreement
statistics and how disagreements were resolved. Example: "Twelve trained
agents labelled with guideline v4; 10% double-labelled; kappa 0.81; lead
adjudication for all disagreements."]

### 4.3 Raw data and software

| Question | Answer |
|---|---|
| Was the raw data saved? Where, and who can access it? | [Answer] |
| Is the preprocessing software available? | *Example:* Yes, repository `data-pipelines/tickets`, tag `ds-2.0.0` |

## 5. Uses

<!-- Guidance: Describe current and possible uses and, most importantly, uses that would be inappropriate or harmful given how the data was made. -->

### 5.1 Uses so far and repository of uses

[Answer. Example: "Training and evaluating urgency model 1.x (see model
card MC-URGENCY-001). A list of uses is kept in the dataset registry."]

### 5.2 Other suitable tasks

[Answer. Example: "Topic classification of support tickets; routing to
product areas."]

### 5.3 Risks from composition and collection

**Could anything about the composition or collection affect future uses or cause unfair treatment, legal or financial harm?**

[Answer. Example: "Chat is under-represented, so models trained on this
data may underperform on chat. Users should evaluate per channel."]

### 5.4 Uses to avoid

| ID | Use to avoid | Reason |
|---|---|---|
| AV-01 | *Example:* Profiling individual customers | Data collected for support improvement only |
| AV-02 | *Example:* Evaluating agent performance | Labels reflect ticket content, not agent work |
| [AV-nn] | [Use] | [Reason] |

## 6. Distribution

<!-- Guidance: State who can get the data, how, under what licence and with what restrictions. -->

| Question | Answer |
|---|---|
| Will the dataset be distributed outside the creating organisation? | *Example:* No, internal teams only |
| How is it distributed (download, API, registry)? Does it have a DOI? | *Example:* Internal dataset registry, versioned |
| When was or will it be distributed? | YYYY-MM-DD |
| Under what licence or terms of use? | [Licence or internal policy] |
| Have third parties imposed restrictions on the data? | [Answer] |
| Do export controls or other regulatory restrictions apply? | [Answer] |

## 7. Maintenance

<!-- Guidance: Explain who keeps the dataset correct over time and how consumers learn about changes and errors. -->

| Question | Answer |
|---|---|
| Who supports and maintains the dataset? | [@data-owner], [team] |
| How can the owner be contacted? | [Channel, email alias] |
| Is there an erratum? | [Link to errata log] |
| Will the dataset be updated? How often, by whom, and how will consumers learn about it? | *Example:* Quarterly release; announced in the registry change feed |
| Are there retention limits for data about people? Are they enforced? | *Example:* 24 months from ticket creation; records past the limit dropped at each release |
| Will older versions remain available? | *Example:* Last two versions kept for reproducibility, then deleted |
| Can others extend or contribute? How are contributions validated? | [Answer] |

### 7.1 Errata and change log

Record every correction and every removal of records, including removals
made in response to deletion requests, so that consumers can tell whether
a result was produced on affected data.

| ID | Date | Version affected | Issue | Action | Fixed in |
|---|---|---|---|---|---|
| ER-01 | YYYY-MM-DD | *Example:* 2.0.0 | 140 tickets labelled urgent by a misconfigured import | Labels corrected after re-review | 2.0.1 |
| ER-02 | YYYY-MM-DD | *Example:* 2.0.1 | 312 records subject to deletion requests | Records removed | 2.1.0 |
| [ER-nn] | YYYY-MM-DD | [Version] | [Issue] | [Action] | [Version] |

## 8. Privacy, consent and data protection summary

<!-- Guidance: A one-page summary for privacy reviewers, pulling together answers from sections 2.6, 3.3, 4 and 7. This section is a format aid, not legal advice. -->

| Item | Status | Evidence |
|---|---|---|
| Legal basis recorded | [Yes / No] | [Reference] |
| Notice given to data subjects | [Yes / No] | [Privacy notice section] |
| Data minimisation applied | [Yes / No] | [Fields dropped, masking] |
| Special category data handled | [Yes / No / N/A] | [Control] |
| Deletion and objection requests honoured | [Yes / No] | [Process] |
| Retention limit enforced | [Yes / No] | [Job or control] |
| DPIA completed | [Yes / No / Not required, reason] | [Reference] |

This datasheet documents facts about the dataset. It is not legal advice;
confirm data protection obligations with your privacy or legal function.

## 9. References and glossary

<!-- Guidance: Cite the method and related documents. -->

### 9.1 References

| Reference | Use |
|---|---|
| Gebru, T., Morgenstern, J., Vecchione, B., Wortman Vaughan, J., Wallach, H., Daumé III, H., Crawford, K. (2021). *Datasheets for Datasets*. Communications of the ACM 64(12), 86-92. | Question structure |
| [Model card] | Downstream use of this dataset |
| [Annotation guideline vN] | Labelling rules |

### 9.2 Glossary

| Term | Meaning |
|---|---|
| Instance | One record of the dataset, such as one ticket or one image |
| Adjudication | Resolution of annotator disagreement by a senior reviewer |
| Kappa | Agreement statistic between annotators corrected for chance |
| Pseudonymous identifier | An ID that replaces a direct identifier but can be linked back with extra data |

## Standard and licence note

Structure aligned with the question sections of Gebru et al. (2021),
*Datasheets for Datasets* (motivation, composition, collection process,
preprocessing, cleaning and labelling, uses, distribution, maintenance).
The questions here are paraphrased and extended in original text written
for this collection and reproduce no text from the paper; read the paper
for the authors' full question set. Template licence: MIT.