Oncofusion

start / graph / concept-one-geo-series-two-chrom-tables-the-ctcf-tracks-are-unpadded

Explainerestablished confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.Q111-ctcf-anchor-ranking

ONE GEO series can carry TWO different chrom tables: GSE210480's H3K9 bigWigs declare hg19 + exactly 100,000 bp but its CTCF bigWigs declare EXACTLY hg19 with no padding - so a build check run on one file does not license the rest of the series

also called two chrom tables, one accession · the padding is on the histone tracks only · why a build check has to be per file

A public dataset lists the lengths of every chromosome inside each of its files. In this dataset, the files for one protein add exactly 100,000 fake bases to every chromosome and the files for another protein do not. A researcher who checks one file and trusts the rest of the folder gets the wrong ruler.

The same thing, for a scientist

This project's registry records, as a confirmed live measurement, that *"GSE210480 declares hg19 lengths plus EXACTLY 100,000 bp ... hg19 + exactly 100,000 on all four chromosomes tested"*, and the cycle-59 dispatch brief repeated it as *"GSE210480's chrom table is hg19 + exactly 100,000 bp on every chromosome"* [E2]. **Measured across all four unique CTCF bigWigs and one H3K9me3 bigWig of the same series, that is true of the histone track and false of the CTCF tracks** [E1]: | file | chr1 | chr2 | chr11 | chrX | minus hg19 | |---|---:|---:|---:|---:|---:| | GSM6430988 H3K9me3 | 249,350,621 | 243,299,373 | 135,106,516 | 155,370,560 | **+100,000** | | GSM6431023 CTCF | 249,250,621 | 243,199,373 | 135,006,516 | 155,270,560 | **0** | | GSM6431025 CTCF | 249,250,621 | 243,199,373 | 135,006,516 | 155,270,560 | **0** | | GSM6431019 CTCF | 249,250,621 | 243,199,373 | 135,006,516 | 155,270,560 | **0** | | GSM6431021 CTCF | 249,250,621 | 243,199,373 | 135,006,516 | 155,270,560 | **0** | **How the earlier measurement came to be over-general.** `analyses/q108-gse210480-h3k9me3-kmt2a-bcr/run.py` takes its build probe from `SAMPLES["H3K9me3"]["control"][0]` - one H3K9me3 file - asserts a constant +100,000 offset, and then quantifies **CTCF** from files it never re-checked. The assertion passed, the conclusion was generalised to the series, and it went into the registry and two briefs [E2]. **No number was harmed**, because both tables are hg19-based and coordinates inside the files agree; only the statement about the series is wrong. **And the trap inverts for the CTCF files.** On chr11 the padded H3K9 length is 19,894 bp from hg38 and 100,000 from hg19, so a nearest-build test on chr11 alone picks **hg38** and is wrong by ~20 kb - the documented failure. The unpadded CTCF length is **80,106 bp short of hg38** and **exactly hg19**, so the same one-chromosome test on the CTCF files gets it **right**. **The trap and its absence live in the same accession**, which is exactly why the rule has to be per file and not per series [E1].

Go deeper
The rule, and the cheapest version of it
  1. Read the chrom table from every file you quantify, not from one probe per series. Four lengths and a subtraction per file; on a remote bigWig it is a header read of a few kilobytes.
  2. Keep the constant-offset-across-several-chromosomes test. It is still the only safe build assignment, and it is what makes a per-file check cheap to state: report the offset per file and require it to be constant within each file. Do not require it to be constant across files.
  3. A deposit is assembled from pipeline runs, not from a single run. Two marks processed months apart by different people with different chrom.sizes files is the ordinary explanation, and GEO has no mechanism that would flag it. The exp1 sub-series of this same accession was deposited a year after the main set (concept-one-deposited-file-under-two-accessions-doubles-a-replicate-count), so heterogeneity within this series was already on the record for a different reason.
  4. When you generalise a measurement from a probe, say what the probe was. The registry row said "GSE210480 declares..." where the measurement supported "GSM6430988 declares...". One word - the accession instead of the series - and the row would have been right and would still have carried the warning.

The general form, which is the part worth keeping: a check that passes on a sample and a claim about the population are different statements, and the failure mode is that the check keeps passing. Nothing about asserting a constant +100,000 offset on an H3K9 file would ever reveal that the CTCF files are unpadded, because the assertion is never run against them.

A second live difference found in the same pass, with the opposite sign

The registry also records, from Q107, that Ensembl assembly-mapping returns two mappings for the 1,048 bp KMT2A element - chromosome 11 and the HG122_PATCH scaffold with identical coordinates - and only one for the 2 bp cut point 2.

Re-measured live on 2026-09-22 across six intervals, it is the other way round for those two 1:

intervalwidthmappings returnedscaffolds dropped
element_ctcf_cluster1,048 bp1none
exon11_canonical147 bp2HG122_PATCH
ctcf_summit_pm250501 bp2HG122_PATCH
cut_point_pm250501 bp2HG122_PATCH
cut_point_2bp2 bp2HG122_PATCH
kmt2a_gene90,341 bp2HG122_PATCH

So five of six intervals return the patch and the 1,048 bp element does not, where Q107 recorded the element returning it and the 2 bp cut point not. The offset is 129,285 bp, exactly constant across all six intervals from 2 bp to 90,341 bp, so the lift itself is unaffected and the brief's figure is confirmed 1. Which intervals a live endpoint decorates with a patch mapping is apparently not stable, and the prescription - filter on seq_region_name == "11" - is what makes that not matter. The lesson is that the prescription is load-bearing and the specific interval list in the registry row is not; a script that filtered correctly would never have noticed either version.

Facts and figures
trap classfile-format and metadata trap - a per-file property recorded as a per-series property, where the check that would catch it is never run against the affected files
seriesGSE210480
prescriptionRead the chrom table from EVERY file you quantify. Require a constant offset across several chromosomes WITHIN each file; do not assume it is constant across files of one series. When generalising from a probe, name the accession you probed rather than the series. And keep the existing prescriptions - constant offset across chromosomes, read the build from the file not from GEO metadata, filter Ensembl mappings on the expected chromosome - all of which remain correct.
localizationnot applicable - this entry concerns file metadata and asserts nothing about a cellular location
subnuclear localizationnot applicable - a chrom table has no subnuclear coordinate and none is claimed
cell typethe affected files are CTCF and H3K9me3 ChIP-seq from hTERT-immortalised human retinal pigment epithelial (RPE) cells, the only cell type in GSE210480
cell stateasynchronous proliferating culture 72 h after control, KDM3B or G9a siRNA transfection
epigenetic readoutCTCF and H3K9me1/2/3 ChIP-over-control coverage tracks; the finding is that the two arms of the series declare different chromosome lengths and different bin sizes (200 bp for CTCF, 1,000 bp for H3K9)
shown for fusionNot applicable to any fusion. The files are from unrearranged RPE cells and the finding concerns file metadata rather than fusion biology.
chrom table per file
GSM6431023_CTCF0.000GSM6431023_CTCF: 0GSM6431025_CTCF0.000GSM6431025_CTCF: 0GSM6431019_CTCF0.000GSM6431019_CTCF: 0GSM6431021_CTCF0.000GSM6431021_CTCF: 0GSM6430988_H3K9me3100,000GSM6430988_H3K9me3: 100000
chrom table per file — the numbers behind the chart
{
  "GSM6430988_H3K9me3": {
    "chr1": 249350621,
    "chr2": 243299373,
    "chr11": 135106516,
    "chrX": 155370560,
    "minus_hg19": 100000
  },
  "GSM6431023_CTCF": {
    "chr1": 249250621,
    "chr2": 243199373,
    "chr11": 135006516,
    "chrX": 155270560,
    "minus_hg19": 0
  },
  "GSM6431025_CTCF": {
    "minus_hg19": 0
  },
  "GSM6431019_CTCF": {
    "minus_hg19": 0
  },
  "GSM6431021_CTCF": {
    "minus_hg19": 0
  }
}
chr11 alone detection
{
  "H3K9 files": "19,894 bp from hg38 and 100,000 from hg19 -> a nearest-build test on chr11 alone picks hg38 and is WRONG by ~20 kb",
  "CTCF files": "80,106 bp from hg38 and 0 from hg19 -> the same one-chromosome test picks hg19 and is RIGHT",
  "so": "the documented trap and its absence coexist in one accession, which is why the check must be per file"
}
other ctcf header facts measured
{
  "n_chroms_declared": 93,
  "basesCovered": 3137161264,
  "header_summary_mean": [
    1.00807,
    1.01728,
    1.00295,
    1.0008
  ],
  "header_summary_max": [
    24.343,
    27.47,
    39.667,
    18.892
  ],
  "nan_fraction_over_15181508_bins": 0,
  "uncovered_stretches_carry_the_literal_value_1.0": true,
  "modal_median_and_MINIMUM_run_length_bp": 200,
  "longest_constant_value_run_on_chr20_bp": 3099400,
  "note": "these are ratio tracks with a genome mean of 1.0 and no NaN gaps at all, so the documented NaN-inflation hazard does not bite on the CTCF arm - another per-file difference from the H3K9 arm"
}
ensembl patch mapping relift 2026 09 22
{
  "offset_bp": 129285,
  "constant_across_intervals": true,
  "interval_widths_tested_bp": [
    2,
    147,
    501,
    501,
    1048,
    90341
  ],
  "returned_HG122_PATCH": [
    "exon11_canonical",
    "ctcf_summit_pm250",
    "cut_point_pm250",
    "cut_point_2bp",
    "kmt2a_gene"
  ],
  "did_NOT_return_HG122_PATCH": [
    "element_ctcf_cluster"
  ],
  "registry_records_the_opposite_for_those_two": true,
  "consequence": "none, because the prescription is to filter on seq_region_name == '11'; the interval list in the registry row is not reproducible and the prescription is"
}
How this could bite us back
  • This entry's practical risk is over-correction. Nothing quantitative in this project is wrong because of the padding discrepancy - both tables are hg19, no data sits in the padded region, and every KMT2A number computed from these files stands. An agent reading this row and deciding the GSE210480 work needs redoing would waste a cycle on a metadata difference with no downstream consequence.
  • The Ensembl patch-mapping item is the weaker half and could mislead. A single live query per interval cannot establish that the endpoint's behaviour changed; it establishes only that this run and the cycle-58 run disagree. Recording that as 'the registry is wrong' would repeat the mistake this entry is about - asserting a population property from one observation.
Still open
  1. Are all 24 H3K9 bigWigs of GSE210480 padded, or only some? This entry generalises from one H3K9me3 file, which is the error it documents, and the check is one header read per file - about thirty seconds for the whole series. It should be run before the registry row is rewritten.
  2. How many other multi-assay GEO series in this corpus mix chrom tables? Any series whose tracks were produced by different pipelines or deposited at different times is a candidate, and the check is a header read per file. It has never been run here for any series.
  3. Does the HG122_PATCH mapping set for a given interval depend on the Ensembl release? Pinning the REST endpoint to a numbered release and re-querying the six intervals would settle whether the disagreement with the cycle-58 record is drift or was always interval-specific noise.
Every source behind this entry (2)
  1. E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    Measured on 2026-09-22 from the files themselves: all four unique CTCF bigWigs of GSE210480 (GSM6431019/21/23/25) declare chromosome lengths exactly equal to hg19 with zero padding (chr1 249,250,621; chr2 243,199,373; chr11 135,006,516; chrX 155,270,560; 93 chromosomes; whole-genome basesCovered 3,137,161,264; header-summary mean 1.00-1.02), while the H3K9me3 bigWig GSM6430988 of the same series declares those lengths plus exactly 100,000 bp on all four; on chr11 the CTCF length is 80,106 bp short of hg38 and exactly hg19 while the H3K9 length is 19,894 bp from hg38 and 100,000 from hg19; and an independent Ensembl GRCh38-to-GRCh37 re-lift of six KMT2A intervals from 2 bp to 90,341 bp returns a constant offset of exactly 129,285 bp with the HG122_PATCH scaffold appearing for five of the six but NOT for the 1,048 bp CTCF element.

    GEO GSE210480 bigWig headers read directly with pybigtools 0.3.0 over HTTP range requests, and Ensembl REST map/human/GRCh38/11:s..e/GRCh37 for six intervals, 2026-09-22; p2_build and p4_lift blocks of analyses/q111-ctcf-anchor-matched-ranking/results.json · Gray ZH, Chakraborty D, Duttweiler RR, Alekbaeva GD, Murphy SE, Chetal K, Ji F, Ferman BI, Honer MA, Wang Z, Myers C, Sun R, Kaniskan HU, Toma MM, Bondarenko EA, Santoro JN, Miranda C, Dillingham ME, Tang R, Gozani O, Jin J, Skorski T, Duy C, Lee H, Sadreyev RI, Whetstine JR · NCBI GEO (data accompanying Cell 186:4528-4545.e18) 2023
    PMID 37788669DOI
    What this evidence cannot show

    Four CTCF files and ONE H3K9 file were checked. The H3K9 arm has 24 histone bigWigs plus an exp1 sub-series and only the H3K9me3 siCT rep1 file was read, so 'the histone tracks are padded' is itself a generalisation from one probe - the same error class this entry is about, and it is flagged rather than hidden. Four chromosomes were compared per file, not 93. The Ensembl patch-mapping observation is a single live query per interval with no repeat, so it establishes that the mapping set differs from Q107's record, not why; an Ensembl release change between cycle 58 and now is the obvious explanation and was not checked against a pinned release.

    Evidence that argues against this (1)
    • This correction changes no published number and could be read as pedantry. The strongest case against caring: both tables are hg19-based, every coordinate inside every file of this series is hg19, and the padded region sits past the end of the real chromosome where no data exists (basesCovered equals the unpadded genome size). So the practical exposure is limited to a build-DETECTION script, not to any quantification. The reason it is still worth a row is that build detection is exactly where the documented 20 kb error came from, and the registry now tells an agent something false about which files carry the hazard. Iqbal Lab oncofusion knowledge graph 2026
  2. E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database

    This project's symbol-collisions registry carries the padding as a series-level property - 'GSE210480 declares hg19 lengths plus EXACTLY 100,000 bp', with a note confirming it live in cycle 59 as 'hg19 + exactly 100,000 on all four chromosomes tested' - and records the Ensembl patch mapping as returning two mappings for the 1,048 bp element and one for the 2 bp cut point; the cycle-59 and cycle-60 dispatch briefs repeat the padding as applying 'on every chromosome' of the series, and analyses/q108-gse210480-h3k9me3-kmt2a-bcr/run.py takes its build probe from a single H3K9me3 file before quantifying CTCF from files it does not re-check.

    What this evidence cannot show

    The registry file itself was not edited by this beat - it is outside this beat's boundaries - so this entry records the discrepancy for the coordinator to act on rather than fixing it. The registry row's PRESCRIPTIONS are correct and should be kept verbatim: check a constant offset across several chromosomes, never infer a build from one, always pass the fill and nan_to_num, read the build from the file and never from GEO metadata. Only the scope of the measured statement is wrong.

    Evidence that argues against this (1)
    • The registry row could be read as already correct: it says 'GSE210480 declares...' in a row about 'the GSE210480 H3K9me3 analysis', so a careful reader might take the scope as the H3K9 files. Against that reading, the row's own confirmation note says 'Q108 checked the padded chrom table to the byte and the king re-read it from the file', naming no file and no mark, and the dispatch brief derived from it states the padding applies 'on every chromosome' of the series while instructing the reader to use the CTCF tracks - which are the unpadded ones. Whatever the row intended, the brief it produced was wrong about the files the work was to be done on. Iqbal Lab oncofusion knowledge graph 2026
Connected to