In the app, your policy is the prompt. The model reads your policy, looks at the content, and applies your rules. It doesn't bring its own opinions about what should be flagged or allowed: sharp policy, sharp output; vague policy, and the model fills the gaps with its own priors. This page covers how to create a policy, how policies are structured, and the writing practices that make them perform well.

💡 These tips are based on current observations with specific models. Validate through testing before relying on them in production. If you have questions, we're here to help.

Creating a policy

Click New Policy on the Policies page and the Musubi Agent drafts the policy with you:

1. Enter policy text. Paste in an existing policy (including notes), or describe what you want in a sentence: "Scam listings for our marketplace platform" or "harassment in live chat between players." Telling us about your platform and who uses it (for example, "dating app, 18+, mostly 1:1 DMs") is recommended: it helps the draft match your context.
2. Add details. Choose each kind of content this policy will review (text, image, audio, video, or PDF) and include as many as you need. Optionally, tune how the policy handles tradeoffs: whether close calls lean toward catching more or only clear matches, and whether to favor lower cost or best quality. These choices shape the model choice, policy phrasing, and AI instructions in the draft. Check latency-sensitive if this policy will review content in real time.
3. Draft Policy. The Agent writes a complete first draft (categories, descriptions, and instructions) and opens a chat alongside it. Review the assumptions it made and ask for changes in plain language: "split harassment into two categories," "add exceptions for medical content."

Prefer to write everything yourself? Click Start with a blank policy instead in the same dialog. You can also duplicate one of your existing policies from the Policies page.

What to paste: the first step accepts anything from a finished policy document to two sentences. If you paste an SOP, the draft keeps the classification criteria and drops the procedural steps (queues, escalation paths): the model returns a label, and your pipeline picks the action. If you paste a public-facing policy, expect to add the concrete criteria the public version deliberately leaves out. The chat is a good place to do both.

However it starts, treat the draft as a starting point: read every category, description, and example, and evaluate the policy against labeled data before it goes live.

How policies are structured

Policies have two # H1 top level sections:

• # Instructions (optional): How the model should evaluate content and make decisions (tone, nuance, fallback behavior).
• # Policies (required): Your policy's evaluation categories and their descriptions.

Policy Categories are defined under the Policies section. There must be at least two (label/clear) but you can add more.

• Labels (required): ## H2 headings that are the exact labels the model returns.
• Description (required): Directly under each H2 heading, this text explains when and why this label should apply.
• "Clear" category (required): Include exactly one label covering everything your other H2 headers don't. Must be called Other, Safe, or Clear, or it will be treated as a flagging category.

Category names can't contain special characters: use letters, numbers, and spaces.