Skip to main content
This is Moonbounce’s label-first experience. If you’re looking for the policy-first experience, switch using the version selector above.
Signals are the words, phrases, and questions you write inside a label to tell Moonbounce what to look for in content. In the label editor you compose rules from signals and conditions (such as ANY, AND, or exact match). Together they define when your label should match.

​
What is a signal?

A signal is a quoted phrase (or question) that names a concept you want the system to evaluate — for example "graphic violence" or "spammy promotional language".
  • Signals are always wrapped in double quotation marks.
  • A signal can be a single word or multiple words.
  • Signals are not case-sensitive.
  • A rule combines one or more signals with optional conditions. If any rule in the label matches, the label matches.
Simple rules can be a single signal on its own line: 
"graphic violence"
That tells the system to evaluate whether the content matches the concept described by that phrase.

​
Rules, conditions, and signal lists

Most labels use conditions to combine signals:
ConditionPurpose
ANY ( … )Match if any expression inside the parentheses matches
ALL ( … )Match only if every expression inside matches
NONE ( … )Match only if none of the expressions inside match
ANDBoth sides must match
OREither side may match
NOTNegates the following expression
=( … )Exact match on literal text (case-insensitive)
~( … )Fuzzy match on literal text (catches variations and leetspeak)
SENTIMENT ( … )Match when content carries the given sentiment (for example threatening language)
Parentheses group expressions. Separate rules with a newline or a comma.

​
Connecting signals with ANY and AND

ANY ("violence", "gore", "weapons") AND "directed at person"
This matches when any of the first three concepts appears together with content that matches "directed at person".

​
Exact and fuzzy literal matches

Use exact match when you need specific terms to appear as written (ignoring case): 
=("kill", "murder")
Use fuzzy match when you want to catch spelling variants or leetspeak: 
~("spam")

​
Sentiment

SENTIMENT("threatening", "hostile")

​
Questions

Append ? after the closing quote to ask a yes/no question about the content: 
"is this promotional spam"?

​
Exceptions with UNLESS

Use UNLESS to carve out exceptions for the label. The block applies to the label you are editing: 
"attacks on personal circumstances"
UNLESS {
  "light trash talk"
  "fictional context"
}
Content that matches an UNLESS rule should not cause the label to match, even when other rules would have matched.

​
Comments

Add comments with #. Everything after # on that line is ignored: 
# Promotional patterns
ANY ("buy now", "limited time offer")

​
A fuller example

ANY ("violence", "gore", "weapons") AND "directed at person"
=("kill", "murder") OR "threatening language"
UNLESS {
  "fictional context"
  "educational material"
}

​
Good vs. weak signals

Strong signals describe what you mean in plain language the model can interpret: 
"sexually explicit content involving minors"
"unsolicited bulk commercial email"
Weak signals are vague single words that leave too much room for interpretation: 
"bad"
"inappropriate"
Prefer specific, testable phrasing — then use your label’s dataset to confirm the behavior you want.

​
Common mistakes

MistakeFix
Unquoted text (spam instead of "spam")Wrap every signal in "double quotes"
Missing separator between rules ("a" "b" on one line)Put each rule on its own line, or separate with a comma
Question mark inside quotes ("is this spam?")Put ? after the closing quote: "is this spam"?
Using [ABOUT] or other bracket operatorsNot supported in the label editor grammar — see Policy Reference for the policy-first syntax
PRIORITY, SECTION, or multiple top-level labels in one editorLabel-first uses a single-label grammar (v3); one label per editor
UNLESS -> "Other Label"Use an UNLESS { … } block with signals, not a reference to another label
The editor validates your draft as you work and surfaces syntax errors with line numbers when something cannot compile.

​
Policy-first vs. label-first syntax

The policy-first experience supports a broader policy language (including context operators like "drugs" [IN REFERENCE TO] "selling", PRIORITY chains, and multiple LABEL blocks in one policy). That syntax is documented under Policy Reference in the version selector. The label-first editor uses grammar version 3: one label body, the conditions listed on this page, and UNLESS blocks — but not context operators, PRIORITY, or SECTION.

General Policy Syntax

Full policy language reference (policy-first experience).

Creating Rules

Deeper guide to conditions and rule patterns.

​
Where to next

Building with Labels

The craft → test → publish → integrate loop.

Labels, Versions & Datasets

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