Getting the most out of Nima

Best Practices for T&S Leads, Policy Ops, Moderators and Engineers

Nima delivers the most value when four roles adopt it deliberately: T&S Leads who own enforcement outcomes, Policy Ops who turn policy into rules, moderators who apply policy to the cases automation can't settle, and engineers who connect the platform to Nima. This guide gives the practices that matter most for each role, and the rituals that connect them.

In smaller teams one person plays several roles. Read the tracks that apply and use the Working together section as your own checklist.

The T&S Lead succeeds with Nima when enforcement is consistent, proportionate and explainable to users, executives and regulators. set the policy frame, the risk appetite and the operating cadence that Policy Ops works within.

What success looks like:

Start from policy, not tooling. Map Nima policies one-to-one to your community guidelines before anyone builds a rule.

Design queues around decisions, not volume. Give each queue one decision type or reviewer skill: CSAM escalation, hate speech in a given language, appeals. Tight scope keeps reviewer context sharp and makes misrouting visible.

Make enforcement proportionate. Use strike engines to encode graduated consequences. This cuts repeat-offender workload and gives users and regulators a consistent, explainable enforcement story.

Build compliance in from day one. Consistent policies and actions make statement-of-reasons, action logs and transparency reporting a by-product rather than a quarterly scramble.

Run governance on a cadence. Hold a monthly review with Policy Ops, not just post-incident reviews.

Policy Ops succeeds with Nima when every rule is traceable, tested and tuned from evidence rather than instinct. You translate the T&S Lead's policies and risk appetite into rules, signals, thresholds and routing.

What success looks like:

Invest early in custom attributes. Provide as much context to the system as you can

Treat thresholds as hypotheses. A threshold set by gut feel drifts toward over-enforcement or under-enforcement. Every threshold should have a recorded rationale and a test result behind it.

Gate changes with batch testing. Run every meaningful rule or threshold change against the golden set before activation. Read the results by type: under-enforcement (false negatives) and over-enforcement (false positives) first, then over-routing and under-routing. Use ad-hoc testing to sanity-check single edge cases, not to approve changes.

Close the loop with reviewer decisions. Overturned automated actions are your richest tuning signal. Review overturn rates per rule and per model weekly, and add each overturned case to the golden set.

Keep the rule set clean. Once a month, retire rules that haven't fired, merge overlapping ones, and re-validate thresholds against fresh traffic.

Moderators succeed with Nima when their decisions are accurate, consistent and well documented, because every decision they make is both an enforcement action and a training signal. You apply policy to the cases automation can't settle, and your overturns tell Policy Ops where rules are wrong.

What success looks like:

Read the context before the content. Check the custom attributes and history Nima shows alongside the item, such as account age.

Decide on policy, not instinct. Pick the policy that the content actually violates and the action the strike ladder prescribes. When personal judgment and policy disagree, follow policy and flag the gap.

Tag precisely. The policy you select feed statement-of-reasons notices, transparency reports and strike counts.

Escalate rather than guess. Use the escalation queue for severe harms, legal edge cases and anything the policy doesn't clearly cover. A fast escalation beats a confident wrong call.

Report what the rules miss. If you see a pattern the automation isn't catching, such as a new slang term or evasion technique, raise it. Moderators are usually the first to spot under-enforcement.

Wellbeing is part of accuracy. Rotate moderators between high-exposure and low-exposure queues, cap continuous time on severe-harm queues, and use any blurring or grayscale display options your setup provides.

The Engineer owns what flows into Nima and how decisions flow back to the platform. Nima is designed to keep that work small, so the job is less about building an integration and more about configuring one well.

What success looks like:

Integrate once, through a single endpoint. All content types, surfaces and events go through one API endpoint, so there's one contract, one auth setup and one place to monitor. Adding a new surface or content type means sending a new payload shape, not building a new integration.

Shape webhooks to fit your platform. Customise the webhook body so enforcement decisions arrive in the format your services already expect: your field names, IDs and action codes. That removes the translation layer on your side, and decisions can go straight to the service that applies them.

Send metadata up front, refresh it when needed. Include the metadata workflows rely on, such as account age and verification status, in the first API request, and Nima ingests it along with the content. When that context may have gone stale by the time a rule runs or a moderator reviews the case, data fetch refreshes it from your systems.

The roles meet at five handoffs: platform data becomes signals, policy becomes rules, rules become reviewed decisions, evidence becomes policy changes, and incidents become test cases.