Dietary attributes

Dietary filtering is the clearest case where grocery data is messier than the interface built on top of it. Most catalogs carry some dietary signal, few carry it consistently, and almost none carry it as a clean boolean.

How flags are read

Neomi looks inside the product attributes bag for keys matching known dietary prefixes and normalizes them into a small set of flags. Lactose, gluten, and sugar are the ones handled today. The prefix match is deliberate, because real catalogs carry attribute keys like a lactose-free flag scoped to a specific category rather than one global field.

When the tags are missing

Where your catalog has no dietary attribute at all, Neomi can enrich the product rather than returning nothing. That enrichment lives on the Neomi side unless you ask for it back, so your product data stays as it is and you do not have to run a PIM project before a pilot.

What this is not

This is better tagging and filtering, not a medical or allergen guarantee. Enriched attributes are inferred, the shopper sees every item before buying, and nothing here should be presented to a shopper as an allergen assurance.

Extending the set

Additional dietary dimensions are a mapping question rather than a code change. Bring the attribute keys you already hold and we map them.

Note on this page

Described from the current implementation rather than from a published contract. Field names and shapes are what Neomi normalizes to today; our engineering team confirms the public naming when the reference is finalized.