# Why quantity and item are separate fields

> Storing "3 tbsp white miso" as one line makes a recipe readable. Splitting it into three fields makes it searchable and editable. Here is what that buys.

- Canonical: https://www.getcurate.ai/blog/recipes/why-quantity-and-item-are-separate-fields/
- Language: en
- Published: 2026-09-16
- Author: Curate
- Tags: recipes, search, data model

---

A recipe extractor can stop at the line. Most do. You get *3 tbsp white miso* as a string, it renders correctly, and it looks finished.

It is not finished, and the difference shows up the first time you ask a question.

## The question a line cannot answer

*What have I got with miso in it?*

Against a list of strings, that is a substring search, and a substring search on ingredient lines gives you every recipe containing the letters m-i-s-o somewhere. It also cannot tell you that *3 tbsp white miso* and *1 tablespoon miso paste* are the same ingredient in different amounts.

Against three fields – quantity, unit, item – it is a question about one column, and the answer is exact.

## What the split gives you

**Search that means something.** The ingredient is its own value, so *miso* matches the ingredient and not the word appearing in a method step. When a result comes back, Curate can tell you it matched *in the ingredients* and quote the line, rather than leaving you to find the word yourself.

**Editing that does not punish you.** When extraction gets a quantity wrong – and on a photograph of a curled page it will – you tap the quantity and change the quantity. You do not retype the whole line, and you do not risk breaking the item while fixing the number.

**Facets that are real.** Once ingredients are values rather than prose, the app can offer you the ingredients your recipes actually contain, counted. Not a guess at what you might search for: the list, from your own library.

## Where it gets interesting

The third field is the one people underestimate: the **note**. *Unsalted butter, softened*. *Acorn squash, seeded and cut into wedges*. The preparation belongs to the item but is not part of what the item is, and keeping it separate is what lets *butter* match without *softened* getting in the way.

## The cost, honestly

Three fields per ingredient is more work at extraction time and more surface for an error. A parser that only has to produce a line has fewer ways to be wrong.

We think that trade is obviously right, because a wrong quantity you can tap and fix costs you four seconds, and a library you cannot ask questions of costs you the entire reason for having one.

## The rule we hold to

**Nothing scanned is ever saved unseen.** However confident the parse, the editor opens first, and saving is something you do. A machine reading a photograph of a cookbook page is going to be wrong sometimes, and the honest design is to assume it and make the correction trivial – not to assume it is right and make the correction someone else's discovery three weeks later, halfway through cooking.