diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
index d3d7ca0760..a9f9bf11e2 100644
--- a/_attributes/common-attributes.adoc
+++ b/_attributes/common-attributes.adoc
@@ -147,6 +147,10 @@ endif::[]
 //observability
 :ObservabilityLongName: Red Hat OpenShift Observability
 :ObservabilityShortName: Observability
+// Cluster Monitoring Operator
+:cmo-first: Cluster Monitoring Operator (CMO)
+:cmo-full: Cluster Monitoring Operator
+:cmo-short: CMO
 //power monitoring
 :PM-title-c: Power monitoring for Red Hat OpenShift
 :PM-title: power monitoring for Red Hat OpenShift
diff --git a/modules/cluster-monitoring-operator.adoc b/modules/cluster-monitoring-operator.adoc
index a9baf0310b..4d01b0a59c 100644
--- a/modules/cluster-monitoring-operator.adoc
+++ b/modules/cluster-monitoring-operator.adoc
@@ -3,12 +3,12 @@
 // * operators/operator-reference.adoc
 
 [id="cluster-monitoring-operator_{context}"]
-= Cluster Monitoring Operator
+= {cmo-full}
 
 [discrete]
 == Purpose
 
-The Cluster Monitoring Operator manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
+The {cmo-first} manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
 
 [discrete]
 == Project
diff --git a/modules/infrastructure-moving-monitoring.adoc b/modules/infrastructure-moving-monitoring.adoc
index a75076cc87..54de79f05d 100644
--- a/modules/infrastructure-moving-monitoring.adoc
+++ b/modules/infrastructure-moving-monitoring.adoc
@@ -7,7 +7,7 @@
 = Moving the monitoring solution
 
 The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager.
-The Cluster Monitoring Operator manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
+The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
 
 .Procedure
 
diff --git a/modules/monitoring-common-terms.adoc b/modules/monitoring-common-terms.adoc
index 56318f6a32..fb6bee41e9 100644
--- a/modules/monitoring-common-terms.adoc
+++ b/modules/monitoring-common-terms.adoc
@@ -14,8 +14,8 @@ Alertmanager handles alerts received from Prometheus. Alertmanager is also respo
 Alerting rules::
 Alerting rules contain a set of conditions that outline a particular state within a cluster. Alerts are triggered when those conditions are true. An alerting rule can be assigned a severity that defines how the alerts are routed.
 
-Cluster Monitoring Operator::
-The Cluster Monitoring Operator (CMO) is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The CMO is deployed by the Cluster Version Operator (CVO).
+{cmo-full}::
+The {cmo-first} is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
 
 Cluster Version Operator::
 The Cluster Version Operator (CVO) manages the lifecycle of cluster Operators, many of which are installed in {product-title} by default.
diff --git a/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc b/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc
index 0f3e54d76e..041803b5d7 100644
--- a/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc
+++ b/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc
@@ -11,7 +11,7 @@ You can configure different alert receivers for default platform alerts and user
 * All default platform alerts are sent to a receiver owned by the team in charge of these alerts.
 * All user-defined alerts are sent to another receiver so that the team can focus only on platform alerts.
 
-You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the Cluster Monitoring Operator to all platform alerts:
+You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the {cmo-full} to all platform alerts:
 
 * Use the `openshift_io_alert_source="platform"` matcher to match default platform alerts.
 * Use the `openshift_io_alert_source!="platform"` or `'openshift_io_alert_source=""'` matcher to match user-defined alerts.
diff --git a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
index e372633c0e..812bc588a6 100644
--- a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
+++ b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
@@ -8,7 +8,7 @@
 
 You can configure pod topology spread constraints for 
 ifndef::openshift-dedicated,openshift-rosa[]
-all the pods deployed by the Cluster Monitoring Operator
+all the pods deployed by the {cmo-full}
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 all the pods for user-defined monitoring
diff --git a/modules/monitoring-configuring-the-monitoring-stack.adoc b/modules/monitoring-configuring-the-monitoring-stack.adoc
index de67bc88bb..686128f6a7 100644
--- a/modules/monitoring-configuring-the-monitoring-stack.adoc
+++ b/modules/monitoring-configuring-the-monitoring-stack.adoc
@@ -7,10 +7,10 @@
 = Configuring the monitoring stack
 
 ifndef::openshift-dedicated,openshift-rosa[]
-In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
+In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
-In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
+In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
 endif::openshift-dedicated,openshift-rosa[]
 
 .Prerequisites
diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
index 312fe4e191..053fc78929 100644
--- a/modules/monitoring-creating-cluster-monitoring-configmap.adoc
+++ b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
@@ -6,7 +6,7 @@
 [id="creating-cluster-monitoring-configmap_{context}"]
 = Creating a cluster monitoring config map
 
-You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the core components of the monitoring stack.
+You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack.
 
 .Prerequisites
 
diff --git a/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc b/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc
index 8b25118be3..ba8e9a1b79 100644
--- a/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc
+++ b/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc
@@ -6,7 +6,7 @@
 [id="creating-user-defined-workload-monitoring-configmap_{context}"]
 = Creating a user-defined workload monitoring config map
 
-You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the components that monitor user-defined projects.
+You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The {cmo-first} then configures the components that monitor user-defined projects.
 
 [NOTE]
 ====
diff --git a/modules/monitoring-default-monitoring-components.adoc b/modules/monitoring-default-monitoring-components.adoc
index 1b0d93be81..1d89ef78c5 100644
--- a/modules/monitoring-default-monitoring-components.adoc
+++ b/modules/monitoring-default-monitoring-components.adoc
@@ -14,8 +14,8 @@ By default, the {product-title} {product-version} monitoring stack includes thes
 
 |Component|Description
 
-|Cluster Monitoring Operator
-|The Cluster Monitoring Operator (CMO) is a central component of the monitoring stack. It deploys, manages, and automatically updates Prometheus and Alertmanager instances, Thanos Querier, Telemeter Client, and metrics targets. The CMO is deployed by the Cluster Version Operator (CVO).
+|{cmo-full}
+|The {cmo-first} is a central component of the monitoring stack. It deploys, manages, and automatically updates Prometheus and Alertmanager instances, Thanos Querier, Telemeter Client, and metrics targets. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
 
 |Prometheus Operator
 |The Prometheus Operator (PO) in the `openshift-monitoring` project creates, configures, and manages platform Prometheus instances and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
@@ -34,7 +34,7 @@ By default, the {product-title} {product-version} monitoring stack includes thes
 
 |monitoring-plugin
 |The monitoring-plugin dynamic plugin component deploys the monitoring pages in the *Observe* section of the {product-title} web console.
-You can use Cluster Monitoring Operator (CMO) config map settings to manage monitoring-plugin resources for the web console pages.
+You can use {cmo-full} config map settings to manage monitoring-plugin resources for the web console pages.
 
 |openshift-state-metrics agent
 |The openshift-state-metrics exporter (OSM in the preceding diagram) expands upon kube-state-metrics by adding metrics for {product-title}-specific resources.
diff --git a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc
index b221a25ba7..8574cacd48 100644
--- a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc
+++ b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc
@@ -6,8 +6,7 @@
 [id="enabling-query-logging-for-thanos-querier_{context}"]
 = Enabling query logging for Thanos Querier
 
-[role="_abstract"]
-For default platform monitoring in the `openshift-monitoring` project, you can enable the Cluster Monitoring Operator to log all queries run by Thanos Querier.
+For default platform monitoring in the `openshift-monitoring` project, you can enable the {cmo-first} to log all queries run by Thanos Querier.
 
 [IMPORTANT]
 ====
diff --git a/modules/monitoring-maintenance-and-support.adoc b/modules/monitoring-maintenance-and-support.adoc
index f6796901c5..ac299b862a 100644
--- a/modules/monitoring-maintenance-and-support.adoc
+++ b/modules/monitoring-maintenance-and-support.adoc
@@ -5,9 +5,9 @@
 [id="maintenance-and-support_{context}"]
 = Maintenance and support for monitoring
 
-Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the Cluster Monitoring Operator using the options described in the "Config map reference for the Cluster Monitoring Operator". *Do not use other configurations, as they are unsupported.*
+Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the "Config map reference for the {cmo-short}". *Do not use other configurations, as they are unsupported.*
 
-Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the Cluster Monitoring Operator", your changes will disappear because the Cluster Monitoring Operator automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
+Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the {cmo-full}", your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
 
 ifdef::openshift-dedicated,openshift-rosa[]
 [IMPORTANT]
diff --git a/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc b/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc
index ffdc522cdf..64e962f671 100644
--- a/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc
+++ b/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc
@@ -100,7 +100,7 @@ $ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapte
 +
 [NOTE]
 ====
-If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the Cluster Monitoring Operator.
+If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the {cmo-full}.
 ====
 
 . Review the audit log for the Prometheus Adapter:
diff --git a/modules/monitoring-understanding-the-cluster-observability-operator.adoc b/modules/monitoring-understanding-the-cluster-observability-operator.adoc
index 2e4ef53460..90ef7948c8 100644
--- a/modules/monitoring-understanding-the-cluster-observability-operator.adoc
+++ b/modules/monitoring-understanding-the-cluster-observability-operator.adoc
@@ -15,7 +15,7 @@ Each {coo-short} stack also includes an optional Thanos Querier component, which
 
 The `MonitoringStack` CRD used by the {coo-short} offers an opinionated default monitoring configuration for {coo-short}-deployed monitoring components, but you can customize it to suit more complex requirements.
 
-Deploying a {coo-short}-managed monitoring stack can help meet monitoring needs that are difficult or impossible to address by using the core platform monitoring stack deployed by the Cluster Monitoring Operator (CMO).
+Deploying a {coo-short}-managed monitoring stack can help meet monitoring needs that are difficult or impossible to address by using the core platform monitoring stack deployed by the {cmo-first}.
 A monitoring stack deployed using {coo-short} has the following advantages over core platform and user workload monitoring:
 
 Extendability:: Users can add more metrics to a {coo-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
diff --git a/modules/prometheus-database-storage-requirements.adoc b/modules/prometheus-database-storage-requirements.adoc
index 876fd62fda..22bd501e7e 100644
--- a/modules/prometheus-database-storage-requirements.adoc
+++ b/modules/prometheus-database-storage-requirements.adoc
@@ -48,7 +48,7 @@ Red{nbsp}Hat performed various tests for different scale sizes.
 
 Approximately 20 percent of the expected size was added as overhead to ensure that the storage requirements do not exceed the calculated value.
 
-The above calculation is for the default {product-title} Cluster Monitoring Operator.
+The above calculation is for the default {product-title} {cmo-full}.
 
 [NOTE]
 ====
diff --git a/modules/telco-core-monitoring.adoc b/modules/telco-core-monitoring.adoc
index a12408ef32..a7c9f54f88 100644
--- a/modules/telco-core-monitoring.adoc
+++ b/modules/telco-core-monitoring.adoc
@@ -12,7 +12,7 @@ New in this release::
 
 Description::
 
-The Cluster Monitoring Operator is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
+The {cmo-first} is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
 +
 Configuration of the monitoring operator allows for customization, including:
 +
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
index 65d120a726..3d42e9836c 100644
--- a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+++ b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
@@ -17,8 +17,8 @@ The {coo-short} deploys the following monitoring components:
 * Thanos Querier (optional)
 * Alertmanager (optional)
 
-The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the Cluster Monitoring Operator (CMO).
-Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the CMO.
+The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the {cmo-first}.
+Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the {cmo-short}.
 
 include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
 
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc b/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
index 2c5d9a1310..42aebb9acb 100644
--- a/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
+++ b/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
@@ -12,7 +12,7 @@ include::snippets/technology-preview.adoc[leveloffset=+2]
 
 The {coo-first} is an optional {product-title} Operator that enables administrators to create standalone monitoring stacks that are independently configurable for use by different services and users.
 
-The {coo-short} complements the built-in monitoring capabilities of {product-title}. You can deploy it in parallel with the default platform and user workload monitoring stacks managed by the Cluster Monitoring Operator (CMO).
+The {coo-short} complements the built-in monitoring capabilities of {product-title}. You can deploy it in parallel with the default platform and user workload monitoring stacks managed by the {cmo-first}.
 
 These release notes track the development of the {coo-full} in {product-title}.
 
diff --git a/observability/index.adoc b/observability/index.adoc
index fc8b04cfbf..d095b4dcdf 100644
--- a/observability/index.adoc
+++ b/observability/index.adoc
@@ -28,9 +28,9 @@ endif::openshift-dedicated,openshift-rosa[]
 
 [id="monitoring-overview-index"]
 == Monitoring
-Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the Cluster Monitoring Operator.
+Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the {cmo-full}.
 
-Monitoring stack components are deployed by default in every {product-title} installation and are managed by the Cluster Monitoring Operator (CMO). These components include Prometheus, Alertmanager, Thanos Querier, and others. The CMO also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
+Monitoring stack components are deployed by default in every {product-title} installation and are managed by the {cmo-first}. These components include Prometheus, Alertmanager, Thanos Querier, and others. The {cmo-short} also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
 
 For more information, see xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview] and xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring].
 
diff --git a/observability/monitoring/configuring-the-monitoring-stack.adoc b/observability/monitoring/configuring-the-monitoring-stack.adoc
index c1e672f968..5a4915d029 100644
--- a/observability/monitoring/configuring-the-monitoring-stack.adoc
+++ b/observability/monitoring/configuring-the-monitoring-stack.adoc
@@ -22,27 +22,27 @@ and demonstrates several common configuration scenarios.
 [IMPORTANT]
 ====
 Not all configuration parameters for the monitoring stack are exposed.
-Only the parameters and fields listed in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator] are supported for configuration.
+Only the parameters and fields listed in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}] are supported for configuration.
 ====
 
 ifndef::openshift-dedicated,openshift-rosa[]
 == Prerequisites
 
-* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scaling the Cluster Monitoring Operator] and verify that you have sufficient resources.
+* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scaling the {cmo-full}] and verify that you have sufficient resources.
 endif::openshift-dedicated,openshift-rosa[]
 
 // Maintenance and support for monitoring
 // include::modules/monitoring-maintenance-and-support.adoc[leveloffset=+1]
 
 // .Additional resources
-// xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator]
+// xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}]
 
 [id="maintenance-and-support_{context}"]
 == Maintenance and support for monitoring
 
-Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the Cluster Monitoring Operator using the options described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator]. *Do not use other configurations, as they are unsupported.*
+Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}]. *Do not use other configurations, as they are unsupported.*
 
-Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator], your changes will disappear because the Cluster Monitoring Operator automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
+Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}], your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
 
 ifdef::openshift-dedicated,openshift-rosa[]
 [IMPORTANT]
@@ -63,7 +63,7 @@ ifndef::openshift-dedicated,openshift-rosa[]
 [id="preparing-to-configure-the-monitoring-stack"]
 == Preparing to configure the monitoring stack
 
-You can configure the monitoring stack by creating and updating monitoring config maps. These config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the monitoring stack.
+You can configure the monitoring stack by creating and updating monitoring config maps. These config maps configure the {cmo-first}, which in turn configures the components of the monitoring stack.
 
 include::modules/monitoring-creating-cluster-monitoring-configmap.adoc[leveloffset=+2]
 include::modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc[leveloffset=+2]
diff --git a/observability/monitoring/managing-alerts.adoc b/observability/monitoring/managing-alerts.adoc
index 96f7dd9ca4..ca337d87e8 100644
--- a/observability/monitoring/managing-alerts.adoc
+++ b/observability/monitoring/managing-alerts.adoc
@@ -34,7 +34,7 @@ include::modules/monitoring-getting-information-about-alerts-silences-and-alerti
 
 [role="_additional-resources"]
 .Additional resources
-* See the link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[Cluster Monitoring Operator runbooks] to help diagnose and resolve issues that trigger specific {product-title} monitoring alerts.
+* See the link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[{cmo-full} runbooks] to help diagnose and resolve issues that trigger specific {product-title} monitoring alerts.
 
 // Managing silences
 include::modules/monitoring-managing-silences.adoc[leveloffset=+1]
diff --git a/observability/network_observability/network-observability-operator-release-notes.adoc b/observability/network_observability/network-observability-operator-release-notes.adoc
index 0b2876baf3..4286356814 100644
--- a/observability/network_observability/network-observability-operator-release-notes.adoc
+++ b/observability/network_observability/network-observability-operator-release-notes.adoc
@@ -332,7 +332,7 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
 
 [id="network-observability-operator-1.3.0-bug-fixes"]
 === Bug fixes
-* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the Cluster Monitoring Operator to read the metrics were not installed as expected. The issue did not occur when the operator was installed from the web console. Now, either way of installing the Operator installs the required `Role` and `RoleBinding`. (link:https://issues.redhat.com/browse/NETOBSERV-1003[*NETOBSERV-1003*])
+* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the {cmo-full} to read the metrics were not installed as expected. The issue did not occur when the operator was installed from the web console. Now, either way of installing the Operator installs the required `Role` and `RoleBinding`. (link:https://issues.redhat.com/browse/NETOBSERV-1003[*NETOBSERV-1003*])
 
 * Since version 1.2, the Network Observability Operator can raise alerts when a problem occurs with the flows collection. Previously, due to a bug, the related configuration to disable alerts, `spec.processor.metrics.disableAlerts` was not working as expected and sometimes ineffectual. Now, this configuration is fixed so that it is possible to disable the alerts. (link:https://issues.redhat.com/browse/NETOBSERV-976[*NETOBSERV-976*])
 
@@ -340,7 +340,7 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
 
 * Previously, a bug prevented users from setting `spec.consolePlugin.portNaming.enable` to `false`. Now, this setting can be set to `false` to disable port-to-service name translation. (link:https://issues.redhat.com/browse/NETOBSERV-971[*NETOBSERV-971*])
 
-* Previously, the metrics exposed by the console plugin were not collected by the Cluster Monitoring Operator (Prometheus), due to an incorrect configuration. Now the configuration has been fixed so that the console plugin metrics are correctly collected and accessible from the {product-title} web console. (link:https://issues.redhat.com/browse/NETOBSERV-765[*NETOBSERV-765*])
+* Previously, the metrics exposed by the console plugin were not collected by the {cmo-full} (Prometheus), due to an incorrect configuration. Now the configuration has been fixed so that the console plugin metrics are correctly collected and accessible from the {product-title} web console. (link:https://issues.redhat.com/browse/NETOBSERV-765[*NETOBSERV-765*])
 
 * Previously, when `processor.metrics.tls` was set to `AUTO` in the `FlowCollector`, the `flowlogs-pipeline servicemonitor` did not adapt the appropriate TLS scheme, and metrics were not visible in the web console. Now the issue is fixed for AUTO mode. (link:https://issues.redhat.com/browse/NETOBSERV-1070[*NETOBSERV-1070*])
 
diff --git a/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc b/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc
index b57c58758e..cdd9438d4f 100644
--- a/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc
+++ b/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc
@@ -11,9 +11,9 @@ This topic provides recommended performance and scalability practices for infras
 include::modules/infrastructure-node-sizing.adoc[leveloffset=+1]
 
 [id="scaling-cluster-monitoring-operator_{context}"]
-== Scaling the Cluster Monitoring Operator
+== Scaling the {cmo-full}
 
-{product-title} exposes metrics that the Cluster Monitoring Operator collects and stores in the Prometheus-based monitoring stack. As an administrator, you can view dashboards for system resources, containers, and components metrics in the {product-title} web console by navigating to *Observe* -> *Dashboards*.
+{product-title} exposes metrics that the {cmo-first} collects and stores in the Prometheus-based monitoring stack. As an administrator, you can view dashboards for system resources, containers, and components metrics in the {product-title} web console by navigating to *Observe* -> *Dashboards*.
 
 include::modules/prometheus-database-storage-requirements.adoc[leveloffset=+1]