What actually happens when you hit search

Think about how you actually solve an R&D challenge.

You start with a question and you search. You read an abstract, decide it's worth more, pull the parameters that matter. You read another, and another. You start comparing technologies against each other. Somewhere in there you realise the question you began with was wrong, so you reframe it and search again with better terms, and you get better results. There are a lot of interesting ones, so inevitably you open more and more tabs. The number grows. You structure what you've found into something the team can look at. You present it back. The team decides a direction. Someone takes it into the lab. Weeks later you come back to the overview, add what the lab taught you, and go around again.

That whole loop is months of work.

Inside it is a smaller loop that repeats every time you go around. You search on a set of keywords. You read what comes back, and what you read tells you the next set of keywords, so you search again. You formulate, find, judge, pull out what matters, re-key, and go again until the picture holds. On a hard challenge, the searching alone takes two to three weeks of someone's time. The structuring and the report on top of that take longer.

That leg is what we built into the software. Not the lab work, not the deciding, those are yours. The search-structure-report part, the part you run over and over. It comes back in minutes, and it keeps the whole thread intact between passes, so when you come back from the lab in six weeks you start exactly where you left off, with nothing lost.

That is the part that runs while you work. There are two more, and we come back to them at the end.

We break your question down

You type a question. The first thing we do is break it down into functions, constraints, and objectives, the way TRIZ and functional analysis have taught R&D to read a problem for the better part of a century. What is the core function. What are the hard constraints. What is the real objective under the wording.

We pull the function deliberately wide, so the search casts for everything that could be relevant. The technology that solves your problem rarely describes itself in your exact words, so a narrow query misses it. Then we layer the constraints back on as a filter. The aim is a question wide enough to find all the relevant work and specific enough to decide on it. If you leave the constraints out, we suggest the ones that matter in your field. If you pack too many in, we set some aside.

This is the part you usually only get to the hard way. Most of the time you find out your question was wrong after the searching, when the results come back thin or off, and you have to go back and reframe it. We do that reframing at the start, before a single search fires, because the question you typed is almost never the question that gets you the best answer.

Then we check it against seven common pitfalls. Your question is legitimate; the way it is framed is what costs you results. These are the seven ways a sound R&D question ends up shaped badly for the search, the ones we have seen recur across 3,000 projects. We know what each one does to your results, because we have watched it happen.

From there we write five versions of your question and run them together. Three keep your framing and change only how much detail they carry: your question tidied up, a minimal version stripped back to the core, and a fuller one that spells out every requirement. The other two step outside your wording: one picks up a second job hidden in the question, getting rid of the brine; the other borrows the words a different field uses for zero liquid discharge, where a lot of the answers actually sit.

Those five questions all fire at the same time.

Five searches, running in parallel

Those five variations are the better questions you would have arrived at eventually, the ones you usually only find after weeks of searching down the wrong path and doubling back. We already know the shapes a good question takes, so instead of making you discover them one loop at a time, we run them all at once.

Take one of the five. It turns its functions into keywords and synonyms, the ones we know work, and marks some as must-match and some as must-not-match. Then it runs against our curated scientific database, which we own, update, and index ourselves.

It does not run once. It reads what comes back, judges whether those documents answer the question, and uses that judgement to change the keywords: it drops the terms that pulled noise and keeps the ones that pulled signal, then runs again. If a search finds nothing, it loosens the query. If it finds strong results, it tightens. This is the loop a scout runs by hand, and it repeats five to seven times per search.

By the end, one search has read through as many as 3,000 documents to find the ones that count. Five searches run in parallel. Across all five we read in the order of 150,000 abstracts and return the 100 to 200 that answer your question, when they exist. Reading 150,000 abstracts by hand would take you weeks. The software does it in about two minutes.

We read all of it and judge it, one at a time

That judging happens one document at a time, and it drives the loop above. We hold each paper against your original question with an LLM judge that scores how well it answers: very relevant, relevant but thin, or wrong despite looking right. That score is what tells the search which keywords to change.

It is the read-it-and-decide call you make by hand, the same judge-and-move-on you do paper by paper. Here it runs across thousands of papers in parallel, in about two minutes.

The judge is not a general-purpose model guessing at what is good. It is tuned on how our own expert scouts selected and read these papers.

We merge the five and sort what's left

When the five searches are done, we bring them back together. If the same document came up in more than one stream, we don't show it twice, we combine it. Then everything is sorted by relevance. That is the gallery of results you see.

Top 30 into extraction built for R&D

From here the results split into two parts, and the second part is where most of the value is.

First, the quick answer. We take the top 30 results and write a short summary of two or three paragraphs from the most relevant papers, pulled by our own prompts for what a scientist needs from a paper. If your answer is there, you have it in one read.

Often it is not, because there is more in the set. So we go wider and extract from every one of the 100 to 200 documents we kept, not only the top 30. For each document we find the technology that answers your question, and we group similar ones together. For the desalination question, that is reverse osmosis in one group, microbial desalination in another, and so on, with five to twenty papers per group, sorted the way the field itself divides. You get the documents already organised by technology instead of as one long list.

Then, for each group, we extract the constraints you set at the start: efficiency, sustainability, and where the technology has been used. You can read one technology's efficiency against another without opening a paper. What you get back is close to the report you would otherwise build by hand.

What that costs, and what it replaces

All of that, one run of guided research, costs us about seven euros.

Your part in it was about twenty minutes.

It is the same work I would do as a scout in twenty to thirty hours by hand. Breaking the question down, searching, reading, judging, changing keywords, reading again, grouping, extracting. The same work. Seven euros, a couple of minutes, and it doesn't get tired on document ninety.

Put it in money. An R&D engineer on a hundred thousand a year costs somewhere around fifty euros an hour. Twenty to thirty hours of their time on the searching is a thousand euros, give or take, of work they could have spent in the lab or with the team. The software does that same leg for about seven. Their time was never the thing to save money on. It's worth far more than the part we just took off their plate.

That's the search-structure-report leg, the three weeks you spend every time you go around the loop, done in minutes.

The science, the deciding, and the lab work stay with you. What we hand back is the weeks, and the thread held intact, so the next pass starts where the last one ended.

The results do not disappear when you close the tab. You keep the documents that matter, set aside the ones that do not, and dig further into the ones worth more, pulling more detail out of them and regenerating the report as you go. This is the point where a search becomes a project.

This points to the bigger picture, which is three things working together. A search works while you work: it does the three-thousand-document job in minutes while you get on with the day. A project works alongside you: it holds the thread for the months, sometimes years, that the real question takes, so you come back to where you left off instead of starting again. Monitoring, which we are building now, works while you are away from it: it watches the literature and brings back what has changed, so the question keeps being answered when you are not the one asking.

That covers the whole research loop: while you work, alongside your project, and while you are not working at all.