The hard part of scientific AI isn't always finding more information. It's working out what kind of answer the question actually needs: published literature, measured data, a new analysis, or a prediction.

Ask a scientific AI system a question and the first visible action is often a search. That makes sense. Biomedical research is built on an enormous literature, and much of what a researcher needs has already been published somewhere.

But not every scientific question is a request to find what a paper says.

Some ask for a measurement that was actually recorded in an experiment. Others need several of those measurements compared or analysed together. And some ask about something no one has observed yet, a value that can only be estimated with a computational model. These are genuinely different tasks, even when they arrive through the same text box.

A system can retrieve excellent papers and still fail if search was the wrong way to approach the question.

Questions That Look Alike but Aren't

The same drug discovery project can produce questions that look similar in a chat box but require very different operations.

A mechanism question, such as how CRBN molecular glues work, is primarily a literature task. A target-dependency question may be answered more directly from CRISPR screening data in a resource such as DepMap. Working out what compound-sensitive cell lines have in common requires analysis across drug-response and molecular-feature data. Estimating an unsolved protein structure requires prediction, and the output is a modelled estimate, not an experimental observation.

All four concern biomedical evidence. Only one is primarily a literature search.

Routing Is a Reliability Problem

From an engineering perspective, the first challenge is routing: identifying the operation hidden inside the question and sending it to an appropriate source or method. Retrieval works when the answer has already been expressed in searchable sources. It cannot produce an analysis that was never performed.

A routing error does not always cause a visible failure. The selected tool may run successfully and return technically valid output, just for the wrong task. A literature summary can appear to answer a dataset-level question. A model may fill a missing measurement with plausible language instead of switching to a database query or simply stating that the evidence isn't available. This is one of the ways fluent systems produce inaccurate or unsupported answers.

Reliability therefore depends on more than the underlying language model. It requires classifying the task, limiting which tools can be used for it, keeping outputs structured so the type of evidence is preserved, checking both inputs and results, and having a fallback when no route fits. Better generation cannot make up for evidence gathered through the wrong process.

Where a Result Comes From Changes What It Means

These are three different kinds of result, and the difference matters. A measured value comes from an experiment, though it can still carry noise, bias and gaps in coverage. An analysed result is built from existing measurements, and depends on choices like filtering, normalisation, grouping and statistical method. A prediction estimates something not yet available, and inherits its model's assumptions and limits.

None of these is automatically superior. A prediction can be genuinely useful when no experimental structure exists. A reanalysis can reveal a pattern no publication has described. A database measurement can be more directly relevant than a broad literature conclusion. The problem begins when the categories are collapsed together and their different uncertainties disappear.

For a researcher, knowing how a result was produced is part of knowing what it means.

Knowing When Not to Use a Tool

This is where scientific AI becomes harder than connecting a language model to a collection of tools. The system has to recognise the real task behind the question. It has to decide whether to search, query, analyse or predict, and sometimes combine several routes in the right order.

Complex questions often need several routes in sequence. Prioritising a drug target, for example, might draw on published work on its mechanism and safety, dependency data from relevant models, expression in the tissue that matters, and then a fresh comparison across candidates. To do that, the system has to break the question into steps, keep track of how those steps depend on each other, and keep every output tied to the operation that produced it.

It also has to know when not to use a method that is available. A database may not cover the relevant disease model. A docking score may not support the biological conclusion being asked for. An analysis can run successfully while resting on groups too small or poorly matched to interpret. Technical completion is not the same as scientific usability.

The Answer Should Preserve Its Route

Once several evidence paths are combined, provenance becomes essential. Published findings, experimental measurements, new analyses and computational predictions should stay distinguishable in the final answer, each keeping its source, method and limitations.

Otherwise, the smoothness of the answer works against the researcher. Different kinds of evidence merge into one confident narrative, and the reader loses what they need to tell what is established, what has been calculated, and what remains hypothetical.

This is the principle Clarisyn is built on. Rather than treating every question as a search, it works out what each one actually requires, whether that means retrieving literature, querying a dataset, running an analysis, or generating a prediction, and keeps each result tied to the method and evidence behind it.

The ambition for scientific AI should be larger than better search, but more disciplined than automatic tool use. The goal is to choose the route the question actually requires, show what happened along the way, and return an answer whose strength does not exceed the evidence that produced it.