Skip to main content
This is Moonbounce’s label-first experience. If you’re looking for the policy-first experience, switch using the version selector above.
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.
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.

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

​
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:
1

Pick what to test

Test your draft while you’re actively refining, or test a published version to confirm how it behaves.
2

Run against the dataset

Evaluate against the label’s own dataset and read the results.
3

Refine and re-test

Adjust the draft, add or correct examples in the dataset, and run again until you’re confident.
4

Publish

When the results hold up, publish a new version and move on to integration.

​
Where to next

Building with Labels

Step back to the overview of the craft → test → publish → integrate loop.

Integrating a Label

Take a published version to production with the evaluate API.

​
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.
  • Security, availability, or other incidents: Use the in-app Feedback button or email support@moonbounce.io. See Customer Feedback for what to include.