Answers the question the delivery path itself asks — would a message for this
tenant go out right now — and never the question does a provider row
exist. The two diverge on the state this endpoint exists for: a provider
declared with a valid credential and never probed is present, populated and
syntactically valid, and delivers nothing, because activation requires a
connectivity verdict measured against the configuration the row currently holds.
deliverable is therefore the emptiness of the ACTIVE delivery chain

and nothing else; every other member exists to EXPLAIN a false and
none of them may change it.

This is the platform plane's read of a tenant's verdict, and it is what

a surface acting INTO a tenant consumes — the create-user and force-password-reset
flows an operator runs on a tenant's behalf. The tenant-plane twin
(GET /api/v3/admin/tenants/{tenantId}/notification/readiness) answers
403 to a SaaS platform operator, which is the whole reason this one

exists — the same rule that put the tenant's provider list on this plane (PRD
§166).

The chain is resolved exactly as delivery resolves it: the tenant's own ACTIVE rows first, and the deployment's whole chain as the fallback when the tenant has none. effectiveScope reports which of the two answered — and it reads DEPLOYMENT whenever the fallback was taken, including when that fallback is itself empty.

One entry is returned per reported channel: EMAIL

unconditionally — account activation and password reset are email-borne — plus
every other chain-borne channel for which a provider row exists at any status, in
either scope.

The reported set is EMAIL, SMS and WHATSAPP — the three channels whose delivery resolves the provider

chain this verdict is computed from. WEBHOOK is a fourth
NotificationChannel value and is reported in NO state, even when a

WEBHOOK provider row is declared: a webhook resolves an alert DESTINATION, whose
endpoint and signing secret are per-destination and are not in this chain, so a
verdict derived here would be an answer to a question webhook delivery never
asks.

The blocking vocabulary is ordered, and the order is the precedence, so

a scope in more than one condition yields the earliest, which is always the first
action that must be taken:

1. NO_PROVIDER_DECLARED — no row for this channel. Declare one.
2. PROVIDER_UNVERIFIED — rows exist and none carries a PASSED verdict measured against its CURRENT configuration: never probed, last probe FAILED, or probed and then edited. Run the connectivity test.
3. PROVIDER_NOT_ACTIVATED — a current PASSED verdict exists and no row is ACTIVE. Enable the provider.

The vocabulary's fourth token, NOT_REMEDIABLE_HERE, is never

emitted on this endpoint, in any state. It means contact the platform
operator, and the caller here IS the platform operator, for whom that is a loop
and not a remedy. The cause is therefore the specific derived token whether
the rows that explain it are the tenant's or the deployment's.

blockingProviderId is gated separately from the token, and

on a different rule: it is present only when the blocking row lies in the scope
this read is about — so only when the tenant holds rows of its own. When the tenant
declared nothing and the block is on a DEPLOYMENT row, the token still rides and
the identifier is omitted:
admin.platform.notification.tenant.read grants THAT TENANT's provider

list, not the deployment's, so naming a deployment row would hand out an identifier
the scope does not otherwise carry. The deployment plane's own verdict,
identifiers included, is at
GET /api/v3/admin/platform/notification/readiness, under the scope

that does grant it.

Absence is key omission, never null. A deliverable channel

carries no blocking key at all, rather than a token meaning
"nothing is wrong" — a rendered all-clear cannot be distinguished from a read that
never happened.

The non-blocking notice member is orthogonal to blocking: it has its own condition, never suppresses and is never

suppressed by a blocking token, and both may ride one channel entry.
INHERITING_DEPLOYMENT_CHAIN states that this tenant declared rows of

its own for the channel and is nonetheless riding the deployment chain, because
none of its own rows is currently ACTIVE. A tenant that declared nothing is
inheriting by design and receives no notice.

The ROOT platform tenant is a valid target HERE, unlike on every write of this plane: a read creates no row and emits no audit, so the ROOT-target refusal has nothing to protect, and the surfaces bound to the platform tenant must be able to render a verdict. The ROOT tenant owns no provider rows, so its answer is the deployment chain's, reported with effectiveScope = DEPLOYMENT.

Nothing here is cached. Every call is a fresh resolution, so the verdict moves on the read immediately after the remedy — no invalidation call exists because no cache does.