In the Upgradeability Dashboard, the "OOTB changes updated in future upgrades" grid shows all modified Out of the Box elements in the instance which will be affected by a future upgrade of the instance.
ServiceNow defines an upgrade as:
"Moving a customer's instance from one release family to another. For example, moving from Jakarta to Kingston."
The list of standard definitions, which is available on this HI link, is also copied below for reference.
In the Upgradeability Dashboard, the patch and hotfix number on the "From" version on any release family (London, Madrid, etc) is always the last available one at the time at which the early access version of the new family release was made available. For instance, for London to Madrid this is patch 4, hotfix 2.
The patch and hotfix number on the "To" version in this grid is updated as patches are released for that release family. So, to continue with the example above, any records which were originally flagged as "Madrid Early Access" will have their "To version" attribute modified to "Madrid patch 1" once that patch is released. This is because upgrading directly to patch 1 has the same effect as upgrading to the early access version, and then to patch 1.
If you are upgrading from a patch released after the early access availability of the next release family, you can still use the list of OOTB modifications affected by future upgrades. Because of the cumulative nature of upgrade and patch changes, if you upgrade from London patch 7 to Madrid patch 1, any changes in London patches 4 to 7 will be included in the reference list of changes which Quality Clouds builds up after the upgrade to Madrid patch 1. This means that if any out of the box modifications which are present in your instance will be affected by the upgrade to Madrid patch 1 it will be reported by Quality Clouds, regardless of the upgrade path which took you to the final version.
A complete solution including new capabilities that customers can implement to add value to their organization. The release family also incorporates available fixes to existing functionality.
Supports existing functionality within the release family with a collection of problem fixes and generally does not include new features.
Supports existing functionality within the release family with specific security fixes. These fixes are incrementally added to the patch version. For example, Kingston Patch 6a is a security patch that contains security fixes added to Kingston Patch 6. Similarly, Kingston Patch 6b contains the fixes in Kingston Patch 6a plus the new ones in Kingston Patch 6b. There are usually less than five fixes per security patch, but we reserve the right to include more fixes as required.
Supports existing functionality within the release family with a targeted, specific problem fix. It may or may not include any previous fixes within the release family. It does not include new capabilities. For example, Kingston Patch 1 Hotfix 2 is part of the Kingston family.
The specific level within each release family, e.g. Kingston Patch 5 is a patch version of Kingston. Patch versions are cumulative within a release family, i.e. Kingston Patch 5 contains all of the fixes in Kingston Patch 4 plus the additional fixes in Kingston Patch 5.
The minimum version required to be installed for each supported release family.
Moving a customer's instance from one release family to another. For example, moving from Jakarta to Kingston.
Patching (also known as Updates)
Moving from one patch level to another within a release family. For example, moving from Kingston Patch 2 to Kingston Patch 4.