Goal
Decide whether/how to surface PredIG's MHC-I immunogenicity score in mhctools.
What PredIG is
A trained MHC-I immunogenicity model for CD8+ T-cell epitopes (binary: immunogenic vs. not). 8–15mer peptides, 4-digit HLA-I alleles.
Architectural mismatch (the main problem)
PredIG is not a base predictor — it's an aggregator that internally re-runs:
- NetCleave v2.0 (proteasomal cleavage)
- NetCTLpan v1.1 (TAP transport)
- MHCflurry v2.0 (binding/processing/presentation)
- NOAH v1.0 (structure-based HLA binding)
mhctools currently wraps base predictors (one tool per wrapper, one Kind per call). PredIG would be the first aggregator. Two integration shapes, both with downsides:
- Thin subprocess wrapper. Treat PredIG as a black box, shell out, return the final immunogenicity score into
Kind.immunogenicity. Duplicates work when the same pipeline already runs MHCflurry / NetCleave separately via mhctools. Also opaque — no access to intermediate scores.
- Re-implement PredIG's aggregation on top of mhctools predictors. Avoids duplication, but that's the wrong layer of the stack — it belongs in topiary / vaxrank or a new repo, not in mhctools' "thin wrapper per tool" model.
A third option is to not integrate it in mhctools at all and instead let topiary / vaxrank / a new package call PredIG directly when they want an aggregated immunogenicity score.
Distribution
- Docker / Singularity containers, or web API (5k pHLAs/batch).
- No pip / conda package.
- GPL-v2 — compatible with mhctools (Apache-2.0) for use, but not for vendoring source.
Decision needed
- Do we want PredIG as a thin subprocess wrapper in mhctools, accepting the redundant-work cost?
- Or do we route this to topiary / vaxrank where aggregation belongs?
Leaning toward the second path — file this for tracking; revisit if a concrete downstream need pushes for option (1).
Related
Goal
Decide whether/how to surface PredIG's MHC-I immunogenicity score in mhctools.
What PredIG is
A trained MHC-I immunogenicity model for CD8+ T-cell epitopes (binary: immunogenic vs. not). 8–15mer peptides, 4-digit HLA-I alleles.
Architectural mismatch (the main problem)
PredIG is not a base predictor — it's an aggregator that internally re-runs:
mhctools currently wraps base predictors (one tool per wrapper, one Kind per call). PredIG would be the first aggregator. Two integration shapes, both with downsides:
Kind.immunogenicity. Duplicates work when the same pipeline already runs MHCflurry / NetCleave separately via mhctools. Also opaque — no access to intermediate scores.A third option is to not integrate it in mhctools at all and instead let topiary / vaxrank / a new package call PredIG directly when they want an aggregated immunogenicity score.
Distribution
Decision needed
Leaning toward the second path — file this for tracking; revisit if a concrete downstream need pushes for option (1).
Related
Kind.immunogenicity(already populated by BigMHC_IM today)