Business logic
Moveat is built around a simple principle: users should be able to understand and improve their nutrition and training behavior without needing to manually manage complex spreadsheets or calorie tools. The product does not try to be a clinical system. It is a coaching and tracking system that turns user input into structured data, summaries and feedback.Product objective
The primary objective is to make daily health tracking easier:- Reduce friction when logging food, weight and workouts.
- Keep a reliable history of user progress.
- Provide daily and weekly context.
- Allow automation through conversational channels.
- Keep final business data centralized and auditable in Platform.
Core product loop
Business ownership rules
Platform owns the official state of the product. Any surface that wants to create or read business data must go through Platform.Canonical values
Platform stores canonical values in metric units even when the user prefers imperial display.
This keeps calculations stable and avoids splitting business logic across clients.
Estimation policy
Food recognition is expected to include estimation. When a user logs a meal through text, image or audio, the system may estimate food items, portion size, calories and macros. The important product rule is transparency: estimated values should be represented as estimates and should be easy to correct later.What should not happen
Moveat should avoid these failure modes:- Agent writing directly to the database.
- Frontend calculating official calorie targets independently.
- Business logic duplicated between Platform, Agent and Client.
- Long-lived user facts stored only in Redis.
- Internal APIs being treated as public frontend APIs.
- Logs, summaries or derived values becoming the only source of truth.