Answers which backend protects this tenant's keys, and why in one read, so an operator does not have to open the deployment default, the Edition tier and the tenant's own declaration and infer the chain from three screens.

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 this tenant has no Edition override from this tenant's Edition override is being overruled by its own declaration. Those lead to different operator actions.

changeRefusals is the part an operator arriving from a refusal needs. There is no re-wrap path on this platform: once key material is wrapped under a backend it stays there, so every rung change is PREVENTED rather than migrated. Five transitions can be refused and all five answer 409, which is precisely why a client cannot tell them apart by status. Each row names the transition, the rung whose gate refuses it, the population that refusal protects, and the verdict for this tenant right now.

An unverifiable key-material probe is a 503, never a permissive answer. The verdicts are read from the same probe the write plane is gated on. If it cannot be verified the refusal posture is unknown, and this read fails closed rather than reporting a transition as permitted that the write plane is about to refuse.

It is not a free read. Building changeRefusals drives up to TWO outbound service-to-service probes of core-api: the tenant-scoped key-material check on every call, and the tier-scoped population check when this tenant carries an Edition override. Neither passes through the reachability permit set that bounds the connection tests, so a console that POLLS this endpoint fans out to core-api on every poll. Read it on navigation and on an explicit refresh — not on a timer.

This plane is ROOT-only and discloses the full ladder, tokens included — the operator reading it is the deployment's own. It writes nothing: no audit row, no event, no state change. Required scope: admin.platform.key-backend.byok.read, plus the ROOT platform tenant.