minor edits

Author: micheleRP

modules/manage/pages/disaster-recovery/shadowing/failover-runbook.adoc

@@ -132,9 +132,9 @@ Name: <topic-name>, State: ACTIVE
 
 The partition information shows:
 
-* **SRC_LSO**: Source partition Last Stable Offset
-* **SRC_HWM**: Source partition High Watermark  
-* **DST_HWM**: Shadow (destination) partition High Watermark
+* **SRC_LSO**: Source partition last stable offset
+* **SRC_HWM**: Source partition high watermark  
+* **DST_HWM**: Shadow (destination) partition high watermark
 * **Lag**: Message count difference between source and shadow partitions
 
 [IMPORTANT]

modules/manage/pages/disaster-recovery/shadowing/failover.adoc

@@ -12,6 +12,7 @@ include::shared:partial$enterprise-license.adoc[]
 endif::[]
 
 Failover is the process of modifying shadow topics or an entire shadow cluster from read-only replicas to fully writable resources, and ceasing replication from the source cluster. You can fail over individual topics for selective workload migration or fail over the entire cluster for comprehensive disaster recovery. This critical operation transforms your shadow resources into operational production assets, allowing you to redirect application traffic when the source cluster becomes unavailable.
+
 include::shared:partial$emergency-shadowing-callout.adoc[]
 
 == Failover behavior

modules/manage/pages/disaster-recovery/shadowing/monitor.adoc

@@ -12,6 +12,7 @@ include::shared:partial$enterprise-license.adoc[]
 endif::[]
 
 Monitor your shadow links to ensure proper replication performance and understand your disaster recovery readiness. Use `rpk` commands, metrics, and status information to track shadow link health and troubleshoot issues.
+
 include::shared:partial$emergency-shadowing-callout.adoc[]
 
 == Status commands
@@ -52,10 +53,10 @@ For troubleshooting specific issues, you can use command options to show individ
 
 The status output includes:
 
-* **Shadow link state**: Overall operational state (`ACTIVE`)
-* **Individual topic states**: Current state of each replicated topic (`ACTIVE`, `FAULTED`, `FAILING_OVER`, `FAILED_OVER`)
+* **Shadow link state**: Overall operational state (`ACTIVE`).
+* **Individual topic states**: Current state of each replicated topic (`ACTIVE`, `FAULTED`, `FAILING_OVER`, `FAILED_OVER`).
 * **Task status**: Health of replication tasks across brokers (`ACTIVE`, `FAULTED`, `NOT_RUNNING`, `LINK_UNAVAILABLE`). For details about shadow link tasks, see xref:manage:disaster-recovery/shadowing/setup.adoc#shadow-link-tasks[Shadow link tasks].
-* **Lag information**: Replication lag per partition showing source vs shadow high watermarks (HWM)
+* **Lag information**: Replication lag per partition showing source vs shadow high watermarks (HWM).
 
 [[shadow-link-metrics]]
 == Metrics

modules/manage/pages/disaster-recovery/shadowing/overview.adoc

@@ -52,7 +52,7 @@ Shadowing for disaster recovery currently has the following limitations:
 * During a disaster, xref:manage:audit-logging.adoc[audit log] history from the source cluster is lost, though the shadow cluster begins generating new audit logs immediately after the failover.
 * After you failover shadow topics, automatic fallback to the original source cluster is not supported.
 
-== Best Practices
+== Best practices
 
 To ensure reliable disaster recovery with Shadowing:
 

modules/manage/pages/disaster-recovery/shadowing/setup.adoc

@@ -9,7 +9,7 @@ ifndef::env-cloud[]
 include::shared:partial$shadow-link-management-tip.adoc[]
 endif::[]
 
-ifndef::env-cloud[]
+ifdef::env-cloud[]
 include::shared:partial$shadow-link-cloud-tip.adoc[]
 endif::[]
 
@@ -116,14 +116,14 @@ To set up Shadowing:
 * **Configure filters**: Define which topics, consumer groups, and ACLs should replicate by creating include/exclude patterns that match your disaster recovery requirements. See <<set-filters>>.
 * **Create a shadow link**: Establish the connection between clusters using `rpk`, the Admin API, or Redpanda Console with authentication and network settings. See <<create-a-shadow-link>>.
 
-== Shadow Link Tasks
+== Shadow link tasks
 
 Shadow linking operates through specialized tasks that handle different aspects of replication. Each task corresponds to a configuration section in your shadow link setup and runs continuously to maintain synchronization with the source cluster.
 
 [#source-topic-sync-task]
-=== Source Topic Sync Task
+=== Source Topic Sync task
 
-The **Source Topic Sync Task** manages topic discovery and metadata synchronization. This task periodically queries the source cluster to discover available topics, applies your configured topic filters to determine which topics should become shadow topics, and synchronizes topic properties between clusters.
+The **Source Topic Sync task** manages topic discovery and metadata synchronization. This task periodically queries the source cluster to discover available topics, applies your configured topic filters to determine which topics should become shadow topics, and synchronizes topic properties between clusters.
 
 The task is controlled by the `topic_metadata_sync_options` configuration section, which includes:
 
@@ -135,7 +135,7 @@ The task is controlled by the `topic_metadata_sync_options` configuration sectio
 When this task discovers a new topic that matches your filters, it creates the corresponding shadow topic and begins replication from your configured starting offset.
 
 [#consumer-group-shadowing-task]
-=== Consumer Group Shadowing Task
+=== Consumer Group Shadowing task
 
 The **Consumer Group Shadowing task** replicates consumer group offsets and membership information from the source cluster. This ensures that consumer applications can resume processing from the correct position after failover.
 
@@ -148,9 +148,9 @@ The task is controlled by the `consumer_offset_sync_options` configuration secti
 This task runs on brokers that host the `__consumer_offsets` topic and continuously tracks consumer group coordinators to optimize offset synchronization.
 
 [#security-migrator-task]
-=== Security Migrator Task
+=== Security Migrator task
 
-The **Security Migrator task** replicates security policies, primarily ACLs (Access Control Lists), from the source cluster to maintain consistent authorization across both environments.
+The **Security Migrator task** replicates security policies, primarily ACLs (access control lists), from the source cluster to maintain consistent authorization across both environments.
 
 The task is controlled by the `security_sync_options` configuration section, which includes:
 
@@ -159,7 +159,7 @@ The task is controlled by the `security_sync_options` configuration section, whi
 
 By default, all ACLs replicate to ensure your shadow cluster maintains the same security posture as your source cluster.
 
-=== Task Status and Monitoring
+=== Task status and monitoring
 
 Each task reports its status through the shadow link status API. Task states include:
 
@@ -218,7 +218,7 @@ The filtering system you configure determines the precise scope of replication a
 
 Filters determine which resources Shadowing automatically creates when establishing your shadow link.
 
-Topic filters select which topics Shadowing automatically creates as shadow topics when they appear on the source cluster. Once Shadowing creates a shadow topic, it continues replicating until you failover the topic, delete it, or delete the entire shadow link.
+Topic filters select which topics Shadowing automatically creates as shadow topics when they appear on the source cluster. After Shadowing creates a shadow topic, it continues replicating until you failover the topic, delete it, or delete the entire shadow link.
 
 Consumer group and ACL filters control which groups and security policies replicate to maintain application functionality.
 
@@ -300,7 +300,7 @@ schema_registry_sync_options:
 - The `_schemas` topic must not exist on the shadow cluster, or must be empty
 - Once enabled, the `_schemas` topic will be replicated completely
 
-**Important:** Once the `_schemas` topic becomes a shadow topic, it cannot be stopped without either failing over the topic or deleting it entirely.
+**Important:** After the `_schemas` topic becomes a shadow topic, it cannot be stopped without either failing over the topic or deleting it entirely.
 
 
 === System topic filtering rules
@@ -402,7 +402,7 @@ topic_metadata_sync_options:
 
 [IMPORTANT]
 ====
-The starting offset only affects **new shadow topics**. Once a shadow topic exists and has data, changing this setting has no effect on that topic's replication.
+The starting offset only affects **new shadow topics**. After a shadow topic exists and has data, changing this setting has no effect on that topic's replication.
 ====
 
 === Generate a sample configuration