AI Recommendation-Generation Failure Honesty Automation: Two Dead Ends, Two Fabricated Successes

When a system genuinely fails — an error is thrown, a screen shows nothing, a spinner never stops — the failure is uncomfortable but at least visible: someone knows something went wrong and can retry, escalate, or wait. A failure path that instead returns something plausible-looking removes exactly that visibility. Nothing crashes, nothing looks broken, and the person on the other end has no reason to suspect that what they're looking at wasn't actually produced by the process they think produced it — the failure becomes invisible specifically because it was engineered, even unintentionally, to look like success.

A multi-step pipeline — call an external service, then parse and validate what comes back — has at least as many potential failure points as it has steps, and each one is a separate, independent decision about what to do when things go wrong. A team fixing the FIRST failure point they find (say, the external call itself) can reasonably believe the pipeline is now honest, without realizing a SECOND, structurally identical shortcut exists one step later, in the parsing or validation logic, written by the same reasoning at a different time. Both shortcuts look identical from the outside — a function that's supposed to either succeed or throw instead quietly returns something else — which means finding one doesn't automatically surface the other; each has to be found and fixed on its own.

This gap surfaced from the same internal audit that rewrote Axiom's proof-of-action mechanism and closed several other gaps covered on this pillar's companion pages — the audit's own account of this specific defect states it plainly: "209 lines of pre-written Meta Ads campaign were returned whenever the proxy failed, and `useSession` PERSISTED it as a recommendation with `recommendation_generated` in the audit trail. Now it fails, and the failure appears." Reading the current source in full surfaced a second detail this pillar had not previously captured in full: the fix actually closes TWO separate, compounding dead ends in the same short pipeline, not one.

The first lived inside `callGeminiAPI`, the function that actually calls the AI proxy. If that call failed for any reason — a network error, the proxy being down, any outright failure — the code caught the error and returned the output of a separate function that fabricated a complete, plausible-looking Meta Ads campaign: a naming convention, target audiences, exclusion lists, creative suggestions with sample ad copy, a pre-publish and post-publish checklist, and a specific suggested daily budget — 209 lines of hardcoded content with zero relationship to the actual goal a person had typed in. Nothing about the returned value signaled it was a fallback; it was shaped exactly like a genuine AI response, and the calling code downstream had no way to tell the difference. That calling code, in `useSession.ts`, took whatever came back and created a real recommendation record from it, then logged a `recommendation_generated` event to the audit trail — meaning a complete AI outage could result in a durable database record and audit entry asserting that a real, goal-specific recommendation had been generated, when nothing had actually run.

The second dead end lived one step later and further downstream, inside `generateForSession`, the function that takes the AI proxy's raw text response and parses it as JSON. If that parsing failed — the AI responded, but its answer wasn't valid JSON, or didn't match the expected shape — the prior code caught that failure and returned a recommendation object with an empty summary and a manufactured `confidence: 30`. The current code's own comment on this exact fix asks precisely the right question about that number: "confidence 30% in what? There was no response to have confidence about." A specific, plausible-sounding percentage was invented and attached to a result that represented total failure to parse anything at all — and, exactly like the first dead end, that fabricated result was indistinguishable from a genuine low-confidence recommendation once it left the function, and was persisted the same way.

Both paths now throw an explicit error naming what actually happened, instead of returning anything. Neither has a fallback branch left in a catch block — deliberately, since a fallback there would simply recreate the same defect in a different form. Tracing the call chain forward into the current `useSession.ts` confirms both persistence points — creating the recommendation record and logging the `recommendation_generated` audit event — sit structurally AFTER the call to `generateForSession`, meaning neither is ever reached if either underlying function throws; a failure now genuinely prevents anything from being written, rather than writing a fabricated result instead. And because a function further up the chain (`generateRecommendations` in the hook) has no catch of its own around this call — deliberately, so the rejection propagates rather than being silently absorbed — the screen itself, `SessionView.tsx`, wraps the call in its own try/catch specifically to turn that rejection into a visible message. The current code's own comment at that exact call site states the reasoning directly: "the catch isn't caution for its own sake — without it, `generateRecommendations`' rejection becomes an unhandled promise rejection," which would have made the failure invisible in a different way, rather than surfacing it honestly to the person waiting for a response.

The AI proxy goes down briefly while someone describes a campaign goal to Axiom. Before the fix, that person would have received a complete, confident-looking Meta Ads plan with real-sounding budgets and creative suggestions — entirely unrelated to what they actually asked for — and it would have been saved to their session's history as if genuinely generated. After the fix, they see a clear, honest message that the AI didn't respond and nothing was generated, with nothing saved to their history describing a plan that was never actually made.

A recommendation that appears in a session's history, or a `recommendation_generated` entry in the audit trail, now reliably means a real AI response was received and successfully parsed — not that one of two separate failure paths quietly manufactured something plausible instead. Someone whose request fails now sees an honest, actionable message immediately, rather than acting on a fabricated plan or a meaningless confidence number they had no reason to doubt.

This fix makes AI generation failures honest and visible — it does not add retry logic, automatic fallback to a different AI provider, or any mechanism to reduce how often the underlying AI proxy itself fails. A team wanting automatic retries or provider failover on top of this honest failure behavior would need that as a separate, additional mechanism; what this guarantees is that a failure, when it happens, is never mistaken for a success.

Fixing the most visible failure point in a multi-step pipeline can create the reasonable impression that the whole pipeline is now honest, while a second, structurally identical shortcut sits one step further down, written by the same reasoning at a different point in time. Centriu Axiom's fix specifically traced the ENTIRE short pipeline — the AI call and the response parsing that follows it — and closed both fabricated dead ends it found, rather than treating the first fix as proof the second problem didn't exist.