What happens when a risk provider is unavailable?
An unavailable provider is an operational failure, not a low-risk signal. GridZen’s current Twilio adapter returns a 503 through the API when the provider is unavailable. A review queue or authorized fallback must be implemented by the calling workflow; the alpha does not silently convert that failure to allow.
Separate three outcomes
Keep mismatch, insufficient evidence and technical failure separate. A mismatch is a returned assertion; insufficient evidence means the policy lacks a required signal; a technical failure means the check could not complete. Collapsing these states prevents reviewers from explaining the result and can create an unsafe default.
Design the caller workflow
For a payout, hold the customer workflow when a required check cannot complete; route it to an owner or an explicitly approved backup. Use bounded retries only where the upstream operation and customer workflow permit them. GridZen’s alpha does not move funds or guarantee idempotency for the downstream payment action.
Verify failure behavior
Test timeout, malformed response, missing credentials, provider rejection and recovery. Record HTTP status separately from decision outcome. A 503 has no successful decision response and should not be logged as decline or allow. Review the same cases again when a new provider or policy is enabled.
Sources and scope
Based on the alpha contract and source implementation. Live route availability requires separate confirmation.