Why Refusing to Lie Is a Feature

"I'd rather stay silent than lie to you. That's not a limitation of the client. It's the point of it."

The Feature Nobody Lists

Feature lists are full of things a product does. The most important thing about Pippa Go is something it refuses to do: it will not manufacture an answer it can't verify came from Pippa. That refusal never shows up as a bullet point, because it looks like absence — a waiting badge instead of a reply. But it's the load-bearing feature. Every other promise in this quest exists to protect the moment when the honest move is to say nothing yet.

Reframe it and the value is obvious. A client that sometimes fakes answers is untrustworthy always, because you can never tell which answers are real. A client that never fakes is trustworthy always, even when it's waiting, because its silence and its answers mean exactly what they say. Consistency of honesty is worth more than the convenience of a fast guess.

Silence Preserves Trust; A Lie Spends It

Trust is a balance you can only draw down. A confident, wrong answer is a withdrawal the user doesn't even know happened — they walk away believing something false, and the cost lands later, out of context. Honest waiting spends nothing: the user knows precisely where things stand and can decide what to do. Given a choice between a truthful "not yet" and a plausible fabrication, a client that intends to be relied upon takes the "not yet" every time. The fabrication buys a second of satisfaction and mortgages the whole relationship.

A Principle That Outlives the Client

This isn't only about phones and bad signal. "Don't fabricate what you can't verify; make honest uncertainty visible" is a design value that transfers everywhere a system speaks under incomplete information — dashboards, agents, search, any tool that could bluff instead of admitting a gap. Pippa Go just happens to be a place where the principle is unusually clear, because the gap (no signal) is so concrete. Learn it here and you'll recognize the same choice in far less obvious places: the quiet temptation to present a guess as a fact because the honest answer is less satisfying.

Code

The refusal, encoded·typescript

// The client can be in exactly one of two truthful positions about an answer:
type AnswerState =
  | { kind: "waiting"; reason: "offline" | "pending" | "sending" } // honest 'not yet'
  | { kind: "answered"; text: string; fromCanonical: true };       // verified real reply

// There is deliberately no third variant:
//   { kind: "guess"; text: string }   <-- does not exist, by design
// If 'guess' can't be represented, no code path can ever show one as the answer.

Exercise

Find a system in your life that bluffs — presents a guess, estimate, or stale value as if it were current fact (a maps ETA that's wildly off, a 'live' number that's cached, an assistant that confidently makes something up). Describe the moment the bluff cost you. Then redesign that one interaction to make its uncertainty visible instead. Notice that the honest version is almost always the more trustworthy product.

Hint

The bluff is usually chosen because honesty feels less polished — a range instead of a number, a 'not sure yet' instead of an answer. But the honest version is the one you'd rely on twice. Trust compounds; bluffs erode it one invisible withdrawal at a time.