diff --git a/website/content/docs/enterprise/replication.mdx b/website/content/docs/enterprise/replication.mdx
index 48100549c2..c406668e04 100644
--- a/website/content/docs/enterprise/replication.mdx
+++ b/website/content/docs/enterprise/replication.mdx
@@ -42,14 +42,17 @@ All communication between primaries and secondaries is end-to-end encrypted
 with mutually-authenticated TLS sessions, setup via replication tokens which are
 exchanged during bootstrapping.
 
+## Replicated data
+
 What data is replicated between the primary and secondary depends on the type of
 replication that is configured between the primary and secondary. These types
-of relationships are either **disaster recovery** or **performance**
-relationships.
+of relationships are either **disaster recovery** or
+**performance replication** relationships.
 
 ![](/img/replication-overview.png)
 
-The following table shows a capability comparison between Disaster Recovery and Performance Replication.
+The following table shows a capability comparison between Disaster Recovery
+and Performance Replication.
 
 | Capability                                                                                                           | Disaster Recovery | Performance Replication                                                                                                                                                                        |
 | -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -58,6 +61,30 @@ The following table shows a capability comparison between Disaster Recovery and
 | Mirrors the tokens and leases for applications and users interacting with the primary cluster                        | Yes               | No. Secondaries keep track of their own tokens and leases. When the secondary is promoted, applications must reauthenticate and obtain new leases from the newly-promoted primary. |
 | Allows the secondary cluster to handle client requests                                                               | No                | Yes                                            |
 
+Everything written to storage is classified into one of three categories:
+* `replicated` (or "shared"): all downstream clusters receive it
+* `local`: only downstream disaster recovery clusters receive it
+* `ignored`: not replicated to downstream clusters at all
+
+When mounting a secret engine or auth method, you can choose whether to make it a
+local mount or a shared mount.
+
+Shared mounts (the default) usually replicate all their data to performance secondaries, but
+they can choose to designate specific storage paths as local.  For example, PKI mounts
+store certificates locally. If you query the roles on a shared PKI mount, you'll see
+the same result for that mount when you send the query to either the performance primary or
+secondary, but if you list stored certs, you'll see different values.
+
+Local mounts replicate their data only to disaster recovery secondaries.  A local mount
+created on a performance primary isn't visible at all to its performance secondaries.
+Local mounts can also be created on performance secondaries, in which case they aren't visible
+to the performance primary.
+
+There exist other storage entries that aren't mount specific.  For example, the Integrated
+Storage Autopilot configuration is an `ignored` storage entry, which allows for disaster recovery
+secondaries to have a different configuration than their primary.  Tokens and leases are written to
+`local` storage entries.
+
 ## Performance Replication
 
 In Performance Replication, secondaries keep track of their own tokens and leases
@@ -222,9 +249,9 @@ its encrypted barrier.
 
 ## Mutual TLS and Load Balancers
 
-Vault generates its own certificates for cluster members. All replication traffic 
-uses the cluster port using these Vault-generated certificates after initial 
-bootstrapping. Because of this, the cluster traffic can NOT be terminated at the 
+Vault generates its own certificates for cluster members. All replication traffic
+uses the cluster port using these Vault-generated certificates after initial
+bootstrapping. Because of this, the cluster traffic can NOT be terminated at the
 cluster port at a load balancer level.
 
 ## Tutorial