11 — Extension Formalism: The Estate Flow Tree

11 — Extension Formalism: The Estate Flow Tree

Core claim: All three extensions (Munāsakhat, Mafqūd, Dhawī al-Arḥām) are instantiations of a single mathematical structure — a weighted rooted tree over $\mathbb{Q}$ — differing only in how the tree is constructed and how leaf values are aggregated. The classical pen-and-paper algorithms (jāmiʿa, shabak, four-ratio comparison) are integer-normalization strategies for evaluating this tree without decimals.

---

---

4.1 Re-expression of Heirs Relative to a Sub-Deceased (Munāsakhat re-expression)

When a deceased $d$ inside a Chain (Munāsakhat) problem produces a sub-problem, the heir set passed to the core pipeline $F$ for that sub-problem must be the original persons re-expressed relative to $d$. In other words: the 5-tuple that identifies an heir is relative to who died; the same physical person has a different tuple when considered with respect to a different deceased.

This section gives a concise, deterministic formula for that re-expression so implementations need not perform ad‑hoc translations in tests or in callers.

Definitions

• Let $d$ be the sub-deceased whose sub-problem we must solve.
• Let $p$ be a physical person who appears in the original heir set (of the root) and may or may not be an heir of $d$.
• Let the BFS path between $p$ and $d$ (considering parent/child edges) be used as the canonical relation extractor. The path direction is taken from $p$ → … → $d$ (or equivalently from $d$ → … → $p$ when computing up/down steps).

Core rewrite rules (algorithmic)

• g (gender) is copied from the person node — it never changes.
• If there is no biological or marital path between p and d, then p is excluded from $H^{(d)}$ (do not pass as a zero share; drop the person).
• Otherwise compute the path-derived tuple (g, j', d', q', c') as follows (apply the standard path→5-tuple derivation from findings/01-5tuple-and-graph.md, but with d as the reference point):
  • j' (Jiha):
    • 0 if p is spouse of d.
    • 1 if p is a descendant of d (no upward steps from d to reach the pivot).
    • 2 if p is an ascendant of d (no downward steps from d to reach the pivot).
    • 3 if the path goes up 1 generation from d to the pivot then down to p (collateral sibling axis).
    • 4 if the path goes up ≥2 generations from d to the pivot then down to p (uncle/older collateral axis).
  • d' (degree): number of generations between d and p according to the role above (0 for spouse; downward steps for descendants/collaterals; upward steps for ascendants).
  • q' (Quwwa): 9 for direct ancestor/descendant/spouse; otherwise determined by whether the pivot connection from d to p traverses both parents (full, 1), father only (2), or mother only (3).
  • c' (chain-validity): recompute eligibility from the new path sequence (grandmother rule and female-intermediary rules apply). Do not copy c from the original tuple.

Aggregation rule

• After mapping all persons p to tuples relative to d, merge identical tuples by summing their count (or multiplicity). Implementations must not keep duplicate entries for the same logical tuple — this breaks gcd/lcm-based normalization and conservation checks.

Invariants to preserve (for implementers)

• Exclusion: non-related persons are dropped, not passed as zero-share entries.
• Aggregation: identical (g,j',d',q',c') tuples are merged with count += before calling F.
• Purity: re-expression is pure and deterministic (function of the kinship graph only).
• Recompute c': eligibility must be decided from the d-relative path (grandmother/female-intermediary patterns).
• Conservation check: after solving F(H^{(d)}), the sub-problem must satisfy $\sum \text{sahm} = $ sub-base; this is a sanity assertion before merging into the jāmiʿa.

Concrete examples (short)

• Sub R1 (MS dies): persons unrelated to MS are excluded; a FullSis relative to the original deceased may become q'=3 (maternal) relative to MS; maternal grandmother becomes j'=2,d'=1 relative to MS.
• Sub R2 (PS1 dies): relatives on the maternal side of the original deceased that are not connected to PS1 are excluded; a FullSis may become q'=2 (paternal) relative to PS1.
• Sub R3 (PG dies): descendants of PG who were siblings of the original deceased become descendants (j'=1) of PG with increased d' (commonly d'=2) and should be merged (counts aggregated) if they map to the same tuple.

These rules are direct formalizations of the prose in faraid/munasakhat.md and the estate-flow tree in findings/11-extension-formalism.md §3; they are the source-of-truth mapping that tests and the chain extension must use.

---

5. Extension 2: Min-Envelope (Mafqūd) — Fully Specified

Let $F$ denote the core 6-phase pipeline:

$$F: \mathcal{H} \to (\mathbb{Z}^+,; \mathbb{Z}_{\ge 0}^{|H|})$$

$$F(H) = (B, \vec{s}) \quad \text{where } B = \text{muṣaḥḥaḥ},; \sum_i s_i = B$$

In $\mathbb{Q}$, each heir $h$ receives fraction $\phi_h = s_h / B$.

$F$ is a pure function (stateless, deterministic). This is what makes the extensions composable.

---

2. The Estate Flow Tree

Definition. An estate flow tree $T = (V, E, \omega)$ is a rooted tree where:

Component	Meaning
Root $r$	The original deceased
Internal node $v$	A deceased heir (died before distribution)
Leaf $\ell$	A living heir at the time of distribution
Edge $(v, w)$	$w$ is an heir of $v$
Weight $\omega_{v \to w} \in \mathbb{Q}^+$	The fraction of $v$‘s sub-estate flowing to $w$, computed by $F$

Each internal node $v$ has an associated problem $P_v = F(H_v)$ with base $B_v$ and shares $\vec{s}_v$. The edge weight is:

$$\omega_{v \to w} = \frac{s_v(w)}{B_v}$$

Share Formula (Theorem 1). For any living heir $\ell$, their share of the original estate is:

$$\boxed{\phi(\ell) = \sum_{\pi ,:, r \leadsto \ell} ;\prod_{(v,w) \in \pi} \omega_{v \to w}}$$

where the sum ranges over all root-to-$\ell$ paths. In a tree, each leaf has exactly one path; but a person may appear as a leaf in multiple branches (inheriting from multiple deceased), so the sum collapses to addition of products.

Proof sketch. By induction on tree depth. Base case (depth 1): a single $F$-call, $\phi(\ell) = s_r(\ell) / B_r = \omega_{r \to \ell}$. Inductive step: if deceased $d$ at depth $k$ has share $\phi(d)$ from the root, then their heir $h$ at depth $k+1$ receives $\phi(d) \cdot \omega_{d \to h}$, which is the product along the extended path. $\square$

Verification. Conservation: $\sum_{\ell \in \text{leaves}} \phi(\ell) = 1$ (since each internal node’s children’s weights sum to 1 by $F$‘s conservation axiom $\gamma$, and induction gives the result).

This is the formula. The entire Munāsakhat chapter — 80+ pages of tables and cases — is an integer-arithmetic algorithm for evaluating $\phi(\ell)$ without decimals.

---

3. Integer Normalization: The Jāmiʿa

3.1 The Problem

Each $\phi(\ell)$ is a product of fractions. To express all shares as integers from a single base (the jāmiʿa $J$), we need:

$$J \cdot \phi(\ell) \in \mathbb{Z}^+ \quad \forall \ell$$

3.2 The Classical Algorithm

The source text (faraid/munasakhat.md) describes an incremental algorithm. Restated in modern terms:

Algorithm: Incremental Jāmiʿa

Input: Tree T with root r, pipeline F
Output: (J, {(ℓ, sahm_ℓ)} for all leaves ℓ)

1. Solve F(H_r) → (B_r, s_r). Set J ← B_r.
   For each heir h of r: result[h] ← s_r(h).

2. Process deceased heirs in BFS order.
   For each deceased d with share result[d] in current J:
     a. Solve F(H_d) → (B_d, s_d).
     b. Let g ← gcd(result[d], B_d).
     c. Let scale ← B_d / g.        // juz' al-sahm for the current table
     d. J ← J × scale.               // new jāmiʿa
     e. For all h ≠ d in result: result[h] ← result[h] × scale.
     f. Let multiplier ← result[d] / B_d.   // = (result[d] × scale) / (B_d × scale) ... simplified
        Actually: multiplier = result[d] * scale / B_d
                            = (old_result[d] * scale) / B_d
                            = (old_result[d] * B_d/g) / B_d
                            = old_result[d] / g.
     g. result[d] ← 0.               // deceased is removed
     h. For each heir h of d:
          result[h] ← result[h] + s_d(h) × multiplier.
          // (result[h] may already have a value if h appears in an earlier problem)

3. Return (J, result).

Complexity: Each merge step is $O(|H_d|)$. Total: $O(\sum_v |H_v|)$ — linear in the total number of heir-slots across all problems.

3.3 Relationship to LCM

The incremental algorithm computes $J$ such that $J$ is the smallest integer for which all path-products become integers. This is equivalent to:

$$J = B_r \cdot \prod_{d \in \text{internal}(T) \setminus {r}} \frac{B_d}{\gcd!\left(\text{sahm}_d^{(\text{pre-scale})},, B_d\right)}$$

where $\text{sahm}_d^{(\text{pre-scale})}$ is $d$‘s share in the jāmiʿa before processing $d$‘s sub-tree. The classical four-ratio comparison (tamāthul, tadākhul, tawāfuq, tabāyun) is simply the case analysis of $\gcd(s, B)$:

Arabic term	Condition	$\gcd(s, B)$	Scale factor
Tamāthul (تماثل)	$s = B$	$s$	$1$
Tadākhul (تداخل)	$B \mid s$	$B$	$1$
Tawāfuq (توافق)	$1 < \gcd < \min$	$g$	$B/g$
Tabāyun (تباين)	$\gcd = 1$	$1$	$B$

3.4 The Three Classical Cases of Munāsakhat

The source text (faraid/munasakhat.md) identifies three cases. These map to tree structure:

Classical case	الحالة	Tree structure	Algorithm shortcut
Case 1 (اختصار المسائل)	Heirs of deceased₂ = survivors of deceased₁ with same relationships	Tree collapses to a single node (re-root at survivors)	One $F$-call on survivors only
Case 2 (اختصار الجوامع)	All deceased are children of root; heir sets are disjoint	Star graph (root + independent sub-trees)	Single jāmiʿa for all sub-problems
Case 3 (الحالة العامة)	Overlapping heir sets, heirs appearing in multiple problems	General tree	Sequential jāmiʿa layering

Case 3 is the general algorithm above. Cases 1 and 2 are optimizations that the source text provides to avoid unnecessary work — but a correct implementation of Case 3 handles all three.

---

4. Extension 1: Chain (Munāsakhat) — Fully Specified

Input: An ordered sequence of deaths: $[(d_1, H_1), (d_2, H_2), \ldots, (d_n, H_n)]$ where $d_1$ is the original deceased, $H_i$ is $d_i$‘s heir set, and $d_i$ (for $i \ge 2$) was an heir of some previous deceased.

Construction: Build the estate flow tree $T$ by:

1. Create root $r = d_1$ with children = $H_1$.
2. For each subsequent deceased $d_i$: find $d_i$ in $T$ (currently a leaf), convert to internal node, attach $H_i$ as children.

Evaluation: Apply the incremental jāmiʿa algorithm (§3.2).

Formula in $\mathbb{Q}$: For each living heir $\ell$:

$$\phi(\ell) = \sum_{i : \ell \in H_i} \left(\prod_{k=1}^{i} \omega_{d_{p(k)} \to d_k}\right) \cdot \omega_{d_i \to \ell}$$

where $d_{p(k)}$ is the parent of $d_k$ in $T$, and the product traces the path from root to $d_i$‘s problem.

Simplification: If $\ell$ appears in only one problem (the common case), this reduces to a single product:

$$\phi(\ell) = \prod_{(v,w) \in \text{path}(r, \ell)} \omega_{v \to w}$$

If $\ell$ appears in multiple problems (they inherit from multiple deceased), we sum the products.

Edge cases:

• Case 1 shortcut: Before constructing the tree, check if $H_2 \setminus {d_2} \subseteq H_1 \setminus {d_2}$ with identical relationships. If so, collapse: just solve $F(H_1 \setminus {d_2})$.
• Reduction after computation: The source text describes اختصار السهام — dividing the jāmiʿa and all shares by their GCD. This is a post-processing step: $J’ = J / \gcd(J, s_1, s_2, \ldots)$.

---

4.2 Extension 1b: Chain Forest (Gharqā Ḥanbalī) — Fully Specified

When: A group of mutual heirs $D = {d_1, \ldots, d_n}$ die in an accident or unknown-order event (Gharqā / Hadmā / analogous cases). The Ḥanbalī school allows mutual inheritance under two conditions:

1. Each inherits only from the other’s tilād (التلاد — original pre-existing wealth), not from their ṭarīf (الطريف — what they received from another co-deceased). Source: faraid/gharqa.md:80–82.
2. The heirs agree on the assumed ordering (no contradictory claims). Source: faraid/gharqa.md:82.

Why the TILD/ṬARIF rule exists: Without it, $d_i$ inherits from $d_j$, and $d_j$ inherits from $d_i$ — creating a cycle where each person inherits from themselves: «لأنه لو ورّث أحدهما الآخر من طريف ماله للزم منه الدور، وهو أن يرث الإنسان نفسه، وهو ممتنع» (faraid/gharqa.md:164–168).

Construction: Build a forest of $n$ trees, one per assumed-first deceased:

For each $k \in {1, \ldots, n}$:

1. Treat $d_k$ as “the root” (first to die).
2. Build TILD($d_k$): solve $F(H_k)$ where $H_k$ = $d_k$‘s living heirs ∪ all other co-deceased $d_l$ ($l \ne k$).
3. For each co-deceased $d_l$ receiving a share $s_{kl}$ from TILD($d_k$): build ṬARIF($d_l$): solve $F(H_l^)$ where $H_l^$ = $d_l$‘s living heirs excluding $d_k$ (the original deceased is already dead, cannot be an heir of $d_l$).
4. Merge TILD($d_k$) + ṬARIF($d_l$) using the Munāsakhat Case-2 merge primitive.

This is exactly Munāsakhat Case 2 (Ḥalāt al-Thāniyya) applied with $d_k$ as the root. Source: faraid/gharqa.md:240–244.

Share formula:

Let $E_k$ be $d_k$‘s pre-existing estate. The share of living heir $h$ from tree $T_k$ is $\phi_{T_k}(h)$ (computed by the Munāsakhat path-product formula on $T_k$). The total share:

$$\boxed{\phi(h) = \sum_{k=1}^{n} \frac{E_k}{E_{\text{total}}} \cdot \phi_{T_k}(h)}$$

Conservation proof: Each tree $T_k$ conserves its own estate by $\gamma$ (Munāsakhat conservation). Therefore:

$$\sum_h \phi(h) = \sum_{k=1}^{n} \frac{E_k}{E_{\text{total}}} \underbrace{\sum_h \phi_{T_k}(h)}{=1} = \sum{k=1}^{n} \frac{E_k}{E_{\text{total}}} = 1 ;\checkmark$$

Difference from single-root Chain: Chain (§4) assumes a canonical temporal ordering of deaths. Chain Forest has no global ordering — each tree $T_k$ assigns $d_k$ as root and treats all other co-deceased as “survived the root” within that tree. The TILD/ṬARIF rule severs back-edges to prevent circular inheritance across trees.

Jumhūr alternative (Ḥanafī, Mālikī, Shāfiʿī): No mutual inheritance. Each estate is divided by a single $F$-call with co-deceased excluded: $\phi_{T_k}(h) = F(H_k^{\text{living only}})(h)$. This requires no merge — just $n$ independent core calls. Source: faraid/gharqa.md:232–236.

Complexity: $O(n)$ $F$-calls (one TILD + one ṬARIF per co-deceased pair). For $n$ co-deceased this is $O(n^2)$ $F$-calls in the worst case; practically $n \le 5$.

---

5. Extension 2: Min-Envelope (Generalized) — Mafqūd, Ḥaml, Khunthā

Revised scope: The original Min extension was specified for the binary {alive, dead} Mafqūd scenario. This section generalizes it to an arbitrary finite scenario set $\mathcal{S}$ with parameterized aggregation. Three source texts now ground this: faraid/mafqud.md (Mafqūd), faraid/haml.md (Ḥaml), faraid/khuntsa.md (Khunthā).

5.0 The Generalized Framework

Input: An heir set $H$ containing an uncertain entity $u$ whose properties (presence, gender, count) are unknown. A finite scenario set $\mathcal{S}$ enumerates the exhaustive (or practically exhaustive) possibilities for $u$.

For each scenario $s \in \mathcal{S}$:

• Build $H_s$: the heir set $H$ with $u$ instantiated to scenario $s$ (possibly absent, or with a specific 5-tuple).
• Solve $F(H_s) \to (B_s, \vec{s}_s)$.

Merge: Find common base $J = \text{lcm}_{s \in \mathcal{S}}(B_s)$. Scale all shares: $\hat{s}_s(h) = s_s(h) \cdot J / B_s$.

Aggregation rule $\mathcal{A}$: A function mapping the per-scenario share vectors to a final share vector:

$$\mathcal{A} : (\mathcal{S} \to \text{ShareMap}) \to \text{ShareMap}$$

Each madhhab choice corresponds to a specific $(\mathcal{S}, \mathcal{A})$ pair (see table in §5.5).

Mawqūf: $\text{mawqūf} = J - \sum_h \text{sahm}(h)$. For conservation-preserving $\mathcal{A}$ (sum, mean, single-pick), mawqūf $= 0$. For min-type $\mathcal{A}$, mawqūf $\ge 0$ represents the uncertainty premium — the “uncertainty cost” of not knowing the true scenario.

5.1 Instance: Mafqūd (Missing Person)

Source: faraid/mafqud.md.

$$\mathcal{S} = {S \subseteq M} \quad \text{($2^n$ scenarios: each subset of missing persons assumed alive)}$$

$$\mathcal{A}{\text{Mafqūd}}(h) = \min{s \in \mathcal{S}} \hat{s}_s(h) \quad \text{(component-min for all known heirs)}$$

$$\text{mawqūf} = J - \sum_{h \notin M} \mathcal{A}_{\text{Mafqūd}}(h)$$

The three classical heir categories map directly:

Category	Arabic	Condition	Share
Unaffected	لا يؤثر المفقود عليه	$\min = \max$	Full share
Dropped	يسقطه المفقود	$\min = 0$	0
Reduced	يحجبه حجب نقصان	$0 < \min < \max$	$\min$

Complexity: $O(2^n)$ $F$-calls. Practical: $n \in {1, 2}$.

5.2 Instance: Ḥaml (Unborn Heir)

Source: faraid/haml.md:431–527.

$$\mathcal{S}_{\text{Ḥaml}} = \begin{cases} {\text{stillborn, 1m, 1f, 2m, 2f, 1m+1f}} & \text{Shāfiʿī/Ḥanbalī} ; (k=6) \ {\text{1m, 1f}} & \text{Ḥanafī} ; (k=2) \end{cases}$$

Aggregation is asymmetric: known heirs get component-min; the unborn gets the maximum (set aside as mawqūf):

$$\mathcal{A}{\text{Ḥaml}}(h) = \begin{cases} \min{s \in \mathcal{S}} \hat{s}s(h) & h \ne \text{ḥaml} \quad (\text{الأضر}) \ J - \sum{h \ne \text{ḥaml}} \min_{s} \hat{s}_s(h) & h = \text{ḥaml} \quad (\text{mawqūf} = \text{الأحظ reserve}) \end{cases}$$

Three heir states (from faraid/haml.md:455–467):

1. Share constant across all scenarios → give in full.
2. Share varies → give $\min$ (الأضر).
3. Inherits in some scenarios, not others → give 0, suspend all.

Key structural note: The scenarios differ in the 5-tuple of the unborn (gender $g$, count), not merely in presence/absence. Theorem 2 (5-tuple completeness) holds within each scenario — no change to the 5-tuple encoding is needed.

Post-birth resolution (from faraid/haml.md:503–527): When the scenario $s^$ is confirmed by birth, the mawqūf is distributed: ḥaml receives $\hat{s}_{s^}(\text{ḥaml})$; known heirs receive the difference $\hat{s}_{s^*}(h) - \min_s \hat{s}_s(h)$.

5.3 Instance: Khunthā Mushkil (Ambiguous Gender)

Source: faraid/khuntsa.md:332–702.

$$\mathcal{S}_{\text{Khunthā}} = {\text{male}, \text{female}} \quad (k=2)$$

The khunthā can only appear in $j \in {1, 3, 4, 5}$ — never $j = 0$ (marriage requires definite gender) or $j = 2$ (biological ascendant status implies procreation → gender known). Source: faraid/khuntsa.md:113–129.

Four madhhab aggregation rules:

Ḥanafī — Single-pick (faraid/khuntsa.md:336–342):

$$s^* = \arg\min_{s \in \mathcal{S}} \hat{s}s(\text{khunthā})$$ $$\mathcal{A}{\text{Ḥan}}(h) = \hat{s}_{s^}(h) \quad \forall h \quad \text{(entire } s^ \text{ scenario applies)}$$

No mawqūf. Decisive but may under-compensate other heirs.

Mālikī — Component-mean (faraid/khuntsa.md:344–346, 689–702):

$$\mathcal{A}{\text{Māl}}(h) = \frac{1}{2}\left(\hat{s}{\text{male}}(h) + \hat{s}_{\text{female}}(h)\right) \quad \forall h$$

No mawqūf. Conservation holds: $\sum_h \mathcal{A}{\text{Māl}}(h) = \frac{1}{2}(\sum_h \hat{s}{\text{male}}(h) + \sum_h \hat{s}_{\text{female}}(h)) = \frac{1}{2}(J + J) = J$. ✓

Shāfiʿī — Component-min + mawqūf (faraid/khuntsa.md:348–352, 511–525):

$$\mathcal{A}{\text{Shāf}}(h) = \min\left(\hat{s}{\text{male}}(h),; \hat{s}_{\text{female}}(h)\right) \quad \forall h$$

$$\text{mawqūf} = J - \sum_h \mathcal{A}_{\text{Shāf}}(h) \ge 0$$

Identical structure to Mafqūd component-min. Heirs treated by الأضر; remainder suspended.

Ḥanbalī — Case-split (faraid/khuntsa.md:352–358):

$$\mathcal{A}{\text{Ḥan}}(h) = \begin{cases} \mathcal{A}{\text{Shāf}}(h) & \text{if khunthā is a living minor (status may clarify)} \ \mathcal{A}_{\text{Māl}}(h) & \text{if khunthā is matured or deceased (status will never clarify)} \end{cases}$$

5.4 Pseudocode (Generalized)

function scenarioExtension(
  F: Pipeline,
  H: Heir[],
  scenarios: ScenarioSpec[],           // each spec: how to instantiate H_s
  aggregation: AggregationRule,        // "component-min" | "component-mean" | "single-pick" | "asymmetric-min-max"
  knownHeirs: HeirId[],
  uncertainId: HeirId | null
): { base: number, shares: ShareMap, mawquf: number } {

  // Solve each scenario
  const results = scenarios.map(s => ({
    s,
    result: F(buildH(H, s))            // instantiate scenario then solve
  }));

  // Find common base
  const J = results.reduce((j, { result }) => lcm(j, result.base), 1);
  const scaled = results.map(({ s, result }) => ({
    s,
    shares: scaleToBase(result, J)
  }));

  // Apply aggregation rule
  const finalShares = new Map<HeirId, number>();
  for (const h of knownHeirs) {
    finalShares.set(h, aggregation.aggregate(h, scaled));
  }

  const mawquf = J - [...finalShares.values()].reduce((a, b) => a + b, 0);
  return { base: J, shares: finalShares, mawquf };
}

5.5 Summary Table

Extension	$\mathcal{S}$	$\mathcal{A}$	mawqūf	Source
Mafqūd	$2^{|M|}$ alive/dead masks	component-min	$\ge 0$	faraid/mafqud.md
Ḥaml (Jumhūr)	6 gender×count	min for known, max for ḥaml	$\ge 0$	faraid/haml.md
Ḥaml (Ḥanafī)	2 gender×count	min for known, max for ḥaml	$\ge 0$	faraid/haml.md
Khunthā Shāfiʿī	${m, f}$	component-min	$\ge 0$	faraid/khuntsa.md
Khunthā Mālikī	${m, f}$	component-mean	$= 0$	faraid/khuntsa.md
Khunthā Ḥanafī	${m, f}$	single-pick (worst for khunthā)	$= 0$	faraid/khuntsa.md
Khunthā Ḥanbalī	${m, f}$	case-split (Shāfiʿī or Mālikī)	varies	faraid/khuntsa.md

All instances reuse the same merge primitive (LCM-based jāmiʿa) from §3.

Input: An heir set $H$ containing $n$ missing persons $M = {m_1, \ldots, m_n}$.

Construction: Generate $2^n$ scenarios:

$$\mathcal{S} = {S \subseteq M} \quad \text{(each $S$ = the set of missing persons assumed alive)}$$

For each scenario $S$:

• Alive missing persons are included in $H_S$
• Dead missing persons are removed from $H_S$
• Solve $F(H_S) \to (B_S, \vec{s}_S)$

Merge: Find common base:

$$J = \text{lcm}_{S \in \mathcal{S}}(B_S)$$

Scale all shares: $\hat{s}_S(h) = s_S(h) \cdot J / B_S$.

Aggregation: For each known (non-missing) heir $h$:

$$\boxed{\text{sahm}(h) = \min_{S \in \mathcal{S}} \hat{s}_S(h)}$$

Suspended amount:

$$\text{mawqūf} = J - \sum_{h \notin M} \text{sahm}(h)$$

Resolution. When a scenario $S^*$ is confirmed (the true status of each missing person becomes known):

• Missing persons assumed alive in $S^$ receive $\hat{s}_{S^}(m) - 0 = \hat{s}_{S^*}(m)$ from the mawqūf.
• Known heirs who received less than their $S^$-share receive the difference: $\hat{s}_{S^}(h) - \text{sahm}(h)$.

Verification from source: The source text (faraid/mafqud.md) confirms exactly three heir categories:

Category	Arabic	Formula
Unaffected (same in all scenarios)	لا يؤثر المفقود عليه	$\min = \max$; give full share
Dropped (0 in some scenario)	يسقطه المفقود	$\min = 0$; give nothing
Reduced (different in scenarios)	يحجبه حجب نقصان	$0 < \min < \max$; give $\min$

Complexity: $O(2^n)$ calls to $F$. For $n > 5$ missing persons, this becomes expensive. However, the source text notes that the practical case is $n \in {1, 2}$ (rarely more).

Optimization: Many scenarios produce identical problems (e.g., if two missing persons have the same relationship to the deceased). These can be grouped.

---

6. Extension 3: Projection (Dhawī al-Arḥām) — Both Methods

6.1 Method A: Tanzīl (أهل التنزيل) — Ḥanbalī/Shāfiʿī

Insight: Tanzīl is a two-level estate flow tree where the intermediate level consists of “virtual” standard heirs.

Input: A set of DhA heirs $D = {d_1, \ldots, d_k}$ and optionally a spouse.

Step 1 — Projection map $\pi$:

For each $d_i$, identify the standard heir (mudlā bihi) they connect through:

$$\pi: D \to \mathcal{W} \qquad d_i \mapsto w_i$$

where $w_i$ is the standard heir whose “seat” $d_i$ occupies. The projection table from the source text (faraid/dzawilarham.md):

DhA heir	$\pi$ maps to
Daughter’s children	Daughter (بنت)
Son’s daughter’s children	Son’s daughter (بنت ابن)
Paternal uncles-for-mother, paternal aunts	Father (أب)
Maternal uncles, maternal aunts	Mother (أم)
Sisters’ children	The sister (أخت)
Brothers-for-mother’s children	The sibling-for-mother (أخ/أخت لأم)

Step 2 — Virtual heir set:

$$H’ = {\pi(d_i) : d_i \in D} \cup {\text{spouse if present}}$$

Step 3 — Solve the virtual problem:

$$F(H’) \to (B’, \vec{s}’)$$

Each virtual heir $w$ gets share $s’(w) / B’$.

Step 4 — Sub-distribution:

For each virtual heir $w$ with pre-image $\pi^{-1}(w) = {d_{i_1}, \ldots, d_{i_m}}$:

• If $m = 1$: $d_{i_1}$ gets all of $w$‘s share.
• If $m > 1$ and all $d_{i_j}$ have the same relationship to $w$: split equally (Ḥanbalī: 1:1 regardless of gender; Shāfiʿī: 2:1 male:female).
• If $m > 1$ and they have different relationships to $w$: treat $w$ as a new deceased, construct the heirs’ relationships to $w$, and solve $F(H_w)$. This is a recursive $F$-call — the Munāsakhat technique.

Formula. Let $\rho_{w \to d}$ be the sub-distribution fraction (from Step 4). Then:

$$\boxed{\phi(d_i) = \omega_{\text{root} \to \pi(d_i)} \cdot \rho_{\pi(d_i) \to d_i}}$$

This is exactly the estate flow tree with depth 2 (root → virtual heirs → DhA heirs).

With spouse: The spouse takes their full share first (no ḥajb by DhA heirs, no ʿawl). This is stated explicitly in the source: the spouse gets النصف or الربع without reduction. The DhA heirs distribute the remainder. This matches the Radd-with-spouse structure from core $F$, but with $P = \text{DhA heirs}$:

$$\phi(\text{spouse}) = f_{\text{spouse}}, \qquad \phi(d_i) = (1 - f_{\text{spouse}}) \cdot \frac{s’(\pi(d_i))}{B’{\text{DhA}}} \cdot \rho{\pi(d_i) \to d_i}$$

Integer normalization: The source text explicitly says “solve by the method of Case 3 of Munāsakhat” (بطريقة الحالة الثالثة من المناسخات) — confirming that Tanzīl reuses the Chain merge primitive.

6.2 Method B: Qarāba (أهل القرابة) — Ḥanafī

Insight: Qarāba extends the ʿaṣaba priority cascade to DhA heirs. It is a single-pass priority algorithm, not a tree.

Input: A set of DhA heirs $D$ with their 5-tuple vectors $(g, j, d, q, c)$.

Priority cascade (from faraid/dzawilarham.md):

$$\text{jiha} \succ \text{daraja} \succ \text{quwwa} \succ \text{connection}$$

where jiha has 4 levels: Fūrūʿ (descendants) $\succ$ Uṣūl (ancestors) $\succ$ Ukhuwwa (siblings’ descendants) $\succ$ ʿUmūma (uncles/aunts).

Algorithm:

1. Filter D to the highest jiha present.
2. Among those, filter to the closest daraja.
3. Among those, filter to the strongest quwwa.
4. Among those, filter to those connecting through a standard heir
   (mudlī bi-wārith) over those connecting through another DhA.
5. Remaining heirs share the estate:
   - If single class (all same gender): equal split.
   - If mixed gender: 2:1 male:female.
   - EXCEPT: if they connect to both father and mother sides
     (e.g., paternal aunts + maternal aunts), the paternal side gets ⅔
     and the maternal side gets ⅓ (mirroring the father:mother ratio).

Formula. For the simple case (single class):

$$\phi(d_i) = \frac{w_i}{\sum_j w_j}$$

where $w_i = 2$ if male, $w_i = 1$ if female (or $w_i = 1$ for all if Ḥanbalī 1:1 rule).

For the two-sided case (paternal + maternal):

$$\phi(d_i) = \begin{cases} \frac{2}{3} \cdot \frac{w_i}{\sum_{j \in \text{paternal}} w_j} & \text{if } d_i \text{ is from the paternal side} \[6pt] \frac{1}{3} \cdot \frac{w_i}{\sum_{j \in \text{maternal}} w_j} & \text{if } d_i \text{ is from the maternal side} \end{cases}$$

With spouse: Same as Tanzīl — spouse takes full share first, DhA distribute remainder.

Complexity: $O(|D| \log |D|)$ (sort by priority, then split). No recursive $F$-call needed.

---

7. The Unifying Structure

7.1 All Extensions Are Tree Evaluations

Extension	Tree structure	Aggregation at leaves
Chain (Munāsakhat)	Depth $n$ tree; one node per deceased	Sum of path-products
Min (Mafqūd)	$2^n$ parallel depth-1 trees (one per scenario)	Component-wise minimum across trees
Project/Tanzīl (DhA)	Depth-2 tree: root → virtual heirs → DhA leaves	Path-product (with sub-distribution at depth 2)
Project/Qarāba (DhA)	Depth-1 tree: root → DhA leaves (priority-filtered)	Weighted equal split

7.2 The Shared Merge Primitive

All extensions that produce integer output use the same merge operation:

$$\text{merge}(s, B) = \left(\frac{B}{\gcd(s, B)},; \frac{s}{\gcd(s, B)}\right)$$

This is the four-ratio comparison. It appears in:

• Chain: merging each deceased’s sub-problem with the current jāmiʿa
• Min: finding a common base across $2^n$ scenarios
• Tanzīl: merging the DhA sub-problem with the spousal problem

7.3 Composition Rules

The extensions compose with each other:

Composition	Meaning	Example
Chain ∘ Min	A missing person’s estate is chained into another problem	Mafqūd dies before distribution → solve Min first, then Chain the result
Chain ∘ Project	A DhA heir dies before distribution	Project to identify shares, then Chain the deceased DhA heir’s portion
Min ∘ Project	A DhA heir is missing	Project the DhA heirs, then apply Min across alive/dead scenarios

Composition is associative: $(A \circ B) \circ C = A \circ (B \circ C)$ — because $F$ is a pure function and the tree evaluation is order-independent (each node is processed exactly once).

---

8. The Formulas (Summary for Engineers)

8.1 Chain — $O(n)$ $F$-calls

type ShareMap = Map<HeirId, Fraction>;

function chain(F: Pipeline, deaths: Death[]): { base: number, shares: ShareMap } {
  // Solve first problem
  let { base, shares } = F(deaths[0].heirs);
  let result: ShareMap = new Map(shares);

  for (let i = 1; i < deaths.length; i++) {
    const d = deaths[i].deceased;
    const s_d = result.get(d)!;           // deceased's share in current result

    const sub = F(deaths[i].heirs);        // solve sub-problem
    const g = gcd(s_d, sub.base);
    const scale = sub.base / g;

    // Scale existing shares
    base *= scale;
    for (const [h, s] of result) {
      result.set(h, s * scale);
    }

    // Distribute deceased's share to their heirs
    const multiplier = result.get(d)! / sub.base;
    result.delete(d);

    for (const [h, s] of sub.shares) {
      const existing = result.get(h) ?? 0;
      result.set(h, existing + s * multiplier);
    }
  }

  return { base, shares: result };
}

---

Developer Sign-off Checklist — Re-expression (Munāsakhat)

Use this checklist when reviewing an implementation of re-expression or when integrating it into the chain extension.

• Input contract: function accepts (dag: FamilyDAG, deceasedId: string, originalIds?: string[]) and returns a pure Heir[] suitable for computeF.
• Resolver dependence: implementation must call resolve(dag, deceasedId) (BFS path resolver) so c and the full path sequence are computed correctly.
• Identification: resolve() must expose the physical node id (stored in Heir.name) so callers can map original persons into the sub-problem.
• Filtering: if originalIds is provided, only those node ids are retained; unrelated persons must be dropped (not passed with zero share).
• Aggregation: identical (g,j,d,q,c) tuples must be merged with count += before calling computeF to preserve gcd/lcm normalization and avoid duplicate entries.
• Purity: the function must be pure (no mutation of dag or global state) and deterministic.
• Sanity check: after computeF on the returned Heir[], assert sum(sahm) == base for the sub-problem before merging into the jāmiʿa.
• Edge cases to unit-test:
  • Maternal vs paternal quwwa re-mapping (full → maternal/paternal depending on path).
  • Grandmother c (female ancestor validity) where gender-sequence matters.
  • Multiple persons mapping to same tuple → count aggregation.
  • Spouse presence (j=0) and d=0 correctness.
  • Persons with no path to deceasedId are excluded.
• Acceptance: mathematician (Jon) signs off when unit tests for the above cases match hand-verified numerical examples (R1,R2,R3) and when chain merges produce the expected jāmiʿa.

8.2 Min — $O(2^n)$ $F$-calls

function minEnvelope(F: Pipeline, heirs: Heir[], missing: Heir[]):
  { base: number, shares: ShareMap, suspended: number }
{
  const n = missing.length;
  const scenarios: { base: number, shares: ShareMap }[] = [];

  // Generate all 2^n scenarios
  for (let mask = 0; mask < (1 << n); mask++) {
    const H = heirs.filter(h => {
      const idx = missing.indexOf(h);
      if (idx === -1) return true;          // known heir: always include
      return (mask & (1 << idx)) !== 0;     // missing heir: include if "alive" bit set
    });
    scenarios.push(F(H));
  }

  // Find common base
  const base = scenarios.reduce((J, s) => lcm(J, s.base), 1);

  // For each known heir: take minimum across scenarios
  const shares: ShareMap = new Map();
  const known = heirs.filter(h => !missing.includes(h));

  for (const h of known) {
    let minShare = Infinity;
    for (const sc of scenarios) {
      const scaled = (sc.shares.get(h) ?? 0) * (base / sc.base);
      minShare = Math.min(minShare, scaled);
    }
    shares.set(h, minShare);
  }

  const suspended = base - [...shares.values()].reduce((a, b) => a + b, 0);
  return { base, shares, suspended };
}

8.3 Project (Tanzīl) — $1 + k$ $F$-calls (where $k$ = distinct mudlā bihi with multiple claimants)

function projectTanzil(F: Pipeline, dhaHeirs: DhaHeir[], spouse?: Heir):
  { base: number, shares: ShareMap }
{
  // Step 1: Build projection map
  const projection: Map<DhaHeir, StandardHeir> = new Map();
  for (const d of dhaHeirs) {
    projection.set(d, findMudlaBihi(d));
  }

  // Step 2: Build virtual heir set
  const virtualHeirs = [...new Set(projection.values())];
  if (spouse) virtualHeirs.push(spouse);

  // Step 3: Solve virtual problem
  const main = F(virtualHeirs);

  // Step 4: Sub-distribute
  // Group DhA heirs by their mudlā bihi
  const groups: Map<StandardHeir, DhaHeir[]> = new Map();
  for (const [dha, std] of projection) {
    if (!groups.has(std)) groups.set(std, []);
    groups.get(std)!.push(dha);
  }

  // For each group: compute sub-distribution
  // This uses the Chain merge primitive (Munāsakhat Case 3 method)
  const result: ShareMap = new Map();
  let base = main.base;

  if (spouse) {
    result.set(spouse, main.shares.get(spouse)!);
  }

  for (const [std, group] of groups) {
    const stdShare = main.shares.get(std)!;

    if (group.length === 1) {
      result.set(group[0], stdShare);
    } else {
      // Sub-distribute: treat std as "deceased", group as "heirs"
      // Compute their relationships to std, solve F
      const subHeirs = group.map(d => asHeirOf(d, std));
      const sub = F(subHeirs);

      // Merge using Chain merge primitive
      const g = gcd(stdShare, sub.base);
      const scale = sub.base / g;

      // Scale all existing shares
      base *= scale;
      for (const [h, s] of result) result.set(h, s * scale);

      // Distribute
      const multiplier = (stdShare * scale) / sub.base;
      for (const [h, s] of sub.shares) {
        result.set(h, s * multiplier);
      }
    }
  }

  return { base, shares: result };
}

8.4 Project (Qarāba) — $0$ $F$-calls (pure priority algorithm)

function projectQaraba(dhaHeirs: DhaHeir[], spouse?: Heir):
  { base: number, shares: ShareMap }
{
  // Sort by priority: jiha > daraja > quwwa > connection
  const sorted = [...dhaHeirs].sort(compareDhaPriority);

  // Filter to highest priority class
  const topJiha = sorted[0].jiha;
  let candidates = sorted.filter(d => d.jiha === topJiha);

  const topDaraja = candidates[0].daraja;
  candidates = candidates.filter(d => d.daraja === topDaraja);

  const topQuwwa = candidates[0].quwwa;
  candidates = candidates.filter(d => d.quwwa === topQuwwa);

  // Prefer those connecting through a standard heir
  const viaWarith = candidates.filter(d => connectsThroughStandardHeir(d));
  if (viaWarith.length > 0) candidates = viaWarith;

  // Check if two-sided (paternal + maternal)
  const paternal = candidates.filter(d => d.side === 'paternal');
  const maternal = candidates.filter(d => d.side === 'maternal');

  let shares: ShareMap;
  let base: number;

  if (paternal.length > 0 && maternal.length > 0) {
    // Two-sided: paternal gets 2/3, maternal gets 1/3
    const pWeights = paternal.map(d => d.gender === 'M' ? 2 : 1);
    const mWeights = maternal.map(d => d.gender === 'M' ? 2 : 1);
    const pTotal = pWeights.reduce((a, b) => a + b, 0);
    const mTotal = mWeights.reduce((a, b) => a + b, 0);

    base = 3 * lcm(pTotal, mTotal);
    shares = new Map();
    for (let i = 0; i < paternal.length; i++)
      shares.set(paternal[i], 2 * pWeights[i] * (base / 3) / pTotal);
    for (let i = 0; i < maternal.length; i++)
      shares.set(maternal[i], 1 * mWeights[i] * (base / 3) / mTotal);
  } else {
    // Single-sided: equal (Ḥanbalī) or 2:1 (Ḥanafī)
    const weights = candidates.map(d => d.gender === 'M' ? 2 : 1);
    base = weights.reduce((a, b) => a + b, 0);
    shares = new Map();
    for (let i = 0; i < candidates.length; i++)
      shares.set(candidates[i], weights[i]);
  }

  // If spouse present: spouse takes share first, DhA get remainder
  if (spouse) {
    const spouseFrac = spouse.gender === 'M' ? 2 : 4; // 1/2 or 1/4
    const newBase = base * spouseFrac;
    const spouseShare = newBase / spouseFrac;
    const remainder = newBase - spouseShare;

    const finalShares: ShareMap = new Map();
    finalShares.set(spouse, spouseShare);
    for (const [h, s] of shares) {
      finalShares.set(h, s * remainder / base);
    }
    return { base: newBase, shares: finalShares };
  }

  return { base, shares };
}

---

9. Complexity Summary

Extension	$F$-calls	Space	Practical range
Chain	$n$ (number of deceased)	$O(\sum	H_i
Min	$2^n$ (scenarios)	$O(2^n \cdot	H
Tanzīl	$1 + k$ ($k$ = shared mudlā bihi)	$O(	D
Qarāba	$0$	$O(	D

---

10. What the Classical Texts Actually Compute

The 80-page Munāsakhat chapter and the elaborate shabak (grid) tables are:

1. The tree construction (identifying which case — الحالة الأولى/الثانية/الثالثة — determines the tree shape).
2. The incremental jāmiʿa algorithm (§3.2), performed with pen-and-paper integer arithmetic.
3. The four-ratio comparison (a manual case-split for computing $\gcd$ without Euclid’s algorithm).
4. Verification (summing shares to check they equal the jāmiʿa — the conservation invariant $\gamma$).

In $\mathbb{Q}$, the entire computation is:

$$\phi(\ell) = \sum_{\pi : r \leadsto \ell} \prod_{(v,w) \in \pi} \frac{s_v(w)}{B_v}$$

One line. The integer normalization is the engineering concern, not the mathematical structure.

---

11. Open Questions

#	Question	Status
Q1	Can Min be optimized below $O(2^n)$ by exploiting monotonicity in the hajb lattice?	Open. If missing persons form a chain (each excludes the next), the scenarios reduce to $n+1$.
Q2	Does the Akdariyya’s post-ʿawl pooling interact with Chain? (A deceased Akdariyya heir triggers Munāsakhat.)	Open. Needs test case.
Q3	Tanzīl with 3+ levels of DhA nesting — does the recursion always terminate?	Yes. The projection strictly reduces the nesting depth (each DhA maps to a standard heir one level closer).
Q4	Can Qarāba and Tanzīl produce different results that violate Conservation ($\sum \ne 1$)?	No — both guarantee $\sum = 1$ by construction (Qarāba by weight normalization, Tanzīl by $F$‘s conservation).

---

References

Source	Content used
faraid/munasakhat.md	Full Munāsakhat theory: 3 cases, 4 sub-cases of Case 3, worked examples, algorithm steps, reduction shortcuts
faraid/munasakhat-math.md	Modern mathematical summary confirming the “fraction of fraction” structure and LCM interpretation
faraid/mafqud.md	Mafqūd theory: min-envelope, 3 heir categories, multi-missing $2^n$ scenarios, mawqūf distribution
faraid/dzawilarham.md	DhA theory: Tanzīl vs Qarāba, 4 jiha, projection table, sub-distribution rules, spouse interaction
findings/06-core-vs-extensions.md	Core/extension boundary, litmus test, architecture diagram