Checks coordinates a platform operator is considering for one tenant's own
(BYOK) key-material backend, and answers what was checked. Required scope:
admin.platform.key-backend.byok.declare, plus the ROOT platform

tenant.

It rides the declare scope rather than a read scope deliberately:

the operation has a side effect an attacker would want, an outbound connection
to a host the caller names, and that is a capability someone entitled to declare
a backend already has while a reader must not gain it.

It persists nothing and it reads nothing. No declaration is

created or mutated, no credential is read, sealed or unsealed, no
key-encryption key is moved and no lifecycle state changes. Equally,
nothing about the tenant's current declaration takes part in the
verdict: every value checked travels in the request body, so the answer is
a statement about the coordinates being proposed and never about the ones the
tenant already holds. Calling it on a tenant that has already bound a backend is
explicitly supported and changes nothing. 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 to the

named key, or key material is known until the backend is declared and bound.

Which checks run depends on the selected family and on what was submitted, and the verdict names them. SHAPE and ENDPOINT_POLICY always run. KEY_ID_GRAMMAR_PARSED runs when a keyId was supplied

AND the declared family publishes a grammar for it - aws-kms,
gcp-kms and gcp-kms-hsm do; Azure key names and PKCS#11

labels have none, and for those the entry is ABSENT rather than reported as
vacuously passing. 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 carries no TRANSPORT_PROBE entry at all. That 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 neither is one omitted where the

backend requires it. The rule is the declared per-backend requirement the DECLARE
verb enforces, read here by the same single reader - so a body this check admits
is a body the declare admits, and a rehearsal cannot come back green for a
submission the commit refuses.

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.

The named backend family is checked against this tenant's admissibility before anything is contacted, so a family the tenant may never declare

cannot drive an outbound dial. That refusal is a 422 identical to the declare
verb's.