Questions regarding some of the MSP API models

For current automation work I've put together an openapi spec for the MSP API and wanted to clarify some potential inconsistencies or omitted values I've encountered with the following models:

Regarding the device model, when using the device endpoints the model has proven consistent. This however begins to deviate when using the alarm endpoints, which according to the alarm model should contain a Device instance (as it is directly referenced and links to the model). In practice however, the Device instance yielded by the alarm model contains the following additional items *not* reflected within the Device model:

• portInfo - This is a unique object containing a protocol and port
• port - This has been an array of port numbers
• deviceType - This has been a string machine descriptor

Similarly again with the flow endpoints, the model denotes the presence of a device object within. Referencing the device model, many fields are omitted that are otherwise not listed as optional, most significantly with the Firewall box itself. In this circumstance only the Device ID and the external IP address is present. Further more, the Device ID is inconsistent as the "There are 3 device types available for now" are not reflected. Neither specified prefixes (ovpn:, wg_peer:) nor the MAC address are present. Instead the field is populated by a new prefix 'if:' followed by a Flow Network ID which also contains two omitted values from the model:

• type - string of the interface descriptor (wan)
• gid - firewalla box id

Regarding the Target List endpoint, all requests always return a model with extra values not seemingly missing form the model:

• type - string that so far is always a list
• count - seemingly the number of items within a list
• beta - assuming this is for the curated beta lists
• blockMode - string that is so far always 'domainOnly', assuming this is enumerated I'd love to know what possible values

Most confusingly however, the model changes slightly when requested when specifying an owner. Under this circumstance yet another undocumented field appears:

• access - seems to indicate if the list is editable / user generated

Regarding the Trend model, no trend endpoint seemingly returns *just* the trend model, with each different trend type (alarm, flow, rule) containing additional data. Namely all three contain a count field, with the TrendFlow containing the additional following fields:

• Count
• Download
• Upload
• Total

I've been working off MSP v2.9.1 and have compared both the public MSP api documentation as well as my MSP instances hosted documentation for any documentation on the different values with none specified. 

I'm curious if these behaviors are expected, if these values are considered stable and should be left within my spec?

Thank you.