Skip to main content
Guidelines let you define custom rules in plain English without training a model. Write what isn’t allowed, give the rule a key, and the LLM scores every submission against it. You can add as many as you need — they’re all evaluated in a single LLM call per request. Use guidelines when one of the pre-built policies doesn’t quite cover what you want, but the rule is simple enough to describe in a sentence or two.

​
Shape

Each guideline has two fields:
FieldLimitWhat it is
key100 charsA unique identifier for the rule on this channel (e.g. no-spam, be-respectful).
instructions750 charsA natural-language description of what is not allowed.

​
In API responses

Every guideline shows up as its own entry in response.policies. The id is guideline/<key>, the type is classifier, and you read probability / flagged like any other classifier: 
{
  "policies": [
    {
      "id": "guideline/no-spam",
      "type": "classifier",
      "probability": 0.92,
      "flagged": true
    },
    {
      "id": "guideline/be-respectful",
      "type": "classifier",
      "probability": 0.08,
      "flagged": false
    }
  ]
}

const noSpam = response.policies.find(p => p.id === "guideline/no-spam");

if (noSpam?.flagged) {
  await sendToReview(content);
}

​
Writing good instructions

A few patterns that work well:
  • Lead with the violation, not the policy. Posts that ask users to DM, follow on another platform, or share contact info beats Anti-spam rule for off-platform redirection.
  • Be specific about edge cases. If “promoting other products” should allow users mentioning tools they use, say so: Promoting other products or services. Mentioning tools a user personally uses is allowed.
  • One concept per guideline. Split unrelated rules into separate guidelines so you can flag them independently and tune thresholds per rule.
  • Keep it under ~300 characters. Longer instructions don’t make the LLM more accurate — they make it slower and harder to debug.

​
Configuring guidelines

Guidelines are configured in the dashboard, per channel — open the channel’s Policies tab and add them under Guidelines. They run on text and audio content.

​
Project context

Guidelines are evaluated with your project context in scope. That’s the description you set under Configure → Context in the dashboard — typically a short paragraph about what your platform is, who uses it, and the kind of content you expect. It’s passed to the LLM alongside your guideline instructions so the rules are interpreted in the right setting. For example, a guideline like No promoting other platforms will behave differently for a developer forum (where mentioning GitHub is normal) than for a dating app (where directing users off-platform is a red flag). A well-written project context lets the LLM make that call without you spelling out every exception in the guideline itself. See Understanding API responses for the full response shape, and Optimizing accuracy for guidance on tuning thresholds.