Skip to content
AI products4 min

When the prompt is a safety problem, not a quality problem

Every other product I have built fails by being unhelpful. ReliefAI can fail by saying the wrong thing to someone in real distress, and that changes what prompt engineering even is.

On most AI products a bad output is an annoyance. The summary is thin, the illustration is generic, the answer is vague. The user shrugs, retries, and the cost of the failure is a little trust and a little compute.

ReliefAI helps people through a breakup, with no-contact and recovery support. Someone opens it at a genuinely bad moment, sometimes at three in the morning. A bad output here is not a thin answer. It is the wrong thing said to a person in distress, and there is no retry that undoes having read it.

That single difference changes what prompt engineering is on this product. Everywhere else it is a quality discipline. Here it is a safety discipline, and the two do not use the same methods.

Bounding the worst case instead of raising the average

Normal model work optimises the average output. You look at a sample, decide which responses read better, tune towards those, and the mean rises. It is a perfectly good method when the downside of a weak answer is boredom.

It is the wrong method when one output in a hundred can do harm, because the mean tells you nothing about the tail and the tail is the entire risk. A system that is excellent ninety-nine times and harmful once is not a good system with a rough edge. On this product it is an unshipped system.

  • You define the failures you will not accept before you write the prompt, in concrete terms: minimising what someone reports, implying fault, pushing action on someone who is not ready, or presenting itself as a clinician.
  • You go looking for those failures on purpose, with inputs written to provoke them rather than to demonstrate the feature. Nobody finds the tail by sampling good days.
  • You accept a lower ceiling in exchange for a higher floor. The most impressive possible response is not worth having if the same latitude that produces it also produces the worst one.

Every other product on this page fails by being unhelpful. This one can fail by saying the wrong thing to someone who is not okay.

Tone is not polish

On most products tone is a layer applied to a correct answer. Here it is part of whether the answer is correct at all. The same information delivered briskly and delivered gently are not the same output with different styling, they are a useful response and a harmful one.

Which means tone cannot live in a final rewrite pass, and it cannot be a line in the prompt saying be empathetic, because that produces the performed empathy everyone can now recognise instantly and which reads worse than plain speech. The reliable version is narrower and duller: say less, do not diagnose, do not predict how they will feel next week, and never claim to understand something you were not told.

Refusal is a feature, not a fallback

There are inputs where the correct output is to not answer. Somebody describing something beyond what a support tool should touch needs a clear, warm, immediate handoff, not a best effort. If that path is left as whatever the model does when it is unsure, you have not designed it, you have hoped for it.

Designing refusal means deciding what triggers it, what it says, what it offers instead, and what happens next time that person opens the app. Done badly it feels like a door slammed, which on this product is its own harm. Done properly it is the most important screen in the product and most users never see it.

The returning loop

A person in this state does not use the product once and leave satisfied. They come back over days and weeks, and what they need on day two is not what they needed on day one. Early on it is mostly getting through an hour. Later it is not relapsing on a decision they already made.

A tool that is comforting on the first visit and identical on the tenth stops being support and becomes wallpaper. Worse, sameness reads as not listening, which on this product is a failure with the same shape as saying the wrong thing, just slower.

The limit, stated in the product

This is a support tool. It is not therapy and it is not a person. Saying so plainly inside the product is not a legal footnote, it is part of the safety work: the failure where someone treats it as more than it is, is a design failure and not a user error.

None of this is a constraint you satisfy once and move past. It is the shape of the product. If you removed it you would not have a freer version of ReliefAI, you would have a different product that should not be pointed at these people.