Oncofusion

start / graph / ana-q114-every-route-to-human-suv39h1-occupancy-data-leads-to-the-same-two-deposits

Analysisstrong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.Q114-suv39h1-at-the-locus

Three archives, one answer: SUV39H1 has no ENCODE target record under any label (three routes, all empty), ChIP-Atlas's entire hg38 SUV39H1 holding IS the four GSE139196 MCF-7 samples re-indexed, and KMT2A is not among the 26 genes ChIP-Atlas calls SUV39H1 targets

also called SUV39H1 archive census 2026-09-22 · ChIP-Atlas is not a third route

We checked every public archive that could hold a map of where this enzyme sits on human chromosomes. The big reference atlas holds nothing at all, the second archive holds only a re-labelled copy of one breast-cancer experiment, and in that experiment the KMT2A gene is not on the list of genes the enzyme is called a regulator of.

The same thing, for a scientist

**Three independent routes into ENCODE all return nothing for SUV39H1, and the registry row that says so is now verified rather than inherited** [E1]. Queried 2026-09-22: | route | result | |---|---| | `GET /targets/SUV39H1-human/` | **HTTP 404** | | `GET /targets/BARD1-human/` (positive control, identical template) | **HTTP 200** | | `GET /targets/EXO1-human/` (negative control, identical template) | **HTTP 404** | | `type=Target&searchTerm=SUV39H1` (the tagged-label route rule 97's registry row prescribes) | **total 0** | | `type=Experiment&target.label=SUV39H1` | **total 0**, `notification: "No results found"` | The positive and negative controls travel through the **identical URL template** as the queries, which is what the `a malformed URL token is indistinguishable from an absent antigen` registry row demands and what a hand-typed control would not have given. My dispatch brief explicitly flagged this as the one premise the coordinator had **not** verified for SUV39H1 - it had been checked for BARD1, RAD50, EXO1 and DNA2 only - and it holds. **ChIP-Atlas is NOT a third independent route, and my brief said it was** [E2]. `hg38/target/SUV39H1.5.tsv` returns **HTTP 200** (not 206), 938 bytes, and its header row names exactly four experiment columns: **SRX7030945, SRX7030946, SRX7030947, SRX7030948, all labelled MCF-7**. Those four are the GSE139196 SUV39H1 ChIP-seq samples GSM4133857-60. **The file is a re-index of one of the two deposits this beat was sent to read, not a separate body of data**, and it does not index the GSE225028 DIPG CUT&RUN at all - so the true count of independent human SUV39H1 occupancy systems in all public archives is **two**, not three. **And the file answers the beat's first question at gene resolution, negatively.** It lists **26 target genes** at the +/-5 kb threshold: MTRNR2L2, MSH3, DHFR, MTRNR2L8, MTRNR2L1, DUX4, RGPD2, RGPD1, COL23A1, FRG2, FRG2C, CNOT3, CDKN1A, PGK1, CCDC200, MDM2, GATA3, TPTEP2-CSNK1E, DDB2, FAM227B, DTWD1, STMN3, RTEL1, SIRT1, MYOG, LMO3. ***KMT2A* is not one of them.** This was read **before** the Q114 pre-registration was written and is disclosed there as the basis of its NEGATIVE prior.

Go deeper
Why 'no ENCODE record' and 'never measured' are different claims, and this beat had to say which

The registry already carries the row SUV39H1 has ChIP-Atlas data and no ENCODE target record, whose instruction is: state the archive in the claim. absence-no-h3k9-writer-or-reader-localised-at-the-kmt2a-locus wrote SUV39H1: never-measured on the strength of the ENCODE census alone, and Q113 then found two GEO deposits. The ENCODE half was right; the word never was not.

This entry closes the archive question properly: ENCODE holds nothing (three routes, controlled); ChIP-Atlas holds one deposit re-indexed; GEO holds two deposits, six SUV39H1 samples, two human cell types. That is the whole world of human SUV39H1 occupancy data as of 2026-09-22, and both deposits are now read (ana-q114-suv39h1-is-not-at-the-kmt2a-locus-in-either-patient-derived-diffuse-midline-glioma-line and the MCF-7 companion).

What the 26-gene list can and cannot bound

It is a peak-level, +/-5 kb, gene-resolution summary of four MCF-7 ChIP-seq samples at ChIP-Atlas's own threshold. It cannot speak to a 147 bp intragenic element, it cannot speak to a cell type other than MCF-7, and a gene's absence from it is not the same as no signal in the gene. It is a prior, and it is used here only as one.

It is also a useful warning in the other direction: five of the 26 are MT-RNR2-like pseudogenes and two are FRG2 paralogues, which is the signature of a repeat-rich mapping artefact rather than of a curated biology list.

Facts and figures
scriptno script - three live archive queries with controls through the identical URL template; every response code and count recorded inline
statusrun
run date2026-09-22
run byQ114-suv39h1-at-the-locus
independent human suv39h1 occupancy systems in all public archives2
shown for fusionNO - nobody has looked in any KMT2A fusion system; neither archived system is haematopoietic
encode routes 2026 09 22
{
  "/targets/SUV39H1-human/": "HTTP 404",
  "/targets/BARD1-human/ (positive control)": "HTTP 200",
  "/targets/EXO1-human/ (negative control)": "HTTP 404",
  "type=Target&searchTerm=SUV39H1": "total 0",
  "type=Experiment&target.label=SUV39H1": "total 0"
}
chip atlas 2026 09 22
{
  "url": "https://chip-atlas.dbcls.jp/data/hg38/target/SUV39H1.5.tsv",
  "http_status": 200,
  "bytes": 938,
  "n_target_genes": 26,
  "experiment_columns": [
    "SRX7030945",
    "SRX7030946",
    "SRX7030947",
    "SRX7030948"
  ],
  "all_columns_cell_type": "MCF-7",
  "kmt2a_present": false,
  "maps_to_geo": "GSE139196 / GSM4133857-60"
}
brief premises corrected
[
  "the ChIP-Atlas URL returns HTTP 200, not 206",
  "ChIP-Atlas is a second route to one of the two deposits, not a third independent route to SUV39H1 data"
]
How this could bite us back
  • A clean archive census invites the conclusion that the question is closed. It is not: two deposits, both non-haematopoietic, both resting-state, is the smallest evidence base in this graph's H3K9 argument, and the census makes that scarcity visible rather than resolving it.
Still open
  1. Does ReMap or GTRD hold a SUV39H1 experiment that neither ENCODE nor ChIP-Atlas indexes? The registry records that ReMap returns 401 for SUV39H1, which is an access failure and not an absence, and this beat did not retry it. GTRD was not queried at all.
  2. Are the five MT-RNR2-like pseudogenes and two FRG2 paralogues in ChIP-Atlas's 26-gene list a mapping artefact? If they are, the list's specificity is poor and KMT2A's absence from it carries correspondingly less weight as a prior.
  3. Is there a SUV39H1 CUT&RUN or ChIP in any haematopoietic cell, deposited under the retired symbol KMT1A rather than SUV39H1? Q113 swept GEO on SUV39H1[Title]; a KMT1A[Title] sweep of GEO DataSets was not run by that beat and is not run here.
Every source behind this entry (3)
  1. E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database

    SUV39H1 has no ENCODE target record and no ENCODE experiment, by three routes queried on 2026-09-22, with a positive and a negative control travelling through the identical URL template.

    What this evidence cannot show

    An HTTP 404 on a target page is a statement about ENCODE's target vocabulary, not about the protein. ENCODE could add a SUV39H1 experiment tomorrow. The claim is dated and archive-scoped on purpose.

    Evidence that argues against this (1)
    • ENCODE carries tagged-target labels a bare-symbol census cannot see, which is why the type=Target searchTerm route was run in addition to the exact-label page; both are empty. A third possibility the registry does not cover - a SUV39H1 experiment filed under an entirely unrelated target label - cannot be excluded by any query. source
  2. E2strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database

    ChIP-Atlas's entire hg38 SUV39H1 holding is the four MCF-7 samples SRX7030945-48, i.e. GSE139196 re-indexed, and KMT2A is not among the 26 genes it calls SUV39H1 targets at +/-5 kb.

    What this evidence cannot show

    Fetched 2026-09-22: HTTP 200, 938 bytes, 27 lines (header + 26 genes). The dispatch brief recorded this URL as returning 206 and as constituting a third independent route to SUV39H1 data; both are corrected here. A target-gene table is a peak-level summary at a fixed threshold, not a signal track, and it cannot address a 147 bp element.

    Evidence that argues against this (1)
    • ChIP-Atlas thresholds and gene-assignment rules change between releases, and a gene can drop off a target list for reasons unrelated to the underlying signal. The signal-level read of the same four samples is the check on this, and it is run in the MCF-7 arm rather than inferred from here. source
  3. E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    GSE139196 carries no !Series_pubmed_id of its own; PMID 34194047 sits on the SuperSeries GSE139199, which lists GSE139196 as one of four sub-series.

    What this evidence cannot show

    Fetched 2026-09-22 with targ=self&form=text&view=brief for both accessions. Attributing the sub-series to PMID 34194047 is therefore an inference through the SuperSeries relation, which is the correct route but is one step longer than a direct !Series_pubmed_id and should be stated as such wherever the PMID is used for these four samples.

    Evidence that argues against this (1)
    • A SuperSeries relation does not guarantee that every sub-series' samples appear in the linked paper. The four SUV39H1 samples may be deposited data the paper never analysed, which is in fact this beat's working assumption. source
Connected to