diff --git a/.changeset/pretty-bats-know.md b/.changeset/pretty-bats-know.md
new file mode 100644
index 00000000000..48d85353ac3
--- /dev/null
+++ b/.changeset/pretty-bats-know.md
@@ -0,0 +1,5 @@
+---
+'polaris.shopify.com': minor
+---
+
+Remove section on compositions vs patterns.
diff --git a/polaris.shopify.com/content/patterns/design-patterns.md b/polaris.shopify.com/content/patterns/design-patterns.md
index ecc5aa48e4f..c50dd22252c 100644
--- a/polaris.shopify.com/content/patterns/design-patterns.md
+++ b/polaris.shopify.com/content/patterns/design-patterns.md
@@ -15,7 +15,7 @@ A design pattern is a repeatable solution to a common UX problem in a specific m
 
 ---
 
-### Join the conversation!
+### Join the conversation
 
 Do you have ideas or feedback on how we can make these guidelines more empowering and useful? Please share your thoughts in the [GitHub discussion](https://github.com/Shopify/polaris/discussions/6046).
 
@@ -23,11 +23,7 @@ Do you have ideas or feedback on how we can make these guidelines more empowerin
 
 ## Principles
 
-For patterns to be successful, they need to be contextual, consistent, and unified.
-
-### Contextual
-
-A pattern is always paired with the problem it solves and the situation it appears in. A solution applied in a context it wasn’t designed for is not a pattern.
+For patterns to be successful, they need to be consistent, unified, and contextual.
 
 ### Consistent
 
@@ -37,31 +33,8 @@ Patterns are always used in the same way for the same reasons. Merchants need to
 
 Patterns are always informed by and designed together with similar patterns. For example, patterns with similar purpose should complement each other, and patterns with similar functionality should share appearance and behavior.
 
-![A solution box within a problem box within a situation box.](/images/foundations/patterns/design-patterns/situation-problem-solution.png)
-
-Patterns come with a solution, problem, and situation that belong together. Solutions taken out of this context are no longer a pattern.
-
-## Patterns vs. compositions
-
-Patterns are for merchants and compositions are for builders.
-
-### Pattern purpose
-
-- Design the best possible merchant experience
-- Simplify learning the UI
-- Improve recognizability and ease of use
-- Improve merchants’ admin proficiency
-
-### Composition purpose
-
-- Share as much code as possible
-- Speed up the build process
-- Improve maintainability and reusability
-- Ensure build consistency
+### Contextual
 
-### How to distinguish
+A pattern is always paired with the problem it solves and the situation it appears in. A solution applied in a context it wasn’t designed for is not a pattern.
 
-- Patterns solve usability problems that relate to the usage of admin, while compositions solve build problems that relate to the build process
-- Patterns ensure consistent product experience, while compositions ensure consistent implementation
-- A pattern can be hard coded and still be a pattern, and a composition can be using Polaris primitives and tokens and still not be a pattern
-- Patterns are the language we speak with merchants, compositions are the code we share among us
+![A solution box within a problem box within a situation box.](/images/foundations/patterns/design-patterns/situation-problem-solution.png)