Status. An HQ-S26 research note: work done by fellows of the HyperQuark Research Fellowship between April and July 2026, written up by the lab from the track's own files. It is a design note: the track built components and did not complete an evaluation, so it reports no results. It has not been reviewed outside HyperQuark, and its code and data have not been released.
The question
A search-then-answer system is only as good as its first search. If a question is vague, or needs a fact the first search did not reach, the system still answers, from whatever it found, and sometimes from nothing it found. The track's question was whether a light step, notice that the first retrieval was weak, rewrite the question, search once more, would make answers better grounded without the cost of full planning.
HQ-S26 was HyperQuark's first cohort: twelve fellows in four tracks, twelve weeks, weekly reports due every Sunday. No track reached a final submission, so every result here is interim and is reported as the track left it.
The design
-
Ask. A question arrives at a backend service.
-
Retrieve. Passages are found in a corpus of scholarly papers, fetched from a public preprint server, parsed and cut into passages.
-
Check. A failure check looks at the retrieved passages and the draft answer: is what was found close enough to the question, and is the draft answer vague or unsupported by it? It returns a verdict and a reason.
-
Recover once. If the check fails, the question is rewritten and retrieval runs a second time; the loop stops there.
-
Answer, with the trail. The answer comes back with its sources and the steps taken, which the interface shows the user, so a second search is visible rather than hidden.
The track kept recovery to one attempt on purpose: each extra search costs time, and an unbounded loop can wander from the question.
What the track built
-
A backend service with a question endpoint (answer generation was still mocked when the track stopped).
-
The failure check, returning a verdict and its reason.
-
Ingestion of papers from a public preprint server, with parsing and passage-cutting planned.
-
An interface that displays the plan, the retrieval and the reasoning steps.
An observation worth testing
Questions containing words like recent, latest, new or current tended to skip retrieval and be answered from the model's own memory, which is exactly where a model is most likely to be out of date. A system that routes such questions to fresh sources by default may avoid a common class of stale answers. The track did not measure this.
What an evaluation would need
A fixed set of questions, including vague and multi-step ones, with expected answers set before any run; the single-pass system as the baseline; and measures of answer accuracy, how relevant the retrieved passages are, and how often an answer states something its sources do not support. The track planned this with 10 to 20 questions and did not run it.
Limitations
-
No end-to-end run is documented, and there are no results.
-
The track's research claim changed between weeks 3 and 5, from recovering from weak retrieval to structuring an agent's workflow; this note follows the earlier, better-documented claim.
Contributions
-
Madhu Priya Pulletikurthi (Track Lead): research design, and the evaluation and failure-check module.
-
Farah Cisse: backend orchestration and the contract between components.
-
Thomas Hazarika: retrieval and paper ingestion.
-
Abhishek M. Sharma: the interface and gateway that show each step, and the observation about time-sensitive questions.
-
Bishnu Dev Changkakoti (Programme Director): set the fellowship's research agenda and directed the track.
Code
Not released.
