Fix wording and punctuation in retention rules documentation

Author: jtaylor-cs

src/content/artifact-management/retention-rules.mdx

@@ -9,7 +9,7 @@ Cloudsmith Retention Rules automate artifact data management for a repository by
 - The number of days (time).
 - A [search query](/artifact-management/search-filter-sort-packages) to filter packages.
 
-Each repository has one configurable Retention Rule. This rule runs automatically when a new package is uploaded and synchronized; subsequently, it deletes any packages that do not meet the configured parameters.
+Each repository has one configurable Retention Rule. This rule runs automatically when a new package is uploaded and synchronized, subsequently deleting any packages that meet the configured parameters.
 
 Retention Rules can be configured for a repository either via the Cloudsmith Web App, the Cloudsmith API, or the Cloudsmith Terraform Provider.
 
@@ -41,12 +41,12 @@ From the Cloudsmith Web App UI, use the sliders to configure rule values, and th
 | Name | API | Description |
 |----------|----------|----------|
 | Enabled  | `retention_enabled`     | Enables/Disables a Retention Rule for a repository. A value of `true` enables the rule, and `false` disables it.    |      
-| Limit by Days  | `retention_days_limit`     | The number of days to retain packages. A cutoff date is calculated and packages with an upload date before this cutoff date are selected for deletion; packages uploaded on or after the cutoff are retained. Set to zero to remove this criteria from the rule.      |      
-| Limit by Count    | `retention_count_limit`     | The maximum number of packages to retain. Set to zero to remove this criteria from the rule.     |      
-| Limit by Size    | `retention_size_limit`     | The maximum total size (in bytes) of packages to retain. Set to zero to remove this criteria from the rule.     |      
-| Group Packages by Name |   `retention_group_by_name` | If enabled, retention will apply to groups of packages by name rather than all packages. For example, when `retention_count_limit` is defined as "1" and packages `PkgA 1.0`, `PkgB 1.0` and `PkgB 1.1` are identified as eligible for deletion; only `PkgB 1.0` is deleted because there are two (2) `PkgBs` and one (1) `PkgA`; this parameter is applied to each grouped package name.        |
+| Limit by Days  | `retention_days_limit`     | The number of days to retain packages. A cutoff date is calculated, and packages with an upload date before this cutoff date are selected for deletion; packages uploaded on or after the cutoff date are retained. Set to zero to remove this criterion from the rule.      |      
+| Limit by Count    | `retention_count_limit`     | The maximum number of packages to retain. Set to zero to remove this criterion from the rule.     |      
+| Limit by Size    | `retention_size_limit`     | The maximum total size (in bytes) of packages to retain. Set to zero to remove this criterion from the rule.     |      
+| Group Packages by Name |   `retention_group_by_name` | If enabled, retention will apply to groups of packages by name rather than all packages. For example, when `retention_count_limit` is defined as "1" and packages `PkgA 1.0`, `PkgB 1.0`, and `PkgB 1.1` are identified as eligible for deletion; only `PkgB 1.0` is deleted because there are (2) `PkgBs` and (1) `PkgA`; this parameter is applied to each grouped package name.        |
 | Group Packages by Format | `retention_group_by_format` | If enabled, retention will apply to packages by package formats rather than across all package formats. For example, when `retention_count_limit` is defined as "1" and packages `PkgA 1.0`(Python) and `PkgA 1.0`(Ruby) are identified as eligible for deletion; nothing is deleted because these packages are different formats and the rule must retain 1 for each grouped package format.         |
-| Group Packages by Type |  `retention_group_by_package_type` | If enabled, retention will apply to packages by package type (e.g. by binary, by source, etc.), rather than across all package types for one or more formats. For example, when retaining by a limit of 1 and packages `DebPackage 1.0` and `DebSourcePackage 1.0` are uploaded, no packages are deleted because they are different package types, binary and source respectively.         |    
+| Group Packages by Type |  `retention_group_by_package_type` | If enabled, retention will apply to packages by package type (e.g. by binary, by source, etc.), rather than across all package types for one or more formats. For example, when retaining by a limit of 1 and packages `DebPackage 1.0` and `DebSourcePackage 1.0` are uploaded, no packages are deleted because they are of different types: binary and source, respectively.         |    
 | Query String   |  `retention_package_query_string` | A package search expression. If provided, this expression further filters the packages to be deleted. For example, a search expression of `name:foo` will result in only packages called `foo` being eligible for deletion, or a search expression of `tag:~latest` will prevent any packages with the `latest` tag from being deleted. Refer to the Cloudsmith documentation for package query syntax.  |         
 
 ### Configuration Parameters via the Cloudsmith API
@@ -55,19 +55,19 @@ Visit [API reference](https://api.cloudsmith.io/swagger/) and search by `/repos/
 As a reference, use the `GET` method to retrieve an existing retention rule or the `PATCH` method to update it.
 
 ## When Do Retention Rules Get Evaluated?
-1. **Upload Trigger:** A Retention Rule is evaluated automatically whenever a new package is uploaded and completes synchronization. This is the ideal method for triggering a retention rule to ensure packages are evaluated and actioned as expected.
-2. **Resync Trigger:** A Retention Rule can also be triggered by resyncing the most recently uploaded package. When using this mechanism, review this documentation to understand how the cutoff date is calculated and how it affects package deletion.
+1. **Upload Trigger:** A Retention Rule is evaluated automatically whenever a new package is uploaded and completes synchronization. This is the ideal method for triggering a retention rule to ensure that packages are evaluated and acted upon as expected.
+2. **Resync Trigger:** A Retention Rule can also be triggered by resyncing the most recently uploaded package. When using this mechanism, review this documentation to understand how the cutoff date is calculated and its impact on package deletion.
 
 <Note variant="note" headline="Limit by Days: Cutoff Date Calculation">
 The cutoff date is calculated by subtracting the Limit by Days parameter value from the upload date of the newest package.
 
-Example: If today is June 10 and you upload a new package and the Limit by Days parameter is 4, the cutoff date would be June 6. Packages uploaded before June 6 would be deleted.
+Example: If today is June 10 and you upload a new package with the Limit by Days parameter set to 4, the cutoff date would be June 6. Packages uploaded before June 6 would be deleted.
 </Note>
 
 <Note variant="note" headline="Invoking an Evaluation Using the Resync Trigger">
-The Cloudsmith Package Resync feature does not alter the upload date of a package. The cutoff date is a relative calculation based on the upload date of the most recently uploaded package used to trigger the evaluation. If the most recently uploaded package is 1,000 days old, and the ***Limit by Days*** parameter is 90 (days), the cutoff date calculation will be based on the upload date of that 1,000-day-old package.
+The Cloudsmith Package Resync feature does not alter the upload date of a package. The cutoff date is calculated based on the upload date of the most recently uploaded package that triggered the evaluation. If the most recently uploaded package is 1,000 days old, and the **Limit by Days** parameter is 90 (days), the cutoff date calculation will be based on the upload date of this 1,000-day-old package.
 
-Example: 1,000 (uploaded date) subtracted by 90 (Limit by Days parameter) = 910 (cutoff date). Packages 911 days old and older would be deleted. Additionally, the 1,000 day old package used to trigger the evaluation would not be deleted, as it is not eligible for deletion. To effectively delete this 1,000-day-old package, upload a new package to trigger a new evaluation based on the new package's upload date.
+Example: 1,000 (uploaded date) subtracted by 90 (Limit by Days parameter) = 910 (cutoff date). Packages 911 days old and older would be deleted. Additionally, the 1,000-day-old package used to trigger the evaluation would not be deleted, as it is not eligible for deletion. To effectively delete this 1,000-day-old package, upload a new package to trigger a new evaluation based on the new package's upload date.
 </Note>
 
 ## Other Considerations
@@ -76,23 +76,23 @@ When multiple parameters of a retention rule are enabled, a package that meets a
 ### Understanding Groupings
 Enable grouping(s) to filter packages into groups based on specified criteria before applying retention rules. 
 
-For example, if “Group Packages by Name” is selected, retention will apply to groups of packages by name rather than all packages. For example, when retaining by a count limit of 1 and packages `PkgA 1.0`, `PkgB 1.0` and `PkgB 1.1` are uploaded; only `PkgB 1.0` is deleted because there are two (2) `PkgBs` and one (1) `PkgA`. Or, If “Group Packages by Format” is selected, retention will apply to packages within package types rather than across all package formats. For example, when retaining by a limit of 1 and packages `PythonPkg 1.0` and `RubyPkg 1.0` are uploaded, no packages are deleted because they are different formats.
+For example, if “Group Packages by Name” is selected, retention will apply to groups of packages by name rather than all packages. For example, when retaining by a count limit of 1 and packages `PkgA 1.0`, `PkgB 1.0`, and `PkgB 1.1` are uploaded; only `PkgB 1.0` is deleted because there are two (2) `PkgBs` and one (1) `PkgA`. Or, if “Group Packages by Format” is selected, retention will apply to packages within package types rather than across all package formats. For example, when retaining by a limit of 1 and packages `PythonPkg 1.0` and `RubyPkg 1.0` are uploaded, no packages are deleted because they are different formats.
 
 ### Understanding the Sequence of an Evaluation
 1. **Initial Query Set is Created** - All successfully synced packages within the repository are identified.
-2. **Grouping is Applied to the Initial Query Set** - The initial query set of all packages is grouped by format, grouped by name, grouped by type based on the enabled parameters specified in the retention rule. To be clear, if all (3) grouping parameters are enabled, this will result in (3) separate query sets.
+2. **Grouping is Applied to the Initial Query Set** - The initial query set of all packages is grouped by format, grouped by name, and grouped by type based on the enabled parameters specified in the retention rule. To be clear, if all 3 grouping parameters are enabled, this will result in 3 separate query sets.
 3. **Package Query String is Applied to Query Set** - The query string filters the packages of each existing query set. Again, if multiple grouping parameters are enabled, the query string is applied to each query set separately.
-4. **Query Set is Ordered by Package Upload Date** - Any query set(s) gets sorted based on the upload date of the packages, newest to oldest and excluding the newest package used to trigger the evaluation.
+4. **Query Set is Ordered by Package Upload Date** - Any query set(s) gets sorted based on the upload date of the packages, newest to oldest, and excluding the newest package used to trigger the evaluation.
 5. **Limit by Count is Applied** - The number of packages to keep is determined according to the Limit by Count parameter. Packages exceeding this limit are deleted from the query set.
 6. **Limit by Days is Applied** - The number of days to keep packages is determined according to the Limit by Days parameter. Packages older than the calculated cutoff date are deleted from the query set.
-7. **Limit by Size is Applied** - The total size of packages to keep is determined according to the Limit by Size parameter. The latest query set is reordered by semantic version value and packages are deleted from the oldest semantic version to newest until the total size of remaining packages is under the defined parameter.
+7. **Limit by Size is Applied** - The total size of packages to keep is determined according to the Limit by Size parameter. The latest query set is reordered by semantic version value, and packages are deleted from the oldest semantic version to the newest until the total size of remaining packages is under the defined parameter.
 
 <Note variant="note">
 The Package Query String Parameter is an excellent way to further filter packages before applying retention rules. The Cloudsmith Web App UI repository Filter function can be used to refine a query string to a desired set of packages and visualize the results.
 </Note>
 
 ### Limiting the Number of Packages to Delete
-The **Limit by count** option defines the number of packages to keep. For example, if we set its value to `4` and only a total of `3` packages meet the criteria, then `0` packages will be deleted. But if `5` packages meet the criteria, then `1` will be deleted and `4` will be keep in the repository.
+The **Limit by count** option defines the number of packages to keep. For example, if we set its value to `4` and only a total of `3` packages meet the criteria, then `0` packages will be deleted. But if `5` packages meet the criteria, then `1` will be deleted and `4` will be kept in the repository.
 
 This value applies per group. So, the maximum total number of packages to keep will always be the result of `retention_count_limit` multiplied by the number of groups.
 
@@ -106,16 +106,16 @@ The **Limit by Size** option defines the total size of packages to keep. For exa
 ### Example 1
 Delete packages older than 100 days.
 
-To configure a retention rule in the UI that removes all packages older than 100 days, configure the next values:
+To configure a retention rule in the UI that removes all packages older than 100 days, configure the following values:
 
 - "Limit By Days" = 100
 - "Limit By Count" = 0 
 - "Limit By Size" = 0.0B (disabled)
 
-By disabling count and size, it means it only uses the package age to delete.
+Disabling count and size means it only uses the package age to delete.
 
 ### Example 2
-Delete all packages that are more than 30 days old and do not have any tag.
+Delete all packages that are more than 30 days old and do not have any tags.
 
 ```shell
 curl --request PATCH \
@@ -131,7 +131,7 @@ curl --request PATCH \
 ```
 
 ### Example 3
-Delete all packages that are more than 60 days old and have less than 10 downloads. 
+Delete all packages that are more than 60 days old and have fewer than 10 downloads. 
 
 ```shell
 curl --request PATCH \
@@ -147,7 +147,7 @@ curl --request PATCH \
 ```
 
 ### Example 4
-Keep only 5 packages per format (python, docker, helm, etc.), that are not older than 100 days, are not tagged with `production`, have been downloaded less than 10 times and are violating some policies.
+Keep only 5 packages per format (Python, Docker, Helm, etc.) that are not older than 100 days, are not tagged with `production`, have been downloaded fewer than 10 times, and are violating some policies.
 
 ```shell
 curl --request PATCH \