Improve documentation related to the remodelling process.

docs/explanation/core-elements/snaps-in-ubuntu-core.md

@@ -28,7 +28,7 @@ The snap packaging ecosystem consists of the following parts:
 Developers can publish snaps to the Snap Store or to their own private Brand Store. They take sole responsibility for update cadence and quality. While snaps are commonly known as an application packaging format, Ubuntu Core is built from several different types of snap:
 
 1. **kernel**: Contains the Linux kernel for a device</br>
-The [kernel snap](https://snapcraft.io/docs/kernel-snap) is selected with the [model assertion](/reference/assertions/model) describing the device which is produced and signed before the image is built. Once the image is built, the kernel snap may be updated but cannot be replaced by a completely different kernel snap.
+The [kernel snap](https://snapcraft.io/docs/kernel-snap) is selected with the [model assertion](/reference/assertions/model) describing the device which is produced and signed before the image is built. Once the image is built, the kernel snap may be updated at any time. Note that the only way to change to a different kernel snap (i.e. different name/ID) is to [remodel](/explanation/remodelling).
 1. **gadget**: Defines device properties</br>
 The [gadget snap](/reference/gadget-snap-format) is responsible for defining and manipulating the system properties and configuration which are specific to one or more devices that will usually look similar to one another from an implementation perspective. It is also responsible for shipping the device bootloader and bootloader assets. It is selected with the [model assertion](/reference/assertions/model).
 1. **base**: The runtime environment</br>

docs/explanation/remodelling.md

@@ -8,14 +8,26 @@ The model assertion contains:
 * Identification information, such as brand account id and model name.
 * Which essential snaps make up the device system, including the gadget snap, kernel snap and the boot base snap with the root filesystem.
 * Other required or optional snaps that implement the device functionality.
-* Additional options for the defined device, such as grade.
+* Additional options for the defined device, such as grade, and the store it is connected to.
 
-When one or more of the above elements change, the updated model assertion and its associated image are deployed to the device, authenticated and linked through its serial assertion, to the store. This process is called remodelling.
+The snaps declared in the model assertion can be [updated](/explanation/refresh-control) during the device lifecycle. However, when the system must be [upgraded](/how-to-guides/manage-ubuntu-core/upgrade-ubuntu-core.md), or when one or more of the above elements change, a new model assertion can be deployed to the device. The updated model assertion is authenticated and linked through its serial assertion to the store. The image is upgraded based on the delta compared to the previous model. This process is called remodelling.
 
-One example of remodelling is [Upgrading Ubuntu Core](/how-to-guides/manage-ubuntu-core/upgrade-ubuntu-core.md).
 ## Remodelling viability
 
-The remodelling process is triggered by either updating the model assertion, running the `snap remodel` command, or from the [snapd the REST API](https://snapcraft.io/docs/snapd-api) (the last two require _snapd 2.61_ or later). Remodelling triggers the generation of a new recovery system, which means care needs to be taken to ensure the [ubuntu-seed](/explanation/core-elements/storage-layout.md#the-ubuntu-seed-partition) partition is sized accordingly.
+The remodelling process (requires _snapd 2.61_ or later) is triggered by either via the [snapd's REST API](https://snapcraft.io/docs/snapd-api), or running the following command on the device.
+
+```bash
+sudo snap remodel <new-model.assert>
+```
+
+Both methods need an updated [model assertion](/reference/assertions/model) as input. Its `revision` field must be incremented, and it must be signed using a key registered to the same brand that signed the original model. If it differs from the key used to sign the original model, an account-key assertion must be registered on the device before proceeding with the remodelling.
+
+```bash
+snap known account-key --remote public-key-sha3-384=<digest> > key.assert
+snap ack key.assert
+```
+
+Remodelling triggers the generation of a new recovery system, which means care needs to be taken to ensure the [ubuntu-seed](/explanation/core-elements/storage-layout.md#the-ubuntu-seed-partition) partition is sized accordingly. The process also ensures the newly created recovery system is valid. Therefore, the previous recovery system can be safely removed after remodelling has completed. An [API call](/how-to-guides/manage-ubuntu-core/create-a-recovery-system-from-the-api.md/#removing-api-usage) is available to perform this removal.
 
 Remodelling is the responsibility of the snap daemon (_snapd_) running on the device. It both mediates the update process and the re-registration of the device after the update (if required). But the complexity and viability of the remodelling process is dependent on several factors outside of snapd’s control.
 
@@ -42,6 +54,28 @@ The below permutations of the remodelling contexts are all valid:
 
 If a [validation set](https://snapcraft.io/docs/validation-sets) has been defined for the old model and the new model, or just the new model, the snaps installed during the remodelling process must follow the validation set rules.
 
+To ensure the remodelling process completes successfully when a device's model name changes, a specific configuration is required in the [Serial Vault](https://canonical-serial-vault.readthedocs-hosted.com/serial-vault/register-a-new-device-model-name/), under the `Sub-Store Models` tab, to specify the allowed migration path from the old to new model name.
+
+### Gadget snap
+
+In the new model definition, the gadget snap can be kept identical to the previous model, or modified with any combination of the following items:
+
+* modification of the gadget snap name and associated ID
+* modification of the channel
+
+If the [model base](/reference/assertions/model.md/#model-assertion-fields) changes, the gadget snap must be modified, and its base must match that of the new model.
+The gadget's default settings are not applied when remodelling, these are used only when the device is [(re)installed](/explanation/recovery-modes.md/#install-mode). See [gadget snap](/reference/gadget-snap-format.md/#the-gadget-yaml-file) for further information.
+
+### Kernel snap
+
+The kernel snap can also be kept as-is, or modified with any combination of the following items:
+
+* modification of the kernel snap name and associated ID
+* modification of the channel
+
+The build-base of the new kernel snap should be aligned with the base defined in the updated [model assertion](/reference/assertions/model).
+Ubuntu Core only supports kernel snaps built from LTS releases. Refer to [Release Notes](/reference/release-notes.md/#release-policy-and-schedule) for details on Ubuntu Core versioning.
+
 ## Snap removal
 
 The remodelling process does not automatically remove snaps which are no longer marked as `required` or `optional` in the new model assertion. Those snaps stay in the system and keep receiving updates, but since they are no longer required by the model, it is possible to remove them.

docs/how-to-guides/manage-ubuntu-core/create-a-recovery-system-from-the-api.md

@@ -79,7 +79,7 @@ In this example, “validation-set.assert”, “pc.assert”, “pc-kernel.asse
 
 Recovery systems can be removed by using the remove API. Note that the “current” system, the default recovery system, and the last recovery system cannot be removed.
 
-Example POST to /v2/system/<label>:
+Example POST to /v2/system/\<label\>:
 
 ```json
 {

docs/reference/gadget-snap-format.md

@@ -62,7 +62,7 @@ Two YAML keys are used to describe your target device:
 ```{admonition} Defaults only become available during snap installation.
 :class: warning
 
-Values in `defaults:` (other than `system:`) are not consumed and do not become available until either the [configure hook](https://snapcraft.io/docs/supported-snap-hooks#heading--the-configure-hook) or the [default-configure hook](https://snapcraft.io/docs/supported-snap-hooks#heading--default-configure) are run as part of the corresponding snap installation. `system:` values are set immediately.
+Values in `defaults:` (other than `system:`) are not consumed and do not become available until either the [configure hook](https://snapcraft.io/docs/supported-snap-hooks#heading--the-configure-hook) or the [default-configure hook](https://snapcraft.io/docs/supported-snap-hooks#heading--default-configure) are run as part of the corresponding snap installation. `system:` values are set immediately. These values are only applied during the first boot, and will be ignored in case of a gadget snap refresh or a remodel operation.
 ```
 
 - **volumes** (YAML sub-section, required): the volumes layout, where each disk image is represented as a YAML sub-section.

docs/reference/release-notes.md

@@ -12,11 +12,33 @@ This page outlines the release notes of Ubuntu Core, summarising new features, b
 
 ## Release policy and schedule
 
-A new version of Ubuntu Core is released every two years, and each release is considered an LTS release. Minor updates are delivered continuously through new versions of snapd.
+A new version of Ubuntu Core is released every two years, built on the foundations of a Ubuntu LTS release. Each Ubuntu Core release is considered an LTS release. Minor updates are delivered continuously through new versions of snapd, and other [essential snaps](/explanation/core-elements/snaps-in-ubuntu-core) composing the system (gadget, base and kernel snaps).
 
-To upgrade an Ubuntu Core image from one version to another, see [Upgrade Ubuntu Core](/how-to-guides/manage-ubuntu-core/upgrade-ubuntu-core.md).
+A [base](/explanation/core-elements/snaps-in-ubuntu-core.md/#types-of-snap) snap is released with each Ubuntu Core version, named `core<version>`. This base snap is used to build Ubuntu Core images for a particular version, as specified in the [model assertion](/reference/assertions/model). The gadget and kernel snap's tracks are aligned with that of the base snap. Supported kernel tracks for a given Ubuntu Core release should follow this pattern: `<version>[-<suffix>]`.
 
-When Ubuntu Core is running, its snap packages update automatically. To manually control or modify this process, see [Refresh control](/explanation/refresh-control).
+For example, when building an Ubuntu Core 24 image, the model uses the `core24` base snap. A kernel snap, in general from the `stable` risk-level, should be picked from the following options:
+
+```{terminal}
+   :input: snap info pc-kernel | grep "^ *24[/|-]" | grep stable
+   :user: ubuntu
+   :host: machine-amd64
+
+snap info pc-kernel | grep "^ *24[/|-]" | grep stable
+  24-rt-hwe-edge/stable:    6.14.0-1010.10~24.04.1      2025-08-14 (2736) 377MB -
+  24-rt-hwe/stable:         6.14.0-1010.10~24.04.1      2025-08-14 (2736) 377MB -
+  24-rt/stable:             6.8.1-1030.31               2025-08-18 (2760) 360MB -
+  24-hwe-edge/stable:       --
+  24-hwe/stable:            6.14.0-28.28~24.04.1        2025-08-18 (2674) 372MB -
+  24/stable:                6.8.0-64.67                 2025-08-20 (2575) 319MB -
+```
+
+Other [risks levels](https://snapcraft.io/docs/channels) are available for testing. However, kernel snaps based on interim (non-LTS) releases are not supported in Ubuntu Core images.
+
+## Update mechanisms in Ubuntu Core
+
+When Ubuntu Core is running, its snap packages update (aka refresh) automatically. To manually control or modify this process, see [Refresh control](/explanation/refresh-control). Essential snaps, such as the base and kernel snaps, can be refreshed assuming the updated version is built from the same build-base used in the original model definition. When refreshing the base or kernel snaps, the system will automatically reboot to apply the freshly installed snap. When refreshing the gadget snap, a reboot occurs if the [boot-assets](https://snapcraft.io/docs/gadget-boot-assets) are modified.
+
+To upgrade an Ubuntu Core image from one version to another, see [Upgrade Ubuntu Core](/how-to-guides/manage-ubuntu-core/upgrade-ubuntu-core.md). This process is known as [remodelling](/explanation/remodelling).
 
 The snap daemon, snapd, manages snap package updates and Ubuntu Core functionality. For the snapd release plan and a complete list of changes, please refer to the [snapd roadmap](https://snapcraft.io/docs/snapd-roadmap). Feel free to provide your test feedback on the [forum](https://forum.snapcraft.io/c/snapd/5), or directly in [Launchpad](https://bugs.launchpad.net/snapd/+filebug).