> ## 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.

# Building with Labels

> An overview of Moonbounce's label-first experience: craft a label, test it, publish a version, and integrate.

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

In the label-first experience, the **label** is the unit of work. Instead of
authoring a policy that contains labels, you craft a single, named
classification concept — like "Harassment" or "Spam" — and iterate on it
directly. Each label owns its own lifecycle, its own test data, and its own
version history.

<Tip>
  **A quick note on the word "label."** In this experience a label is a
  first-class entity you build and iterate on — it is the thing you create, not
  a component inside a policy. If you've used Moonbounce's policy-first
  experience, this is a different meaning of "label" than you may be used to.
</Tip>

## The loop

Everything you do in the label-first experience follows one loop:

<Steps>
  <Step title="Craft a label">
    Create a named label that captures the concept you want to detect, and
    describe what should and shouldn't match.
  </Step>

  <Step title="Test it against its dataset">
    Every label carries its own set of test examples. Run your work-in-progress
    against that dataset, read the results, and refine.
  </Step>

  <Step title="Publish a version">
    When you're happy with the results, publish. Publishing mints an immutable
    snapshot — a **version** — that never changes underneath you.
  </Step>

  <Step title="Integrate">
    Send that version's `label_version_id` to the evaluate API to classify
    content in production.
  </Step>
</Steps>

You'll repeat this loop continuously: craft, test, publish, integrate — then
come back and refine the label as your needs evolve.

## Why label-first

* **The label is self-contained.** Test data and version history live with the
  label, so there's no separate object to wire together before you can iterate.
* **Published versions are reproducible.** Because a published version is an
  immutable snapshot, the results you saw while testing are the results you get
  in production.
* **You iterate in isolation.** Editing happens on a draft that auto-saves, so
  your live, published versions are never disturbed while you experiment.

## Where to next

<CardGroup cols={2}>
  <Card title="Writing Signals" icon="pen" href="/v2/writing_signals">
    Syntax for signals and rules in the label editor, with examples and common
    mistakes.
  </Card>

  <Card title="Labels, Versions & Datasets" icon="layer-group" href="/v2/labels_versions_datasets">
    The core concepts: drafts vs. published versions, immutability, and
    per-label datasets.
  </Card>

  <Card title="Integrating a Label" icon="plug" href="/v2/integrating_a_label">
    Get a label version id and send it to the evaluate API to classify content
    in production.
  </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.