Add NetCleave integration for MHC-I/II C-terminal cleavage prediction

[iskandr]

Goal

Add a NetCleave predictor wrapper to mhctools for C-terminal peptide processing prediction (MHC-I and MHC-II pathways).

• Paper: https://www.nature.com/articles/s41598-021-92632-y
• Repo: https://github.com/BSC-CNS-EAPM/NetCleave

Why

• One of the only public predictors that explicitly covers MHC-II antigen processing in addition to MHC-I. Class-II processing is currently a gap in our predictor set (NetChop / pepsickle are MHC-I proteasomal cleavage; no class-II option exists today).
• Fits the existing proteasome_cleavage / antigen-processing slot for class-I; class-II coverage may motivate a separate Kind or a refinement of the existing semantics.

Integration shape (proposed)

Closest existing analogue is NetChop, not pepsickle:

• Not pip-installable. Distributed as git clone + python3 NetCleave.py --predict .... We'd shell out to a user-configured installation path, the same way we configure NetMHCpan paths today.
• Heavy deps on the NetCleave side: Keras/TensorFlow, scikit-learn, biopython, pandas, numpy, plus R (dplyr, argparser). Users provide a working install; we don't try to manage it.
• Inputs: FASTA of a protein, or CSV (peptide + UniProt ID, or peptide + protein sequence). We'd write a temp FASTA/CSV and parse the output directory.
• Side effects: NetCleave can fetch protein sequences from UniProt at runtime. Wrapper should prefer the peptide+protein-sequence CSV form so we don't introduce network dependence inside predict().
• Subprocess isolation: Likely needed (same Keras/TF + libomp class of issues that motivated [codex] Add pepsickle subprocess isolation #201 for pepsickle). Worth following the optional-subprocess pattern from Pepsickle.

Open design questions

1. Kind choice. Use existing proteasome_cleavage for both class I and II, or introduce a class-II-specific antigen-processing kind? The MHC-II pathway is endolysosomal, not proteasomal — strictly speaking proteasome_cleavage is misnamed if reused. Possible: add Kind.antigen_processing (already exists) as the umbrella and let predictors declare which they cover via kind_support() + mhc_class.
2. Output semantics. NetCleave outputs positional cleavage probabilities, not a single per-peptide score. We need to decide whether the per-peptide score is the C-terminal probability (analogous to NetChop) or something derived. Should align with how ProcessingPredictor and the score_cterm / score_nterm_cterm family already collapse positional scores to per-peptide.
3. Class-II peptide-length handling. Class-II peptides span a wider length range and the cleavage signal is different. Check whether the same wrapper code path works for both classes or whether class-II needs its own subclass (e.g. NetCleave_I / NetCleave_II mirroring NetMHCpan*_BA / _EL pattern).
4. kind_support() metadata. New predictor needs to declare its mhc_class (I, II, or both) and mhc_dependence (none — cleavage is MHC-independent).

Out of scope

• Bundling or vendoring NetCleave itself.
• Training / --train mode of NetCleave; we only need --predict.

Related

• Add pepsickle integration for proteasome cleavage scoring #178 (pepsickle integration)
• Pepsickle: optional subprocess isolation to avoid torch / pandas libomp clash on macOS #200 / [codex] Add pepsickle subprocess isolation #201 (pepsickle subprocess isolation — pattern to reuse)
• problem with netChop #120 (NetChop integration history — closest existing analogue)
• Track candidate model integrations (open weights, pip-installable, active) #189 (candidate model integrations tracker — link from there once this is filed)

[iskandr]

Decision: Kind for class-II cleavage → endolysosomal_cleavage

Resolving open design question #1 (the Kind choice) so the wrapper isn't blocked on naming.

Decision: add a new distinct kind rather than overloading proteasome_cleavage:

Kind.proteasome_cleavage    # existing — MHC-I, cytosolic proteasome (NetChop, Pepsickle)
Kind.antigen_processing     # existing — umbrella
Kind.endolysosomal_cleavage # new — MHC-II, endolysosomal cathepsin cleavage (NetCleave class II)

Why this name (and not the alternatives):

• The existing enum names the agent of proteolysis (proteasome_cleavage, erap_trimming, tap_transport), not the compartment.
• Class I has a single dominant machine (the proteasome); class II does not — it's a diffuse cathepsin family across the endosome→lysosome continuum. So the rule is: name the machine when one dominates, fall back to the compartment when the machinery is a diffuse family. endolysosomal is effectively a proxy for "the cathepsin family."
• Rejected cathepsin_cleavage (implies one enzyme; it's a family) and cytosolic_cleavage/renaming the class-I side (trades a precise machine name for a broader compartment name, would be a breaking rename of a shipped kind, and "cytosolic" wrongly implies it also covers cytosolic exopeptidase trimming, which the enum keeps separate).
• The two scores are not comparable across pathways, which is the substantive reason for distinct kinds, not just naming taste.

kind_support() metadata for the new predictor:

• endolysosomal_cleavage: mhc_class="II", mhc_dependence="none" (cleavage is MHC-independent).
• If a single wrapper covers both classes, it declares both kinds with the right mhc_class per kind.

If we later want the compartment axis first-class: don't rename — add a compartment bit (cytosolic vs endolysosomal) to kind_support() metadata alongside mhc_class, so it's queryable without overloading the Kind string.

---

Two implementation notes found while scoping NetCleave

1. There's no class-II "mode" — you select class by model. NetCleave has no --class II flag. Class is chosen by which pretrained model in data/models/ you point at (--model_path); models are prefixed I_ / II_:

• MHC-II: II_mass-spectrometry_HLA-DR, II_mass-spectrometry_HLA-DP, II_mass-spectrometry_HLA-DQ, II_mass-spectrometry_HLA
• MHC-I: I_mass-spectrometry_HLA-A*02:01, I_mass-spectrometry_HLA-B, I_mass-spectrometry_H2-Kb, … (+ combined_strategy, new_iedb)

This supports the NetCleave_I / NetCleave_II subclass split floated in design question #3 — each subclass just pins its default model prefix. Confirmed not pip-installable: git clone + python3 NetCleave.py --predict <input> --pred_input <n>, shell out per the NetChop pattern (subprocess isolation à la pepsickle #201 if the Keras/TF + libomp clash bites).

2. ⚠️ Class-II signal is weak — document it. The paper reports AUC 0.66 for MHC-II vs 0.91 for MHC-I (the class-II C-terminus sits outside the binding groove and cathepsin specificity is diffuse). The wrapper should ship a docstring warning so nobody over-trusts the class-II score.

Refs: NetCleave repo · NetCleave paper (Sci Rep 2021)