Answers which backend protects my keys, and why in one read, so a tenant administrator does not have to infer the chain from a status screen that can only say "mine" or "inherited".

The platform decides the backend as a three-rung precedence: a backend the tenant brought itself wins; otherwise a per-tenant licensed-Edition override routes the tenant to that tier's ANKA-managed backend; otherwise the tenant rides the deployment instance. effective names the rung that won and the backend token it resolves to. rungs carries all three, highest first, exactly one of them WINNER — and each of the other two carries a machine-readable reason from a closed vocabulary, so a client can distinguish I have no Edition override from my Edition override is being overruled by my own declaration. Those lead to different actions.

What this plane is told depends on who operates the deployment, not on who is asking. On an ANKA-operated (SaaS) install every rung except TENANT_BYOK — the WINNER included — carries its outcome and reason and no backendType: that token names the DEPLOYMENT's key-custody configuration, which is the same thing the admissibility refusal beside it withholds byte-identically so that a caller cannot probe it. It is the RUNG that decides, not whether the rung won — winning does not make the deployment's token the tenant's. TENANT_BYOK keeps its token on every posture, and it is the only rung that does, because that token is the tenant's own declaration submitted through this API. On a customer-operated install (PRIVATE_CLOUD, ON_PREMISE) every rung carries its token — the operator is the customer's own staff, and withholding would hide the customer's configuration from the customer.

So effective.backendType is OPTIONAL and MUST be modelled as nullable. A tenant with no declaration of its own and no Edition override wins on DEPLOYMENT_INHERITED, so on a SaaS deployment the response WITHOUT effective.backendType is the ordinary one, not an edge case. The same holds for every rungs[].backendType: an outcome of WINNER does not imply a token is present. effective.keyBackendSource is always present, so the tenant is always told WHICH rung decides its custody.

changeRefusals — which rung transitions the platform would refuse right now — is not part of this plane's body. Those verdicts are read from an outbound key-material probe, and a tenant-reachable read does not drive one.

The read is scoped to the caller's OWN tenant: the path tenant must equal the tenant in the token. It writes nothing — no audit row, no event, no state change. Required scope: admin.tenant.key-backend.byok.read.