The Nedarim.ExpirationDateResolver Service: A Bug Report on Contextual Ambiguity

Greetings, fellow data architects of Halakha! Pull up a chair, grab your favorite energy drink (mine's a lukewarm Gemara-cola), and let's dive into a fascinating bug report from the Nedarim module, specifically Nedarim 63. Our ExpirationDateResolver service, responsible for calculating the precise moment a konam vow's prohibition expires, is encountering some unexpected runtime behavior when processing temporal conditions.

Problem Statement: The UNTIL <EVENT> Parameter Ambiguity

The core issue stems from the UNTIL <EVENT> parameter within our resolveVow function. While seemingly straightforward, the "event" can be interpreted in multiple ways, leading to non-deterministic outcomes. Our system, currently leaning towards a literal, "syntactic sugar" interpretation, frequently fails to align with the halakhic_intent protocol, resulting in VowResolutionExceptions or MisinterpretedVow warnings.

Consider the following VowSchema:

{
  "vowId": "NDRM63-001",
  "vowerId": "User123",
  "prohibitedItem": "Wine",
  "durationType": "UNTIL_EVENT",
  "event": "Adar"
}

If event is "Adar," which Adar are we talking about in a leap year? The first? The second? Does the vower's knowledge_state regarding the leap year affect this? Similarly, a vow "until the rain" (עד הגשם) – does this mean the scheduled date for rain, or the actual precipitation event? And what about "until the rains" (עד הגשמים)? This isn't just about parsing strings; it's about discerning the semantic_context and user_intent hidden behind simple declarations.

The Ran (Nedarim 63a:1:1) succinctly highlights this problem with a comparative analysis of עד הגשם (until the rain) versus עד הקציר (until the harvest). He posits that for עד הגשם, we follow the known, scheduled time of the rain, because "ידעינן זמנה של רביעה" (we know the fixed time of the rainfall). However, for עד הקציר, since "לא ידעינן זמניה שהכל הוא לפי הארצות" (we don't know its time, as it varies by regions), we must follow the actual occurrence of the harvest. This immediately tells us that our resolveVow function cannot simply have a single event_type_parser; it needs contextual_dependency_injection based on the nature of the event itself.

The Nedarim.ExpirationDateResolver must evolve from a simple literal_string_matcher to a sophisticated contextual_intent_engine that accounts for:

1. Event Type: Is it a fixed calendar event, a scheduled natural phenomenon, or an actual occurrence?
2. Vower's Knowledge State: Did the vower possess critical information (e.g., leap year status) at the time of the vow?
3. Underlying Purpose/Intent: Was the vow intended to achieve a specific social outcome (e.g., honor, preventing marriage, avoiding a meal)?

Our current literal_parser throws null values or defaults to an incorrect expiration_timestamp, causing halakhic_compliance_errors. We need a robust, multi-layered decision_tree to navigate these complexities.

Text Snapshot: Anchoring the Ambiguity

Let's ground our analysis in the source code, referencing the relevant lines from Nedarim 63:

• The Rainfall Problem (Scheduled vs. Actual):

  • Nedarim 63a:16: "מיתיבי איזוהי זמנה של רביעה הבכירה בשלשה בינונית בשבעה אפילה בעשרים ושלשה דברי ר"מ" - The Gemara raises an objection... When is the time of the rainfall? The early rainfall occurs on the third of Marḥeshvan; the intermediate on the seventh... This is the statement of Rabbi Meir. (This establishes scheduled rain dates).
    • Commentary Note (Steinsaltz Nedarim 63a:1): "מיתיבי [מקשים] על כך ממה ששנינו: איזוהי זמנה של רביעה?" - Steinsaltz clarifies this is an objection, setting up the problem.
  • Nedarim 63a:22: "לנודר" - Rabbi Zeira said: It is significant for one who vows [until the rain]. (R. Zeira applies the scheduled rain dates to vows).
  • Nedarim 63a:24: "רשב"ג אומר גשמים שירדו ז' ימים זה אחר זה אתה מונה רביעה ראשונה ושניה" - Rabban Shimon ben Gamliel says: In the case of rains that fell for seven days, one after another, you count them as the first rainfall and the second. (This implies actual rain, not scheduled).
  • Nedarim 63a:27: "ההיא דאמר עד הגשמים" - The Gemara answers: That baraita is referring to one who said: Until the rains [plural]. (The critical distinction: singular vs. plural, implying scheduled vs. actual).

• The Adar Problem (Leap Year Ambiguity):

  • Nedarim 63a:29: "מתניתין: היין קונם עלי שאני טועם כל השנה כו' עד ראש אדר עד ראש אדר הראשון" - MISHNA: ...If he vowed until the beginning of Adar, the vow remains in effect until the beginning of the first Adar. (The Mishna's default for "Adar").
  • Nedarim 63a:36: "בדין הוא דמתניתין ר' יהודה היא דתניא בראשון כותב אדר הראשון בשני כותב אדר סתם דברי ר"מ ר' יהודה אומר בראשון כותב אדר סתם ובשני כותב אדר שני" - Shall we say that the mishna is in accordance with the opinion of Rabbi Yehuda? As it is taught: In the first Adar, one writes first Adar; in the second Adar, one writes Adar without specification; this is the statement of Rabbi Meir. Rabbi Yehuda says the reverse: In the first Adar one writes Adar without specification, and in the second Adar he writes second Adar. (The Tannaic dispute on dating documents, creating a dilemma for the Mishna).
  • Nedarim 63a:40: "אביי אמר לך אפילו תימא רבי מאיר, הכא כשלא ידע דשנה מעוברת היא" - Abaye said: You can even say that the mishna is in accordance with the opinion of Rabbi Meir, as there is a difference between the cases: This baraita is referring to one where the individual who took the vow knew that the year was extended... Conversely, that mishna is referring to a case where he did not know... (Abaye's critical vowerKnowledge parameter).

• The Intent Problem (Contextual Overrides):

  • Nedarim 63a:45: "ר' יהודה אומר: היין קונם עלי שאני טועם עד שיהא פסח לא אמר אלא עד לילי פסח" - Rabbi Yehuda says: ...Wine is konam for me... until it will be Passover, this individual intended only until the night of Passover... (Intent overrides literal end date for Mitzvah fulfillment).
  • Nedarim 63a:60: "ההוא דהוה קא מפתה ליה לחבירו למיכל בהדיה ואמר ליה קונם ביתך עלי וקונם טיפה קרה שלך עלי מותר ליכנס לביתו ולשתות טיפה קרה שלו לא אמר אלא דרך אכילה ושתיה" - Similarly, if one was urging another to eat with him, and the latter said: Entering your house is konam for me, as is tasting even a drop of cold liquid of yours, the individual... is nevertheless permitted to enter his house and to drink a cold beverage of his... he intended only for the purpose of eating and drinking a meal... (Intent limits scope of prohibition).

Flow Model: The VowExpirationResolver Decision Tree

To address the UNTIL <EVENT> ambiguity, we need a robust VowExpirationResolver module. Here's a simplified decision tree representing its logic:

graph TD
    A[Vow Declared: KONAM X UNTIL <EVENT>] --> B{Is <EVENT> a Calendar/Scheduled Phenomenon?};
    B -- Yes --> C{Is <EVENT> "Rain" (singular) or similar fixed schedule?};
    C -- Yes --> D[Resolve to Scheduled Date: e.g., R. Meir's 3rd Marheshvan for "Rain"];
    C -- No (e.g., "Harvest", "Rains" plural) --> E[Resolve to Actual Occurrence: Wait for physical event];
    B -- No (e.g., "Passover", "Adar", "Shabbat", "Yom Kippur") --> F{Is <EVENT> a Time-Bound Religious/Social Context?};
    F -- Yes --> G{Is there a specific Vower's Intent/Purpose?};
    G -- Yes (e.g., Passover -> Seder; Yom Kippur -> Seudah Mafseket; Adar -> Vower's Knowledge) --> H[Apply Contextual Override: Adjust expiration based on intent];
    G -- No --> I[Apply Literal Calendar Date];
    F -- No (e.g., Conditional Vows involving benefit/marriage/eating) --> J{Is Vow Conditional on an Action or Social Interaction?};
    J -- Yes --> K{Determine Vower's Underlying Purpose (e.g., Honor, Avoid Marriage, Avoid Meal)};
    K -- Yes --> L[Apply Intent-Based Scope/Dissolution Logic: e.g., "My honor is not to take," "Only prohibits marriage," "Only prohibits the meal"];
    K -- No --> M[Default to Literal Conditional Fulfillment];
    J -- No --> M;
    I --> Final[Vow Expiration/Scope Resolved];
    H --> Final;
    E --> Final;
    D --> Final;
    L --> Final;
    M --> Final;

This model outlines the flow:

• Input: VowDeclaration(prohibited_item, event_string, context_params)
• Step 1: Event Categorization (B): The system first classifies the <EVENT> string.
  • If Calendar/Scheduled (e.g., "rain" singular, "Adar"): Proceed to C.
  • If Actual Occurrence (e.g., "harvest", "rains" plural): Proceed to E.
  • If Contextual Time-Bound (e.g., "Passover", "Shabbat"): Proceed to F.
  • If Conditional/Social Interaction (e.g., "if you don't take gift"): Proceed to J.
• Step 2: Scheduled Event Resolution (C, D, E): For scheduled events, differentiate between those with fixed halakhic schedules (like עד הגשם, leading to D) and those requiring actual observation (like עד הקציר or עד הגשמים, leading to E).
• Step 3: Contextual Override for Time-Bound Events (F, G, H, I): For events like "Passover" or "Adar", a critical VowerIntentParser (G) is invoked. This parser checks for mitzvah_fulfillment_intent (Passover/wine, Yom Kippur/meat) or vower_knowledge_state (Adar/leap year). If intent is found, H applies a contextual override (e.g., "until Seder night," "until First Adar if vower didn't know"). Otherwise, a literal calendar date (I) is used.
• Step 4: Intent-Based Scope/Dissolution for Conditional Vows (J, K, L, M): For complex conditional vows, an IntentAnalyzer (K) extracts the underlying social_purpose. This allows for non-literal resolutions, such as dissolving a vow based on the recipient's declaration of honor (L), or limiting the vow's scope to a specific activity (e.g., only prohibiting the meal, not general entry, L).
• Output: ResolvedVowState(expiration_timestamp, scope_of_prohibition).

This VowExpirationResolver decision tree ensures that our system can intelligently interpret UNTIL <EVENT> parameters, moving beyond simple string matching to a more halakhically_nuanced_semantic_analysis.

Two Implementations: The AdarResolutionAlgorithm

Let's zoom in on a specific challenge: resolving the Adar string in VowSchema.event during a leap year. The Gemara presents us with a classic scenario where initial Algorithm A and Algorithm B (from different Tannaim) are debated, only to be unified by a higher-order Algorithm Abaye that introduces a crucial contextual parameter.

The Problem: Ambiguous Adar

When a vower declares "until Adar" (עד אדר) in a year that might be intercalated with a second Adar, which month is implied? The Mishna (Nedarim 63a:29) initially states: "If he vowed until the beginning of Adar, the vow remains in effect until the beginning of the first Adar." This seems to offer a clear default. However, the Gemara immediately challenges this (Nedarim 63a:35), asking: "Shall we say that the mishna is in accordance with the opinion of Rabbi Yehuda?" This question opens the door to conflicting AdarResolutionAlgorithms used for a different, yet related, task: dating documents.

Algorithm A: DocumentAdarResolver_Meir (R. Meir's Protocol)

Purpose: To correctly identify the specific Adar month when dating a document in a leap year, according to Rabbi Meir. Inputs:

• monthString: A string representing the Adar month (e.g., "אדר", "אדר ראשון").
• isLeapYear: A boolean indicating if the current year is a leap year. Assumptions:
• The person dating the document knows it is a leap year.
• Specific terminology is used to differentiate the Adars. Logic (Nedarim 63a:36):

class DocumentAdarResolver_Meir:
    def resolve_adar(self, monthString: str, isLeapYear: bool) -> int: # Returns 1 or 2 for Adar I/II
        if not isLeapYear:
            return 1 # Only one Adar in a regular year

        # In a leap year, R. Meir's protocol:
        if monthString == "אדר ראשון": # "First Adar" explicitly stated
            return 1
        elif monthString == "אדר": # "Adar" without specification
            return 2 # Defaults to the Second Adar
        else:
            raise ValueError("Invalid Adar month string for R. Meir's protocol")

Example Usage:

resolver_meir = DocumentAdarResolver_Meir()

doc_date_meir_1 = resolver_meir.resolve_adar("אדר ראשון", True) # Output: 1

doc_date_meir_2 = resolver_meir.resolve_adar("אדר", True) # Output: 2

**Critique:** Rabbi Meir's algorithm prioritizes the *later* Adar as the "default" when no explicit "First" is mentioned. This implies that "Adar" (without qualification) refers to the *main* or *final* Adar, which is the second one in a leap year. This makes sense for document dating, where the later date might be considered the "true" or "primary" Adar for legal purposes.

#### Algorithm B: `DocumentAdarResolver_Yehuda` (R. Yehuda's Protocol)

**Purpose:** To correctly identify the specific Adar month when dating a document in a leap year, according to Rabbi Yehuda.
**Inputs:**
*   `monthString`: A string representing the Adar month (e.g., "אדר", "אדר שני").
*   `isLeapYear`: A boolean indicating if the current year is a leap year.
**Assumptions:**
*   The person dating the document *knows* it is a leap year.
*   Specific terminology is used to differentiate the Adars.
**Logic (`Nedarim 63a:36`):**
```python
class DocumentAdarResolver_Yehuda:
    def resolve_adar(self, monthString: str, isLeapYear: bool) -> int: # Returns 1 or 2 for Adar I/II
        if not isLeapYear:
            return 1 # Only one Adar in a regular year

        # In a leap year, R. Yehuda's protocol:
        if monthString == "אדר": # "Adar" without specification
            return 1 # Defaults to the First Adar
        elif monthString == "אדר שני": # "Second Adar" explicitly stated
            return 2
        else:
            raise ValueError("Invalid Adar month string for R. Yehuda's protocol")

# Example Usage:
# resolver_yehuda = DocumentAdarResolver_Yehuda()
# doc_date_yehuda_1 = resolver_yehuda.resolve_adar("אדר", True)      # Output: 1
# doc_date_yehuda_2 = resolver_yehuda.resolve_adar("אדר שני", True) # Output: 2

Critique: Rabbi Yehuda's algorithm prioritizes the earlier Adar as the "default" when no explicit "Second" is mentioned. This implies that "Adar" (without qualification) refers to the original or initial Adar. This also makes logical sense, viewing the second Adar as an "addition" or "extension."

The Conflict and Abaye's Refactor: VowAdarResolver_Abaye (The Contextual Meta-Algorithm)

The Mishna's statement that "until Adar" means "until the first Adar" (for a vow) seems to directly contradict R. Meir's DocumentAdarResolver_Meir (which defaults "Adar" to the second Adar in a leap year). The Gemara's question, "Shall we say that the mishna is in accordance with the opinion of Rabbi Yehuda?" highlights this incompatibility. If the Mishna follows R. Yehuda, then R. Meir's view on vows would be left unresolved.

This is where Abaye introduces a brilliant refactor—not by choosing between R. Meir and R. Yehuda's document-dating protocols, but by introducing a higher-level contextual parameter for vow resolution: the vowerKnowledgeOfLeapYear. Abaye argues that the Mishna's rule applies when the vower did not know the year was a leap year. The Baraita disputing R. Meir and R. Yehuda, conversely, applies when the vower did know.

Purpose: To resolve the specific Adar month for a vow based on the vower's knowledge state, harmonizing the Mishna and the Baraita. Inputs:

• vowText: The original vow string (e.g., "עד ראש אדר").
• vowerKnowledge: An enum representing the vower's knowledge of the leap year status (UNKNOWN_LEAP_YEAR, KNEW_LEAP_YEAR).
• isLeapYear: A boolean indicating if the current year is a leap year (essential for KNEW_LEAP_YEAR context). Assumptions:
• If vowerKnowledge is UNKNOWN_LEAP_YEAR, the vower naturally refers to the primary, first Adar.
• If vowerKnowledge is KNEW_LEAP_YEAR, the vower's specific wording or common practice in a leap year becomes relevant.

Logic (Nedarim 63a:40 onwards):

from enum import Enum

class VowerKnowledge(Enum):
    UNKNOWN_LEAP_YEAR = 1
    KNEW_LEAP_YEAR = 2

class VowAdarResolver_Abaye:
    def resolve_vow_adar(self, vowText: str, vowerKnowledge: VowerKnowledge, isLeapYear: bool) -> int:
        if not isLeapYear:
            return 1 # In a regular year, there's only one Adar

        if vowerKnowledge == VowerKnowledge.UNKNOWN_LEAP_YEAR:
            # This is the Mishna's case: "עד ראש אדר" -> First Adar
            # Abaye's logic: If the vower didn't know it was a leap year,
            # "Adar" (unspecified) *must* refer to the first, primary Adar.
            # All Tannaim would agree on this default for vows.
            # (Nedarim 63a:40: "הכא כשלא ידע דשנה מעוברת היא")
            return 1

        elif vowerKnowledge == VowerKnowledge.KNEW_LEAP_YEAR:
            # This is the Baraita's case (document dating, or specific vow phrasing):
            # If the vower *knew* it was a leap year, then their specific phrasing matters.
            # The Gemara (Nedarim 63a:43) re-interprets a Baraita:
            # "until the New Moon of Adar" (when he knew it was a leap year) means "until the New Moon of the *second* Adar."
            # This implies a default to the *later* Adar when knowledge is present and no explicit "Rishon" is given.
            # This aligns with the *spirit* of R. Meir's document dating, where the unspecified Adar is the later one,
            # although applied to a vow here.
            # The specific wording "עד ראש אדר" might still mean first Adar,
            # but if it was just "עד אדר" with knowledge, the second is implied.
            # For simplicity, based on the Gemara's inference for the second clause of the Baraita:
            if "ראש אדר" in vowText: # Explicitly "beginning of Adar" (usually implies first)
                return 1
            elif "אדר" in vowText: # Unspecified Adar, with knowledge of leap year
                return 2 # Default to Second Adar (as per the re-interpreted Baraita)
            else:
                raise ValueError("Invalid Adar vow text with knowledge of leap year")

# Example Usage:
# resolver_abaye = VowAdarResolver_Abaye()
#
# # Mishna's case: "until beginning of Adar" when vower didn't know it's a leap year
# vow_adar_mishna = resolver_abaye.resolve_vow_adar("עד ראש אדר", VowerKnowledge.UNKNOWN_LEAP_YEAR, True) # Output: 1
#
# # Baraita's case: "until New Moon of Adar" when vower *knew* it's a leap year
# # (Gemara's re-interpretation: Nedarim 63a:43)
# vow_adar_known = resolver_abaye.resolve_vow_adar("עד ראש חודש אדר", VowerKnowledge.KNEW_LEAP_YEAR, True) # Output: 2
#
# # If the vow explicitly stated "עד ראש אדר ראשון" (until beginning of First Adar),
# # even with knowledge, it would be 1. The code above simplifies this specific sub-case.

Synthesis: Abaye's VowAdarResolver_Abaye acts as a meta-algorithm, a higher-order function that selects the appropriate Adar interpretation based on the vowerKnowledge parameter.

• If vowerKnowledge == UNKNOWN_LEAP_YEAR, it "short-circuits" to the First Adar. This is a universal default for vows when the vower lacks full information, ensuring the vow is not more stringent than intended. This reconciles the Mishna's ruling with all Tannaic opinions.
• If vowerKnowledge == KNEW_LEAP_YEAR, then the interpretation becomes more nuanced, potentially falling back to the spirit of the R. Meir/R. Yehuda debate based on specific phrasing, with the Gemara inferring a default to Second Adar for an unspecified "Adar" under these conditions.

This demonstrates a powerful principle in Halakha's contextual parsing engine: user_state (the vower's knowledge) can be a more dominant factor in semantic resolution than literal_string_matching or even established sub-protocols (like document dating rules). Abaye's solution is not just an answer; it's an architectural pattern for intent-driven resolution.

Edge Cases: Stress-Testing the VowExpirationResolver

Let's throw some tricky inputs at our VowExpirationResolver to see if our contextual_intent_engine can handle scenarios that break naïve literal parsing.

Edge Case 1: The Rosh Hashanah Wine Vow

Input:

{
  "vowId": "EC-001",
  "vowerId": "User456",
  "prohibitedItem": "Wine",
  "durationType": "UNTIL_EVENT",
  "event": "Rosh Hashanah"
}

Naïve Logic Prediction: The vow prohibits wine until the actual day of Rosh Hashanah (Tishrei 1). This means the vower could not drink wine for Kiddush or the festive meal on the night of Rosh Hashanah (Erev Rosh Hashanah), as the day itself has not yet technically begun.

Expected Output (with Contextual Intent): The vow prohibits wine only until Erev Rosh Hashanah, specifically before the evening meal begins. This allows the vower to fulfill the mitzvah of Kiddush and drink the four cups of wine at the Seder.

Reasoning: This is a direct parallel to the Mishna's ruling regarding "until Passover" (Nedarim 63a:45): "Rabbi Yehuda says: ...Wine is konam for me... until it will be Passover, this individual intended only until the night of Passover, i.e., until the time when it is customary for people to drink wine." The system recognizes Rosh Hashanah as a JewishFestivalEvent with an associated MitzvahConsumptionProtocol (Kiddush). The VowerIntentParser deduces that the vower's underlying intent was to prevent consumption leading up to the holiday, not to sabotage their ability to perform a core mitzvah on the holiday. The expiration_timestamp is therefore adjusted to RoshHashanahSunsetEve rather than RoshHashanahSunriseDay. This is a mitzvah_fulfillment_override.

Edge Case 2: The Unwanted Leftovers Conditional Vow

Input:

{
  "vowId": "EC-002",
  "vowerId": "User789",
  "prohibitedItem": "Benefiting from me",
  "durationType": "CONDITIONAL_ACTION",
  "condition": "if you do not come and eat my leftover Challah"
}

Naïve Logic Prediction: The recipient (User101) is prohibited from benefiting from User789 until User101 physically comes and eats the leftover Challah. If User101 refuses, the prohibition remains in effect.

Expected Output (with Contextual Intent): User101 is permitted to benefit from User789 even if they do not eat the leftover Challah. The condition is effectively annulled or fulfilled by intent.

Reasoning: This scenario draws upon the Mishna's examples of conditional vows involving benefit and honor (Nedarim 63a:53 and Nedarim 63a:56).

• Case 1 (Recipient's Honor): "One who says to another: Benefiting from you is konam for me, if you do not come and take for your son one kor of wheat... this other individual can dissolve his vow without the consent of a halakhic authority... Did you say your vow for any reason other than due to my honor? This is my honor, that I refrain from accepting the gift, and consequently the vow is annulled."
  • If User101 perceives eating the leftover Challah as an affront to their honor (e.g., it's stale, or they feel insulted by the nature of the "gift"), they can declare "My honor is not to eat your leftovers." The VowerIntentParser would recognize that User789's underlying intent was to induce an action (eating the Challah), likely for User101's benefit or to get rid of the Challah. If the recipient declines for reasons of honor, the original intent of the vower is thwarted, and the vow's condition is thus not binding.
• Case 2 (Vower's Fulfillment by Declaration): "And, so too, in the case of one who says to another: Benefiting from me is konam for you, if you do not come and give my son one kor of wheat... the Rabbis say: Even this individual who took the vow can dissolve his own vow without the consent of a halakhic authority. This is because he can say to him: I hereby consider it as though I have received the gift."
  • If User789's intent was merely to ensure the Challah was consumed (e.g., to not waste it, or to prove a point), but User101 genuinely cannot or will not eat it, User789 can declare: "I hereby consider the Challah eaten" (metaphorically). The VowerIntentParser recognizes that the primary_goal of the vow was not strict enforcement of consumption but rather a desired outcome. By the vower's own declaration, that outcome is considered met.

In both sub-cases, the VowExpirationResolver prioritizes the human_element and underlying_motivation over a rigid, literal interpretation of the conditional_clause.

Refactor: Introducing the VowContext Object

Our current VowExpirationResolver is a bit of a spaghetti code mess, with if/else statements attempting to guess the context based on string matching. To truly clarify the rule and make our system robust, we need a minimal but impactful refactor: introduce a dedicated VowContext data object.

Instead of: resolveVow(vowText: str, isLeapYear: bool)

We refactor to: resolveVow(vow: Vow, context: VowContext) -> VowResolutionResult

Where Vow is an object representing the vow's basic components, and VowContext is a rich data structure that encapsulates all the necessary contextual metadata before the resolution logic even begins.

from dataclasses import dataclass
from datetime import datetime
from enum import Enum

class EventType(Enum):
    CALENDAR_FIXED = "CalendarFixed"
    CALENDAR_SCHEDULED = "CalendarScheduled"
    ACTUAL_OCCURRENCE = "ActualOccurrence"
    MITZVAH_TRIGGER = "MitzvahTrigger"
    SOCIAL_CONDITIONAL = "SocialConditional"

class VowerKnowledgeLevel(Enum):
    UNKNOWN = "Unknown"
    KNOWN_LEAP_YEAR = "KnownLeapYear"
    KNOWN_EVENT_DETAILS = "KnownEventDetails"

@dataclass
class VowContext:
    timestamp_of_vow: datetime
    is_current_year_leap: bool
    vower_knowledge_level: VowerKnowledgeLevel
    vower_stated_intent: str = None # Optional: explicit intent statement
    vower_implied_purpose: EventType = None # Inferred purpose (e.g., MitzvahTrigger)
    # Add other contextual parameters as needed, e.g.,
    # recipient_reaction_to_offer: str = None for conditional vows

@dataclass
class Vow:
    id: str
    prohibited_item: str
    duration_type: str # e.g., "UNTIL_EVENT", "CONDITIONAL_ACTION"
    event_string: str # e.g., "Adar", "Passover", "the rain"
    condition_string: str = None # For conditional vows

@dataclass
class VowResolutionResult:
    expiration_timestamp: datetime = None
    prohibition_scope: str = "FULL_PROHIBITION"
    is_dissolved: bool = False
    resolution_logic_applied: str = "Literal" # For debugging/auditing

Minimal Change, Maximal Impact: The VowContext object is a single, minimal addition to our resolveVow function's signature, yet it fundamentally shifts our architecture. Instead of the resolveVow function having to infer context from limited inputs, the VowContext object provides pre-parsed, rich metadata.

This allows the VowExpirationResolver to:

1. Directly Branch: Use context.vower_implied_purpose or context.event_type to immediately jump to the correct logic path (e.g., MitzvahOverrideLogic, AdarKnowledgeBasedResolver, IntentBasedDissolution).
2. Reduce Redundancy: Avoid repetitive parsing or inference within each if/else block.
3. Improve Testability: Easily create mock VowContext objects to test specific scenarios (e.g., vower_knowledge_level=KNOWN_LEAP_YEAR).
4. Enhance Readability: The function signature clearly communicates its dependencies and decision-making inputs.

This refactor transforms VowExpirationResolver from a black-box-string-parser into a context-aware-halakhic-inference-engine, making our codebase cleaner, more maintainable, and most importantly, more halakhically_accurate.

Takeaway: The Halakhic Contextual Engine

Our deep dive into Nedarim 63 reveals a profound insight into the Halakhic system: literal interpretation is merely the default fallback for the Vow Intent Resolution Engine. The true power of this system lies in its sophisticated contextual parsing.

When processing a vow, the Halakha doesn't just look at the syntactic structure of "until X." Instead, it performs a multi-dimensional semantic analysis, incorporating:

• The nature of X: Is it a fixed date, a scheduled event, or an actual occurrence? (e.g., עד הגשם vs. עד הקציר).
• The vower's knowledge state: Did the vower have all the relevant runtime parameters when making the vow? (e.g., vower_knowledge_of_leap_year for Adar).
• The underlying human intent or social purpose: What was the primary objective or mitzvah consideration driving this vow? (e.g., allowing Seder wine, respecting honor, preventing unwanted marriage, avoiding a meal).

This isn't just about finding loopholes; it's about optimizing for shalom_bayit (peace in the home), mitzvah_fulfillment, and preventing unintended_consequences that would arise from a purely literal_string_match. The Halakha's Vow Intent Resolution Engine is a masterclass in user-centric design, prioritizing the spirit_of_the_law by building robust contextual overrides into its core parsing protocols. It teaches us that true understanding often requires looking beyond the raw data to the metadata and the human story behind it.