> ## 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 Versions

> Versions represent snapshots of your rules. Understand the version lifecycle from draft to deployment.

## What is a Policy Version?

A **Policy Version** is a snapshot of rules within a policy group. It follows a strict lifecycle — similar to a Git branch that gets merged and tagged as a release.

Each version has:

* A **version number** (auto-incremented: v1, v2, v3…)
* A **commit message** describing what changed
* A **status** that determines what you can do with it
* Zero or more **rules** (conditions + actions)

## Version Lifecycle

```
DRAFT → ACTIVE → ARCHIVED
           ↓
       EXPIRED (auto)
```

| Status     | Can Edit Rules? | Can Deploy? | Description                                                  |
| ---------- | :-------------: | :---------: | ------------------------------------------------------------ |
| `DRAFT`    |        ✅        |      ❌      | Work in progress. Add, modify, delete rules freely.          |
| `ACTIVE`   |        ❌        |      ✅      | Published and locked. Ready for deployment.                  |
| `ARCHIVED` |        ❌        |      ❌      | Superseded by a newer version. Read-only history.            |
| `EXPIRED`  |        ❌        |      ❌      | Past its `effectiveTo` date. Auto-transitioned by scheduler. |

<Info>
  Publishing a version (`DRAFT → ACTIVE`) locks it permanently. You cannot add, modify, or delete rules in a published version. If changes are needed, **clone** the version to create a new DRAFT.
</Info>

## Key Constraints

1. **Cannot publish without rules.** A version must have at least one rule before publishing.
2. **Cannot modify after publishing.** Once ACTIVE, the version is immutable.
3. **Cannot deploy a DRAFT.** Publish first, then deploy.
4. **Always dry-run before publishing.** Validate rule behavior against test inputs.

## Cloning a Version

When you need to iterate on a published version:

1. Select the ACTIVE version you want to base changes on
2. Click **Clone** — this creates a new DRAFT with all the same rules. The effective date range is intentionally **not** copied: a version's serving window is a statement of intent, and each new version must declare its own.
3. Modify rules in the new DRAFT
4. Dry-run → Publish → Deploy

Cloning preserves the full rule set, so you only need to change what's different.

## Effective Date Range

Versions can optionally have `effectiveFrom` and `effectiveTo` dates, and the scheduler enforces both ends of the window — every automatic action is recorded in the deployment ledger:

* **`effectiveFrom` in the future** — the version cannot be deployed immediately (`P-037`), but it can be armed as a [Scheduled Deployment](/guides/deployments#scheduled-deployment): the system deploys it automatically when the window opens.
* **`effectiveTo` passes while live** — the version transitions to `EXPIRED` and the system falls back to the latest currently-valid ACTIVE version, recorded as a **System** deployment. If no valid candidate exists, the group is undeployed — also recorded.

This makes time-bound promotions self-managing on both ends: they start and stop on schedule, with a full audit trail.

## Next Steps

<CardGroup cols={2}>
  <Card title="Policy Rules" icon="list-check" href="/guides/policy-rules">
    Learn how to define conditions and actions within a version.
  </Card>

  <Card title="Deployments" icon="rocket" href="/guides/deployments">
    Learn how to push versions to production.
  </Card>
</CardGroup>