@@ -64,7 +64,7 @@ Pick your SDK and follow the quickstart:
## Use cases
Standalone Activities can be used for [durable job processing use
-cases](/evaluate/development-production-features/job-queue) such as sending an email, processing a
+cases](/evaluate/features/job-queue) such as sending an email, processing a
webhook, syncing data, or executing a single function reliably with built-in retries and timeouts.
## Key features
diff --git a/docs/encyclopedia/workflow/cancellation-and-termination.mdx b/docs/encyclopedia/workflow/cancellation-and-termination.mdx
new file mode 100644
index 0000000000..34ff95c796
--- /dev/null
+++ b/docs/encyclopedia/workflow/cancellation-and-termination.mdx
@@ -0,0 +1,136 @@
+---
+id: cancellation-and-termination
+title: Cancellation and Termination
+sidebar_label: Cancellation and Termination
+description:
+ Cancellation asks a Workflow to stop and run cleanup. Termination stops it immediately without cleanup. Compare the two
+ and what each records.
+toc_max_heading_level: 4
+tags:
+ - Concepts
+ - Workflows
+ - Activities
+---
+
+Cancellation and Termination both stop a [Workflow Execution](/workflow-execution) before it finishes on its own. They
+differ in whether your Workflow code gets a say.
+
+Cancellation is cooperative. The Temporal Service delivers the request to the Workflow, and the Workflow decides what to
+do with it, which means it can release resources, compensate for completed steps, and choose its own closing status.
+Termination is forceful. The Workflow Execution is closed immediately and Workflow code never sees the request, so no
+cleanup runs.
+
+Prefer Cancellation. Reach for Termination when a Workflow can't process a Cancellation request, such as when it's
+blocked on a non-deterministic error or has no Workers to run its Tasks.
+
+## Operations summary
+
+| Operation | What it does | CLI |
+| ------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+| [Cancellation](#cancellation) | Asks the Workflow to stop, letting it run cleanup first. | [`temporal workflow cancel`](/cli/command-reference/workflow#cancel) |
+| [Termination](#termination) | Closes the Workflow Execution immediately, with no cleanup. | [`temporal workflow terminate`](/cli/command-reference/workflow#terminate) |
+
+Both operations are also available through the Web UI, the SDK Clients, and the gRPC API. Both accept a
+[List Filter](/list-filter) instead of a Workflow Id to act on matching Workflow Executions in bulk.
+
+## Cancellation
+
+### What happens when you cancel a Workflow
+
+- A [WorkflowExecutionCancelRequested](/references/events#workflowexecutioncancelrequested) Event is recorded, carrying
+ the requester's identity and the reason.
+- The Temporal Service schedules a new [Workflow Task](/tasks#workflow-task), so the Workflow can react to the request.
+- The SDK surfaces the request to Workflow code as a Cancelled Failure. See
+ [How Temporal represents failures](/encyclopedia/application-failures#failure-representation).
+- The Workflow runs whatever cleanup its implementation supports.
+- The closing status depends on what the Workflow does next.
+
+Because Cancellation is delivered as a failure, unhandled Cancellation closes the Workflow Execution as **Canceled**
+rather than Failed, recording a [WorkflowExecutionCanceled](/references/events#workflowexecutioncanceled) Event. A
+Workflow that handles the request and returns normally closes as **Completed**. Both are valid outcomes; which one you
+want is a business decision, not a technical one.
+
+Cleanup that calls Activities has to run outside the canceled scope, because a canceled scope can't schedule new work.
+Each SDK provides a mechanism for this, such as `workflow.NewDisconnectedContext` in Go. See the SDK guides below.
+
+### Cancellation and Activities
+
+Activity Cancellations are delivered to the Activity when it [Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat).
+This has two consequences worth planning around:
+
+- An Activity that doesn't Heartbeat can't receive a Cancellation. It runs to completion, fails, or times out.
+- Heartbeat throttling can delay delivery, so Cancellation may reach the Activity later than the request was made.
+
+If you need a long-running Activity to stop when its Workflow is canceled, it has to Heartbeat.
+
+### Cancellation across Workflow boundaries
+
+A Workflow can request Cancellation of another Workflow Execution. This records a
+[RequestCancelExternalWorkflowExecutionInitiated](/references/events#requestcancelexternalworkflowexecutioninitiated)
+Event in the requesting Workflow, followed by
+[ExternalWorkflowExecutionCancelRequested](/references/events#externalworkflowexecutioncancelrequested) once the Service
+delivers it. When the target is a [Child Workflow](/child-workflows), the parent records
+[ChildWorkflowExecutionCanceled](/references/events#childworkflowexecutioncanceled).
+
+## Termination
+
+### What happens when you terminate a Workflow
+
+- A [WorkflowExecutionTerminated](/references/events#workflowexecutionterminated) Event is recorded with the reason and
+ the requester's identity. This is the closing Event in the Workflow Execution's Event History.
+- Workflow code can't see or respond to the termination, so no cleanup runs and no compensation happens.
+- Pending Activities are not given a chance to stop cleanly.
+
+The reason is optional and defaults to the current user's name. Provide one — it's the only record of why the Workflow
+Execution was stopped.
+
+Anything a terminated Workflow would have cleaned up is left as it was: reserved inventory stays reserved, held locks
+stay held, partial writes stay written. If that matters for your use case, cancel instead, and terminate only if the
+Cancellation doesn't take effect.
+
+## Which one should you use?
+
+| | Cancellation | Termination |
+| ---------------------------- | ----------------------------------------------- | ---------------------------------- |
+| **Workflow code notified?** | Yes, as a Cancelled Failure | No |
+| **Cleanup and compensation** | Runs, if the Workflow implements it | Doesn't run |
+| **Closing status** | Canceled, or Completed if the Workflow handles it and returns normally | Terminated |
+| **Closing Event** | WorkflowExecutionCanceled | WorkflowExecutionTerminated |
+| **Takes effect** | On the next Workflow Task | Immediately |
+| **Works on a stuck Workflow** | No, the Workflow has to process the request | Yes |
+| **Failure type** | Cancelled Failure | Terminated Failure |
+
+## Child Workflows
+
+A [Parent Close Policy](/parent-close-policy) decides what happens to a Child Workflow Execution when its parent reaches
+a Closed status. Two of the three values are these same operations:
+
+- **Terminate** (the default): the child is forcefully Terminated.
+- **Request Cancel**: a Cancellation request is sent to the child.
+- **Abandon**: the child isn't affected.
+
+Each child sets its own policy, so a parent can terminate some children, cancel others, and leave the rest running.
+
+## Related controls
+
+These operations also stop a Workflow Execution from progressing, but they aren't Cancellation or Termination:
+
+- **[Workflow Pause](/encyclopedia/workflow/workflow-pause)** holds a Workflow Execution in place without closing it or
+ losing state. A cancel request sent to a Paused Workflow is recorded and takes effect after the Workflow is Unpaused. A terminate request takes effect immediately.
+- **[Reset](/cli/command-reference/workflow#reset)** terminates the current Run and starts a new Run from a point you
+ choose in the Event History. Use it when a Workflow is blocked by a non-deterministic error you've since fixed.
+- **Timeouts** close a Workflow Execution as Timed Out rather than Canceled or Terminated. See
+ [Detecting Workflow failures](/encyclopedia/detecting-workflow-failures).
+
+## Handle Cancellation in your SDK
+
+Cancellation is the half of this that needs Workflow code. Termination needs none.
+
+- [.NET SDK](/develop/dotnet/workflows/cancellation)
+- [Go SDK](/develop/go/workflows/cancellation)
+- [Java SDK](/develop/java/workflows/cancellation)
+- [PHP SDK](/develop/php/workflows/cancellation)
+- [Python SDK](/develop/python/workflows/cancellation)
+- [Ruby SDK](/develop/ruby/workflows/cancellation)
+- [Rust SDK](/develop/rust/workflows/cancellation)
+- [TypeScript SDK](/develop/typescript/workflows/cancellation)
diff --git a/docs/encyclopedia/workflow/workflow-pause.mdx b/docs/encyclopedia/workflow/workflow-pause.mdx
index cbaa1ae0d5..4727a619e2 100644
--- a/docs/encyclopedia/workflow/workflow-pause.mdx
+++ b/docs/encyclopedia/workflow/workflow-pause.mdx
@@ -157,7 +157,7 @@ request ID.
- Signals are accepted while Paused and processed after the Workflow is Unpaused.
- Updates and Queries are rejected while Paused.
- Cancel requests are recorded while Paused, but cancellation takes effect after the Workflow is Unpaused.
-- [Terminate](/evaluate/development-production-features/interrupt-workflow) requests still terminate the Workflow
+- [Terminate](/encyclopedia/workflow/cancellation-and-termination#termination) requests still terminate the Workflow
immediately.
- Resetting a Paused Workflow terminates the current Run and starts a new Run from the selected reset point.
diff --git a/docs/evaluate/development-production-features/core-application.mdx b/docs/evaluate/development-production-features/core-application.mdx
deleted file mode 100644
index 5aef3153af..0000000000
--- a/docs/evaluate/development-production-features/core-application.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: core-application
-title: Core application - Temporal feature
-description: Discover Temporal's Workflow, Activity, and Worker framework; orchestrate steps, encapsulate business logic, and execute code efficiently using the Temporal SDK in your favorite language.
-sidebar_label: Core application
-tags:
- - Workflows
- - Activities
- - Workers
- - Temporal SDKs
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-**Workflows**, **Activities**, **Standalone Activities**, and **Workers** form the core parts of a Temporal Application.
-
-**Workflows**: A Workflow defines the overall flow of the application.
-You write it in your programming language of choice using the Temporal SDK.
-Conceptually, a Workflow specifies a sequence of steps and orchestrates the execution of Activities.
-
-**Activities**: An Activity is a method or function that encapsulates business logic prone to failure (for example, calling a service that may go down).
-The system can automatically retry these Activities upon some failures.
-Activities perform a single, well-defined action, such as calling another service, transcoding a media file, or sending an email message.
-
-**Standalone Activities**: A Standalone Activity is a top-level [Activity Execution](/activity-execution) started directly by a [Client](/encyclopedia/temporal-client), without using a Workflow. Use a [Workflow](/workflows) to orchestrate multiple Activities, but if you just need to execute a single Activity, use a [Standalone Activity](/standalone-activity). Standalone Activities are Temporal's job queue.
-
-**Workers**: A Worker executes your Workflow and Activity code.
-
-**Follow one of our tutorials to [Get started](https://learn.temporal.io/getting_started/) learning how to develop Workflows and Activities and run them in Worker Processes.**
-
-Or jump straight to a Temporal SDK feature guide:
-
-
-
-
-
-
-
-
-
-
-
-
-For a deep dive into Temporal Workflows, Activities, and Workers, visit the following Temporal Encyclopedia pages or enroll in one of [our courses](https://learn.temporal.io/courses/).
-
-- [Temporal Workflows](/workflows)
-- [Temporal Activities](/activities)
-- [Temporal Workers](/workers)
diff --git a/docs/evaluate/development-production-features/data-encryption.mdx b/docs/evaluate/development-production-features/data-encryption.mdx
deleted file mode 100644
index ba428ad09b..0000000000
--- a/docs/evaluate/development-production-features/data-encryption.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: data-encryption
-title: Data encryption - Temporal feature
-description: Implement data encryption in your Temporal Workflows to ensure the security and confidentiality of your data.
-sidebar_label: Data encryption
-tags:
- - Codec Server
- - Security
- - Encryption
- - Workflows
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-Data Converters in Temporal are SDK components that handle the serialization and encoding of data transmitted and received by a Temporal Client.
-Workflow input and output need to be serialized and deserialized so they can be sent as JSON to the Temporal Service.
-
-Temporal provides its own default Data Converter logic, which is not apparent to a user if payloads contain plain text or JSON data.
-For enhanced security, you can implement your own encryption standards using a Codec Server.
-Temporal's data encryption capabilities ensure the security and confidentiality of your Workflows and provides protection without compromising performance.
-
-Jump straight to a Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/debugging.mdx b/docs/evaluate/development-production-features/debugging.mdx
deleted file mode 100644
index 93f6942d63..0000000000
--- a/docs/evaluate/development-production-features/debugging.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: debugging
-title: Debugging - Temporal feature
-description: Discover Temporal's comprehensive debugging capabilities; tools and frameworks that facilitate Workflow and activity debugging across different programming languages with Temporal.
-sidebar_label: Debugging
-tags:
- - Debugging
- - Errors
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-Temporal offers powerful and efficient debugging capabilities for both development and production. These capabilities help developers inspect and troubleshoot Workflows and Activities with precision, ensuring that Workflows perform as expected.
-
-By leveraging detailed event histories and intuitive tooling, you can trace the execution path of Workflows, identify issues, and understand the state of your application at any given point in time.
-
-Jump straight to a Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/failure-detection.mdx b/docs/evaluate/development-production-features/failure-detection.mdx
deleted file mode 100644
index b38efa7494..0000000000
--- a/docs/evaluate/development-production-features/failure-detection.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-id: failure-detection
-title: Failure detection - Temporal feature
-description: Explore Temporal's robust timeout and Retry Policy features for Workflows and Activities. Start with our tutorials or dive deep with our SDK guides and Encyclopedia resources.
-sidebar_label: Failure detection
-tags:
- - Workflows
- - Activities
- - Timeouts
- - Failures
- - Errors
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-In Temporal, timeouts detect application failures.
-The system can then automatically mitigate these failures through retries.
-Both major application function primitives, **Workflows** and **Activities**, have dedicated **timeout configurations** and can be configured with a **Retry Policy**.
-
-**Follow one of our tutorials to [Get started](https://learn.temporal.io/getting_started/) exploring timeouts and Retry Policies.**
-
-Or jump straight to a Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-For a deep dive into timeouts and Retry Policies visit the following Temporal Encyclopedia pages or enroll in one of [our courses](https://learn.temporal.io/courses/).
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/index.mdx b/docs/evaluate/development-production-features/index.mdx
deleted file mode 100644
index 852df3a6d5..0000000000
--- a/docs/evaluate/development-production-features/index.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: index
-title: Temporal development and production features
-description: Leverage a Temporal SDK to develop robust applications featuring Workflows, Activities, Workers, testing suites, Temporal Clients, Scheduled Workflows, and advanced observability tools.
-sidebar_label: Features
----
-
-Through a Temporal SDK, Temporal provides a wide range of features that enable developers to build applications that serve a wide range of use cases.
-
-- **[Core application primitives](/evaluate/development-production-features/core-application)**: Develop and run your application with Workflows, Activities, and Workers.
-- **[Testing suite](/evaluate/development-production-features/testing-suite)**: Each Temporal SDK comes with a testing suite that enables developers to test their applications as they would any other.
-- **[Scheduled Workflows](/evaluate/development-production-features/schedules)**: Start a business process at a specific time or on a given time interval.
-- **[Interrupt a Workflow](/evaluate/development-production-features/interrupt-workflow)**: Cancel or terminate a business process (Workflow) that is already in progress and compensate for any steps already taken.
-- **Runtime safeguards**: Prevent avoidable errors and issues from executing during runtime.
-- **[Failure detection and mitigation](/evaluate/development-production-features/failure-detection)**: Detect failures with timeouts and configure automatic retries to mitigate them.
-- **[Temporal Nexus](/evaluate/nexus)**: Connect Temporal Applications across (and within) isolated Namespaces for improved modularity, security, debugging, and fault isolation. Nexus supports cross-team, cross-domain, and multi-region use cases.
-- **[Workflow message passing](/evaluate/development-production-features/workflow-message-passing)**: Build responsive applications that react to events at runtime and enable data retrieval from ongoing Workflows.
-- **Versioning**: Support multiple versions of your business logic for long-running business processes.
-- **[Observability](/evaluate/development-production-features/observability)**: List business processes, view their state, and set up dashboards with metrics.
-- **[Debugging](/evaluate/development-production-features/debugging)**: Surface errors and step through code to find issues.
-- **[Data encryption](/evaluate/development-production-features/data-encryption)**: Transform data and protect the privacy of the users of your application.
-- **[Throughput composability](/evaluate/development-production-features/throughput-composability)**: Breakup business processes by data streams, team ownership, or other organization factors.
-- **[Cloud Automation](/evaluate/development-production-features/cloud-automation)**: Simplify cloud management and boost security with Temporal's Cloud Automation.
-- **[Low Latency](/evaluate/development-production-features/low-latency)**: Making your applications faster, more performant, and more efficient.
-- **[Multi-tenancy](/evaluate/development-production-features/multi-tenancy)**: Enhances efficiency and cost-effectiveness.
-
-For detailed information on Temporal feature release stages and criteria, see this [Product Release Stages Guide](/evaluate/development-production-features/release-stages).
diff --git a/docs/evaluate/development-production-features/interrupt-a-workflow.mdx b/docs/evaluate/development-production-features/interrupt-a-workflow.mdx
deleted file mode 100644
index f086eb3834..0000000000
--- a/docs/evaluate/development-production-features/interrupt-a-workflow.mdx
+++ /dev/null
@@ -1,61 +0,0 @@
----
-id: interrupt-workflow
-title: Interrupt a Workflow - Cancellation and Termination
-description:
- Manage Workflow interruptions in Temporal; understand how to gracefully handle Workflow cancellations and terminations
- to ensure proper cleanup and state management.
-sidebar_label: Interrupt a Workflow
-tags:
- - Workflows
----
-
-import { RelatedReadContainer, RelatedReadItem } from "@site/src/components";
-
-Discover how Temporal enables you to gracefully handle Workflow interruptions through cancellations and terminations.
-Understand how to stop a Workflow cleanly with cancellation, allowing for proper cleanup and state management.
-
-For situations where a Workflow is stuck, termination provides an immediate solution, ensuring your applications remain
-robust and responsive.
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/observability.mdx b/docs/evaluate/development-production-features/observability.mdx
deleted file mode 100644
index 18f01df415..0000000000
--- a/docs/evaluate/development-production-features/observability.mdx
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: observability
-title: Observability - Temporal feature
-description: Explore the observability and visibility features of Temporal, including Metrics, Tracing, Logging, and Visibility.
-sidebar_label: Observability
-tags:
- - Observability
- - Metrics
- - Logging
- - Visibility
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-Temporal's observability feature helps you track the state of your Workflows in real-time, providing tools for detailed metrics, tracing, comprehensive logging, and visibility into your application state.
-
-Monitor performance, trace Activity and Workflow Executions, debug, and filter Workflow Executions to gain deeper insights into your Workflows.
-
-**Key Components of Temporal's Observability and Visibility**
-
-- **Metrics**: Detailed performance metrics to track the health and efficiency of your Temporal Service and Workflows.
-- **Tracing**: End-to-end tracing of Workflow and Activity Executions to understand the flow and timing of operations.
-- **Logging**: Comprehensive logging capabilities for debugging and auditing purposes.
-- **Search Attributes**: Custom attributes that can be used to enhance searchability and provide additional context to Workflow Executions.
-- **Web UI**: A user-friendly interface for visualizing and interacting with your Workflows and Temporal Service state.
-
-**Benefits of Temporal's Observability and Visibility Features**
-
-- **Real-time Monitoring**: Track the state and progress of your Workflows as they execute.
-- **Performance Optimization**: Identify bottlenecks and optimize your Workflow and Activity implementations.
-- **Effective Debugging**: Quickly locate and diagnose issues in your Temporal applications.
-- **Compliance and Auditing**: Maintain detailed records of all Workflow executions for compliance and auditing purposes.
-- **Operational Insights**: Gain a deep understanding of your application's behavior and usage patterns.
-- **Scalability Management**: Monitor and manage the scalability of your Temporal Service effectively.
-
-Jump straight into the Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/schedules.mdx b/docs/evaluate/development-production-features/schedules.mdx
deleted file mode 100644
index b19716bea4..0000000000
--- a/docs/evaluate/development-production-features/schedules.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: schedules
-title: Schedules - Temporal feature
-description: Learn the benefits of scheduling Temporal Workflows and explore best practices to ensure timely and efficient execution of your business processes.
-sidebar_label: Schedules
-tags:
- - Schedules
- - Workflows
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-Temporal Schedules is a feature that allows you to "schedule" Temporal Workflows at specified times or intervals, adjusting for peak use.
-
-It offers a flexible way to automate and manage your Temporal Workflows, ensuring your business processes run smoothly and efficiently especially when handling time-sensitive tasks.
-
-1. **Automate Repetitive Tasks:**
- Schedules automate repetitive tasks, reducing manual intervention and ensuring timely execution of business processes.
-2. **Enhanced Workflow Control and Observability:**
- Gain complete control over your automation processes. With Schedules, you can create, backfill, delete, describe, list, pause, trigger, and update Workflow Executions.
-3. **Flexible Timing:**
- Schedule Workflow Executions to run at regular intervals or specific future times, ensuring they execute precisely when needed.
-4. **Reliable and Scalable:**
- Designed for reliability and scalability, Temporal Schedules handle the complexities of distributed systems while ensuring your Workflows run as intended, even during failures.
-5. **Eliminate External Dependencies:**
- Schedules remove the need to integrate external scheduling systems.
-
-If a Workflow Execution started by a Schedule is [Paused](/cli/command-reference/workflow#pause), it remains open and can affect future scheduled starts through the Schedule's Overlap Policy.
-For policy-specific behavior, see [Overlap Policy](/schedule#overlap-policy).
-
-Jump straight to a Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/temporal-nexus.mdx b/docs/evaluate/development-production-features/temporal-nexus.mdx
deleted file mode 100644
index 3e67bbf53a..0000000000
--- a/docs/evaluate/development-production-features/temporal-nexus.mdx
+++ /dev/null
@@ -1,71 +0,0 @@
----
-id: nexus
-title: Temporal Nexus - Temporal feature
-description: Temporal Nexus enables durable execution across team and namespace boundaries and promotes a modular architecture that enables each team to have its own namespace for improved security, troubleshooting, and blast radius isolation.
-sidebar_label: Temporal Nexus
-slug: /evaluate/nexus
-tags:
-- Nexus
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-import { CaptionedImage } from '@site/src/components';
-
-As Temporal adoption grows across teams, organizations partition their applications into isolated Namespaces for security and fault isolation.
-Nexus bridges these boundaries, connecting Temporal applications across Namespaces, regions, and clouds with built-in durable execution, observability, and access control.
-Each team retains ownership of their own Namespace while sharing capabilities through clean service contracts.
-Watch the [Nexus overview](https://www.youtube.com/watch?v=tJ1OwSFokOg&t=117s) for a walkthrough.
-
-## Before Nexus
-Connecting Namespaces was possible, but painful. It required extensive configuration, added operational overhead, and often depended on additional infrastructure
-
-- **Child Workflows** - Limited to the same Namespace. Cross-Namespace use leaks underlying implementation details, requiring callers to manage the target Namespace, Task Queue, and Workflow options.
-- **Activity wrappers** - Require per-target mTLS clients, adding configuration and certificate management overhead. Often over-permissioned, lack built-in observability, and require error-prone boilerplate for async results.
-- **Extra gateway infrastructure** - Not durable, difficult to debug across services, and adds another service to manage and patch.
-
-Nexus replaces all of these with a clean service contract between caller and handler, reducing code, and providing first-class observability.
-
-## Benefits
-
-Connect Temporal Applications across teams, domains, regions, and clouds with:
-
-- **Stronger security posture** - Built-in access controls for service contracts instead of broad Namespace access. Each team controls their own Namespace, Workers, and deployment lifecycle.
-- **Higher reliability** - Durable, atomic handoffs eliminate lost requests. Faults are isolated so misbehaving Workers don't impact other teams.
-- **Easier to build and maintain** - Less boilerplate code, custom retry and deduplication logic, and ongoing maintenance. Teams focus on business logic instead of infrastructure.
-- **Scalable platform patterns** - Enables cross-team and cross-region orchestration without centralizing ownership.
-- **Lower barriers to cross-team use cases** - Makes it easy to incrementally build and adopt shared services, with built-in discoverability.
-- **Compliance and data isolation** - Isolated Namespaces support auditability, data residency requirements, and dedicated encryption and access controls for sensitive data (PCI, PII).
-
-## What customers are using Nexus for
-
-- **Duolingo** - Self-service infrastructure ([Case study](https://temporal.io/resources/case-studies/duolingo-temporal-nexus) | [Webinar](https://www.youtube.com/watch?v=tJ1OwSFokOg&t=524s))
-- **Netflix** - Infrastructure orchestration ([Replay talk](https://www.youtube.com/watch?v=izR9dQ_eIe4&t=470s) | [Webinar](https://www.youtube.com/watch?v=At1FfqGQiu0&t=1295s))
-- **Miro** - Cross-region data migration ([Replay talk](https://youtu.be/YLmFR-IAC3M?feature=shared&t=1488))
-
-
-## Should I use Nexus?
-
-Use the following decision tree to help determine if Nexus is right for your use case:
-
-
-
-
-
-## Get started {/* #learn-more */}
-
-Join the [#nexus](https://temporalio.slack.com/archives/C07LQN0JK9B) channel in [Temporal Slack](https://t.mp/slack) to connect with the Nexus community.
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/testing-suite.mdx b/docs/evaluate/development-production-features/testing-suite.mdx
deleted file mode 100644
index c74b5f1632..0000000000
--- a/docs/evaluate/development-production-features/testing-suite.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: testing-suite
-title: Temporal Testing Suite - Temporal feature
-description: Explore Temporal's comprehensive testing suite; Frameworks that facilitate Workflow and integration testing across different programming languages with Temporal.
-sidebar_label: Testing suite
-tags:
- - Testing
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-In the context of Temporal, you can create these types of automated tests:
-
-1. End-to-end: Running a Temporal Server and Worker with all its Workflows and Activities; starting and interacting with Workflows from a Client.
-2. Integration: Anything between end-to-end and unit testing.
- Running Activities with mocked Context and other SDK imports (and usually network requests).
- Running Workers with mock Activities, and using a Client to start Workflows.
- Running Workflows with mocked SDK imports.
-3. Unit: Running a piece of Workflow or Activity code and mocking any code it calls.
-
-Jump straight to a Temporal SDK feature guide.
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/development-production-features/throughput-composability.mdx b/docs/evaluate/development-production-features/throughput-composability.mdx
deleted file mode 100644
index 5a5533b45f..0000000000
--- a/docs/evaluate/development-production-features/throughput-composability.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: throughput-composability
-title: Child Workflows - Temporal feature
-description: Leverage Temporal Child Workflows for enhanced composability and efficiency. Partition steps, manage resources, invoke multiple services, and execute periodic logic seamlessly.
-sidebar_label: Composability
-tags:
- - Child Workflows
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-In Temporal, **Child Workflows** enable applications to achieve another level of composability when it comes to throughput.
-
-The following example scenarios are a few reasons to use this feature:
-
-- To create a separate service that can be invoked from multiple other services or applications.
-- To partition a step into smaller chunks.
-- To manage a dedicated resource and guarantee uniqueness.
-- To execute logic periodically without overwhelming the parent business process.
-
-See the SDK feature guides for implementation details:
-
-
-
-
-
-
-
-
-
-
-
-
-For a deep dive into Child Workflows see the [Child Workflows Encyclopedia page](/child-workflows).
diff --git a/docs/evaluate/development-production-features/workflow-message-passing.mdx b/docs/evaluate/development-production-features/workflow-message-passing.mdx
deleted file mode 100644
index 031e8774aa..0000000000
--- a/docs/evaluate/development-production-features/workflow-message-passing.mdx
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: workflow-message-passing
-title: Workflow message passing - Temporal feature
-description: Enhance your Workflows with Signals and Queries, allowing dynamic responses to external events and real-time state access for comprehensive monitoring and tracking.
-sidebar_label: Workflow message passing
-tags:
- - Signals
- - Queries
- - Updates
- - Workflows
- - Activities
- - Workers
----
-
-import { RelatedReadContainer, RelatedReadItem } from '@site/src/components';
-
-Need to interact with your Workflow from outside of it? Think about use cases like these:
-
-- Your shipment-tracking Workflow needs to know when the item leaves the warehouse and is loaded into their truck. **Signal** your Workflow when the truck driver scans the barcode.
-- Folks in your company want to track the progress of their data migration Workflows. **Query** your running batch Workflow to get the data for the progress bar.
-- Your eCommerce shopping cart Workflow needs to know when a new item is added. **Update** it to add the item and receive back the current items to render.
-
-Temporal provides Signals, Queries, and Updates to allow rich interactivity with your running Workflows.
-
-**Signals**: Signal to send messages asynchronously to a running Workflow, changing its state or controlling its flow in real-time.
-
-**Queries**: Query to check the progress of your Workflow or debug the internal state in real-time.
-
-**Updates**: Update to send synchronous requests to your Workflow and track it in real-time.
-
-To learn more about using these powerful primitives, see our encyclopedia entry:
-
-
-
-
-
-For a deeper dive into Workflow message passing, enroll in one of [our courses](https://learn.temporal.io/courses/interacting_with_workflows).
-
-If you want to jump straight to implementation details, see the SDK feature guides.
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/evaluate/features/cancellation-and-termination.mdx b/docs/evaluate/features/cancellation-and-termination.mdx
new file mode 100644
index 0000000000..0f2c82d8f3
--- /dev/null
+++ b/docs/evaluate/features/cancellation-and-termination.mdx
@@ -0,0 +1,102 @@
+---
+id: cancellation-and-termination
+title: Cancellation and termination
+description:
+ Stop a Workflow already in progress, either by asking it to unwind the work it has done or by closing it outright when
+ it can't respond.
+sidebar_label: Cancellation and termination
+tags:
+ - Workflows
+ - Activities
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+A business process that's already running sometimes has to stop: an order is retracted, a customer closes an account, a
+deploy goes wrong. Temporal gives you two ways to stop a
+[Workflow Execution](/workflow-execution), and the difference between them is whether your code gets to clean up after
+itself.
+
+**Cancellation** asks the Workflow to stop. The Workflow receives the request, so it can release resources, undo steps it
+has already taken, and notify other systems before closing. The steps it takes are your code, so you decide what
+unwinding a half-finished process means.
+
+**Termination** closes the Workflow Execution immediately. Workflow code never sees the request and no cleanup runs. It
+works on a Workflow that can't respond to anything, which is what makes it the fallback when Cancellation won't land.
+
+## What this means for your design
+
+- **You write the cleanup.** Temporal delivers the Cancellation request and
+ schedules a Workflow Task so your code can act on it. You can specify what to undo, and in what order. If your
+ process reserves inventory, charges cards, or provisions infrastructure, plan the unwind path alongside the forward
+ one. See the [Saga Pattern](/design-patterns/saga-pattern) for the usual structure.
+- **Long-running Activities need Heartbeats to be cancellable.** Cancellation reaches an Activity when it Heartbeats, so
+ an Activity that never Heartbeats runs to completion regardless. This shapes how you write anything long-running.
+- **You always have a way out.** A Workflow blocked by a bug, a bad deploy, or a missing Worker can still be terminated,
+ so a stuck process is never permanently stuck.
+- **The record survives the stop.** Both operations are recorded in
+ [Event History](/workflow-execution/event#event-history) with who requested it and why, which matters for audit and
+ incident review.
+
+Cancellation and Termination close a Workflow for good. To hold one in place and resume it later, see
+[Workflow Pause](/encyclopedia/workflow/workflow-pause).
+
+## Resources
+
+Read the Temporal Encyclopedia for conceptual depth:
+
+- [Cancellation and Termination](/cancellation-and-termination)
+- [Parent Close Policy](/parent-close-policy)
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/features/child-workflows.mdx b/docs/evaluate/features/child-workflows.mdx
new file mode 100644
index 0000000000..a7e2f4c6b1
--- /dev/null
+++ b/docs/evaluate/features/child-workflows.mdx
@@ -0,0 +1,117 @@
+---
+id: child-workflows
+title: Child Workflows
+description: Child Workflows give part of a business process its own Event History, Workers, and lifecycle, with the limits and trade-offs versus one Workflow.
+sidebar_label: Child Workflows
+tags:
+ - Child Workflows
+ - Workflows
+ - Event History
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+A **[Child Workflow](/child-workflows)** is a [Workflow Execution](/workflow-execution) started by another Workflow.
+The child gets its own [Event History](/workflow-execution/event#event-history), can run on a separate set of [Workers](/workers#worker), and has its own lifecycle.
+That lets a Parent Workflow hand off part of a business process instead of running every step itself.
+
+## When to use a Child Workflow
+
+- **[Create a separate service](/child-workflows#create-a-separate-service)**: because a child can be processed by a completely separate set of Workers than its parent, it can act as its own service. Parent and child share no local state and communicate only through asynchronous [Signals](/sending-messages#sending-signals). To compose across Namespace boundaries, or between teams that own separate Temporal Applications, use [Temporal Nexus](/evaluate/nexus) instead.
+- **[Partition a large workload](/child-workflows#partition-problems-into-smaller-chunks)**: each child has its own Event History, so splitting work across children raises the ceiling on how many steps one business process can take.
+- **[Represent a single resource](/child-workflows#represent-a-single-resource)**: map one child to one resource and use its [Workflow Id](/workflow-execution/workflowid-runid) to guarantee uniqueness, which serializes every operation on that resource.
+- **[Run periodic logic](/child-workflows#periodic-logic-execution)**: a child can call [Continue-As-New](/workflow-execution/continue-as-new) as many times as it needs and then complete. From the parent's point of view it was a single invocation, so the periodic work never fills the parent's Event History.
+
+## When not to use a Child Workflow
+
+- **For code organization alone.** Use the object-oriented structure and other organizing techniques your language already offers.
+- **When the workload has a bounded size.** Start from a single Workflow Definition when you can put a ceiling on the number of Activity Executions and Signals. One Workflow is simpler to reason about than several communicating asynchronously.
+- **When Activities would do.** Child Workflow Executions record more Events overall than Activities do, and each Event in an Event History costs compute. Start with a single Workflow that calls Activities, and add Child Workflows once you have a clear reason.
+
+### Child Workflow or Activity?
+
+Both are started from a Workflow, which makes the choice easy to get wrong.
+A Child Workflow has access to all Workflow APIs but is subject to the same [deterministic constraints](/workflow-definition#deterministic-constraints) as any other Workflow.
+An Activity has the inverse trade-off: no access to Workflow APIs, but no determinism constraints either.
+See [Child Workflow versus an Activity](/child-workflows#child-workflow-versus-an-activity) for the full comparison.
+
+## Limits to plan for
+
+These numbers shape how you partition a business process:
+
+- A Workflow Execution's Event History is capped at 51,200 Events or 50 MB, with a warning at 10,240 Events or 10 MB.
+- A Workflow Execution can have at most 2,000 incomplete Child Workflows at a time, by default.
+- A Parent Workflow's Event History records Events for each child's status, so a single parent should not spawn more than about 1,000 Child Workflow Executions.
+- Those figures compound: one parent running 1,000 children that each run 1,000 Activity Executions reaches 1,000,000 Activity Executions, far past what one Workflow Execution can hold.
+
+See [Workflow Execution limits](/workflow-execution/limits) for the full set.
+
+## Parent Close Policy
+
+Every Child Workflow Execution carries a [Parent Close Policy](/parent-close-policy) that decides what happens to the child when its parent reaches a Closed status:
+
+- **Terminate** (the default): the child is forcefully Terminated.
+- **Request Cancel**: a Cancellation request is sent to the child.
+- **Abandon**: the child keeps running.
+
+Each child can set its own policy, so a parent can terminate some children and leave others running.
+
+## Resources
+
+Read the Temporal Encyclopedia for conceptual depth:
+
+- [Child Workflows](/child-workflows)
+- [Parent Close Policy](/parent-close-policy)
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/development-production-features/cloud-automation.mdx b/docs/evaluate/features/cloud-automation.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/cloud-automation.mdx
rename to docs/evaluate/features/cloud-automation.mdx
diff --git a/docs/evaluate/development-production-features/cloud-vs-self-hosted.mdx b/docs/evaluate/features/cloud-vs-self-hosted.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/cloud-vs-self-hosted.mdx
rename to docs/evaluate/features/cloud-vs-self-hosted.mdx
diff --git a/docs/evaluate/features/core-primitives.mdx b/docs/evaluate/features/core-primitives.mdx
new file mode 100644
index 0000000000..82842f243a
--- /dev/null
+++ b/docs/evaluate/features/core-primitives.mdx
@@ -0,0 +1,91 @@
+---
+id: core-primitives
+title: Core primitives
+description: Discover Temporal's Workflow, Activity, and Worker framework; orchestrate steps, encapsulate business logic, and execute code efficiently using the Temporal SDK in your favorite language.
+sidebar_label: Core primitives
+tags:
+ - Workflows
+ - Activities
+ - Workers
+ - Temporal SDKs
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+[Workflows](/workflows), [Activities](/activities), [Standalone Activities](/standalone-activity), and [Workers](/workers) form the core parts of a Temporal Application.
+
+**[Workflows](/workflows)**: A Workflow defines the overall flow of the application.
+You write it in your programming language of choice using the Temporal SDK.
+Conceptually, a Workflow specifies a sequence of steps and orchestrates the execution of Activities.
+
+**[Activities](/activities)**: An Activity is a method or function that encapsulates business logic prone to failure (for example, calling a service that may go down).
+The system can automatically retry these Activities upon some failures.
+Activities perform a single, well-defined action, such as calling another service, transcoding a media file, or sending an email message.
+
+**[Standalone Activities](/standalone-activity)**: A Standalone Activity is a top-level [Activity Execution](/activity-execution) started directly by a [Client](/encyclopedia/temporal-client), without using a Workflow. Use a [Workflow](/workflows) to orchestrate multiple Activities, but if you just need to execute a single Activity, use a [Standalone Activity](/standalone-activity). Standalone Activities are Temporal's job queue.
+
+**[Workers](/workers)**: A Worker executes your Workflow and Activity code.
+
+## Resources
+
+Follow one of our [tutorials](https://learn.temporal.io/getting_started/) to develop Workflows and Activities and run them in Worker Processes, or enroll in one of [our courses](https://learn.temporal.io/courses/).
+
+Read the Temporal Encyclopedia pages for each core primitive:
+
+- [Temporal Workflows](/workflows)
+- [Temporal Activities](/activities)
+- [Temporal Standalone Activities](/standalone-activity)
+- [Temporal Workers](/workers)
+
+Or jump straight to a Temporal SDK develop docs:
+
+
diff --git a/docs/evaluate/features/data-encryption.mdx b/docs/evaluate/features/data-encryption.mdx
new file mode 100644
index 0000000000..e187073bb1
--- /dev/null
+++ b/docs/evaluate/features/data-encryption.mdx
@@ -0,0 +1,115 @@
+---
+id: data-encryption
+title: Data encryption
+description: Payload Codecs encrypt Workflow inputs, outputs, and Signals before they reach the Temporal Service, so plaintext stays on hosts you control.
+sidebar_label: Data encryption
+tags:
+ - Codec Server
+ - Security
+ - Encryption
+ - Workflows
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+The Temporal Service persists what your Workflows send it.
+Workflow inputs and results, Activity results, Signal and Query payloads, and memos are all recorded in the [Event History](/workflow-execution/event#event-history) and stay there for the length of the Namespace [Retention Period](/temporal-service/temporal-server#retention-period).
+
+A [Payload Codec](/payload-codec) encrypts those Payloads before they leave your process.
+The Service stores ciphertext, and the data exists unencrypted only on the Clients and Workers you run, on hosts you control.
+Temporal ships no default codec: the default [Data Converter](/dataconversion) serializes to JSON without encrypting, so encryption is something you add.
+
+Encrypted Payloads are unreadable in the Web UI and CLI, which is what a [Codec Server](/codec-server) is for.
+It's an HTTP server you run that holds the same decode logic as your codec.
+The Web UI and CLI send Payloads to it and display what it returns, so decrypted values reach the browser and the terminal only. The copy on the Temporal Service stays encrypted.
+
+## What you operate
+
+Encryption is opt-in, and each piece of it is yours to run:
+
+- **The codec.** You choose the cipher and write the `encode` and `decode` logic. Temporal doesn't hold or generate your keys.
+- **Key distribution.** Your Workers and your Codec Server need the same keys, which usually means [key management](/key-management) infrastructure you already have or have to stand up.
+- **The Codec Server.** You host it, secure it, and control access to it. Because it decodes sensitive data through a single API call, restrict it by putting it behind a VPN or adding authentication if it's reachable from the internet. It also needs [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) enabled to answer the Web UI.
+
+Where the endpoint gets configured depends on where the Temporal Service runs:
+
+- **Temporal Cloud.** A [Namespace Admin](/cloud/manage-access/roles-and-permissions#namespace-level-permissions) sets the Codec Server endpoint on the Namespace, which enables it for everyone on that Namespace. Cloud can pass a JWT access token with each request so your server can decide, per user, whether to return plaintext.
+- **Self-hosted.** The endpoint is set for the whole Temporal Service, though one Codec Server can route per Namespace. You configure Web UI authorization yourself.
+
+Expect the Web UI to send several requests per Workflow Execution, and expect the round trip to add latency when someone views an Event History.
+
+## What a codec doesn't cover
+
+- **Search Attributes** are persisted unencoded so the Visibility store can index them. Anything you need to search on is readable by the Service, so keep sensitive values out of [Search Attributes](/search-attribute) and in encrypted Payloads.
+- **Failure messages and stack traces** aren't encoded as codec-capable Payloads by default. Encoding them is an explicit opt-in through the [Failure Converter](/failure-converter).
+- **Payloads above the Service size limit** still need [External Storage](/external-storage), whether or not they're encrypted.
+- **Nexus Operations** pass through the Data Converter like any other Payload, so caller and handler Workers need compatible converters. See [Nexus security](/nexus/security#payload-encryption-data-converter).
+
+For how converters and codecs work, see the Encyclopedia pages on [data conversion](/dataconversion).
+For setting up and securing a Codec Server, see [Codecs and encryption](/production-deployment/data-encryption).
+
+## Resources
+
+
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/features/index.mdx b/docs/evaluate/features/index.mdx
new file mode 100644
index 0000000000..5b87370e62
--- /dev/null
+++ b/docs/evaluate/features/index.mdx
@@ -0,0 +1,100 @@
+---
+id: index
+title: Temporal development and production features
+description: Leverage a Temporal SDK to develop robust applications featuring Workflows, Activities, Workers, testing suites, Temporal Clients, Scheduled Workflows, and advanced observability tools.
+sidebar_label: Features
+keywords:
+ - temporal sdk
+ - core application primitives
+ - workflows in temporal
+ - activities and workers
+ - temporal testing suite
+ - temporal clients
+ - scheduled workflows
+ - workflow cancellation
+ - runtime safeguards
+ - failure detection in temporal
+ - automatic retries
+ - temporal messages
+ - business process versioning
+ - observability in workflows
+ - debugging temporal applications
+ - data encryption in applications
+ - throughput composability
+ - signals
+ - queries
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+Through a Temporal SDK, Temporal provides a wide range of features that enable developers to build applications that serve a wide range of use cases.
+
+
+
+Temporal also provides these features:
+
+- **Runtime safeguards**: Prevent avoidable errors and issues from executing during runtime.
+- **Versioning**: Support multiple versions of your business logic for long-running business processes.
+
+For detailed information on Temporal feature release stages and criteria, see this [Product Release Stages Guide](/evaluate/features/release-stages).
diff --git a/docs/evaluate/development-production-features/job-queue.mdx b/docs/evaluate/features/job-queue.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/job-queue.mdx
rename to docs/evaluate/features/job-queue.mdx
diff --git a/docs/evaluate/development-production-features/low-latency.mdx b/docs/evaluate/features/low-latency.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/low-latency.mdx
rename to docs/evaluate/features/low-latency.mdx
diff --git a/docs/evaluate/development-production-features/multi-tenant.mdx b/docs/evaluate/features/multi-tenant.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/multi-tenant.mdx
rename to docs/evaluate/features/multi-tenant.mdx
diff --git a/docs/evaluate/features/observability.mdx b/docs/evaluate/features/observability.mdx
new file mode 100644
index 0000000000..fbc7f82573
--- /dev/null
+++ b/docs/evaluate/features/observability.mdx
@@ -0,0 +1,135 @@
+---
+id: observability
+title: Observability
+description: Query live and closed Workflow Executions by your own business identifiers, export Prometheus-compatible metrics, and trace Executions across Worker processes.
+sidebar_label: Observability
+tags:
+ - Observability
+ - Metrics
+ - Logging
+ - Visibility
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+Temporal records every Workflow Execution as a durable [Event History](/workflow-execution/event#event-history): the inputs, every Activity result, every timer, and every message, in order.
+Logs and metrics tell you what a process reported while it was running.
+The Event History lets you replay what a Workflow actually did, including one that finished last week.
+
+Around that history, Temporal gives you three things you would otherwise assemble yourself.
+
+## Query Executions by your own identifiers
+
+[Visibility](/visibility) indexes running and closed Workflow Executions so you can list, filter, and count them with a SQL-like [List Filter](/list-filter).
+[Custom Search Attributes](/search-attribute#custom-search-attribute) put your own identifiers into that index like, an order Id, customer, region, or tier.
+An operator can then answer "which orders are stuck in payment retry" from the [Web UI](/web-ui) or the [CLI](/cli), without querying your application database.
+
+Visibility is a search index that Temporal updates asynchronously, so a List or Count query can return results that are a few seconds stale.
+It's built for finding Executions across many, not for reading the authoritative state of one.
+
+## Metrics from both sides of the connection
+
+Temporal emits two independent, Prometheus-compatible metric sets, and you need both:
+
+- **[SDK metrics](/references/sdk-metrics)** come from your Workers and Clients: task slot availability, Schedule-To-Start latency, Activity failures. They tell you whether your Workers are keeping up with the work.
+- **Temporal Service metrics** come from the Service: request rates, latencies, and errors. On Temporal Cloud these stream from the [OpenMetrics endpoint](/cloud/metrics/openmetrics) into Datadog, Grafana Cloud, New Relic, or your own Prometheus. Self-hosted deployments scrape [Temporal Service metrics](/references/cluster-metrics) directly.
+
+Watching one side alone hides the most common failure mode: the Service is accepting and serving work normally while Tasks pile up in a Task Queue because the Workers are under-provisioned.
+
+## Tracing and logs that survive process boundaries
+
+A Workflow Execution can span days, several Activities, and multiple Worker restarts, which is where hand-rolled tracing usually loses the thread.
+Temporal SDKs ship OpenTelemetry interceptors that propagate trace context from the Client into the Workflow and out to each Activity, across Worker processes, so one trace covers the whole Execution.
+
+SDKs also expose a logger for Workflow and Activity code that suppresses duplicate output during replay, so a retried or resumed Workflow doesn't repeat every log line it already emitted.
+
+## What you operate
+
+What you run yourself depends on where the Temporal Service runs:
+
+- **Temporal Cloud.** Visibility is enabled by default, and metrics come from the OpenMetrics endpoint. There's no Visibility store to size or upgrade. Both the [number of custom Search Attributes](/cloud/limits#number-of-custom-search-attributes) and the [Visibility API rate limit](/cloud/limits#visibility-api-rate-limit) are scoped per Namespace.
+- **Self-hosted.** You choose and operate the [Visibility store](/self-hosted-guide/visibility): MySQL v8.0.17+ or PostgreSQL v12+ on Temporal Server v1.20 and later, or Elasticsearch and OpenSearch. [Dual Visibility](/dual-visibility) covers migrating between them without downtime.
+
+On both, the Namespace [Retention Period](/temporal-service/temporal-server#retention-period) bounds how long closed Workflow Executions stay queryable. To keep Event Histories past that window, configure [Archival](/temporal-service/archival).
+
+## Resources
+
+
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/development-production-features/release-stages.mdx b/docs/evaluate/features/release-stages.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/release-stages.mdx
rename to docs/evaluate/features/release-stages.mdx
diff --git a/docs/evaluate/features/schedules.mdx b/docs/evaluate/features/schedules.mdx
new file mode 100644
index 0000000000..16ae3ec8d4
--- /dev/null
+++ b/docs/evaluate/features/schedules.mdx
@@ -0,0 +1,121 @@
+---
+id: schedules
+title: Schedules
+description: A Schedule starts Workflows on an interval or calendar expression, with Overlap Policy, Catchup Window, backfill, and pause controls the Temporal Service runs for you.
+sidebar_label: Schedules
+tags:
+ - Schedules
+ - Workflows
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+A [Schedule](/schedule) starts a [Workflow Execution](/workflow-execution) at times you define: on an interval, on a calendar expression, or on a combination of both.
+
+A Schedule is its own object in the Temporal Service with its own Id, separate from the Workflow Executions it starts.
+You can update, pause, backfill, or trigger it without changing or redeploying the Workflow code it runs.
+
+That separation is what you get instead of running a scheduler alongside your application.
+There's no second system to deploy, monitor, and reconcile with your Workers, and every start the Schedule makes is an ordinary Workflow Execution with the same durability, retries, and [Event History](/workflow-execution/event#event-history) as one you start by hand.
+
+## What a Schedule controls
+
+- **Spec.** When Actions happen: an interval (`45m`, or `6h/5h` for every six hours offset into the fifth hour) or a calendar expression, given as a cron string (`0 8 * * 1-5`, weekdays at 8:00 UTC) or as JSON with named fields (`{"dayOfMonth": "1,15", "hour": "11-14"}`). One Spec can combine several of each and add start and end times, exclusions, jitter, and a time zone. Exclusions and embedded time zone data are available through the SDKs and API, but not the CLI or Web UI.
+- **[Overlap Policy](/schedule#overlap-policy).** What happens when it's time to start and the previous Execution is still running: `Skip` (the default), `BufferOne`, `BufferAll`, `CancelOther`, `TerminateOther`, or `AllowAll`.
+- **[Catchup Window](/schedule#catchup-window).** Which missed Actions to take when the Temporal Service was unavailable at the scheduled time. The default is one year; the minimum is ten seconds.
+- **[Pause-on-failure](/schedule#pause-on-failure).** Pause the Schedule automatically when a scheduled Execution ends in failure or timeout.
+- **[Backfill](/schedule#backfill).** Run every Action for a past time range now, including a range from before the Schedule existed.
+- **[Action limit](/schedule#limit-number-of-actions).** Stop after a set number of scheduled Actions, after which the Schedule behaves as paused.
+
+Every Execution a Schedule starts carries the `TemporalScheduledStartTime` and `TemporalScheduledById` [Search Attributes](/search-attribute), so you can query scheduled runs with a [List Filter](/list-filter) the same way you query anything else.
+
+## What a Schedule doesn't do
+
+- **Pausing a Schedule doesn't pause what's already running.** It stops future Actions. Executions the Schedule already started keep going.
+- **A Paused Workflow Execution still counts as running.** When the Schedule evaluates its Overlap Policy, a Paused Execution is an open Execution, so `Skip` skips and `BufferOne` buffers behind it. See [Interaction with Workflow Pause](/schedule#workflow-pause).
+- **Listing Schedules is eventually consistent.** `ListSchedules` and `CountSchedules` are served by [Visibility](/visibility#operations-that-use-visibility) and share its rate limit, so a Schedule you just created or deleted may not appear right away.
+
+## How to choose between a Schedule, a Cron Job, and Start Delay
+
+- **Use a Schedule when the same Workflow has to run more than once.** It's the right choice as soon as you need to pause the series during an incident, change the timing without a deploy, or run the Actions an outage skipped. Use it for new applications even when the timing is a plain cron expression, because you get those controls whether or not you need them yet.
+- **Use [Start Delay](/workflow-execution/timers-delays#delay-workflow-execution) when there's exactly one run, at a time you know when you start it.** A trial expiry, a cancellation deadline, a reminder. It isn't recurring, and it's incompatible with both Schedules and Cron Jobs, so it's not a way to hold off the first Action of a Schedule. Set a start time on the Schedule Spec for that.
+- **Keep a [Temporal Cron Job](/cron-job) if you have one running, but don't write new ones.** A cron string is a property of the Workflow Execution rather than a separate object, so the next Run starts only after the current one closes, and changing or stopping the series means terminating the Workflow. A Schedule covers the same cases and lets you update it in place.
+
+If the waiting happens inside a Workflow that's already running, none of these apply. Use a [Timer](/workflow-execution/timers-delays#timer).
+
+## Resources
+
+
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/development-production-features/serverless-workers/index.mdx b/docs/evaluate/features/serverless-workers/index.mdx
similarity index 100%
rename from docs/evaluate/development-production-features/serverless-workers/index.mdx
rename to docs/evaluate/features/serverless-workers/index.mdx
diff --git a/docs/evaluate/features/temporal-nexus.mdx b/docs/evaluate/features/temporal-nexus.mdx
new file mode 100644
index 0000000000..8e9c498dad
--- /dev/null
+++ b/docs/evaluate/features/temporal-nexus.mdx
@@ -0,0 +1,138 @@
+---
+id: nexus
+title: Temporal Nexus
+description: Nexus connects Temporal Applications across Namespace, team, and region boundaries.
+sidebar_label: Temporal Nexus
+tags:
+ - Nexus
+ - Namespaces
+ - Workflows
+ - Temporal Cloud
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+import { CaptionedImage } from '@site/src/components';
+
+**[Temporal Nexus](/nexus)** connects Temporal Applications across isolated Namespaces, regions, and clouds.
+Each team keeps its own Namespace, Workers, and deployment lifecycle, and exposes a service contract that other teams call with the same durability, observability, and access control as the rest of Temporal.
+Callers get a durable, atomic handoff instead of a network call they have to make reliable themselves.
+Watch the [Nexus overview](https://www.youtube.com/watch?v=tJ1OwSFokOg&t=117s) for a walkthrough.
+
+## When to use Nexus {/* #should-i-use-nexus */}
+
+Use Nexus when a business process crosses a boundary you put in place on purpose:
+
+- **Separate teams or domains** - Each team owns its Namespace, Workers, and release cadence, and shares capability through a service contract instead of shared internals.
+- **Security and fault isolation** - Grant access to a Nexus Endpoint rather than to a whole Namespace. A misbehaving Worker affects its own Namespace, not its callers.
+- **Multiple regions or clouds** - Temporal Cloud routes Nexus requests across Namespaces in AWS and GCP over a global mTLS-secured mesh.
+- **Compliance and data residency** - Isolated Namespaces keep sensitive data (PCI, PII) under their own encryption, access controls, and audit trail.
+- **Shared internal services** - A registered Endpoint is discoverable, so teams can adopt an existing service instead of rebuilding it.
+
+Use the following decision tree to help determine if Nexus is right for your use case:
+
+
+
+
+
+## When not to use Nexus
+
+- **One team in one Namespace** - [Child Workflows](/evaluate/features/child-workflows) and [Activities](/activities) already compose work inside a Namespace, and an Endpoint is one more thing to register and operate. If you expect to split into separate Namespaces later, Nexus is still worth adopting now. It separates the contract from the implementation, so the migration is mostly configuration.
+- **Synchronous calls that can't finish fast** - A [Synchronous Operation](/nexus/operations#operation-lifecycle) has to complete within the 10-second handler deadline. Anything slower or less predictable belongs in an Asynchronous Operation.
+
+### Nexus, Child Workflows, or Activities?
+
+Connecting Namespaces without Nexus is possible, but each option costs you something:
+
+- **Child Workflows** are limited to the same Namespace. Using them across Namespaces leaks implementation details because the caller has to manage the target Namespace, Task Queue, and Workflow options.
+- **Activity wrappers** need a per-target mTLS client, so you take on configuration and certificate management. They tend to be over-permissioned, have no built-in cross-Namespace observability, and need error-prone boilerplate for asynchronous results.
+- **A gateway service** is not durable, is hard to debug across services, and is one more service to run and patch.
+
+Nexus replaces all three with a contract between caller and handler, less code, and first-class observability.
+
+## Limits to plan for
+
+- Nexus is available in the Go, Java, Python, TypeScript, .NET, and Rust SDKs. PHP and Ruby don't support it.
+- A Synchronous Operation must complete within a [10-second handler deadline](/cloud/limits#nexus-operation-request-timeout). An Asynchronous Operation has a [maximum ScheduleToClose duration of 60 days](/cloud/limits#nexus-operation-duration-limits).
+- A Workflow Execution can have 30 in-flight Nexus Operations at a time, and a handler Workflow accepts 2,000 callbacks, which sets how many callers can attach to it.
+- Temporal Cloud defaults to 100 Nexus Endpoints per Account and 1,000 caller Namespaces per Endpoint. Support can raise both.
+- The global Nexus Registry, runtime access controls, audit logging, and cross-region routing are Temporal Cloud features. On a self-hosted Temporal Service, you enable the HTTP API and Nexus dynamic configuration yourself, and external Nexus calls are still experimental.
+
+See [Nexus limits](/cloud/nexus/limits) for the full set.
+
+## How teams use Nexus
+
+- **Duolingo** uses Nexus for self-service infrastructure ([case study](https://temporal.io/resources/case-studies/duolingo-temporal-nexus) | [webinar](https://www.youtube.com/watch?v=tJ1OwSFokOg&t=524s)).
+- **Netflix** uses it to orchestrate infrastructure across teams ([Replay talk](https://www.youtube.com/watch?v=izR9dQ_eIe4&t=470s) | [webinar](https://www.youtube.com/watch?v=At1FfqGQiu0&t=1295s)).
+- **Miro** uses it for cross-region data migration ([Replay talk](https://youtu.be/YLmFR-IAC3M?feature=shared&t=1488)).
+
+For more architectural patterns built on Temporal, see [use cases and design patterns](/evaluate/use-cases-design-patterns).
+
+## Resources {/* #learn-more */}
+
+Join the [#nexus](https://temporalio.slack.com/archives/C07LQN0JK9B) channel in [Temporal Slack](https://t.mp/slack) to connect with the Nexus community.
+
+Read the Temporal Encyclopedia for conceptual depth:
+
+- [How Nexus works](/nexus)
+- [Nexus Security](/nexus/security)
+- [Nexus Patterns](/nexus/patterns)
+
+Or jump straight to an SDK quick start:
+
+
+
+Then set up Nexus on the deployment you run:
+
+
diff --git a/docs/evaluate/features/timeouts-and-retries.mdx b/docs/evaluate/features/timeouts-and-retries.mdx
new file mode 100644
index 0000000000..f5b475dde1
--- /dev/null
+++ b/docs/evaluate/features/timeouts-and-retries.mdx
@@ -0,0 +1,173 @@
+---
+id: timeouts-and-retries
+title: Timeouts and Retry Policies
+description: Detect Workflow and Activity failures with timeouts, then mitigate them with automatic retries. Configuration guides for every Temporal SDK.
+sidebar_label: Timeouts and retries
+tags:
+ - Workflows
+ - Activities
+ - Timeouts
+ - Failures
+ - Errors
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+In Temporal, timeouts detect application failures.
+The system can then automatically mitigate these failures through retries.
+Both major application function primitives, **[Workflows](/workflows)** and **[Activities](/activities)**, have dedicated **timeout configurations** and can be configured with a **[Retry Policy](/encyclopedia/retry-policies)**.
+
+Follow one of our tutorials to [Get started](https://learn.temporal.io/getting_started/) exploring timeouts and Retry Policies.
+
+## Workflow timeouts
+
+Each Workflow timeout limits a different aspect of a [Workflow Execution](/workflow-execution), and you set them when you start the Workflow Execution.
+
+- **[Workflow Execution Timeout](/encyclopedia/detecting-workflow-failures#workflow-execution-timeout)**: the maximum time a Workflow Execution can stay Open, including retries and any use of [Continue-As-New](/workflow-execution/continue-as-new). The default is infinite.
+- **[Workflow Run Timeout](/encyclopedia/detecting-workflow-failures#workflow-run-timeout)**: the maximum duration of a single [Workflow Run](/workflow-execution/workflowid-runid#run-id), which excludes retries and Continue-As-New. The default matches the Workflow Execution Timeout.
+- **[Workflow Task Timeout](/encyclopedia/detecting-workflow-failures#workflow-task-timeout)**: the maximum time a [Worker](/workers#worker) has to execute a [Workflow Task](/tasks#workflow-task) after picking it up from the [Task Queue](/task-queue). The default is 10 seconds, with a maximum of 120 seconds.
+
+Workflows are built to run for long periods and to survive failures, so most applications don't need a Workflow Execution Timeout or Workflow Run Timeout.
+A timeout limits how long a Workflow can absorb delays. To act after a set period inside a Workflow, use a [Timer](/workflow-execution/timers-delays) instead.
+Workflow Execution and Workflow Run Timeouts are most often used to bound a [Temporal Cron Job](/cron-job).
+
+Set Workflow timeouts and Retry Policies in your language:
+
+
+
+## Activity timeouts
+
+Activity timeouts tell a Workflow which kind of Activity failure occurred, and the Activity's [Retry Policy](/encyclopedia/retry-policies) decides what happens next.
+
+- **[Schedule-To-Start Timeout](/encyclopedia/detecting-activity-failures#schedule-to-start-timeout)**: the maximum time an [Activity Task](/tasks#activity-task) can sit in the Task Queue before a Worker picks it up. The default is infinite, and this timeout never triggers a retry, because a retry would return the Activity Task to the same Task Queue.
+- **[Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout)**: the maximum time for a single [Activity Task Execution](/tasks#activity-task-execution). The default matches the Schedule-To-Close Timeout.
+- **[Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout)**: the maximum time for the whole [Activity Execution](/activity-execution), from the first Activity Task being scheduled to the last one closing. The default is infinite.
+- **[Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout)**: the maximum time between [Activity Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat), the pings a Worker sends to report that an Activity Execution is still making progress.
+
+Every Activity Execution needs either a Start-To-Close or a Schedule-To-Close Timeout.
+Set Start-To-Close: the [Temporal Service](/temporal-service) can't tell when a Worker crashes or loses contact, so it relies on this timeout to retry the Activity.
+Long-running Activities should also Heartbeat and set a Heartbeat Timeout, which detects a lost Worker sooner than a long Start-To-Close Timeout can.
+
+Set Activity timeouts and Retry Policies in your language:
+
+
+
+## Resources
+
+For a deep dive into timeouts and Retry Policies visit the following Temporal Encyclopedia pages or enroll in one of [our courses](https://learn.temporal.io/courses/).
+
+
diff --git a/docs/evaluate/features/workflow-message-passing.mdx b/docs/evaluate/features/workflow-message-passing.mdx
new file mode 100644
index 0000000000..cf1221bb2b
--- /dev/null
+++ b/docs/evaluate/features/workflow-message-passing.mdx
@@ -0,0 +1,153 @@
+---
+id: workflow-message-passing
+title: Workflow message passing
+description: Signals write to a running Workflow without waiting, Queries read its current state, and Updates do both and return a result to the caller.
+sidebar_label: Workflow message passing
+tags:
+ - Signals
+ - Queries
+ - Updates
+ - Workflows
+---
+
+import PatternCards from '@site/src/components/PatternCards';
+
+A running [Workflow Execution](/workflow-execution) can receive messages from outside itself.
+Its message handlers act on the Workflow's current state, which makes a Workflow behave like a stateful service with its own endpoints.
+Temporal has three message types: **Signals** are asynchronous write requests, **Queries** are read requests, and **Updates** are synchronous write requests that return a result.
+
+Each one fits a different job:
+
+- Your shipment-tracking Workflow needs to know when an item leaves the warehouse. **Signal** the Workflow when the driver scans the barcode.
+- Your team wants to track the progress of a data migration. **Query** the running batch Workflow for the numbers behind a progress bar.
+- Your shopping cart Workflow needs to add an item and render the cart. **Update** it to add the item and get the current contents back in the same call.
+
+## Choose a message type
+
+| | Signal | Query | Update |
+| ------------------------------------------------------ | ----------------- | ----- | ------------------- |
+| Reads Workflow state | No | Yes | Yes |
+| Changes Workflow state | Yes | No | Yes |
+| Caller waits for the handler | No | Yes | Yes |
+| Returns a value to the caller | No | Yes | Yes |
+| Recorded in the [Event History](/workflow-execution/event#event-history) | Yes | No | Yes, once accepted |
+| Handler can block | Yes | No | Yes |
+
+For **write requests**, the choice is whether the caller needs to know the outcome.
+Send a Signal when the caller can move on without a result and shouldn't depend on a Worker being available to accept the request.
+Send an Update when the caller needs a result or an error, wants low end-to-end latency, or should be rejected up front by a validator before the request enters the Workflow's Event History.
+
+For **read requests**, start with a Query.
+Queries never add Events to the Event History, and they work against completed Workflow Executions.
+Because a Query handler cannot block, reading a value that only exists once the Workflow reaches a certain state means either polling with Queries or writing the read as an Update, which is more efficient but does write to the Event History.
+
+For **combined read and write requests**, use an Update.
+If the request has to be asynchronous, send a Signal and poll with a Query.
+
+To stream a sequence of events out of a Workflow rather than answer a single request, see [Workflow Streams](/workflow-streams).
+
+## When not to use a message
+
+- **To change state from a Query.** A Query handler can inspect Workflow state but must not mutate it. Use a Signal or an Update.
+- **To carry data that's known at start time.** Pass it as a Workflow argument instead of sending a message after the Workflow starts.
+- **To reach a Child Workflow from inside a Workflow.** Send Updates from an Activity using a Temporal Client, not from Workflow code.
+- **For high fan-in with Updates.** A Workflow Execution can have only a small number of Updates in flight at once, while Signals have no equivalent per-message concurrency cap. See [Limits to plan for](#limits-to-plan-for).
+- **To stop a Workflow.** Cancellation and Termination are their own operations. See [Cancellation and Termination](/evaluate/features/cancellation-and-termination).
+
+## Send a message and start a Workflow in one call
+
+Both write types have a variant that starts a Workflow Execution if one isn't already running under the given [Workflow Id](/workflow-execution/workflowid-runid):
+
+- **[Signal-With-Start](/sending-messages#signal-with-start)** Signals a running Workflow Execution, or starts one and immediately Signals it. The operation is atomic, which makes it a way to lazily initialize a Workflow.
+- **[Update-With-Start](/sending-messages#update-with-start)** sends an Update and starts the Workflow if needed, in a single round trip, and requires a [Workflow Id conflict policy](/workflow-execution/workflowid-runid#workflow-id-conflict-policy). Unlike Signal-With-Start it is not atomic: the SDK retries the request, but the Update is not guaranteed to succeed. Self-hosted deployments should run [Temporal Server v1.28](https://github.com/temporalio/temporal/releases/tag/v1.28.0) or later.
+
+## Limits to plan for
+
+These figures are for Temporal Cloud. Self-hosted deployments configure their own, starting from the [self-hosted defaults](/self-hosted-guide/defaults).
+
+- A Workflow Execution can receive up to 10,000 Signals. It stops processing Signals after that.
+- A Workflow Execution can have at most 10 in-flight Updates, and 2,000 Updates total in its Event History.
+- A Workflow Execution can have at most 2,000 incomplete `SignalExternalWorkflowExecution` Commands at a time, which bounds how many Signals it can send to other Workflows at once.
+- A single request payload is capped at 2 MB, and any one Event History transaction at 4 MB. Offload larger payloads to [External Storage](/external-storage).
+
+See [System limits](/cloud/limits) for the full set.
+
+## Resources
+
+For conceptual depth on the three message types, read the Temporal Encyclopedia or enroll in one of [our courses](https://learn.temporal.io/courses/interacting_with_workflows).
+
+
+
+Or jump straight to the SDK feature guide for implementation details:
+
+
diff --git a/docs/evaluate/index.mdx b/docs/evaluate/index.mdx
index e134849e88..c6d397c59a 100644
--- a/docs/evaluate/index.mdx
+++ b/docs/evaluate/index.mdx
@@ -15,7 +15,7 @@ Applications benefit from fault-tolerance and execution guarantees.
Thousands of companies of all sizes are leveraging Temporal's capabilities for both mission critical and standard workloads.
- [Why Temporal](/evaluate/why-temporal)
-- [Development and production features](/evaluate/development-production-features)
+- [Development and production features](/evaluate/features)
- [Use cases](/evaluate/use-cases-design-patterns)
- [Temporal Cloud](/cloud)
- [Security](/security)
diff --git a/docs/glossary.md b/docs/glossary.md
index 4cef188100..406e2f0c60 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -254,7 +254,7 @@ responsible for rate limiting, authorizing, validating, and routing all inbound
-#### [General Availability](/evaluate/development-production-features/release-stages#general-availability)
+#### [General Availability](/evaluate/features/release-stages#general-availability)
Learn more about the General Availability release stage
@@ -475,13 +475,13 @@ A Payload Converter serializes data, converting objects or values to bytes and b
-#### [Pre-release](/evaluate/development-production-features/release-stages#pre-release)
+#### [Pre-release](/evaluate/features/release-stages#pre-release)
Learn more about the Pre-release stage
-#### [Public Preview](/evaluate/development-production-features/release-stages#public-preview)
+#### [Public Preview](/evaluate/features/release-stages#public-preview)
Learn more about the Public Preview release stage
diff --git a/docs/production-deployment/self-hosted-guide/checklist.mdx b/docs/production-deployment/self-hosted-guide/checklist.mdx
index 2d8de3c604..bad57d1788 100644
--- a/docs/production-deployment/self-hosted-guide/checklist.mdx
+++ b/docs/production-deployment/self-hosted-guide/checklist.mdx
@@ -15,7 +15,7 @@ This page covers common challenges you'll face when self-hosting Temporal for pr
:::note
-This guide covers self-hosted deployments. If you're weighing self-hosting against a managed offering, see [Temporal Cloud vs. self-hosted Temporal](/evaluate/development-production-features/cloud-vs-self-hosted-features).
+This guide covers self-hosted deployments. If you're weighing self-hosting against a managed offering, see [Temporal Cloud vs. self-hosted Temporal](/evaluate/features/cloud-vs-self-hosted-features).
:::
diff --git a/sidebars.js b/sidebars.js
index 34e8bcb975..d0ecafeca2 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -1172,32 +1172,30 @@ module.exports = {
collapsed: true,
link: {
type: 'doc',
- id: 'evaluate/development-production-features/index',
+ id: 'evaluate/features/index',
},
items: [
- 'evaluate/development-production-features/core-application',
- 'evaluate/development-production-features/failure-detection',
- 'evaluate/development-production-features/throughput-composability',
- 'evaluate/development-production-features/nexus',
- 'evaluate/development-production-features/workflow-message-passing',
- 'evaluate/development-production-features/debugging',
- 'evaluate/development-production-features/interrupt-workflow',
- 'evaluate/development-production-features/testing-suite',
- 'evaluate/development-production-features/observability',
- 'evaluate/development-production-features/data-encryption',
- 'evaluate/development-production-features/schedules',
- 'evaluate/development-production-features/cloud-automation',
- 'evaluate/development-production-features/low-latency',
- 'evaluate/development-production-features/multi-tenancy',
- 'evaluate/development-production-features/job-queue',
- 'evaluate/development-production-features/serverless-workers/index',
+ 'evaluate/features/core-primitives',
+ 'evaluate/features/timeouts-and-retries',
+ 'evaluate/features/child-workflows',
+ 'evaluate/features/nexus',
+ 'evaluate/features/workflow-message-passing',
+ 'evaluate/features/cancellation-and-termination',
+ 'evaluate/features/observability',
+ 'evaluate/features/data-encryption',
+ 'evaluate/features/schedules',
+ 'evaluate/features/cloud-automation',
+ 'evaluate/features/low-latency',
+ 'evaluate/features/multi-tenancy',
+ 'evaluate/features/job-queue',
+ 'evaluate/features/serverless-workers/index',
{
type: 'category',
label: 'Product release stages',
collapsed: true,
link: {
type: 'doc',
- id: 'evaluate/development-production-features/release-stages',
+ id: 'evaluate/features/release-stages',
},
items: [
{
@@ -1954,6 +1952,7 @@ module.exports = {
'encyclopedia/workflow/workflow-execution/timers-delays',
],
},
+ 'encyclopedia/workflow/cancellation-and-termination',
'encyclopedia/workflow/workflow-pause',
'encyclopedia/workflow/dynamic-handler',
'encyclopedia/workflow/workflow-schedule',
diff --git a/src/components/elements/ReleaseNoteHeader/ReleaseNoteHeader.js b/src/components/elements/ReleaseNoteHeader/ReleaseNoteHeader.js
index d857de4ed5..9eb1b100a5 100644
--- a/src/components/elements/ReleaseNoteHeader/ReleaseNoteHeader.js
+++ b/src/components/elements/ReleaseNoteHeader/ReleaseNoteHeader.js
@@ -9,14 +9,14 @@ import { FEATURE_RELEASE_TYPES } from "../../../constants/featureReleaseTypes";
export const BASE_RELEASE_STAGES = {
prerelease: {
label: "Pre-release",
- descriptionLink: "/evaluate/development-production-features/release-stages#pre-release",
+ descriptionLink: "/evaluate/features/release-stages#pre-release",
backgroundColor: "var(--release-prerelease-bg)",
borderColor: "var(--release-prerelease-border)",
textColor: "var(--release-prerelease-text)",
},
publicPreview: {
label: "Public Preview",
- descriptionLink: "/evaluate/development-production-features/release-stages#public-preview",
+ descriptionLink: "/evaluate/features/release-stages#public-preview",
backgroundColor: "var(--release-public-preview-bg)",
borderColor: "var(--release-public-preview-border)",
textColor: "var(--release-public-preview-text)",
diff --git a/vercel.json b/vercel.json
index 978fa0e5b1..785d6c13b6 100644
--- a/vercel.json
+++ b/vercel.json
@@ -1413,6 +1413,10 @@
"source": "/evaluate/release-stages",
"destination": "/evaluate/development-production-features/release-stages"
},
+ {
+ "source": "/evaluate/development-production-features/release-stages",
+ "destination": "/evaluate/features/release-stages"
+ },
{
"source": "/concepts:path*",
"destination": "/encyclopedia"
@@ -2309,6 +2313,86 @@
"source": "/production-deployment/multi-tenant-patterns",
"destination": "/best-practices/multi-tenant-patterns",
"permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features",
+ "destination": "/evaluate/features",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/index",
+ "destination": "/evaluate/features",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/core-application",
+ "destination": "/evaluate/features/core-primitives",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/failure-detection",
+ "destination": "/evaluate/features/timeouts-and-retries",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/throughput-composability",
+ "destination": "/evaluate/features/child-workflows",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/nexus",
+ "destination": "/evaluate/features/nexus",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/workflow-message-passing",
+ "destination": "/evaluate/features/workflow-message-passing",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/interrupt-workflow",
+ "destination": "/evaluate/features/cancellation-and-termination",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/observability",
+ "destination": "/evaluate/features/observability",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/data-encryption",
+ "destination": "/evaluate/features/data-encryption",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/schedules",
+ "destination": "/evaluate/features/schedules",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/cloud-automation",
+ "destination": "/evaluate/features/cloud-automation",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/low-latency",
+ "destination": "/evaluate/features/low-latency",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/multi-tenancy",
+ "destination": "/evaluate/features/multi-tenancy",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/job-queue",
+ "destination": "/evaluate/features/job-queue",
+ "permanent": true
+ },
+ {
+ "source": "/evaluate/development-production-features/serverless-workers/index",
+ "destination": "/evaluate/features/serverless-workers",
+ "permanent": true
}
]
}