diff --git a/content/patterns/rhoso-gitops/_index.adoc b/content/patterns/rhoso-gitops/_index.adoc
index 277ab6bfe..9817e8e08 100644
--- a/content/patterns/rhoso-gitops/_index.adoc
+++ b/content/patterns/rhoso-gitops/_index.adoc
@@ -2,7 +2,7 @@
 title: RHOSO GitOps
 date: 2026-06-15
 tier: sandbox
-summary: Deploy Red Hat OpenStack Services on OpenShift using GitOps via the rhoso-gitops meta-chart.
+summary: Deploy Red Hat OpenStack Services on OpenShift using GitOps through the rhoso-gitops meta-chart.
 rh_products:
   - Red Hat OpenShift Container Platform
   - Red Hat OpenShift GitOps
diff --git a/content/patterns/rhoso-gitops/cluster-sizing.adoc b/content/patterns/rhoso-gitops/cluster-sizing.adoc
index f68812e24..fe3e9ac0b 100644
--- a/content/patterns/rhoso-gitops/cluster-sizing.adoc
+++ b/content/patterns/rhoso-gitops/cluster-sizing.adoc
@@ -15,15 +15,16 @@ include::modules/cluster-sizing-template.adoc[]
 [id="rhoso-gitops-dataplane-hosts"]
 == Data plane host requirements
 
-The hub cluster sizing tables above cover the {rh-ocp} nodes that host the
-{rh-rhoso-short} control plane. A full {rh-rhoso-short} deployment also
+The preceding hub cluster sizing tables cover the {rh-ocp} nodes that host the
+{rh-rhoso-short} control plane.
+A full {rh-rhoso-short} deployment also
 requires separate {rhel-short} hosts for the data plane (compute nodes running
-dataplane elements).
+data plane elements).
 
 Plan additional {rhel-short} capacity beyond the OpenShift worker sizing in
-`pattern-metadata.yaml`. Operator stages, sync order, and version pins are
-documented in the pattern repository
-link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
+`pattern-metadata.yaml`.
+For Operator stages, sync order, and version pins, see
+the pattern repository link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
 file.
 
 [id="next-steps_rhoso-gitops-cluster-sizing"]
diff --git a/content/patterns/rhoso-gitops/configuration.adoc b/content/patterns/rhoso-gitops/configuration.adoc
index b4b54445a..e24d606fd 100644
--- a/content/patterns/rhoso-gitops/configuration.adoc
+++ b/content/patterns/rhoso-gitops/configuration.adoc
@@ -15,4 +15,4 @@ include::modules/rhoso-gitops/rhoso-gitops-configuration.adoc[leveloffset=+1]
 == Next steps
 
 * link:../getting-started/[Deploy the pattern]
-* link:../troubleshooting/[Troubleshooting]
+* link:../troubleshooting/[Troubleshoot the pattern]
diff --git a/content/patterns/rhoso-gitops/getting-started.adoc b/content/patterns/rhoso-gitops/getting-started.adoc
index 31f5bb66c..9e27f0fa3 100644
--- a/content/patterns/rhoso-gitops/getting-started.adoc
+++ b/content/patterns/rhoso-gitops/getting-started.adoc
@@ -16,4 +16,4 @@ include::modules/rhoso-gitops/rhoso-gitops-deploying.adoc[leveloffset=+1]
 
 * link:../configuration/[Configure the pattern]
 * link:../cluster-sizing/[Review cluster sizing]
-* link:../troubleshooting/[Troubleshooting]
+* link:../troubleshooting/[Troubleshoot the pattern]
diff --git a/content/patterns/rhoso-gitops/troubleshooting.adoc b/content/patterns/rhoso-gitops/troubleshooting.adoc
index c32b53fb3..6789b2106 100644
--- a/content/patterns/rhoso-gitops/troubleshooting.adoc
+++ b/content/patterns/rhoso-gitops/troubleshooting.adoc
@@ -12,34 +12,59 @@ include::modules/comm-attributes.adoc[]
 [id="troubleshooting-rhoso-gitops"]
 = Troubleshooting the {rhoso-gitops-pattern}
 
+Use these procedures to validate the pattern, inspect Argo CD application and
+pod status, and review known issues for the {rhoso-gitops-pattern}.
+
 [id="rhoso-gitops-validate-pattern"]
 == Validating the pattern
 
-Run pattern validation commands from the pattern repository root:
+Run the following pattern validation commands from the pattern repository root:
 
+. Validate prerequisites:
++
 [source,terminal]
 ----
 $ ./pattern.sh make validate-prereq
+----
+
+. Validate the schema:
++
+[source,terminal]
+----
 $ ./pattern.sh make validate-schema
+----
+
+. Check Argo CD health:
++
+[source,terminal]
+----
 $ ./pattern.sh make argo-healthcheck
 ----
 
 [id="rhoso-gitops-check-argocd"]
 == Checking Argo CD application status
 
-The pattern uses two Argo CD namespaces. List applications in each:
+The pattern uses two Argo CD namespaces. List applications in each namespace:
 
+. List applications in `vp-gitops`:
++
 [source,terminal]
 ----
 $ oc get applications -n vp-gitops
-$ oc get applications -n openshift-gitops
 ----
 
-Inspect a child application that is out of sync or unhealthy:
+. List applications in `openshift-gitops`:
++
+[source,terminal]
+----
+$ oc get applications -n openshift-gitops
+----
 
+. Inspect a child application that is out of sync or unhealthy:
++
 [source,terminal]
 ----
-$ oc describe application <application-name> -n openshift-gitops
+$ oc describe application <application_name> -n openshift-gitops
 ----
 
 Use the Argo CD UI in the `openshift-gitops` namespace to review sync waves,
@@ -60,23 +85,25 @@ Review logs for a specific pod:
 
 [source,terminal]
 ----
-$ oc logs -n <namespace> <pod-name>
+$ oc logs -n <namespace> <pod_name>
 ----
 
 [id="rhoso-gitops-known-issues"]
 == Known issues
 
-* *`openstack-secrets` disabled* — The default pattern leaves
-  `openstack-secrets` disabled because no Git path is configured (`path: TODO`).
+The following known issues can affect pattern deployment:
+
+* *`openstack-secrets` disabled*: The default pattern leaves
+  `openstack-secrets` disabled because no Git path exists (`path: TODO`).
   Enable it only after you configure secret wiring and a bootstrap credential
   out of band. See link:../configuration/#rhoso-gitops-secret-zero[Secret zero
   (bootstrap credential)].
-* *Upstream sync failures* — Confirm `targetRevision` and paths in
+* *Upstream sync failures*: Confirm that `targetRevision` and paths in
   `overrides/values-rhoso-gitops.yaml` match a tag or branch that exists in
   link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops].
-* *Operator install delays* — Infrastructure operators in `operator-dependencies`
-  subscribe from the cluster catalog; allow time for OLM to resolve CSVs before
-  later sync waves run.
+* *Operator install delays*: Infrastructure Operators in `operator-dependencies`
+  subscribe from the cluster catalog; allow time for OLM to resolve
+  `ClusterServiceVersions` (CSVs) before later sync waves run.
 
 For community support, open an issue in the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].
@@ -84,5 +111,5 @@ link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern re
 [id="next-steps_rhoso-gitops-troubleshooting"]
 == Next steps
 
-* link:../getting-started/[Getting started]
-* link:../configuration/[Configuration]
+* link:../getting-started/[Deploy the pattern]
+* link:../configuration/[Configure the pattern]
diff --git a/modules/rhoso-gitops/rhoso-gitops-about.adoc b/modules/rhoso-gitops/rhoso-gitops-about.adoc
index 29fcb8367..8aadf3c77 100644
--- a/modules/rhoso-gitops/rhoso-gitops-about.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-about.adoc
@@ -4,22 +4,19 @@
 [id="about-rhoso-gitops-pattern"]
 = About the {rhoso-gitops-pattern}
 
-Deploying {rh-rhoso} spans operators, networking, and control-plane and data-plane
-resources. Teams that rely on imperative scripts or manual cluster changes face
-slow rollouts, configuration drift, and weak audit trails when the stack must be
-upgraded or reproduced.
+Deploying {rh-rhoso} spans Operators, networking, and control-plane and data-plane resources.
+Teams that rely on imperative scripts or manual cluster changes face
+slow rollouts, configuration drift, and weak audit trails when you upgrade or
+reproduce the stack.
 
-The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public
-Git through Argo CD: manifests stay declarative and version-controlled, and the
-cluster is reconciled to match what is declared in the repository.
+The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public Git through Argo CD: manifests stay declarative and version-controlled, and Argo CD reconciles the cluster to match what the repository declares.
 
 [id="rhoso-gitops-pattern-goals"]
 == Pattern goals
 
 The {rhoso-gitops-pattern} aims to:
 
-* Install the *rhoso-gitops* meta-chart through the Validated Patterns
-  clustergroup and {gitops-title} operator
+* Install the *rhoso-gitops* meta-chart through the {solution-name-upstream} clustergroup and {gitops-title} Operator
 * Create child Argo CD Applications that sync {rh-rhoso-short} stages from upstream
   link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops]
   (`example/*` Kustomize overlays)
@@ -29,6 +26,8 @@ The {rhoso-gitops-pattern} aims to:
 [id="rhoso-gitops-red-hat-technologies"]
 == Red Hat technologies
 
+The {rhoso-gitops-pattern} uses the following Red Hat products:
+
 * {rh-ocp}
 * {gitops-title}
 * {rh-rhoso}
@@ -36,11 +35,11 @@ The {rhoso-gitops-pattern} aims to:
 [id="rhoso-gitops-cluster-scope"]
 == Cluster scope
 
-Validated Patterns distinguish between the *initial cluster* (where the pattern
-is installed) and *managed clusters* (additional {rh-ocp} clusters or hosts
-managed from that hub, for example through {rh-rhacm}).
+{solution-name-upstream} distinguishes between the *initial cluster* (where you
+install the pattern) and *managed clusters* (additional {rh-ocp} clusters or
+hosts managed from that hub, for example through {rh-rhacm}).
 
-The {rhoso-gitops-pattern} is *single-cluster only*. It does not provide
+The {rhoso-gitops-pattern} is *single-cluster only*. It does not include
 multi-cluster support, spoke provisioning, or hub-to-spoke {gitops-shortname}
 fan-out.
 
@@ -51,14 +50,15 @@ fan-out.
 
 | Initial cluster
 | Yes
-| Validated Patterns clustergroup (`values-standalone.yaml`), *rhoso-gitops*
-  meta-chart, and child {rh-rhoso-short} Applications in `openshift-gitops`
+| {solution-name-upstream} clustergroup (`values-standalone.yaml`),
+  *rhoso-gitops* meta-chart, and child {rh-rhoso-short} Applications in
+  `openshift-gitops`
 
 | Managed clusters
 | None
-| Not in scope (`spoke_support: false` in `pattern-metadata.yaml`). No spoke
-  sizing, policies, {rh-rhacm} placement, or remote Argo CD instances are
-  defined or deployed
+| Not in scope (`spoke_support: false` in `pattern-metadata.yaml`). The pattern
+  does not define or deploy spoke sizing, policies, {rh-rhacm} placement, or
+  remote Argo CD instances
 |===
 
 Sizing guidance under `requirements.hub` in the pattern repository applies to
@@ -68,7 +68,7 @@ consistency across spokes) do not apply to this pattern.
 [id="rhoso-gitops-support"]
 == Support
 
-This is a *sandbox tier* Validated Pattern. Support is provided by the community
-on a best-effort basis. For details, see the
+This is a *sandbox tier* pattern. The community provides support on a
+best-effort basis. For details, see the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/SUPPORT.md[support policy]
 in the pattern repository.
diff --git a/modules/rhoso-gitops/rhoso-gitops-architecture.adoc b/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
index bd032a8cd..81ee4e9dc 100644
--- a/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
@@ -4,56 +4,65 @@
 [id="rhoso-gitops-architecture"]
 = {rhoso-gitops-pattern} architecture
 
+The {rhoso-gitops-pattern} delivers {rh-rhoso-short} configuration through Argo CD
+Applications that the *rhoso-gitops* meta-chart creates. Use this overview to
+understand GitOps delivery, the dual Argo CD namespaces, infrastructure topology,
+and sync-wave order before you deploy or customize the pattern.
+
 [id="rhoso-gitops-gitops-delivery"]
 == GitOps delivery flow
 
-The pattern uses the Validated Patterns framework to install the *rhoso-gitops*
-Helm meta-chart. That chart creates Argo CD `Application` resources that sync
-{rh-rhoso-short} stages from the upstream
+The pattern uses the {solution-name-upstream} framework to install the
+*rhoso-gitops* Helm meta-chart. That chart creates Argo CD `Application`
+resources that sync {rh-rhoso-short} stages from the upstream
 link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops]
 repository (`example/*` Kustomize overlays).
 
 The delivery path is:
 
-. Validated Patterns operator reconciles the pattern clustergroup
-. Parent *rhoso-gitops* Application runs in `vp-gitops` (Validated Patterns GitOps)
-. Meta-chart renders child Applications in `openshift-gitops` ({gitops-title})
-. Child apps sync upstream `example/*` overlays in order (operators, networks,
-  control plane, dataplane)
+. The {validated-patterns-op} reconciles the pattern clustergroup
+. The parent *rhoso-gitops* Application runs in `vp-gitops`
+  ({solution-name-upstream} GitOps)
+. The meta-chart renders child Applications in `openshift-gitops`
+  ({gitops-title})
+. The child apps sync upstream `example/*` overlays in order (Operators,
+  networks, control plane, data plane)
 
 .GitOps application delivery and sync-wave ordering
 image::rhoso-gitops/rhoso-gitops-applications.svg[{rhoso-gitops-pattern} GitOps application delivery,700]
 
 The diagram shows the parent Application in `vp-gitops`, child Applications in
 `openshift-gitops`, and the upstream Kustomize overlays they sync. Sync-wave
-annotations order deployment from infrastructure operators through the data
+annotations order deployment from infrastructure Operators through the data
 plane.
 
 [id="rhoso-gitops-dual-argocd"]
 == Dual Argo CD namespaces
 
-* The pattern operator deploys the parent *rhoso-gitops* Application into
-  *`vp-gitops`* (Validated Patterns GitOps).
-* Child {rh-rhoso-short} Applications are created in *`openshift-gitops`*
-  ({gitops-title} operator), per the meta-chart defaults.
+The pattern uses two Argo CD namespaces:
+
+* The {validated-patterns-op} deploys the parent *rhoso-gitops* Application into
+  *`vp-gitops`* ({solution-name-upstream} GitOps).
+* The meta-chart creates child {rh-rhoso-short} Applications in
+  *`openshift-gitops`* ({gitops-title} Operator), per the chart defaults.
 
 [id="rhoso-gitops-infrastructure-topology"]
 == Infrastructure topology
 
-An {rh-ocp} cluster hosts the {rh-rhoso-short} control plane (OpenStack operators
+An {rh-ocp} cluster hosts the {rh-rhoso-short} control plane (OpenStack Operators
 and `OpenStackControlPlane` services on control-plane nodes). Separate {rhel-short}
-hosts run the {rh-rhoso-short} data plane (dataplane elements on compute nodes).
+hosts run the {rh-rhoso-short} data plane (data plane elements on compute nodes).
 
-The GitOps flow above describes *how* configuration is delivered. The diagram
-and list below describe *what* gets deployed:
+The preceding GitOps flow describes *how* GitOps delivers configuration. The
+following diagram and list describe *what* gets deployed:
 
-.RHOSO infrastructure topology
+.{rh-rhoso-short} infrastructure topology
 image::rhoso-gitops/rhoso-gitops-infrastructure.svg[{rhoso-gitops-pattern} infrastructure topology,700]
 
-* *OpenShift cluster* — control-plane nodes run OpenStack operators and
-  `OpenStackControlPlane` services
-* *Data plane hosts* — one or more {rhel-short} compute nodes run {rh-rhoso-short}
-  dataplane elements, connected to the control plane
+* *OpenShift cluster*: Control-plane nodes run OpenStack Operators and
+  `OpenStackControlPlane` services.
+* *Data plane hosts*: One or more {rhel-short} compute nodes run {rh-rhoso-short}
+  data plane elements and connect to the control plane.
 
 [id="rhoso-gitops-sync-waves"]
 == Application sync order
@@ -66,11 +75,11 @@ Child Applications deploy in sync-wave order when Argo CD reconciles the parent
 | Application | Purpose | Sync wave
 
 | `operator-dependencies`
-| Infrastructure operators (cert-manager, MetalLB, nmstate, observability)
+| Infrastructure Operators (cert-manager, MetalLB, nmstate, observability)
 | `-20`
 
 | `openstack-operator`
-| OpenStack operator subscription
+| OpenStack Operator subscription
 | `-20`
 
 | `openstack-operator-cr`
@@ -94,5 +103,5 @@ Child Applications deploy in sync-wave order when Argo CD reconciles the parent
 | `20`
 |===
 
-After changing overrides, confirm child apps in the Argo CD UI or with
+After you change overrides, confirm child apps in the Argo CD UI or with
 `oc get applications -n openshift-gitops`.
diff --git a/modules/rhoso-gitops/rhoso-gitops-configuration.adoc b/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
index 009c86c89..32263837b 100644
--- a/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
@@ -2,18 +2,18 @@
 :imagesdir: ../../images
 
 [id="rhoso-gitops-configuration"]
-= Configuring the {rhoso-gitops-pattern}
+= {rhoso-gitops-pattern} configuration
 
 The *rhoso-gitops* meta-chart renders Argo CD `Application` resources. It does
 not deploy {rh-rhoso-short} workloads directly; Kustomize overlays in the
-upstream gitops repository remain the source of truth.
+upstream GitOps repository remain the source of truth.
 
 [id="rhoso-gitops-values-layers"]
 == Values file layers
 
 The clustergroup application in `values-standalone.yaml` points Argo CD at
 `charts/all/rhoso-gitops` and layers pattern overrides from
-`overrides/values-rhoso-gitops.yaml` via `extraValueFiles`.
+`overrides/values-rhoso-gitops.yaml` through `extraValueFiles`.
 
 .Values file layers
 [cols="1,2,3",options="header"]
@@ -59,34 +59,34 @@ at the revision pinned in `overrides/values-rhoso-gitops.yaml`.
 
 | `operator-dependencies`
 | `example/dependencies`
-| yes
+| Yes
 
 | `openstack-operator`
 | `example/openstack-operator`
-| yes
+| Yes
 
 | `openstack-operator-cr`
 | `example/openstack-operator-cr`
-| yes
+| Yes
 
 | `openstack-secrets`
 | not configured (`path: TODO`)
-| no
+| No
 
 | `openstack-networks`
 | `example/openstack-networks`
-| yes
+| Yes
 
 | `openstack-controlplane`
 | `example/openstack-controlplane`
-| yes
+| Yes
 
 | `openstack-dataplane`
 | `example/openstack-dataplane`
-| yes
+| Yes
 |===
 
-Product, framework, upstream Git, and operator versions are listed in the pattern
+For product, framework, upstream Git, and Operator versions, see the pattern
 repository
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
 file.
@@ -94,7 +94,8 @@ file.
 [id="rhoso-gitops-pin-revision"]
 == Pinning a different upstream revision
 
-In `overrides/values-rhoso-gitops.yaml`:
+In `overrides/values-rhoso-gitops.yaml`, set `targetRevision` for each
+application that you want to pin:
 
 [source,yaml]
 ----
@@ -106,11 +107,13 @@ applications:
 ----
 
 Apply the same key under every application you want on that revision, or only
-the entries you need to change; unspecified keys keep chart defaults.
+the entries that you want to change; unspecified keys keep chart defaults.
 
 [id="rhoso-gitops-disable-stage"]
 == Disabling a deployment stage
 
+To disable a deployment stage, set `enabled` to `false` for that application:
+
 [source,yaml]
 ----
 applications:
@@ -119,7 +122,10 @@ applications:
 ----
 
 [id="rhoso-gitops-repoint-overlay"]
-== Repointing an application to your Git overlay
+== Pointing an application to your Git overlay
+
+To point an application at your own Git overlay, set `repoURL`, `path`, and
+`targetRevision`:
 
 [source,yaml]
 ----
@@ -133,7 +139,7 @@ applications:
 [id="rhoso-gitops-kustomize-components"]
 == Adding Kustomize components
 
-For example, to add a secrets operator component via `operator-dependencies`:
+For example, add a secrets Operator component through `operator-dependencies`:
 
 [source,yaml]
 ----
@@ -144,16 +150,17 @@ applications:
         - "https://github.com/openstack-k8s-operators/gitops/components/secrets/vault-secrets-operator?ref=v0.2.0"
 ----
 
-Component URLs for Vault Secrets Operator and External Secrets Operator are
-documented in the upstream
+For Vault Secrets Operator and External Secrets Operator component URLs, see the
+upstream
 link:https://github.com/openstack-k8s-operators/gitops/tree/main/components/secrets[components/secrets]
-readme.
+README.
 
 [id="rhoso-gitops-secret-zero"]
 == Secret zero (bootstrap credential)
 
-{rh-rhoso-short} GitOps often uses a secure store (for example Vault). The
-bootstrap credential must not live in Git. Typical steps:
+{rh-rhoso-short} GitOps often uses a secure store (for example
+{hashicorp-vault-short}). The bootstrap credential must not live in Git. Complete
+the following steps:
 
 . Create the `openstack` namespace (or the namespace your overlay specifies).
 . Create the Kubernetes `Secret` out of band (`oc create secret generic ...`).
@@ -162,7 +169,7 @@ bootstrap credential must not live in Git. Typical steps:
 . Enable and configure `applications.openstack-secrets` in
   `overrides/values-rhoso-gitops.yaml` (`enabled: true`, `repoURL`, `path`,
   `targetRevision`, optional `kustomize` patches).
-. Install the secrets operator via `operator-dependencies` using
+. Install the secrets Operator through `operator-dependencies` by using
   `kustomize.components` URLs from the upstream secrets components.
 
 For standalone Helm usage and advanced chart examples, see the upstream
diff --git a/modules/rhoso-gitops/rhoso-gitops-deploying.adoc b/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
index ef0cc72e9..8faf0f4a2 100644
--- a/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
@@ -4,18 +4,23 @@
 [id="deploying-rhoso-gitops-pattern"]
 = Deploying the {rhoso-gitops-pattern}
 
+Deploy the {rhoso-gitops-pattern} on a single {rh-ocp} cluster. Complete the
+prerequisites, prepare your fork of the pattern repository, install with
+`./pattern.sh`, and verify that Argo CD Applications are healthy.
+
 [id="rhoso-gitops-prerequisites"]
 == Prerequisites
 
-Before you deploy the pattern, ensure that you have the following:
+Before you deploy the pattern, verify that you have the following:
 
-* An {rh-ocp} 4.14 or later cluster with sufficient compute and storage for
+* A {rh-ocp} 4.14 or later cluster with enough compute and storage for
   {rh-rhoso-short}. For sizing guidance, see link:../cluster-sizing/[Cluster sizing].
-* Cluster administrator privileges and a working `kubeconfig`
-* link:https://podman.io/[podman] 4.3 or later for `./pattern.sh`
+* Cluster administrator privileges and a working `kubeconfig`.
+* link:https://podman.io/[Podman] 4.3 or later for `./pattern.sh`.
 * {gitops-title} available on the cluster (installed by the pattern framework or
-  pre-installed)
-* link:https://validatedpatterns.io/learn/quickstart/[Install the tooling dependencies]
+  pre-installed).
+* The link:https://validatedpatterns.io/learn/quickstart/[tool dependencies] are
+  installed.
 
 [id="rhoso-gitops-preparing-deployment"]
 == Preparing for deployment
@@ -30,11 +35,18 @@ Before you deploy the pattern, ensure that you have the following:
 +
 [source,terminal]
 ----
-$ git clone git@github.com:<your-organization>/rhoso-gitops.git
+$ git clone git@github.com:<your_organization>/rhoso-gitops.git
+----
+
+. Change to the repository directory:
++
+[source,terminal]
+----
 $ cd rhoso-gitops
 ----
 
-. Optional: if you plan to use Vault integration later, copy the secrets template:
+. Optional: If you plan to use {hashicorp-vault-short} integration later, copy
+  the secrets template:
 +
 [source,terminal]
 ----
@@ -44,11 +56,19 @@ $ cp values-secret.yaml.template values-secret.yaml
 [id="rhoso-gitops-installing-pattern"]
 == Installing the pattern
 
+.Procedure
+
 . Validate prerequisites without applying changes:
 +
 [source,terminal]
 ----
 $ ./pattern.sh make validate-prereq
+----
+
+. Preview the rendered manifests:
++
+[source,terminal]
+----
 $ ./pattern.sh make show
 ----
 
@@ -62,11 +82,19 @@ $ ./pattern.sh make install
 [id="rhoso-gitops-verifying-deployment"]
 == Verifying the deployment
 
-. Watch Argo CD applications in both GitOps namespaces:
+.Procedure
+
+. List Argo CD applications in `vp-gitops`:
 +
 [source,terminal]
 ----
 $ oc get applications -n vp-gitops
+----
+
+. List Argo CD applications in `openshift-gitops`:
++
+[source,terminal]
+----
 $ oc get applications -n openshift-gitops
 ----