docs improvements - do not merge

concepts/billing.mdx

@@ -6,24 +6,24 @@ keywords: ['pricing', 'subscription', 'credit card', 'stripe', 'invoice download
 
 ## Overview
 
-A billing account allows you to manage user access, invoices, payment methods, and spending threshold alerts. You can create multiple billing accounts to manage billing separately.
+A billing account allows you to manage user access, invoices, payment methods, and spending threshold alerts. You can create multiple billing accounts to manage billing independently.
 
-In each billing account, you can access:
+Each billing account provides access to:
 
-- [Account Details](#account-details): Manage personal details, billing information, and spend threshold email alert.  
-- [Orgs](/reference/org): View the orgs linked to this billing account.  
-- Invoices: View and download invoices.  
-- Payment Methods: Add, update, or remove payment methods.  
-- [Users](#users): Manage user access, roles, and permissions. 
-- Cost & Usage: Review cost and usage across all orgs in this billing account. 
+- [Account Details](#account-details): Manage account details, billing information, and spend threshold email alert.
+- [Orgs](/reference/org): View the orgs associated with this billing account.
+- Invoices: View and download billing invoices.
+- Payment Methods: Add, update, and remove payment methods.
+- [Users](#users): Manage user access, roles, and permissions.
+- Cost & Usage: Review cost and usage across all orgs associated in this billing account.
 
 ### Account Details
 
 View and manage your billing account information.
 
 ### Spend Threshold Email Alert 
-Spend threshold email alerts help you monitor your billing account. You must first enable the spend alert to receive an email when you reach the monthly limit that has been set.
+Spend threshold email alerts help you monitor billing usage and spending. You must first enable the spend alert to receive email notifications when your configured monthly threshold is reached.
 
 ### Users
 
-You can add users to your billing account. You must assign them a role of either billing_admin or billing_viewer. Additionally, you can assign a user as an org_creator. The user will gain immediate access to the billing account once added.
+You can add users to your billing account and assign billing roles. You must assign them a role of either billing_admin or billing_viewer. Additionally, you can assign a user as an org_creator. The user will gain immediate access to the billing account once added.

concepts/gvc.mdx

@@ -6,40 +6,40 @@ keywords: ['cpln', 'multi-region', 'geo', 'pull secret', 'private registry', 'im
 
 ## Overview
 
-A Global Virtual Cloud ([GVC](/reference/gvc)) defines a set of cloud providers and their [locations](/reference/location).
+A Global Virtual Cloud ([GVC](/reference/gvc)) defines a set of cloud providers and deployment [locations](/reference/location).
 
-When creating a GVC you are in essence building an uber-cloud that is comprised of the specified [locations](/reference/location). [Workloads](/concepts/workload) are deployed to the GVC which are then served from all the [locations](/reference/location) specified.
+When creating a GVC effectively builds a unified multi-cloud environment that is comprised of the specified [locations](/reference/location). [Workloads](/concepts/workload) are deployed to the GVC which are then served from all the configured [locations](/reference/location).
 
-Each [org](/reference/org) can have multiple GVCs, each with its own unique set of [locations](/reference/location).
+Each [org](/reference/org) can have multiple GVCs, each with its own set of [locations](/reference/location).
 
-A [domain name](/reference/domain) owned at the org level can be assigned to a GVC for routing. Each domain is associated with exactly one GVC at a time. Callers can reach [workloads](/concepts/workload) using the assigned [domain name](/reference/domain).
+A [domain name](/reference/domain) configured at the org level can be assigned to a GVC for routing. Each domain is associated with exactly one GVC at a time. Traffic is routed to [workloads](/concepts/workload) using the assigned [domain name](/reference/domain).
 
 ## Benefits
 
-- GVCs enable your [workload](/concepts/workload) to be deployed with ease to multiple cloud providers and locations
-  - You choose the provider (AWS, Azure, and GCP) and their different locations
-  - Select [locations](/reference/location) that are close to your end-users
-  - Select the [locations](/reference/location) that fulfill the requirements of your workloads
-  - Ensure maximum availability if a cloud provider has an occasional outage
-- You get granular controls to define the scaling characteristics of your [workload](/concepts/workload)
+- GVCs enable your [workload](/concepts/workload) to be deployed easily to multiple cloud providers and locations
+  - Choose cloud providers such as (AWS, Azure, and GCP) along with their deployment locations
+  - Select [locations](/reference/location) close to your end users
+  - Select the [locations](/reference/location) that fulfill your workload requirements
+  - Ensure maximum availability if a cloud provider experiences an outage
+  - Configure granular scaling behavior for your [workload](/concepts/workload)
 
 ## Domain Name
 
 [Domains](/reference/domain) are configured at the [org](/reference/org) level and routed to workloads via [domain route configuration](/reference/domain#path-based-routing). The default domain name `cpln.app` is used for workload endpoints unless a custom [domain](/reference/domain) is configured.
 
 ## Pull Secrets
 
-Pull secrets are [secrets](/reference/secret) that are assigned to a GVC and used by [workloads](/concepts/workload) when authentication is required for pulling an image from a private registry. Only the [Docker](/reference/secret#docker), [Amazon ECR](/reference/secret#ecr), and [GCP](/reference/secret#google-cloud-platform-gcp) [secret](/reference/secret) types are supported.
+Pull secrets are [secrets](/reference/secret) assigned to a GVC and used by [workloads](/concepts/workload) when authentication is required to pull an image from a private registry. Only the [Docker](/reference/secret#docker), [Amazon ECR](/reference/secret#ecr), and [GCP](/reference/secret#google-cloud-platform-gcp) [secret](/reference/secret) types are supported.
 
 <Tip>If the image was pushed to the Control Plane registry for the same [org](/reference/org), no secret is required.</Tip>
 
-Multiple pull secrets can be assigned to a GVC. A [workload's container](/concepts/workload) will use the appropriate secret when pulling the image from a private registry. If there are multiple secrets, the container will cycle through each one.
+A GVC can have multiple pull secrets assigned. A [workload's container](/concepts/workload) will use the appropriate secret when pulling images from a private registry. f multiple secrets are configured, the container attempts each secret in sequence.
 
-If authentication fails, the deployment will not be updated and the image pull will have an exponential backoff retry starting at 10 seconds until 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.).
+If authentication fails, the deployment is not updated and the image pull will have an exponential backoff retry starting at 10 seconds until 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.).
 
 ## Location Routing
 
-By default, traffic is routed to the nearest healthy location using DNS geo-routing based on latency. For more complex routing scenarios, you can configure [location routing options](/reference/gvc#location-routing-options) on a per-GVC basis to control priority-based failover, adjust traffic distribution with latency offsets, and set latency thresholds for location availability.
+By default, traffic is routed to the nearest healthy location using latency-based DNS geo-routing. For more advanced routing scenarios, you can configure [location routing options](/reference/gvc#location-routing-options) on a per-GVC basis to control priority-based failover, adjust traffic distribution with latency offsets, and set latency thresholds for location availability.
 
 ## Reference
 

concepts/org.mdx

@@ -6,14 +6,13 @@ keywords: ['tenant', 'tenancy', 'workspace', 'cpln', 'multi-tenant', 'globally u
 
 ## Overview
 
-An organization is a strictly isolated bounded context that encapsulates all the resources managed by Control Plane. These kinds of resources include [domains](/reference/domain), [images](/reference/image), [workloads](/concepts/workload), [GVCs](/reference/gvc), [users](/reference/user), [groups](/reference/group), [service accounts](/reference/serviceaccount), etc.
+An organization is a strictly isolated bounded context that encapsulates all the resources managed by Control Plane. These resources include [domains](/reference/domain), [images](/reference/image), [workloads](/concepts/workload), [GVCs](/reference/gvc), [users](/reference/user), [groups](/reference/group), [service accounts](/reference/serviceaccount), etc.
 
-A physical organization (e.g., Acme) can create more than one ‘org’, although it is optional. Reasons for
-doing so might be to provide absolute isolation between subsidiaries for example.
+A physical organization (e.g., Acme) can create more than one ‘org’, although it is optional. Reasons for doing so might include providing isolation between subsidiaries.
 
-<Note>An org name is **globally unique**</Note>
+<Note>An org name must be **globally unique**</Note>
 
-As a user of Control Plane, you will be a member of at least one organization and have access to manage the org resources listed below:
+As a user of Control Plane, you are a member of at least one organization and have access to manage the org resources listed below:
 
 **Click on any of the links below to learn more about each specific resource:**
 
@@ -39,7 +38,7 @@ As a user of Control Plane, you will be a member of at least one organization an
 
 ## Cross-GVC Communication
 
-Workloads in different GVCs within the same org can communicate with each other using [internal firewall rules](/reference/workload/firewall#internal). Configure the internal firewall with `same-org` or `workload-list` to allow specific cross-GVC access.
+Workloads in different GVCs within the same org can communicate using [internal firewall rules](/reference/workload/firewall#internal). Configure the internal firewall with `same-org` or `workload-list` to allow specific cross-GVC access.
 
 ## Reference
 

concepts/workload.mdx

@@ -6,11 +6,11 @@ keywords: ['microservice', 'app', 'service', 'pod', 'replica', 'serverless', 'st
 
 ## Overview
 
-A workload represents a backend application such as a microservice. It is comprised of one or multiple containers. Containers making up the workload communicate freely on localhost.
+A workload represents a backend application such as a microservice. It is comprised of one or multiple containers. Containers within a workload communicate freely on localhost.
 
-Workloads run in Control Plane’s AWS, Azure, GCP accounts or in your own [Custom Location](/reference/location#byok-locations) (BYOK), where clouds/regions are determined by the [GVC](/reference/gvc) definition. Your workload may run only in a single region of one cloud, or across many regions of all the three clouds – completely up to the GVC definition. Requests are routed to the nearest healthy location.
+Workloads run in Control Plane’s AWS, Azure, GCP accounts, or in your own [Custom Location](/reference/location#byok-locations) (BYOK), where cloud providers and regions are determined by the [GVC](/reference/gvc) definition. Your workload may run in a single region of one cloud, or across many regions of all the three clouds – depending up to the GVC definition. Requests are routed to the nearest healthy location.
 
-Workloads are managed using a common interface, regardless of cloud providers. Workload log data is consolidated for easy retrieval and analysis. It means that a particular workload can be operating on AWS, Azure and GCP, yet its log – across instances/providers is accessed using a single API/CLI/UI/Grafana operation.
+Workloads are managed using a common interface, regardless of cloud providers. Workload log data are consolidated for easy retrieval and analysis. This means that a workload can run across AWS, Azure and GCP, yet its log – across instances and providers is accessed using a single API/CLI/UI/Grafana operation.
 
 ## Reference
 For detailed workload configuration options see the [Workload Reference](/reference/workload/general).
@@ -28,7 +28,7 @@ For detailed workload configuration options see the [Workload Reference](/refere
 
 ## Auto Scaling
 
-The number of workload replicas is automatically scaled up and down based on the workload's scaling strategy.
+Workload replicas are automatically scaled up and down based on the selected scaling strategy.
 
 Selectable Scaling Strategies:
 
@@ -52,23 +52,23 @@ The minimum and maximum number of replicas that can be deployed are configurable
 
 A workload can leverage intelligent allocation of its container's resources (CPU and Memory) by using Capacity AI.
 
-Capacity AI uses an analysis of historical usage to adjust these resources up to a configured maximum.
+Capacity AI uses historical usage analysis to adjust these resources up to a configured maximum.
 
 This approach can substantially reduce costs; however, it may result in temporary performance issues during sudden spikes in usage.
 
-Before enabling capacity AI on your workload, please read the [Capacity AI reference page](/reference/workload/capacity)
+Before enabling capacity AI on your workload, review the [Capacity AI reference page](/reference/workload/capacity)
 
 ## Location Override
 
-By default, both [Capacity AI](#capacity-ai) and [Auto Scaling](#auto-scaling) settings are applied to all deployments at each location enabled in the [GVC](/concepts/gvc). However, these settings can be customized at each location to enhance performance for specific audiences.
+By default, both [Capacity AI](#capacity-ai) and [Auto Scaling](#auto-scaling) settings are applied to all deployments at each location enabled in the [GVC](/concepts/gvc). However, these settings can be customized per location to enhance performance for specific audiences.
 
 This allows for granular control over how your workload scales in specific locations. For instance, if the majority of your users are in Europe, you can set the European locations to a higher level than the rest of the world.
 
 Setting local options ensures that your target users are served quickly and helps reduce costs for unused resources.
 
 ## Probes
 
-Probes are a feature of Kubernetes that are used to control the health of an application running inside a container.
+Probes are a Kubernetes feature that are used to monitor the health of an application running in a container.
 
 Each container can have a:
 
@@ -77,13 +77,13 @@ Each container can have a:
   - An endpoint is configured to allow queries, enabling you to check if the workload is available and ready to receive requests.
 
 - Liveness Probe
-  - An endpoint is configured to allow queries, enabling you to check if the workload is healthy or if it needs to be restarted.
+  - An endpoint is configured to allow queries, enabling you to check if the workload is healthy or needs to be restarted.
 
 ## Alerts
 
 Using Grafana, you can create alerts on any of the standard metrics exposed by Control Plane, or on your [custom metrics](/reference/workload#metrics). To access Grafana, navigate to one of your orgs in the Control Plane console and click the "Metrics" link.
 
-You have the full capability of Grafana alerting at your disposal. For more information, please consult [the Grafana documentation](https://grafana.com/docs/grafana/latest/alerting/)
+You have full access to Grafana alerting capabilities. For more information, see the [the Grafana documentation](https://grafana.com/docs/grafana/latest/alerting/)
 
 ## Reference
 

core/accessing-cloud-resources.mdx

@@ -10,21 +10,21 @@ The Control Plane platform enables your [workloads](/reference/workload), regard
 
 This capability is **optional**.
 
-This feature alleviates various aspects of credential management. By leveraging this capability, running workloads becomes more straightforward. Cloud providers refer to this as "temporary session credentials." For more information, see how AWS uses temporary credentials in this [link](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).
+This feature simplifies credential management by allowing workloads to obtain temporary credentials dynamically instead of relying on embedded secrets. Cloud providers refer to this as "temporary session credentials." For more information, see how AWS uses temporary credentials in this [link](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).
 
 Customers choosing to define fine-grained access that allows a [workload](/reference/workload) to access cloud resources must perform the following:
 
-- Register with Control Plane a [cloud account](/reference/cloudaccount) for each cloud provider (AWS, Azure, or GCP) that hosts the resources your workload requires.
-- Create an [identity](/reference/identity) and assign the desired [cloud access](/guides/create-identity#cloud-access) to resources within each registered [cloud account](/reference/cloudaccount).
-- Assign the [identity](/reference/identity) to a [workload](/reference/workload). Only one identity can be assigned to a particular workload. [Identities](/reference/identity) can be re-used by multiple workloads and have the same set of permissions.
+- Register a [cloud account](/reference/cloudaccount) with Control Plane for each cloud provider (AWS, Azure, or GCP) that hosts the resources your workload requires.
+- Create an [identity](/reference/identity) and assign the desired [cloud access](/guides/create-identity#cloud-access) permissions to resources within each registered [cloud account](/reference/cloudaccount).
+- Assign the [identity](/reference/identity) to a [workload](/reference/workload). Each workload can have only one assigned identity. [Identities](/reference/identity) can be re-used by multiple workloads that require the same permissions.
 
-For Control Plane to provision and de-provision the [identity's](/reference/identity) access to consume native cloud services, Control Plane must be able to:
+For Control Plane to provision and revoke the [identity's](/reference/identity) access to consume native cloud services, Control Plane must be able to:
 
 - Create `Roles` in AWS
 - Create `App registrations` in Azure
 - Create `Service Accounts` in GCP
 
-For additional details on this process, refer to the [cloud account](/reference/cloudaccount) reference page for each cloud provider:
+For additional detail, refer to the [cloud account](/reference/cloudaccount) reference page for each cloud provider:
 
 - [AWS](/reference/cloudaccount#aws-details)
 - [Azure](/reference/cloudaccount#azure-details)