PhosphoSitePlus returns HTTP 403 to its own homepage from this environment, so the PTM-database absence named by the cycle-65 census cannot be bounded there - and the positive control is what proves the 403 is a block and not an answer
also called Q115 PhosphoSitePlus unreachable
One of this project's claims is that no phosphorylation site has ever been mapped on a fusion protein, and the right place to check is a database of such sites. That database refuses every request from this machine, including its own front page, so the check could not be run and no conclusion may be drawn from the refusal.
The same thing, for a scientist
The cycle-65 census named four entries that ask PubMed a question PubMed cannot answer, and `absence-no-phosphosite-mapped-on-any-kmt2a-fusion-protein` is one: it claims a PTM-database-shaped absence and its instrument is `[tiab]`. This beat attempted PhosphoSitePlus. **Every request returns HTTP 403, including `https://www.phosphosite.org/homeAction.action`** [E1]. Because the positive control travels through the same host and the same request shape as the query, the 403 is identifiable as a blanket block rather than as a statement about KMT2A - **which is the whole point of running it**. Had only the protein page been tried, a 403 would have been indistinguishable from 'no record', and this project has already published one absence built on exactly that confusion, the ENCODE `assay_title` 404. **The correct record is: instrument unavailable, absence unchanged, no zero written.** Two reachable substitutes were confirmed working from the same session: PRIDE returned MLL-AF4 projects on a keyword query [E2], and Europe PMC full text gives 24 records for an MLL-fusion-name list intersected with `phosphopeptide`, 3 for the phrase `phosphorylation of MLL-AF9` [E3].
What was tried, exactly
GET https://www.phosphosite.org/proteinAction.action?id=4815&showAllSites=true -> HTTP 403
GET https://www.phosphosite.org/simpleSearchSubmitAction.action?searchStr=KMT2A -> HTTP 403
GET https://www.phosphosite.org/homeAction.action <- POSITIVE CONTROL -> HTTP 403
All three with a browser User-Agent, from the same process, seconds apart. The control is the third line and it is the only line that makes the first two interpretable.
The general rule this beat applied and recommends: a positive control must travel the same URL template, not merely the same API - the project already has this written down for ChIP-Atlas, where CTCF.05.tsv and NOTAREALANTIGEN.5.tsv both 404 while CTCF.5.tsv returns 206. Here the same discipline turns an apparent database answer into an environment fact.
What can still be said about the underlying absence
Nothing new, and that is the honest outcome. The full-text route does add a little: BODY: intersections of MLL-fusion names with phosphopeptide return 24 records and with phosphosite/phosphorylation site/phosphoproteomic 175, and BODY:"phosphorylation of MLL-AF4" returns 0 while BODY:"phosphorylation of MLL-AF9" returns 3 - all three of which are titled as phenotype papers (immunosuppressant repurposing, E-selectin niche chemoresistance, MEF2C phosphorylation) rather than as fusion-protein PTM mapping 3. That is consistent with the entry and does not replace a PTM-database query.
One reachable proxy was not tried and should be: UniProt's own MOD_RES feature table for Q03164 and P51825, which is a PTM database this project already queries daily for other fields.
| script | none - direct HTTP probes and Europe PMC BODY: queries, 2026-09-22 |
|---|---|
| status | run |
| verdict | INSTRUMENT UNAVAILABLE - no zero written, absence unchanged |
| entry re bounded | absence-no-phosphosite-mapped-on-any-kmt2a-fusion-protein |
| absence class | measured-not-searched |
| absence class basis | UNCHANGED from the entry under test, and deliberately so. The archive that would settle it was not reached, so no evidence was added in either direction. Recording the failed attempt is the contribution: the next beat knows PhosphoSitePlus is blocked from this environment and knows that UniProt MOD_RES is the untried reachable alternative. |
probes — the numbers behind the chart
[
{
"url": "https://www.phosphosite.org/proteinAction.action?id=4815&showAllSites=true",
"http": 403
},
{
"url": "https://www.phosphosite.org/simpleSearchSubmitAction.action?searchStr=KMT2A",
"http": 403
},
{
"url": "https://www.phosphosite.org/homeAction.action",
"http": 403,
"role": "POSITIVE CONTROL - same host, same request shape"
}
]reachable substitutes confirmed
[
{
"archive": "PRIDE Archive v2",
"http": 200,
"example": "PXD043920"
},
{
"archive": "Europe PMC BODY: full text",
"http": 200,
"corpus": 12362145
}
]full text counts — the numbers behind the chart
{
"(MLL-AF4 OR MLL-AF9 OR MLL-ENL) AND phosphopeptide": 24,
"MLL fusion list AND phospho vocabulary": 175,
"phrase 'phosphorylation of MLL-AF4'": 0,
"phrase 'phosphorylation of MLL-AF9'": 3,
"operand phosphopeptide": 16254
}not tried
[ "UniProt MOD_RES feature table for Q03164 (KMT2A) and P51825 (AFF1) - a reachable PTM source this project already queries", "iPTMnet, dbPTM, PhosphoPICK - other PTM aggregators, none attempted", "a PRIDE query restricted to phospho-enriched MLL-fusion datasets" ]
not read
[
{
"pmid": "21574958",
"why": "AF4 phosphorylation-dependent regulation; the nearest miss and the cheapest refutation"
}
]- Does UniProt's MOD_RES feature table for Q03164 and P51825 carry experimentally supported phosphosites, and do any fall C-terminal to a breakpoint so that they sit on the fusion? This is reachable today and was not run.
- Is PhosphoSitePlus blocked by network or by User-Agent? A single retry from a different route would settle whether this is an environment fact or a permanent one for this project.
- Does PMID 21574958 map a phosphosite on AF4 that lies within the retained C-terminal region? That single read could reword the entry's headline.
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
PhosphoSitePlus returns HTTP 403 Forbidden to a protein page request, a simple-search request and its own homepage from this environment on 2026-09-22.
PhosphoSitePlus homeAction.action - HTTP 403 Forbidden (positive control), 2026-09-22 · PhosphoSitePlus, Cell Signaling Technology 2026What this evidence cannot show
This is a statement about this environment on this date, not about PhosphoSitePlus. The site is widely used and almost certainly serves ordinary browsers; the block is most likely a datacentre-IP or automation filter. An agent on a different network, or one using the licensed bulk download, would very probably succeed.
Evidence that argues against this (1)
- A 403 can also be transient or rate-limit related, and only one attempt per URL was made with no retry and no delay. The correct reading of a single 403 with a failing control is 'not attempted successfully', which leaves open that a patient retry would work. PhosphoSitePlus 2026
- E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
The proteomics archive route is reachable from the same session: the PRIDE Archive v2 API returns projects for keyword MLL-AF4, the first being PXD043920, 'MLL-AF4 cooperates with PAF1 and FACT to drive high density enhancer interactions in leukemia'.
PRIDE Archive API v2 project search, keyword=MLL-AF4 (returns PXD043920) · EMBL-EBI PRIDE Archive 2026What this evidence cannot show
Fetched 2026-09-22, HTTP 200, 39,534 bytes. This confirms the route works; it does not re-do the cycle-65 PRIDE sweep, which already recorded three MLL-AF4 projects and two under RS4;11. A project existing is not a phosphosite being mapped - the deposited runs would have to be searched with a variable phospho modification and against a junction-containing database.
Evidence that argues against this (1)
- PXD043920 is an enhancer-interaction proteomics study, not a phospho-enrichment study, so its existence argues that the relevant deposits may not be phospho-enabled at all. A PRIDE query restricted to phospho-enriched MLL-fusion datasets was not run and could return zero, which would strengthen the entry rather than weaken it. EMBL-EBI PRIDE Archive 2026
- E3moderate confidence 3 of 5: One strong study, or several smaller consistent ones.database
Europe PMC full text gives 24 records for (MLL-AF4 OR MLL-AF9 OR MLL-ENL) AND phosphopeptide, 175 for an MLL-fusion list intersected with phosphosite vocabulary, 0 for the phrase 'phosphorylation of MLL-AF4' and 3 for 'phosphorylation of MLL-AF9', none of the three titled as a fusion-protein PTM mapping study.
Europe PMC RESTful search, BODY: full-text field, MLL fusion names x phospho vocabulary, 2026-09-22 · Europe PMC 2026What this evidence cannot show
Operand control BODY:"phosphopeptide" = 16,254, so the conjunction is not dead. Eight of the 24 phosphopeptide records are congress abstract books. Screening was at title level only and the three phrase hits were not opened, so a phosphosite mapped in a supporting figure of any of them would be missed - which is exactly the rule-80 limitation this beat exists to reduce and cannot eliminate.
Evidence that argues against this (1)
- PMID 21574958, 'Protein network study of human AF4 reveals its central role in RNA Pol II-mediated transcription and in phosphorylation-dependent regulatory mechanisms' (Biochem J 2011), is in the 24 and is the nearest miss in the whole search: it is about phosphorylation-dependent regulation of AF4, the index fusion's C-terminal partner. It was NOT opened. If it maps a site and places it C-terminal to the AFF1 breakpoint, the site is on the fusion by construction and the entry's claim needs rewording. Biochemical Journal 2011
INSTRUMENT UNAVAILABLE: PhosphoSitePlus 403s on its own homepage, so the census's named instrument mismatch could not be closed and no zero was written
a fourth archive that spells unavailability as an HTTP error code, caught only because the positive control travelled the same URL template
the sequence lookup that would tell you whether the YEATS hotspot residues are phospho-acceptors needs the PTM database that is blocked from this environment
independently reproduces the 403 and supplies a working substitute endpoint