One system. Seven problems it solves. One demo you can try right now.
I built an AI to verify health claims against 4,700 scientific papers. The same system solves problems your team hits every week — no data team required.
If you have ever picked up a supplement, a protein bar, or any health product and read the claims on the back, you have probably wondered the same thing: is any of this actually true?
“Supports immune function.” “Clinically shown to improve recovery.” “Backed by science.” These phrases are everywhere. But the science behind them ranges from rigorous multi-year clinical trials to a single study with eighteen participants, and nothing on the label tells you which one you are looking at.
I built NutriClaim Labs to close that gap. Feed it a claim, and it searches across 4,700 peer-reviewed papers, weighs the evidence by quality and relevance, and tells you whether the science supports it, contradicts it, or gives mixed signals. th citations to the exact studies it used to reach that conclusion.
Building it made me realise that the same system solves a much broader set of problems. Too much information to process, knowledge that lives in documents nobody has time to read, answers that need a traceable source, institutional knowledge that walks out the door when someone leaves. These are not niche problems. They show up in almost every organisation I talk to, and they all have the same underlying solution.
If any of that sounds familiar, read on. You do not need a data team for this.
What RAG actually is, in two sentences
Most people assume AI either knows something or it doesn’t. RAG (Retrieval-Augmented Generation) is the architecture you use when that assumption isn’t good enough.
Instead of relying on what a model learned during training, RAG retrieves the most relevant documents from a specific knowledge base in real time, hands them to the model, and asks it to reason from that evidence. The model doesn’t guess. It reads, then answers.
Think of it as the difference between asking a consultant what they remember from a conference two years ago, versus handing them the original research and asking them to work through it with you. Same person. Very different answer.
The knowledge base doesn’t have to be enormous. It just has to be yours, highly specific, or more current than the data used to train the model.
Why I built this on scientific papers specifically
I read a lot about health and nutrition. And one thing I kept noticing is that different publications make contradictory claims about the same topics, often citing science to support opposite conclusions. After a while I stopped knowing what to believe, and I suspect most people who read this kind of content feel the same way.
Scientific papers felt like the right place to go for a more rigorous answer. But the volume is the problem. According to their site, PubMed alone contains over 37 million citations. For a specific topic like “intermittent fasting metabolic outcomes,” there are still thousands of relevant papers. Nobody has time to read them all, cross-reference methodologies, and form an informed view.
That makes it a near-perfect use case for this kind of system. The knowledge base is enormous, highly technical, and genuinely hard to navigate without expertise. It is exactly the kind of problem where a well-built retrieval system adds real value.
There is a third reason. General-purpose AI models are trained on a broad mix of sources, which means their conclusions about health and nutrition blend peer-reviewed evidence with wellness blogs, popular articles, and other content of varying quality. By grounding the system exclusively in scientific papers, I can be much more confident that the answers reflect what the research actually says, not what the internet says about what the research says.
NutriClaim Labs indexes papers across 39 topics, applies quality filters (publication type, recency, citation count, study design) and ranks evidence accordingly. A well-designed randomised controlled trial outranks a loosely relevant editorial every time, even if the editorial happens to match the query keywords better. That distinction matters enormously in practice.
Why the data layer is where most AI projects quietly fail
Before the AI ever sees a document, someone has to make sure the right documents are actually being collected. This sounds obvious. It is also the step most teams underestimate.
The first time I ran the pipeline to collect papers, every single topic returned zero results. No errors. No warnings. Just nothing. It took a while to find the issue. The system was searching PubMed using phrases that felt natural and descriptive, but had no exact match in the database. PubMed simply ignored them without saying so. Once I understood that, the fix was straightforward: use the terms researchers actually write, not the terms a marketer would reach for.
This pattern repeated itself in subtler ways throughout the build. Keywords that felt intuitive (“cardiovascular diet,” “heart disease food”) returned almost nothing because that’s not how researchers write. Replacing them with clinical terminology (“cardiovascular outcomes,” “cardiovascular mortality”) went from zero results to thousands.
A system that is collecting the wrong documents will give you confident, well-structured, completely unreliable answers. The model is almost never the problem. The data feeding it usually is.
How the system decides what evidence to trust
The pipeline retrieves candidate chunks of text from across the document library, then ranks them before passing the most relevant ones to the AI for synthesis.
For a team that needs answers they can act on or stand behind, this ranking step is everything. A purely keyword-based approach surfaces whatever matches the query best on paper, regardless of whether the underlying study is any good. So I added a second scoring dimension alongside semantic relevance: evidence quality. Study type, sample size, recency, citation count. The final ranking weights semantic relevance at 70% and evidence grade at 30%.
This means the system behaves more like a scientist than a search engine. Relevant evidence from a weak study ranks below slightly less keyword-matched evidence from a rigorous one. For a claim validation use case, that distinction is the whole point. For any use case where you need to trust the answer, the same principle applies.
Why a well-built RAG system doesn’t have to be expensive
This is worth saying clearly, because cost is the concern that stops most founders and lean teams from exploring this further.
Not every step in the pipeline needs a powerful model. Summarising a document, transforming a query for better retrieval, classifying whether a chunk is relevant — these tasks work well with smaller, faster, cheaper models. Reserving the most capable model for the final synthesis step, where it actually reads the evidence and produces a conclusion, keeps costs low and response times fast whout sacrificing the quality of the output that matters.
The infrastructure side follows the same logic. NutriClaim Labs runs entirely on Cloudflare’s edge network. No separate servers to manage, no data engineering team to maintain it. The system handles 4,700 documents across 39 topics on infrastructure that scales automatically and costs a fraction of what most teams assume.
Match the model to the complexity of the task. You don’t use a sledgehammer to cut a sandwich.
The same system. Seven different problems.
NutriClaim Labs is a showcase. The underlying pattern (ingest a specific body of knowledge, retrieve against it accurately, synthesise with citations) applies anywhere you have a question-and-answer problem where the answers need to come from your knowledge and need to be traceable.
Here’s where this is being built right now:
1. Scientific and evidence validation. Health brands, supplements, foodtech, sports nutrition. Exactly what NutriClaim Labs demonstrates. If your marketing team writes claims and your legal team reviews them slowly, this is the gap it closes.
2. Internal knowledge bases (especially useful for marketing and ops teams in companies that have grown fast). Your SOPs, HR policies, product documentation, past proposals, all queryable from a single interface. Knowledge workers spend roughly 20% of their working week searching for information that already exists somewhere in their organisation.
3. Sales enablement (high-impact for startups without a dedicated enablement function). A system that knows your product, your competitors, and your historical win/loss data. A new sales rep asks how you compare to a competitor on a specific feature. They get a grounded, citable answer instead of whatever they remember from onboarding.
4. Research and competitive intelligence (useful for marketing teams making strategic decisions). Ingest your purchased market research reports, industry publications, and competitor content. Query across all of it. Stop paying analysts to reformat PDFs.
5. Customer-facing product agents. Every SKU, every ingredient, every compatibility question, answered accurately and instantly. Significantly stronger than a generic chatbot because answers are grounded in your actual product documentation, not a model’s best guess.
6. Legal and regulatory assistants. “Is this product launch compliant with the EU AI Act?” Answer grounded in the actual regulation text, with article citations. Demand is accelerating as EU AI Act compliance deadlines hit companies through 2026.
7. Rules and procedural support. Anywhere a complex, authoritative document set generates high volumes of edge-case questions. Game rules. Sports regulations. Legal procedures. Insurance policy interpretation. The document set is fixed. The query volume is infinite.
These systems can be built and maintained without a standing data team. The knowledge base is your documents. The complexity is manageable.
You might be wondering
“Can’t you just paste the papers into ChatGPT and ask it the same question?”
You could. The only caveat is that you’d have to find which papers are relevant, download them, decide which ones are credible, and summarise them first.
Given there are over 37 million papers on PubMed, the relevant pool for even a specific topic averages more than a thousand documents. After filtering for quality and picking the ones you think matter, you’d still need to rank them by credibility and synthesise across them.
That would only take you a month of work. Your choice.
And for a team that needs answers they can act on, stand behind, or show to a regulator, “I asked ChatGPT” is not a foundation.
Try it, then let’s talk
NutriClaim Labs is live. Submit a health or nutrition claim and see how the system handles it: what it finds, how it ranks the evidence, and how it reaches a conclusion.
Most of the organisations I work with are either founders at early-to-mid-stage startups, or marketing teams at larger companies. What they have in common is that they are sitting on knowledge their teams cannot easily access, and they do not have a data function to fix that.
If that sounds familiar, a 30-minute call is enough to figure out whether this applies to your situation and what building it would actually involve.
Lluís Gassó is an AI & Analytics consultant at Lluis Gasso LLC. He builds data and AI systems for startups and marketing teams that want to use AI seriously.