Deployment Policy Is Compliance-Immutable

URI: https://docs.ankatech.co/errors/deployment-policy-immutable
HTTP Status: 403 Forbidden

When you see this

The deployment was created for a regulated compliance region, and its deployment policies are locked for the lifetime of that deployment. The write was refused and nothing was changed.

This is not an authorization problem. The caller holds every scope the operation needs; the deployment itself is immutable. No role, no scope and no platform-administrator privilege admits the write, because the lock protects regulatory integrity rather than access.

The detail names the regulatory framework in force and the only remedy: to change the compliance region, recreate the deployment environment.

Why it is a separate problem type

The same handlers answer 403 for a second, unrelated reason: the caller is not a platform-tenant principal. That one is an authorization refusal, and a client should treat it as such — the operator lacks a permission and someone can grant it.

These two outcomes need different responses from the operator, so they carry different type values. A client that distinguishes them only by reading detail will eventually show the wrong remedy; match on type.

Common Causes

• The deployment was created with a regulatory compliance region (BSI, NIST, eIDAS, EU, and the other recognised regimes). Every region except UNRESTRICTED locks its deployment policies at bootstrap. The deployment rotation schedule is the one exception: it is created with no default cadence and no maximum, and it is locked by the first write that stores a default cadence or a maximum, so the refusal follows that write.
• An operator or an automation attempted to relax, retighten, or reset a deployment policy on such a deployment — including a reset to DEFAULT, which is a write to that same row and not an escape from the lock.
• A runbook written against an UNRESTRICTED development environment was replayed against a regulated one. Development deployments are UNRESTRICTED, so the write succeeds there and is refused here.

Response Example

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json

{
  "type": "https://docs.ankatech.co/errors/deployment-policy-immutable",
  "title": "Deployment Policy Is Compliance-Immutable",
  "status": 403,
  "detail": "Deployment algorithm policy is immutable (regional compliance locked). Regulatory framework: BSI-TR-02102-1. To change compliance region, recreate the deployment environment.",
  "instance": "/api/v3/admin/platform/deployment/policies/algorithm-availability",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The detail names the policy plane and the regulatory framework. It discloses no row identifier and no database detail.

How to Resolve

1. Confirm the deployment's compliance region. If it is a regulated region, the refusal is correct and final; the policies it locks are the ones the region requires.
2. Do not attempt a reset as a way around it. A reset writes to the same row and is refused identically. The refusal is enforced by the platform and by the database, which refuses both updating and deleting a locked deployment policy row, so no code path unlocks or removes it.
3. If the compliance region itself is wrong, the deployment has to be recreated with the intended region. There is no in-place change, by design: a deployment created for one regulatory regime must remain compliant with it for its lifetime.
4. If the deployment should not have been locked at all, it was created with the wrong compliance region — treat it as point 3.

Operations that emit it

Every deployment-policy write, on all five planes:

Tenant-plane policy writes do not emit it, and the reason is worth stating plainly: a tenant policy is stored in its own row, which this lock does not cover. The lock fixes the deployment row; it does not decide whether a tenant may hold a policy of its own. A tenant that has been granted policy delegation may therefore write its own policy on a regulated deployment, and the only thing examined is whether the proposal stays within the deployment policy as a ceiling. One that exceeds it is refused Tenant Policy Subset Violation — a 422, naming each exceeded dimension, identical on a regulated deployment and an unrestricted one. The rotation schedule follows the same principle: a tenant or key rotation interval longer than the default of a locked deployment is refused Rotation Interval Exceeds Its Ceiling (422), and a shorter one is admitted.

Related

• Forbidden — the other cause of a 403 on these same endpoints, which is an authorization refusal
• Policy Lock Timeout — a deployment policy write that could not take its lock in time; retryable, and unrelated to compliance immutability