The GSE260742 H2AK119ub pair that shares a processing state - rep2 against rep3, both bare `.tdf` - is not an unconfounded replicate pair: rep3 was submitted 2024-10-01 and rep2 2024-03-03, through a different file-naming pipeline. No pairing in this deposit isolates replicate variance alone.
also called the second confound · Mar-2024 against Oct-2024 · no clean replicate pair exists here
A dataset's repeated samples looked like a fair like-for-like comparison because their filenames matched. Their submission dates do not: they were deposited seven months apart through different pipelines, so comparing them still mixes two things together, just different ones.
The same thing, for a scientist
**Read from the live GEO record, field `!Sample_submission_date`:** | accession block | submission date | supplementary-file shape | `.filt.bam` marker | |---|---|---|---| | GSM81233xx (rep1, rep2) | **Mar 03 2024** | `GSM..._ChIP_K119UB_F3_....tdf` | rep1 yes, rep2 no | | GSM85498xx (rep3) | **Oct 01 2024** | `GSM..._trimmed_7-K119-DMSO_S7_.tdf` | no | Both blocks declare the identical `!Sample_data_processing` text (cutadapt, Bowtie2, mm10, samtools, igvtools) and the identical platform GPL24247 and instrument NovaSeq 6000, so **the deposit's own processing description cannot distinguish them** - only the submission date and the filename pipeline can. **The consequence for the beat's design.** The three available pairings each carry a different nuisance, and none carries none: | pairing | marker | batch | |---|---|---| | rep1 vs rep2 | **differs** | same | | rep2 vs rep3 | same | **differs** | | rep1 vs rep3 | **differs** | **differs** | A pair that differs in neither would need two same-batch bare-`.tdf` H2AK119ub tracks of one condition, and GSE260742 does not contain one. **It also shows up in the data.** The Oct-2024 tracks carry 964k-1,074k non-empty 2 kb bins against the Mar-2024 tracks' 1,229k - a systematically shallower genome coverage that no amount of share normalisation removes, and the reason the doubly-differing pairing fails the universe gate outright.
Why the dispatch brief could not have known
The brief's table of six accessions is correct as printed - every accession, title and .tdf suffix matches the live record. Its premise that rep2 and rep3 'share a processing state' is true of the .filt.bam marker, which is the only processing signal visible in a filename. The submission date is a different field and is not in the sample list this project caches.
The general form is worth keeping: a filename records one processing decision; the record around it records several more. Checking the suffix and stopping is how a pair gets called clean.
A brief premise that IS false, checked rather than assumed
Separately, the brief states that GSM8123369/71/70 - the MLLAF9-arm H3K27me3 rep1 tracks - are 'already binned as q125_bin_K27_*'. They are not. analyses/q125-the-h2ak119ub-arm-of-the-pcgf1-knockout/run.py lines 299-300 map those tags to GSM8123423-GSM8123428, which are the NTvKO arm (ChIP_K27_{NT,C1}_{DMSO,SGC,VTP}.tdf) - a different experiment entirely. No MLLAF9-Control-arm H3K27me3 or H3K79me2 track was on local disk and all twelve were downloaded. The brief itself instructed that this be checked rather than assumed, and the check paid.
THE RENORMALISATION BOUND, AND IT APPLIES TO EVERY NUMBER IN THIS ENTRY. Within-sample shares sum to 1 and GSE260742 has NO USABLE SPIKE-IN (Q117 verified zero hits for the entire spike-in vocabulary across all 419,824 characters of its 158 sample records, and no scale factor is deposited), so a purely local change leaks into every other stratum by arithmetic. A FLOOR COMPUTED THIS WAY CANNOT DISTINGUISH 'the bulk moved' from 'the peaks moved and the shares renormalised'. A TIGHTER NUMBER IS NOT THEREBY A CLEANER ONE.
| deposit | GSE260742 |
|---|---|
| unconfounded pair exists | false |
batch mar 2024
{
"accession_prefix": "GSM81233xx",
"submission_date": "2024-03-03",
"filename_shape": "GSM..._ChIP_K119UB_F3_....tdf",
"nonempty_2kb_bins_range": [
1229065,
1230238
]
}batch oct 2024
{
"accession_prefix": "GSM85498xx",
"submission_date": "2024-10-01",
"filename_shape": "GSM..._trimmed_N-K119-DRUG_SN_.tdf",
"nonempty_2kb_bins_range": [
964358,
1074450
]
}pairings and their nuisances
{
"rep1_vs_rep2": "marker differs, batch same",
"rep2_vs_rep3": "marker same, batch differs",
"rep1_vs_rep3": "both differ"
}- Do the Oct-2024 H2AK119ub tracks come from new chromatin or from re-sequenced libraries? Only the depositors can say, and the answer decides whether rep3 is a replicate at all.
- Does any other deposit this project uses mix submission batches inside what it treats as one replicate group? Nothing has checked.
- E1strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.dataset
In GSE260742, samples GSM8549830/8549831/8549832 (H2AK119ub 'rep3', MLLAF9 Control arm) carry `!Sample_submission_date = Oct 01 2024` and filenames of the form `GSM..._trimmed_7-K119-DMSO_S7_.tdf`, while GSM8123377/8123378/8123379 ('rep2') carry `Mar 03 2024` and `GSM..._ChIP_K119UB_F3_NT_DMSO.tdf`. Both declare identical `!Sample_data_processing`, platform GPL24247 and instrument NovaSeq 6000. The Oct-2024 tracks carry 964,358-1,074,450 non-empty 2 kb bins against the Mar-2024 tracks' 1,229,065-1,230,238.
What this evidence cannot show
A submission date is not a library-prep date and not a sequencing date. It bounds when the files were deposited, and the inference that the two blocks are different experimental batches is an inference from that plus the different naming pipeline plus the systematically different genome coverage - not a statement the deposit makes. THE RENORMALISATION BOUND, AND IT APPLIES TO EVERY NUMBER IN THIS ENTRY. Within-sample shares sum to 1 and GSE260742 has NO USABLE SPIKE-IN (Q117 verified zero hits for the entire spike-in vocabulary across all 419,824 characters of its 158 sample records, and no scale factor is deposited), so a purely local change leaks into every other stratum by arithmetic. A FLOOR COMPUTED THIS WAY CANNOT DISTINGUISH 'the bulk moved' from 'the peaks moved and the shares renormalised'. A TIGHTER NUMBER IS NOT THEREBY A CLEANER ONE.
Evidence that argues against this (2)
the confound structure that makes the Task-1 answer a trade rather than a removal
- related to →KMT2A::MLLT3 (MLL-AF9), t(9;11)(p21.3;q23.3)
the deposit's fusion
a second way this deposit's file metadata misleads about which samples are comparable