Checks coordinates an operator is considering for one licensed tier and answers
what was checked. Required scope:
admin.platform.key-backend.tier.manage, plus the ROOT platform

tenant, on a SaaS deployment.

It persists nothing and it reads nothing. No tier row is

created or mutated, no settings row is written, no credential is read, sealed or
unsealed, no key-encryption key is moved and no lifecycle state changes. Equally,
nothing about the tier's current configuration takes part in the
verdict: every value checked travels in the request body, so the answer is a
statement about the coordinates the operator is proposing and never about the
ones the tier already holds. Calling it on an ACTIVE tier is explicitly supported
and changes nothing - that is the tier 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 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, 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 - and wraps nothing, so a
pass is not something it is able to observe. The green outcome is
NOT_APPLICABLE. Nothing about authorization, entitlement or key

material is known until the tier is bound.

Which checks run depends on the selected family and the verdict names them. SHAPE and ENDPOINT_POLICY always run. TRANSPORT_PROBE runs only when an endpoint is supplied

- so for the four PKCS#11 tokens and the two GCP tokens, which name no
operator-specific host, nothing is contacted and the verdict says so with a
two-entry checks list. That is what stops a green answer reading as
"everything is fine".

Whether an endpoint may be supplied at all is the backend's own declared requirement, and it is enforced here before anything is judged or dialled - so an endpoint under a family that accepts none, or a missing one under a family that requires it, is a 422 and not a verdict. It is a statement about the two values submitted and about nothing else: nothing was contacted.

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.

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.