> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whitecircle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Strike System

> Set up strike severity, actions, metadata, and appeals

export const domain = 'https://eu.whitecircle.com';

Striking turns policy violations into user-level actions. Use it after you have a deployment and the policies you want to score.

## Prerequisites

Before you configure striking, make sure you have:

* [Deployment](/2026-04-15/first-steps/deployments) with the policies you want to score
* [Policies](/2026-04-15/first-steps/policies) with the right flagged content
* [User metadata](/2026-04-15/session/metadata) in your content checks
* A plan for how your app will apply the resulting action

<Warning>
  White Circle does not enforce account restrictions directly. Your application must apply the returned action state to your users.
</Warning>

## Set it up

<Steps>
  <Step title="Set severity levels">
    Open the <Link href={`${domain}/policies`} target="_blank">Policies page</Link> and assign each policy a severity level: `Critical`, `High`, `Medium`, or `Low`.

    Use severity to express how much a violation should contribute to a user's strike history.
  </Step>

  <Step title="Review actions">
    Decide which effective actions your app will honor.

    You can keep the default actions (`none`, `throttle`, `warn`, `suspend`, `ban`), delete some of them, or define your own custom actions.

    Keep the thresholding simple so support and moderation teams can explain the result quickly.
  </Step>

  <Step title="Submit user metadata">
    Include [stable identifiers](/2026-04-15/session/metadata) in `metadata.user` on content checks so White Circle can connect sessions, strikes, and appeals to the same user.

    ```json theme={null}
    {
      "metadata": {
        "user": {
          "id": "user-123",
          "email": "user@example.com",
          "ip": "203.0.113.10"
        }
      }
    }
    ```
  </Step>

  <Step title="Check created actions">
    Use [Risk Scoring](/2026-04-15/user/radar) to inspect the current action and strike history, or subscribe to [Webhooks](/2026-04-15/integrations/webhooks) for `strike.action.updated` and `strike.action.expired`.
  </Step>
</Steps>

## How striking works in production

Once configured, the strike system runs as a loop:

1. You send content checks with stable user identifiers.
2. White Circle evaluates policy violations and updates strike state.
3. White Circle calculates the current effective action for that user.
4. Your application applies that action and keeps it in sync over time.

## How points and actions are calculated

Use these rules to understand exactly how strike points become user actions:

1. If a session has multiple violations, only the violation with the highest severity contributes points for that session.
2. A strike contributes points until the strike expiration time configured in that severity level.
3. White Circle sums only active strike points for each user.
4. When the sum of active points exceeds an action threshold, that action is applied to the user.
5. The action expiration time is the later of the configured action duration or the moment when active points drop below that action's threshold.
6. Permanent actions never expire.
7. Severity-level and action configuration changes are not retroactive. Existing strikes and actions stay unchanged, and updated settings apply only to new strikes and actions.

### Worked example timeline

Assume your setup is:

* `Critical` = 10 points, strike expires in 30 days
* `High` = 6 points, strike expires in 14 days
* `Medium` = 3 points, strike expires in 7 days
* `Low` = 1 point, strike expires in 3 days
* `Warn` threshold = 6 points, configured duration = 24 hours
* `Suspend` threshold = 10 points, configured duration = 3 days
* `Ban` threshold = 20 points, permanent

| Time          | Event                                             | Points change         | Active points | Effective action         | Why                                                                  |
| ------------- | ------------------------------------------------- | --------------------- | ------------- | ------------------------ | -------------------------------------------------------------------- |
| Day 0, 10:00  | Session A has `Medium` and `High` violations      | +6 (`High` only)      | 6             | `Warn`                   | In one session, only the highest severity is counted.                |
| Day 2, 12:00  | Session B has `Critical` and `Low` violations     | +10 (`Critical` only) | 16            | `Suspend`                | Active points exceed the `Suspend` threshold (10).                   |
| Day 5, 12:00  | `Suspend` configured duration (3 days) is reached | 0                     | 16            | `Suspend` remains active | Action does not expire yet because points are still above threshold. |
| Day 14, 10:00 | Day 0 `High` strike expires                       | -6                    | 10            | `Suspend` remains active | Points are still at the threshold.                                   |
| Day 32, 12:00 | Day 2 `Critical` strike expires                   | -10                   | 0             | `None`                   | Points drop below thresholds, so the action ends.                    |

In this example, `Suspend` lasts until Day 32, not Day 5, because action expiration uses the later of:

* configured action duration, and
* the moment active points drop below the threshold.

If `Ban` is applied, it never expires automatically.

<Info>
  Configuration updates are not retroactive. Existing strikes and actions keep their original values, and new settings apply only to new strikes and actions.
</Info>

The most common integration pattern is:

* Use [Check Content](/2026-04-15/session/check-session) for normal moderation traffic.
* Use [Create Strike](/2026-04-15/user/create-strike) when you need to add strikes directly from your own workflows.
* Use [Risk Scoring](/2026-04-15/user/radar) to fetch the current action and full strike history.
* Use [Webhooks](/2026-04-15/integrations/webhooks) to react to real-time action changes (`strike.action.updated`, `strike.action.expired`).

### Core endpoints

<CardGroup cols={3}>
  <Card title="Check Content" icon="shield-check" href="/2026-04-15/session/check-session">
    Evaluate user/assistant content and generate policy violations.
  </Card>

  <Card title="Create Strike" icon="plus" href="/2026-04-15/user/create-strike">
    Add a strike directly when your internal workflow requires manual insertion.
  </Card>

  <Card title="Risk Scoring" icon="user" href="/2026-04-15/user/radar">
    Read current action, strike points, and strike timeline for a user.
  </Card>
</CardGroup>

## Appeals

Use appeals to let users challenge strikes and route those challenges to your reviewers.

### Endpoints

<CardGroup cols={2}>
  <Card title="Create Appeal" icon="plus" href="/2026-04-15/user/create-appeal">
    Create a new appeal for a strike.
  </Card>

  <Card title="Get Appeal" icon="magnifying-glass" href="/2026-04-15/user/get-appeal">
    Retrieve current appeal status and reviewer outcome fields.
  </Card>
</CardGroup>

### Strike relationship

An appeal does not replace the strike record. It adds workflow state to the strike so you can show whether the strike is under review, resolved, or canceled.

When an appeal changes strike impact, refresh the user state with [Risk Scoring](/2026-04-15/user/radar) and apply updated restrictions in your own system.

### Typical flow

1. Create a strike with [Create Strike](/2026-04-15/user/create-strike) or via session checks.
2. Let the user submit an appeal with [Create Appeal](/2026-04-15/user/create-appeal).
3. Review the appeal in your tooling and track status with [Get Appeal](/2026-04-15/user/get-appeal).
4. If outcome changes enforcement, consume webhook updates and apply the new action to the user account.

## Next steps

<CardGroup cols={2}>
  <Card title="Risk Scoring" icon="user" href="/2026-04-15/user/radar">
    See the user-level strike response and appeal data.
  </Card>

  <Card title="Webhooks" icon="webhook" href="/2026-04-15/integrations/webhooks">
    Sync effective actions and strike changes in real time.
  </Card>
</CardGroup>