Meals

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

What this covers

This page governs meals: the agency's meal bank, the per-client approval of meals by the family, and the placement of approved meals onto meal-preparation tasks inside scheduled shifts — so the care provider on duty knows exactly what to prepare. Its sibling features have their own pages: Engagement Activities, Essential Needs, and Home Inventory.

Meal planning is available to all agencies and to Tier 2 family subscribers.

Key terms

• Meal bank — the agency's library of meals (recipes with ingredients, steps, and nutrition) that can be offered to clients.
• Meal link — the connection between one meal and one client, carrying that client's own approval decision for the meal.
• Shift attachment — placing one approved meal onto one specific meal-preparation task within one scheduled shift.
• Bulk scheduling — automatically spreading a client's approved meals across the matching meal-preparation tasks in their upcoming shifts.

How it works

From bank to plate

An agency builds a meal bank. Meals are written by hand or generated by the AI assistant for a specific client — staff choose how many breakfasts, lunches, dinners, and snacks they want, list preferred and avoided ingredients, and pick a generation depth (fast, standard, or thorough). The assistant checks the client is eligible, studies their profile and dietary needs, drafts the meals (optionally with photos), and reports progress live until it finishes. Generation can be cancelled mid-run, and existing meals can spawn AI variations.

A meal only matters to a client once it is linked to them. Each link carries its own approval decision, so the family can approve a meal for one client while another family rejects the same meal:

Once approved, a meal can be attached to a meal-preparation task inside a shift — one meal per task. Staff can place meals one task at a time, or bulk-schedule: the system takes the client's approved meals, matches them to tasks by meal type (breakfast meals onto breakfast tasks, and so on), and rotates through them evenly across upcoming shifts.

Rules

1. MEAL-1 — Every meal belongs to exactly one agency. Staff browsing the meal bank must only ever see their own agency's meals.
2. MEAL-2 — Only one AI generation run (meals or engagement activities) can be active per client at a time; a second request joins the run already in progress instead of starting another.
3. MEAL-3 — Every AI-generated meal is automatically linked to the client it was generated for and starts as Pending approval.
4. MEAL-4 — A meal can be linked to a given client only once; attempts to link it again are ignored, never duplicated.
5. MEAL-5 — Meal approval is decided per client: the same meal can be approved for one client and rejected for another. Approving meal plans is inherent to the Representative role and cannot be removed by permission configuration (ACCESS-35).
6. MEAL-6 — Only meals approved for a client may be attached to that client's meal-preparation tasks.
7. MEAL-7 — A meal-preparation task in a shift holds at most one meal. Assigning a new one replaces the old.
8. MEAL-8 — Bulk meal scheduling must use only the client's approved meals, match them to tasks by meal type, rotate through them evenly, skip cancelled shifts, leave existing choices untouched unless overwriting was explicitly requested, and refuse to run when the client has no approved meals.
9. MEAL-9 — When a meal is rejected or unlinked from a client, it must no longer appear on that client's upcoming shift tasks.
10. MEAL-10 — Deleting a meal removes all of its client links and shift attachments. Deleting a client removes all of their meal records.
11. MEAL-11 — A meal's nutrition totals are always calculated from its ingredients; nutrition is never entered or stored separately.
12. MEAL-12 — Meals are visible only to logged-in users whose role permits it, and never cross agency boundaries.
13. MEAL-13 — When the representative reviews a meal plan, they may approve it, ask for a meal to be changed, or substitute a meal; the care manager applies the requested changes and finalizes the plan. (🚧 Spec only)
14. MEAL-14 — When a meal-preparation task comes due, the care provider on duty must be able to document that the meal was prepared and record the client's response to it. (🚧 Spec only)

Note: This page's rules were retired from the old Daily Living page: DAILY-1 – DAILY-11 → MEAL-1 – MEAL-11 (the meal halves of DAILY-7 and DAILY-10); DAILY-27 → MEAL-12. IDs are never reused.

Who can do what

Decisions needed

• Are approval decisions final? Today a meal can be flipped between approved and rejected indefinitely, even after it has been scheduled into shifts. Options: lock the decision once made; allow changes only until the first shift attachment; keep decisions freely changeable.
• Should meal planning be gated on the nutritional assessment? The PRD's 30-day meal plan is generated only after the client's nutritional and dietary assessment is completed (see Care Assessments), but generation today only checks general eligibility (MEAL-2, MEAL-3). Options: hard-block generation until the meal/nutritional assessment is signed off; warn but allow; leave the gate to staff judgement.
• What must the nutritional and dietary assessment capture? The PRD expects it to record dietary restrictions, allergies, medical requirements, food preferences, cultural considerations, swallowing needs, and overall nutritional status before any plan is drafted. Today meal generation reads only the general client profile and dietary needs (MEAL-3); the full set of fields above is not yet defined as a structured assessment. Decide where this assessment lives (Care Assessments vs. this page) and which fields are mandatory.