diff --git a/content/architecture/long-term-reproducibility.md b/content/architecture/long-term-reproducibility.md
index 8281bace7fea2a15b5b573bf5eec4fbe5aac7540..9105fd6c7e600d646355399b6f9bf1a889d4ec78 100644
--- a/content/architecture/long-term-reproducibility.md
+++ b/content/architecture/long-term-reproducibility.md
@@ -137,7 +137,7 @@ but not exactly the original one gives acceptable results.
 To further make build environments more reproducible, care can be taken to
 make their own build process as reproducible as possible.
 The same concerns affecting the main build recipes affect the recipes for the
-Docker images, from storing pipelines in git, to relying only on snapshotted
+Docker images, from storing pipelines in git, to relying only on snapshots of
 package archives, to taking extra care on third-party downloads, and the
 following sections address those concerns for both the build environments
 and the main build process.
@@ -216,12 +216,12 @@ While the stability of the release channels is suitable for most use-cases,
 sometimes it is desirable to reproduce an old build as close to the
 original as possible, ignoring any update regardless of their importance.
 
-To accomplish that goal the package archives are snapshotted regularly,
-storing their full history. The image build pipeline accepts an optional
-parameter to use a specific snapshot rather than the latest contents.
-This results in the execution installing exactly the same packages and
-versions as the original run, regardless of any changes that landed in the
-archive in the meantime.
+To accomplish that goal snapshots of the package archives are created
+regularly, storing their full history. The image build pipeline accepts an
+optional parameter to use a specific snapshot rather than the latest contents.
+This results in the execution installing exactly the same packages and versions
+as the original run, regardless of any changes that landed in the archive in
+the meantime.
 
 To use a snapshot it is sufficient to change the APT mirror address, for
 instance going from `https://repositories.apertis.org/apertis/` to
@@ -314,7 +314,7 @@ latest package versions for each channel.
 
 Since the purposes taken in account in this document do not involve large scale
 package rebuilds, it is recommended to use the SDK images and the devroots in
-combination with the snapshotted APT archives to rebuild packages in an
+combination with APT archives snapshots to rebuild packages in an
 environment closely matching a past build.
 
 # Recommendations for product teams
@@ -357,7 +357,7 @@ contents available from the package archive.
 
 The most common approach, also employed in Debian upstream, is to take
 snapshots of the archive contents so that subsequent builds can point to the
-snapshotted version and retrieve the exact package versions originally used.
+snapshot and retrieve the exact package versions originally used.
 
 To provide the needed server-side support, the archive manager need to be
 switched to the `aptly` archive manager as it provides explicit support for
@@ -484,7 +484,7 @@ In this way the product team has complete control on the components used to
 build their products:
 * Source code for all packages is stored on GitLab with full development
   history
-* Compiled binary packages are tracked by the APT archive snapshotting system
+* Compiled binary packages are tracked by snapshots of the APT archive system
   for both the product-specific packages and the packages in the main Apertis
   archive.