Quality control isn’t optional in sequencing.

If you generate a sequencing dataset, you should collect the metrics that tell you how that dataset was made, how it behaved, and whether anything subtle went wrong along the way. That should be standard practice, not a special step reserved for failed runs or high-priority projects.

The problem is that QC tooling has not kept up with current sequencing scale.

For years, Picard has been the default tool for sequencing metrics, and for good reason. It gave the field a common set of measurements and became part of a huge number of production workflows. I spent a lot of time working on it, and I know exactly why it became so widely used.

I also know where it started to fall behind.

Picard reflects an earlier era of sequencing. It is slower than modern pipelines need it to be, some of its assumptions deserve updating, and it has not evolved in step with the scale and complexity of current sequencing workflows. When a tool sits at the base of thousands of pipelines, those shortcomings stop being minor annoyances, and they become an accumulated tax on every dataset.

That is why I built Riker.

Riker is a modern successor to Picard for sequencing QC metrics. It is faster, cleaner, and built around the idea that metrics collection should happen on every dataset because the information is too useful and too cheap to ignore.

QC should do more than raise a flag

Most teams would agree that QC is important, but they probably don’t think as deeply about it as they could.

A lot of QC tooling is built to answer a narrow question: did this dataset clear a threshold or not? That is useful, but not enough. The more valuable question is often why the data looks the way it does.

That is why tools like Picard became so useful. Picard doesn’t just report a summary number. It helps explain where signal is being lost, what kind of bias is showing up, and which parts of the workflow are most likely responsible. Fantastic tools like mosdepth and perbase can give you mean coverage very quickly, which can tell you that something is off. A richer collector like CollectWgsMetrics can help tell you where the missing bases went and how to start fixing the problem.

The diagnostic value is a big part of why sequencing metrics matter. They are not just there to catch failed samples. They help you understand assay behavior, library quality, alignment artifacts, enrichment performance, and process drift over time. They are useful for immediate troubleshooting, but they are also useful for comparing projects, building quality systems, improving operations, and building better models of sample and pipeline performance.

Fast enough to run every time

Once you accept that QC should be run on every sequencing dataset, performance comes to the forefront of importance.

Older tooling made it too easy to compromise. When metrics take too long, people start trimming the workflow. They run fewer collectors, or reserve deeper QC for troubleshooting. Over time, that gives you an inconsistent picture of the data and makes it harder to catch process drift.

I wanted to remove that friction.

Riker is written in Rust because this kind of systems work benefits from speed, efficiency, and tighter control over performance. But the goal was never just to make Picard faster in a newer language. The real goal was to make routine metrics collection cheap enough that the right default becomes obvious: run in depth QC every time.

That only matters if the outputs deserve confidence, so I also went back through the metrics themselves. I fixed issues, cleaned up implementations, and updated calculations and assumptions where the older logic no longer matched current sequencing practice or current biological understanding.

Riker is faster, but it is also a chance to revisit what these metrics should be doing for people now.

Why using AI here makes sense

There is a lot of justified scrutiny right now around the compute and energy cost of AI. These are real, worthwhile questions. A lot of energy is likely being spent on work that will be forgotten in a week.

But sequencing QC is a different category of problem.

Using AI to help build a foundational tool that will be run thousands or millions of times across real sequencing workflows is a productive use of compute. If that work produces software that is materially more efficient than what came before, the savings compound every time someone runs it. Every faster execution, every reduced resource requirement, every workflow that no longer carries legacy overhead adds up. Not to mention that catching QC problems sooner can massively reduce waste on the wetlab side.

I do not find the argument compelling that we should worry about the compute used to build better infrastructure while ignoring the repeated waste of running slower, aging infrastructure at scale. If a focused use of AI helps produce software that saves far more compute over its lifetime than it consumes during development, that is a trade worth making.

Riker clears that bar.

There is no excuse to skip in depth sequencing QC

Sequencing QC metrics are useful, signal rich, and cheap enough to run routinely when the tooling is built for it. They help you understand not just whether something went wrong, but why. They support troubleshooting, operations, and machine learning. And they become more valuable when they are collected consistently across every dataset instead of only when someone suspects a problem.

That is the standard behind Riker.

If you generate sequencing data, you should be collecting rich QC metrics on every dataset. The information is too useful, and the cost of collecting it is now too low, to justify treating it as optional.

🔗 https://github.com/fulcrumgenomics/riker

At Fulcrum Genomics, we care a lot about what happens before variant calling: how samples are collected, stored, and prepared. A single artifactual C>T mutation in the wrong place can look identical to a cancer driver mutation. If sample storage and preservation introduces thousands of these artifacts, no amount of downstream pipeline tuning will fix it.

“Identifying and eliminating sources of error has been central to Fulcrum’s work since our inception,” said Nils Homer, Founding Partner at Fulcrum Genomics. “This work shows that ensilication can preserve samples at room temperature while actually reducing the artifacts that complicate variant interpretation.”

Why DNA Storage Still Matters

Today, most nucleic acid preservation depends on cold storage, typically from −20 °C to −80 °C, and sometimes even colder. That infrastructure is expensive, energy-intensive, and hard to scale globally. As precision oncology and population genomics expand, we need preservation methods that don’t require a dense network of ultra‑low temp freezers and the associated cold chain.

As Michael Becich, CEO of CacheDNA, puts it: “The first era of genomics was built on cold storage. The next belongs to elegant biochemistries that preserve truth at the molecular level without ongoing energy or intervention. Every sample tells a story, and we believe that if a sample can be collected, it should be carefully protected until ready for testing. We’re building the bridge that makes modern biopreservation possible to reveal those insights.”

Ambient-temperature solutions like Cache DNA’s ensilication are promising, but they must clear a high bar:

• Maintain clinical variant detection

• Avoid introducing artifactual mutations

• Preserve DNA integrity across temperatures and time

This study tackles those questions directly using clinical FFPE tumor samples, targeted mutation assays, and deep whole‑genome sequencing.

What the Study Shows

The study evaluates ensilication side-by-side with standard −80 °C storage across multiple dimensions:

Clinical panels showed perfect concordance.

Lung cancer DNA extracted from FFPE blocks was split, stored either frozen or ensilicated at room temperature for 14 days, and then tested using a routine clinical panel. Across ten samples, there was 100% diagnostic concordance between storage methods, including low VAF variants down to ~2%, meaning no gained or lost actionable mutations after 14 days of storage.

Whole‑genome sequencing revealed frozen storage introduced more artifacts.

For 32 matched tumor–normal pairs, DNA aliquots were stored frozen (−80 °C) or ensilicated at room temperature for 28 days and then sequenced (30x normal, 80x tumor). Overall sequencing metrics, including insert sizes, chimera rates, duplication rates, and library complexity, were comparable between storage conditions, enabling direct comparison of storage-induced mutations.

Frozen −80 °C storage of FFPE tumor DNA generated substantially more artifactual C>T mutations than ensilication at room temperature, increasing background ‘noise’ that can mimic true cancer variants.

The key finding: frozen storage accumulated substantially more artifactual C>T mutations in tumor DNA than ensilication, particularly in CpG contexts. Frozen samples showed up to 65% more C>T substitutions per million bases than ensilicated samples, adding thousands of apparent mutations that are indistinguishable from true somatic events. These artifacts are especially concerning at clinically relevant CpG sites frequently mutated in cancer.

Ensilication worked across DNA shapes and extreme temperature ranges.

The study examined both linear ssDNA and circular ssDNA (cssDNA) libraries across a range of temperatures (−80 °C to 37 °C) with and without ensilication over 20 days. Circular libraries showed strong inherent stability even unprotected, while linear DNA benefited markedly from encapsulation, with ensilicated linear samples outperforming unprotected controls across every tested temperature.

Across −80 °C to 37 °C, circular ssDNA libraries remained highly stable, and ensilication markedly improved the stability of linear ssDNA, while all conditions still supported accurate detection of ~5% variants.

Importantly, even where some loss of amplifiable molecules occurred, variants above 5% VAF remained accurately detectable in all conditions and topologies.

Fulcrum Genomics’ Contributions

Fulcrum’s role in this work was to make the storage comparison quantitative at whole‑genome scale, not just qualitative at a few loci. This included:

• Processing and aligning whole‑genome data from matched tumor–normal pairs, ensuring that differences between storage methods weren’t confounded by pipeline noise.

• Calling and filtering somatic variants to separate true tumor mutations from storage-induced artifacts that could affect downstream interpretation.

• Analyzing and visualizing substitution rates and sequence context to reveal the characteristic patterns of damage associated with frozen vs. ensilicated storage.

By standardizing these analyses across all samples, we were able to show not just that ensilication preserves clinical calls, but also how different storage conditions reshape the apparent mutation landscape, especially the excess C>T artifacts seen in frozen FFPE tumor. That level of detail is critical for applications like tumor mutational burden, signature analysis, and regulatory decision‑making.

“Our goal has always been maximum sensitivity without sacrificing accuracy for clinical decision-making. This work with Cache DNA represents a significant step in that direction, showing Cache DNA’s ensilication technology can preserve samples at room temperature while actually reducing the artifacts that complicate variant interpretation,” said Homer.

This kind of artifact‑aware, whole‑genome benchmarking is a natural extension of our work: helping teams understand not only what their sequencing data says, but how upstream choices—from preservation through library prep—shape the answers they get.

Working with James Banal, Co-Founder of Cache DNA, and the broader team was a model collaboration. Their rigorous experimental design made the computation analysis straightforward to interpret and the findings unambiguous.

Implications for Genomic Medicine

The findings suggest that ambient ensilication can match or outperform −80 °C storage in preserving sequencing fidelity, at least over the timeframes evaluated. That matters for:

Clinical oncology – Reducing storage-induced artifacts lowers the risk of false-positive somatic calls, especially in FFPE samples where C>T damage is already endemic. This study directly evaluated clinically relevant genomic biomarkers to ensure downstream clinical decisions rest on robust data.

Regulatory and biomarker development – Artifact-aware preservation supports reliable measurement of tumor mutational burden, mutational signatures, and subclonal architecture. Removing temperature requirements also opens opportunities for global drug development programs that rely on sample transit to centralized labs.

Global and decentralized genomics – Ambient storage reduces cost and infrastructure barriers, making it feasible to collect and ship samples from remote or resource-limited settings without sacrificing data quality.

Of course, more work is needed: multi‑year studies, diverse tissue types, and broader operational and economic analyses will be important to understand where ambient methods can replace or complement cold storage at scale. But this study provides strong, whole‑genome evidence that ensilication is a viable path toward cold‑chain‑free genomic medicine.

At Fulcrum Genomics, we’re glad to partner with teams like Cache DNA on this kind of foundational work where careful computational analysis helps clarify not just what variants we see, but why we see them, and whether they’re real.

As ensilication and other ambient preservation methods mature, we’re committed to bringing the same rigor to evaluating them that we’ve applied to library preparation, sequencing platforms, and variant calling. Because genomic medicine is only as good as the samples it starts with.

📖Read the paper:
Evaluation of ensilication technology for ambient DNA preservation

💻Code and data:
Analysis code is available at Zenodo (10.5281/zenodo.17469053); sequencing data will be deposited to EGA upon publication.

Years ago, when UMIs were becoming standard in high-accuracy sequencing workflows, we (Fulcrum co-founders Tim Fennell and Nils Homer) built fgbio to handle extraction, grouping, consensus calling, and the mechanics required to make error-corrected sequencing practical. It became widely adopted across research and clinical pipelines, and we’ve maintained it ever since.

And eventually, we ran into its limits.

Amplicon panels grew. Some assays began stacking hundreds of UMIs at a single locus with thousands of reads in a group. Error-corrected sequencing moved beyond small panels into exomes and other much larger datasets.

Tim describes what that looked like in practice:

“When dealing with amplicon sequencing with hundreds of UMIs at the same location and many thousands of reads, runtime just explodes. Some of the algorithms you’d like to use become infeasible.”

The underlying issue was straightforward. fgbio is single-threaded. It was written at a time when that design choice wasn’t a major limitation.

As Nils puts it:

“Error-corrected sequencing used to run on small targeted panels, and fgbio could handle that in minutes. As the field moved to exomes, those same tools went from minutes to hours.”

Around the same time, Tim and Nils were seeing accelerated UMI tools appear in commercial products, often referencing fgbio’s behavior.

“If anyone was going to build a faster implementation,” Tim says, “we felt like it should probably be us.”

That work became fgumi.

What fgumi focuses on

fgumi covers the core pieces of a UMI workflow:

• Extract UMIs directly from FASTQ files

• Group reads by UMI

• UMI-aware deduplication

• Consensus calling (simplex, duplex, and CODEC)

• Filtering and metrics generation

The overall structure will look familiar if you’ve worked with fgbio or pipelines like nf-core/fastquorum.

The intention was to preserve the way these pipelines already operate.

Tim explains the constraint that guided most design decisions:

“It really needed to be a drop-in replacement for fgbio for the main workflows. If moving to fgumi required a lot of work or changed how the tools behaved, adoption would be hard.”

Nils frames the priorities this way:

“Equivalency first, performance second, scope third.”

Each tool in fgumi is expected to produce the same results as the corresponding tool in fgbio. During development, this comparison surfaced small areas of non-determinism in fgbio itself, which were corrected there as well.

After outputs matched, performance work began in earnest. Rewriting in Rust allowed multi-threading and more direct control over memory usage and concurrency.

The project also kept a fairly tight scope.

“fgbio does a lot of things beyond UMI processing,” Nils says. “fgumi focuses on the core UMI tools and nothing else.”

Even sorting functionality was implemented directly so that the full processing path could be controlled and tuned.

On our deepest benchmark dataset, the full consensus pipeline, from extraction through consensus calling and filtering, completes in about 70 seconds compared to 30 minutes in fgbio, roughly a 25x speedup.

Building the rewrite

fgbio was built incrementally over many years, with Tim and Nils reviewing essentially every line of code.

fgumi was developed differently.

Some of the development work was done with the help of AI-assisted coding tools. Reviewing every line at the same level wasn’t practical at that pace.

Nils describes the adjustment:

“Letting go of reviewing every line was probably the hardest tradeoff.”

Confidence instead came from testing and validation.

fgbio itself served as the reference implementation. The large unit-test suite that had accumulated over the years was ported across. Automated review tools checked pull requests, and vendor partners provided real assay datasets for validation.

“The safety net was deep,” Nils says. “fgbio was always there as a reference, and the tests tell you whether the outputs match.”

What this should enable

The immediate impact of fgumi is runtime. Multi-threading and implementation changes make a large difference when grouping and consensus calling have to operate across very deep datasets.

That matters for several reasons.

Clinical pipelines often rely on error-corrected sequencing and have tighter turnaround requirements. Faster UMI processing also reduces compute cost when running large numbers of samples. And certain research workflows, such as large ecDNA studies, become easier to scale.

Looking further ahead, Nils hopes the practical limitations simply fade away:

“Five years from now, nobody should have to think twice about running error-corrected sequencing on a whole genome at ultra-deep coverage. The answer should just come back fast, and it should be right.”

Current status

fgumi is currently in alpha. The toolkit is functional and is being tested across a variety of vendor-provided datasets.

The team is targeting June 1, 2026 as the point when fgumi can be recommended over fgbio for production use.

We’ve also published documentation that includes:

• A best practice pipeline from FASTQ to filtered consensus reads

• A performance tuning guide for threading and memory

• A reference Snakemake implementation

• Tools for simulating UMI data and for comparing output files

The code is open source under the MIT license.

fgumi grows directly out of the same work that produced fgbio: building and maintaining UMI workflows in real sequencing projects.

If you’re already using UMI-based sequencing in your workflows, we encourage you to take a look at fgumi and see how it fits your use cases. The code is open source, the documentation is available, and your feedback will help guide the project as it matures toward production readiness.

🔗 https://github.com/fulcrumgenomics/fgumi

Last year we received an email from a client struggling with exactly this problem. They had downloaded what they believed was the right reference FASTA from UCSC, 455 contigs, but the BAMs they were trying to work with had been aligned to a reference with 595 contigs. Contigs like chr11_KZ559110v1_alt appeared in the BAM headers but were nowhere to be found in the downloaded FASTA. After some sleuthing, the culprit turned out to be a specific GRCh38 patch release. Close, but not the same, and in genomics, “close but not the same” can silently corrupt an entire analysis.

This is a problem we’ve hit repeatedly in client work over the years, and it’s surprisingly hard to solve cleanly. Grepping the header for a version comment works maybe half the time. MD5-checking sequences requires having the right sequences to check against. Asking the data provider what reference they used is often met with a shrug or a filename. And trial-and-error alignment is expensive and frustrating.

So we built something better.

Introducing ref-solver

ref-solver is a tool that identifies which human genome reference a file is associated with by comparing its sequence metadata, contig names, lengths, and ordering, against a curated catalog of known references. Crucially, it never looks at the actual sequence data. That makes it fast, lightweight, and appropriate even for sensitive datasets where you wouldn’t want to upload raw sequences to a third party.

The tool accepts a wide range of input formats: SAM/BAM/CRAM headers, .dict files, .fai index files, or a full FASTA. It extracts the sequence dictionary and scores it against the catalog, returning a ranked list of the closest matching references, down to the specific patch release.

You can use it two ways:

• Web app: Head to whatsmygenome.fulcrumgenomics.com, paste or upload your file, and get an answer in seconds. No installation, no accounts, nothing to configure.

• Command line: Install via Bioconda (conda install ref-solver) for integration into pipelines and automated workflows.

How It Works

The core idea is simple: two files derived from the same reference genome will have matching sequence dictionaries, the same contig names, the same lengths, in the same order. Different reference versions, sources, or patch releases will differ in at least one of those dimensions.

ref-solver builds a fingerprint from the sequence dictionary and compares it against a catalog that covers the major human genome reference flavors: UCSC (hg19, hg38), NCBI/Ensembl (GRCh37, GRCh38), Broad bundle releases, T2T-CHM13, and a range of GRCh38 patch releases from p1 through p14. When an exact match exists, you get a definitive answer. When the match is partial, for example, a BAM that was aligned to a reference with a subset of the catalog’s contigs, ref-solver returns a similarity score so you can identify the closest known reference and understand what’s missing or different.

When This Matters

The most obvious use case is provenance recovery: you have a BAM and you need to know what it was aligned to before you can do anything useful with it. This comes up constantly when working with legacy datasets, public repositories, or data shared between institutions where documentation is incomplete.

But it’s equally valuable as a validation step in active pipelines. Before you run variant calling or any reference-dependent analysis, you want to confirm that the FASTA you downloaded from UCSC last Tuesday is actually what you think it is. Reference files get updated, mirrors can serve stale content, and download errors are real. Spending thirty seconds running ref-solver before kicking off a multi-day pipeline is cheap insurance.

It’s also useful in multi-site studies or collaborations where different groups may have independently downloaded “the same” reference from different sources, UCSC versus Ensembl versus a Broad bundle, and ended up with subtly different files that will cause headaches downstream when you try to merge or compare results.

Try It

If you have a BAM, CRAM, FASTA, .dict, or .fai lying around whose exact provenance you’re not 100% certain of, give it a try at whatsmygenome.fulcrumgenomics.com. The web app takes seconds and requires nothing but the file.

The source code is on GitHub at fulcrumgenomics/ref-solver, and contributions, especially additions to the reference catalog, are very welcome. If there’s a reference build you’d like to see covered, open an issue or submit a PR.

Reference genomes are the foundation everything else is built on. Getting them wrong quietly is far worse than failing loudly.

Every genetic variant reported in a clinical laboratory has a precise, standardized name. It looks something like NM_000249.4:c.350C>T, and what it communicates is specific: in the MLH1 gene, at position 350 of the coding sequence, a cytosine changes to a thymine. That compact string is how clinical labs communicate findings to each other, how oncology reports describe mutations, and how hundreds of millions of records in global databases like ClinVar are stored, retrieved, and compared.

This naming system is called HGVS nomenclature, named for the Human Genome Variation Society that maintains it. It is the backbone of clinical genomics, used in hereditary cancer panels, rare disease diagnosis, pharmacogenomics testing, and variant database submissions worldwide. The software tools that process HGVS strings are infrastructure that the field depends on every day, often without thinking about it.

Fulcrum Genomics is releasing ferro-hgvs (v0.1.0), a new open-source HGVS parser and normalizer written in Rust. ferro-hgvs is the fastest HGVS tool available by a wide margin, supports the broadest set of HGVS patterns of any open-source library, has been validated against millions of real clinical variants, and is accompanied by infrastructure that makes the tools you already use work better. A live web service at hgvs.acgt.bio lets you try everything described in this post with no installation required.

The HGVS Standard

The authoritative HGVS specification is maintained at hgvs-nomenclature.org by the HGVS Variant Nomenclature Committee (HVNC), a working group of the Human Genome Organization. The standard covers six coordinate systems: genomic (g.), coding DNA (c.), non-coding (n.), RNA (r.), protein (p.), and mitochondrial (m.). It defines rules for every variant type from simple substitutions to complex repeat expansions, and applies across multiple reference sequence types including NM_, NR_, NC_, NG_, LRG_, and NP_ accessions.

The standard has been evolving for decades. Beginning with version 21.0.0 in January 2024, the HVNC adopted semantic versioning and introduced formal computational grammar using Extended Backus-Naur Form (EBNF), improving both the precision of the specification and its implementability in software. A December 2024 paper in Genome Medicine (Hart et al.) summarizes these improvements.

The standard is also a living document. The HVNC manages changes through a public Community Consultation process, where proposed extensions and clarifications are published for open community comment before ratification. These proposals matter because many of them describe patterns that already appear in real clinical data, in ClinVar submissions, lab reports, and variant databases, before they are formally adopted. A tool that does not track these proposals will reject or mishandle variants that clinical teams encounter every day.

ferro-hgvs supports all ratified consultation proposals, including SVD-WG001 (reporting variants confirmed to be unchanged, such as c.1823A=, important for negative findings in clinical reporting), SVD-WG002 (non-coding DNA reference sequences with the n. prefix), SVD-WG004 (the ISCN/HGVS named extension for structural variants and chromosomal rearrangements), SVD-WG009 (the discontinuation of the conversion variant type), and the accepted proposal for circular reference sequences such as the mitochondrial genome. Beyond ratified proposals, ferro parses patterns corresponding to open consultation topics including distance-between-variants notation (SVD-WG010), handling the kinds of strings that appear in real data even where the specification is still evolving.

Why HGVS Parsing Is Harder Than It Looks

Not all variants are simple single-letter substitutions. The notation covers deletions, insertions, duplications, deletion-insertions (delins), inversions, frameshifts, tandem repeat expansions, uncertain positions, and compound variants, each with distinct rules for formatting and normalization. Protein notation adds three-letter amino acid codes, stop codon representations, extension variants, and uncertain amino acid ranges on top of that.

One of the most clinically significant challenges is intronic variant handling. Many of the most important variants in clinical genetics fall at splice sites, the boundaries between coding exons and non-coding introns, because disrupting splicing often destroys gene function entirely. These variants use an offset notation such as NM_000249.4:c.117-2del, which describes a deletion two bases before the start of exon 12 in MLH1 (a classic splice acceptor variant). Processing these correctly requires knowing not just the transcript sequence but how the transcript maps back to the genome. This is a step that most HGVS tools either skip entirely or handle only through opaque workarounds.

Normalization is a separate challenge from parsing. The same indel near a repetitive region can be written in dozens of equivalent but non-identical ways, and normalization is the process of resolving all of them to a single canonical form. This matters enormously for matching variants across databases, deduplicating records, and submitting to ClinVar, where a non-normalized form may fail submission or be treated as a novel variant. A simple example: NM_000249.4:c.1852_1853delAA normalizes to NM_000249.4:c.1852_1853del, because the explicit deleted sequence is redundant under HGVS guidelines.

Finally, HGVS strings in the real world frequently deviate from the formal specification. Clinical labs, VEP annotators, legacy databases, and manual curators have produced decades of HGVS strings that use lowercase amino acids, omit version numbers, use informal shorthand, or reflect older versions of the standard. A production tool for clinical genomics needs to handle these gracefully, with configurable behavior, rather than simply rejecting them.

The Current Tool Landscape

Three main tools are currently in wide use for HGVS parsing and normalization: mutalyzer (from Leiden University Medical Center), biocommons/hgvs (the Python reference implementation), and hgvs-rs (a Rust port of biocommons). All three are valuable contributions to the field, and ferro-hgvs builds on the work they represent.

Speed is the most visible limitation. All three tools run at roughly 20 variants per second or fewer when operating locally. In network-dependent mode, which biocommons and mutalyzer require for some operations by default, throughput drops to 0.2 to 1 variant per second. At those rates, processing a complete ClinVar export of over one million variants takes days. For real-time annotation in clinical pipelines, or for researchers running large cohort studies, this is a genuine bottleneck.

Coverage gaps compound the speed problem. The table below shows validation (V) and normalization (N) support across the four tools, as tested live at hgvs.acgt.bio. The most significant gap is intronic c. coordinate normalization, a category that covers a large fraction of clinically actionable splice-region variants. hgvs-rs can validate these but cannot normalize them. biocommons can normalize them but requires a running UTA database. mutalyzer handles them by rewriting to genomic coordinates behind the scenes. Only ferro normalizes them natively and transparently.

Table 1: HGVS Feature Support by Tool (V = validate, N = normalize, V/N = both)

Operational complexity is an additional barrier. biocommons requires a running UTA PostgreSQL database and SeqRepo, a locally stored sequence repository. Configuring and containerizing these dependencies for reproducible clinical pipelines takes significant effort. The end result is that teams often fall back to network-dependent operation, which sacrifices both speed and reproducibility.

Introducing ferro-hgvs

ferro-hgvs is written in Rust and uses nom, a well-established Rust parsing library, to implement zero-copy parsing of HGVS strings. Variants are parsed without allocating intermediate string representations, which contributes to the tool’s throughput and makes it suitable for memory-constrained environments. The parser produces a typed abstract syntax tree that covers every valid HGVS form, giving downstream code precise, structured access to every component of a variant without manual string manipulation.

The name follows Fulcrum’s growing Rust-based genomics toolchain, where “ferro” (iron in Latin and Spanish) reflects the language’s reputation for performance and reliability. This is the same philosophy that produced fgumi, Fulcrum’s Rust port of fgbio’s UMI-handling tools.

Performance

ferro-hgvs parses approximately 4 million HGVS patterns per second and normalizes approximately 2.5 million variants per second, all offline after a one-time reference data preparation step. The table below compares performance against existing tools. The speedups are large enough that they change what is computationally feasible: a normalization run over all of ClinVar that would take days with existing tools takes minutes with ferro-hgvs.

Table 2: Normalization Performance Comparison

Error Handling

ferro-hgvs provides three configurable error modes to match different workflow needs. Strict mode rejects any non-conformant input and is appropriate for validation pipelines where every variant must be checked carefully. Lenient mode auto-corrects common deviations (for example, converting the lowercase p.val600glu to the correctly capitalized p.Val600Glu) while emitting warnings, which is useful for batch processing real-world data. Silent mode applies the same auto-corrections without logging warnings, useful when processing large legacy datasets where noise from formatting issues would obscure other information.

Error and warning behavior can be tuned per-code through a .ferro.toml configuration file, and the ferro explain command provides plain-English explanations for every error and warning code, making it practical for teams to understand and act on quality issues in their variant data.

Tested Against the Real World

Performance numbers only matter if the tool is correct. ferro-hgvs has been validated against multiple large corpora of real HGVS data, and the testing strategy was designed to leave as few gaps as possible.

ClinVar and major variant databases. ferro-hgvs has been run against the full ClinVar database, over one million HGVS strings spanning decades of submissions from clinical laboratories worldwide. ClinVar contains variants from every major gene, disease area, and variant type, including many edge cases and historically inconsistent notations that accumulate in any large curated database. In addition to ClinVar, the tool has been validated against variant sets from gnomAD, LOVD (the Leiden Open Variation Database), and other major genomic resources, representing the full breadth of HGVS usage across research and clinical communities.

VEP-annotated VCFs. The Variant Effect Predictor (VEP) is the most widely used annotation tool in genomics, and its HGVS output appears in tumor sequencing reports, population studies, and research publications at scale. VEP-annotated HGVS strings frequently deviate subtly from the formal specification in ways that are predictable but that naive parsers reject. ferro-hgvs has been validated extensively against VEP outputs specifically because they represent the kind of real-world data that clinical pipelines encounter most often.

Client pipeline data. Fulcrum Genomics works with biotech and clinical genomics teams across oncology, rare disease, and pharmacogenomics. That work has produced a large internal corpus of HGVS strings from diverse laboratory platforms, annotation tools, and reporting systems, which directly informed the edge cases ferro was designed to handle. Real production data surfaces failure modes that no synthetic test suite can fully anticipate.

Borrowed test suites from competing tools. One of the most rigorous validation steps was incorporating the test suites from mutalyzer, biocommons/hgvs, and hgvs-rs directly into ferro’s testing framework. These are the carefully curated sets of specific variants, tricky edge cases, and known failure modes that each tool’s development team built and refined over years. By running ferro against all of them and checking that it produces equivalent or better results, we can confirm that ferro’s correctness is at least as strong as each competing tool in their own strongest areas. Where ferro and another tool produce different outputs, the comparison is surfaced explicitly, which is itself useful information for the community about where implementations diverge and why.

Fuzz testing. ferro-hgvs includes a fuzz testing harness that generates millions of pseudo-random HGVS-like strings to find crashes, panics, and unexpected behavior at the parser boundary. This kind of robustness testing is rare in bioinformatics software and helps ensure that ferro does not fail silently or unpredictably when it encounters malformed input, which is a common occurrence when processing data from heterogeneous clinical sources.

Better Infrastructure for the Whole Ecosystem

One of the most time-consuming aspects of running any HGVS tool locally is assembling the reference data it needs: transcript sequences, genome assemblies, transcript-to-genome mappings, and protein sequences. Getting this data, keeping it versioned, and making it available to tools in the right formats is work that every team running HGVS software has to do independently.

The ferro prepare command solves this once. It downloads and organizes the complete reference dataset needed for comprehensive HGVS normalization from authoritative sources (NCBI, EBI, and MANE), validates the downloads, and structures them in a format that ferro can use offline without any network access during normal operation. The dataset totals approximately 6 GB:

Table 3: Reference Data Prepared by ferro prepare

Crucially, this reference dataset is not ferro-proprietary. The same data is shared with mutalyzer, biocommons/hgvs, and hgvs-rs, enabling all of them to run fully offline with consistently versioned, high-quality reference data. Teams that continue to use existing tools can still run ferro prepare once and immediately benefit from better-quality local reference data for all of their HGVS workflows.

A related community contribution is the ferro-benchmark harness. mutalyzer, biocommons, and hgvs-rs are all single-threaded by design, which limits how quickly they can process large variant sets even on multi-core hardware. The benchmark harness parallelizes all of them across CPU cores, dramatically improving their throughput for large validation and benchmarking runs. The ferro-benchmark compare results command then surfaces disagreements between tools variant-by-variant, making tool differences visible and actionable. This infrastructure is available to anyone running tool evaluation or validation studies, regardless of whether they adopt ferro as their primary tool.

Try It Now: hgvs.acgt.bio

The fastest way to experience ferro-hgvs is the live web service at hgvs.acgt.bio. No account, no installation, and no configuration is required. Paste any HGVS variant and see results in seconds. The service is backed by ferro-hgvs and exposes its full feature set through a tabbed interface, along with a REST API for programmatic access.

Multi-tool normalization and comparison. The normalize tab runs any HGVS string through ferro, mutalyzer, biocommons, and hgvs-rs simultaneously and displays their outputs side by side. The service detects agreement and disagreement automatically, shows processing time per tool, and provides a detailed component breakdown from ferro showing reference, coordinate system, variant type, position, and whether shifting occurred during normalization. Batch mode accepts a list of variants for processing all at once. This is a useful diagnostic for teams evaluating tools or investigating why a variant is producing inconsistent results across systems.

Coordinate conversion. The convert tab translates variants between coordinate systems: c. to g., g. to c., c. to p., and n. to g. Provide a coding variant like NM_000249.4:c.350C>T and retrieve the equivalent genomic position on GRCh38, or calculate the protein consequence. An option to return all conversions across all mapped transcripts at once is available for variants where multiple transcripts are relevant.

Variant effect prediction. The effect tab predicts variant consequences using standardized Sequence Ontology (SO) terms: splice_site_variant, frameshift_variant, inframe_deletion, missense_variant, stop_gained, and others. Each prediction includes an impact level (HIGH, MODERATE, LOW, or MODIFIER) and optionally a prediction of whether a truncating variant would trigger nonsense-mediated mRNA decay (NMD), a key factor in determining whether a premature stop codon produces a loss-of-function outcome.

Genomic liftover. The liftover tab converts coordinates between GRCh37 (hg19) and GRCh38 (hg38) in either direction. It accepts both raw chromosome positions (chr7:117120148) and HGVS genomic notation (NC_000007.13:g.117120148) and returns the lifted position, the equivalent HGVS g. string, and the relevant chain region.

VCF conversion. The VCF tab handles bidirectional conversion between HGVS and VCF format. Convert a genomic HGVS variant to VCF fields (CHROM, POS, REF, ALT), or provide VCF fields and optionally a transcript accession to receive the g., c., and p. HGVS representations in a single step.

REST API. Every operation is also available via a REST API for integration into existing pipelines: POST /api/v1/normalize, /api/v1/batch/normalize, /api/v1/convert, /api/v1/effect, /api/v1/liftover, /api/v1/hgvs-to-vcf, and /api/v1/vcf-to-hgvs. All endpoints return JSON with results, processing time, and any errors or warnings. A /api/v1/validate endpoint runs ferro-only syntax checking without requiring reference data. The /health/detailed endpoint exposes the live status of all four tools and a pass/fail matrix for a built-in set of test variants.

A good starting point is to paste NM_000249.4:c.117-2del (an MLH1 splice acceptor deletion) into the normalize tab with all four tools selected. The results make the coverage difference between tools immediately visible.

Getting Started

Bioconda (recommended for most users). A Bioconda recipe is in review (PR #62795) and will be available shortly. Once merged, installation is:

conda install -c bioconda ferro-hgvs

The Bioconda build includes the benchmark and hgvs-rs comparison features. After installation, run ferro prepare --output-dir ferro-reference once to download reference data, then ferro normalize to start processing variants.

Rust library. Add to your Cargo.toml:

ferro-hgvs = “0.1”

CLI (via cargo). cargo install ferro-hgvs installs the ferro binary directly.

Python. A Python package backed by PyO3 bindings is available via pip install ferro-hgvs, providing Rust-level performance from Python code.

Web service. hgvs.acgt.bio requires no installation at all and is the quickest way to evaluate the tool.

Current Status and What Is Coming

ferro-hgvs v0.1.0 is alpha software. The parser and normalizer have been extensively validated against real clinical data, but the API is not yet stable and should be expected to evolve. The alpha designation reflects the early stage of the project, not the level of testing behind it.

Known gaps in the current release: protein (p.) and RNA (r.) normalization are validate-only in v0.1.0, repeat expansion normalization is not yet implemented, and Ensembl (ENST) transcript accessions are not supported. All of these are on the roadmap. p. and r. normalization and ENST support are the near-term priorities.

Issue reports and pull requests are welcome at the ferro-hgvs GitHub repository. Real-world HGVS strings that produce unexpected results are among the most valuable contributions the community can make. Contact Fulcrum Genomics to discuss production deployments, custom integrations, or sponsoring specific feature development.

Closing Thoughts

A variant name is only as useful as the software that can reliably parse, normalize, and compare it. When tools disagree with each other, or when they quietly fail on patterns that appear constantly in clinical data, that uncertainty propagates through pipelines, reports, and databases in ways that are hard to detect and harder to correct.

ferro-hgvs is built against the living HGVS specification at hgvs-nomenclature.org, validated on the largest and most diverse HGVS corpora we could assemble, and designed to raise the floor for the whole ecosystem rather than just replace individual tools. We hope it is useful to the community and look forward to hearing how people are using it.

Start with hgvs.acgt.bio. Paste a variant you care about. See what all four tools say.

Resources

Web service: hgvs.acgt.bio

GitHub: github.com/fulcrumgenomics/ferro-hgvs

Rust crate: crates.io/crates/ferro-hgvs

API docs: docs.rs/ferro-hgvs

HGVS specification: hgvs-nomenclature.org/stable

Community consultation proposals: hgvs-nomenclature.org/stable/consultation

Fulcrum Genomics: fulcrumgenomics.com

Every bioinformatics tool I’ve written over the past two decades has had the same job: take biological data in, produce a result out. Align reads. Call variants. Build consensus sequences. And over the years, I’ve learned (sometimes the hard way) that the primary output alone is never enough. You need QC metrics. You need debug output. You need the evidence trail that lets you and your users understand what happened and why. I’ve put a lot of work into making tools like fgbio produce rich, useful metrics at every step, and it has consistently paid off.

But I’ve been designing those metrics for humans. For a scientist staring at a MultiQC report, or for myself trying to track down a subtle bug. The question I keep coming back to is: what if that same data were structured and complete enough to train a model?

We are in the middle of two big shifts in how bioinformatics gets done. First, AI research and coding assistants are not just writing code; they are reasoning about experimental designs, interpreting analysis results, and proposing next steps. They are becoming junior scientists in our labs. Second, machine learning is eating every problem where sufficient training data exists. In genomics, we have oceans of data. Both shifts demand that we rethink how we design bioinformatics tools.

I want to make a simple argument: every new bioinformatics tool and method you write should be AI-ready. AI assistants need to work with your code, your outputs, and your analysis logic. Machine learning needs to train on the rich data your tools produce. If you’re not gathering this data as you go, you’re leaving value on the table.

Halfway there

The idea that tools should produce rich, structured metrics is not new. Picard, developed at the Broad Institute (and originally written by my co-founder Tim Fennell, and I later helped maintain along with htsjdk), was doing this over a decade ago. CollectAlignmentSummaryMetrics, CollectInsertSizeMetrics, CollectWgsMetrics, MarkDuplicates: the Picard philosophy was that every tool should emit detailed, structured metrics alongside its primary output. That approach shaped how Tim and I thought about tool design when we founded Fulcrum Genomics and built fgbio.

In fgbio, when we call consensus reads from UMI-tagged data, we compute a lot of information along the way and capture much of it in BAM tags and metrics files. CollectDuplexSeqMetrics alone produces eight output files, continuing that Picard tradition.

That makes tools like Picard and fgbio halfway AI-ready. The data is there. The metrics exist. But they were designed for human interpretation: summary tables, aggregate statistics, plots you eyeball. They weren’t designed to be feature vectors that a model can ingest at scale across thousands of samples. The gap between “useful QC” and “ML-ready features” is smaller than most people think, but it’s real, and closing it requires intentional design.

Most tools don’t even get halfway. Your aligner gives you a BAM with mapping qualities, but not the distribution of sub-optimal alignments it considered. Your variant caller gives you a VCF with QUAL scores, but not the per-site feature vectors that went into that decision. All of that discarded information is training data for models you haven’t built yet. In the ML engineering world, they call this “data exhaust”. In bioinformatics, we are incinerating ours.

Two kinds of AI-ready

When I say “AI-ready,” I mean two things.

Your tools need to be legible to AI. Not just to coding assistants that autocomplete your Python, but to AI agents acting as junior scientists in your lab: designing analyses, interpreting outputs, proposing hypotheses, troubleshooting failures. A tool with clean APIs, consistent output formats, well-documented parameters, and structured logs is a tool not only useful to humans but also a tool an AI scientist can reason about. A tool that dumps cryptic column names and unstructured stderr is hostile to humans and AI alike.

This is already a real problem. The emerging field of “agentic bioinformatics“ (Phan et al. 2025) is running headfirst into inconsistent interfaces and poorly documented outputs, as tools like BioAgents (Li et al. 2025), AutoBA (Fan et al. 2024), and MCPmed (Li et al. 2025) all demonstrate. Our tools were built for humans reading man pages. The next generation of consumers won’t be human.

Your tools also need to be generative with metadata. Every step in a pipeline is an opportunity to emit features: quality scores, distributional summaries, error profiles, alignment characteristics, signal-to-noise ratios. These aren’t just nice-to-have QC metrics. They’re input features for downstream ML models that can learn to make better decisions than your hand-tuned heuristics.

Where this matters most: filtering

If there’s one place where AI-ready output would have the most immediate impact, it’s filtering. Every domain in genomics has its own version of the signal-vs-artifact problem. HLA typing, where alignment ambiguity and allele-level read support bury the difference between right and wrong. MSI detection, where true microsatellite length changes hide behind polymerase stutter. SV calling, where split reads, discordant pairs, read depth changes, and assembly contigs form a multi-dimensional feature set that ML thrives on. Somatic variant calling, where the difference between a real low-frequency mutation and a sequencing artifact is a subtle pattern no single hard filter captures well.

In all of these cases, the path to better filtering is the same: emit the features, not just the calls. Give downstream models (and downstream scientists, human or AI) the evidence they need to find your false positives and recover your false negatives.

We already have existence proofs. DeepVariant (Poplin et al. 2018) works because the upstream pileup data, base qualities, mapping qualities, and strand information were already captured in a structured format, enabling a CNN to outperform hand-tuned statistical models (Barbitoff et al. 2022). GATK’s VQSR works because the variant caller emits rich per-variant annotations (QD, FS, SOR, MQ, MQRankSum, ReadPosRankSum) that a Gaussian mixture model can train on. If those callers had only emitted PASS/FAIL, neither approach would have been possible. The features are the product.

Prior art

I’m not the first person to think about this. Karpathy’s “Software 2.0” (2017) argued that neural networks shift the work from writing code to curating data; if Software 2.0 is coming for bioinformatics, our Software 1.0 tools need to emit the training data it will consume. Andrew Ng’s data-centric AI movement (2021) makes the case that the bottleneck is data quality, not model architecture. Most directly relevant is the NIH Bridge2AI program ($130M), whose Standards Working Group (Jain et al. 2024) defines AI-readiness criteria for biomedical data and observes that most data generated for other tools is not suitable for ML without significant rework. My argument is that we should stop generating unsuitable data in the first place.

The pushback

“You want me to 10x my output size for features nobody uses yet.” The marginal cost of emitting structured metrics alongside your primary output is small. Storage is cheap. Compute is expensive. You’re already doing the computation; I’m asking you to write down what you learned. The cost of not having this data when you need it is re-running everything, or discovering you can’t answer a question because the intermediate data is gone.

“I’ll add metrics when someone asks for them.” By then it’s too late. The value of these features comes from having them across large cohorts, computed consistently, from the beginning. Retroactively adding feature emission and re-processing thousands of samples is orders of magnitude more expensive than doing it right the first time.

Design principles

If I were writing a set of principles for AI-native bioinformatics tools:

Observable. Emit structured, semantically rich metadata at every step. Not just final answers, but the evidence trail. Per-read, per-site, per-family, per-molecule. Use well-defined tags, clear column headers, and machine-readable formats.

Composable. Consistent, well-documented interfaces that both humans and AI agents can discover, chain, and reason about. Standard formats. Clear help text. Predictable behavior. Outputs parseable by a post-doc who happens to be an LLM.

Trainable. Feature-rich representations that serve as training data for downstream ML. Emit the features, not just the conclusions.

The pitch

You’re already paying for the compute to run these analyses. The marginal cost of capturing richer output is small. Every time you run a pipeline without capturing intermediate features, you’re burning money twice: once on the compute you’re using now, and once on the compute you’ll need later to regenerate what you threw away.

I should be honest: AI is already changing how we work at Fulcrum Genomics. It has changed how we write code, how we review analyses, and how we think about tool design. We are adapting our business to leverage it, and we think every genomics organization should be thinking about the same.

But here’s what we keep seeing: AI makes expert bioinformaticians more productive, but it doesn’t replace the judgment needed to produce AI-ready data, design the right experiments, or know when the model is wrong. The gap between experts and everyone else is widening, not narrowing. You still need human experts to build the foundation that AI stands on.

For most of my career, the bottleneck has been doing the analysis: writing the pipeline, wrangling the formats, debugging the failures. AI is changing that. It handles the routine work. We get to spend more time on the science: asking the right questions and directing AI to explore the ideas. But the AI post-doc is only as good as the data you give it. With rich, structured features, it can spot batch effects in your consensus calling, flag GC-correlated false positives in your SV calls, catch allele balance inconsistencies in your HLA typing. With minimal, undocumented output, it’s working blind.

That’s what the fulcrum in our name has always meant: a small, well-placed point of leverage that amplifies force. AI is a lot of force. We’re here to help you apply it well.

The tools we build today will either be the foundation for tomorrow’s ML models, or they’ll be replaced by tools that are. I know which side of that I want to be on.

References

1. Barbitoff YA, Abasov R, Tvorogova VE, et al. Systematic benchmark of state-of-the-art variant calling pipelines identifies major factors affecting accuracy of coding sequence variant discovery. BMC Genomics. 2022;23(1):396. doi: 10.1186/s12864-022-08365-3

2. Fan J, Chen Z, Chen J, et al. AutoBA: An Autonomous Bioinformatics Agent. Bioinformatics. 2024. PMC11600294

3. Fennell T, et al. Picard: A set of command line tools for manipulating high-throughput sequencing data. Broad Institute. broadinstitute.github.io/picard

4. Homer N. fgbio: Tools for working with genomic and high throughput sequencing data. github.com/fulcrumgenomics/fgbio

5. Jain S, Neumann M, Goenaga-Infante H, et al. Defining AI-Readiness for Biomedical Data: Bridge2AI Standards Working Group Recommendations. Nature Scientific Data. 2024. PMC11526931

6. Karpathy A. Software 2.0. Medium. 2017. karpathy.medium.com/software-2-0-a64152b37c35

7. Li H, Wang Q, Wang Y, et al. BioAgents: Democratizing Bioinformatics Analysis with Multi-Agent Systems. arXiv. 2025. arxiv.org/html/2501.06314v1

8. Li Z, Zeng Y, Zhu X, et al. MCPmed: A Standardized Protocol for Biomedical Tool Integration with LLM Agents. arXiv. 2025. arxiv.org/html/2507.08055v1

9. Ng A. Why it’s time for data-centric artificial intelligence. MIT Sloan Management Review. 2021. mitsloan.mit.edu

10. Phan L, Gururajan S, Goh B, et al. Agentic Bioinformatics. Briefings in Bioinformatics. 2025;26(5):bbaf505. doi:10.1093/bib/bbaf505

11. Poplin R, Chang PC, Alexander D, et al. A universal SNP and small-indel variant caller using deep neural networks. Nature Biotechnology. 2018;36:983-987. github.com/google/deepvariant

Nils Homer is a Founding Partner at Fulcrum Genomics, where he builds bioinformatics tools and pipelines for the genomics community. He is the creator of fgbio and a co-author of the SAMtools paper. You can find him on LinkedIn or reach Fulcrum at contact@fulcrumgenomics.com

If you’ve worked with UMI-tagged sequencing data long enough, you already know the theory. Tag molecules early, group reads that came from the same original fragment, collapse them into a consensus, and dramatically reduce error. In theory, it’s straightforward.

In practice, it’s rarely clean.

UMI consensus workflows tend to grow organically: a script here to extract tags, another to sort and group reads, a carefully tuned command copied from a past project, plus a handful of assumptions that only live in someone’s head. The science is sound, but the implementation is fragile. Small changes in library structure, read layout, or scale can quietly break things. Or worse, corrupt results without anyone noticing.

That’s the gap fastquorum was built to close.

fastquorum is an nf-core pipeline built by Fulcrum Genomics that implements the fgbio FASTQ-to-consensus best-practice workflow in a way that’s reproducible, inspectable, and boringly consistent. It doesn’t invent a new approach to UMI consensus. It takes an approach many teams already intend to use and makes it reliable enough to trust across projects, people, and environments.

From “works once” to “works every time”

At a high level, fastquorum does exactly what you’d expect: it takes raw FASTQs, extracts UMIs, aligns reads, groups them by molecular family, and generates single-strand or duplex consensus reads. Quality metrics are captured along the way so you can see what’s happening, not just accept a final BAM on faith.

What matters more than the individual steps is that those steps are locked into a tested, versioned workflow. fastquorum runs under Nextflow using the nf-core framework, which means the same pipeline can be executed on a laptop, an HPC cluster, or in the cloud, with the same logic, the same tool versions, and the same outputs.

If that sounds mundane… It’s not.

Reproducibility is often treated as a compliance box to check, but in UMI-based workflows it’s foundational. Consensus calling is sensitive to grouping rules, filtering thresholds, and read handling details. When those details drift between runs or between analysts, you can end up “discovering” biology that’s really just pipeline variance.

fastquorum removes that variable.

What it’s good at — and what it isn’t

fastquorum shines when UMI consensus is a means to an end, not the end itself. If you’re doing rare variant detection, duplex sequencing, or any application where error suppression is table stakes, fastquorum gives you a clean, standardized starting point for downstream analysis.

It’s especially useful when:

• Multiple projects or teams need to process UMI data the same way

• You want to compare results across runs without second-guessing the pipeline

• You’re tired of maintaining bespoke glue code around tools

But it doesn’t magically fix experimental limitations. Systematic sequencing errors, biased library prep, or insufficient UMI diversity will still show up in the data. fastquorum won’t hide those problems, and that’s a feature, not a bug.

Why this fits in Fulcrum’s UMI toolset

Like MutSeqR, fastquorum reflects our belief that the hardest problems aren’t caused by missing algorithms, but by brittle implementations of well-understood methods.

By packaging UMI consensus into a transparent, reproducible workflow, fastquorum makes it easier for teams to focus on interpretation, validation, and decision-making instead of debugging the same pipeline assumptions over and over again.

If UMI consensus is part of your workflow today, fastquorum is worth a look. It lets this part of your analysis fade into the background, exactly where infrastructure should be.

💻 Access the code: https://github.com/nf-core/fastquorum/tree/1.2.0

That question sits at the center of a newly published Nature Genetics paper co-authored by Fulcrum Principal Bioinformatics Scientist Alison Meynert, based on work completed prior to her joining Fulcrum. The study offers a concrete example of what becomes visible once functional differences between variants are measured directly, rather than inferred.

A closer look at a familiar hotspot

CTNNB1 exon 3 mutations are common across multiple cancer types and are typically described as activating β-catenin signalling. While that description is broadly correct, it glosses over meaningful variation within the hotspot.

In this work, the authors used a saturation mutagenesis strategy to generate and measure all 342 possible missense mutations across the exon 3 region. By combining a β-catenin reporter assay with flow sorting and deep sequencing, they quantified signalling output for each variant under endogenous regulatory control.

The result is a functional spectrum rather than a single category.

What functional measurements add

One of the more striking observations is that mutation frequency does not explain functional impact.

The team calculated mutational likelihood scores based on background nucleotide substitution rates in hepatocellular and endometrial cancers, accounting for all single-nucleotide paths between codons. Those probabilities did not predict which mutations are observed in tumours.

Instead, different tissues preferentially accumulate mutations that fall within particular ranges of β-catenin activity.

Mutations that sit close together in sequence space can differ substantially in effect size. And treating them as interchangeable hides that structure.

Figure 1e from Krishna, et al. Mutational spectra changes with strength of B-catenin activity for each flow-selected pool.

When functional differences surface clinically

When hepatocellular carcinoma samples were stratified by measured signalling strength, rather than by mutation presence alone, clinically relevant patterns emerged.

Tumours with relatively weakly activating CTNNB1 mutations showed poorer survival than those with stronger activating mutations. These same tumours also showed greater immune cell infiltration.

One interpretation, proposed by the authors, is that tumours may select for a “sweet spot” of β-catenin activation within the WNT pathway that’s strong enough to support growth, but not so strong that it triggers counterproductive immune or regulatory responses. That optimal range appears to vary by tissue type and may interact with other dysregulated pathways.

From the tumour’s perspective, not all pathway activation is equally advantageous.

Without functional stratification, these associations are not apparent.

Carrying this perspective forward

Although the work for this study predates Alison’s time at Fulcrum, the perspective it reflects is familiar in her work today: a reluctance to overgeneralize and a focus on resolving heterogeneity before drawing conclusions.

For clients, that often shows up as how questions are framed early. We ask what assumptions are worth challenging and where additional resolution is likely to change interpretation rather than add noise.

📖Read the paper:
Mutational scanning reveals oncogenic CTNNB1 mutations have diverse effects on signalling and clinical traits

Jess joined Fulcrum Genomics in December 2023. She has worked in immuno-oncology, antibody discovery, molecular diagnostics, and core sequencing technology improvements — where her background in physical sciences informs her consideration of the physical processes and molecular mechanisms involved in generating sequencing data. We recently sat down to chat about work and life as a bioinformatics consultant.

What’s your area of expertise, and what excites you about your work?

Jess: I’d say I’m a generalist, in terms of bioinformatics expertise. I do have more of a scientific background and training, though having been in the field for some time now you do find you pick up a lot of software engineering, and in particular cloud architecture expertise. As a generalist I like seeing how these technologies touch many different fields. Most of my jobs have allowed me to use RNA sequencing and DNA sequencing and do some assembly of constructs, and, and, and… I like that I get to see the broad impact.

In terms of what excites me, it’s the scientific problems. I think of my role as a bioinformaticist as ‘interrogating molecules’. I think part of that comes from my background in physics and chemistry. Of course we have to write good software in order to efficiently and accurately interrogate molecules, but ultimately what’s coming off a sequencer is some sort of physical signal that is correlated to a molecule. What biologists are usually interested in is what those molecules are doing in a biological sense, so providing them an accurate readout of what the molecules are doing is really the job. Really, what excited me about analysis of NGS was the massively parallel scale. To get so much information about so many molecules all at the same time! It’s really cool.

What’s a common challenge in our industry that people don’t talk about enough?

Experimental Design

In the last ten to twenty years it’s become so easy to take some DNA or RNA and just throw it on a sequencer, see what happens. Doing good old-fashioned hypothesis-based research is what’s going to get you the answers you want, more than trying mine some big data post hoc. Thinking really hard to focus your question, and then designing your experiment around that, will make the downstream analysis trivial. The analysis is hard and costly and time-consuming and maybe even impossible if you don’t think carefully about what you put on the sequencer before you do your sequencing.

What’s one tool, tip, or mindset shift that has made a big impact in your work?

There have been a number of people who have mentored me in my career, but most recently Jeff Gentry, at this company, who really emphasized, and helped me hone, my instinct for ‘right-sizing’ a solution. Avoiding premature optimization, but also avoiding something so slap-dash that you regret it in two months. I think instinct for right-sizing is something that comes with experience, and not to be too ‘sales-y’ but one of the nice things at Fulcrum is that everyone has seen so many projects that even our junior people have a pretty good instinct for the amount of rigor for a given effort, what is the right amount of structure and process. We don’t want to waste time and money today, but we also don’t want to waste time and money in the long term.

What’s a recent project or insight you’re particularly proud of?

I am working on a PacBio long read project right now and I’m just really excited! Every time I get to work on a new library prep technology, or a new sequencing read type, on a new application with long reads I’m thrilled. I’m just stoked about long reads, if you’ve got long reads bring them to Fulcrum! I want to analyze them.

If you could give biotech startups one piece of advice, what would it be?

I have been in three. There’s fifty-thousand things I could say. If I had to choose one it would be to hire very carefully your initial people. And then this goes back to what we were saying about right-sizing your solution, but think very carefully if you need a whole team for this, or do you need people to put a solution in place that a smaller team can then maintain? When do you need to bring certain kinds of expertise in, and do they need to be full-time employees? And then in terms of your full-time employees, are you promising them growth as employees as a best-case scenario trajectory or are you going to need them to be an individual contributor for a long time and are they going to be happy doing that? If that’s the case, hire them to be a good individual contributors and not for management opportunities ‘down the road’.

What’s something outside of work that inspires how you think about problem-solving?

My hobby is rock climbing. Lots of people like rock climbing because it’s both exercise and a little puzzle you get to solve. I’m not a particularly accomplished climber but I do enjoy it. I think it’s a pretty good metaphor for a lot of technical things. You stand on the ground and you look at your route and you think “I know what this is going to be like! I have a plan, it will be fine, I’ll just do the plan.” Then you get up there two-thirds of the way and think “oh, now that I’m closer I can see why this plan is not going to work.” You have to pivot, and be flexible. Those are skills that are very important when you’re doing technical work, particularly doing a new thing that people haven’t done before. You definitely should go in with a plan! But you should be open-minded about what you’re going to do if something unexpected comes up or there were unknown variables adding complexity.

Matt joined Fulcrum in September 2023. His professional expertise spans a diverse range of biological contexts, including immunotherapy, spatial and single-cell transcriptomics, and structural variant discovery. We recently sat down to chat about work and life as a bioinformatics consultant.

What’s your area of expertise, and what excites you about your work?

Matt: I embrace diving deep on both the computational and biology sides of a project, and I care about building software that is well grounded in biology and motivated by a business need. Building breadth in my expertise allows me to speak both languages and act effectively as the bridge between computational and lab teams. I bring a strong sense of product mindedness to my client projects, and I believe in letting data drive our development. The data doesn’t lie, and working with the stakeholders is the only real way to know if a pipeline is actually solving their problem.

I’m always excited by the chance to work with a client on a new assay or experiment. It’s rewarding to finally reach the moment a client lights up at a new result, and having the chance to reflect that excitement back. I’m also excited by opportunities to improve our open source software and internal engineering practices. I love learning about a better way to be doing something.

What’s a common challenge in our industry that people don’t talk about enough?

Getting lab and computational teams to talk with each other effectively.

I’ve noticed this can be made worse by imbalanced expectations for in-person work. Obviously, bench scientists have to be in-person, while the computational team may be hybrid or fully remote. I’ve worked in settings where this created a sense of “othering” between the two teams, so I made sure to be on site 2-3 days a week and always for team meetings. Without these interactions, you miss out on the opportunity to have unplanned conversations from which good ideas can spring.

It’s really about finding ways to meet people where they’re at, and being the person to connect the teams and connect the dots. At Fulcrum, this is balancing several different chat clients; in previous environments this was making sure I was on the ground to talk to scientists who had better things to do at the bench than check Slack. Good science doesn’t happen in silos.

And nothing is better than a whiteboard for unblocking a project.

What’s one tool, tip, or mindset shift that has made a big impact in your work?

Scale effort to the context. Don’t reinvent or overcomplicate the wheel, and also make it really easy to build good wheels.

I do most of my work in Python, where my rule of thumb is to optimize for developer time, not CPU time. At Fulcrum, we rely heavily on strict type checking to catch avoidable bugs early. I’ve worked with Clint (Valentine) to develop an internal Python package template so it’s trivially easy to stand up a new project with our recommended configuration. We want the default bar to be high, and we never want a developer to opt out of type checking or unit tests because setup is too much overhead. When we talk about scaling effort to context, we want folks to think about bigger picture concerns, like how thoroughly the code needs to be tested. Is a happy path okay, or do we need robust coverage? And the same goes for refactoring, containerization, or general productionization.

What’s a recent project or insight you’re particularly proud of?

Recently I was brought in to get a stalled project back on track - a workflow port from Snakemake to Nextflow that had grown beyond its original scope. The client had a critical dataset arriving in November and needed the pipeline ready. I managed three other engineers on the project, made calls about where to refactor versus where to work around existing patterns, and handled code review. A lot of my role was triaging - what do we fix properly, what do we patch, what do we leave alone to hit the deadline. We reached code completion in about two months, then discovered the new workflow wasn’t producing results consistent with the legacy pipeline. I set up a weekly iteration cycle: run the old pipeline, diagnose differences, implement patches, repeat. After about a month of that disciplined process, the ported workflow is now validated against legacy results, and we’re on track for the new dataset.

If you could give biotech startups one piece of advice, what would it be?

Good software engineering practices complement good lab work.

I think it’s easy to perceive testing, code review, and documentation as “nice to have”, but they’re just as necessary as detailed SOPs, lab journals, and disciplined LIMS provenance. Biotech isn’t Silicon Valley - we can’t just move fast and break things.

What’s something outside of work that inspires how you think about problem-solving?

Having a child has reshaped how I think about time. Before I had the flexibility to follow interesting tangents and didn’t worry too much about how long something might take because I could always make up the time later. But now time has become much more zero-sum and that’s made me more deliberate. I’m more mindful about where I invest my energy, and I’ve become better at identifying what really matters. I’m a perfectionist by nature and I’ve gotten better at saying “this is good enough for now and for its purpose.”

To cut through the noise, we asked members of our own team at Fulcrum Genomics what trends they’re seeing now and what they expect to shape 2026. Their answers cluster around a common theme: making genomics work in the real world through better tools, better standards, and deeper biology.

1. AI in Genomics: Powerful, but Not a Magic Wand

AI is already changing how genomics professionals work, but our team is clear-eyed about both the upside and the mess it can create.

“I’m seeing some serious time-multiplying advantages to all genomics professionals using AI agents. But I’m also predicting there’s going to be a lot of human time needed to clean up some of the messes this creates in 2026 (ironically, with the aid of AI agents no doubt).”

-Clint Valentine | Vice President, Operations

“[I’m seeing] a shift from the previous cycle of ‘we’ll just throw all of our data in a pile, and armed with nothing but the power of friendship we’ll empower our clinicians to make deep insights’ to ‘we’ll just throw all of our data in a pile and AI will figure it out’. Curious to see how it goes.”

-Jeff Gentry | Distinguished Bioinformatics Engineer

Taken together, their perspectives suggest that in 2026:

• AI agents will be indispensable force multipliers for genomics teams

• Thoughtful data practices, validation, and oversight will matter more than ever

• “Just add AI” will not rescue disorganized data or ad hoc infrastructure

2. Standards Cross the Academia–Industry Divide

While tools and platforms evolve, data standards are also becoming more central to how genomics gets done.

“I’m seeing GA4GH standards that have been pushed/originated in academic bioinformatics starting to be used more in industry, and not just file formats e.g. BAM/VCF, but things like Phenopackets.”

-Alison Meynert | Principal Bioinformatics Scientist

This matters because:

• Standardized data models make it easier to share, integrate, and re-use data across projects and organizations

• Clinical and phenotypic standards are essential for robust AI and for scaling precision medicine efforts

In 2026, expect interoperability and well-defined standards to move from “nice to have” to “table stakes” for serious genomics programs.

3. The Genomics Stack Grows Up: Tools, Workflows, and Rust

On the engineering side, the tooling that underpins genomics is rapidly maturing.

“We’re seeing a trend of clunky environment management tools (conda, poetry) being replaced with faster and improved versions written in Rust. Specifically, pixi is fantastic as a drop-in replacement for conda and uv replaces poetry. Going into the new year, we also have our eye on ty as a mypy replacement.”

-Zach Norgaard | Associate Director, Bioinformatics

“We’re seeing the continuing maturation of some popular workflow languages (snakemake & nextflow) and platform-as-a-service products (e.g., seqera and latch). I’m predicting that 2026 will be a year where genomics professionals take the time to upgrade their projects to exploit these offerings.”

-Jason Fan | Staff Bioinformatics Engineer

The takeaway: the genomics software stack is moving from “held together with scripts and hope” toward something more like a modern, robust engineering environment that’s faster, safer, and easier to maintain.

4. From Short Reads to Structural Truth: Long Reads, SVs, and Error-Corrected Sequencing

Several team members highlighted a shift toward technologies that capture more complex and clinically relevant variation.

“Error-corrected sequencing expanded to larger target panels this year, with new methods addressing the double-sampling challenge and library preps that preserve native DNA features for epigenetic analysis. In 2026, I expect these advances and more to bring ECS into routine clinical workflows.”

-Nils Homer | Founding Partner

“Long-read sequencing should keep gaining momentum, especially with PacBio HiFi moving further into clinical workflows. I wonder if we’ll see some tools for Roche SBX processing/analysis start to be developed out in the open.”

-Erin McAuley | Staff Bioinformatics Scientist

“I’m seeing an interest in structural variants that began in academia shifting into industry, and with it the incorporation of long read data into standard bioinformatics workflows.”

-Tim Dunn | Senior Bioinformatics Scientist

Together, these perspectives point to a 2026 where:

• Long reads are no longer niche, but an expected part of serious clinical and translational genomics efforts

• Error-corrected approaches and SV-aware pipelines play a larger role in diagnostics and disease characterization

• The field moves beyond SNPs and small indels toward a more complete view of genomic architecture

5. Beyond the Genome: Proteins Take Center Stage

Genomics is only one layer of biology, and Yossi expects 2026 to bring much more practical attention to proteins.

“In 2026 I expect proteins to get a lot more practical attention. AI-based protein design will become a standard early step in enzyme and therapeutic work, rather than optional or experimental. Improvements in automated prep and quantification will make pilot-scale proteomics studies far more reliable than they are today. Altogether, this will let us go beyond the genome and work with the molecules that do things in cells.”

-Yossi Farjoun | Principal Bioinformatics Scientist

In other words, 2026 may be the year where genomics and proteomics feel less like parallel worlds and more like a connected continuum of molecular insight.

Looking Ahead: Making Genomics Work in the Real World

Across the Fulcrum Genomics team, a coherent story emerges.

• AI and agents will be everywhere, but the organizations that win will be the ones that pair them with sound data strategy, validation, and governance.

• Modern tools and workflows, from Rust-based environment managers to mature workflow engines and PaaS platforms, will give genomics teams a stack they can build on instead of battle.

• Standards like GA4GH’s will make it easier to share, integrate, and interpret data across research, clinical, and commercial settings.

• Advanced sequencing approaches, including long reads, ECS, and SV-aware analyses, will enable a more accurate and clinically meaningful view of the genome.

• And protein-level technologies will push us beyond sequence toward function, mechanism, and ultimately, better interventions.

Across AI, infrastructure, standards, sequencing, and proteins, one message stands out: the building blocks for real-world genomics are finally in place. The work of 2026 is to turn those capabilities into systems that are dependable, scalable, and clinically meaningful. And to do it without losing scientific rigor along the way.

If you’re planning how to evolve your pipelines, platforms, or assays in 2026, we’d love to partner on it. Get in touch with the Fulcrum Genomics team to design, optimize, or troubleshoot the genomics and multi-omics workflows that will carry your organization into the next phase.

Figure 1 from MutSeqR publication showing an overview of the MutSeqR utilities.

At Fulcrum Genomics, we’ve always believed that open and reproducible methods are essential to advancing science. That’s why we’re proud to share that our own Clint Valentine co-authored a new publication in Bioinformatics Advances introducing MutSeqR. It’s an open-source R package designed to bring standardization to error-corrected sequencing (ECS) data analysis for genetic toxicology applications and beyond.

ECS has become a cornerstone technique in genetic toxicology, environmental health, and cancer research. By comparing multiple reads of both strands from the same DNA molecule, ECS can dramatically improve accuracy and detect ultra-rare mutations that traditional sequencing might miss in a sea of noise.

Despite its power, one major challenge has persisted: the lack of open and reproducible methods for analyzing ECS data for what genetic toxicology researchers and regulators care about. Different laboratories often use proprietary or custom-built pipelines, which make it difficult to compare results or reproduce findings.

MutSeqR addresses that challenge head-on.

What is MutSeqR?

MutSeqR was developed collaboratively by Health Canada, the University of Ottawa, and our team at Fulcrum Genomics. The goal was to create a shared, open framework for analyzing mutation data across ECS technologies like Duplex Sequencing (DS) and SMM-Seq.

Key features of MutSeqR:

• Variant filtering and classification: Applies validated filters and identifies mutation types across ECS platforms

• Mutation frequency and dose-response modeling: Quantifies how mutation rates change across experimental conditions

• Benchmark dose (BMD) estimation: Implements statistical modeling consistent with regulatory methods for chemical risk assessment

• Mutation spectrum and signature analysis: Characterizes mutation types and connects them to biological mechanisms

• Built-in visualization tools: Generates reproducible plots for mutation frequency, spectra, and statistical comparisons

All analyses can be run in R (v3.4.0 or higher), and the code is openly available on GitHub and Bioconductor.

Fulcrum Genomics’ Role

Our Ops Lead, Clint Valentine, contributed as a co-author on the study and helped establish many of the methods and software foundations that MutSeqR builds upon.

“This work reflects Fulcrum’s commitment to open and reproducible science,” said Valentine. “Our team has been developing tools for error-corrected sequencing for more than a decade, so it’s meaningful to see those methods evolve into frameworks that support regulatory applications.”

Matt Meier, of Health Canada and senior author on the paper, added: “For technologies like error-corrected sequencing to be used in a regulatory setting, we need open and transparent methods. Annette Dodge, first author on the publication, worked meticulously to build a tool that meets that need. It’s been rewarding to bring together experts from different disciplines to create something that serves the entire genetic toxicology community.”

This project continues a theme in our work at Fulcrum: helping scientists build confidence in their data through robust bioinformatics tools. Whether we’re consulting on experimental design, developing analysis pipelines, or contributing to open-source software, our goal is always the same: to help research teams make sense of complex genomic data with clarity and precision.

Why Standardization Matters for Genetic Toxicology

In toxicology and environmental genomics, reproducibility is essential for regulatory confidence. Small differences in variant calling or filtering parameters can lead to divergent conclusions about a chemical’s mutagenic risk.

MutSeqR brings consistency to these workflows by:

• Supporting cross-platform comparability among ECS technologies

• Offering transparent statistical models for mutation frequency and dose-response

• Providing regulatory-aligned analysis tools for mutagenicity testing

• Ensuring data reproducibility across labs and studies

MutSeqR’s benchmark dose modeling also aligns with methodologies already used by Health Canada, the U.S. Environmental Protection Agency (EPA), and the European Food Safety Authority (EFSA), making it easier for results to be interpreted in a regulatory context.

Together, these tools make MutSeqR a valuable resource for researchers and regulators who need reliable, open-source methods for evaluating genetic safety data.

Looking Ahead: Open Science and Public Benefit

We see the publication and release of MutSeqR as part of a broader movement toward open and transparent genomics methods in genetic toxicology. As error-corrected sequencing continues to expand in research, industry, and government, tools like MutSeqR help bridge the gap between data generation, interpretation, and subsequent public health decision-making.

We’re excited about what comes next. Our open-source pipeline, fastquorum, already takes researchers from raw sequencing data to highly accurate error-corrected DNA sequences. MutSeqR now picks up from variant calls with variant filtering and annotation, dose response modeling, statistics, and visualization. But one automated piece is still missing: variant calling. We’d love to collaborate with others to develop this step or extend our existing tools toward an end-to-end open workflow for all the various flavors of error-corrected sequencing analysis. We want to see a solution with the same reproducible, regulatory-minded approach, that further helps researchers get the answers they need quickly and openly.

At Fulcrum Genomics, we remain committed to building open standards and collaborative methods that strengthen scientific integrity and transparency in genomics.

📖 Read the publication:

• MutSeqR: An Open-Source R Package for Standardized Analysis of Error-Corrected Next-Generation Sequencing Data in Genetic Toxicology

💻 Access the code:

• https://bioconductor.org/packages/release/bioc/html/MutSeqR.html

• github.com/EHSRB-BSRSE-Bioinformatics/MutSeqR

The whole picture: How our values connect

Over the past weeks, we’ve shared our core values one at a time: Openness, Excellence, Valuing People, Client Focus, Public Benefit. Each essay stood on its own. But here’s what we’ve realized in reflecting on them: they’re not really separate at all.

They’re all different expressions of the same fundamental commitment: to show up fully, to do work that matters, and to do it with people, not just for them.

You can’t have excellence without openness, without the willingness to surface problems early, question assumptions, and say “I don’t know, but let’s figure it out together.”

You can’t truly focus on clients without valuing people, because clients aren’t abstractions or contracts. They’re humans trying to solve hard problems, often under real pressure.

And public benefit ties it all together. It’s the why that makes the how matter. When your goal is to advance science in ways that help people, excellence isn’t optional, relationships aren’t transactional, and openness isn’t a nice-to-have. It’s all connected.

We started Fulcrum with a simple question: Can we do meaningful work with people we really like? Ten years in, the answer is still yes. And if you’ve followed this series, or worked with us as a client, collaborator, teammate, or friend, thank you for helping us live these values, and for holding us accountable to them. Today and every day we are thankful for you.

We’re just getting started. Here’s to the next chapter, together.

Public Benefit has a global and a local component.

Public Benefit: Grounded by Good

At Fulcrum Genomics, Public Benefit isn’t just a principle—it’s our purpose. Each of us brings a deeply personal motivation to this work. Many of us have been touched by genetic disease, and that experience shapes not only the projects we choose, but how we choose to do them.

We want our work to matter. We want to create impact. We want to move science forward in a way that improves lives.

This value—Public Benefit—inspires the why behind our work. It fuels our drive to contribute to both basic research and human health, and it guides how we collaborate with clients. In every project, in every conversation, we stay mindful of the broader implications: What are we building, and who does it help?

We’re happier, more motivated, and more fulfilled when we know that what we’re doing is genuinely making a difference.

“Fix-Forward”: Small Acts, Big Impact

Public Benefit isn’t just about the big picture. It also shows up in the small choices we make every day. At home, many of us live by the simple rule: “tidy as you go.” Put things back where they belong, so the space works better for everyone. We bring that same mindset to the bioinformatics community.

A lot of open-source bioinformatics software is under-resourced, a bit rough around the edges. Being a good community member means noticing those rough edges—and choosing to smooth them out. Whether it’s submitting a bug report, contributing a pull request, improving documentation, or sharing a workaround that might save someone else an hour of frustration, we try to leave things better than we found them.

Could we fork the code privately and solve the problem for ourselves? Sure. But with a little more effort, we can solve it for everyone. And that’s the kind of scientist—and the kind of company—we want to be. If we can make even 1% of the world’s bioinformatics software 5% better, that’s a meaningful difference.

The Big and the Small

We see Public Benefit at two levels:

1. Capital-P Public Benefit: the big-picture commitment to working in biomedicine, pushing research forward, and improving human health.

2. Lowercase-p public benefit: the daily acts of generosity, responsibility, and craftsmanship that make the scientific ecosystem stronger for everyone.

Both matter.

We are part of a community, and we want to help it thrive. When you look for the helpers, we want you to see us—not quietly in the background, but out front, leading the charge.

Alison joined Fulcrum Genomics in April 2024. Her professional expertise has focused on maximizing clinical impact with well-engineered workflows generating insights from ‘omics data. We recently sat down to chat about work and life as a bioinformatics consultant.

What’s your area of expertise, and what excites you about your work?

Alison: I come from an academic background, where I spent years working with very early-stage research and projects nowhere near therapeutic application. Moving to Fulcrum has been an interesting shift. The assays are much more defined, and each client typically focuses on just one or two. They know them inside out, and my role is to help analyze their data and build production-ready pipelines so they can bring their product to market. That’s a big change from academia, where you’re often helping define the assay itself, or juggling many different experiment types across multiple groups. At the Institute for Genetics and Cancer in Edinburgh, where I worked in a bioinformatics core, the remit was broad. It was mostly human-focused, or relevant model organisms, but still—there’s a lot you can do in that space. Our bioinformatics core partnered with the National Health Service in Scotland working on rare disease diagnostics for children and babies with very rare developmental disorders. That was another world altogether. There is no profit motive there, the margins are razor-thin, and you’re trying to do the best you can with publicly-available data. Working with the clinical side was what I enjoyed the most, and in some ways I think that’s what’s translated best to working with the Fulcrum clients. It’s one assay, it’s one focus, and some of our clients - well they probably have pretty thin margins too!

I don’t regret leaving academia. There was a lot of politics that could be tough to navigate, and it’s been lovely to just focus on science. I was hired at Fulcrum as a Bioinformatics Scientist, not an Engineer, so clearly that analysis background was something Nils and Tim were looking for. But over the past year, I’ve also had the chance to develop my skills in pipelining and tooling, which has been a lot of fun. I didn’t realize how much I missed diving into a real programming challenge. My undergrad in Canada was in straight computer science and statistics, and I even worked as a software developer for a bit before heading back for a Master’s and then a Ph.D. I worked on file format conversion—which, in hindsight, might be the perfect start for a career in bioinformatics!

Over the last year I’ve been happy to get to keep the variety of projects I used to see working at a core facility but now it’s like a super-professional core facility for the world. So I get to work on loads of different cool things, I have excellent support for the technical things that I’m learning, and it’s just a lot of fun.

What’s a common challenge in our industry that people don’t talk about enough?

Ironically, communication! Making sure you speak the right language for your client. That you really understand what they’re trying to do. Occasionally figuring out what they actually need instead of what they say they need. You have to be very careful to not talk at cross-purposes with each other. Sometimes that means asking very basic questions, not being offended when people ask the same back, and sometimes just slowing down at the start of a project to make sure that everyone is on the same page, understands the end goals, what might not be able to be answered. Setting expectations is a big part of communicating a project. I have certainly seen when this goes wrong. In academia it can be devastating for a career. In industry for a whole company. So we want to get it right.

What’s one tool, tip, or mindset shift that has made a big impact in your work?

It’s two sides to the same coin. One is setting aside your ego and saying “I don’t know”. Being honest about that and asking for help with things that you don’t know about. And the other side of that is battling your own imposter syndrome, to understand what you are good at, to project that confidence when it’s justified, when you do know your stuff.

What’s a recent project or insight you’re particularly proud of?

I have one client who wanted to compare something they were doing with something that is available in the public domain. The public domain tool was a mess in terms of getting it to run. It takes in big data and takes a lot of processing time. Getting it to run and making sure it was running correctly was really hard work, but I finally got it to run end-to-end with the correct input data, correctly formatted. When I finally did the comparison and the client’s assay performed better, that was nice and the client was very happy!

If you could give biotech startups one piece of advice, what would it be?

Understand your assay, your product, and do lots of diagrams. It will help everyone. It’s the best thing when you come to a client and they have really beautiful diagrams. Particularly when it’s sequencing and you can see “these are the pieces we’re sequencing and this is how they are coming together as we are constructing this particular fragment of whatever it is we’re going to sequence”.

What’s something outside of work that inspires how you think about problem-solving?

I am a big fan of just letting my brain work while I’m not actively thinking about things. People call them shower thoughts. Or you wake up in the morning and think “oh, that’s how that works”. Both letting your unconscious brain do the work, and giving your brain the space to do that work - making sure you get enough sleep and go for walks and give yourself breaks, go for a drive, have some music on, let your brain wander. It’s amazing what it will come up with.

Partnership Rooted in Empathy

At Fulcrum Genomics, the vast majority of our work comes through reputation and referrals—not by accident, but by design. Clients come back, and they send others, because we stay focused on what matters most: doing the right thing, within reason, for the client.

That might sound like a simple idea. After all, we’re a consulting company—we succeed when our clients succeed. But true Client Focus isn’t just about doing what’s asked. It’s about building relationships where we listen deeply, challenge constructively, and elevate the work together.

Finding the Gaps

Client Focus means going beyond execution. It’s not just what we deliver—it’s how and why. We don’t just fulfill requests. We strive to understand the strategic context: What does the client really need? What are their goals, constraints, and blind spots? How can we help them see around corners? Many of our most meaningful client interactions begin when a request prompts a thoughtful response: “We understand what you’re asking—but based on what you’re trying to achieve, we think there’s a better approach.”

When clients light up—when they see that we’ve truly understood them, and helped clarify or elevate their goal—that’s the heart of exceptional Client Focus.

Importantly, we recognize that some clients have been conditioned to ask for less. Past experiences with bioinformatics or software teams may have led them to pre-compromise, to narrow their scope, or to hide uncertainty. Our job is to meet them where they are, and to gently expand the frame—to uncover and address the deeper needs they may not have voiced.

That requires more than technical skill. It requires business empathy: stepping into the client’s shoes to understand their context, risks, and motivations. It’s how we guide toward the best solutions—not just the most convenient ones.

Fine-Tuning Frequencies

Strong Client Focus means clear communication—and careful listening. Sometimes clients seem to agree, but their response contains subtle cues that something’s not fully understood. Maybe it’s a mismatch in vocabulary, expectations, or assumptions. These are the moments where true Client Focus shines—not by plowing forward, but by pausing.

We ask: Are we really on the same page? Should we reframe or clarify? Is there a better way to explain or engage?

This is especially important in cross-disciplinary settings, where scientists, engineers, clinicians, and stakeholders may all speak different languages. Our role is to tune to each frequency—ensuring alignment across levels, disciplines, and decision-makers.

Graceful Guidance

Client Focus is not about saying “yes” to everything. It’s about being a trusted partner—one who supports, challenges, and guides with empathy. That includes adapting our communication to the audience. Some clients want high-touch collaboration; others prefer structured, hands-off updates. Some teams welcome informality; others expect polish and precision. Even within a single organization, preferences can vary by role, project, or moment. We stay attuned to these dynamics, adapting how we engage—while keeping the focus on delivering value at every level.

At its heart, Client Focus is a relationship: built on trust, strengthened by clarity, and sustained through care. We prefer close collaboration over distant transactions, because real insight comes from connection.

A Shared Mission

We care deeply about our clients—not just because it’s good business, but because we share a larger mission. We’re part of a community of smart, driven, empathic humans working to solve real problems in human health. Supporting this work requires precision, partnership—and focus. And that’s what we bring, every day.

Zach joined Fulcrum Genomics in May 2024. Previously Zach has contributed to research on gene and cell therapy, genetic toxicology, spatial transcriptomics, cancer minimal residual disease, and HIV. We recently sat down to chat about work and life as a bioinformatics consultant.

What’s your area of expertise, and what excites you about your work?

Zach: My area of expertise is helping wet lab scientists pair their questions and experimental designs with an appropriate software solution, figuring out what we can do to help. That specifically requires a decent understanding of the biology. I have a background in genetics, ecology, and evolution, so for a lot of the different kinds of questions people might ask I can help work out how we will answer them using software. My first position out of grad school was at a gene editing lab and I got to work with many Postdocs there, doing a variety of experiments. I helped them work out how we would answer their questions and get their results published. In my next role I got to work with wet lab scientists building entirely new products, which is something I really enjoy and I think I’m good at.

The thing that excites me the most is being involved early in the R&D phase and getting to see that concept go all the way to product and launch!

What’s a common challenge in our industry that people don’t talk about enough?

A big challenge people don’t talk about enough is how you take a concept and turn it into a real, functioning product. There’s so much involved, and it’s critical that people on the technology side are tightly integrated with wet lab and software experts. You need all the pieces to fit together and you need to be thinking about how it’s actually going to deliver value to your customers.

One part that often gets overlooked is how, at some point, you have to lock in your design — especially if there’s a physical component. I’ve seen projects where there was a strong urge to keep improving right up to the last minute. But when you’re going to market for the first time, that’s just not feasible. You have to commit, build a bunch of units, and be ready to ship, even if you know you could make it a little better.

What’s one tool, tip, or mindset shift that has made a big impact in your work?

This is one that may be common for those with a software background but for me coming from a genetics background I found it very exciting. There’s a whole set of tools that are linters, and they auto-format your code for you, so you no longer have to worry about all the nit-picks. This helps particularly when you’re a consultant and bouncing around different languages, different repositories, different client environments. It’s nice to have that set up to handle formatting for you.

What’s a recent project or insight you’re particularly proud of?

We’ve been able to stand up pipelines for teams developing new technologies and hand them off to their teams to keep running with limited need for our continued support of those pipelines. I am thinking of one in particular to QC an oligonucleotide product. I think that’s a really good example of how we can tailor what we are delivering to our clients’ needs, so they can continue in-house after our primary work is done. It’s really exciting to see people have continued success with things we built for them.

If you could give biotech startups one piece of advice, what would it be?

Science and software = same team!

If your startup bridges wet lab and software, where the software is essential to unlocking the value of your technology, it’s critical to engage your software team early. A strong, well-integrated software team can spot opportunities where a small tweak to the wet lab design can make the downstream analysis faster, more scalable, or more robust.

You’ll end up with a better product overall if your scientific and technical teams stay in close collaboration from the start.

What’s something outside of work that inspires how you think about problem-solving?

Magic: The Gathering, especially the Limited format, is surprisingly relevant. In a draft you’re working with a small, fixed card pool and trying to infer what others are picking. There’s a ton of statistics involved, both in building your deck and playing it well. There’s even a site, 17lands.com, that dives deep into the data collected from players.

What I find fascinating is how your individual experience can deviate from the broader trends. The stats might say one card is better, but in a specific moment context matters more. That’s a lot like gene annotation. Just because a gene has a label doesn’t mean that’s the key to your question. You need both the contextual data and the bigger picture to make smart decisions.

Flourishing in Fellowship

At Fulcrum Genomics, we believe that consulting is a relationship business—and relationships are built on people. From day one, Valuing People has been one of our deepest commitments: to ourselves, to our team, and to our clients.

When we founded Fulcrum, we didn’t write a business plan full of buzzwords. We just asked: Can we have fun? Can we do meaningful, interesting work? Can we do it with people we really like? That core sentiment still guides us today. Fulcrum was founded in friendship, and that foundation continues to shape how we live, work, and grow.

Founded in Friendship

Fulcrum began with a simple truth: we wanted to build a company where friendship came first. In fact, we were friends first, having met at a local dog park and working closely together thereafter. We supported each other as we each grew our family, and times of personal challenge. At work, friendship came first.

That meant valuing each other’s time, talents, and humanity—not just output. As we’ve grown, we’ve extended that ethos to everyone who joins us. We believe that excellence and empathy go hand in hand—and that great work is only possible when people are seen, supported, and respected.

What does that look like in practice? It means creating opportunities for our team to do purposeful work alongside amazing colleagues. It means working hard—but also protecting boundaries so work doesn’t take over life. It means recognizing that work is just one part of a full life, and sometimes other parts matter more.

Life is messy—just like biology. When life gets complicated, we don’t look away. We step in.

Over the years, we’ve stood with teammates through bereavement, international moves, new children, and other personal challenges. We’ve also stepped up for clients when previous partners let them down—helping them get back on track with clarity, speed, and empathy.

Building a Team, and a Community

We didn’t set out to build a team—at first, we were hesitant. We knew the responsibility that would come with it. But over time, we found that bringing in the right people made everything better. The work got deeper. The projects got more diverse. The joy got bigger.

Our team now includes an exceptionally skilled and thoughtful group of scientists, engineers, and problem-solvers. And because we’ve built this team intentionally—with relationships at the center—we can take on a broader range of challenges and clients, with more creativity, precision, and care. We’ve found that Valuing People doesn’t dilute performance—it amplifies it. Stronger, Together.

For ten years, we’ve been in the business of building lasting relationships—not just transactions. Whether we’re collaborating on a complex dataset, navigating a hard deadline, or supporting someone through a difficult season of life, we never do it alone.

Because life throws challenges at all of us—and the only way through is together. When we value people, we create the conditions for trust. For resilience. For real, lasting success. We flourish—not in isolation, but in fellowship.

Yossi joined Fulcrum Genomics in July 2015. Throughout his career he has enjoyed exploring complex data, learning about new technologies, and improving analysis methods. We recently sat down to chat about work and life as a bioinformatics consultant.

What’s your area of expertise, and what excites you about your work?

Yossi: In broad strokes, the analysis part of ‘Data Analysis’. Coming up with relevant metrics and QC for data, especially when there’s a novel element and we don’t yet have a standard. When it’s a novel assay, a new machine, a novel use case, it’s any novel combination of things, novel experimental design, whatever it is, we’re thinking about how to help our client capture something that hasn’t been done enough to know how to do well. That’s usually my speciality.

Other things I do a lot because I have a lot of experience is sample identity, metadata accuracy, contamination investigations in general. Not new, but a constant thread, and something that’s often otherwise neglected.

I love learning about our client’s process and challenges. Whatever it is there’s usually something hidden and I delight in the unknown and unclear and not-working, the exciting bit for me is figuring out those challenges.

What’s a common challenge in our industry that people don’t talk about enough?

One of the biggest challenges we face, and one that directly affects both our work and the results, is being brought in too late. The experiment’s already been run, the data are in, and we’re left wishing we could have helped shape the study design. Instead we’re untangling batch effects, missing context, and avoidable quality issues. Sometimes low-quality data is just what you’ve got — every dataset has its limits, and you work with it. But other times the quality is poor due to how the experiment was done, it wasn’t part of the experimental design, it wasn’t part of the plan, it just happened. We are often asked to participate when things are going wrong, and while we’re good at that, it would have been a lot easier if we’d been brought in earlier. As the saying goes, “Statistics is an autopsy of data” — and this message might be our homage to pilot studies: a reminder that a little upfront planning can save a lot of pain later on.

What’s one tool, tip, or mindset shift that has made a big impact in your work?

There’s this idea some mathematicians and data analysts have, that you don’t need to understand the data, that your analysis can be totally agnostic to its meaning. But I’ve found the opposite to be true. There are so many ways to analyze a dataset, so many interpretations you could make, that if you don’t understand where the data came from or what it’s meant to support, you’re going to struggle. If you just translate the request literally, you can end up with something that’s technically correct — statistically significant and full of buzzwords — but completely useless to the client. The real value isn’t in picking the fanciest statistical test; it’s in keeping the real-world goal in mind. That shift had a big impact on how I work, because while the details of the math can be fascinating it’s easy to get lost in them and forget the problem you're actually trying to solve.

What’s a recent project or insight you’re particularly proud of?

I recently looked at a dataset and identified what seemed to be a 1% swap rate. Based on very little data because I didn’t have access to the reads - I was only working with statistics - and I was really hesitant to call it a swap because I fear I’m always calling out swaps, so I was looking at it in all different ways before speaking to the client. It’s not a small thing to tell your client they have a sample swap. But eventually I had to say that the data that I was given appeared to have a swap in it. The client, obviously, was terrified and they started to look into it. Eventually we determined that the swap was due to a small number of runs that were used as some sort of QC test and the data were added manually and erroneously and not part of the study. It was good that I found the issue, and that there was actually no real issue. There is a learning here that relates back to the last question - even when you have good evidence you don’t necessarily have the full story until you have the process and history and goals of the data you’re analyzing.

What’s something outside of work that inspires how you think about problem-solving?

I am a rock climber and I have found that rock climbing experience is a pretty good metaphor for many things that I do. I have found connections to work, to glass blowing, to parenting... Working step-by-step, working in a team, looking out for each other, having a safety net. All those things combined is a very distilled way of thinking about problem solving. And also there’s this really nice thing that happens in climbing, that also happens in real life obviously, but is kind of nice - you’re struggling with a certain move or location and it’s the only thing you can think of. But the moment you overcome it, it’s completely gone, you’re over it, it’s vanished and you’re in the next move. You don’t have to think about it anymore. When the whole problem is done you can look back and reminisce but in the moment you don’t have to carry irrelevant problems. It’s true in life but it’s made so clear when you’re climbing that that’s how it is.

Excellence: A Practice, Not Perfection

At Fulcrum Genomics, Excellence is not about being perfect. It’s about choosing to do our best work—honestly, rigorously, and relentlessly—and to keep growing from there.

Excellence is a mindset and a practice. It’s not something you arrive at once and for all, but something you strive for, continually refining. It emerges not from the pursuit of flawlessness, but from a culture of openness, curiosity, and accountability.

It begins with a habit: stepping back and asking: Why am I doing this? How does this help the client? How does this advance science?

The Anatomy of Excellence

Excellence is a practice. It lives in how we plan, how we communicate, and how we execute. It’s about:

1. Being honest—about what we can do, what we are doing, and where we can improve

2. Questioning assumptions—ours and each other’s—with curiosity, not judgment

3. Surfacing issues early—before they grow into problems

4. Staying organized and intentional—so the work aligns with the goal, not just the task

When our work falls short of our standards, it usually traces back to one of these: something unsaid, unclear, or unchecked.

Driving Value for Clients

We often talk about excellent code, excellent analyses—but technical quality isn’t enough on its own. True excellence is measured by the value we deliver. Are we enabling the client to move forward? Are we solving the problem that actually matters?

That may mean doing something unexpected: working around a client’s deadline, responding to a stakeholder’s baffling request with trust, or adapting when the landscape shifts. Context matters. Excellence means understanding the constraints, not ignoring them—and still delivering high-impact results.

And often, our clients have been conditioned by prior experiences to ask for the minimum. Excellence involves teaching them to aim higher. We ask deeper questions, listen harder, and look for the unspoken need. We don’t just solve the problem as stated—we help uncover the right problem to solve.

Breadth Over Specialization

Excellence in bioinformatics is inherently interdisciplinary. It lives at the intersection of biology, software engineering, statistics, and more—and it requires more than technical know-how.

To be excellent in this space, you need:

1. Scientific curiosity

2. Engineering discipline

3. Mathematical insight

4. Clear communication

5. Time management

6. Good judgment

We’re not aiming to be the absolute best in any one dimension. Instead, we pursue consistent excellence across the board—like a decathlete who wins through being well rounded, not specialization. It’s this range, paired with clarity and rigor, that allows us to turn many strong parts into a truly exceptional whole.

Holding the Bar High

Sometimes we ask ourselves: Do we really need to hold the bar this high?

The honest answer: We wouldn’t know how to work any other way.

Excellence is our internal compass. Without it, how do we know where we’re going, and more importantly, when we’ve arrived? With it, things get clearer, simpler, more satisfying. Not because the work is easy—but because doing it just right feels right.

We don’t want to deliver something that’s just “acceptable.” We want to deliver work we’re proud of—work our team can grow from, and our clients can count on. Once you decide to do good work, aiming for excellence becomes the obvious next step. Why not be the best?

The Standard We Aspire To Be

We want Fulcrum Genomics to be the place people turn to when they want a project done right. Not just technically correct, but thoughtful, impactful, and well-crafted.

“If I want it done—and done right—I should take this project to Fulcrum.”

That’s the standard we set.

That’s the reputation we seek to earn.

That’s the kind of excellence we practice—every day.