Suggestions to docs

docs/tutorials/integrations/kserve-mm/canary.md

@@ -96,7 +96,7 @@ cat grpc_input.json \
   inference.GRPCInferenceService.ModelInfer \
 | grep -e app-version
 ```
-4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the same model version.
+4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the primary version.
 ```shell
 cat grpc_input.json \
 | grpcurl -vv -plaintext -proto kserve.proto -d @ \

docs/tutorials/integrations/kserve/canary.md

@@ -90,7 +90,7 @@ http://wisdom.default -d @input.json -s -D - \
 | grep -e HTTP -e app-version
 ```
 
-4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the same model version.
+4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the primary version.
 ```shell
 curl -H 'Content-Type: application/json' \
 -H 'traffic: test' \

docs/tutorials/integrations/kubernetes-gateway-api/blue-green.md

@@ -25,10 +25,10 @@ This tutorial uses the Kubernetes Gateway API to allow the use any service mesh
 
 ## Deploy initial version
 
-Deploy the initial version of the application ([httpbin](https://httpbin.org/))using the Iter8 `release` chart by identifying the environment into which it should be deployed, a list of the versions to be deployed (only one here), and the rollout strategy to be used. Note that we deploy the application to the namespace `test`. 
+Deploy the initial version of the application ([httpbin](https://httpbin.org/)) using the Iter8 `release` chart by identifying the environment into which it should be deployed, a list of the versions to be deployed (only one here), and the rollout strategy to be used. Note that we deploy the application to the namespace `test`. 
 
-???+ note "About creating a namespace for linkerd deployments"
-    When creating a namespace, it should be annotated so that all created pods are injected with the linkerd proxy. This can be done, for example, by using the linkerd CLI:
+???+ note "About creating a namespace for Linkerd deployments"
+    When creating a namespace, it should be annotated so that all created pods are injected with the Linkerd proxy. This can be done, for example, by using the Linkerd CLI:
     ```shell
     kubectl create ns test --dry-run=client -o yaml | linkerd inject - | kubectl apply -f -
     ```

docs/tutorials/integrations/kubernetes-gateway-api/canary.md

@@ -25,10 +25,10 @@ This tutorial uses the Kubernetes Gateway API to allow the use any service mesh
 
 ## Deploy initial version
 
-Deploy the initial version of the application ([httpbin](https://httpbin.org/))using the Iter8 `release` chart by identifying the environment into which it should be deployed, a list of the versions to be deployed (only one here), and the rollout strategy to be used. Note that we deploy the application to the namespace `test`. 
+Deploy the initial version of the application ([httpbin](https://httpbin.org/)) using the Iter8 `release` chart by identifying the environment into which it should be deployed, a list of the versions to be deployed (only one here), and the rollout strategy to be used. Note that we deploy the application to the namespace `test`. 
 
-???+ note "About creating a namespace for linkerd deployments"
-    When creating a namespace, it should be annotated so that all created pods are injected with the linkerd proxy. This can be done, for example, by using the linkerd CLI:
+???+ note "About creating a namespace for Linkerd deployments"
+    When creating a namespace, it should be annotated so that all created pods are injected with the Linkerd proxy. This can be done, for example, by using the Linkerd CLI:
     ```shell
     kubectl create ns test --dry-run=client -o yaml | linkerd inject - | kubectl apply -f -
     ```
@@ -82,7 +82,7 @@ kubectl exec --stdin --tty "$(kubectl get pod --sort-by={metadata.creationTimest
 curl httpbin.test -s -D - | grep -e '^HTTP' -e app-version
 ```
 
-4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the same model version.
+4. Requests can also be sent with the header `traffic: test`. When a candidate is deployed, requests with this header will be routed to the candidate. When no candidate is deployed, all requests will be routed to the primary version.
 ```shell
 curl httpbin.test -H 'traffic: test' -s -D - | grep -e '^HTTP' -e app-version
 ```