We moved the work to before the question.
Agentic retrieval over financial documents. A retrieved number arrives knowing what it is. Almost every decision here comes from doing something once, slowly. Instead of every time, under pressure.
The problem
A number without its labels isn't an answer.
A portfolio manager isn't doing research for its own sake. They're producing a report on somebody's investments. The research is a step inside that job.
So a retrieved number has to arrive knowing what it is. Twelve point four per cent of what? For which fund. In which month. On which basis. Most retrieval loses exactly that. It reads text first and works out the structure afterwards.
Grounded, cited, or abstain. Never guessed.
That principle costs coverage on purpose. Here, a confident wrong number is worse than no number.
That trade was mine to make. In a demo it looks worse. In the job it's trusted faster, because the person signing off learns they can believe what it does return.
Job one, done once
The number can never arrive naked.
A detector classifies each region of the page before any text is lifted. This is a table. This is a chart. This is a paragraph. Then a table is captured as a table. Every row carries its own headers.
Twelve point four per cent of what?
The chunk carries its own context, so retrieval can't strip it.
Charts become data
A vision pass reads the chart and writes out the series itself, stored beside the chunk, so asking for March's value looks up a number. Not squinting at a picture.
One name per thing
Three spellings of the same fund collapse to one canonical ID. Dates all become one format. So "July 25", "Jul-25" and "FY26 Q1" stop being three different questions.
One meaning per concept
Portfolio holdings, invested companies and asset portfolio mean the same thing to a fund manager, so they map to one concept, using the finance industry's public standard vocabulary.
Why do this at storage time rather than at question time? Otherwise every question pays that cost again, under uncertainty. Do it once, and finding the right chunk becomes a cheap filter. Not a guess. That's the single most important idea in the system.
Job two, done per question
Filter first, search second.
Narrow to the exact fund and the exact month before comparing meaning. The technical brief calls that ordering the biggest lever in the whole design, and it's what stops March's factsheet competing with January's.
The tables
Straightforward retrieval of a stored value. No reasoning required, so none is paid for.
The knowledge graph
Which of our funds hold banking stocks. A question about connections, not about text.
The vector store
Where the question is about what something says rather than what it equals.
Two searches run at once. Meaning-based search finds the right paragraph. Keyword search finds the exact code. They fail in opposite directions. So both run, and the results merge.
Arithmetic goes to a calculator, not to the model. Any sum becomes a database query. The model decides what to calculate. The database calculates it. That turns a ten-year revenue question into an exact result. Instead of a hallucination risk.
What was measured, and what wasn't
The brief is honest about this, so the page should be too.
The pitch describes documents of eight to ten thousand pages. The corpus was a few hundred pages. Neoflo's own brief calls the huge-document capability "motivated, not yet tested at full scale."
The architectural claim is that document size stops mattering once indexing happens offline. Cheap to prove. Embarrassing to leave unproven. Run one real filing end to end. Publish the ingestion time and cost.
Fourteen questions per tier means a single question is worth about seven points. No individual percentage here is bulletproof. The claim worth making is the pattern, not any one figure.
The baseline is sending whole documents to a frontier model. Nobody runs that in production. It's a real comparison, and it isn't a competitive one. The head-to-head against a properly built alternative is still missing.
Meaning-based search treats "funds that don't hold banking stocks" as very similar to "funds that hold banking stocks". Close in meaning space. Opposite in fact.
It's used mostly for scoping. Deep multi-hop questions are still hardening. The kind the graph exists to answer.
Aggregation across many documents depends on the calculator path being taken. Where a query slips into model arithmetic instead, the maths becomes a risk. That tier was never benchmarked at all.
What comes next
Prove the claim the whole design rests on.
One real filing, end to end, with the numbers published. Ingestion time, cost per document, and accuracy at that size. If document length genuinely stops mattering once indexing is offline, prove it. That's the most valuable demonstration available.
Then a real competitive baseline. Beating brute force proves the design is sensible. Beating a properly built alternative proves it's better.
And a decision on negation. That's a correctness problem, not a ranking one. It won't improve with a better embedding.
