jurisdiction_residual_gate
A policy set governs this number and names its own hole. Raised by GET /v1/contacts/{id}/dialability and by POST /v1/calls when the resolved policy carries a residual_gate nothing has cleared - a requirement the record cannot evaluate: a state registration, permit, bond or message filing (operating_authority); a live-human-first or natural-voice condition (call_architecture); or a fact about the callee we do not hold (evidence). The gate ids and their citations ride into the attempt's policy_snapshot beside source_versions. Deliberately not carried on the tenant's own blocked-state refusal, which would make a platform finding and a customer preference indistinguishable in an evidence export. The distinction from the row above is the whole point and an integrator should branch on it: one means we have nothing here, the other means we have a record and it names a permit regime standing between you and this call - different sales conversations, different customer decisions. What an operator does: read the gate id and citation from detail, then either record that the tenant holds the operating authority the gate names, or drop the state from the campaign. There is no override field and no support tool that clears it - a gate opens and closes by PR with owner approval, because it is a claim about a legal regime (CANON 164). P1, unbuilt: residual_gates is not a field on JurisdictionPolicy and PolicyRefusal has no such member.
Problem shape
Every non-2xx response is an RFC 9457 application/problem+json body. The type URI below is stable and machine-matchable, so branch on the final path segment (the code) and treat the status as redundant confirmation. See the error-handling guide.
{
"type": "https://docs.vocapable.com/errors/jurisdiction_residual_gate",
"title": "…",
"status": 409,
"detail": "…",
"instance": "/v1/…"
}