Skip to content

Spike prep diverges from legacy: in-frame codon deletions dropped, replicate subset differs #313

Description

@jaredgalloway

STUB — this is a goal only, not a spec. Run /spec <this issue number> before implementing.

Goal

Reconcile the SARS-CoV-2 spike pipeline's data-prep stage with the legacy analysis, and decide whether to retain in-frame codon deletions in the fitted variant set.

Finding 1 — in-frame codon deletions are dropped (original-sin defect)

experiments/scv2-spike/notebooks/prepare_data.ipynb (cell 9) filters out every variant containing a deletion:

has_deletion = df["aa_substitutions"].str.contains("-", regex=False)
df = df.loc[~has_deletion].copy()

This filter has been present since baaa0dc, the first commit of the spike pipeline — it is not a regression, it is an original-sin defect.

The legacy analysis kept them: matsengrp/SARS-CoV-2_spike_multidms@6c98b7b, data/prepped_func_scores.csv, whose first row already contains N439- and L1244-.

There is no encoding obstacle. A deletion is written <WT><site>- (e.g. P25-), structurally identical to a substitution, and every fitting entry point already builds its BinaryMap over multidms.AAS_WITHSTOP_WITHGAP, whose alphabet includes -.

Measured cost, restricted to the 6 replicates our config selects (Delta-2, Delta-4, Omicron_BA1-2, Omicron_BA1-3, Omicron_BA2-1, Omicron_BA2-2):

Quantity Count
Unique deletion-bearing variants dropped 8,312 (2.7% of the fittable set)
Unique deletion mutations lost 881
...of those, with >=5-variant support 354
...singletons 215
Total unique mutations currently fitted 12,400

Top deletion mutations by variant support: P25- (175), N164- (123), F140- (118), T250- (113), L241- (109), H66- (104), W64- (104), I68- (103). These are NTD antigenic-supersite residues — the deletions with the most data are exactly the ones with a plausible antigenic story, which is why this is worth deciding deliberately rather than leaving as an accident.

Finding 2 — the 999,055 -> 303,007 row gap is NOT filtering

Earlier framing of this as a "3x drop from count/max_subs filters" was wrong. The exact like-for-like accounting:

legacy, all 9 replicates                        999,055 barcodes
  |- restricted to our 6 replicates             689,433 barcodes
       |- unique (condition, aa_substitutions)  308,515 variants
            |- minus WT/synonymous (6)          308,509
                 |- minus deletion-bearing      300,197
OURS (results-prod-294, as fitted)              303,007

Two causes, neither of them a count filter:

  1. Barcode -> variant aggregation. Legacy rows are barcodes; ours are aggregated variants. This is correct behavior, not a loss.
  2. Replicate subset. Legacy uses 9 replicates; config.yaml selects 6.

max_subs: 10 drops only 235 legacy rows. The count thresholds are not the story.

Open question that must be answered by the spec

If deletions are restored, λ = 8.0e-05 is no longer supported by its existing evidence and must be re-derived. shift_sparsity uses stop codons as its false-positive-rate denominator, and deletions are invisible to it. Adding ~881 new β entries without changing that denominator makes the current λ justification non-transferable. See config/config_downstream.yaml lines 9-45 for the derivation that would need redoing.

Starting point

A working edit that restores deletions in prepare_data.ipynb (plus the matching evaluate.ipynb / manuscript_figures.ipynb follow-through) was parked out of PR #311 as a git stash so it would not land unreviewed:

  • commit 8d911b50995e3faab4871f696f63a5bed3c73fce, tagged deletion-restoration-313 and pushed to origin
git fetch origin --tags
git show deletion-restoration-313          # view the diff
git cherry-pick -n deletion-restoration-313  # or apply it onto a fresh branch

(It began life as a git stash in the PR #311 worktree; it was tagged before that worktree was removed, so it is now durable and no longer depends on any local checkout.)

Related

Stub #312 — library mut_type() (multidms/model_collection.py:1301 and :1368) mislabels deletions as "nonsynonymous". Any deletion work must land alongside or after that fix, or the mutation-type breakdowns will be wrong.

Metadata

Metadata

Assignees

Labels

stubGoal-only draft — needs brainstorming → /spec <N> before work

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions