I stumbled over this spectrum and noticed the fragment m/z's compared to the parent-ion-mz (423.5989 and 782.2591 vs 147.0441). If the validator could reveal fragments which are too heavy, than we would at least be aware of that.

I have no idea for the proper procedure, especially in this case, because its experimental data, not meta data. I wouldn't touch it. One could flag it or raise an issue with the original contributor, but sometimes this will be complicated.

Check CH$NAME for

• duplicated names
• InChIKeys, i.e. "^[A-Z]{14,14}-[A-Z]{10,10}-[A-Z]{1,1}"
• typical database IDs, i.e. ChEBI, PubChem CID, ...

In light of issues found/raised by Herbert Oberacher recently, I see a couple of new ideas we should consider implementing in the validator:

• do a spectral search of new entries and flag records if extremely high similarity is show to a record with a different compound annotation. To discuss: to do this globally or introduce different warnings? If the compound annotation is clearly completely different (radically different precursor mass etc), this should be an error or high level warning; but we will get many cases where they are isobars or substances that may validly have very similar spectra as they are closely related. Note: this will only catch errors for substances that are already on the public record, but it's a start. Contributor should be prompted to check records.
• We should flag all Orbitrap spectra that have a base peak of absolute intensity below 10,000. These are highly likely noise only. Contributor should check and decide whether to deprecate?
• Orbitrap records where one peak is just above 10,000 but all others below are also likely just noise
• To discuss in more detail: how to catch and deprecate poor quality records where we now have better records? Similarity is challenging to use alone as we can have poor similarity because of different settings ...

• also check for the presence of possible interfering precursor masses in the peak list, e.g. around the isolation width of 1, using MS$FOCUSED_ION: PRECURSOR_M/Z entry

Please check whether all fragment-m/z in the PK$ANNOTATION section are present in the PK$PEAK section

Good idea, I suggest to build in a slight tolerance to avoid decimal place issues. I wouldn't check on the reverse, i.e. there may be fewer PK$ANNOTATION entries than PK$PEAK but there should not be more PK$ANNOTATION entries than PK$PEAK (unless anyone puts out multiple annotations for a given PK$PEAK, I am not aware of this case ... RMassBank only puts out one formula per peak and tags if more were possible ...

unless anyone puts out multiple annotations for a given PK$PEAK, I am not aware of this case ...

• I am not 100% certain that we don't have cases like this from RMassBank - the s4power branch is certainly able to produce such records if you tell it to.
• I personally don't think a record should be invalid if multiple annotations are present for a peak. Note that the annotation field is loosely defined in what it is allowed to contain, so this is certainly legal and possibly also welcome in some cases...

Agree with @meowcat - in principle no problem with having multiple annotations for one peak