diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md
index cb7e754d..3ecc4b77 100644
--- a/hips/hip-00XX.md
+++ b/hips/hip-00XX.md
@@ -43,9 +43,9 @@ Helm will add a new flag to the install, upgrade and rollback sub-commands (mode
 
 `--server-side=false|true|auto`
 
-Helm will default to `false` for installs, retaining its existing CSA behavior.  And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release. With the usage of SSA for a given release being stored in the release's manifest. When enabled, Helm will submit object to the Kubernetes API server via SSA patches.
+Helm will default to `false` for installs, retaining its existing CSA behavior.  And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release. With the usage of SSA for a given release being stored in the release's metadata. When enabled, Helm will submit object to the Kubernetes API server via SSA patches.
 
-If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new manifest object will omit the indication of SSA usage from the releases manifest (and so further upgrades/rollbacks will continue to use CSA by default).
+If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new release's metadata will omit the indication of SSA usage (and so further upgrades/rollbacks will continue to use CSA by default).
 
 In a future version of Helm 3 cli, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA).
 
@@ -87,7 +87,7 @@ As such, while option 1. is probably the cleanest from an implementation and use
 
 ### Implementation
 
-Helm will send object manifests to the Kubernetes API server via SSA patches. Similar to `kubectl`, utilizing the field manager name `helm`:
+Helm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl`, utilizing the field manager name `helm`:
 https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248
 https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L602
 
@@ -96,7 +96,7 @@ https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2
 <!-- Describe potential impact and severity on pre-existing code. -->
 
 There are thought to be four main compatibility concerns for Helm switching to SSA:
-1. The differences between object manifests managed with SSA vs the existing three-way strategic merge process:
+1. The differences between object's manifests managed with SSA vs the existing three-way strategic merge process:
    - Arrays will be merged
    - Removal of unset fields
    - Default values