Recipes and reproducibility

Every run the daemon makes writes recipe.json beside its outputs: the daemon's version and platform, the tool and its parameters, every input with its size and sha256, and the studio's metadata (step, scope, label, parents). A result cites the run; the run cites its inputs by checksum.

{
  "recipe": 1,
  "job": "mutopia-1792864225-1",
  "sigscape": { "daemon": "0.2.0", "api": 1, "target": "x86_64-unknown-linux-gnu" },
  "tool": "mutopia",
  "params": { "tumor_type": "Breast-All", "sample": "BC_BR001_tumor" },
  "inputs": {
    "vcf": { "path": "data/hg38/BR001.vcf", "bytes": 8716521, "sha256": "fb2dfa5e…" },
    "ref_fasta": { "path": "data/hg38/hg38_genome.fa", "bytes": 3273481150, "sha256": "5be01555…" }
  }
}

The run's job.json and daemon.log sit beside it, and the export zip carries all three.

One numerics, three surfaces

What the page computes itself (cosine similarities, resampling nulls, non-negative least squares with bootstrap intervals, optimal matching, opportunity correction, mixture weights by EM) comes from one Rust crate, sigscape-core, compiled to WebAssembly for the browser and natively into the local runner, which can recompute any page result (see Checking a result). The repository's parity test holds the builds to agreement within 1e-9; they agree exactly. Random draws take an explicit seed and use one generator, so a bootstrap is the same in a notebook and in the page.

Catalogs are versioned

Every catalog the studio knows is a file under /catalogs/ with a manifest naming its version, source, license and sha256: COSMIC v3.4 (GRCh37, GRCh38, exome), COSMIC v3.2 as MuSiCal and SigMA2 ship it, and the 208 MuTopia components. An exposure table or an Add object is keyed to the catalog its names belong to when it arrives, and the crosswalk between catalogs records what was renamed, split (SBS40 into SBS40a, b and c) or merged.