Healthcare & life sciences — consumer health and nutritionKnowledge graphs & Graph-RAG

A nutrition knowledge graph that turns health-test results into meal plans people can trust

A consumer health-testing company had test results, profiles and a recipe library, but no way to turn them into a meal plan for one person. We built a nutrition knowledge graph with Graph-RAG retrieval behind one API — delivered in three weeks.

Four kinds of user context — profile and goals, health-test results, diet and restrictions, and feedback with the ingredients at hand — flow into a nutrition knowledge graph of users, goals, recipes and ingredients, shown as a triplet: a user linked by a weight goal to "maintain", with a value of 63 kg. Four Graph-RAG agents read from the graph: context understanding, report analysis, meal recommendations and an explainer. The output is a personalised meal plan with a reason for each choice, served through one API, retrieved by query vector, KNN and hybrid graph search, subgraph and answer. Restrictions are hard constraints. Headline figures: three weeks to a working API, three core datasets in one graph, four specialist agents, and up to 40% higher satisfaction and retention.
The user’s data becomes a subgraph. The agents build the plan from it, and say why each meal is there.

Project snapshot

Client
A consumer health-testing and nutrition company helping people act on their own health data
Industry
Healthcare & life sciences — consumer health and nutrition
Business function
Product, personalisation and customer engagement
Challenge
Users received health-test results and a profile, but meal guidance stayed generic. Profiles, test data, recipe PDFs and ingredient data sat apart, so nothing could connect a result, a goal and a dietary restriction to a specific recipe — or explain the choice.
Solution
A nutrition knowledge graph linking user profiles, goals, test results, recipes and ingredients, with Graph-RAG agents — context understanding, report analysis, meal recommendations and an explainer — retrieving each user’s subgraph to generate meal plans, exposed through one API with guardrails and a feedback loop.
Result
Up to 40% higher customer satisfaction and retention, real-time retrieval of personalised meal plans for low-carb and vegan users with a reason attached to every recommendation — delivered in 15 working days.

Key outcomes

40%
Higher customer satisfaction and retention
3 weeks
From kick-off to a working recommendation API
3
Core datasets connected in one graph
4
Specialist Graph-RAG agents

The client

Health data people wanted to act on

A consumer health-testing and nutrition company that helps people understand their own health data. Its customers take tests, read their results and want to know what to do next. For most of them, the next thing is what to eat.

The company had the results, the profiles and a recipe library. What it did not have was a way to connect them for one person.

The challenge

Generic advice on top of personal results

A user could see exactly what their tests said and still get the same meal suggestions as everyone else. Profiles, test data, recipe PDFs and ingredient data lived apart, so nothing linked a result and a goal to a specific dish.

What had to be connected

3
core datasets — profiles, recipes, ingredients
3
input types — profile and test data, images, recipe PDFs

Personal results with generic guidance is the gap where customers lose interest. They had paid for insight and received a list.

Constraints

What we had to design around

  • Health contextA meal plan built on someone’s test results is not a playlist. A nut-free user cannot get a recipe with almonds in it, however well it scores. Restrictions had to behave as rules, not preferences.
  • Data shapeProfiles and test data, recipe PDFs, images and ingredient lists — in different formats and different places. The connections between them, not the records themselves, were what a recommendation needed.
  • ExplanationPeople change what they eat when they understand why. Every suggestion had to come with a reason a user could read, tied to their own goals and results.
  • IntegrationThe company already had an app its customers used. The capability had to arrive as an API that app could call, not as a separate product.
  • Speed to valueThree weeks from kick-off to meal plans served through that API — so the foundations had to be small, clean and ready to grow.

Our approach

Model the relationships, then retrieve them

A recommendation is a path: this person, this goal, this result, this restriction, this recipe, these ingredients. Plain vector search finds recipes that sound similar. It cannot follow that path or prove a recipe respects every rule on it.

So we built the path first. A small ontology of users, goals, recipes, ingredients and dietary preferences, filled by triplet generation from the raw data. Graph-RAG then retrieves the user’s subgraph and hands the language model only what is true for that person — which is also what makes each answer explainable.

The solution

Five layers, from a test result to a plate

  1. Data processing — Profile and test data, images and recipe PDFs land in file storage. Feature extraction and embedding extraction run on the way in, with quality checks on critical fields such as recipe names and ingredient quantities.
  2. Graph construction — A prompt-templated triplet generator turns each record into subject–relation–object facts — a user, a weight goal, a value — which are indexed into the knowledge graph. The ontology covers recipes, ingredients, users and dietary preferences.
  3. Knowledge base — Three stores behind one interface: the knowledge graph on Amazon Neptune, a vector store on Aurora PostgreSQL, and conversation history, so a follow-up question knows what came before.
  4. Graph-RAG retrieval — A query becomes a vector, then a KNN and hybrid search over the graph. The matching subgraph and its linked documents go to the language model on Amazon Bedrock, which generates the answer from them.
  5. Agents and API — Context understanding, report analysis, meal recommendations and an explainer share the context engine. A FastAPI service exposes recommendation endpoints that take structured inputs from the app.
The high-level system. A user sends a query through the application UI, which passes it to a context engine holding the user's profile, test results, feedback and available ingredients. The context engine exchanges information through a language model with AI agents inside a GraphRAG module, where four specialists — context understanding, report analysis, meal recommendations and an explainer — feed the agents. Beneath them, an analytics layer links guardrails, a feedback module and a usage tracker. The response returns to the user.
The context engine holds what is known about the user. The GraphRAG agents decide what to do with it; analytics keeps it safe and learning.
How the knowledge base is built. In a data processing stage, profile and test data, images and recipe PDFs go into file storage, then through feature extraction and embedding extraction; embeddings flow to the vector store. In a knowledge graph construction pipeline, data ingestion feeds triplet generation, guided by a triplet generation prompt template. An example triplet shows a user node linked by a weight-goals relation to a maintain node, with a property value of 63 kg. Triplets are indexed into the knowledge graph. The knowledge base holds three stores: the knowledge graph, the vector store and conversation history.
Raw records become facts the graph can walk. The 63 kg example is one triplet; a user’s subgraph is built from many.
Three epics in fifteen working days. Epic one, data collection and ETL: user profiles, recipes and ingredient data collected, cleaned and standardised, with quality checks on recipe names and ingredient quantities. Epic two, the foundation: a knowledge graph and ontology of recipes, ingredients and dietary preferences, with relationships for use cases such as recipes for vegan diets. Epic three, Graph-RAG and the API: retrieval from the graph generating meal plans for low-carb and vegan users, exposed through API endpoints that take structured inputs, tested end to end on user profiles with API and workflow documentation handed over.
The graph sits in the middle because retrieval reads it.
15working days from kick-off to meal plans served through an API

Responsible by design

Four rules for AI that tells people what to eat

  • Ground

    Meals come from the graph, not the model’s memory.

    Every recipe in a plan exists in the graph and connects to the user’s own profile and results. The language model writes; it does not invent food.

  • Constrain

    A restriction is a filter, never a weight.

    Dietary restrictions and preferences sit in the graph as relationships, so a recipe that breaks one is not retrieved at all. Guardrails check the output before it reaches the user.

  • Explain

    No recommendation without a reason.

    A dedicated explainer agent says why each meal fits — which goal, which result, which preference — in language a user can act on.

  • Learn

    Feedback flows back into the context.

    A feedback module and usage tracker capture how users respond to their plans, and feed it into the context engine for the next plan.

The second rule matters most. A ranking model can trade a restriction for a better score. A graph that never retrieves the recipe cannot.

Results

What changed for the customers

  • Up to 40% higher customer satisfaction and retention — meal plans built on each user’s own data give people a reason to come back to the app.
  • Real-time retrieval of personalised meal plans, pulled from the user’s subgraph rather than assembled from scratch on every request.
  • Low-carb and vegan plans from one ontology, with relationships ready for new diets and use cases without a redesign.
  • A reason attached to every recommendation, written by the explainer agent and tied to the user’s goals.
  • Delivered in 15 working days — three epics, ending in tested recommendation endpoints and documentation for the API and its workflows.

Test results stopped being the end of the journey and became the start of a plan.

Beyond the numbers

What else changes

Every new test, recipe or diet becomes another set of nodes, not another feature. Add a recipe and it is immediately reachable for every user it fits. Add a new marker and report analysis can reason about it on the next request.

And because the answer is a subgraph, the company can see exactly why the system suggested what it did. That makes every plan easy to check and easy to trust.

If your customers get personal data and generic advice

The first question is which connections your data already holds. That is answerable from a sample of your records, before anything gets built.