Skip to main content

​
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

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

  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: 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

Policy Rules

Learn how to define conditions and actions within a version.

Deployments

Learn how to push versions to production.