GSE210480 carries FOUR CTCF bigWigs under EIGHT sample accessions, byte-identical, under different filenames - so counting GEO sample records doubled the replicate count and would have halved every standard error
also called four files, eight accessions · the duplicated CTCF arm · why a sample count is not a replicate count
A public dataset lists eight samples for one experiment, but four of them are exactly the same computer files as the other four, just renamed. Anyone who counted the samples would think they had twice as much evidence as they do.
The same thing, for a scientist
GSE210480 lists eight CTCF ChIP-seq samples across two sub-series: GSM6431019/21/23/25 in the main set, named `siCT-CTCF-High_rep1` and so on, and GSM7594696/98/7594700/02 in the `exp1` set, named `20220606siCT1-CTCF-High_S5` and so on. **They are four files, not eight.** Each main-set accession and its exp1 partner have identical HTTP `Content-Length` to the byte (85,904,588 / 92,801,623 / 81,484,213 / 91,808,652) and return **exactly equal per-base arrays** over a 5 kb test window [E1]. Every derived quantity is also identical to every printed decimal - chr11 mean, the fold at each of twelve intervals, the 200 bp argmax summit and the peak half-maximum width [E1]. **The negative control was run and passed:** the exp1 *histone* samples are genuinely distinct files from the main-set histone samples, so this is a duplication confined to the CTCF arm and not a bug in the URL builder [E1]. **The cost of missing it.** This beat's own pre-registration wrote `SAMPLES["CTCF"]` with eight entries and the first run reported eight tracks, four replicates per arm. Treating them as eight independent replicates would have reported a standard error 1/sqrt(2) too small on the CTCF result that is this beat's strongest number, and the summit would have looked like a four-way agreement in the control arm when it is a two-way one. **The general rule: a GEO sample count is a submission count. A replicate count needs the files compared.**
How to detect it, in increasing cost
- HTTP
Content-Length, one HEAD request per file. Free, no download, and two bigWigs of identical byte length are either the same file or a coincidence worth investigating. This is the check to run by default on any multi-sub-series GEO deposit. - Exact array equality over a test window, a few hundred KB by range request. Confirms it.
- Full checksum. Unnecessary once 1 and 2 agree.
And run the negative control. Identical numbers from two accessions can equally mean a bug in your own URL construction - a gsm[:-3] prefix rule that silently collapses two accessions onto one path, say. The way to tell a real duplication from your own aliasing bug is to compare a pair you expect to be different: here the exp1 and main-set H3K9me1 control tracks, which came back distinct. Without that control this finding would be indistinguishable from a self-inflicted error, and this project has published a confident wrong number from exactly that class of mistake before.
Why a series does this, and what it means for the science
The innocent and most likely reading: the exp1 sub-series was added to GSE210480 later (its accessions are GSM7594xxx against GSM6430-31xxx, a year apart) to deposit an earlier independent replicate experiment for the histone marks, and the CTCF files from the original submission were re-uploaded alongside it rather than cross-referenced. GEO permits that and it is not misconduct.
But it has a scientific consequence the deposit does not flag. The series appears to contain eight CTCF samples across two experiments, which reads as independent replication of the CTCF result in a second experiment. It does not. There is exactly one CTCF experiment in this series: two control and two siKDM3B libraries. The paper's central CTCF claim - that KDM3B depletion lowers CTCF occupancy at KMT2A exon 11 - rests, in the deposited data, on n = 2 versus n = 2 from one experiment. That is also true of the paper as published (it reports CTCF ChIP-qPCR as well), but a re-analyst counting accessions would overstate it.
One more consequence, for this beat specifically. There is no siG9A CTCF arm and no double-knockdown CTCF arm anywhere in the series. So the balance signature - opposite effects of the two single knockdowns - can be tested for the histone marks but cannot be tested for CTCF occupancy at all from this deposit. The step of the published chain that carries the locus specificity is the step whose balance shape is unmeasurable here.
| trap class | identifier and file-format trap - a submission count mistaken for a replicate count |
|---|---|
| series | GSE210480 |
| accessions listed | 8 |
| unique files | 4 |
| negative control | exp1 H3K9me1 control track versus main-set H3K9me1 control track: DISTINCT, so the finding is not an artefact of the URL-building rule |
| detection recipe | one HTTP HEAD per file for Content-Length, then exact per-base array equality over a few kilobases by range request; and ALWAYS compare a pair you expect to differ, or a self-inflicted aliasing bug looks identical to a real duplication |
| consequence if missed | eight tracks read as four replicates per arm instead of two, understating every standard error by a factor of sqrt(2), and a two-way summit agreement in the control arm reads as a four-way one |
| second consequence | there is NO siG9A CTCF arm and NO double-knockdown CTCF arm in this series, so the KDM3B-versus-G9a balance signature cannot be tested for CTCF occupancy at all from this deposit - at the very step that carries the locus specificity |
| premise it corrected | this beat's dispatch brief said 'four CTCF bigWigs in this series', which was RIGHT; the first pass of this beat's own pre-registration counted eight sample records and was wrong. The brief's number was correct and the agent's was not. |
| localization | not applicable - this entry concerns a data deposit, not a cellular location, and no localisation is claimed |
| subnuclear localization | not applicable - a file-identity finding has no subnuclear coordinate |
| cell type | the affected files are CTCF ChIP-seq from hTERT-immortalised human retinal pigment epithelial (RPE) cells, the only cell type in GSE210480 |
| cell state | asynchronous proliferating culture 72 h after control or KDM3B siRNA transfection |
| epigenetic readout | CTCF ChIP-over-input coverage tracks (200 bp bins) - the duplicated arm; the H3K9me1/2/3 histone arms of the same series are not duplicated |
| shown for fusion | Not applicable to any fusion. The duplicated files are from unrearranged RPE cells and the finding is about data curation, not about fusion biology. |
duplicate pairs
[
[
"GSM6431023",
"GSM7594700",
85904588
],
[
"GSM6431025",
"GSM7594702",
92801623
],
[
"GSM6431019",
"GSM7594696",
81484213
],
[
"GSM6431021",
"GSM7594698",
91808652
]
]- This entry's value is methodological and it could be over-applied. Two ChIP tracks from the same experiment deposited once are still a legitimate n = 2; the error is only in counting them twice. A reader who takes 'duplicated deposits' as a reason to distrust the series would be over-correcting - the CTCF result read from these files is internally consistent and locus-specific, and the duplication changes its precision, not its direction.
- The absence of a siG9A CTCF arm is the more damaging half of this finding and it will be overshadowed by the neater duplication story. The chain's terminal step has never been measured under the perturbation that is supposed to reverse it.
- How many other GEO series in this corpus have sub-series that re-deposit the same files? The check is one HTTP HEAD per supplementary file and a byte-length comparison within a series, and it has never been run here. Any series with two widely separated accession blocks is a candidate.
- Does any published entry in this graph quote a replicate count taken from a GEO sample listing rather than from the files? A sample count is the natural thing to quote because it is what the listing shows, and it is what this beat's own first pass quoted.
- Is there a CTCF ChIP in any G9a-depleted human cell, anywhere? The absence of a siG9A CTCF arm in this series means the most direct test of the published chain's terminal step under the opposing perturbation does not exist in this deposit, and this beat did not search other archives for it.
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset
The four exp1 CTCF samples of GSE210480 are byte-identical duplicates of the four main-set CTCF samples: GSM6431023/GSM7594700, GSM6431025/GSM7594702, GSM6431019/GSM7594696 and GSM6431021/GSM7594698 have equal HTTP Content-Length (85,904,588 / 92,801,623 / 81,484,213 / 91,808,652 bytes respectively) and return exactly equal per-base arrays over hg19 chr11:118,355,000-118,360,000, while a negative control comparing an exp1 H3K9me1 track with a main-set H3K9me1 track returns distinct arrays - so the series contains four unique CTCF bigWigs under eight accessions, and contains no siG9A or double-knockdown CTCF arm at all.
GEO GSE210480 CTCF and H3K9me1 supplementary bigWigs compared by HTTP HEAD Content-Length and by exact per-base array equality over a 5 kb window, 2026-09-22; code and output at analyses/q108-gse210480-h3k9me3-kmt2a-bcr/followups.py and results_followups.json · NCBI Gene Expression Omnibus 2026What this evidence cannot show
Equality was tested over one 5 kb window plus total byte length, not by checksumming 350 MB of file. Two distinct files could in principle share a byte length and agree over 5 kb, though the probability is negligible and the derived quantities also agreed to every printed decimal across twelve intervals and a chr11-wide mean. The interpretation of WHY the duplication exists - a later sub-series re-uploading the original CTCF files - is inferred from the accession ranges and filenames and was not confirmed with the submitters. No claim of misconduct is made or intended.
Evidence that argues against this (1)
- The duplication could be deliberate and correct rather than an oversight: if the exp1 sub-series was designed as a self-contained package for a specific figure, including the CTCF tracks it needs is reasonable curation, and GEO has no mechanism for a sample record to point at another sample's file. On that reading nothing is wrong with the deposit and the entire burden falls on the re-analyst to compare files before counting replicates - which is what this entry concludes anyway. NCBI Gene Expression Omnibus 2026
sweeps for the replicate-provenance class; 3 candidates, all stating structures correct for their arms, and no entry asserts a replicate count for the CTCF arm where the duplication actually is
corrects this beat's own first-pass CTCF replicate count from eight to four
the summit rests on two unique control tracks, not four
the CTCF result is n=2 versus n=2 from one experiment, and no siG9A CTCF arm exists to test the balance shape
the four distinct Content-Lengths re-verified by HTTP HEAD, each appearing twice across eight accessions
the neighbouring hazard: there two accessions were one file; here two distinct files agree at rho 0.21-0.33