Home / Vaults / Private Health Score
Private Health Score
A complete clinical workflow in one vault — adaptive questionnaire, a versioned scoring framework, an explainability layer that traces every recommendation back to an answer, and a clinician review screen — running entirely client-side. It is published here as a sanitised republication, because the vault it was built from carried its own write credential in its home page and could never have had its key published.
Read key:
sgit_rk1_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40:zc6abngvIn the official UI: open it read-only in a new tab · From the CLI:
sgit clone sgit_rk1_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40:zc6abngvThis key opens vault
zc6abngv, the sanitised republication — not the vault this content was authored in, whose key was never published and never will be. See the audit below.See it live, here
Both surfaces open automatically below. You can also open the app in its own window ↗.
What this vault demonstrates
| Feature | How this vault uses it |
|---|---|
| One vault, three audiences | patient/, doctor/ and shared/ split the same record by who is reading it, not by copying it. The patient fills in the questionnaire, the clinician opens a review of the same answers, and the framework and analysis both sides rely on sit in shared/. One credential, one copy, three views |
| The rules are data, and versioned | shared/health-score-standard.json is the scoring framework as a file — 5 dimensions with explicit weights (cardiovascular 25%, metabolic 20%, lifestyle 20%, wellbeing 20%, preventive care 15%), 5 bands and 8 rules, stamped v1.0. The viewer labels it "loaded from vault at runtime", and a Reveal JSON button shows the source behind the rendering |
| Deterministic score, generated prose | the number comes from the framework; the LLM writes the narrative around it. The clinician screen states the provenance in the open — AI-generated · estimated cost $0.024 · claude-sonnet-4 — and llm-analysis.json carries status: pending_clinician_review. The model's output is a draft for a human, and the file says so |
| Every recommendation traced to an answer | the explainability layer lists what helped and what hurt with the rule that decided it: "Last Blood Test: over 2 years — scored 50/100, affects your Preventive Care score." Its own note draws the line: "The framework — not the AI — produced these. The AI analysis adds nuance; these are the foundations" |
| Severity-ranked clinical actions | the review screen sorts suggested actions URGENT → HIGH → MEDIUM → LOW rather than presenting a flat list, and pairs them with the dimension scores that triggered them — plus an adaptive risk gates section showing which branches the questionnaire opened because of earlier answers |
| No account anywhere in the flow | sharing the record with a clinician is handing over a derived read key. There is no clinician login, no tenant, and no server-side copy — the vault's own architecture section states the three-credential model, and the read key you are holding is the proof |
| Permissions left undeclared | honest gap rather than a feature: app.json declares entry, auto_open, present and a HUD block, and no permission block at all — compare VoiceDebrief, which scopes fs.read to one folder. An app that never states what it needs cannot demonstrate least authority, and will need a grant declared when the platform's deny-by-default lands |
What is going on here, step by step
The embeds above are the real vault, which makes it easy to scroll past the parts that matter. Each row points at one of them. Every screenshot is of this vault, driven by a script holding nothing but the published read key.
Two demo profiles, chosen to disagree
The vault opens on a hub built around two synthetic profiles that are deliberately not alike: Alex, 34 — BMI 25.9, good lifestyle, scoring 74 · Good — and Sam, 47 — BMI 33.8, multiple risk factors, scoring 38 · Needs Attention.
One profile would demonstrate the rendering. Two that land in different bands demonstrate the framework, because every screen after this one can be read twice and compared.
A ten-step questionnaire that branches on what you answer
The patient app is a ten-section flow — welcome, about you, lifestyle, health, history, concerns, score, AI analysis, vault save, complete — with a demo bar across the top that can drive each step or run the whole thing.
The two steps worth noticing are the last two. Vault save is where the record is encrypted and written, and complete is the final record — the flow ends by producing an artefact the person keeps, not a result page that disappears.
The framework is versioned, readable and separate from the code
This is the part that makes the rest auditable. The scoring standard is a JSON file in the vault, rendered here as a document: five bands from At Risk (0–29) to Excellent (85–100), and five weighted dimensions shown as a radar with the weights stated numerically beside it.
Because it is data rather than logic buried in a function, it can be versioned (v1.0), diffed between commits, and disagreed with. Reveal JSON shows the source that produced the page you are reading — the rendering and the rules are the same object.
Each number carries the answer that produced it
Alex's 74 breaks into heart health 78, lifestyle 76, wellbeing 72 — and then into the individual answers behind them. "Smoking: never — scored 100/100 in the framework." "Alcohol: light — 90/100." Against him: "Last blood test: over 2 years — 50/100, affects your Preventive Care score. Framework flag: book routine blood panel."
Three tabs sit above it — Your Health Story, Score Breakdown, Evidence Map — the same result at three depths. The layer's own caveat is the important sentence: the recommendations come from the framework, and the model only adds nuance on top.
The same record, arranged for someone qualified to act on it
Sam's review puts the record on the left — dimension scores with the reasoning under each, then the full profile — and the AI analysis on the right, as suggested actions ranked by urgency: two URGENT (a GP appointment for cardiac symptoms, and a specific blood panel), three HIGH, then medium and low.
Two things make this more than a dashboard. The analysis is labelled AI-generated with its model and cost, so a clinician knows what they are reading. And beneath it is a clinical notes block for the reviewer's own observations — the tool expects to be corrected, and keeps the correction next to what it corrected.
The card that used to hold a live write key
The vault explains its own credential model in three cards: the vault key (full read/write, kept private), the derived read-only share token for the clinician, and the data location (client device only). The model is right, and it is the argument the whole demo makes.
In the original vault, the first card contained an actual working vault key — the real credential for the vault you were reading it in. Here it shows the shape, ⟨passphrase⟩:⟨vault-id⟩, with the reason attached: a write credential is never written into the vault's own content. The teaching value survives; the credential does not.
Two commits, both from the day it was republished
The SGit view is the evidence for the claim in the audit below. This vault's history begins on 22 August 2026 with init, followed by the sanitising commit. The original's 61 commits are not here, and neither is anything they contained.
That is deliberate and it is the whole point of republishing rather than patching. A read key hands over every commit, so deleting a credential from the current files would have left it sitting in history, reachable by anyone holding the key that was supposed to be safe to publish.
A manifest that declares no permissions at all
145 bytes: an entry point, auto_open, present, and a HUD configuration that hides the vault name. There is no permission block.
Included because it is the honest weak point of an otherwise careful vault. Silence is not least authority — it is an absence of a statement, and it reads as one next to VoiceDebrief's scoped fs.read or Risk Graph Explorer's deliberate empty grant. When deny-by-default lands, an app that never said what it needs is the one that stops working.
app.json: an entry point, a HUD, and nothing said about permissions.Why this shape matters beyond health
The transferable pattern is the rules as a versioned file, the model on top, and the trace between them. Anywhere a decision has to be explainable — lending, eligibility, triage, grading — the same split applies: put the criteria in a document that can be versioned and argued with, compute deterministically against it, let the model write the part humans read, and label which is which. The failure mode this avoids is the one where nobody can say afterwards whether the number came from a rule or from a sentence a model produced.
The vault-shaped part is that sharing with a professional is handing over a derived read key, not creating them an account. The nearest thing on this site is Supplement Stack, which does the same for a patient-held supplement record with real data; this one covers the fuller workflow, on synthetic profiles, and adds the clinician's side.
The audit, honestly
This is the vault whose audit stopped a publication, so the finding comes first.
The original vault published its own write credential. home/index.html rendered a card labelled "Patient vault key (write access) — full read/write, patient keeps this private", and the value in it was the real, working vault key for that vault. Anyone given the read key — the credential this page exists to hand out — could have read that card and gained write access to everything in it. The read key was therefore never publishable, and was never published.
Why a fresh vault and not a fix. Removing the card from the current files would not have been enough: a read key grants every commit, and the credential would have remained readable in the history. So the working tree was copied, sanitised, and committed into a new vault (zc6abngv) with a new key. The original's 61 commits were left behind. This is the site's own rule — republish, don't retrofit — applied to the case that produced it.
What was verified, and how. After publishing, all 35 files were fetched back using only the read key above — the exact credential a reader holds — and scanned. No occurrence of the original passphrase, the new passphrase, the old vault id, or any sgit_vk1_ / sgit_private_vault_ / delete_auth string. The broad secret scan across API-key, bearer-token and private-key patterns is clean too.
On the data. Both profiles are synthetic and say so in their own files: profile_id: demo-alex, vault_commit: "simulated", first names only, and a postcode area (SW1, M1) rather than a postcode. The test-lab submissions are labelled Test Patient (lab), age 99. No real person's health data is published here — which is the difference between this vault and Supplement Stack, and worth stating rather than leaving to be assumed.
One defect found, and it is not ours. The patient app throws Uncaught ReferenceError: loadStandard is not defined on load: patient/app/data.js calls it at line 116, while patient/app/app.js defines it at line 9 — a load-order race. It is pre-existing, not introduced by the sanitising: patient/index.html is byte-identical between the original clone and this republication. The app still renders and runs, and the error is left as found rather than quietly patched, because this page publishes someone else's vault and the fix is theirs to make.
The rule that goes with any published key applies here too: revocation is not retroactive. Anybody who fetches these objects keeps them, and rotating the key protects future commits only.
Derived facts
35 files · 1,224 KB · 3 commits · HEAD obj-cas-imm-4c5c2c178517 · app entry home/index.html · 12 JSON, 9 HTML, 9 JS, 3 markdown, 2 CSS — derived from the read key alone by admin/build/catalogue_derive.py, the same derivation that populates the catalogue, with no token and no clone.