1 files changed, 68 insertions, 2 deletions
diff --git a/worldbuilding_guide/recipes.md b/worldbuilding_guide/recipes.md
index 29b513a..335a6cc 100644
--- a/worldbuilding_guide/recipes.md
+++ b/worldbuilding_guide/recipes.md
@@ -4,7 +4,7 @@
 
 Recipes define how items are processed on stations to produce new items. They are the foundation for cooking, smithing, crafting, and fletching.
 
-Recipe files live in `data/recipes/<type>/<id>.yaml` (e.g., `data/recipes/smithing/smith_bronze_dagger.yaml`).
+Recipe files live in `data/recipes/<type>/<id>.yaml`. Two formats are supported: **individual** (one recipe per file) and **consolidated** (multiple related recipes per file). Consolidated format is preferred when many recipes share the same type, station, and materials (e.g., all bronze smithing products in one file).
 
 ### Recipe vs MadeFrom
 
@@ -51,9 +51,71 @@ consume:
     quantity: 1
     byproducts: [empty_bucket, ""]   # bucket returns empty, vial is consumed entirely
   - items: [herb]
-    quantity: 1                           # no byproducts — herb is consumed entirely
+     quantity: 1                           # no byproducts — herb is consumed entirely
 ```
 
+### Consolidated Format
+
+For recipe categories where many recipes share the same `type`, `station`, and `wait` (e.g., smithing all bronze items from bronze bars, fletching all arrow shafts from logs), use a **consolidated** file. Shared fields are set once at the top level; each product entry provides only the fields that differ.
+
+**Loader behavior:** At load time, the loader expands each `products` entry into an individual `RecipeDef` with the same shape as the individual format. The production engine sees no difference — all lookup, matching, and execution code works identically.
+
+**Inheritance:** Child fields override parent. `consume` at the top level provides a default ingredient list; any product with different `consume` (e.g., a platebody needing 5 bars instead of 1) specifies its own. `output_qty`, `message`, `fail`, and `level` are per-product.
+
+```yaml
+# data/recipes/smithing/bronze.yaml — consolidated: 8 products in one file
+
+type: smithing           # shared by all products
+station: [anvil]         # shared by all products
+wait: 4                  # shared by all products
+consume:                 # default ingredient list — overridden per-product if needed
+  - items: [bronze_bar]
+    quantity: 1
+
+products:
+  - id: smith_bronze_dagger
+    output: bronze_dagger
+    level: 1
+    xp: 12
+    # inherits consume: 1 bronze_bar from parent
+
+  - id: smith_bronze_nails
+    output: bronze_nails
+    level: 4
+    xp: 12
+    output_qty: 15        # stackable output, 15 per cycle
+
+  - id: smith_bronze_full_helm
+    output: bronze_full_helm
+    level: 7
+    xp: 25
+    consume:               # overrides parent — 2 bars instead of 1
+      - items: [bronze_bar]
+        quantity: 2
+
+  - id: smith_bronze_platebody
+    output: bronze_platebody
+    level: 18
+    xp: 62
+    consume:               # overrides parent — 5 bars
+      - items: [bronze_bar]
+        quantity: 5
+
+  # ... dagger, sword, med_helm, arrowtips, bolts_unf ...
+```
+
+**Use consolidated files when:**
+- Many recipes share the same `type`, `station`, and `material`
+- Adding a new tier means copy-pasting identical consume/station/wait fields
+- The relationship between recipes is easier to understand as a group
+
+**Use individual files when:**
+- The recipe is unique and doesn't share structure with others (e.g., compound smelting recipes with different ore ratios)
+- You want fine-grained version control on a single recipe
+- The recipe is complex enough that a consolidated file would be harder to read
+
+Individual and consolidated files coexist — the loader handles both transparently.
+
 ### Station-based recipe (cooking on a fire)
 
 ```yaml
@@ -127,6 +189,10 @@ success:
 
 Smithing recipes use `type: smithing` and `station: [anvil]`. The `smith` command or `use <bar> on anvil` triggers them. Requires a hammer (`tool_type: hammer`) in inventory.
 
+**Recommended:** Use consolidated format (one file per metal type) since all products for a given metal share the same bar, station, and wait. See [Consolidated Format](#consolidated-format) above.
+
+The individual format is also supported:
+
 ```yaml
 id: smith_steel_platebody
 type: smithing