Clinical genomics runs on software that was usually built for research first.

That is not an insult. Research code has carried this field a very long way. Many of the tools we use every day were written by small groups, often underfunded, often in academic labs, usually to answer a scientific question before anyone knew the tool would become infrastructure. Some of those tools now sit underneath diagnostic pipelines, clinical trials, drug development programs, and patient reports.

The clinical assays built on top of that software are validated. The shared tools underneath them are more often benchmarked, trusted, and left alone until something breaks.

That gap is getting harder to defend.

Benchmarking asks whether a tool performed well on a defined dataset at a point in time. Verification asks whether a tool continues to do what it claims to do, across versions, inputs, and edge cases. Clinical validation asks whether the result is fit for the medical use in front of it.

Each activity is an attempt to answer a different question. Genomics has spent a lot of time benchmarking and then acting as though the other two activities come along for free, when they do not.

A mutation can depend on the software that reads it

Take FLT3 internal tandem duplications in acute myeloid leukemia. FLT3-ITDs are clinically important because they can affect risk stratification and treatment decisions. They are also awkward for short-read sequencing.

An ITD is an insertion created when a stretch of DNA is copied head-to-tail. Reads that span that kind of event do not always align cleanly to the reference genome. Depending on the aligner, the extra sequence may be represented as an insertion, or it may be soft-clipped and set aside as unmatched sequence.

That choice can decide whether the downstream mutation caller sees the alteration.

In one evaluation, BWA missed 85 bp and 95 bp duplications that another aligner detected because the signal was pushed into soft-clipped reads instead of aligned as the duplicated sequence. Same sample. Different aligner behavior. Different downstream visibility.

Getting that call right is not academic. FLT3-ITD status gates targeted therapy (quizartinib is approved specifically for FLT3-ITD AML) so a miscalled ITD can change the drugs a patient is offered. And the result is more than present-or-absent: the duplication’s length, position, polyclonality, and allelic burden are the annotation a lab relies on for interpretation and for tracking residual disease. That is the deeper version of the alignment problem above: when the duplicated sequence is soft-clipped instead of represented as an insertion, you don’t only risk missing the variant, you lose the metadata needed to characterize it.

We have seen versions of this problem in client work. We have built custom FLT3-ITD callers for multiple groups because there is no generic tool I trust to get this right everywhere. The right approach depends on the sequencing platform, read length, panel design, coverage profile, homopolymer behavior, aligner behavior, and caller assumptions.

That is the part people underestimate. A clinical result can depend on a default chosen years earlier by someone solving a different problem.

Nobody set out to make that fragile. It is what happens when tools are benchmarked once and then treated as fixed infrastructure.

What a benchmark can miss

A benchmark is useful. I like benchmarks. I have written plenty of them.

But a benchmark is a measurement. It does not give you a specification. It does not tell you what happens when two inputs tie, when clipping lands on a boundary, when quality encodings drift, when a dependency changes, when a tool is run twice on the same file, or when a new architecture exposes an assumption that was invisible on x86.

For clinical bioinformatics, that is not a minor distinction.

The assay gets validated end to end because the lab has to validate it. The tool underneath may never be re-verified unless the lab changes something obvious enough to trigger the work. Every lab repeats some version of that burden in isolation, while the shared tool itself often carries less validation infrastructure than the workflows built on top of it.

This is one reason maintenance in bioinformatics feels so broken. The field depends on shared software, but the cost of keeping that software reliable lands in odd places. A lab validates around it. A user files an issue. A maintainer triages it at night. A company forks it. A clinical team discovers the edge case after the tool has already shaped a result.

That is not a sustainable validation model.

What changed with AI-assisted development

AI did not make clinical validation unnecessary. Anyone saying otherwise is selling something dangerous.

What AI has changed is the cost of building verification infrastructure.

A coding model can help rewrite a tool. More importantly, it can help build the harness that checks the rewrite against a reference implementation. It can generate test cases, run comparisons, summarize differences, and help tighten conformance tests. That work used to take enough engineering time that most grants, labs, and product teams could not justify it. Now large parts of it can be done much faster.

The hard part did not go away. You still need someone who knows which differences matter. You need someone skeptical enough to distrust a green test suite. You need someone who understands the biology, the file formats, and the failure modes.

The machine can make experiments cheap. It cannot decide what counts as a clinically meaningful answer.

That combination is useful, but only if we use it honestly.

fgumi, and the bug I did not expect to find

fgumi is our Rust reimplementation of fgbio’s UMI tools.

Unique molecular identifiers are short barcodes that help distinguish true molecules from sequencing errors. The grouping step is not glamorous, but it sits in the middle of workflows where reproducibility is essential.

When we built fgumi, the important part was not just writing a faster or more portable implementation, it was building the verification harness.

The harness ran fgumi and fgbio on the same inputs and compared the outputs read by read. It did this continuously across versions and datasets. It caught the kinds of bugs ordinary unit tests miss: tie-breaking differences, sort-order drift, quality-score encoding problems, and fixes that later refactors accidentally undid.

Then it found something I did not expect.

The problem was not in the rewrite. It was in fgbio, the original tool I had recommended for years.

On the same patient sample, fgbio could group molecules differently across runs. When two barcodes had equal counts, the code broke the tie using hash-map order, which was not deterministic. That kind of bug can sit undetected for years because a one-time benchmark will not catch it. You have to run the same data repeatedly and compare behavior carefully.

The harness found other issues too, including numeric instability in the consensus caller, double-counted statistics, and edge cases around clipped bases. We fixed them upstream.

It turns out building the new tool, then refusing to let it disagree with the old one without explanation, made the old tool better.

bwa-mem3, and the work nobody wants to fund

Most foundational tools will not be rewritten from scratch. They will be inherited.

bwa-mem3 is our modernization of bwa-mem2, which descends from bwa, the aligner much of the field has depended on for more than a decade. We forked it for speed, but also for control.

Control is underrated. bwa-mem2 ran on x86, while a lot of current development happens on Apple Silicon and deployment increasingly includes Arm. Quality-of-life improvements and correctness work had slowed because maintainer attention is finite. If a tool is going to remain load-bearing, someone has to do the unglamorous work of portability, tests, continuous integration, documentation, benchmarking, and verification against the prior implementation.

So that is what we did.

The verification harness compares bwa-mem3 and bwa-mem2 read by read. Across more than 800 whole-genome comparisons and 5.5 billion aligned reads, the two agree on 99.9% of reads. The remaining differences are not hand-waved away. They are characterized. Some are deliberate improvements. Some are tolerated. Some get budgets that fail the build if they drift.

That is the kind of boring engineering clinical genomics needs more of.

It is also the kind of work the field has historically undervalued.

ferro-hgvs, and where I got it wrong

The same validation gap shows up further downstream, where variants get named.

A clinical report usually does not communicate a variant as a raw genomic coordinate. It uses HGVS nomenclature to describe DNA, RNA, and protein changes. That string is how the variant gets looked up in databases like ClinVar, dbSNP, and CIViC. If the string is wrong, the variant may fail to match the interpretation that already exists for it.

ferro-hgvs is our library for parsing and normalizing HGVS strings. We verified it against established parsers and tested it against ClinVar, dbSNP, CIViC, and tens of millions of variants from public datasets. By release 0.6.0, it handled every publicly reported clinically relevant variant I had put through it.

I thought it was basically done.

It was not.

I should be blunt here because this is the part people tend to skip in blog posts. Variant representation is not my home turf. My background is read alignment and sequencing data infrastructure. I have written aligners, helped write the SAM specification, and built fgbio. HGVS projection is a different specialty.

I leaned too hard on the harness.

That worked for fgumi because the test suite behind fgbio had been built over years, case by case, by people who knew the tool deeply. In that situation, the test suite was close to a specification. Verify against it and you have done a meaningful part of the work.

ferro-hgvs was different. I leaned on tests ported from other tools, plus large public variant corpora. That was useful, but it was not enough. A corpus is not a specification. It is only the set of cases someone collected.

A clinical-trial client found the edge for us. They needed projection from genome to transcript to protein on their own data. The harness was green. I was confident. My confidence came across as authority.

The tool did not behave the way I had implied it would.

No patient was harmed because human review was part of the validation process, but the miss was still ours. More specifically, it was mine.

We could not simply add their failing examples to our tests. The variants would have revealed the disease area and therapy the company was working on. So we had to anonymize the patterns while preserving the shape of the HGVS constructs. This amounted to keeping the grammar and removing the biology.

Since then, much of the work has been building the projection I had assumed was finished and hardening the harness so it cannot tell the same comfortable story twice.

That is the difference between verification and validation in one project. The harness verified ferro-hgvs against the references we gave it. Validation required real use, private data, a clinical context, and enough humility to admit the harness was not asking the whole question.

A green test suite is evidence. It is not absolution.

The same problem runs below our code

This gap does not stop with tools we build.

htsjdk is the Java library used by Picard, GATK, and many other genomics tools to read and write sequencing files. A bug in htsjdk can become a bug everywhere at once. But it does not need a flashy rewrite. It needs careful hardening for performance work, correctness fixes, thread-safety checks, regression tests, and review by people who understand how widely the library is used.

The same principle applies when general tools are the wrong answer.

SMN1 and SMN2, the gene pair involved in spinal muscular atrophy carrier screening, are so similar that standard short-read pipelines can struggle to assign reads confidently. In some populations, relying on a standard pipeline alone can miss a substantial fraction of carriers. The field’s answer was to build specialized, separately validated callers for that region.

Knowing where a general tool fails is part of validation.

What should change

Equivalence testing against a reference implementation should be standard for rewrites. If you replace a foundational tool, you should show where the new implementation agrees, where it differs, and why those differences are acceptable.

Public benchmarks should also include more clinical edge cases. Genome in a Bottle’s challenging medically relevant genes benchmark is a good model. The field needs more of that across ancestries, assay types, and regions routine pipelines still handle poorly: FLT3 duplications, SMN paralogs, CYP2D6, repeat expansions, difficult structural variants, awkward HGVS constructs, and all the cases that get dismissed as edge cases until they show up in a report.

Clinical labs will still need to validate their assays. That does not change. I have run clinical validations and helped lead bioinformatics in a CLIA lab, and I know enough to respect the difference between tool verification and clinical validation.

But assay-level validation has been asked to carry too much of the tool-level burden. Each lab validates its own configured pipeline against the samples it has. That does not certify every shared tool underneath across the range of inputs it will eventually see. It also means the same work gets repeated in isolation by groups that all depend on the same infrastructure.

We can do better than that.

Who pays for this?

Bioinformatics has never settled who pays for maintenance.

AI-assisted engineering makes that harder to ignore because one of the old excuses is weaker now. The harnesses are cheaper to build. The comparisons are cheaper to run. The scaffolding that used to be uneconomic is now within reach for many more teams.

That does not make validation free. Human judgment is still expensive, and it should be. Someone has to decide what the tool is allowed to do, what counts as a meaningful difference, which edge cases belong in the suite, and where the tool should not be used.

The labs, diagnostic developers, funders, software companies, and open-source users all benefit from this infrastructure. They should all expect to fund some part of it.

At Fulcrum, we are starting with the tools in front of us. The validation suites behind fgumi, bwa-mem3, and ferro-hgvs are worked examples of what continuous verification can look like for real bioinformatics software. They do not solve clinical validation. They do show that tool-level verification can be done routinely, and that it can find real bugs in software the field already depends on.

I would rather build that infrastructure now, while it is finally cheap enough to do properly, than explain later why we kept trusting research code without checking it.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

This post is part of Fulcrum’s series on practical informatics for CRISPR off-target analysis. In a companion post, Tim Dunn describes recent work on Sassy that helps enumerate plausible guide alignments at a locus instead of returning only one preferred answer. DivRef addresses the other side of the same problem, which is what sequence space should be searched in the first place.

Finding short-sequence matches in the human genome is a common problem in bioinformatics. CRISPR guide RNAs are a good example. The guide is designed to match the intended editing site, but close matches elsewhere in the genome can also matter, because the guide could also edit at those sites, causing unintentional effects. To evaluate those possible off-target sites, the search has to include the sequences where those matches could occur.

The standard human reference genome does not contain all of the common sequence variation present across populations. A single alternate allele, or a short haplotype of nearby alleles, can create a match that is not present in the reference assembly. For CRISPR off-target analysis, that means the reference alone is an incomplete search space.

DivRef was built to help with this problem. The resource contains FASTA records for common human haplotypes and variants, plus an index with population allele frequencies and variant metadata. Those FASTA files can be used directly with CRISPR off-target search tools.

I recently rebuilt the DivRef generation workflow because I wanted something more transparent, configurable, and easier to update.

Why rebuild it?

The existing DivRef generation workflow was a collection of standalone Python scripts and a Makefile. Some inputs were hard-coded; others were not fully recorded. That makes it difficult to answer basic questions later: exactly which variants were included, where did they come from, what thresholds were used, and how would the bundle change if those assumptions changed?

For some applications, that may be fine. For off-target workflows that need to account for population variation and make their assumptions visible, it is not enough.

I reimplemented the workflow in Snakemake, wrapping a Python toolkit, with a configuration schema and support for ingesting data from GCS or AWS Open Data. The workflow runs per chromosome, so a full rebuild with default parameters takes less than 20 hours on a laptop.

That makes it practical to rebuild DivRef when the underlying data change, or when a specific scientific application needs different allele frequency thresholds, population sets, or sequence windows. In general, that won’t occur very often, so a rebuild process that takes less than one day (or less on a VM with more resources) is reasonable.

What changed?

The new workflow makes several updates.

The rebuilt workflow now includes gnomAD 4.1 joint exome/genome variants in the single-variant records. The original DivRef documentation said these records were included, but the released resource did not contain them. The rebuild also updates the haplotype computation algorithm, adds chrX haplotypes, flags haplotypes with incompatible variant combinations, and exposes the main assumptions through configuration rather than hard-coded scripts.

For single-variant records, users can also specify additional populations from gnomAD 4.1. Several populations have enough samples in the larger joint dataset to be useful, even though they are underrepresented in the gnomAD 3.1.2 phased subset used to build multi-variant haplotypes.

The haplotype computation change is especially important. The original algorithm used staggered windows to aggregate nearby variants into haplotypes, then split and deduplicated the results. That approach can split true haplotypes across bin boundaries or choose one representative when the same haplotype appears with different allele counts.

The new algorithm walks each sample haplotype in genomic order, cuts parent blocks using a reference-aware gap rule, enumerates contiguous sub-fragments, and counts each parent block once. The result is deterministic and handles indel-driven gaps more cleanly.

The workflow also flags haplotypes with incompatibly phased variants instead of trying to repair them. Phasing is not perfect, especially around repeats, which can yield such cases. When the input data place mutually incompatible variants on the same haplotype, the workflow carries that information forward in the index. A downstream user can decide whether to keep or exclude those records for a particular application.

Key for off-target workflows

A CRISPR off-target search is only as good as the sequences it searches.

If a guide has a plausible off-target match created by a common haplotype, and that haplotype is not represented in the search space, the workflow will never report it. Better alignment logic cannot recover a candidate sequence that was never included.

That is why DivRef and Sassy are complementary. Sassy helps expose plausible alignments at a locus. DivRef helps make sure population-level variation and haplotype sequence are available to search in the first place.

For teams building or maintaining off-target workflows, this is the kind of detail that tends to matter late, after a method has already become part of a larger pipeline. The tool may run, the output may look reasonable, and the assumptions may still be too hidden for the next use case.

A rebuildable DivRef workflow makes those assumptions easier to inspect and change.

Read the technical write-up

This post is the short version. I wrote a more detailed technical walkthrough on GitHub covering the implementation, gnomAD 4.1 inclusion, haplotype computation, incompatible haplotype flags, chrX handling, and runtime details.

Read the full technical write-up on GitHub: https://github.com/fg-labs/divref-wf/blob/main/docs/blog.md

View the workflow: https://github.com/fg-labs/divref-wf/tree/main

Alison Meynert is a Principal Bioinformatics Scientist at Fulcrum Genomics, where she builds bioinformatics tools and pipelines for the genomics community. She previously ran the bioinformatics core facility at Edinburgh's Institute of Genetics and Cancer, where she built rare disease diagnostic pipelines for NHS Scotland. You can find her on LinkedIn and GitHub.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

CRISPR off-target analysis depends on two things that are easy to take for granted: the sequence space being searched and the alignments a tool chooses to report. A workflow can miss relevant off-target candidates if it searches only the reference genome, or if it collapses multiple plausible alignments at a locus into a single preferred answer.

This post focuses on the second problem. Tim Dunn walks through recent work on Sassy that makes it possible to enumerate all reasonable alignments for short sequences such as CRISPR guides, while keeping runtime practical. In a companion post, Alison Meynert will look at the other side of the problem: rebuilding DivRef as a configurable resource for searching human variation and haplotype sequence.

Executive Summary

Sassy (authored by Rick Beeloo and Ragnar Groot Koerkamp) is an approximate string matching algorithm that uses bitpacking and SIMD instructions to quickly search for short patterns in long texts. The recent v0.2.5 release (authored by Fulcrum in collaboration with the original authors) eliminates the computational blind spot of returning only the single ‘best’ alignment at a particular locus when searching for CRISPR guide RNA off-target sites. For a typical Cas9 guide RNA, the enhanced algorithm identifies >9X more reasonable alignments in the human genome in under 30 seconds of total runtime, allowing researchers to evaluate the full spectrum of its potential off-target interactions.

Background

When CRISPR-Cas9 edits a genome, the guide RNA is designed to direct Cas9 to a single intended target. The guide is only 20 bases, and that’s short enough that it can partially match thousands of other sites across the human genome. Cas9 will cut at any of those if the spacer binds strongly enough. Unintended off-target cuts can disrupt genes, activate oncogenes, or introduce structural variants, any of which can be catastrophic in a therapeutic setting. Before a CRISPR-based therapy can advance toward the clinic, researchers must enumerate every close-enough partially matched genomic site and characterize what a cut there would mean. This post explains how we extended the fuzzy string matching tool sassy to not just report alignment locations within a given maximum edit distance from a guide sequence, but all reasonable alignments at each location.

Why Report Every Alignment?

When investigating potential CRISPR off-target sites, looking at only the “best” possible alignment at a given location doesn’t always show the full picture.

Consider two ways to align the same guide to one off-target genomic region. For readability, the figure shows the corresponding DNA sequence on the non-target strand, followed by the PAM. This allows the bases to be compared directly without also depicting complementation or U-to-T conversion.

Alignment 1 receives a slightly better score when aligned using BWA’s default parameters, but that does not establish that it is the more biologically relevant configuration. Standard affine-gap and edit-distance scores measure sequence similarity; they are not models of guide binding or cleavage. A downstream model or domain expert may rank the same alignments differently based on the locations and types of edits, including whether the PAM remains intact.

A guide-specific scoring model could choose one configuration, but there is no single model whose assumptions are appropriate for every nuclease, guide, or experimental context. Reporting only one alignment therefore commits the analysis to one scoring model before downstream evaluation begins. Sassy instead separates candidate enumeration from biological ranking: it reports every reasonable alignment at the locus, allowing later models and experts to decide which configurations warrant further attention.

Rather than trying to claim that every reported alignment is equally likely to produce an off-target cut, the goal is to avoid eliminating plausible configurations before the appropriate biological scoring, filtering, or experimental validation can be applied.

The question of which alignments are worth reporting turns out to be surprisingly subtle, and working through it is where some interesting algorithmic ideas live. This post walks through the depth-first search at the core of sassy’s new search_all_alignments() API, developed collaboratively between Fulcrum Genomics, Ragnar Groot Koerkamp, and Rick Beeloo. The algorithm builds on sassy’s existing SIMD-accelerated search and adds a recursive backtracker that efficiently enumerates every reasonable alignment within edit distance k.

What We’re Building On

In this section, we’ll be using the language of approximate string matching algorithms. A “pattern” in this context is the sequence of characters for which you want to find partial or exact matches, e.g. a guide RNA sequence. The “text” is the sequence of characters in which you are searching, e.g. a reference genome.

Sassy already does the hard part: given a short DNA pattern (in our case a 20 bp guideRNA plus a 3 bp PAM) and a reference sequence, it uses SIMD bitwise operations to find every position where the pattern matches within edit distance k, fast. What it couldn’t do until now was report all reasonable alignments — the specific sequences of matches, mismatches, insertions, and deletions that connect the pattern to the reference sequence.

The new search_all_alignments() API adds a second pass to accomplish this:

Pass 1 is the same SIMD search sassy already uses. Pass 2 is where the new recursive depth-first search lives.

Pass 1: Alignment

Sassy’s search_all() algorithm faithfully implements Navarro’s definition of ‘Approximate String Matching’: it finds all positions in the text where an alignment of the pattern with cost ≤k ends, and returns those positions with a traceback/alignment for each. If you are unfamiliar with sequence alignment, the Needleman-Wunsch Wikipedia article on semi-global alignment provides a good introduction. Sassy uses a block-based dynamic programming (DP) algorithm based on Myers’ bit-parallel alignment algorithm to efficiently search the text. Below, an example fully-computed DP matrix shows alignment end positions where the pattern matches the text with edit distance k≤3 (highlighted in gray). For this figure (and all following matrices), we depict only the 7-base prefix of the pattern, since all remaining bases match and are uninformative.

Pass 2: Backtracking

Backtracking occurs independently for each of the alignment end positions highlighted in the final row of the above DP matrix. In order to make backtracking simple, many sequence alignment implementations store the predecessor of each cell in the DP matrix when it is first reached during the forward pass. Once the full DP matrix has been computed, backtracking is as simple as following a trail of pointers to the top of the matrix:

Since we would like to return all reasonable alignments, and not just one alignment that ends at this position, we cannot take this approach and must instead consider each possible path backwards from the alignment end position:

At each step, the depth-first search (DFS) considers three backward moves: diagonal (Match or Sub, consuming one base in both sequences), horizontal (Del, consuming text only), and vertical (Ins, consuming pattern only). Any move that would push the cumulative edit cost above k is pruned immediately. Other subtrees are explored only if they meet several additional criteria, explained in more detail below.

What Does “All Reasonable Alignments” Mean?

Before writing a line of code, the team had to answer a difficult question: which alignments should actually be reported?

Naively enumerating every path through the edit-distance dynamic programming (DP) graph is combinatorially explosive. Aligning a 23-mer and allowing k=6 edits has on the order of millions of candidate paths, and reference regions dense with N bases make things even worse. You need a principled way to thin the set.

Our discussion converged on the idea that an alignment B is not reasonable if there exists another alignment A that covers the same region with a strict subset of the edits. In this case, alignment A should be kept and alignment B should be discarded.

In general, a “reasonable” alignment with edit distance ≤k must meet the following additional criteria:

(A) it doesn’t start or end with deletions, i.e. horizontal edges (deletions don’t consume pattern bases, so the alignment should be considered complete instead of marking additional text bases as deleted when they could just not be part of the alignment)

(B) for any two points in the alignment, if the intervening positions match exactly in the text and pattern, the alignment uses those matches rather than routing around it with indels

(C) it doesn’t contain adjacent insertions and deletions (in this case, substitutions should be preferred)

For example, an alignment with CIGAR string 4=1I2=1D4= is not reasonable if another alignment covering the same positions has CIGAR string 9=, and so only 9= is reported. But 4=1X6= and 4=1I2=1D4= are incomparable (neither alignment contains a set of edits that is a subset of the other), so both get reported. Below, we explain how these criteria are enforced in greater detail:

Rule 1 — No leading or trailing deletions (Criterion A)

In general, a deletion represents a text base that is not present in the pattern. A deletion at the very edge of the aligned region is meaningless, since all text bases outside the aligned region are already not present in the pattern. For any alignment with cost c where c<k, the alignment could be left- and right-padded with up to k-c deletions. These additional alignments are not useful, and should be discarded.

Rule 2 — Don’t leave a diagonal you can extend exactly to the end (Criterion B)

Before taking an indel movement away from the current diagonal, the algorithm checks whether the remaining pattern prefix matches the corresponding text exactly:

If the prefix is all exact matches, any indel taken here produces an unreasonable alignment, since there exists an alignment (the path with all matches) with no additional edits. This rule covers criterion B from the left-hand side of the alignment.

Rule 3 — Don’t enter a diagonal reachable by exact matches (Criterion B)

The symmetric counterpart: when entering a new diagonal via an indel, the algorithm checks whether the pattern rows between the new position and the last time it visited this diagonal are all exact matches:

If these slices match exactly, then there exists an alignment with fewer edits (that never left this diagonal during this section of the alignment) and the current alignment is unreasonable and can be discarded. The key data structure here is last_row_in_diagonal, a vector that tracks, for each diagonal in the DP matrix, the most recent row in this diagonal visited during the current DFS. This logic enables enforcing criterion B from the right-hand side of each indel, ensuring that no unnecessary indels are ever included.

The following example illustrates this criterion filtering out path P2 as it extends leftwards into the dark gray cell (1,1). Because the last time this path visited the main diagonal was cell (4,4), text[1..4] = TGG is compared to pattern[1..4] = TGG and this path is pruned because alternate path P1 exists with fewer edits.

Rule 4 — No insertion-deletion mixing without a match anchor (Criterion C)

In an alignment, adjacent insertions and deletions can always be replaced by substitutions. For every alignment that includes a mismatch (X), reporting a pair of adjacent indels (ID or DI) as well is not useful. This rule avoids reporting all such alignments, but still allows D=I and I=D when == does not work.

Summary

The result of applying these four rules during a depth-first backtracking search is an iterator that delivers every structurally distinct alignment within cost k, without reporting unreasonable alignments, and without materializing the exponential set of possible alignments first.

The above figure visualizes all seven search_all_alignments() results reported on this example, and you can see that both Alignment #1 and Alignment #2 from the very first figure in this blog post are depicted here as paths P6 and P1, respectively.

Optimization: Filtering N-dense Regions

Reference sequences frequently contain hard-masked regions, most often due to assembly gaps caused by repetitive regions such as centromeres or telomeres. These are present in the FASTA as long stretches of N bases (e.g. NNNNN…) which result in a large number of uninformative alignments, since all bases A/C/G/T are considered a Match with N. To enable filtering these alignments, search_all_alignments() provides the argument max_n_frac, which defaults to 0.2. Any alignments where more than 20% of the aligned reference bases are Ns are discarded.

In many such cases, we can avoid computing the recursive DFS entirely using known properties of the alignment and text. All alignments of a pattern to the text with edit distance ≤k must have length of at least len(pattern)-k and at most len(pattern)+k. The alignment’s end_pos in the text has been computed by search_all(), and is known. Thus, all alignments will cover the region text[end_pos - (len(pattern)-k).. end_pos], though some may extend further leftwards. If the number of Ns contained in this text substring divided by the maximum possible alignment length (len(pattern)+k) exceeds max_n_frac, no alignments from this position will be valid and the recursive DFS can be skipped entirely. Since the pattern length is 23 and k is usually less than or equal to 6, as long as max_n_frac is below 58%, all alignments fully within hard-masked regions will be skipped.

Conclusion

Aligning the guideRNA sequence GAGTCCGAGCAGAAGAAGAANGG (from Zhang 2013) to a GRCh38 reference FASTA with k=6 results in the following high-level metrics, computed on an Apple M3 Max:

In under 30 seconds, we are able to find all reasonable alignments of the guide RNA to the human reference genome. The new N-region pre-filtering and recursive backtracking steps add less than 10 seconds of runtime, yet they are able to discard over 99% of hits as uninformative and increase the total number of useful alignments by over 9x! This is important because any alignments which are not reported are unable to be filtered and evaluated by a human expert. Removing this computational blind spot is cheap and fast, potentially saving significant time and money on downstream validation efforts.

Sassy is currently available on GitHub. The alignment iterator work is complete and has been incorporated into the recent sassy release v0.2.5.This release includes both a Rust implementation and Python bindings for Searcher.search_all_alignments().

Tim Dunn is a Staff Bioinformatics Scientist at Fulcrum Genomics, where he builds bioinformatics tools and pipelines for the genomics community. He earned his PhD in Computer Science from the University of Michigan and is the author of vcfdist, a method for accurately benchmarking small variant calls. You can find him on LinkedIn and GitHub, where he's still trying to convince two variant callers they made the same call.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

That kind of staying power is a credit to the original tool. It also creates a familiar problem in bioinformatics: once a tool becomes standard, the field starts treating its limitations as part of the landscape.

Tim Fennell recently wrote about this in Bioinformatics Still (Mostly) Runs on Old Plumbing. A lot of useful work in genomics happens below the visible layer of new assays and new methods, in the libraries, file formats, utilities, and command-line tools that carry the everyday workload. When those tools get faster or more reliable, the benefit spreads across many workflows at once.

The new preprint from Heng Li and Fulcrum Genomics’ Nils Homer is a concrete example of that argument.

Minibwa takes on one of the most widely used pieces of genomic infrastructure: read alignment.

Moving past strict compatibility

A lot of recent work on BWA-MEM has focused on acceleration while preserving BWA-MEM-like behavior. BWA-MEM2 improved performance. BWA-MEME, BWA-MEM3, GPU implementations, and other efforts have pushed the limits of the approach.

That work is valuable, but strict compatibility creates a ceiling. If a tool has to stay close to BWA-MEM by design, there are only so many algorithmic changes and code optimizations it can make.

Minibwa takes a different approach. It does not try to be a bit-identical replacement for BWA-MEM. It keeps pieces that still make sense, including BWA-MEM-style variable-length seeding, but combines them with newer approaches from minimap2 and ropebwt3.

The result is a mapper designed for standard WGS short reads, Hi-C reads, accurate long reads, and directional bisulfite sequencing data.

In practical terms, minibwa introduces:

• a faster batched SMEM-finding algorithm

• minimap2-style chaining adapted for variable-length seeds

• SIMD-based base alignment

• more frequent use of ungapped fast paths

• reduced effort in highly repetitive regions where short reads are unlikely to be placed accurately

• native support for directional bisulfite sequencing

That last point is worth calling out. BWA-Meth made bisulfite alignment practical by wrapping BWA-MEM. BISCUIT went deeper by modifying the BWA-MEM source code. Minibwa brings bisulfite-aware mapping into a faster framework rather than treating it as a layer bolted onto older assumptions.

The speedup is substantial

The headline result is speed.

In the reported benchmarks, minibwa is about four times as fast as BWA-MEM and more than twice as fast as BWA-MEM2 for standard WGS short-read alignment, while maintaining comparable accuracy. For long-read data, it is slightly faster than minimap2 in the reported tests. For bisulfite sequencing, it is several times faster than BWA-Meth and BISCUIT, and more than 10 times faster than Bismark.

That kind of improvement is important because alignment remains a real cost center in many genomics workflows. In complementary work, we re-wrote fgbio into fgumi finding significant speedups in the fgbio tools (over 25x), finding that now alignment is the dominant bottleneck in the end to end workflow.

Even when it is not the only bottleneck, it is often one of the steps teams have learned to scale around. More cores. More waiting. More Cloud spend. More acceptance that the old path is simply the path.

Minibwa shows that some of that cost is not inherent to the problem. Some of it comes from inherited design choices.

As Nils puts it:

“Every hour and every dollar spent on alignment sits between a sample and an answer. Cutting both reaches the patient, the clinical report, and the researcher.”

Accuracy still has to survive downstream

A faster aligner is useful only if the downstream results hold up.

On simulated WGS short reads, BWA-MEM remains slightly more accurate in some settings, largely because of centromeric and acrocentric regions. Minibwa spends less effort in regions where short reads are often difficult or impossible to place accurately because of repetitiveness and structural variation.

That is the tradeoff, and it’s worth considering for your own pipelines. But we think the better question is whether it changes the outputs users actually care about.

For small variant calling, the reported answer is encouraging.

In the preprint, HG002 short reads were aligned to GRCh38, variants were called with DeepVariant, and results were compared to the GIAB Q100 truth set. Minibwa closely matched or slightly improved on BWA-MEM: fewer SNP false negatives, fewer SNP false positives, fewer indel false negatives, and slightly more indel false positives.

That is the right kind of benchmark. Alignment metrics are informative, but production users need to understand whether changes in mapping behavior affect the calls, reports, and decisions that sit downstream.

The Fulcrum view

At Fulcrum, we care about this category of work because it is highly leveraged.

Most genomics teams do not need novelty for its own sake. They need pipelines that run faster, cost less, behave predictably, and keep up with changes in sequencing technology. Sometimes that means building new methods. Often it means improving the tools people already depend on.

Minibwa fits that pattern. It addresses a real bottleneck, supports multiple read types, reduces unnecessary computation, and evaluates downstream impact instead of stopping at raw speed.

For teams running large-scale WGS, bisulfite sequencing, Hi-C, or mixed read-length workflows, minibwa is worth watching closely — especially where alignment time is starting to shape cost, throughput, or pipeline design.

Read the preprint

The preprint, “Fast genomic read alignment with minibwa,” is available now. The source code is available on GitHub.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

Bioinformatics has a weakness for novelty. That is understandable enough in a field built around publications that prefer new methods, new assays, and new ways of extracting signal from data, but it leaves a blind spot. A lot of the work still runs through old libraries, old file-format code, old command-line utilities, and old assumptions about what counts as acceptable performance. Once those things become standard, people stop looking at them very hard. They learn the rough edges, budget around the delays, and treat the friction as part of the landscape.

I don’t think that is a great habit.

If a tool sits in the path of thousands of workflows, any inefficiency in that tool gets paid again and again. The same goes for awkward implementations, stale assumptions, and missing features that everyone has worked around for long enough that they no longer seem strange. Familiarity has a way of lowering standards. A lot of core tooling in bioinformatics gets treated as settled long after it has stopped being current.

One thing that makes this especially odd is that people do recognize the value of this work when it shows up in a product. Nobody is confused about why faster software is worth paying for. Products like DRAGEN and Sentieon make that point well enough. What gets less attention is the open-source tooling underneath a much larger share of the field’s day-to-day work. The value there is just as real, but it is spread across enough users and enough workflows that it often goes unclaimed.

I have been spending a fair amount of time on that layer of the field lately, partly because I think it is undervalued and partly because the leverage is often better than people realize. When you improve a method that gets used once in a niche workflow, you have improved a method. When you improve a library, file format implementation, or utility that other tools build on, you end up improving a much larger slice of the field all at once.

File formats and I/O still deserve real engineering effort

A recent example is the work that went into HTSJDK. I put a lot of effort into a recent release that adds CRAM 3.1 writing and makes CRAM and BAM read/write substantially faster. That work lands in one library, but the effect carries into Picard, GATK, IGV, fgbio, and a long tail of other tooling that depends on it. There is nothing glamorous about faster BAM and CRAM handling, but there is also no serious argument that it is unimportant when so much other software is standing on top of it.

One small part of that work was building jlibdeflate, Java bindings for libdeflate. Libdeflate has been around for close to a decade and is widely recognized as one of the fastest block-deflate implementations, so it was surprising to realize the Java ecosystem still lacked a clean way to use it. That is a pretty good example of the kind of gap I mean here: not some grand new method, just an obvious missing piece in heavily used tooling that, once filled in, improves a lot of downstream software.

There is a tendency to talk about work like this as though it were just maintenance. Sometimes it is maintenance. Sometimes it is finally correcting an obvious deficiency in widely used tooling that had gone unaddressed for years. I would put a lot of this in the second category.

The boring steps in a workflow still run on every dataset

The same pattern shows up lower down in the pipeline. I am getting ready to release chelea, a faster, more accurate tool for short-read adapter trimming. My co-founder, Nils, has released mako, which sorts BAM files substantially faster than samtools sort. Nobody is going to confuse adapter trimming or BAM sorting with the exciting part of genomics, but they are steps that show up constantly across real production workflows, where inefficiency compounds very quickly.

In one sense this is no different from why people value DRAGEN or Sentieon. Speed, better implementation, and fewer operational headaches are easy to appreciate when they show up in steps you run all the time. The difference is that open-source plumbing often has no obvious owner, even when the user base is broader and the cumulative waste is larger.

A lot of this work lingers for the same reason. The payoff is broad, but not concentrated. Faster compression, better BAM and CRAM handling, a faster adapter trimmer, a better BAM sorter, or a speedup in a heavily used imputation or QC tool can improve a lot of workflows at once. However, no single group usually feels enough of the pain to justify taking it on, so the work sits there until somebody gets annoyed enough to do it for the broader user base.

Some of the best work is improving tools other people already use

Not all of this shows up as a new release from us. Some of it is just contributing back to tools that are already broadly useful and already embedded in other people’s work.

I have open pull requests into GLIMPSE that improve single-sample low-pass imputation performance in glimpse2_phase by about 30 to 50 percent. I have also had pull requests merged into verifyBamID that make the compute-heavy optimization phase roughly 20 times faster and add support for non-human genomes. Nils has also been spending time on bwa-mem3, a fork of bwa-mem2 that is faster, includes a number of quality-of-life improvements, and supports non-Intel architectures. None of that fits neatly into the usual story people like to tell about innovation, but it is the sort of work that makes existing workflows better in ways users feel immediately.

I don’t think every old tool needs a rewrite, and I don’t think starting over is automatically admirable. In plenty of cases the better answer is to speed up the thing people are already using, fix the part that is wasteful, or add the capability that should have been there in the first place. There is a lot of value in meeting the ecosystem where it is instead of pretending value only appears when you create something brand new.

We underrate accumulated drag

Part of the reason this work gets less attention is that accumulated drag is hard to see. A new method is easy to point at. An old dependency that is 30 percent slower than it needs to be, or a file-format implementation that has not kept up, tends not to announce itself with the same clarity. People absorb the cost in small increments. They wait a little longer, provision a little more compute, put up with some awkwardness, and move on.

A lot of the value in this layer of the stack is real, but diffuse. Faster BAM and CRAM handling in HTSJDK, Java bindings for libdeflate, a better adapter trimmer, a faster BAM sorter, a speedup in GLIMPSE, or a much faster optimization loop in verifyBamID all make real workflows better. The problem is that the gain often lands a little bit everywhere, which makes it harder for any one group to justify doing the work. So a lot of it sits there until somebody gets annoyed enough to fix it for the broader user base.

AI changes that calculus some. A lot of this plumbing work used to be easy to defer because it was tedious, sprawling, and hard to justify against more visible priorities. Lowering the cost of implementation makes more of it tractable. That does not make the work glamorous, and it does not remove the need for careful engineering, but it does make it more practical to go fix things that many people depend on and no one had quite gotten around to fixing.

Some of the most valuable work happens in the tools underneath the tools

The field does not need less ambition. It does need a broader view of what ambitious work looks like.

Sometimes it is a new method. Sometimes it is a new model. Sometimes it is a much faster BAM/CRAM implementation, a missing binding that should have existed years ago, a better adapter trimmer, a faster sort, or a pull request that takes a painful optimization loop and makes it 20 times faster. The common thread is leverage. When a tool sits low enough in the stack and gets used widely enough, improving it pays off across a lot of other work.

That is why I think this layer deserves more attention than it gets. Not because it is fashionable, and not because every old tool is secretly broken, but because a lot of scientific software still depends on code that can be made materially better with focused effort.

That will never be the glamorous part of bioinformatics.

It is still some of the most useful work you can do.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

Jess Smith (GitHub) 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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

Matt Stone (GitHub) joined Fulcrum Genomics 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.”

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.

Alison Meynert (GitHub) 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.

Fulcrum Genomics is a bioinformatics consulting firm built by scientists at the forefront of large-scale genomic research, with deep expertise in sequencing technology, pipeline engineering, and genomic data analysis for biotech, pharma, and academia. Engage us through project-based work, fractional R&D, or hourly consulting. Contact us to discuss your project.