Mishneh Torah, Mourning 2

Problem Statement: The Avail-a-Bility Matrix (or, "Who Gets the AVEL Flag, and When?")

Greetings, fellow data architects of the divine! Today, our bug report comes from the intricate world of avelut (mourning) and tum'at kohanim (priestly ritual impurity). Imagine a highly regulated system where certain flags (mourning status, impurity status) are triggered based on relationships and states. The core challenge, the bug we're debugging, is that these flags don't always align. A kohen (priest) might mourn for someone but not become impure, or vice-versa. And the source of the obligation (Scriptural vs. Rabbinic) acts like a privilege level in our system architecture, impacting how deeply the protocol is enforced. Rambam, in Mishneh Torah, Mourning Chapter 2, is essentially giving us the spec sheet for this complex event-driven system, detailing the callbacks and exception handlers for life's ultimate terminal event.

The Core Bug: Discrepant Obligation.Source and Obligation.Type

The system's initial design spec (Torah law) defines a baseline mourning_obligation for a very specific relative_set. But then, middleware (Rabbinic enactments) expands this set, and introduces conditional overrides for Kohen.ImpurityStatus. The bug surfaces when a naive query might assume mourning_obligation == TRUE implies kohen_impurity_obligation == TRUE. Rambam's text meticulously disentangles these.

Text Snapshot: Core Data Points

Here are some critical lines from Mishneh Torah, Mourning 2, that define our initial data structures and conditional logic:

Mishneh Torah, Mourning 2

• Mourning 2:1: "These are the relatives for whom a person is obligated to mourn according to Scriptural Law: His mother, his father, his son, his daughter, his paternal brother and paternal sister. According to Rabbinic Law, a man should also mourn for his wife if she dies while they are married. And a woman should mourn for her husband. Similarly, a person should mourn for a maternal brother and sister. Even a priest who does not become impure for his maternal brother and sister or for his paternal sister who is married, mourns for them. For his married paternal sister who is married, he is required to mourn by Scriptural Law."
• Mourning 2:3: "Whenever a person is obligated to mourn for a relative, he also mourns with that relative in his presence according to Rabbinical Law. What is implied? If a person's grandson, his son's maternal brother, or son's mother dies, he is obligated to rend his garments in the presence of his son and follow the mourning rites while in his presence. Outside his presence, he is not obligated."
• Mourning 2:9: "A priest is forced to contract ritual impurity to tend to his deceased wife. This obligation is Rabbinic in origin. Our Sages had her considered as an unattended corpse. Since she has no other heir aside from him, there will be no one else to tend to her. He becomes impure only for a wife he has married. If he has merely consecrated her, he does not become impure for her."
• Mourning 2:10: "When a priest's sister is married - even to another priest, he does not become impure for her sake, 'as Leviticus 21:3 states: 'his virgin sister who is close to him who has not been with a man.' 'Virgin' excludes a girl who has been raped or seduced... 'Who has not been with a man' - this also excludes a sister who has been consecrated. He does not become impure, for her sake even if she is consecrated to a priest. If, however, a priest's sister is divorced after consecration, before marriage, he must become impure for her sake... A priest does not become impure for the sake of his maternal brother and sister..."
• Mourning 2:11: "A priest may not become impure for the sake of a limb severed from his father while alive, nor for the sake of one of his father's bones... If his father's head is decapitated, he may not become impure for his sake. This is implied by Leviticus 21:2: 'To his father,' i.e., at a time when his corpse is intact and not when it is impaired."

Flow Model: The Obligation.Compute() Decision Tree

Let's visualize the Obligation.Compute() function as a decision tree, with INPUT: (DeceasedRelative, Observer, ObserverStatus) and OUTPUT: (MourningObligation, ImpurityObligation, ObligationSource).

START: EvaluateObligations(DeceasedRelative, Observer, ObserverStatus)

1. Is DeceasedRelative in CORE_DEORAITA_MOURNERS_LIST? (Father, Mother, Son, Daughter, Paternal Brother, Paternal Sister)
    ├── YES --> MourningObligation = TRUE, MourningSource = Scriptural
    │   └── Is Observer a Kohen?
    │       ├── YES --> Is DeceasedRelative a PaternalSister AND is she Married/Non-Virgin/Consecrated?
    │       │   ├── YES --> ImpurityObligation = FALSE (See 2.10)
    │       │   └── NO --> ImpurityObligation = TRUE, ImpuritySource = Scriptural
    │       └── NO --> ImpurityObligation = N/A
    └── NO --> Continue to 2.

2. Is DeceasedRelative in RABBINIC_MOURNERS_LIST? (Wife, Husband, Maternal Brother, Maternal Sister)
    ├── YES --> MourningObligation = TRUE, MourningSource = Rabbinic
    │   └── Is Observer a Kohen?
    │       ├── YES --> Is DeceasedRelative a Wife (married)?
    │       │   ├── YES --> ImpurityObligation = TRUE (forced, like Met Mitzvah), ImpuritySource = Rabbinic (See 2.9)
    │       │   └── NO (i.e., Maternal Sibling, or Consecrated Wife) --> ImpurityObligation = FALSE (See 2.10, 2.9)
    │       └── NO --> ImpurityObligation = N/A
    └── NO --> Continue to 3.

3. Is DeceasedRelative relevant for JOINT_MOURNING? (Grandson, Son's Maternal Brother, Son's Mother, Father-in-law, Mother-in-law)
    ├── YES --> Is Observer IN_PRESENCE_OF direct mourner?
    │   ├── YES --> MourningObligation = TRUE, MourningSource = Rabbinic (joint)
    │   └── NO --> MourningObligation = FALSE
    └── NO --> Continue to 4.

4. Is DeceasedRelative in EXCLUSION_LIST? (Maid-servant/Gentile child, Convert/Freed slave for each other, Unconsecrated wife, Executed by court, Suicide, Stillborn, Doubtful lineage, Severed limb, Decapitated/Non-intact body)
    ├── YES --> MourningObligation = FALSE, ImpurityObligation = FALSE
    └── NO --> No obligation found (Return Default: FALSE, FALSE, N/A)

END: Return (MourningObligation, ImpurityObligation, ObligationSource)

Two Implementations: The Wife.StatusCheck() Algorithm

Our Mishneh Torah text presents a fascinating architectural decision regarding the status of a wife within the mourning system. Specifically, whether a husband's obligation to mourn for his wife is hard-coded (Scriptural) or configurable (Rabbinic). This isn't just an academic distinction; it's a privilege escalation issue. De'oraita (Scriptural) obligations often override other mitzvot and carry a higher severity level than derabanan (Rabbinic) ones.

Rambam, in Mourning 2:1, explicitly states: "According to Rabbinic Law, a man should also mourn for his wife if she dies while they are married." This is Algorithm A, Rambam's implementation of Wife.StatusCheck().

Algorithm A: Rambam's StrictDerasha Parsing

Function Wife.StatusCheck_Rambam(deceased_relative)

1. Input: deceased_relative (object with type = Wife, marital_status = Married).
2. Core_Deoraita_Relatives_Scan():
   • Iterate through the hard-coded list of Scriptural mourners: [Father, Mother, Son, Daughter, PaternalBrother, PaternalSister].
   • Wife is not an explicit match in this array.
3. Derasha_Evaluation("his flesh"):
   • Consider the Biblical phrase "to his flesh, to whom he is close" (Leviticus 21:2-3), which is often interpreted to include a wife.
   • Rambam's parser (his halachic methodology), as explained by the Yad Eitan (on Mourning 2:1:1), performs a strict_derasha_check. He argues that the derasha connecting "his flesh" to a wife is not a complete (i.e., fully definitive and Scriptural) derivation for mourning purposes.
   • The Yad Eitan states: "Our master follows his own reasoning that he ruled in Hilchot Ishut and Hilchot Nachalot regarding a husband's inheritance of his wife, that it is only Rabbinic. For he holds that 'his flesh' (Leviticus 21:2) which includes his wife, is not a complete derasha (interpretation)."
   • This means the boolean_result for IsWifeDeoraitaMourner() is FALSE under Rambam's compiler.
4. Rabbinic_Override_Check():
   • Since the Scriptural flag isn't set, the system then checks for a Rabbinic_enactment_for_wife_mourning().
   • Such an enactment exists (Mourning 2:1).
5. Output: MourningObligation = TRUE, ObligationSource = Rabbinic.

Furthermore, this design choice cascades. For a Kohen, his obligation to become impure for his wife is also Rabbinic (Mourning 2:9). The reasoning is a pragmatic exception handler: she's considered a met mitzvah (an unattended corpse) because she has no other heir to tend to her, forcing the Kohen to act. This is a runtime decision based on system state rather than a hard-coded de'oraita instruction.

Algorithm B: The BroaderDerasha Interpretation

Many other Rishonim and halachic developers (commentators) implement Wife.StatusCheck() differently, leading to an alternative output.

Function Wife.StatusCheck_OtherRishonim(deceased_relative)

1. Input: deceased_relative (object with type = Wife, marital_status = Married).
2. Core_Deoraita_Relatives_Scan():
   • Same as Algorithm A: Wife is not an explicit match.
3. Derasha_Evaluation("his flesh"):
   • These developers interpret "to his flesh, to whom he is close" as a complete and definitive derasha that does include a wife as a Scriptural relative for mourning. They see the marital bond as creating a de'oraita "flesh" connection.
   • The boolean_result for IsWifeDeoraitaMourner() is TRUE under their compiler.
4. Rabbinic_Override_Check():
   • This step is skipped or irrelevant because the de'oraita obligation has already been established.
5. Output: MourningObligation = TRUE, ObligationSource = Scriptural.

Implications of the Algorithmic Difference:

This divergence isn't minor. If mourning for a wife is de'oraita, it carries more weight and stringency. For instance, it might imply that a Kohen's tum'ah for his wife would also be de'oraita, not merely derabanan as a met mitzvah. The system's behavior changes based on which algorithm is invoked. Rambam's codebase prioritizes literal interpretation and explicit enumeration for de'oraita status, reserving Rabbinic directives for extended functionality or exception handling. Other codebases utilize a broader API interface for derashot, expanding the de'oraita scope. This illustrates how even within the same Torah OS, different compilers can yield different runtime behaviors.

Edge Cases: Stress Testing the Obligation.Compute() Function

Our system needs to handle specific edge cases that might trip up a naive implementation.

Edge Case 1: The Kohen's Married Paternal Sister ({RelativeType: PaternalSister, MaritalStatus: Married, ObserverType: Kohen})

• Naïve Logic (Buggy_Algorithm_V1.0): "Sister is a Scriptural mourner. Kohen becomes impure for Scriptural mourners. Therefore, a Kohen becomes impure for his married paternal sister."
• Textual Constraint (Mourning 2:1 & 2:10):
  • Mourning 2:1: "...a priest who does not become impure for his maternal brother and sister or for his paternal sister who is married, mourns for them. For his married paternal sister who is married, he is required to mourn by Scriptural Law."
  • Mourning 2:10: "When a priest's sister is married - even to another priest, he does not become impure for her sake..."
• Input: DeceasedRelative = PaternalSister, DeceasedRelative.MaritalStatus = Married, Observer = Kohen.
• Expected Output (Obligation.Compute()):
  • MourningObligation = TRUE
  • MourningSource = Scriptural (due to being a paternal sister)
  • ImpurityObligation = FALSE (because she is married, the Kohen.Impurity rules have an exclusion_clause for this specific state).
• Analysis: This edge case perfectly highlights the decoupling of mourning and impurity obligations for a Kohen. The mourning_protocol is engaged (de'oraita), but the impurity_protocol has a conditional bypass based on the sister's marital_status. This prevents a cascading failure of assumptions.

Edge Case 2: The Decapitated Father ({RelativeType: Father, CorpseIntegrity: Decapitated, ObserverType: Kohen})

• Naïve Logic (Buggy_Algorithm_V1.0): "Father is a Scriptural mourner. Kohen becomes impure for his father. Therefore, a Kohen becomes impure for his decapitated father."
• Textual Constraint (Mourning 2:11): "If his father's head is decapitated, he may not become impure for his sake. This is implied by Leviticus 21:2: 'To his father,' i.e., at a time when his corpse is intact and not when it is impaired."
• Input: DeceasedRelative = Father, DeceasedRelative.CorpseIntegrity = Decapitated, Observer = Kohen.
• Expected Output (Obligation.Compute()):
  • MourningObligation = TRUE (the father is still the father, mourning applies)
  • MourningSource = Scriptural
  • ImpurityObligation = FALSE (because the CorpseIntegrity.Check() returns IMPAIRED, triggering an impurity_exclusion).
• Analysis: This edge case demonstrates a crucial precondition for Kohen.Impurity. It's not just about the relationship_type but also the state of the deceased_object. The system requires the corpse to be intact (or at least, not severely impaired in certain ways) for the impurity_protocol to be active. It's a data validation step on the deceased_object itself.

Refactor: Clarifying the Kohen.Impurity Data Model

The Rambam's text, while comprehensive, initially presents the Kohen's tum'ah rules as a series of specific inclusions and then detailed exclusions (especially for the sister). A minimal refactor could be to clarify the Kohen.Impurity data model by introducing two distinct attributes for sister and wife within the Kohen.ImpurityEligibility schema, rather than relying on implicit context.

Current (Implicit) Model:

KohenImpurityRelatives = [Father, Mother, Son, Daughter, PaternalBrother, PaternalSister, Wife] Exceptions: PaternalSister.IsMarried=TRUE || PaternalSister.IsConsecrated=TRUE || PaternalSister.IsNonVirginNotByMan=TRUE...

Refactored Kohen.Impurity Data Model (Minimal Change):

Instead of a generic PaternalSister, the Kohen.ImpurityEligibility data structure should define:

• PaternalSister:
  • REQUIRED_STATE: IsVirgin = TRUE
  • REQUIRED_STATE: HasNotBeenWithMan = TRUE
  • REQUIRED_STATE: IsNotConsecrated = TRUE
  • REQUIRED_STATE: IsNotMarried = TRUE
• Wife:
  • REQUIRED_STATE: IsMarried = TRUE
  • REQUIRED_STATE: IsNotConsecrated = TRUE
  • OBLIGATION_SOURCE: Rabbinic (explicitly flagged, not implied by an exception)

This small refactoring explicitly encodes the preconditions for a Kohen to become impure for his sister directly into her data type definition, and flags the wife's unique Rabbinic source. It moves from an exception-driven logic to a condition-driven logic for these complex relationships, making the system's behavior more predictable at a glance. It's like switching from a long IF-THEN-ELSE chain to a concise pattern match.

Takeaway: Robust Systems Design

This deep dive into Rambam's mourning-and-impurity system reveals a master architect at work. We see how Scriptural APIs are extended by Rabbinic middleware, how data validation (corpse integrity) and state checks (marital status, virginity) are critical, and how different algorithmic interpretations can lead to varied runtime behaviors. The system is designed with layered logic and exception handling, demonstrating a profound appreciation for robustness and precision in halachic engineering. It's a beautiful testament to the complexity and elegance inherent in Torah's operating system.