Product case study
Verification as the product, not a feature.
Most AI research tools are tuned for how an answer feels. Vireon is built on the opposite bet: in financial research, people need a reason to believe the answer. This is how that bet became three shipped products, and what broke along the way.
Ori Optic · Deep Research
"How did Nvidia's quarter compare with what analysts expected?"
Reading sources
sec.gov · the quarterly filing
Elapsed41s
The problem
An AI that answers financial questions is not hard to build. An AI whose answers you can act on is a different product.
When an assistant says oil surged, you cannot tell whether that came from a wire service this morning or a content farm last quarter. Both arrive in the same confident voice. In finance, where someone may size a position on it, that is a defect in the core promise.
So the thesis is narrow. The differentiator is verifiability, not answer quality. Every claim traces to a source, every source carries a known trust weight, and the confidence score shows its arithmetic.
The fast path
Answers in under a minute, with citations in the text, a confidence score and a panel of sources.
The deep path
Up to 40 sources, a reading pass on each one, and a longer written report.
The standing path
Groups market news into events, then goes looking for a second outlet when only one carries the story.
Trust as a number
If verifiability is the product, it has to be readable in two seconds. That means one number, and being able to defend it.
The foundation is a registry of 622 domains, sorted by hand into four trust tiers and an exclusion list. It is the least glamorous part of the system and everything rests on it.
One tick is ten domains. Choose a tier to find it.
A and B sources can carry a claim alone. C and D can support one but never establish it. That is a judgment about what counts as evidence, so it sits with product, where someone has to defend it.
Checking the registry for this page turned up four domains sitting in two tiers at once. Their weight was being decided by which list the code read first, not by anyone's decision.
Writing the fix took ten minutes. Deciding it took longer, because the question was editorial: is an aggregator that also reports a news outlet? Three of the four moved down a tier.
The durable part is the test. The registry now fails its own checks if a domain appears twice or if the total drifts from the figure on this page.
Three questions, one number. Change the sources and watch each part respond.
5 credible outlets across 3 tiers. Each extra outlet adds a little less than the one before.
How good are these sources?
How many credible outlets arrived at this on their own?
Is this an echo chamber?
The first version scored how much sources agreed with each other. In production it did nothing. Tagging each source's stance was never reliable, so almost everything landed on neutral and the score sat low however strong the sourcing was. It was teaching people that Ori was unsure of everything.
The replacement measures something the system can observe: how many distinct credible outlets arrived at the story.
Credible outlets, and the corroboration score they earn. One outlet is thin, not worthless.
What it taught me
A metric can be defensible in review and inert in production. Only live traffic showed it.
Corroboration
A score tells you how well corroborated a story is. It does not make the story better corroborated. That second job is where the news product earns its keep.
A feed of articles shows the same event five times when a story is picked up widely, and syndication starts to look like significance. So LiveFeed groups articles by the event they describe and writes one story per event.
Any article the model leaves out gets its own story. A tidy result that ignored ten inputs is a worse product, and nothing in the output would show it.
A story's ID decides whether tomorrow's coverage joins today's story or forks a copy. The system accepts a known ID or builds one from the articles. It never trusts one the model made up.
One outlet breaks a story and publishes it three times. Count articles and the event looks well covered. Count publishers and it is thin. The system treats that as a task.
Search for the same event, using the story's own summary.
Set aside outlets already in the story, and anything outside a short list of established publishers.
Read up to three new publishers and fold them in, marked as found by search.
If any step fails, the story stays single-source and is labelled that way.
What it taught me
"Poorly corroborated" is not only a fact to report to the reader. It is a task to queue for the system.
Cost and speed
A deep research run costs many times what a standard answer does. Most of that is breadth: every extra source is read before writing starts. The real lever is deciding who gets how much.
Edge and trial read 40. A trial has to sell the thing being sold, so it runs at full depth.
The paywall and the cost control are the same setting. One tick is one source.
First words on screen
A full fresh answer
A repeat question, from the saved answer
Deep research
Most of the wait is the model writing a long answer. That is the price of the depth we chose. Saying so plainly freed the effort to go where it paid: the costs that bought nothing.
Long answers hit the output limit, came back cut off and triggered a full retry. Raising the limit removed the retry and 30 to 40 seconds.
The model was asked for a source list the server rebuilds anyway. Removing the field saved three to five seconds.
Saving the session was finished before the answer was released. Moving it to the background cut six seconds to three milliseconds.
What it taught me
The biggest savings did not make the model faster. They removed work that was never holding anything up.
Four failures
Every one of these reached production. None was a model quality problem, and none would have been caught by grading answers.
A live answer showed WTI crude above Brent, both as current prices. WTI trades below Brent. Both figures were real. One was a historical peak presented as today.
On a trust product, accuracy is a release gate, not a quality metric.
A fixed consistency check now runs after writing and before release. On a flag the answer is discarded and the last good result is served, clearly labelled.
Citations that matched nothing the system had retrieved.
For anything carrying trust, the model proposes and the server disposes.
The model lost authority over sources. The server builds the list from what it retrieved, and the model cites by position. It matters because one invented link does three things:
Extraction quality fell quietly. A third-party call was failing on every request, and the fallback produced output that looked plausible.
A fallback that produces plausible output is an outage you cannot see. Degraded paths have to be loud.
One provider, one key, one failure mode.
Saved results went missing for questions that had run, so expensive retrieval was paid for twice.
Correctness that only shows up in a bill will not be found by testing for correctness.
Background work now registers with the runtime, so it survives the end of the response.
Carry forward
The pattern is the same across all four. They were decisions about where authority sits, what a fallback may do quietly, and which failures are allowed to reach a person. Building on a model turned out to be much less about the model than I expected.
The rule appeared twice on its own. Ori discards the sources a model emits and rebuilds them from what it retrieved. LiveFeed discards the story IDs a model mints and rebuilds them from the articles. Let the model judge, and never let it hold the key.
The decision I would defend hardest is making accuracy a gate. It costs answers, and it is the reason the product has a claim worth making. The decision I would revisit is shipping the first confidence formula on reasoning instead of data.
Ori Search, Ori Optic and LiveFeed are live today.
See Vireon live