Finding
SamplingSpecification.sidechain_conditioning DOES gate real atom-37/sidechain-atom tensor injection in _prepare_ligand_context (_sampling_helper.py): if not spec.sidechain_conditioning: return {..., "atom_37": None, ...} -- this part is a genuine, working gate, unlike ligand_conditioning (filed separately, #114).
But populating those tensors only matters if the model itself was built to consume sidechain context. That's a separate knob, ligand_mpnn_use_side_chain_context (a RunSpecification field, forwarded to load_model via prep.py's model_conditioning dict -- fixed this session, commit 83a918e, as part of the same audit). The campaign CLI path (aminx campaign plan/ramp-plan) never exposes a flag to set ligand_mpnn_use_side_chain_context at all -- only aminx run/aminx spec do (verified against the installed CLI's --help).
Impact
Even after this session's prep.py forwarding fix (which corrected the mechanism), a campaign row that sets sidechain_conditioning=True populates real atom_37/atom_37_mask tensors and feeds them into a model that was still built with use_side_chain_context=False, because nothing on the campaign path ever sets the model-level flag. The tensors are real; the model can't use them. Net effect for campaign users is unchanged from before the prep.py fix, even though the underlying wiring bug that fix addressed is real and correctly resolved for aminx run/aminx spec callers.
Found during the 260715/260716 aminx campaign control-knob audit (same investigation as #110/#111/#113/#114).
Recommendation
Add --ligand-mpnn-use-side-chain-context to campaign plan/ramp-plan's CLI surface, or auto-derive it from sidechain_conditioning=True at the campaign-planner level (mirroring how model_family now auto-derives from checkpoint_id, aminx PR #104) so a caller doesn't have to know to set two separate, non-obviously-linked flags to get real sidechain conditioning through the campaign path.
Finding
SamplingSpecification.sidechain_conditioningDOES gate real atom-37/sidechain-atom tensor injection in_prepare_ligand_context(_sampling_helper.py):if not spec.sidechain_conditioning: return {..., "atom_37": None, ...}-- this part is a genuine, working gate, unlikeligand_conditioning(filed separately, #114).But populating those tensors only matters if the model itself was built to consume sidechain context. That's a separate knob,
ligand_mpnn_use_side_chain_context(aRunSpecificationfield, forwarded toload_modelviaprep.py'smodel_conditioningdict -- fixed this session, commit83a918e, as part of the same audit). The campaign CLI path (aminx campaign plan/ramp-plan) never exposes a flag to setligand_mpnn_use_side_chain_contextat all -- onlyaminx run/aminx specdo (verified against the installed CLI's--help).Impact
Even after this session's
prep.pyforwarding fix (which corrected the mechanism), a campaign row that setssidechain_conditioning=Truepopulates realatom_37/atom_37_masktensors and feeds them into a model that was still built withuse_side_chain_context=False, because nothing on the campaign path ever sets the model-level flag. The tensors are real; the model can't use them. Net effect for campaign users is unchanged from before theprep.pyfix, even though the underlying wiring bug that fix addressed is real and correctly resolved foraminx run/aminx speccallers.Found during the 260715/260716 aminx campaign control-knob audit (same investigation as #110/#111/#113/#114).
Recommendation
Add
--ligand-mpnn-use-side-chain-contexttocampaign plan/ramp-plan's CLI surface, or auto-derive it fromsidechain_conditioning=Trueat the campaign-planner level (mirroring howmodel_familynow auto-derives fromcheckpoint_id, aminx PR #104) so a caller doesn't have to know to set two separate, non-obviously-linked flags to get real sidechain conditioning through the campaign path.