Product Architecture

2. Three verticals

The platform serves three distinct populations, each with its own coaching domains, role structures, and segment logic. These are not tiers or feature gates. They are structurally different products that share a common data model and intelligence pipeline.

Individual

Self-directed development arcs for individuals pursuing personal fitness goals. The Individual vertical has a single segment (“User”) and supports all five coaching domains: training, nutrition, cardio, recovery, and performance. Roles are limited to User and Coach. Capabilities include personal arcs, coach-client relationships, progress tracking, photo uploads, and in-app messaging.

Athletic

Team-based athletic development organized by sport. Each sport is its own segment (football, basketball, soccer, swimming, and others) each define distinct seasonal periodization, position structures, and training cultures. The role set expands to include team strength coach, athlete, athletic trainer, team admin, and parent viewer. Capabilities include team arcs, team programming, athlete monitoring, coach dashboards, and optional parent portal access.

Professional

Performance readiness for tactical, commercial fitness, and community health populations. Professional has three segments:

• Department: fire, police, and military contexts with duty readiness and shift-aware scheduling.
• Gym / Studio: boutique studios and class-based gyms focused on class performance and member retention.
• Community Health: corporate wellness and community centers focused on habit building at scale.

Professional uses four of the five coaching domains (performance is not currently active) and supports readiness arcs, conditioning arcs, weight management, and performance diagnostics.

3. Four data layers

The system has four distinct data abstractions that all represent cuts of the same underlying behavioral data. Understanding the difference between them is essential to understanding how the product works. They are listed here from closest to raw data to most arc-specific.

Dimensions (raw data)

Dimensions are the most granular data types the system tracks. They exist for every user regardless of vertical, segment, or arc. Dimensions represent what gets stored.

Logging domains (user input)

Logging domains are the categories the user sees on the activity logging surface. They map to the actions a user can take to record their day. There are six: Nutrition, Workout, Cardio, Steps, Weight, and Sleep. Logging domains are coarser than dimensions. They represent UI sections, not data types.

Coaching domains (system evaluation)

Coaching domains are the evaluation categories the intelligence system uses to assess behavior, detect gaps, and generate coaching actions. There are five: Training, Nutrition, Cardio, Recovery, and Performance. They are the lens through which the system looks at a user's data.

Coaching domains evaluate across logging domains. They are not one-to-one. Recovery, for example, has no direct logging section. It synthesizes from sleep logs and rest day inference from workout gaps. Steps feeds into the Cardio coaching domain because daily movement is part of cardiovascular evaluation. Weight feeds into arc progress but is not itself a coaching domain. It is a measurement input, not an evaluation category.

Paths (arc-specific targets)

Paths are the strategic evaluation lanes defined by each arc. They tell the coaching system what to evaluate and what “good” looks like at each phase. Paths are built from dimensions but are arc-specific. Different arcs draw from different combinations of the same underlying data.

The relationship flows in one direction: Dimensions (raw data) are logged via Logging Domains (user input surfaces), evaluated by Coaching Domains (system evaluation lenses), and targeted by Paths (arc-specific strategic lanes). Four different cuts of the same behavioral data, each serving a different part of the system.

4. Arcs, phases, and paths

An arc is the central unit of user engagement. It is time-bound (typically eight to sixteen weeks), phased (always four phases), and goal-directed. Every arc defines exactly two or three paths that represent the strategic lanes of effort required to reach the goal.

The four-phase progression

Every arc follows the same four-phase pattern, though the specific demands within each phase vary by arc type.

Path anatomy

Each path carries a machine-readable key, a user-facing label, a rationale explaining why the path matters for the goal, optional confidence tiers (high-data vs. low-data evaluation strategies), and an array of phase-specific targets with measurable metrics. Each metric specifies a data source, a threshold condition, a required frequency, and contextual notes for the coaching system.

Example: Fat Loss Arc

The Fat Loss arc defines three paths that must all succeed for sustainable body fat reduction:

• Increased Daily Activity. Progresses from logging activity as-is (Phase 1) through structured cardio three to four times per week with step targets (Phase 3) to maintaining those levels (Phase 4).
• Total Volume Output. Progresses from logging training as-is through structured resistance work three days per week to week-over-week volume increases measured as load multiplied by reps.
• Sustained Caloric Deficit. Progresses from unrestricted food logging through establishing a baseline intake near estimated daily expenditure to a 300–500 calorie deficit with measurable weekly weight change.

This pattern (multiple independent paths evaluated against phase-specific metrics) applies across all arcs in all three verticals.

Cross-vertical arcs

Some arcs are available across multiple verticals. Fat Loss, Strength Development, Conditioning, and Return to Training each appear in Individual, Athletic, and Professional with segment-appropriate targeting. This is possible because arcs are defined once as templates and tagged with the verticals and segments where they apply.

5. Plans, targets, and programs

Three terms with precise, non-interchangeable meanings. Conflating them causes structural confusion in the data model and the user experience.

Plan: the prescribed activity

A Plan is the atomic, one-dimensional, assignable unit. It spans exactly one coach-assignable logging domain: workout, nutrition, cardio, or steps. There is no multi-dimensional plan. One plan equals one logging domain. A coach assigns plans; an individual authors them for themselves. Plans are stored as reusable templates and can be assigned to clients independently.

Plans carry a coach-type prefix that acts as a discriminator, not a structural divergence. The plan's shape is driven by the logging domain (which already has separate storage), not by the coach type. Where a coach type genuinely needs additional fields (movement keys, RPE loading, compliance standards for strength coaches), those ride as per-type extensions on that domain's plan, never as a new type per coach.

Target: the measurable outcome

A Target is the measurable outcome to hit: 2,000 calories, 10,000 steps, a weekly volume number, a bodyweight. Plans and targets are different concepts. A dimension may carry a plan, a target, or both. Workout carries both (a prescribed program plus a volume target). Steps carry a target only (a daily step number with no structured activity prescription).

Targets derive from the arc. The system auto-derives a target from the user's current arc and phase as a proposal; the coach or user may override. On a phase change, system-derived targets recompute; coach-set targets pin until explicitly cleared. Every coach override requires a one-line rationale explaining the choice.

Program: the derived view

A Program is the arc-scoped composite of the plans an individual held across logging domains and what they actually accomplished under them. It is a plan-versus-actual view, to-date on an active arc, or final at arc end. Programs are never authored, never assigned, and have no stored record. A program exists only once plans reach an individual. Coaches never possess a program. “Program” does not appear on the coach side of the product.

6. The authoring model

The canonical authoring philosophy is system proposes, human owns. The system offers to construct; the user chooses how much to accept. This applies identically to self-coaching individuals and professional coaches.

• One full-control editor is the foundation. Every saved plan can open there, every control is reachable, and blank-canvas authoring is always available.
• An optional guided on-ramp asks intent questions and uses the user's arc context to generate a filled-in draft. That draft then opens in the full-control editor and is owned by the user.
• Control is never role-gated. A self-coaching individual has the same reachable control ceiling as a coach. Role may change defaults, suggested starting points, and client-selection context. Role must not remove editor capability.

The guided on-ramp writes a draft, not a final artifact. The draft carries intent answers, arc-derived proposals, environment constraints, and provenance metadata indicating whether it was system-proposed, wizard-seeded, blank-canvas, or coach-created. Once created, the draft opens in the full-control editor. The user can always skip the guided flow and start from a blank canvas.

This model replaces an earlier doctrine that positioned individuals as “executors, not designers.” Automatic plan generation remains valid as an on-ramp and proposal mechanism, but it is not a permanent control ceiling.

7. User states

The system classifies every user into one of seven states. These states govern which surfaces are visible, what coaching language is permitted, and how the intelligence pipeline frames its outputs. State transitions are deterministic. They are derived from observable behavioral signals, not manual assignments.

The Re-Entry Welcome philosophy

When a user returns after an inactivity gap, the system follows a strict principle: zero backward-looking language. The re-entry surface shows a single minimum-viable action and a logging call-to-action. There is no mention of streak loss, score decline, absence duration, or anything that frames the gap as a failure. The weekly review suppresses comparisons. The coaching surface limits itself to encouragement. The ambient domain view shows only positive signals.

The philosophy is that returning is the win. The system does not punish the user for coming back.

8. Surfaces and experience governance

Each user-facing surface has strict governance rules that control what kind of language and content it may contain. These rules exist because mixing coaching directives with ambient information erodes user trust and creates decision fatigue.

Coaching surface (primary domain)

This is the only surface where coaching language is permitted: verbs, directives, and action framing. It shows the primary domain header, reasoning string, tone message, tier selector, and running progress. Every other surface in the system is restricted to descriptive or ambient language only.

Ambient domain view (secondary domains)

Displays a single descriptive line per domain. No verbs, no directives, no severity language, no color coding. Tapping navigates to the logging surface. This surface appears only in the weekly plan view, not in the daily view.

Weekly plan surface

The primary domain card is permitted coaching language (verbs). The secondary domain rows are ambient (descriptive only). The primary domain is determined by the intelligence pipeline's prioritization, not by the user.

Daily execution surface

Ambient only. Shows running adherence counts and pace messages. No coaching language, no mid-week intervention.

Weekly review

Descriptive framing. The weekly win is always positive. No backward comparisons during Re-Entry. For Established users, the review may include outcome stall prompts and goal misalignment prompts, but these are framed as observations, not judgments.

Bootstrap surfaces

The three bootstrap surfaces (Onboarding, Exploring, Emerging) each have their own governance:

• Onboarding: No domain language, no scores, no signals. Absolute minimum complexity. A single prompt and logging buttons.
• Exploring: Domain counts may be visible but are not presented as recommendations. The system observes and does not direct.
• Emerging: The first coaching surface appears. Starter plans default to the minimum viable tier and use conservative, goal-aligned actions that enrich as multi-domain data accrues.

Weekly insights

Informational only. No verbs, no coaching, no actions. Shows per-domain participation, active signals, cross-domain observations, and metabolism calibration status. Available only to Established users (seven or more completed cycles).

Arc reassessment prompt

Non-judgmental. Shows an observation text with three equally-weighted options: continue, switch, or adjust the arc. “Continue” is a valid and celebrated choice. The prompt appears inline within the weekly review, not as a modal, and shows once per detection period.

9. Surface visibility matrix

Not every surface appears in every user state. The matrix below defines exactly what is visible where. An empty cell means the surface does not render for that state.

The matrix is not decorative. It is enforced at the rendering layer. If a surface does not have a “Visible” entry for a given user state, it must not render. Partial entries like “Simplified,” “Encourage only,” and “No comparisons” are governance constraints on the content and tone of a surface that does render, not separate surfaces.

10. The intelligence-to-surface contract

The coaching intelligence pipeline is a layered system that transforms raw behavioral data into user-facing experiences. Each layer has a defined input, output, and contract with the layers around it.

The pipeline

At a high level, data flows through these stages:

• Signal detection: Raw dimension data is analyzed for patterns, gaps, streaks, plateaus, and stalls. Specialized systems handle plateau diagnostics, failure zone analysis, outcome stall detection, energy calculation, and metabolism state tracking.
• Priority classification: The multi-domain prioritization pipeline ranks coaching domains by urgency and relevance to the user's arc. Domain priority weights from the arc template influence which domain gets primary attention.
• Action generation: The tiered action layer produces Full, Modified, and Minimum Viable actions per domain. This gives the user agency over how much to take on without the system deciding for them.
• Tone and framing: A tone layer and domain reasoning layer shape how actions are presented. Tone adapts to user state: encouragement during Re-Entry, direct coaching during Active phases, observational framing during Established.
• Surface routing: The visibility tier classification determines which surface receives the output. Primary content goes to the coaching surface. Secondary content goes to the ambient view. Insights go to the weekly insights surface. The routing is deterministic, not configurable.

Supporting intelligence systems

The pipeline is supported by specialized systems that produce the coaching content it consumes:

• Coaching Decision Engine. Aggregates signals, classifies decisions, and generates insights and interventions.
• Nutrition Plateau Diagnostics. Distinguishes true plateaus from adherence issues and metabolic adaptation.
• Exercise Substitution Mapping. Over 70 substitutions for plateau breaking, injury accommodation, and equipment constraints.
• Failure Zone Analysis. Detects sticking points across 28-day windows.
• Outcome Stall Detection. Identifies when behavior is consistent but outcomes are flat.
• Energy Calculation Engine. Estimates daily energy balance from observed data.
• Metabolism State. Tracks daily energy expenditure confidence through three stages: insufficient data, building, and well-calibrated.

The coach surface boundary

On the coach side, the intelligence-to-surface contract is governed by a strict boundary between two surfaces:

• Plans = inventory. What a coach builds and hands out. Plan template libraries and the “Assign to Client” action.
• Pulse = responsibility. What a coach is accountable to review and respond to. Active assignment monitoring, duty queues, highlights (wins), and SLA-tracked review items.

An assignment is a Plans action that creates a live responsibility. Monitoring that responsibility belongs on Pulse, not Plans. This separation ensures that the template library is never cluttered with operational state, and the duty queue is never obscured by authoring tools.

The governing principle

Every intelligence output has exactly one destination surface, one visibility tier, and one set of language governance rules. No surface may exceed its governance tier. No coaching language on ambient surfaces. No backward-looking language during Re-Entry. No score-decline framing anywhere. The intelligence pipeline produces the content; the surface governance rules determine how and whether it is shown.

The result is a system where vocabulary, data architecture, coaching intelligence, user state, and surface presentation are all governed by the same coherent set of rules, from the raw dimension logged by a user on day one through the coaching intervention shown to an established user in week twelve.