> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clavata.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Labels, Versions & Datasets

> The core concepts of the label-first experience: labels, drafts vs. published versions, immutability, and per-label datasets.

<Note>
  This is Moonbounce's label-first experience. If you're looking for the
  policy-first experience, switch using the version selector above.
</Note>

This page covers the three concepts at the heart of the label-first
experience. They build on each other, so we'll take them in order: the
**label**, its **versions**, and its **dataset**.

## Labels

A **label** is a named, first-class classification concept that you build — for
example "Harassment" or "Spam." It's the thing you create and iterate on, and
it owns everything it needs to do its job:

* its definition (what it's looking for),
* its **test data**, and
* its **version history**.

You create a label, refine it, and keep returning to it over time. There's no
separate container to manage — the label is the unit of work.

<Tip>
  Treat a label as an independent thing you create and iterate on. It stands on
  its own, with everything it needs to do its job — its definition, test data,
  and version history — living right alongside it.
</Tip>

## Drafts vs. published versions

Editing always happens on a **draft**. The draft auto-saves as you work, so
your changes are never lost and you don't have to manage a separate "save"
step.

When the draft is ready, you **publish** it. Publishing mints a **version**: an
**immutable snapshot** of the label at that moment. Versions are sequential —
each publish creates the next one in the label's history.

<Warning>
  A published version never changes. To make changes, you edit the draft and
  publish again, which creates a new version. Existing versions — and anything
  integrated against them — are untouched.
</Warning>

### Why immutability matters

Immutability is the whole point. Because a published version is frozen:

* **Production results are reproducible.** The behavior you tested is the
  behavior you get, every time, for as long as you send that version.
* **Nothing shifts underneath you.** A teammate refining the draft can't change
  how an already-integrated version behaves.
* **History is auditable.** You can always see exactly which version produced a
  given result.

## Per-label datasets

Each label has its **own** set of test examples — its dataset. There is no
separate dataset object to create and no dataset id to track; the dataset
simply belongs to the label.

A good dataset has well-rounded examples of both content you *want* the label
to match and content you *don't*. This is what makes your testing meaningful.

### Testing and iterating

Testing folds directly into how you iterate:

<Steps>
  <Step title="Pick what to test">
    Test your **draft** while you're actively refining, or test a **published
    version** to confirm how it behaves.
  </Step>

  <Step title="Run against the dataset">
    Evaluate against the label's own dataset and read the results.
  </Step>

  <Step title="Refine and re-test">
    Adjust the draft, add or correct examples in the dataset, and run again
    until you're confident.
  </Step>

  <Step title="Publish">
    When the results hold up, publish a new version and move on to integration.
  </Step>
</Steps>

## Where to next

<CardGroup cols={2}>
  <Card title="Building with Labels" icon="layer-group" href="/v2/building_with_labels">
    Step back to the overview of the craft → test → publish → integrate loop.
  </Card>

  <Card title="Integrating a Label" icon="plug" href="/v2/integrating_a_label">
    Take a published version to production with the evaluate API.
  </Card>
</CardGroup>

***

## We'd Love to Hear From You

Whether you have a suggestion, feedback, or a bug to report, here are the best ways to get in touch:

* **In the App:** Use the **Feedback button** for direct suggestions.
* **On Slack:** Reach out to the team in your shared channel.
* **With your AM:** Talk to your dedicated account manager.
* **Via Email:** Send a message to [**support@moonbounce.io**](mailto:support@moonbounce.io).
* **Security, availability, or other incidents:** Use the in-app **Feedback button** or email [**support@moonbounce.io**](mailto:support@moonbounce.io). See [Customer Feedback](/feedback/customer_feedback) for what to include.