diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx
index 717b2056b3..56653c3897 100644
--- a/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx
@@ -11,7 +11,7 @@ type name. Note that the `provider` argument is distinct from the [`provider` bl
 
 ## Usage
 
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider.
 
 You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
 
@@ -31,11 +31,11 @@ resource "google_compute_instance" "example" {
 }
 ```
 
-Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions.
 
 A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
 
-Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
 
 ## Supported constructs
 
@@ -44,7 +44,7 @@ You can use `provider` in the following Terraform configuration blocks:
 - [`check` blocks](/terraform/language/block/check)
 - [`data` blocks](/terraform/language/block/data)
 - [`ephemeral` blocks](/terraform/language/block/ephemeral)
-- [`import` block ](/terraform/language/block/import)
+- [`import` block](/terraform/language/block/import)
 - [`resource` blocks](/terraform/language/block/resource)
 
 ## Example use cases
@@ -114,4 +114,4 @@ import {
 resource "aws_instance" "web" {
   # ...
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx
index 717b2056b3..56653c3897 100644
--- a/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx
@@ -11,7 +11,7 @@ type name. Note that the `provider` argument is distinct from the [`provider` bl
 
 ## Usage
 
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider.
 
 You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
 
@@ -31,11 +31,11 @@ resource "google_compute_instance" "example" {
 }
 ```
 
-Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions.
 
 A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
 
-Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
 
 ## Supported constructs
 
@@ -44,7 +44,7 @@ You can use `provider` in the following Terraform configuration blocks:
 - [`check` blocks](/terraform/language/block/check)
 - [`data` blocks](/terraform/language/block/data)
 - [`ephemeral` blocks](/terraform/language/block/ephemeral)
-- [`import` block ](/terraform/language/block/import)
+- [`import` block](/terraform/language/block/import)
 - [`resource` blocks](/terraform/language/block/resource)
 
 ## Example use cases
@@ -114,4 +114,4 @@ import {
 resource "aws_instance" "web" {
   # ...
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.14.x/docs/cli/import/index.mdx b/content/terraform/v1.14.x/docs/cli/import/index.mdx
index 6d1e7b13a3..e44648fe56 100644
--- a/content/terraform/v1.14.x/docs/cli/import/index.mdx
+++ b/content/terraform/v1.14.x/docs/cli/import/index.mdx
@@ -10,7 +10,6 @@ This topic provides an overview of the Terraform commands that let you import ex
 
 > **Hands-on:** Try the [Import Terraform Configuration](/terraform/tutorials/state/state-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
 
-
 ## Workflows
 
 You can import an existing resource to state from the Terraform CLI. You can also perform import operations using HCP Terraform. To import multiple resources, use the `import` block.  
diff --git a/content/terraform/v1.14.x/docs/language/block/moved.mdx b/content/terraform/v1.14.x/docs/language/block/moved.mdx
index b47ef87201..d6b3f4c12b 100644
--- a/content/terraform/v1.14.x/docs/language/block/moved.mdx
+++ b/content/terraform/v1.14.x/docs/language/block/moved.mdx
@@ -34,7 +34,7 @@ This section provides details about the fields you can configure in the `moved`
 
 The `moved` block specifies the previous address and the new address for the resource. The following table describes the arguments you can set in the `moved` block.
 
-| Arbument | Description | Type | Required |
+| Argument | Description | Type | Required |
 | ---   | ---         | ---  | ---      |
 | `from` | Specifies a resource's previous address. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
 | `to` | Specifies the new address to relocate the resource to. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
@@ -50,4 +50,4 @@ moved {
   from = aws_instance.a
   to   = aws_instance.b
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/component.mdx b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/component.mdx
index 4c997836b5..f37cbec8b0 100644
--- a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/component.mdx
+++ b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/component.mdx
@@ -130,6 +130,12 @@ The keys in the `providers` map must match the provider names that the source mo
 
 `providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
+#### Summary
+
+- Data type: Map
+- Default: None
+- Required: Yes
+
 
 ### `inputs`
 
@@ -171,6 +177,7 @@ component "app_server" {
   # ...
 }
 ```
+
 You do not need to include the dependant component’s outputs in the `depends_on` list because Terraform automatically recognizes those dependencies.
 
 `depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
@@ -211,7 +218,6 @@ When you use `for_each`, Terraform creates one component instance for each item
 
 `for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
-
 ## Examples
 
 The following examples demonstrate common use cases for `component` blocks.
diff --git a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/provider.mdx b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/provider.mdx
index d4fdecc607..31f8d6626d 100644
--- a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/provider.mdx
+++ b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/provider.mdx
@@ -113,11 +113,6 @@ When you use `for_each`, you can reference individual provider instances using `
 
 `for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
-#### Summary
-
-- Data type: Map or Set
-- Default: None
-
 ## Examples
 
 The following examples demonstrate common use cases for `provider` blocks in Stacks.
diff --git a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/removed.mdx b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/removed.mdx
index c920288924..c83bc7e0f4 100644
--- a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/removed.mdx
+++ b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/removed.mdx
@@ -154,7 +154,8 @@ removed {
 
 </Tabs>
 
-You can use `for_each` to remove components from specific regions or environments.
+
+The `for_each` meta-argument is useful when you want to remove components from specific regions or environments.
 
 `for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
diff --git a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/variable.mdx b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/variable.mdx
index 7bc0b67512..bf7bfe67ef 100644
--- a/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/variable.mdx
+++ b/content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/variable.mdx
@@ -59,7 +59,7 @@ The `variable` block supports the following arguments:
 | `description` | A description of the variable's purpose and the value it expects. | String | Optional |
 | `sensitive` | Specifies if Terraform hides this value in UI and logs. | Boolean | Optional |
 | `nullable` | Specifies if the value of a variable can be `null`. | Boolean | Optional |
-| `ephemeral` | Specifies whether Terraform excludes this value from plans and state. | Boolean | Boolean | Optional |
+| `ephemeral` | Specifies whether Terraform excludes this value from plans and state. | Boolean | Optional |
 
 ### `type`
 
diff --git a/content/terraform/v1.14.x/docs/language/data-sources/index.mdx b/content/terraform/v1.14.x/docs/language/data-sources/index.mdx
index a053e392c6..c6b605a894 100644
--- a/content/terraform/v1.14.x/docs/language/data-sources/index.mdx
+++ b/content/terraform/v1.14.x/docs/language/data-sources/index.mdx
@@ -68,7 +68,7 @@ data "aws_ami" "example" {
 }
 ```
 
-The `data` block instructs Terraform to read from the `aws_ami` data source and export the result to an object named `example`. To reference the returned data, use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax, for example, `data.aws_ami.example.id`. Refer to [Reference queried data](#referenece-queried-data) for more information.
+The `data` block instructs Terraform to read from the `aws_ami` data source and export the result to an object named `example`. To reference the returned data, use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax, for example, `data.aws_ami.example.id`. Refer to [Reference queried data](#reference-queried-data) for more information.
 
 ## Configure query constraints
 
@@ -113,7 +113,7 @@ data "aws_ami" "example" {
 }
 ```
 
-Custom conditions return useful information about errors earlier and in context so that you can more easily diagnose configuration issues. They also help future maintainers understand the configuration design and intent. Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
+Custom conditions return useful information about errors earlier and in context so that you can more easily diagnose configuration issues. They also help future maintainers understand the configuration design and intent. Refer to [Custom Condition Checks](/terraform/language/expressions/conditionals#conditions) for more details.
 
 ### Multiple instances
 
@@ -187,4 +187,4 @@ resource "aws_instance" "web" {
 }
 ```
 
-The `filter` blocks, and the arguments within them, and the `most_recent` argument are specific to the `aws_ami` provider. Refer to the [AWS provider documenation](https://registry.terraform.io/providers/hashicorp/aws/latest) in the Terraform registry for details. 
\ No newline at end of file
+The `filter` blocks, and the arguments within them, and the `most_recent` argument are specific to the `aws_ami` provider. Refer to the [AWS provider documenation](https://registry.terraform.io/providers/hashicorp/aws/latest) in the Terraform registry for details. 
diff --git a/content/terraform/v1.14.x/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.14.x/docs/language/meta-arguments/provider.mdx
index 3a235c9311..ad5167998a 100644
--- a/content/terraform/v1.14.x/docs/language/meta-arguments/provider.mdx
+++ b/content/terraform/v1.14.x/docs/language/meta-arguments/provider.mdx
@@ -11,9 +11,7 @@ type name. Note that the `provider` argument is distinct from the [`provider` bl
 
 ## Usage
 
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
-
-The default behavior does not apply to [`list` blocks](/terraform/language/block/tfquery/list), however, because Terraform does not implicitly use the default `provider` configuration when querying resources.  
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider.
 
 You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
 
@@ -33,11 +31,11 @@ resource "google_compute_instance" "example" {
 }
 ```
 
-Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions.
 
 A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
 
-Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
 
 ## Supported constructs
 
@@ -46,14 +44,13 @@ You can use `provider` in the following Terraform configuration blocks:
 - [`check` blocks](/terraform/language/block/check)
 - [`data` blocks](/terraform/language/block/data)
 - [`ephemeral` blocks](/terraform/language/block/ephemeral)
-- [`import` blocks ](/terraform/language/block/import)
+- [`import` block](/terraform/language/block/import)
 - [`resource` blocks](/terraform/language/block/resource)
 
 You can use `for_each` in the following query configuration blocks:
 
 - [`list` blocks](/terraform/language/block/tfquery/list)
 
-
 ## Example use cases
 
 The following use cases describe common patterns for the `provider` argument. Refer to the [examples in the `provider` block reference](/terraform/language/block/provider#examples) for more use cases.
@@ -121,4 +118,4 @@ import {
 resource "aws_instance" "web" {
   # ...
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.14.x/docs/language/modules/configuration.mdx b/content/terraform/v1.14.x/docs/language/modules/configuration.mdx
index afb809de7f..ecd2188ecc 100644
--- a/content/terraform/v1.14.x/docs/language/modules/configuration.mdx
+++ b/content/terraform/v1.14.x/docs/language/modules/configuration.mdx
@@ -44,6 +44,7 @@ In the following example, Terraform selects the module version from a Git reposi
 module "vpc" {
   source = "git::https://example.com/vpc.git?ref=v1.2.0"
 }
+```
 
 You can also source a module using its SHA-1 hash: 
 
@@ -66,7 +67,7 @@ Add the `depth` query parameter to the `source` URL and specify how many commits
 
 The following module sources support shallow clones:
 
-- [GitHub repositoris](/terraform/language/block/module#github-repository)
+- [GitHub repositories](/terraform/language/block/module#github-repository)
 - [Git repositories](/terraform/language/block/module#git-repository)
 - [BitBucket repositories](/terraform/language/block/module#bitbucket-repository)
 
@@ -179,4 +180,4 @@ removed {
 }
 ```
 
-Refer to [`moved` block reference](/terraform/language/block/removed) for more information.
\ No newline at end of file
+Refer to [`moved` block reference](/terraform/language/block/removed) for more information.
diff --git a/content/terraform/v1.14.x/docs/language/modules/develop/refactoring.mdx b/content/terraform/v1.14.x/docs/language/modules/develop/refactoring.mdx
index f89c53a3d5..5ac66ceaaf 100644
--- a/content/terraform/v1.14.x/docs/language/modules/develop/refactoring.mdx
+++ b/content/terraform/v1.14.x/docs/language/modules/develop/refactoring.mdx
@@ -22,7 +22,7 @@ You can use `moved` blocks for the following use cases:
 - [Rename a module call](#rename-a-module-call)
 - [Split a module](#split-a-module)
 
-When the module or resource is no longer necessary, you can [remove `moved` blocks](#remove-a-move-block) from the configuration. Note that removing a `moved` block is a breaking change.
+When the module or resource is no longer necessary, you can [remove `moved` blocks](#remove-a-moved-block) from the configuration. Note that removing a `moved` block is a breaking change.
 
 ## Requirements
 
@@ -109,7 +109,7 @@ resource (a `data` block).
 
 ## Create multiple instances
 
-You can use a `moved` block when creating mulitple instances of a resource or module call while preserving the original instance.
+You can use a `moved` block when creating multiple instances of a resource or module call while preserving the original instance.
 
 ### Enable `count` or `for_each` for a resource
 
@@ -416,7 +416,7 @@ moved {
 }
 ```
 
-## Remove a `move` block
+## Remove a `moved` block
 
 Over time, a long-lasting module may accumulate many `moved` blocks.
 
diff --git a/content/terraform/v1.14.x/docs/language/resources/configure.mdx b/content/terraform/v1.14.x/docs/language/resources/configure.mdx
index 53c706ce4c..80aeee3089 100644
--- a/content/terraform/v1.14.x/docs/language/resources/configure.mdx
+++ b/content/terraform/v1.14.x/docs/language/resources/configure.mdx
@@ -105,7 +105,7 @@ The following examples describe some common ways you can use meta-arguments in y
 
 ### Custom conditions
 
-Add `precondition` and `postcondition` blocks to specify assumptions and guarantees about how the resource operates. These blocks help avoid common misconfigurations and can help future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context so that consumers can diagnose issues in their configuration. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate) for instructions on creating custom condition checks.
+Add `precondition` and `postcondition` blocks to specify assumptions and guarantees about how the resource operates. These blocks help avoid common misconfigurations and can help future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context so that consumers can diagnose issues in their configuration. Refer to [Validate your configuration](/terraform/language/validate) for instructions on creating custom condition checks.
 
 For an example configuration, refer to [Apply custom conditions](/terraform/language/block/resource#apply-custom-conditions).
 
diff --git a/content/terraform/v1.14.x/docs/language/stacks/deploy/pass-data.mdx b/content/terraform/v1.14.x/docs/language/stacks/deploy/pass-data.mdx
index e8db22a3db..83de5a2b23 100644
--- a/content/terraform/v1.14.x/docs/language/stacks/deploy/pass-data.mdx
+++ b/content/terraform/v1.14.x/docs/language/stacks/deploy/pass-data.mdx
@@ -20,8 +20,8 @@ To consume the data exported by the upstream Stack, declare an `upstream_input`
 Downstream Stacks must reside in the same project as their upstream Stacks.
 
 The following limitations apply to passing data between Stacks:
-- Stacks can link to up to 20 other upstream Stacks. [Learn more about passing data between Stacks](/terraform/language/stacks/deploy/pass-data).
-- Stacks can expose values to up to 25 downstream Stacks. [Learn more about passing data between Stacks](/terraform/language/stacks/deploy/pass-data).
+- Stacks can link to up to 20 other upstream Stacks.
+- Stacks can expose values to up to 25 downstream Stacks.
 
 ## Expose outputs to another Stack
 
diff --git a/content/terraform/v1.14.x/docs/language/stacks/design.mdx b/content/terraform/v1.14.x/docs/language/stacks/design.mdx
index 5e4ca5fde0..96f114c036 100644
--- a/content/terraform/v1.14.x/docs/language/stacks/design.mdx
+++ b/content/terraform/v1.14.x/docs/language/stacks/design.mdx
@@ -27,7 +27,7 @@ Before writing your component configuration, we recommend assessing your current
 
 Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together.
 
-We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation lets you to manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
+We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation lets you manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
 
 ### Sketch out your configuration
 
diff --git a/content/terraform/v1.14.x/docs/language/stacks/update-GA.mdx b/content/terraform/v1.14.x/docs/language/stacks/update-GA.mdx
index e31adc3298..3251035711 100644
--- a/content/terraform/v1.14.x/docs/language/stacks/update-GA.mdx
+++ b/content/terraform/v1.14.x/docs/language/stacks/update-GA.mdx
@@ -22,11 +22,11 @@ The general availability release of Stacks introduced a few backward-incompatibl
 - Stacks no longer support the `<NAME>.tfstack.hcl` file extension.
   - The new extension for configuring your Stack components is `<NAME>.tfcomponent.hcl`. The file name change better reflects the mental model of a component-based configuration.
 
-## Billing Changes
+## Billing changes
 
 The Stacks public beta did not count toward your HCP Terraform organization's Resources Under Management (RUM). With the GA release, Stacks RUM is aggregated with your workspace RUM for billing purposes.
 
-### Billing Dashboard
+### Billing dashboard
 
 The HCP Terraform usage page has been updated to reflect the new billing metrics, including:
 
@@ -37,6 +37,13 @@ The HCP Terraform usage page has been updated to reflect the new billing metrics
 
 For more information on billing, refer to the [HCP Terraform pricing page](https://www.hashicorp.com/en/pricing).
 
+
+## UI changes
+
+You can no longer destroy Stack deployments and their resources from the HCP Terraform UI. To destroy a Stack deployment, add the [`destroy` argument](/terraform/language/block/stack/tfdeploy/deployment#destroy) to a `deployment` block, then trigger a new deployment run.
+
+To learn more about destroying Stacks and their deployments, refer to [Destroy a Stack](/terraform/cloud-docs/stacks/destroy).
+
 ## Steps for migration
 
 If you used Stacks during the public beta, you need to take a few steps to transition your existing configurations to the GA release.
@@ -108,4 +115,4 @@ For more information about deployment groups and auto-approval rules, refer to [
 
 ### Fetch your configuration
 
-Trigger a new configuration fetch for each of your Stacks. The fetching process pulls your configuration from your Version Control System (VCS) and reinitializes your Stack. You can do this by using the [`terraform stacks fetch`](/terraform/cli/commands/stacks/configuration/fetch) command in the new CLI, or by triggering a deployment run in the HCP Terraform UI.
+Trigger a new configuration fetch for each of your Stacks. The fetching process pulls your configuration from your Version Control System (VCS) and reinitializes your Stack. You can do this by using the [`terraform stacks configuration fetch`](/terraform/cli/commands/stacks/configuration/fetch) command in the new CLI, or by triggering a deployment run in the HCP Terraform UI.
diff --git a/content/terraform/v1.14.x/docs/language/validate/index.mdx b/content/terraform/v1.14.x/docs/language/validate/index.mdx
index 9954efcb91..7f97d669ba 100644
--- a/content/terraform/v1.14.x/docs/language/validate/index.mdx
+++ b/content/terraform/v1.14.x/docs/language/validate/index.mdx
@@ -123,6 +123,7 @@ data "aws_ami" "example" {
   executable_users = ["self"]
   most_recent      = true
   owners           = ["self"]
+
   filter {
     name   = "name"
     values = ["myami-*"]
diff --git a/content/terraform/v1.14.x/docs/partials/premium-deployment-groups.mdx b/content/terraform/v1.14.x/docs/partials/premium-deployment-groups.mdx
index 8f9c13f054..c7f659052f 100644
--- a/content/terraform/v1.14.x/docs/partials/premium-deployment-groups.mdx
+++ b/content/terraform/v1.14.x/docs/partials/premium-deployment-groups.mdx
@@ -1,5 +1,5 @@
 <Note title="Premium tier">
 
-Running orchestration rules for deployment groups is available in the HCP Terraform **Plus** Edition. Refer to [HCP Terraform pricing](https://www.hashicorp.com/products/terraform/pricing) for details.
+Running orchestration rules for deployment groups is available in the HCP Terraform **Premium** Edition. Refer to [HCP Terraform pricing](https://www.hashicorp.com/products/terraform/pricing) for details.
 
 </Note>
diff --git a/content/terraform/v1.15.x (alpha)/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.15.x (alpha)/docs/language/meta-arguments/provider.mdx
index 3a235c9311..84367fc016 100644
--- a/content/terraform/v1.15.x (alpha)/docs/language/meta-arguments/provider.mdx	
+++ b/content/terraform/v1.15.x (alpha)/docs/language/meta-arguments/provider.mdx	
@@ -11,9 +11,9 @@ type name. Note that the `provider` argument is distinct from the [`provider` bl
 
 ## Usage
 
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider.
 
-The default behavior does not apply to [`list` blocks](/terraform/language/block/tfquery/list), however, because Terraform does not implicitly use the default `provider` configuration when querying resources.  
+The default behavior does not apply to [`list` blocks](/terraform/language/block/tfquery/list), however, because Terraform does not implicitly use the default `provider` configuration when querying resources.
 
 You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
 
@@ -33,11 +33,11 @@ resource "google_compute_instance" "example" {
 }
 ```
 
-Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions.
 
 A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
 
-Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
 
 ## Supported constructs
 
@@ -46,7 +46,7 @@ You can use `provider` in the following Terraform configuration blocks:
 - [`check` blocks](/terraform/language/block/check)
 - [`data` blocks](/terraform/language/block/data)
 - [`ephemeral` blocks](/terraform/language/block/ephemeral)
-- [`import` blocks ](/terraform/language/block/import)
+- [`import` blocks](/terraform/language/block/import)
 - [`resource` blocks](/terraform/language/block/resource)
 
 You can use `for_each` in the following query configuration blocks:
@@ -121,4 +121,4 @@ import {
 resource "aws_instance" "web" {
   # ...
 }
-```
\ No newline at end of file
+```