---
title: Policies
description: Policies are the rules that turn checks into a verdict. A policy is a tree of conditions plus an action: when the conditions match, the action becomes the verdict.
---

# Policies

A policy is a rule that turns [checks](/docs/v3/concepts/checks) into a [verdict](/docs/v3/concepts/verdicts). It's a tree of conditions plus an action: when the conditions match an [evaluation](/docs/v3/concepts/evaluations), the action becomes the verdict.

Policies are the v3 replacement for v2 environments. Where v2 leaned on fixed environment thresholds, v3 lets you write your own AND/OR conditions over any check and pick the [verdict](/docs/v3/concepts/verdicts) to apply.

## Anatomy of a policy

- **Name and description**: for your own reference in the dashboard.
- **Type**: `development` or `production`. A development policy is evaluated only for traffic from a development API key, and a production policy only for production keys. That lets you test rules without touching live traffic.
- **Enabled**: turn a policy on or off without deleting it.
- **Event types**: which [actions](/docs/v3/concepts/actions) the policy applies to: `login`, `signup`, or `access`.
- **Conditions**: a nested AND/OR tree of comparisons over checks, lists, and metadata.
- **Action**: the [verdict](/docs/v3/concepts/verdicts) to produce when the conditions match.
- **Priority**: decides which policy wins when more than one matches. The highest-priority match takes effect.

## What conditions can check

Condition fields line up with the [check](/docs/v3/concepts/checks) inventory, grouped by category:

- **Device**: `device_count`, `computer_device_count`, `tablet_device_count`, `mobile_device_count`, `device_id`.
- **Network**: `impossible_travel`, `is_new_ip`, `ip_country`, `ip_is_vpn`, `ip_is_proxy`, `ip_is_tor`, `ip_is_hosting`, `concurrent_sessions`.
- **User**: `is_new_user`, `is_email_verified`, `is_phone_verified`, `user_age_days`, `is_suspended`, `in_list` (see [Lists](/docs/v3/concepts/lists)), `user_external_id`, `user_email`, `metadata`.
- **Email**: `email_is_disposable`, `email_is_webmail`, `email_is_invalid`, `email_is_accept_all`.
- **Fingerprint**: `is_new_fingerprint`, `fingerprint_user_count`.
- **Velocity**: `event_count` over a sliding window.
- **Device integrity** (native SDKs): `jailbroken_ios`, `rooted_android`, `is_simulator`, `is_emulator`, `debugger_attached`, `ui_testing`.
- **Group**: `group`, the user's assigned group (if you use groups).

Conditions match on [checks](/docs/v3/concepts/checks), not [risks](/docs/v3/concepts/risks). Risks are scored separately and recorded on the evaluation for review. Matching a policy directly on a risk score or severity is coming soon.

## How matching works

When an [evaluation](/docs/v3/concepts/evaluations) runs, Rupt walks every enabled policy whose `type` matches the calling API key's environment and whose event type matches the action, in `priority` order, and tests each one's conditions against the derived checks. The highest-priority match wins; ties break toward the older policy. Order your rules so the most specific ones sit above the broad catch-alls.

The winning policy's action becomes the evaluation's [verdict](/docs/v3/concepts/verdicts). If nothing matches, the verdict is `allow`.

## Practical guidance

- Start broad and narrow as you learn. A first `login` policy that challenges when `impossible_travel` is true catches a lot with very few false positives.
- Reach for specific checks when you want a surgical rule: deny on `is_simulator` in native flows, or challenge once `device_count` crosses a threshold.
- Keep development and production policies separate by `type`. The dashboard shows both side by side, and only the set matching the calling key is evaluated.