Speed is a feature, trust is the product
Every latency benchmark in this industry measures the same half of the clock: the part between your question and the first word of the answer. It is the half you can see, and it is not the half that decides anything.
The other half is the checking. It happens after the benchmark has stopped, inside the reader, and it is frequently longer than the wait it followed.
The clock nobody starts
A tool that produces a confident-sounding answer in two seconds and then needs three minutes of verification before you can use it is, in practice, slower than one that takes thirty seconds and hands you something you can act on. Both numbers are real. Only one of them gets published.
This is not a rhetorical trick, and it is not an argument against being fast. Fast is good. The point is that "time to first token" and "time until the work can move on" are different quantities, they are not correlated, and the entire industry optimises the first because it is the one you can put on a chart.
The gap between them is filled by a specific, tedious activity: cross-referencing, re-reading the source, checking whether the number in the summary is the number in the filing, deciding whether the confident sentence is confident because the evidence is strong or because the prose is. That activity is invisible to the tool, invisible to the benchmark, and entirely visible to the person doing it at half past four on a Thursday.
Fluency is the problem, not the fix
Here is the uncomfortable part. The better the writing, the more expensive the checking.
An answer that reads badly gets scrutinised. An answer that reads well gets believed. Fluency is the property these systems have improved fastest, and it is the property most decoupled from correctness — so the industry has spent several years making errors harder to notice while making them no less frequent.
For casual use this barely matters. For professional work it decides everything. It is the exact mechanism by which an AI tool ends up filed under "useful for drafts, not for anything important" — not because it was wrong often, but because when it was wrong there was no surface cue, and after one bad experience the reader can no longer distinguish the good answers from the bad ones without checking all of them. At that point the tool has negative value: it produces work you must audit at full cost.
What we tried instead, and dropped
Two approaches came before the one we settled on. Both are worth naming because both are widely shipped.
Confidence scores. The obvious fix: have the system say how sure it is. We built toward this and stopped, because a calibrated confidence number is a much harder thing to produce than a plausible one, and a plausible one is worse than nothing. A number that says 0.87 invites exactly the behaviour we were trying to prevent — it replaces the reader's judgement with an arithmetic-looking token that has no arithmetic behind it. Worse, it fails asymmetrically: the cases where the system is confidently wrong are precisely the cases where the confidence score is also confidently wrong, because both come from the same place.
Hedging. The other obvious fix: make the language cautious, so nothing reads as more settled than it is. We rejected this one faster. Hedging everything is the same as hedging nothing — the reader normalises it within a day and it becomes noise, while the genuinely uncertain claims lose the only signal that would have distinguished them. It also degrades the tool: a professional asking a question needs an answer, and universal hedging is a way of declining to give one while appearing responsible.
What both attempts have in common is that they try to communicate reliability about the answer. The thing that actually works is communicating where the answer came from, and letting the reader do the calibration they are already better at than we are.
Provenance changes the question being asked
This is the substitution that makes the difference, and it is smaller than it sounds.
Without a source, the reader's task is: is this right? That question is frequently unanswerable from the output alone. It has no bounded cost — you can spend five minutes on it or fifty and never reach certainty.
With a source, the task becomes: does this source support this claim? That question is answerable, it is fast, and it terminates. You open the thing, you look, you are done.
Provenance does not make an output correct. It converts an unbounded verification problem into a bounded one, which is the difference between a tool you can build a process on and a tool you cannot.
It also encodes a position about who is doing the work. If the tool is meant to replace professional judgement, sources are decoration. If it is meant to give a professional better raw material, sources are the material. We hold the second view, which is why provenance is a default rather than an expandable panel.
Trust accumulates slowly and leaves at once
The asymmetry here is severe and it shapes what we build first.
Someone who uses a tool for six months and finds it consistently accurate, consistently sourced, and consistently behaving the way they expect develops a working relationship with it. Someone who hits one significant confident error — one chart computed on a stale slice, one summary that dropped a material fact — recalibrates immediately and permanently. Not for that feature. For the whole product.
So features that make the tool more impressive are valuable, and features that make it more dependable are prior. An impressive tool you cannot quite trust gets used for low-stakes work forever. A dependable tool gets moved into the work that matters, which is the only place any of this pays for itself.
Where this position is weakest
Two admissions, because a note like this without them is an advertisement.
Provenance is not free at the point of use. Sources take space, they take a click, and there is a real population of tasks where the reader does not want them and is right not to want them. Showing the working is a cost we impose on every answer to protect a fraction of them. We think that trade is correct and we know it is a trade.
A source can be present and still not settle anything. Citing a document proves the claim came from somewhere. It does not prove the somewhere was any good, and a confidently cited weak source is its own failure mode — arguably a more dangerous one, because the citation reads as diligence. Provenance shifts the burden from "is this true" to "is this source any good", which is a much better question to be stuck on and is still a question.
What we would do differently
We would have treated verification time as a product metric from the beginning, rather than as something that happens to users after our part is over.
Everything gets measured up to the moment the answer renders, and nothing after it — which means the number the team watches every day is structurally incapable of noticing the cost this whole note is about. We could improve response time by a wide margin and make the product slower to actually use, and the dashboard would show a win. That is not a monitoring gap, it is a design flaw in what we chose to count.
Speed will keep improving across the industry; every platform gets faster and the capability floor rises on its own. The differentiation speed buys in 2026 is table stakes in 2028. Trust does not work like that — it cannot be bought from a provider or unlocked with a new interface. It is the accumulated record of a tool behaving the way it said it would.
Speed brings people in. Trust is the reason anyone is still here in a year.