How the catalog works

Pantensa stores five kinds of thing, and one rule governs all of them: an object references the objects below it rather than copying their numbers. A recipe does not hold nutrition values, it holds a list of products. A planned meal does not hold a recipe, it points at one. A closed day does not hold food, it holds the entries that were in it.

Everything else on this page follows from that rule, including the parts that are inconvenient.

The five objects

Object	What it is	What it references
Product	A food and its nutrition values	Nothing — this is the bottom of the stack
Recipe	A dish, its ingredients and how many servings it makes	Products
Plan entry	An intention: this day, this meal, this amount	A product or a recipe
Diary entry	A record: this is what was actually eaten	A product or a recipe
Closed day	A day marked finished, with its totals	The diary entries in it

Reading that table upwards is the reason the catalog is worth building: the work you do at the bottom is done once and reused by everything above it.

Products carry the nutrition

A product is a food with nutrition values attached, normalised so that different foods can be added together. Four ways in, all producing the same kind of entry:

• Scan a barcode with the phone camera.
• Search the food databases — Open Food Facts for branded packages, USDA FoodData Central for generic ingredients.
• Edit an imported result before it is saved.
• Create the product by hand when nothing is found.

Imported values are a draft, not a fact

An import fills the fields; it does not finish them. The databases disagree with each other, packaging changes faster than any record of it, and declared serving sizes do not always convert cleanly. So the values arrive as a draft you confirm — one glance at import time instead of a wrong number repeating in every meal built on top of it. The reasoning is written out in why imported nutrition data is shown as a draft.

The edge cases worth knowing

• A barcode that returns nothing is not a failure state. You create the product yourself and it behaves identically to an imported one from then on. Coverage is good for widely sold packaged goods and thin for local and store-brand products.
• Two packages are two products when their labels differ, even if the food is “the same”. The catalog stores what a label says, and averaging two labels into one entry loses the only thing that made either of them trustworthy.
• Raw and cooked are different foods by weight. A product’s values describe the state it was weighed in, so a recipe that starts from dry rice and a diary entry that records cooked rice are referring to two different products, not one product measured twice.

Recipes reference products

A recipe is a list of ingredients — each one a product plus an amount — together with the number of servings it makes. Its nutrition is computed from that list. There is no field to type a recipe’s calories into, because a number typed there would be a copy, and copies go stale.

Ingredient slots are flexible: the recipe describes the dish you actually cook, not a fixed formula you have to match. Servings matter more than they look — they are the divisor between “what this pot contains” and “what one person ate”, and they are what lets the same recipe land differently in two people’s diaries.

The plan is a prediction

A plan entry says: on this day, in this meal, this recipe or this product, in this amount. Because the entries reference recipes, and recipes reference products, a planned day already knows its calories, macros and wider nutrient set — before the day happens. That is the whole point of planning inside the same system that tracks: you see the consequence while the decision is still cheap to change.

The plan is shared across the household, because dinner is shared.

What the plan deliberately does not do in the first release: it does not choose meals for you, and it does not produce a shopping list. Placing is your job; the list needs stock, which is Pantry mode.

The diary is a record

A diary entry says what was eaten. A planned meal can be confirmed as eaten, adjusted to the portion that actually happened, replaced with something else, or left alone. Food that was never planned is logged directly.

The two are kept separate on purpose. A tool that collapses plan and log forces you either to pretend you ate the plan, or to abandon the plan the first time dinner changed. Here the day’s totals follow the diary, never the intention — an unconfirmed plan entry is not food, and it never becomes a diary entry on its own.

Correcting a portion in the evening is an update, not a confession. The first entry was not a mistake; it was the best estimate available at the time.

Closing the day

Closing marks a day finished. Its totals stop being a moving figure and become part of history: the record you look back at, and the input to the 7-day trend.

Closing is bookkeeping, not grading. Nothing is scored, nothing is failed, and a day that went badly is closed exactly the same way as a day that went well — because the value of history comes from it being complete, not from it being flattering. A day you never close is simply a day the trend has nothing to say about.

Targets, and nutrition-only mode

Targets are personal and they know their direction: protein is a floor to reach, sodium a ceiling to stay under. Comparing a day to a target is therefore not one subtraction — it is a different question per nutrient.

The first release opens in nutrition-only mode: products, recipes, planning, logging and targets, with no stock tracking anywhere in the interface. That is not a stripped-down configuration, it is the release.

Household boundaries

The catalog, the recipes and the plan are shared across the household. The food diary and the personal targets are not.

This is a line in the data model rather than a setting to remember to switch on. Two people can eat the same planned dinner, see it against two different targets, and neither can read the other’s day.

What the catalog grows into

Pantry mode is not in the first release

Stock and batches, expiration dates, missing-product warnings, a shopping list counted from the plan minus what you have, cooked-dish inventory and pantry-aware planning all come next.

The reason to describe it here at all is that it changes nothing about the five objects above. Pantry mode adds a sixth thing — how much of a product is actually in the kitchen — and hangs it off the products you already entered. The plan stays the same plan, the recipes stay the same recipes, and nothing gets typed in twice.

That is what “build your food system once” means in practice, and it is why the bottom of the stack is worth the care.