AI features earn trust by showing their working

By Meet Patel · 2026-10-03 · 6 min read

In 2023, two New York lawyers filed a court motion that cited several cases generated by ChatGPT. The cases involved fictitious airlines and carried fabricated quotations. When the lawyers asked ChatGPT to confirm the cases were real, it assured them they “indeed exist” and could be found in reputable databases such as LexisNexis and Westlaw. Judge P. Kevin Castel fined the lawyers $5,000 on June 22, 2023 (Mata v. Avianca, summary of the sanctions order).

The only verification the lawyers sought came from the same model that produced the cases, so the reassurance was more generated text and added no independent evidence. In my view many AI features present answers the same way, as finished sentences with the evidence out of sight, and the fix is mostly interface work. An AI feature earns trust when it shows its working: the sources behind an answer, how sure it is, and what would change it.

What Google’s guidebook says to put on screen

Google’s People + AI Guidebook, from its PAIR research group, treats explanation as a trust-calibration problem. Its chapter on explainability says the user “shouldn’t trust the system completely” and, based on the explanations, “should know when to trust the system’s predictions and when to apply their own judgement” (People + AI Guidebook, Explainability + Trust).

The same chapter makes a point about data that I find the most useful: telling users what data the model is using can help them know when they hold a critical piece of information that the system does not. A finance lead who can see that a forecast excluded unsigned contracts can supply the missing fact. A finance lead who sees only a number can accept it or reject it, and neither choice improves the next forecast.

From that I take three elements that every consequential AI answer should carry: sources, confidence and a statement of what would change the answer. The rest of this post takes them one at a time.

Sources: claim-level, dated and scoped

A source list at the bottom of an answer is a bibliography. Evidence works better attached to the claim it supports, so that a reader can open the exact record behind one sentence and skip the others. Three details make a source useful:

• Claim-level links. Each figure or assertion points to the row, document or passage it came from.
• A read date. Data changes, so the answer says when each source was read.
• Scope and exclusions. The answer states what it looked at and what it did not, for example “billing system and CRM, not the contract tracker”.

Here is how a hypothetical revenue assistant might present a forecast to a finance lead. The figures are invented for illustration.

Q4 revenue forecast: $2.4M (likely range $2.1M to $2.6M). Based on invoices through 30 September from the billing system and pipeline stages from the CRM as of 1 October. Not included: contracts awaiting signature. Would change if: the two renewals worth $180K slip past 31 December.

That answer is four sentences, and each one gives the reader something to check or contest. This is the gap between an answer and a confident sentence: the claim arrives with its basis attached.

Confidence: show it when it changes what the user does

The PAIR chapter lists several ways to display confidence: categorical labels such as high, medium and low, n-best alternatives, numeric percentages, and visualizations with error bars. It also warns that confidence should be left out when it is not impactful or when showing it could create mistrust (People + AI Guidebook).

My rule is to show confidence where it changes the next action, and to define each level by that action:

• High: the user can proceed, and the source is one click away if they want it.
• Medium: the user should open the source before acting.
• Low: the answer is a lead, and a person should verify it first.

A label only works if it is calibrated, meaning the answers marked 90 percent should be right roughly 9 times in 10. The check takes a sample of past answers, groups them by stated confidence and compares the label with the share that held up. That is the same calibration table described in the post on judging the decision rather than the outcome. A confidence label nobody has audited will teach users to ignore it, which is worse than having none.

What would change the answer

This is the element most likely to be left out, and it is the one that turns a reader into a participant. It lists the assumptions and thresholds the answer depends on, in terms a user can contest. In the forecast above, the two renewals are the swing factor. If the user knows that one of them has already been signed, they can say so, and the assistant can recompute.

Three forms of the statement are available:

1. A named dependency: “Would change if the two renewals slip.”
2. A threshold: “Holds as long as weekly churn stays below 1.5 percent.”
3. A missing input: “Cannot account for pricing changes announced after 1 October.”

Each form gives the user a precise place to push. It also produces a useful by-product: the corrections users make become a record of where the system’s assumptions were wrong. PAIR makes a related point in its errors chapter, noting that many of the errors users experience require their feedback in order to improve the system, and that when an AI system fails, often the easiest path forward is to let the user take over (People + AI Guidebook, Errors + Graceful Failure).

Why companies should want an evidence trail

In February 2024 a British Columbia tribunal ruled on a dispute in which Air Canada’s website chatbot told a customer he could apply for a bereavement fare within 90 days of his ticket being issued, and the airline then denied the retroactive claim. Air Canada argued it could not be held liable for what the chatbot said. The tribunal disagreed and wrote that “it makes no difference whether the information comes from a static page or a chatbot.” It ordered the airline to pay the customer $812.02 in damages, interest and fees (Daily Hive, MobileSyrup).

Reports of the case disagree on whether the chatbot also linked to the policy page, so I will not build anything on that detail. The finding is enough: a company owns the sentences its AI feature produces. A product that stores, for every answer, the sources it read and the version it used can reconstruct why a sentence was said, which is the foundation of any later correction or defense. For the wider question of what happens once an agent can query your data, see AI agents can query your data.

A specification you can hand to a designer

I would put this list into the requirements for any AI answer that informs a decision:

1. Every figure or claim links to its source record.
2. Each source shows the date it was read.
3. The answer states its scope and names what it did not include.
4. Confidence uses defined levels, and each level maps to an action.
5. Confidence labels are audited against outcomes at least quarterly.
6. The answer lists what would change it, as a dependency, a threshold or a missing input.
7. The user can correct an input and see the answer recompute.

To keep the screen readable, show one line by default and put the full evidence behind an expand control. PAIR’s guidance on partial explanations supports this: an explanation can leave out parts of the system’s function that are unknown, complex or simply not useful, while still telling the user what the answer rests on.

One test summarizes the list. Take an answer from last week and give it to a colleague who did not see the original session. If they can reconstruct why the system said what it said and where it might be wrong, the feature shows its working. If they cannot, the interface is asking users to trust a tone of voice. The principle I would hold to is that an AI answer is finished when someone other than its author can check it.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com