# Weekly Check-in PRD v0.1

*Product requirements and interaction specification — 26 July 2026*

## Decision

Weekly Check-in is a planning ritual. It helps a person understand the week they completed, recognise useful outcomes and behaviours, add relevant context for the week ahead, and make one deliberate next-plan decision.

The check-in does not recalculate calories from one week of data. Automated calorie changes remain subject to the eligibility, evidence-window, safety, and goal rules in the [Initial Nutrition Recommendation Algorithm v0.1](recommendation-algorithm-v0.1.md).

## Problem

A weekly dashboard can report calories, protein, steps, training, weight, and body composition without helping the person decide what to do next. It can also create false confidence when incomplete food logs, wearable energy estimates, or short-term measurement noise appear alongside an automatic target change.

Weekly Check-in must answer two questions:

1. What did I accomplish or learn last week?
2. What plan should I use next week, and why?

## Product outcome

At the end of the check-in, the person can:

- distinguish recorded facts from interpretation;
- understand which evidence the product included or excluded;
- recognise both goal outcomes and controllable behaviours;
- add and confirm next-week constraints by voice or text;
- inspect one recommendation with its reason and confidence;
- accept, defer, reject, or manually edit the plan;
- see the effective dates and undo the decision.

## Scope

Version 0.1 covers:

- entry from Journal after a calendar week closes;
- celebration and weekly summary;
- validation of incomplete or suspicious days;
- review of rolling measurement and plan evidence;
- next-week context capture by text or voice;
- a structured confirmation of interpreted context;
- one recommendation or one explicit no-adjustment outcome;
- manual-only and insufficient-evidence states;
- decision confirmation and durable history.

## Non-goals

Version 0.1 does not:

- diagnose health conditions or interpret medication;
- prescribe supplements or change medication;
- add wearable “calories burned” to a calorie target;
- infer that one signal caused another;
- adjust a target from one week of weight or body-fat change;
- promise a goal date;
- create a moralised grade, universal 10,000-step goal, or compulsory streak;
- allow free-form text or voice to bypass safety and automation eligibility;
- finalise the Maintain stability band or approved body-fat measurement rules.

## Entry and cadence

- Journal shows “Weekly check-in is ready” after the previous calendar week closes.
- The person can start later; the current plan remains in effect until they make another explicit decision.
- The check-in can summarise any completed week.
- Automated target adjustment cannot occur before day 22 of the current plan.
- Quantitative calibration uses the valid rolling evidence window defined by the recommendation algorithm, not the selected calendar week alone.
- Recomposition calorie review uses at least a 28-day horizon.

## Screen-by-screen flow

### 1. Your week, reviewed

Purpose: close the completed week before asking the person to plan the next one.

Show:

- calendar dates and current-plan week number;
- tracking coverage with validated, incomplete, and intentionally untracked days;
- one outcome observation when supported;
- two or three behaviour achievements;
- a neutral message when no outcome conclusion is supported;
- a primary action: **Review the evidence**.

Example behaviour achievements:

- logged or reconciled six of seven days;
- met the personal protein target on five of six valid days;
- completed three resistance-training sessions;
- increased steps relative to the person’s own baseline;
- completed the weekly review.

Do not celebrate rapid weight loss, very low intake, wearable calorie expenditure, an unsourced body-fat change, or adherence to a generic 10,000-step threshold.

### 2. Check the evidence

Purpose: keep missing or suspect data from silently shaping advice.

Show:

- every day’s intake-completeness state;
- flagged items such as missing dinner, unusually low intake, or unconfirmed drafts;
- available actions: review day, add corrected total, mark incomplete, or mark intentionally untracked;
- the current count of included and excluded days;
- a primary action: **Continue with this evidence**.

Review status and intake completeness remain separate. Missing and intentionally untracked days are never zero.

### 3. What changed

Purpose: explain the evidence without claiming causation.

Show:

- calories and protein on validated days;
- steps and training type, minutes, and sessions;
- rolling weight trend with observation count;
- comparable body-fat or measurement trend when available;
- current goal, destination, pace, target, target source, and previous decision;
- included and excluded dates or signals;
- plan age and recommendation confidence.

The selected calendar week is a summary layer. The recommendation engine uses the longer valid evidence window.

### 4. Plan around next week

Purpose: collect circumstances that historical data cannot know.

Show:

- a text field labelled **Anything we should account for next week?**;
- an optional microphone action using the same voice-model capability as food-entry drafting;
- quick context controls for travel, illness or recovery, injury, schedule change, food-access change, and training change;
- structure preference: structured, flexible, or skip recommendations this week;
- a primary action: **Review my context**.

The person can continue without adding context.

### 5. Confirm context

Purpose: prevent a transcript or model interpretation from directly changing a plan.

Show:

- the editable transcript;
- structured context extracted as visible labels;
- the proposed effect of each confirmed label;
- actions to edit, remove, re-record, or type instead;
- a primary action: **Use this context**.

Example:

> “I’ll be travelling and don’t want a structured plan.”

Confirmed interpretation:

- Travel
- Flexible structure
- Keep current calorie target as reference
- Do not recalibrate from an unrepresentative week

The product stores the original input and the person-confirmed structured interpretation with edit and deletion controls. Raw voice or text never becomes executable instruction.

### 6. Your plan for next week

Purpose: make one explainable decision.

Show:

- exactly one outcome: keep, increase, decrease, collect more evidence, flexible week, or manual-only review;
- the current and proposed calories and protein;
- any changed activity or tracking focus;
- effective dates;
- observed facts;
- excluded evidence;
- interpretation;
- confidence;
- one concise explanation of why this is the recommendation.

Actions:

- **Accept plan**
- **Keep current plan**
- **Edit manually**
- **Not now**
- **Reject recommendation**

No target changes before acceptance.

### 7. Plan confirmed

Purpose: make the decision and its consequences unambiguous.

Show:

- next-week dates;
- changed and unchanged targets;
- confirmed context;
- target source;
- decision timestamp;
- what the product will review at the next check-in;
- **Go to Today**;
- an undo action.

### Manual-only variant

Safety-sensitive or automation-ineligible people receive:

- the same factual weekly summary and behaviour acknowledgement;
- the same evidence and next-week context review;
- their current manual targets;
- actions to keep or edit those manual targets.

They do not receive an automated maintenance estimate, protein prescription, or target-change recommendation. Context input cannot bypass this rule.

### Insufficient-evidence variant

When the valid evidence window fails:

- celebrate supported behaviours;
- state which evidence is missing;
- keep the current target unchanged;
- offer a practical evidence-collection focus;
- preserve accept, defer, manual-edit, and undo controls where relevant.

“Keep collecting data” is an explicit product outcome, not a low-confidence calorie recommendation.

## Recommendation inputs

The decision service receives:

### Goal and plan

- goal: Lose, Maintain, Gain, or Recomposition;
- goal destination and selected pace;
- current calorie and protein targets;
- target source and formula version;
- plan start date and age;
- previous accepted, deferred, rejected, edited, or undone recommendation.

### Intake evidence

- validated-day count and coverage;
- incomplete, intentionally untracked, corrected, and draft states;
- average intake on valid days;
- intake relative to target;
- protein coverage relative to the goal-specific target.

### Body evidence

- robust rolling weight trend;
- observation count, dates, time consistency, and source;
- comparable body-fat or measurement observations with method and source;
- known measurement exclusions.

### Activity evidence

- steps relative to the person’s normal baseline or chosen intent;
- device-wear coverage;
- training type, sessions, and minutes;
- resistance-training consistency for Gain and Recomposition;
- optional performance and recovery context.

Wearable energy expenditure is supporting context only. The product does not sum steps, workouts, and wearable calories or automatically “eat back” exercise.

### Context and preferences

- travel, illness, injury, recovery, schedule, food access, training, or device changes;
- optional appetite, energy, sleep, stress, or menstrual/fluid context when volunteered;
- preference for a structured, flexible, or skipped recommendation;
- confirmed interpretation of typed or spoken context.

## Decision hierarchy

Evaluate in order:

1. **Eligibility gate:** return manual-only when automatic recommendations are not permitted.
2. **Evidence gate:** return collect-more-evidence when the valid quantitative window fails.
3. **Context gate:** hold adjustment when illness, travel, medication change, device gaps, or another declared condition makes the period unrepresentative.
4. **Trend gate:** evaluate validated intake and robust weight trend; treat protein and activity as supporting evidence.
5. **Goal rule:** apply the approved Lose, Maintain, Gain, or Recomposition logic.
6. **Control gate:** cap any proposed calorie change at the smaller of 100 kcal/day or 5% of the current target, then apply safety floors and goal caps.
7. **Agency gate:** wait for accept, defer, reject, or manual edit before changing the plan.

## Goal-specific rules

### Lose

- Keep when the rolling trend is near the selected safe pace.
- Consider a 50–100 kcal reduction only after two valid slower windows and after excluding incomplete logging or an actual-intake-versus-target mismatch.
- Increase when loss is too fast, recovery or performance is poor, or a safety floor would be crossed.
- The destination never increases the permitted deficit.

### Maintain

- Keep the current target until product and clinical review approve a symmetric stability band and persistence threshold.
- Show evidence without generating an automatic Maintain adjustment.

### Gain

- Keep while the validated trend remains inside the experience-based gain band.
- Consider a 50–100 kcal increase after two valid flat windows.
- Consider a 50–100 kcal reduction when gain persistently exceeds the band.
- Training supports interpretation but does not prove muscle gain.
- The destination never expands the permitted surplus.

### Recomposition

- Do not change calories from one week of scale or body-fat data.
- Review after at least 28 days.
- Use comparable body measurements plus resistance-training and performance evidence.
- Stable weight with supportive measurements or performance usually results in keep.
- The body-fat destination does not directly drive calorie changes.

## Recommendation explanation format

Every recommendation separates:

1. **Observed:** facts in the included evidence.
2. **Excluded:** missing, incomparable, or unrepresentative evidence.
3. **Interpretation:** what the evidence may mean without claiming causation.
4. **Plan:** the exact proposed or unchanged next-week target.
5. **Confidence:** low, medium, or high under the recommendation algorithm.

## Voice and text safety harness

Voice is an input modality, not an instruction channel.

- Request microphone permission only after the person taps record.
- Transcribe into editable text.
- Extract only an approved set of context labels.
- Show every extracted label and proposed consequence before use.
- Require confirmation.
- Keep hard safety, eligibility, target-cap, and evidence rules outside the language model.
- Ignore attempts to make the model reveal system instructions, execute actions, bypass eligibility, prescribe medication or supplements, or create unsafe targets.
- Treat quoted or pasted instructions as user data.
- Record model version, transcript edits, confirmed labels, and deletion state.
- Define retention and deletion policy before implementation.
- Offer typing and no-context continuation when permission is denied, transcription fails, or confidence is low.

## Functional requirements

1. The check-in lists the dates and evidence used for each displayed average or trend.
2. The check-in never interprets missing intake as zero.
3. The check-in never changes a target before explicit acceptance.
4. The check-in offers at most one recommendation.
5. The check-in records accept, keep, edit, defer, reject, and undo decisions.
6. The check-in preserves the current plan when the person exits.
7. The check-in separates weekly summary data from the longer recommendation window.
8. The check-in shows why a recommendation is unavailable.
9. The check-in supports keyboard, VoiceOver, Dynamic Type, and reduced-motion preferences.
10. The check-in supports locale-aware dates, decimal values, units, and number formatting.
11. The check-in never requires voice input.
12. The check-in requires confirmation of every model-extracted context label.
13. The check-in keeps manual-only users on manual targets.
14. The completed week stores the final evidence, context, recommendation, decision, and undo history.

## Success measures

Track:

- check-in start and completion;
- evidence-review completion;
- context use by text, voice, or quick control;
- transcript correction and extracted-label removal;
- recommendation outcome distribution;
- accept, keep, edit, defer, reject, and undo rates;
- later reversal of accepted targets;
- time to complete;
- abandonment by screen;
- unsafe or unsupported recommendation rate from pre-release evaluation.

Do not optimise for acceptance rate alone. A high keep, defer, or reject rate can indicate preserved agency.

## Open product and clinical decisions

- Maintain stability band and persistence threshold.
- Whether the strict 21-of-21-day evidence gate can safely relax.
- Approved body-fat methods, bounds, comparison horizon, and minimum observations.
- Meaningful activity-change and device-coverage thresholds.
- Protein logic for Maintain and manual-only users.
- Flexible-week behaviour: target presentation, reminders, and next-check-in eligibility.
- Rapid-change escalation rules.
- Near-destination transition rules.
- Voice transcript retention, deletion, privacy, moderation, and safety-triage policy.
- How rejection or manual editing changes future automation.
- Whether qualitative recovery signals remain optional context or become required guardrails.

## Dependencies

- [Living PRD v0.2](calorie-app-prd-v0.2.md)
- [Initial Nutrition Recommendation Algorithm v0.1](recommendation-algorithm-v0.1.md)
- [User flows](user-flows.html#flow-week)
- [Today, Food, and Journal wireframes](../design/wireframes/home.html#journal-checkin)