Arukh HaShulchan, Orach Chaim 209:2-9

Greetings, fellow data-devotees and code-conjurers! Get ready to debug some ancient algorithms, because today we're diving deep into the Arukh HaShulchan, the ultimate API for Jewish law, specifically Orach Chaim 209. We're going to deconstruct the intricate logic of ikar v'tafel – the "primary and secondary" food paradigm – and translate its elegant, yet sometimes elusive, flow into systems thinking. Think of it as reverse-engineering the ultimate food-blessing compiler. Let's get our geek on!

Problem Statement

Every programmer knows the pain of an ambiguous function call. You pass in a set of parameters, but the expected output isn't consistently clear. In the world of halakha, our "function" is makeBlessing(food_items_consumed). The food_items_consumed parameter often contains a complex array of elements: a main dish, a side, a drink, a condiment. The "bug report" we're tackling today is precisely this: How does our system correctly determine which blessing(s) to emit when multiple food items are consumed concurrently, especially when their relationships are not explicitly declared?

The core issue stems from the principle of ikar v'tafel (primary and secondary). Intuitively, if you're eating a steak with mustard, you don't bless the mustard separately; it's tafel (subordinate) to the ikar (primary) steak. But what if the "steak" is actually a veggie burger, and the "mustard" is a gourmet aioli that's arguably more central to the flavor profile? What if the "steak" never even made it to your plate, but you still ate the "mustard" that was prepared for it? The system needs a robust, deterministic algorithm to classify food items and cascade blessing coverage.

The Arukh HaShulchan, our venerable compiler, seeks to resolve this ambiguity, providing a layered set of rules to handle various input states. It's a masterclass in conditional logic, handling everything from the obvious (bread with butter) to the perplexing (meatballs with breadcrumbs). The "bug" isn't a flaw in the concept of ikar v'tafel, but rather the challenge of creating a universally applicable implementation that accounts for human intention, ingredient composition, and the dynamic nature of a meal. Without a clear decision tree, we risk inconsistent outputs: blessing something that's covered, or worse, failing to bless something that stands alone. This isn't just a theoretical exercise; it’s about correctly interfacing with the divine API.

Text Snapshot

Let's anchor our analysis in the source code itself, specifically Arukh HaShulchan, Orach Chaim 209:2-9.

• 209:2: "האוכל עיקר וטפל, מברך על העיקר ופוטר את הטפל" (One who eats a primary and a secondary, blesses on the primary and exempts the secondary.)
• 209:3: "ואם אחר שגמר סעודתו ובירך ברכת המזון, הביאו לו פירות לאכול, צריך לברך עליהם" (And if after he finished his meal and blessed Birkat Hamazon, they brought him fruits to eat, he must make a blessing on them.)
• 209:4: "כל דבר שבא מחמת דבר אחר, הרי הוא טפל לו" (Anything that comes on account of another thing, is secondary to it.)
• 209:5: "וכן כל מיני משקים ששותה בתוך הסעודה להרבות אכילתו או לבלוע המאכל, הרי הם טפלים לאכילה" (And similarly all types of drinks that one drinks during the meal to increase his eating or to swallow the food, they are secondary to the eating.)
• 209:6: "אבל אם היה דעתו לאכלו ואף על פי שלא אכלו, דהיינו כשהעיקר מוכן לפניו, הרי הטפל נפטר" (But if his intention was to eat it [the primary] and even though he didn't eat it, meaning when the primary is prepared before him, the secondary is exempt.)
• 209:7: "תבשיל שיש בו כמה מינים, אם אחד מהם עיקר והשאר טפלים לו, מברך על העיקר" (A dish that has several kinds [of ingredients], if one of them is primary and the rest are secondary to it, one blesses on the primary.)
• 209:8: "ועל כן נראה לי דאם עיקרו הבשר, אע"ג דנתן בו הרבה אורז לפרפרת או קמח למען יתחבר, מברך שהכל על הבשר ופוטר את האורז או הקמח" (Therefore, it seems to me that if the meat is primary, even if a lot of rice was added for garnish or flour for binding, one blesses Shehakol on the meat and exempts the rice or flour.)
• 209:9: "הכל לפי כוונת האוכל" (Everything is according to the intention of the eater.)

Flow Model

Let's flowchart this logic. We're building a determineBlessing(foodItems, context) function.

determineBlessing(foodItems, context) Decision Tree:

1. System Initialization:

   • Input: foodItems (array of food objects), context (e.g., "during meal", "after meal", "prepared for X").
   • Output: blessingsRequired (array of blessing strings).

2. Primary Meal Check (Bread-based):

   • IF foodItems contains bread (or equivalent Hamotzi item) AND context is "during main meal" (before Birkat Hamazon):
     • Add "Hamotzi" to blessingsRequired.
     • FOR EACH item in foodItems (excluding bread):
       • IF item.isInherentlyChashuv (e.g., wine, as per 209:2, 209:5, 209:9):
         • Add getSpecificBlessing(item) to blessingsRequired.
       • ELSE IF item.isSignificantGrainComponent (e.g., a kugel eaten alongside the bread, not with it, as per 209:7-8 nuances):
         • Add getSpecificBlessing(item) (likely "Mezonot") to blessingsRequired.
       • ELSE (item is clear tafel to bread, e.g., cheese, meat, salad dressing):
         • item is covered by "Hamotzi". No additional blessing.
     • RETURN blessingsRequired.

3. Standalone Item Check:

   • IF foodItems contains only one item:
     • Add getSpecificBlessing(foodItems[0]) to blessingsRequired.
     • RETURN blessingsRequired.

4. Multi-Ingredient Dish Check (Internal Composition):

   • IF foodItems represents a single, composite dish (e.g., casserole, soup, meatballs, as per 209:7-8):
     • Identify primaryIngredient within the dish.
     • Rule Set for primaryIngredient (Arukh HaShulchan's algorithm):
       • Criterion 1: dishName: What is the dish primarily called? (e.g., "Meatballs" implies meat is primary, even if filled with breadcrumbs).
       • Criterion 2: mainComponent: What is the most significant component by volume/weight, or what provides the core sustenance/flavor?
       • Criterion 3: primaryPurpose: What is the main reason for eating this dish? (e.g., "eating the meat," "eating the rice").
       • Criterion 4: functionalRole: If an ingredient (especially grain) is only for binding, thickening, or coloring, it's tafel regardless of quantity (unless it becomes the main component).
     • Add getSpecificBlessing(primaryIngredient) to blessingsRequired.
     • RETURN blessingsRequired.

5. Separate Items Eaten Together Check (External Relationship):

   • IF foodItems contains multiple distinct items not forming a single dish (e.g., a fruit and a dip, separate salad and dressing, as per 209:2, 209:4-5, 209:9):
     • Determine primaryItem and secondaryItems based on eaterIntention and itemPurpose:
       • Criterion 1: eaterIntention: What does the eater consider the main item? (209:9: "הכל לפי כוונת האוכל").
       • Criterion 2: itemPurpose: Is one item "brought on account of" another? (209:4: "שבא מחמת דבר אחר").
       • Criterion 3: inherentImportance: Is an item inherently chashuv (e.g., wine, even if intended as tafel to quench thirst, still needs its own blessing, 209:5)?
     • FOR EACH item in foodItems:
       • IF item is classified as primaryItem:
         • Add getSpecificBlessing(item) to blessingsRequired.
       • ELSE IF item is classified as secondaryItem AND item.isInherentlyChashuv (e.g., wine):
         • Add getSpecificBlessing(item) to blessingsRequired.
       • ELSE IF item is classified as secondaryItem AND context is "after main item finished and Birkat Hamazon said" (209:3, 209:5):
         • Add getSpecificBlessing(item) to blessingsRequired.
       • ELSE IF item is classified as secondaryItem AND primaryItem was intended to be eaten (even if not, but was presentAndAvailable, 209:6) AND eaterIntention for primaryItem persists:
         • item is covered by the blessing made/intended for primaryItem. No additional blessing.
       • ELSE (item is a standalone primaryItem or secondaryItem whose ikar was not intended or intention changed):
         • Add getSpecificBlessing(item) to blessingsRequired.
     • RETURN blessingsRequired.

6. Fallback:

   • IF no rules apply (shouldn't happen with comprehensive input):
     • ERROR: "Blessing determination failed. Ambiguous input."
   • RETURN blessingsRequired (after resolving any duplicates).

This structured approach, with its nested conditionals and explicit criteria, transforms the textual sugya into a runnable algorithm.

Two Implementations

The Arukh HaShulchan, while presenting its own definitive rulings, often engages with alternative viewpoints, effectively comparing different algorithmic approaches to the same problem. A prime example of this lies in its discussion of composite dishes containing grain, particularly in sections 209:7 and 209:8, where it contrasts its view with that of the Magen Avraham. This provides us with two distinct algorithms for determining the ikar in a mixed dish.

Algorithm A: The "Threshold-Based Promotion" (Magen Avraham's Interpretation)

Let's call this BlessingEngine_MagenAvraham_v1.0. This algorithm is characterized by a more dynamic assessment of ingredients, where even a functionally tafel component can "level up" to requiring its own blessing, or even becoming the ikar, if it crosses certain quantitative thresholds.

Core Logic (Simplified from Magen Avraham's implied approach in 209:8):

1. Initial Classification: Identify the prima facie primary ingredient (ikar_candidate) and other ingredients (tafel_candidates) based on the dish's name or the user's primary intent.
2. Grain Presence Check: Scan tafel_candidates for any of the five species of grain (wheat, barley, rye, oats, spelt).
3. Quantity Threshold Evaluation (for Grain):
   • IF a tafel_candidate_grain is present in a significant quantity (e.g., a k'zayit within tochei k'dei akhilat pras – a specific volume/time threshold for consumption, or exceeding a certain proportion, like 1/6th of the dish):
     • THEN: This tafel_candidate_grain is "promoted." It is no longer simply covered by the ikar_candidate.
     • Sub-Rule 1 (Promotion to Co-Ikar): If the ikar_candidate is Shehakol (e.g., meat) and the tafel_candidate_grain is now significant, the dish is considered to have two ikkarim. In such cases, Mezonot (for the grain) would be recited first, as it is generally considered a "more important" blessing (Bracha Chamurah), and it would then cover the Shehakol item.
     • Sub-Rule 2 (Promotion to Ikar): If the tafel_candidate_grain is so prevalent that it fundamentally alters the dish's character or provides significant sustenance beyond its functional role, it might even replace the ikar_candidate as the primary blessing.
4. Final Blessing Determination:
   • If no grain promotion occurred, bless on the ikar_candidate.
   • If grain promotion to Co-Ikar occurred, bless Mezonot (on grain), which covers the Shehakol (on original ikar_candidate).
   • If grain promotion to Ikar occurred, bless Mezonot (on grain).

Analogy: Imagine a software module (tafel_grain.js) that typically runs as a background utility, subservient to the main application (ikar_meat.exe). However, BlessingEngine_MagenAvraham_v1.0 has a monitor that, if tafel_grain.js consumes more than, say, 15% of CPU cycles, it triggers an "escalation protocol." This protocol might promote tafel_grain.js to a co-primary process, or even a new main process, requiring a different resource allocation (blessing). The quantitative aspect (amount of grain) is the primary trigger for this promotion.

Algorithm B: The "Purpose-Driven Hierarchy" (Arukh HaShulchan's Definitive Stance)

This is BlessingEngine_ArukhHaShulchan_v2.0 – a more streamlined and, arguably, more robust algorithm that prioritizes the purpose and identity of the dish over the mere quantity of its components. The Arukh HaShulchan directly critiques the Magen Avraham's approach in 209:8, finding it overly complex and potentially inconsistent with the fundamental ikar v'tafel principle.

Core Logic (From 209:7-8, Arukh HaShulchan's final ruling):

1. Initial Classification: Identify the prima facie primary ingredient (ikar_candidate) and other ingredients (tafel_candidates) based on the dish's name and the user's primary intent.
   • Key Question: What is the main component of the dish? What gives it its identity? Is it called "meatballs" or "rice casserole"? (209:7: "העיקר... והשאר טפלים לו").
   • Key Question: What is the primary purpose for eating this dish? Are you eating it for the meat, or for the rice? (209:9: "לפי כוונת האוכל").
2. Functional Role Check (for Grain):
   • IF a tafel_candidate_grain (e.g., flour, breadcrumbs) serves a purely functional role within the dish (e.g., binding, thickening, coloring, adding bulk without being a primary flavor/substance component):
     • THEN: This tafel_candidate_grain remains tafel to the ikar_candidate, regardless of its quantity. (209:8: "אע"ג דנתן בו הרבה אורז לפרפרת או קמח למען יתחבר, מברך שהכל על הבשר ופוטר את האורז או הקמח").
     • Exception: The only way the grain would become the ikar is if it is clearly the main ingredient (e.g., a grain kugel where the grain is the overwhelming substance and the dish is known for it) or the dish is named after the grain (e.g., "rice porridge" where rice is the focus). In such cases, the ikar_candidate would actually be the grain itself, not the other ingredients.
3. Final Blessing Determination:
   • Bless on the ikar_candidate identified in step 1. The functional tafel_candidate_grain (and all other tafel_candidates) are covered.

Analogy: Consider BlessingEngine_ArukhHaShulchan_v2.0 as an operating system that assigns a static PROCESS_ROLE flag upon initial program launch. If a module is flagged ROLE_BINDER_THICKENER, it will always be treated as a background process, even if it happens to consume a lot of memory or CPU cycles during peak operation. Its declared role and the main application's identity dictate its status, not its transient resource usage. The system prioritizes the overarching architecture and user intent. The Arukh HaShulchan effectively argues that the "functional role" of an ingredient in a composite dish is a more stable and reliable determinant of its ikar/tafel status than simply its quantity.

Comparison and Implications:

Feature	Algorithm A (Magen Avraham)	Algorithm B (Arukh HaShulchan)
Primary Determinant	Quantity/Proportion of ingredients (especially grain)	Primary purpose, dish's identity/name, eater's intention
Grain Status	Can be "promoted" from tafel to co-ikar or ikar if it meets a quantity threshold.	Remains tafel if its role is purely functional (binding/thickening), regardless of quantity.
Complexity	Higher complexity; requires monitoring ingredient proportions and applying conditional promotions.	Lower complexity; relies on a more stable, overarching classification of the dish's nature.
Robustness	Susceptible to edge cases where quantity doesn't match perceived primary (e.g., "meatballs" with much bread).	More robust in maintaining the ikar based on identity, even with varying component ratios.
Real-world example (Meatballs with breadcrumbs):	If breadcrumbs are > 1/6th or a k'zayit, might require Mezonot (covering Shehakol).	If meat is the main component and breadcrumbs are for binding, always Shehakol on meat.

The Arukh HaShulchan's rejection of the Magen Avraham's approach in 209:8 is a clear preference for a consistent, purpose-driven hierarchy over a dynamic, quantity-triggered promotion system. It suggests that once an ingredient's functional role is established as tafel within a composite dish, that role is sticky. The "main component" rule isn't just about weight, but about what defines the dish. This makes BlessingEngine_ArukhHaShulchan_v2.0 a more predictable and, arguably, more elegant solution to the ikar v'tafel problem in complex food mixtures.

Edge Cases

Even the most robust algorithms can encounter unexpected inputs that challenge their core logic. Let's explore two such edge cases that could "break" a naive implementation of the ikar v'tafel system, and then see how the Arukh HaShulchan's refined algorithm handles them.

Edge Case 1: The "Invisible Ikar" – Intended Primary, Not Consumed

Input Scenario: Sarah prepares for a significant meal, placing a large loaf of Hamotzi bread (ikar_bread) prominently on the table. Alongside it, she has a rich, flavorful cheese spread (tafel_cheese) and an elaborate salad (tafel_salad), both specifically prepared and intended to be eaten with the bread. Just as she's about to make Hamotzi, an urgent call comes in. She's called away unexpectedly and, due to time constraints, only manages to quickly eat a significant amount of the cheese spread and salad. The bread remains untouched.

Naïve Logic (Rambam's implied view in 209:6, before Shulchan Arukh's refinement): A naive algorithm might execute a simple IF ikar_consumed THEN cover_tafel. Since ikar_bread was not consumed, the condition ikar_consumed evaluates to FALSE. Therefore, the algorithm would proceed to treat tafel_cheese and tafel_salad as standalone items.

• Expected Output (Naïve):
  • Blessing on tafel_cheese: "Shehakol" (assuming it's not made of grain).
  • Blessing on tafel_salad: "Ha'adama" (assuming vegetables).
  • Total: Two blessings.

Arukh HaShulchan's Expected Output (Based on 209:6, following Shulchan Arukh): The Arukh HaShulchan's algorithm introduces a crucial state variable: ikar_present_and_intended_to_be_eaten. This variable, if TRUE, allows the tafel items to be covered even if the ikar is not ultimately consumed. The condition is that the ikar must be "מוכן לפניו" (prepared before him) and his "דעתו לאכלו" (intention to eat it) must persist.

• Algorithm's execution:
  1. ikar_bread is present_and_available (on the table).
  2. Sarah's eaterIntention for ikar_bread was initially TRUE.
  3. Even though she didn't eat the bread, her intention to eat it persisted while she ate the tafel items (she was called away, not that she decided not to eat the bread).
  4. Therefore, tafel_cheese and tafel_salad are covered by the intended (though unrecited) Hamotzi blessing.
• Expected Output (Arukh HaShulchan):
  • No blessings required for tafel_cheese or tafel_salad.
  • Total: Zero blessings.

Why this matters: The Arukh HaShulchan's rule reflects a deeper understanding of human intent and the holistic nature of a meal. The relationship between the items (primary and secondary) is established by the initial setup and intention, not solely by the act of consumption. This prevents unnecessary blessings in situations where the "plan" was clear, even if execution was interrupted. It’s like a promise function in programming: the promise itself creates a state, even if the eventual fulfillment is deferred or, in this case, prevented.

Edge Case 2: The "Overachieving Tafel" – Subordinate Ingredient, Large Quantity

Input Scenario: David is eating a hearty stew. The stew is predominantly made of large chunks of beef (ikar_meat), but to thicken it and add some bulk, the chef has added a significant amount of barley (tafel_barley) – enough to constitute a k'zayit (olive-sized volume) for each serving, and perhaps even more than 1/6th of the total volume of the stew. The dish is clearly called "Beef Stew," and David's primary intention is to eat the meat.

Naïve Logic (Magen Avraham's implied view in 209:8, rejected by Arukh HaShulchan): A naive algorithm might be BlessingEngine_MagenAvraham_v1.0 (Threshold-Based Promotion). It would first identify ikar_meat as the primary. Then, it would detect tafel_barley and check its quantity. Since tafel_barley exceeds the k'zayit threshold (and perhaps the 1/6th proportion), the algorithm would "promote" it.

• Expected Output (Naïve/Magen Avraham):
  • Blessing on tafel_barley: "Mezonot" (as it's a grain). This "Mezonot" blessing would then cover the "Shehakol" (on the meat) because Mezonot is generally considered a higher-priority blessing.
  • Total: One blessing ("Mezonot").

Arukh HaShulchan's Expected Output (Based on 209:8): The Arukh HaShulchan's algorithm (BlessingEngine_ArukhHaShulchan_v2.0 - Purpose-Driven Hierarchy) directly confronts this scenario. It asserts that if the ikar_meat is truly the main component and the tafel_barley is there only for thickening or bulk (i.e., a functional role), then its quantity is irrelevant. The tafel_barley remains subordinate to the ikar_meat.

• Algorithm's execution:
  1. The dish is named "Beef Stew," and David's eaterIntention is for the meat (ikar_meat).
  2. tafel_barley is identified as having a functionalRole (thickening, bulk).
  3. Even though tafel_barley quantity > k'zayit, the Arukh HaShulchan's rule explicitly states this does not change its tafel status if its role is functional and the meat is ikar.
  4. Therefore, the blessing is made on the ikar_meat, covering the tafel_barley.
• Expected Output (Arukh HaShulchan):
  • Blessing on ikar_meat: "Shehakol".
  • Total: One blessing ("Shehakol").

Why this matters: This highlights the Arukh HaShulchan's preference for a robust, purpose-driven classification over a quantity-driven one. It prevents the system from being "tricked" by ingredient ratios that don't reflect the fundamental identity or purpose of the dish. The "Beef Stew" remains "Beef Stew," and the blessing reflects that, regardless of how much barley was needed to perfect its texture. It's about the semantic meaning, not just the raw data.

Refactor

The current rules, while comprehensive, sometimes require navigating multiple conditions and sub-conditions to establish the ikar status, particularly for composite dishes or items eaten together. A minimal change that could clarify the rule and make the system more intuitive would be to introduce a primary intent state variable that, once established, acts as a strong override for certain quantitative or secondary conditions.

Proposed Refactor: Introduce PrimaryIntentLocked State

The current system implicitly factors in "intention" (כוונת האוכל, 209:9), but it's often a fuzzy input. Let's make it an explicit, sticky state.

Current Implicit Logic: IF dish_is_meatballs AND grain_for_binding AND meat_is_main_component THEN bless_Shehakol ELSE IF dish_is_grain_kugel AND grain_is_main_component THEN bless_Mezonot (This relies on a complex evaluation of "main component" and "functional role" in each check).

Refactored Logic:

1. Introduce a PrimaryIntentLocked boolean state variable.

   • This variable is set to TRUE early in the blessing determination process, based on the initial, overarching intention of the eater or the universally recognized identity of the dish.
   • Once PrimaryIntentLocked is TRUE, it acts as a strong gatekeeper against "promotion" or "reclassification" of other items based on secondary criteria (like quantity of tafel grain).

2. Modified Flow Model Step (e.g., for Multi-Ingredient Dish Check - Step 4):

   • IF foodItems represents a single, composite dish:
     • Determine PrimaryIntentItem:
       • Criterion 1: dishName: What is the dish primarily called? (e.g., "Meatballs" -> PrimaryIntentItem = Meat).
       • Criterion 2: eaterOverallIntention: What does the eater primarily intend to eat/experience? (e.g., "I'm having meat," "I'm having rice").
       • IF PrimaryIntentItem is clearly established:
         • Set PrimaryIntentLocked = TRUE.
         • Blessing will be getSpecificBlessing(PrimaryIntentItem).
     • FOR EACH otherIngredient in the dish:
       • IF PrimaryIntentLocked == TRUE:
         • IF otherIngredient's role is purely functional (binding, thickening) and it's not the PrimaryIntentItem:
           • otherIngredient is covered. No separate blessing.
         • ELSE IF otherIngredient is inherently chashuv and not the PrimaryIntentItem (e.g., wine in a meat sauce, but wine is still important):
           • Add getSpecificBlessing(otherIngredient) to blessingsRequired. (This handles cases where a chashuv item is intended to be secondary but is too important to be covered.)
         • ELSE (otherIngredient would be primary if PrimaryIntentLocked wasn't true, but it's not the PrimaryIntentItem):
           • otherIngredient is covered. No separate blessing.
       • ELSE (no clear PrimaryIntentLocked could be established, e.g., truly mixed dish with co-equal intent):
         • Evaluate each item individually or fallback to a more complex comparison. (This is the rare case where the Arukh HaShulchan might allow two blessings or a more nuanced rule).

This minimal change elevates "intention" and "dish identity" to a higher-priority, sticky state. Once the system identifies the primary focus of the consumption event (the "Beef Stew" is about the beef), it effectively "locks in" the ikar, making subsequent checks (like the quantity of barley) irrelevant for reclassifying the ikar/tafel relationship. This better reflects the Arukh HaShulchan's decisive ruling in 209:8, where the meat's primary status overrides the quantity of the functional grain. It's like setting a const variable for the ikar early in the function, simplifying subsequent conditional branches.

Takeaway

What a journey through the blessing-algorithm matrix! Our deep dive into Arukh HaShulchan 209 reveals that halakha isn't just a collection of rules; it's a sophisticated, carefully architected system designed to interface with the nuanced realities of human experience. The ikar v'tafel paradigm is a testament to this, providing a framework for managing complexity in food consumption.

We've seen how the Arukh HaShulchan, acting as a master system architect, prioritizes semantic meaning and overarching intent over raw data points (like ingredient quantity). Its Purpose-Driven Hierarchy algorithm (our Algorithm B) for mixed dishes, and its handling of PrimaryIntentLocked states for unconsumed ikar (our Edge Case 1), demonstrate a robust design philosophy. This system is optimized for predictability and consistency, ensuring that the blessing reflects the true relationship between the foods in the eater's mind, rather than being swayed by mere ratios or unfulfilled intentions.

Ultimately, the lesson extends beyond food blessings. It's a meta-lesson in systems design: a truly resilient system must understand its users' intentions, define clear hierarchies, and establish stable state variables, even when faced with dynamic inputs. By doing so, it simplifies decision-making, reduces ambiguity, and ensures that the output – in our case, the sacred act of blessing – is always aligned with its profound purpose. Keep coding, keep learning, and may all your blessings be bug-free!