From CSV to API: How We Turned IFCT 2017 into a Queryable Nutrition Graph

IFCT 2017 is, by any measure, an excellent dataset. It's also, in its native form, a static reference book - tables meant to be read, not queried. Turning it into something a product can actually call in real time, at scale, for arbitrary dishes and conditions, is a different kind of problem entirely. This post walks through that transformation in general terms: how a static composition table becomes a nutrition graph India developers can query, and why that step is harder than it looks from the outside.

This isn't a literal commit-by-commit account of

AamoAI^™

What IFCT 2017 Actually Gives You

Before talking about architecture, it's worth being precise about the source material itself, because the gap between what IFCT provides and what a product needs is the entire reason this is an engineering problem at all.

• IFCT 2017, published by ICMR's National Institute of Nutrition, documents 151 nutrient components across 528 key foods, each compositely sampled across six geographical regions of India.
• It uses a "key foods" methodology - prioritizing the foods that together account for roughly 75% of population-level nutrient intake, rather than attempting exhaustive coverage of every ingredient.
• Critically, as independent researchers building on IFCT have documented in peer-reviewed work, IFCT 2017 covers raw food items - uncooked rice, raw tomatoes, raw wheat flour - and does not include composite dishes like chapatis or curries at all.

That last point is the crux of the entire problem. IFCT tells you what's nutritionally true about raw rice. It says nothing directly about biryani. Everything between the raw ingredient table and a usable IFCT 2017 API India teams can query for real dishes has to be built on top.

Why a Flat Table Doesn't Scale

The naive first approach is to treat IFCT as a lookup table: dish name in, nutrient values out. This works for exactly as long as nobody asks a second question. The first version of almost every nutrition database starts this way, because it's the fastest path to a demo - and demos are forgiving in ways production systems aren't.

• What happens when "dal" needs to resolve differently depending on region, lentil type, and cooking method? A flat table either picks one answer and is wrong for most of the country, or duplicates "dal" into dozens of near-identical rows that quickly become impossible to maintain consistently.
• What happens when a composite dish - say, a vegetable curry - needs its nutrient profile derived from several raw IFCT entries combined according to a recipe, rather than looked up directly? A flat table has no concept of "derived from," so each composite dish ends up as a manually entered, unverifiable guess.
• What happens when the same recipe needs to return different effective values depending on whether it was prepared at home or in a restaurant kitchen, given how much added fat that distinction typically represents? Without a structured way to represent that variation, it either gets ignored or hard-coded as yet another duplicated row.

A flat table answers none of these without duplicating rows endlessly or hard-coding exceptions everywhere - and every hard-coded exception is a future maintenance liability nobody remembers the reasoning behind six months later. This is the moment IFCT data model design stops being a spreadsheet decision and becomes a graph problem.

Why "Graph" Is the Right Word, Not Just a Buzzword

A nutrition graph treats ingredients, dishes, regions, cooking methods, and conditions as connected nodes rather than flattened rows. A dish node connects to its constituent ingredient nodes through "contains" relationships, each carrying a quantity. A regional variant connects back to its base dish through a "variant of" relationship, carrying the specific attribute that changes - different lentil, different fat, different spice profile. This structure is what allows a single underlying ingredient correction in IFCT to propagate correctly to every dish that depends on it, instead of requiring a manual update across hundreds of duplicated table rows.

Modelling the Raw-to-Composite Gap

Since IFCT only covers raw ingredients, the real engineering work sits in the layer that converts raw ingredient data into composite dish data - and does so in a way that's traceable back to the source, not just estimated once and frozen.

• Recipe decomposition: every composite dish needs to be represented as a structured list of raw ingredients and quantities, so its nutrient profile can be calculated by summing the contribution of each IFCT-sourced ingredient rather than guessed at the dish level.
• Cooking-method adjustment factors: raw-to-cooked transformations change nutrient values meaningfully - water-soluble vitamins degrade with heat, fat content rises with frying or tempering, and these adjustment factors need to be modelled explicitly rather than assumed away.
• Regional substitution rules: the same dish name needs to map to different underlying ingredient sets depending on region, which means the graph needs region as a first-class attribute on the dish-to-ingredient relationship, not just a tag on the dish itself.
• Gap-filling for missing nutrients: IFCT doesn't cover every nutrient for every food completely, which means a credible system needs a clear, documented policy for which secondary sources fill specific gaps - and needs to track that provenance, so a number's confidence level is always knowable. A value derived purely from IFCT should be distinguishable, internally, from one patched in from a secondary source, even if the end user never sees that distinction directly.

Real precedent exists for parts of this approach: independent academic efforts to build an open Indian Nutrient Databank have taken a similar two-stage path - building a raw-ingredient layer from IFCT first, then layering a separate recipe database on top that maps composite dishes back to those raw ingredients, drawing on hundreds of standardized recipes from Indian nutrition training manuals to do it. That two-layer structure is a sound instinct, and it's the same general shape worth building toward, regardless of the specific implementation choices any one team makes. The lesson generalizes well beyond any single project: separate the verified raw data from the derived composite layer, and keep the relationship between them explicit and traceable rather than collapsed into a single opaque number.

Designing the API Layer

Once the underlying graph exists, the API surface needs to expose it in a way that's actually usable by the kinds of products that will consume it - dietician software, hospital systems, family meal-planning tools.

A workable design typically needs to support queries like:

• "Give me the nutrient profile for this dish, in this region, prepared this way" - a precise, multi-attribute query rather than a single dish-name lookup.
• "Adjust this meal's sodium and potassium guidance for someone managing both diabetes and hypertension" - condition-aware filtering layered on top of raw nutrient values.
• "Adjust fluid and electrolyte guidance for this user given current heat conditions" - a query that pulls in external context like season or climate zone, not just static food data.
• "Return this dish's nutrient profile scaled to a katora, not a hundred grams" - translating natural portion language into the underlying gram-based calculations IFCT actually provides.

None of these are simple key-value lookups. Each one requires the graph structure underneath to actually carry the relationships needed to answer it - which is the whole reason the upfront modelling work matters more than the API design itself. A well-designed API is just a clean way of asking questions; the graph is what makes the answers correct.

What This Means for Builders

If you're evaluating Indian food nutrition API engineering work - whether to build it or to integrate with an existing layer - the lesson from this kind of build is consistent: the hard part was never the API surface. REST endpoints and JSON responses are the easy 10%. The Indian nutrition ontology underneath - the graph of ingredients, dishes, regions, methods, and conditions, all correctly related to each other and traceable back to a credible source like IFCT - is the 90% that actually determines whether the product works.

Our Approach at

AamoAI^™

This is the category of problem

AamoAI^™

Conclusion: The Database Was Never the Hard Part

IFCT 2017 gave India something genuinely valuable: a rigorous, regionally-aware foundation for raw food data. What it couldn't give, by design, was a system for representing the thousands of composite dishes, regional variants, and real-world cooking contexts that sit on top of that foundation. Building that layer - correctly, traceably, and queryably - is where the real engineering work lives, and it's a multi-year commitment disguised as a data import.

If your team is wrestling with exactly this problem - turning static nutrition data into something your product can actually query in real time - get in touch with

AamoAI^™