How granular should the version be?

Most platform teams version per change rather than per period. A version per change is small enough to reason about; a version per day groups too many changes. The exception is glossary-level tweaks (typo fixes, comment changes) that do not affect behavior; those can be batched.

What about emergency rule changes?

Emergency changes get an expedited approval path and a flagged version label (such as prod-2026-06-20-emergency-r1). The metadata records the emergency status and the reviewer. The audit record carries the same version field; the auditor sees the emergency label and the rationale in the metadata.

How does this interact with feature flags?

Feature flags that control rule behavior are part of the policy code; the flag's value at the moment of the decision is recorded with the version. A version label and a feature-flag snapshot together describe the exact behavior; the snapshot lives alongside the version in the registry.

Does the gateway support multiple active versions at once?

Yes, during canary rollouts. The gateway treats each version as an independent bundle. A request resolves the version that applies to its route or its identity, then evaluates against that bundle. The audit record carries whichever version applied.

What happens if the registry is unreachable?

The gateway's locally cached bundles continue to serve. New deployments cannot pull new versions until the registry is reachable. The fail-closed behavior is on policy decisions that depend on a version the gateway has not seen yet; the gateway refuses them. The fail-open behavior is on the cached bundle, which continues to apply.

AI Policy Versioning: Why the Audit Record Has to Carry a Policy Version, Not Just a Decision

A per-decision audit record that says "allowed" without a policy version is a decision without a rule. The auditor reads the record and asks what rule produced the allow. The platform team retrieves the policy text that was in force at the moment of the decision and shows that the decision was consistent with the rule. The lookup requires the policy version on the record. Without the version, the audit chain breaks the moment the policy text changes.

I want to walk through the versioning scheme that survives, the rollout patterns that hold under contention between deploy time and request time, and the audit-record fields the regulator expects.

Why "current policy" is not enough

Most policy systems support a single "current" view of the policy. When the regulator asks about a decision from three weeks ago, the system can describe the current policy but not the policy that applied at the moment of the decision. If the policy changed in the interim, the audit chain breaks.

The fix is to treat the policy plane as code with a version identifier per change. The version identifier travels with every decision. The audit pipeline can retrieve the policy text by version. The chain is reconstructable regardless of how many times the policy has been updated since.

EU AI Act Article 12 requires automatic recording over the lifetime of the system. The lifetime spans multiple policy versions. The recording is only meaningful if each event is bound to the version that applied to it.

The versioning scheme

A useful versioning scheme has three properties.

Monotonic per environment

Each environment (dev, staging, production) maintains its own monotonic version sequence. A production policy version is a single identifier such as prod-2026-06-20-r3 that increments per release.

Carries the policy hash

The version identifier ties to a content hash of the policy bundle. The hash binds the version label to the exact rules. A version label without a hash is renamable; a label tied to a hash is not.

Tagged with the rollout

Each version carries metadata about the rollout: when the rollout started, when it reached 100%, who approved it, what change list it carries. The metadata is what the auditor reads alongside the rules.

The rollout patterns that hold

Three patterns cover production rollouts.

Pattern A: instant cutover

The new policy version replaces the old version at a defined moment. Every decision after the cutover carries the new version; every decision before carries the old version. The pattern works for small policy changes with low risk.

The decision record carries the version. There is no ambiguity at the cutover boundary as long as the gateway uses a single clock to bind the version to the decision.

Pattern B: canary by route

The new version applies to a subset of routes first. The remaining routes continue on the old version until the canary completes. The decision record carries the version that applied to that specific route. The auditor can see which routes ran which versions.

Pattern C: canary by identity

The new version applies to a subset of caller identities first. The remaining identities continue on the old version. The pattern is useful when a policy change might affect a sensitive workload that needs more lead time. The decision record again carries the per-identity version.

In all three patterns, the audit-pipeline view of the world is the same: each decision points to one version. The path the version reached the decision is internal to the gateway.

Avoiding the racy version

A common failure mode is to look up the current version at request time. Under high load and during the brief window of a rollout, two adjacent requests can resolve different versions in a way the platform team did not intend. The fix is to bind the version to the worker at the moment it pulls the policy bundle, not at the moment the request lands.

The atomic swap is the property that prevents the racy version. Until the swap, every decision on this worker carries r3; after the swap, every decision carries r4. There is no in-between.

What the audit record carries

The audit record carries the version identifier and a way to retrieve the policy text by that identifier. The fields below survive the inquiry.

The reason field is the rule name from the bundle. The auditor uses the reason to navigate to the specific rule inside the policy text retrieved by version. The chain is short and verifiable.

The policy registry as the system of record

The policy registry stores every version that was ever deployed, indexed by version identifier and hash. The registry is read by the audit pipeline; the registry is read by the rollback procedure; the registry is read by the change-management workflow.

The registry's retention is at least the audit retention. EU AI Act Article 19 sets six months; sector regulations often extend it. A registry that drops a version after a month makes audit records from before the drop unverifiable.

The registry is also the source of truth for diffs across versions. When the auditor asks what changed between r2 and r3, the registry produces the diff alongside the text. The diff is what the auditor reads to confirm that the change was approved and rolled out as intended.

How policy versioning interacts with the four AI compliance roles

The four AI compliance roles each operate on the policy plane through a different surface.

The AI Compliance Officer reads the regulatory mapping and the diff summary on each version. The mapping confirms that the change is consistent with the regulation it claims to satisfy.

The AI Risk Manager reads the residual risk impact in the diff. Each version's metadata includes the risk-register entries it affects.

The AI Audit Lead reads the audit records and the registry. The pair of artifacts answers the regulator's questions about which rule applied to which decision.

The AI Governance Engineer maintains the policy code, the rollout pipeline, and the registry. The engineer's git history is the per-change provenance the AI Compliance Officer cross-references.

DeepInspect

DeepInspect treats policies as code. Every version carries a label, a hash, a rollout history, and a change list. The gateway binds the version to every decision; the audit record carries the version and the hash. The policy registry is the system of record, indexed by version, and retained at least as long as the audit retention requires.

The platform team rolls out new versions through the canary patterns above. The audit pipeline retrieves the policy text by version. The auditor's question about a decision from three weeks ago resolves against the exact rule set in force at that moment. Book a technical deep dive at deepinspect.ai to walk through the versioning scheme against your current policy posture.