Flagship case study · health and performance intelligence

Apex Human Hybrid

CoachAI → Apex Human Hybrid

I built and operate Apex Human Hybrid as a private application connecting training plans with workout history, recovery signals, route analysis, and race results. It grew from CoachAI as repeated loading of years of history consumed increasing tokens and credits. I designed the PostgreSQL/PostGIS data model, ingestion pipelines, APIs, readiness calculations, model routing, and web clients, with a locally built Swift wrapper for mobile access.

Working private application PostgreSQL/PostGIS · FastAPI · Vue/Swift

Evidence and current limits

Repository evidence records 135 tracked migrations, 42 certified state releases, and 12,415 workout-set rows in the dated production snapshot. These figures measure platform scale and data maturity. Performance improvement is tracked separately through longitudinal training, physiology, and race outcomes. The documented athlete record includes a VO2 max estimate rising 3.9% to 39.53 mL/kg/min over about five weeks, up from a 30.1 trough in 2024, and a Houston 2026 HYROX result that improved one minute overall and 5:13 in total running time versus Dallas 2025. These are measured outcomes, without a causal claim that the software produced them.

Screens & Evidence

Application interfaces & tracking

Apex athlete portal dashboard — **Apex athlete portal**Desktop view connecting readiness, volume, route analysis, and the model authority boundary.

Apex event analysis phone view — **Apex event analysis**Normalized effort and elevation analysis across training blocks and race simulations.

01 / Problem

Years of training history became expensive to reload for every coaching session.

The original CoachAI file bundle preserved years of training history, physiological baselines, movement identity, and coaching rules. As the datasets and guardrails grew, each model session had to reload more context. Token and credit use increased while targeted analysis became harder to isolate.

The application moved calculation, freshness, state, and suppression rules into deterministic services. Models receive smaller fact packets for a specific task and may explain approved state. Canonical facts and workout loads remain under deterministic control.

02 / Evolution

What changed as the project grew.

01 CoachAI prompt bundle
Eleven volatility-aware files separated daily state from stable athlete facts.
02 Data platform
PostgreSQL/PostGIS, Python ETL, layered schemas, and certified snapshots became the source of truth.
03 Application surfaces
FastAPI served a Vue portal, React Gym PWA, and Swift wrapper with offline work.
04 Controlled operation
Certified state releases, validation, and fallback text support ongoing use of the private application.

03 / What I built

A governed platform around biological and training data.

Layered data model Raw, core, dimension, mart, API, operations, and geospatial schemas with 135 tracked migrations.
Safety engines Expected-weight calculations and HRV or resting-heart-rate suppression gates run outside model inference.
Multi-surface clients A Vue athlete portal and React Gym PWA support analysis and gym-floor logging. Client work also includes a locally built Swift wrapper.
Bounded model router Provider and local-model lanes produce schema-constrained prose with deterministic fallback text.
Review queues Unknown movement mappings and ambiguous organic notes wait for human resolution.

04 / Architecture

Facts move through deterministic gates before a model sees them.

Working private application

Telemetry Health, plans, workout logs

Ingestion Python ETL + normalization

Canonical state PostgreSQL/PostGIS

Bounded AI Schema-checked narrative

Clients Portal + Gym PWA + Swift source

Simplified architecture of the private application, showing how training data becomes validated state and coaching context.

05 / System Boundary

Safety-critical decisions remain deterministic.

Deterministic tasks

Identity and data freshness
Unit conversion and movement precedence
HRV and RHR suppression gates
Expected-weight calculations
State certification and fallbacks

Model reasoning

Rewrite approved facts
Parse organic notes into proposals
Suggest movement taxonomy candidates
Generate bounded dashboard prose

Human decisions

Resolve ambiguous movements
Review proposed mappings
Approve release promotion
Interpret health context

06 / Reliability

Stale inputs and model failures remain visible.

State releases use hashes, locks, and atomic promotion. Ambiguous mappings enter a review queue. Unsupported model values fail validation and return precomputed text.

Data freshness and fallback states remain visible in the coaching workflow, so a delayed health feed or failed model response can be distinguished from current training information.

07 / Outcomes

The platform measures system maturity and longitudinal athletic change separately.

What changed

A prompt-based coaching workflow became a database-backed application with ETL, APIs, clients, release state, and explicit authority boundaries.

Performance tracked

The athlete record shows a VO2 max estimate rising 3.9% to 39.53 mL/kg/min over about five weeks, up from a 30.1 trough in 2024. Houston 2026 improved one minute overall and 5:13 in total running time versus Dallas 2025.

Claim boundary

The system records and analyzes these outcomes. The available evidence does not establish that the software caused the physiology or race improvements.