Some model objects which are written at top level to their own XML file. The most important examples are AbstractItem, Run, and User.
Sometimes various classes defined in Jenkins which are intended to be serialized via XStream will mistakenly declare a non-transient field referring back to the model object. If the class happens to be an action, property, etc. which is contained in that same model object, this will usually be harmless, as XStream will create a reference—though it will occasionally blow up in your face when using lazy loading of builds, since there are conditions under which a fresh copy of the model object will be written, which will typically be in some inconsistent state after deserialization since no onLoad method has been called on it. If the class is contained in something else, you will definitely get duplicated data, which can be rather bad.
Jenkins should if possible block you from accidentally storing a model object inside something else.