---
title: Rule Configuration
slug: rule-configuration
docTags: 
createdAt: 2025-09-15T10:35:44.574Z
---

Rules are the mechanisms that parse content entering Nima and distribute it for moderation, either through automated enforcement or by routing it to human moderators.

## Types of rules

Nima supports two main types of rules, configurable in the Rule Engine:

1. **Proactive Detection Rules **to automatically ingest and analyze any type of content uploaded with AI models and triage it based on the thresholds (confidence levels) you set to:
   - Automatically enforce policy violations for high confidence cases 🔴 
   - Send content to the configured human moderation queues for cases flagged as 🟠
   - Dismiss content flagged as 🟢 if no issues detected.
2. **Queue Routing Rules (only for Human Moderation) **to parse content coming from sources other than proactive detection (user reports, user report illegal content, LEA or Trusted Flagger notices) into queues for manual review, where moderators apply policies.

## Configuring rules 

### Proactive detection rules

A proactive detection rule is associated to one of your [Policy Configuration](docId\:R6VgF6m3D_k8SLKyOPpPP) and displayed on the same screen as each policy.

Steps to configure:

1. `Source` is pre-selected to `proactive detection`
2. **Select other trigger criteria -** Choose additional conditions such as `content type`(mandatory),`label`, `custom attributes`, and all the available variables. All conditions must match; to combine them with OR or in groups, use **Advanced view** (below).
3. **Set up AI detection **by selecting the Provider and the model(s) to utilise. For multiple models, users can use the `AND / OR `operator. After this, users can select the different thresholds for detection, resulting in:
   1. 🟢 for cases to dismiss
   2. 🟠 for cases to send to queues
   3. 🔴 for cases where the selected policy will be automatically enforced.
4. **Assign Policy - **choose which policy/sub-policy applies for 🔴 cases (pre-filled if set from the Policies screen).
5. **Assign Queue **for cases that will be selected as 🟠

:::hint{type="info"}
Trigger criteria support matching operators including **equals**, **does not equal**, **contains**, and **does not contain**. The negated operators (**does not equal**, **does not contain**) let you build rules that exclude a specific value or a list of values — for example, matching content that is *not* in a given set of languages.

When a custom attribute arrives as a list of values, **contains** matches if at least one of those values is in the criterion's list. For example, a criterion `categories contains ["spam", "scam"]` matches a report sent with `categories = ["scam", "other"]`.

**Label** and list-type custom attributes can be used in more than one condition of the same rule, each with its own operator and value — for example, `Label contains misrepresentation` AND `Label does not contain spam`. All other criteria can be used once per rule.
:::

::Image[]{src="https://api.archbee.com/api/optimize/ijRmXIIrObJhIfPMa8rmJ/c4dPE6qQtWUV51FTnV8t4_image.png" size="50" width="1438" height="804" position="center" darkWidth="1438" darkHeight="804" showCaption="false"}

On screen the three zones are labelled by what they do, rather than by colour:

| Zone | Label in Nima                      | Outcome                                       |
| ---- | ---------------------------------- | --------------------------------------------- |
| 🟢   | **No Policy Violation**            | The case is dismissed                         |
| 🟠   | **Requires human review**          | The case is sent to the queue you assign      |
| 🔴   | **Automated policy reinforcement** | The assigned policy is enforced automatically |

The three zones are set with a single slider that has two handles. Drag both handles to the same point to remove a zone, leaving only two. Depending on your goals, you can use only:

- 🟢 and 🟠: dismiss non-issues or send flagged content to queues
- 🟢 and 🔴: dismiss non-issues or automatically enforce policy
- 🟠 and 🔴: route all flagged content either to queues or automatic enforcement

### Queue routing rules

Queue routing rules are associated to one of your [Queues](docId\:AzSiicK6eEHFlzwytQL-V) and displayed on the same screen.

Steps to configure:

1. **Select the **`Source` among the different options, including User Report, User Report Illegal Content, LEA, Trusted Flaggers.
2. **Select other trigger criteria:** Choose additional conditions such as `content type`, `label`, `custom attributes`, and all the available variables.
3. **Assign the queue **to which the content matching the criteria will be redirected

In case you want to pre-assign policies** --> **Enable the toggle "Automatically apply policy or workflow action" to automatically apply a policy on intake.

::Image[]{src="https://api.archbee.com/api/optimize/ijRmXIIrObJhIfPMa8rmJ/g80Jn5bruQc1vvYoeub3j_image.png" size="50" width="1440" height="814" position="center" darkWidth="1440" darkHeight="814" showCaption="false"}

##

### Advanced View

By default, a rule's conditions form a single list that must all match. When a rule needs alternatives ("match this **or** that"), groups of conditions, or exclusions, turn on the **Advanced view** toggle next to the **Conditions** heading and write the conditions as one expression. Advanced view is available for both proactive detection and queue routing rules.

Instead of keeping several near-identical rules that differ by one condition, you can write them as a single rule:

:::BlockQuote
channel == "Proactive Detection"
and content\_type == "Image"
and (account\_verified == false or (follower\_count \< 100 and account\_age\_days \< 7))
and not label in \["Spam"]
:::

| Write   | Meaning                                         |
| ------- | ----------------------------------------------- |
| and     | both sides must match                           |
| or      | either side can match                           |
| not     | excludes what follows                           |
| ( )     | groups conditions so they are read together     |
| "text"  | a single value                                  |
| \[a, b] | several values; matches if any one of them does |

The operators available depend on the attribute type:

| Attribute type     | Operators             |
| ------------------ | --------------------- |
| Text, True / False | ==, !=, in, not in    |
| Number, Date       | ==, \<, >, in, not in |
| List               | in, not in            |

Dates are written as YYYY-MM-DD. Built-in attributes are channel (Source), label (Input Labels), content\_type, country, priority and status; custom attributes are referenced by their name. A rule targets a single content type, so content\_type always takes one value with ==. Attributes of the Reporting Account, Reported Account or content appear as reporter.…, reportee.… and content.….

The editor helps you write and check the expression:

- **Ctrl + Space** suggests attributes and values as you type.
- **Reference** lists the syntax and every attribute you can use, with a search.
- **Preview** shows how the rule reads in plain language.
- **Reformat** tidies the layout of the expression.

Errors are highlighted as you type, and the rule cannot be saved until they are fixed. A proactive detection rule must include channel == "Proactive Detection".

:::hint{type="warning"}
Switching from Normal view to Advanced view converts your conditions into an expression. Switching back only keeps them if the expression is a simple list joined by and; otherwise every condition is cleared. A rule that uses or can still be viewed in Normal view, but only edited in Advanced view.
:::

## How to prioritise rules in Nima

As multiple rules can have the exact same criteria,**&#x20;Nima allows users to choose how they are prioritised in the Rules tab, by simply dragging and dropping the different rules.**&#x20;

By ranking rules, you are setting what rules with same criteria are hit first by content entering Nima.

**Order only matters where criteria overlap.** Two rules that can never match the same content are unaffected by their relative position. Where they can both match, the higher rule wins and the lower one never runs.

*Example:* one rule routes all image content to a general review queue, and a second routes image content carrying the label `nudity` to a specialist queue. If the general rule sits higher, the specialist rule never fires — an image with that label matches the general rule first. Placing the more specific rule above the general one gives the outcome you expect.

:::hint{type="warning"}
**Your ranking is saved as soon as you drop a rule** — there is no separate save step. Nima confirms with "Rule order updated successfully".
:::

**The default rule always runs last.** Every instance has a default rule that catches content matching no other rule. It sits at the bottom of the list, cannot be dragged, reordered or edited, and stays there however you rearrange the rules above it. Treat it as the fallback rather than something you tune.

From the same page, **users can also create new rules and edit pre-existing rules.**

Finally, the Rules tab is where users can get a full overview of how automated rules have been mapped to policies.

To control the order in which cases already sitting in a queue are served to moderators — a separate question from which rule matched — see [Prioritisation Engine](docId\:jQGkZZnGEonnuJ8xbSIbW).

## Testing rules before you go live

The **Test Rules** button on the Rules page opens a playground where you can submit sample content and see exactly how your configuration would handle it, without sending anything through your live pipeline.

Choose a content type, provide the text or a content URL, and run the test. Nima shows you:

- the **outcome** — No Rule Violation, Sent to queue, or Automated Enforcement
- the **rule that matched**, and which of its criteria matched
- the **AI provider** that ran and the confidence score it returned
- the **policy** that would be applied

This is the fastest way to confirm a new rule behaves as intended, and to diagnose the common surprises: a rule that never fires because a broader rule sits above it, or a threshold set tighter than the scores your provider actually returns.

:::hint{type="info"}
Test Rules is in Beta and is not switched on for every instance. If you do not see the button, contact the Tremau Support team.
:::

::Image[]{src="https://api.archbee.com/api/optimize/ijRmXIIrObJhIfPMa8rmJ/rVG8PDgFIHybIrfYvySdP_screenshot-2025-12-30-at-160602.png" size="50" width="2920" height="1495" position="center" darkWidth="2920" darkHeight="1495" showCaption="false"}

## Measuring a proactive detection rule

Once a proactive detection rule is live, open **View performance report** on its rule card to see what it has been doing. The report covers the time range you pick (the last 30 days by default) and shows:

- **Triggers** — how many times the rule matched a report.
- **Outcomes** — the share and volume of matched content that was auto-actioned, auto-dismissed, reviewed in a queue with a policy violation, reviewed in a queue with no policy violation, or is still waiting in a queue.
- **Rule effectiveness** — moderators' time saved, plus the appeal rate, number of appeals and overturn rate for the rule's decisions.

A rule that sends a lot of content to queues that is then closed as **No Policy Violation** is mostly creating queue workload, and is a good candidate for tighter criteria or thresholds. **See all detection metrics**opens the full detection analytics.

:::hint{type="info"}
💡The performance report is not switched on for every instance. If you do not see it on your rule cards, contact the Tremau Support team.
:::