Precision Physiques

The split is the whole design: the engine owns the numbers and the model owns the food. Nothing a model returns is allowed to become a calorie target, and the targets it writes around are floored twice over — never below a client's own resting burn, never below a hard minimum set by sex, and never generated at all below the very-low-calorie line the platform refuses to aim at. The floor is never silent either: when it bites, the coach sees that it bit and by how much, rather than a number that quietly moved.

One rejected approach is worth naming. Allergies were first handled by matching words in food names against what the client had typed, and that filter was hardened five times and beaten five times — mostly in the wrong direction. Across a measured run of forty-eight plans for eight realistic clients, twelve of the fourteen failures were the filter refusing food the client could perfectly well eat: peanut butter withheld from someone avoiding dairy, olive oil from someone who disliked olives, oats treated as gluten. Removing it took that run from 71% to 96%. What replaced it is a vetted list decided once per client, which the plan writer is then bounded by — a food that is not on a client's list cannot appear on their plate whatever its name contains. The coach sees every list with its reasons and can exclude anything he disagrees with, and the platform will not let him allow a food whose own packet declares, at high confidence, an allergen that client named.

The console is where the coach actually works — the cohort roster, six plan slots per client, a plan wizard that regenerates a plan at a new calorie target, an editable food library, client messaging, progress photos and a weigh-in that reflows every plan a client holds.

Plan generation fails towards refusal, deliberately. A drafted week that lands too far from its target is not quietly stored as a plan — it is held, flagged, and cannot be released to a client. The direction of that error was chosen rather than inherited: refusing costs the coach a regenerate, while accepting costs a client a bad week.

Nothing reaches a client until the coach has reviewed and approved it. The backend runs on an isolated Firebase project with consent capture, an audit log and data export built in — because the data involved is health data, not an order history.

Isolation is enforced rather than intended: this platform runs on its own backend project, shared with nothing else MAST has built. A subject-access request is answered by one call that gathers everything held about a client — plans, messages, photos, requests and the coach's own private notes, including drafts that were generated and never released to them — and every export writes a durable record of who ran it and when.