--- title: Glossary slug: glossary docTags: createdAt: 2026-01-07T11:54:14.762Z --- This page is your go-to reference for clear, consistent terminology. It defines the core concepts and terms we use throughout Nima and this documentation. | **Concept** | **Definition** | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Account Action** | Any action applied directly to an account (e.g., warn, strike, suspend). | | **Account History** | The historical record of all cases related to a specific account, including past reports, violations, account-level enforcement, current and expired strikes, and appeals. This can also include custom fields relevant to each platform, such as verified status. | | [Account Strike System](docId\:iMkSiySjEwZVi5nE93O7N) | Nima enables platforms to configure their own automated strike system, building upon individual content violations all the way to account bans, taking into account a range of severity and actions. The system includes configurable strike expiration times. | | [Actions](#) | What is applied after a moderation decision, such as removing content, restricting visibility, suspending an account, or issuing a warning. | | **Action Configuration** | Configuration mapping policies/sub-policies to the actions triggered when violations occur. | | **Appeal** | A request to reconsider a moderation decision | | **Appeal Date** | The date when the appeal was submitted by the appellant (either Reporter or Reportee). | | **Appeal ID** | The unique identifier assigned to each individual appeal submitted in Nima. | | **Audit Logs** | The full collection of all audit log entries over time. | | **Automated Enforcement** | The threshold of the rule engine within which a policy is automatically enforced and therefore the associated action is triggered. | | **Case** | A case is a record created in Nima for potentially violative content reported one or several times. Multiple reports on the same content will be grouped under the same case. A case corresponds to a single parent content\_id. In the case of a collection of files, a case will have a single parent content\_id and multiple child content\_ids that will not vary across different reports. | | **Case Handling Time** | The time between a case being presented to a moderator and that case being effectively processed. | | **Case Response Time** | The time duration from the moment a case enters Nima until it is resolved. This measure is usually not communicated externally. | | **Confidence Score** | The probability returned by AI detection engines when reviewing a content. | | **Content** | The user-generated item under review (e.g., text, image, video, listing, message). It is a single piece of content that can be subject to multiple reports. Therefore, multiple cases and case\_IDs can pertain to a single piece of content. | | **Content Action** | Actions that specifically affect content items (e.g., remove, blur, limit visibility). | | **Content History** | The versioned record of all changes, actions, and states of a content item. | | **Content ID** | The unique identifier assigned to a piece of content. Multiple reports on the same content correspond to the same content\_ID. | | **Content Type** | The format of the content being moderated, such as text, image, video static, or video stream. | | **Criteria** | The conditions used in the Rule engine when setting up tules | | [Custom Attributes](#) | Configurable metadata fields attached to cases, reporters, reportees, or content for workflow and analytics purposes. | | **Escalation** | Routing a case to a higher-level queue or specialized team due to sensitivity or severity. | | **Escalation Queue** | A queue dedicated to escalated cases requiring experienced or specialized review. | | **Event Logs** | A time-stamped record of everything that happens to a particular flagged case. | | **Post-Appeal Action** | The action applied at the end of a case or appeal review, which may differ from the initial action. | | **Illegal Content User Report** | A user report alleging that content violates the law, submitted through the Nima Illegal Content Reporting Form. | | **Infringement Categories** | Categories set by the EU Commission and matched to policies in Nima to automatically compile the DSA Transparency Report. | | **Initial Action** | In the Appeal List, the action originally applied before the appeal was submitted. | | **Initial Policy Violation** | In the Appeal List, the Policy or Sub-policy selected during the first moderation decision before any potential appeal or reevaluation. | | **Input Label** | The category or descriptor assigned to the alleged violation by a reporter when compiling a form or an AI detection provider through automated detection. | | **Max Handling Time in Queue** | The maximum amount of time a case may remain in a queue before breaching SLA. | | **Move to Queue** | Moderators working on a report in a queue can manually move this report to another standard queue. | | **Overturn** | A review outcome in appeals in which the original moderation decision is reversed. | | [Policy Configuration](#) | Configuration of policies, sub-policies, descriptions, and mapping to actions or tiers. | | **Policy Description** | The policy or sub-policy rationale or summary, describing the type of violative content or behavior that is covered. | | **Policy Violation** | A confirmed violation of a given policy or sub-policy. | | **Policy** | A high-level content moderation guideline defined by your platform that specifies what types of content or behavior are prohibited. Policies represent broad categories of violations (e.g., "Hate Speech", "Violence", "Spam") and are the foundation of enforcement in Nima, either applied through proactive detection rules or selected by moderators when reviewing content. | | **Sub-policy** | Sub-policies provide detailed breakdowns of policies (e.g., under "Hate Speech" policy, sub-policies might include "Racial Slurs", "Religious Intolerance", "Gender-based Harassment"). If a policy has subpolicies, these will be applied through proactive detection rules or selected by moderators when reviewing content. | | **Priority Score** | Based on configurable criteria, a priority score is calculated for each report to prioritize it in the content review queue. | | [Proactive Detection](#) | Nima's automated detection uses AI/ML systems to identify potential violations without requiring initial human review. When integrated as an ingestion channel, these systems trigger automated workflows via the Rule Engine. This engine features a centralized AI Marketplace, allowing users to easily select and manage various detection providers. | | **Proactive Detection Provider** | A third-party or internal AI detection engine that detects content proactively and triages it based on the rules set in the Rule engine. | | **Proactive Detection Rule** | A rule that automatically performs moderation actions or routing based on defined conditions. | | [Quality Control](#) | Nima's Quality Control system helps maintain consistency and accuracy in moderation decisions by providing data analytics, performance metrics, and audit capabilities for both human moderation and automated enforcement. It enables teams to review moderation decisions and continuously improve it. | | [Queues](#) | Queues contain reports pending review and can be manually configured. Queues can have different prioritization models based on the severity of the content and can be assigned to specific groups of moderators. | | **Queue Routing Rule** | Rule defining how cases ingested in Nima through different channels (excluding automated detection) are redirected to queues. | | **Reply Status** | In an appeal assessment, moderators may message the appellant for clarification or additional information. Reply Status records two things: whether the appellant has replied to that initial moderator message, and whether the appellant's message has been marked as read. | | **Report** | A flagged instance of potentially violative content submitted to Nima for review. Reports can originate from multiple sources: user reports (via your platform's reporting flows or the Nima Illegal Content Reporting Form), proactive detection (AI/ML automated detection), trusted flaggers, or law enforcement agencies. Each report indicates a potential policy violation and creates or contributes to a case for moderation review. | | **Reported Account** | The user whose content or behavior is being reported. | | **Reported Account Custom Attributes** | Custom metadata relating to the reportee or their content. | | **Reporting Account** | The person or entity submitting a report. | | **Reporting Account Custom Attributes** | Custom attributes relating to the reporting account (e.g., trusted flagger status). | | **Reset Time** | The time after which a previous violation expires within a Tier of the Account Strike System, so that it no longer counts towards escalation. Set in days, on each step of a tier individually. | | **Roles** | Permission profiles determining what capabilities a user can access within Nima. | | **Service Level Agreement (SLA)** | The target maximum time allowed for resolving a case, set up for each Standard or Escalation Queue. | | **Signal** | The outcome (e.g., a probability score) sent by an internal detection tool to Nima. | | **Source** | The channel of a report or detection (e.g., automated detection, user report, LEA form, illegal content report form). | | **Standard Queue** | A standard queue receives incoming reports from users or through automated detection. Reports in a standard queue can be manually moved by a moderator to another standard queue, or automatically re-routed to an escalation queue. | | **Team** | Defined groups of moderators or reviewers assigned to queues. | | **Threshold** | When setting up rules, users can set and edit thresholds for automatically actioning content, sending it to human review, or taking no action. | | **Tier** | When configuring the account strike system, each tier corresponds to the severity of the policy violation. For example, a single Tier 1 violation may lead to the permanent ban of a user from the platform. Users match tiers to policies in Policy Configuration. | | **Trails** | A report trail contains all logs related to a report, such as actions taken, appeals, etc. | | **Trusted Flagger Report** | A report submitted by an accredited or designated entity recognized for high-quality reporting through the Nima Illegal Content Reporting Form. | | **Uphold** | When reviewing a user appeal, the decision to uphold the original action means that the original moderation decision was correct. | | **User Notifications** | Communications sent to users regarding actions taken on their content or account or to reporters following the action on their reports. These include DSA Statement of Reasons but can be sent for any action taken in Nima. | | [User Reports](#) | A report submitted by users using either the platform's own reporting flows or through Nima's Illegal Content Reporting Form. User reports can be configured to be routed to specific queues. | | **Workflow Action** | An action that is not linked to a policy or policy violation, such as no action, unlock content, or unlock user. |