The user's vision, captured verbatim (2026-06-22):
"Also an idea if for it to connect to you TARS, so you can know my health data and health status. I'm not sure how we would do this—and it's not a now feature, but something I'd like to think about now for later."
The user wants TARS (their personal AI agent, my role) to have awareness of their health status, so conversations with TARS can be contextually aware of how the user is feeling physically, how recovered they are, what their trends look like.
The problem it solves
TARS today has zero awareness of the user's physical state. A user who slept 4 hours, has a 2σ HRV drop, and is mid-training-block gets the same TARS experience as a user who is fully rested. The integration lets TARS:
Surface relevant health context proactively — "you slept 5h last night and your HRV is 1.5σ below baseline — should we keep this session short?"
Correlate health data with work output, mood, decisions — the cross-domain link the user already cares about (per 2026 06 17 cross domain podcast reading pattern)
Give more grounded answers to health questions — use the user's actual data, not generic advice
Catch patterns the user wouldn't see — "your last 3 hard conversations correlated with elevated resting HR the next day"
Parasym writes a daily health summary to ~/brain/inbox/health/ (or a dedicated path). The existing autopilot cron picks it up. TARS reads it via gbrain query, the same way it reads any other brain page.
Pros:
Minimal new code (Parasym already has CSV/JSON export; just adds a daily-summary file)
Reuses the existing sense→inbox→autopilot pattern
Privacy-preserving (file is on the user's disk, under user's control)
TARS gets low-frequency health signal (daily) — sufficient for the "context-aware conversation" use case
Cons:
Daily granularity only. TARS can't query "what's my HRV right now?" — only "what was my HRV yesterday?"
Requires the user to actually run the cron / open the app daily
The signal lag (24h) means TARS doesn't catch real-time changes
Option 2: MCP server exposed by Parasym (medium, v1.0+ candidate)
Parasym runs a local MCP server with tools like:
get_hrv_baseline(window: "30d") → current baseline + σ
get_recovery_score() → today's 0-100 score
query_hrv_window(start: ISO8601, end: ISO8601) → raw time series
get_today_summary() → narrative summary
get_hrr_recent(workout_id: string) → post-workout HRR data
TARS calls these in-conversation when contextually relevant. The MCP server runs on localhost (or over a local Unix socket), authenticated to the user's machine.
Pros:
Real-time access. TARS can query on demand.
Tools are discoverable, callable, with structured inputs/outputs
Cleanest developer experience for TARS — same MCP surface it uses for everything else
Could also be used by other local agents / automation
Cons:
Adds an MCP server surface to maintain
Requires Parasym to be running (or the MCP server to run as a daemon)
Battery cost if the MCP server is always-on (mitigated by on-demand activation)
Privacy implications: TARS can read any health data the user has — but that's the point
Significant engineering investment; not v0.3 material
Option 3: TARS has direct HealthKit access (simplest for the read path)
A new MCP tool read_healthkit that gives TARS direct HealthKit query access (read-only, no write). Bypasses Parasym entirely for simple queries.
Pros:
Zero coordination with Parasym
TARS works even if Parasym isn't installed
Standard HealthKit queries (RHR, HRV SDNN, sleep, weight, workouts)
Minimal engineering — just an MCP tool wrapper around HKHealthStore
Parasym pushes events to a log (e.g., ~/brain/health_events.jsonl) whenever something notable happens:
"HRV dropped 1.8σ" (with timestamp, baseline, current value)
"Recovery score dropped below 50" (with citation)
"3 days of declining RHR" (with trend data)
"Completed workout with HRR in 90th percentile" (with conditioning interpretation)
"Sleep < 6h for 3 consecutive nights" (with citation)
TARS subscribes via the existing sense→inbox→autopilot cron (or a new health-events-specific cron).
Pros:
TARS gets NARRATIVE events, not just data. "Your HRV dropped 1.8σ" is more useful than "your HRV is 42ms today"
Push model = TARS doesn't need to poll
Reuses sense→inbox→autopilot (the same pattern as the YouTube + Zotero sensors)
Event-driven, not periodic — catches anomalies immediately
Cons:
Requires Parasym to know what counts as a "notable event" — i.e., the insight engine is doing the selection
Risk of alert fatigue if not tuned (too many events → TARS learns to ignore them)
More engineering than Option 1 (event schema + serialization + cron)
The "what's notable" is a moving target as the insight engine matures
Recommendation
Option 1 for v0.3, Option 2 for v1.0+ if there's traction.
v0.3 (Option 1): Parasym writes a daily health summary to the brain. TARS gains low-frequency awareness with zero new infrastructure. This is the "see if I even use it" version. If the user finds TARS context-aware health valuable, the case for Option 2 is clear. If not, we've spent 2 days building it.
v1.0+ (Option 2): Parasym exposes an MCP server. TARS can query in real-time. This is the "TARS as a true health-aware companion" version. Saves to a v1.0+ decision because it requires the MCP server architecture to be stable and worth the maintenance cost.
Option 3 (direct HealthKit) is a viable fallback or complement but doesn't unlock the value of the chest strap data. Option 4 is the most ambitious but requires the insight engine to be mature first.
Why defer
The integration is not a v0.1 feature. The user's directive was explicit: "not a now feature, but something I'd like to think about now for later."
v0.1 has to ship the core insight engine before TARS can consume anything meaningful. The integration is the LAST thing, not the first.
Building the integration prematurely risks designing for a use case that the user doesn't actually need yet. The Option 1 v0.3 is the cheapest way to validate the concept.
TARS's value comes from being contextually aware, which requires a mature insight engine. Pre-mature integration is integration with the wrong surface.
Privacy boundaries (per-data-type configuration)
The user's preference (verbatim, 2026-06-22):"maybe the level of access can be configured in the settings page."
TARS's access to Parasym data is per-data-type, user-controlled in the Parasym settings page. Not a single on/off switch — each data category has its own toggle.
Proposed setting taxonomy (v0.3+):
| Data type | Default | Why | |---|---|---| | HRV (RMSSD + SDNN) | ON | Core insight; low-sensitivity, no privacy concern | | Resting HR | ON | Basic; no privacy concern | | Sleep stages + duration | ON | Core recovery context | | Workouts (HR + HRR + motion) | ON | Already a fitness app; expected sharing | | Recovery score | ON | Derived; safe to share | | Anomaly alerts | ON | Whole point of the integration | | Weight | OFF | User-specific privacy concern (body data) | | Body composition (if added) | OFF | Default-off for new sensitive categories | | Workout history with GPS (if added) | OFF | Location data — separate privacy tier |
Implementation pattern (v0.3+):
ParasymTARSAccess SwiftData model: dataType: String, enabled: Bool, lastUpdated: Date
All TARS queries are filtered through this access model — TARS never sees a category that's OFF, even if Parasym has the data
The access model is local; TARS queries it before serving data. No way for TARS to bypass it without modifying the app.
Default philosophy: sensitive data types default to OFF. The user opts in to sharing weight, GPS, body composition, etc. Core fitness + recovery data defaults to ON because that's the integration's purpose.
Defensive design: even when a category is ON, TARS never sees individual data points (e.g., "42.3 ms on Tuesday at 7:42am"). TARS sees insights (e.g., "your HRV is 1.5σ below your 30-day baseline"). The insight is the unit of sharing, not the raw value. (Subject to refinement when we get to v0.3 implementation — but the principle holds: minimize the surface area.)
TARS is aware but does NOT modify its own behavior
The user's preference (verbatim, 2026-06-22):"no, just aware."
TARS uses health context to inform content (what it says) but never to inform delivery (how it says it). TARS's tone, response length, formatting, and behavior are stable across the user's health state.
The design constraint:
TARS's voice/behavior is governed by the agent's own soul/persona, not by the user's physiological state
TARS can say "your HRV is 1.5σ below baseline — should we keep this session short?" but it does NOT shorten its response, adopt a more cautious tone, or otherwise adapt to the user's sleep state
TARS treats the user as a competent adult who can read a number and decide for themselves
Why this is the right call (per the agent-skills meta rule "push back when warranted" — applied to a meta-level design choice, not just a code decision):
Adaptive tone based on biometrics is paternalistic. The user didn't ask to be managed.
TARS's value comes from being a thinking companion with full context, not a coaching nanny
The pattern is consistent with the user's general philosophy (per hydrolyze feel direction playful v1): warmth through interaction design, not through clinical translation
Implementation guardrail (v0.3+):
The TARS context that includes health data is a data field in the system prompt, not a mode field
TARS's tone, response length, formatting are governed by other parts of the system prompt (the soul, the persona)
No code path in the agent loop should check health state and modify response style
A test or assertion: "regardless of HRV state, TARS's response to the same prompt is the same length and tone, modulo the health-context content it includes"
Health mention guardrails (citations + caveat on proactive mentions)
The user's preference (verbatim, 2026-06-22):"with is probably a good idea—or just put a caveat."
Translation: both citations AND a wellness caveat when TARS proactively surfaces health context.
Two contexts, two policies:
Reactive (user asks TARS about health)
When the user explicitly asks "what was my HRV this week?" or "am I overreaching?", TARS can answer directly. No mandatory caveat per message — the user is the one who initiated the health conversation. Citations still good practice (cite Joel / Galpin / etc.) but caveat is implicit (the user knows they're asking about health).
Proactive (TARS surfaces health without being asked)
When TARS brings up health context unprompted — "your sleep was 5h last night" or "your recovery score is 38 today" — TARS MUST include:
Citation — the source of the insight. The insight engine produces what + why + when + source citation as a structured data shape; TARS surfaces the citation in its message ("based on your 30-day baseline per Galpin's σ-deviation rule")
Wellness caveat — brief, non-clinical. Format options:
"Note: this is wellness insight, not medical advice"
"For anything medical, talk to a doctor — this is just data correlation"
A persistent footer-style caveat if TARS mentions health proactively more than once in a conversation
Why both, not either: citations establish credibility, the caveat manages liability. A user who gets a TARS proactive health mention should know (a) where the insight comes from and (b) that it's not a diagnosis. Either alone is incomplete.
Implementation (v0.3+):
The HealthEvent data structure (Option 4) and the DailySummary data structure (Option 1) both have a requires_caveat: Bool field
When TARS surfaces a HealthEvent proactively, the message generator includes both the citation and the caveat
Caveat text is configurable in settings (let the user choose "always caveat" / "only first mention" / "never caveat") — but the default is "always caveat on proactive mentions"
What the v0.1 architecture must accommodate NOW (cheap, no extra work)
Even though the integration is deferred, the v0.1 architecture should leave room for it. Specifically:
Data model is JSON-exportable — Parasym's data is already in SwiftData, but the v0.1 schema should be designed for easy JSON export (the "everything is JSON-friendly" rule from the CSV-export discipline)
Insight engine produces NARRATIVE outputs — every insight is a structured what + why + when + source citation, not just a number. This is the same data shape Option 4 would push to the events log
No proprietary locks on the insight logic — every insight has a public-domain basis (Joel, Galpin, Attia, Bu, medical literature). TARS doesn't need Parasym's code to interpret them; the citation is enough
Local-only data storage — no required cloud, so the integration layer can be entirely on-device
Decoupled insight engine — the engine outputs insights as data structures, not as UI. This means TARS can consume the same data structures the UI renders
Settings page architecture — the v0.1 settings page is the foundation for the v0.3 TARS access toggles. Build the settings surface with a SettingsSection / SettingsRow pattern that can absorb new sections without rewrite.
Defensive privacy by default — the v0.1 ParasymDataExport struct has the data types that could be sensitive flagged (weight, GPS) so the v0.3 toggle system has something to bind to from day 1.
Open design questions (status as of 2026-06-22)
Auth model for the MCP server (if Option 2 lands in v1.0+) — local-only, no auth? Or signed requests with a per-machine key? — DEFERRED to v1.0+ when Option 2 is built
Privacy boundaries — RESOLVED (2026-06-22): per-data-type configuration in settings page; sensitive categories default OFF; insights are the unit of sharing, not raw values
Bad-advice risk — RESOLVED (2026-06-22): citations on all health mentions + wellness caveat on proactive mentions; caveat is configurable in settings but defaults to "always caveat on proactive"
TARS modifying its own behavior based on health state — RESOLVED (2026-06-22): NO. TARS is aware, uses data in content, but does NOT adapt tone, length, or delivery based on health state. Behavior is stable; only content is context-aware.
Linked concepts
projects/parasym — the parent project (rev 2 scope)
people/joel jamieson — methodology source (TARS will eventually cite Joel)
hrv sdnn vs rmssd — the architecture foundation TARS would consume
2026 06 17 cross domain podcast reading pattern — the user's pattern of cross-domain resonance; TARS's value compounds with health context
hydrolyze feel direction playful v1 — the user's pattern of "warmth through interaction, not clinical translation"; reinforces the "TARS is aware, doesn't adapt behavior" choice
User preference signals (verbatim, 2026-06-22)
"Also an idea if for it to connect to you TARS, so you can know my health data and health status. I'm not sure how we would do this—and it's not a now feature, but something I'd like to think about now for later."
"1. maybe the level of access can be configured in the settings page."
"2. no, just aware."
"3. with is probably a good idea—or just put a caveat."