Your genome never leaves the tab it is read in.

LocusLocal is a variant-triage workbench for data too sensitive to upload. You drop a VCF or a 23andMe / AncestryDNA raw export onto the page; it is parsed, annotated against a bundled ClinVar subset and triaged entirely inside one browser tab. Then an AI agent can analyse it with you — without the file ever being transmitted anywhere.

The problem

Tens of millions of people are sitting on a consumer-genomics raw export they will not upload to a third-party interpretation site. So the file just sits there: simultaneously the most personal data they own and completely unreadable to them. The obstacle is not analysis. The obstacle is that every tool capable of doing the analysis asks for the file first.

Why it cannot upload your file

This is not a promise, it is a property the browser enforces. The page is served with Content-Security-Policy: connect-src 'none' and form-action 'none', which makes fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon and form submission structurally unavailable to every line of code on the page — ours included. There is no code path that can open a data connection, so there is nothing to audit for good behaviour.

The data the app itself needs — the ClinVar subset and the demo genome — is shipped as lazily imported script chunks, which the browser governs under script-src rather than connect-src. The fonts are self-hosted for the same reason: a product whose entire claim is that data never leaves the tab must not open a connection to a font CDN to draw its own interface. A monitor instruments every outbound API and stays silent at zero; if one byte is ever attempted, it takes the full width of the screen and says so.

What the agent can and cannot do

The genome is inaccessible to the agent except through WebMCP tools this page registers. Those tools are read-only by default; every tool with a side effect renders a confirmation card in the page and waits. The agent can propose. Only a human can commit — and a refusal is recorded, so the agent can read back that it asked and was told no rather than asking again.

Every change an agent makes goes through the same code as a mouse click, lands in the same undo stack, and briefly outlines the panel it touched. Nothing a tool can do is unavailable by hand: the same filters, the same explanations, the same shortlist edits. The analysis lives in one module that both the guided screen and the agent's tools call, so the human and the model are always reading one analysis rather than two implementations of it.

What it is not

This is not a diagnosis and not medical advice. ClinVar classifications describe variants, not people, and a consumer genotype file is not a diagnostic test. A genotyping chip reads a small, fixed slice of the genome: a variant absent from your file has not been ruled out, it was never looked for. An empty findings list is the common result and it is not a clean bill of health. Take anything that worries you to a clinician or a genetic counsellor.

Where the data comes from

Nothing shipped here is synthetic. The demo genome is sample NA12878 from the 1000 Genomes Project on an Affymetrix 6.0 genotype chip — real, public, open-consent human genotypes. Annotations come from NCBI ClinVar (GRCh37), a public-domain U.S. Government work. The build is not assumed: it is detected and scored, and a file that cannot be safely joined against a GRCh37 subset is browsable but carries no clinical classifications at all, with the reason stated on screen.

Where your session is kept

The parsed genome, your filters, your shortlist and your notes are written to IndexedDB on this device so you can pick the work up again. That copy never leaves the machine, restoring it is always offered rather than automatic — silently reopening somebody's genome on a shared computer would be a privacy failure dressed up as a convenience — and one button in the header erases all of it.

Built for the WebMCP Challenge. Source on GitHub.

Open the workbench