> For the complete documentation index, see [llms.txt](https://docs.lassomoderation.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lassomoderation.com/moderator-toolkit/policy-categories.md). # Policy Categories A policy category is the reason attached to a moderation decision. When a moderator removes a post, when a rule flags a user, or when an AI Moderator hides a comment, the policy category records which of your guidelines was broken, for example "Harassment", "Spam" or "Underage Protection". Policy categories are what turn a pile of moderation actions into something you can report on and automate against. They also travel outside Lasso: every category has an identifier that your platform receives in [webhooks](/developers/webhooks.md) and sends back through the API when your users file a report. {% hint style="info" %} The **Policies** page holds two related things. **Categories** are the short reasons described here. A **policy** is the written policy document your AI Moderators read. Categories can be added to a written policy so an AI Moderator can pick them, but they work on their own for human moderators and rules. {% endhint %} ### What you can use them for * Record why each decision was taken, so an action taken today is still explainable months later. * Report on what your moderators actually deal with, in **Analytics → Reports** and **Analytics → Reviews**. * Drive automation: a rule can apply a category, and routing rules can send everything flagged under one category to a specialist queue. * Give your users a list of report reasons that stays in sync with the dashboard. * Tell your platform *why* something was removed, through the `policy_id` field in webhooks. * Meet compliance obligations: a category can be configured to file [DSA reports](/compliance/dsa-compliance/setup.md) automatically. ### Where to find them Policy categories live under **Policies** in the sidebar, in the **Categories** section ("Manage your policy categories"). The table lists every category in your workspace, sorted alphabetically, with its name, its **Policy Category ID**, which types and actions it applies to, its hotkey, the number of rules using it and whether it is available in user reports. ### Creating a policy category 1. Go to **Policies** and click the button to add a category. 2. Fill in the **Policy Category Name** (placeholder: "E.g. Inappropriate Content"). Names are limited to 40 characters. 3. Click **Create new policy category**. The settings dialog opens straight away so you can finish configuring it. Two things worth knowing about names: * The name determines the **Policy Category ID**, which is the identifier used everywhere outside the dashboard. "Inappropriate Content" becomes `inappropriate-content`. Renaming a category later does **not** change its ID, so your integration keeps working. * Because the ID is derived from the name, two names that produce the same ID are the same category. Creating "Spam!" when "Spam" already exists reuses the existing category instead of creating a second one. You may also see a category appear that nobody created: **Revert Action**. Lasso adds it the first time your platform rejects a status change through a webhook and Lasso reverts its own decision. ### Category settings Click any row in the Categories table to open **Policy Category Settings**. **Information** * **Name** and **Description**. The description is guidance for whoever picks the category: "This information helps users understand when to select this policy category while submitting a user report." It is up to 400 characters, and it is returned by the user reports API, so it is worth writing properly for anything your users can pick. * **User Reports**: "Can this policy category be selected when users are reporting content or other users?" Off by default. See [user reports](/automation-and-review/user-reports.md). **Settings** * **Hotkey**: "Use this hotkey to quickly apply this policy category to content." Pick a digit from `0` to `9` and pressing it in the action dialog selects that category. Each digit can only be used by one category, so up to ten categories can have one. * **Policy can be selected by**: "Can this policy category be selected by moderators or rules?" Choose **Moderators & Rules**, **Only Moderators** or **Only Rules**. Use **Only Rules** for internal bookkeeping categories you do not want your team choosing by hand, and **Only Moderators** for judgement calls you never want automated. * **Available for types**: "For which types can this be used as a policy category?" Either **All**, or one specific object type (content, users or subcategories, under whatever names your workspace uses). A user-only category like "Repeat Offender" will not clutter the dropdown when a moderator is acting on a post. * **Enabled for actions**: "For which of the actions can this be used as a policy category?" A checkbox per action, using your workspace's own wording for allow, flag and remove, plus **Strikes** if [strikes](/managing-users/strikes.md) are enabled. Untick the ones that make no sense, for example an "Approved" category that should only ever be used when allowing content. The dialog also has a collapsible **Rules with this policy category** section listing every rule that applies it, or "No rules tied to this policy". Click **Update** to save. If your workspace has multiple languages enabled, the Name and Description fields appear once per language and are translated automatically when you create a category. You can correct any translation by hand. If you have the Sift integration, a **Sift Decision** field lets you map the category onto a decision in Sift. Lasso forwards it when a user's status changes. ### Using categories while moderating Wherever a moderator takes an action, the confirmation dialog has a **Policy category** field with the placeholder "Select policy category". Only categories that fit are offered: the object type has to match, the action has to be enabled on the category, the category has to be selectable by moderators, and, in a review queue, the category has to be allowed in that queue. Under **Settings → Moderation preferences** you can make this smoother: * Set a **default policy category** per action, so the right one is preselected. Once a default is configured, moderators can Shift+Click an action button to act without opening the dialog at all. * Make a category **required** for a given action, so no decision is recorded without a reason. Both are configured separately for content, users and subcategories. See [user moderation](/managing-users/user-moderation.md) for the user side.
### Categories in rules Every rule action that changes a status can carry a policy category, chosen with the **Policy Category** field on the rule. That is how automated decisions end up as explainable as manual ones. A rule that bans a user and removes their content can set a separate **Policy Category Content** for the removals. Rules count as automation rather than a moderator, so a category set to **Only Moderators** cannot be attached to a rule. Categories are also something rules can match on. Routing rules for [review queues](/automation-and-review/review-queues.md) have a **Policy Category** condition ("Condition based on the policy category it got flagged for") with `is in` and `is not in` operators, so you can send everything flagged under your child safety category to a dedicated queue. When you export and import [custom moderation rules](/automation-and-review/custom-moderation-rules.md) between workspaces, categories are carried by their ID. Any category the target workspace is missing is created automatically, and the import warns you that it did so. ### Categories in review queues A review queue can be limited to a subset of categories. On the queue, untick **All policies are available in this queue** and pick the ones you want under **Policies available in this queue**. Moderators working that queue then only see those categories in their action dialog. ### Categories in user reports Categories with **User Reports** ticked are the reasons your own users choose from when they report something. `GET /api/v1/user-reports` returns them (id, name, description and, with translations enabled, a `translations` object), and you send the id back as `policy_id` when submitting the report. Full details are on the [user reports](/automation-and-review/user-reports.md) page. ### Categories and AI Moderators An AI Moderator decides using a written policy, and the sections of that policy are your policy categories. Add a category to a policy document, write the guidance for it there, and the AI Moderator can judge content against it and apply that category to its decisions, along with a short explanation of its reasoning. A category that is not part of the written policy, or that is in it but has no text, is invisible to the AI Moderator. It still works normally for moderators and rules. ### Categories in the API and webhooks There is no endpoint for creating or listing all your policy categories. They appear in the API in two places, and always by their **Policy Category ID**, never the display name: * `POST /api/v1/user-reports` takes `report.policy_id`. An unknown value returns a `400` with `Policy not found`. * `POST /api/v1/status` takes an optional `policy_id`, so a decision your own platform makes is recorded with the same reason your moderators would use. An unknown value here is ignored silently and the status change still goes through, so check your spelling. On the way out, every action [webhook](/developers/webhooks.md) that has a category attached carries: | Field | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------ | | `policy_id` | The Policy Category ID, for example `inappropriate-content`. | | `policy_name` | The display name at the time of the action, for example `Inappropriate Content`. | | `policy_information` | Optional extra reasoning, filled in by AI Moderators and by decisions your platform reverts through the API. | Do not confuse `policy_id` with the `category_id` and `subcategory_id` fields inside the `content` object of the same payload. Those describe where the content lives on your platform, not why it was actioned. The full payload is documented under [webhooks](/developers/webhooks.md). ### Reporting on categories **Analytics → Reports** has **Reports by Policy**, and **Analytics → Reviews** has **Reviews by Policy**, both broken down over time and as a total for the period. Decisions taken without a category are grouped as "No policy", and decisions taken under a category that has since been deleted show as "Deleted Policy". ### Renaming and deleting Renaming is safe. The Policy Category ID stays the same, past decisions keep pointing at the category, and your integration does not need to change. Deleting is restricted. The delete button is disabled, with the tooltip "Cannot delete policy category that is used by a rule or in a policy", as long as any rule uses the category or it is part of a written policy. Remove those references first. When you do delete a category: * It disappears from every dropdown, but past actions, reports and compliance reports keep their reason. They show up as "Deleted Policy" in analytics. * Creating a category with the same name again restores the original one, hotkey, settings and history included. ### Choosing your categories Categories work best when they are few and clearly separated, so a moderator picking one under time pressure does not have to think about it. A set of eight to twelve is typical. Most platforms end up with something close to: * Harassment and Discrimination * Hate Speech and Extremism * Obscenity and Profanity * Nudity and Sexual Content * Self-Harm or Threats * Personal and Sensitive Information * Fraud and Scams * Spam * Underage Protection Add whatever is specific to your product (cheating and exploits for a game, prohibited goods for a marketplace, misrepresentation for a dating app), plus a couple of internal categories that are not really violations, such as "User Feedback" or a rules-only category for automated cleanup.