Known limitations

mantispy is in alpha. These are the gaps to know about before you build on it.

• Case studies are not re-executed in CI. The tutorials run on every change, but the case-study notebooks ship with stored outputs and are only re-run by hand, so their outputs can lag behind the code.

• One perturbation per object, by design. Each row is a member of a single perturbation. A cell carrying more than one guide is a QC artifact that is expected to be filtered out upstream, in your own pipeline, before stamping, so multi-membership is out of scope rather than unimplemented. In pooled screens the guide is the perturbation identity (recorded in uns["mantispy"]["perturbation"]) and is aggregated to genes downstream; see Genetic screens.

• Performance is not tuned for full JUMP scale. The functions are correct on large screens, but some use memory or time that grows quickly with the number of profiles. One easy lever is the PCA that feeds tvn() and harmony(): scanpy’s default solver decomposes the whole cells-by-features matrix in double precision, whereas on a screen with far more cells than features sc.pp.pca(adata, svd_solver="covariance_eigh") eigendecomposes the small features-by-features covariance instead. It returns the same components with a fraction of the memory and time, and is exact rather than fitted on a subsample.

• SpatialData is read-only. Images and segmentations are read through io.read_plate, and nothing is written back to the SpatialData object.