Oncofusion

start / graph / ana-q117-gse260742-deposits-no-spike-in-scale-factors-and-152-of-its-158-samples-are-tdf-only

Analysisestablished confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.Q117-gained-fusion-occupancy

The premise that GSE260742 'carries a ChIP-Rx spike-in' does not survive reading the deposit: zero of 158 sample records mention a spike-in, the only ChIP-Rx experiment in the paper is an H2AK119ub panel that is not identifiable among the deposited samples, and 152 of 158 samples ship only an unnormalised igvtools .tdf

also called Q117 normalisation verification · GSE260742 has no deposited scale factors

Before comparing a protein's position on DNA between a drug and a control, you have to know how the two experiments were put on the same scale, and here they were not. The public files are raw coverage with no scaling information at all, so any fold-change between conditions would be measuring the scaling rather than the biology.

The same thing, for a scientist

The dispatch brief for this beat, following a cycle-65 entry, stated that GSE260742 carries a ChIP-Rx spike-in and that this is what makes cross-condition comparison legitimate. **Checked directly against the deposit and against the paper, and the premise is wrong for every arm this beat needs.** A case-insensitive search for `spike`, `drosoph`, `dm6`, `dm3`, `S2 cell`, `scale factor`, `normaliz` and `normalis` over the complete 419,824-character SOFT dump of **all 158 sample records returns zero hits** [E1]. The word *spike-in* appears exactly once in the paper's chromatin analysis, in the legend of Extended Data Fig. 4d: *"Average profile plots of H2AK119ub ... in a ChIP-Rx ChIP-seq experiment. Drosophila S2 chromatin was used as a spike-in control to normalise ChIP-seq data"* [E2]. That is an **H2AK119ub** panel. It is not the FLAG arm, not KDM2B and not BCOR, and no deposited sample is labelled as its output. What the deposit actually contains is **152 `.tdf` files, 2 `.bam` files and 4 records with `supplementary_file = NONE`** [E1]. The paper's Methods say the TDFs were made with `igvtools (count)` **for genome-browser snapshots**, and that the quantitative figures were made from **RPGC-normalised bigWigs produced with bamCoverage** plus 5 kb-bin featureCounts **"normalized to sequencing depth as reads per million"** [E2]. The bigWigs are not deposited. **So the deposited processed data are raw coverage, and the normalisation the paper used is depth-based, not spike-in-based, for everything except one H2AK119ub panel.** The consequence, adopted as a binding constraint for this whole beat before any signal was read: **no fold change between conditions is reported as a biological gain.** Cross-condition statements are within-sample percentile ranks or within-sample signal shares, both of which are invariant to an unknown per-sample scale factor.

Go deeper
What was checked, in the order it was checked
  1. acc.cgi?acc=GSE260742&targ=gsm&form=text&view=brief - the SOFT text view for all samples at once, which is authoritative and not behind bot detection. 158 ^SAMPLE records, 419,824 characters.
  2. Grep for the spike-in vocabulary across the whole dump: 0 hits, for eight different strings.
  3. Tabulate !Sample_supplementary_file_* by extension: 152 tdf, 2 bam, 4 NONE.
  4. Read the paper's ChIP-seq Methods section in the retrieved fullTextXML (PMC12904788, 142,554 characters of stripped text) rather than its abstract.
  5. Locate every occurrence of spike, Rx and Drosophila in that text and read the surrounding 400 characters.

Step 5 is the one that matters. A reader who greps for ChIP-Rx and finds a hit will conclude the series is spike-in normalised. The hit is a figure legend for one panel of one antibody.

Why a rank and a share survive a missing scale factor, and a fold change does not

Let the true occupancy at bin i in sample s be x_si and the deposited coverage be k_s * x_si, where k_s is the unknown and unrecoverable per-sample constant.

  • A fold change k_v*x_vi / (k_d*x_di) carries the factor k_v/k_d and is therefore uninterpretable.
  • A within-sample rank is invariant to k_s outright, because ranking is invariant to multiplication by a positive constant.
  • A within-sample share sum_H(k_s*x_si) / sum_all(k_s*x_si) cancels k_s in numerator and denominator, so the ratio of two samples' shares is well defined even though neither sample's absolute scale is.

This is why this beat reports the fusion's share of its own track at its own sites rather than its fold change. It is not a weaker statement than a fold change with a bogus scale factor; it is the statement the data can support.

What this does not say

It does not say the authors did anything wrong. They deposited genome-browser files, which is normal practice, and they reported the normalisation they used. It says that a re-analyst who wants to compare conditions cannot recover their scaling from the deposit, and that a cycle-65 corpus entry asserting the series 'carries a ChIP-Rx spike-in' over-states what is there. Raw reads are in SRA (for example SRX23818722/23/24 for the three FLAG samples), so a spike-in-free but depth-controlled re-alignment is possible; a spike-in-normalised one is not, because the spike-in reads were never separated out in anything public.

Facts and figures
scriptanalyses/q117-gained-fusion-occupancy/run117.py (Q117Bin.java for the tdf reader)
statusrun
result summaryNo spike-in and no scale factors are recoverable from GSE260742. 152/158 samples ship only an unnormalised igvtools .tdf. All cross-condition statements in this beat are within-sample ranks or within-sample shares.
seriesGSE260742
samples total158
spike in hits across all 158 records0
paper normalisation as writtenigvtools count -> TDF for browser snapshots; bamCoverage -> RPGC bigWig for heatmaps and profiles; featureCounts over 5 kb bins -> RPM for region analysis
the one spike in experimentExtended Data Fig. 4d, H2AK119ub only, Drosophila S2 chromatin
premise correctedThe dispatch brief and the cycle-65 entry ana-q115-gse260742-turns-the-gained-fusion-occupancy-question-into-a-desk-job state that the series carries a ChIP-Rx spike-in. That is true of one H2AK119ub panel in the paper and of no identifiable deposited sample, and it is not true of the FLAG, KDM2B or BCOR arms.
absence classmeasured-not-reported
absence class noteThis entry carries ONE gap and the token describes that one: the per-sample spike-in scale factors. They were computed by the authors for the Extended Data Fig. 4d H2AK119ub panel - the normalised and unnormalised profiles are both shown, so the factors exist - and they were never written into the deposit or the text. Closing it is an email to the corresponding author, not an experiment. It is NOT a statement about the FLAG or KDM2B or BCOR arms, for which there is no evidence a spike-in was ever run at all.
absence class assigned2026-09-23 (Q117)
supplementary file types
bam2.000bam: 2NONE4.000NONE: 4tdf152.0tdf: 152
inputs
[
  "GEO GSE260742 per-sample SOFT records (158)",
  "PMC12904788 fullTextXML",
  "igvtools 2.3.98"
]
supplementary file types — the numbers behind the chart
{
  "tdf": 152,
  "bam": 2,
  "NONE": 4
}
strings searched
[
  "spike",
  "spike-in",
  "Spike",
  "drosoph",
  "Drosophila",
  "dm6",
  "dm3",
  "S2 cell",
  "scale factor",
  "normaliz",
  "normalis",
  "Rx"
]
How this could bite us back
  • A pharmacodynamic endpoint built on ChIP signal under a menin inhibitor inherits this problem directly. If a trial correlative assay reports 'fusion occupancy fell 5-fold at MEIS1' without a spike-in or a cell-number-referenced scale, the number is a property of the library composition, and a drug that reduces total chromatin-bound protein will make every surviving site look relatively enriched.
  • The failure is asymmetric in a way that flatters the drug. Depth normalisation makes losses look smaller and gains look larger, so an unnormalised analysis of an evicting drug systematically under-reports eviction and over-reports redistribution - the two readings with opposite clinical implications.
Still open
  1. Were series-level supplementary files deposited under GSE260742 (as opposed to per-sample), and do any of them carry the Extended Data Fig. 4d scale factors? This beat enumerated per-sample files only and the series-level listing is an unclosed cheap check.
  2. Do the SRA submissions for the H2AK119ub ChIP-Rx samples contain Drosophila reads? If they do, the scale factors are re-derivable by anyone willing to align to a dm6 index, which would convert this from measured-not-reported to a two-hour job.
  3. How many other occupancy series this project relies on deposit only .tdf? The format is readable, but a corpus-wide count would tell us how much of the re-analysable archive is currently being skipped for the wrong reason.
Every source behind this entry (3)
  1. E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    Across all 158 GSE260742 sample records, no record mentions a spike-in, a scale factor or any normalisation, and the deposited processed files are 152 .tdf, 2 .bam and 4 absent.

    What this evidence cannot show

    Fetched 2026-09-23; 419,824 characters; 158 `^SAMPLE` lines counted directly. The negative is bounded by the strings searched - spike, spike-in, Spike, drosoph, Drosophila, dm6, dm3, S2 cell, scale factor, normaliz, normalis, Rx - and by the fields GEO carries. A submitter could in principle have scale factors in a series-level supplementary file; the series-level supplementary files were not enumerated in this beat, which is a named and uncleared gap.

    Evidence that argues against this (1)
    • A sample record is a submitter-written description, not an audit of the experiment. The absence of the word 'spike-in' in a record does not prove no spike-in chromatin was added to that ChIP; it proves the deposit gives a re-analyst nothing to use. The two statements have different consequences, and only the second one is claimed here. NCBI Gene Expression Omnibus 2026
  2. E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.paper

    In the depositing paper, spike-in normalisation (ChIP-Rx, Drosophila S2 chromatin) is described for one H2AK119ub panel only; the ChIP-seq Methods state that TDFs were made with igvtools count for browser snapshots and that quantitative figures used RPGC-normalised bigWigs from bamCoverage and 5 kb-bin counts normalised to reads per million.

    DOT1L provides transcriptional memory through PRC1.1 antagonism. · Neville D, Ferguson DT, Heikamp EB, et al. · Nature Cell Biology 2026
    What this evidence cannot show

    Read from the retrieved fullTextXML (PMC12904788), tags stripped before entities were unescaped, 142,554 characters, on 2026-09-23. Title, journal, year, DOI and PMCID were taken from a live PubMed esummary fetched the same session, not from a sibling graph entry. Extended Data Fig. 4d itself was not viewed as an image; the quotation is from its legend text.

    Evidence that argues against this (1)
    • RPGC normalisation is not nothing. It scales each library to 1x genome coverage, which is a defensible control for depth and is what the published figures rest on. The objection here is narrower: RPGC assumes total genomic occupancy is unchanged by the drug, which is exactly the assumption a menin inhibitor that strips a chromatin factor violates - and it is also the assumption the ChIP-Rx panel was run to test for H2AK119ub. Nature Cell Biology 2026
  3. E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database

    A .tdf deposit is readable without the raw reads: IGVTools' own TDFReader exposes per-chromosome datasets whose tiles give start, end and value, and a 95 MB FLAG .tdf re-bins to 2 kb resolution genome-wide in about seven seconds.

    What this evidence cannot show

    Downloaded and run 2026-09-23. `TDFDataset.getTiles(start, end)` is public and takes GENOMIC positions, so tiles can be streamed one at a time; `nTiles` is package-private and was read by reflection. The undocumented `tdftobedgraph` command also exists in this jar but dumps the whole genome at the count window size, which is impractical on a disk-constrained box. Values are NaN for uncovered windows and must be skipped, not treated as zero.

    Evidence that argues against this (1)
    • A TDF is a summarisation, not the alignment. igvtools count writes mean coverage per window (25 bp by default) and the deposit does not state the window used, so the finest resolution recoverable is whatever the submitter chose. Any analysis needing read-level information - duplicates, fragment length, strand, MAPQ - has to go back to SRA. This route is therefore a screen, not a replacement for re-alignment. Broad Institute 2017
Connected to