Genomics Foundations Engine

live   Domain: genomics   Type: engine

GPU germline variant calling: FASTQ to BAM to VCF via accelerated alignment (fq2bam/BWA-MEM2) and DeepVariant. Script/pipeline-invoked (Parabricks in Docker via run.sh/run_caller.sh), not yet a request/response API. ClinVar/AlphaMissense annotation is served by the Precision Intelligence Engine (E2, :5001); E1 produces the QC'd variant substrate E2 annotates.

A narrated, captioned explainer. Decision support for a qualified clinician.

Illustrative. Decision support for a qualified clinician — never autonomous diagnosis or prescribing.

In plain terms

The Genomics Foundations Engine is the factory's front door. A DNA sequencer never hands you a person's genome as a tidy readout — it hands you hundreds of millions of short, overlapping fragments of text called reads. This engine turns that raw pile into a clean, trustworthy list of exactly where a patient's DNA differs from the standard reference human genome. Those differences — called variants — are the raw material that every other engine and agent in the factory reasons about.

It does the job the way a modern clinical genomics lab does, only faster: it runs GPU-accelerated tools — NVIDIA Parabricks for read alignment and Google's DeepVariant for variant calling — so a whole genome goes from raw reads to a finished variant file in hours instead of the day or two a CPU pipeline would take.

Why it matters

Everything downstream — interpreting a variant's meaning, matching a patient to a therapy, designing a molecule, running a disease program — is only ever as good as this first step. A missed variant here is a missed diagnosis later; a false one is a false alarm. The engine's job is therefore not just speed but correctness you can check: it produces a result whose quality can be measured and reproduced, not merely asserted.

For a patient: the faster and more reliably their variants are found, the sooner a clinician has trustworthy answers to act on.

How it works

Germline variant calling: FASTQ → BAM → VCF, in hours not days. Illustrative.

1. Align — the millions of raw reads are mapped onto the GRCh38 reference genome (Parabricks fq2bam, built on BWA-MEM2), so every fragment is placed where it belongs.
2. Call variants — DeepVariant, a convolutional neural network, reads the stacked-up ("pileup") evidence at each position and decides where the patient genuinely differs from the reference, producing germline SNVs and small insertions/deletions.
3. Quality-check — the run is sanity-checked before anyone trusts it. A headline metric is the transition/transversion (Ts/Tv) ratio, which lands near 2.0 for a healthy whole-genome call set — a quick, standard signal that calling worked.
4. Hand off — the QC-passed variant file (VCF) is handed to the Precision Intelligence Engine, which annotates and interprets it. This engine finds where the variants are; the next engine explains what they mean.

What goes in, what comes out

• In: the raw text fragments from the sequencer (FASTQ) and the standard human reference genome (GRCh38).
• Out: a VCF (the list of the patient's variants) and a BAM (the reads aligned to the reference) — the substrate the rest of the factory builds on.

Where it fits

The genomics substrate flows to interpretation, then to the agents and disease programs. Illustrative.

The engine sits at the head of the pipeline. It does not annotate or interpret variants itself — that is deliberately the Precision Intelligence Engine's job (ClinVar / AlphaMissense annotation on :5001). Keeping calling and interpretation separate is what lets each stay honest and independently verifiable.

Honest limits

• Germline, not tumor. This engine calls inherited (germline) variants. Somatic/tumor analysis lives in the Precision Oncology Engine.
• Script-invoked today. It currently runs as a batch container pipeline, not yet an on-demand API — that API is on the roadmap.
• Elastic burst — and honest about what leaves. Parabricks is an x86-only CUDA container, so on an ARM DGX Spark this step runs on a remote x86 GPU over a private, encrypted mesh. Alignment needs the raw reads, so genomics is the one step where identifying data goes off-box: the reference deployment demonstrates it on the public HG002 sample, and any real-patient deployment must send those reads only to a dedicated, secure environment. Everywhere else in the factory, only derived, non-identifying data ever bursts — raw patient data stays on the local box.
• Proven on a public benchmark. The companion Variant Store capability is verified against HG002 — a public "gold-standard" human sample with a known, community-agreed set of variants, so the results can be checked in the open (the Ts/Tv quality signal lands at ≈ 2.0). Real-data evidence, not a claim.
• Decision support, not diagnosis. The output supports a qualified clinician's judgment; it never diagnoses on its own.

Interface

• Endpoint: localhost:5000 · Invoke path: /
• Serving: container · GPU: yes · Cost class: high

Inputs

Name	Shape	Semantic	Notes
fastq	file	fastq_reads	paired-end reads
reference	file	—	GRCh38 reference

Outputs

Name	Shape	Semantic	Notes
vcf	file	vcf_variants	annotated variants
bam	file	aligned_reads	aligned reads

Tags: parabricks · deepvariant · genomic-foundation · engine

---

↩ Back to the Engines index · the Capability Maturity Matrix · the Capability Brief.

Note

Status and interface are generated from the capability registry (lib/hcls_common/capabilities.json) — the site cannot claim ahead of the code. All clinical output is decision support for a qualified clinician, never autonomous diagnosis.