Today has four jobs, not forty widgets

The Today screen is designed to answer four questions: what is planned, what has been recorded, what appears to need attention, and what can wait. In the development build, it places a workout beside calorie and protein totals, steps, sleep duration, and short recommendation cards. The goal is one daily orientation point rather than forcing a person to reconcile separate training, food, and wearable dashboards.

That layout does not make every number equally reliable. A meal a person reviewed and saved has a different origin from a wearable estimate; a completed workout is different from a planned one; a sleep duration may be missing, manually entered, or inferred by a device. A connected screen becomes useful only when it preserves those distinctions instead of flattening them into a single authoritative “health score.”

Connection should reduce the work of interpretation. It should never hide where a number came from.

What the current development build actually does

Today currently asks the Moow API for a daily summary. The backend totals calories and protein from saved meals, loads the stored workout plan, and checks whether that workout has a completed session. The mobile app caches the latest summary so an offline screen can show the last saved plan. That offline label matters: cached context is still useful, but it is not the same as a live update.

Some displayed inputs are still development fixtures. Calorie and protein targets are fixed in the current Today endpoint, and the step and sleep values are not yet coming from finalized production wearable integrations. The recommendation cards are straightforward development rules built around those fields. They are not a clinically validated AI model, and the current workout is not automatically rewritten from sleep, heart rate, or readiness.

• Saved meals: totaled from the user’s own logged entries.
• Workout: loaded from the current stored plan and session status.
• Offline state: the most recent cached summary, visibly marked as offline.
• Steps, sleep, and targets: development data until live integrations and profile wiring are completed.

What a responsible recommendation layer needs

The planned product direction is to compare goals, recent activity, meals, workouts, and recovery signals before suggesting a practical next step. That does not mean converting every low sleep score into a cancelled workout or every protein gap into the same dinner prompt. Recommendations need source quality, recency, personal baseline, recent behavior, and the cost of being wrong.

A good system should also communicate uncertainty. “Your watch recorded less sleep than usual” is more honest than “you are not recovered.” “Your logged meals are below today’s target” is different from “you have eaten too little,” because meals may be missing or portions estimated. Before this layer is treated as adaptive coaching, Moow must validate its inputs, define supported decisions, and make the unchanged manual path easy to use.

Read the screen as a briefing, not a verdict

Start with provenance. Was the meal reviewed? Is the workout completed or merely scheduled? Is the sleep value current? Then look for an action you can safely take: log a missing meal, begin the planned session, choose an easy walk, or ignore a nudge that does not fit the day. One screen can organize the decision, but it cannot observe symptoms or understand an unrecorded event.

The product standard is therefore restraint: fewer recommendations, clearer reasons, and visible ways to correct the input. As the system develops, users should be able to disconnect a source, edit a record, decline a suggestion, and keep using the underlying logs. Today succeeds when it makes the day easier to understand—not when it makes the app sound certain.

Sources

1. Umbrella review: Accuracy of consumer wearable technology
2. CDC: Physical activity recommendations for adults
3. AASM and SRS: Recommended sleep duration for healthy adults