diff --git a/README.md b/README.md
index 2cd4a4f14e0..44df36d24f3 100644
--- a/README.md
+++ b/README.md
@@ -39,7 +39,7 @@ These resources can be helpful to refine your issue, work out an application/dri
 ### Internals
 
 The Validation Layers are broken up as many smaller internal "Validation Objects" each tasked with own job.
-[Core Checks](./docs/core_checks.md) is what is on by default, but there are other validation such as [Synchronization Validation](./docs/synchronization.md), [GPU Assisted Validation](./docs/gpu_validation.md), and [more](./docs/README.md).
+[Core Checks](./docs/core_checks.md) is what is enabled by default, but there are other validation objects that can be additionally enabled, such as [Synchronization Validation](./docs/synchronization.md), [GPU Assisted Validation](./docs/gpu_validation.md), and [more](./docs/README.md).
 There are also a few [limitations](./docs/limitations.md) that the Validation Layers can not handle due the nature of being a Vulkan Layer.
 
 ## Version Tagging Scheme
diff --git a/docs/limitations.md b/docs/limitations.md
index 3e68d72ddc9..ba4e559e77a 100644
--- a/docs/limitations.md
+++ b/docs/limitations.md
@@ -20,7 +20,7 @@ If an app is trying to use `VkBindImageMemoryInfo`, but is setting the `sType` a
 
 The Validation Layers (as well as any other layer or driver) uses the `sType` to know how to cast the `void* pNext`, so if it is wrong, there is no way a Vulkan Layer could know.
 
-There are VUID such as `VUID-VkBufferCreateInfo-pNext-pNext` that limit which `sType` can appear in the pNext chain, but something the 2 `sType` being mixed up both might be valid to use in that case.
+There are VUID such as `VUID-VkBufferCreateInfo-pNext-pNext` that limit which `sType` can appear in the pNext chain, but something the 2 mixed up `sType` can both be valid by chance, and there will be no validation error.
 
 ### Dereferencing Pointers