Checks submitted deployment key-protection backend coordinates and answers what
was checked. Required scope: platform.bootstrap, plus the ROOT
platform tenant.

It persists nothing, on every path. No declaration is written

or changed, no configuration row is created or mutated, no credential is read,
sealed or unsealed, no candidate custody envelope is created, no self-test verdict
is recorded and no per-tenant KEK is provisioned. Calling it on a deployment that
has already bound a backend is explicitly supported and changes nothing — that is
the deployment whose replacement an operator most needs to rehearse. Its one
lasting effect is an audit row recording that a configuration was submitted for
checking.

A FAILED verdict is an HTTP 200. The question this operation

asks is whether the submitted coordinates are admissible and, where they name an
operator-specific host, whether that host answers. "It did not answer" is an
answer to that question, so it arrives as a 200 carrying
FAILED/UNREACHABLE. A client that renders that as a

transport error loses the distinction that makes the operation useful.

It never answers PASSED, and cannot. A pass means key material

was wrapped and unwrapped again and came back identical. This operation presents
no credential — the request shape carries none on any provider subtype — and wraps
nothing, so a pass is not something it is able to observe. The green outcome is
NOT_APPLICABLE, and it is deliberately not a pass: it says the

coordinates are admissible and, where a host was named, that the host is alive at
the transport layer. Nothing about authorization, entitlement or key material is
known until activate runs.

Which checks run depends on the provider family and the verdict names them. SHAPE and ENDPOINT_POLICY always run, and KEY_ID_GRAMMAR_PARSED runs whenever the declared family publishes a

key-coordinate grammar — aws-kms, gcp-kms and
gcp-kms-hsm do; neither Azure token has one, because Azure publishes no

parseable key-coordinate grammar for a vault key or for a Managed HSM key, so for
those two the entry is ABSENT rather than reported as vacuously passing.
TRANSPORT_PROBE runs only when the coordinates

carry an operator-specific host: always for the two Azure tokens, each of whose
endpoint IS the backend — a vault URL for azure-kv and a Managed HSM
URL for azure-kv-mhsm, which are different Azure resource types on
different host families — and for aws-kms only when an endpoint
is supplied. Neither GCP token accepts an endpoint at all, so nothing is
contacted for them and the verdict says so —
COORDINATES_ADMITTED with no TRANSPORT_PROBE among the

checks that ran, which is what stops a green answer reading as "everything is
fine".

An endpoint the declared backend does not accept is a 422, not a verdict, and it is refused before anything is

contacted. The rule is the declared per-backend requirement the commit enforces,
read here by the same single reader — so a body this operation admits is a
body PUT /backend/configuration admits. Answering
ENDPOINT_ANSWERED for a submission the commit refuses would make the

rehearsal actively misleading, and would dial an operator-supplied host under a
token the platform declares accepts none.

The probe is pinned at TCP connect plus TLS handshake and issues no application-layer request. A vault that completes the handshake and would decline an unauthenticated API call therefore answers ENDPOINT_ANSWERED, because it was never asked anything to decline.

The verdict's reason comes from a closed vocabulary

(SelfTestReason) that can carry no credential, ARN, resource path,
Azure account URL, region or account id, and no vendor exception text. A client
MUST tolerate a reason it does not recognise and render it as an unknown verdict —
never as a pass.

503 never means "the backend did not answer". It means this

instance declined to start a check it could not bound, because too many outbound
reachability probes are already in flight here. It carries Retry-After
and no verdict member at all, because a bounded-out request contacted nothing. An
endpoint that did not answer is a 200 carrying
FAILED/UNREACHABLE.

Documented property of the 403. The 403 is identical for every

non-ROOT caller given a request body that passes Bean Validation. The
endpoint policy is enforced by a constraint on the request record, which the
framework evaluates while binding the argument — strictly before the handler body,
and therefore before the ROOT-tenant gate that is its first statement. A caller
holding platform.bootstrap but not the ROOT tenant consequently
receives a 400 for a policy-refused endpoint and a 403 for an accepted one. The
narrowing is stated rather than closed: the fact so disclosed is a published rule,
documented in the configuration reference, and the same ordering governs
PUT /backend/configuration, which this operation deliberately shares a

request shape and a validation mechanism with.