Cycling Training Intelligence: A Case Study in Grounded AI
A working example of what Orbital builds. CTI is an AI coaching platform whose advice runs on the athlete's actual power history, fitness trajectory, and past coaching conversations — not generic training-blog content. It's the public proof of concept for the approach Orbital takes with every client.
The Problem: Generic AI Gives Generic Coaching
Plug an off-the-shelf chatbot into a cycling training context and you get plausible-sounding nonsense. It will cheerfully recommend a 4×8-minute threshold session to a rider whose training stress balance has just dropped to −35 and who told the coach last week she was fighting a flu. It doesn't know what FTP means in the athlete's actual numbers. It doesn't remember the conversation about the September Gran Fondo. It hallucinates citations to studies that don't exist.
This is the same failure mode that hits every domain-specific AI product. The model has fluency without grounding. It sounds expert and behaves like a tourist.
The fix isn't a better model. It's giving the AI access to the structured intelligence the domain actually runs on — in CTI's case, the rider's power data, the fitness model the coaching profession agrees on, and the history of what's been said before.
What Was Built
CTI is a production web application with a coaching layer that:
Knows the rider's training state. Every conversation starts with the athlete's CTL (chronic training load), ATL (acute training load), TSB (training stress balance), FTP, recent rides, and any persistent profile facts — goals, target events, medical conditions — already loaded into context. The coach never asks "what's your FTP?" — it knows.
Remembers across sessions. Three layers of memory — permanent profile facts, per-session episodic summaries, and a hybrid keyword + semantic search over full chat history — mean the coach can reference last Tuesday's threshold workout, the Gran Fondo plan from three weeks ago, or the recurring left-knee complaint without the rider having to repeat themselves.
Refuses to leave its lane. A cheap classifier short-circuits off-topic messages — weather, poems, unrelated questions — before they ever reach the main model. The coach stays a coach.
Generates structured outputs. Workouts come back as valid .zwo files for Zwift and Rouvy. Weekly summaries follow a consistent structure. Slash commands (/ride, /week, /form, /training) trigger purpose-built skills with their own prompts and tool selections.
Improves with use. Every conversation is captured as a trace. Bad responses get tagged in an admin triage UI and promoted into a regression test suite. Prompt changes are validated against the suite before they ship. The system gets measurably better over time, not worse.
Composes with other tools. An authenticated MCP server exposes CTI's rides, fitness state, profile memory, workout generator, and coach to any compliant agent — Claude Desktop, n8n, Zapier — so users can wire CTI into their own workflows without CTI having to build every integration.
How It Was Built
The system is documented in depth across a five-part technical series. Each post covers one of the architectural pillars.
1. Building CTI in One Week with Claude Code — the foundation. 3D route viewer, FIT-file parsing, cinematic camera animation, real-time charts. Production-ready in a week, ~$50 of model spend.
2. CTI's AI Architecture: How the Coaching Layer Works — the request pipeline. PII redaction, intent routing with a hard off-topic exit, ten-layer system-prompt assembly, three-tier memory, and hybrid search across four sources merged with Reciprocal Rank Fusion.
3. CTI's Reinforcing Evals Loop — the quality machinery. Prompt versioning, trace capture via OpenTelemetry, golden + regression fixtures via Evalite, an admin triage UI that promotes real production failures into the test suite.
4. CTI's MCP Server: Making the Coach Composable — the OAuth 2.1 + Personal Access Token auth model, the resource / tool / prompt surface, and the per-user scoping that keeps the existing libraries usable from a different transport without weakening the security model.
5. CTI's Fitness Metrics: TSS, CTL, ATL, TSB — the domain model the coach reasons in. Bannister's impulse-response framework, the Critical Power model, why TSS-based load tracking is the right level of abstraction for a coaching AI to ground its recommendations on.
If you're a senior engineer or technical founder evaluating whether Orbital can build this kind of system for you, the architecture and evals-loop posts are the ones to read first.
What This Proves About How Orbital Works
CTI is not a demo. It's a production system, shipped fast, instrumented properly, and grounded in domain knowledge that took years to learn. Reading the series, a buyer sees:
The Map → Architect → Build approach applied end-to-end. The fitness-metrics post is the Map output: this is the structured intelligence the coach reasons in, and here's why this is the right vocabulary. The architecture and evals posts are Architect and Build.
AI grounded in real data, not vibes. The model never freelances. It has the rider's CTL, the right ride, the right past conversation, all loaded before it generates a single token.
Production-grade infrastructure most teams don't build. Multi-tier memory, hybrid retrieval with Reciprocal Rank Fusion, prompt versioning, trace-driven regression evals, an authenticated MCP server with OAuth 2.1 and PATs — the kind of architecture larger AI teams aspire to and small teams skip.
Domain knowledge, embedded correctly. TSB, CP modeling, PMC, TSS — the metrics aren't decorative. They're the substrate the coach reasons over, and the post explains why each one is in the system and how it shapes recommendations.
Documentation as a deliverable. Roughly 15,000 words explaining why each decision was made. That's the same standard of clarity Orbital brings to client engagements — a system your team can maintain and extend without me, because the reasoning is on paper.
The Translation: Same Architecture, Different Substrate
If you're a cycling platform, CTI is your reference architecture. If you're not — if you're an accounting firm, an environmental consultancy, a logistics operator, a law practice, a financial services group — the architecture is the same. The structured domain model, the grounded retrieval, the multi-tier memory, the eval loop, the MCP surface for composability — none of that is cycling-specific.
What changes for your business is what goes into the substrate: your decision patterns, your judgment calls, your accumulated intelligence, the metrics your experts actually reason in. Surfacing that and shaping it into something an AI can ground on is what Orbital's Map phase produces.
Start With A Map
If CTI is the kind of system you'd like running on your business's expertise — or if you're already building one and want a second pair of hands that has shipped this exact architecture before — the place to start is a Map engagement. We surface the operational intelligence in your business, identify where AI has genuine leverage, and produce a concrete plan.
You walk away with clarity, whether or not we keep working together.
Email: info@orbital.co.nz