Legal governance documentation
Data Architecture & Security Model
How GeneticCoding ingests raw DNA data, extracts and minimizes it, stores it in pseudonymized namespaces, and why an exfiltrated copy of the data is not re-identifiable or usable on its own.
1 · End-to-end ingestion & processing pipeline
Every stage from file selection to report delivery. The raw genome is only ever whole inside ephemeral job memory — every durable store receives a minimized, pseudonymized derivative.
1 · Client-side intake & validation
The raw DNA text export (.txt / .csv / .zip, ≤ 50MB) is selected in the browser. Format, vendor, and genome build are detected locally — nothing leaves the user's device until they explicitly confirm.
No data leaves device yet2 · Informed-consent gate (before any processing)
A mandatory multi-check informed consent (age, own-DNA attestation, educational-only scope, GINA limits, US region, Terms/Privacy/Disclaimer) is recorded server-side with the exact affirmations stored verbatim as an immutable audit trail. No report is ever generated without a stored proof of consent.
Immutable consent audit trailPre-analysis gate3 · Server-side entitlement check
A backend function verifies upload rights (free-report token, report credits, or legacy purchase) under the privileged service role before any job is created. Entitlements are auto-refunded if analysis fails.
Auth requiredService role4 · Secure upload to encrypted object storage
The file is transmitted over TLS into platform-managed PRIVATE, encrypted object storage (AES-256 at rest). The raw file is never publicly addressable — the pipeline reaches it only through temporary, narrowly scoped access grants — and raw bytes are never stored inside the application database.
TLS 1.2+ in transitNever publicly addressableAES-256 at rest5 · In-memory extraction (ephemeral)
The analysis pipeline downloads the file into job memory, parses it line-by-line, and extracts rsID → genotype pairs. The full raw text exists only in transient memory during this pass and is discarded when the job ends — it is never copied into the database.
Ephemeral memory onlyNever persisted as text6 · Public-catalog filter (radical minimization)
Only SNPs whose rsIDs appear in our curated, annotated catalog of the public SNP knowledge base are kept. Typically 99%+ of the raw file's rows are discarded here — unannotated positions never enter our systems in any durable form.
>99% of rows discardedAnnotated rsIDs only7 · Pseudonymous variant index write
The retained genotype calls are encrypted at the field level under keys that never reside with the data, and written as a sparse index — rsID, gene, encrypted genotype, category — keyed ONLY to the user's random genome ID, which is held in a separate, tightly access-controlled link. No account ID, name, email, address, or any direct identifier exists inside this genetic data namespace.
Field-level encryptionAutomated key rotationZero direct identifiers8 · Report assembly from public knowledge
Interpretations are joined from the public annotation catalog and assembled into the user's report payload, stored on the access-controlled job record behind Row-Level Security (owner + admins only).
RLS-guardedOwner-scoped access9 · Raw-file lifecycle
An automated retention job destroys the raw file reference once its default retention window expires — the file is then unreachable from the application, since access can no longer be granted without the reference. The file is retained only when the user explicitly opts in (auto-enabled for monitoring subscribers) and is removed on account deletion.
Automated purgeOpt-in retention only10 · Notification
The user is emailed a link to their completed report. The email contains no genetic content.
No genetic data in email
2 · Extraction & radical data minimization
The defining design decision: we do not store the user's DNA. We store a sparse index of the public library of annotated SNPs, tagged to an encrypted anonymous identity.
Full genotype export from 23andMe, AncestryDNA, MyHeritage, or FamilyTreeDNA. Exists whole only in ephemeral analysis memory.
Only rsIDs present in our curated SnpFinding catalog survive the filter — typically under 1% of the file. Each retained row is one rsID plus a two-letter genotype call, nothing more.
Rows of rsID · gene · encrypted genotype · category keyed to an opaque random genome ID (a pseudonymous identity linked to the account only through a separate, tightly access-controlled link). This index — not the DNA — is what the system durably holds, and its genotypes are stored as ciphertext.
3 · Storage architecture: separated, pseudonymized namespaces
Identity and genetic data live in distinct namespaces joined only by a surrogate key. The interpretation layer is entirely public knowledge.
Identity namespace
Who you are. Guarded by Row-Level Security: each user reads only their own records; writes happen only under the admin/service role.
Genetic namespace (pseudonymized)
What your DNA says — as a sparse index of catalog-annotated SNPs. Contains no direct identifiers of any kind.
Public knowledge base (separate namespace)
The interpretive layer is public scientific knowledge, decoupled from all user data. It is shared by every user and contains nothing about any individual.
4 · Security controls in force
Layered controls across transport, storage, access, payments, consent, and deletion.
TLS 1.2+ HTTPS-only; no plaintext endpoints
Retained genotypes encrypted at the field level; keys rotate on an automated schedule with manual and emergency controls
Platform-managed AES-256 encrypted storage & database
Per-entity ownership scoping — users read only their own records
Mutations run under the service role only after server-side auth + entitlement checks
All card data handled by Stripe — never stored in our systems
Immutable, verbatim consent audit trail preceding every analysis
On-demand data purge and full account deletion cascade
5 · Breach-impact model: why an exfiltrated copy is useless
Governance analysis of what a database compromise would actually yield and why re-identification fails at each stage.
What an exfiltrated copy contains
- •Sparse variant rows: rsID + gene/category plus field-level encrypted genotype calls — unreadable without key material that is never stored alongside the data
- •Opaque genome IDs and job IDs
- •Public annotation catalog text (already publicly available)
- •Account emails and report payloads on access-controlled job records
What it does NOT contain
- •No raw DNA sequence — discarded once the report is generated, by default
- •No unannotated SNPs — never extracted, never stored
- •No names, addresses, dates of birth, or government IDs
- •No payment card data — Stripe handles all card details (PCI delegated)
- •No SSNs, insurance IDs, medical records, or third-party login identifiers
Why the data is useless to an attacker
An exfiltrated copy of the variant index is a list of public rsIDs, gene names, and encrypted genotype calls tagged to opaque genome IDs. Nothing can be decrypted without key material that is never stored with the data, and rsIDs and their interpretations are public knowledge — the stored content alone identifies no one.
Re-linking requires a second, separate compromise of the tightly access-controlled linkage between the two namespaces — different records, guarded by per-entity access controls and managed auth. There is no shared external identifier between the two namespaces to exploit.
Even a successful re-link yields only: this account holder's email plus their genotype calls on curated SNPs. No financial credentials, no government identifiers, no raw genome — minimal resale value and minimal harm surface.
6 · Data retention schedule
What we keep, for how long, and what disappears.
| Data class | Retention policy |
|---|---|
| Raw DNA file | Purged after a short default retention window once the report is delivered (enforced by an automated job; the file becomes unreachable once the reference is destroyed). Retained only on explicit opt-in (monitoring auto-enable). Removed on account deletion. |
| Variant index | Lives with the account; fully deleted on account deletion. |
| Job & report records | Lives with the account behind RLS; fully deleted on account deletion. |
| Consent records | Retained as a compliance audit trail of what was affirmed, and when. |
| Payment references | Only Stripe object IDs stored; card data never enters our systems. |
Retention purges and encryption-key rotation are enforced by automated processes, with manual and emergency controls available to administrators.