Oncofusion

start / graph / concept-every-archive-spells-zero-differently-and-two-of-the-three-spellings-look-like-transport-errors

Explainerestablished confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.Q37-archive-sweep

ENCODE spells zero as HTTP 404, ReMap spells it as HTTP 401, and GEO spells it as a well-formed count of zero under a retired symbol - three archives, three spellings, and two of them are indistinguishable from a broken connection

also called how each archive says it has nothing · ENCODE 404, ReMap 401, GEO retired symbol · CUT&RUN is not searchable in Entrez

When a public database has no data for a gene, it does not always say so politely. One returns the same error a missing web page gives, another returns the error you get when a password is wrong, and a third returns a confident zero simply because you used the gene's current name instead of its old one.

The same thing, for a scientist

**Four distinct spellings of zero were hit in one beat, across three archives, and each one can be mistaken for something else** [E1, E2]. This graph already carries the first of them as a registry row; the other three are new. | archive | how it spells zero | what it looks like | the distinguishing control | |---|---|---|---| | **ENCODE** experiment search | **HTTP 404** | a dead endpoint | a target known to have data, in the same call | | **ENCODE** - and the trap on top of it | 404 is a property of the **WHOLE QUERY**, not of the target | "no target record exists" | query `/targets/?label=X` separately | | **ReMap 2022** | **HTTP 401** with `{"error":"Sorry. There is no experiment for target BARD1 and tax_id 9606 on remap2022"}` | an authentication failure | CTCF returns 628 in the same batch | | **GEO** esearch | a clean, well-formed `count: 0` with a non-empty `querytranslation` | a genuine zero, and it is one **for the string you asked about** | run the retired symbol and the protein name too | **The ENCODE refinement is the one that cost this graph a wrong classification.** The existing registry row is correct that a 404 means zero experiments. What it does not say is that the 404 describes **the query**, and a query carries an assay filter. `assay_title=TF ChIP-seq&target.label=BARD1` returns 404 because BARD1 has no ChIP-seq; **BARD1 has an ENCODE target record and two released CRISPR RNA-seq experiments.** Two entries in this corpus render that 404 as *"no ENCODE target record exists"*, which is a stronger claim the API never made. **RAD50 separates the two cleanly: `/targets/RAD50-human/` is HTTP 200 and the experiment search is HTTP 404.** **The GEO spelling is the most dangerous, because it looks correct.** In this beat, at GSM title level: ``` NBN[Title] AND ChIP -> 0 NBS1[Title] AND ChIP -> 19 RBBP8[Title] AND ChIP -> 0 CtIP[Title] AND ChIP -> 16 MRE11[Title] AND ChIP -> 44 MRE11A[Title] AND ChIP -> 0 ``` **Three of twelve proteins were invisible in one archive under one of their names.** Each zero carried a non-empty `querytranslation` and the `pubmed_safe` genuine-zero signature, so every instrument check this project owns passed. The zero is real; the question it answers is not the question that was asked. **ChIP-Atlas has the same property from the other side** - it files MRE11 under `MRE11A`, so an exact antigen match on the current symbol returns zero for a protein with fourteen experiments. This is rule 71 and the septin rule, living in archives rather than in PubMed. **And a fourth, found in-run: `CUT&RUN` cannot be searched in Entrez at all.** `CUT&RUN[All Fields]` translates to `CUT[All Fields] AND RUN[All Fields]` - the ampersand is the boolean AND. That particular failure runs **broad**, so the zeros stay conservative. But the grouped form built from it does not: `(ChIP OR CUT&RUN OR CUT&Tag OR CUT-RUN OR ...)` returned **0 for CBX3** while its own `ChIP` sub-term returned **7**, and **0 for KDM5A** while its `CUT AND RUN` sub-term returned **4**. **An OR group returning fewer records than one of its own disjuncts is a parser failure, and it returns a clean zero.** Same family as rule 94. **The rule.** Before recording an archive zero: run a **control target with known data in the same call**; query the archive's **target/entity registry separately from its data search**; run the **retired symbol, the protein name and the archive's own antigen vocabulary**; and **read the query back** - a translation, an error body, or whatever the archive gives you - rather than reading only the count. An HTTP status code is part of the answer in two of these three archives, and in neither case does it mean what its name means.

Facts and figures
prior art in this graphthe ENCODE-404 row in data/symbol-collisions.json (added king-cycle-63, found by Q35) is the first of these and is correct as far as it goes; the ReMap 401, the ENCODE target-registry distinction, the GEO retired-symbol spelling, the ChIP-Atlas antigen vocabulary and the Entrez ampersand are new and are proposed as registry rows.
spellings of zero measured 2026 09 22
{
  "ENCODE_experiment_search": {
    "spelling": "HTTP 404",
    "example": "https://www.encodeproject.org/search/?type=Experiment&status=released&target.label=EXO1&format=json -> 404",
    "control_in_same_batch": "CTCF -> 200, 579 experiments",
    "the_refinement": "the 404 is a property of the WHOLE QUERY. target.label=BARD1 with assay_title=TF ChIP-seq gives 404; without the assay filter it gives 200 and 2 experiments."
  },
  "ENCODE_target_registry": {
    "spelling": "HTTP 404 for a target with no record at all",
    "example": "/targets/?label=EXO1 -> 404; /targets/?label=RAD50 -> 200 with /targets/RAD50-human/",
    "why_it_matters": "RAD50 has a target record and zero experiments. That pair is the demonstration that 'experiment search 404' does not mean 'no target record'."
  },
  "ReMap_2022": {
    "spelling": "HTTP 401",
    "body": "{\"error\":\"Sorry. There is no experiment for target BARD1 and tax_id 9606 on remap2022\"}",
    "endpoint": "https://remap.univ-amu.fr/api/v1/info/byTarget/target=<SYMBOL>&taxid=9606",
    "control_in_same_batch": "CTCF -> 200 with count_datasets 628",
    "hazard": "a retry loop reads 401 as an auth failure and either retries forever or records the wrong absence class; the informative content is in the BODY of a status code most clients discard"
  },
  "GEO_esearch_under_a_current_symbol": {
    "spelling": "a well-formed count of 0 with a non-empty querytranslation and warninglist 'No items found.'",
    "measured": {
      "NBN[Title] AND ChIP": 0,
      "NBS1[Title] AND ChIP": 19,
      "RBBP8[Title] AND ChIP": 0,
      "CtIP[Title] AND ChIP": 16,
      "MRE11[Title] AND ChIP": 44,
      "MRE11A[Title] AND ChIP": 0
    },
    "why_it_is_the_worst": "every instrument check this project owns passes. The zero is genuine for the string asked; the string was the wrong one."
  },
  "ChIP_Atlas_antigen_vocabulary": {
    "spelling": "no matching row",
    "measured": "an exact antigen match on MRE11 returns 0; ChIP-Atlas files those 14 experiments under MRE11A, the symbol HGNC retired in 2019",
    "prescription": "match the antigen column with an alias regex, and print the antigen strings actually matched rather than the symbols searched"
  }
}
the entrez ampersand
{
  "finding": "CUT&RUN[All Fields] translates to CUT[All Fields] AND RUN[All Fields] - Entrez parses & as the boolean AND, so the literal string CUT&RUN cannot be searched",
  "direction": "BROAD - any record containing both words matches, so a zero from this form is conservative",
  "but_the_grouped_form_runs_to_zero": {
    "CBX3[Title] AND \"Homo sapiens\"[Organism] AND gsm[ETYP] AND ChIP[All Fields]": 7,
    "CBX3[...] AND (ChIP OR CUT&RUN OR CUT&Tag OR CUT-RUN OR CUTRUN OR ChEC OR DamID)[All Fields]": 0,
    "KDM5A CUT AND RUN sub-term alone": 4,
    "KDM5A the same OR group": 0,
    "verdict": "an OR group returning FEWER records than one of its own disjuncts is a parser failure that returns a clean zero. Same family as rule 94. Use one simple term per query and combine the counts yourself."
  },
  "how_it_was_caught": "by reading querytranslation back on a POSITIVE count, not on a surprising zero - the grouped query's translation showed the sub-terms had been rearranged by operator precedence"
}
the checklist
[
  "run a control target with known data IN THE SAME CALL, so an outage cannot masquerade as zero",
  "query the archive's target/entity registry separately from its data search - they answer different questions and return different status codes",
  "run the retired symbol, the protein name, and the archive's own antigen vocabulary, not only the current HGNC symbol",
  "read the query back: a querytranslation, an error body, a status code. The count alone is not the answer in any of these three archives",
  "never build an OR group of assay tokens in Entrez; run each term and add the counts yourself"
]
How this could bite us back
  • A checklist that says 'always run a control in the same call' doubles the number of requests to every archive, and the beats most likely to skip it are the ones under a session limit - which are also the ones whose zeros go into entries unrechecked.
  • Treating a 401 as data rather than as an auth failure is safe for ReMap today and would be actively wrong for an archive that genuinely requires credentials. The rule is to read the BODY, not to trust the status code in either direction.
Still open
  1. How many archive-derived absences in this corpus were bounded against a single archive with a single symbol spelling? The GEO and ChIP-Atlas evidence here says the under-count is real and this beat did not measure its size.
  2. Do IHEC, BLUEPRINT, PRIDE, 4DN and ProteomeXchange each have their own spelling of zero? Five more archives this project cites or plans to cite, none of them characterised, and the cost of finding out is one query with a control per archive.
  3. Should scripts/pubmed_safe.py grow a db=gds sibling? This beat wrote one in the analysis directory rather than in scripts/, which means the next beat will write a third. The genuine-zero signature is identical; only the database name changes.
Every source behind this entry (3)
  1. E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database

    Three archives spell an empty result three different ways and two of the three use an HTTP status code that names a different failure. Measured live on 2026-09-22 with a CTCF control in every batch: the ENCODE experiment search returns HTTP 404 for EXO1, DNA2, MRE11, RBBP8 and RAD50 while returning 579 experiments for CTCF; ReMap 2022 returns HTTP 401 with an explicit 'there is no experiment for target' message for the same proteins while returning 628 datasets for CTCF; and GEO esearch returns a well-formed count of 0 with a non-empty querytranslation.

    PMID 34751401DOI
    What this evidence cannot show

    Three archives at one moment. API behaviour changes without notice and none of these spellings is documented as a contract by its provider, so a future beat must re-establish the spelling rather than quoting this entry. Only ENCODE's behaviour was tested on more than a handful of symbols (seven), and ReMap's 401 was observed on six.

    Evidence that argues against this (1)
    • Reading a 404 or a 401 as 'zero' is itself a risk: a genuine outage, a rate limit or a URL typo produces the same codes. The only defence is the in-batch control, and if the control and the query differ in any respect other than the symbol - a different endpoint, a different filter - the control licenses nothing. This is the same defect rule 67 records inside a script written to enforce rule 67. Oncofusion knowledge graph coordinator 2026
  2. E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    A GEO zero under a current HGNC symbol can be a confident false negative: at GSM title level on 2026-09-22, NBN returned 0 ChIP samples and NBS1 returned 19; RBBP8 returned 0 and CtIP returned 16; MRE11 returned 44 and MRE11A returned 0. Each zero carried a non-empty querytranslation and the 'No items found.' warning, so every false-zero check this project owns passed. ChIP-Atlas has the mirror-image property, filing MRE11's fourteen experiments under the retired symbol MRE11A.

    What this evidence cannot show

    The queries were scoped to the symbol in the SAMPLE TITLE, the tightest and most under-recovering form; a looser All-Fields query would recover some of these under either name. The measurement therefore establishes that the title-scoped form has this property, not that GEO as a whole does. No systematic alias expansion was attempted for the nine proteins where the current symbol did return results, so the true under-count across this census is unknown.

    Evidence that argues against this (1)
    • Alias expansion is not a free fix and can make things worse: this graph records that expanding HGNC aliases resolves CD15 to FUT4, producing a confident wrong gene assignment for a 24-entry antigen. The prescription here is to run the alias as a SEPARATE query and report both counts, never to merge them. Oncofusion knowledge graph coordinator 2026
  3. E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    An Entrez OR group over assay tokens returned fewer records than one of its own disjuncts, producing a clean zero: CBX3[Title] AND Homo sapiens[Organism] AND gsm[ETYP] AND ChIP[All Fields] returns 7, while the same query with (ChIP OR CUT&RUN OR CUT&Tag OR CUT-RUN OR CUTRUN OR ChEC OR DamID)[All Fields] returns 0; KDM5A's CUT AND RUN sub-term alone returns 4 while the same OR group returns 0. Separately, CUT&RUN[All Fields] translates to CUT[All Fields] AND RUN[All Fields], because Entrez parses the ampersand as the boolean AND.

    What this evidence cannot show

    The mechanism was not fully diagnosed. Operator precedence (AND binding tighter than OR) explains the rearrangement visible in the translation but not obviously why the group returns FEWER than a disjunct, so 'parser failure' is a description of the behaviour and not an explanation of it. The finding is one archive, one query family, and was reproduced across twelve symbols rather than isolated.

    Evidence that argues against this (1)
    • This was my own error before it was a finding: the first pass of the GEO sweep pre-encoded the ampersand as %26, which urllib then re-encoded, and the resulting query silently dropped the CUT&RUN and CUT&Tag terms entirely. The translation showed only ChIP[All Fields] and I did not read it. The finding exists only because the second, correctly encoded run produced a zero so implausible that the translation finally got read. Oncofusion knowledge graph coordinator 2026
Connected to