Skip to content

Talos

Talos is a scalable, open-source variant prioritisation tool designed to support automated reanalysis of genomic data in rare disease. It identifies candidate causative variants in known disease genes by integrating static annotations (e.g. population frequency, predicted consequence) with dynamic knowledge sources such as ClinVar and PanelApp Australia. Talos applies a set of configurable, rule-based logic modules aligned with ACMG/AMP criteria and prioritises variants consistent with expected mode of inheritance and, optionally, patient phenotype.

While Talos can be used for one-off reanalysis of individual families or cohorts, its core design is optimised for routine, cohort-scale reanalysis. By comparing current annotations with prior results, Talos highlights variants that have become reportable due to newly available evidence — such as new gene–disease or variant–disease relationships — since the last analysis cycle.

A full description of the method and its validation in large clinical and research cohorts is available in our preprint: medRxiv 2025.05.19.25327921.

Note - whether you are a new Talos user, or have an implementation already, we encourage you to run the preparation workflow with each update!

Latest Changes

[0.3.0]

Changed

  • The annotation workflow now runs echtvar and bcftools csq on a sites-only copy of each normalised shard (all samples dropped), then lifts the resulting INFO fields back onto the full-width shard with bcftools annotate. Only bcftools norm/+fill-tags and the final lift touch the genotype columns, so the per-shard cost no longer scales with cohort width for the annotation tools themselves. AnnotateWithEchtvar and AnnotateCsqWithBcftools are replaced by a single AnnotateShard process - update any withName: resource blocks accordingly.
  • The gnomAD AF < 0.05 pre-filter has moved from echtvar's -i expression to a bcftools view -e 'INFO/gnomad_AF >= 0.05' on the annotated full-width shard. Variants absent from gnomAD (gnomad_AF=0) are retained exactly as before.
  • Annotated shards are now published with a .tbi index alongside. Existing ${cohort}_annotated directories (without indexes) remain valid - the manifest still names the shards to reuse.

  • The gnomAD 4.1 annotation source has been changed - the new Zenodo record is https://zenodo.org/records/22297079, and it is referenced by a new name in the config file to differentiate the two versions. The new version of the data contains fewer annotations, but spans every base in the gnomAD dataset, which prevents issues where frequency annotations could have been missing due to over-zealous region filtering when generating the original record.

  • NormaliseVcf writes its full-width intermediate at the lightest BCF compression level with threaded deflate, and AnnotateShard compresses its output across task.cpus (now 2). Deflate was ~70% of the per-shard runtime.

Removed

  • Annotated shards no longer carry a per-sample FORMAT/BCSQ bitmask. Nothing in Talos read it; INFO/BCSQ is unchanged.
  • FORMAT/PL is dropped from every shard during normalisation, and so is absent from the annotated and labelled VCFs. Talos never read it (only GT, GQ, DP, AD and the phasing fields), and it was the widest per-sample field - published shards shrink by roughly a fifth.

[0.2.0] - 2026-08

Added

  • Adds a new category for BND variants occurring in Exons

[0.1.0] - 2026-08

  • Every main.nf run now writes talos_input_YYYYMMDD.tsv to the root of the output directory - a copy of the run's input TSV with each cohort's history cell repointed at the results JSON that run published, ready to be reviewed and used as the --input_tsv for the next reanalysis cycle.
  • This aims to bridge the gap in the current implementation, where inputs and analysis outputs need to be manually updated for future cycles. Feel free to use this or ignore it :)

[0.0.2] - 2026-08

Changed

  • Really reduces the per job resource requirements. This may be insufficient in HUGE cohorts, but has been successful in mid-sized (50-genome) testing. Users are invited to customise based on local requirements.

Fixed

  • Fixes the mechanism NextFlow uses to find adjacent-files, and carry out file globbing. This was fine for local deployments, but buggy in cloud environments due to String trimming.

[0.0.1] - 2026-08

Added

  • Welcome to the new repository! This is Talos 2.0, designed to be easier to deploy outside the CPG and Hail Batch-using sites. Instead of using Hail/Spark as a processing framework, this reimagined version uses a more basic map/reduce framework, scattering the input data as sharded VCFs, annotating and filtering in pieces, and re-forming a final VCF input from the minimal set of relevant variants. No Hail runtime, no MatrixTables, no Spark cluster. Just VCFs. This feels like a good compromise given the considerations - this needs to remain site-agnostic, making few assumptions about available infrastructure, but needs to run relatively quickly across cohorts of all sizes. This will still present scaling issues at super-high cohort sizes, but it represents dramatic improvements over the original Talos implementation at non-Spark enabled sites.

Changes from the original Talos

  • The labelling/filtering phase which runs on the annotated data has been rewritten as a loop over an annotated VCF fragment, instead of requiring data to be read into a MatrixTable and processed in a single highly-resourced runtime.
  • The annotation workflow no longer physically splits the input VCF (SplitVcf is gone - it was a serial pass over the whole callset). Scatter regions are now derived from the VCF index (MakeScatterRegions), with each NormaliseVcf task reading only its region from the input; params.vcf_split_n is now the target records per region, and 0 still disables the scatter.
  • MakeScatterRegions now stages only the .tbi - bcftools index -s reads contig, length and record count from the index alone, so the whole-callset VCF is no longer localised into that task.
  • Outputs are split per cohort: annotation products (annotated shards, shard manifest, annotated SV VCF) publish to {cohort}_annotated/, and analysis results to a dated {cohort}_analysis_YYYYMMDD/. The {cohort}_annotated directory is reusable across reanalysis cycles and safe to delete to force re-annotation. Migration: existing output directories keep annotation products in {cohort}_outputs/ with no manifest - re-run main.nf once to regenerate into the new layout.
  • Annotation writes a per-cohort {cohort}_manifest.json naming exactly the shards it produced, and is now idempotent: cohorts whose manifest already exists are reused (shards read from the manifest, never a directory glob), so stale shards from an earlier annotation run (e.g. a different vcf_split_n) can never be double-counted, and a reanalysis cycle is simply a re-run of main.nf. A new optional params.annotated_dir lets a run read annotation products from a different location than it publishes results to.
  • VCF ingestion in ValidateMOI no longer iterates the full cohort three times per variant - depths, alt depths and AB ratios are sliced from the genotype arrays at carrier positions only, and phase data is read for carriers only. Per-variant config lookups (exomiser rank, de novo thresholds, CSQ field names) are now resolved once per process.

Removed

  • talos_only.nf - redundant now that annotation is idempotent; re-run main.nf for reanalysis cycles instead.

Full changelog

Where to next

  • Getting Started Install the requirements, download annotation resources, and run your first cohort.

  • Features Logic modules, reanalysis mode, phenotype matching, and what Talos is (and isn't) for.

  • Configuration Full reference for the Talos TOML config and Nextflow parameters.

  • SV Annotation Project document for the SV annotation and integration project.

  • Changelog Release history and version-by-version changes.

When to use Talos

Talos is best suited for scenarios where:

  • You are performing routine reanalysis of undiagnosed individuals (e.g. monthly or quarterly).
  • You want to detect variants that have become reportable due to updates in gene–disease or variant–disease knowledge.
  • You aim to minimise the number of variants requiring manual review, optimising for specificity over sensitivity.
  • You are working with exome or genome sequencing data from previously analysed research or clinical cohorts.
  • You need a scalable, reproducible pipeline for family-based or cohort-scale analysis.

Talos is not currently designed for:

  • Identifying novel candidate disease genes or gene discovery.
  • Analysing short tandem repeats (STRs), mosaic variants, or variants outside standard clinical reporting regions.

Support for some of these variant types may be added in future releases.

Citation

If you use Talos in your research or clinical workflow, please cite:

Welland MJ, Ahlquist KD, De Fazio P, et al. Scalable automated reanalysis of genomic data in research and clinical rare disease cohorts. medRxiv 2025.05.19.25327921; https://doi.org/10.1101/2025.05.19.25327921

@article{welland2025talos,
  title     = {Scalable automated reanalysis of genomic data in research and clinical rare disease cohorts},
  author    = {Welland, Matthew J and Ahlquist, KD and De Fazio, Paul and Austin-Tse, Christina and Pais, Lynn and Wedd, Laura and Bryen, Samantha and Rius, Rocio and Franklin, Michael and Hall, Giles and et al.},
  journal   = {medRxiv},
  year      = {2025},
  doi       = {10.1101/2025.05.19.25327921},
  url       = {https://www.medrxiv.org/content/10.1101/2025.05.19.25327921},
}