REAL-WORLD PERSONAL AI SYSTEM
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.
Training, recovery, nutrition, calendar and subjective observations.
Decisions and reusable workflows instead of another screen of metrics.
CASE STUDIES
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.
PERSÖNLICHE LAUFGESCHICHTE · ISARLAUF 2026
2024 waren zehn Kilometer unter 4:30 min/km eine harte Nummer. Knapp zwei Jahre später beim Halbmarathon: noch Kraft für einen schnellen Schluss. Mit Fotos, Video und einem Blick auf die zwei Jahre dazwischen.
Die Geschichte lesenCROSS-SOURCE WORKFLOW
Ten previous reports plus LiftTrack, freddy, Google Calendar and Airtable become one structured weekly review and write-back.
Read case studyDECISION SUPPORT
Recovery, strength history, subjective context and calendar constraints are combined before one training recommendation is made.
Read case studyNEGATIVE ACTION
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
Fast conversational capture is separated from later reconciliation, timestamp checks and durable storage.
Read case studyWORKOUT REVIEW
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
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
Two valid activity records were linked by an unsupported chronology because connector return order was mistaken for time order.
Read failure caseLONGITUDINAL CONTEXT
Three years of repeated weight, recovery and sleep data show why a higher scale number did not automatically justify renewed restriction or tracking.
Read case studyCALIBRATED DECISION SUPPORT
Garmin forecast 4:24/km. The runner considered sub-1:30. Context and uncertainty were turned into controlled execution — followed by an official 1:33:03.8 finish.
Read case studyA CENTRAL INTEGRATION LAYER
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
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
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
Real-world use has shown that connector status, ingestion state and metric-level freshness can disagree. The important question is not just whether a source says “connected”, but whether the specific data needed for a decision are actually current and complete.
REAL-WORLD RELIABILITY CASE
Runalyze and Intervals.icu have provided useful examples of why connector status and data freshness must be treated separately. A source can be connected and actively syncing while profile-level coverage metadata, individual metric families and the underlying source are not perfectly aligned. Product capabilities also evolve over time, so historical sync incidents remain provenance rather than a permanent description of current availability.
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
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
ACCESS & MEMORY
REASONING
WHY THIS PROJECT EXISTS
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
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. Since October 2026, a separate prospective episode ledger also captures observable substantive interactions — including failures and maintenance — without asking for extra study-specific logging. If and when I turn the accumulated evidence into a formal publication, the study/manuscript state will be frozen from that reviewed evidence.
BUILD IN PUBLIC
Shorter examples, running and practical Personal AI OS workflows.
Instagram ↗TOOLS
The devices, apps and training tools actually used in the system.
Explore the stackCOLLABORATION
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
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.