The AFF1 promoter window holds three genes' TSSs, not two, and the third is protein-coding - Q153's 92.5% is confirmed and its two-gene framing is not

The same pairwise statistic, computed the same way, over three annotations:

The last row is not a rounding difference. Ensembl does not carry the symbol AFF1-AS1 at all, and its model of the antisense locus starts 1,201 bp downstream of AFF1's refGene TSS, inside AFF1, rather than 151 bp upstream of it. Ensembl does contain RefSeq's reading, as one of four transcripts (ENST00000509262, TSS 86,934,542), so the two databases are not simply opposed - but the headline statistic takes essentially the whole range of its possible values depending on which one you ask, and Q153's entry quotes only the top of that range 12.

This is the same shape as Q153's own IRX2/IRX2-DT finding (215 bp / 89.2% under RefSeq, 437 bp / 78.2% under Ensembl) but far more extreme, and the reason is that the disagreement here is about which end of the gene the transcript starts at, not about where within a few hundred bp.

# C:\Temp\q145irx1\promoters.tsv  (19,404 rows, TSS +/- 1000, one NM_ row per symbol)
C4orf36  chr4  86892422  86891422  86893422  -  NM_144645
AFF1     chr4  86935001  86934001  86936001  +  NM_001166693
# AFF1-AS1: no row

Membership tested directly against the loaded 19,404-symbol matrix: AFF1 present, C4orf36 present, AFF1-AS1 absent, IRX2 present, IRX2-DT absent.

So an audit asking "does another row of my table have its TSS inside this window?" returns no for AFF1 - correctly, given the table - and that answer is wrong about the genome in two independent ways at once.

I pre-registered three branches and named C3 (NEITHER / the premise is wrong) as "the branch I am least prepared for and the one I would most like to be true, which is a reason to distrust my reading of it". C3 fired, and the self-warning was warranted, so here is the specific record it demanded:

The record that established it is the UCSC ncbiRefSeq track over chr4:86,915,000-86,945,000, fetched 2026-09-24, HTTP 200, which returns seven C4orf36 transcripts in a window where the refGene track returns none. I did not go looking for C4orf36; it appeared because the Ensembl region query, run to check whether Ensembl and RefSeq disagreed about AFF1-AS1, returned a third gene I had not asked about. The finding is a by-product of running a control for something else, which is worth saying because a beat scoped tightly to the AFF1/AFF1-AS1 pair would have missed it entirely and would have reported a clean confirmation of Q153.

Two other pre-registration weaknesses came true:

• I pre-declared that C1 (never occupied, so the question is moot) was the likeliest branch. It is false: the window is occupied in 20 of 27 samples. See ana-q155-aff1s-own-promoter-window-is-occupied-in-20-of-27-samples-and-the-call-cannot-be-attributed-to-aff1.
• I labelled "IRX2-DT"[tiab] and IRX2[tiab] AND antisense[tiab] as positive controls in the literature script. They are not controls, they are comparators, and both returned zero, which made the script print controls_all_positive: False and briefly look like an instrument failure. The genuine positive controls all returned large values. A control that can legitimately be zero is not a control.
• 🔴 And the largest error, caught by the coordinator's own audit within the hour: I reported C4orf36's row as displaced by 42,310 bp. It is not displaced at all. I computed the displacement against a UCSC track query restricted to chr4:86,915,000-86,945,000 — a window that by construction cannot contain the matching transcript at 86,892,422 — and then took min(observed TSSs) as the nearest. Every step ran correctly and the answer was manufactured by the filter that defined the query. A filter must report what it removed. The finding the error supported — a current C4orf36 TSS 269 bp from AFF1's, invisible to the project's table — is unchanged; only the reason it is invisible changed, from stale to one row per symbol, and the corrected reason is the one that cannot be fixed by refreshing anything.