Search turns what a human typed into a specific thing in the graph. A gene, a variant, a disease, a drug. It is the layer every typeahead, entity explorer, and AI agent disambiguation runs through.
Engineering notes, not a contract
Search has one job: take messy input and hand back the right entity, or a short list of candidates, with enough context for the caller to decide what to do next. A caller here is a typeahead in the portal, a graph explorer, or the AI agent resolving a name before it traverses.
The hard part is not speed. The hard part is that the same input can mean different things. “BRCA1” is a gene. “Metformin” is a drug. “Alzheimer” is a disease with several close relatives. Search has to return something useful for all of these without guessing.
Most of the design comes down to recognising what kind of input a caller gave you, because different inputs need different strategies.
Structured identifiers
VCF coordinates, rsIDs, ChEMBL identifiers, ontology codes. These have exactly one correct answer. Search recognises them by shape and resolves directly without going through fuzzy matching.
Short symbolic tokens
Uppercase strings that look like gene symbols. Search prefers symbol matches first, because that is what a scientist almost always means when they type six uppercase letters.
Free text
Everything else. Names, partial names, typos, common misspellings. This is where fuzzy matching earns its place, but always after the cleaner strategies have been tried.
The rule is simple: cheaper and more certain strategies run first. Fuzzy matching is a fallback, not the default.
Every result comes back with a confidence level and a short reason for why the match happened. “Exact identifier match” is not the same as “edit distance two from your input”.
The reason this matters is that downstream code needs to make different decisions based on how sure we are. A typeahead can show low confidence matches as suggestions. An AI agent resolving a name before running an expensive traversal should stop and ask if the match is weak. By returning the reason alongside the result, search lets each caller decide for itself where to draw the line.
Typeahead
The search bar in the portal. Fires on every keystroke, has to feel instant, and returns a handful of top candidates grouped by type.
Entity explorer
Used when a result has been selected and the caller wants to see the entity in its neighbourhood. Returns more results per type and is cacheable, because the same entity view is often reloaded.
Batch resolution
Used by the AI agent and by bulk imports. Several names in, several resolved entities out, all in a single round trip with confidence on each.
The AI agent does not roll its own entity resolution. When it sees a name in your question, it calls batch resolution and gets back the candidates with confidence. If confidence is high it moves on. If confidence is low it asks you which one you meant. This keeps the agent from silently walking down the wrong branch of the graph.
Improvements to search therefore improve the agent at the same time. The two are not separate systems.