← All privacy impact assessments

PIA: suggested shopping day for a meal plan

The meal-plan Review screen already proposes a shopper and hour, reads the group's recent shopping events for its usual shopper/hour, and warns about conflicting group events before adoption. This change also considers the day: from the plan's selected start through its first cooking day, it prefers a day with a free shopping slot for the proposed shopper and uses the weekday of recent shopping events as a preference when several days fit. The first cooking event remains a deadline; the suggestion cannot move the plan's cooking days or silently adopt anything. A member can edit the review before the existing explicit Adopt action. If no day fits, the screen retains a visible conflict rather than claiming the suggestion is safe.

Data and flow

The phone reads the current group's already-loaded task and event schedule, the plan's is_cooking_day days and generated cooking events, and up to ten recent group shopping events (local start time and assignee). These can describe adults and children and disclose routines; the review is visible to members with existing meal-plan and schedule access. The same data is already used by the current shopper/hour allocator and conflict review. The new weekday preference is computed in memory on the phone. No new table, transcript, profile, expiry claim, analytics event or provider call is added. The suggested date can become part of the existing allocator request if the member later asks it to allocate the reviewed plan; no raw shopping history is newly sent for this decision. Existing group RLS, meal plan access and data retention apply. Device-only groups can receive the deterministic proposal without sending schedule history to a model.

Risks and boundaries

Risk Mitigation Residual
A bad day is proposed because a member's calendar is incomplete or a person changes availability Search only the plan-start-to-first-cook window, check the proposed shopper's loaded events and generated events, keep the existing conflict scan and recheck at Adopt, show a reason and allow manual edit A phone may have stale or incomplete schedule rows; a member can still adopt despite a warning
A past day or a shop after cooking is suggested Use the group's timezone, a same-day buffer and the first actual cooking event as a deadline; reject a candidate slot after that deadline A plan starting today may have no feasible slot; the app must say so rather than invent one
Routine information is exposed or treated as a rule Read only the current group's last ten shopping event times/assignees; aggregate weekday preference locally; never send those rows to a new provider or use them to override a manual choice Other group members with schedule access can already see the underlying events; a repeated weekday may be stale
A child is assigned shopping work Existing assignable-roster and allocation rules still decide the person; this change only selects a day among valid slots A group's own eligibility and supervision choices remain necessary

The benefit is a more useful, reviewable shopping proposal where a fixed day is busy. The implementation must keep explicit member control and existing same-user conflict checks. This assessment does not cover proactive pantry-expiry suggestions, changing cooking days, or new model access. Reassess before adding any of those or storing a new history profile.

Structural versus conventional

The existing group membership and row-level access rules constrain which schedule and shopping rows the phone can fetch. That is the structural group boundary. The day ranking, bounded window, same-user timed-event checks, no new history store, preservation of a member's chosen date, and the reason shown on screen are application code and copy, pinned by focused tests; they are not database constraints. The existing conflict review and explicit Adopt step give the member another chance to catch a bad suggestion, but neither proves the calendar complete.

Best interests of the child

A child's activities or shopping assignment can affect which day looks available, although the child does not need to use the suggestion. A better-timed shop can help a carer have ingredients ready before meals. The cost is that a child's routine already visible to authorised group members is considered in a new local calculation; the feature does not collect a new record about the child or send their schedule to another provider for the day choice. The safer fixed shop day would avoid this extra inference but can propose a clash the family then has to fix. We keep the suggestion editable and the conflicting schedule visible, so an adult's convenience does not silently decide the child's commitments. The child's own account gets no new assistant surface or explanation; the existing age-appropriate account information about what the group can see remains relevant. A family may still have missing events, and adults must judge the child's needs when they adopt a plan.

Sources