SYSTEM / DIETARY CONTEXT
The dietary graph
hello.food models dietary context as structured, source-aware data. Diet styles, allergies, health conditions, additional constraints, cuisines, activity, and notes remain distinguishable rather than being compressed into one prompt string.
Selections retain their source
Synced profile schema v5 records canonical source selections separately from compatibility fields. That distinction lets the client rebuild derived restrictions deterministically and clear one category without deleting a constraint still required by another.
{
"selection_provenance_version": 1,
"diet_style_ids": ["low_fodmap"],
"allergy_ids": ["peanut"],
"health_condition_ids": ["ibs"],
"additional_restriction_ids": ["onion", "garlic"]
}Synthetic excerpt. The public catalog contains identifiers and coarse constraint tags, not the proprietary evaluation engine.
Household scope stays explicit
heyfood members list discovers synced profile member IDs. Commands that accept --member-id can target a specific person, while household menu results preserve per-member summaries and conflicts. The response identifies who a concern applies to.
$ heyfood members list
$ heyfood profile --member-id member_02
$ heyfood daily today --member-id member_02Canonicalization protects compatibility
Source-aware clients write the canonical selection arrays. Flattened compatibility fields are rebuilt from those sources before preview and upload. Older labels that have no current enum remain represented instead of being silently discarded.
- Catalog changes are versioned and additive by default.
- A CI drift check keeps published client snapshots synchronized.
- Empty authoritative arrays are distinct from absent legacy data.
- Condition severity remains attached to its selected condition.