IntAct curates SEVEN MLL fusion proteins as first-class interactors - ENL, AFF4, AF9, GAS7, ELL, AF6 and CALM - and not the index one

These are not trivial records. EBI-2890930 against DOT1L is MI:0915 physical association and is NOT spoke-expanded 1 - an observed binary interaction between a fusion protein and DOT1L, which is precisely the kind of evidence this graph most wants and cannot get for its own fusion.

The modelling convention also carries a warning: EBI-2890930's annotation reads "An amino acid sequence which is not represented in UniProt", and its alternative identifiers list both Q03164 and P42568 as 'multiple parent'. A naive accession join will therefore silently attribute a fusion-protein interaction to wild-type KMT2A, which is the same family of error as the processed-chain and protein-group-leader traps already recorded here.

Bounded to: the IntAct interactor namespace, on 2026-09-21, reached through the REST findInteractions endpoint, by (a) enumerating every non-UniProt interactor appearing in the 908 records of the six core proteins, (b) free-text queries on the naming pattern IntAct itself uses for the chimeras that do exist, and (c) a wider free-text sweep over mll, KMT2A, AFF1, MLL-AF4 and fusion, filtered on interactor labels containing mll, which is what raised the count from four chimeras to seven.

Query controls, per brief rule 67 - never trust a zero from a query you have not shown can return a one:

mll_af9_human_protein    32   <- the instrument returns ones
mll_aff4_fusion           7   <- and again
mll_enl_human_protein     8   <- and again
mll_af4                   0
mll_aff1                  0
KMT2A-AFF1                0

NOT bounded to: the literature. A KMT2A::AFF1 co-IP exists in many papers; what does not exist is an IntAct curation of it as a distinct molecular entity. Nor is this a statement about other interaction databases - BioGRID, MINT, ComplexPortal and the IMEx consortium members were not queried, and a federated PSICQUIC sweep across providers is the obvious next step and was not done.

Also not bounded: the naming pattern. Five of the seven existing entities follow a mll_<partner> convention and two are written MLL/<partner> fusion, so the free-text queries were built from it; a KMT2A::AFF1 entity filed under an unexpected label - af4_mll, kmt2a_aff1_chimera, a bare EBI accession with a descriptive name - would be missed by (b) although it should still have been caught by (a) if it interacted with any of the six core proteins.

Three of this project's recurring difficulties converge here.

1. Partner import, measured at the database level. concept-partner-import records that 54% of fusion-bearing load-bearing evidence in this graph comes from a fusion other than the index one, and that 0 of 24 sampled load-bearing experiments rest on a dedicated human KMT2A::AFF1 experiment 3. The interaction database reproduces the same asymmetry exactly: seven other chimeras are modelled - including GAS7, AF6 and CALM fusions that are far rarer clinically - and the index one is not.
2. The fusion is not the sum of its parts and the database cannot say so. KMT2A::AFF1 loses the KMT2A PHD fingers, bromodomain and SET domain and gains the AFF1 C-terminus. An interaction recorded against full-length KMT2A may involve a domain the fusion does not have - which is the graph's own subtraction-kmt2a-* argument - and no amount of wild-type interactome curation resolves it.
3. It is why the TurboID keeps getting proposed. This project has repeatedly listed a proximity-labelling experiment on KMT2A::AFF1 as unfinished business. The absence here is the same gap seen from the database side, and it also says what the deposit should look like when it is done: a distinct interactor entity for the fusion, not rows filed against Q03164.