P247 — Design Document & Architecture Roadmap

Version: 1.0 Date: 25 March 2026 Author: Myles Bruggeling, Founder Status: Living document for roadmap discussion

Table of Contents

1. The Product Test
2. Product Vision 1.5. Prediction Primitives
3. Market Position
4. Current State (What Exists Today)
5. System Architecture
6. Core Product Components
7. Data Pipeline
8. AI Engine
9. iOS App
10. Infrastructure & Deployment
11. Business Model & Monetisation
12. Roadmap
13. Risks & Mitigations
14. Open Decisions
15. Reference Documents

0. The Product Test

Every day, the user should either make a different decision than they would have, or feel more confident in the one they made. If that’s not happening, nothing else matters.

Everything in this document serves this test or gets cut. Every feature, every integration, every prediction primitive exists to help an athlete make a better decision today. If a capability does not contribute to that outcome, it does not belong in the product.

1. Product Vision

What P247 Is

A performance intelligence platform for serious endurance athletes. P247 reads across all of an athlete’s existing data sources (Garmin, Whoop, Oura, Strava, Apple Health, nutrition logs, body composition scans) and surfaces the patterns that predict problems BEFORE they show up in a recovery score.

The One-Liner

“Your devices tell you what happened. P247 predicts how your body will respond to today’s training and tells you what to do about it.”

What P247 Is NOT

• Not another dashboard (athletes already have too many)
• Not a training plan generator (TrainingPeaks, TrainerRoad own this)
• Not a generalist AI coach (athletedata.health already owns this positioning)
• Not a zone calculator or workout tracker

What P247 IS

A decision system that learns how your body responds to training, recovery, and fuel. Cross-device synthesis, prospective pattern detection, and plain-language interpretation of what multi-source health data actually means for today’s training decision.

Core Belief

Performance is not limited by effort. It is limited by the body’s capacity to absorb effort.

Most athletes who plateau are under-recovered, under-fuelled on the days that matter, or accumulating fatigue faster than they dissipate it. P247 finds which of these is true for a specific athlete, right now, in the context of their specific goal.

Core Product Loop

Predict → Decide → Act → Measure → Learn

This loop is the product. Every feature either feeds data into this loop, improves a stage of this loop, or presents the output of this loop to the athlete.

1.5 Prediction Primitives

These are the named, user-facing prediction types that P247 surfaces. They are product primitives, not internal categories. Athletes should recognise them by name and expect to see them when conditions warrant.

These predictions are user-facing, named, and repeatable. Athletes should recognise them by name and expect to see them when conditions warrant.

2. Market Position

Competitive Landscape

Three User Archetypes

Key Differentiators

1. Cross-device synthesis (not locked to one wearable ecosystem)
2. Predictive, not reactive (pattern detection before the crash, not explanation after)
3. Specialist focus (recovery intelligence, not generalist coaching)
4. Strength + cardio synthesis (most competitors are cardio-only)
5. Direct Garmin integration (main competitor athletedata.health doesn’t have this)
6. Decision system, not dashboard (one decision per day, with a learning loop that improves over time)
7. Risk as first-class concept (injury risk, burnout risk, performance suppression surfaced proactively)

3. Current State (What Exists Today)

3.1 Backend API (app.p247.io)

Stack: Python / FastAPI / SQLite / Uvicorn Location: /opt/p247-backend on home server (Tailscale: 100.66.36.81) Domain: app.p247.io (Cloudflare) Total live endpoints: 42+

3.2 Mission Control (Personal Dashboard)

Stack: Node.js / Express / HTML/JS frontend Location: /home/james/.openclaw/workspace/mission-control/ (port 8765 + Next.js on port 3000) Purpose: Myles’s personal health dashboard, HAE data receiver

Separate from P247 backend. Mission Control is the personal prototype. P247 backend is the product. Mission Control receives data from Health Auto Export (HAE), generates briefs using that data, and serves Myles’s personal dashboard. P247 backend will receive data from the iOS app directly via HealthKit.

3.3 iOS App

Status: Phase 1 functional, connecting to production endpoints Language: Swift/SwiftUI What works:

• Brief display (recovery score, metrics, coaching, events)
• Brief history with date picker
• Coach tab with messaging (text only, image support pending)
• Strava connect flow
• Body composition display
• 7-day trends
• Event countdown with training phase

What’s pending:

• Native HealthKit sync (code written, needs dropping into Xcode project)
• Push notification delivery (needs APNs .p8 key)
• Coach image attachments (backend ready, iOS needs image picker + display)
• Plan tab (backend ready, iOS needs card UI)
• Hydration display (backend returns water_ml, iOS needs rendering)
• Apple Sign In + email auth (currently API key only)
• Check-in UI

3.4 Content & Marketing

• Website: p247.io (Jekyll, GitHub Pages)
• Blog: 25+ SEO posts published (daily cadence since 5 March)
• Landing pages: 4 live (homepage, early-access, GLP-1, athletes)
• HubSpot: Forms on all 4 pages, 6 nurture emails drafted
• GA4 + Search Console: Connected, baseline established
• Reddit campaign: Stage 1 gate passed (23/20 qualifying conversations)
• Strava Club: Created, post cadence defined

3.5 Database State (as of 25 March 2026)

• 1 user (Myles)
• 422 Strava activities synced
• 20 agent messages
• 0 HealthKit syncs (iOS app hasn’t shipped native sync yet)
• 1 check-in, 1 body comp entry
• All health data currently flows through HAE -> Mission Control, not through P247 backend

3.6 Observability

• Grafana Alloy v1.14.1 shipping node metrics, app metrics, systemd logs to Grafana Cloud
• Mission Control /metrics endpoint: 30+ health/fitness Prometheus gauges
• Prometheus remote write to Grafana Cloud
• Loki log shipping to Grafana Cloud

4. System Architecture

4.1 Current Architecture (Prototype)

┌──────────────────┐
│   Health Auto     │──── Apple Health data ────┐
│   Export (HAE)    │                            │
│   (iOS, $4.99)   │                            ▼
└──────────────────┘                   ┌─────────────────┐
                                       │ Mission Control  │
                                       │ (Node.js :8765)  │
                                       │                  │
                                       │ Personal dash    │
                                       │ HAE receiver     │
                                       │ Brief generation │
                                       └────────┬────────┘
                                                │
                                         reads health data
                                                │
┌──────────────────┐                   ┌────────▼────────┐
│   iOS App         │◄── REST API ────►│  P247 Backend    │
│   (Swift/SwiftUI) │                  │  (FastAPI :8000) │
│                   │                  │                  │
│   Briefs, Coach,  │                  │  app.p247.io     │
│   Activities,     │                  │  42+ endpoints   │
│   Strava, Plan    │                  │  Claude Sonnet   │
└──────────────────┘                   │  SQLite          │
        │                              └────────┬────────┘
        │ OAuth2                                │
        ▼                                       │ OAuth2
┌──────────────────┐                            ▼
│   Apple Health    │                   ┌──────────────────┐
│   (HealthKit)     │                   │  Strava API       │
└──────────────────┘                   │  (422 activities) │
                                       └──────────────────┘

4.2 Target Architecture (Production)

                    ┌─────────────────────────────────────┐
                    │          iOS App (thin client)        │
                    │   HealthKit ◄───► Apple Health        │
                    └──────────────┬──────────────────────┘
                                   │ HTTPS
                                   ▼
                    ┌─────────────────────────────────────┐
                    │  Ingress (nginx/Traefik) + TLS       │
                    └──────────────┬──────────────────────┘
                                   │
              ─────────────────────┼──── Kubernetes Cluster ─────────────
              │                    │                                     │
              │     ┌──────────────▼──────────────────┐                 │
              │     │       API Service (HPA)          │                 │
              │     │   Auth, Sync, Briefs, Coach,     │                 │
              │     │   Activities, Trends, Plan       │                 │
              │     └──┬──────────┬───────────┬───────┘                 │
              │        │          │           │                          │
              │   ┌────▼────┐ ┌──▼────┐ ┌────▼──────┐                  │
              │   │Postgres │ │ Redis │ │   S3/GCS  │                  │
              │   │(managed)│ │       │ │  (images, │                  │
              │   │         │ │       │ │  exports) │                  │
              │   └─────────┘ └───────┘ └───────────┘                  │
              │        │                                                │
              │   ┌────▼────────────────────────────────┐               │
              │   │     Worker Pods                      │               │
              │   │                                      │               │
              │   │  ┌────────────┐  ┌────────────────┐ │               │
              │   │  │Data Poller │  │Brief Generator │ │               │
              │   │  │(CronJob)   │  │(CronJob, per   │ │               │
              │   │  │            │  │ athlete TZ)    │ │               │
              │   │  └────────────┘  └────────────────┘ │               │
              │   │                                      │               │
              │   │  ┌────────────┐  ┌────────────────┐ │               │
              │   │  │Normaliser  │  │Push Notifier   │ │               │
              │   │  │(queue)     │  │(queue)         │ │               │
              │   │  └────────────┘  └────────────────┘ │               │
              │   └──────────────────────────────────────┘               │
              │        │                                                │
              │   ┌────▼────────────────────────────────┐               │
              │   │     Analysis Engine                  │               │
              │   │                                      │               │
              │   │  Readiness · Training Load · Sleep   │               │
              │   │  Body Comp · Adaptation · Flags      │               │
              │   │  LLM Brief Generation (Claude/GPT)   │               │
              │   └──────────────────────────────────────┘               │
              │                                                         │
              │   ┌──────────────────────────────────────┐              │
              │   │  Webhook Receivers                    │              │
              │   │  Strava · Garmin · Whoop · Oura      │              │
              │   └──────────────────────────────────────┘              │
              │                                                         │
              ──────────────────────────────────────────────────────────
                         │              │              │
                   ┌─────▼───┐   ┌──────▼───┐  ┌──────▼───┐
                   │ Strava  │   │ Garmin   │  │ Whoop /  │
                   │ API     │   │ Health   │  │ Oura API │
                   │         │   │ API      │  │          │
                   └─────────┘   └──────────┘  └──────────┘

4.3 Key Architectural Principles

1. iOS app is a thin client. All intelligence, analysis, and recommendation logic lives server-side. App collects, syncs, and displays.
2. Backend handles all wearable API integrations. The app never calls Strava/Garmin/Whoop directly. Server holds OAuth tokens, pulls data, normalises it.
3. Containerised from day one. Every component is a Docker container. Kubernetes for orchestration. No bare metal application code.
4. Separate data stores per concern. Postgres for relational data, Redis for caching/queues, S3 for images/exports. Time-series extension (TimescaleDB) if health sample volume warrants it.
5. Observability built in. Prometheus metrics, structured JSON logs, OpenTelemetry traces. Grafana Cloud for dashboards and alerting.

5. Core Product Components

5.1 Daily Performance Brief

The primary product output. Generated nightly per athlete’s timezone.

Structure:

• Readiness signal: Push (🟢 ≥75) / Train Smart (🟡 ≥60) / Easy (🟠 ≥45) / Recover (🔴 <45)
• Recovery score (0-100) with 6-component breakdown (sleep 25%, HRV 20%, fragmentation 20%, deep sleep 15%, RHR 10%, load 10%)
• Key metrics: sleep, vitals, activity, nutrition, training
• 7-day trends (avg sleep, HRV, RHR)
• Body composition (latest scan)
• Event countdown with periodisation phase
• One primary decision for the day (the single most important thing)
• Supporting context (max 1 additional insight, only if genuinely relevant)
• Confidence level on primary decision (High / Medium / Low with different UI treatment)
• Reasoning: “Why this matters today” with source data references

The system must always choose the single most important decision for today. Not top 3, not top 2. One primary. Everything else is subordinate.

Generation pipeline:

1. Scheduler fires per athlete (configured time minus 90 min)
2. Normaliser processes raw data
3. Deduplicator merges overlapping records
4. Analysis engine runs all components
5. LLM generates natural language brief from analysis outputs
6. Brief stored in database
7. Push notification sent at athlete’s preferred time

Emerging Patterns (Low Confidence)

Cross-domain correlations surfaced before full confidence is established. These are framed as “Early signal (learning)” to set user expectations appropriately.

Example: “Early signal: poor sleep + intensity may be impacting your HRV more than expected (low confidence, 3 weeks of data)”

Purpose: Shows the system is learning from day 1 without overpromising. Users see the system actively building their personal model, which builds trust and retention even when the system is too new to make high-confidence predictions.

5.2 AI Coaching Agent

Per-user AI agent powered by Claude Sonnet. Each athlete gets a personal coach that:

• Has full 14-day health data context
• Maintains conversation history (last 20 messages)
• Learns and remembers per-user facts (persistent memory)
• Calibrates tone based on coaching preferences (push/balanced/supportive)
• Supports image analysis (workout whiteboards, watch screenshots, gym boards)
• Follows a comprehensive coaching knowledge base covering recovery science, training load management, nutrition, body composition, Hyrox-specific training, running mechanics

Tone rules: Warm conversational prose. No markdown formatting. Lead with encouragement. Use “we” and “let’s”. Every flag gets a fix, never list problems without solutions. Write like texting your coach, not a lab report.

Safety: Backend handles all guardrails. No medical diagnosis, no supplement prescriptions. System prompt enforces appropriate boundaries.

5.3 Activity Feed (Strava Integration)

422 activities synced from Strava. Each activity gets AI-powered enrichment:

• AI-generated summary (Claude Sonnet, cached)
• Effort score (0-10 with historical comparison)
• 6-zone HR breakdown (Apple Fitness model)
• TRIMP calculation
• Training load effect (CTL/ATL before and after)
• Body region inference
• MET estimation
• HR recovery rating (2-min post-workout, 5-tier scale)
• Time-series samples: HR, speed, elevation, power, cadence (downsampled to 200 points)
• GPS route coordinates (downsampled to 300 points)

5.4 Plan Tab

Unified daily action feed replacing the old Events tab:

• Completed workouts (auto-populated from activity sync)
• Coach-suggested sessions (auto-created when coach prescribes exercises)
• Scheduled events
• Recovery alerts
• Start/complete/dismiss workflow per item

5.5 Goals & Metrics History

• Per-athlete goals: body comp targets, weekly training targets, nutrition targets, custom JSON
• Metrics history API: time-series data with stats (latest/avg/min/max) over configurable periods
• 30-day trend modals for every vital metric

5.6 Body Composition Tracking

• Manual entry of InBody/DEXA/scale results
• Trend visualisation over time
• Correlation with training load and nutrition data
• Future: OCR from scan photo

6. Data Pipeline

6.1 Data Sources & Ingestion

User decisions are a primary data source, equal in importance to physiological inputs. Whether an athlete followed, modified, or ignored a recommendation is signal that feeds directly into personalisation and model accuracy.

6.2 Data Normalisation

Raw data from different providers uses different scales, units, and granularity. The normalisation layer converts everything into a unified internal schema:

• Heart rate: BPM, unified zone calculation across providers
• HRV: RMSSD in ms (Garmin gives average, Whoop gives RMSSD, Oura gives nightly average)
• Sleep: Common staging model (awake, light, deep, REM) with interval merging for overlapping segments
• Training load: Unified acute/chronic load model (CTL/ATL/TSB), with sport-specific multipliers
• Timestamps: UTC internally, athlete’s local timezone for display
• Deduplication: Same workout from HealthKit and Strava identified and merged (timestamp + activity type + duration tolerance)

Cross-device data normalisation is a core product challenge, not a pipeline detail. The differences between how Oura measures HRV (nightly average), Whoop measures HRV (RMSSD during sleep), and Garmin measures HRV (varied timing) are significant enough to produce contradictory readiness signals from the same physiological state. Solving this reliably is part of the product’s intellectual property.

6.3 Analysis Engine

The core intellectual property. Six analysis components:

Temporal Modeling

The analysis engine operates across multiple time horizons simultaneously:

• Rolling windows: 7-day acute, 42-day chronic, and custom windows per metric. These form the basis of load management (ATL/CTL) and trend detection.
• Decay functions: Recent data is weighted more heavily than older data. A poor night’s sleep 2 days ago matters more than one 10 days ago. Decay rates are tuned per metric type.
• Cumulative load modeling: Not just current load, but accumulated load over time with dissipation rates. An athlete who has been at 90% capacity for 3 weeks is in a different state than one who spiked to 90% yesterday.
• Lagging vs leading indicators: HRV and RHR are lagging indicators (they reflect what already happened). Training load, sleep quality, and fueling are leading indicators (they predict what will happen). The system weights leading indicators for predictions and uses lagging indicators for validation.

7. AI Engine

7.1 Architecture: Detection and Interpretation Layers

The AI engine has two explicitly separated layers:

A. Detection Layer Statistical and ML models, time-series analysis, pattern recognition, anomaly detection. This layer processes raw normalised data and produces structured signals with confidence scores. It identifies when a prediction primitive (Section 1.5) should fire, calculates risk scores, and detects cross-metric correlations. Detection outputs are deterministic given the same inputs and are fully testable.

B. Interpretation Layer LLM translates detection layer outputs into human language. Adds context, explains reasoning, suggests action. The interpretation layer never generates insights independently. It is always grounded in detection layer outputs. If the detection layer does not flag something, the interpretation layer does not surface it.

This separation is critical: detection must be reproducible and testable; interpretation must be natural and personal. A bug in detection is a data science problem. A bug in interpretation is a prompt engineering problem. Keeping them separate means each can be improved, tested, and debugged independently.

7.2 LLM Usage

7.3 Insight Philosophy (Five Performance Levers, Priority Order)

1. Recovery Capacity (foundation; if the athlete can’t recover, nothing else matters)
2. Nutritional Timing and Adequacy (day-specific fuelling, not daily averages)
3. Training Load Distribution (excess high-intensity clustering, Zone 2 deficiency)
4. Event-Specific Readiness (all advice anchored to a specific outcome with a date)
5. Progressive Adaptation (long-arc improvement signal across weeks)

7.4 Insight Quality Test

Every insight must pass three checks:

1. Is it specific? References actual numbers from the athlete’s data.
2. Is it cross-referenced? Connects at least two data streams.
3. Is it actionable? Tells the athlete what to do today or this week.

7.5 Anti-Staleness Design (The Week 5 Problem)

Insight variety mechanism to prevent repetition:

• Weeks 1-2: Establish baseline, surface obvious gaps
• Weeks 3-4: Trend analysis (improving, stuck)
• Weeks 5-8: Predictive signals (where is this heading?)
• Race/event prep weeks: Race-specific briefings (gear, pacing, nutrition strategy, taper)

7.6 Model Confidence Evolution

The system communicates its confidence in personalisation transparently, creating a sense of progression as it learns:

This manages expectations and creates a sense of progression. Users understand why early insights are simpler and can see the system getting smarter over time. It also provides a natural retention mechanism: leaving at week 2 means losing a system that was just starting to learn you.

8. iOS App

8.1 Tech Stack

• Language: Swift / SwiftUI
• Min iOS: 17+
• Auth: JWT (access + refresh), Apple Sign In, email/password
• Local storage: Core Data or SwiftData (offline brief caching)
• Charts: Swift Charts (native)
• Push: APNs

8.2 Screen Map

8.3 Design Direction

• Clean, minimal, dark UI (athlete/performance aesthetic)
• Information hierarchy: the brief is the hero, everything else supports it
• No dashboard overload. One screen, one decision.
• App open to brief in under 2 seconds

9. Infrastructure & Deployment

9.1 Current (Prototype)

9.2 Target (Production)

9.3 Environments

10. Business Model & Monetisation

10.1 Validation Status

10.2 Pricing Hypothesis

Pricing not validated yet. Will be tested during Stage 3.

10.3 Revenue Scenarios

$1M ARR target requires ~8,300 athletes at $12/month.

10.4 Unit Economics (Estimated)

11. Roadmap

Phase 1: Foundation (CURRENT — Complete)

Timeline: Jan-Mar 2026 (done)

Phase 2: Close the Loop (NEXT — Q2 2026)

Timeline: April-June 2026 Goal: Get real athletes using the product end-to-end

Phase 2 exit criteria: Francesca (beta tester #1) using the app daily with native HealthKit sync, receiving push notification briefs, chatting with the coach. No HAE dependency.

Phase 3: Validate & Charge (Q2-Q3 2026)

Timeline: May-July 2026 Goal: Run validation Stages 2-4 with real product

Phase 3 exit criteria: Clear signal on subscription vs event package model. At least 3/5 paid participants retained. Revenue model validated.

Phase 4: Wearable Expansion (Q3-Q4 2026)

Timeline: July-October 2026 Goal: Multi-device support (the actual moat)

Phase 4 exit criteria: At least 3 wearable ecosystems integrated. Briefs incorporate data from multiple devices for the same athlete. Deduplication working reliably.

Phase 5: Scale (Q4 2026 - Q1 2027)

Timeline: October 2026 - March 2027 Goal: Production infrastructure, App Store launch

Phase 6: Growth & Intelligence (2027+)

Long-term vision

12. Risks & Mitigations

Product Risks

Technical Risks

Business Risks

13. Open Decisions

14. Reference Documents

Summary: Where We Are & What’s Next

Built: Backend with 42+ live endpoints, AI coaching agent, Strava integration (422 activities), activity enrichment, plan tab API, admin dashboard, iOS app Phase 1, website with 25+ blog posts, SEO infrastructure, Reddit validation (Stage 1 passed).

Immediate next step (Phase 2): Close the data loop. HealthKit native sync, push notifications, auth, check-in UI. Get Francesca using the full product daily without HAE.

Critical path to revenue: Phase 2 (close the loop) -> Phase 3 (validate & charge). The entire business depends on the Stage 2-3 validation results. Everything after that is conditional on those results.

The question this roadmap needs to answer: Can P247 consistently make athletes change their daily decision or feel more confident in the one they made? That’s the product test. Everything else is execution detail.

P247 — The intelligence layer between raw data and peak performance.