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
| 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. |
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.Key Constraints
- Cannot publish without rules. A version must have at least one rule before publishing.
- Cannot modify after publishing. Once ACTIVE, the version is immutable.
- Cannot deploy a DRAFT. Publish first, then deploy.
- Always dry-run before publishing. Validate rule behavior against test inputs.
Cloning a Version
When you need to iterate on a published version:- Select the ACTIVE version you want to base changes on
- Click Clone — this creates a new DRAFT with all the same rules
- Modify rules in the new DRAFT
- Dry-run → Publish → Deploy
Effective Date Range
Versions can optionally haveeffectiveFrom and effectiveTo dates. When the current time exceeds effectiveTo, the scheduler automatically transitions the version to EXPIRED. This is useful for time-bound promotions or seasonal rules that should automatically deactivate.
Next Steps
Policy Rules
Learn how to define conditions and actions within a version.
Deployments
Learn how to push versions to production.