Solution 03
Never let a disclaimer substitute for a correctness fix
01 — Root cause addressed
This addresses a shipped response that consisted of a disclaimer, which the system then contradicted days later by affirming that it could give professional business advice.
02 — Implementation
In domains where following an answer creates legal exposure, require a demonstrated correction to the answers as the condition of the system staying live, and treat every mitigation as a change that gets its own verification pass. That pass includes the direct question: ask the system whether the claims the new disclaimer makes about it are true. If the page says the system does not give professional advice, the system has to say the same, and if it does not, the disclaimer is decoration over an unchanged defect. Record the mitigation, its verification and its result the way a code fix is recorded.
03 — Prevention
Add a mitigation-verification step to the incident process, so every disclaimer, scope limit or guardrail is tested against the live system before the incident can be closed.
04 — Trade-offs
Taking a service offline while its answers are corrected carries a visible cost that a disclaimer avoids, and there will be pressure to prefer the cheaper option. A disclaimer is also legitimate as an interim measure running alongside a fix in progress, so the rule is that it cannot be the whole response, not that it is never appropriate.