Policy Versioning
Version scheme
Policy version identifier format is:
"<counter>:<sha256-of-canonical-bundle>"
This combines strict ordering (counter) with verifiable content identity (hash). This is not semantic-version labeling and does not use compatibility labels like major/minor/patch (per policy_versioning_and_upgrade_spec.md §3.1, PV-002).
Version lifecycle
Policy lifecycle sequence is:
propose -> validate -> assign version -> activate -> archive prior
Activation is atomic. No request may observe partial policy state (per PV-003, policy_versioning_and_upgrade_spec.md §7).
Only one policy version is active at a time.
v1 deployment note This page describes the v1 local-embedded deployment. Team and enterprise deployments use
syndicate-serverand may differ in distribution and activation controls, while version identity, atomic activation, and evidence requirements remain normative.
Backward compatibility windows
Permits and approvals embed policy version at issuance time (per PV-005). Compatibility windows define whether prior-version artifacts remain eligible after activation of a new version (policy_versioning_and_upgrade_spec.md §8).
If version mismatch is incompatible, the system must produce explicit and actionable incompatibility reasons (per PV-006).
Rollback lifecycle
Rollback is a first-class governed lifecycle operation, not a special-case bypass (per PV-007).
Rollback activation increments the counter and preserves monotonic ordering. Historical counter values are not reused (policy_versioning_and_upgrade_spec.md §14.2).
Old evidence remains valid
Policy upgrades and rollbacks do not invalidate historical evidence. Events, approvals, and permits recorded under prior policy versions remain readable and replayable with embedded version context (per PV-004).
Policy version in the audit chain
policy_version is embedded in:
- audit events
- permits
- approval records/fingerprints
- trust records
This makes past execution reconstruction deterministic against the exact governing policy state (per PV-001, policy_versioning_and_upgrade_spec.md §6 and §15).