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

# Policy Groups

> A policy group is the top-level container for your business rules. Learn how to create, manage, and configure groups.

## What is a Policy Group?

A **Policy Group** is the top-level container for a set of related business rules. Think of it like a Git repository — it holds multiple versions of your rules and manages their lifecycle.

Each policy group has:

* A unique **name** (e.g., `tiered-discount`, `fraud-detection`)
* A **priority** that determines execution order when multiple groups apply
* A **status** that controls whether the group accepts traffic

## Group Status

| Status     | Description                                 | Traffic    |
| ---------- | ------------------------------------------- | ---------- |
| `ACTIVE`   | Normal operation. Rules are evaluated.      | ✅ Accepted |
| `DISABLED` | Emergency stop. All executions are blocked. | ❌ Rejected |
| `ARCHIVED` | Permanently removed from the system.        | ❌ Rejected |

<Warning>
  Disabling a group immediately stops all traffic to it. Use this as an emergency kill switch when you need to halt rule execution without modifying rules.
</Warning>

## Creating a Group

In the Console, navigate to **Policies → New Policy Group** and fill in:

* **Name**: A descriptive, unique identifier
* **Description**: What this group of rules does
* **Priority**: Lower numbers = evaluated first (0 is highest)

## Execution Mode

When multiple rules match within a group, the **Execution Mode** (`activationMode`) controls how many of them fire:

| Mode (`activationMode`) | Console Label        | Behavior                             |
| ----------------------- | -------------------- | ------------------------------------ |
| `NONE`                  | Allow All (Parallel) | All matching rules execute (default) |
| `EXCLUSIVE`             | Single Execution     | Only one winning rule executes       |
| `MAX_N`                 | Top N Execution      | Up to `executionLimit` rules execute |

When using `EXCLUSIVE` or `MAX_N` mode, the **Priority Strategy** (`activationStrategy`) determines which rules win:

| Strategy (`activationStrategy`) | Behavior                                     |
| ------------------------------- | -------------------------------------------- |
| `FIRST_MATCH`                   | First matching rule in priority order wins   |
| `HIGHEST_PRIORITY`              | Rule with the lowest priority number wins    |
| `MAX_BENEFIT`                   | Rule producing the highest output value wins |

<Info>
  Execution Mode applies at the **group level** — controlling competition between groups that share the same **Execution Group** (`activationGroup`). For rule-level conflict resolution within a single version, see [Mutex Groups](/guides/policy-rules#mutex--rule-level-conflict-resolution).
</Info>

## A/B Testing

Policy groups support A/B testing to compare two versions' performance with live traffic. To start an A/B test, you need a currently deployed (live) version, a test version (must be ACTIVE/published), and a traffic percentage to route to the test version (1–99%).

The remaining traffic continues to the live version. A/B tests produce execution logs for both versions, so you can compare their performance in the History tab.

## Next Steps

<CardGroup cols={2}>
  <Card title="Policy Versions" icon="code-branch" href="/guides/policy-versions">
    Learn how versions work inside a group.
  </Card>

  <Card title="A/B Testing" icon="shuffle" href="/guides/ab-testing">
    Set up traffic splitting between versions.
  </Card>
</CardGroup>