Using AI for Building Trust and Transparency

The expensive failure isn't a wrong answer

Direct answer: Most writing about trustworthy AI is about stopping a model saying something harmful. That matters, and it is not where the money goes.

The expensive failure is an assistant that does exactly what you asked, correctly, and hands back something nobody wanted. It is invisible in every log: the request succeeded, the tool returned, the bill is real. We have a case that started this work — a search for dentists returned 25 real dentists, every record correct, and the fit column on each one read “no relevant fit” for what that account actually sells. Nothing failed. One question up front would have caught it.

The second expensive failure is a confident sentence resting on nothing. An assistant that hedges everything is useless; one that hedges nothing is worse, because you cannot tell which sentences it actually checked.

Both are trust problems, and neither is solved by asking the model to behave better. That is the part we got wrong first.

Rule one: if it matters, it is code, not a prompt

Direct answer: We tried the instruction route. A tool returned an internal note that began, in as many words, do not repeat this to the user. The model repeated it to a user. We rewrote the instruction to be more explicit. It repeated it again.

That is not a story about a bad model. It is a story about a bad mechanism. Every rule in our system that has actually held started as code — the spend gate, the send confirmation, the outbound scan. The ones written as instructions are the ones that regressed quietly, on a customer’s tokens, weeks after anyone was watching.

So the honesty features described below are not prompt lines. They are functions that run over what actually executed, and the model does not get a vote.

It questions the job before it bills you

Direct answer: Eight tools now check a request before any money moves. The check lands as one sentence on the approval card you were already reading, in front of the button it affects.

“Before you confirm — 3 of these 12 won’t go out because they unsubscribed or failed verification, so 9 will actually send.”

That number 12 was ours. We put it on the screen. The send loop would have skipped three of them — correctly, for compliance and deliverability — and told you afterwards. Reporting it afterwards is the defect: you approved a number that was never achievable.

Six of those eight checks call no model at all. They are arithmetic on records already in hand: how many of these contacts carry a verdict from this week, how many days since the last crawl, how many answers a sample will actually produce. This is deliberate. A model-based check that fires wrongly argues with you about your own market, and users who get argued with once learn to click past the warning forever. Where a check can be deterministic, it must be.

One check was built and then deleted. It sat behind a threshold it could never reach — the call cost more than the spend it was protecting, so the card it would speak on never opened. We record that rather than quietly removing it, because “we tried and it was wrong” and “we never looked” are different facts that look identical in an empty registry.

It marks the claims it could not verify

Direct answer: When the assistant researches something, it searches the web and reads live pages mid-answer. The honesty question is what it is then allowed to assert.

A version of our own product once wrote that a page “does not have the same level of optimization and relevance” — and three lines lower, correctly listed that same page under what it had been unable to read. Both halves shipped in one message. The footer was honest about a claim that was not.

A caveat underneath an assertion does not retract the assertion. Readers keep the specific sentence and drop the general disclaimer, which is precisely backwards from what the evidence supports. So the system now records which pages were actually read, and marks any sentence describing one that was not, in the sentence itself: (unverified — we could not read this page).

A search result does not count as having read the page. A search returns a title and a snippet, which grounds “this page exists” and never “this page is better optimised” — and that second claim is exactly the one the original defect made.

It ends by saying what it could not check

Direct answer: Every answer that hit a wall closes with a short list: which page refused us, which search came back empty, and the line that makes it matter — anything above that depends on these is unverified.

Two distinctions are load-bearing there. A site that blocks automated readers is a permanent boundary on the analysis, not a glitch worth retrying, and the answer says so by name. And a search that ran perfectly and returned nothing is still a gap: status “ok” with zero results is not an answer, and reporting only hard failures would hide the commoner case.

The footer is rendered from the execution record, not requested from the model. It cannot be forgotten on a busy turn, which is the only property that makes it worth reading.

It never blocks you

Direct answer: Not once, anywhere in the layer. Every check adds a line and usually a one-click better option to a card that already had a Confirm button, and that button still means run it anyway.

This is not politeness. It is your budget and your market, and an assistant that overrules you on either is worse than one that stays quiet. The measure of the layer is not how often it fires — it is whether the times it fires were worth your attention.

What it still cannot do

Direct answer: Claims are marked when they name the page. A sentence that says “that page is thinner” with no domain in it cannot be attributed to a target by any honest reading, and guessing would put warnings on correct sentences. The named case is the one that actually occurs, because users give us the URL. The pronoun case is open.

Some sites refuse us and always will. We report that as a boundary rather than working around it.

And the checks above cover eight tools, not everything. The rest sit in an exemption list with a written reason, and a build check fails if a tool appears in neither — because a silent gap and a considered decision look the same from outside.

We would rather publish that list than a claim of completeness. That is the same instinct the whole feature set is built on: the trustworthy version of an AI product is not the one that sounds most certain, it is the one whose uncertainty you can see.

Evidence and scope

Review date: 2026-08-21.

Reproducible use. Use the framework with a defined audience, source data, and review date; test material recommendations against your own evidence before making a production or buying decision.

Limit. This article is educational guidance, not legal, financial, security, or performance assurance.