Honest AI design: four rails that keep an assistant truthful
Honest AI design is a product philosophy with one rule: the interface never asserts anything it cannot ground in real data or real state. It is built from four rails: honest-empty states, real-or-nothing data rails, provenance-first memory, and consent-gated actions. Each rail is a structural constraint on what the product may render or do, not a tone-of-voice guideline, which is what makes it checkable.
What honest AI design is
Language models can produce fluent text that is wrong, and product interfaces can imply things that are not so. Honest AI design is the discipline of building the product so neither failure can reach the user as a false assertion. The key move is structural: instead of asking writers and models to be careful, the system is built so unbacked claims have no path to the screen and unapproved actions have no path to the world. The four rails below name the pattern. They are defined here as general design concepts, and each is illustrated with the concrete behavior Violet ships, because a design philosophy is only worth quoting if some real codebase actually implements it.
Honest-empty states
An honest-empty state is an interface state that says plainly that there is nothing, instead of dressing the void in placeholders, sample data, or aspirational copy. Conventional product design treats empty screens as a conversion problem and fills them with fake liveliness. The honest-empty pattern treats them as a statement of fact. In Violet, when the app has stored nothing on your device, the trust panel says exactly that: "Nothing stored on this device yet." When your day has no events, the morning line is "Nothing scheduled. The day is open." When cloud sync is off, the cloud card does not advertise the sync feature; it says "Nothing. Your data does not leave this device." Each of these lines is generated from the real state at that moment, so the empty state is not copywriting, it is a reading.
Real-or-nothing data rails
A real-or-nothing data rail is a structural rule that every number, count, and line on screen must derive from real recorded data, or the element does not render at all. No sample dashboards, no invented sentiment, no streaks, no decorative metrics. In Violet's companion app, the proactive daily moments are computed only from the real calendar, task, and reminder payload the app just fetched; if there is no real payload, or the client is not connected, the module stays quiet rather than inventing a line. The device-storage card in the trust panel lists the actual browser storage keys present at that moment, by name, and the count shown is the real count. The evening summary even carries its provenance in the interface: "from your real day, nothing invented." The rail turns "we do not fake data" from a promise into a property you can check against the screen.
Provenance-first memory
Provenance-first memory is the rule that an assistant never asserts a remembered fact without a source it can point to. A model asked "what do you remember about me" can fluently confabulate memories that were never stored, which is the most corrosive failure a companion can have: it fakes the relationship itself. Under this rail, remembered claims must trace to a stored record with an origin, and where there is no source there is no claim. This is one of Violet's non-negotiable build rules: never claim a memory without a source. It pairs with the honest-empty rail, because the truthful answer to "what do you remember" is sometimes "nothing yet," and the product has to be able to say so.
Consent-gated actions
A consent-gated action is any action with an effect beyond the conversation, such as sending, deleting, or changing something, that cannot execute without the user's explicit confirmation, with the gate enforced outside the model. Placement is the whole design: if the model itself decides when to ask permission, a bad generation can skip the asking. In Violet the confirmation gate sits outside the model as a hard rail and is not disableable by settings. The same posture shows up in small places: clearing local data in the trust panel takes two clicks, with the button itself asking "Really clear? Click again." before anything is removed. And the microphone follows the same consent logic in hardware terms: it is live only while the talk button is physically held, so there is no wake word and no always-listening mode to trust.
Why this matters
Trust in an AI product cannot be established by tone. Any interface can sound calm and truthful. The four rails matter because they are checkable from outside: you can open the app with no data and see whether the screens admit it, compare the storage panel against your browser's actual storage, ask about memories you never shared and see whether it invents some, and watch whether anything ever happens without your confirmation. Honest design converts trust from a feeling into a series of small experiments the user can run. For a companion, the product whose whole premise is holding your life, that checkability is not a nicety; it is the permission slip for the entire category.
When honest design costs you
These rails are not free, and pretending otherwise would violate the philosophy. An honest product looks emptier on day one, because there is no sample data softening the blank screens. It cannot ship the growth tactics that fabricate liveliness: invented activity feeds, fake scarcity, streaks with no substance. Its marketing gives up fabricated proof entirely, which means no invented testimonials or user counts while real ones do not exist. And provenance requirements add engineering work that a looser product skips. A team should adopt these rails only if it accepts the costs, because a half-honest implementation, where some numbers are real and some are decorative, is worse than either extreme: it teaches users that nothing on screen can be trusted.
How to recognize honest design in any product
- Open it with no data. Do the screens say so plainly, or do they perform liveliness with placeholders and samples?
- Find a number in the interface and ask where it comes from. A real-or-nothing product can name the record behind it.
- Ask the assistant what it remembers about you before telling it anything. The honest answer is nothing.
- Look for what happens before an action takes effect. Consent should be asked at the moment of effect, not buried in a settings default.
- Check whether the product ever admits a limit unprompted: an unreachable server, an unsupported browser feature, a thing not built yet. Systems that never say "I cannot" are hiding the cases where it is true.
Anti-patterns to avoid
- Placeholder data styled identically to real data, so the user cannot tell which is which.
- Aspirational states: advertising a feature as active, such as sync or backups, when it is off or not built.
- Confabulated recall: letting the model answer memory questions from fluency instead of from stored records.
- Consent theater: a confirmation dialog the system can bypass, or one pre-checked box deciding for the user.
- Silent failure dressed as success: showing a stale or invented state when the real source did not answer, instead of saying it did not answer.
Questions
Is honest AI design the same as explainable AI?
No. Explainable AI tries to make a model's internal reasoning interpretable. Honest AI design governs the product layer: what the interface may render and what the system may do. A product can implement every honest-design rail while using a model whose internals remain opaque, because the rails constrain assertions and actions, not the model's mathematics.
Does honest design mean the AI never makes mistakes?
No. Models still produce wrong and uncertain output. The rails limit the blast radius: fabricated data cannot be rendered as real records, unbacked memories cannot be asserted as remembered facts, and no mistaken impulse can act on the world without a human confirming. Honest design is about what the product asserts and does, not about making the model infallible.
Do these rails apply to products other than AI companions?
Yes. Any product that shows data or takes actions can adopt honest-empty states, real-or-nothing rendering, provenance for claims, and consent gates at the point of effect. The rails matter most for companions because persistence and intimacy raise the stakes, but nothing about them is specific to AI.