website: Bold Note: in beta callouts (#507)

website/docs/plugin/framework/accessing-values.mdx

@@ -7,7 +7,7 @@ description: |-
 
 # Accessing State, Config, and Plan
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 There are various points at which the provider needs access to the data from
 the practitioner's configuration, Terraform's state, or generated plan.

website/docs/plugin/framework/acctests.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Acceptance Tests
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 You can implement testing with the [acceptance test framework](/plugin/sdkv2/testing/acceptance-tests) shipped with SDKv2.
 

website/docs/plugin/framework/data-sources/configure.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Configure Data Sources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Data sources](/plugin/framework/data-sources) may require provider-level data or remote system clients to operate correctly. The framework supports the ability to configure this data and/or clients once within the provider, then pass that information to data sources by adding the `Configure` method.
 

website/docs/plugin/framework/data-sources/index.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Data Sources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Data sources](/language/data-sources) are an abstraction that allow Terraform to reference external data. Unlike [managed resources](/language/resources), Terraform does not manage the lifecycle of the resource or data. Data sources are intended to have no side-effects.
 

website/docs/plugin/framework/data-sources/timeouts.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Timeouts
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 The reality of cloud infrastructure is that it typically takes time to perform operations such as booting operating systems, discovering services, and replicating state across network edges. As the provider developer you should take known delays in data source APIs into account in the `Read` function of the data source. Terraform supports configurable timeouts to assist in these situations.
 

website/docs/plugin/framework/data-sources/validate-configuration.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Validate Configuration
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Data sources](/plugin/framework/data-sources) support validating an entire practitioner configuration in either declarative or imperative logic. Feedback, such as required syntax or acceptable combinations of values, is returned via [diagnostics](/plugin/framework/diagnostics).
 

website/docs/plugin/framework/debugging.mdx

@@ -5,7 +5,7 @@ description: How to implement debugger support in Framework Terraform providers.
 
 # Debugging Framework Providers
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 This page contains implementation details for inspecting runtime information of a Terraform provider developed with Framework via a debugger tool by adjusting the [provider server](/plugin/framework/provider-servers) implementation. Review the top level [Debugging](/plugin/debugging) page for information pertaining to the overall Terraform provider debugging process and other inspection options, such as log-based debugging.
 

website/docs/plugin/framework/diagnostics.mdx

@@ -7,7 +7,7 @@ description: |-
 
 # Returning Errors and Warnings
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Providers use `Diagnostics` to surface errors and warnings to practitioners,
 such as contextual messages returned from Terraform CLI at the end of

website/docs/plugin/framework/index.mdx

@@ -6,7 +6,7 @@ description: |-
 
 # Terraform Plugin Framework
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 The plugin framework is a new way to develop Terraform Plugins on [protocol version 6](/plugin/how-terraform-works#protocol-version-6) or [protocol version 5](/plugin/how-terraform-works#protocol-version-5). It offers improvements and new features from [Teraform Plugin SDKv2](/plugin/sdkv2).
 

website/docs/plugin/framework/migrating/attributes-blocks/attribute-schema.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Attribute Schema
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Attributes define how users can configure values for your Terraform provider, resources, and data sources. Refer to
 [Schemas - Attributes](/plugin/framework/schemas#attributes) in the Framework documentation for details.

website/docs/plugin/framework/migrating/attributes-blocks/blocks-computed.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Blocks with Computed Fields
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Some providers, resources, and data sources include repeatable nested blocks in their attributes. Some blocks contain
 fields  with `Computed: true`, which means that the provider code can define the value or that it could come from the

website/docs/plugin/framework/migrating/attributes-blocks/blocks.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Blocks
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Some providers, resources, and data sources include repeatable nested blocks in their attributes. These nested blocks
 typically represent separate objects that are related to (or embedded within) the containing object.

website/docs/plugin/framework/migrating/attributes-blocks/default-values.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Default Values
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Default values set a value for an attribute when the Terraform configuration does not provide one. In SDKv2, default
 values are set via fields on an attribute's schema. In the Framework, you set default values via plan modification.

website/docs/plugin/framework/migrating/attributes-blocks/fields.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Attribute Fields
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 A subset of attribute fields, such as required, optional, computed, or sensitive, define attribute behavior as boolean flags. Refer to
 [Schemas - Attributes](/plugin/framework/schemas#required) in the Framework documentation for details.

website/docs/plugin/framework/migrating/attributes-blocks/force-new.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # ForceNew
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 In Terraform, sometimes a resource must be replaced when the value of an attribute changes. In SDKv2, this is
 accomplished via the `ForceNew` field. In the Framework, you implement the same behavior via a `RequiresReplace` plan

website/docs/plugin/framework/migrating/attributes-blocks/types.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Attribute Types
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 An attribute either contains a primitive type, such as an integer or a string, or contains other attributes. Attributes
 that contain other attributes are referred to as nested attributes, and are implemented by populating the

website/docs/plugin/framework/migrating/attributes-blocks/validators-custom.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Custom Validators
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 You can write custom validations that give users feedback about required syntax, types, and acceptable values in your
 provider. The Framework has a collection of

website/docs/plugin/framework/migrating/attributes-blocks/validators-predefined.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Validators - Predefined
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Attribute validators ensure that attributes do or do not contain specific values. You can use predefined validators for
 many use cases, or implement custom validators. Refer to [Schemas - Validators](/plugin/framework/schemas#validators) in

website/docs/plugin/framework/migrating/data-sources/index.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Data Sources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Data sources let Terraform reference external data. Unlike resources, Terraform does not create, update, or delete
 data sources, and makes no attempt to modify the underlying API. Data Sources are a read-only resource type, so they

website/docs/plugin/framework/migrating/data-sources/timeouts.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Timeouts
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in CRUD functions.
 

website/docs/plugin/framework/migrating/index.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Overview
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 This guide helps you migrate a Terraform provider from SDKv2 to the plugin Framework. We recommend migrating because the Framework has abstractions that make it easier to use, and it represents the future of Terraform plugin development. Refer to [Which SDK should I Use?](/plugin/which-sdk) for more details.
 

website/docs/plugin/framework/migrating/providers/index.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Provider
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Providers are Terraform plugins that define resources and data sources for practitioners to use. You serve your
 providers with a provider server so they can interact with Terraform.

website/docs/plugin/framework/migrating/resources/crud.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # CRUD functions
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 In Terraform, a resource represents a single instance of a given resource type. They modify a specific resource in the
 API and in Terraform's state through a set of Create, Read, Update, and Delete (CRUD) functions. A resource's CRUD

website/docs/plugin/framework/migrating/resources/import.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Import
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Practitioners can use the [`terraform import` command](https://www.terraform.io/cli/commands/import) to let Terraform
 begin managing existing infrastructure by importing an existing resource into their Terraform project's state. A

website/docs/plugin/framework/migrating/resources/index.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Resources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Resources are an abstraction that allow Terraform to manage infrastructure objects by defining create, read, update,
 and delete functionality that maps onto API operations. Resource schemas define what fields a resource has, give

website/docs/plugin/framework/migrating/resources/plan-modification.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Plan Modification
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Your provider can modify the Terraform plan to match the expected end state. This can include replacing unknown values
 with expected known values or marking a resource that must be replaced. Refer to

website/docs/plugin/framework/migrating/resources/state-upgrade.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # State Upgraders
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 When you update a resource's implementation in your provider, some changes may not be compatible with old versions. You
 can create state upgraders to automatically migrate resources provisioned with old schema configurations. Refer to

website/docs/plugin/framework/migrating/resources/timeouts.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Timeouts
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in CRUD functions.
 

website/docs/plugin/framework/migrating/schema/index.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Schema
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Providers, resources, and data sources all use schema to define their attributes and behavior. Schemas specify the
 constraints of Terraform configuration blocks and how the provider, resource, or data source behaves. Refer to

website/docs/plugin/framework/migrating/testing.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Testing
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 During migration, you should [write tests](#testing-migration) to verify that the behaviour of your provider has not
 been altered by the migration itself. You will also need to [update](#provider-factories) your tests too.

website/docs/plugin/framework/path-expressions.mdx

@@ -8,7 +8,7 @@ description: >-
 
 # Path Expressions
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Path expressions are logic built on top of [paths](/plugin/framework/paths), which may represent one or more actual paths within a schema or schema-based data. Expressions enable providers to work outside the restrictions of absolute paths and steps.
 

website/docs/plugin/framework/paths.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Paths
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 An exact location within a [schema](/plugin/framework/schemas) or schema-based data such as [`tfsdk.Config`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#Config), [`tfsdk.Plan`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#Plan), or [`tfsdk.State`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#State), is referred to as a path.
 

website/docs/plugin/framework/provider-servers.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Provider Servers
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Before a [provider](/plugin/framework/providers) can be used with Terraform, it must implement a [gRPC server](https://grpc.io) that supports Terraform-specific connection and handshake handling on startup. The server must then implement the [Terraform Plugin Protocol](/plugin/how-terraform-works#terraform-plugin-protocol).
 

website/docs/plugin/framework/providers/index.mdx

@@ -8,7 +8,7 @@ description: >-
 
 # Providers
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Providers are Terraform plugins that define [resources](/plugin/framework/resources) and [data sources](/plugin/framework/data-sources) for practitioners to use. Providers are wrapped by a [provider server](/plugin/framework/provider-servers) for interacting with Terraform.
 

website/docs/plugin/framework/providers/validate-configuration.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Validate Configuration
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Providers](/plugin/framework/providers) support validating an entire practitioner configuration in either declarative or imperative logic. Feedback, such as required syntax or acceptable combinations of values, is returned via [diagnostics](/plugin/framework/diagnostics).
 

website/docs/plugin/framework/resources/configure.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Configure Resources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Resources](/plugin/framework/resources) may require provider-level data or remote system clients to operate correctly. The framework supports the ability to configure this data and/or clients once within the provider, then pass that information to resources by adding the `Configure` method.
 

website/docs/plugin/framework/resources/import.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Resource Import
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Practitioners can use the  [`terraform import` command](/cli/commands/import) to let Terraform begin managing existing infrastructure resources. Resources can implement the `ImportState` method, which must either specify enough Terraform state for the `Read` method to refresh [`resource.Resource`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/resource#Resource) or return an error.
 

website/docs/plugin/framework/resources/index.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Resources
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Resources](/language/resources) are an abstraction that allow Terraform to manage infrastructure objects, such as a compute instance, an access policy, or disk. Terraform assumes that every resource:
 

website/docs/plugin/framework/resources/plan-modification.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Plan Modification
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 After [validation](/plugin/framework/validation) and before applying configuration changes, Terraform generates a plan that describes the expected values and behaviors of those changes. Providers can then tailor the plan to match the expected end state. For example, they may replace unknown values with expected known values or mark a resource that must be replaced. Users can perform this plan modification for an attribute or an entire resource.
 

website/docs/plugin/framework/resources/private-state.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Private State Management
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Resource private state is provider maintained data that is stored in Terraform state alongside the schema-defined data. Private state is never accessed or exposed by Terraform plans, however providers can use this data storage for advanced use cases.
 

website/docs/plugin/framework/resources/state-upgrade.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # State Upgrade
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 A resource schema captures the structure and types of the resource [state](/language/state). Any state data that does not conform to the resource schema will generate errors or may not be persisted properly. Over time, it may be necessary for resources to make breaking changes to their schemas, such as changing an attribute type. Terraform supports versioning of these resource schemas and the current version is saved into the Terraform state. When the provider advertises a newer schema version, Terraform will call back to the provider to attempt to upgrade from the saved schema version to the one advertised. This operation is performed prior to planning, but with a configured provider.
 

website/docs/plugin/framework/resources/timeouts.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Timeouts
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 The reality of cloud infrastructure is that it typically takes time to perform operations such as booting operating systems, discovering services, and replicating state across network edges. As the provider developer you should take known delays in resource APIs into account in the CRUD functions of the resource. Terraform supports configurable timeouts to assist in these situations.
 

website/docs/plugin/framework/resources/validate-configuration.mdx

@@ -6,7 +6,7 @@ description: >-
 
 # Validate Configuration
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 [Resources](/plugin/framework/resources) support validating an entire practitioner configuration in either declarative or imperative logic. Feedback, such as required syntax or acceptable combinations of values, is returned via [diagnostics](/plugin/framework/diagnostics).
 

website/docs/plugin/framework/schemas.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Schemas
 
--> Note: The Plugin Framework is in beta.
+-> **Note:** The Plugin Framework is in beta.
 
 Schemas specify the constraints of Terraform configuration blocks. They define what fields a provider,
 resource, or data source configuration block has, and give Terraform metadata