Every number here was made, not taken.
SEVN Vital contains no real health information: nothing anonymised, de-identified or borrowed. Every observation is generated by code from a fixed seed, so it is identical for every visitor and traceable to its source line.
How the data is made
1,925 synthetic observations across three fictional adults (Ava: 724 · Malik: 519 · Ruth: 682), covering 1 July – 28 September 2026.
A storyline per persona
Each persona has a short written storyline: a launch that shortens sleep, a new walking routine, two weeks away from home. The storyline sets a curated 0–100 sample score for each dimension on each day.
Seeded randomness
A seeded pseudo-random generator (mulberry32, seeded from the persona’s key) adds gentle day-to-day wander. Same seed, same numbers, on every device, every day.
Measurements in real units
Steps, minutes, hours, %, ms, bpm, mmHg, mmol/L and cm are generated around each persona’s own fictional baseline, so they move with the storyline. They are plausible-looking, not representative of any population.
Deliberate gaps
Sources go quiet on purpose: a wearable left on the charger, a cuff left at home, a habits log abandoned, pathology results months apart. Gaps are what make missing-data rules testable.
Snapshots link back
Every daily dimension snapshot lists the IDs of the observations recorded that day. That link is what lets each summary sentence cite its evidence.
What a record looks like
Units and dates are always explicit, and every record carries synthetic: true.
{
"id": "ava-steps-2026-09-19",
"profileId": "ava",
"metric": "steps",
"dim": "movement",
"value": 15910,
"unit": "steps/day",
"day": 80,
"date": "2026-09-19",
"source": "wearable",
"synthetic": true
}{
"id": "ava-movement-snap-2026-09-19",
"dim": "movement",
"day": 80,
"score": 79.1,
"evidence": [
"ava-steps-2026-09-19",
"ava-active_minutes-2026-09-19"
],
"available": true
}| Entity | Essential fields | Note |
|---|---|---|
| DemoProfile | id, persona_key, fictional_name, age | Synthetic only |
| Observation | id, metric, value, unit, date, source, synthetic | Units and dates explicit |
| DimensionSnapshot | id, dimension, day, sample_score, evidence[] | Curated score, not a medical ranking |
| IndexDefinition | version, weights, availability_rule, method_text | Versioned method |
| Scenario | id, hypothetical_inputs, result | Never overwrites observations |
| Summary | id, sentences[], evidence_map, method_version | Every sentence cites records |
The personas
Ava, Malik and Ruth are invented. Their names, ages, jobs and measurements belong to no one. Any resemblance to a real person is coincidental.
Ava, 34
Runner; August launch; six-day wearable gap; metabolic results from July only (stale).
Malik, 52
Walking routine from late July; home BP twice weekly; nutrition never logged (missing).
Ruth, 67
Steady routines; two-week trip without devices; habits log ends 11 September.
What this site stores
The public pages store nothing about you. There are no forms, no accounts and no analytics events that contain health values.
The profile explorer keeps your demo settings, weights, freshness window, scenarios and generated summaries, in your own browser’s local storage, so they survive a page refresh. That workspace resets to its baseline every day at 03:00 Sydney time, or whenever you press Reset now. Nothing is uploaded. Downloads are created in your browser from the synthetic data.
Anything that looks like sending, for example, sharing a summary with a clinician, is simulated and appears only in the demo outbox.
What a real product would need
Turning this concept into something that handles real people’s health information is a separate, much larger piece of work. At a minimum it would need:
Consent you can read
Explicit, specific, revocable consent for each source and each use, written in plain language, and a real way to see, export and delete everything.
Privacy assessment
Health information is sensitive information under Australian privacy law. A real product would need a privacy impact assessment against the Privacy Act 1988 and the Australian Privacy Principles, plus legal review.
Regulatory review
Any feature that interprets measurements could bring software within medical-device regulation. A real product would need a TGA regulatory assessment before launch, this concept has had none.
Validated criteria
Converting real biomarkers into scores needs agreed, clinically validated criteria. Until those exist, real measurements should be shown as measurements, never normalised into health scores.
Security by default
Encryption in transit and at rest, strict access controls with per-record ownership checks, audit logs, data minimisation and Australian data residency where possible.
Checked explanations
AI-written summaries validated against the source records, with every sentence cited and anything unverifiable removed, and still no clinical interpretation.