diff --git a/docs/1_introduction/deployment_decision_guide/0_assess_readiness.md b/docs/1_introduction/deployment_decision_guide/0_assess_readiness.md
index 9a032f3..77d981e 100644
--- a/docs/1_introduction/deployment_decision_guide/0_assess_readiness.md
+++ b/docs/1_introduction/deployment_decision_guide/0_assess_readiness.md
@@ -7,28 +7,28 @@ nav_order: 1
 description: Covers the technical prerequisites an STLT must meet before beginning NBS 7 migration, including cloud, staffing, and network requirements.
 ---
 
-## Assess your readiness for NBS 7
+# Assess your readiness for NBS 7
 {: .no_toc }
 
 This section helps you assess whether NBS 7 is a viable option for your jurisdiction before you commit to a migration. Some prerequisites in this section are also covered in the **NBS 7 Migration Info Sheet**. If your jurisdiction has already begun the migration process, use that document alongside this one.
 
-{: .note }
-**Health department leaders:** For key considerations on migration planning, staffing, and budget, see [Leadership considerations](leadership_considerations.html).
-
-If you work through this section and find that your jurisdiction does not meet one or more prerequisites, you might still be able to move forward. You can address some gaps with planning and lead time, but other gaps might indicate that NBS 7 is not the right fit for your jurisdiction right now.
+## On this page
+{: .no_toc .text-delta }
 
 1. TOC
 {:toc}
 
----
+If you work through this section and find that your jurisdiction does not meet one or more prerequisites, you might still be able to move forward. You can address some gaps with planning and lead time, but other gaps might indicate that NBS 7 is not the right fit for your jurisdiction right now.
+
+For more information on migration planning, staffing, and budget, see [Operational considerations](leadership_considerations.html).
+{: .note }
 
 ## State IT security approval
 
 Has your jurisdiction obtained state IT security approval for cloud hosting and the software technologies that NBS 7 requires, including Kubernetes, Terraform, and Docker?
 
 - **Yes, or approval is not required** — Continue with the rest of this section.
-- **No, or unknown** — Begin the approval process now. Approval timelines vary and can significantly affect your migration schedule. Work with your state IT office while you continue planning.
-
+- **No, or unknown** — Approval timelines vary and can significantly affect your migration schedule. We recommend working with your state IT office while you continue to plan.
 
 ## Cloud infrastructure
 
@@ -39,7 +39,6 @@ You need an active account with a supported cloud provider:
 - **Amazon Web Services (AWS)** — The primary supported option. NBS 7 has been fully tested on AWS.
 - **Microsoft Azure** — Supported via Terraform. Use this option if your jurisdiction has an existing Azure commitment or a compliance requirement that mandates Azure.
 
-
 ## Technical staff capacity
 
 NBS 7 uses Kubernetes, a container orchestration platform. To deploy and maintain NBS 7, you need staff who can:
@@ -51,9 +50,8 @@ NBS 7 uses Kubernetes, a container orchestration platform. To deploy and maintai
 
 If your IT team does not have these skills, you have two options:
 
-- **Build capacity** — Train existing staff or hire staff with these skills before you begin deployment.
-- **Use a vendor** — Contract with a vendor to deploy or manage your NBS 7 infrastructure. See [Vendor-managed deployment](1_choose_configuration/3_vendor_managed_deployment.html) for guidance on what to look for in a vendor.
-
+- **Building capacity** — Train existing staff or hire staff with these skills before you begin deployment.
+- **Working with a vendor** — Contract with a vendor to deploy or manage your NBS 7 infrastructure. See [Vendor-managed deployment](1_choose_configuration/3_vendor_managed_deployment.html) for guidance on what to look for in a vendor.
 
 ## Network readiness
 
@@ -67,7 +65,6 @@ Before deployment, your network must meet the following requirements:
 
 Your specific network configuration will depend on your cloud provider and the existing infrastructure for your jurisdiction.
 
-
 ## NBS 6 status
 
 During migration, NBS 7 components gradually replace NBS 6 functionality while NBS 6 continues to run. This means:
@@ -77,10 +74,9 @@ During migration, NBS 7 components gradually replace NBS 6 functionality while N
 - You need to know your current NBS 6 hosting setup before you begin — specifically, whether it is hosted on-premises or in the cloud, and if in the cloud, which provider.
 - **You must be running NBS 6.0.16.1 or higher** before you can install any version of NBS 7. Verify your current NBS 6 version before you begin planning your migration timeline.
 
-
 ## CDC coordination
 
-Contact your CDC NBS point of contact before you begin deployment. CDC provides deployment support at no cost and can help you:
+Reach out to your CDC NBS point of contact before you begin deployment. CDC provides deployment support at no cost and can help you:
 
 - Validate your technical readiness
 - Identify the right configuration for your jurisdiction
diff --git a/docs/1_introduction/deployment_decision_guide/1_choose_configuration.md b/docs/1_introduction/deployment_decision_guide/1_choose_configuration.md
index a583f73..490dda3 100644
--- a/docs/1_introduction/deployment_decision_guide/1_choose_configuration.md
+++ b/docs/1_introduction/deployment_decision_guide/1_choose_configuration.md
@@ -8,8 +8,15 @@ has_children: true
 description: Guides STLT administrators through the NBS 7 configuration options and helps identify the right starting configuration for their jurisdiction.
 ---
 
-## Choose your NBS 7 configuration
+# Choose your NBS 7 configuration
 {: .no_toc }
 
-NBS 7 is modular. Rather than a single fixed system, it is a set of components that you assemble based on the size, technical capacity, and public health needs of your jurisdiction. The following sections help you understand your options and identify the right starting configuration for your jurisdiction.
+<!--
+## On this page
+{: .no_toc .text-delta }
 
+1. TOC
+{:toc}
+-->
+
+You can deploy the base NBS 7 product on its own, or with optional add-ons based on the size, technical capacity, and public health needs of your jurisdication. The following pages help you understand your options and identify the right starting point for your needs.
diff --git a/docs/1_introduction/deployment_decision_guide/1_choose_configuration/1_configuration_tiers.md b/docs/1_introduction/deployment_decision_guide/1_choose_configuration/1_configuration_tiers.md
index b4e57a3..5c40ae0 100644
--- a/docs/1_introduction/deployment_decision_guide/1_choose_configuration/1_configuration_tiers.md
+++ b/docs/1_introduction/deployment_decision_guide/1_choose_configuration/1_configuration_tiers.md
@@ -1,31 +1,34 @@
 ---
-title: Configuration tiers
+title: NBS 7 and available add-ons
 layout: page
 parent: Choose your configuration
 grand_parent: NBS 7 Deployment Decision Guide
 nav_order: 1
-description: Describes the four NBS 7 configuration tiers — NBS Core, Core + RTR, Core + DI API, and NBS Complete — and when each is appropriate.
+description: Describes NBS 7 and its two optional add-ons — Real-Time Reporting (RTR) and the Data Ingestion (DI) API — and when each is appropriate.
 ---
 
-## NBS 7 configuration tiers
+# NBS 7 and available add-ons
 {: .no_toc }
 
-This section describes the four ways to deploy NBS 7. You do not have to deploy everything at once. Most jurisdictions will start with NBS Core, then add RTR or the DI API as their team builds confidence with the platform. Starting smaller reduces deployment risk and gives your team time to learn the system before taking on additional complexity.
+NBS 7 is the base product. Two optional add-ons are available: Real-Time Reporting (RTR) and the Data Ingestion (DI) API. You do not have to deploy add-ons at the outset. Most jurisdictions deploy NBS 7 first, then evaluate add-ons as their team builds confidence with the platform. Starting without add-ons reduces deployment risk and gives your team time to learn the system before taking on additional complexity.
+
+## On this page
+{: .no_toc .text-delta }
 
 1. TOC
 {:toc}
 
-After you review the configuration tiers, use the [decision tree](2_decision_tree.html) to identify your recommended starting configuration. If your jurisdiction plans to use a vendor, see the [Vendor-managed deployment](3_vendor_managed_deployment.html) page.
+After you review the available options, use the [decision tree](2_decision_tree.html) to identify your recommended starting configuration. If your jurisdiction plans to use a vendor, see the [Vendor-managed deployment](3_vendor_managed_deployment.html) page.
 
 ---
 
-### NBS Core
+## NBS 7
 
-The minimum viable deployment. NBS Core gives your jurisdiction NBS 6 feature parity on modern, cloud-based infrastructure, plus foundational NBS 7 improvements such as real-time patient search.
+The base deployment. NBS 7 gives your jurisdiction NBS 6 feature parity on modern, cloud-based infrastructure, plus foundational improvements such as real-time patient search.
 
-NBS Core components are organized into three layers. For details on what each component does and when you need it, see [NBS Core components](../3_component_reference/1_nbs_core_components.html).
+NBS 7 core components are organized into three layers. For details on what each component does and when you need it, see [NBS 7 core components](../3_component_reference/1_nbs_core_components.html).
 
-**Networking layer**
+### Networking layer
 
 The networking layer manages traffic routing and secure communication between your NBS 6 and NBS 7 environments.
 
@@ -33,7 +36,7 @@ The networking layer manages traffic routing and secure communication between yo
 - Virtual Private Cloud (VPC) and routing groups
 - VPN connectivity between NBS 6 and NBS 7 instances
 
-**Infrastructure layer**
+### Infrastructure layer
 
 The infrastructure layer provides the container orchestration platform and cloud services that host and run NBS 7 components.
 
@@ -43,7 +46,7 @@ The infrastructure layer provides the container orchestration platform and cloud
 - Terraform infrastructure automation modules
 - Load balancer
 
-**Application layer**
+### Application layer
 
 The application layer contains the NBS 7 services and legacy NBS 6 components that users and administrators directly interact with.
 
@@ -65,13 +68,13 @@ The application layer contains the NBS 7 services and legacy NBS 6 components th
 
 ---
 
-### NBS Core + Real-Time Reporting (RTR)
+## Add-on: Real-Time Reporting (RTR)
 
-Core plus modern analytics. This configuration adds the Real-Time Reporting (RTR) pipeline, which we recommend using alongside the legacy MasterETL batch process during transition, with the goal of eventually replacing it.
+RTR is an optional add-on that replaces the legacy MasterETL batch process with an event-driven reporting pipeline. We recommend running RTR alongside MasterETL during transition, with the goal of eventually replacing it.
 
 **With RTR, data is available within 5 minutes to 1 hour instead of 24 hours.**
 
-RTR adds the following components. For details, see [Add-on: Real-Time Reporting (RTR)](../3_component_reference/2_rtr.html).
+RTR adds the following components to your NBS 7 deployment. For details, see [Add-on: Real-Time Reporting (RTR)](../3_component_reference/2_rtr.html).
 
 - [Debezium](../3_component_reference/2_rtr.html#debezium)
 - [Kafka and Kafka Connect](../3_component_reference/2_rtr.html#kafka-and-kafka-connect)
@@ -85,9 +88,9 @@ RTR adds the following components. For details, see [Add-on: Real-Time Reporting
 
 ---
 
-### NBS Core + Data Ingestion (DI) API
+## Add-on: Data Ingestion (DI) API
 
-Core plus a built-in data transit layer. This configuration adds the Data Ingestion (DI) API, which accepts incoming public health data in multiple formats and routes it into NBS without requiring third-party middleware.
+The DI API is an optional add-on that provides a built-in data transit layer. It accepts incoming public health data in multiple formats and routes it into NBS without requiring third-party middleware.
 
 For details, see [Add-on: Data Ingestion (DI) API](../3_component_reference/3_di_api.html).
 
@@ -95,15 +98,3 @@ For details, see [Add-on: Data Ingestion (DI) API](../3_component_reference/3_di
 > Best for
 >
 > Jurisdictions that do not currently use Rhapsody or Mirth Connect for data ingestion, and want a built-in path for getting data into NBS 7.
-
----
-
-### NBS Complete
-
-The full NBS 7 deployment. NBS Complete includes NBS Core, RTR, and the DI API.
-
-{: .note-title }
-> Best for
->
-> Jurisdictions with larger IT teams, high case volumes, and advanced reporting or analytics needs.
-
diff --git a/docs/1_introduction/deployment_decision_guide/1_choose_configuration/2_decision_tree.md b/docs/1_introduction/deployment_decision_guide/1_choose_configuration/2_decision_tree.md
index 92cb48d..98d4857 100644
--- a/docs/1_introduction/deployment_decision_guide/1_choose_configuration/2_decision_tree.md
+++ b/docs/1_introduction/deployment_decision_guide/1_choose_configuration/2_decision_tree.md
@@ -7,82 +7,83 @@ nav_order: 2
 description: A step-by-step decision tree that guides jurisdictions to a recommended NBS 7 starting configuration based on hosting model, capacity, and case volume.
 ---
 
-## NBS 7 configuration decision tree
+# NBS 7 configuration decision tree
 {: .no_toc }
 
 Use the decision tree to identify your recommended starting configuration. Answer each question in order, then validate your recommendation with the CDC NBS team before you begin deployment.
 
+## On this page
+{: .no_toc .text-delta }
+
 1. TOC
 {:toc}
 
-
 {: .important }
-The decision tree identifies a recommended starting point, not a final answer. CDC provides free pre-deployment consultation to help jurisdictions validate their configuration choice. Do not begin deployment without first connecting with the CDC NBS team at [nbs@cdc.gov](mailto:nbs@cdc.gov).
-
+The decision tree identifies a recommended starting point, not a final answer. CDC provides free pre-deployment consultation to help jurisdictions validate their configuration choice. Connect with the CDC NBS team at [nbs@cdc.gov](mailto:nbs@cdc.gov) before you begin deployment.
 
-### Step 1: Hosting model
+## Step 1: Hosting model
 
 Is your jurisdiction planning to self-host and self-maintain NBS 7, or will you use a vendor to host or maintain it?
 
-- **Self-hosted, self-maintained** — Go to [Step 2](#step-2-state-it-security-approval).
-- **Vendor-hosted or vendor-maintained** — Go to [Vendor-managed deployment](3_vendor_managed_deployment.html).
+- **Self-hosted, self-maintained** → Go to [Step 2](#step-2-state-it-security-approval).
+- **Vendor-hosted or vendor-maintained** → Go to [Vendor-managed deployment](3_vendor_managed_deployment.html).
 
-### Step 2: State IT security approval
+## Step 2: State IT security approval
 
 Has your jurisdiction obtained state IT security approval for cloud hosting and the required software technologies (Kubernetes, Terraform, Docker)?
 
-- **Yes, or approval is not required** — Go to [Step 3](#step-3-internal-technical-capacity).
-- **No, or unknown** — Begin the approval process now, then continue planning. Approval is required before deployment. Go to [Step 3](#step-3-internal-technical-capacity).
+- **Yes, or approval is not required** → Go to [Step 3](#step-3-internal-technical-capacity).
+- **No, or unknown** → Begin the approval process now, then continue planning. Approval is required before deployment. Go to [Step 3](#step-3-internal-technical-capacity).
 
-### Step 3: Internal technical capacity
+## Step 3: Internal technical capacity
 
 Does your jurisdiction have IT staff with skills in Kubernetes, Terraform, and cloud infrastructure management, roughly half or more of the required skill set?
 
-- **Yes** — Go to [Step 4](#step-4-current-nbs-6-hosting).
-- **No** — Go to [Step 3a](#step-3a-external-assistance).
+- **Yes** → Go to [Step 4](#step-4-current-nbs-6-hosting).
+- **No** → Go to [Step 3a](#step-3a-external-assistance).
 
-### Step 3a: External assistance
+## Step 3a: External assistance
 
 Will your jurisdiction obtain external assistance from a contractor, vendor, or consultant for deployment and ongoing maintenance?
 
-- **Yes** — Go to [Step 4](#step-4-current-nbs-6-hosting). Note that your vendor or contractor must be capable of Kubernetes-based deployments on AWS or Azure. See [Vendor-managed deployment](3_vendor_managed_deployment.html) for what to look for.
-- **No** — **Stop.** Build internal capacity or identify a vendor before proceeding. Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) for support resources.
+- **Yes** → Go to [Step 4](#step-4-current-nbs-6-hosting). Note that your vendor or contractor must be capable of Kubernetes-based deployments on AWS or Azure. See [Vendor-managed deployment](3_vendor_managed_deployment.html) for what to look for.
+- **No** → **Stop.** Build internal capacity or identify a vendor before proceeding. Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) for support resources.
 
-### Step 4: Current NBS 6 hosting
+## Step 4: Current NBS 6 hosting
 
 Where does your NBS 6 currently run?
 
-- **Already on AWS** — Lowest migration complexity. Go to [Step 5](#step-5-case-volume).
-- **Already on Azure** — Low migration complexity; you will follow the Azure-specific deployment path. Go to [Step 5](#step-5-case-volume).
-- **On-premises** — Your migration includes a cloud migration as well as an NBS 7 deployment. Plan for additional time and resources. Go to [Step 5](#step-5-case-volume).
+- **Already on AWS** → Lowest migration complexity. Go to [Step 5](#step-5-case-volume).
+- **Already on Azure** → Low migration complexity; you will follow the Azure-specific deployment path. Go to [Step 5](#step-5-case-volume).
+- **On-premises** → Your migration includes a cloud migration as well as an NBS 7 deployment. Plan for additional time and resources. Go to [Step 5](#step-5-case-volume).
 
-### Step 5: Case volume
+## Step 5: Case volume
 
 What is the approximate annual reportable disease case volume in your jurisdiction?
 
-- **Lower volume** (fewer than approximately 50,000 cases per year) — Go to [Step 6](#step-6-data-intake-needs-lower-volume-jurisdictions).
-- **Higher volume** (50,000+ cases per year), or significant growth expected — Go to [Step 7](#step-7-reporting-needs-higher-volume-jurisdictions).
+- **Lower volume** (fewer than approximately 50,000 cases per year) → Go to [Step 6](#step-6-data-intake-needs-lower-volume-jurisdictions).
+- **Higher volume** (50,000+ cases per year), or significant growth expected → Go to [Step 7](#step-7-reporting-needs-higher-volume-jurisdictions).
 
 {: .note }
 The 50,000 case threshold is a planning guideline, not a hard rule. Validate your volume assessment with CDC before making a final configuration decision.
 
-### Step 6: Data intake needs (lower-volume jurisdictions)
+## Step 6: Data intake needs (lower-volume jurisdictions)
 
 Does your jurisdiction currently receive high volumes of electronic lab reports (ELRs) or electronic case reports (eCRs)?
 
-- **No** — Recommended configuration: **NBS Core**. Validate with CDC before deploying.
-- **Yes** — Recommended configuration: **NBS Core + DI API**. Validate with CDC before deploying.
+- **No** → Recommended starting point: **NBS 7**. Validate with CDC before deploying.
+- **Yes** → Recommended starting point: **NBS 7 + DI API add-on**. Validate with CDC before deploying.
 
-### Step 7: Reporting needs (higher-volume jurisdictions)
+## Step 7: Reporting needs (higher-volume jurisdictions)
 
-Does your jurisdiction need near-real-time reporting — data available within minutes to hours, rather than 24 hours?
+Does your jurisdiction need near-real-time reporting → data available within minutes to hours, rather than 24 hours?
 
-- **No** — Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) to discuss your specific needs. **NBS Core or NBS Core + DI API** may be appropriate starting points.
-- **Yes** — Go to [Step 8](#step-8-data-intake-needs-higher-volume-jurisdictions).
+- **No** → Contact [nbs@cdc.gov](mailto:nbs@cdc.gov) to discuss your specific needs. **NBS 7** or **NBS 7 + DI API add-on** might be appropriate starting points.
+- **Yes** → Go to [Step 8](#step-8-data-intake-needs-higher-volume-jurisdictions).
 
-### Step 8: Data intake needs (higher-volume jurisdictions)
+## Step 8: Data intake needs (higher-volume jurisdictions)
 
 Does your jurisdiction currently receive high volumes of ELRs or eCRs?
 
-- **No** — Recommended configuration: **NBS Core + RTR**. Validate with CDC before deploying.
-- **Yes** — Recommended configuration: **NBS Complete**. Validate with CDC before deploying.
+- **No** → Recommended starting point: **NBS 7 + RTR add-on**. Validate with CDC before deploying.
+- **Yes** → Recommended starting point: **NBS 7 + RTR + DI API add-ons**. Validate with CDC before deploying.
diff --git a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7.md b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7.md
index de25441..8a1091b 100644
--- a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7.md
+++ b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7.md
@@ -11,11 +11,9 @@ description: Presents example NBS 7 deployment scenarios for small, medium, and
 # Deploy NBS 7
 {: .no_toc }
 
-The following sections cover actual NBS 7 deployment scenarios as example use cases. No two jurisdictions have identical infrastructure, staffing, or data needs, so your configuration will not match any of these exactly. Use the examples to identify which profile is closest to your situation and to understand the tradeoffs that other jurisdictions encountered.
+The pages in this section cover actual NBS 7 deployment scenarios as example use cases. No two jurisdictions have identical infrastructure, staffing, or data needs, so your configuration will not match any of these exactly. Use the examples to identify which profile is closest to your situation and to understand the tradeoffs that other jurisdictions encountered.
 
 1. TOC
 {:toc}
 
 After you have chosen your configuration, use the [**NBS 7 System Administrator Guide**](https://cdcgov.github.io/NEDSS-SystemAdminGuide/) for step-by-step deployment instructions.
-
-
diff --git a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/2_medium_jurisdiction.md b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/2_medium_jurisdiction.md
index dc544c4..bc01a67 100644
--- a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/2_medium_jurisdiction.md
+++ b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/2_medium_jurisdiction.md
@@ -15,8 +15,7 @@ description: Case study for a medium jurisdiction with existing Rhapsody middlew
 1. TOC
 {:toc}
 
---- 
-
+---
 
 ### Profile
 
diff --git a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/3_large_jurisdiction.md b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/3_large_jurisdiction.md
index b4d3c03..aef0c93 100644
--- a/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/3_large_jurisdiction.md
+++ b/docs/1_introduction/deployment_decision_guide/2_deploy_nbs7/3_large_jurisdiction.md
@@ -15,8 +15,7 @@ description: Case study for a large, vendor-managed NBS Complete deployment at e
 1. TOC
 {:toc}
 
---- 
-
+---
 
 ### Profile
 
diff --git a/docs/1_introduction/deployment_decision_guide/3_component_reference.md b/docs/1_introduction/deployment_decision_guide/3_component_reference.md
index 2f82350..1d58bd3 100644
--- a/docs/1_introduction/deployment_decision_guide/3_component_reference.md
+++ b/docs/1_introduction/deployment_decision_guide/3_component_reference.md
@@ -5,17 +5,17 @@ parent: NBS 7 Deployment Decision Guide
 grand_parent: Introduction
 nav_order: 4
 has_children: true
-description: Describes each component in NBS 7 — what it does, when it is needed, and how it relates to other components — organized by configuration tier.
+description: Describes each NBS 7 component — what it does, when it is needed, and how it relates to other components — organized by NBS 7 core components and available add-ons.
 ---
 
-## NBS 7 component reference
+# NBS 7 component reference
 {: .no_toc }
 
-The pages in this section describes each component in NBS 7. Use it to understand what each component does, why it is included in your configuration, and how it relates to other components.
+The pages in this section describe each component in NBS 7. Use it to understand what each component does, why it is included in your deployment, and how it relates to other components.
 
-Components in this reference are organized by configuration tier:
+Components in this reference are organized by deployment scope:
 
-- [NBS Core components](3_component_reference/1_nbs_core_components/)
+- [NBS 7 core components](3_component_reference/1_nbs_core_components/)
 - [Add-on: Real-Time Reporting (RTR)](3_component_reference/2_rtr/)
 - [Add-on: Data Ingestion (DI) API](3_component_reference/3_di_api/)
 
@@ -25,25 +25,25 @@ For deployment configuration details including configuration parameters, Helm ch
 
 ## Quick reference
 
-The following table shows which components are included in each configuration tier.
-
-| Component | NBS Core | Core + RTR | Core + DI API | NBS Complete |
-|:---|:---:|:---:|:---:|:---:|
-| Legacy NBS 6 | ✓ | ✓ | ✓ | ✓ |
-| NBS Modernization API | ✓ | ✓ | ✓ | ✓ |
-| NBS Web UI | ✓ | ✓ | ✓ | ✓ |
-| NBS Gateway | ✓ | ✓ | ✓ | ✓ |
-| Page Builder | ✓ | ✓ | ✓ | ✓ |
-| Elasticsearch | ✓ | ✓ | ✓ | ✓ |
-| Nifi | ✓ | ✓ | ✓ | ✓ |
-| Keycloak | ✓ | ✓ | ✓ | ✓ |
-| Database (NBS\_ODSE, NBS\_SRTE) | ✓ | ✓ | ✓ | ✓ |
-| Infrastructure and networking layer | ✓ | ✓ | ✓ | ✓ |
-| Debezium | | ✓ | | ✓ |
-| Kafka and Kafka Connect | | ✓ | | ✓ |
-| RTR domain services | | ✓ | | ✓ |
-| RDB\_Modern | | ✓ | | ✓ |
-| DI API | | | ✓ | ✓ |
-
-> NBS Core components are required for all NBS 7 deployments. RTR and DI API are optional add-ons, so their components are only required if your jurisdiction chooses a configuration tier that includes them.
+The following table shows which components are included in NBS 7 and its available add-ons.
+
+| Component | NBS 7 | + RTR add-on | + DI API add-on |
+|:---|:---:|:---:|:---:|
+| Legacy NBS 6 | ✓ | ✓ | ✓ |
+| NBS Modernization API | ✓ | ✓ | ✓ |
+| NBS Web UI | ✓ | ✓ | ✓ |
+| NBS Gateway | ✓ | ✓ | ✓ |
+| Page Builder | ✓ | ✓ | ✓ |
+| Elasticsearch | ✓ | ✓ | ✓ |
+| Nifi | ✓ | ✓ | ✓ |
+| Keycloak | ✓ | ✓ | ✓ |
+| Database (NBS\_ODSE, NBS\_SRTE) | ✓ | ✓ | ✓ |
+| Infrastructure and networking layer | ✓ | ✓ | ✓ |
+| Debezium | | ✓ | |
+| Kafka and Kafka Connect | | ✓ | |
+| RTR domain services | | ✓ | |
+| RDB\_Modern | | ✓ | |
+| DI API | | | ✓ |
+
+> NBS 7 core components are required for all deployments. RTR and DI API are optional add-ons. Components for the add-ons are only required if your jurisdiction chooses to include them.
 {: .note }
diff --git a/docs/1_introduction/deployment_decision_guide/3_component_reference/1_nbs_core_components.md b/docs/1_introduction/deployment_decision_guide/3_component_reference/1_nbs_core_components.md
index a3acc56..0dad7f7 100644
--- a/docs/1_introduction/deployment_decision_guide/3_component_reference/1_nbs_core_components.md
+++ b/docs/1_introduction/deployment_decision_guide/3_component_reference/1_nbs_core_components.md
@@ -1,31 +1,32 @@
 ---
-title: NBS Core components
+title: NBS 7 core components
 layout: page
 parent: Component reference
 grand_parent: NBS 7 Deployment Decision Guide
 nav_order: 1
-description: Details each component in NBS Core — the application, infrastructure, and networking layers required for all NBS 7 deployments.
+description: Details each component in NBS 7 — the application, infrastructure, and networking layers required for all NBS 7 deployments.
 ---
 
-## Component reference: NBS Core
+# Component reference: NBS 7 core components
 {: .no_toc }
 
-NBS Core includes three layers of components: the application layer, the infrastructure layer, and the networking layer. The application layer components are documented individually below. [Infrastructure and networking layer components](#infrastructure-and-networking-layer-components) are summarized as a group.
+For information on migration planning, staffing, and budget, see [Operational considerations](leadership_considerations.html).
+{: .note }
 
-1. TOC
-{:toc}
+NBS 7 core components are organized into three layers: the application layer, the infrastructure layer, and the networking layer. The application layer components are documented individually below. [Infrastructure and networking layer components](#infrastructure-and-networking-layer-components) are summarized as a group.
 
---- 
+\[architecture diagram\]
 
+## On this page
+{: .no_toc .text-delta }
 
-\[architecture diagram\]
+1. TOC
+{:toc}
 
 > The NBS Modernization API, NBS Web UI, NBS Gateway, and Page Builder are deployed together from the NEDSS-Modernization repository. Each serves a distinct function, but vendors and admins scoping deployment work should be aware that they share a single deployment unit.
-{: .note }
+{: .important }
 
----
-
-### Legacy NBS 6
+## Legacy NBS 6
 
 The existing NBS 6 application. A WildFly-based UI and backend that most STLTs currently run.
 
@@ -35,9 +36,7 @@ The existing NBS 6 application. A WildFly-based UI and backend that most STLTs c
 | When you need it | Always. An operational NBS 6 instance is a prerequisite for any NBS 7 deployment. You must be running NBS 6.0.16.1 or newer before installing NBS 7. |
 | Dependencies | Required by NBS Gateway, Elasticsearch (via Nifi), and the NBS Modernization API. Must maintain network connectivity to your NBS 7 environment throughout the migration period. |
 
----
-
-### NBS Modernization API
+## NBS Modernization API
 
 The modern backend API layer for NBS 7, built to replace NBS 6 functionality incrementally.
 
@@ -47,9 +46,7 @@ The modern backend API layer for NBS 7, built to replace NBS 6 functionality inc
 | When you need it | Always. The Modernization API is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires Legacy NBS 6 and NBS Gateway. Exposes functionality to the NBS Web UI. |
 
----
-
-### NBS Web UI
+## NBS Web UI
 
 The modern React/TypeScript frontend for NBS 7 features.
 
@@ -59,9 +56,7 @@ The modern React/TypeScript frontend for NBS 7 features.
 | When you need it | Always. The NBS Web UI is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires NBS Gateway and the NBS Modernization API. |
 
----
-
-### NBS Gateway
+## NBS Gateway
 
 A routing service (built on Spring Cloud Gateway) that manages traffic between the legacy NBS 6 application and modern NBS 7 services.
 
@@ -71,9 +66,7 @@ A routing service (built on Spring Cloud Gateway) that manages traffic between t
 | When you need it | Always. NBS Gateway is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires Legacy NBS 6, the NBS Modernization API, and the NBS Web UI. Sits behind the infrastructure layer ingress controller. |
 
----
-
-### Page Builder
+## Page Builder
 
 A tool for creating and editing the investigation forms used by STLT epidemiologists and disease investigators.
 
@@ -86,9 +79,7 @@ A tool for creating and editing the investigation forms used by STLT epidemiolog
 | When you need it | Always, if your jurisdiction uses NBS to manage investigation forms. Page Builder is included in NBS Core. |
 | Dependencies | Requires the NBS Modernization API. |
 
----
-
-### Report Execution API
+## Report Execution API
 
 A Python FastAPI service intended to replace SAS-based report execution in NBS 7. SAS 9.4 is currently required for report execution and must be carried forward into NBS 7 deployments until this component is production-ready. Jurisdictions with significant SAS infrastructure or licensing costs should monitor this component as NBS 7 matures.
 
@@ -100,9 +91,7 @@ A Python FastAPI service intended to replace SAS-based report execution in NBS 7
 | What it does in NBS 7 | \[Pending SME verification\] |
 | Dependencies | \[Pending SME verification\] |
 
----
-
-### Elasticsearch
+## Elasticsearch
 
 An open source search and analytics engine optimized for speed and scalability.
 
@@ -112,9 +101,7 @@ An open source search and analytics engine optimized for speed and scalability.
 | When you need it | Always. Elasticsearch is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires Nifi to populate its indices from the NBS database. Search functionality in the NBS Web UI and Modernization API depends on Elasticsearch. |
 
----
-
-### Nifi
+## Nifi
 
 An open source data flow automation tool for moving and transforming data between systems.
 
@@ -124,9 +111,7 @@ An open source data flow automation tool for moving and transforming data betwee
 | When you need it | Always. Nifi is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires the NBS database (NBS\_ODSE) as its data source and Elasticsearch as its destination. |
 
----
-
-### Keycloak
+## Keycloak
 
 An open source identity and access management platform.
 
@@ -136,12 +121,12 @@ An open source identity and access management platform.
 | When you need it | Always. Keycloak is a core component of NBS Core and is required for all NBS 7 configurations. |
 | Dependencies | Requires network access to your identity provider if you are integrating with an existing SSO system. All NBS 7 services that require authentication depend on Keycloak. |
 
-{: .note }
-**Health department leaders:** See [Leadership considerations](../leadership_considerations.html) for guidance on Single Sign-On planning and early coordination requirements.
+> Health department leaders
+>
+> For guidance on Single Sign-On planning and early coordination requirements, see [Operational considerations](../leadership_considerations.html).
+{: .note-title }
 
----
-
-### Database (NBS\_ODSE, NBS\_SRTE)
+## Database (NBS\_ODSE, NBS\_SRTE)
 
 The core SQL Server databases that store operational and reference data for NBS.
 
@@ -151,9 +136,7 @@ The core SQL Server databases that store operational and reference data for NBS.
 | When you need it | Always. Both databases are required for all NBS 7 configurations. |
 | Dependencies | Required by Legacy NBS 6, the Modernization API, Nifi, Debezium (if using RTR), and the DI API (if using the DI API add-on). |
 
----
-
-### Infrastructure and networking layer components
+## Infrastructure and networking layer components
 
 The following components make up the infrastructure and networking layers of NBS Core. They are provisioned and managed primarily through Terraform and Helm, and most do not require configuration decisions from IT admins during the planning phase. They are documented here for awareness.
 
diff --git a/docs/1_introduction/deployment_decision_guide/3_component_reference/2_rtr.md b/docs/1_introduction/deployment_decision_guide/3_component_reference/2_rtr.md
index 01615f6..2574438 100644
--- a/docs/1_introduction/deployment_decision_guide/3_component_reference/2_rtr.md
+++ b/docs/1_introduction/deployment_decision_guide/3_component_reference/2_rtr.md
@@ -4,25 +4,25 @@ layout: page
 parent: Component reference
 grand_parent: NBS 7 Deployment Decision Guide
 nav_order: 2
-description: Details the four components added by the Real-Time Reporting (RTR) add-on: Debezium, Kafka, RTR domain services, and RDB_Modern.
+description: "Details the four components added by the Real-Time Reporting (RTR) add-on: Debezium, Kafka, RTR domain services, and RDB_Modern."
+nav_enabled: true
 ---
 
-## Component reference: Real-Time Reporting (RTR) add-on
+# Component reference: Real-Time Reporting (RTR) add-on
 {: .no_toc }
 
-RTR works alongside the legacy MasterETL batch process during transition, with the goal of eventually replacing it. The following components are added to your NBS Core deployment when you choose NBS Core + RTR or NBS Complete.
+For information on migration planning, staffing, and budget, see [Operational considerations](leadership_considerations.html).
+{: .note }
 
-1. TOC
-{:toc}
+RTR works alongside the legacy MasterETL batch process during transition, with the goal of eventually replacing it. The following components are added to your NBS 7 deployment when you choose to deploy the RTR add-on.
 
---- 
+## On this page
+{: .no_toc .text-delta }
 
-{: .note }
-**Health department leaders:** See [Leadership considerations](../leadership_considerations.html) for guidance on evaluating RTR for your jurisdiction.
-
----
+1. TOC
+{:toc}
 
-### Debezium
+## Debezium
 
 An open-source Change Data Capture (CDC) platform.
 
@@ -32,9 +32,7 @@ An open-source Change Data Capture (CDC) platform.
 | When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
 | Dependencies | Requires the NBS database (NBS\_ODSE) as its source. Streams data to the Kafka cluster. |
 
----
-
-### Kafka and Kafka Connect
+## Kafka and Kafka Connect
 
 Apache Kafka is an open source event-streaming platform. Kafka Connect is the framework that moves data between Kafka and other systems.
 
@@ -44,11 +42,9 @@ Apache Kafka is an open source event-streaming platform. Kafka Connect is the fr
 | When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
 | Dependencies | Receives events from Debezium. Delivers messages to RTR domain services. Kafka Connect writes processed data to RDB\_Modern. Requires sufficient cluster resources — Kafka is one of the more operationally demanding components in the RTR stack. |
 
----
+## RTR domain services
 
-### RTR domain services
-
-A unified Spring Boot service that transforms streaming data from Kafka into reportable public health records. Previously implemented as five separate entity-specific services (investigation, person, observation, organization, and LDF data), these are being consolidated into a single `reporting-service` application to reduce deployment complexity and operational overhead.
+A unified Spring Boot service that transforms streaming data from Kafka into reportable public health records. Previously implemented as five separate entity-specific services (investigation, person, observation, organization, and LDF data), these are being consolidated into a single `reporting-pipeline-service` application to reduce deployment complexity and operational overhead.
 
 | Attribute | Description |
 |:---|:---|
@@ -56,12 +52,10 @@ A unified Spring Boot service that transforms streaming data from Kafka into rep
 | When you need it | When your jurisdiction chooses NBS Core + RTR or NBS Complete. |
 | Dependencies | Requires Kafka (message source) and NBS\_ODSE (operational data store). Populates RDB\_Modern staging tables, which are then consumed by the post-processing service. |
 
-> The five entity-specific RTR services (investigation-service, person-service, observation-service, organization-service, ldfdata-service) are being consolidated into a single `reporting-service` as of early 2026. Check with your CDC NBS point of contact for the current deployment state.
+> The five entity-specific RTR services (investigation-service, person-service, observation-service, organization-service, ldfdata-service) are being consolidated into a single `reporting-pipeline-service` as of early 2026. Check with your CDC NBS point of contact for the current deployment state.
 {: .note }
 
----
-
-### RDB\_Modern
+## RDB\_Modern
 
 The modern reporting database introduced by RTR.
 
diff --git a/docs/1_introduction/deployment_decision_guide/3_component_reference/3_di_api.md b/docs/1_introduction/deployment_decision_guide/3_component_reference/3_di_api.md
index be422f2..ffedb3d 100644
--- a/docs/1_introduction/deployment_decision_guide/3_component_reference/3_di_api.md
+++ b/docs/1_introduction/deployment_decision_guide/3_component_reference/3_di_api.md
@@ -10,16 +10,20 @@ description: Details the Data Ingestion (DI) API add-on component, which accepts
 ## Component reference: Data Ingestion (DI) API add-on
 {: .no_toc }
 
-The DI API is a data transit layer built into NBS 7 that accepts incoming public health data and routes it into NBS without requiring third-party middleware. The DI API is added to your NBS Core deployment when you choose NBS Core + DI API or NBS Complete.
-
+For information on migration planning, staffing, and budget, see [Operational considerations](leadership_considerations.html).
+{: .note }
 
---- 
+<!--
+## On this page
+{: .no_toc .text-delta }
 
-{: .note }
-**Health department leaders:** See [Leadership considerations](../leadership_considerations.html) for guidance on evaluating the DI API for your jurisdiction.
+1. TOC
+{:toc}
+-->
 
+The DI API is a data transit layer built into NBS 7 that accepts incoming public health data and routes it into NBS without requiring third-party middleware. The DI API is added to your NBS 7 deployment when you choose to deploy the DI API add-on.
 
-### DI API
+## DI API
 
 A modern data ingestion layer that accepts incoming public health data in multiple formats and routes it into NBS.
 
diff --git a/docs/1_introduction/deployment_decision_guide/deployment_decision_guide.md b/docs/1_introduction/deployment_decision_guide/deployment_decision_guide.md
index 5d283d0..888d8f4 100644
--- a/docs/1_introduction/deployment_decision_guide/deployment_decision_guide.md
+++ b/docs/1_introduction/deployment_decision_guide/deployment_decision_guide.md
@@ -4,10 +4,9 @@ layout: page
 parent: Introduction
 nav_order: 2
 has_children: true
-description: Helps STLT IT administrators evaluate NBS 7 adoption, choose a deployment configuration, and prepare a leadership recommendation.
+description: Helps STLT IT administrators evaluate NBS 7 adoption and choose a deployment configuration.
 ---
 
-
 # NBS 7 Deployment Decision Guide
 {: .no_toc }
 
@@ -17,20 +16,19 @@ description: Helps STLT IT administrators evaluate NBS 7 adoption, choose a depl
 1. TOC
 {:toc}
 
-## Overview 
+## Overview
 
-This guide is for **STLT IT administrators** who operate NBS 6 and are evaluating whether to migrate to NBS 7. It aims to help your jurisdiction decide whether to adopt NBS 7 and, if so, plan your deployment configuration. Review the decision guide before you begin migration planning.
+This guide is for **STLT IT administrators** who operate NBS 6 and are evaluating whether to migrate to NBS 7. It aims to help your jurisdiction decide whether to adopt NBS 7 and, if so, plan your deployment. Review the decision guide before you begin migration planning.
 
 Use this guide to:
 
 - Assess whether NBS 7 is the right fit for your jurisdiction
-- Identify which configuration would be right for your jurisdiction if you move forward
-- Understand what components make up NBS 7 and what each one does
-- Prepare a recommendation for your leadership
-
+- Identify the right starting configuration for your jurisdiction: NBS 7 alone, or NBS 7 with one or both optional add-ons
+- Understand the components that make up NBS 7 and what each one does
+- Prepare a recommendation for your deployment
 
+> Some factors that affect NBS 7 migration extend beyond infrastructure and configuration. For a summary of organizational, financial, and operational considerations, see [Operational considerations](leadership_considerations.html).
 {: .note }
-**Health department leaders:** This guide is written for IT administrators. For a summary of the key organizational, financial, and operational considerations relevant to your go/no-go decision, see [Leadership considerations](leadership_considerations.html).
 
 ## How this guide fits into the NBS 7 process
 
@@ -46,4 +44,3 @@ Some prerequisites covered in this guide are also covered in the Migration Info
 
 {: .note }
 NBS 7 is under active development. Component availability and configuration options will change as development continues. Make sure you are reading the latest version of this guide before you begin to plan.
-
diff --git a/docs/1_introduction/deployment_decision_guide/leadership_considerations.md b/docs/1_introduction/deployment_decision_guide/leadership_considerations.md
index 948231e..32c455c 100644
--- a/docs/1_introduction/deployment_decision_guide/leadership_considerations.md
+++ b/docs/1_introduction/deployment_decision_guide/leadership_considerations.md
@@ -1,48 +1,51 @@
 ---
-title: Leadership considerations
+title: Operational considerations
 layout: page
 parent: NBS 7 Deployment Decision Guide
 grand_parent: Introduction
 nav_order: 0
-description: Summarizes the organizational, financial, and operational factors that health department leaders should address before committing to NBS 7 migration.
+description: Summarizes organizational, financial, and operational factors that affect NBS 7 migration planning.
 ---
 
-## NBS 7 leadership considerations
+# Operational considerations
 {: .no_toc }
 
-This page is for **health department leaders and decision-makers** who need to understand the organizational, financial, and operational implications of migrating to NBS 7. Each consideration below represents a decision point or planning requirement that leadership should address before your jurisdiction commits to migration.
+This page covers organizational, financial, and operational factors that affect NBS 7 migration planning. Some of these factors involve decisions or timelines that extend beyond the technical team and might be worth raising with others in your organization early in your planning process.
 
-For technical deployment guidance, refer to the [Assess your readiness](0_assess_readiness.html) section and the rest of this guide.
+## On this page
+{: .no_toc .text-delta }
 
 1. TOC
 {:toc}
 
 ---
 
-### Migration is gradual, not a cutover
+For technical deployment guidance, refer to the [Assess your readiness](0_assess_readiness.html) section and the rest of this guide.
+
+## Migration is gradual, not a cutover
 
-NBS 7 does not replace NBS 6 in a single switch. Your jurisdiction will run both systems in parallel during the transition. NBS 7 components gradually take over functionality while NBS 6 continues to operate. Plan for the operational complexity and cost of maintaining two systems simultaneously. The length of this parallel period depends on your jurisdiction's pace of deployment and configuration choices.
+NBS 7 does not replace NBS 6 in a single switch. Both systems run in parallel during the transition. NBS 7 components gradually take over functionality while NBS 6 continues to operate. The length of this parallel period depends on your jurisdiction's pace of deployment and configuration choices. Planning for the operational complexity and cost of maintaining two systems simultaneously is a common part of migration preparation.
 
-### State IT security approval takes time
+## State IT security approval takes time
 
-State IT security approval is often the longest-lead item in an NBS 7 migration. NBS 7 requires approval for cloud hosting and specific technologies including Kubernetes, Terraform, and Docker. If your jurisdiction has not started this process, start it now, even if deployment is months away. Waiting until you are technically ready to deploy before seeking approval is one of the most common causes of migration delays.
+State IT security approval is often the longest-lead item in an NBS 7 migration. NBS 7 requires approval for cloud hosting and specific technologies including Kubernetes, Terraform, and Docker. Jurisdictions that start this process early, even when deployment is still months away, might avoid one of the most common causes of migration delays.
 
-### Cloud infrastructure requires new ongoing budget
+## Cloud infrastructure requires ongoing budget
 
-NBS 6 could run on-premises, but NBS 7 cannot. NBS 7 is a cloud-only system. Your jurisdiction needs an active cloud account (AWS or Azure) and an ongoing budget to sustain cloud infrastructure costs. Cloud hosting costs scale with usage, so budget planning should account for both normal operations and surge scenarios such as outbreak response.
+NBS 6 could run on-premises, but NBS 7 is a cloud-only system. Your jurisdiction needs an active cloud account (AWS or Azure) and an ongoing budget to sustain cloud infrastructure costs. Cloud hosting costs scale with usage, so budget planning might account for both normal operations and surge scenarios such as outbreak response.
 
-### Technical staffing requirements are different from NBS 6
+## Technical staffing requirements differ from NBS 6
 
-Migrating to NBS 7 requires skills your current NBS 6 team may not have, including Kubernetes, Terraform, and cloud infrastructure management. Assess your team's current capacity before committing to a migration timeline. If you underestimate the staffing gap, your migration will take longer than planned. Jurisdictions without the necessary in-house expertise will need to build capacity or engage a vendor.
+Migrating to NBS 7 involves skills that might differ from what your current NBS 6 team uses, including Kubernetes, Terraform, and cloud infrastructure management. Jurisdictions that assess their team's capacity early are poised to set more accurate migration timelines. Those without the necessary in-house expertise have typically built capacity or engaged a vendor before deployment.
 
-### Real-Time Reporting adds capability and cost
+## Real-Time Reporting adds capability and cost
 
-The Real-Time Reporting (RTR) add-on reduces the time for data to appear in reports from up to 24 hours to between 5 minutes and 1 hour. For jurisdictions managing active outbreaks or time-sensitive disease investigations, this improvement can meaningfully affect response time. However, RTR adds infrastructure complexity and requires additional cloud resources. Weigh the reporting speed benefit against the additional operating cost for your jurisdiction's case volume and reporting needs.
+The Real-Time Reporting (RTR) add-on reduces the time for data to appear in reports from up to 24 hours to between 5 minutes and 1 hour. For jurisdictions managing active outbreaks or time-sensitive disease investigations, this improvement can meaningfully affect response time. RTR also adds infrastructure complexity and requires additional cloud resources. The reporting speed benefit and the additional operating cost are both worth weighing against your jurisdiction's case volume and reporting needs.
 
-### The Data Ingestion API is not yet a full middleware replacement
+## The Data Ingestion API is not yet a full middleware replacement
 
-The Data Ingestion (DI) API is a built-in data transit layer that can receive lab reports and case reports without third-party middleware. If your jurisdiction currently uses Rhapsody or Mirth Connect, the DI API is not yet a full replacement. Continue to use your existing middleware for now. If your jurisdiction does not have existing middleware, the DI API is worth evaluating. Revisit its capabilities as the product matures.
+The Data Ingestion (DI) API is a built-in data transit layer that can receive lab reports and case reports without third-party middleware. If your jurisdiction currently uses Rhapsody or Mirth Connect, the DI API is not yet a full replacement. Continuing to use your existing middleware for now is the current guidance. If your jurisdiction does not have existing middleware, the DI API is worth evaluating. Its capabilities are expected to expand as the product matures.
 
-### Single Sign-On requires early coordination
+## Single Sign-On requires early coordination
 
-NBS 7 uses Keycloak for identity management. If your jurisdiction uses a centralized identity provider such as Okta or Active Directory, Keycloak can integrate with it, allowing NBS 7 users to log in with their existing jurisdiction credentials. This integration requires early coordination between your NBS deployment team and your identity provider administrators. Do not leave SSO configuration to the end of the deployment process.
+NBS 7 uses Keycloak for identity management. If your jurisdiction uses a centralized identity provider such as Okta or Active Directory, Keycloak can integrate with it, allowing NBS 7 users to log in with their existing jurisdiction credentials. This integration requires coordination between your NBS deployment team and your identity provider administrators. We recommend that you start that coordination early rather than addressing it later in the deployment process.
diff --git a/docs/2_prerequisites/prereq.md b/docs/2_prerequisites/prereq.md
index 528f4a1..6c2ba39 100644
--- a/docs/2_prerequisites/prereq.md
+++ b/docs/2_prerequisites/prereq.md
@@ -5,7 +5,6 @@ nav_order: 3
 nav_enabled: true
 ---
 
-
 # Installation prerequisites
 
 ## On this page
@@ -14,8 +13,6 @@ nav_enabled: true
 1. TOC
 {:toc}
 
----
-
 You must have the following prerequisites in place before proceeding with the installation.
 
 ## AWS environment