mSigSDK

Mutational signatures are how we read a tumor's history: the pattern of DNA typos a cancer carries points back to what caused them, from tobacco smoke to a broken repair pathway. The catch is that the field reads those patterns with several different software tools, and the tools do not always agree. At the National Cancer Institute I built mSigSDK, a JavaScript library that runs four of those tools side by side in a web browser, with no installation and no data leaving the machine, so a researcher can see the agreement and the disagreement in one place. It was published in BMC Bioinformatics in 2026.

Evidence

Paper: Ge A, Zhang T, Martins YC, et al., “mSigSDK: browser-native computation of mutational signatures,” BMC Bioinformatics 2026, DOI 10.1186/s12859-026-06681-z. Project site: episphere.github.io/msig. Code (MIT): github.com/episphere/msig. Documentation: episphere.github.io/msig/docs.

The setup

A tumor's DNA keeps a record of what damaged it. Sunlight, tobacco smoke, and the cell's own copying errors each leave a different pattern of typos, called a mutational signature. A spectrum is a tumor's pattern, an exposure is how much of a known signature it contains, and the COSMIC catalog is the reference shelf of known patterns that a tumor's pattern gets matched against.

Presenting problem

Mature tools exist, but each needs a local install and its own input format, so triangulation across tools is expensive and rare. There was also no standard machine-readable format recording an analysis's parameters, review evidence, and provenance, so results were hard to audit or carry between tools. Most researchers ran one tool and trusted it, and the paper shows the choice of tool changes the answer.

What I built

A modular JavaScript SDK loaded by a single dynamic import, with spectra and MAF rows staying on the device and a strict-local mode that blocks even public-data lookups. It runs four established tools through one adapter layer: SigProfilerAssignment, MuSiCal, deconstructSigs, and sigminer. It adds its own NNLS fitting, NMF-based exploratory extraction, a MAF-to-spectrum converter, rule-based review evidence, and schema-validated portable reports. Page load to a rendered local report takes about 1.82 seconds.

The disagreement is the finding

On 2,700 synthetic spectra with known truth, every tool's exposure estimates stayed close (mean cosine above 0.96), but at 10% noise the tools' calls for which signatures are active ranged from F1 0.532 to 0.924. On the real PCAWG cohort the four tools called between 4.13 and 17.39 active signatures per sample, while all of them rebuilt the spectra well (cosine 0.982 to 0.994). Same data, four different answers to “what caused this cancer,” all numerically tidy.

In the 38 lung spectra, SBS4, the tobacco-linked signature, was the largest single fitted signature, and raising the reporting cutoff from 0 to 5% cut the mean number of reported signatures more than six-fold while costing less than 0.04 of reconstruction cosine.

Validation

Each adapter reproduced its package's own local results on 38 public PCAWG lung adenocarcinoma SBS96 spectra (exact for three tools, floating-point precision for the fourth). The MAF converter matched SigProfilerMatrixGenerator exactly on the tested SBS96, SBS1536, DBS78, and ID83 fixtures.

Discharge summary

Published in BMC Bioinformatics (2026), MIT-licensed and public at episphere.github.io/msig, with documented API and worked notebooks. The demo at the top of this page runs the tutorial’s own chart component in this page: the SDK’s SBS96 renderer drawing the real COSMIC v3.6 profiles. mSigPortal (analysistools.cancer.gov) is related work only: a separate NCI portal and a separate manuscript, under review at Cancer Research; here it appears only as a public data source the SDK reads from.

What I would do differently

The adapter fidelity checks rest on one tumor type, one profile type, and one catalog, so I would widen the benchmark before claiming the browser paths match everywhere. The tested browsers are desktop Chrome, Edge, and Firefox (Safari itself was not tested, only a WebKit-family engine), so mobile and Safari support is still an open job. And I would ship the disagreement demo first, because it teaches the point faster than any methods text.