The federated sweep this graph prescribes for the missing index-fusion interactor cannot be run: PSICQUIC free text returns ZERO for `mll_af9`, an entity that provably exists and returns 32 records under its accession - so every provider's zero in that sweep is uninterpretable
also called Q113 PSICQUIC control failure
One entry here says the next thing to do is search every interaction database for the fusion protein this project is about. Running that search returns nothing everywhere - but it also returns nothing for a fusion protein we know is in there, so the search cannot tell the two apart and the recommendation does not work as written.
The same thing, for a scientist
`absence-intact-holds-seven-mll-fusion-proteins-and-not-the-index-one` names its own next step: *a federated PSICQUIC sweep across all IMEx providers for a KMT2A::AFF1 entity*. This beat ran it across all 14 providers in the live PSICQUIC ACTIVE registry. Every provider returned 0 for `mll_af4`, `mll_aff1`, `MLL-AF4`, `KMT2A-AFF1` and `af4_mll` - **and also 0 for `mll_af9`**, which is EBI-2890930, an interactor that exists in IntAct and returns **32** records when queried by its accession through the same endpoint. The transport is fine: `brca2` returns 189 on IntAct, 322 on BioGrid, 92 on MINT, 341 on IMEx. **PSICQUIC free text does not index the interactor LABEL.** So the prescribed sweep produces a uniform zero that is a property of the query grammar, not of the databases, and writing it down would have created a five-provider bounded absence out of nothing. The right instrument is the IntAct REST interactor endpoint, which resolves `mll_af9` to one entity and `mll_af4`, `MLL-AF4` to zero - so the original absence **survives**, on a working instrument, and its named next step should be replaced.
The measurement
| route | brca2 | Q03164 | mll_af9 | EBI-2890930 | mll_af4 |
|---|---|---|---|---|---|
| IntAct PSICQUIC | 189 | 218 | 0 | 32 | 0 |
| BioGrid PSICQUIC | 322 | 0 | 0 | - | 0 |
| MINT PSICQUIC | 92 | 13 | 0 | - | 0 |
| IMEx PSICQUIC | 341 | 295 | 0 | - | 0 |
IntAct REST findInteractor | - | - | 1 entity | - | 0 |
The mll_af9 row is the whole result. An entity that exists, in the database being queried, returns zero through free text and thirty-two through its accession 1. Reactome's provider returns 0 even for brca2 and is separately broken; it was excluded rather than counted 2.
What this means for the absence it was supposed to test
Through the working instrument the absence holds. findInteractor/mll_af9 returns one entity, mll_af9_human_protein / EBI-2890930; findInteractor/mll_af4 and findInteractor/MLL-AF4 return zero; findInteractor/mll returns 70 interactors including MLL/CALM fusion (Q8N6B3) and MLL/AF6 fusion (Q1WD23) - the very entities the original entry enumerated - and no KMT2A::AFF1 among them 3. Complex Portal, checked independently, returns 15 complexes for KMT2A and 7 for AFF1 and zero for MLL-AF4 4. So: IntAct does not hold it, Complex Portal does not hold it, and the cross-provider question remains genuinely open because PSICQUIC cannot be asked it.
The general form, which is the part worth carrying
A recommendation stored in an entry is a claim that a procedure will work, and this project has never checked one. The failure here is invisible in the ordinary way: the sweep runs, returns cleanly, and produces a confident uniform zero across fourteen independent providers - the most convincing-looking absence imaginable, from an instrument that cannot see the object. Run the positive control on the recommended procedure, not only on the query. One line - mll_af9, an entity we already knew existed - cost nothing and turned a five-provider finding into an instrument failure.
| script | no script; PSICQUIC registry ACTIVE list enumerated live, then current/search/query?format=count per provider per term |
|---|---|
| status | run |
| run date | 2026-09-22 |
| run by | Q113-bounded-absence-audit |
| recommendation tested | absence-intact-holds-seven-mll-fusion-proteins-and-not-the-index-one, data.next_step_not_done: 'a federated PSICQUIC sweep across all IMEx providers for a KMT2A::AFF1 entity' |
| verdict | NOT EXECUTABLE AS WRITTEN. The positive control fails on every provider. |
| providers enumerated | 14 |
| a first attempt that was also wrong | the first run of this sweep built every URL by appending '/webservices/current/search/query/' to the registry's own base string, which already ends in '/psicquic'. Every provider returned HTTP 500, including IntAct. That is recorded because a 500 across 14 providers reads as an outage and is in fact a typo, and because the second attempt's uniform ZERO was far more dangerous than the first attempt's uniform ERROR. |
| replacement recommendation | IntAct REST /intact/ws/interactor/findInteractor/<label> for IntAct and IMEx-in-IntAct, Complex Portal complex-ws/search for complexes, and a BioGRID REST call with an API key for BioGRID. PSICQUIC free text should not be used for any label-keyed question in this project again. |
| bearing on the original absence | SURVIVES. On the working instruments IntAct holds no KMT2A::AFF1 entity and Complex Portal holds none either; the cross-provider half remains genuinely unasked. |
providers with a passing brca2 control
[ "IntAct (189)", "BioGrid (322)", "MINT (92)", "IMEx (341)" ]
providers not individually controlled
[ "bhf-ucl", "ChEMBL", "HPIDb", "MPIDB", "Reactome-FIs", "UniProt", "MBInfo", "VirHostNet" ]
providers excluded for a failing control
[ "Reactome" ]
the control that killed it
{
"term": "mll_af9",
"psicquic_free_text": 0,
"psicquic_by_accession": 32,
"accession": "EBI-2890930",
"intact_rest_findInteractor": 1
}- Is there a BioGRID entity for any MLL fusion? BioGRID's PSICQUIC passes the brca2 control but cannot be asked a label question; a keyed REST call would settle it and was not made.
- How many other entries in this corpus store a recommended NEXT STEP that has never been tested for executability? This is the first one checked and it failed.
- Should Complex Portal be sent a curation request for the KMT2A::AFF1 chimera, given that it already models every complex the fusion joins?
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
PSICQUIC free text returns zero for the interactor label mll_af9 while returning 32 for its accession EBI-2890930 through the identical endpoint.
PSICQUIC IntAct provider, current/search/query: brca2=189, Q03164=218, id:Q03164=161, mll_af9=0, EBI-2890930=32, id:EBI-2890930=32 · EMBL-EBI PSICQUIC 2026What this evidence cannot show
Run 2026-09-22. Counts are the `format=count` scalar and were not re-derived from the returned MITAB rows.
Evidence that argues against this (1)
- It is possible that some providers DO index labels and simply hold no MLL fusion, in which case their zeros are honest and only IntAct's is uninterpretable. Distinguishing that needs a label-positive control per provider, which does not exist because no other provider is known to hold a fusion entity - so the sweep is unresolvable rather than merely failed. Aranda B et al. 2011
- E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
One of the fourteen active PSICQUIC providers returns zero for the universal positive control and must be excluded rather than counted as a zero.
PSICQUIC registry ACTIVE list, 14 providers; Reactome provider returns 0 for brca2 while BioGrid returns 322 and IMEx 341 · EMBL-EBI PSICQUIC Registry 2026What this evidence cannot show
A provider can return zero for brca2 legitimately if it holds no protein-protein interaction data of that kind; Reactome-FIs and Reactome are pathway-derived and this may be a scope difference rather than an outage. Either way the zero carries no information about fusion entities.
Evidence that argues against this (1)
- Counting an outage as a zero is the ReMap-401 failure in another costume, and the standing registry row already says so: a client that branches on transport status records a true negative or a service failure identically. ReMap 2026
- E3strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database
On the working instrument, IntAct holds no KMT2A::AFF1 interactor entity while holding mll_af9 and the MLL/CALM and MLL/AF6 fusions.
What this evidence cannot show
`findInteractor` matches on name and identifier fields; a KMT2A::AFF1 entity filed under a label containing neither 'mll' nor 'af4' would still be invisible. The original entry makes the same caveat and it stands.
Evidence that argues against this (1)
- The absence of a curated fusion ENTITY is not the absence of curated fusion interactions: KMT2A::AFF1 co-immunoprecipitations are published and are simply recorded against the two parent accessions, as the original entry says in its own `not_bounded_to`. EMBL-EBI IntAct 2026
- E4strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database
Complex Portal holds no MLL-AF4 complex, while holding 15 KMT2A-containing and 7 AFF1-containing complexes.
EMBL-EBI Complex Portal complex-ws search: MLL-AF4 = 0, KMT2A = 15, AFF1 = 7, MLL = 36 · EMBL-EBI Complex Portal 2026What this evidence cannot show
Complex Portal curates stable stoichiometric complexes and does not model chimeric proteins at all, so this zero is a modelling-scope fact rather than a curation gap. It is recorded as a checked provider, not as a surprise.
Evidence that argues against this (1)
- The KMT2A=15 result includes the super-complex entries, so Complex Portal DOES hold the machinery this project cares about - meaning the zero for the fusion is a decision about chimeras specifically, which is the more interesting reading and the one a curation request should target. EMBL-EBI Complex Portal 2026
the absence survives on the working instrument (IntAct REST) and on Complex Portal; its stored next step does not work as written
the database-entity-enumeration class audited: a recommendation stored in an entry is a claim, and this is the first one tested for executability