Sign in Subscribe
AI Signals and Reality Checks

AI Signals & Reality Checks: Decision Provenance Turns Into Default UX

Kaizhi Tang

• 3 min read
Minimal abstract motif of a single signal line splitting into provenance checkpoints
AI Signals & Reality Checks — Feb 19, 2026

AI Signals & Reality Checks (Feb 19, 2026)

Signal

“Why did it do that?” is becoming a first-class product surface—not a support ticket.

As AI systems graduate from “answering” to acting (booking, routing, editing, approving, sending), teams are quietly standardizing a new UI primitive:

Decision provenance: a compact, structured trace of what the system used and what it decided.

Not a long explanation. Not a motivational story. A readable receipt.

In practice, the best products are converging on a small set of provenance fields that users actually care about:

  • Inputs: what data sources were consulted (email thread, calendar event, CRM record, doc section).
  • Constraints: which rules/policies were applied ("do not email external domains", "expense limit $X").
  • Tool calls: what actions were attempted (drafted email, created event, opened ticket) and with what parameters.
  • Uncertainty: where the system was unsure (missing attendee, ambiguous account, conflicting dates).
  • Diffs: what changed (before/after) when it edited something.

This is the UI equivalent of moving from “trust me” to “here’s the trace.”

Reality check

Provenance only builds trust if it’s auditable—otherwise it becomes a decorative “because AI said so” layer.

Most teams underestimate how easy it is to ship provenance that looks good but fails in real operations:

  1. The trace must survive retries and partial failures. If an agent runs the same task twice (network glitch, tool timeout, user changes one parameter), the “receipt” can’t quietly mutate without a record. Users notice when the UI says it used Source A yesterday and Source B today for “the same thing.”
  2. The trace must be tied to real artifacts. If the provenance claims “consulted CRM” but can’t deep-link to the exact record/version, it turns into theater. A provenance line is only useful when it’s grounded: record id, timestamp, query, or snapshot hash.
  3. The trace must include policy decisions, not just model decisions. In agent systems, many failures are not “the model hallucinated”—they’re “the policy layer allowed it” or “the routing layer picked the wrong tool.” If provenance hides those layers, you’ll still be debugging in the dark.
  4. Over-explaining is a trust killer. Users don’t want essays. They want:
  • the one reason it chose this action,
  • the one risk it detected,
  • and the one place they can correct it.

If provenance turns into verbose rationalization, it trains users to stop reading—right before the moment they need it.

Second-order effect

“Receipts” will become a competitive moat—and a compliance requirement.

Once provenance exists, it spreads:

  • Support teams want it for faster incident resolution.
  • Security teams want it as an audit trail.
  • Product teams want it to A/B test autonomy thresholds.
  • Users want it to decide when to grant broader permissions.

Two practical shifts follow:

  • Provenance-first design: you architect the agent so every meaningful decision emits a structured event.
    • If it didn’t emit, it didn’t happen.
    • If it happened, it’s linkable.
  • UX for correction, not explanation: the trace becomes an interactive object.
    • “Use a different thread.”
    • “Exclude this contact.”
    • “Set a stricter policy next time.”

This is where provenance stops being transparency theater and becomes control.

What to watch (next 24–72h)

  • Do agent products standardize a “receipt schema” (inputs, tools, policies, diffs) that is portable across vendors?
  • Are teams instrumenting provenance in the same pipeline as reliability telemetry (so you can correlate failures with specific tool-call patterns)?
  • Do we see provenance compressed into a single line that users can scan—and expand only when needed?

Source note

阅读中文版本 →