A researcher wants to know which facility in a multi-site program has the instrument that can characterize in-plane strain in a particular two-dimensional material.
That question has a real answer. It is sitting on a tool page, in a publication, and in a program record. The person asking will not find it, because finding it requires already knowing which of a dozen sites to look at first. So they do what everyone does, which is to email the one person they happen to know and hope that person forwards it.
We built the thing that shortens that loop. The retrieval is standard practice and not worth writing about. What is worth writing about is the decision we made about what the system is allowed to do with an answer once it has one.
The honest version of "why not just use ChatGPT"
A reviewer will ask this, and they are right to. A public assistant with web browsing answers a good share of these questions for free, and our own estimate was somewhere around two thirds of them.
The remaining third is the entire argument, and it is worth being specific about what sits in it.
The source of truth. A public assistant answers from whatever a search engine surfaced that day, which varies by phrasing and is frequently a page from four years ago. Ours answers from a curated index of every tool page, publication and program record, re-crawled on a schedule.
Something the program can point at. A chat session is ephemeral. It has no URL, it is not a deliverable, and nobody can cite it in a report. A branded page the program owns is a thing that exists.
Metrics. A public assistant tells the program nothing about who is asking what. Every query here is logged, anonymized and aggregate only. That turns "there is external interest in our capabilities" from an anecdote a director asserts into a number they can show.
Correction speed. When a public model is wrong about your program, you wait for a retrain and hope. When ours is wrong, we fix the index that afternoon, because the error is in a document rather than in a set of weights.
A handoff. This is the one that matters, and it gets its own section.
Routing is the feature, not the fallback
Every answer ends with the name and contact of the facility manager who owns that instrument at that site.
That reads at first like an admission of limits. It is the design.
A capability question is not really a request for a paragraph. It is a request to start a conversation with whoever can say yes, and the paragraph is only the part the asker thinks they need in order to start it well. A system that hands over the right name has done the whole job. A system that writes three fluent paragraphs about the technique has done the easy half and left the person exactly where they started, except now more confident.
It also changes what correct means, which is the quiet benefit. Grading free text is hard and everyone in this field knows it. Grading a routing decision is not: either the instrument is at that site and that person runs it, or it is not and they do not. The success criterion becomes something you can actually check, and anything you can check you can improve.
What it refuses to do
The guard rails are more interesting than the generation.
It answers only from pages re-crawled inside the last thirty days. Stale infrastructure data is worse than no data, because a lead time that changed six months ago produces a confident answer that wastes a researcher's month.
It declines anything outside the ingested corpus. The default for a low-confidence question is not a hedge and not a softened guess. It is a plain statement that the system does not have that information, attached to the contact for the site most likely to.
Every factual claim links back to the page it came from. Not a source list at the bottom, which nobody reads. The link sits on the claim.
We tune these systems to refuse more often than a consumer product would, and that costs something real in how satisfying the thing feels to use. It is the right trade every time. A researcher who gets a decline goes and emails somebody. A researcher who gets a confident wrong answer about instrument availability books travel.
The constraint that made it fundable
One architectural commitment carried the whole design: every feature runs on public data we can crawl, plus the program's own existing records. Nothing asks any individual site to take on a new task.
This is not a technical preference. It is the difference between a program asset and a workflow dependency.
A system that needs eleven sites to each keep something updated is a system that degrades at the speed of the busiest one, and every site is the busiest one at some point in the year. Six months in, three of them have stopped, the data is visibly wrong, and the whole thing becomes the tool nobody trusts. Building on what sites already publish means the system improves when they do their normal work, and does not decay when they are underwater.
It also gives a clean answer to the funding question, which any program office will ask. The work compounds on crawler investment that has already been made rather than starting from nothing.
Two things we would tell you before you build one
Version one does discovery and routing. Nothing else. No booking, no scheduling, no calendar integration. The scope creep here is obvious and it is fatal, because each of those turns a read-only system into one that writes into somebody's calendar, and that is a different security review, a different failure mode, and a different conversation with every site.
Write the data residency paragraph before anyone asks for it. University IT pushes back on AI use even when the underlying concern, which is data being used to train models, does not apply to API-based systems at all. Get ahead of it in the pitch: name the provider, commit to US-only regions and container isolation, and state plainly that commercial API providers do not train on customer data by default. That paragraph moves a procurement conversation further than an accuracy benchmark does, and it costs an afternoon to write.
The general version
Most retrieval systems are built to answer. The better question is what the answer is for.
When the real goal is a decision that a specific human has to make, the highest-value output is not prose. It is the shortest correct path to that human, with enough context attached that the conversation starts in the right place. Fluency is the cheap part now. Knowing when to stop talking and hand over is not.