diff --git a/docs.json b/docs.json
index 7475f23..894fadc 100644
--- a/docs.json
+++ b/docs.json
@@ -111,6 +111,7 @@
               "fhe-library/core-concepts/data-evaluation",
               "fhe-library/core-concepts/encrypted-operations",
               "fhe-library/core-concepts/conditions",
+              "fhe-library/core-concepts/require",
               "fhe-library/core-concepts/access-control",
               "fhe-library/core-concepts/decryption-operations",
               "fhe-library/core-concepts/randomness",
diff --git a/fhe-library/core-concepts/conditions.mdx b/fhe-library/core-concepts/conditions.mdx
index 3d4637c..d067669 100644
--- a/fhe-library/core-concepts/conditions.mdx
+++ b/fhe-library/core-concepts/conditions.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Conditions"
+title: "Conditions (if .. else)"
 description: "Understanding why if..else isn't possible with FHE and exploring the alternatives"
 ---
 
diff --git a/fhe-library/core-concepts/require.mdx b/fhe-library/core-concepts/require.mdx
new file mode 100644
index 0000000..83a445e
--- /dev/null
+++ b/fhe-library/core-concepts/require.mdx
@@ -0,0 +1,54 @@
+---
+title: "Require"
+description: "Understanding require statements with encrypted data in FHE"
+---
+
+## Overview
+
+The `require` statement in FHE contracts works similarly to [Conditions (if .. else)](/fhe-library/core-concepts/conditions) because both involve conditional logic on encrypted data. Just like you can't use traditional `if...else` statements with encrypted values, you also can't use standard `require` statements that depend on encrypted conditions.
+
+<Warning>
+Traditional `require` statements that check encrypted conditions will leak information about your encrypted values through execution paths.
+</Warning>
+
+---
+
+## Why Require is Like Conditions
+
+Both `require` and conditional statements face the same fundamental challenge in FHE:
+
+<CardGroup cols={2}>
+<Card title="Encrypted Evaluation" icon="lock">
+The condition being checked is encrypted, so the contract can't directly evaluate it to decide whether to revert.
+</Card>
+
+<Card title="Information Leakage" icon="shield-exclamation">
+If a transaction reverts based on an encrypted condition, observers can infer information about the encrypted data.
+</Card>
+</CardGroup>
+
+---
+
+## The Solution
+
+Instead of using `require` with encrypted conditions, you should:
+
+1. **Use `FHE.select`** to handle the conditional logic (see [Conditions (if .. else)](/fhe-library/core-concepts/conditions))
+2. **Only use `require` for non-encrypted conditions** like access control checks, address validation, or other plaintext values
+
+```solidity
+// Good - require on plaintext condition
+require(msg.sender == owner, "Not authorized");
+
+// Good - use select for encrypted logic
+euint32 result = FHE.select(encryptedCondition, valueA, valueB);
+
+// Bad - require on encrypted condition leaks information!
+require(FHE.decrypt(encryptedValue.gt(threshold)), "Value too low");
+```
+
+---
+
+## Learn More
+
+For detailed guidance on handling conditional logic with encrypted data, see the [Conditions (if .. else)](/fhe-library/core-concepts/conditions) page.