The interactome instrument is migrated to IntAct REST: 277 partners, 118 written, 42.6% - the denominator grew by 60 and coverage fell 3.5 points, which is the instrument getting honest

This is a count within one run of one instrument against one database, which is what makes it established rather than strong - it is not a claim about the true size of the interactome. It is IntAct only: a partner absent from IntAct is absent from this figure, and IntAct has NOT curated Skucha 2018 (PMID 29777171), the seven-bait MLL-fusion AP-MS network this project measures separately, so the real biological denominator is larger again. Partner identity comes from IntAct's own moleculeA/moleculeB symbol fields, which removes the old alias-parsing failure mode and substitutes a dependency on IntAct's symbol choice. The paging guard asserts the promised totalElements equals the records actually paged, so a silently short union would fail rather than be reported.

• The two figures are less comparable than presenting them side by side implies. The PSICQUIC instrument resolves partners by parsing alias strings and the REST instrument reads a symbol field, so a partner both endpoints carry could still be counted under different symbols by the two scripts. The 60-partner difference is therefore an upper bound on what the endpoint change alone contributed, and no row-level reconciliation of the two unions was performed.
• A coverage figure that falls when the instrument improves undermines the use this project has been putting it to. It has been reported cycle to cycle as progress, and this shows the series is not a time series at all - it mixes changes in the graph with changes in the instrument. The honest reading is that no coverage number here should be compared across cycles unless the endpoint and the matching regex were identical, and most of the historical series does not meet that test.
• The queue figure in this item was wrong when first written and is corrected here, which is itself an argument against trusting this instrument's derived numbers on first run. It reported 19 because the adjudication register had not been ported, so the very first thing the migrated instrument produced was ten units of duplicated work.

'Reachable only via a non-canonical id' is a property of THIS query form - a bare accession - not an absolute statement about PSICQUIC, which might return these rows under a different query. The underlying paper for the proof case (PMID 22327296) was not read here; what was verified is the curated record's fields, so the claim is about what IntAct asserts and what each endpoint delivers, not about the biology of the menin-KMT2A interface. The count of 20 depends on the isoform-stripping rule, and a partner with one canonical row and ten isoform rows correctly does not appear in it.

• That seven of the twenty already had entries argues the practical cost of the defect was smaller than its size suggests. The graph had found these proteins by other routes - curated reading, other databases, the Skucha network - so the missing rows were not, for those seven, missing biology. It is evidence that redundant sourcing partly compensated for a broken instrument, which weakens the case that the coverage figure was badly misleading even while confirming it was wrong.
• Thirteen of the twenty have no entry and most are single-row, single-bait observations - BRINP1, CKAP5, KIF11, KIF24, ORC1, RBM45, SDC1, YEATS4 each appear once. On this project's own read-queue threshold (two publications or two baits) almost none qualifies, so the newly visible partners are mostly the weakest class of evidence and should not be written up as findings merely because they became visible.

The MI-id set was declared by me, not taken from a published ontology slice, so 'exactly one' is exactly one UNDER THAT FILTER and a different reasonable filter would give a different number. The rule is deliberately strict - it requires EVERY row for a partner to be substrate-or-structure - so a partner with one co-IP and nine methyltransferase assays does not appear, which understates the contamination. Including MI:0065 (ITC) and MI:0114 (x-ray) in the same set as enzyme assays is arguable: they are binding measurements, and the menin-KMT2A ITC record in E2 is evidence this project treats as its best, so this filter would discard it if that were its only row.

• This result cuts against the fix Q104 asked for. It recommended filtering the census by detection method rather than by symbol class, and the measurement says that filter would remove exactly one partner out of 277 - so the engineering is not worth doing for its effect on the figure. The reason to care about substrate rows is that they misdescribe the biology of a specific entry, which is an argument for reading rows, not for filtering the census.
• The strictness that makes 'exactly one' defensible also makes it nearly uninformative about how much of the union rests on non-binding evidence. A per-ROW census - what fraction of all rows are enzyme assays or structures - was not computed, and it is the number that would actually bound the problem.

A count of row-sides in one run. The recovery resolves an accession to a symbol and therefore silently merges a processed chain with its parent protein - NFKB1's p50 chain becomes NFKB1 - which is right for a partner census and WRONG for any claim about which cleavage product was assayed. Nothing here establishes that the p50 chain rather than p105 is what binds; that distinction is discarded by design and would have to be read back out of the rows.

• Merging a processed chain into its parent may be the wrong call for NF-kappa-B specifically, which is the clearest case in the set. p105 and p50 are functionally different molecules - p105 is a cytoplasmic precursor and inhibitor, p50 a nuclear DNA-binding subunit - so recording 'NFKB1 is a partner' from rows curated on the p50 chain asserts less than the rows contain and could mislead an entry written from this census.