Demo the failure, not the success: what does the user actually experience when a generation fails — and can a degraded output ever slip through as a good one?

The full executive answer

The design rule is fail loud, fail clean, never fail plausible. When a generation cannot meet the bar — untraceable numbers after the corrective retry, a failed consistency guardrail, both providers down, budget or readiness gates unmet — the user gets an explicit, human-readable error stating what happened and what to do, and nothing is saved. There is no code path where a degraded artifact is stored with a shrug. The distinct failure classes each have their own honest message: a timeout says the analysis needed more time; a provenance rejection says figures could not be traced to your data; an insufficient-data gate refuses to generate a hollow analysis at all and points to which inputs to add first — refusing to answer beats inventing an answer, so we gate before the paid call.

Degradation that is acceptable is disclosed, not hidden: a provider failover to the fallback model is stamped on the insight and in the audit log, the outputs quality score reflects it, and the monitoring layer tracks fallback rate as a health signal with alerting when it spikes — so a systemic quality dip pages us; it does not wait for a customer to notice. Partial results follow the same contract: an output either clears every gate or does not exist; there is no half-validated artifact state. For a CAO the summary is that every failure mode terminates in one of exactly two states — a validated stored artifact, or an explicit error with a clean retry path — and the enumeration of what can go wrong is written in the engine as typed, user-facing messages, which is what operational maturity looks like in code.