Is a NetTCR-2.2 (pMHC:TCR binding) predictor in scope for mhctools?

[iskandr]

mhctools gives a lovely uniform interface over the MHC-ligand predictors — NetMHCpan, NetMHCcons, NetMHCIIpan, NetMHCstabpan, MHCflurry, etc. — all "does this peptide bind this MHC" tools.

We've been leaning on it heavily (thank you!) and hit a gap one step down the antigen-presentation cascade: pMHC:TCR binding (does a given αβ TCR recognise a given pMHC). The reference model there is NetTCR-2.2 (mnielLab — the same lab as NetMHCpan), and it would be natural to call it through the same mhctools-style wrapper we already use for NetMHCpan.

Before proposing a PR, I wanted to check scope, because NetTCR differs from everything currently in mhctools in two ways:

1. Modality — it predicts TCR specificity, not MHC-ligand binding. mhctools has so far been MHC-ligand-only; TCR:pMHC may be deliberately out of scope.
2. Interface — NetTCR-2.2 isn't a compiled DTU netMHC* binary you shell out to. It's a Python/Keras package that ships pretrained TFLite models; prediction runs on plain tensorflow (tf.lite.Interpreter) with no conda env. So a wrapper wouldn't follow the BaseCommandlinePredictor subprocess pattern — it'd be an in-process TFLite runner.

Questions:

• Is pMHC:TCR prediction something you'd want under mhctools, or should such wrappers live in a separate package (or be contributed upstream to NetTCR itself)?
• If in scope: we have a small, working wrapper that runs NetTCR-2.2's pan CV ensemble on the six-CDR input format (peptide + A1/A2/A3/B1/B2/B3), averages the ensemble, and reproduces the published IMMREP-2022 per-peptide AUROC (~0.79) in a few seconds. Happy to open a PR if you'd take it.

Context: we're using it as the runnable SoTA for a TCR:pMHC benchmark task; the wrapper is ~40 lines.

[iskandr]

How we'd actually run NetTCR-2.2 (it's more tractable than the "no conda env" note suggests)

Dug into mnielLab/NetTCR-2.2 to pin down the runtime story before committing to the modality. Good news: the weights are self-contained and the inference path is light. Notes for whoever picks this up.

Distribution & weights — no gated download

• Weights are committed directly into the git repo, not git-LFS. The pan model (models/nettcr_2_2_pan/checkpoint/) is a 5×5 CV ensemble of 25 .tflite files, ~407 KB each, ~9.7 MB total. A plain git clone gets everything — no registration wall, no separate weight fetch (unlike the DTU netMHC* binaries).
• negative_controls/ (needed for percentile ranks) and cv_pred_df.csv are bundled too.

Runtime — skip their conda env

• The official path is heavy-ish (environment.yml → conda, TF 2.11.0, Python 3.10.9; CPU is fine, no CUDA). We don't need it. Each fold is a standalone .tflite, so inference is just tf.lite.Interpreter — their own src/predict.py does exactly this: get_input_details() / get_output_details() → resize_tensor_input() for batch → allocate_tensors() → set_tensor() per feature → invoke() → get_tensor(output_details[0]['index']).
• So the optional dependency is just tensorflow (or the lighter tflite-runtime / ai-edge-litert) — much lighter than the full training env. Same optional-subprocess isolation pattern we use for pepsickle ([codex] Add pepsickle subprocess isolation #201) applies if the TF/libomp import clashes.

Input contract — the only non-trivial part

• Input is 7 features: peptide + the six CDR loops A1, A2, A3, B1, B2, B3.
• Each is BLOSUM50-encoded with a normalization factor of 5 (i.e. BLOSUM50 row /5) via keras_utils.enc_list_bl_max_len(), then right-padded per feature to a fixed length (peptide 12; A1/A2/A3 = 7/8/22; B1/B2/B3 = 6/7/23 in src/predict.py; missing residues padded with a 20-dim -1 vector).
• Don't hardcode those lengths — read them from interpreter.get_input_details()[i]['shape'] and match encoded arrays to input tensors by shape/order. That keeps the wrapper robust to the pan-vs-peptide model differences.

Ensemble + percentile rank

• src/predict.py runs a single model; ensembling and ranking live elsewhere. We'd average the sigmoid outputs across all 25 folds for the final score (this is what reproduces the published IMMREP-2022 ~0.79 per-peptide AUROC).
• Percentile rank = rank the raw score against the bundled negative-control score distribution — maps cleanly onto our existing percentile_rank field.

Ontology surface (the real design work)

Running it is easy; fitting it into mhctools' I/O model is the actual scope decision. NetTCR needs two things that don't exist today:

1. A TCR input type — the six CDR loops (A1/A2/A3/B1/B2/B3), which don't fit the current (peptide, allele) shape.
2. A new output kind — e.g. Kind.pMHC_TCR_binding — since this is TCR recognition, not MHC-ligand binding. mhc_dependence would be none (no allele), mhc_class I for the current 2.2 models.

Minimal in-process runner (sketch)

import numpy as np
import tensorflow as tf  # or tflite_runtime.interpreter as tflite

# per-feature encoders derive length from the model's own input tensors
def encode(seqs, maxlen):          # BLOSUM50 / 5, right-pad with -1 vectors
    ...                            # -> (batch, maxlen, 20) float32

def nettcr_score(row, checkpoint_dir):
    folds = sorted(glob(f"{checkpoint_dir}/t.*.v.*.tflite"))  # 25 models
    scores = []
    for path in folds:
        itp = tf.lite.Interpreter(model_path=path)
        inp = itp.get_input_details()          # 7 tensors, order == features
        for d in inp:
            itp.resize_tensor_input(d["index"], (1, *d["shape"][1:]))
        itp.allocate_tensors()
        for d, feat in zip(inp, ["peptide","A1","A2","A3","B1","B2","B3"]):
            itp.set_tensor(d["index"], encode([row[feat]], d["shape"][1]))
        itp.invoke()
        out = itp.get_output_details()[0]
        scores.append(float(itp.get_tensor(out["index"])[0, 0]))
    return float(np.mean(scores))   # ensemble mean -> Kind.pMHC_TCR_binding score

Verdict: no vendoring, no gated download, ~10 MB of weights, light optional dep. The engineering is a clean job; the only open question is appetite for adding the TCR modality (input type + new Kind) to the ontology — not "can we run it."

Refs: NetTCR-2.2 repo · NetTCR-2.2 preprint (eLife)