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
  • 0 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

A version can optionally have an effective window, from effectiveFrom to effectiveTo, and the scheduler enforces both ends of it — 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.

​
Setting the Window

  • Both ends are inclusive. The version is effective at the exact effectiveFrom and effectiveTo instants.
  • The API, CLI, and MCP tools take instants: ISO-8601 with Z or an offset, such as 2026-10-01T00:00:00Z or 2026-10-01T09:00:00+09:00. A bare date, or a time without an offset, is rejected.
  • The console reads the dates and times you pick in your organization’s timezone (Settings → Organization → Timezone). An end picked as 23:59 includes that whole minute.

​
Changing the Window of a DRAFT

An update keeps any end you leave out. To remove an end, ask for it explicitly: Sending a value and its clear flag for the same end is rejected (C-001).

​
When the End Has Passed

A version whose effectiveTo has passed can no longer be published, deployed, or rolled back to (P-058). For a DRAFT, move the end into the future. For a published version, clone it and set a new window on the clone.

​
Next Steps

Policy Rules

Learn how to define conditions and actions within a version.

Deployments

Learn how to push versions to production.