architecture and data flow.
A plain reading of how Canary handles the most sensitive data a person has, and what the system refuses to do with it.
Technical documentation, revision 1.0
read the full privacy policy →
how data moves through the system.
separated identity
Health data and identity are stored separately. Individual records are keyed by an anonymous identifier, not by name or employee ID, inside the application's data layer.
the clinical layer
Biomarker results are reviewed by a clinician before the member sees them. Raw lab data is handled under a defined retention window, not kept indefinitely.
the aggregation gate
Employer-facing insight is produced only above a minimum cohort size of 5. This is not a UI rule — it is enforced directly in the database: our Postgres row-level security policy for the aggregate-metrics table requires cohort_size >= 5 before a row is visible to any employer session. Below that floor, there is nothing to suppress in the UI, because the query returns no rows at all.
consent boundaries
Separate, revocable consent for clinical care, employer aggregation, and any model-development use. Participation is genuinely optional, and withdrawing consent does not remove access to the underlying clinical service.
the floor, in practice.
What an employer session sees when one team is too small: not a hidden row or a zeroed-out one. For that session, the team does not exist.
- Engineering · 32 peopleTrends shown
- Sales · 18 peopleTrends shown
- Design · 4 peopleWithheld · under 5
- Finance · 7 peopleTrends shown
Enforced by row-level security in the database, not by the screen. No individual is ever listed.
constraints, not promises.
Every row below describes something the system cannot do, not something we have committed not to do.
- No individual health data is ever visible to the employer.
- Enforced at the database level. The table holding individual health records has a row-level security policy that lets a member read only their own rows — there is no policy granting an employer-context session any access to it at all. With RLS default-deny, the absence of a policy is the guard: an employer session querying that table returns zero rows, not filtered rows.
- No employer signal below the minimum cohort size.
- The aggregate-metrics table's row-level security policy requires cohort_size >= 5. A cohort of 4 or fewer produces no visible row for any employer session — not a hidden one, not a zeroed-out one. It does not exist from that session's point of view.
- No use of any data for employment, promotion, or dismissal decisions.
- Prohibited contractually in every employer agreement, and structurally impossible in practice — the data an employer can query is aggregate by design and cannot be traced back to an individual.
- No health data leaves the EU except via named processors under Standard Contractual Clauses.
- Our database and authentication infrastructure run on Supabase, hosted in Frankfurt. Two processors operate outside the EU under Standard Contractual Clauses, disclosed in full on our privacy policy: WHOOP (wearable integration, only if you connect a device) and Anthropic (AI-powered insights, processed under a data processing agreement and never used to train models). We say this plainly rather than claiming data never leaves the EU, because it sometimes does, under a named legal basis.
- No sale of data, ever.
- Not to advertisers, not to data brokers, not to the employer beyond the aggregate view described above.
test it with your own questions.
Bring your DPO and your hardest questions to a pilot, or read what the research already knows.