Genomic research tools rarely arrive as interchangeable components. They use different input conventions, produce different kinds of evidence, and often leave their operational limits in prose that a workflow cannot enforce.
The project takes the form of a FastAPI and React workbench paired with a registry of tool manifests describing inputs, outputs, limits, provenance, and execution contracts. Its purpose is to make heterogeneous genetics tools easier to run, compare, audit, and compose into safe research workflows.
The question behind Genome Model Runner + Registry
Genome Model Runner and its registry address that integration layer. The registry describes what a tool accepts, what it returns, how it should be invoked, and what its output can establish; the runner turns those declarations into inspectable workflows. Bioinformatics researchers and expert reviewers benefit most directly. Patients benefit only indirectly after appropriate validation and clinical governance.
How Genome Model Runner + Registry took shape
The current workbench combines a FastAPI service, a React interface, prepared CSV and VCF intake, normalization, manifests, adapters, tables, JSON exports, and reviewer packets. Initial evidence paths include FH-oriented sources such as ClinVar, gnomAD, and ClinGen. Josiah set the modular runner-and-registry direction, selected the initial evidence workflow, defined safety requirements, and directed agent-assisted implementation.
Capability map · implementation boundary
The architecture makes working, partial, and unbuilt capabilities visible.
The capability map is deliberately candid: implemented evidence adapters sit beside scaffolds and missing clinical-grade capabilities, preventing the long-term vision from being mistaken for the current system.
Source: Genome Model Runner capability audit · July 2026What the evidence supports
Runnable adapters currently cover selected FH, ClinVar, gnomAD, and ClinGen paths and can generate inspectable workflow outputs. The registry's most important function is not discoverability but epistemic discipline. A model or database entry should travel with its assumptions, version, provenance, and limits so that composition does not quietly turn several narrow tools into one unjustifiably confident system.
It is not a universal model host, a validated clinical pipeline, or a substitute for expert review. Tool coverage and input handling remain intentionally narrow. Future development will strengthen manifests and validation, introduce reproducible benchmark cases, and admit new tools only when their evidence boundaries are explicit.