Address reported bugs (#2449)

website/content/docs/concepts/filtering/events.mdx

@@ -17,16 +17,15 @@ several formats including [cloudevents](https://github.com/cloudevents/spec) and
 [hclog](https://github.com/hashicorp/go-hclog), and can be encoded as text and
 json.
 
-Boundary allows you to configure any number of
-[sinks](/docs/configuration/events/overview), where these events will be
+Boundary allows you to configure any number of sinks where these events will be
 written. When configuring an event sink, you can specify [common sink
 parameters](/docs/configuration/events/common) which include both
 `allow_filters` and `deny_filters` which use the standard [filter
-syntax](/docs/concepts/filtering) used
-elsewhere in Boundary.
+syntax](/docs/concepts/filtering) used elsewhere in Boundary.
 
 Example events encoded as cloudevents-text.  The first event is a system event
 and the second event is an observation event.
+
 ```json
 {
   "id": "DU7u227Jhc",

website/content/docs/configuration/events/common.mdx

@@ -16,9 +16,9 @@ These parameters are shared across all sink types:
 - `event_types` - Specifies a list of event types that will be sent to the sink.
   Can be `*`, `error`, `system`, `observation` or `audit`.
 
-- `event_source_url` - Specifies an optional event source URL for the sink.  If
-  not specified a default source will be composed of the
-  https://hashicorp.com/boundary.io/ServerName/Path/FileName.
+- `event_source_url` - Specifies an optional event source URL for the sink. If
+  not specified, the default source will be composed of the
+  `https://hashicorp.com/boundary.io/ServerName/Path/FileName`.
 
 - `allow_filters` - Specifies a set of predicates for including an event in the
   sink. If any filter matches, the event will be included. For more information,

website/content/docs/configuration/kms/aead.mdx

@@ -5,6 +5,8 @@ description: |-
   The AEAD KMS configures AEAD-specific parameters.
 ---
 
+# `aead` KMS
+
 ~> **Note:** This is mostly used for `dev` workflows or testing. The key will be exposed
 to anyone that can view the configuration file. If using this KMS, consider
 using `boundary config encrypt` to encrypt all but the `config` KMS and using an

website/content/docs/configuration/worker/index.mdx

@@ -10,8 +10,9 @@ description: |-
 The `worker` stanza configures Boundary worker-specific parameters. Boundary
 supports two different types of workers, differentiated by their means of
 authentication to Boundary:
-- [KMS Workers][] use a shared KMS to authenticate with controllers
+
 - [PKI Workers][] use certificates issued by Boundary to authenticate with controllers
+- [KMS Workers][] use a shared KMS to authenticate with controllers
 
 Different worker types have different configuration requirements, but share the common worker parameters listed below.