User Trust Half-Life: Why One Bad Session Erases Weeks of Calibration

A user's calibration of an AI feature is one of the most expensive things you ship. It costs them weeks of attention: learning which prompts work, where the model's reliable, when to double-check, what to ignore entirely. Then a single visible failure — a wrong number in a generated report, a hallucinated citation the user pasted into a deck, a confidently-incorrect recommendation they acted on — can vaporize all of it in one session. The recovery curve isn't symmetric. The user's prior was "this is reliable," and the update doesn't land as a data point. It lands as a betrayal.

The team measuring DAU sees nothing for weeks. The user keeps opening the app out of habit, runs a few queries, doesn't act on the output, and then quietly stops. By the time engagement metrics flinch, the trust event that caused it is two months old and nobody on the team remembers shipping it.

This is the trust half-life problem, and most AI product teams are flying blind on it because the instrumentation they inherited from the pre-AI era was built for a different failure model.

Trust isn't a number, it's a posterior

When a user interacts with a deterministic feature, their model of it stabilizes fast: it either works or it doesn't, and the failure modes are predictable. A button that submits a form behaves the same way every time. The user's mental model converges in a handful of interactions.

AI features don't converge like that. The user is running an informal Bayesian update on every output, building a posterior over questions like "does this feature get product names right," "can I trust the financial figures," "does it know my codebase well enough to refactor without breaking things," "is the summary actually accurate or is it just plausibly-shaped." Each successful interaction nudges the posterior toward trust. Each visible failure nudges it the other way — but not symmetrically.

The asymmetry matters. A 2025 longitudinal study of conversational AI use found that trust evolves through interaction as users adapt expectations and refine strategies, but the trajectory isn't smooth. Surprising failures cause discrete, sharp updates. The user's posterior over "is this reliable" doesn't decay; it jumps. And once the prior shifts from "reliable" to "not reliable," getting it back requires far more successful interactions than the failure cost, because every subsequent output is now being evaluated under the new, suspicious prior.

Research on human-AI financial advisory interactions captured this with hard numbers: trust erosion after a visible AI error was significantly steeper than trust gain after a successful interaction, and recovery required sustained correct behavior over a much longer window than the original calibration phase. Translation: the customer who saw your feature hallucinate a citation last Tuesday will need substantially more good interactions to come back than they needed to get to "I trust this" in the first place.

The metrics you have lag the metric you need

The default product analytics stack reports lagging indicators of trust: DAU, session length, retention, NPS. All of these move weeks after trust does. A user whose trust collapsed on Tuesday will likely open the app on Wednesday, on Thursday, possibly through the next month — running queries, generating outputs, and quietly not acting on any of them. DAU stays flat. Then in week six the user stops opening it, and the dashboard shows a churn event with no proximate cause.

What you actually need is a trust event stream — a layer of instrumentation that captures the leading indicators trust calibration produces:

• Verification clicks. The user opens a citation, cross-checks a generated number against a source, expands a footnote. Verification is healthy when it's calibrated; an upward spike after a release is a trust event.
• Undo and redo patterns. The user accepts a suggested edit, then reverts it within the same session. Pattern frequency tells you whether the model's outputs are landing as helpful or as noise.
• Escalation rates. The user routes a task that the AI was supposed to handle to a human path, manually edits the output instead of accepting it, or abandons mid-flow.
• Engagement-without-action. Sessions where the user generated output and then took no downstream action with it (no copy, no save, no share). This is the canary metric for the silent-trust-loss period that DAU misses.

Each of these is recoverable from existing telemetry but rarely surfaced as a first-class signal. Teams who run them on a per-user, per-feature basis can see the trust update happening in the days after a regression, not the weeks after.

Surfacing uncertainty before the failure

The other half of the architecture is the failure-prevention side: making sure trust updates happen incrementally rather than catastrophically. The cheapest way to do this is to surface the model's uncertainty visibly enough that the user's mental model includes "this can be wrong" from the first interaction, so a future failure is a confirmed prior rather than a betrayal.

Loading…