01Facts versus judgement
Every enrichment field falls into one of two buckets. Some are facts that follow from data you already have. Others need judgement, like which joints an exercise loads or which allergens a dish description implies. Only the second bucket goes to a model.
02What stays in code
- Zabber decides whether an exercise is home-friendly from its equipment. Barbell means no, and no model is asked.
- When a Zabber user describes an injury, keyword rules map it to joints, so the mapping is predictable and testable.
- Gobbles fingerprints each dish's text. A price edit leaves the fingerprint unchanged, so nothing is re-enriched.
- Gobbles keys its shared catalog on the normalised dish name plus the veg flag, so a match is decided by code before any model call.
03What goes to the model, and how it's fenced in
Judgement calls go to a model, but never free-form. Zabber classifies 1,324 exercises against fixed vocabularies, and Gobbles extracts allergens against 14 classes. Any value outside the allowed list is rejected rather than stored.
Because the rule-based fields are already filled in, the model's job is narrower, and when something looks wrong there are fewer places it could have come from.
04Why it matters more when safety is involved
Code behaves the same way every time and can be covered by tests. Models can drift when a prompt or version changes. The more of a safety-relevant record that comes from rules, the less of it can change underneath you.