Rule Testing

testing your rules in nima rule testing lets you check how your rule configuration will behave before it goes live — either against a batch of content you upload, or against a single piece of content on demand this isn't limited to a single rule in isolation your configuration typically includes several rules evaluated together, with priority determining which rule's decision wins when more than one applies to the same piece of content testing shows you the outcome of that full configuration — including how priority resolves overlapping rules — so you can catch over enforcement, under enforcement, and misrouted content before it affects your users why rule testing matters testing your rule configuration before it goes live pays off across three areas of the business operations fewer post launch fire drills catching blindspots and over flagging before a rule ships means less emergency rule patching and fewer escalations from the field lighter queue load spotting content that's being unnecessarily routed to human review (reviewing safe content) lets teams tune rules to auto resolve clear cut cases, freeing reviewer time for genuinely ambiguous content more predictable staffing knowing in advance how a rule will distribute content across auto enforcement, queue, and no violation outcomes makes it easier to forecast reviewer workload and capacity needs trust & safety higher confidence before publishing teams can validate a rule's real world behavior against expected outcomes rather than relying on intuition or waiting for user reports to surface problems faster iteration on rule quality the expected vs actual framework turns rule tuning into a measurable, repeatable process rather than trial and error — every change can be re tested and compared better audit trail and accountability test results provide documented evidence of due diligence — useful for internal reviews, regulatory conversations, and demonstrating a considered approach to enforcement decisions business reduced legal and reputational risk catching blindspots (missed violations) before launch reduces exposure to harmful content slipping through, while catching over flagging protects against wrongly restricting legitimate users and content better user trust and retention fewer false positives means fewer frustrated, wrongly actioned users — a direct lever on platform trust and churn lower operational cost reducing unnecessary queue volume and rework translates directly into lower moderation headcount or vendor costs for the same level of coverage quick recap of how the rule engine works rules are what parse content entering nima and decide how it's handled there are two types proactive detection rules — evaluate content ingested and analyzed by ai models, using confidence thresholds you set queue routing rules — route content from other sources (user reports, lea/trusted flagger notices, etc ) into the right queue for manual review for proactive detection, a single threshold slider defines three possible outcomes for any given rule 🟢 no policy violation — content is dismissed, no action taken 🟠 requires human review — content is sent to the assigned queue 🔴 automated policy enforcement — the assigned policy is applied automatically when multiple rules could match the same content, priority decides which one actually fires rules are ranked by drag and drop, and where two rules' criteria overlap, the higher ranked rule wins and the lower one never runs (order only matters where criteria overlap — rules that can never match the same content aren't affected by their relative position) every instance also has a default rule that catches anything matching no other rule; it always runs last and can't be reordered this is exactly what rule testing lets you validate — not just whether a single rule's thresholds are set correctly, but whether the right rule fires at all once priority and overlapping criteria are taken into account why test a rule before publishing it? a rule that looks correct on paper can still behave unexpectedly once it meets real content testing lets you confirm the rule catches what it's supposed to catch spot content it wrongly flags or misses see whether content is being routed to the right queue compare the rule's decisions against your own expectations, side by side two ways to test a rule 1\ batch testing use batch testing when you want to validate a rule — or your whole rule configuration — against a larger, representative sample of content at once to run a batch test open the rule you want to test and click test rule (to test one rule), or go to trust & safety → rules → test rules (to test the whole rule configuration set) select test a dataset download a templated csv for your import fill in your csv file, specifying the expected outcome for each row your csv file should be capped to 50 rows of content (excluding the column headers) upload your test file nima will run the rule (if testing one rule) or all rules (if testing the whole configuration) against every item in your file and generate a results report 2\ single piece of content testing choose test one item when you want a quick answer for a single piece of content — for example, while you're still drafting a rule, or when you want to see how a specific piece of content and/or payload will make its way through the rule configuration to run a single content test open the rule you want to test and click test rule (to test one rule), or go to trust & safety → rules → test rules (to test the whole rule configuration set) choose test one item paste in the text or url of the single item you want to test nima evaluates the item against the rule and shows you the result immediately reading your results after a test runs, nima shows you how the rule's decisions compare to the expected outcome for each item results are grouped into categories so you can quickly spot where a rule needs adjustment category expected outcome actual outcome what it means reviewing clear violations auto enforcement routed to queue the content is expected to be a clear violation, but instead of being auto enforced it was sent to a queue for human review reviewing safe content no violation routed to queue the content is expected to be safe, but it was still sent to a queue for human review when reviewed, the item will confirm it's safe — this may point to a rule condition that's overly cautious blindspot auto enforcement no violation the content is expected to be a clear violation, but the rule took no action at all — it wasn't even routed to a queue for review this is a full miss and typically needs urgent attention over flagging no violation auto enforcement the content is expected to be safe, but the rule auto enforced against it anyway (a false positive) — this risks wrongly restricting legitimate content each result row shows the content item tested the rule's decision the expected decision which category (if any) it falls into example reading a real results screen the top summary shows how many rows a batch test actually reached in this example, 21 of 25 rows were processed, with 4 failed of the processed rows, \ "no violation" came in at 52% against an expected 10% (↑42pts), while both \ "routed to queue" (5% vs an expected 29%, ↓24pts) and \ "auto enforcement" (43% vs an expected 62%, ↓19pts) came in well under expectations the up arrow on "no violation" paired with down arrows on the other two tells you the same story from two angles content that was expected to be actioned is instead landing as no violation at all the rules results table shows both configured rules behaving correctly when they fire \ the nudity rule matched 9 rows and auto enforced 100% of them, \ and the violence rule matched 1 row and routed 100% of it to a queue the detailed results table confirm this 11 rows landed as a clean match , but 9 rows landed as blindspot (fn) — content expected to be a violation that no rule caught, so it defaulted to "no violation" — against only 1 over flagging row unlike the earlier over flagging example, this run's dominant issue is under detection rather than being too aggressive it points to missing rule coverage or thresholds set too high, rather than needing anything tightened what to do with your results high blindspot rate clear violations are being missed entirely, with no action taken this is the most severe gap — consider loosening thresholds or broadening conditions so the rule catches these cases high over flagging rate safe content is being auto enforced against consider tightening thresholds so the rule stops acting on content it shouldn't high "reviewing clear violations" rate violations are being routed to a queue instead of auto enforced this isn't a miss, but it may mean the rule could be tightened to auto enforce these cases directly, reducing reviewer workload high "reviewing safe content" rate safe content is being routed to a queue unnecessarily consider narrowing the conditions that trigger routing, so reviewers aren't spending time on content that doesn't need review we recommend re running a batch test any time you significantly change a rule's conditions or thresholds faq does testing a rule affect live content? no testing runs in a dry run mode and never takes action on real content or affects your live queues can i export my results? yes is there a limit to how much content i can test at once? batch tests are capped to 50 rows of content per csv (excluding headers)