VitaSide - a health sidecar that keeps its claims on a leash
A local-first MCP product for personal patterns and doctor-visit preparation. Its hard feature is not an AI answer. It is the chain from observation to uncertainty to dated source - and the refusal to speak when that chain is missing.
- Filed under
- Case study · VitaSide
- Published
- Language
- EN
- Reading time
- 9 min
- Version
- v0.10.0
The answer was never the product
Personal health exports produce a familiar temptation. Put sleep, stress, notes and wearable data into an AI system, ask why something happened, and let fluent prose close the gap between an observation and a cause.
VitaSide was designed to keep that gap open.
It is a local-first MCP sidecar for people organising their own longitudinal data before a conversation with a clinician. The system can calculate personal baselines, compare dated periods, look for lagged associations and assemble a visit packet. It cannot diagnose, prescribe, validate a medical intervention or turn an N-of-1 association into a forecast.
The product decision was to make evidence discipline part of the interface rather than a disclaimer appended after generation.
VitaSide
Five dated nights fall below the personal baseline.
Support and uncertainty remain attached to the association.
The report points back to the source period instead of inventing a cause.
What shipped for the defined scope
The current implementation is more than a research document. The repository contains:
- a Python MCP application with personal-baseline, historical-comparison, condition-tracking and visit-packet tools;
- a local FastAPI delivery layer and React dashboard;
- a manifest-scoped sidecar protocol with tool allowlists, TTL, revocation and audit metadata;
- a SQLite longitudinal store with versioned migration and idempotent writes;
- optional Omi, Apple Health, FHIR, Frame and doctor-device adapters with deterministic fallbacks;
- an evidence-to-action loop that begins only from a dated, readable excerpt;
- a field-pilot protocol that stores consent and progress locally and exports only a de-identified completion proof.
The default path runs without cloud inference. Optional Azure operations require explicit consent and a minimised payload contract. Raw health notes and filesystem paths are rejected from that outbound shape.
The architecture follows the claim
A health feature can sound private while quietly moving its most sensitive step into a general agent prompt. VitaSide avoids that by separating roles.
The raw export remains user-owned. Normalised observations enter a local longitudinal store. Statistical modules calculate comparisons without importing the web server, MCP transport or cloud adapters. The application layer orchestrates those modules. The host agent receives a bounded result with evidence semantics rather than an unrestricted view of the vault.
That boundary is tested as architecture, not left as a diagram. Eight domain and statistical modules are checked for forbidden delivery and adapter imports.
The result is intentionally boring in one important way: if a source is absent, a citation is not improvised. If the comparison lacks support, the output says so. If an optional adapter fails, the local path continues.
Statistics before narrative
The strongest product correction happened around the language of prediction.
An early public tool name, simulate_whatif, remains for compatibility. The versioned schema no longer treats its result as a forecast. It returns historical contrasts: what followed one observed condition in the available record versus another.
The statistical layer exposes the counts behind the comparison. It uses uncertainty intervals, Fisher exact tests where appropriate, minimum support and Benjamini-Hochberg false-discovery-rate adjustment. Reports use absolute percentage-point differences and evidence grades instead of a sentence such as “better sleep will improve mood by 23%.”
That is not just scientific caution. It changes what a user can do next. A dated association can become a question for a clinician or a small observation plan. A fabricated causal number can become a medical decision it never earned.
Verification is software evidence, not clinical evidence
A clean-install verification recorded on 2026-07-15 (see the public production-readiness review). Later CI may change exact counts; the dated review is the claim here:
Python unit and integration tests 101 passed
UI tests 21 passed
Application coverage 80%
Acceptance and OpenAPI contracts passed
Local API / UI smoke passed
MCP self-test passed
Those gates support a release decision for local, single-user, non-diagnostic visit-preparation software. They do not establish medical usefulness or population validity.
The production-readiness review says this explicitly. A public-network, multi-user, diagnostic or regulated deployment would require a new threat model, identity and tenancy controls, clinical validation and a regulatory quality programme.
The current status record also keeps fixture proof separate from field evidence. The scripted three-user, fourteen-day pilot has a verifier, but real participant completion remains pending. Three generated folders cannot be promoted into three patients because the test suite is green.
The interface is a boundary viewer
The local dashboard is not designed as a wellness score. It shows where a signal came from, how much support it has and what is still unknown.
A useful sequence is:
- Observation: several dated sleep windows fall below the person's own baseline.
- Comparison: stress notes appear more frequently in a defined following window.
- Uncertainty: support, interval and multiple-comparison handling remain visible.
- Provenance: the report links back to the exact dates and excerpts.
- Action boundary: the system suggests a question or observation, not a diagnosis or treatment change.
The visit packet then compresses the useful part: trends, problem list, dated patterns and questions worth bringing into the room. Raw transcripts do not need to become the report.
What I was responsible for
I set the product boundary, chose the sidecar architecture, defined the evidence and privacy gates, and orchestrated a large AI-agent build and review process. Agents wrote substantial code, tests and documentation. My work was to keep the system from optimising the wrong thing: a more confident answer at the cost of a less inspectable claim.
This distinction is included because “built with AI” can conceal both authorship and failure modes. The implementation speed came from agents. The product judgment was deciding what those agents were not allowed to claim.
What remains unresolved
The next useful evidence is not another module.
It is the field pilot: can three real people configure the local product, understand the provenance, prepare a useful visit packet and rate the result without exposing their health data? Hardware-in-the-loop checks for Frame and Omi also remain outside the core offline gate. Public or multi-user operation remains out of scope.
Until those gates are crossed, VitaSide is a technically verified local product with an unverified real-user usefulness claim.
That sentence is the case study.