How the three occupancy archives spell zero: ENCODE 404, ReMap 401, ChIP-Atlas 404 - and ChIP-Atlas spells a one-character URL typo exactly the same way, so a whole sweep can come back cleanly and be entirely false
also called Q113 archive zero spellings · ChIP-Atlas threshold trap
None of the three big protein-on-DNA archives answers an empty question with an empty answer; all three answer with what looks like a broken connection. Worse, one of them gives the identical broken-connection answer when you mistype one character in the address, so a search that finds nothing anywhere can be a typo rather than a fact.
The same thing, for a scientist
Every archive-bounded absence in this corpus rests on reading a status code, and all three archives this project uses return an HTTP error for a genuine zero. Measured live 2026-09-22, each with a passing positive control in the same batch: **ENCODE** returns **404** from the search endpoint for zero results, so `type=Experiment&assay_title=TF ChIP-seq&target.label=BARD1` is a 404 while `/targets/BARD1-human/` is a 200 [E1]. **ReMap 2022** returns **401** with a plain-English body saying there is no experiment for that target, while CTCF returns 200 and 172 kB of JSON [E2]. **ChIP-Atlas** returns **404** for an antigen it does not hold - and returns **the identical 404 for a valid antigen queried with the wrong threshold token**: `CTCF.05.tsv` is a 404 and `CTCF.5.tsv` is a 200 [E3]. A sweep written with `05` produces a clean, well-formed, uniform zero for every protein queried, with no error text and nothing in the response to distinguish it from a genuine archive-wide absence. This beat hit exactly that and caught it only because CTCF was in the batch. The rule that follows is not about any of these three archives: **for any archive query, the positive control must go through the same URL template as the queries, not merely the same API.**
The measurements, each with its control
| archive | genuine zero spells | positive control in the same batch | the trap |
|---|---|---|---|
| ENCODE search endpoint | HTTP 404 | target.label=CBX5 returns 200 with 4 experiments | pinning assay_title=TF ChIP-seq makes the 404 a property of the FILTER; BARD1 and RAD50 both have target records at 200 1 |
ReMap 2022 findByTarget | HTTP 401 + {"error":"Sorry. There is no experiment for target X and tax_id 9606 on remap2022"} | CTCF returns 200, 172,276 bytes | 401 normally means authentication; a client branching on status records a true negative as a credentials failure 2 |
ChIP-Atlas target/<ANTIGEN>.<th>.tsv | HTTP 404 | CTCF.5.tsv returns 200, 47,217 bytes | CTCF.05.tsv also returns 404. The threshold token is load-bearing and its failure is indistinguishable from an absent antigen 3 |
All three are the same defect in three costumes: the transport layer is being used to carry a data-layer answer, and the data layer has more states than the transport layer has codes.
Why the ChIP-Atlas one is the worst of the three
The ENCODE and ReMap zeros are at least about the query you sent. The ChIP-Atlas threshold typo makes every query in the sweep wrong in the same direction at once, so the result has no internal inconsistency to notice: five proteins, five 404s, a tidy conclusion that none of them has occupancy data anywhere. Nothing in the response mentions the threshold. The only thing that catches it is a protein you already know is present, queried through the same template - and the template is where the error lives, so a control run through a different template would not catch it either.
This beat's first ChIP-Atlas batch returned 404 for SUV39H1, SETDB1, CTCF, BARD1 and EXO1. SETDB1 has 14 experiments and CTCF has thousands. Without them in the batch the sweep would have produced a five-protein archive-wide absence that is completely false.
One substantive cross-archive result that fell out of doing this properly
With controls passing, the three archives disagree about SUV39H1: ChIP-Atlas holds 4 experiments (SRX7030945-48, MCF-7), ReMap 2022 holds 0 (401), ENCODE holds 0 (no target record under any label). And ChIP-Atlas does not hold the GSE225028 CUT&RUN samples at all. So no single secondary archive is a sufficient bound for an occupancy absence in this project, and the GEO primary index reached samples that two of the three secondaries had missed 4.
| script | no script; direct HTTP HEAD/GET against three archives with a positive control in every batch |
|---|---|
| status | run |
| run date | 2026-09-22 |
| run by | Q113-bounded-absence-audit |
| the rule | the positive control must travel through the SAME URL TEMPLATE as the queries, not merely the same API. A control built by hand while the queries are built by a loop cannot catch a defect in the loop's template, and the template is where this failure lives. |
| this beats own near miss | the first ChIP-Atlas batch of this beat used the token 05 and returned 404 for SUV39H1, SETDB1, CTCF, BARD1 and EXO1. SETDB1 has 14 experiments and CTCF has thousands. Only the CTCF row made the batch uninterpretable rather than publishable. |
zero spellings
{
"ENCODE_search_endpoint": {
"zero": "HTTP 404",
"control": "target.label=CBX5 -> 200, 4 experiments",
"note": "the target-record endpoint /targets/<SYM>-human/ is the one that discriminates a missing protein from an empty filtered search"
},
"ReMap2022_findByTarget": {
"zero": "HTTP 401 with an English error body",
"control": "CTCF -> 200, 172276 bytes"
},
"ChIP_Atlas_target_tsv": {
"zero": "HTTP 404",
"control": "CTCF.5.tsv -> 200, 47217 bytes",
"typo_returns_the_same": "CTCF.05.tsv -> 404"
}
}cross archive suv39h1
{
"ChIP-Atlas": 4,
"ReMap2022": 0,
"ENCODE": 0,
"GEO_primary": 6,
"reading": "no single secondary archive bounds an occupancy absence in this project"
}- How many archive-bounded zeros already committed in this corpus were taken from a status code without a same-template control in the same batch? This beat re-ran three and all three had a control; the other archive-bounded entries were not audited for it.
- Does ChIP-Atlas expose a query API that returns a structured empty result rather than a 404, so that a sweep can distinguish 'no antigen' from 'bad path' without a control?
- ReMap's scope is transcription-factor-like experiments. Is its exclusion of SUV39H1 a documented scope rule or a coverage gap? The distinction decides whether ReMap can ever be cited as a bound for a chromatin enzyme.
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
The ENCODE search endpoint returns HTTP 404 for zero results, so a filtered target query can return 404 for a protein that has a live target record.
What this evidence cannot show
Fetched 2026-09-22. The 404-for-empty behaviour is not documented in the responses themselves; it is inferred from the pairing of a 404 search with a 200 target record for the same label, which this beat verified on four labels.
Evidence that argues against this (1)
- For EXO1, DNA2, SUV39H1 and SUV39H2 the 404 turns out to be honest - no target record exists under any label, tagged or untagged - so the filter did not manufacture those. Treating every ENCODE 404 as suspect would be its own error. ENCODE Project 2026
- E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
ReMap 2022 returns HTTP 401 with an explanatory body for a target it holds no experiments for, while returning 200 for CTCF in the same batch.
What this evidence cannot show
Fetched 2026-09-22. A 401 could in principle also be returned for a genuine authorisation problem; the body text is what discriminates, so a client must read the body and not the code.
Evidence that argues against this (1)
- The body is unambiguous English, so this failure is only dangerous for an automated client. A human running the query once sees the explanation immediately - which is an argument that scripted archive sweeps in this project need body-reading assertions more than interactive ones do. Hammal F et al. 2022
- E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
ChIP-Atlas returns HTTP 404 both for an antigen it does not hold and for a valid antigen queried with a wrong threshold token, and the two are indistinguishable.
ChIP-Atlas hg38 target tables: CTCF.5.tsv 200 (47,217 bytes), CTCF.1.tsv 200, CTCF.10.tsv 200, CTCF.05.tsv 404; SUV39H1.5.tsv 200 with 4 SRX; BARD1.5.tsv 404; EXO1.5.tsv 404 · ChIP-Atlas / DBCLS 2026What this evidence cannot show
Fetched 2026-09-22 by HEAD for the controls and GET for the parsed tables. The valid threshold tokens observed are 1, 5 and 10; whether other tokens are valid was not enumerated.
Evidence that argues against this (1)
- A static file server returning 404 for a path that does not exist is correct behaviour, not a bug. The defect is in treating a file-path convention as a query API - which is what this project did, and which is why the remedy is a control through the same template rather than a complaint to the archive. Oki S et al. 2018
- E4strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database
The three secondary archives disagree about SUV39H1 - ChIP-Atlas 4, ReMap 0, ENCODE 0 - and none of them holds the CUT&RUN samples that the GEO primary index returned.
ChIP-Atlas SUV39H1.5.tsv header: SRX7030945|MCF-7, SRX7030946|MCF-7, SRX7030947|MCF-7, SRX7030948|MCF-7 · ChIP-Atlas / DBCLS 2026What this evidence cannot show
ChIP-Atlas and ReMap both re-process from SRA and have different inclusion rules, release dates and antigen-normalisation steps; a disagreement between them is expected and is not evidence that either is wrong. The point is only that one of them is not a bound.
Evidence that argues against this (1)
- ReMap explicitly restricts itself to transcription-factor-like DNA-binding experiments, so excluding a histone methyltransferase may be a deliberate scope decision rather than a coverage gap - in which case its zero is honest and uninformative rather than wrong. ReMap 2026
the mechanism behind the filtered-database-query class: all three archives carry a data-layer answer on the transport layer
re-derives that entry's ENCODE 404 correction and its ReMap 401 observation live, with CTCF and BARD1 controls passing
every count in this hypothesis was taken with a same-template positive control, which that entry is the reason for
a fourth archive that spells unavailability as an HTTP error code, caught only because the positive control travelled the same URL template