Your data · Commitments
What we will never do, and how you’d know.
What we will never do, who each promise is about, and the check that enforces it.
Your data · Commitments
What we will never do, and how you’d know.
Promises are cheap. Each one below names who it is about — pharmaceutical companies, insurers and payers, advertisers — and names the check in this repository that enforces it. A commitment reads as held only while every file it names exists; where one is not yet fully met, it says so, with the current state.
Versioned · v1.1 · 2026-09-19
0 held · 7 in progress · read from the tree at render
- in progress
We will never sell or license a patient record, or data derived from one.
About pharmaceutical companies, data brokers, and anyone who would pay.
No individual record, and no data derived from one, is sold, licensed or exchanged for value. Consented research access is not an exception to that: it is a purpose you switched on and can switch off, it reaches aggregates of five or more people and never a record, it is released only after an administrator records an ethics verdict, and what it returns is findings rather than revenue. An industry researcher is a separate account type reaching the same aggregates through the same gate.
How it’s enforced
Row-level security in the database: no role can read another person’s rows. The research cache is a materialized view the database itself floors at five, and the only ways into it are two functions that clamp the floor again. There is no export path for an individual record to any third party.
- scripts/check-rls.ts · missing
- scripts/check-research.ts · missing
- scripts/check-findings.ts · missing
- in progress
We will never run ads or take sponsored content.
About advertisers, and about pharmaceutical and supplement companies who would sponsor a page.
No advertising anywhere on the site or in the app. No paid placement in education, the directory or the shelves. Where we earn an affiliate commission on a product, the page says so beside the link and the link is marked as sponsored to search engines — and nothing is ranked by what pays.
How it’s enforced
Every affiliate link is enumerated from the product file and asserted to carry the sponsored marker; a product definition refuses ranking language at module load; a sweep of every public page refuses unexempted ranking claims; and the directory’s order is proven not to move when a listing is marked featured.
- scripts/check-rendered.mjs · missing
- scripts/check-superlatives.ts · missing
- scripts/check-directory.ts · missing
- in progress
No payer will see an individual record.
About health insurers, Medicare Advantage plans, employers and benefits administrators.
Insurers are not a role here. There is no payer account type, no payer API, and no export formatted for a payer. Claims you import stay closed to the clinicians you share with and to research, by policy and by the promise in the consent copy. If you use the appeal kit, you send the appeal; we never contact a payer.
How it’s enforced
The frozen role enum holds five values — patient, provider, researcher, pharma, admin — and no payer. Imported claims are proven unreadable in a clinician’s session and absent from the research cache.
- docs/architecture/schema.sql · missing
- scripts/check-claims.ts · missing
- scripts/check-auth.mjs · missing
- in progress
You can export your record as one standard file, and the file names what it does not carry.
About you.
One download: symptoms, labs, medications with their response windows, household animal tests, and your consent settings, as a FHIR R4 bundle. Your journal is not in it, and the file itself lists every element it does not carry rather than filling anything in. No fee, no waiting period, no support ticket.
How it’s enforced
The export’s coverage statement is diffed against the element set both ways on every run, and three things that must never leave — the journal, a lab’s prose note, a Beacon interpretation — are proven present in the database and absent from the file.
- scripts/check-standards.ts · missing
The shape of the file: the element set, on the standards page →
- in progress
You can have your account deleted, and we say exactly what stays.
About you — and about us, because the self-serve half is not built.
Ask from the address you signed up with, and the record is erased in one audited operation: every row, every uploaded file, every stored credential, the login itself. Three things stay by design and are said plainly: the history of your consent choices and the log of who accessed what, both append-only, attached to a placeholder that names nobody; and a note a clinician wrote about their own reasoning while you shared with them, with its link to you cut. Aggregates already released were never you as a row and cannot be un-released.
How it’s enforced
The erasure is swept against every foreign key that points at a person, enumerated from the schema so a forgotten table fails loudly; the two retained tables are asserted positively, because a sweep that only checks absence would pass a deletion that destroyed the evidence too.
- scripts/check-deletion.ts · missing
- in progress
We will never rate, rank or review clinicians.
About clinicians — and about the directories that make money doing this.
The directory lists who a person checked, what they submitted, and the two facts the schema holds about a practice. Order is alphabetical. No stars, no reviews, no rankings, no lists of the top anything, and a paid tier never moves a listing.
How it’s enforced
The listings table has no rating or review column; the verified badge requires a human verdict recorded in an append-only table and cannot be set by a flag alone; and the check proves that marking a listing featured does not change the order.
- scripts/check-directory.ts · missing
- docs/architecture/schema.sql · missing
- in progress
Beacon will never tell you what you have.
About the AI companion, and the people who would ask it to.
Beacon explains records you point it at and phrases figures the code computed. It does not diagnose, it does not name a dose, it never computes a trend itself, and its scope line sits above every conversation. It sees your record only while a switch you hold is on, and the switch starts off.
How it’s enforced
A safety floor scans every reply inside the only function that can produce one and refuses a diagnosis or a live dose; the consent gate is a type only one function can mint, so a route that has not checked consent does not compile; arithmetic, not the model, decides every direction.
- scripts/check-beacon-floor.mjs · missing
- scripts/check-beacon.mjs · missing
Changelog
- v1.12026-09-19Commitment 1 now says plainly that consented research access is not a sale or a licence — a purpose you switched on, revocable, returning findings rather than revenue. It prohibited licensing data derived from a record and then described aggregate research access in the next sentence, and an aggregate is derived from records. No commitment was removed or weakened; the contradiction was.
- v1.02026-09-17First published: seven commitments, staff access, retention and deletion, no way in, and who else touches this.
Every version of this page is kept in the repository’s history. Removing a commitment would appear here as a line; none has been removed.
Staff access
What people who work here cannot do
Two of these are not permissions we withhold from our own staff — they are screens that do not exist in the software. The third is the database refusing. And one thing the kit’s page said, we do not: the credential that bypasses row-level security exists here, so the honest sentence is that there is no screen, not that there is no way.
Open your record from a screen
no screen · a credential existsThere is no administrative view of a patient record — not a read-only one, not a redacted one. The administrator’s seat reaches two queues and nothing else. What does exist is the database credential the cron jobs and the audit writer use, and it is held by the founder; we do not claim “even we cannot see your data”, and that phrase is on the security page’s list of things we will not say.
Sign in as you
not builtNo impersonation, no “view as this user”, no session takeover. It is the most common support feature in software like this and it does not exist here, because a tool that lets staff become you is a tool that can be used or compelled without you knowing.
Change or remove an entry in the audit log
refused by the databaseThe log refuses updates and deletes at the table itself, including entries about a staff member’s own actions. Emptying the whole table is not guarded the same way, so we say “cannot edit” rather than “can never be erased”.
What staff can do, so this is not a half-truth
- See the queues and their states — never the record content behind them.
- Approve or decline a clinician’s verification, citing the evidence, recorded under their own name in an append-only table.
- Approve, deny or revoke a research access request, with a written reason kept in the audit log. That reason is not yet readable by the researcher, and that gap is filed.
- Nothing else. Suspending an account, restoring a seat and producing the log under a legal hold are not built.
Every administrative action is written to the audit log under the name of the person who took it, and that table refuses edits — including from us.
Retention and deletion
Exactly when it is actually gone
“You can delete your data” is the easy sentence. These are the timelines behind it, including the one case where deletion cannot reach, and the two figures we have not measured and therefore do not print.
- Immediately
- Access stopsTurning sharing off, or removing a clinician, takes effect on their next page load. There is no cache and no grace period for the recipient.
- On request
- The record is erasedBy a person, in one audited operation, once the request is checked. Not archived, not anonymised and kept, not “deactivated”.
- Kept
- The consent history and the access logAppend-only, attached to a placeholder that names nobody, because a log you can delete is not evidence. A clinician’s note about their own reasoning also stays, with its link to you cut. No retention period has been set for any of them yet; when one is, it is published here first.
- Unmeasured
- BackupsThe database host keeps backups on its own rotation. No figure is printed here until it has been measured and sourced.
- Cannot
- Analyses already runIf you contributed to research and a figure has been released, deletion removes you from every future analysis and cannot recall the past one. This is the single limit on deletion here, and it is stated at the switch as well as on this page.
There is no emergency door in the product
Systems that promise not to read your record usually have a procedure for reading your record. It is usually called break-glass, it is usually justified by an emergency, and it is usually the thing that gets used. No such screen, override or dual-authorisation ceremony exists here — and we do not dress that up as “the code path does not exist”, because the service credential above is a code path, and the honest claim is the narrower one.
Who else touches this · as of 2026-09-17
Every company with access to any part of this system
What each holds, published and dated. This is the locked stack; a new one is added here in the same commit that connects it. Stripe is chosen for payments and not integrated — no card data exists here. No hosting region is stated, because we have not verified one.
| Company | What they hold |
|---|---|
| Supabase | The database, sign-in, and uploaded files — all application data. |
| Vercel | Hosting, and the functions that run the app and its scheduled jobs. |
| Upstash | A Redis cache: rate-limit counters, queued access-denial events, import cursors. Never health data, by rule. |
| Postmark | Email addresses and the text of transactional email. Never record content. |
| Anthropic | The text of a Beacon question, and the parts of your record the switch allows, only while it is on. |