diff --git a/content/contribute/extending-a-pattern.adoc b/content/contribute/extending-a-pattern.adoc
index ec4976076..f25e240c1 100644
--- a/content/contribute/extending-a-pattern.adoc
+++ b/content/contribute/extending-a-pattern.adoc
@@ -27,7 +27,7 @@ In the example below AMQ Streams (Kafka) is chosen as a product to add to a patt
 
 == Before starting, fork and clone first
 
-. Visit the github page for the pattern that you wish to extend. E.g. https://github.com/hybrid-cloud-patterns/multicloud-gitops[multicloud-gitops]. Select "`Fork`" in the top right corner.
+. Visit the github page for the pattern that you wish to extend. E.g. https://github.com/validatedpatterns/multicloud-gitops[multicloud-gitops]. Select "`Fork`" in the top right corner.
 . On the create a new fork page. You can choose what owner repository you want and the name of the fork. Most times you will fork into your personal repo and leave the name the same. When you have made the appropriate changes press the "Create fork" button.
 . You will need to clone from the new fork onto you laptop/desktop so that you can do the extension work effectively. So on the new fork's main page elect the green "`Code`" button and copy the git repo's ssh address.
 . In an appropriate directory on your laptop (e.g. `~/git`) use `git clone` on the command line using the ssh address copied above. Then create a branch to extend the pattern. For example if you are extending the `multicloud-gitops` pattern and adding kafka, you will need to clone your fork of multicloud-gitops and create a branch to add Kafka:
diff --git a/content/contribute/maintained.adoc b/content/contribute/maintained.adoc
index 21fae666b..44be87a80 100644
--- a/content/contribute/maintained.adoc
+++ b/content/contribute/maintained.adoc
@@ -20,7 +20,7 @@ A pattern categorized under the {maintained} tier implies that the pattern was k
 [id="nominating-a-pattern-for-maintained-tier"]
 == Nominating a pattern for the {maintained} tier
 
-If your pattern qualifies or meets the criteria for {maintained} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
+If your pattern qualifies or meets the criteria for {maintained} tier, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 
 [NOTE]
 ====
diff --git a/content/contribute/pattern-metadata-documentation-sync.adoc b/content/contribute/pattern-metadata-documentation-sync.adoc
index 30ab12a35..6bef30a53 100644
--- a/content/contribute/pattern-metadata-documentation-sync.adoc
+++ b/content/contribute/pattern-metadata-documentation-sync.adoc
@@ -122,6 +122,6 @@ The workflow validates `repo_url`, flattens the metadata, and opens a pull reque
 
 . Review and merge the resulting pull request in `validatedpatterns/docs`.
 
-Contact mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com] if you need help configuring repository secrets for metadata sync.
+https://groups.google.com/g/validatedpatterns/about[Join the validatedpatterns group] and contact mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com] if you need help configuring repository secrets for metadata sync.
 
 For sync failures, see link:/contribute/pattern-metadata-validation/#metadata-sync-workflow-fails-on-repo-url[Metadata sync workflow fails on repo URL] in Validation and troubleshooting.
diff --git a/content/contribute/support-policies.adoc b/content/contribute/support-policies.adoc
index 3a7e65ff2..53f2cba9f 100644
--- a/content/contribute/support-policies.adoc
+++ b/content/contribute/support-policies.adoc
@@ -39,7 +39,7 @@ To ensure we can best help you please provide the following information:
 * Any changes that were made prior to the failure
 * Expected Outcome: What you thought should have happened
 
-If you are unsure if your issue is product or pattern related, please reach out to the community using https://groups.google.com/g/validatedpatterns or by emailing validatedpatterns@googlegroups.com 
+If you are unsure if your issue is product or pattern related, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and reach out to the community by posting in the group or emailing mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com]. 
 
 Any pattern-based security issues, such as hard coded secrets, found should be reported to: validated-patterns-team@redhat.com  You can expect a response **within 5 business days**
 
diff --git a/content/contribute/tested.adoc b/content/contribute/tested.adoc
index c1da48ef0..8a47583d3 100644
--- a/content/contribute/tested.adoc
+++ b/content/contribute/tested.adoc
@@ -20,7 +20,7 @@ The {tested} tier provides you with additional collateral and reassurance that t
 [id="nominating-a-pattern-for-tested-tier"]
 == Nominating a pattern for the {tested} tier
 
-If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
+If your pattern qualifies or meets the criteria for {tested} tier, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 
 [NOTE]
 ====
diff --git a/content/patterns/rhoso-gitops/_index.adoc b/content/patterns/rhoso-gitops/_index.adoc
index 07f282158..7ab2cc79d 100644
--- a/content/patterns/rhoso-gitops/_index.adoc
+++ b/content/patterns/rhoso-gitops/_index.adoc
@@ -11,7 +11,9 @@ industries:
   - General
 focus_areas:
   - DevSecOps
-aliases: /rhoso-gitops/
+aliases:
+  - /rhoso-gitops/
+  - /rhoso-gitops/cluster-sizing/
 ci: rhoso-gitops
 ci_sources:
   - base: https://raw.githubusercontent.com/validatedpatterns-sandbox/rhoso-gitops/reporting/
@@ -19,7 +21,7 @@ ci_sources:
       - rhoso-gitops-baremetal-4.18-stable-badge.json
 links:
   github: https://github.com/validatedpatterns-sandbox/rhoso-gitops
-  install: getting-started
+  install: deploying-rhoso-gitops-pattern
   bugs: https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues
   feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform
 ---
diff --git a/content/patterns/rhoso-gitops/cluster-sizing.adoc b/content/patterns/rhoso-gitops/cluster-sizing.adoc
deleted file mode 100644
index f8b797bf5..000000000
--- a/content/patterns/rhoso-gitops/cluster-sizing.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Cluster sizing
-weight: 20
-aliases: /rhoso-gitops/cluster-sizing/
----
-
-:toc:
-:_content-type: ASSEMBLY
-include::modules/comm-attributes.adoc[]
-:imagesdir: /images
-include::modules/rhoso-gitops/metadata-rhoso-gitops.adoc[]
-
-Review the cluster and data plane host requirements before you deploy the
-{rhoso-gitops-pattern}.
-
-[id="rhoso-gitops-cluster-requirements"]
-== Cluster requirements
-
-{rh-rhoso-short} requires bare-metal infrastructure for both the {rh-ocp} cluster
-and the compute nodes. {rh-rhoso-short} does not support cloud-based instance types
-such as AWS, GCP, or Azure.
-
-For detailed hardware, software, and network requirements, see
-link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/latest/html/planning_your_deployment/assembly_infrastructure-and-system-requirements[Infrastructure and system requirements]
-in the {rh-rhoso} _Planning your deployment_ guide.
-
-[id="rhoso-gitops-dataplane-hosts"]
-== Data plane host requirements
-
-The {rh-ocp} cluster hosts 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 data plane elements).
diff --git a/content/patterns/rhoso-gitops/configuration.adoc b/content/patterns/rhoso-gitops/configuration.adoc
index 6049fff78..6e6df0ca7 100644
--- a/content/patterns/rhoso-gitops/configuration.adoc
+++ b/content/patterns/rhoso-gitops/configuration.adoc
@@ -1,5 +1,5 @@
 ---
-title: Configuration
+title: RHOSO GitOps pattern configuration
 weight: 30
 aliases: /rhoso-gitops/configuration/
 ---
diff --git a/content/patterns/rhoso-gitops/getting-started.adoc b/content/patterns/rhoso-gitops/deploying-rhoso-gitops-pattern.adoc
similarity index 54%
rename from content/patterns/rhoso-gitops/getting-started.adoc
rename to content/patterns/rhoso-gitops/deploying-rhoso-gitops-pattern.adoc
index be7fb9eda..7f63a6199 100644
--- a/content/patterns/rhoso-gitops/getting-started.adoc
+++ b/content/patterns/rhoso-gitops/deploying-rhoso-gitops-pattern.adoc
@@ -1,7 +1,9 @@
 ---
-title: Getting started
-weight: 10
-aliases: /rhoso-gitops/getting-started/
+title: Deploying the RHOSO GitOps pattern
+weight: 20
+aliases:
+  - /rhoso-gitops/deploying-rhoso-gitops-pattern/
+  - /rhoso-gitops/getting-started/
 ---
 
 :toc:
diff --git a/content/patterns/rhoso-gitops/secret-management.adoc b/content/patterns/rhoso-gitops/secret-management.adoc
index a8a47a476..4ffc42616 100644
--- a/content/patterns/rhoso-gitops/secret-management.adoc
+++ b/content/patterns/rhoso-gitops/secret-management.adoc
@@ -1,6 +1,6 @@
 ---
-title: Secret management
-weight: 25
+title: Secret management for the RHOSO GitOps pattern
+weight: 10
 aliases: /rhoso-gitops/secret-management/
 ---
 
@@ -15,10 +15,10 @@ include::modules/comm-attributes.adoc[]
 The {rhoso-gitops-pattern} requires secrets for OpenStack service passwords, SSH
 key pairs, bare-metal controller credentials, and container registry
 authentication. You can provide these secrets in two ways depending on whether a
-secure storage backend is available. The two approaches can also be combined: for
-example, store shared credentials (registry, subscription) in the backend while
-injecting service-specific passwords as `bootstrap_secrets`, or use
-`onMissingValue: generate` to let the backend generate passwords at deployment
+secure storage backend is available. The two approaches can also be combined, for
+example, by storing shared credentials (registry, subscription) in the backend while
+injecting service-specific passwords as `bootstrap_secrets`, or by using
+`onMissingValue: generate` to have the backend generate passwords at deployment
 time.
 
 For the canonical list of required secrets, see
@@ -33,14 +33,10 @@ Review the following approaches before you deploy the pattern.
 [id="rhoso-secrets-vault-eso"]
 === Secure storage backend and {eso-op}
 
-image::rhoso-gitops/rhoso-gitops-secrets-vault-eso.png[Secure storage backend and {eso-op} secrets flow]
+For production deployments, store secrets in a secure storage backend such as {hashicorp-vault}, AWS Secrets Manager, or any link:https://external-secrets.io/latest/provider/aws-secrets-manager/[provider supported by the {eso-op}]. `ExternalSecret` resources project these secrets into the `openstack` namespace through a `SecretStore`.
 
-This is the recommended approach for production deployments. You store secrets
-in a secure storage backend (for example {hashicorp-vault}, AWS Secrets Manager,
-or any
-link:https://external-secrets.io/latest/provider/aws-secrets-manager/[provider supported by the {eso-op}]).
-`ExternalSecret` resources project these secrets into the `openstack` namespace
-through a `SecretStore`.
+.Secret flow from secure storage method
+image::rhoso-gitops/rhoso-gitops-secrets-vault-eso.png["Secure storage backend and {eso-op} secrets flow"]
 
 The framework does not install the storage backend or the {eso-op}
 automatically. You must include the {eso-op} through the `operator-dependencies`
@@ -65,7 +61,8 @@ This approach uses the following configuration:
 [id="rhoso-secrets-direct-injection"]
 === Direct injection without an external store
 
-image::rhoso-gitops/rhoso-gitops-secrets-direct.png[Direct injection secrets flow]
+.Secret flow for direct injection method
+image::rhoso-gitops/rhoso-gitops-secrets-direct.png["Direct injection secrets flow"]
 
 Use this approach when you do not have a secure storage backend. All secrets are
 defined as `bootstrap_secrets` in the `values-secret.yaml` file. The framework
@@ -92,7 +89,7 @@ contains placeholder entries for each secret.
 | `vault-approle-secret-id`
 | `id`
 | Authentication credential for the {eso-op} `SecretStore` to connect to the
-  secure storage backend. Required only with the backend + {eso-op} approach.
+  secure storage backend. Required only with the backend and {eso-op} approach.
 
 | `osp-secret`
 | Multiple service and database password fields
@@ -203,7 +200,7 @@ bootstrap_secrets:
         path: ~/vault-approle-secret-id
         onMissingValue: error
 
-secrets: []
+secrets: []     # additional secrets loaded into the back end
 ----
 
 . Install the pattern:
@@ -213,7 +210,7 @@ secrets: []
 $ ./pattern.sh make install
 ----
 
-. Verify that the `ExternalSecret` resources are synchronized:
+. Verify that the `ExternalSecret` resources synchronized:
 +
 [source,terminal]
 ----
diff --git a/content/patterns/rhoso-gitops/troubleshooting.adoc b/content/patterns/rhoso-gitops/troubleshooting.adoc
index 30712bdcf..a00179891 100644
--- a/content/patterns/rhoso-gitops/troubleshooting.adoc
+++ b/content/patterns/rhoso-gitops/troubleshooting.adoc
@@ -1,5 +1,5 @@
 ---
-title: Troubleshooting
+title: Troubleshooting the RHOSO GitOps pattern
 weight: 40
 aliases: /rhoso-gitops/troubleshooting/
 ---
@@ -12,9 +12,13 @@ include::modules/comm-attributes.adoc[]
 [id="troubleshooting-rhoso-gitops"]
 = Troubleshooting the {rhoso-gitops-pattern}
 
-Validate the {rhoso-gitops-pattern} deployment, inspect Argo CD application and
-pod status, and review known issues. Use these procedures when child applications
-fail to sync, pods are unhealthy, or you need to confirm a successful deployment.
+Validate the {rhoso-gitops-pattern} deployment and inspect Argo CD application and
+pod status. Use these procedures when child applications fail to sync, pods are
+unhealthy, or you need to confirm a successful deployment.
+
+For known issues that can affect deployment, see
+link:../#rhoso-gitops-known-issues[Known issues] in
+link:../[About the {rhoso-gitops-pattern}].
 
 [id="rhoso-gitops-validate-pattern"]
 == Validating the pattern
@@ -45,23 +49,23 @@ $ ./pattern.sh make argo-healthcheck
 [id="rhoso-gitops-check-argocd"]
 == Checking Argo CD application status
 
-All Argo CD applications run in the `vp-gitops` namespace:
+Confirm the health of the Argo CD applications.
 
-. List applications in `vp-gitops`:
+. Confirm that all Argo CD applications run in the `vp-gitops` namespace:
 +
 [source,terminal]
 ----
 $ oc get applications -n vp-gitops
 ----
 
-. Inspect a child application that is out of sync or unhealthy:
+. Inspect any child application that is out of sync or unhealthy:
 +
 [source,terminal,subs="+quotes"]
 ----
 $ oc describe application __<application_name>__ -n vp-gitops
 ----
 
-Use the Argo CD UI in the `vp-gitops` namespace to review application status,
+. Use the Argo CD UI in the `vp-gitops` namespace to review application status,
 resource health, and diff details for upstream overlays.
 
 [id="rhoso-gitops-check-pods"]
@@ -82,22 +86,5 @@ Review logs for a specific pod:
 $ oc logs -n __<namespace>__ __<pod_name>__
 ----
 
-[id="rhoso-gitops-known-issues"]
-== Known issues
-
-The following known issues can affect pattern deployment:
-
-* *`openstack-secrets` disabled*: The default pattern leaves
-  `openstack-secrets` disabled because no Git path exists.
-  Enable it only after you configure secret wiring. See
-  link:../secret-management/[Secret management for the {rhoso-gitops-pattern}].
-* *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
-  `ClusterServiceVersions` (CSVs). Other applications retry automatically
-  until their dependencies are satisfied.
-
 For community support, open an issue in the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].
diff --git a/modules/contributing.adoc b/modules/contributing.adoc
index 5d87893cf..810092729 100644
--- a/modules/contributing.adoc
+++ b/modules/contributing.adoc
@@ -8,7 +8,7 @@
 
 There are a few different ways you can contribute to Validated Patterns documentation:
 
-* Email the Validated Patterns team at mailto:hybrid-cloud-patterns@googlegroups.com[hybrid-cloud-patterns@googlegroups.com].
+*  https://groups.google.com/g/validatedpatterns/about[Join the validatedpatterns group] and email the Validated Patterns team at mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 * Create a link:https://github.com/validatedpatterns/docs/issues[GitHub] or link:https://issues.redhat.com/projects/MBP/issues[Jira issue] .
 //to-do: Add link to the contribution workflow when we have a proper one. You might need to create a new file
 * Submit a pull request (PR). To create a PR, create a local clone of your own fork of the link:https://github.com/validatedpatterns/docs[Validated Patterns docs repository], make your changes, and submit a PR. This option is best if you have substantial changes.
@@ -16,7 +16,7 @@ There are a few different ways you can contribute to Validated Patterns document
 
 == Contribution workflow
 
-When you submit a PR, the https://github.com/orgs/hybrid-cloud-patterns/teams/docs[Validated Patterns Docs team] reviews the PR and arranges further reviews by Quality Engineering (QE), subject matter experts (SMEs), and others, as required. If the PR requires changes, updates, or corrections, the reviewers add comments in the PR. The documentation team merges the PR after you have implemented all feedback, and you have squashed all commits.
+When you submit a PR, the https://github.com/orgs/validatedpatterns/teams/docs[Validated Patterns Docs team] reviews the PR and arranges further reviews by Quality Engineering (QE), subject matter experts (SMEs), and others, as required. If the PR requires changes, updates, or corrections, the reviewers add comments in the PR. The documentation team merges the PR after you have implemented all feedback, and you have squashed all commits.
 
 
 == Repository organization
diff --git a/modules/emerging-disease-detection/metadata-emerging-disease-detection.adoc b/modules/emerging-disease-detection/metadata-emerging-disease-detection.adoc
new file mode 100644
index 000000000..a6577ac16
--- /dev/null
+++ b/modules/emerging-disease-detection/metadata-emerging-disease-detection.adoc
@@ -0,0 +1,21 @@
+// This file has been generated automatically from the pattern-metadata.yaml file
+// Do not edit manually!
+:metadata_version: 1.0
+:name: emerging-disease-detection
+:description: This pattern deploys a sepsis early warning system driven by clinical AI at the edge
+:pattern_version: 1.0
+:display_name: Emerging Disease Detection
+:repo_url: https://github.com/validatedpatterns/emerging-disease-detection
+:docs_repo_url: https://github.com/validatedpatterns/docs
+:issues_url: https://github.com/validatedpatterns/emerging-disease-detection/issues
+:docs_url: https://validatedpatterns.io/patterns/emerging-disease-detection/
+:ci_url: https://validatedpatterns.io/ci/?pattern=emerging-disease-detection
+:tier: sandbox
+:owners: dminnear-rh
+:requirements_hub_compute_platform_aws_replicas: 3
+:requirements_hub_compute_platform_aws_type: m5.2xlarge
+:requirements_hub_controlPlane_platform_aws_replicas: 3
+:requirements_hub_controlPlane_platform_aws_type: m5.xlarge
+:extra_features_hypershift_support: true
+:extra_features_spoke_support: false
+:external_requirements: 
diff --git a/modules/rhoso-gitops/rhoso-gitops-about.adoc b/modules/rhoso-gitops/rhoso-gitops-about.adoc
index cca9ffdd5..0af286b5f 100644
--- a/modules/rhoso-gitops/rhoso-gitops-about.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-about.adoc
@@ -5,11 +5,9 @@
 = 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 you upgrade or
-reproduce the stack.
+Teams that rely on imperative scripts or manual cluster changes can therefore face slow rollouts, configuration drift, and weak audit trails when they try to upgrade or reproduce the stack.
 
-The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public
+The {rhoso-gitops-pattern} addresses these issues 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.
 
@@ -38,8 +36,8 @@ The {rhoso-gitops-pattern} uses the following Red Hat products:
 == Cluster scope
 
 {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}).
+install the pattern) and additional *managed clusters* that are managed by the
+initial cluster, for example, through {rh-rhacm}.
 
 The {rhoso-gitops-pattern} is *single-cluster only*. It does not include
 multi-cluster support, spoke provisioning, or hub-to-spoke {gitops-shortname}
@@ -64,8 +62,7 @@ fan-out.
 |===
 
 Sizing guidance under `requirements.hub` in the pattern repository applies to
-the single target cluster. Managed-cluster requirements (for example eventual
-consistency across spokes) do not apply to this pattern.
+the single target cluster. Requirements that apply only to managed clusters are not relevant for this pattern.
 
 [id="rhoso-gitops-support"]
 == Support
@@ -74,3 +71,24 @@ 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.
+
+[id="rhoso-gitops-known-issues"]
+== Known issues
+
+The following known issues can affect pattern deployment:
+
+* *`openstack-secrets` disabled*: The default pattern intentionally leaves `openstack-secrets` disabled. Enable `openstack-secrets` only after you have configured secrets in a secure location outside your repository. See
+  link:secret-management[Secret management for the {rhoso-gitops-pattern}] for details.
+* *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 the Operator Lifecycle Manager to resolve
+  `ClusterServiceVersions` (CSVs). Other applications retry automatically
+  until their dependencies are satisfied.
+
+For deployment validation and troubleshooting procedures, see
+link:troubleshooting[Troubleshooting the {rhoso-gitops-pattern}].
+
+For community support, open an issue in the
+link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].
diff --git a/modules/rhoso-gitops/rhoso-gitops-architecture.adoc b/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
index ff3ce8e59..261a9e717 100644
--- a/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-architecture.adoc
@@ -5,9 +5,7 @@
 = {rhoso-gitops-pattern} architecture
 
 The {rhoso-gitops-pattern} delivers {rh-rhoso-short} configuration through Argo CD
-Applications that the *rhoso-gitops* meta-chart creates. The pattern uses GitOps
-delivery through a single Argo CD namespace, manages infrastructure topology, and
-converges deployment through retry policies.
+Applications that the *rhoso-gitops* meta-chart creates. The pattern uses GitOps to deploy all Argo CD applications to a single namespace, control cluster topology, and converge deployment dependencies using retry policies.
 
 [id="rhoso-gitops-gitops-delivery"]
 == GitOps delivery flow
@@ -30,7 +28,7 @@ The delivery path is:
 .GitOps application delivery
 image::rhoso-gitops/rhoso-gitops-applications.png[{rhoso-gitops-pattern} GitOps application delivery]
 
-All child Applications deploy at sync-wave 0 and converge eventually through
+All child Applications deploy at sync-wave `0` and converge eventually through
 retry policies.
 
 [id="rhoso-gitops-argocd-namespace"]
@@ -43,7 +41,7 @@ enabled by `global.singleArgoCD: true` in `values-global.yaml`. The
 the same namespace.
 
 For more information about this option, see the
-link:https://validatedpatterns.io/blog/2026-06-04-single-argocd-option/[single ArgoCD blog post].
+link:https://validatedpatterns.io/blog/2026-06-04-single-argocd-option/[single Argo CD blog post].
 
 [id="rhoso-gitops-infrastructure-topology"]
 == Infrastructure topology
@@ -53,7 +51,7 @@ and `OpenStackControlPlane` services on control-plane nodes). Separate {rhel-sho
 hosts run the {rh-rhoso-short} data plane (data plane elements on compute nodes).
 
 The GitOps delivery flow defines *how* configuration reaches the cluster. The
-infrastructure topology defines *what* gets deployed:
+infrastructure topology defines *what* gets deployed.
 
 .{rh-rhoso-short} infrastructure topology
 image::rhoso-gitops/rhoso-gitops-infrastructure.png[{rhoso-gitops-pattern} infrastructure topology]
@@ -72,9 +70,30 @@ simultaneously. Each child retries (per `syncPolicy.retry`) until its upstream
 dependencies resolve and it converges eventually.
 
 For the full list of child applications, their upstream paths, and links to the
-corresponding {rh-rhoso} product documentation, see
-link:configuration/#rhoso-gitops-configuration[Configuration] >
-link:configuration/#rhoso-gitops-upstream-applications[Upstream applications].
+corresponding {rh-rhoso} product documentation, see link:configuration/#rhoso-gitops-upstream-applications[Upstream applications].
 
-After you change overrides, confirm child applications in the Argo CD UI or with
-`oc get applications -n vp-gitops`.
+After you change overrides,confirm that child applications are healthy by using
+the Argo CD UI or running the following command:
+
+[source,terminal]
+---
+$ oc get applications -n vp-gitops
+---
+
+[id="rhoso-gitops-cluster-requirements"]
+== Cluster requirements
+
+{rh-rhoso-short} requires bare-metal infrastructure for both the {rh-ocp} cluster
+and the compute nodes. {rh-rhoso-short} does not support cloud-based infrastructure
+such as deployments on AWS, GCP, or Azure.
+
+For detailed hardware, software, and network requirements, see
+link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/latest/plan-ref_rhocp_cluster_requirements[Infrastructure and system requirements]
+in the {rh-rhoso} documentation.
+
+[id="rhoso-gitops-dataplane-hosts"]
+== Data plane requirements
+
+Deploying {rh-rhoso-short} requires separate {rhel-short} hosts for the
+data plane (compute nodes running data plane elements).
+For detailed data plane requirements, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/latest/plan-ref_data_plane_node_requirements[Data plane node requirements] in the {rh-rhoso} documentation.
\ No newline at end of file
diff --git a/modules/rhoso-gitops/rhoso-gitops-configuration.adoc b/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
index c0170ebef..210bbc8c9 100644
--- a/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-configuration.adoc
@@ -63,7 +63,7 @@ To deploy {rh-rhoso-short}, point each application at your own Git overlay
 .Default upstream applications
 [cols="2,3,2,3",options="header"]
 |===
-| Application | Purpose | Upstream path | {rh-rhoso} docs
+| Application | Purpose | Upstream path | Documentation
 
 | `operator-dependencies`
 | Infrastructure Operators (cert-manager, MetalLB, nmstate, observability)
@@ -119,7 +119,7 @@ Always pin `targetRevision` to a *tag* or *commit hash* for stability.
 ====
 
 In `overrides/values-rhoso-gitops.yaml`, set `targetRevision` for each
-application that you want to pin:
+application that you want to pin to a specific revision:
 
 [source,yaml]
 ----
@@ -130,8 +130,7 @@ applications:
     targetRevision: "abc123def456"           # commit hash — also safe
 ----
 
-Apply the same key under every application you want on that revision, or only
-the entries that you want to change; unspecified keys keep chart defaults.
+Applications without an explicit `targetRevision` use the default *automated sync* behavior.
 
 [id="rhoso-gitops-disable-automated-sync"]
 == Disabling automated sync for an application
@@ -196,13 +195,13 @@ applications:
   openstack-controlplane:
     repoURL: "https://github.com/example/your-gitops.git"
     path: "environments/prod/controlplane"
-    targetRevision: "main"
+    targetRevision: "version-x.y.z"
 ----
 
 [id="rhoso-gitops-kustomize-components"]
 == Adding Kustomize components
 
-For example, add a secrets Operator component through `operator-dependencies`:
+To include a Kustomize component in an application, define the component under `operator-dependecies.kustomize`. For example, to add a secrets Operator component:
 
 [source,yaml]
 ----
diff --git a/modules/rhoso-gitops/rhoso-gitops-deploying.adoc b/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
index 422fdcac5..a0778a414 100644
--- a/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
+++ b/modules/rhoso-gitops/rhoso-gitops-deploying.adoc
@@ -13,14 +13,13 @@ prerequisites, prepare your fork of the pattern repository, install with
 
 Before you deploy the pattern, verify that you have the following:
 
-* A {rh-ocp} cluster meeting the
+* A {rh-ocp} cluster that meets the 
   link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/latest/html/planning_your_deployment/assembly_infrastructure-and-system-requirements#ref_RHOCP-software-requirements_planning[{rh-rhoso-short} software requirements]
-  with enough compute and storage. For sizing guidance, see
-  link:../cluster-sizing/[Cluster sizing].
+  and has enough compute and storage capacity. For sizing guidance, see
+  link:../#rhoso-gitops-cluster-requirements[Cluster requirements].
 * 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).
+* A pre-existing {gitops-title}. This is installed by the pattern framework if not present.
 * The required link:https://validatedpatterns.io/learn/quickstart/[tool dependencies].
 
 [id="rhoso-gitops-preparing-deployment"]
@@ -47,13 +46,10 @@ $ cd rhoso-gitops
 ----
 
 . Configure your overrides. See
-  link:../configuration/[{rhoso-gitops-pattern} configuration] for the values
+  link:../configuration[{rhoso-gitops-pattern} configuration] for the values
   file layers and override options.
 
-. Configure your secrets file before installing. See
-  link:../secret-management/[Secret management for the {rhoso-gitops-pattern}]
-  for instructions on both the {hashicorp-vault-short} + {eso-op} and direct
-  injection approaches.
+. Configure your secrets file before installing. For instructions on the secure storage backend and the direct injection approaches, see link:../secret-management[Secret management for the {rhoso-gitops-pattern}].
 
 [id="rhoso-gitops-installing-pattern"]
 == Installing the pattern
@@ -93,7 +89,7 @@ $ ./pattern.sh make install
 $ oc get applications -n vp-gitops
 ----
 
-. After installation, run the pattern health check:
+. Verify the health of the pattern:
 +
 [source,terminal]
 ----