Prerequisites
Before configuring the Strike System, make sure you have:- Environment with the Policies you want to score
- Policies with the right flagged content
- Active Conditions that enable those Policies for the relevant Events
- User metadata in your Events, such as
metadata.user.id - A plan for how your app will apply the resulting action
Set it up
1
Set severity levels
Open the Policies page 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.2
Review actions
Decide which actions your application will enforce.You can keep the default actions (
none, throttle, warn, suspend, ban), remove some of them, or define your own custom actions.Keep thresholds simple so support and moderation teams can explain the result quickly.3
Submit user metadata
Include stable identifiers in
metadata.user on Events so White Circle can connect Events, strikes, and appeals to the same user.4
Review the actions
Use Risk Scoring to inspect the current action and strike history, or subscribe to Webhooks for
strike.action.updated and strike.action.expired.How striking works in production
Once configured, the Strike System works as follows:- You send content checks with stable user identifiers.
- White Circle evaluates Policy violations and updates strike state.
- White Circle calculates the current effective action for that user.
- 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:- If one checked item has multiple violations, only the violation with the highest severity contributes points for that item.
- A strike contributes points until the strike expiration time configured in that severity level.
- White Circle sums only active strike points for each user.
- When the sum of active points meets or exceeds an action threshold, that action is applied to the user.
- The action expiration time is the later of the configured action duration or the moment when active points drop below that action’s threshold.
- Permanent actions never expire.
- 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 daysHigh= 6 points, strike expires in 14 daysMedium= 3 points, strike expires in 7 daysLow= 1 point, strike expires in 3 daysWarnthreshold = 6 points, configured duration = 24 hoursSuspendthreshold = 10 points, configured duration = 3 daysBanthreshold = 20 points, permanent
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.
Ban is applied, it never expires automatically.
Configuration updates are not retroactive. Existing strikes and actions keep their original values, and new settings apply only to new strikes and actions.
- Use Check One Event or Check Multiple Events for normal moderation traffic.
- Use Create Strike when you need to add strikes directly from your own workflows.
- Use Risk Scoring to fetch the current action and full strike history.
- Use Webhooks to react to real-time action changes (
strike.action.updated,strike.action.expired).
Core endpoints
Check Events
Evaluate Messages, Tool Calls, Agent State, Reasoning, and artifacts.
Create Strike
Add a strike directly when your internal workflow requires manual insertion.
Risk Scoring
Read current action, strike points, and strike timeline for a user.
Appeals
Use appeals to let users challenge strikes and route those challenges to your reviewers.Endpoints
Create Appeal
Create a new appeal for a strike.
Get Appeal
Retrieve current appeal status and reviewer outcome fields.
Strike relationship
An appeal does not replace the strike record. It adds review 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 and apply updated restrictions in your own system.Typical flow
- Create a strike with Create Strike or via Event checks.
- Let the user submit an appeal with Create Appeal.
- Review the appeal in your internal tools and track status with Get Appeal.
- If the outcome changes enforcement, consume webhook updates and apply the new action to the user account.
Next steps
Risk Scoring
See the user-level strike response and appeal data.
Webhooks
Sync effective actions and strike changes in real time.
