Nexus docs update

docs/cloud/get-started/namespaces.mdx

@@ -264,9 +264,10 @@ Namespace configuration requires some consideration. Following are some general
 - Namespaces can be split along additional boundaries such as service, application, domain or even sub-domain.
 - Namespaces should be used to reduce the "blast radius" for mission-critical applications.
 - Environments such as production and development usually have requirements for isolation. We recommend that each
-  environment has its own Namespace. This helps keep production Namespaces secure. It also protects production Namespaces from being throttled due to throughput spikes in development.
-- Workflows should use Nexus to communicate across Namespaces with a clean service contract instead of sharing Temporal primitives directly.
-- Workflows in the same Namespace can communicate with each other directly.
+  environment has its own Namespace.
+- Namespaces should be used to reduce the "blast radius" for mission-critical applications.
+- Use [Nexus](/nexus) to communicate across team, domain, and Namespace boundaries with a clean service contract instead of sharing Temporal primitives directly.
+  Nexus enables each team to have their own Namespace for improved security, troubleshooting, and fault isolation while sharing capabilities through Nexus Endpoints.
 
 ### Examples
 

docs/cloud/nexus/index.mdx

@@ -2,7 +2,7 @@
 id: index
 slug: /cloud/nexus
 title: Nexus
-description: Discover Temporal Nexus, a powerful feature for connecting durable executions across team, namespace, region, and cloud boundaries. Nexus also enables each team to have their own namespace for improved security, troubleshooting, and blast radius isolation.
+description: Temporal Cloud adds global Nexus Registry, built-in access controls, audit logging, and multi-region connectivity on top of core Nexus.
 sidebar_label: Temporal Nexus
 keywords:
   - Temporal Nexus
@@ -32,48 +32,20 @@ Learn why you should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-[Temporal Nexus](/nexus) allows you to connect Temporal Applications across (and within) isolated Namespaces.
-This provides all the benefits of Durable Execution across team and application boundaries with improved modularity, security, debugging, and fault isolation.
-Nexus supports cross-team, cross-domain, cross-namespace, multi-region, and multi-cloud use cases.
+Temporal Cloud builds on the [core Nexus experience](/nexus) with:
+
+- **Global [Nexus Registry](/nexus/registry)** - Scoped to your entire Account across all Namespaces. Workers in any Namespace can host Nexus Services for others to use.
+- **Built-in [access controls](/nexus/registry#configure-runtime-access-controls)** - Restrict which caller Namespaces can use a Nexus Endpoint at runtime.
+- **[Audit logging](/cloud/audit-logs)** - Stream Nexus Registry actions (create, update, delete Endpoints) to your audit log integration.
+- **Multi-region connectivity** - Nexus requests route across Namespaces within and across AWS and GCP using a global mTLS-secured Envoy mesh. Compatible with [Multi-region Namespaces](/cloud/high-availability#multi-region-replication) as Endpoint targets.
+- **[Terraform support](/cloud/terraform-provider#manage-temporal-cloud-nexus-endpoints-with-terraform)** - Manage Nexus Endpoints with the Temporal Cloud Terraform provider.
 
 <CaptionedImage
     src="/img/cloud/nexus/nexus-overview-short.png"
     title="Nexus Overview"
 />
 
-Temporal Cloud support is built on top of the [core Nexus experience](/nexus) and adds a global Nexus Registry within an Account, enhanced security, and multi-region connectivity within and across AWS and GCP.
-
-:::tip RELATED
-
-- [Evaluate](/evaluate/nexus) why you should use Nexus and learn more about [Nexus use cases](/evaluate/nexus#use-cases).
-- [Learn Nexus concepts](/nexus) in the Encyclopedia.
-
-:::
-
-## Global Nexus Registry
-
-The Nexus Registry in Temporal Cloud is scoped to an Account.
-Workers in any Namespace can host Nexus Services for others to use within an Account.
-
-## Built-in access controls
-
-Temporal Cloud has built-in Endpoint access controls to restrict which callers can use a Nexus Endpoint.
-
-## Audit logging
-
-Temporal Cloud supports audit log streaming for Nexus Registry actions to create, update, or delete Endpoints.
-
-## Multi-region connectivity
-
-Nexus requests in Temporal Cloud are routed across Namespaces, within and across AWS and GCP, using a global mTLS-secured Envoy mesh.
-Built-in Nexus Machinery provides reliable at-least-once execution and Workflow policy can deduplicate requests for exactly-once execution, even across multi-region boundaries.
-
-## Terraform support
-
-The [Terraform provider for Temporal Cloud](/cloud/terraform-provider#manage-temporal-cloud-nexus-endpoints-with-terraform) supports managing Nexus Endpoints.
-
 ## Learn more
 
-- [Evaluate](/evaluate/nexus) why you should use Nexus and watch the [Nexus keynote and demo](https://youtu.be/qqc2vsv1mrU?feature=shared&t=2082).
-- [Learn key Nexus concepts](/nexus) and how Nexus works in the [Nexus deep dive talk](https://www.youtube.com/watch?v=izR9dQ_eIe4&t=934s)
-- Explore [additional resources](/evaluate/nexus#learn-more) to learn more about Nexus.
+- [Evaluate Nexus](/evaluate/nexus) | [Keynote and demo](https://youtu.be/qqc2vsv1mrU?feature=shared&t=2082)
+- [How Nexus works](/nexus) | [Deep dive talk](https://www.youtube.com/watch?v=izR9dQ_eIe4&t=934s)

docs/cloud/nexus/latency-availability.mdx

@@ -20,45 +20,15 @@ keywords:
   - service level agreement
 ---
 
-import { CaptionedImage } from '@site/src/components';
-
 :::tip SUPPORT, STABILITY, and DEPENDENCY INFO
 
 Temporal Nexus is now [Generally Available](/evaluate/development-production-features/release-stages#general-availability).
 Learn why you should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-Nexus requests (commands, polling) have the same latency SLOs and error rate SLAs as other Worker requests in both the caller and handler Namespaces.
-
-## Latency metrics
-
-Nexus supports various [latency metrics](/nexus/metrics).
-
-## Worker to Temporal Cloud interactions
-
-Nexus interactions between a Worker and Temporal Cloud use the Worker's Namespace gRPC endpoint.
-Nexus-related Worker interactions with Temporal Cloud have the same [latency SLOs](/cloud/service-availability#latency) and [availability SLAs](/cloud/sla) as other calls to a Namespaces's gRPC endpoint.
-
-<CaptionedImage
-    src="/img/cloud/nexus/nexus-workers-short.png"
-    title="Interaction between Workers and Temporal Cloud"
-/>
-
-This applies to the following Nexus-related interactions between a Worker and Temporal Cloud:
-
-- Caller Namespace
-  - RespondWorkflowTaskCompleted \- schedule a Nexus Operation.
-- Handler Namespace
-  - PollNexusTaskQueue \- get a [Nexus Task](/tasks#nexus-task) to process, for example to start a Nexus Operation.
-  - RespondNexusTaskCompleted \- report the Nexus Task was successful.
-  - RespondNexusTaskFailed \- report the Nexus Task failed.
-
-## Nexus connectivity across Namespaces
-
-Nexus connectivity in Temporal Cloud is provided by a global mTLS secured Envoy mesh.
-The cross-namespace latency between the caller's Nexus Machinery and the handler's Nexus Machinery varies based on the locality of the caller and handler Namespaces, which may be placed in different regions.
+Nexus latency and availability in Temporal Cloud:
 
-Communication between Namespaces in the same region will have lower latency.
-Communication across different regions will have higher latency.
-Consult the cross-region latency tables for your cloud provider(s) to estimate the latency for Nexus communication across Namespaces in Temporal Cloud.
+- **SLOs and SLAs** - Nexus operations (for example, `RespondWorkflowTaskCompleted`, `PollNexusTaskQueue`, `RespondNexusTaskCompleted`, and `RespondNexusTaskFailed`) have the same [latency SLOs](/cloud/service-availability#latency) and [availability SLAs](/cloud/sla) as other Worker requests in both caller and handler Namespaces.
+- **[Nexus metrics](/nexus/metrics)** - SDK and Cloud latency metrics for monitoring Nexus performance.
+- **Cross-Namespace connectivity** - Traffic routes through a global mTLS-secured Envoy mesh. Same-region Namespaces have low latency; cross-region latency varies by provider. See [secure connectivity](/nexus/security#secure-connectivity).

docs/cloud/nexus/limits.mdx

@@ -25,37 +25,11 @@ Learn why you should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-Temporal Cloud has default limits for several aspects of Nexus.
-Many of these defaults are configurable, so if you need them changed please open a support ticket.
-
-## Rate Limiting
-
-Nexus requests (commands, polling) are counted as part of the overall [Namespace rate limit](/cloud/limits#requests-per-second) in both the caller and handler Namespaces.
-
-## Operational Limits
-
-Nexus has operational limits for things like the maximum number of Nexus Endpoints and the maximum request handler timeout.
-
-### Max Nexus Endpoints
-
-By default, each account is provisioned with a max of 100 Nexus Endpoints.
-You can request further increases beyond the initial 100 Endpoint limit by opening a support ticket.
-
-### Workflow Max Nexus Operations
-
-A single Workflow Execution can have a maximum of 30 in-flight Nexus Operations.
-
-See the Nexus Encyclopedia entry for [additional details](/workflow-execution/limits#workflow-execution-nexus-operation-limits).
-
-### Nexus Request Handler Timeout
-
-Nexus Operation handlers have less than 10 seconds to process a single Nexus start or cancel request.
-Handlers should observe the context deadline and ensure they do not exceed it.
-This includes fully processing a synchronous Nexus operation and starting an asynchronous Nexus operation, for example one that starts a Workflow.
-If a handler doesn’t respond within a context deadline, a context deadline exceeded error will be tracked in the caller Workflow’s pending Nexus operations, and the Nexus Machinery will retry the Nexus request with an exponential backoff policy.
-
-### Nexus Operation Maximum Duration
-
-Each Nexus Operation has a maximum ScheduleToClose duration of 60 days, which is most applicable to asynchronous Nexus Operations that are completed with an asynchronous callback using a separate Nexus request from the handler back to the caller Namespace.
-The 60 day maximum is a limit we will look to increase at some point in the future.
-While the caller of a Nexus Operation can configure the ScheduleToClose duration to be shorter than 60 days, the maximum duration can not be extended beyond 60 days and will be capped by the server to 60 days.
+Nexus limits are documented in [Temporal Cloud limits](/cloud/limits):
+
+- [Nexus rate limits](/cloud/limits#nexus-rate-limits) - Nexus requests count toward the Namespace RPS limit.
+- [Nexus Endpoint limits](/cloud/limits#nexus-endpoints-limits) - 100 Endpoints per Account (default).
+- [Per-Workflow Nexus Operation limits](/cloud/limits#per-workflow-nexus-operation-limits) - 30 in-flight Operations per Workflow.
+- [Nexus Operation request timeout](/cloud/limits#nexus-operation-request-timeout) - Less than 10 seconds for a handler to process a start or cancel request.
+- [Nexus Operation duration limits](/cloud/limits#nexus-operation-duration-limits) - 60-day maximum ScheduleToClose duration.
+- [Per-Workflow callback limits](/cloud/limits#per-workflow-callback-limits) - 2000 callbacks per Workflow. Governs how many Nexus callers can attach to a handler Workflow.

docs/cloud/nexus/observability.mdx

@@ -25,20 +25,8 @@ should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-Nexus provides metrics and audit log streaming, in addition to integrated
-[execution debugging](/nexus/execution-debugging).
+Nexus observability in Temporal Cloud:
 
-## Metrics
-
-Nexus provides the following metrics:
-
-- [SDK metrics](/nexus/metrics#sdk-metrics) \- emitted by a Worker.
-- [Cloud metrics](/nexus/metrics#cloud-metrics) \- emitted by Temporal Cloud.
-
-## Audit Logging
-
-The following Nexus control plane actions are sent to the [Audit Logging](/cloud/audit-logs) integrations:
-
-- Create Nexus Endpoint: `CreateNexusEndpoint`
-- Update Nexus Endpoint: `UpdateNexusEndpoint`
-- Delete Nexus Endpoint: `DeleteNexusEndpoint`
+- **[Nexus metrics](/nexus/metrics)** - [SDK metrics](/nexus/metrics#sdk-metrics) emitted by Workers and [Cloud metrics](/nexus/metrics#cloud-metrics) emitted by Temporal Cloud.
+- **[Execution debugging](/nexus/execution-debugging)** - Bi-directional linking, pending Operations, pending callbacks, and tracing across Namespaces.
+- **[Audit logging](/cloud/audit-logs)** - `CreateNexusEndpoint`, `UpdateNexusEndpoint`, and `DeleteNexusEndpoint` actions streamed to your audit log integration.

docs/cloud/nexus/pricing.mdx

@@ -20,18 +20,12 @@ Learn why you should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-The pricing for [Temporal Nexus](/evaluate/nexus) is:
+Nexus pricing:
 
 - **One Action to start or cancel a Nexus Operation** in the caller Namespace.
-  The underlying Temporal primitives such as Workflows, Activities, Signals created by a Nexus Operation handler (directly or indirectly) result in the normal Actions for those primitives.
-  This includes retries for underlying Temporal primitives like Activities.
-- **No Action results for handling or retrying the Nexus Operation itself**.
-  However, while the retry of the Nexus Operation incurs no charge, any billable action initiated by the handler (such as an Activity) will be charged if it fails and is subsequently retried.
+  Underlying primitives (Workflows, Activities, Signals) and their retries created by the handler result in normal Actions.
+- **No Action for handling or retrying the Nexus Operation itself**.
+  However, billable actions initiated by the handler (such as Activities) are charged if they fail and retry.
 
-See [Pricing](/cloud/pricing) for additional details.
+See [Pricing](/cloud/pricing) for details.
 
-## Learn more
-
-- [Evaluate](/evaluate/nexus) why you should use Nexus and watch the [Nexus keynote and demo](https://youtu.be/qqc2vsv1mrU?feature=shared&t=2082).
-- Learn how Nexus works in the [Nexus deep dive talk](https://www.youtube.com/watch?v=izR9dQ_eIe4) and [Encyclopedia](/nexus).
-- [Additional resources](/evaluate/nexus#learn-more) to learn more about Nexus.

docs/cloud/nexus/security.mdx

@@ -14,57 +14,16 @@ keywords:
   - access control
 ---
 
-import { CaptionedImage } from '@site/src/components';
-
 :::tip SUPPORT, STABILITY, and DEPENDENCY INFO
 
 Temporal Nexus is now [Generally Available](/evaluate/development-production-features/release-stages#general-availability).
 Learn why you should use Nexus in the [evaluation guide](/evaluate/nexus).
 
 :::
 
-Temporal Cloud has built-in Nexus security.
-It provides secure Nexus connectivity across Namespaces with an mTLS secured Envoy mesh.
-Workers authenticate to their Namespace with mTLS client certificates or API keys, as allowed by their Namespace.
-Encryption for Nexus payloads is also supported, for example using shared symmetric keys and compatible Data Converters.
-
-## Registry roles and permissions
-
-Nexus Endpoints are Account-scoped resources, similar to a Namespace.
-The following roles and permissions are required to manage and view Nexus Endpoints in the Nexus Registry:
-
-- Viewing and browsing the full list of Nexus Endpoints in an Account:
-  - Read-only role (or higher)
-- Managing a Nexus Endpoint (create, update, delete):
-  - Developer role (or higher) and Namespace Admin permission on the Endpoint’s target Namespace
-
-## Runtime access controls
-
-The Nexus Registry allows setting Endpoint access policy on each Endpoint.
-This currently includes an allow list of caller Namespaces that can use the Endpoint at runtime.
-Endpoint access control policies are enforced at runtime:
-
-1. Caller's Worker authenticates with their Namespace as they do today with mTLS certificates or API keys.
-   This establishes the caller's identity and caller Namespace.
-2. Caller Workflow executes a Nexus Operation on a Nexus Endpoint.
-3. Endpoint access control policy is enforced, checking if the caller Namespace is in the Endpoint allow list.
-
-See [Runtime Access Controls](/nexus/security#runtime-access-controls) and [Configuring Runtime Access Controls](/nexus/registry#configure-runtime-access-controls) for additional details.
-
-## Secure connectivity
-
-Nexus Endpoints are only privately accessible from within a Temporal Cloud and mTLS is used for all Nexus communication, including across cloud cells and regions.
-Workers authenticate to their Namespaces through mTLS or an API key as allowed by their Namespace configuration.
-
-<CaptionedImage
-    src="/img/cloud/nexus/nexus-workers-short.png"
-    title="Nexus Security"
-/>
-
-See [Nexus Secure Connectivity](/nexus/security#secure-connectivity) for additional details.
-
-## Payload encryption
-
-For payload encryption, the DataConverter works the same for a Nexus Operation as it does for other payloads sent between a Worker and Temporal Cloud.
+Nexus security in Temporal Cloud:
 
-See [Nexus Payload Encryption & Data Converter](/nexus/security#payload-encryption-data-converter) for additional details.
+- **[Runtime access controls](/nexus/security#runtime-access-controls)** - Endpoint allowlists restrict which caller Namespaces can use an Endpoint. See [configuring access controls](/nexus/registry#configure-runtime-access-controls).
+- **[Secure connectivity](/nexus/security#secure-connectivity)** - mTLS for all Nexus communication across cells and regions. Endpoints are only accessible within a Temporal Cloud Account.
+- **[Payload encryption](/nexus/security#payload-encryption-data-converter)** - Same Data Converter as Workflows and Activities, with three approaches for cross-Namespace encryption.
+- **[Registry roles and permissions](/nexus/registry#roles-and-permissions)** - Controls who can view, create, edit, and delete Endpoints.