CROSS-SOURCE WORKFLOW
One request. Four systems. One weekly review.
Ten previous reports plus LiftTrack, freddy, Google Calendar and Airtable become one structured weekly review and write-back.
Read case studyREAL-WORLD PERSONAL AI SYSTEM
Personal AI OS
Your data. One context. Better decisions.
I use a conversational AI layer to connect specialist tools that already work — wearables, training apps, structured memory and real-life context — without replacing them with another dashboard.
This site is the public reference for the project: how the system is built, what it actually does, where integrations fail, and the real workflows that are worth keeping.
Context
Training, recovery, nutrition, calendar and subjective observations.
Output
Decisions and reusable workflows instead of another screen of metrics.
CASE STUDIES
What does it actually do?
Documented workflows from the real system — including the cases that save time, the cases that combine multiple sources, and the cases where the AI gets something subtly wrong.
DECISION SUPPORT
“Should I run today?”
Recovery, strength history, subjective context and calendar constraints are combined before one training recommendation is made.
Read case studyNEGATIVE ACTION
Sometimes the useful answer is no workout.
The system should be able to recommend less when recent load and upcoming quality work make another structured session unattractive.
Read case studyLOW-FRICTION DATA CAPTURE
Raw Log → daily QC → curated Journal.
Fast text, voice and image capture is separated from slower reconciliation, timestamp checks and durable storage.
Read case studyWORKOUT REVIEW
Does this workout fit my week?
A planned Push workout is checked against training history, recovery, calendar and journal context, then translated into concrete execution guidance.
Read case studyMINIMUM SUFFICIENT CONTEXT
Sometimes one connected app is enough.
LiftTrack’s exercise catalogue plus real equipment context was enough to create executable Push A/B templates — and to correct a movement that did not fit the actual bench.
Read case studyFAILURE CASE · PROVENANCE
Correct facts can still produce a wrong story.
Two valid activity records were linked by an unsupported chronology because connector return order was mistaken for time order.
Read failure caseA CENTRAL INTEGRATION LAYER
Why freddy plays a central role.
My Personal AI OS needs a reliable way to make longitudinal health and training data available inside the conversation. In the current setup, freddy is the main quantitative access layer doing that job.
CONNECTED SOURCES
Multiple systems, one query surface.
Garmin Connect, Apple Health, Intervals.icu and Runalyze are currently connected through freddy. That gives the conversational layer access to recovery, sleep, training, activity and other longitudinal metrics without rebuilding those source systems.
ROLE IN THE OS
Access layer, not replacement.
Garmin, Runalyze and Intervals.icu keep doing their specialist jobs. freddy makes the relevant records queryable from the AI conversation and exposes enough source context to support cross-domain reasoning.
WHY RELIABILITY MATTERS
Integration failures are part of the real system.
Runalyze import behavior has been an active real-world reliability case. The important distinction is not just whether a connector says “connected”, but whether the metrics needed for a decision are actually current and complete.
REAL-WORLD RELIABILITY CASE
Runalyze has been a useful example of why connector status and data freshness must be treated separately. During the integration period, freddy could report the source as connected while metric families were still being imported or lagged behind the underlying source. By 21 September 2026, 89 Runalyze metrics were exposed and major activity and recovery families were current through 20 September, while freddy still reported the sync as in progress.
Operating rule: before a current decision depends on a connector, check the freshness of the metrics actually being used — not just whether the connector is green.
ARCHITECTURE
Specialist tools stay specialist. Context gets connected.
The system is a loop rather than one app. Measurement stays close to the tools that are good at it; the AI layer connects enough context to answer better questions.
CAPTURE & SPECIALIST TOOLS
Garmin Fenix 8 + CIRQATraining execution, sleep, recovery and continuous signals
LiftTrackStrength templates, exercise catalogue and workout history
Runalyze + Intervals.icuEndurance analysis and derived training context
Calendar + Raw LogReal-life constraints and information sensors cannot know
ACCESS & MEMORY
freddyMain quantitative health/training access layer across connected services
Airtable JournalCurated durable context after daily reconciliation
Google Calendar + Airtable connectorsDeliberate read/write actions where useful
REASONING
ChatGPT / conversational AIRetrieves relevant context, reconciles differences and turns it into one answer
OutcomeTraining decisions, weekly reviews, rest, structured logging and reusable workflows
WHY THIS PROJECT EXISTS
The problem is not a lack of data.
The useful information already exists across wearables, training apps, calendars, notes and structured logs. The hard part is knowing which pieces matter together for the question being asked.
The value is not another place to look at data. It is having enough context to ask — and answer — a better question.
ABOUT
Hi, I’m Alex.
I am a scientist, runner and the person building and using Personal AI OS. I document the system publicly because real examples are more useful than abstract AI claims — including the parts that break.
The research side is maintained continuously in a structured Research Log. If and when I turn the accumulated evidence into a formal publication, the study/manuscript state will be frozen from that reviewed evidence rather than maintaining a second parallel research registry.
BUILD IN PUBLIC
Prompt & Perform
Shorter examples, running and practical Personal AI OS workflows.
Instagram ↗TOOLS
My real stack
The devices, apps and training tools actually used in the system.
Explore the stackCOLLABORATION
Integration and methods conversations welcome.
I am particularly interested in interoperability, longitudinal personal data, training/health integrations and the failure modes that appear when these systems meet real life.
LIMITS
A practical project, not a clinical product.
Examples describe my own setup. AI-generated interpretations can be wrong. Health-related outputs are informational and decision-support only. Third-party services process data under their own terms, and integrations can change without notice.