Answers which tenants send mail through something other than the deployment chain, and through what, in what order in ONE read, over the WHOLE tenant population.

This is the ordered-chain surface, so the binding class IS the chain. bindings[ is the ordered signature — SENDGRID>SMTP — and bindings[].chain carries the positions in order, mirroring the top-level deploymentChain. A tenant on SENDGRID → SMTP and a tenant on SMTP → SENDGRID are therefore two DIFFERENT elements: grouped by provider they would be indistinguishable, and on this surface the order is the configuration. The absence of a backup is a chain of length 1 — read from the chain itself, so no per-tenant flag exists and none is needed.

The top-level deploymentShape is the SIGNATURE over deploymentChain, not one of its positions — SENDGRID>SMTP for a chain of SendGrid then SMTP. That is why a populated scalar sits beside a non-empty chain here by design: the signature names the chain as a whole and the positions name its members in order, so the two carry different facts rather than one fact stated twice. deploymentLabel is the signature's label in the same way. A chain of length 1 is the case that hides the distinction, because the signature and the single class token are then textually identical — read compositionRule on this same envelope to tell the regimes apart, never the value. Under every other composition rule the scalar names the plane's sole class instead, and deploymentChain is an unordered set.

The response is a CLASS-level projection, on both planes. It carries the mechanism at each position — SENDGRID | SMTP | MS_GRAPH | GMAIL — and a server-derived label for it, and nothing finer. It deliberately omits: the relay hostname and port, the sender address, the sender display name, the SMTP username, the TLS mode, the API key and its mask, the credential-custody key, the Entra directory id, and the probe verdict text. The same rule binds the DEPLOYMENT chain: each position names its class, never a configured value.

The four coverage bands partition the whole population, so onDefaultCount + divergingCount + notEligibleCount + suspendedCount == tenantCount always holds. A tenant that inherits the deployment chain is counted in onDefaultCount and is absent from bindings; it is never reported as unknown, and this read never answers 404 for it. This surface has no entitlement plane, so notEligibleCount is 0 and notEligibleTenants is [] — present, never omitted. A suspended tenant stays INSIDE the denominator.

A position that is declared-but-untested or disabled is reported ATTENTION rather than dropped: it is part of the operator's failover intent, and hiding it would report a two-position chain as a single point of failure. One unhappy position makes its whole chain ATTENTION. surfaceStatus is the server-composed worst-of across both planes (FR-190.21); deploymentStatus and every bindings[*].status are returned unchanged beside it. maxTenantBindings is null because this surface states no per-tenant ceiling — the key is PRESENT, as it is on all six.

Takes no path and no query parameter, so no caller-supplied identifier enters a query. It writes nothing: no audit row, no event, no state change. Required: the ROOT platform tenant, holding admin.platform.notification.tenant.read and admin.tenant.list. The second conjunct is not decoration — this response enumerates every tenant and names it, which the surface scope alone does not grant.