PLATFORM / NATIVE CLIENT PREVIEW
A grocery list with dietary context
The grocery domain turns recipes and conversational intent into a persistent household list where every screened item can explain who it affects, why it was flagged, and what could replace it.
From intent to committed list
- 01
Resolve intent
A direct command or conversational request identifies the list operation and any recipe, quantity, or intended household member.
- 02
Normalize ingredients
Recipe lines and free text become bounded grocery items while retaining their source and the name the user supplied.
- 03
Snapshot the household
The service resolves the consented dietary context and records which profile versions informed the screening pass.
- 04
Screen every item
Each ingredient receives per-member annotations, reasons, substitutions, confidence, and an explicit ingredient-level basis.
- 05
Freeze a proposal
The pending action binds the list, list version, dietary-context fingerprint, account, and idempotency identity.
- 06
Confirm and commit
Accept, edit, or cancel is explicit. A changed list or household context invalidates the stale proposal instead of silently overwriting it.
The terminal contract
# Native client preview — not in the released Python CLI
> Add what I need for red lentil dahl for everyone
Grocery proposal
generally safer red lentils
risky · Maya onion
substitute: scallion greens
risky · Maya garlic
substitute: garlic-infused oil
Screened as ingredients. Verify product labels.
[A]ccept [E]dit [C]ancelConfirmation carries authority
- List mutations require the relevant read and write scopes.
- Every write carries the list version it was prepared against.
- The household-context fingerprint prevents confirmation against changed dietary data.
- Idempotency makes a replay return the original result instead of repeating the mutation.
- Purchase state remains grocery data; it is not treated as consumption or fed into dietary evaluation.
Human review and machine output share a contract
The rendered list, REST response, confirmation event, and future --json output derive from versioned language-neutral schemas. Safety status, screening basis, substitutions, provenance, versions, and typed conflicts remain available to automation.