Build a DNA analysis once, and it runs in every CommonSense user's library — privately, on their own machine. You never touch their data, and they never see yours. Same open contract whether you're a person or an AI agent.
Reach. Publish once and your analysis lands in every CommonSense user's library, ready to install in one click. There's one runtime to target — no per-OS builds, and no UI to write, since results render from a fixed set of building blocks.
No data to handle. Your code runs on each user's own machine, against data they control — you never receive, store, or see anyone's DNA. No sensitive data to secure, no compliance burden. The platform's job is to make that exchange trustworthy: a reviewed, signed bundle running in a sandbox the user controls.
Easy to build well. Describe a test and the in-app AI writes it; an evidence endpoint hands you real GWAS Catalog citations so your test is grounded in published research, not guesswork; and the dev-kit validates everything locally before you submit. Your handle ships on every analysis you publish.
For now the catalog is free and open — free tests are the wedge that brings users in, and that's where the energy goes. A paid tier with publisher revenue-sharing is on the roadmap, deliberately held back until the catalog has proven its pull. Get the ecosystem right first; split revenue later.
Algorithms in the public catalog ship as readable source. The bundle a user installs is the code itself — we read it at review, the user can read it on their own machine, anyone can. That's a deliberate stance, not an oversight: a test that runs on someone's DNA should be one they (or a reviewer acting on their behalf) can inspect. In a local-first tool there's no server to take on faith, so openness is the trust model. Publish to the public catalog and your code is visible — by design.
A confidential path is on the roadmap for organisations that need to keep an algorithm proprietary — say, a DNA-testing vendor packaging CommonSense as their own product without exposing their methods. It would use this same contributor pipeline with an added layer (still being designed) for the commercial side — pricing, licensing, and running proprietary code without revealing it. Open stays the default for the public catalog; confidential is an opt-in for those who need it.
Algorithms are Tier-1 Pyodide bundles: a Python entry point plus a manifest. The
host streams the user's parsed variants in; your code returns a result envelope
conforming to result.schema.json.
The renderer is a closed set of block kinds (rows, score, table, distribution,
callout, bars), which means any algorithm renders cleanly on every user's machine
without you shipping UI code. See each kind beside its example JSON in the
block gallery.
Bundles are signed twice — by your publisher key and by the marketplace's — and verified by the desktop app before any bytes run. The sandbox blocks network access, host filesystem access, and subprocess spawning by construction; the privacy invariant the brief calls out ("absence of capability, not trust") is enforced at the OS layer, not at runtime by your code.
A good test rests on published science; guessing at an rsID→trait link is how a library
fills with junk. So we've distilled the GWAS
Catalog into a per-trait evidence layer you can query before you write a line —
to pick a trait that's actually well-supported, and to pull a real citation for the
references your submission must carry (the publish gate resolves
every citation and rejects fabricated ones, so this is also how you satisfy it honestly).
How we prepared the dataset. We start from the GWAS Catalog studies metadata — roughly 220,000 rows, one per published study — and aggregate it per ontology-mapped trait (the EFO/MONDO term, not the messy free-text label) into about 20,900 cards, one per trait. Each card carries:
It's an index of evidence — what's been studied, and how strongly — not the variant-level data itself. For a single-SNP trait the curated top hits are enough; for a real polygenic score, follow the summary-statistics links down to the genome-wide per-variant data. And it's triage, not clinical validity: a strong tier means "well studied, look here first," never "safe for a health decision."
Query it — from the dev-kit:
commonsc-devkit evidence "caffeine" # human summary
commonsc-devkit evidence "eye color" --json # machine-readable…or hit the API directly (handy for agents and scripts):
GET https://api.commonsc.io/evidence?q=eye+color
→ { "count": 2, "results": [
{ "trait": "eye color", "tier": "strong", "portability": "multi_ancestry",
"pmid": "36672889", "n_studies": 16, "medical": false,
"caveats": ["No full summary statistics; only curated top hits…"] }, … ] }Turning a card into a quality test:
strong: many studies, large samples, replication.european_only is the honesty flag; carry it into your result as a caveat callout so a user of another ancestry isn't misled.manifest.references as { "type": "pubmed", "id": "…" }. It resolves at the gate, so your submission passes on a genuine source.Install the toolkit, register, scaffold a project, fill in your interpretation, test it locally in the sandbox, and publish:
curl -fsSL https://commonsc.io/install.sh | sh # installs commonsc-devkit
commonsc-devkit register --name "You" --contact you@example.com
commonsc-devkit init my-algorithm \
--id my-handle/my-algorithm \
--name "My algorithm" \
--rsid rs12345678
# Edit my-algorithm/<package>/main.py — fill in the GENOTYPES table.
commonsc-devkit run my-algorithm # run it in the real sandbox (needs Deno)
commonsc-devkit validate my-algorithm
commonsc-devkit publish my-algorithm --remote
publish --remote signs your manifest and uploads it to
the marketplace review queue; once a reviewer approves, it's promoted to the public
catalog. Prefer building from source? Clone
druidalabs/commonsc-marketplace- and use
cargo run -p commonsc-devkit -- …. The
run step needs Deno; the rest doesn't.
The entire pipeline is machine-readable. Start with the discovery contract:
GET https://commonsc.io/.well-known/commonsc.jsonThat JSON document lists every schema URL, every API endpoint (including the evidence lookup below), every tier, every constraint, the registration URL, the synthetic fixtures to test against, and the review SLA. From there:
Ground the test in evidence first. Before you author, query the same
evidence layer described above — it's a plain GET, no auth, with the response shape
documented under api.endpoints.evidenceLookup in the discovery
contract:
GET https://api.commonsc.io/evidence?q=eye+color
→ { count, results: [ { trait, tier, portability, pmid,
caveats, medical, summary_stats, … } ] }
Pick a card that is medical: false and well-tiered, cite its
pmid in manifest.references (the
publish gate resolves it), and carry any portability caveat into the result. Then:
POST https://api.commonsc.io/algorithms/validate
multipart/form-data, field "bundle" = tar.zst of project
→ gate-result.schema.json document
POST https://api.commonsc.io/algorithms/publish
same shape → { submissionId, status: "queued" }
GET https://api.commonsc.io/algorithms/{submissionId}/status
→ current state, polls cheapSubmissions land in our review queue. Approval triggers the marketplace co-sign and promotes the bundle to the public catalog. Every consumer who pulls the catalog sees it on their next refresh.
For the rationale and the closed set of structured remediation actions you can loop
on, read /llms.txt — written
specifically for agents that crawl it as context.
manifest.schema.json — what your bundle declares about itselfgenomic-io.schema.json — the VariantSet the host streams inresult.schema.json — the result envelope your compute() returnsgate-result.schema.json — what /algorithms/validate returnsdiscovery.schema.json — meta-schema for the discovery doc itself--allow-net. Don't try; it fails noisily./etc, $HOME, etc. are unreachable.algorithms/ — they're the canonical examples.Questions: druidas@druidalabs.com.