# Cancel a batch job Source: https://docs.clavata.ai/api-reference/batch-processing/cancel-a-batch-job /openapi.json post /v1/batch-jobs/{batchJobId}/cancel Cancels a batch job. This will stop the batch job from being processed further. Policy-first endpoint: batch jobs are created from a `policy_id`. # Create a new batch job Source: https://docs.clavata.ai/api-reference/batch-processing/create-a-new-batch-job /openapi.json post /v1/batch-jobs Creates a new batch job that can process multiple content items in bulk. Returns a presigned URL for uploading the input file. The job will automatically start processing once the input file is uploaded. Policy-first endpoint: batch jobs are created from a `policy_id`. # Get batch jobs Source: https://docs.clavata.ai/api-reference/batch-processing/get-batch-jobs /openapi.json get /v1/batch-jobs Retrieves batch jobs, optionally filtered by batch job IDs or states. If no filters are provided, all batch jobs will be returned. Policy-first endpoint: batch jobs are created from a `policy_id`. # Create a new job Source: https://docs.clavata.ai/api-reference/create-jobs/create-a-new-job /openapi.json post /v1/jobs Creates a new job for content evaluation. Can be configured to wait for completion or return immediately with a job ID. Policy-first endpoint: requires a `policy_id`. # Stream job results in real-time Source: https://docs.clavata.ai/api-reference/create-jobs/stream-job-results-in-real-time /openapi.json post /v1/jobs/stream Initiates a streaming job that processes content data and returns results as they become available. Useful for real-time content evaluation. Policy-first endpoint: requires a `policy_id`. # Get job details Source: https://docs.clavata.ai/api-reference/get-jobs/get-job-details /openapi.json get /v1/jobs/{jobUuid} Retrieves details of a specific job, including evaluation results if the job is complete. Available to policy-first and label-first accounts; works on any job in the account, including jobs from `POST /v1/labels/evaluate`. # Get job label hits Source: https://docs.clavata.ai/api-reference/get-jobs/get-job-label-hits /openapi.json get /v1/jobs/{jobUuid}/labels Retrieves label occurrences for a job, projected to label, modality, score, and timed fields (start_ms/end_ms and their timecodes). Video frame hits are point-in-time (start only); audio chunk hits are ranged when end_ms is set. Set the optional job_result_id to scope the response to a single result of the job. Hits are paged in a stable order: results in the order they were recorded, and each result's hits in the order the evaluation recorded them (start time ascending for video). Omitting `page_size` uses the default of 1000. The maximum `page_size` is 1000. Negative `page_size` is rejected. When more hits remain, `next_page_token` is set; pass it as `page_token` with the same job_uuid and job_result_id to fetch the next page. An incomplete job returns its status with no labels and no `next_page_token`. Available to policy-first and label-first accounts; works on any job in the account, including jobs from `POST /v1/labels/evaluate`. # List jobs Source: https://docs.clavata.ai/api-reference/get-jobs/list-jobs /openapi.json get /v1/jobs Retrieves a list of jobs with optional filtering by time ranges and status. Incomplete jobs will only include basic information. Failed jobs omit Job.error here; fetch failure details with GetJob or GetJobLabels. Available to policy-first and label-first accounts; works on any job in the account, including jobs from `POST /v1/labels/evaluate`. # API Reference Source: https://docs.clavata.ai/api-reference/introduction Which Moonbounce API endpoints work with policy-first accounts, label-first accounts, or both. Every request authenticates with an API key for your account, sent as a bearer token in the `Authorization` header. See [API Key Management](/integrations_and_developer_tools/api-docs-sdks/api_key_management) to create a key. ## Endpoints by account type Moonbounce accounts are either **policy-first** or **label-first**. Some endpoints belong to one workflow; the job read and feedback endpoints work with both. | Endpoints | Account | | - | - | | `POST /v1/jobs`, `POST /v1/jobs/stream` | Policy-first: requires a `policy_id`. | | `POST /v1/batch-jobs`, `GET /v1/batch-jobs`, `POST /v1/batch-jobs/{batchJobId}/cancel` | Policy-first: batch jobs are created from a `policy_id`. | | `/v1/labels`, `/v1/labels/{labelId}`, `/v1/labels/{labelId}/versions`, `POST /v1/labels/evaluate` | Label-first only. Other accounts receive `FAILED_PRECONDITION`. | | `GET /v1/jobs`, `GET /v1/jobs/{jobUuid}`, `GET /v1/jobs/{jobUuid}/labels`, `POST /v1/jobs/{jobUuid}/feedback`, `GET /v1/jobs/{jobUuid}/feedback` | Both. Works on any job in the account, including the jobs `POST /v1/labels/evaluate` creates (it returns a `job_uuid` for each label version it evaluates). | ## Which account do you have? If your workspace has you crafting **labels** rather than writing policies, you're on a label-first account; new accounts start label-first. Use the version selector at the top of these docs to switch between the policy-first and label-first API Reference. To enable label-first endpoints on an existing account, contact [support@moonbounce.io](mailto:support@moonbounce.io). *** ## 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. # Get job feedback Source: https://docs.clavata.ai/api-reference/job-feedback/get-job-feedback /openapi.json get /v1/jobs/{jobUuid}/feedback Retrieves the feedback recorded against a job, one entry per (content or video occurrence, label) pair that has been given feedback, oldest first (by when the feedback was first submitted, then ID). Replacing feedback keeps its original position. Omitting `page_size` uses the default of 1000. The maximum `page_size` is 1000. Negative `page_size` is rejected. When more feedback remains, `next_page_token` is set; pass it as `page_token` with the same job_uuid to fetch the next page. actual_outcome is the thresholded section or label result, not a per-frame occurrence score. Available to policy-first and label-first accounts; works on any job in the account, including jobs from `POST /v1/labels/evaluate`. # Submit job feedback Source: https://docs.clavata.ai/api-reference/job-feedback/submit-job-feedback /openapi.json post /v1/jobs/{jobUuid}/feedback Records feedback about the outcome a label produced for a piece of content, or a specific video frame or transcript chunk, in a completed job. Copy GetJobLabels LabelHit fields into the item's target.occurrence to address a video occurrence, or omit occurrence to address the whole result. Feedback is stored one entry per (content or video occurrence, label) pair; submitting feedback for a pair that already has feedback replaces it. actual_outcome is the thresholded section or label result, not a per-frame occurrence score. Available to policy-first and label-first accounts; works on any job in the account, including jobs from `POST /v1/labels/evaluate`. # April 23, 2026 Source: https://docs.clavata.ai/changelog/2026-04-21 LUNA label assistant, account switching, label insights, and more. ## New features ### LUNA — AI-powered label assistant [LUNA](/guides/policy_authoring/label_copilot) (Label Understanding & Notation Assistant) is now available. Describe what you want a label to detect in plain language, and LUNA generates working policy syntax through a guided loop of generation, evaluation, signal review, and refinement. You can launch LUNA from the policy editor or directly on an existing label version. ### Account switching You can now belong to multiple accounts and switch between them without logging out. Use the account switcher in the dashboard to move between organizations seamlessly. ### No-expiration API keys When creating an [API key](/integrations_and_developer_tools/api-docs-sdks/api_key_management), you can now choose a no-expiration option alongside the existing 30, 90, 180, and 365-day durations. ### Batch processing results with labels and scores [Batch processing](/integrations_and_developer_tools/api-docs-sdks/batch_processing) output now includes structured label names and scores in the results CSV, so you can see exactly which labels matched and at what confidence for each item. ### Content feed job type The content feed now displays the job type for each evaluation, making it easier to distinguish between API calls, batch jobs, and test runs. # June 2, 2026 Source: https://docs.clavata.ai/changelog/2026-06-02 Free plans, self-serve signup, and a brand-new label-first experience. ## New features ### Sign up for free Moonbounce is now open to everyone. You can create a free account in a couple of minutes. The free plan includes every feature, and your first 10,000 reviews are on us. See [Plans & Pricing](/getting_started/plans_and_pricing) for details. ### Get classifying in minutes New accounts land in our reimagined label-first experience. You start from a single label: a concept you want to detect, like "Harassment" or "Spam." Describe in plain language what should and shouldn't match, and it runs against real content right away. Naming what you care about is all it takes to start classifying. ### Test, publish, and integrate with confidence Every label has its own set of examples, so you can test it against real content and refine until it's right. Your work saves automatically as you go. When a label is ready, you publish a version, which is a snapshot that stays fixed. Send that version to the evaluate API and production will behave the way it did in testing. Learn more in [Building with Labels](/v2/building_with_labels). ### Improve labels from real production traffic The [Content Feed](/v2/content_feed) shows what your labels are matching in production. Review real results, find the edge cases, and pull them straight into a label's examples to sharpen your next version. ### Get started even faster with our Label Library A built-in tour walks you through your first label, and the [Label Library](/getting_started/overview/policies/label_library) offers pre-built templates for common harms to give you a head start. ### Keep an eye on usage The new [Usage](/v2/usage) page shows how much you've evaluated, broken down by label, with a reviews-remaining indicator. **Coming soon:** a Pro plan for teams that outgrow the free tier, with more capacity and higher limits and no enterprise contract. # June 10, 2026 Source: https://docs.clavata.ai/changelog/2026-06-10 API key expiration alerts and label experience improvements. ## What's new ### **CSAM Detection Confidence Levels** CSAM pre-check failures now include `match_confidence`. Exact hash matches are labeled `EXACT`, while perceptual matches are graded `HIGH`, `MEDIUM`, or `LOW` based on similarity. ### API key expiration alerts Customer admins now receive email reminders before an API key expires, with notices sent one month, one week, and one day before expiration. These alerts make it easier to rotate keys on time and prevent integration interruptions. ### Label UX improvements The tuning panel now gives you deeper insight into how signals are scored against specific content, making it easier to refine signals so they align with your expectations. New label versions are less likely to show stale auto-evaluation results as the latest state, so version results should better reflect the current evaluation state. Daily rate limits are also clearer for enterprise customers. # July 8, 2026 Source: https://docs.clavata.ai/changelog/2026-07-08 Image support in LUNA, cost transparency on Usage, and faster dataset review. ## New features ### Image support in LUNA [LUNA](/guides/policy_authoring/label_copilot) now works with image content end-to-end. Choose Text or Images at the start of a session, and LUNA scopes its dataset, evaluation, and generation flow to that modality. Image rows show inline thumbnails with hover previews in the dataset picker, expand overlay, and signal results, and LUNA can incorporate image feedback when refining signals. ### Cost transparency on the Usage page Eligible plans now see a **Current billing cycle estimate** on the [Usage](/v2/usage) page, with a cost breakdown alongside review counts so you can track spend against usage without leaving the dashboard. ## Improvements ### Faster dataset scrolling with row thumbnails Image cells in datasets and LUNA now render lightweight cached thumbnails instead of decoding the full-resolution image on every scroll, making large image datasets noticeably snappier. ### LUNA "generate from name" and UX polish You can now kick off a LUNA session from just a label name — LUNA drafts an initial description before you write any signals. The **Generate** button also responds immediately when clicked instead of waiting for validation to finish. ### Draft dataset filters load all matching rows In the Manage Dataset sheet, clicking a match-type chip (FP / FN / TP / TN) on a draft version now loads every matching row automatically instead of stopping at the first page. ## Fixes * **Clearer upload errors.** Adding a row with an unsupported image format now keeps the dialog open and shows the specific rejection reason instead of a generic success toast. * **No more stale test decorations.** After editing a signal, old score chips and row highlights are cleared until you rerun tests, so results always match the current editor state. * **Better LUNA signal generation.** LUNA no longer produces assertions made entirely of negated signals or references to signal placeholders like `S1`/`S2`, and retries or falls back automatically when a model response is invalid. * **Modal and overlay consistency.** Fixed a mismatch in underlying UI primitives that could cause subtle focus and layering issues in modals. # August 26, 2026 Source: https://docs.clavata.ai/changelog/2026-08-26 Public API for label CRUD and immutable label versions. ## New features ### Programmatic label management Label-first accounts can now create, list, read, update, and delete labels over the public API, and publish immutable versions from rule text. `PATCH` updates label metadata only (name, description, disabled) and never mutates rule content. Versions are create-and-read only: there is no update, delete, or "current version" pointer. Evaluation remains by explicit version ID. See [Managing Labels via API](/v2/managing_labels_via_api) and the [API Reference](/api-reference/labels/create-a-label). # September 22, 2026 Source: https://docs.clavata.ai/changelog/2026-09-22 Job label hits and job feedback endpoints, and an API Reference split by account type. ## New features ### Job label hits and job feedback Three job endpoints are now documented in the API Reference. They work for policy-first and label-first accounts, on any job in the account, including jobs from `POST /v1/labels/evaluate`. * [Get job label hits](/api-reference/get-jobs/get-job-label-hits) (`GET /v1/jobs/{jobUuid}/labels`) lists the labels a job hit, with modality, score, and video or audio timing. * [Submit job feedback](/api-reference/job-feedback/submit-job-feedback) (`POST /v1/jobs/{jobUuid}/feedback`) records whether a label's outcome on a piece of content, video frame, or transcript chunk was right. * [Get job feedback](/api-reference/job-feedback/get-job-feedback) (`GET /v1/jobs/{jobUuid}/feedback`) returns the feedback recorded on a job. ## Improvements ### API Reference by account type The API Reference now lists only the endpoints that apply to the selected version: policy-first shows job creation and batch processing, and label-first shows labels, label versions, and label evaluation. Both show the job read and feedback endpoints. See the [API Reference introduction](/api-reference/introduction) for which endpoints each account type can use. # Customer Feedback Source: https://docs.clavata.ai/feedback/customer_feedback Overview of how to submit customer feedback in the app. Easily submit **bugs, ideas, feature requests, and security or availability concerns** directly from our web app. Just look for the chat bubble. # What You Can Do ## Report Bugs Bugs should be squashed! Please report them through the web app rather than Slack, email, or other methods. We get the most useful information when feedback is submitted in-app. ### What to Include * What were you doing when you experienced the bug? * Does it happen consistently? * Screenshots, videos, or files: anything helps! ## Report Security, Availability, and Other Incidents If you spot anything that affects the **security, confidentiality, integrity, or availability** of Moonbounce, or you have any other concern or complaint, please report it through the in-app feedback bubble. Examples include: * **Security:** suspected vulnerabilities, account compromise, suspicious activity, or data exposure. * **Confidentiality:** content, customer data, or credentials visible to people who shouldn't see them. * **Integrity:** classifications, datasets, or other records that appear corrupted, altered, or wrong in a way you can't explain. * **Availability:** outages, degraded performance, or other reliability issues. * **Other concerns or complaints:** anything else you'd like us to look into. If you can't access the app, email [**support@moonbounce.io**](mailto:support@moonbounce.io) instead. We triage incident reports on receipt and will follow up with the reporter. ## Share Ideas Have an idea that could make Moonbounce better? We love hearing creative suggestions for new possibilities and improvements. ## Request Features Need a feature to improve your workflow or deliver better insights (like enhanced reporting)? Tell us what would make the product more valuable for you. # How to Submit 1. Look for the **Message Bubble** in the app (bottom-right corner). 2. Add details and, if possible, attach screenshots or recordings. 3. Submit your feedback. Your input goes straight to us to review, categorize, and prioritize. ## 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. # Getting Started Source: https://docs.clavata.ai/getting_started/getting_started_guide Brief guide to getting started with Moonbounce. **Using labels instead of policies?** Moonbounce has two experiences, and these docs cover the policy-first one. If your workspace has you crafting **labels** rather than writing policies, you're on the label-first experience — switch to the **label-first** experience using the version selector at the top, or jump to the [Quickstart](/v2/quickstart). ## Overview This brief guide introduces the key features of Moonbounce, highlighting how it can help streamline your policy management process. *** ### Home Page From the Home Page, you can easily access key areas of the system. This includes: * Help articles, which offer support resources to assist with any questions. * Your Policies section, where you can manage and configure compliance settings. * Datasets, where all uploaded data used for testing is stored. * This navigational walkthrough, which you can revisit at any time for guidance. ### Navigation Bar On the left side of the screen, you'll find the navigation bar. This allows you to: * Return to the Home Page from any page in Moonbounce. * Manage your Policies, where you can create, edit, and otherwise view details of your Policies. * Access the support center for access to our reference documentation. * View and manage your user account. ### Manage Policies Page In the "Manage Policies" section, you have the ability to: * View and edit existing Policies. * Manage your Policies, including updating their states, viewing the version numbers, and reviewing the last edit dates. * Identify policies using their unique IDs, displayed next to each policy name. * Create new Policies. ### Policy Editor On the Editor page, you can select an existing Policy for modification. Once selected, you are able to: * View the configurations of your Policy. * Add, edit, or remove Sections or Rules. * Create a Section or a Label. * Create Rules and add them to your Section. Rules are created using Conditions. * Adjust Signal Lists. * Run tests on the current Policy, or on your updated Policy. *** ### Running a Test Below the Policy Editor, you can run tests on your Policy using your datasets, or pre-defined datasets provided by Moonbounce. This includes: * Selecting a dataset or uploading your own, adjusting your User Labels if needed, then clicking "Run Test." * Viewing the test results, which display lines of content analyzed, showing whether the content was classified as true (the AI flagged the content based on a Section in the Policy) or false (the AI did not flag the content). * Downloading the test results in csv format, once a test is run. * Make adjustments to your Policy based on the test results. * Re-run your test and continue making adjustments until you are comfortable with the test results. *** ## 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. # Analytics Overview Source: https://docs.clavata.ai/getting_started/overview/analytics_overview Brief overview of the Analytics page. The Analytics page provides insights into your dataset and policy performance. View trends, identify patterns, and assess the impact of policy decisions with visual reports and key metrics. Use this page to refine your approach and make data-driven improvements. ## Tokens This chart shows you your daily token usage across Text and Images. Analytics Token Update 9 30 2025 Pn ## Policy Overview Table Below the token usage chart, you’ll find a table showing your policy activity for a selected time period. * **Total tokens** — Total tokens used by the policy during the selected period. * **Text tokens** — Tokens used for text-based evaluations. * **Image tokens** — Tokens used for image-based evaluations. * **Total reviews** — Number of evaluations performed using the policy. Policy Activity Table **Testing** shows how many tests you’ve run in the UI during the selected period across all policies (even those not listed here). ## Reviews Remaining If you're an evaluator you'll see a chart like the below showing you how many reviews you have before your review limit is up. You'll need to contact your account owner to change this limit. file-279z1afmi4.png ## 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. # Dataset Overview Source: https://docs.clavata.ai/getting_started/overview/datasets_page_overview Brief overview of the Dataset page. The **Datasets** tab allows you to manage manually uploaded data for policy testing. You can label entries, modify existing labels, and organize data into dedicated datasets to streamline your workflow. Use this tab to curate and prepare datasets for effective policy evaluation. # Uploading a dataset Moonbounce offers two ways to upload your datasets. Single row additions or bulk uploading. The process differs slightly between text and images. ## Add row (single uploads) Clicking the **+ Add row** button will bring up a modal where you can add an image or text and labels if desired. This is a single upload if you need to add a quick row. Add Row Modal 8 21 2025 Pn ## Bulk uploading There are slight differences when it comes to bulk uploading so see below for your use case. ### Text Text is fairly straightforward using a .csv and it only requires two columns. * **Content**: The text that you want to upload * **Labels**: This should relate to the labels either in your policy or what you intend to write in your policy (e.g., `dog`, `cat`) * If the label column is left blank, the system will assume that the content of that row should not be caught by a policy Labels must be comma separated and it is good form to have a space as well: dog, cat and not dog,cat. ### Images (bulk-csv) Images can be uploaded using a modified csv from text. * **Content**: The image name you want. If you leave this blank, the system will return a blank title which is more difficult to search on * **Labels**: This should relate to the labels either in your policy or what you intend to write in your policy (e.g., `dog`, `cat`) * **ImageUrl**: This is the url of the image you want to upload Images must be publicly accessible in order for Moonbounce to download them. ### Images (bulk) In the bulk upload window, you can drag and drop images from your computer as you would on most other sites. You have the option of adding a label(s) or uploading with no labels. Bulk Upload Images 8 21 2025 Pn Labels are applied to all images. If you have images with different labels it is best to upload them in batches to ensure they get the correct labels. The csv method is faster if available. *** # Labelling data ### Adding new labels * You can click on a row of content and then add or remove labels individually for quick fixes * For larger changes you can select all or select multiple rows and **Set labels** to make changes Click a row then use Shift + click on a different row. This will select everything in between. # **All Content** The **All content** view contains a list of all the data you've uploaded to Moonbounce along with its original labels, type of content (text or image), and the content itself. ## 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. # Feed Source: https://docs.clavata.ai/getting_started/overview/feed How to use the Feed page to view your content. The **Feed** tab allows you to view content as it flows through our system. This view gives you a quick overview of how content is being labeled by your policy. Because the Feed displays live content from your evaluation endpoint, you may encounter harmful, sensitive, or explicit material depending on the nature of your traffic. Please proceed with caution. ## Filtering Content To keep your view focused, the policy filter only displays policies that have actively processed traffic via the evaluation endpoint. You can further refine the feed using the following tools: * **Policy Selection:** On the top left, select from the list of policies that have been used in production evaluations. * **Date Range:** Select a specific date and time range for the content you would like to view. * **Label:** Filter the results to show only content containing a specific label. * **Confidence Score:** Filter by a specific confidence score range (e.g., 50%-90%) to isolate uncertain or high-confidence evaluations. Data availability starts from 12/10/2025. You cannot filter by dates prior to this. ## Viewing Content Once a policy is selected, content will populate the page in real-time, sorted by most recent. Each entry provides a snapshot of how the system interpreted the data: * **Content:** The actual text or image that was evaluated. * **Policy Label:** Clearly visible tags showing which labels your policy applied to the content. * **Timestamp:** The exact date and time the content entered the system. ## Curating Datasets The Feed is not just for monitoring; it is also an active workspace for improving your models. You can select specific pieces of content directly from the feed to build or refine your datasets. 1. **Select Content:** Click to select one or more items from the feed. 2. **Add to Dataset:** Choose the option to add the selected items to a dataset. This allows you to rapidly capture edge cases or correctly labeled examples to retrain and improve your policy's accuracy over time. *** ## 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. # Dashboard Source: https://docs.clavata.ai/getting_started/overview/navigating_the_dashboard Overview of the main homepage of Moonbounce. ### Home Page From the Home Page, you can easily access key areas of the system. This includes: * The Policies page, where you can create or manage your policies * Datasets, to curate, tag, or upload new data for testing * Analytics, where you can view charts and graphs related to your instance * Admin, where you can add/remove users from your instance or adjust their roles * Help article quick links, to help get you up to speed on using Moonbounce Dashboard 8 20 2025 Pn ### Navigation Bar On the left side of the screen, you'll find the navigation bar. This allows you to: * Return to the Home Page from any page in Moonbounce. * Manage your Policies, where you can create, edit, and otherwise view details of your Policies. * Access the support center for access to our reference documentation. * View and manage your user account. ### Manage Policies Page In the "Manage Policies" section, you have the ability to: * View and edit existing Policies. * Manage your Policies, including updating their states, viewing the version numbers, and reviewing the last edit dates. * Identify policies using their unique IDs, displayed next to each policy name. * Create new Policies by selecting either: * A blank template * Pre-populated templates provided by Moonbounce. ### Policy Editor On the Editor page, you can select an existing Policy for modification. Once selected, you are able to: * View the configurations of your Policy. * Add, edit, or remove Sections or Rules. * Adjust Signal Lists. * Otherwise generally refine your Policy. * Run tests on the current Policy, or on your updated Policy. ### Running a Test Below the Policy Editor, you can run tests on your Policy using your datasets, or pre-defined datasets provided by Moonbounce. This includes: * Selecting a dataset or uploading your own, then clicking "Run Test." * Viewing the test results, which display lines of content analyzed, showing whether the content was classified as benign or harmful. ### Analytics — Coming soon! *** ## 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. # Insights Source: https://docs.clavata.ai/getting_started/overview/policies/insights View quick metrics associated to your policy and its versions. # Insights Here you can see basic metrics filtered to a specific policy over a given time period. This will help you see the version over version performance, how your label outcomes change over time or with volume spikes and more. ## Summary metrics These metrics are calculated only from evaluations run against the selected policy within the selected time window. ### Total tokens used * The total number of tokens processed for evaluations in the time window. ### Reviews (API evaluations) * The total number of evaluations executed against this policy in the time window. * Each evaluation counts as one review. ### True % * The share of evaluations in the time window that returned True. * **At least one label was applied** during that evaluation. ### False % * The share of evaluations in the time window that returned False. * **No labels were applied** during that evaluation. ## Daily label chart The chart shows **day-by-day label outcomes** for the selected time window. ### What’s shown For each day (UTC): * How often each **label** was **True** (i.e., applied at least once in an evaluation) * The **policy version** associated with those outcomes * If the policy version changed during the selected window, the chart reflects which version the label outcomes belonged to. Insights Chart 02 06 2026 ### How to interpret it * A higher count for a label means the label was applied more often that day. * If you see a behavior shift aligned with a version change, use the version context to compare performance before/after the deployment. ## Deployment history Deployment history lists policy deployments that occurred within the selected time window. Each deployment includes: * **Dates**: The time range when this policy version was used to evaluate content. * **Version**: The policy version's sequential identifier. * **Version author**: Who authored the policy content. * **Deployed by**: Who made this version the active version used for policy evaluations. * **Token multiplier**: [Multiplier](/guides/policy_authoring/token_multiplier) applied to policy evaluations that affects cost and reflects relative complexity. * **Current True %**: Percentage of evaluations during this deployment where at least one label was applied. Deployment History 02 09 2026 ## 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. # Label Library Source: https://docs.clavata.ai/getting_started/overview/policies/label_library An overview of how to use the Label Library. # Label Library The **Label Library** provides a comprehensive collection of pre-built label templates designed to give you a head start in policy creation. Whether you are detecting hate speech, harassment, or other sensitive topics, the Label Library helps you build robust policies without starting from scratch. Label Library Policy 2025 12 05 Gi ## Overview Creating effective policies takes time, and staring at a blank editor can be daunting. The Label Library solves this by offering a curated selection of labels that you can instantly add to your policies. These templates are optimized for Moonbounce’s latest syntax, ensuring you are building on a foundation of best practices from day one. ### Key Benefits * **Accelerated Onboarding:** Skip the initial learning curve and get a functional policy running in minutes. * **Best Practices:** Use pre-configured labels that demonstrate best practices for catching your most serious harms. * **Flexible Integration:** Add library content to completely new policies or append them to your existing rulesets. ## How to Use the Label Library You can access the Label Library during two key workflows: when creating a new policy and when editing an existing one. ### Creating a New Policy When you start the **Create Policy** flow, you can choose to begin with a blank policy. From the editor, you will see the option to browse the Label Library. 1. Select the labels you wish to include (e.g., *Hate Speech*, *Harassment*). 2. Moonbounce will automatically populate your blank policy with the selected content. It is very important to test any labels against a labelled dataset via the UI to ensure the label(s) are catching what you want! ### Editing an Existing Policy You can also expand your current policies using the library. 1. Open an existing policy in the **Policy Editor**. 2. Select the **Label Library** feature. 3. Choose the specific labels you want to add. 4. The system will append the new labels to your existing policy code, allowing you to integrate new rules without disrupting your current logic. ## Important Notes * **Templates, Not References:** When you add a label from the library, it is copied into your policy as a standalone template. It does not maintain a link to the library version. * **No Auto-Updates:** Since these are static templates, updates or improvements made to the global Label Library will not automatically propagate to policies where you have already added them. You are free to modify the added code to suit your specific needs. ## 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. # Policy Editor Source: https://docs.clavata.ai/getting_started/overview/policies/policy_editor Brief overview of the policy editor. The Policy Editor is your main workspace for building and refining policies in Moonbounce. This page gives you the essentials to get started quickly. Policy Editor 8 20 2025 Pn ## Name Your Policy * Choose a clear, descriptive name. * Helps you stay organized and makes collaboration easier. Text Policy Username and Profile Text Policy ## Select a Dataset * Pick a dataset to test against: * Using your own dataset with labels is always best * Ensure the labels in your dataset match the labels in your policy ## Select a Test * **All labels**: This will run a test against your entire dataset. Can be useful for seeing everything together but can feel overloaded with a large dataset * **All metrics**: This will give you an overview of how each label in your policy is performing against the dataset. You can find trouble spots or low performers easily here * **Label focused**: This runs a test against a singular label and gives you the metrics for that label. Much smaller than running the **All labels** view * Testing helps you: * See which items are flagged or missed in real time * Use the results to refine conditions ## Metrics Breakdown * After testing, review key performance indicators: * **F1 score**: balance between precision and recall (higher = better overall performance) * **Accuracy**: overall percent of correct results (both positives and negatives) * **Precision**: of the items flagged, how many were actually correct * **Recall**: of the items that should be flagged, how many you caught * **False negative %**: share of harmful items missed * **False positive %**: share of safe items wrongly flagged * **True positives**: correctly flagged content * **True negatives**: safe content correctly ignored * **False positives**: safe content incorrectly flagged * **False negatives**: harmful content missed * Metrics guide your next iteration and help you understand how your policy will perform in production ## Commit Versions * Save changes with a **commit**. * Add a short **commit note** (e.g., “Added rule for image spam”). * Commits create a version history so you can track progress and roll back if needed. * Click the **Versions** tab, the version you want, then click **Make current version** to set that version as the one used by your 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**](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. # Policy Management Source: https://docs.clavata.ai/getting_started/overview/policies/policy_management_page Brief overview of the policy management page. The Policy Management page is where you will create new policies and manage your existing policies. ## Creating new policies 1. Click the 'New policy +' button in the top right to bring up the policy editor. 2. You can then start creating a policy right there or use [Label Library](/getting_started/overview/policies/label_library). ## Editing an existing policy If you have an existing policy you'd like to edit, simply click its name and you'll be brought into the editor. ## Additional page callouts * You can click the ellipsis on the right hand side of your policies and delete them if they are no longer needed If you delete a policy by accident don't panic! Reach out to a Moonbounce team member through Slack or email and we can restore it for you. ## 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. # Plans & Pricing Source: https://docs.clavata.ai/getting_started/plans_and_pricing Overview of Moonbounce plans and how to upgrade Moonbounce offers different plans to match where you are in your journey — from kicking the tires to running production workloads at scale. ## Free The Free plan lets you try the product end to end. You get enough usage to develop rules, evaluate content, and explore the platform. Usage is capped, so Free is best suited for evaluation and light experimentation rather than production traffic. ## Pro The Pro plan is coming soon. Stay tuned. A self-serve tier between Free and Enterprise, intended for teams ready to run production workloads without a custom contract. ## Enterprise Enterprise plans are tailored to your use case — usage, support, SLAs, and any platform requirements are negotiated to fit. If you're running Moonbounce in production or expect to, Enterprise is the right fit. ## Upgrading To upgrade, email us at [hello@moonbounce.io](mailto:hello@moonbounce.io) and we'll get back to you to scope the right plan for your needs. If you're on the Free plan, you can also use the **Upgrade to Enterprise** button on the Account page in the dashboard. *** ## 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. # What can Moonbounce do for you? Source: https://docs.clavata.ai/getting_started/what_can_moonbounce_do_for_you Overview of the key areas and features Moonbounce might be able to help you with. Moonbounce is built to help you understand, organize, and act on the content flowing through your platform, whether it's AI-generated or user-generated. ## **Moderate Harmful or Sensitive Content** Moonbounce is often used to detect and flag content that violates platform policies or poses harm to users. Common categories include: * **Harmful or illegal content** like CSAM (Child Sexual Abuse Material), NCII (Non-Consensual Intimate Images), Bestiality, Incest or Rape * **Community guideline violations**, like Nudity, Violence or Hate speech These categories can be adapted to fit your platform's unique trust and safety needs. You define what "harmful" or "violative" means in your context, and Moonbounce detects it accordingly. ## **Label Content or Build Taxonomies** In addition to harmful content, Moonbounce can be used to apply **non-violative, descriptive labels** to help structure your content, build robust taxonomies and improve recommendations, search, or tagging workflows. Some examples include: * **Demographic or identity-based labels** e.g., Straight, LGBTQ+, Fictional, Human, Mixed * **Content maturity** e.g., PG, PG-13, R, X * **Language labels** e.g., English, Spanish, Formal, Informal * **Fine-grained features in text or image** e.g., Cat, Dog, Eyeliner, Blue eyes, Brown eyes Moonbounce supports full customization of your taxonomy. You can define custom labels and rules for detection, build a hierarchy of labels, make policies region-specific to accommodate different cultural contexts for different parts of the world and detect nuanced differences, such as distinguishing between eye colors or language or tone. Our customers have used labelling for training their own AI models and developing a semantic understanding of what's being developed/shared on their platform. ## 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. # What is Moonbounce? Source: https://docs.clavata.ai/getting_started/what_is_moonbounce Overview of Moonbounce and its key features **Moonbounce** (formerly Clavata) was built for companies that refuse to choose between moving fast and staying in control. Our **patented AI control engine** closes the gap between intention and outcome, giving teams the real-time insight and nuanced control they need to create with conviction at any scale. Moonbounce serves companies building the AI products that people rely on every day across **healthcare, financial services, consumer social**, and beyond and has processed **1T+ tokens** across a customer base of **100 million monthly active users**. Founded in 2024 and based in Oakland, California, Moonbounce was built by engineers with decades of experience at **Meta, Apple, and Evernote**. ## System Diagram system diagram ## Development Loop *** ## 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. # Rule Filtering Source: https://docs.clavata.ai/guides/assertion_filtering A guide to using Rule Filtering to isolate and analyze the impact of individual policy rules on your test data. Rule Filtering is a powerful tool for debugging and refining your policies. It allows you to trace a specific outcome in your test results directly back to the individual rule that caused it. By clicking on the filter button to the left of your rules within a label, you can instantly filter your test data to see only the rows that were affected by that specific assertion. This provides a granular view that is essential for understanding complex policy logic. ## Why Use Assertion Filtering? This feature is invaluable for several common tasks: * **Debugging Complex Policies:** When a label is applied, it can sometimes be difficult to know which of its many rules was the trigger. Assertion Filtering lets you pinpoint the exact rule responsible for a result. * **Validating New Rules:** After adding a new rule to a label, you can click on it to immediately see if it's capturing the correct data without affecting unintended rows. * **Refining Rule Logic:** If a rule seems too broad or too narrow, you can filter by it to see a sample of the data it's matching. This helps you fine-tune the logic with confidence. * **Auditing and Transparency:** Quickly answer questions like "Why was this specific row flagged?" by showing the exact rule that triggered the label. ## How to Filter by Assertion Follow these steps to filter your test results by a specific rule. 1. Navigate to the **Test** tab of the policy you want to analyze. 2. In the policy definition panel on the left, expand the label that contains the rule you wish to investigate. 3. Simply **click** on the specific rule (assertion) you want to filter by. 4. When the test results are filtered by an assertion, you are seeing a subset of your data where that specific rule evaluated to `true`. The test results view will automatically update, displaying only the rows that were directly affected by the selected rule. Assertion Filtering 10 8 2025 Gi ## 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. # Automated Policy Creation Source: https://docs.clavata.ai/guides/automated_policy_creation Learn how to automatically generate a policy from your labeled datasets. Automated Policy Creation (APC) is a powerful feature that transforms your manually labeled data into a usable policy. Instead of writing rules from scratch, APC analyzes the patterns in your existing data and creates a robust baseline policy for you, saving you effort and time. # Before You Begin: Preparing Your Data The quality of your automated policy is directly dependent on the quality of your input data. For the best results, please ensure your dataset meets the following criteria: * **A Labeled Dataset:** You need a dataset where labels have already been applied. See this [guide](/getting_started/overview/datasets_page_overview) if you haven't done this yet. * **Clear and Consistent Labels:** The labels should be accurate and consistently applied. A policy generated from noisy or incorrect labels will not perform well. If you don't have labels see our [Rapid Labelling](/guides/rapid_data_labelling) feature. * **Sufficient Examples:** The model needs enough examples to learn the patterns for each label. While the minimum should be at least 10, **40 examples for each label** is a good target. # How to Create a Policy from a Dataset Follow these steps to generate your first automated policy. ## Navigate to the Policies Page From the main navigation, head to the Datasets tab. ## Initiate Policy Creation Choose the dataset you want to create the policy from and hit 'Generate Policy'. Apc Data Policy Creation 9 15 2025 Pn ## Name Your Policy This name can be changed later. apc_dialogue_9_15_2025 ## Policy Processing Once your dataset has been submitted for creation, you can return to the 'Policies' tab to see if it has finished. Apc Generation 9 15 2025 Pn Automated Policy Creation time depends on a number of factors including how many Labels and examples you have in your dataset. # Best Practices for High-Quality Policies Keep these tips in mind to ensure your automated policies are accurate and effective. ## Data Volume and Balance are Key A policy's ability to recognize a concept is based on the examples it's shown. If one label has 1,000 examples and another has only 10, the policy will be far less accurate for the label with fewer examples. For best results, try to provide a relatively balanced number of examples across all labels. We recommend a minimum of 10 examples per label with 40 being the sweet spot. Quality is better than quantity. It's more useful to have fewer but diverse representative examples than a large number of bad or repetitive examples. ## Think of It as an Iterative Process Think of your first automated policy as a strong first draft. The best workflows often involve: 1. **Generating** a policy from your data 2. **Reviewing** its performance 3. **Adding** more labeled examples to address any weaknesses 4. **Refining** the policy with the improved dataset. ## Garbage In, Garbage Out The APC process learns directly from your labels. If the source data is inconsistently or incorrectly labeled, the resulting policy will inherit those mistakes. Always start with the cleanest data possible. ## 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. # Handling Sensitive Content: CSAM Source: https://docs.clavata.ai/guides/handling_sensitive_content_csam How Moonbounce detects CSAM through NCMEC hash matching and PhotoDNA perceptual matching, and how to use the matchConfidence field on precheck failures. This page deals with sensitive content, including abuse targeted at children. This banner serves as a content warning before reading on. Glossary of terms * [NCMEC](https://www.missingkids.org/home) = National Center for Missing and Exploited Children - NCMEC works with local and federal agencies in the USA along with other countries when it comes to investigating and reporting instances of CSAM and other abuses towards children. * CSAM = Child Sexual Abuse Material - this represents abuse or exploitation of a minor that is typically sexual in nature. * Hash Database - NCMEC maintains a validated hash database of known CSAM. This database is used by Moonbounce to check if uploaded content presents an exact hash match. * PhotoDNA - a perceptual hashing technology used to detect content that is visually similar to known CSAM, even when the file has been resized, re-encoded, or lightly edited. Unlike an exact hash match, PhotoDNA reports how close a match is. ## How does Moonbounce detect this content? When evaluating image content, Moonbounce checks it against known CSAM using two complementary techniques: 1. **NCMEC exact hash match** - the image's cryptographic hash (md5/sha1) is compared against NCMEC's validated database. An exact match is the highest-confidence signal that the file is a known instance of CSAM. 2. **PhotoDNA perceptual match** - the image is compared perceptually so that near-duplicates and lightly modified copies of known CSAM are also caught. Because this is a similarity measure rather than an exact match, the result is graded by how close the match is. When content matches, you will see a precheck failure in your [API response](/api-reference/get-jobs/get-job-details). file-MACC9A4pVR.png All CSAM detections — whether from an exact hash match or a PhotoDNA perceptual match — are reported with the precheck failure type **`PRECHECK_FAILURE_TYPE_NCMEC`**. This type means "treat this content as CSAM." ## Match confidence Precheck failures include a `matchConfidence` field that tells you *how* the content was identified and how strong the signal is. This lets you tailor your response to the strength of the match. | `matchConfidence` | What it means | | - | - | | `EXACT` | Exact NCMEC hash match. The file is a known instance of CSAM. Highest confidence. | | `HIGH` | PhotoDNA perceptual match in the closest distance band (near-duplicate of known CSAM). | | `MEDIUM` | PhotoDNA perceptual match in the middle distance band (moderate visual similarity). | | `LOW` | PhotoDNA perceptual match in the farthest distance band (loose similarity; review recommended). | | `UNSPECIFIED` | No confidence tier reported. Returned for non-CSAM failures and for legacy responses that predate this field. | ## Suggested handling Every confidence tier indicates a potential CSAM match and should be treated seriously. The following is **guidance, not a mandate** — you know your platform, your legal obligations, and your risk tolerance best, and you should set policy accordingly. * **`EXACT`** is a confirmed match against the NCMEC database. Many platforms choose to block and report this content automatically. * **`HIGH`** is a very close perceptual match. It is reasonable to treat it like `EXACT` and act automatically, depending on your tolerance for false positives. * **`MEDIUM`** and **`LOW`** are progressively looser perceptual matches. These are good candidates to route to a trained human reviewer before taking irreversible action, rather than auto-enforcing. When you do act on a match, the steps below outline a common workflow: 1. Lock the content down! Ensure other users on your platform can't view this content. 2. Head over to NCMEC's [CyberTipline Report](https://report.cybertip.org/) to report the content to NCMEC. 1. When filling out the report be detailed and provide as much information as you can. 3. You will typically need to isolate the content on your system for a period of time in order to securely share the content with NCMEC. 4. From there you should follow guidance and instructions from NCMEC. ## 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. # Components of a policy Source: https://docs.clavata.ai/guides/policy_authoring/components_of_a_policy An overview of what makes up a policy in Moonbounce. # Components In Moonbounce, a Policy defines the guidelines the system follows to analyze and classify content. Policies are fully customizable, written in clear, readable terms, and are used to classify text and image content. Because of this, it’s crucial to understand how to write, read, and manage your Moonbounce Policies effectively. ## Label Labels organize your Policy by grouping related Rules, which helps organize your logic structure. They define where the evaluation process starts and ends to determine if the content meets or violates your guidelines: * If any Rule matches, then the entire Label is considered a match. * A Label can contain unlimited Rules. * The outcome of each Rule evaluation is recorded for detailed review in the API response. When running a Test, the results are visible on the Policy editor screen. ## Rule Rules are the core logical statements in your Policy that guide how the system evaluates content, determining if it violates any of your Policies. Essentially, each Rule sets a condition that content must either pass or fail. Rules are written inside a Label, and if any single Rule within a Label matches, the entire Label is considered a match, meaning that piece of content is flagged based on that Label’s logic. The exact structure of a Rule depends on the Conditions you choose, which define what kind of Signals are needed. The Rule should be grammatically correct based on the chosen Condition and precise enough to target what you're looking for. ## Conditions Moonbounce provides predefined Conditions that are used to create Rules, depending on the specific content you want to detect. There are 4 different types of Conditions within Moonbounce: ### **Connecting Condition** * Connecting Conditions allow you to link various Signals and Signal Lists within your Policy using logical terms—such as NOT, AND, OR, ALL, ANY, and NONE. * They help define how different Rules interact with each other. For example, you can combine statements like: `ANY ("gender") AND ANY ("degrading remarks", "offensive stereotypes", "slurs")` ### **Match Condition** * Match Conditions are where you can specify one or more words or phrases to look for within text. The matches can be exact, fuzzy, or sentiment matches. * Exact Match Conditions identify specific words or phrases in content, ignoring case differences, like `=("cat")` would identify cAt, CAT, and CAt. * Fuzzy Match Conditions detect words or phrases that are similar in meaning or form, including variations like leetspeak, like `~("hate")` will detect “h4t3”. * Exact and Fuzzy Match Conditions are only applicable to text or text-on-image. * The Sentiment Match Condition analyzes the overall sentiment of content, such as identifying threatening or negative language. i.e., `Sentiment("threatening")` will detect “I am going to kill you.” ### **UNLESS Condition** * The UNLESS Condition specifies exceptions to the Rules within a Label of your Policy. These exceptions apply only to that Label, without affecting the overall Policy or other Labels. * The example below indicates that this Label is analyzing the content for attacks about personal circumstances, except when it is deemed to be light trash talk. If detected as light trash talk, this Label will not be flagged. ``` LABEL "Harassment": "MED" { "attacks" [ABOUT] "personal circumstances" UNLESS { "light trash talk" } } ``` *** ## Signal(s) A Signal or Signal List contains the words, phrases, or sentiments to search for within content, represented in “quotation marks.” Every Rule must include at least one Signal, and often Rules will contain multiple Signals grouped together, to form a Signal List. For example, this Signal list will find any mention of the words "dog," "cat," or "pony." This is an example of a Rule with an Exact Match Condition, and works like saying, "Find the words dog OR cat OR pony." ``` =("cat", "dog", "pony") ``` For Rules where you want to detect multiple contexts, use a Signal List with the ANY Condition. This example will tell the system to flag all mentions of any content related to the Signals “racial group”, “gender”, or “race”: ``` ANY( "racial group", "gender", "races" ) ``` Whereas, a simple example of a Signal in a Context Condition is as follows. The Signals here are “misinformation” and “elections”, and the Rule is looking for contexts relating to misinformation about elections: `"misinformation" [ABOUT] "elections"` *** ## Key Features / Benefits * Pre-built templates are available to help you get started, especially if you're new to Policy syntax. * Each Policy must include at least one Label and one Rule, and each Rule must include at least one Signal, ensuring a clear structure for managing content. * Custom names can be assigned to Policies, making them easy to differentiate and organize. * Policies support flexible matching, allowing you to detect exact matches, fuzzy matches, or even analyze sentiment in content. * You can set up conditional logic to handle multiple contexts or exclude specific content using "UNLESS" blocks within a Label. *** ## Example *** file-i40RTdtRPV (1).png *** ## 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. # Introduction to Policies Source: https://docs.clavata.ai/guides/policy_authoring/introduction_to_policies An overview of what policies are and how to approach writing them in Moonbounce. **Using labels instead of policies?** Moonbounce has two experiences, and these docs cover the policy-first one. If your workspace has you crafting **labels** rather than writing policies, you're on the label-first experience — switch to the **label-first** experience using the version selector at the top, or jump to the [Quickstart](/v2/quickstart). In Moonbounce, a Policy defines what content you want to label on your platform. Policies are very flexible and can be used for a number of different scenarios including: detecting harmful content on the platform, providing ratings, returning a taxonomy, and more. This guide will walk you through some general processes to help in creating effective Policies that align with your platform’s specific use cases. ## How to Approach Writing a Policy Writing a Policy in Moonbounce begins with understanding your use case. Here’s how to get started: 1. Start by identifying what content you'll be dealing with, images or text? Is the policy designed to filter content, provide better understanding, or something else? Examples include: * Flagging problematic Usernames * Rating images for user filtration * Returning a taxonomy per image * AI-generated inputs and outputs 2. Consider what content should get a label vs. what content shouldn't get a label. This is important for crafting your policy but also creating your dataset for testing. 3. Write your policy and test! Moonbounce makes it easy to test your policy as you write using a dataset you've curated. Having a well-rounded dataset with good examples of things you want your policy to identify and things you don't want your policy to identify is very important. Writing, testing, deploying, and monitoring your Policy is an iterative process. Once your Policies are deployed, periodically review flagged content and update your Policies to address emerging issues. ## Key Considerations When Creating Your Policy When writing Policies for your platform, it's important to address the different types of content and contexts where violations may occur. Here are a few things to keep in mind while creating your Policies. ### Content-Type While Policies can handle both text and image content, different types or sources of content on your platform may require varying levels of oversight, which could benefit from distinct Policies tailored to those specific needs. Examples: * Usernames are typically short and have to be written in broken language in order to fit the short character length * Images are filled with detail and it's important to hone in on which aspects you want the model to focus on * Detecting AI inputs and outputs requires determining in what ways could an AI misbehave that you'd want your policy to detect ### Areas of your Platform It's always a good idea to start with a well-rounded dataset that has examples you want your policy to apply labels to and ones you don't. From there, start simple when building out your labels and rules to see what works and what doesn't. ### Exceptions Moonbounce’s Policies allow for exceptions when necessary. When writing Policies, think about where exceptions should be applied. Example: * If your platform is related to education, your Policy may flag sexual vulgarity, but you may want to have an exception for sexual terms used in a scientific or medical context. *** ## 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. # Label Copilot Source: https://docs.clavata.ai/guides/policy_authoring/label_copilot Generate and refine label syntax through a guided, AI-powered workflow. The **Label Copilot** (internally codenamed LUNA — Label Understanding & Notation Assistant) is an AI-powered tool that turns a plain-language label description into working policy syntax. Instead of writing DSL by hand, the copilot guides you through a step-by-step loop of generation, evaluation, signal review, and refinement until your label is performing the way you intend. The label copilot is currently in beta and is actively being improved. Text content is supported today; image support is coming soon. # How the Label Copilot Works The copilot follows a four-step iterative loop: 1. **Define Your Label** — provide a label name and plain-language description; the copilot generates the syntax 2. **Evaluate Content** — test the generated label against a dataset of real examples 3. **Review Signals** — for any misclassified items, indicate which signals are firing correctly or incorrectly 4. **Clarify & Refine** — answer the copilot's clarifying questions to drive a refined, more accurate version of the syntax You can repeat the loop as many times as needed. When you're satisfied with the results, insert the label directly from within the copilot. # Step 1: Define Your Label The first step is telling the copilot what you want the label to detect. Two fields are required to generate: * **Label name** — a short, descriptive name for the label (e.g., `hate_speech`, `spam_promotion`) * **Content modality** — select **Text** (image support is coming soon) You can also provide a **Description** — a natural-language explanation of what the label should and should not apply to. This field is optional, but the more specific you are, the better the initial result will be. Once ready, click **Generate**. The syntax will stream into the editor: here's an example of what a completed generation looks like. LUNA_define_label_filled # Step 2: Evaluate Content With syntax generated, the next step is testing it against real content. You can add your label without testing by clicking **Insert label selection**. ## Selecting a Dataset Choose an existing dataset or create a new one. Your dataset should include a mix of content that **should** trigger the label and content that **should not**. A minimum of **3 positive** (Label) and **3 negative** (Not label) examples is required before running evaluation. If you are using the label copilot in an existing policy it will select your current dataset. ## Labeling Rows For each row in the dataset, mark it with one of the following: | Action | Keyboard shortcut | | - | - | | Label (positive example) | `→` | | Not label (negative example) | `←` | | Skip | `s` | | Navigate up/down | `↑` / `↓` | | Focused view | `spacebar` | LUNA_content_labelled ## Running Evaluation Once you have enough labeled examples, click **Run evaluation**. Moonbounce tests the generated syntax against your dataset and shows you which rows were correctly and incorrectly classified. * If **all reviewed items are correctly classified**, you can proceed directly to inserting the label * If there are **misclassifications**, the copilot may automatically run an optimization pass (auto-patch) — if it finds deterministic improvements, it removes redundant rules and re-runs evaluation silently; a toast notification confirms any rules that were removed LUNA_content_label_review # Step 3: Review Signals This step appears when misclassifications remain after evaluation. Signals are the individual rules that contribute to a label match. For each misclassified item, the copilot shows you the signals that fired and asks you to mark each one: | Value | Meaning | | - | - | | **True** | This signal is correctly firing for this item | | **False** | This signal should not have fired for this item | | **Unknown** | You're not sure | This feedback tells the copilot precisely which parts of the syntax are working and which are not, giving it the information it needs to produce a better refinement. LUNA_review_signals # Step 4: Clarify & Refine After signal review, the copilot generates clarifying questions based on the feedback it received. Each question is aimed at resolving ambiguity in the label definition — for example, distinguishing borderline cases or tightening the scope. For each question, either select a suggested answer or type a custom one, then click **Submit**. The copilot refines the DSL and returns you to the **Define Label** step with updated syntax already in the editor. From there, you can run another round of evaluation or insert the label if you're satisfied with the result. LUNA_review_questions # Inserting or Refining Your Label At the end of a loop, you have two options: * **Insert label selection** — adds the label to your policy. Use this when the evaluation results meet your expectations. * **Evaluate Content** — returns you to Step 2 to run another round of evaluation and refinement. Use this when you want to keep improving the label before committing it. LUNA_second_evaluation # Tips for Best Results * **Be specific in your description.** Vague descriptions produce vague syntax. Include examples of what the label should and should not apply to, edge cases, and context about your platform. * **Use a representative dataset.** The evaluation step is only as useful as the examples in it. Include a realistic mix of positive and negative cases, including borderline examples. * **Expect iteration.** One or two refinement rounds is normal. The label copilot is designed to improve with each pass of feedback. ## 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. # Comparing Policies Source: https://docs.clavata.ai/guides/policy_authoring/policy_comparison A guide to using the Policy Compare feature to visualize differences in policy logic and performance metrics. The Policy Compare feature provides a detailed, side-by-side view that highlights the exact differences between any two policies. The view is designed to feel familiar to anyone who has used a code comparison or "diff" tool, making it easy to track changes, review updates, and understand the impact of policy evolution. You'll find this tool especially useful for: * **Version Control:** Seeing exactly what changed between an older version of a policy and a new one. * **Reviewing Updates:** Checking a new "draft" policy against the current "production" policy before deploying it. * **Auditing Automated Policies:** Comparing a policy generated by our Automated Policy Creation (APC) feature against a manually refined version. * **Performance Analysis:** Comparing key metrics between two policy versions using the same dataset to see the real-world impact of your changes. *** ## How to Compare Two Policies Comparing policies is a straightforward process. 1. From the **Policies** tab, select a policy and navigate to the **Compare** tab. 2. The **Origin Policy** (left side) will default to your 'Current' active version. 3. The **Modified Policy** (right side) will default to the newest version to compare against. 4. You can change either policy version using the dropdown menus. Policy Comparison Metrics 10 8 2025 Pn *** ## Understanding the Comparison View The comparison view is designed to make differences immediately obvious. It shows how the **Modified Policy** has changed relative to the **Origin Policy**, both in its logic and its performance. Policy Comparison Zoom 10 8 2025 Pn ### Comparing Performance Metrics At the top of the view, you'll see a side-by-side comparison of key performance metrics. This table uses a **single dataset** to run both policy versions, giving you an apples-to-apples view of their effectiveness. Use this to quantify the impact of your changes and ensure a new version performs as expected before you deploy it. Policy Comparison Zoom Metrics 10 8 2025 Pn Any rows highlighted in **yellow** indicate a label present in one policy but not in another. ### Reading the Policy Diff For policy diff, the view is split into two panels for comparing the policy logic: * **Left Panel (Origin Policy):** This is your reference policy. Think of it as the original or "source of truth" for the comparison. * **Right Panel (Modified Policy):** This panel shows the policy you are comparing against the origin. All changes are highlighted here. The color-coded highlighting tells you exactly what has changed: * **Red Highlight:** Shows lines that exist in the **Origin Policy** but were **removed** from the **Modified Policy**. * **Green Highlight:** Shows lines that were **added** to the **Modified Policy** and do not exist in the **Origin Policy**. * **No Highlight:** Indicates lines that are identical in both policies, providing context for the changes around them. ### Reading the Metrics Diff The metrics diff view uses a table to compare the performance outcomes of both policies against the same dataset. * **Top Metrics (Origin Policy):** The metrics here represent the outcome of your **Origin Policy's** metrics against the dataset. * **Bottom Metrics (Modified Policy):** The metrics here represent the outcome of your **Modified Policy's** metrics against the dataset. Bold and highlighted metrics give you a sense of where to focus. * **Bolded Metrics:** Indicates the higher-performing metric in a direct comparison, making it easy to see which policy performed better for a specific measure. * **Yellow Highlighted Labels:** Indicates that a label present in either your **Origin Policy** or **Modified Policy** but not in the other. This helps you spot newly tracked or removed labels. *** ## Best Practices for Policy Comparison ### Establish a Clear Base When initiating a comparison, always start by selecting your "source of truth" as the **Origin Policy**. For example, if you're reviewing changes for a new version, select the current, active policy as the base and the new draft as the policy to compare against it. This makes the additions and removals intuitive to read. ### Review the Metric Impact A change in policy logic might look correct on its own, but it could have unintended consequences on performance. Always check the metrics comparison to validate that your changes produce the desired outcome—whether that's improving precision, increasing recall, or maintaining overall performance. ### Use as a Pre-Deployment Check Incorporate the compare feature into your workflow as a final review step. Before you replace an active policy, run a comparison against the new version to get a clear, final summary of the changes you're about to deploy. This can help you catch unintended alterations and confirm that all expected changes are present. *** ## 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. # Policy Writing 101 Source: https://docs.clavata.ai/guides/policy_authoring/policy_writing_101 A 101 course on writing policies in Moonbounce which includes diving into the structures of a policy. Effective policy writing in Moonbounce is crucial for accurate labelling of content. This guide provides best practices for crafting clear, maintainable, and efficient policies using Moonbounce's syntax and features. *** # Understanding Policy Structure A Moonbounce policy comprises **Labels** containing one or more **Rules**. Each Rule uses **Conditions** and **Signals** to define what content should be flagged. ## Labels * **Definition**: Organize related Rules under a common category. * **Syntax**: ``` LABEL "Label Name": "Risk Level" { // Rules go here } ``` ## Rules * **Definition**: Logical statements that evaluate content against specified Conditions and Signals. * **Example**: ``` "dogs in a park" ``` ### Priority Priority allows you to specify hierarchies when it comes to your Labels. This allows you to say if there are two labels that come back as true then prefer one over the other. ``` PRIORITY: "Mature" > "R" > "PG-13" > "PG" ``` This tells the system that if the Mature label comes as true along with the R label, then only return Mature from the system. This is useful if you plan on doing API response logic. *** # Writing Efficient Rules ## Simple Inclusion vs. Logical Operators **Example 1**: ``` "dogs in a park" ``` **Example 2**: ``` ANY("dogs") AND ANY("park") ``` Both Rules aim to flag content mentioning "dogs" in relation to a "park". ## Handling Multiple Contexts **Example 1:** ``` "dogs in a park" "dogs in a city" "dogs in a field" ``` **Example 2**: ``` ANY("dogs") AND ANY("park", "city", "field") ``` Other than readability or organization, there is no difference in the two "dogs" examples. They are both functionally looking for the same thing. Context and personal workflows can dictate how you write different policies. *** # Policy Pitfalls ## Vagueness The enemy of a good policy is not having the AI understand what you mean. Much like a human, if you were to say "there is a deli down the street", a human might ask: * Which direction? * How far? * How long will it take me? Think of this same logic when writing policy. You may want to flag content if it contains **Vulgarity** so you write something simple like the below thinking your bases are covered. ``` "vulgarity" ``` **You** know what the definition of vulgarity is but does the AI? Think of what "vulgarity" might mean to a random human. Things like "damn" or "hell" could be considered vulgarity to some. Consider refining your definition so the model has a better understanding. You could try any of the below: ``` "vulgarity not acceptable in the presence of children" "is the vulgarity something that would be found in a pg-13 movie?" "common terms considered vulgar in all countries" ``` ## Contradictory Statements Contradictory statements can be just as harmful for AI as they can be for humans when it comes to understanding. Things like below cause your brain to pause and the same thing can happen with AI. * "Shattered glass still whole" * "bloody wound with no blood" * "Drenched but completely dry" Avoid contradictory statements whenever you can as they will cause confusion both with the AI and with anyone else reading your policy. ## Placing in the wrong place An easy mistake to make is placing your braces in the wrong locations when using UNLESS statements. These statements allow you to carve out exceptions for your policy. Want to label discussions of sports but not when it comes to **Baseball**? By adding it to an UNLESS block you can. ``` LABEL "Sports": { "discussion about sports" UNLESS { "baseball" } } ``` The above example is considering the UNLESS statement as part of the overall "Sports" label. If someone were to say "basketball is the best" that would come back as true since it is a discussion of sports but isn't about baseball. However, if they were to say "baseball is the best" that would come back as false since it is a discussion about sports but baseball was part of the discussion. ``` LABEL "Sports": { "discussion about sports" } UNLESS { "baseball" } LABEL "Drinking": { "drinking beer" } ``` The above example works differently than the previous one. Since they are outside of the label then the UNLESS is applied to the entire policy. For example, if someone said "let's go drink some beer at the baseball game" this would come back as false. Even though the text would normally be marked as true by the "Drinking" label, since UNLESS Baseball is applied to the entire policy, it counts **anything** mentioning baseball to come back as false. There is no right or wrong answer for how to use an UNLESS statement. It all depends on what you are trying to achieve. *** ## Best Practices * **Clarity**: Write Rules that are easy to understand. * **Maintainability**: Use concise structures to simplify updates. * **Testing**: Regularly test Policies to ensure accuracy. * **Documentation**: Comment complex Rules for future reference. *** ## 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. # Refining Your Policy Source: https://docs.clavata.ai/guides/policy_authoring/refining_policies_after_testing A guide on how to refine your policy using the test results. In Moonbounce, a policy defines the guidelines the system follows to analyze and classify content. Policies are customizable, written in clear, human-readable terms, and designed to classify different content types. After creating a Policy, it’s crucial to test it and then refine it to ensure the AI accurately flags and analyzes content based on your platform’s needs. This is an ongoing process that allows you to make adjustments to ensure your Policies evolve with the needs of your platform. Below are key considerations for refining your Policy. ## Align Results to a Policy ### Understand Which Label and Rule Flagged the Content When a Policy flagged a piece of content, the test results will indicate which Label of your Policy flagged it. * Locate the Label in your Policy to narrow down what caused the false positive. * Investigate further to determine which Rule triggered the flag. * This helps ensure you’re refining the corresponding Rule(s) and reducing errors efficiently. If content that you expected to be flagged by your Policy was not detected by any Section, it is considered a False Negative. In this case, there is likely not a Rule in place that captures the intended context. ## Refine your Policy ### Address False Positives False positives occur when False content is incorrectly flagged as True. * If a Rule is too broadly written it may over label content. * For example, a Rule targeting general vulgar language might flag mild terms like “crap”, when your intention is to flag just explicit vulgarity. * Amend Rules to target more specific content, or add Conditions to hone it further. * For example, specifying the level of vulgarity or content you want to target, or adding Conditions to omit certain contexts that you deem appropriate. ### Address False Negatives False negatives happen when content you wanted labelled is missed by the AI. * This can be because the Rules are too narrowly targeting content and are missing grey-area or adjacent contexts. In this case, broadening the Rules’ scope or adding more Rules to your Policy will help ensure the intended contexts are captured in your Policy. * For example, a Rule might target extreme language but miss subtler inappropriate phrases. In this case, broadening the context of your Rule to include slang or casual vulgarity may be a good solution. * False Negatives can also occur when there simply is not yet a Rule in place that targets the specific contexts. * For example, there may be an emerging trend on your platform that was not existent when your Policy was last updated, and now requires Rules to address it. ### Experiment with Rule Types Some contexts can be addressed through different variations of Rule types, so if you are having trouble with a Rule not flagging the expected content, you can experiment with different Rule types: * Start with the Connecting Conditions like “ANY” and “ALL” to broadly capture multiple signals. These Connecting Conditions offer strong versatility in addressing content issues. * For example, use "ALL" when multiple conditions need to be met, and/or use "ANY" when only one condition needs to be met. * Consider using Context Conditions to gain more granular control over how Signals are detected and flagged. These are great for situational contexts. * Try Fuzzy Match, which is useful for flagging subversions of certain words. * Test out Exact Match if you only want specific terms flagged. ### Ensure Correct Labeling and Section Syntax in Tests The dataset labels directly correspond with the Policy’s Label or Section names, which determine the test results. * Verify that your Policy's Section/Label names align with your User Labels. * Your User Labels can be updated in the test result section by clicking on them, or you can update your Policy’s Section names. * However, once your Policy is deployed it is recommended not to update the Section/Label names as these may correspond with logic in the API response. Instead, update your dataset’s User Labels to match your Section names. ## Run Another Test ### Run Targeted and Comprehensive Tests After your initial test and Policy amendments, it is important to run further tests to ensure the changes made do not adversely impact the overall accuracy of your Policy. * You can run a Test on specific lines of content to ensure the Rule edits flag the intended material. * Once all issues are addressed, re-run the test on the entirety of your dataset to re-evaluate overall performance and ensure no gaps in detection or unintended false positives remain. ## Iterate ### Continuous Experimentation and Improvement Policy refinement is an ongoing process, and should evolve with your online environment. * Experiment with different Rule types and configurations. * Continuously monitor and refine to improve performance. * Reach out to Moonbounce if you would like to discuss further how we can support your unique platform needs. ## 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. # Token multiplier Source: https://docs.clavata.ai/guides/policy_authoring/token_multiplier Understanding the token multiplier and how it affects your usage costs The token multiplier reflects a policy version's complexity and impacts the cost of running evaluations. ## How is it calculated? The token multiplier is automatically calculated based on the complexity of a policy version, primarily determined by the number of signals present. More complex versions with multiple signals and sophisticated logic will have higher multipliers. ## What is the impact? The token multiplier directly affects your usage costs: * **Higher multiplier** = more tokens consumed per evaluation * **Lower multiplier** = fewer tokens consumed per evaluation For example, a policy with a 2.5x multiplier will consume 2.5 times more tokens than a baseline policy (1x multiplier) when processing the same content. ## Where do I find it? The token multiplier is displayed alongside version details in the version tab to help you understand the cost implications of running evaluations against a given policy version. ## 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. # Rapid Data Labelling Source: https://docs.clavata.ai/guides/rapid_data_labelling A how-to guide on Rapid Data Labelling. Rapid Data Labelling is a feature designed to streamline your workflow by letting you apply a **single label** to many data points in quick succession. You can use this feature on a dataset with no labels or to update an existing set of labels. The rapid-labeling interface allows you to focus on applying one label at a time using your keyboard's arrow keys. This focused approach is often the most efficient and accurate way to process large volumes of data. # Overview To begin, you will need an existing dataset. If you haven't created one yet, you can follow this [guide](/getting_started/overview/datasets_page_overview). ## Select the data to label ### Data Selection You can select any number of rows in your dataset to begin labelling. This can be all the data in your dataset or a specific subset. Rapid Data Labelling works the same if you select all your data or only a few rows. Rapid Data Labelling Selection 9 4 2025 Pn ### Choosing Your Label After selecting your data, choose the label you wish to apply. If your dataset already has labels, you can select one from the dropdown menu. If you're starting fresh, you can create a new label here. Rapid Data Labelling Label Selection 9 4 2025 Pn ### Labelling Data Once you've chosen your label and clicked "Continue," you will enter the labelling view. Use your keyboard to navigate and apply labels. **Key Controls:** * **Navigate:** Use the `↑` and `↓` arrow keys to move between data rows. * **Apply Label:** Press the `→` arrow key. The item will be highlighted in **green**. * **Do Not Apply Label / Remove Label:** Press the `←` arrow key. The item will be highlighted in **purple**. For longer text entries (e.g., over 400 characters), you may need to scroll within the content box to view the entire item. Rapid Data Labelling Gif 9 4 2025 3 Gi ### Finalizing Changes Your changes are saved automatically in the background as you work. When you are finished with your session, it is still a good practice to click **Done** to exit the view. You can then start a new session by selecting the same data to apply a different label, or select a new set of rows. # Best Practices & Tips Here are a few recommendations to help you get the most out of Rapid Data Labelling, especially when working with large datasets or as part of a team. ### Labelling Large Datasets The Rapid Labelling view treats a label as either **present** or **absent** on a piece of data; there is no intermediate "unlabeled" or "skipped" state for the label you are currently applying. Because of this, the system doesn't track your overall progress through a large selection. For datasets with thousands of rows, we recommend labelling in manageable batches (e.g., a few hundred rows at a time). This makes it easy to remember where you left off if you need to take a break. ### Collaborative Labelling (Working in a Team) Multiple users can label the same dataset simultaneously, which is great for team productivity. To ensure no work is accidentally overwritten, it's important for team members to coordinate. The system operates on a **"last write wins"** basis. If two users apply a label to the same row at the same time, the final action to be saved will be the one that is kept. To avoid this, we recommend that team members select and work on **distinct sets of rows**. For example, one user can take rows 1-500, and another can take rows 501-1000. ## 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. # Understanding Test Metrics Source: https://docs.clavata.ai/guides/understanding_tests An overview of the metrics Moonbounce returns after you've run a test. Testing in Moonbounce lets you safely validate Policies before applying them to live content analysis. Use your own labeled test datasets for the most relevant results, or choose from Moonbounce’s available datasets. While images and text must be tested separately, both can be evaluated under the same Policy. Labeled datasets improve testing by providing key metrics like accuracy, precision, recall, and false positive/negative rates. They also help identify mismatches between your labels and AI-detected content, highlighting areas where your Policy may need adjustments for better coverage. # Running Tests Running tests should be a normal part of policy creation and updating. Moonbounce provides a number of metrics to help you understand how well your policy is performing against a dataset. ## Status ### **True Positive/Negative** * **True Positive** is when the system results match all of the labels within the **User label** column. * **True Negative** is when the system and **User label** are returned as blank meaning the row was not supposed to be caught by the policy. ### **False Positive/Negative** * **False Positive** happens when the **User label** is blank and the system returns some result for the row. This indicates the row was not supposed to be caught by the policy but was. * **False Negative** happens when the **User label** is not blank but the system did not detect a label from the policy. This indicates the row was supposed to be caught by the policy but wasn't. file-piFgleHwx6.png *** # Score Confidence scores are returned from the model from 1-99. This demonstrates how confident the model was in its decision. file-Jj2GznEoYI.png In the above example the model had a confidence score of 99 meaning it was very confident that row was supposed to receive the 'Drugs' label. # Testing Metrics Overview Here you will get an overview of Accuracy, Precision, Recall, False Negative Rate, and False Positive Rate. Here, you will be able to see how these are calculated and what they mean for your policy and results. ## F1 Score The **F1 score** is a machine learning metric that provides a single value to assess the accuracy of a classification model, especially when dealing with imbalanced datasets. It's calculated as the **harmonic mean of** [**Precision**](#Precision-qg0yv) **and** [**Recall**](#Recall-3N-Q6). The F1 score effectively **balances both False Positives and False Negatives**, making it a more robust metric than just Precision or Recall alone, especially in situations where missing positive cases is as critical as incorrectly identifying negative ones, or vice versa. The F1 score ranges from **0% (completely inaccurate)** to **100% (perfectly accurate)**. A higher F1 score indicates a better-performing model. It's calculated by * 2 x (Precision x Recall) / (Precision + Recall) ## Accuracy Accuracy measures how often Moonbounce’s assessment matches the intended outcome. It ranges from **0% (completely inaccurate) to 100% (perfectly accurate)**. It’s calculated by dividing the number of matches between Moonbounce’s results and your labels by the total dataset size. * **(True Positive + True Negative) / All Content** Accuracy in the **All metrics** section for the **overall** is an average from the label derived metrics. ## Precision * **Precision** is a measure of accuracy in classification. It calculates the proportion of correctly identified positive cases out of all cases predicted as positive. In simple terms, it tells you how often a positive prediction is actually correct. * **Precision** measures how well your policy correctly flags labelled content. A high precision score means fewer false positives, and more true positives which are things you want labels to be applied to. * For example, if the AI labels 100 items and 90 are correct (true positives) while 10 are incorrect (false positives), the precision is **90%**—meaning 90% of flagged content was correctly identified. ## Recall * **Recall** measures how well a system identifies all actual positive cases. It calculates the proportion of correctly identified positives out of all true positives that exist. In simple terms, it tells you how often the system catches what it’s supposed to find. * **Recall** measures how well your policy flags all the content you wanted flagged from your dataset. A high recall means fewer false negatives, ensuring most harmful content is flagged. * For example, if there are 100 items that should have labels and the AI correctly flags 80 but misses 20, recall is **80%**—meaning 80% of harmful content was identified. Moonbounce offers a structure to achieve both high Precision and Recall but at the upper levels there is a trade-off between correctly labelling content at a cost of letting content that should be labelled go unlabelled vs. labelling everything that should at the cost of labelling some content that shouldn't be. ## False Negative * A **False Negative** happens when the AI misses something that should have been labelled. Having a low percentage rate here is a good thing. * The measurement is done by taking False Negatives/All the content in the dataset. ## False Positive * A **False Positive** occurs when the AI incorrectly labels content. Having a low percentage rate here is a good thing. * The measurement is done by taking False Positive/All the content in the dataset. Note! Metrics of F1 Score, Accuracy, Precision, Recall, False Neg, and False Pos represent the selected label. So if you are refining your "Dog" label, the metrics will represent how your current "Dog" label is doing against your dataset. Toggle to 'All metrics' to see how all labels are performing. *** # Condition information After running a test, Moonbounce will provide information in the editor on how often a specific Condition was triggered. You can safely assume that a Condition with a high hit count is more impactful to your testing metrics than one with a low hit count. file-6e5FaxrbyX.png If a condition does not have a hit count, then that means that condition was not triggered by anything in your dataset. ## Hits Hits show how often a condition is coming back as **True**. This will demonstrate how much content an assertion is finding in your given dataset. ## Precision Precision shows how good your assertion is at finding the correct content. As above, it measures how good a condition is at finding labelled content. A higher percentage here is a positive and lower percentage means the condition should be changed or an UNLESS statement may be needed. ## Negative Predictive Value (NPV) The purpose of an **UNLESS** statement is to help exclude content from an assertion. An example of that is if you are attempting to remove the sale or discussion of drugs in your policy you may add something like 'legal drugs' to your **UNLESS** statement to ensure that legal drugs can still be discussed. NPV attempts to measure the effectiveness of this by ensuring it is removing non-labelled data. A high NPV score means that it is working well while a low NPV score means that content you would want labelled is being skipped by NPV. ## Confidence Each assertion in your policy comes with a confidence score from 0-1. By clicking a row in your results table, you can see the confidence the model had for that specific assertion. This will help you understand whether the model felt highly confident it was right or more on the line. Screenshot2025-08-07at4.01.04PM.png # Downloading your results Click the download button to generate a csv with a full breakdown of your data. *** ## 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. # API Documentation Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/api_documents_and_sdks Overview of available integration paths ## Accessing the Moonbounce API Documentation Our comprehensive API documentation is available in the [API Reference](/api-reference) section. This resource provides detailed information on all available endpoints, including: * **Job Management**: Create, retrieve, and manage jobs. The documentation includes request/response schemas, authentication methods, and usage examples to assist in integrating Moonbounce's capabilities into your applications. ## Job results retention Job and batch job records (including evaluation results from [Get job details](/api-reference/get-jobs/get-job-details), [List jobs](/api-reference/get-jobs/list-jobs), and [Get batch jobs](/api-reference/batch-processing/get-batch-jobs)) are guaranteed to remain queryable via the API for *at least 30 days*. Jobs may remain available longer, but you should not rely on that. After a job is archived, [Get job details](/api-reference/get-jobs/get-job-details) (by job UUID) and [Get batch jobs](/api-reference/batch-processing/get-batch-jobs) (by batch job ID) respond with HTTP `404 Not Found`. The API does not distinguish an archived job from an unknown or invalid ID. [List jobs](/api-reference/get-jobs/list-jobs) and [Get batch jobs](/api-reference/batch-processing/get-batch-jobs) only return jobs that are still within the active retention window. If you need access to an archived job, contact [support@moonbounce.io](mailto:support@moonbounce.io). Recovery may be possible on request. ## 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. # API Key Management Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/api_key_management Create, manage, and revoke API keys for programmatic access to Moonbounce ## Overview Admins can create, view, and revoke API keys directly from the Moonbounce dashboard. API keys provide programmatic access to the Moonbounce API for your integrations and automated workflows. To manage API keys, navigate to **Account Settings → API Keys**. Only users with the **Admin** role can access and manage API keys. ## Creating an API Key 1. Go to **Account Settings → API Keys** and click **Create API Key**. 2. Enter a descriptive **name** for the key (e.g. "Production API Key"). 3. Choose an **expiration** for how long the key should remain valid: * 30 days * 90 days * 180 days * 365 days * No expiration 4. Click **Create**. 5. **Copy your API key immediately.** The full key is only shown once and cannot be retrieved later. ## Using Your API Key Include your API key in the request headers when calling the Moonbounce API: ```bash theme={null} curl -H "Authorization: Bearer YOUR_API_KEY" \ https://api.clavata.ai/v1/jobs ``` For SDK usage, refer to the [Python SDK](/integrations_and_developer_tools/api-docs-sdks/python_sdk), [JavaScript/TypeScript SDK](/integrations_and_developer_tools/api-docs-sdks/javascript_typescript_sdk), or [Go SDK](/integrations_and_developer_tools/api-docs-sdks/go_sdk) documentation. ## Managing Existing Keys The API Keys page displays all keys for your account, including: | Column | Description | | - | - | | **Name** | The label you assigned when creating the key | | **Owner** | The email of the user who created the key | | **Status** | Enabled, Disabled, or Revoked | | **Created** | When the key was generated | | **Expires** | When the key will expire (or **No expiration**), color-coded by urgency | | **Signature** | The last 6 characters of the key for identification | ### Key Actions From the actions menu on each key, you can: * **Disable** — Temporarily deactivate a key. It can be re-enabled later. * **Enable** — Reactivate a previously disabled key. * **Revoke** — Permanently invalidate a key. This action cannot be undone. ## Best Practices * **Rotate keys regularly.** Create a new key before revoking an old one to avoid downtime. * **Use descriptive names.** Name keys after their intended use (e.g. "CI Pipeline", "Staging Environment") so you can easily identify them later. * **Revoke unused keys.** If a key is no longer needed, revoke it promptly to reduce your attack surface. * **Never share keys in plaintext.** Store API keys in environment variables or a secrets manager, not in source code. # Batch Processing Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/batch_processing Learn how to process large datasets using Moonbounce's Batch Processing feature. For technical docs see the [Batch Processing API](/api-reference/batch-processing). # How it Works Using the Batch API is a three-step process. You must follow these steps in order to successfully process your data. 1. **Create a Batch Job:** First, you make an API request to create a new job. This initial call will return a `job_id` and a secure, pre-signed URL that you will use to upload your data. 2. **Upload Your Input File:** Next, you will upload your data file to the pre-signed URL provided in Step 1. The file must be in the specified CSV format. See below for details. The job will automatically start processing shortly after the upload is complete. 3. **Check Job Status:** To monitor the progress of your job, you will need to periodically poll the 'Get Batch Job' endpoint using your `job_id`. ## Create a Batch Job Creating a Batch Job is very simple. Sending in a request will grant you a URL to upload your content to. The URL is only good for **4-hours** so be sure to upload your content before that expires. If you miss the window then you will need to create another job. ## Upload Your Input File Currently Moonbounce supports uploading your content via a CSV. Each Batch Job can only take one file at a time. Uploading more than one CSV will overwrite the oldest. ### Text Text processing requires the below: * ref\_id - this could be a numbered list, a content guid, or any other identifier so long as it is unique in the row. * type - this should be set to 'text' * content - should contain the content you wish to have evaluated ``` ref_id, type, content 1, text, hello 2, text, nice to meet you 3, text, have a great day! ``` [Download text example](/public/csvs/batch_input_text.csv) ### Image Image processing requires the below: * ref\_id - this could be a numbered list, a content guid, or any other identifier so long as it is unique in the row. * type - this should be set to 'image\_url' * content - should contain the content you wish to have evaluated ``` ref_id, type, content 568695, image_url, https://image.com/1234_fuzzy_bunny.png 568696, image_url, https://image.com/5678_fluffy_cat.png 568727, image_url, https://image.com/0912_funny_dog.png ``` [Download image example](/public/csvs/batch_input_images.csv) Ensure your image URLs are publicly accessible! ## Check Job Status You will need to check on your job status periodically. **When the job status returns** `BATCH_JOB_STATE_COMPLETED`, **the response from the API call will also contain an** `output_url` **to download your results.** This URL is valid for 4-hours. Each pull of Batch Job Status will return a new URL for completed jobs. Each of these are good for 4-hours. Batch job records and API responses are subject to [job results retention](/integrations_and_developer_tools/api-docs-sdks/api_documents_and_sdks#job-results-retention) (*at least 30 days*; archived jobs return 404; contact support to request recovery). ### Stages Your job will pass through several stages. You can monitor these by polling [Get batch jobs](/api-reference/batch-processing/get-batch-jobs). * `BATCH_JOB_STATE_QUEUED` - Your job is in the queue waiting for processing. * `BATCH_JOB_STATE_PREPROCESSING` - Your job is being prepared and validated. * `BATCH_JOB_STATE_SUBMITTED` - Your job has been submitted to the AI for evaluation. * `BATCH_JOB_STATE_POSTPROCESSING` - The results are being compiled. * `BATCH_JOB_STATE_COMPLETED` - Your job is complete and the results are ready to be downloaded. * `BATCH_JOB_STATE_ERROR` - Your job has encountered an error. ## Output File The results CSV contains the following columns: | Column | Description | | - | - | | `ref_id` | The reference ID you provided in the input file. | | `type` | The content type: `text` or `image_url`. | | `labels` | A JSON array of all evaluated labels and their scores (see below). Empty if evaluation failed. | | `content` | The original content that was evaluated. | | `error` | An error message if the item failed processing. Empty on success. | ### Labels format The `labels` column contains a JSON array of objects, each with a `label` name and a `score` between 0 and 1: ```json theme={null} [ {"label": "Civil/Baseline", "score": 0.988}, {"label": "Casual Dating", "score": 0.976}, {"label": "Unstated/Exploring", "score": 0.964} ] ``` Every label defined in your policy is included with its score, regardless of whether it matched. Use the scores to determine which labels apply to each piece of content. ### Performance Expectations A job can take 24-48 hours to complete. Processing time is not guaranteed and can vary significantly based on several factors: * **Job Size:** Larger jobs will naturally take longer to complete. * **Content Type:** Image processing is more resource-intensive and will take longer than text processing. * **Policy Complexity:** Jobs run against policies with a higher number of assertions or more complex logic will require more processing time. * **System Queue:** There may be a delay before your job begins processing as it waits in our internal queue. ## 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. # GO SDK Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/go_sdk Install and use the Moonbounce Go SDK. ## **GO** * **Package**: `github.com/clavataai/gosdk` * **Installation**: ``` go get github.com/clavataai/gosdk ``` * **Repository:** Available on [pkg.go.dev](https://pkg.go.dev/github.com/clavataai/gosdk). The Go SDK enables developers to interact with Moonbounce's API using Go, simplifying tasks such as job submission and policy management. ## Labels v2 Evaluation Labels v2 evaluation is currently beta and exposed through the beta namespace: ```go theme={null} resp, err := client.Beta().EvaluateLabels(ctx, &clavata.EvaluateLabelsRequest{ Content: clavata.NewTextContent("Text to evaluate"), LabelVersionIDs: []string{"label-version-id-1", "label-version-id-2"}, Threshold: 0.5, }) ``` Request and response type names remain stable, including `EvaluateLabelsRequest` and `EvaluateLabelsResponse`. ## 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. # Javascript/Typescript SDK Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/javascript_typescript_sdk Install and use the Moonbounce JavaScript/TypeScript SDK. ## JavaScript / TypeScript * **Package**: `@clavata/sdk` * **Installation**: ``` npm install @clavata/sdk ``` * **Repository**: Available on [npm](https://www.npmjs.com/package/@clavata/sdk). This SDK provides TypeScript definitions and is suitable for Node.js and browser environments, facilitating seamless integration into JavaScript applications. ## Labels v2 Evaluation Labels v2 evaluation is currently beta and exposed through the beta namespace: ```ts theme={null} const response = await client.beta.evaluateLabels({ content: { content: { value: "Text to evaluate", $case: "text" }, contentType: "text", }, labelVersionIds: ["label-version-id-1", "label-version-id-2"], threshold: 0.5, }); ``` Request and response type names remain stable, including `EvaluateLabelsRequest` and `EvaluateLabelsResponse`. ## 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. # Python SDK Source: https://docs.clavata.ai/integrations_and_developer_tools/api-docs-sdks/python_sdk Install and use the Moonbounce Python SDK. ## **Python** * **Package**: `clavata-sdk` * **Installation**: ``` pip install clavata-sdk ``` * **Repository**: Available on [PyPI](https://pypi.org/project/clavata-sdk/). The Python SDK enables developers to interact with Moonbounce's API using Pythonic constructs, simplifying tasks such as job submission and policy management. ## Labels v2 Evaluation Labels v2 evaluation is currently beta and exposed through the beta namespace: ```python theme={null} response = await client.beta.evaluate_labels(request=EvaluateLabelsRequest( content=ContentData(text="Text to evaluate"), label_version_ids=["label-version-id-1", "label-version-id-2"], threshold=0.5, )) ``` Request and response type names remain stable, including `EvaluateLabelsRequest` and `EvaluateLabelsResponse`. ## 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. # Discord Bot Source: https://docs.clavata.ai/integrations_and_developer_tools/discord_bot_how-to The Clavata Discord Bot - ClavataBot - can help you moderate your Discord communities. Big or small, the bot offers a number of moderation features and abilities to moderate various channels. It works seamlessly with your existing Clavata policies or create a new one just for Discord. Read on to learn how to set the bot up and what the different commands do. # Setting up your Discord bot Setting up the Discord bot is quick and easy and only takes a few steps if you're using an existing Clavata policy. ## Adding the API Key and Policy In order to allow your Discord Bot to communicate with your Clavata instance you will need to provide an API key and a Policy Id. Both of these are simple to get. Your API Key was provided to you when setting up your instance and you can access your Policy Ids whenever you want. * Your API key will be a long series of letters and numbers. * Your Policy Id can be found in your Policies tab in Clavata and to the right of a policy's name. ## Adding the bot to your server You will need a specific link in order to add the Discord bot to your server, along with the appropriate permissions. Server owners and admins typically have this permission but your admin roles and responsibilities may differ from server to server. Follow the below instructions to add the bot to your server. 1. Paste the URL you've been given by Clavata into your browser of choice. 1. Note: you will need to be logged into Discord. 2. You will see a pop up asking you to add 'ClavataBot' to a server. 3. In the 'ADD TO SERVER:' dropdown, select the server you would like to add the bot to. 1. Note: if you own multiple servers you will see a list of all of them. Be sure to select the correct one to ensure the bot is added to the correct server. 4. Clicking 'Continue' will allow you to proceed to adding the bot. Inside your Discord server, the bot will ask you to enter setup mode and enter your API credentials and Policy Id. # Clavata bot commands ``` /clavata setup ``` This will have you enter the setup modal where you can enter your API Key and Policy Id and should be the first command you run after installing the bot. ``` /clavata show ``` This command will give you an overview of your current settings for Clavata Bot. * API Key - your API Key used by the bot to communicate with your Clavata instance * Policy ID - is the current policy your bot is using to evaluate content * Channels - the current Channels your bot is monitoring and evaluating * Active - whether the bot is actively making decisions or not * Mod Actions - displays the current Mod Actions the bot is taking when it finds a violation against your policy ![](https://s3.amazonaws.com/helpscout.net/docs/assets/66e1fc9f2de3eb1957dcc446/images/67b4f21c2ed3f35984da42eb/file-NAzqmrwRtN.png) ``` /clavata actions set ``` This will allow you to set moderation actions for your bot to perform when it finds a policy violation. Click on one or more actions to set them. * Notify the admin via DM * This notifies admins via a DM that a violation was found * Delete the message * This will delete the violating message * Warn the user * This will send a warning message to the user about the violating message * Timeout the user for 10 minutes * This will prevent the user from doing any actions on the server for 10 minutes * Kick the user * This will kick the user from the server but will allow them to join back if they have an invitation link * Ban the user * This will ban the user from the server. They can't join again unless the ban is removed ``` /clavata actions clear ``` This will clear any moderation actions you've set in your 'actions set' command. * Notify the admin via DM * This notifies admins via a DM that a violation was found * Delete the message * This will delete the violating message * Warn the user * This will send a warning message to the user about the violating message * Timeout the user for 10 minutes * This will prevent the user from doing any actions on the server for 10 minutes * Kick the user * This will kick the user from the server but will allow them to join back if they have an invitation link * Ban the user * This will ban the user from the server. They can't join again unless the ban is removed ``` /clavata active yes ``` This will enable the bot to take moderation actions if set. ``` /clavata active no ``` This will disable the bot so no moderation actions are taken. ![](https://s3.amazonaws.com/helpscout.net/docs/assets/66e1fc9f2de3eb1957dcc446/images/67b5021f2ed3f35984da4351/file-25RKV1xfPB.png) ``` /clavata auth ``` This will allow you to set an API Key for your instance. ``` /clavata channels set ``` This will allow you to set the channels you would like the bot to monitor. Leave this blank to monitor all channels. ``` /clavata channels clear ``` You can use this command to clear any channel selections made and monitor all channels. ![](https://s3.amazonaws.com/helpscout.net/docs/assets/66e1fc9f2de3eb1957dcc446/images/67b5040213bcf329880da260/file-u6UrNRntJu.png) ``` /clavata policy ``` This will allow you to set which policy you want the Discord bot to use. ## 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. # Glossary of Terms Source: https://docs.clavata.ai/policy_reference/moonbounce_glossary_of_terms A reference glossary of terms you might encounter when working on policies. ## Overview This glossary provides a list of key terms used within Moonbounce's platform. Whether you're new to the platform or need a quick reference, this guide will help you understand the essential terminology for navigating and using Moonbounce effectively. *** **Accuracy**: The percentage of items that were analyzed correctly by the AI. This value ranges from 0% (not accurate) to 100% (perfect Accuracy). **AI Agent**: An advanced AI component within Moonbounce that reviews and evaluates content based on your platform's Policies. **Moonbounce**: Moonbounce is a platform designed to enhance safety in online spaces and generative AI environments. It leverages advanced AI Agents to review content with high Accuracy, helping platforms ensure secure and trustworthy interactions. **Connecting Conditions**: Used to link different Signals and Signal Lists in Policy Sections using logical operators like NOT, AND, OR, ALL, ANY, and NONE. **Context Conditions**: Define relationships between objects or concepts in specific contexts to create Rules, such as "threats" \[CONCERNING] "real-world violence." **Exact Match Conditions**: Identify specific words or phrases in content, ignoring case differences (e.g., =("cat") identifies “cAt,” “CAT,” and “CAt”). **EXCEPT WHEN Condition**: Specifies exceptions to the Rules within a Section of your Policy. These exceptions only apply to that specific Section without affecting the overall Policy. **False**: Indicates that the content did not match any Rule in your Policy. **False Negative**: Occurs when the AI fails to identify a relevant result, missing something that should have been flagged. **False Positive**: Occurs when the AI incorrectly flags something as relevant when it is not. **Fuzzy Match Conditions**: Used to detect variations of words or phrases, including leetspeak (e.g., \~("hate") detects “h4t3”). **Label**: Also referred to as a Section. A defined part of a Policy that contains one or more Rules. All Rules within a Section or Label must be met for the content to align with the Section’s or Label's logic. **Match Conditions**: Specify one or more words or phrases to look for within the text. Matches can be Exact, Fuzzy, or Sentiment-based. **Operator**: Predefined functions used in Context Conditions to define relationships between Signals or objects in Rules. Operators guide how Conditions are evaluated, enabling complex Rule creation. **Policy**: A Policy defines the guidelines the system follows to analyze and classify content. Policies are customizable, human-readable, and used to classify various content types. **Precision**: Measures how many of the AI's predicted positive results are correct. High Precision ensures that most of the flagged results are accurate, but it may miss some relevant ones (low Recall). **Recall**: Measures how many actual relevant results the AI identified. High Recall ensures that the AI captures most or all relevant results, though it may occasionally include incorrect ones. **Rule**: A core logical statement in your Policy that guides how the system evaluates content. Rules set conditions that the content must either pass or fail. **Section**: Also referred to as a Label. A defined part of a Policy that contains one or more Rules. All Rules within a Section or Label must be met for the content to align with the Section’s or Label's logic. **Sentiment Conditions**: Analyze the overall sentiment of content to identify language such as threats (e.g., Sentiment("threatening") detects “I am going to kill you.”). **Signal**: A Signal or Signal List is a set of words, phrases, or sentiments the system searches for within your content. **Syntax**: The set of rules that define how Operators, Conditions, and Signals must be structured when creating Rules. Correct Syntax allows Moonbounce to interpret and execute Rules effectively. **True**: Indicates that the content matched a Rule in your Policy. *** ## 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. # Creating Rules Source: https://docs.clavata.ai/policy_reference/syntax/creating_rules An overview of how to create and use rules. In Moonbounce, Conditions are the specific criteria you set to detect certain types of content. These Conditions allow you to specify how content should be flagged or evaluated based on patterns, context, and sentiment. They are the foundation of every Rule you create. There are several types of Conditions you’ll use when creating Rules. For more details on the types of Conditions, check out this article. *** ## When and Where to Use Conditions ## AND and ALL Use these Conditions when you need to narrow down your search by combining multiple criteria that must be met. For instance, if you're looking for content that’s both offensive and related to a particular topic, the **AND** Condition ensures all logic is met. The **ALL** Condition is similar but requires every Condition in the list to be true. AND and ALL Conditions are used in the following format. AND and ALL are entered, followed by parentheses containing a Signal or Signal List. Signals are enclosed in quotation marks and separated by commas. The Signals in this format are to be replaced with the content you are targeting. **Example format:** ``` ALL ( "signal","signal" ) AND ( "signal" ) ``` **Example in a Rule:** ``` ALL ( "gender identity", "sexual orientation" ) AND ( "offensive stereotypes" ) ``` This Rule flags content where gender identity and sexual orientation are mentioned together in the context of offensive stereotypes. *** ## NOT and NONE Use **NOT** when you need to exclude certain Conditions from your search. **NONE** ensures that none of the listed Signals are present, making it an ideal Condition when you want to avoid certain content or language. NOT and NONE Conditions are used in the following format. NOT and NONE are entered, followed by parentheses containing a Signal or Signal List. Signals are enclosed in quotation marks and separated by commas. The Signals in the format example below are to be replaced with the content you are targeting. **Example format:** ``` ANY ( "signal1" "signal2" "signal3" ) AND NOT ( "signal" ) ``` **Example in a Rule:** ``` ANY ( "positive feedback" "positive adjectives" ) AND NOT ( "vulgarity" "sarcasm" ) ``` *** ## Exact and Fuzzy Matches Use **Exact Match** Conditions for clear, specific terms that must be flagged exactly as they appear. **Fuzzy Match** is useful when content may include variations or misspellings, helping to catch similar but not identical terms. Exact and Fuzzy Match Conditions follow the following formats. For an Exact Match, enter the symbol =, followed by an opening parenthesis, followed by a Signal enclosed in quotation marks, then a closing parenthesis. For a Fuzzy Match, enter the symbol \~, followed by an opening parenthesis, followed by a Signal enclosed in quotation marks, then a closing parenthesis. **Example format:** ``` Exact match: =("signal") Fuzzy Match: ~("signal") ``` **Example in a Rule:** ``` Exact Match: =("crap") Fuzzy Match: ~("crap") ``` In these examples, the Exact Match will flag the word “crap” with any variations of capitalization or letter repetition. The Fuzzy Match will flag the word “crap” written with any leet speak or more complex variations than simple capitalization. *** ## UNLESS Use **UNLESS** when you need to allow for certain exceptions within a Policy Section or Policy Label. This is particularly useful when content may technically match a Rule’s Conditions, but shouldn’t be flagged due to context or lighter intent. UNLESS Conditions are used in the following format. Input UNLESS, followed by curly brackets containing one or more Rules in the curly brackets. **Example format:** ``` UNLESS { "signal" } ``` **Example in a Rule:** ``` SECTION "Positive": "MEDIUM" { ANY ( "encouraging", "celebrating", "friendship" ) UNLESS { "performance nitpicking" } } ``` This example shows the UNLESS in relation to the Section or Label it is creating the exception for. The example is analyzing for any encouraging, celebrating, or friendship contexts except when it is used in the context of performance nitpicking. *** ## Considerations * **Keep it simple**: Start with basic operators like AND and ALL, and build complexity as needed. Overly complicated Rules can be difficult to manage. * **Test Fuzzy Matches**: Make sure to test your Rules with different variations of the content to ensure Fuzzy Matches flag your expected variations. * **Use context wisely**: Context Conditions are powerful but should be used carefully to avoid missing relevant content that may be better suited to be found using a Rule built with Connecting Conditions. * **Test and refine**: Regularly review your Policies to ensure they are flagging the right content and adjust them as needed. * **Use UNLESS thoughtfully**: Ensure that the exceptions you create truly reflect the intent behind your Policy Section to avoid letting harmful content slip through. *** ## 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. # General Policy Syntax Source: https://docs.clavata.ai/policy_reference/syntax/general_syntax_of_policies An overview of the syntax that makes up policies. ## Overview In Moonbounce, a Policy defines the guidelines the system follows to analyze and classify content. Policies can serve various purposes, including flagging content that should be avoided on your platform, detecting and categorizing content, and streamlining your moderation process for greater efficiency. Policies are written in clear, readable terms, and are used to classify text and image content. Because Policies are at the center of how Moonbounce works, it’s crucial to understand how to write, read, and manage your Policies effectively. This guide provides an overview of the core elements of Policy syntax. *** ## Conditions and Rule Writing #### Labels * Labels must have a name, and can optionally have a risk level or action. * All Rules and content within a Label are enclosed in curly brackets. Example structure using the **LABEL** nomenclature: ``` LABEL "label name": "section risk or action" { "signal" [OPERATOR] "signal" } ``` #### Connecting Conditions * Connecting Conditions are not enclosed in any punctuation, but the Rules within them are enclosed in curly brackets. * The Rules and Signals within a Label are subject to their own punctuation requirements, dependent on how they are used. * Connecting Conditions are referred to in all capital letters in documentation as a matter of preference, but they are not case sensitive. Example structure: ``` ANY ( "signal" ) AND ANY ( "signal" "signal" ) ``` #### Match Conditions * Match Conditions follow individual syntax: * Exact Match is written as `=("signal")` * Fuzzy Match is written as `~("signal")` * Sentiment Match is written as `SENTIMENT("signal")` (finds negative language). * Note: when using Signal Lists with Match Conditions, the syntax remains the same but the signals are listed on individual lines. #### UNLESS Conditions * UNLESS Conditions apply to the Label immediately preceding it. * The UNLESS Conditions are not enclosed in any punctuation, but the Rules within them are enclosed in curly brackets. * Individual Rules are subject to their own punctuation requirements. * UNLESS Conditions are referred to in all capital letters in documentation as a matter of preference, but they are not case sensitive. Example structure: ``` LABEL "label name" {  "signal" [OPERATOR] "signal" UNLESS { "signal" } } ``` ### Priority Priority allows you to specify hierarchies when it comes to your Labels. This allows you to say if there are two labels that come back as true then prefer one over the other. If the system returns the Dog label and the Cat label, then only return Dog from the system. This is useful if you plan on doing API response logic. ### Top-Level Priority You can set priority at the top of your policy. This does not need to include every label within a policy but should include the ones you want to add to your hierarchy. ``` PRIORITY: "Mature" > "R" > "PG-13" > "PG" LABEL "Mature" { "Mature content" } LABEL "R" { "R rated content" } ``` ### Label-Level Priority This works functionally the same as the top but you are setting the priority in an UNLESS block. ``` LABEL "Mature" { "Mature content" } LABEL "R" { "R rated content" UNLESS -> "Mature" } ``` ### Duplicate Priorities Duplicating priority logic will result in an error that has to be fixed before being able to save your policy. ``` PRIORITY: "Mature" > "R" > "PG-13" > "PG" LABEL "Mature" { "Mature content" } LABEL "R" { "R rated content" UNLESS -> "Mature" } ``` #### Signals * Signals can be a single word or multiple words. * Each Signal must always be enclosed in quotation marks. * Example: "signal" * Signal Lists must have each Signal in the list enclosed in quotation marks. * Signal Lists are always paired with a Condition and therefore are enclosed in parentheses. Example structure: ``` ANY ( "dog" "cat" "pony" ) ``` ## General Punctuation This section provides information about the use of capitalization/case-sensitivity and general punctuation for Policies. #### Case Sensitivity * No components of Policies are case-sensitive. * In documentation, Conditions are referred to in full capitalization and Signals are shown in lowercase for readability, but this is not required. #### Rules on Separate Lines * Each Rule must be entered on a new line. Example structure: ``` LABEL "label name": "risk or action" { "signal" [OPERATOR] "signal" ← RULE "signal" [OPERATOR] "signal" ← RULE } ``` #### Commas * You may use commas to separate Rules or Signal Lists, but it is not required. This is purely a matter of style preference. #### Indentations * Indenting Labels and Rules is not required, but we recommend doing so as it makes your Policies significantly tidier and easier to read. #### Comments * You can add comments to your Policies using the `#` symbol. * Anything following the # on a line will be ignored by the system. Example: `# This is a comment` #### Logical Wording * Rules should be written in a way that logically connects the Signals, ensuring the Rule forms a clear and meaningful phrase or sentence. * This is particularly relevant to Context Conditions. * For example: `"misinformation" [ABOUT] "elections"` uses the `[ABOUT]` Operator. Notice that it reads naturally with the surrounding Signals. *** ## 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. # Label Prioritization Source: https://docs.clavata.ai/policy_reference/syntax/label_prioritization_and_taxonomies An overview of how to use label prioritization. The primary object that you work with in Moonbounce's system is a `LABEL`. Labels are really just a way to give a particular set of assertions a name. Moonbounce's API then returns that name back to your platform whenever you send us content (or other unstructured data) to evaluate. Historically, when you send our API a piece of content (or run a test in our web application), we try to find as many matching labels as we can for each input. Recently, customers indicated that they wanted a way to say, "If `Label A` is true, then `Label B` should never be true." Another way to say this is that there's a **dependency** **between** `Label "A"` **and** `Label "B"` **.** Well, wish granted! You can now express dependencies in your policies to better control which labels are matched to each of your inputs. ## Use Cases ### Taxonomies A common use case for this new feature is the creation of *Taxonomies*. Taxonomies are trees (or tree-like) structures that represent how different ideas are connected. While Moonbounce's users have always been able to look for labels that are part of a taxonomy, the "logic" of how those ideas are related had to be represented in your integration with our API. Now, you can represent these taxonomies right in your policy. file-2REIPurSaK.png ### Rating systems Another common use case we've been asked for is a way to represent a "rating system", like the common movie ratings `R`, `PG-13`, and `PG`. It has always been possible to create labels for each "rating", but in the past, trying to tell our system that "if something is rated `R` then you should never apply the `PG-13` or `PG` label" has been a bit cumbersome—requiring the use of complicated `UNLESS { }` blocks. As a result, most customers chose to just implement the hierarchy of the rating system on their side of the integration. This works well, but it has a downside: When you test in the Moonbounce application, you may end up with some of the examples in the dataset being labeled with `R` **and** `PG-13` (for example), which throws off the metrics. No longer! You'll now be able to test accurately and avoid the need to implement this hierarchy as part of your integration. file-4VAGkE2akO.png Ok! Enough talking about it. Let's dive in and see how we can use these new features. # Two approaches, same result Before we dive into the actual syntax, it's worth noting that both of the forms of syntax we show below have the exact same impact. They are simply two ways to achieve the same thing. Why two ways? Because depending on the specifics of your use case, one will likely be easier to write, read, and maintain than the other. Below, we share the syntax, what it means, and when we recommend you use one form or the other. ## Option 1: `UNLESS -> X` We'll start by talking about our new `UNLESS ->` syntax because it's the simplest and most straightforward and will probably be where most users start. Suppose you have two labels, `LABEL "A"` and `LABEL "B"` in your policy, and suppose also that if `LABEL "A"` turns out to be `true` for a piece of content, then `LABEL "B"` should never be true for that same piece of content. You can now express this relationship as follows: ``` LABEL "A" { "foo" AND "bar" } LABEL "B" { "baz" AND "qux" UNLESS -> "A" } ``` Simply by adding `UNLESS -> "A"` **inside the** `LABEL "B"` block, you've now told our system about the relationship—`Label "B"`'s result now *depends on* the result of `LABEL "A"`. This is probably already obvious. But for clarity, the `UNLESS -> "X"` syntax does not **force** its label to match when `"X"` is false. It merely *allows* its label to match if `"X"` is false. ## **When to Use** `UNLESS ->` **?** * You want to make one label *depend on* whether a different label matched (or not). * Specifically, this operator allows you to ensure that a label *will not* be a match if another label is a match for a particular piece of content. ## More than one dependency You can also use `Unless ->` more than once in the same `Label` block. The effect will be to cause that label to *depend on* the result of all the specified labels. ``` Label "A" { Unless -> "B" Unless -> "C" } ``` This means: Label A **should not match** if Label B or Label C already match. Importantly, this only impacts Label A—it does **not** create any dependency from B to C or between B and A unless explicitly declared. ## Example Use Case: Images with Overlapping Labels Imagine you’re moderating visual content with 3 labels whose definitions overlap to some degree: * **Realistic** (most severe) * **Anime** * **Cartoon** Let’s say: * You want to apply the “Realistic” label only if the content is *not* Anime or Cartoon. * Anime and Cartoon can coexist, so they should not block one another. ### **Setup Using UNLESS** ``` LABEL "Realistic" { "real people" UNLESS-> "Anime" UNLESS-> "Cartoon" } ``` This setup ensures “Realistic” is only applied when the content doesn’t fall into either the Anime or Cartoon categories (along with descriptors of any other assertions you may have). And since Anime and Cartoon can overlap: ``` LABEL "Cartoon" { "hand drawn" OR "line art" UNLESS-> "Anime" # Only if you want Anime to take priority over "Cartoon" } ``` This is optional. You could add this rule **only if** you want to give Anime slight priority over Cartoon. Otherwise, you can allow both labels to be applied together. *** ## Option 2: `PRIORITY` The `Priority` **operator** is great for defining longer chains of hierarchies. It allows you to define a hierarchy among labels in a dataset, ensuring that only the highest-priority applicable label is assigned to any single item. This is especially useful when labels are **mutually exclusive** within a shared category. ## When to Use the Priority Operator? * You have multiple labels in a **dependent hierarchy** (i.e., where one label takes precedence over others). * You want to **avoid tagging the same item with multiple conflicting labels** from the same category. * You need to enforce a **clear, logical order of severity or specificity** (e.g., content risk levels, maturity ratings). For example, if a piece of content could be classified as both “R” and “NSFW,” the more severe label—“NSFW”—should take precedence. The Priority operator ensures that only one, highest-priority label is applied. ## **Syntax** ``` PRIORITY: "A" > "B" > "C" ``` This should be read as: If "A" is true, then neither "B" nor "C" can be true. If "A" is not true but "B" is, then "C" cannot be true. You can extend this chain to include as many labels as necessary: ``` PRIORITY: "NSFL" > "NSFW" > "R" > "PG-13" ``` ## **Example Use Case: Content Ratings** Let’s say you’re building a moderation system that assigns content risk levels. Each label represents a different severity tier: * **NSFL** (Not Safe for Life) * **NSFW** (Not Safe for Work) * **R** (Restricted) * **PG-13** (Parental Guidance) These categories are mutually exclusive: a single piece of text, image or video shouldn’t be tagged as both NSFL and PG-13. In this scenario, the Priority operator allows you to enforce a strict label hierarchy: ``` PRIORITY: "NSFL" > "NSFW" > "R" > "PG-13" ``` If an item qualifies as NSFL, it **will not** be tagged as NSFW, R, or PG-13—even if it meets the criteria for those as well. This ensures that the most severe label is always the one applied, avoiding conflicting tags. file-nNlI8Lh9TA.png ## **Notes** * Priority chains only make sense when labels are **exclusive** and **ranked**. * The operator does not define the criteria for the labels—only their **order of application** when more than one could apply. * This is **not** a ranking of confidence or probability, but a rule-based hierarchy. *** ## **Comparison: UNLESS vs PRIORITY** Let’s say you have three labels: * Label A * Label B * Label C If you use UNLESS logic like this: ``` Label A { UNLESS -> "B" UNLESS -> "C" } ``` Then: * Label A will be skipped if either Label B or C matches. * Label B and C can still be applied independently of one another. But if you write: ``` PRIORITY: "C" > "B" > "A" ``` This is shorthand for the following logic: ``` Label A { UNLESS -> Label B UNLESS -> Label C } Label B { UNLESS -> Label C } ``` This **creates a cascading dependency across all three labels**, making it a cleaner choice when the relationship is fully hierarchical. ## **Best Practices** Use the UNLESS operator when: * You need targeted exclusions. * You don’t want to define a full ranking between all labels. * You’re working with labels that can **overlap**, except in specific edge cases. Use PRIORITY when: * Your labels are **fully hierarchical** and mutually exclusive. * You want the system to enforce cascading exclusions automatically. Ultimately, you can achieve *the same goals* with either form of our new dependency features, so which one you use is up to you. Our advice: Prioritize (no pun intended) ease of understanding and maintenance. For long chains of dependencies, it's much easier to write one line at the top of the file, but it's also much easier for future editors/testers to understand. The drawback to `PRIORITY` is that it cannot represent **branching** logic. And from an understandability perspective, there's an argument to be made that having `UNLESS -> X` with the `LABEL` it applies to may be less prone to errors or confusion when you're dealing with large numbers of labels. *** # Watch out for **circular dependencies!** One thing to be aware of is that you may not create **circular dependencies**. A circular dependency occurs when `LABEL "A"` depends on `Label "B"` **and** `Label "B"` depends on `Label "A"` at the same time. This makes sense, because if we allowed this, it would be **impossible for** both `"A"` and `"B"` to ever be true. The compiler will check to make sure there are no circular dependencies when you run a test or try to commit a version. If a circular dependency is found, an error will be returned with info on how to correct the problem. It's rare to create a circular dependency between 2 labels, as it's a fairly obvious problem. The more common case occurs when you have 3 (or more) labels and don't realize you've created a circular chain. For example: ``` LABEL "A" { UNLESS -> "C" } LABEL "B" { UNLESS -> "A" } LABEL "C" { UNLESS -> "B" } ``` In the above example, none of the labels *obviously* refer to each other, yet a circular dependency still exists because `B` depends on `A`, `A` depends on `C`, and then `C` depends on `B` (so we are back at the beginning). The same problem could also look like this when using the `PRIORITY` operator: ``` PRIORITY: "A" > "B" > "C" > "A" ``` This is actually one of the benefits of the `PRIORITY` operator—the "circularity" of this chain is more obvious because all the relationships are in one place. ## 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.