PREWAVE-BE-102 — Fail Closed When the Configured AI Provider Is Unavailable #803

Problem context

The AI assistant's LLM provider service returns a fabricated mock response whenever the selected provider has no configured client/key. The runtime schema blocks AI_PROVIDER=mock in staging/production, but the LLM service independently selects DEFAULT_LLM_PROVIDER and falls back to provider: mock when that provider is unavailable. The runtime schema must validate the provider actually used by this service, not only the separate AI_PROVIDER field.

Technical scope

Unify AI provider configuration and validation. Require a supported provider and its corresponding secret in staging/production; make missing or unavailable provider configuration a startup/readiness failure or an explicit unavailable response. Restrict mock provider overrides to local/test and authorized development tooling. Never return mock text as though it were a real model response. Record provider/model metadata truthfully and redact secrets.

Required tests

• Production/staging boot rejects mock provider, missing selected provider key, unsupported provider, and mismatched DEFAULT_LLM_PROVIDER.
• Local/test can explicitly use MockProvider.
• Runtime provider outage returns a truthful unavailable error; no synthetic content or usage metrics are stored as real model output.
• Non-admin users cannot override providers; production admin calls cannot select mock.
• Logs never expose API keys or prompts beyond approved redaction.

Security and architecture constraints

• Fail closed on missing, stale, unauthorized, or ambiguous state.
• Persist audit-critical state; do not rely on process-local maps for user appeals or financial operations.
• Canonical contracts and finalized events remain authoritative for protocol state.
• Do not fabricate scores, provider responses, payout hashes, receipts, or finality.
• Enforce owner/reviewer/service authorization and redact secrets and private evidence.

Acceptance criteria

• The identified in-memory, mock, or simulated behavior is replaced by the production-safe implementation.
• State is durable and consistent across process restarts and API instances where applicable.
• Authorization and privacy boundaries are covered by automated tests.
• Failure, retry, replay, and concurrency behavior is documented and tested.
• Exact-head required CI passes and independent review is recorded.

Dependencies

• No protocol-state dependency. Must preserve the existing prompt orchestration and RAG provenance boundary.

Non-goals

Changing the assistant's model choice, prompt policy, RAG corpus, or billing policy.

Complexity and points

• Medium — 150 points

Candidate only. Activation remains maintainer-controlled; do not apply Stellar Wave as part of implementation.