Mishneh Torah, Neighbors 7-9

The Architectural API: A Bug Report on Neighborly Rights

Welcome, fellow code-slingers and data-wranglers of the digital beit midrash! Today, we're diving into a fascinating corner of Maimonides' Mishneh Torah, specifically Hilchot Sh'chenim (Laws of Neighbors), Chapters 7-9. Think of this as parsing a complex legacy codebase, where the "API" (Application Programming Interface) for property rights has to balance competing user stories, manage resource contention, and prevent "Sodomite exceptions" – that's our kofin al midat Sodom principle in action, compelling efficient resource allocation for collective good.

Our "bug report" for today centers on the intricate dance between privacy, light, and established usage rights when one neighbor builds a window overlooking another's courtyard, or later, when the courtyard owner wishes to build a structure opposite that window. It's a classic race condition: a window exists, granting its owner certain implicit "view" and "light" privileges. Then, a new "process" (a courtyard or a wall) is initiated, which, by its very nature, might interfere with those privileges, or introduce new privacy concerns. How does our halakhic OS (Operating System) arbitrate these conflicting claims? What are the default permissions, and how can they be overridden or modified?

The core problem statement is this: When property rights intersect and potential "damages" (like loss of privacy, obstruction of light, or structural instability) arise, how does the system, a priori, define and prioritize these rights, especially when one party has established a right (chazakah) through prior usage or lack of protest? The system needs a robust, context-sensitive algorithm to determine when a new construction is permissible, what spatial offsets are required, and under what conditions an existing right can be modified or revoked. Without clear protocols, we face constant deadlock and resource starvation – a truly chaotic system state!

Consider the WINDOW_OBJECT and COURTYARD_OBJECT classes. A WINDOW_OBJECT has properties like height, width, purpose (e.g., LIGHT, AIR, VIEW), and status (e.g., NEW, ESTABLISHED). A COURTYARD_OBJECT has properties like owner, development_status (e.g., UNDEVELOPED, BUILDING_WALL). The interaction between these objects generates events that trigger our halakhic rule engine. The "bug" is the ambiguity of how BUILDING_WALL modifies the state of WINDOW_OBJECT without violating its ESTABLISHED rights, or how NEW WINDOW_OBJECTs are handled initially. It's an object-oriented dilemma of property rights, demanding precise methods and event handlers.

Text Snapshot

Let's anchor our analysis in Maimonides' precise code:

• Neighbors 7:1: "When a person has a window in his wall and a colleague comes and builds a courtyard next to it, the owner of the courtyard cannot tell the owner of the window: 'Close this window, so that you will not look at me,' for the owner of the window has established his right to maintain the window even though it is a source of damage."

  • Steinsaltz 7:1:1: "שהרי קדם החלון לחצר והוא מוחזק בו." (For the window preceded the courtyard, and he has established his right in it.)
  • Steinsaltz 7:1:2: "כדי שלא יביט בו בעל החלון." (So that the owner of the window will not look into it.)
  • "If his colleague desires to build a wall opposite the window to block the invasion of his privacy, he must leave a space of four cubits next to the window, to avoid casting a shadow upon it."
  • Steinsaltz 7:1:3: "שלא יסתיר מבעל החלון את האור." (So that it will not hide the light from the owner of the window.)

• Neighbors 7:2: "If the window was positioned low in the wall, the owner of the window may force the owner of the courtyard to build the wall four cubits away from the window and build it at least four cubits high, so that the owner of the courtyard cannot look through the window and watch the owner of the window."

  • Steinsaltz 7:2:1: "כדי לא לחסום את האור." (So as not to block the light.)
  • Steinsaltz 7:2:2: "שיהיה הכותל גבוה ארבע אמות ומעלה מקצה גובה החלון כדי שלא יוכל להביט בעל החצר דרך חלון חברו ולהזיקו בראייה." (That the wall should be four cubits high or more above the top of the window, so that the owner of the courtyard will not be able to look through his colleague's window and damage him with his sight.)

• Neighbors 7:3: "The following rules apply when the window was positioned high on the wall and the owner of the courtyard built a wall below the window. If there were more than four cubits from the top of the wall to the window, the owner of the window may not prevent the owner of the courtyard from building the wall even though he does not leave any space between his wall and the wall in which the window is located. For the new wall is not casting a shadow over his window, nor does it invade the privacy of the owner of the window."

• Neighbors 7:4: "Accordingly, if a person comes to open a window - whether a large window or a small window - overlooking a courtyard belonging to a colleague, that colleague may prevent him from doing so, for he can tell the owner of the window: 'You will be invading my privacy by looking at me.'"

• Neighbors 7:5: "If a person has opened a window overlooking a courtyard belonging to a colleague, and the owner of the courtyard waived his right to protest or displayed his willingness to consent - e.g., he helped him in the window's construction or he knew about this source of damage and did not protest - the owner of the window has established his right to the window. The owner of the courtyard cannot come at a later date and protest that he must close it."

  • "What are the laws that apply with regard to this window that he was allowed to open? If it is large enough for a person to insert his head, or it is less than four cubits high, even if it is not large enough for a person to insert his head into it, the owner of the courtyard may not build a wall opposite or at its side unless he moves four cubits away, as explained in the previous halachah."

• Neighbors 7:6: "If, however, the window was too small for the head of a person to be inserted, and it is more than four cubits high, the owner of the courtyard may build a wall opposite it or at its sides. For he can claim: 'I allowed you to open the window only because it is small and high, but it was not my intent to give you a right that would require me to move away my building.'"

  • "When does the above apply? When the window was opened to be used or to allow air to enter. If, however, the window was opened so that light could enter, even if it was very small and very high, since the owner of the courtyard did not protest at the time of its construction, the owner of the window is granted a right to it. The owner of the courtyard may not build a structure opposite it or at its side unless he moves four cubits away, so that he does not cast a shadow against it, for he granted him the right to the light."

Flow Model

Let's visualize the decision-making process for a CourtyardOwner (N2) attempting to build a Wall (W_new) opposite a Window (W_existing) owned by a WindowOwner (N1). This is a state machine for property development!

START: N2 wants to build W_new opposite N1's W_existing.

1.  Is W_existing a *new* window (N1 is attempting to open it now)?
    *   **IF YES (W_existing.status == NEW):**
        *   N2 *may prevent* N1 from opening W_existing (Neighbors 7:4).
        *   STOP.
    *   **IF NO (W_existing.status == ESTABLISHED):**
        *   Proceed to Step 2.

2.  How was W_existing established? (Relevant for determining *scope* of established right).
    *   **CASE A: W_existing existed *before* N2's courtyard.** (Neighbors 7:1)
        *   N1 has an established right to maintain W_existing.
        *   Proceed to Step 3.
    *   **CASE B: N2 *waived* the right to protest (explicitly or by silence) when W_existing was opened.** (Neighbors 7:5)
        *   N1 has an established right to maintain W_existing.
        *   Proceed to Step 3.

3.  What are the *characteristics* of W_existing and the *impact* of W_new? (Determines N2's building constraints).

    *   **SUB-FLOW 3.1: Building a wall *opposite* W_existing (standard scenario).** (Neighbors 7:1, 7:2, 7:5, 7:6)

        *   **Check W_existing properties:** Is W_existing "large enough for a person to insert his head" OR "less than four cubits high"? (Neighbors 7:5)
            *   **IF YES (Default established window type, e.g., large OR low):**
                *   N2 *must* build W_new at least `4 cubits` away from W_existing.
                    *   **Reasoning:** To prevent `shadow_damage` (loss of light for N1) (Neighbors 7:1, Steinsaltz 7:1:3, 7:2:1).
                *   **Further Check:** Is W_existing "low in the wall"? (Neighbors 7:2)
                    *   **IF YES:** N2 *must* also build W_new at least `4 cubits high` (above the top of W_existing).
                        *   **Reasoning:** To prevent `privacy_invasion_damage` (N2 looking *into* N1's window) (Neighbors 7:2, Steinsaltz 7:2:2).
                    *   **IF NO (W_existing is high):** The `4 cubits high` rule does not apply here (only the 4 cubits distance for light).
            *   **IF NO (W_existing is "too small for head" AND "more than four cubits high"):** (Neighbors 7:6)
                *   **Check W_existing.purpose:** Was W_existing opened *for light*? (Neighbors 7:6)
                    *   **IF YES (W_existing.purpose == LIGHT):**
                        *   N2 *must* build W_new at least `4 cubits` away from W_existing.
                        *   **Reasoning:** N2's waiver implied granting the right to light, so `shadow_damage` is prevented.
                    *   **IF NO (W_existing.purpose == USE_OR_AIR):**
                        *   N2 *may* build W_new directly opposite W_existing (no `4-cubit_distance` required).
                        *   **Reasoning:** N2's waiver was for a limited purpose (small, high, not for light), not to restrict his own building close by.

    *   **SUB-FLOW 3.2: Building a wall *below* a *high* W_existing.** (Neighbors 7:3)
        *   **Check vertical distance:** Is there "more than four cubits from the top of the [new] wall to the [bottom of the] window"?
            *   **IF YES:**
                *   N2 *may* build W_new directly opposite W_existing (no separation required).
                *   **Reasoning:** No `shadow_damage` and no `privacy_invasion_damage` from N2 looking in.
            *   **IF NO ("less than four cubits between the top of the wall and the window"):**
                *   N1 may force N2 to choose one of two options:
                    *   **Option 1:** Lower W_new (so N2 cannot stand on it and look in).
                    *   **Option 2:** Build W_new `4 cubits` away from W_existing AND build it `more than 4 cubits higher` than W_existing.
                    *   **Reasoning:** To prevent potential `privacy_invasion_damage` and ensure `light_access`.

END: System returns permissible building parameters for W_new.

Two Implementations

Let's model the core logic for handling established windows when a courtyard owner wants to build a wall. We'll present two "algorithms" based on Maimonides' text, highlighting a general case versus a specific, highly contextual exception.

Algorithm A: DefaultEstablishedWindowHandler

This algorithm represents the general processing for established windows, prioritizing the window owner's rights to light and privacy from the courtyard owner. This is the "safe mode" for property development.

Core Principle: Once a window is ESTABLISHED (either by prior existence or explicit/implicit consent), it generally carries a robust set of protections, particularly regarding light access and the window owner's privacy from being looked into. The default state for new construction by the courtyard owner is to maintain a 4_CUBIT_CLEARANCE to prevent SHADOW_DAMAGE.

Pseudocode:

class Window:
    def __init__(self, id, height_from_ground, is_large_enough_for_head, purpose, status="ESTABLISHED"):
        self.id = id
        self.height_from_ground = height_from_ground # Low if < 4 cubits from ground, High otherwise
        self.is_large_enough_for_head = is_large_enough_for_head
        self.purpose = purpose # Enum: LIGHT, AIR, USE, VIEW
        self.status = status # Enum: NEW, ESTABLISHED

class Wall:
    def __init__(self, id, desired_location, desired_height):
        self.id = id
        self.desired_location = desired_location # Relative to window
        self.desired_height = desired_height

def DefaultEstablishedWindowHandler(window: Window, new_wall: Wall) -> dict:
    """
    Determines building constraints for a new wall opposite an established window.
    This is Algorithm A, the general case for protecting established window rights.
    Applies to windows that are "large enough for a person to insert his head"
    OR "less than four cubits high" (Neighbors 7:5), or any window for light (Neighbors 7:6).
    """

    if window.status == "NEW":
        # This handler assumes established windows. New windows handled by a prior check (Neighbors 7:4)
        return {"error": "Window not established. Courtyard owner may prevent opening."}

    # Initialize default constraints
    required_distance_from_window = 0 # Default: can build adjacent
    required_height_above_window = 0  # Default: no extra height required
    can_build_directly_opposite = True

    # Rule 1: General protection against shadow damage (Neighbors 7:1, 7:5, 7:6 for LIGHT purpose)
    # Most established windows require 4 cubits distance to prevent shadow.
    # This applies to:
    #   - Windows large enough for a head OR low (7:5)
    #   - Any window, even small/high, if established for LIGHT (7:6)
    if window.is_large_enough_for_head or \
       window.height_from_ground < 4 or \
       window.purpose == Window.purpose.LIGHT:
        required_distance_from_window = 4
        can_build_directly_opposite = False
        # Steinsaltz 7:1:3, 7:2:1: "So that it will not hide the light from the owner of the window."

    # Rule 2: Protection against privacy invasion INTO a low window (Neighbors 7:2)
    # If the window is low, the wall must also be high enough to prevent looking in.
    if window.height_from_ground < 4: # "low in the wall"
        required_height_above_window = 4 # Must be 4 cubits HIGHER than window top
        # Steinsaltz 7:2:2: "so that the owner of the courtyard will not be able to look through his colleague's window and damage him with his sight."

    # Rule 3: Protection for high windows from walls built BELOW (Neighbors 7:3)
    # This is a specific vertical constraint.
    # If N2 is building a wall *below* a high window (window.height_from_ground >= 4)
    # And the wall's top is less than 4 cubits below the window, N1 can force changes.
    if window.height_from_ground >= 4 and \
       new_wall.desired_location == "BELOW_WINDOW" and \
       (window.height_from_ground - new_wall.desired_height) < 4:
        # If the gap between wall top and window bottom is < 4 cubits,
        # it implies risk of N2 climbing or privacy breach.
        can_build_directly_opposite = False # Cannot build directly under with this height
        # Options for N2: Lower wall, or build 4 cubits away and 4 cubits higher than window.
        # This is complex; for simplicity here, we flag it as not directly buildable at that height/distance.
        return {
            "can_build": False,
            "reason": "Wall built below high window too close. Must lower wall OR build 4 cubits away AND 4 cubits higher than window.",
            "enforced_options": [
                "LOWER_WALL",
                "BUILD_4_CUBITS_AWAY_AND_4_CUBITS_HIGHER_THAN_WINDOW"
            ]
        }

    return {
        "can_build": can_build_directly_opposite,
        "required_distance_from_window": required_distance_from_window,
        "required_height_above_window": required_height_above_window,
        "notes": "Rules applied based on general established window protections for light and privacy."
    }

Algorithm B: LimitedScopeWindowHandler

This algorithm represents a critical exception to the general DefaultEstablishedWindowHandler. It applies to very specific types of ESTABLISHED windows where the initial chazakah was granted under limited, implicit conditions. This is a "conditional override" in our system.

Core Principle: While chazakah is generally powerful, its scope can be constrained by the inherent characteristics and known purpose of the object that established the right. If a window is "small and high" (not easily used for looking in or out, and not primarily for light), the initial non-protest by the courtyard owner might be interpreted as a limited waiver, not a full relinquishing of building rights close to the boundary.

Pseudocode:

def LimitedScopeWindowHandler(window: Window, new_wall: Wall) -> dict:
    """
    Determines building constraints for a new wall opposite an established window
    under specific, limited-scope conditions.
    This is Algorithm B, a specialized handler for a subset of established windows.
    Applies ONLY to windows that are "too small for the head of a person to be inserted"
    AND "more than four cubits high" AND "opened to be used or to allow air to enter"
    (i.e., NOT for light). (Neighbors 7:6)
    """

    if window.status == "NEW":
        return {"error": "Window not established. Courtyard owner may prevent opening."}

    # This handler is ONLY for very specific window types as per Neighbors 7:6.
    # It acts as a specialized filter. If conditions not met, defer to DefaultEstablishedWindowHandler.
    if not (not window.is_large_enough_for_head and \
            window.height_from_ground >= 4 and \
            window.purpose in [Window.purpose.AIR, Window.purpose.USE]):
        return {"defer_to_default_handler": True, "reason": "Window does not meet limited scope criteria."}

    # If all specific conditions for a limited scope window are met (small, high, not for light):
    required_distance_from_window = 0 # No 4 cubit distance required
    can_build_directly_opposite = True

    # Neighbors 7:6: "the owner of the courtyard may build a wall opposite it or at its sides.
    # For he can claim: 'I allowed you to open the window only because it is small and high,
    # but it was not my intent to give you a right that would require me to move away my building.'"

    return {
        "can_build": can_build_directly_opposite,
        "required_distance_from_window": required_distance_from_window,
        "required_height_above_window": 0, # No special height requirements for this type
        "notes": "Rules applied based on limited scope of consent for small, high windows not for light."
    }

Comparative Analysis: Algorithm A vs. B

The brilliance of Maimonides' system design here is the layered approach to chazakah.

• Algorithm A (DefaultEstablishedWindowHandler) is the robust, general-purpose method. It assumes that an established window, by default, carries significant protections. Its primary triggers are the prevention of SHADOW_DAMAGE (light obstruction) and PRIVACY_INVASION_DAMAGE (being looked into). The 4_CUBIT_CLEARANCE is the standard "buffer zone" to ensure these damages are mitigated. This algorithm reflects a strong bias towards preserving existing conditions and preventing harm. It's like a baseline security policy: if you have an established resource, we assume it needs maximum protection unless proven otherwise.

• Algorithm B (LimitedScopeWindowHandler) acts as a specialized filter or an "exception handler." It demonstrates that chazakah is not a monolithic boolean TRUE/FALSE flag. Instead, it's a CHAZAKAH_OBJECT with properties, and its SCOPE can be dynamic. For a window to fall under Algorithm B, it must meet stringent criteria: NOT_LARGE_ENOUGH_FOR_HEAD AND HIGH AND PURPOSE_IS_AIR_OR_USE (crucially, NOT_LIGHT). This suggests that the initial implicit_consent (lack of protest) from the courtyard owner was conditional. The system infers that the courtyard owner's silence was not a blanket waiver but a specific, limited allowance based on the minimal impact of such a window. It's like granting read-only access to a file, not full admin privileges.

The data flow would typically involve a Router function that first checks if LimitedScopeWindowHandler applies. If it does, that specialized handler executes. If not, the request falls back to DefaultEstablishedWindowHandler. This hierarchical processing ensures that the most specific, contextual rules are applied first, optimizing for nuanced justice while maintaining a general protective framework.

This distinction is crucial for understanding how the Halakha manages the complexities of shared resources. It doesn't just ask "Is there chazakah?" but "What kind of chazakah is it, and what is its scope and purpose?" This makes the system incredibly resilient and adaptable to a wide range of real-world scenarios, avoiding both overly rigid rules and vague, unenforceable principles.

Edge Cases

Our halakhic operating system, like any well-designed system, must account for edge cases that might expose vulnerabilities in a purely linear or naive interpretation of its rules. Let's test two such scenarios.

Edge Case 1: The "Ephemeral Footing" for a Sukkah

Scenario: Reuven builds a temporary sukkah in Shimon's courtyard (or inserts a beam into Shimon's wall for it) without Shimon's explicit permission. Shimon sees it but, being a good neighbor and knowing it's just for a week-long holiday, doesn't protest. After the holiday, Reuven decides he likes the sukkah's location and wants to make it permanent, claiming chazakah because Shimon didn't protest.

Naïve Logic: "Silence equals consent, and consent establishes chazakah. Shimon didn't protest, so Reuven has an established right." (Based on a superficial reading of Neighbors 7:5, "he knew about this source of damage and did not protest - the owner of the window has established his right").

Expected Output (based on Neighbors 8:3): Reuven does not establish a permanent right to maintain the sukkah or the beam. Shimon can force him to remove it.

Explanation: Maimonides introduces a crucial temporal and contextual qualifier for chazakah established by silence.

• Neighbors 8:3 (on beams for a Sukkah): "If the beam was part of a temporary sukkah, he does not establish the right to maintain it for 30 days. For Reuven will say: 'I did not waive my right to protest. I allowed it merely because it was temporary.' If the owner of the beam maintains the sukkah for 30 days, he establishes his right to it, for that is no longer considered temporary."
• Neighbors 8:3 (on Sukkah for the holiday): "Different rules apply if he constructed a sukkah for the holiday. Within all the seven days of the holiday, he does not establish his right to maintain it. After the seven days are completed, he does establish his right."

The system implicitly categorizes actions into TEMPORARY and PERMANENT states. Silence regarding a TEMPORARY action does not automatically transition it to PERMANENT with chazakah. The window of opportunity for implicit_consent for a permanent right only opens after a TEMPORARY status expires (e.g., 30 days for a general temporary structure, or after the 7 days of Sukkot). Shimon's silence was scoped to the temporary nature of the sukkah; it was not a waiver of his right to protest a permanent encroachment. This prevents a TEMPORARY_RESOURCE_LOCK from becoming a PERMANENT_RESOURCE_ALLOCATION without explicit or prolonged implicit consent.

Edge Case 2: The "Beneficial Nuisance" (Kofin al Midat Sodom)

Scenario: Reuven has windows on the lower portion of his wall. Shimon, his neighbor, wants to erect a new building that would completely block these windows, thus causing SHADOW_DAMAGE and AIR_FLOW_DAMAGE. Shimon offers to tear down Reuven's entire wall, rebuild it for him with new, higher-up windows (thus no longer blocked), and even rent Reuven a temporary home during construction. Reuven, despite suffering no actual loss (and potentially gaining new windows), refuses, saying, "I just don't want the trouble of moving."

Naïve Logic: "Reuven has an established right to his windows (Neighbors 7:1). Shimon's construction would violate this right. Therefore, Reuven can prevent Shimon from building." The system should protect Reuven's established right regardless of Shimon's offer.

Expected Output (based on Neighbors 8:12): Reuven cannot prevent Shimon from performing this construction. The court will compel Reuven to allow Shimon to close the lower windows and build new ones higher up.

Explanation: Maimonides introduces the powerful principle of KOFIN_AL_MIDAT_SODOM (compelling against the traits of Sodom).

• Neighbors 8:12: "Therefore, if there is no difficulty involved at all, and it is not necessary for him to leave his home, he cannot prevent him from performing this construction. We compel him to allow his friend to close the window below and build a new window for him higher up. Not to allow this would be following the traits of Sodom. Similarly, whenever there is a situation where one person will benefit and his colleague will not lose nor be lacking anything, we compel that person to cooperate."

This rule acts as a "fairness override" or an OPTIMIZATION_FOR_COLLECTIVE_UTILITY function. If a proposed change offers a clear benefit to one party (Shimon_Benefits_Flag = TRUE) and causes absolutely no loss or detriment to the other party (Reuven_NoLoss_Flag = TRUE), then the system compels cooperation. Reuven's refusal, based solely on inconvenience or obstinacy, is deemed "Sodomite behavior" – a refusal to allow a benefit to another when it costs you nothing. This prevents a deadlock caused by arbitrary individual preference when the system can achieve a win-win or a win-no-loss state. It's a fundamental principle for promoting communal harmony and efficient resource utilization, even overriding established rights in specific circumstances where the "damage" is fully mitigated.

Refactor

The current structure of chazakah (established right) in the text, while robust, can feel somewhat distributed and implicitly defined. We see chazakah being established by:

1. Prior existence (Neighbors 7:1 for a window preceding a courtyard).
2. Explicit waiver/consent (Neighbors 7:5).
3. Silence/lack of protest (Neighbors 7:5 for windows, 8:1 for projections, 8:4 for drainpipes, 8:7 for beams).

However, the scope and permanence of this chazakah vary wildly based on the type of object (window, ladder, sukkah), its characteristics (size, height, purpose), and the context of its establishment. This leads to the edge cases we just explored, where a simple "silence = chazakah" rule would break.

The Bug: The current establish_chazakah function (conceptual) is overloaded and implicitly relies on external context for its return value's properties. For instance, establish_chazakah(window_A, no_protest) might yield a full Chazakah_Object with 4_CUBIT_PROTECTION, while establish_chazakah(window_B, no_protest) (where window_B is small/high/not for light) yields a Chazakah_Object with NO_4_CUBIT_PROTECTION. Similarly, establish_chazakah(sukkah_beam, no_protest) yields NO_PERMANENT_CHAZAKAH. This implicit context dependence makes the rule engine harder to debug and predict.

Refactor: Introduce a ChazakahContext Object and a ChazakahScopeEvaluator function.

Instead of chazakah being a simple boolean or an implicitly defined state, we should treat it as a rich data object, and its properties should be explicitly derived from a ChazakahContext.

Minimal Change Proposed: Add a context_data parameter to the establish_chazakah function, and a ChazakahScopeEvaluator module.

# Old (conceptual):
# function establish_chazakah(action_object, owner_protested_bool) -> bool/simple_Chazakah_Object

# New (refactored minimal change):
class ChazakahContext:
    def __init__(self, action_type, object_properties, time_elapsed, owner_actions):
        self.action_type = action_type # e.g., "WINDOW_OPENING", "BEAM_INSERTION", "LADDER_PLACEMENT"
        self.object_properties = object_properties # e.g., {"size": "small", "height": "high", "purpose": "air"}
        self.time_elapsed = time_elapsed # e.g., "7_DAYS", "30_DAYS", "INSTANT"
        self.owner_actions = owner_actions # e.g., {"protested": False, "helped_construct": True}

class ChazakahResult:
    def __init__(self, is_established, scope_of_right, permanence):
        self.is_established = is_established # Boolean
        self.scope_of_right = scope_of_right # Enum: FULL_PROTECTION, LIMITED_PROTECTION (e.g., no 4-cubit rule), NO_SPECIFIC_PROTECTION
        self.permanence = permanence # Enum: PERMANENT, TEMPORARY_PENDING_PROTEST, NONE

def ChazakahScopeEvaluator(context: ChazakahContext) -> ChazakahResult:
    """
    Evaluates the scope and permanence of chazakah based on detailed context.
    This function consolidates the nuanced rules across Neighbors 7-9.
    """
    # Rule: Initial protest always prevents chazakah (Neighbors 7:4)
    if context.owner_actions["protested"]:
        return ChazakahResult(False, "NONE", "NONE")

    # Rule: Explicit consent always grants full chazakah (Neighbors 7:5)
    if context.owner_actions["helped_construct"]:
        return ChazakahResult(True, "FULL_PROTECTION", "PERMANENT")

    # Rule: Prior existence (Neighbors 7:1)
    if context.action_type == "WINDOW_EXISTS_PRE_COURTYARD":
        return ChazakahResult(True, "FULL_PROTECTION", "PERMANENT")

    # Rule: Silence as establishment (default)
    if context.owner_actions["protested"] == False:
        # Check for temporary actions (Edge Case 1: Sukkah, Small Ladder)
        if context.action_type == "BEAM_INSERTION" and context.object_properties.get("is_sukkah_beam"):
            if context.time_elapsed < 30: # or during 7 days of holiday sukkah
                return ChazakahResult(False, "NO_SPECIFIC_PROTECTION", "TEMPORARY_PENDING_PROTEST")
            else: # After 30 days, silence now establishes permanent right
                return ChazakahResult(True, "FULL_PROTECTION", "PERMANENT")

        if context.action_type == "LADDER_PLACEMENT" and context.object_properties.get("rungs") < 4:
            return ChazakahResult(False, "NO_SPECIFIC_PROTECTION", "TEMPORARY_PENDING_PROTEST")

        # Check for limited scope windows (Algorithm B: Neighbors 7:6)
        if context.action_type == "WINDOW_OPENING" and \
           context.object_properties.get("size") == "small" and \
           context.object_properties.get("height") == "high" and \
           context.object_properties.get("purpose") != "light":
            return ChazakahResult(True, "LIMITED_PROTECTION", "PERMANENT")

        # Default for silence on other actions: Full Chazakah
        return ChazakahResult(True, "FULL_PROTECTION", "PERMANENT")

# Main function utilizing the refactored logic
def get_building_rules(window: Window, new_wall: Wall, owner_actions_history: dict) -> dict:
    context = ChazakahContext(
        action_type="WINDOW_OPENING" if window.status == "NEW" else "WINDOW_EXISTS_PRE_COURTYARD", # Simplistic for demo
        object_properties={"size": "large" if window.is_large_enough_for_head else "small",
                           "height": "low" if window.height_from_ground < 4 else "high",
                           "purpose": window.purpose},
        time_elapsed=None, # Not directly used for window establishment in this context, but relevant for other chazakot
        owner_actions=owner_actions_history # e.g., {"protested": False, "helped_construct": True}
    )
    chazakah_state = ChazakahScopeEvaluator(context)

    if not chazakah_state.is_established:
        return {"can_build": False, "reason": "No established right for window. Courtyard owner can prevent."}
    
    # Now, based on chazakah_state.scope_of_right, call Algorithm A or B
    if chazakah_state.scope_of_right == "LIMITED_PROTECTION":
        return LimitedScopeWindowHandler(window, new_wall)
    elif chazakah_state.scope_of_right == "FULL_PROTECTION":
        return DefaultEstablishedWindowHandler(window, new_wall)
    else: # e.g., for temporary chazakah that isn't established as permanent
        return {"can_build": False, "reason": "Chazakah not established or expired."}

This refactor clarifies the system by making the determination of chazakah's nature (its scope and permanence) an explicit, centralized process. Instead of needing to re-evaluate the object's characteristics and historical context at every decision point, we now have a ChazakahResult object that encapsulates all the necessary information. This promotes modularity, reduces redundancy, and makes the system's behavior more predictable and auditable. It's like having a dedicated PermissionService that returns a PermissionToken with granular details, rather than scattering permission checks throughout the application logic.

Takeaway

What a deep dive into the algorithmic wisdom embedded in Hilchot Sh'chenim! Maimonides presents not just a collection of rules, but a sophisticated, context-aware system for managing shared resources and resolving interpersonal conflicts. We've seen how:

1. Time is a State Variable: The chronological order of events (window before courtyard) and the duration of inaction (30 days for a sukkah) are critical inputs that modify property rights, establishing or denying chazakah.
2. Context is King: The specific characteristics of an object (window's size, height, purpose) and the implied intent behind inaction (silence regarding a temporary object vs. a permanent one) profoundly influence the scope of established rights. Chazakah is not a binary, but a multi-faceted data structure.
3. Damage Mitigation is Parametric: The system specifies precise spatial offsets (4 cubits, 3 handbreadths) and structural modifications (wall height) to mitigate various forms of "damage" – hezek re'iyah (privacy invasion), hezek ohr (light obstruction), hezek guf (physical damage like heat or vibration). These are like configurable parameters in a robust system.
4. Moral Overrides Exist: The KOFIN_AL_MIDAT_SODOM principle acts as a "compulsory cooperation" override, demonstrating that individual autonomy is balanced against the greater good of preventing "Sodomite" behavior, ensuring that resources are utilized efficiently and harmoniously where no party truly loses.

Far from being archaic, these laws reveal a highly evolved legal operating system, designed to maximize fairness, prevent exploitation, and foster communal well-being, all while handling complex, dynamic interactions between property owners. It's truly a marvel of ancient systems thinking, still running perfectly on the human network today!