Oncofusion

start / graph / concept-q125-the-declared-extents-name-the-container-and-max-end-names-the-data

Explainerstrong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.Q125-the-h2ak119ub-arm-of-the-pcgf1-knockout

Two deposit defects in one beat, both invisible to the check in use: a genome-build verdict read from a file's declared extents names its CONTAINER, and the furthest coordinate carrying signal names its DATA - and a clause that cannot return the other answer has been reported as a passing check in four beats

also called declared extents vs max_end · the vacuous has_chr20 clause · a check that cannot fail is not a check

A data file says which genome it belongs to, and separately it contains data that stops somewhere. Those two can disagree, and only the second is a fact about the measurement. A related mistake: one part of the standard check here could only ever return 'pass', because the program never looked for the thing it was testing for.

The same thing, for a scientist

**Two defects found in one beat, and what they share is more useful than either.** **1. The declaration and the data can name different genomes, in both directions, in one series.** Q122 found four K562 files declaring `mm10` and carrying hg38 coordinates. This beat found one mouse file declaring `hg38` and carrying mm10 coordinates, clipped at the hg38 chromosome lengths [E1]. **The declared per-chromosome extent is written by the conversion tool from whatever genome it was handed. The furthest coordinate carrying signal is a property of the reads.** A build check that reads only the declaration gets one of the two directions wrong every time, and reports a confident verdict either way. **Read both; disagreement between them is the signal, not an inconvenience.** **2. `has_chr20: false` has been part of a passing build verdict in four beats and is VACUOUS.** The binner iterates a hardcoded list of chr1-19+X. It never asks any file whether chr20 exists, so the field is `false` by construction for every file ever checked [E2]. It was introduced as a real test - Q122's hg38-in-mm10 files ARE missing chr20-22 - and it became decorative the moment it was computed from the list of chromosomes requested rather than from the list present. **The general form: a check whose value is determined by the checking code rather than by the object is not a check.** The corpus registry already holds the same shape twice - a coverage metric that counted a link near the thing instead of the thing, and a fallback that constructed the value it was looking for. **The tell is the same each time: the field is always the same for every object.** One line - print the distribution of the field across everything you checked - catches all three.

Go deeper
The concrete remedy, three lines
build_from_declared = argmin over {mm10, mm39, hg38, hg19} of sum |declared_len(c) - size(c)|
build_from_data     = argmin over the same of sum |max_end(c)  - size(c)|   # over c where max_end>0
if build_from_declared != build_from_data:  REPORT BOTH, and derive the retained mask from max_end

and, for any field that forms part of a verdict, print its distribution over everything checked before believing it. has_chr20 was false 34 times out of 34 here, which is what a vacuous field looks like from the outside.

Keep four candidate builds and not two. A mouse-only check of mm10 against mm39 would have called GSM8123405 mm10 by default and flagged nothing.

Why a mouse file might carry a human build declaration at all

GSE260742 contains both mouse and human samples and its own !Sample_data_processing block says 'Mouse cell lines were aligend to mm10 and human to Hg38' and 'Assembly: mm10 and hg38' - a single processing description covering both, applied to every sample record including this one. A pipeline that takes the genome as a per-batch parameter rather than per-sample will do this, and it will do it to whichever samples happen to sit in the wrong batch. That is a prediction: the defect should cluster by submission batch, and it is testable by reading the headers of the other 157 files.

Facts and figures
kindmethodological lesson, measured
the ruleCompute the build twice - once from each file's declared per-chromosome extents and once from its max_end per chromosome - and report both. They name the container and the data respectively, and their disagreement is the finding. Keep at least four candidate builds. And for any field forming part of a verdict, print its distribution across everything checked: a field with one value for every object is determined by the checker, not by the objects.
absence classmeasured-not-analysed
absence class noteBoth defects are present in files that have been public since 2025-11-23 and both are readable from a file header. The sweep that would bound the problem - reading the declared extents and max_end of all 158 GSE260742 samples against four candidate builds - has NOT been run. 34 of 158 headers have ever been read, across five beats, and one of the 34 is wrong.
absence class assigned2026-09-23 (Q125)
measured
{
  "n_tracks_checked_this_beat": 34,
  "n_failing_declared_extent_check": 1,
  "has_chr20_true_count": 0,
  "has_chr20_false_count": 34,
  "beats_carrying_the_vacuous_clause": [
    "Q117",
    "Q120",
    "Q122",
    "Q124",
    "Q125"
  ]
}
How this could bite us back
  • Every murine locus-level claim this project has made from GSE260742 rests on a build verdict computed from declared extents alone. The verdicts happen to be right for the 33 files where both fields agree, and nobody had checked that they agree.
Still open
  1. Does the wrong-build declaration cluster by submission batch, as the per-batch-parameter explanation predicts? Reading 158 headers would answer it and would also bound how much of this series is affected.
  2. How many other fields in this project's checks are determined by the checker rather than by the object? The detector is one line - print the distribution - and it has never been run over the existing checks.
Every source behind this entry (2)
  1. E1strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.dataset

    Within GSE260742 both directions of container/coordinate mismatch occur: Q122 recorded four K562 files declaring mm10 while carrying hg38 coordinates, retaining an 84.46% sub-genome with chr20-22 absent; and GSM8123405 declares hg38 (63 bp from hg38 over 20 chromosomes) while carrying mm10 coordinates clipped at the hg38 lengths on chr13-chr19 and chrX, losing 2.76%.

    What this evidence cannot show

    Q122's half is read from its committed results.json and was not re-measured here; this beat did not re-bin any K562 file. The two directions were found by two different beats using the same four-candidate check, which is evidence that the check finds them and not that they are common.

    Evidence that argues against this (1)
  2. E2strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.dataset

    The has_chr20 clause of the genome-build check used by Q117, Q120, Q122, Q124 and Q125 is determined entirely by the checking code: Q117Bin iterates a hardcoded CHRS list of chr1-19+X and never requests chr20 from any file, so the field is false for all 34 tracks checked in this beat and for every track checked in the four earlier ones.

    What this evidence cannot show

    This is a statement about the instrument's source, read directly. It does not mean any earlier verdict was wrong - the declared-extent distance metric carried those verdicts and the chr20 clause added nothing either way. It means one clause of a stated multi-part check has never contributed information.

    Evidence that argues against this (1)
Connected to