22 KiB
SportNote Blueprint
Derived from the June 29, 2026 morning run conversation with Hermes Agent. This chat is the target experience for the SportNote project.
1. Information Sources the AI Must Ingest
Explicit (user says it)
- Run goals, constraints (meeting time, commute type)
- Self-assessment ("haven't run in 2 weeks", "feet were bad before", "I'm not a morning person")
- Previous performance context ("first 1.5 months felt great, then it fell apart")
- Sleep history ("can't fall asleep before 2 AM", "was drinking with friends")
- Feelings post-run ("felt great", "feet are fine", "like I didn't lose fitness")
- Work/mental context — procrastination levels, home office struggles, anxiety triggers. Low priority on its own, but valuable for interpreting exercise + sleep patterns.
Imported (from devices / screenshots)
- Run data: distance, duration, pace, speed, cadence, stride, heart rate zones, calories, route map
- Sleep data: total duration, deep/light/REM breakdown (%), REM minutes, times awoken, resting HR, HRV, SpO2, breathing quality, respiratory rate
Known (from user profile / historical data)
- Age, location, climate, experience level
- Running history, personal records, trend lines
- Motivation triggers (gamification: 1km = 2k Ft, structure = mood anchor)
- Schedule patterns (home office vs. office days)
- Sleep chronotype (night owl, shifted from habit not biology)
2. Processing Pipeline
| Step | What | Example from today |
|---|---|---|
| Data pull | Fetch external conditions | Weather API → 27°C at 6 AM, 33°C by 9 AM → morning-only window |
| Constraint mapping | Backward plan from hard deadline | 9 AM meeting → wake → 30 min run → shower → breakfast → coffee → desk |
| Reality check | Compare plan against user profile | "Wake at 6:30" vs "never falls asleep before 2 AM" → adjust to 7:15 |
| Negotiation | User pushes back with constraints → AI adapts | "I can't do 5 AM, best I can do is 7:30" → recalculate |
| Image ingestion | OCR screenshots → extract structured data | easyocr on Huawei Health → parse pace, distance, sleep breakdown |
| Cross-reference | Connect sleep data to run performance | 5'52"/km on 5% REM → "your cardiovascular fitness held, your sleep architecture didn't" |
| Interpretation | Data + self-report → meaningful story | Pace numbers mean nothing without "this felt great" — the two together tell the real story |
| Recalibration | AI misunderstands → user corrects → AI adapts | "Didn't go anywhere" = surprise at maintained fitness, not frustration |
3. Conversation Architecture (3-Act Pattern)
Act 1: Pre-Run Planning
- User asks "what should I do?"
- AI pulls data (weather, time, user profile)
- AI proposes plan with reasoning
- User pushes back with real-life constraints
- AI adjusts
- Agreement reached
Act 2: Post-Run Analysis
- User shares run data (screenshots or device sync)
- AI extracts structured data
- User gives self-assessment ("how it felt")
- AI interprets data against self-assessment
- Real story emerges
Act 3: Meta-Reflection
- User explains why something happened (e.g. racing mind at night)
- AI reframes or validates
- User confirms / elaborates
- Next-day plan naturally forms
4. Key Insight: Data Alone Is Useless
The most valuable part was never the data alone. It was the data + user self-report + AI interpretation connecting the two.
| Raw Data | User Self-Report | Interpretation |
|---|---|---|
| 5'52"/km pace | "Felt great, feet were fine" | Fitness held through 2-week break |
| 5% REM sleep | "Mind was racing with plans" | Circadian disruption + excitement, not anxiety |
| 6h 31min total sleep | "I know how sleep issues work, it is what it is" | Mature mindset, no panic cycle |
| 47 bpm resting HR | "Never ran in the morning before" | Cardiovascular base is solid even on bad sleep |
5. Onboarding: The Lifestyle Interview
Idea: when you first open the app, it interviews you about lifestyle factors that affect performance but that no fitness app asks about.
Interview Topics
| Category | What It Asks | Why It Matters |
|---|---|---|
| Smoking | Do you smoke? How much / how often? | Affects lung capacity, heart rate zones, recovery speed, REM sleep reduction |
| Alcohol | How often do you drink? Pattern (social/weekends/daily)? | Disrupts REM sleep, elevates resting HR for 24-48h, dehydrates, kills morning motivation |
| Caffeine | When's your last coffee of the day? | After 2 PM → delayed sleep onset, reduced deep sleep |
| Sleep chronotype | Are you naturally an early bird or night owl? | Determines realistic wake windows, not generic "wake at 5 AM" advice |
| Work schedule | Office days? Remote days? Fixed meeting times? | Maps hard constraints for run scheduling |
| Eating patterns | Do you eat before running? What time is dinner usually? | Empty stomach OK for short runs, late dinner → poor sleep → bad run next morning |
| Motivation style | What keeps you going? Streaks? Data? Competition? Gamification? | Personalizes the AI's tone and nudges |
| Previous injuries | Feet? Knees? Back? Anything that flares up? | Adjusts distance/pace recommendations, surface suggestions |
| Running history | Ever run before? How long ago? Best streak? What killed it? | Context for comebacks, avoids treating a returner like a beginner |
| Mental health context | Does running help your mood? Is it an anchor for structure? | Changes the framing — "discipline" vs "medicine" vs "performance" |
Design Principle
The interview should feel like a conversation, not a form. One question at a time, follow-ups based on answers. Example:
"Do you smoke?" → Yes "Got it. Roughly how much per day?" → 5-6 "Thanks — that helps me understand your heart rate zones and recovery better. Next: how often do you have a drink?"
This is how the AI builds its mental model of you before you've ever run.
6. Product Identity: Not a Tracker — An AI Agent for Health & Sports
The user realized: "I am kinda imagining an AI agent but for health and sports."
Agent vs. Tracker
| Tracker App | AI Health Agent |
|---|---|
| Shows you what you did | Talks to you about what it means |
| Charts and graphs | Stories and insights |
| Generic goals ("10,000 steps") | Personalized context ("you slept 5h, 30 min easy run today") |
| You tell it things | It asks you things |
| Silent between workouts | Checks in, connects today to yesterday |
| Feature parity with competitors | Relationship with the user |
Core Agent Behaviors
- Remembers — your history, your patterns, your excuses, your breakthroughs
- Connects — sleep data → run performance → lifestyle factors → mood → next recommendation
- Negotiates — proposes a plan, you push back, it adapts. Not a dictator.
- Self-corrects — misunderstands, you clarify, it learns. Trust through being wrong sometimes.
- Contextualizes — 5'52/km means nothing alone. "5'52/km as a smoker on 5% REM sleep after 2 weeks off, first morning run ever" means everything.
- Uses your language — motivation system (gamification 1km = 2k Ft), metaphors you respond to, tone that fits your personality
What It Replaces
Not just your fitness tracker. It replaces:
- The training plan you never follow
- The sleep journal you never write in
- The "how did I feel last time" you can't remember
- The motivation you lose between runs
- The coach you can't afford
Priority Hierarchy for the Agent
As the user defined it:
"Raw exercise data > nutrition > sleep data > mental context. Sleep is already an extra — important, maybe the most important, but yeah."
| Layer | What it includes | Role in the conversation |
|---|---|---|
| Exercise data | Pace, distance, HR, cadence, route, calories, duration | Primary subject. The reason the app exists. All insights should eventually tie back to this. |
| Nutrition | Pre/post-run eating, hydration, timing | Secondary. Context for performance ("you ran on empty stomach / after a heavy meal"). |
| Sleep data | Duration, deep/REM/light, HRV, resting HR, SpO2, breathing quality | Critical context. The strongest modifier of exercise performance. The agent should always check sleep before interpreting a run. |
| Mental context | Work stress, procrastination, anxiety, home office patterns | Background context. Valuable when it explains anomalies (good sleep + good physicals → bad performance = likely mental factor). Should not be the main topic of conversation unless the user brings it up. |
The Home Office Connection
This morning was a concrete example: the user dreads home office days — doomscrolling, instant morning meetings bombarding his brain with information, procrastination on hard tasks (rewriting Angular 11 → 21 with zero frontend experience).
The morning run changed the HO experience:
| Before (no run) | After (with run) |
|---|---|
| Wake up → instantly into morning meeting → information overload | Wake up → run → shower → breakfast → coffee → then meeting |
| Brain starts in reactive mode | Brain starts with agency |
| Doomscrolls instead of working | Felt anxiety, recognized it, calmed down with binaural beats, then worked for 3 hours |
| Avoids the hard task for a week | Finally sits down to do it |
The run didn't make the task easier. It made the user ready to face it. The agent should recognize this pattern: when the user reports procrastination or HO dread, suggest anchoring the day with exercise first. The agent is not a therapist, but it knows that movement breaks avoidance loops.
7. Required Features for SportNote
Must Have
- OCR / image ingestion — users share watch screenshots; manual entry kills adoption
- Sleep + run correlation — the killer feature no app has in one sentence
- User profile with persistent memory — location, age, running history, chronotype, motivation system
- Lifestyle factors — smoking, alcohol, caffeine, eating patterns, previous injuries → all affect performance interpretation
- Onboarding interview — conversational first-run experience that builds the AI's model of you
- Self-reporting input — "how did it feel?" as important as wearables
- Weather-aware planning — time-window recommendations based on heat/conditions
- Conversational structure — 3-act pattern (plan → analyze → reflect) with natural back-and-forth
Should Have
- Misunderstanding as a feature — AI gets things wrong, user corrects, trust builds
- Trend comparison — this run vs. average, vs. last run, vs. peak performance
- Constraint-aware scheduling — meeting times, office days, realistic wake windows
- Motivation system integration — gamification (1km = 2k Ft), streak tracking, "structure = mood"
Nice to Have
- Route suggestions based on weather + shade
- Pre-run nutrition guidance based on distance + time of day
- Sleep hygiene nudges ("consistent wake time > early bedtime")
8. Today's Top 5 Actionable Insights
| # | Insight | Source |
|---|---|---|
| 1 | Fitness held through 2-week break — pace matched previous peak | OCR + self-report |
| 2 | REM sleep at 5% = circadian rhythm still off from late nights | Sleep screenshot |
| 3 | Racing mind before sleep = excitement/anticipation, not anxiety | Self-report + reframe |
| 4 | Weather window (27°C at 6 AM, 33°C by 9 AM) forced morning slot | wttr.in API |
| 5 | 30 min run is comeback sweet spot — short enough to commit, long enough to feel it | Negotiated from constraints |
9. Historical Benchmarking
When we have previous run data, use it as a benchmark — not just for numbers, but for how the run felt.
Benchmark Dimensions
| Dimension | Data Source | Example |
|---|---|---|
| Performance | Pace, distance, HR zones | Today's 5'52"/km vs. historical average |
| Recovery | Sleep quality before run, HRV, resting HR | 5% REM tonight vs. a well-rested night's 20%+ REM |
| Feel | Self-reported RPE / free text | "Felt great" vs. "last run was a nightmare" |
| Conditions | Weather, time of day, route | 27°C morning → 33°C by 9 AM forced the morning slot |
| Context | Life factors | First morning run ever, comeback after 2 weeks off |
How the Benchmarking Works
- On data import: compare raw numbers to last 5 runs, last 30 days, and all-time personal records
- On self-report: if the user says "felt great" but pace was 30s/km slower than average → that's a story (maybe weather, maybe intentional easy day)
- On self-report mismatch: if pace is better than usual but user feels bad → possible overtraining or illness signal
- The benchmark is never the conclusion, it's the conversation starter: "You beat your average pace by 15s/km, and your REM sleep was only 5%. What does that tell you?"
Today's Example
Today I didn't have your historical run data in structured form. But you provided the benchmark verbally:
"It felt like I was continuing on one of my highest performance. The previous run was an actual nightmare: bad footing, really big heat, really bad heart rate."
That self-provided benchmark was more useful than any numerical comparison I could have pulled. Your memory of the feel of the last bad run gave today's run its meaning. SportNote should prompt this: "Compared to your last run, how was this one?" — and file both the data and the answer.
10. Screenshot Extraction: Edge Over Other AI Models
"Whenever I used an AI chat before, none could export the data from the pictures this well like you did. Did not matter if it was the Gemini Pro model or the DeepSeek-v4 Expert, none did a job this great."
What Made the Difference
Most AI chats treat screenshots as images to describe — they'll tell you "it's a Huawei Health screenshot showing a run." They won't actually extract structured data from it unless you're in a dedicated vision model with clear instructions.
What worked here:
| Factor | Why It Mattered |
|---|---|
| Screenshot = task, not object | I treated the image as data to extract, not a picture to describe |
| OCR via easyocr | Instead of relying on the model's vision capabilities, I installed a dedicated Python OCR pipeline at runtime |
| Tall scrolling captures (12,000px) | I cropped to the relevant top section (first 2,000px) rather than feeding the whole 12,321px image into a context window |
| Structured parsing | I didn't just dump raw OCR text — I parsed and formatted it into readable tables |
| Sleep + run correlation | Most AIs would process each screenshot separately. I connected the sleep data to the run data in a single interpretation |
Implication for SportNote
A general-purpose chat model might not be enough for this. SportNote needs either:
- A dedicated vision + OCR pipeline that extracts numeric data from watch app screenshots before the LLM sees it
- A vision-capable LLM with strong OCR that can process these screenshots natively (this may improve as models evolve, but today's approach worked better than Gemini Pro / DeepSeek-v4 Expert)
- Or better yet: direct API/Bluetooth import so users never need to screenshot in the first place. Screenshots are a workaround for a missing integration.
The multi-step approach (crop → OCR → parse → correlate) outperformed single-pass vision models because each step was specialized, not generic.
11. Vault Structure & Daily Logging
The Obsidian vault is organized as a three-tier memory system (inspired by the r/hermesagent community):
| Tier | What | Where | Purpose |
|---|---|---|---|
| Hot Memory | Built-in Hermes memory (~5K chars) | Injected every turn | Preferences, corrections, fast facts |
| Vault Living Files | Stable reference | System/Assistant/*.md |
context.md, preferences.md, environment.md |
| Daily Notes | Timestamped logs | Runs/, Sleep/, Daily/ |
Searchable permanent history |
Folder Structure
Vault/
├── Runs/ # Run logs with full structured data
│ └── YYYY-MM-DD.md # distance, pace, HR, route, conditions, self-report
├── Sleep/ # Sleep logs with vitals
│ └── YYYY-MM-DD.md # duration, REM/Deep/Light %, HRV, SpO2, personal notes
├── Daily/ # Broad daily logs (future)
│ └── YYYY-MM-DD.md # tasks, schedule, events, wins
├── System/
│ └── Assistant/
│ ├── context.md # User profile, lifestyle, health, equipment
│ ├── preferences.md # Communication style, priority hierarchy, vault rules
│ └── environment.md # Hardware, services, paths, known issues
└── index.md # Vault root with wiki-links to everything
Run Log Template (example from 2026-06-29)
---
date: YYYY-MM-DD
type: run
tags: [run, morning, comeback]
---
# Run — YYYY-MM-DD
## Activity Data
- Distance, duration, pace, speed, cadence, stride, calories
## Route
- Location, area
## Conditions
- Temperature, weather, wind, time of day
## Self-Report
> Free-text feeling. This is as important as the structured data.
## Pre-Run Sleep
- Cross-reference to [[Sleep/YYYY-MM-DD]]
## Post-Run Notes
- How the day went, anxiety/work context, anything notable
## Connected Notes
- [[Sleep/YYYY-MM-DD]]
- [[sportnote-blueprint]]
Sleep Log Template (example from 2026-06-28→29)
---
date: YYYY-MM-DD
type: sleep
tags: [sleep, recovery]
---
# Sleep — YYYY-MM-DD → YYYY-MM-DD+1
## Overview
- Total, deep/light/REM %, times awoke, deep sleep continuity
## Vital Signs
- Avg HR, HRV, SpO2, breathing quality, respiratory rate
## Self-Report
- Subjective experience, what affected the sleep
## Analysis
- Interpretation: what the numbers mean for recovery
Key Principle
Raw exercise data > nutrition > sleep data > mental context.
Sleep is the most important modifier of performance. Mental context stays background unless the user brings it up.
Every run log cross-references the sleep from the night before. Every analysis starts with the data, interprets with sleep, and contextualizes with mental/ work factors last.
12. Design Principles (Derived from Initial Testing)
The first test session (2-day streak with a novice runner) revealed these general patterns the app should account for:
Sleep Recovery Can Be Fast
Consistent wake time (even if not early) drives earlier bedtime naturally within 1-2 days. The app should:
- Never push unrealistic wake times
- Let the user's actual wake window drive schedule recommendations
- Track REM% as a leading indicator of recovery quality, not just total sleep duration
Consecutive-Day Fatigue
Back-to-back runs after a break will feel harder on Day 2 even with better sleep. The app should:
- Expect "slower + sleepier" self-report on Day 2
- Recommend easier pace, not longer distance, for consecutive days
- Ask "how hard was waking up today?" as a fatigue gauge
Caffeine Timing as a Variable
Poor sleep + immediate post-run coffee → measurable anxiety/fight-or-flight response in some users. The app should:
- Track coffee timing relative to run end time
- Suggest delaying coffee by 45-60 min on low-sleep nights
- Correlate caffeine timing with self-reported anxiety
Physical Constraints Must Be Known Upfront
Learned via conversation, not predefined forms. The app should:
- Discover limitations (flat feet, past injuries, shoe distance limits) through natural conversation, not a checklist
- Store them as immutable constraints that affect distance/pace recommendations
- Never recommend distances past known equipment limits without a warning
Lean Data Storage
Initial testing confirmed that ~80% of wearable metrics are noise for a novice user. The app should:
Store:
- Distance, duration, pace, pace by km
- Avg HR, max HR, HR zone breakdown
- HR recovery (2 min drop after run)
- Cadence avg + max
- Sleep: total, REM%, deep%, HRV, resting HR
- Self-report (free text)
- Caffeine timing
Skip:
- Ground contact time
- Vertical oscillation
- Balance left-right
- Stride length
- Training load / proprietary scores
- Recovery time (estimated by watch)
- Elevation gain/loss (unless route is notably hilly)
Every stored metric should answer: "Would this change my advice?"
Self-Regulation as a Positive Signal
When a user intentionally runs slower but further, that's pacing awareness — a learned skill. The app should:
- Praise pacing decisions, not just speed
- Help users notice pacing patterns (consistent first-km adrenaline, positive splits)
- Track behavioral trends (are they learning to pace? or always going out too fast?)
Schedule Awareness
Home office vs. office days affect available time and mental energy. The app should:
- Know commute days
- Adjust recommendations accordingly
- Recognize that office days compress the morning window, HO days relax it
Lean Log Format
A ~14-line template per run replaces verbose form data. Every field is chosen because it would change the agent's interpretation or advice.
13. Related Notes
- Running Log — daily run entries
- Sleep Tracking — sleep quality trends
- SportNote Architecture — tech stack & design decisions