Measuring the accuracy of SPS MS3 in Proteome Discoverer 2.3!

Proteome Discoverer 2.3 has been out for a couple of months now and I've been too busy to even talk about it(?!?) which is more than a little crazy, probably. Loads of greats new features -- but let's talk about my very favorite one -- directly measuring how well Synchronous Precursor Selection (SPS) worked in your files where you used it!

After processing you've got your Peptide Spectrum(al) Match(es) so you know what (typically) b and y fragment ions truly came from your peptide of interest -- and, in your scan header, you've got the MS2 fragment windows that SPS used to acquire your ions for MS3 based quantification --

PD 2.3 integrates all this and can give you a metric of the percentage of the SPS fragments that the Fusion or Lumos decided to use that actually match the fragments that you used for your PSM! You can even set filters in your consensus where you throw out the quantification of any ions where the SPS didn't select the percentage of signal from ions that you decide is a good cutoff! REALLY concerned about that quantification accuracy? Then only keep ions where at least 90% of your quan signal came from fragments that were really your peptide!

We thought this feature was cool enough to pull a bunch of ProtoemeXchange files down and evaluate SPS accuracy. If you're bored, there is a bioRXIV preprint with more details here (and an unfortunate figure numbering glitch that is 100% my fault (I'm dumb, sleepy, and a bad writer)-- but this is what we found -- and it's mostly normal -- with a big surprise that's made me feel more deranged than usual the last few weeks:

1) Simple samples like yeast or prefractionated samples like offline fractionated and concatenated human lysates (as long as you do a good job with the fractionation) has high levels of SPS selection accuracy. Files like this also have low levels of MS1 --> MS2 coisolation interference, so that makes sense.
2) SPS works just as well if you're doing your MS3 based quan in the ion trap or Orbitrap (MS3 -TMT6 in the ion trap still seems like a better idea than MS3-TMT6 in the Orbitrap
3) Single shot human stuff --  does not work nearly as well. Too many times your MS2 window is a jumble of fragments from 2 or 3 different peptides originally selected from the MS1 together and SPS can't tell what your target is.

All normal stuff, right?

4) Suprise? Okay -- so -- honestly, I might just be stupid. For real. However, if you look at the MS2 coisolation interference that I consider a critical parameter when I'm doing MS2 based TMT quan and the SPS Accuracy, they don't directly correlate. Just because an ion has a friend that is right in it's retention time and m/z window and is using up it's MS/MS fragmentation window space -- like this one --

(w(inner) is the ion I want to quantify -- l(oser) is the one I don't care about. If you select any window around the w ion, you're going to get stuck with the a bunch of l fragments, right? A lot of people doing MS2 based TMT would exclude that peptide from quantification -- can't trust that value, right?

You'd think that would be an MS/MS event where SPS would do a bad job -- and -- as best as we can tell from the 5 or so sets we tested (3 are in the preprint) there is no direct correlation between the 2 variables.  Why? No idea.

What's important, though, is that we've got a new way to make sure the TMT/iTRAQ signal we're reporting for each peptide is as accurate as possible!!

If you're doing at least 12 fractions of human stuff with concatenation and solid preMS chromatography, using an SPS filter isn't going to change very much. If you're doing single shot ultra complex stuff, using an SPS filter is going to cost you a lot of quantified peptides -- but this is the first way I've EVER seen to pick through that data and only keep the good stuff! Go PD team, go!

Now that we know how to do this, it should be pretty easy (unless the idea is trademarked and stuff, definitely check that, in case) for other programs to integrate it. The values are right there in the scan header!