All four input samples explicitly titled to the MLLAF9 ChIP arm of GSE260742 carry supplementary_file = NONE, so no input-referenced peak call is possible from the processed deposit - and the only deposited batch-1 inputs are two BAMs filed under a different arm's title with the same cell line and the same F3 filename prefix
also called Q117 the missing inputs · GSE260742 MLLAF9 input tracks are absent
Every control sample that belongs to the main experiment has its description in the database but no data file attached, so nobody can do the standard background subtraction using the public processed files. The raw reads are there, so it is a compute job rather than a lost experiment.
The same thing, for a scientist
GSE260742 lists 158 samples. Exactly four carry `!Sample_supplementary_file_1 = NONE`, and all four are the inputs for the MLLAF9 ChIP arm [E1]: | accession | title | SRA | processed file | |---|---|---|---| | GSM8123362 | MLLAF9 Control - DMSO input | SRX23818725 | **NONE** | | GSM8123363 | MLLAF9 Control - DMSO input2 | SRX23818726 | **NONE** | | GSM8123375 | MLLAF9 Control - DMSO input for ac | SRX23818758 | **NONE** | | GSM8123376 | MLLAF9 Control - DMSO input for RING1B | SRX23818759 | **NONE** | **The consequence is concrete.** Peak calling with a matched input, which is the standard way to ask whether a treated-only site is a peak at all, cannot be done from the processed deposit for the FLAG, KDM2B, MLL1 or histone-mark samples in that arm. This beat's gain analysis is therefore a **signal-magnitude** analysis and not a peak-based one, and its mappability filter had to borrow an input from a different processing batch (GSM8549823, `trimmed_13-input-f3`), which is the batch with a twenty-fold higher blacklist artefact load. **The cycle-65 entry that identified this dataset states that "the series includes the matched inputs" [E3]. It does, as records. It does not, as files.** That distinction is the difference between a desk job and a desk job that needs a re-alignment first. **And there is an identifier trap beside it.** The only two BAM files in the whole series are GSM8123413 and GSM8123414, titled *NTvKO Control - DMSO input1 / input2*, whose filenames are `GSM8123413_ChIP_INPUT1_F3_..filt.bam` and `GSM8123414_ChIP_INPUT2_F3_..filt.bam`. **`F3` is the clone label used throughout the MLLAF9 arm's own filenames** - `ChIP_FLAG_F3_DMSO`, `ChIP_KDM2B_F3_NT_DMSO` - and both records carry `cell line: MLLAF9` [E2]. So the two deposited BAMs are very likely usable as a batch-1 input for the MLLAF9 ChIPs despite being titled under the knockout arm, and a re-analyst reading titles alone will not find them.
What closes this, and what it costs
The reads exist: four SRX accessions, listed above, plus two deposited BAMs. Closing the gap is align four FASTQ sets to mm10 and make coverage tracks, or read the two BAMs directly, which needs only samtools and no aligner. Neither is wet work. The cost that stopped this beat was disk and time, not availability: the box had 21 GB free on C: and the beat was already holding thirteen 55-200 MB tracks one at a time.
Recorded as measured-not-analysed on the definition this project uses - data deposited and public, this processing never run on it.
| script | analyses/q117-gained-fusion-occupancy/run117.py (inventory step) |
|---|---|
| status | run |
| result summary | Four MLLAF9-arm inputs have no deposited processed file; their reads are in SRA. No input-referenced peak call is possible from the processed deposit for that arm. |
| substitute used in this beat | GSM8549823 (MLLAF9 Control - input, trimmed_13-input-f3), from the second processing batch, used only to define mappability and to build the class-matched null - never subtracted |
| what closes it | align the four SRX runs to mm10, or read the two deposited BAMs with samtools; no wet work, one node-hour, blocked in this beat by disk rather than by availability |
| absence class | measured-not-analysed |
| absence class note | ONE gap and the token describes it: processed input coverage tracks for the MLLAF9 ChIP arm. The chromatin was sequenced and the reads are public (four SRX accessions), and the coverage track was never produced or deposited. It is NOT a statement about the identifier trap in the two NTvKO-titled BAMs, which is a metadata problem and not an absence, and it is NOT a statement about the missing spike-in scale factors, which are measured-not-reported and are recorded in a separate entry. |
| absence class assigned | 2026-09-23 (Q117) |
missing processed inputs
[
{
"gsm": "GSM8123362",
"title": "MLLAF9 Control - DMSO input",
"sra": "SRX23818725"
},
{
"gsm": "GSM8123363",
"title": "MLLAF9 Control - DMSO input2",
"sra": "SRX23818726"
},
{
"gsm": "GSM8123375",
"title": "MLLAF9 Control - DMSO input for ac",
"sra": "SRX23818758"
},
{
"gsm": "GSM8123376",
"title": "MLLAF9 Control - DMSO input for RING1B",
"sra": "SRX23818759"
}
]the two deposited bams
[
{
"gsm": "GSM8123413",
"title": "NTvKO Control - DMSO input1",
"file": "GSM8123413_ChIP_INPUT1_F3_..filt.bam",
"cell_line_field": "MLLAF9"
},
{
"gsm": "GSM8123414",
"title": "NTvKO Control - DMSO input2",
"file": "GSM8123414_ChIP_INPUT2_F3_..filt.bam",
"cell_line_field": "MLLAF9"
}
]queries
[
{
"q": "tabulate !Sample_supplementary_file_1 across all 158 GSE260742 sample records",
"result": "152 tdf, 2 bam, 4 NONE",
"date": "2026-09-23"
}
]- A re-analyst who does not notice the missing inputs will substitute an input from elsewhere in the series, as this beat did, and will inherit whatever differs between the two preparations. Here that included a twenty-fold difference in blacklist artefact load, which then propagated into the bin universe and, through it, into a pre-registered verdict.
- Do the four SRX runs resolve and download? The GEO record says they exist and this beat did not check, and this project has been burned by archive linkages that return confident wrong answers in both directions.
- Are GSM8123413 and GSM8123414 the same physical input material as the MLLAF9-arm inputs, or a separate preparation from the NT-sgRNA derivative? The submitters would know in one email and the filenames suggest the former.
- With a real matched input, does the 52-bin gained set survive a proper peak call? That is the single test that would convert this beat's magnitude-based verdict into a peak-based one.
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset
Four of the 158 GSE260742 sample records carry supplementary_file = NONE, and all four are MLLAF9-arm inputs (GSM8123362, GSM8123363, GSM8123375, GSM8123376), each with a live SRA experiment accession.
NCBI GEO GSE260742 - per-sample SOFT records, all 158 samples (targ=gsm, form=text, view=brief) · NCBI Gene Expression Omnibus 2026What this evidence cannot show
Read 2026-09-23 from the SOFT text view. Only `supplementary_file_1` was tabulated; a sample could in principle carry a second supplementary file, though none of the 158 records shows a `supplementary_file_2`. The SRA accessions were read out of the `!Sample_relation` lines and were NOT independently resolved against SRA in this beat, so 'the reads exist' rests on the GEO record rather than on an SRA fetch.
Evidence that argues against this (1)
- An SRA relation line in a GEO record is not proof that the run is public and downloadable. This project has documented several routes by which an archive linkage returns a clean negative or a clean positive that is wrong, and the SRX ids here were not resolved. Anyone planning the re-alignment should resolve them first rather than assuming. NCBI Sequence Read Archive 2026
- E2strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.dataset
The only two BAM files in GSE260742 are titled to the NTvKO arm but carry cell line: MLLAF9 and the F3 clone label used throughout the MLLAF9 arm's own filenames.
NCBI GEO GSM8123413 and GSM8123414 - NTvKO Control DMSO input1/input2, files GSM8123413_ChIP_INPUT1_F3_..filt.bam and GSM8123414_ChIP_INPUT2_F3_..filt.bam · NCBI Gene Expression Omnibus 2026What this evidence cannot show
The inference that these BAMs are usable as an input for the MLLAF9 ChIPs rests on the shared cell line field and the shared F3 filename prefix, not on a statement by the submitters. NTvKO Control means MLLAF9 cells carrying a non-targeting sgRNA, which is the same parental line with an extra lentiviral integration and a selection history; whether that is close enough to serve as an input for the untransduced arm is a judgement. The BAMs were not downloaded.
Evidence that argues against this (1)
- An sgRNA-transduced, selected derivative is not the parental line. If the NT control underwent a bottleneck, its copy-number profile and therefore its input coverage can differ from the parental line's in exactly the way an input is supposed to control for. Using it as a substitute input would introduce a systematic bias that looks like biology at amplified or deleted loci. NCBI Gene Expression Omnibus 2026
- E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset
This graph's cycle-65 entry on the same dataset states that the series includes the matched inputs, which is true of the sample records and false of the deposited files.
Oncofusion knowledge graph entry ana-q115-gse260742-turns-the-gained-fusion-occupancy-question-into-a-desk-job · Iqbal Lab oncofusion knowledge graph 2026What this evidence cannot show
That entry's own caveat already says 'which of the 158 samples are FLAG pulldowns under VTP50469 with matched input must be read per-GSM and was NOT done here', so it flagged this as unchecked rather than asserting it as verified. This entry closes that named gap; it is not a correction of a claim the earlier entry made carelessly.
Evidence that argues against this (1)
- Because the earlier entry named the gap in its own caveats, a reader who reached the caveat was not misled. The failure mode this illustrates is the project's own documented one - a caveat that names an uncovered case is a task, and the task sat for one cycle. NCBI Gene Expression Omnibus 2026
a second thing the deposit does not contain, found the same way
the absence of a processed matched input is why the gain call is magnitude-based and not peak-based
a different arm of the same series does deposit readable matched inputs