Auto-sync 2026-08-16 06:00:01

2026-08-16 06:08:04 +08:00
commit 45061218f3
31 changed files with 2207 additions and 0 deletions
@@ -0,0 +1,117 @@
 ## PRINCIPLE #1: THE PROBLEM STATEMENT — What Problem Are We Solving?
 ### 1. THE SCENARIO
 You’re the Product Lead at a fintech startup that just closed Series A. Monthly active users are growing, but retention is flat. Your CEO bursts into your weekly sync: “Our users aren’t saving enough. Let’s build an auto-round-up feature—every purchase, round up to the nearest dollar and stash the difference. It’s what Monzo and Acorns do. Ship it by end of quarter.”
 You open your notebook. The spreadsheet of user interview notes stares back at you. The Mujtahid in you whispers: *Before you write a single line of a PRD, ask: What is the hukm (ruling) on this decision? What is the maqsad (purpose) we are truly serving?* The Product Lead in you adds: *Is this a symptom or a root cause? Is this user pain or business pain? And most importantly—which job are we actually being hired to do?*
 ---
 ### 2. DISCOVERY (ISTIQSA’)
 **PRODUCT_LEAD:**  
 Stop. Don’t touch a wireframe. We’re not building anything until we understand the problem space. I pull out the **Opportunity Solution Tree** framework. I ask the team: *What outcome do we want?* “Increase savings rate” is not an outcome—it’s an output. The real outcome? *Users feel financially secure enough to focus on other parts of life.* That smells like **Hifz al-Mal** (preservation of wealth) and **Hifz al-Aql** (preservation of mind/clarity).  
 I draw the tree. Root node: *Improve financial well-being.* First-level opportunities: (1) Users don’t know where their money goes. (2) Users lack the discipline to save. (3) Users feel anxious about unexpected expenses. The CEO’s feature—auto-round-up—maps to opportunity #2. But is #2 the root? I schedule 10 user interviews this week. No solution talk. Just JTBD: *When you think about saving money, what’s the job you’re trying to get done?* The answer might be: “I want to stop feeling guilty about spending on coffee.” That’s an emotional job, not a functional one.
 **MUJTAHID:**  
 Before a fatwa, I conduct **Istiqsa’**—exhaustive investigation of the problem space. The Prophet ﷺ said: “The judge must not judge between two people while he is angry.” Anger clouds reasoning. Likewise, the CEO’s excitement for a popular feature is a form of *hawa* (desire). I ask: *What is the maqsad al-shar’i (higher objective) of this product?* It is not merely to make users save—it is to protect their *aql* (mind) from the anxiety of financial insecurity, which is a *daruriyyah* (essential need) under Hifz al-Aql.  
 I then map the problem using **Maqasid lenses**:  
 - Is this a *daruriyyah* (essential), *hajiyyah* (needed), or *tahsiniyyah* (embellishment)?  
 - If users don’t save, do they lose their mental clarity (aql)? Or do they just miss an opportunity for optimization?  
 The CEO’s feature assumes the problem is *lack of a mechanism*. But Istiqsa’ demands we test that assumption. I ask: *What evidence do we have that users actually want to save?* If the problem is *lack of knowledge* (opportunity #1), then auto-round-up is a *sad al-dhara’i* (blocking the means) that blocks spending—but it may also block the *maslaha* (benefit) of conscious budgeting. I record all assumptions as *zanni* (speculative) until proven.
 *Key question from Istiqsa’:* How do we distinguish a symptom from a root cause? A symptom is the surface complaint—“I can’t save.” A root cause is the underlying *mafsada* (harm) or *maslaha* gap—e.g., “I have no visibility into my spending pattern, so I feel out of control.” The Mujtahid asks: *What is the ‘illah (effective cause) behind the user’s behavior?* Is it ignorance, lack of tools, or emotional friction? The Product Lead asks: *What is the JTBD that the user is hiring our product to do?* Both converge on the same truth: the problem statement must describe the job, not the solution.
 ---
 ### 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Now we gather daleel. Two buckets: **Quantitative** and **Qualitative**.  
 Quantitative: I pull analytics. Our users who attempt to set a savings goal drop off at 70% mid-funnel. That’s a signal. But is it *qati* (certain)? No—it’s *zanni* (speculative) because the drop-off could be due to UI confusion, not lack of desire. I need cohort analysis: do users who complete setup actually save more? If yes, then the bottleneck is *completion*, not *desire*.  
 Qualitative: I conduct 10 user interviews. One user says: “I tried rounding up for two weeks, but I felt like I was being punished for buying groceries. I stopped.” That’s a *symptom*—the feature itself created a negative emotional job (punishment). Another user says: “I want to save automatically, but I also want to know exactly how much I’m saving every month.” That reveals a *missing job*: transparency.  
 I map these onto the Opportunity Solution Tree. The evidence points to opportunity #1 (lack of visibility) being more fundamental than #2 (lack of discipline). I update my hypothesis: *The job is not “make me save” but “show me my financial reality so I can make confident decisions.”*
 **MUJTAHID:**  
 Evidence in Usul al-Fiqh is categorized by strength:  
 - **Qati al-Thubut** (certain transmission): data that is indisputable—e.g., server logs showing drop-off rates.  
 - **Zanni al-Thubut** (speculative transmission): user quotes—they might be lying or mistaken.  
 - **Qati al-Dalala** (certain meaning): the interpretation is obvious—e.g., “I stopped because I felt punished” clearly indicates emotional pain.  
 - **Zanni al-Dalala** (speculative meaning): a high drop-off rate could mean multiple things (bad UI, low intent, technical failure).  
 I weigh the evidence: The quantitative drop-off is *qati al-thubut* (the data is fact) but *zanni al-dalala* (the cause is ambiguous). The qualitative quote is *zanni al-thubut* (one user’s opinion) but *qati al-dalala* (the emotional job is clear). To strengthen, I apply **Istishab** (presumption of continuity): we presume no problem exists until evidence contradicts. Here, the drop-off contradicts the assumption that users want auto-save. So the default state is: *the current solution is not solving the real problem.*  
 I also apply **Sad al-Dhara’i** (blocking the means): if we build auto-round-up without solving visibility, we may actually increase anxiety (users feel they lost control). That harms Hifz al-Aql. The evidence does not support moving forward.
 *Key lesson from evidence:* Distinguish anecdote from data. One user’s “I felt punished” is an anecdote—but if it resonates with patterns across 8 of 10 users, it becomes *mustanid* (supported evidence). The Product Lead triangulates; the Mujtahid demands *tawatur* (multiple independent chains) before accepting.
 ---
 ### 4. SHURA (Consultation)
 **PRODUCT_LEAD:**  
 I call a cross-functional sync: Engineering, Design, Data, and the CEO. I share the Opportunity Solution Tree and the evidence. I start with the user quotes—let them feel the pain. Then I ask: *What do we think the root cause is?*  
 The CEO says: “But auto-round-up works for everyone else.” That’s an appeal to popularity (*istihsan bi al-‘adah*). I counter: “We need to solve *our* users’ job, not copy features.”  
 The Data Lead points out: “Our retention curve flattens after 30 days—users who save manually stay longer than those who use auto-features.” That’s *qati al-thubut* evidence.  
 Design says: “What if we build a dashboard first? Show spending breakdown before any saving feature.”  
 I record all input. I don’t dismiss the CEO—I note his concern as a *maslaha* (speed to market). But I weight it lower because it contradicts user evidence. I then ask: *Who else should we consult?* We need to talk to users who churned. I schedule 5 more interviews.  
 **MUJTAHID:**  
 Shura is not a vote. It is a method of *ijtihad jama’i* (collective reasoning). The Prophet ﷺ consulted the companions even when he knew the answer—to build ownership and gather insights.  
 I establish *adab al-shura* (etiquette of consultation):  
 1. **No rank-based weighting.** The CEO’s opinion gets the same initial weight as the intern’s. True evidence trumps authority.  
 2. **Record dissent explicitly.** If Engineering says “this is technically hard to roll back,” that becomes a *shart* (condition) for the decision.  
 3. **Seek those with *khibra* (expertise).** The Data Lead’s analysis is stronger than a generalist’s intuition. I assign a weight of 3x to domain experts.  
 The key *mas’ala* (issue) is: *Is the problem we’re solving the right one?* The shura reveals consensus that auto-round-up addresses a symptom, not the root. But we need one more round: consult the *ahl al-khibra*## THE PRINCIPLE (HUKM)
 **HUKM:** We will not build any solution — not a single line of code, not a prototype, not an A/B test — until we have a validated problem statement that passes the **Maqasid Problem Filter** and is framed as a **Jobs-to-be-Done**.
 **DALEEL:**  
 Quantitative data from our analytics shows a 40% drop in daily active users within the first week of new feature launches — not because the features were broken, but because they solved problems nobody had. Qualitative interviews (n=12) revealed users couldn’t articulate *what job they were hiring our app to do*; they described tasks, not outcomes. The Shura session with stakeholders confirmed that we have been building from “cool idea” rather than “real struggle.” The evidence is **zanni al-dalala** (probable in meaning) but **qati’ al-thubut** (certain in occurrence): we are wasting engineering capacity on assumptions.
 **MAQSAD:** Primary: **Hifz al-Aql** (Preservation of Mind) — by forcing ourselves to think clearly about the true problem, we protect the team’s cognitive energy from being scattered across low-impact work. Secondary: **Hifz al-Mal** (Preservation of Wealth) — we stop burning budget on features that don’t move the North Star metric.
 **SHURUT** (Conditions that must be met before the principle is considered fulfilled):
 - The problem statement must include a **JTBD functional job** (e.g., “When I read Quran, I want to capture the verse that struck me so I can reflect on it later”) — not a feature request.
 - The problem must pass the **Maqasid Filter**: does solving it preserve Aql, Din, Nafs, Mal, or Nasl? If none, deprioritize.
 - The problem must be validated with at least **5 user interviews** where the user’s *struggle* is observed, not just stated.
 - The problem must have a **measurable outcome** (e.g., increase in “verse capture rate” by 20%) before any solution sketch is drawn.
 **MUNKATHIRAT** (Nullifiers — conditions that invalidate this principle):
 - If a stakeholder (including the CEO) bypasses the problem statement and says “just build this feature,” the principle is nullified — we must immediately call a Shura to re-establish discipline.
 - If the team starts wireframing before the problem statement is written in the JTBD format, the principle is broken — halt and rewrite.
 - If the problem statement changes mid-sprint without a new validation cycle, the principle is violated — rollback to discovery.
 ---
 ## THE PROTOCOL
 **STEP 1: Write the JTBD Problem Card (by Tuesday)**  
 Take the feature request your team is most excited about. Write it on a physical index card. Flip it over. On the back, answer: *What job is the user trying to get done? What is the struggle? What progress are they trying to make?* If you cannot write a clear functional job in one sentence, do not proceed. This is your **“istidlal al-mas’ala”** (inference of the problem).
 **STEP 2: Run the Maqasid Filter (Wednesday)**  
 Bring the problem card to a 30-minute standup with the product triad (PM, designer, lead engineer). For each Maqsad (Din, Nafs, Aql, Mal, Nasl), ask: *If we solve this problem, which Maqsad do we serve? How? Give one concrete example.* If the problem serves zero Maqasid, kill it. If it serves one but with negative externalities (e.g., increases user anxiety), apply **Sad al-Dhara’i** (blocking the means to harm) and deprioritize.
 **STEP 3: Validate with 5 Struggles, Not 5 Opinions (by end of Sprint)**  
 Conduct 5 user interviews. Do not ask “Would you use X?” Ask: *Tell me about the last time you tried to do [the job]. What made it hard? What did you do instead?* Record each struggle as a quote. After the interviews, rewrite the problem statement based on what you observed. If the statement changes, you have validated the *real* problem. If it stays the same, you may have confirmation bias — interview 3 more users.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What would our product look like if we deleted every feature that was built without a validated problem statement?**  
 Take that list. Burn it in your mind. Now ask: *What is the one feature we would keep — the one that actually solves a real struggle for a real person?* That is your **North Star**. Everything else is decoration. Start there next sprint.
@@ -0,0 +1,78 @@
 ## PRINCIPLE #1: THE PROBLEM STATEMENT — What Problem Are We Solving?
 ### 1. THE SCENARIO
 You’re the Product Lead at a fintech startup that just closed Series A. Monthly active users are growing, but retention is flat. Your CEO bursts into your weekly sync: “Our users aren’t saving enough. Let’s build an auto-round-up feature—every purchase, round up to the nearest dollar and stash the difference. It’s what Monzo and Acorns do. Ship it by end of quarter.”
 You open your notebook. The spreadsheet of user interview notes stares back at you. The Mujtahid in you whispers: *Before you write a single line of a PRD, ask: What is the hukm (ruling) on this decision? What is the maqsad (purpose) we are truly serving?* The Product Lead in you adds: *Is this a symptom or a root cause? Is this user pain or business pain? And most importantly—which job are we actually being hired to do?*
 ---
 ### 2. DISCOVERY (ISTIQSA’)
 **PRODUCT_LEAD:**  
 Stop. Don’t touch a wireframe. We’re not building anything until we understand the problem space. I pull out the **Opportunity Solution Tree** framework. I ask the team: *What outcome do we want?* “Increase savings rate” is not an outcome—it’s an output. The real outcome? *Users feel financially secure enough to focus on other parts of life.* That smells like **Hifz al-Mal** (preservation of wealth) and **Hifz al-Aql** (preservation of mind/clarity).  
 I draw the tree. Root node: *Improve financial well-being.* First-level opportunities: (1) Users don’t know where their money goes. (2) Users lack the discipline to save. (3) Users feel anxious about unexpected expenses. The CEO’s feature—auto-round-up—maps to opportunity #2. But is #2 the root? I schedule 10 user interviews this week. No solution talk. Just JTBD: *When you think about saving money, what’s the job you’re trying to get done?* The answer might be: “I want to stop feeling guilty about spending on coffee.” That’s an emotional job, not a functional one.
 **MUJTAHID:**  
 Before a fatwa, I conduct **Istiqsa’**—exhaustive investigation of the problem space. The Prophet ﷺ said: “The judge must not judge between two people while he is angry.” Anger clouds reasoning. Likewise, the CEO’s excitement for a popular feature is a form of *hawa* (desire). I ask: *What is the maqsad al-shar’i (higher objective) of this product?* It is not merely to make users save—it is to protect their *aql* (mind) from the anxiety of financial insecurity, which is a *daruriyyah* (essential need) under Hifz al-Aql.  
 I then map the problem using **Maqasid lenses**:  
 - Is this a *daruriyyah* (essential), *hajiyyah* (needed), or *tahsiniyyah* (embellishment)?  
 - If users don’t save, do they lose their mental clarity (aql)? Or do they just miss an opportunity for optimization?  
 The CEO’s feature assumes the problem is *lack of a mechanism*. But Istiqsa’ demands we test that assumption. I ask: *What evidence do we have that users actually want to save?* If the problem is *lack of knowledge* (opportunity #1), then auto-round-up is a *sad al-dhara’i* (blocking the means) that blocks spending—but it may also block the *maslaha* (benefit) of conscious budgeting. I record all assumptions as *zanni* (speculative) until proven.
 *Key question from Istiqsa’:* How do we distinguish a symptom from a root cause? A symptom is the surface complaint—“I can’t save.” A root cause is the underlying *mafsada* (harm) or *maslaha* gap—e.g., “I have no visibility into my spending pattern, so I feel out of control.” The Mujtahid asks: *What is the ‘illah (effective cause) behind the user’s behavior?* Is it ignorance, lack of tools, or emotional friction? The Product Lead asks: *What is the JTBD that the user is hiring our product to do?* Both converge on the same truth: the problem statement must describe the job, not the solution.
 ---
 ### 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Now we gather daleel. Two buckets: **Quantitative** and **Qualitative**.  
 Quantitative: I pull analytics. Our users who attempt to set a savings goal drop off at 70% mid-funnel. That’s a signal. But is it *qati* (certain)? No—it’s *zanni* (speculative) because the drop-off could be due to UI confusion, not lack of desire. I need cohort analysis: do users who complete setup actually save more? If yes, then the bottleneck is *completion*, not *desire*.  
 Qualitative: I conduct 10 user interviews. One user says: “I tried rounding up for two weeks, but I felt like I was being punished for buying groceries. I stopped.” That’s a *symptom*—the feature itself created a negative emotional job (punishment). Another user says: “I want to save automatically, but I also want to know exactly how much I’m saving every month.” That reveals a *missing job*: transparency.  
 I map these onto the Opportunity Solution Tree. The evidence points to opportunity #1 (lack of visibility) being more fundamental than #2 (lack of discipline). I update my hypothesis: *The job is not “make me save” but “show me my financial reality so I can make confident decisions.”*
 **MUJTAHID:**  
 Evidence in Usul al-Fiqh is categorized by strength:  
 - **Qati al-Thubut** (certain transmission): data that is indisputable—e.g., server logs showing drop-off rates.  
 - **Zanni al-Thubut** (speculative transmission): user quotes—they might be lying or mistaken.  
 - **Qati al-Dalala** (certain meaning): the interpretation is obvious—e.g., “I stopped because I felt punished” clearly indicates emotional pain.  
 - **Zanni al-Dalala** (speculative meaning): a high drop-off rate could mean multiple things (bad UI, low intent, technical failure).  
 I weigh the evidence: The quantitative drop-off is *qati al-thubut* (the data is fact) but *zanni al-dalala* (the cause is ambiguous). The qualitative quote is *zanni al-thubut* (one user’s opinion) but *qati al-dalala* (the emotional job is clear). To strengthen, I apply **Istishab** (presumption of continuity): we presume no problem exists until evidence contradicts. Here, the drop-off contradicts the assumption that users want auto-save. So the default state is: *the current solution is not solving the real problem.*  
 I also apply **Sad al-Dhara’i** (blocking the means): if we build auto-round-up without solving visibility, we may actually increase anxiety (users feel they lost control). That harms Hifz al-Aql. The evidence does not support moving forward.
 *Key lesson from evidence:* Distinguish anecdote from data. One user’s “I felt punished” is an anecdote—but if it resonates with patterns across 8 of 10 users, it becomes *mustanid* (supported evidence). The Product Lead triangulates; the Mujtahid demands *tawatur* (multiple independent chains) before accepting.
 ---
 ### 4. SHURA (Consultation)
 **PRODUCT_LEAD:**  
 I call a cross-functional sync: Engineering, Design, Data, and the CEO. I share the Opportunity Solution Tree and the evidence. I start with the user quotes—let them feel the pain. Then I ask: *What do we think the root cause is?*  
 The CEO says: “But auto-round-up works for everyone else.” That’s an appeal to popularity (*istihsan bi al-‘adah*). I counter: “We need to solve *our* users’ job, not copy features.”  
 The Data Lead points out: “Our retention curve flattens after 30 days—users who save manually stay longer than those who use auto-features.” That’s *qati al-thubut* evidence.  
 Design says: “What if we build a dashboard first? Show spending breakdown before any saving feature.”  
 I record all input. I don’t dismiss the CEO—I note his concern as a *maslaha* (speed to market). But I weight it lower because it contradicts user evidence. I then ask: *Who else should we consult?* We need to talk to users who churned. I schedule 5 more interviews.  
 **MUJTAHID:**  
 Shura is not a vote. It is a method of *ijtihad jama’i* (collective reasoning). The Prophet ﷺ consulted the companions even when he knew the answer—to build ownership and gather insights.  
 I establish *adab al-shura* (etiquette of consultation):  
 1. **No rank-based weighting.** The CEO’s opinion gets the same initial weight as the intern’s. True evidence trumps authority.  
 2. **Record dissent explicitly.** If Engineering says “this is technically hard to roll back,” that becomes a *shart* (condition) for the decision.  
 3. **Seek those with *khibra* (expertise).** The Data Lead’s analysis is stronger than a generalist’s intuition. I assign a weight of 3x to domain experts.  
 The key *mas’ala* (issue) is: *Is the problem we’re solving the right one?* The shura reveals consensus that auto-round-up addresses a symptom, not the root. But we need one more round: consult the *ahl al-khibra*
@@ -0,0 +1,40 @@
 ## THE PRINCIPLE (HUKM)
 **HUKM:** We will not build any solution — not a single line of code, not a prototype, not an A/B test — until we have a validated problem statement that passes the **Maqasid Problem Filter** and is framed as a **Jobs-to-be-Done**.
 **DALEEL:**  
 Quantitative data from our analytics shows a 40% drop in daily active users within the first week of new feature launches — not because the features were broken, but because they solved problems nobody had. Qualitative interviews (n=12) revealed users couldn’t articulate *what job they were hiring our app to do*; they described tasks, not outcomes. The Shura session with stakeholders confirmed that we have been building from “cool idea” rather than “real struggle.” The evidence is **zanni al-dalala** (probable in meaning) but **qati’ al-thubut** (certain in occurrence): we are wasting engineering capacity on assumptions.
 **MAQSAD:** Primary: **Hifz al-Aql** (Preservation of Mind) — by forcing ourselves to think clearly about the true problem, we protect the team’s cognitive energy from being scattered across low-impact work. Secondary: **Hifz al-Mal** (Preservation of Wealth) — we stop burning budget on features that don’t move the North Star metric.
 **SHURUT** (Conditions that must be met before the principle is considered fulfilled):
 - The problem statement must include a **JTBD functional job** (e.g., “When I read Quran, I want to capture the verse that struck me so I can reflect on it later”) — not a feature request.
 - The problem must pass the **Maqasid Filter**: does solving it preserve Aql, Din, Nafs, Mal, or Nasl? If none, deprioritize.
 - The problem must be validated with at least **5 user interviews** where the user’s *struggle* is observed, not just stated.
 - The problem must have a **measurable outcome** (e.g., increase in “verse capture rate” by 20%) before any solution sketch is drawn.
 **MUNKATHIRAT** (Nullifiers — conditions that invalidate this principle):
 - If a stakeholder (including the CEO) bypasses the problem statement and says “just build this feature,” the principle is nullified — we must immediately call a Shura to re-establish discipline.
 - If the team starts wireframing before the problem statement is written in the JTBD format, the principle is broken — halt and rewrite.
 - If the problem statement changes mid-sprint without a new validation cycle, the principle is violated — rollback to discovery.
 ---
 ## THE PROTOCOL
 **STEP 1: Write the JTBD Problem Card (by Tuesday)**  
 Take the feature request your team is most excited about. Write it on a physical index card. Flip it over. On the back, answer: *What job is the user trying to get done? What is the struggle? What progress are they trying to make?* If you cannot write a clear functional job in one sentence, do not proceed. This is your **“istidlal al-mas’ala”** (inference of the problem).
 **STEP 2: Run the Maqasid Filter (Wednesday)**  
 Bring the problem card to a 30-minute standup with the product triad (PM, designer, lead engineer). For each Maqsad (Din, Nafs, Aql, Mal, Nasl), ask: *If we solve this problem, which Maqsad do we serve? How? Give one concrete example.* If the problem serves zero Maqasid, kill it. If it serves one but with negative externalities (e.g., increases user anxiety), apply **Sad al-Dhara’i** (blocking the means to harm) and deprioritize.
 **STEP 3: Validate with 5 Struggles, Not 5 Opinions (by end of Sprint)**  
 Conduct 5 user interviews. Do not ask “Would you use X?” Ask: *Tell me about the last time you tried to do [the job]. What made it hard? What did you do instead?* Record each struggle as a quote. After the interviews, rewrite the problem statement based on what you observed. If the statement changes, you have validated the *real* problem. If it stays the same, you may have confirmation bias — interview 3 more users.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What would our product look like if we deleted every feature that was built without a validated problem statement?**  
 Take that list. Burn it in your mind. Now ask: *What is the one feature we would keep — the one that actually solves a real struggle for a real person?* That is your **North Star**. Everything else is decoration. Start there next sprint.
@@ -0,0 +1,95 @@
 # PRINCIPLE #2: EVIDENCE GATHERING — Continuous Discovery as Istiqsa'
 **MAQSAD:** Hifz al-Mal (Preservation of Wealth/Data)
 **FRAMEWORK:** Evidence Quadrant – Quantitative / Qualitative / Behavioral / Attitudinal
 ---
 ## 1. THE SCENARIO
 You're the Product Lead at a fast-growing fintech startup. Your CEO bursts into your weekly sync: "Why are we building this feature? Show me the evidence." You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *What did we discover? What opportunity are we solving?* The CEO isn't asking for a roadmap slide. She's asking for the daleel. And if you can't produce it, you're building on sand. This is a Hifz al-Mal moment — preserving the company's wealth (time, engineering hours, user trust) from waste. The Habit of Continuous Discovery is your shield.
 ---
 ## 2. DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:**  
 Continuous Discovery is not a meeting. It's a weekly cadence of talking to users, mapping opportunities, and testing assumptions before writing a single line of code. You start with the **Opportunity Solution Tree**. Draw the trunk: the desired outcome (e.g., "Increase monthly active savings accounts by 20%"). Then branch into opportunities: *"Users don't trust automated savings rules"*, *"Onboarding takes too long"*, *"No clear feedback loop after deposits"*. Each opportunity is a hypothesis. Then branch into solutions: *"Add manual override for auto-save rules"*, *"Streamline KYC with biometrics"*, *"Push notification after each deposit"*. But before you pick a solution, you must gather evidence. The habit is: every week, talk to 2–3 users about the opportunity space. No sales pitch. Just JTBD interviews: *"What job were you trying to get done when you set up your savings rule?"* Discovery is a habit, not a phase. You do it continuously because the problem space shifts like sand.
 **MUJTAHID:**  
 Istiqsa' (إستقصاء) in Usul al-Fiqh means thorough investigation — leaving no stone unturned before issuing a hukm. A Mujtahid does not rule on a matter until she has exhausted the sources: Qur'an, Sunnah, Ijma', Qiyas, and then the subsidiary proofs (Istihsan, Maslaha, etc.). She does not leap from a single hadith to a fatwa. She asks: *Is this daleel qati' (definitive) or zanni (probable)? Is the chain authentic? Does it conflict with a stronger daleel?* This is exactly the rigor of Continuous Discovery. The product decision is your hukm (ruling). The maqsad is Hifz al-Mal — preserving the company's wealth and the user's wealth (data, time, money) from waste. Istiqsa' means you do not build a feature based on a single user request or a CEO's gut feeling. You investigate: *What is the real problem? Who faces it? Under what conditions? What have we learned from past features?* The Mujtahid's question at this stage: *What constitutes 'sufficient evidence' for this product decision?* The answer depends on the risk. High-risk decisions (e.g., changing the core transaction flow) require qati' evidence — multiple data sources, triangulated user interviews, A/B test results. Low-risk decisions (e.g., button color) can be zanni — a heuristic or a single test. But the habit of Istiqsa' demands you know the difference.
 ---
 ## 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Evidence comes in four flavors — the **Evidence Quadrant**:  
 - **Quantitative** (what: metrics, dashboards, funnels)  
 - **Qualitative** (why: interviews, diary studies, usability tests)  
 - **Behavioral** (what users actually do: logs, clickstream, feature adoption)  
 - **Attitudinal** (what users say: surveys, NPS, feedback forms)  
 You need all four to triangulate. A high drop-off in onboarding (quantitative) tells you *where* people leave. Interviews (qualitative) tell you *why* — maybe they're confused by the savings rules. Behavioral data (logs) shows that 70% of users who attempt to set a rule abandon after step 3. Attitudinal data (survey) reveals 60% find the rule builder "too complex." Now you have evidence. But the habit is: you don't wait for a perfect dataset. You gather **minimum viable evidence** — just enough to reduce uncertainty to a level where you can make a decision. If the risk is low, a single interview with a clear pattern may suffice. If the risk is high (e.g., launching a new payment rail), you need a full investigation: user research, competitive analysis, prototype testing, and a staged rollout.
 **MUJTAHID:**  
 In Istidlal (استدلال), we classify evidence by strength. The hierarchy:  
 - **Qati' al-Thubut wa Qati' al-Dalala** — Definitive in transmission and meaning (like a mutawatir hadith). In product: a clear, replicable A/B test with statistical significance, or a consistent pattern across 20+ user interviews.  
 - **Qati' al-Thubut wa Zanni al-Dalala** — Definitive transmission but ambiguous meaning. Example: a metric that is reliable but could be interpreted multiple ways (e.g., "time on page" could mean engagement or confusion).  
 - **Zanni al-Thubut wa Qati' al-Dalala** — Probable transmission but clear meaning. Example: a single user interview where the user's words are unambiguous, but you need more data to confirm it's not an outlier.  
 - **Zanni al-Thubut wa Zanni al-Dalala** — Both weak. Example: a gut feeling from the CEO, or a survey with a biased sample.  
 Your job as product Mujtahid is to weigh the evidence and assign a confidence level. The **maqsad of Hifz al-Mal** means you protect resources from being wasted on low-confidence decisions. You do not build a feature based on zanni evidence alone — unless the cost of delay is higher than the cost of a mistake (Maslaha principle). Signal vs. noise: a single spike in support tickets about a bug is signal. A low NPS score with no qualitative context is noise. You must filter noise by triangulating across quadrants. The **minimum viable evidence** for a principle (a product decision with high impact) is at least two independent sources from different quadrants, with no contradictory evidence. For an MVP experiment, one strong qualitative signal plus a behavioral data point is sufficient.
 ---
 ## 4. SHURA
 **PRODUCT_LEAD:**  
 Discovery is not a solo sport. You need input from stakeholders: engineering (feasibility), design (usability), data science (metrics), customer support (pain points), and legal (compliance). But Shura is not voting. It's consultation with weight. You present your evidence — the Opportunity Solution Tree, the user quotes, the data — and ask: *What am I missing? What assumptions are we making? What risks do you see?* You record dissent explicitly. If an engineer says "This will break our caching layer," that's a shart (condition) you must address before the hukm. If a designer says "Users will find this confusing," that's a potential munkathir (nullifier) — if proven, the decision must reverse. Shura is not a rubber stamp. It's a pressure test of your evidence.
 **MUJTAHID:**  
 Shura (مشاورة) is an obligation for the Mujtahid when the evidence is not definitive. The Prophet ﷺ consulted his companions even when the revelation was clear, to teach the method. The methodology:  
 1. **Identify the right stakeholders** — those with relevant expertise (not just hierarchy). The engineer who built the legacy code, the customer support agent who hears complaints daily, the finance analyst who knows the unit economics.  
 2. **Present the evidence neutrally** — do not lead the consultation with your preferred conclusion. The Mujtahid states the facts, the opportunities, the risks.  
 3. **Weigh the input** — not all voices are equal. The person closest to the user's pain may have more weight than the VP who hasn't spoken to a customer in a year. Weight by relevance, not rank.  
 4. **Record dissenting opinions** — if a respected stakeholder disagrees, note it in your product decision log. That dissent becomes a munkathir (nullifier) if later evidence proves it correct. It also protects you from groupthink.  
 A Muslim PM should see Shura as a sunnah that protects Hifz al-Mal — the collective wisdom of the team prevents costly mistakes. The output of Shura is not consensus; it's a refined set of shurut (conditions) and munkathirat (nullifiers) that you will carry into the principle.
 ---
 *End of Part 1. Continue to Part 2: The Principle (Hukm), The Protocol, and The Retrospective.*## THE PRINCIPLE (HUKM)
 **HUKM:** We will institutionalise a weekly Continuous Discovery habit that systematically collects evidence across all four quadrants of the Evidence Quadrant (Quantitative, Qualitative, Behavioral, Attitudinal) before committing any engineering resources to a new feature or experiment.
 **DALEEL:** Analysis of our last three sprints shows 67% of shipped features failed to move the North Star metric because decisions were based on attitudinal data alone (customer “I want X” interviews) without behavioral validation. The Evidence Quadrant framework, when applied rigorously, reduces waste (Hifz al-Mal) by grounding decisions in triangulated signals. Our own A/B test history confirms that features validated with ≥3 quadrants have a 4× higher success rate.
 **MAQSAD:** Primary: *Hifz al-Mal* (Preservation of Wealth/Data) – avoiding wasteful engineering spend and protecting the integrity of our data pipeline. Secondary: *Hifz al-Aql* (Preservation of Intellect) – ensuring decisions are made with sound reasoning, not guesswork.
 **SHURUT:**
 * Evidence must be refreshed within the last 14 days before any sprint commitment.
 * At least two quadrants must agree before a decision is taken to build.
 * Behavioral data (actual user interaction logs) takes precedence over attitudinal data (stated preferences) in case of conflict.
 * The Evidence Quadrant board must be visible to the entire team and updated weekly.
 **MUNKATHIRAT:**
 * Skipping the weekly evidence review without a documented emergency.
 * Making a build decision based on a single quadrant (e.g., only quantitative metrics or only a CEO’s opinion).
 * Ignoring disconfirming evidence that emerges after a decision is made – the principle is invalidated if the team refuses to revisit the evidence.
 ---
 ## THE PROTOCOL
 **STEP 1:** Every Monday morning, block 90 minutes for the Continuous Discovery huddle. The PM brings three pieces of evidence: one quantitative (e.g., funnel conversion), one qualitative (e.g., user interview quote), and one behavioral (e.g., session recording clip). No slide decks – just raw evidence on the Evidence Quadrant board.
 **STEP 2:** For any feature being considered for the next sprint, the team must map it to at least two quadrants within that same week. If only one quadrant has evidence, the feature is deferred to the next cycle. Use the Opportunity Solution Tree to trace the evidence back to a specific opportunity.
 **STEP 3:** Every Friday, run a 30-minute “Evidence Audit” where the team asks: “What did we learn this week that disconfirms our current assumptions?” If any Munkathirat condition is triggered, the build is paused and the Hukm is re-evaluated before Monday.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where in our last sprint did we ship something based on a single quadrant, and what would it have cost us if we had been wrong – both in wasted engineering hours (Hifz al-Mal) and in misleading data that now pollutes our model (Hifz al-Aql)?**
@@ -0,0 +1,62 @@
 # PRINCIPLE #2: EVIDENCE GATHERING — Continuous Discovery as Istiqsa'
 **MAQSAD:** Hifz al-Mal (Preservation of Wealth/Data)
 **FRAMEWORK:** Evidence Quadrant – Quantitative / Qualitative / Behavioral / Attitudinal
 ---
 ## 1. THE SCENARIO
 You're the Product Lead at a fast-growing fintech startup. Your CEO bursts into your weekly sync: "Why are we building this feature? Show me the evidence." You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *What did we discover? What opportunity are we solving?* The CEO isn't asking for a roadmap slide. She's asking for the daleel. And if you can't produce it, you're building on sand. This is a Hifz al-Mal moment — preserving the company's wealth (time, engineering hours, user trust) from waste. The Habit of Continuous Discovery is your shield.
 ---
 ## 2. DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:**  
 Continuous Discovery is not a meeting. It's a weekly cadence of talking to users, mapping opportunities, and testing assumptions before writing a single line of code. You start with the **Opportunity Solution Tree**. Draw the trunk: the desired outcome (e.g., "Increase monthly active savings accounts by 20%"). Then branch into opportunities: *"Users don't trust automated savings rules"*, *"Onboarding takes too long"*, *"No clear feedback loop after deposits"*. Each opportunity is a hypothesis. Then branch into solutions: *"Add manual override for auto-save rules"*, *"Streamline KYC with biometrics"*, *"Push notification after each deposit"*. But before you pick a solution, you must gather evidence. The habit is: every week, talk to 2–3 users about the opportunity space. No sales pitch. Just JTBD interviews: *"What job were you trying to get done when you set up your savings rule?"* Discovery is a habit, not a phase. You do it continuously because the problem space shifts like sand.
 **MUJTAHID:**  
 Istiqsa' (إستقصاء) in Usul al-Fiqh means thorough investigation — leaving no stone unturned before issuing a hukm. A Mujtahid does not rule on a matter until she has exhausted the sources: Qur'an, Sunnah, Ijma', Qiyas, and then the subsidiary proofs (Istihsan, Maslaha, etc.). She does not leap from a single hadith to a fatwa. She asks: *Is this daleel qati' (definitive) or zanni (probable)? Is the chain authentic? Does it conflict with a stronger daleel?* This is exactly the rigor of Continuous Discovery. The product decision is your hukm (ruling). The maqsad is Hifz al-Mal — preserving the company's wealth and the user's wealth (data, time, money) from waste. Istiqsa' means you do not build a feature based on a single user request or a CEO's gut feeling. You investigate: *What is the real problem? Who faces it? Under what conditions? What have we learned from past features?* The Mujtahid's question at this stage: *What constitutes 'sufficient evidence' for this product decision?* The answer depends on the risk. High-risk decisions (e.g., changing the core transaction flow) require qati' evidence — multiple data sources, triangulated user interviews, A/B test results. Low-risk decisions (e.g., button color) can be zanni — a heuristic or a single test. But the habit of Istiqsa' demands you know the difference.
 ---
 ## 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Evidence comes in four flavors — the **Evidence Quadrant**:  
 - **Quantitative** (what: metrics, dashboards, funnels)  
 - **Qualitative** (why: interviews, diary studies, usability tests)  
 - **Behavioral** (what users actually do: logs, clickstream, feature adoption)  
 - **Attitudinal** (what users say: surveys, NPS, feedback forms)  
 You need all four to triangulate. A high drop-off in onboarding (quantitative) tells you *where* people leave. Interviews (qualitative) tell you *why* — maybe they're confused by the savings rules. Behavioral data (logs) shows that 70% of users who attempt to set a rule abandon after step 3. Attitudinal data (survey) reveals 60% find the rule builder "too complex." Now you have evidence. But the habit is: you don't wait for a perfect dataset. You gather **minimum viable evidence** — just enough to reduce uncertainty to a level where you can make a decision. If the risk is low, a single interview with a clear pattern may suffice. If the risk is high (e.g., launching a new payment rail), you need a full investigation: user research, competitive analysis, prototype testing, and a staged rollout.
 **MUJTAHID:**  
 In Istidlal (استدلال), we classify evidence by strength. The hierarchy:  
 - **Qati' al-Thubut wa Qati' al-Dalala** — Definitive in transmission and meaning (like a mutawatir hadith). In product: a clear, replicable A/B test with statistical significance, or a consistent pattern across 20+ user interviews.  
 - **Qati' al-Thubut wa Zanni al-Dalala** — Definitive transmission but ambiguous meaning. Example: a metric that is reliable but could be interpreted multiple ways (e.g., "time on page" could mean engagement or confusion).  
 - **Zanni al-Thubut wa Qati' al-Dalala** — Probable transmission but clear meaning. Example: a single user interview where the user's words are unambiguous, but you need more data to confirm it's not an outlier.  
 - **Zanni al-Thubut wa Zanni al-Dalala** — Both weak. Example: a gut feeling from the CEO, or a survey with a biased sample.  
 Your job as product Mujtahid is to weigh the evidence and assign a confidence level. The **maqsad of Hifz al-Mal** means you protect resources from being wasted on low-confidence decisions. You do not build a feature based on zanni evidence alone — unless the cost of delay is higher than the cost of a mistake (Maslaha principle). Signal vs. noise: a single spike in support tickets about a bug is signal. A low NPS score with no qualitative context is noise. You must filter noise by triangulating across quadrants. The **minimum viable evidence** for a principle (a product decision with high impact) is at least two independent sources from different quadrants, with no contradictory evidence. For an MVP experiment, one strong qualitative signal plus a behavioral data point is sufficient.
 ---
 ## 4. SHURA
 **PRODUCT_LEAD:**  
 Discovery is not a solo sport. You need input from stakeholders: engineering (feasibility), design (usability), data science (metrics), customer support (pain points), and legal (compliance). But Shura is not voting. It's consultation with weight. You present your evidence — the Opportunity Solution Tree, the user quotes, the data — and ask: *What am I missing? What assumptions are we making? What risks do you see?* You record dissent explicitly. If an engineer says "This will break our caching layer," that's a shart (condition) you must address before the hukm. If a designer says "Users will find this confusing," that's a potential munkathir (nullifier) — if proven, the decision must reverse. Shura is not a rubber stamp. It's a pressure test of your evidence.
 **MUJTAHID:**  
 Shura (مشاورة) is an obligation for the Mujtahid when the evidence is not definitive. The Prophet ﷺ consulted his companions even when the revelation was clear, to teach the method. The methodology:  
 1. **Identify the right stakeholders** — those with relevant expertise (not just hierarchy). The engineer who built the legacy code, the customer support agent who hears complaints daily, the finance analyst who knows the unit economics.  
 2. **Present the evidence neutrally** — do not lead the consultation with your preferred conclusion. The Mujtahid states the facts, the opportunities, the risks.  
 3. **Weigh the input** — not all voices are equal. The person closest to the user's pain may have more weight than the VP who hasn't spoken to a customer in a year. Weight by relevance, not rank.  
 4. **Record dissenting opinions** — if a respected stakeholder disagrees, note it in your product decision log. That dissent becomes a munkathir (nullifier) if later evidence proves it correct. It also protects you from groupthink.  
 A Muslim PM should see Shura as a sunnah that protects Hifz al-Mal — the collective wisdom of the team prevents costly mistakes. The output of Shura is not consensus; it's a refined set of shurut (conditions) and munkathirat (nullifiers) that you will carry into the principle.
 ---
 *End of Part 1. Continue to Part 2: The Principle (Hukm), The Protocol, and The Retrospective.*
@@ -0,0 +1,34 @@
 ## THE PRINCIPLE (HUKM)
 **HUKM:** We will institutionalise a weekly Continuous Discovery habit that systematically collects evidence across all four quadrants of the Evidence Quadrant (Quantitative, Qualitative, Behavioral, Attitudinal) before committing any engineering resources to a new feature or experiment.
 **DALEEL:** Analysis of our last three sprints shows 67% of shipped features failed to move the North Star metric because decisions were based on attitudinal data alone (customer “I want X” interviews) without behavioral validation. The Evidence Quadrant framework, when applied rigorously, reduces waste (Hifz al-Mal) by grounding decisions in triangulated signals. Our own A/B test history confirms that features validated with ≥3 quadrants have a 4× higher success rate.
 **MAQSAD:** Primary: *Hifz al-Mal* (Preservation of Wealth/Data) – avoiding wasteful engineering spend and protecting the integrity of our data pipeline. Secondary: *Hifz al-Aql* (Preservation of Intellect) – ensuring decisions are made with sound reasoning, not guesswork.
 **SHURUT:**
 * Evidence must be refreshed within the last 14 days before any sprint commitment.
 * At least two quadrants must agree before a decision is taken to build.
 * Behavioral data (actual user interaction logs) takes precedence over attitudinal data (stated preferences) in case of conflict.
 * The Evidence Quadrant board must be visible to the entire team and updated weekly.
 **MUNKATHIRAT:**
 * Skipping the weekly evidence review without a documented emergency.
 * Making a build decision based on a single quadrant (e.g., only quantitative metrics or only a CEO’s opinion).
 * Ignoring disconfirming evidence that emerges after a decision is made – the principle is invalidated if the team refuses to revisit the evidence.
 ---
 ## THE PROTOCOL
 **STEP 1:** Every Monday morning, block 90 minutes for the Continuous Discovery huddle. The PM brings three pieces of evidence: one quantitative (e.g., funnel conversion), one qualitative (e.g., user interview quote), and one behavioral (e.g., session recording clip). No slide decks – just raw evidence on the Evidence Quadrant board.
 **STEP 2:** For any feature being considered for the next sprint, the team must map it to at least two quadrants within that same week. If only one quadrant has evidence, the feature is deferred to the next cycle. Use the Opportunity Solution Tree to trace the evidence back to a specific opportunity.
 **STEP 3:** Every Friday, run a 30-minute “Evidence Audit” where the team asks: “What did we learn this week that disconfirms our current assumptions?” If any Munkathirat condition is triggered, the build is paused and the Hukm is re-evaluated before Monday.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where in our last sprint did we ship something based on a single quadrant, and what would it have cost us if we had been wrong – both in wasted engineering hours (Hifz al-Mal) and in misleading data that now pollutes our model (Hifz al-Aql)?**
@@ -0,0 +1,125 @@
 ---
 ### Principle #3: Stakeholder Consultation — Shura as Discovery
 **Maqasid:** Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice  
 **Framework:** Shura Quadrant — Users / Team / Business / Regulators
 ---
 ## 1. THE SCENARIO
 You’re the Product Lead at a growing fintech startup. Your CEO walks into your desk, coffee in hand, and asks: “Why are we building this feature? And whose voice are we listening to?” You open your notebook. The Mujtahid in you asks: *“What is the hukm of consulting stakeholders? What is the maqsad behind their input? And what happens when their voices conflict — whose daleel carries weight?”* The CEO isn’t waiting for theory. She wants a decision by end of week. You need a framework that turns consultation into discovery, not performative noise.
 ---
 ## 2. DISCOVERY (ISTIQSA’)
 **PRODUCT_LEAD:**  
 Continuous Discovery starts with a clear Opportunity Solution Tree. Your CEO’s question is a gift — it forces you to map the problem space. Who are your stakeholders? Users, engineers, compliance, finance, the CEO herself. Each sits in a different branch of the tree. Your job is not to collect opinions but to uncover the underlying *jobs to be done* for each stakeholder.
 - **Users:** What outcome do they want from this feature? (e.g., faster checkout, lower fees)
 - **Team (engineers, design):** What technical or process constraints do they see? (e.g., legacy API, sprint capacity)
 - **Business (CEO, finance):** What metric moves? (e.g., conversion rate, LTV)
 - **Regulators (legal, compliance):** What risk must be mitigated? (e.g., KYC, data privacy)
 Run a **Shura Quadrant** mapping exercise this week. Draw four boxes. Populate them with the *primary job* each stakeholder is trying to get done *through you*. Then ask: *Which box is empty?* That’s where discovery is needed.
 **MUJTAHID:**  
 In Usul al-Fiqh, *Istiqsa’* (comprehensive investigation) is the systematic search for all relevant evidence before issuing a ruling. Shura is not a brainstorming session — it’s a *method of evidence gathering*. The Prophet ﷺ consulted his Companions on matters where revelation was silent, not to poll feelings but to surface *valid maqasid* (purposes) and *masalih* (benefits).
 Your fintech feature request is a *mas’ala* (question). The stakeholders are *ahl al-shura* — people with relevant knowledge, not equal weight. The Mujtahid’s question: *What is the maqsad behind each stakeholder’s voice? Is it Hifz al-Mal (preservation of wealth)? Hifz al-Nafs (safety)? Hifz al-Aql (sound judgment)?*
 - **Users:** Their voice protects *Hifz al-Mal* (fair pricing, no exploitation) and *Hifz al-Karama* (they are not just data points).
 - **Team:** Their voice protects *Hifz al-Aql* (technical soundness, avoid harm from rushed code).
 - **Business:** Their voice protects *Hifz al-Mal* (sustainability, growth) but can become *gharar* (uncertainty) if over-prioritized.
 - **Regulators:** Their voice protects *Hifz al-Din* (contractual validity, riba avoidance) and *Hifz al-Nafs* (fraud prevention).
 The maqsad of Shura is not consensus — it is *istiqsa’ of masalih and mafasid*. You must discover whose input is *dareuri* (essential) vs *hajiyyat* (needed) vs *tahsiniyyat* (nice-to-have). The empty quadrant is a *mafsada* waiting to happen.
 ---
 ## 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Evidence comes in two flavors: quantitative (metrics, A/B tests, analytics) and qualitative (interviews, observation, support tickets). Your CEO wants a decision — but the feature request is likely based on a single data point (e.g., “our competitor has it”). That’s *zanni* (speculative) evidence at best.
 Build your evidence stack:
 - **Quantitative:** Funnel drop-off rates, feature usage heatmaps, survey NPS segmented by stakeholder group. *What does the data say about the problem’s prevalence?*
 - **Qualitative:** 5 user interviews this week, 2 stakeholder shadow sessions (e.g., sit with compliance during a manual review). *What story does the data not tell?*
 When stakeholders conflict (e.g., users want speed, compliance wants more checks), weight evidence by *frequency, severity, and reversibility*. A 2% conversion loss from adding a step is *zanni* until you validate it with a cheap experiment. A regulatory fine of $10M is *qati’* (definitive) — it must be addressed first.
 **MUJTAHID:**  
 Daleel in Usul is ranked: *Qati’ al-Thubut wa Qati’ al-Dalala* (definitive source and meaning) vs *Zanni* in either. In Shura, stakeholder input is rarely *qati’*. It is *zanni* evidence that must be weighed.
 - **Qati’ evidence:** Explicit regulatory requirements, binding contracts, clear user harm (e.g., bug causes financial loss). These override everything.
 - **Zanni evidence:** CEO’s strategic hunch, engineer’s “I think this is easier,” user’s stated preference (which may differ from behavior).
 The Mujtahid uses **tarjih** (preponderance) rules:
 1. **Who holds the burden of proof?** The stakeholder advocating a change must bring *daleel*. If they say “competitor does it,” that’s *zanni* — insufficient.
 2. **What is the maqsad?** If the feature protects *Hifz al-Din* (e.g., ensuring riba-free transactions), it takes precedence over *Hifz al-Mal* (revenue).
 3. **Sad al-Dhara’i* (blocking the means to harm):** If a feature opens a path to *mafsada* (e.g., easier fraud), it is avoided even if users request it.
 4. **Istishab (presumption of continuity):** Assume the current state is valid until evidence proves otherwise. Don’t build a feature just because someone asked — the default is *no change*.
 Use a simple **Tarjih Matrix**: For each stakeholder input, assign a score (1-3) for *Qati’/Zanni*, *Maqsad weight* (Daruri=3, Hajji=2, Tahsini=1), and *Mafsada risk* (high=3, medium=2, low=1). The highest total wins — but only if the maqsad is preserved.
 ---
 ## 4. SHURA
 **PRODUCT_LEAD:**  
 Shura is not a meeting. It is a structured discovery ritual. You don’t just “ask stakeholders what they want” — you build a **Shura Cadence**:
 - **Weekly 30-min sync** with each quadrant (Users, Team, Business, Regulators). Use a consistent format: *“What problem are we solving? What evidence do you have? What outcome do you need?”*
 - **Monthly Shura Council** — one hour, all four quadrants present. Each presents their top opportunity (backed by evidence). The goal is not to vote but to *surface trade-offs*.
 - **Record dissent explicitly.** When a stakeholder disagrees, write their dissent and the *daleel* they offered. This is *tadwin al-shura* — documenting consultation. It protects *Hifz al-Karama*: their voice was heard, weighted, and preserved.
 **MUJTAHID:**  
 The Mujtahid consults by *tamyiz* (discernment), not democracy. The Prophet ﷺ consulted Badr strategy with the Companions, but the final decision was his. Shura is advisory, not binding — but the advisor’s dignity is sacred.
 How to consult as a Mujtahid PM:
 1. **Start with the maqsad.** Open the Shura by stating: *“We are here to protect $MAQSAD for $STAKEHOLDER. What evidence do you have that $FEATURE serves or harms this?”*
 2. **Weight by expertise, not hierarchy.** The engineer’s technical feasibility is *zanni* but high weight in that domain. The CEO’s strategic vision is *zanni* but high weight in market context. The user’s pain is *zanni* but weight increases with frequency.
 3. **Use the Shura Quadrant to identify gaps.** If only Business speaks, ask: *“Where is the user’s voice?”* Silence is also a signal — it may indicate *hifz al-Karama* is being violated (their input wasn’t solicited).
 4. **End with a ruling, not a poll.** After gathering all input, you (the Product Lead / Mujtahid) issue a *hukm*: “We will proceed with $DECISION, based on $DALEEL, with $SHURUT (conditions), and $MUNKATHIRAT (rollback triggers).” Record the reasoning. This is *tadwin al-ijtihad*.
 Shura is the discovery engine. When done right, it transforms stakeholder consultation from a political chore into a rigorous, dignity-preserving investigation of what is *khayr* (good) for the product and its people.
 *End of Part 1. Principle, Protocol, and Retrospective continue in Part 2.*## THE PRINCIPLE (HUKM)
 **HUKM:** We will build a recurring, structured Shura Council for every major product decision, with rotating representation from Users, Team, Business, and Regulators, and we will publish a summary of input and outcomes.
 **DALEEL:** Discovery interviews across 12 stakeholder interviews revealed that 8 felt their voice was either ignored or collected too late. Quantitative survey (n=50) showed 74% of stakeholders would increase trust with a formal consultation process. Maqasid analysis confirms that Hifz al-Karama (dignity) is violated when stakeholders are informed after decisions are locked. Qiyas: the Prophet ﷺ consulted even in minor matters (Khandaq, changing strategy based on Salman al-Farsi’s input). The daleel is strong: recurring Shura preserves dignity AND improves decision quality.
 **MAQSAD:** Hifz al-Karama – the preservation of stakeholder dignity through genuine voice, which is a necessary condition for trust, alignment, and sustained collaboration. Secondary Maqasid: Hifz al-Mal (business outcomes improve when blind spots are surfaced early).
 **SHURUT:**
 - The Shura Council must include at least one representative from each quadrant (Users, Team, Business, Regulators) per decision.
 - A written “Shura Brief” (problem statement, constraints, options) must be distributed 48 hours before the session.
 - The Product Manager must explain how each piece of input was used or why it was not used, and publish this in a public log.
 - Rollback trigger: If any quadrant misses two consecutive sessions, the decision is paused until they are represented.
 **MUNKATHIRAT:**
 - When stakeholder input is never referenced in the final decision document (nullifies dignity).
 - When sessions become monologues from the product team (no genuine listening).
 - When the same individuals dominate every session without rotation (entrenchment, not shura).
 ---
 ## THE PROTOCOL
 **STEP 1:** This sprint, identify the next major product decision (e.g., feature prioritization, pricing change, or sunsetting a module). Draft a one-page Shura Brief with the problem, three options, and one clear question: “What would you do if you were me?” Share it with at least one person from each quadrant by Wednesday.
 **STEP 2:** Hold a 45-minute Shura session on Thursday. Start with the brief, then each quadrant speaks uninterrupted for 5 minutes. Take verbatim notes. End with: “I will share my decision and how your input shaped it by Monday.”
 **STEP 3:** By Monday, publish the decision log in a visible place (Slack, wiki, or product board). Include: what we decided, which inputs changed our thinking, which inputs we deprioritized and why. Then schedule the next Shura session two weeks out.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **When did you last change a product decision because a stakeholder disagreed with you?** If you can’t remember, your Shura is performative. Dignity is not about being heard—it’s about being able to change the outcome. The real test of Hifz al-Karama is whether your product roadmap has scars from stakeholder voice.
@@ -0,0 +1,92 @@
 ---
 ### Principle #3: Stakeholder Consultation — Shura as Discovery
 **Maqasid:** Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice  
 **Framework:** Shura Quadrant — Users / Team / Business / Regulators
 ---
 ## 1. THE SCENARIO
 You’re the Product Lead at a growing fintech startup. Your CEO walks into your desk, coffee in hand, and asks: “Why are we building this feature? And whose voice are we listening to?” You open your notebook. The Mujtahid in you asks: *“What is the hukm of consulting stakeholders? What is the maqsad behind their input? And what happens when their voices conflict — whose daleel carries weight?”* The CEO isn’t waiting for theory. She wants a decision by end of week. You need a framework that turns consultation into discovery, not performative noise.
 ---
 ## 2. DISCOVERY (ISTIQSA’)
 **PRODUCT_LEAD:**  
 Continuous Discovery starts with a clear Opportunity Solution Tree. Your CEO’s question is a gift — it forces you to map the problem space. Who are your stakeholders? Users, engineers, compliance, finance, the CEO herself. Each sits in a different branch of the tree. Your job is not to collect opinions but to uncover the underlying *jobs to be done* for each stakeholder.
 - **Users:** What outcome do they want from this feature? (e.g., faster checkout, lower fees)
 - **Team (engineers, design):** What technical or process constraints do they see? (e.g., legacy API, sprint capacity)
 - **Business (CEO, finance):** What metric moves? (e.g., conversion rate, LTV)
 - **Regulators (legal, compliance):** What risk must be mitigated? (e.g., KYC, data privacy)
 Run a **Shura Quadrant** mapping exercise this week. Draw four boxes. Populate them with the *primary job* each stakeholder is trying to get done *through you*. Then ask: *Which box is empty?* That’s where discovery is needed.
 **MUJTAHID:**  
 In Usul al-Fiqh, *Istiqsa’* (comprehensive investigation) is the systematic search for all relevant evidence before issuing a ruling. Shura is not a brainstorming session — it’s a *method of evidence gathering*. The Prophet ﷺ consulted his Companions on matters where revelation was silent, not to poll feelings but to surface *valid maqasid* (purposes) and *masalih* (benefits).
 Your fintech feature request is a *mas’ala* (question). The stakeholders are *ahl al-shura* — people with relevant knowledge, not equal weight. The Mujtahid’s question: *What is the maqsad behind each stakeholder’s voice? Is it Hifz al-Mal (preservation of wealth)? Hifz al-Nafs (safety)? Hifz al-Aql (sound judgment)?*
 - **Users:** Their voice protects *Hifz al-Mal* (fair pricing, no exploitation) and *Hifz al-Karama* (they are not just data points).
 - **Team:** Their voice protects *Hifz al-Aql* (technical soundness, avoid harm from rushed code).
 - **Business:** Their voice protects *Hifz al-Mal* (sustainability, growth) but can become *gharar* (uncertainty) if over-prioritized.
 - **Regulators:** Their voice protects *Hifz al-Din* (contractual validity, riba avoidance) and *Hifz al-Nafs* (fraud prevention).
 The maqsad of Shura is not consensus — it is *istiqsa’ of masalih and mafasid*. You must discover whose input is *dareuri* (essential) vs *hajiyyat* (needed) vs *tahsiniyyat* (nice-to-have). The empty quadrant is a *mafsada* waiting to happen.
 ---
 ## 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Evidence comes in two flavors: quantitative (metrics, A/B tests, analytics) and qualitative (interviews, observation, support tickets). Your CEO wants a decision — but the feature request is likely based on a single data point (e.g., “our competitor has it”). That’s *zanni* (speculative) evidence at best.
 Build your evidence stack:
 - **Quantitative:** Funnel drop-off rates, feature usage heatmaps, survey NPS segmented by stakeholder group. *What does the data say about the problem’s prevalence?*
 - **Qualitative:** 5 user interviews this week, 2 stakeholder shadow sessions (e.g., sit with compliance during a manual review). *What story does the data not tell?*
 When stakeholders conflict (e.g., users want speed, compliance wants more checks), weight evidence by *frequency, severity, and reversibility*. A 2% conversion loss from adding a step is *zanni* until you validate it with a cheap experiment. A regulatory fine of $10M is *qati’* (definitive) — it must be addressed first.
 **MUJTAHID:**  
 Daleel in Usul is ranked: *Qati’ al-Thubut wa Qati’ al-Dalala* (definitive source and meaning) vs *Zanni* in either. In Shura, stakeholder input is rarely *qati’*. It is *zanni* evidence that must be weighed.
 - **Qati’ evidence:** Explicit regulatory requirements, binding contracts, clear user harm (e.g., bug causes financial loss). These override everything.
 - **Zanni evidence:** CEO’s strategic hunch, engineer’s “I think this is easier,” user’s stated preference (which may differ from behavior).
 The Mujtahid uses **tarjih** (preponderance) rules:
 1. **Who holds the burden of proof?** The stakeholder advocating a change must bring *daleel*. If they say “competitor does it,” that’s *zanni* — insufficient.
 2. **What is the maqsad?** If the feature protects *Hifz al-Din* (e.g., ensuring riba-free transactions), it takes precedence over *Hifz al-Mal* (revenue).
 3. **Sad al-Dhara’i* (blocking the means to harm):** If a feature opens a path to *mafsada* (e.g., easier fraud), it is avoided even if users request it.
 4. **Istishab (presumption of continuity):** Assume the current state is valid until evidence proves otherwise. Don’t build a feature just because someone asked — the default is *no change*.
 Use a simple **Tarjih Matrix**: For each stakeholder input, assign a score (1-3) for *Qati’/Zanni*, *Maqsad weight* (Daruri=3, Hajji=2, Tahsini=1), and *Mafsada risk* (high=3, medium=2, low=1). The highest total wins — but only if the maqsad is preserved.
 ---
 ## 4. SHURA
 **PRODUCT_LEAD:**  
 Shura is not a meeting. It is a structured discovery ritual. You don’t just “ask stakeholders what they want” — you build a **Shura Cadence**:
 - **Weekly 30-min sync** with each quadrant (Users, Team, Business, Regulators). Use a consistent format: *“What problem are we solving? What evidence do you have? What outcome do you need?”*
 - **Monthly Shura Council** — one hour, all four quadrants present. Each presents their top opportunity (backed by evidence). The goal is not to vote but to *surface trade-offs*.
 - **Record dissent explicitly.** When a stakeholder disagrees, write their dissent and the *daleel* they offered. This is *tadwin al-shura* — documenting consultation. It protects *Hifz al-Karama*: their voice was heard, weighted, and preserved.
 **MUJTAHID:**  
 The Mujtahid consults by *tamyiz* (discernment), not democracy. The Prophet ﷺ consulted Badr strategy with the Companions, but the final decision was his. Shura is advisory, not binding — but the advisor’s dignity is sacred.
 How to consult as a Mujtahid PM:
 1. **Start with the maqsad.** Open the Shura by stating: *“We are here to protect $MAQSAD for $STAKEHOLDER. What evidence do you have that $FEATURE serves or harms this?”*
 2. **Weight by expertise, not hierarchy.** The engineer’s technical feasibility is *zanni* but high weight in that domain. The CEO’s strategic vision is *zanni* but high weight in market context. The user’s pain is *zanni* but weight increases with frequency.
 3. **Use the Shura Quadrant to identify gaps.** If only Business speaks, ask: *“Where is the user’s voice?”* Silence is also a signal — it may indicate *hifz al-Karama* is being violated (their input wasn’t solicited).
 4. **End with a ruling, not a poll.** After gathering all input, you (the Product Lead / Mujtahid) issue a *hukm*: “We will proceed with $DECISION, based on $DALEEL, with $SHURUT (conditions), and $MUNKATHIRAT (rollback triggers).” Record the reasoning. This is *tadwin al-ijtihad*.
 Shura is the discovery engine. When done right, it transforms stakeholder consultation from a political chore into a rigorous, dignity-preserving investigation of what is *khayr* (good) for the product and its people.
 *End of Part 1. Principle, Protocol, and Retrospective continue in Part 2.*
@@ -0,0 +1,34 @@
 ## THE PRINCIPLE (HUKM)
 **HUKM:** We will build a recurring, structured Shura Council for every major product decision, with rotating representation from Users, Team, Business, and Regulators, and we will publish a summary of input and outcomes.
 **DALEEL:** Discovery interviews across 12 stakeholder interviews revealed that 8 felt their voice was either ignored or collected too late. Quantitative survey (n=50) showed 74% of stakeholders would increase trust with a formal consultation process. Maqasid analysis confirms that Hifz al-Karama (dignity) is violated when stakeholders are informed after decisions are locked. Qiyas: the Prophet ﷺ consulted even in minor matters (Khandaq, changing strategy based on Salman al-Farsi’s input). The daleel is strong: recurring Shura preserves dignity AND improves decision quality.
 **MAQSAD:** Hifz al-Karama – the preservation of stakeholder dignity through genuine voice, which is a necessary condition for trust, alignment, and sustained collaboration. Secondary Maqasid: Hifz al-Mal (business outcomes improve when blind spots are surfaced early).
 **SHURUT:**
 - The Shura Council must include at least one representative from each quadrant (Users, Team, Business, Regulators) per decision.
 - A written “Shura Brief” (problem statement, constraints, options) must be distributed 48 hours before the session.
 - The Product Manager must explain how each piece of input was used or why it was not used, and publish this in a public log.
 - Rollback trigger: If any quadrant misses two consecutive sessions, the decision is paused until they are represented.
 **MUNKATHIRAT:**
 - When stakeholder input is never referenced in the final decision document (nullifies dignity).
 - When sessions become monologues from the product team (no genuine listening).
 - When the same individuals dominate every session without rotation (entrenchment, not shura).
 ---
 ## THE PROTOCOL
 **STEP 1:** This sprint, identify the next major product decision (e.g., feature prioritization, pricing change, or sunsetting a module). Draft a one-page Shura Brief with the problem, three options, and one clear question: “What would you do if you were me?” Share it with at least one person from each quadrant by Wednesday.
 **STEP 2:** Hold a 45-minute Shura session on Thursday. Start with the brief, then each quadrant speaks uninterrupted for 5 minutes. Take verbatim notes. End with: “I will share my decision and how your input shaped it by Monday.”
 **STEP 3:** By Monday, publish the decision log in a visible place (Slack, wiki, or product board). Include: what we decided, which inputs changed our thinking, which inputs we deprioritized and why. Then schedule the next Shura session two weeks out.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **When did you last change a product decision because a stakeholder disagreed with you?** If you can’t remember, your Shura is performative. Dignity is not about being heard—it’s about being able to change the outcome. The real test of Hifz al-Karama is whether your product roadmap has scars from stakeholder voice.
@@ -0,0 +1,22 @@
 10% of users using workarounds** (e.g., converting to fiat immediately to avoid holding crypto), the experiment is terminated because it indicates the feature does not serve its intended purpose.
 ---
 ## THE PROTOCOL
 **STEP 1: THIS SPRINT – SECURE THE FATWA**  
 Write a one‑page executive summary of the crypto‑trading proposal, including the exact token mechanics, smart contract details, and user flow. Submit it to the Shariah board with a deadline of 10 business days. Prepare a sign‑off document that explicitly states the permissible conditions (e.g., no leverage, no interest, instant settlement). If the board demands changes, iterate within the sprint.
 **STEP 2: BUILD THE REVERSIBLE INFRASTRUCTURE**  
 Engineers implement a feature flag toggling the entire crypto module. Write a rollback script that can reverse any pending transactions and restore the previous app state within 60 minutes. Document the rollback procedure and assign an on‑call engineer for the beta period. Test the flag and script in staging with simulated transactions.
 **STEP 3: LAUNCH THE BETA AND MONITOR DAILY**  
 Invite the first 100 users from a waitlist (pre‑qualified for high trust). Send them a one‑time consent screen with a summary of the Shariah board’s ruling and a “I understand the risks” checkbox. Monitor daily: log every transaction, flag any that deviate from the approved mechanics, and run a daily compliance check against the Shurut. At the end of two weeks, hold a retrospective before deciding on broader rollout.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What single assumption about our users’ religious commitment did we make that, if wrong, would invalidate our entire decision?**
 If the assumption is that users will accurately self‑report when they feel a transaction is impermissible, but in reality they stay silent out of fear of missing out, then our “zero complaints” metric becomes meaningless. We would ship a feature that violates Hifz al‑Din while believing it is safe. The uncomfortable question: Do we truly know our users’ threshold for religious compromise, or are we relying on a proxy that can easily break? Next sprint, add a post‑transaction satisfaction survey that explicitly asks: “Did this transaction feel in line with your Islamic values?” Use the answer to calibrate our Shurut, not just as a checkmark.
@@ -0,0 +1,84 @@
 # PRINCIPLE #4: THE PRODUCT DECISION — THE PRINCIPLE AS DEFINITION OF DONE
 **Maqsad:** Hifz al-Din (Preservation of Purpose)  
 **Framework:** Decision Quadrant — Reversible vs Irreversible / High Stakes vs Low Stakes / Data-Rich vs Data-Poor  
 **Core Insight:** The *hukm* itself is the Definition of Done. Not a checklist. Not a ship date. The principle.
 ---
 ## 1. THE SCENARIO
 You’re the Product Lead at a growing fintech startup. Your CEO storms into your weekly sync. “We’re shipping the instant-payout feature next sprint. Marketing has already announced it. Engineering says two weeks. Go.”
 You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *Is this reversible? What’s the evidence?*
 Your CEO expects a simple “yes.” But you know: a feature launched without a principled Definition of Done is a fatwa issued without daleel. It binds the team, the user, and the business — sometimes irreversibly.
 ---
 ## 2. DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:** Let’s start with the problem. The CEO says “instant payouts.” That’s a solution, not a job. What’s the Job to Be Done? “I need my money now because my rent is due tomorrow and I can’t wait three business days.” That’s a JTBD: *Help me access my earned wages immediately when I face an urgent cash need.*
 Draw an Opportunity Solution Tree. Root: “Users abandon our platform because payout speed is slower than competitors.” First branch: “Reduce payout delay.” Second branch: “Increase trust in timing.” Third branch: “Provide emergency liquidity.” The CEO jumped to a solution (instant payouts) without exploring the tree. We need to climb back up.
 **MUJTAHID:** *Istiqsa’* means exhaustive investigation of the problem space. Before we issue a *hukm*, we must determine the *maqsad* — the intended purpose. What is the *maqsad* of this feature? *Hifz al-Mal* (preservation of wealth)? Yes — faster access to money. But also *Hifz al-Nafs* (preservation of life) — if a user can’t pay rent, that’s a threat to shelter and stability. And *Hifz al-Din* — the *din* of the product itself: its core purpose. What is the *din* of this fintech? “Help users manage their finances with dignity and speed.” Instant payouts preserves that purpose — if done right.
 Now classify the decision type. Use the **Decision Quadrant**:
 | | Reversible | Irreversible |
 |---|---|---|
 | **High Stakes** | Type 2 (reversible, high stakes) — e.g., a pricing experiment you can roll back | Type 1 (irreversible, high stakes) — e.g., changing the core payout architecture |
 | **Low Stakes** | Type 4 (reversible, low stakes) — e.g., button color | Type 3 (irreversible, low stakes) — rare, but e.g., deleting old data |
 Instant payouts is **Type 1** if it changes the underlying ledger system — irreversible because rolling back would break accounting records. It’s **Type 2** if it’s a front-end flow that can be toggled off. The CEO wants Type 2 speed but the engineering team suspects Type 1 complexity. We must discover which quadrant we’re in *before* we decide.
 **PRODUCT_LEAD:** So discovery isn’t about “should we build instant payouts?” It’s about understanding the decision type. If it’s Type 1 (irreversible, high stakes), we need heavy evidence. If Type 2, we can experiment. The Definition of Done for discovery is: *We know which quadrant this decision lives in.*
 **MUJTAHID:** Correct. In Usul al-Fiqh, the *hukm* changes based on the *shart* (condition). The *shart* here is reversibility. A reversible decision allows a *zanni* (speculative) ruling. An irreversible decision demands *qat’i* (certain) evidence. The *maqsad* (preservation of purpose) guides the threshold. If the feature threatens the product’s core *din* — e.g., by introducing fraud risk — then *sad al-dhara’i’* (blocking the means to harm) applies even before we have full evidence.
 ---
 ## 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:** Now we gather daleel. Quantitative: What percentage of users request instant payouts? What is the current payout speed? What is the churn rate for users who wait 3 days? Data from analytics: 12% of users have complained about payout speed. 30% of those churn within 30 days. That’s a signal.
 Qualitative: User interviews. “I needed the money for an emergency. I switched to a competitor that offered same-day.” That’s a JTBD insight. Also: “I’m worried about fees — if instant payouts cost me $5, I’d rather wait.” So the evidence is mixed — urgency exists, but price sensitivity is high.
 **MUJTAHID:** In Usul, we classify evidence by *wurud* (source) and *dalala* (indication). Quantitative data (analytics) is *zanni al-thubut* (speculative in origin) — it depends on instrumentation accuracy. User interviews are *zanni al-dalala* (speculative in meaning) — one user’s story doesn’t prove the whole population. Both are *zanni*.
 For a Type 2 (reversible) decision, *zanni* evidence suffices. But if this is Type 1 (irreversible, high stakes), we need *qat’i* evidence. What would be *qat’i*? A controlled experiment with statistical significance. Or a regulatory requirement (text of law is *qat’i al-thubut*). Or a clear *maslaha* (public benefit) that outweighs harm — but that’s a *ijtihad* judgment, not raw data.
 Handle uncertainty: The Mujtahid applies *istishab* — presumption of continuity. The current state (3-day payout) is presumed valid until evidence proves otherwise. The burden of proof is on the change. So we ask: “Do we have enough evidence to shift from the default?” The Product Lead asks: “Is the evidence strong enough to justify the risk of reversal?”
 **PRODUCT_LEAD:** That’s the same question. The evidence threshold depends on the quadrant. For a reversible experiment (Type 2), we need just enough evidence to justify the experiment — *zanni* is fine. For an irreversible architecture change (Type 1), we need *qat’i* evidence — multiple data sources, consistent user feedback, and a clear business case.
 Current evidence: 12% complaint rate, 30% churn among complainers. That’s a strong *zanni* signal. But we don’t know if instant payouts will actually reduce churn — correlation ≠ causation. We need to test. So the evidence points to Type 2 decision: run a controlled experiment with a subset of users.
 **MUJTAHID:** Agreed. The evidence does not reach *qat’i* for an irreversible change. Therefore, the *hukm* should be: proceed with a reversible experiment, with clear *shurut* (conditions) and *munkathirat* (nullifiers). The *maqsad* of *Hifz al-Din* (preserving the product’s purpose) requires that we do not harm the core experience. If the experiment introduces fraud, we must block it (*sad al-dhara’i’*). The Definition of Done for evidence gathering: *We have enough daleel to classify the decision quadrant and set the evidence threshold.*
 ---
 ## 4. SHURA
 **PRODUCT_LEAD:** Time to consult. I schedule a 30-minute decision sync with the CEO, Engineering Lead, and Head of Risk. I bring the Opportunity Solution Tree and the Decision Quadrant. I present the evidence: “We’re in Type 2 territory — reversible, high stakes. Here’s the data. Here’s the user story. Here’s the risk of fraud. I recommend an experiment on 10% of users for two weeks.”
 The CEO pushes back: “Marketing already announced. We can’t do a partial rollout.” The Engineering Lead says: “We can build a toggle, but the ledger change is one-way if we commit.” The Head of Risk says: “Fraud risk is high — we need to cap payouts at $200 per day.”
 **MUJTAHID:** Shura is not a vote. It is a structured consultation where each voice is weighted by *khibra* (expertise) and *taqwa* (responsibility). The Mujtahid listens to all, but the final *hukm* is based on evidence and *maqsad*, not consensus.
 Let’s weight:
 - CEO: Authority, but also bias toward speed. Weight: medium on evidence, high on strategy.
 - Engineering Lead: Technical feasibility. Weight: high on reversibility, low on user need.
 - Head of Risk: Expertise on harm prevention. Weight: high on *sad al-dhara’i’*.
 - Product Lead (you): Synthesis of evidence and *maqsad*. Weight: highest on the *hukm*.
 The dissent here is the CEO’s objection to partial rollout. That dissent must be recorded. The Mujtahid asks: “Can we satisfy the CEO’s need for a full launch while keeping reversibility?” Answer: Yes — launch to 100% but with a kill switch (toggle) and strict *shurut* (max payout, KYC check). That makes it reversible in practice.
 **PRODUCT_LEAD:** So the consultation produces a refined *shart*: full rollout, but with a toggle and risk controls. The Definition of Done for shura: *We have documented all stakeholder input, weighted it by expertise, and recorded dissent. The final decision is not a compromise — it’s a principled ruling based on evidence and maqsad.*
 **MUJTAHID:** Exactly. The *shura* itself is part of the *ijtihad*. It doesn’t replace the *hukm* — it informs it. The *hukm* will be: “Ship instant payouts as a reversible experiment with clear nullifiers.” That is the Definition of Done. Not a ship date. Not a feature list. A principle.
 ---
 *End of Part 1. Part 2 will deliver the Principle (Hukm/Daleel/Maqsad/Shurut/Munkathirat), the Protocol (3 steps), and the Retrospective (Muhasaba).*
@@ -0,0 +1,22 @@
 10% of users using workarounds** (e.g., converting to fiat immediately to avoid holding crypto), the experiment is terminated because it indicates the feature does not serve its intended purpose.
 ---
 ## THE PROTOCOL
 **STEP 1: THIS SPRINT – SECURE THE FATWA**  
 Write a one‑page executive summary of the crypto‑trading proposal, including the exact token mechanics, smart contract details, and user flow. Submit it to the Shariah board with a deadline of 10 business days. Prepare a sign‑off document that explicitly states the permissible conditions (e.g., no leverage, no interest, instant settlement). If the board demands changes, iterate within the sprint.
 **STEP 2: BUILD THE REVERSIBLE INFRASTRUCTURE**  
 Engineers implement a feature flag toggling the entire crypto module. Write a rollback script that can reverse any pending transactions and restore the previous app state within 60 minutes. Document the rollback procedure and assign an on‑call engineer for the beta period. Test the flag and script in staging with simulated transactions.
 **STEP 3: LAUNCH THE BETA AND MONITOR DAILY**  
 Invite the first 100 users from a waitlist (pre‑qualified for high trust). Send them a one‑time consent screen with a summary of the Shariah board’s ruling and a “I understand the risks” checkbox. Monitor daily: log every transaction, flag any that deviate from the approved mechanics, and run a daily compliance check against the Shurut. At the end of two weeks, hold a retrospective before deciding on broader rollout.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What single assumption about our users’ religious commitment did we make that, if wrong, would invalidate our entire decision?**
 If the assumption is that users will accurately self‑report when they feel a transaction is impermissible, but in reality they stay silent out of fear of missing out, then our “zero complaints” metric becomes meaningless. We would ship a feature that violates Hifz al‑Din while believing it is safe. The uncomfortable question: Do we truly know our users’ threshold for religious compromise, or are we relying on a proxy that can easily break? Next sprint, add a post‑transaction satisfaction survey that explicitly asks: “Did this transaction feel in line with your Islamic values?” Use the answer to calibrate our Shurut, not just as a checkmark.
@@ -0,0 +1,8 @@
 3 on ethics/confusion, kill feature. Every Monday morning, the PM runs a 10-minute “Muhāsaba check” — compare actual quadrant performance vs. predicted. If any quadrant drops below threshold, initiate rollback immediately.
 ---
 ## MUHĀSABA (RETROSPECTIVE)
 **Where did we let “Feasible” override “Viable” this sprint, and what wealth did that cost us?**  
 Force yourself to name one feature that was easy to build but ethically uncertain. Write down the exact dollar amount of engineering hours spent, plus the hidden cost of user trust lost. If you can’t find a single example, you haven’t been honest. The MVP Quadrant is not a rubber stamp — it’s a mirror. Look until you see the waste you chose to ignore. Then adjust your Shurūṭ for next sprint.
@@ -0,0 +1,18 @@
 ## PRINCIPLE #5: MINIMUM VIABLE PRINCIPLE — MVP AS MINIMUM VIABLE PRINCIPLE
 **Maqsad: Hifz al-Mal (Preservation of Wealth)**  
 *Framework: MVP Quadrant — Viable / Valuable / Usable / Feasible*  
 *Principle: MVP = Minimum Viable Principle*
 ---
 ### 1. THE SCENARIO
 You’re the Product Lead at a growing fintech startup. The team has been sprinting for six weeks on a new investment feature — fractional shares in halal stocks. The CEO walks into your stand-up: “Why are we building this feature? What’s the smallest thing we can ship to learn?” You open your notebook. The Product Lead in you starts sketching an MVP quadrant. But the Mujtahid in you asks a deeper question: *What is the hukm of this feature? What is the maqsad?* You realise that an MVP isn’t just about scope — it’s about defining a **minimum viable principle**: a conditional decision that balances risk, value, and Islamic compliance. You need to discover, evidence, and consult before you ship.
 ---
 ### 2. DISCOVERY (ISTIQSA’)
 **PRODUCT_LEAD:**  
 You pull out your Opportunity Solution Tree. The CEO’s question is an opportunity: “Fractional shares unlock wealth-building for low-income users.” The desired outcome: increase monthly active investors by 20% among users with 
@@ -0,0 +1,8 @@
 3 on ethics/confusion, kill feature. Every Monday morning, the PM runs a 10-minute “Muhāsaba check” — compare actual quadrant performance vs. predicted. If any quadrant drops below threshold, initiate rollback immediately.
 ---
 ## MUHĀSABA (RETROSPECTIVE)
 **Where did we let “Feasible” override “Viable” this sprint, and what wealth did that cost us?**  
 Force yourself to name one feature that was easy to build but ethically uncertain. Write down the exact dollar amount of engineering hours spent, plus the hidden cost of user trust lost. If you can’t find a single example, you haven’t been honest. The MVP Quadrant is not a rubber stamp — it’s a mirror. Look until you see the waste you chose to ignore. Then adjust your Shurūṭ for next sprint.
@@ -0,0 +1,30 @@
 0) for two consecutive sprints, the entire team halts feature work for one sprint to repay.  
 - If a single “quick fix” introduces a production incident, the debt is immediately reclassified as Reckless and must be fixed within 48 hours.  
 - If the team cannot articulate the *maslaha* (expected outcome) for a deliberate debt, the debt is automatically deemed Inadvertent and treated as *Israf*.
 ---
 ## THE PROTOCOL
 **STEP 1: Audit Your Debt Quadrant (This Week)**  
 Take 2 hours as a team. Open your bug tracker and code review history. For each recent shortcut, answer: “Did we plan it? Do we have a repayment date?” Assign it to one of the four quadrants. Create a single “Debt Ledger” document (Google Sheet or Notion) with columns: Type, Description, Date Incurred, Payoff Date, Interest Cost (estimated hours lost per month). *PRODUCT_LEAD:* Do this during your Tuesday tech review. *MUJTAHID:* This is *istiqsa’* (exhaustive examination) of your *Mal*—do not skip the “why” behind each entry.
 **STEP 2: Create a Debt Repayment Board (This Sprint)**  
 In your project management tool, add a “Debt Repayment” swimlane. Move all Reckless and Inadvertent items into it. Assign each item a story point value (based on effort to fix) and a DRI (directly responsible individual). Set a sprint goal: “Reduce Reckless debt by 30% (or at least fix the top 3 items).” *MUJTAHID:* This is *tazkiyah* (purification) of your codebase—treat it as a non-negotiable worship of trust (*amanah*).
 **STEP 3: Define a “Debt Covenant” for Future Sprints (This Sprint Retro)**  
 Write a 1-page team contract:  
 - “We will never merge a PR without logging its debt impact in the ledger.”  
 - “We will never approve a deliberate debt without a written payoff sprint ID.”  
 - “We will review the ledger every retro and escalate any overdue item.”  
 *PRODUCT_LEAD:* Make this part of your Definition of Done. *MUJTAHID:* This is your *shart* (condition) that prevents *israf* from recurring—treat it like a legal stipulation in a contract.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **One piercing question for your next retro:**  
 *“Where are we knowingly calling *Israf* an ‘investment’ because admitting it’s waste would force us to change our roadmap?”*
 *PRODUCT_LEAD:* Look at the last three features you shipped. How many shortcuts did you tell yourself were “necessary to hit the deadline”? Now ask: Did that deadline actually deliver better outcomes, or did you just shift the cost to next quarter?  
 *MUJTAHID:* The *mujtahid* knows that *niyyah* (intention) alone does not justify *israf*. If the shortcut wasted more time than it saved, it was *haram* even if you meant well. Measure the actual interest paid (hours lost to bugs, refactoring, onboarding friction). Compare it to the time you “saved.” If the debt’s interest exceeds its principal, you have committed *israf*—and the only repentance is repayment.
@@ -0,0 +1,31 @@
 ## PRINCIPLE #6: TECHNICAL DEBT — ISRAF VS INVESTMENT
 ### THE SCENARIO
 You’re the Product Lead at a growing fintech startup. Your CEO bursts into your weekly sync: “The team is screaming. The frontend is a mess. We need a six-month refactor. But our investors want the next feature in two weeks.” You open your notebook. The Mujtahid in you asks: “What is the hukm of this debt? What is the maqsad of the codebase?” Your engineers are burning out. Your users are experiencing bugs. The CEO smells opportunity cost. You smell israf. You need a ruling — not a roadmap.
 ---
 ### DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:** Let’s map the problem space. Draw an Opportunity Solution Tree. At the root: “Our codebase slows down delivery.” The opportunities: (1) Engineers spend 40% of sprint time fixing old bugs. (2) New features take 3x longer to ship than projected. (3) Onboarding crashes on legacy browsers. The solutions on the table: full refactor, incremental cleanup, freeze all features. But which opportunity do we actually solve? Run a JTBD interview: “When you push code, what job are you hiring the codebase to do?” Answer: “Get to production fast without breaking things.” Current codebase is failing that job. The real opportunity is not “refactor everything” — it’s “reduce the friction that makes every feature cost double.”
 **MUJTAHID:** Istiqsa’ begins with the maqasid. Hifz al-Mal — preservation of wealth. Technical debt is wealth stored in code. If that wealth decays (through bad architecture, duplication, untested paths), it becomes israf. Allah says: *“Indeed, the wasteful are brothers of the devils”* (Quran 17:27). Israf is spending without benefit or spending more than needed. But in Usul, not all debt is israf. Debt can be a means (wasila) to a greater maslaha. So first we define the problem space: What kind of technical debt are we facing? The Debt Quadrant: **Prudent Debt** (taken knowingly, with a plan to repay, for urgent feature that grows revenue) vs **Reckless Debt** (taken without plan, ignoring cost). **Deliberate Debt** (intentional, temporary shortcut with a ticket) vs **Inadvertent Debt** (accidental, from ignorance or lack of process). The israf is in reckless and inadvertent debt — they waste the mal of the company (engineering time, user trust). The maqsad of discovering the debt type is to know whether the current situation is a *darura* (necessity) or a *tahsin* (luxury refactor). The hukm of refactoring depends on the maqsad: are we preserving wealth or just polishing?
 ---
 ### EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:** Quantitative daleel first. Pull these metrics: Cycle time per feature. Bug reopen rate. Deployment frequency. Code churn (lines changed per feature). Measure the “interest rate” on the debt: How many hours per sprint are burned on unplanned work (bugs, rework)? If that number exceeds 20% of capacity, the debt is compounding. Qualitative daleel: Interview three engineers. Ask: “What’s one decision you made last month that you regret because you didn’t have time to do it right?” Then ask: “What would you fix first if you had one week?” Also interview one user: “Have you noticed anything getting slower or more broken over the last three months?” Triangulate. If engineers say “we need to rewrite everything” but users say “it works fine,” that’s a signal. If users are complaining, that’s a different daleel. Evidence hierarchy: user behavior (qati’ al-dalala — clear indicator) trumps engineer opinion (zanni — probabilistic). But engineer opinion is qati’ al-thubut (certain source) about the code’s internal state.
 **MUJTAHID:** In Istidlal, we rank evidence by strength. The highest daleel is the *maqsad* itself: Does this debt harm Hifz al-Mal? If the debt causes customer churn (loss of wealth) or blocks a revenue-generating feature (loss of opportunity), then it is israf. Next daleel: *qiyas* — analogize technical debt to a loan with riba. The “interest” on technical debt is the extra time each new feature costs. If the interest rate (extra cost per feature) is higher than the benefit of shipping fast, the debt becomes haram. But if the interest is low (e.g., a 5% overhead) and the feature brings 50% revenue growth, the debt is a valid *istihsan* (juristic preference for necessity). Measure the “interest” using the Product Lead’s metrics: extra hours per feature / baseline hours. That ratio is your *riba al-fadl* (excess). If it exceeds 30%, the debt is reckless. Also apply *sad al-dhara’i* (blocking the means to harm): If the team continues accumulating debt without a repayment plan, that path leads to israf. Block it now. But if the debt is deliberate and tracked (e.g., a ticket in the backlog with a deadline), it is permissible as a calculated risk. Write down the evidence in a table: Type of debt (prudent/reckless/deliberate/inadvertent), interest rate, maqsad harm, and ruling (halal/makruh/haram based on degree of israf).
 ---
 ### SHURA
 **PRODUCT_LEAD:** Call a cross-functional sync. Invite: CEO, CTO, lead engineer, one customer support rep, one user (volunteer). Agenda: “We have a codebase problem. Show the evidence above. Now ask each stakeholder: What is the outcome you care about most?” CEO: “Speed to market.” CTO: “Quality.” Engineer: “Less firefighting.” Support rep: “Fewer user complaints.” User: “Stability.” Now use the Shura methodology: list all priorities, find the intersection. The intersection is: “We need to ship features without breaking things.” That’s the maqsad. Record dissent: if the CTO insists on a full rewrite, note that as a minority opinion but do not discard it. Shura is not voting; it’s weighing evidence and seeking the strongest argument (tarjih). The Product Lead’s role: synthesize. Output: a prioritized list of debt items (not a scope of work) ranked by “harm to Hifz al-Mal.” The shura decides: “We will pay down only the debt that is directly causing user-facing bugs or blocking a high-value feature. Everything else remains tracked but untouched.”
 **MUJTAHID:** Shura in Usul is obligatory for those in authority (Quran 42:38). But the weight of each opinion depends on the *adalah* (trustworthiness) and *khibra* (expertise) of the speaker. The engineer has khibra on code cost. The CEO has khibra on business wealth. The user has khibra on experience. Do not give equal weight. The Mujtahid (you) must weigh: The engineer’s claim of “200 hours of debt” is a zanni estimate — it could be exaggerated. The user’s report of “app crashes every time I pay” is qati’ (certain) in effect. So the shura ruling leans toward fixing crash-causing debt first. Record all opinions, but the hukm is derived from the strongest daleel, not from consensus. Document the shura in a simple table: Stakeholder | Input | Weight (1-5 based on expertise and certainty) | Impact on Ruling. Then write a brief *ta’liq* (annotation) explaining why one view was preferred. This is your shura record — a living artifact for future retrospection.
 *(End of Part 1. Continue to Part 2: Principle, Protocol, Muhasaba.)*
@@ -0,0 +1,30 @@
 0) for two consecutive sprints, the entire team halts feature work for one sprint to repay.  
 - If a single “quick fix” introduces a production incident, the debt is immediately reclassified as Reckless and must be fixed within 48 hours.  
 - If the team cannot articulate the *maslaha* (expected outcome) for a deliberate debt, the debt is automatically deemed Inadvertent and treated as *Israf*.
 ---
 ## THE PROTOCOL
 **STEP 1: Audit Your Debt Quadrant (This Week)**  
 Take 2 hours as a team. Open your bug tracker and code review history. For each recent shortcut, answer: “Did we plan it? Do we have a repayment date?” Assign it to one of the four quadrants. Create a single “Debt Ledger” document (Google Sheet or Notion) with columns: Type, Description, Date Incurred, Payoff Date, Interest Cost (estimated hours lost per month). *PRODUCT_LEAD:* Do this during your Tuesday tech review. *MUJTAHID:* This is *istiqsa’* (exhaustive examination) of your *Mal*—do not skip the “why” behind each entry.
 **STEP 2: Create a Debt Repayment Board (This Sprint)**  
 In your project management tool, add a “Debt Repayment” swimlane. Move all Reckless and Inadvertent items into it. Assign each item a story point value (based on effort to fix) and a DRI (directly responsible individual). Set a sprint goal: “Reduce Reckless debt by 30% (or at least fix the top 3 items).” *MUJTAHID:* This is *tazkiyah* (purification) of your codebase—treat it as a non-negotiable worship of trust (*amanah*).
 **STEP 3: Define a “Debt Covenant” for Future Sprints (This Sprint Retro)**  
 Write a 1-page team contract:  
 - “We will never merge a PR without logging its debt impact in the ledger.”  
 - “We will never approve a deliberate debt without a written payoff sprint ID.”  
 - “We will review the ledger every retro and escalate any overdue item.”  
 *PRODUCT_LEAD:* Make this part of your Definition of Done. *MUJTAHID:* This is your *shart* (condition) that prevents *israf* from recurring—treat it like a legal stipulation in a contract.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **One piercing question for your next retro:**  
 *“Where are we knowingly calling *Israf* an ‘investment’ because admitting it’s waste would force us to change our roadmap?”*
 *PRODUCT_LEAD:* Look at the last three features you shipped. How many shortcuts did you tell yourself were “necessary to hit the deadline”? Now ask: Did that deadline actually deliver better outcomes, or did you just shift the cost to next quarter?  
 *MUJTAHID:* The *mujtahid* knows that *niyyah* (intention) alone does not justify *israf*. If the shortcut wasted more time than it saved, it was *haram* even if you meant well. Measure the actual interest paid (hours lost to bugs, refactoring, onboarding friction). Compare it to the time you “saved.” If the debt’s interest exceeds its principal, you have committed *israf*—and the only repentance is repayment.
@@ -0,0 +1,9 @@
 10%, rollback to cost-plus and iterate on value messaging.
 **Rollback trigger:** If churn exceeds 7% in the first week, pause the test and revert to previous pricing.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What would it take for us to cut our price by 50% and still sustain the business?** If we can’t answer that question honestly, we haven’t truly discovered the value we deliver — we’re just guessing. A just price isn’t the highest the market will bear; it’s the price that reflects genuine worth while preserving the relationship. Did our pricing increase trust or erode it? Did we protect the user’s wealth or exploit their need? The answer will surface in the churn rate and the unsaid resentment in every cancelled subscription.
@@ -0,0 +1,18 @@
 5% is acceptable.  
 3. **Islamic finance advisor** (or a scholar versed in muamalat). Present your evidence. Ask: ‘Does this pricing model fall under *ghabn*? What is the *qima al-mithl* for a digital product? Is profit-sharing (mudaraba) a better model for our premium tier?’ Document their answer as a *fatwa*-like guidance. This becomes your *daleel* for the final decision.”
 **MUJTAHID:**  
 “Shura is not a vote. It is a structured consultation to uncover blind spots and weigh evidence. The Prophet (peace be upon him) consulted his companions even when revelation was available. Why? To sharpen his understanding of context.  
 Methodology:  
 - *Istisharat* (seeking counsel) from three groups: experts (finance, engineering, Islamic law), stakeholders (CEO, user advocates), and those affected (users).  
 - *Tarjih* (weighing): When opinions conflict, give more weight to the *daleel* that is *qati* (definitive) over *zanni* (probable). For example, the user’s emotional response (‘I feel exploited’) is *zanni* but must be taken seriously. The Quranic prohibition is *qati*. So if a pricing model *feels* exploitative to a significant user segment, it likely violates the *maqsad* even if technically permissible.  
 - *Tadwin* (recording): Document every opinion with the reasoning. If you reject an opinion, write why. This protects you from later *ghurur* (arrogance) and allows for *muraja’a* (revision).  
 After shura, you should have:  
 - A clear *shart* (condition) for the pricing model (e.g., ‘Must not exceed 20% churn in first 90 days’).  
 - A *munkathir* (nullifier) statement: ‘If user fairness perception drops below 70%, roll back.’  
 - A prioritized list of *zanni* assumptions to test in the next sprint.”
 *End of Part 1 — proceed to Part 2: Principle, Protocol, Muhasaba.*
@@ -0,0 +1,9 @@
 10%, rollback to cost-plus and iterate on value messaging.
 **Rollback trigger:** If churn exceeds 7% in the first week, pause the test and revert to previous pricing.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What would it take for us to cut our price by 50% and still sustain the business?** If we can’t answer that question honestly, we haven’t truly discovered the value we deliver — we’re just guessing. A just price isn’t the highest the market will bear; it’s the price that reflects genuine worth while preserving the relationship. Did our pricing increase trust or erode it? Did we protect the user’s wealth or exploit their need? The answer will surface in the churn rate and the unsaid resentment in every cancelled subscription.
@@ -0,0 +1,126 @@
 ## Principle #8: Growth Metrics — Barakah vs Vanity Metrics
 **Maqsad: Hifz al-Nasl (Preservation of Lineage/Continuity) → Sustainable Growth**
 ---
 ### 1. THE SCENARIO
 You’re the Product Lead at a fast-growing fintech startup. Your CEO bursts into your office: “Why are we spending two sprints on a retention feature when we could be acquiring new users through paid ads? We need to hit 500K signups by Q4.” You open your notebook. The **Mujtahid** in you asks: *What is the hukm of this growth? What is the maqsad? Is this Barakah or vanity?* The **Product Lead** in you pulls out the AARRR funnel and an Opportunity Solution Tree. You know the CEO is chasing a vanity metric. But you need evidence—and a ruling—to redirect the ship. This is Principle #8.
 ---
 ### 2. DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:**  
 Let’s run Continuous Discovery. First, map the Opportunity Solution Tree. The desired outcome is *sustainable growth*—users who stay, invite their families, and build long-term financial health. The opportunity is: *Users who reach their first savings goal have 80% retention at 6 months.* The problem we’re solving is not “more signups” but “more users who complete the activation loop.”  
 We use Jobs-to-be-Done: What job is the user hiring our product to do? For our fintech app, the core job is *“Help me save consistently for my family’s future without stress.”* That’s **Hifz al-Nasl**—preserving continuity of lineage by protecting wealth and family stability. Growth that undermines that job (e.g., incentivizing debt or gambling-like features) is not Barakah.  
 So our discovery question: *What does growth with Barakah look like?* We interview 10 long-term users. They say: “I only recommend this app to my siblings because it actually helped me stop late fees.” “I don’t care about the referral bonus—I just want my brother to get out of debt too.” These users are our North Star. Their behavior shows that Barakah growth is **organic, trust-based, and aligned with family well-being**.
 **MUJTAHID:**  
 Istiqsa’ (exhaustive inquiry) begins with defining the problem space through the lens of **Maqasid al-Shariah**. The maqsad here is **Hifz al-Nasl**—preserving lineage and continuity. For a fintech product, this means the growth strategy must not lead to harm that breaks families (debt cycles, gambling, exploitation of the vulnerable).  
 Vanity metrics—total signups, raw MAU, paid acquisition numbers—are *gharar* (uncertainty) because they don’t reflect genuine benefit. They are like counting seeds that never sprout. Barakah growth is *increase that carries blessings*—it multiplies benefit without corrupting the intention.  
 We must map the **problem space** using the five Maqasid as filters:  
 - **Hifz al-Din** – Does this metric encourage ethical behavior?  
 - **Hifz al-Nafs** – Does it protect users from financial stress?  
 - **Hifz al-Aql** – Does it promote sound decision-making?  
 - **Hifz al-Mal** – Does it preserve wealth (not waste it on acquisition)?  
 - **Hifz al-Nasl** – Does it sustain family continuity?  
 Acquisition-only metrics fail Hifz al-Mal (waste) and Hifz al-Nasl (no continuity). Retention and referral metrics that come from genuine value—those have Barakah. Our istiqsa’ reveals that the real opportunity is not “more users” but “more users who stay and bring their family.” That is growth with Barakah.
 ---
 ### 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Let’s gather daleel—evidence. Quantitative: We pull cohort analysis. Users acquired through paid ads have a 30% 90-day retention. Users acquired through organic referrals have 70%. The median lifetime value (LTV) of a referred user is 3x higher. The paid users churn faster and cost more to acquire. That’s quantitative daleel that paid acquisition is *less Barakah* for this product.  
 Qualitative: User interviews reveal a pattern. “I downloaded because of a discount code, but I never used it after the first month.” “My sister told me this app helped her save for hajj—so I trust it.” The qualitative daleel confirms: Barakah growth is rooted in trust and real outcomes, not incentives.  
 We also look at *negative evidence*: churn spikes after promotional campaigns. Users who joined via paid ads are 50% more likely to delete the app within 7 days. This is *sad al-dhara’i*—blocking the means to harm. The harm here is wasted resources (israf) and misleading metrics that cause product teams to optimize for the wrong thing.
 **MUJTAHID:**  
 Now we apply the **daleel hierarchy** from Usul al-Fiqh.  
 - **Qati al-Thubut** (certain in transmission) – We don’t have revelation, but we have reliable analytics data from our own backend. That is strong evidence, albeit zanni (speculative) in interpretation.  
 - **Qati al-Dalala** (certain in meaning) – The meaning is clear: referred users stay longer. That’s a *qiyas* (analogy): if organic referral leads to higher retention, then investing in referral features is analogous to preserving wealth (Hifz al-Mal) and lineage (Hifz al-Nasl).  
 - **Istishab** (presumption of continuity) – We presume that the current pattern (paid users churn) will continue unless proven otherwise. So we should not scale paid acquisition without stronger evidence.  
 - **Maslaha** (public benefit) – Sustainable growth benefits the community: users save money, families are less stressed, the company survives long-term. Vanity growth harms the company (burnout, wasted budget) and users (poor experience).  
 What is “churn” in spiritual terms? Churn is *inqita’*—a severing of the relationship. The user leaves the blessing. A metric that measures “users who leave” is good, but more important is “users who stay and refer.” That is *iltizam*—commitment. The Barakah filter asks: *Does this metric measure genuine commitment or fleeting attention?*  
 **Evidence conclusion:** The daleel stack points away from paid acquisition as a primary growth lever. The strongest evidence (quant + qual + qiyas) supports investing in referral programs, activation improvements, and retention loops. Those metrics survive the Barakah filter.
 ---
 ### 4. SHURA
 **PRODUCT_LEAD:**  
 Time for Shura—structured consultation. I schedule a 90-minute cross-functional sync. Attendees: CEO, VP Marketing, Head of Engineering, Customer Support Lead, and two user researchers. I frame the decision: *We need to choose between doubling down on paid acquisition or building a referral + retention engine.*  
 First, I present the evidence from Discovery and Istidlal: the cohort data, user interview clips, and the Barakah filter. Then I open the floor.  
 - **CEO** argues: “We need scale to raise Series B. Paid ads are proven. Referrals take time.”  
 - **VP Marketing** pushes back: “Our paid CAC has risen 40% this quarter. The quality is dropping.”  
 - **Customer Support Lead** shares: “Most complaints come from paid users who don’t understand the product.”  
 - **User researcher** shows a clip: “I only used it because of the $5 bonus—now I forgot I even have the app.”  
 I weight the inputs based on proximity to evidence and expertise. The CEO’s opinion is important but based on a fear of missing growth targets. The Support Lead and researcher have direct daleel from users—their voices carry more weight. I record all opinions, including dissent.
 **MUJTAHID:**  
 Shura in Usul is not a democratic vote. It is a structured process to surface the strongest daleel and reach a ruling that serves the maqsad. The methodology:  
 1. **Identify the stakeholders** – Everyone present has a right to speak, but we weight their *wilaya* (authority) based on knowledge and proximity to the truth. The user researcher and support lead are the *shuhud* (witnesses) to reality.  
 2. **Record each opinion with its daleel** – CEO’s daleel: “We need speed to survive.” That is a maqsad of Hifz al-Mal (company survival), but it conflicts with Hifz al-Nasl (sustainable growth). We note the tension.  
 3. **Seek consensus (ijma’)** – We don’t have full consensus. The CEO dissents. We document that dissent as *mukhalafa* (opposition) but proceed based on the preponderance of evidence.  
 4. **Issue the ruling** – The Shura concludes## THE PRINCIPLE (HUKM)
 **HUKM:** We will only ship growth initiatives that pass the **Barakah Filter** — meaning the metric must be sustainable, user-centric, and directly tied to long-term retention (Hifz al-Nasl), not just short-term acquisition or vanity spikes.
 **DALEEL:**  
 - Quantitative: Cohort analysis shows that users acquired via “growth hacks” (discounts, viral loops, referral spam) have a 60% lower 90-day retention than organic users.  
 - Qualitative: User interviews reveal that aggressive referral prompts erode trust — “I felt like a product, not a person.”  
 - Qiyas (analogy): Just as riba (usury) creates apparent wealth but destroys real economic stability, vanity metrics create apparent growth but destroy product lineage (Nasl). The Barakah filter is analogous to *sad al-dhara’i* — blocking the means to harm, even if the means look beneficial in the short term.
 **MAQSAD:** Hifz al-Nasl (Preservation of Lineage / Continuity) — ensuring the product grows in a way that sustains its user community and value over generations, not just this quarter.
 **SHURUT:**  
 - Each growth experiment must define a **Barakah ratio**: (Retained users after 30 days) / (Total users acquired). Target: ≥ 40% for any experiment to continue.  
 - All growth tactics must be **opt-in, transparent, and avoid manipulation** (no dark patterns, no pre-checked boxes, no shame-based prompts).  
 - Monthly Barakah audit: Review AARRR funnel through the lens of *maslaha* (public benefit). If any stage has a negative *maslaha* score (e.g., activation causes user anxiety), the initiative is paused.  
 - Rollback trigger: If support tickets from growth features exceed 2% of new users within 7 days, automatically halt the experiment.
 **MUNKATHIRAT:**  
 - **Nullifier one:** Any growth tactic that violates user data privacy or consent (even if legal) — this nullifies the principle immediately. *Hifz al-‘aql* (preservation of intellect) requires informed choice.  
 - **Nullifier two:** If the growth metric improves but the core product experience (NPS, task success rate) declines more than 5% relative to baseline — the principle is broken.  
 - **Nullifier three:** If the team cannot articulate how the growth initiative serves a real user job (JTBD) beyond the company’s revenue goal — the principle is suspended until a clear *maqsad* is defined.
 ---
 ## THE PROTOCOL (3 Steps – This Sprint)
 **STEP 1: Audit Your Current Metrics**  
 *Monday–Tuesday.*  
 Pull your last 3 months of AARRR data. For each stage, write two numbers: the raw metric (vanilla) and the **Barakah-adjusted metric** (retention at 30 days ÷ acquisition cost or effort). Highlight any stage where the Barakah ratio is below 40%. Flag those as “vanity growth.” Discuss with your team: “Which of these are we secretly proud of but actually harming our Nasl?”
 **STEP 2: Build and Calibrate Your Barakah Filter**  
 *Wednesday–Thursday.*  
 Create a simple 3-question filter for every growth experiment before it ships:  
 1. Does this serve a real user job (JTBD) or just our revenue goal?  
 2. Can a user opt out without penalty?  
 3. Will this increase *thiqah* (trust) or just traffic?  
 If any answer is “no,” the experiment is blocked. Write the filter as a checklist in your PRD template.
 **STEP 3: Apply the Filter to One Upcoming Growth Experiment**  
 *Friday.*  
 Take your next planned growth initiative (e.g., a referral program, a discount campaign). Run it through the Barakah filter. If it passes, define the specific *shurut* (conditions) and *munkathirat* (rollback triggers) for that experiment. If it fails, redesign it — or kill it. Ship only if it passes. Measure the Barakah ratio after 30 days.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where are we currently optimizing for a vanity metric that we know — deep down — is misleading our team and eroding our product’s long-term trust?**
 Sit with that question for 10 minutes. No defensiveness. Write down the metric name. Then ask: *What would it cost us to drop this metric entirely and replace it with a Barakah-adjusted one?* The answer is usually far less than the cost of chasing ghosts.
@@ -0,0 +1,78 @@
 ## Principle #8: Growth Metrics — Barakah vs Vanity Metrics
 **Maqsad: Hifz al-Nasl (Preservation of Lineage/Continuity) → Sustainable Growth**
 ---
 ### 1. THE SCENARIO
 You’re the Product Lead at a fast-growing fintech startup. Your CEO bursts into your office: “Why are we spending two sprints on a retention feature when we could be acquiring new users through paid ads? We need to hit 500K signups by Q4.” You open your notebook. The **Mujtahid** in you asks: *What is the hukm of this growth? What is the maqsad? Is this Barakah or vanity?* The **Product Lead** in you pulls out the AARRR funnel and an Opportunity Solution Tree. You know the CEO is chasing a vanity metric. But you need evidence—and a ruling—to redirect the ship. This is Principle #8.
 ---
 ### 2. DISCOVERY (ISTIQSA')
 **PRODUCT_LEAD:**  
 Let’s run Continuous Discovery. First, map the Opportunity Solution Tree. The desired outcome is *sustainable growth*—users who stay, invite their families, and build long-term financial health. The opportunity is: *Users who reach their first savings goal have 80% retention at 6 months.* The problem we’re solving is not “more signups” but “more users who complete the activation loop.”  
 We use Jobs-to-be-Done: What job is the user hiring our product to do? For our fintech app, the core job is *“Help me save consistently for my family’s future without stress.”* That’s **Hifz al-Nasl**—preserving continuity of lineage by protecting wealth and family stability. Growth that undermines that job (e.g., incentivizing debt or gambling-like features) is not Barakah.  
 So our discovery question: *What does growth with Barakah look like?* We interview 10 long-term users. They say: “I only recommend this app to my siblings because it actually helped me stop late fees.” “I don’t care about the referral bonus—I just want my brother to get out of debt too.” These users are our North Star. Their behavior shows that Barakah growth is **organic, trust-based, and aligned with family well-being**.
 **MUJTAHID:**  
 Istiqsa’ (exhaustive inquiry) begins with defining the problem space through the lens of **Maqasid al-Shariah**. The maqsad here is **Hifz al-Nasl**—preserving lineage and continuity. For a fintech product, this means the growth strategy must not lead to harm that breaks families (debt cycles, gambling, exploitation of the vulnerable).  
 Vanity metrics—total signups, raw MAU, paid acquisition numbers—are *gharar* (uncertainty) because they don’t reflect genuine benefit. They are like counting seeds that never sprout. Barakah growth is *increase that carries blessings*—it multiplies benefit without corrupting the intention.  
 We must map the **problem space** using the five Maqasid as filters:  
 - **Hifz al-Din** – Does this metric encourage ethical behavior?  
 - **Hifz al-Nafs** – Does it protect users from financial stress?  
 - **Hifz al-Aql** – Does it promote sound decision-making?  
 - **Hifz al-Mal** – Does it preserve wealth (not waste it on acquisition)?  
 - **Hifz al-Nasl** – Does it sustain family continuity?  
 Acquisition-only metrics fail Hifz al-Mal (waste) and Hifz al-Nasl (no continuity). Retention and referral metrics that come from genuine value—those have Barakah. Our istiqsa’ reveals that the real opportunity is not “more users” but “more users who stay and bring their family.” That is growth with Barakah.
 ---
 ### 3. EVIDENCE (ISTIDLAL)
 **PRODUCT_LEAD:**  
 Let’s gather daleel—evidence. Quantitative: We pull cohort analysis. Users acquired through paid ads have a 30% 90-day retention. Users acquired through organic referrals have 70%. The median lifetime value (LTV) of a referred user is 3x higher. The paid users churn faster and cost more to acquire. That’s quantitative daleel that paid acquisition is *less Barakah* for this product.  
 Qualitative: User interviews reveal a pattern. “I downloaded because of a discount code, but I never used it after the first month.” “My sister told me this app helped her save for hajj—so I trust it.” The qualitative daleel confirms: Barakah growth is rooted in trust and real outcomes, not incentives.  
 We also look at *negative evidence*: churn spikes after promotional campaigns. Users who joined via paid ads are 50% more likely to delete the app within 7 days. This is *sad al-dhara’i*—blocking the means to harm. The harm here is wasted resources (israf) and misleading metrics that cause product teams to optimize for the wrong thing.
 **MUJTAHID:**  
 Now we apply the **daleel hierarchy** from Usul al-Fiqh.  
 - **Qati al-Thubut** (certain in transmission) – We don’t have revelation, but we have reliable analytics data from our own backend. That is strong evidence, albeit zanni (speculative) in interpretation.  
 - **Qati al-Dalala** (certain in meaning) – The meaning is clear: referred users stay longer. That’s a *qiyas* (analogy): if organic referral leads to higher retention, then investing in referral features is analogous to preserving wealth (Hifz al-Mal) and lineage (Hifz al-Nasl).  
 - **Istishab** (presumption of continuity) – We presume that the current pattern (paid users churn) will continue unless proven otherwise. So we should not scale paid acquisition without stronger evidence.  
 - **Maslaha** (public benefit) – Sustainable growth benefits the community: users save money, families are less stressed, the company survives long-term. Vanity growth harms the company (burnout, wasted budget) and users (poor experience).  
 What is “churn” in spiritual terms? Churn is *inqita’*—a severing of the relationship. The user leaves the blessing. A metric that measures “users who leave” is good, but more important is “users who stay and refer.” That is *iltizam*—commitment. The Barakah filter asks: *Does this metric measure genuine commitment or fleeting attention?*  
 **Evidence conclusion:** The daleel stack points away from paid acquisition as a primary growth lever. The strongest evidence (quant + qual + qiyas) supports investing in referral programs, activation improvements, and retention loops. Those metrics survive the Barakah filter.
 ---
 ### 4. SHURA
 **PRODUCT_LEAD:**  
 Time for Shura—structured consultation. I schedule a 90-minute cross-functional sync. Attendees: CEO, VP Marketing, Head of Engineering, Customer Support Lead, and two user researchers. I frame the decision: *We need to choose between doubling down on paid acquisition or building a referral + retention engine.*  
 First, I present the evidence from Discovery and Istidlal: the cohort data, user interview clips, and the Barakah filter. Then I open the floor.  
 - **CEO** argues: “We need scale to raise Series B. Paid ads are proven. Referrals take time.”  
 - **VP Marketing** pushes back: “Our paid CAC has risen 40% this quarter. The quality is dropping.”  
 - **Customer Support Lead** shares: “Most complaints come from paid users who don’t understand the product.”  
 - **User researcher** shows a clip: “I only used it because of the $5 bonus—now I forgot I even have the app.”  
 I weight the inputs based on proximity to evidence and expertise. The CEO’s opinion is important but based on a fear of missing growth targets. The Support Lead and researcher have direct daleel from users—their voices carry more weight. I record all opinions, including dissent.
 **MUJTAHID:**  
 Shura in Usul is not a democratic vote. It is a structured process to surface the strongest daleel and reach a ruling that serves the maqsad. The methodology:  
 1. **Identify the stakeholders** – Everyone present has a right to speak, but we weight their *wilaya* (authority) based on knowledge and proximity to the truth. The user researcher and support lead are the *shuhud* (witnesses) to reality.  
 2. **Record each opinion with its daleel** – CEO’s daleel: “We need speed to survive.” That is a maqsad of Hifz al-Mal (company survival), but it conflicts with Hifz al-Nasl (sustainable growth). We note the tension.  
 3. **Seek consensus (ijma’)** – We don’t have full consensus. The CEO dissents. We document that dissent as *mukhalafa* (opposition) but proceed based on the preponderance of evidence.  
 4. **Issue the ruling** – The Shura concludes
@@ -0,0 +1,49 @@
 ## THE PRINCIPLE (HUKM)
 **HUKM:** We will only ship growth initiatives that pass the **Barakah Filter** — meaning the metric must be sustainable, user-centric, and directly tied to long-term retention (Hifz al-Nasl), not just short-term acquisition or vanity spikes.
 **DALEEL:**  
 - Quantitative: Cohort analysis shows that users acquired via “growth hacks” (discounts, viral loops, referral spam) have a 60% lower 90-day retention than organic users.  
 - Qualitative: User interviews reveal that aggressive referral prompts erode trust — “I felt like a product, not a person.”  
 - Qiyas (analogy): Just as riba (usury) creates apparent wealth but destroys real economic stability, vanity metrics create apparent growth but destroy product lineage (Nasl). The Barakah filter is analogous to *sad al-dhara’i* — blocking the means to harm, even if the means look beneficial in the short term.
 **MAQSAD:** Hifz al-Nasl (Preservation of Lineage / Continuity) — ensuring the product grows in a way that sustains its user community and value over generations, not just this quarter.
 **SHURUT:**  
 - Each growth experiment must define a **Barakah ratio**: (Retained users after 30 days) / (Total users acquired). Target: ≥ 40% for any experiment to continue.  
 - All growth tactics must be **opt-in, transparent, and avoid manipulation** (no dark patterns, no pre-checked boxes, no shame-based prompts).  
 - Monthly Barakah audit: Review AARRR funnel through the lens of *maslaha* (public benefit). If any stage has a negative *maslaha* score (e.g., activation causes user anxiety), the initiative is paused.  
 - Rollback trigger: If support tickets from growth features exceed 2% of new users within 7 days, automatically halt the experiment.
 **MUNKATHIRAT:**  
 - **Nullifier one:** Any growth tactic that violates user data privacy or consent (even if legal) — this nullifies the principle immediately. *Hifz al-‘aql* (preservation of intellect) requires informed choice.  
 - **Nullifier two:** If the growth metric improves but the core product experience (NPS, task success rate) declines more than 5% relative to baseline — the principle is broken.  
 - **Nullifier three:** If the team cannot articulate how the growth initiative serves a real user job (JTBD) beyond the company’s revenue goal — the principle is suspended until a clear *maqsad* is defined.
 ---
 ## THE PROTOCOL (3 Steps – This Sprint)
 **STEP 1: Audit Your Current Metrics**  
 *Monday–Tuesday.*  
 Pull your last 3 months of AARRR data. For each stage, write two numbers: the raw metric (vanilla) and the **Barakah-adjusted metric** (retention at 30 days ÷ acquisition cost or effort). Highlight any stage where the Barakah ratio is below 40%. Flag those as “vanity growth.” Discuss with your team: “Which of these are we secretly proud of but actually harming our Nasl?”
 **STEP 2: Build and Calibrate Your Barakah Filter**  
 *Wednesday–Thursday.*  
 Create a simple 3-question filter for every growth experiment before it ships:  
 1. Does this serve a real user job (JTBD) or just our revenue goal?  
 2. Can a user opt out without penalty?  
 3. Will this increase *thiqah* (trust) or just traffic?  
 If any answer is “no,” the experiment is blocked. Write the filter as a checklist in your PRD template.
 **STEP 3: Apply the Filter to One Upcoming Growth Experiment**  
 *Friday.*  
 Take your next planned growth initiative (e.g., a referral program, a discount campaign). Run it through the Barakah filter. If it passes, define the specific *shurut* (conditions) and *munkathirat* (rollback triggers) for that experiment. If it fails, redesign it — or kill it. Ship only if it passes. Measure the Barakah ratio after 30 days.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where are we currently optimizing for a vanity metric that we know — deep down — is misleading our team and eroding our product’s long-term trust?**
 Sit with that question for 10 minutes. No defensiveness. Write down the metric name. Then ask: *What would it cost us to drop this metric entirely and replace it with a Barakah-adjusted one?* The answer is usually far less than the cost of chasing ghosts.
@@ -0,0 +1,57 @@
 CEO’s solution. But CEO’s outcome (reduce fraud complaints) is valid. The squad’s *what* should be: “Help users self-audit transactions to reduce fraud calls.” That serves the CEO’s outcome and the user’s job.
 **MUJTAHID:**  
 Shura in Islam is not a vote. It is *istishara* — seeking counsel from those with *‘ilm* and *hilm* (wisdom). The *mujtahid* (decision-maker) listens to all, then issues a *hukm*. Dissent must be recorded but does not block action.  
 Record the **dissent** from the Engineering Lead: “We will lose velocity building fraud alert first.” That becomes a *shart* (condition) for the decision: if velocity drops below X, revisit.  
 Now document the *shura* process in a log:  
 - Participants: CEO, Eng Lead, PM, User Researcher.  
 - Inputs: Outcome (reduce complaints), User JTBD (self-audit), Technical constraints (2 weeks vs 3 months).  
 - Weighted evidence: User research (2x weight), Engineering feasibility (1.5x), CEO outcome (1x).  
 - Decision: Squad *maqsad* = “Reduce fraud complaints by enabling self-audit via transaction history.”  
 - Dissent recorded: Eng Lead wants fraud alert; rationale noted. Condition: If after 4 weeks fraud complaints don’t drop, re-open shura.  
 This is *shura at scale* — not a committee of equals, but a structured consultation where the *wali al-amr* (Product Lead) holds final authority, bounded by the *maqsad* and *shurut*.
 ---
 *[End of Part 1 — Scenario, Discovery, Evidence, Shura. Continue to Part 2: Principle (Hukm), Protocol, Muhasaba.]*## THE PRINCIPLE (HUKM)
 **HUKM:** We will organize our product teams into autonomous squads with embedded Shura circles, where each squad owns a full opportunity space and makes binding decisions through structured consultation, not hierarchy.
 **DALEEL:** Three evidence streams converge. First, continuous discovery interviews across 12 teams showed that cross-functional squads with decision authority ship 3x faster and produce higher user satisfaction than functionally siloed groups. Second, the prophetic model of Shura at Medina—where the community was organized into small, autonomous units (e.g., the *nuqaba'*) that consulted regularly and then acted—demonstrates that preserving community (Hifz al-Nasl) requires distributed decision-making, not central command. Third, our own A/B test of squad vs. functional organization in the payments domain revealed a 40% reduction in time-to-learning and a 22% increase in team Net Promoter Score.
 **MAQSAD:** Hifz al-Nasl (Preservation of Community) is served directly. Squad Shura preserves the community of makers, users, and stakeholders by ensuring that every decision emerges from local, authentic consultation rather than remote authority. It also preserves the product’s community of users: squads stay close to their user segment, preventing the alienation that comes from one-size-fits-all product decisions. Secondary maqasid: Hifz al-Aql (intellectual property and sound reasoning) through diverse input; Hifz al-Mal (efficient resource use) through faster iteration.
 **SHURUT:**
 - Each squad must include at least one product manager, one designer, and two to three engineers (cross-functional minimum).
 - Every squad holds a weekly Shura huddle (45 min max) where all members have equal voice; decisions are recorded and shared with a Guild-level Shura for coherence.
 - Squads must publish their opportunity solution trees and weekly Shura notes to a shared repository — transparency is a *shart* (condition) for autonomy.
 - No squad may ship a change that violates the product’s North Star metric or the company’s ethical framework (Maslaha check) without escalating to the Guild Shura.
 **MUNKATHIRAT:**
 - If a squad’s opportunity solution tree goes unvisited by any user interview for two consecutive sprints, the Shura circle is invalidated and must be reconvened with fresh evidence.
 - If the Guild Shura observes that two or more squads are solving overlapping problems without coordination, the squads must merge or re-scope; continued overlap nullifies the autonomy principle.
 - Any squad that fails to meet its OKR threshold for two quarters will be dissolved and its members redistributed — autonomy is conditional on outcome accountability.
 ---
 ## THE PROTOCOL
 **STEP 1: Map your current org to the Org Quadrant (this sprint).**  
 Draw four boxes: Functional (teams by skill), Cross-Functional (teams by feature), Squad (teams by opportunity space), Guild/Chapter (cross-squad communities). Plot every team you have. Identify which teams are pure functional and which are already squad-like. For each functional team, list the top three opportunity spaces they touch. This map is your baseline. Deliverable: a single A3 page with the quadrant and annotations.
 **STEP 2: Select one opportunity space and form a pilot squad (next sprint).**  
 Pick the opportunity space with the highest user pain and the clearest JTBD (Jobs-to-be-Done). Pull one PM, one designer, two engineers from existing functional teams. Give them a single OKR: “Improve [metric] by X% in 8 weeks.” Declare them autonomous: they do not need VP approval for any decision that stays within their opportunity tree. They must, however, hold a Shura huddle every Wednesday at 10 AM sharp. No exceptions.
 **STEP 3: Run the pilot for 8 weeks, then run a Muhasaba retrospective.**  
 The pilot squad ships at least one experiment per week. The Guild Shura (composed of all squad leads) reviews the pilot’s opportunity solution tree biweekly. At week 8, answer: “Did the squad preserve community? Did it ship faster? Did users feel heard?” If the pilot clears all three Shurut (cross-functional composition, weekly Shura, transparent notes, no North Star violation), scale to a second squad. If any Munkathirat fire (e.g., no user interviews for two sprints), dissolve and try a different opportunity space.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What did we actually fear when we gave a squad full autonomy, and how much of that fear was rooted in evidence versus ego?**
 This question cuts to the heart of Hifz al-Nasl. Most leaders resist Squad Shura not because it fails empirically, but because it requires surrendering control. The community cannot be preserved by a single guardian; it must be preserved by a thousand small, responsible shuras. If your retrospective reveals that your hesitation was about authority, not outcomes, then the principle isn’t broken — your heart is. Fix that first.
@@ -0,0 +1,19 @@
 CEO’s solution. But CEO’s outcome (reduce fraud complaints) is valid. The squad’s *what* should be: “Help users self-audit transactions to reduce fraud calls.” That serves the CEO’s outcome and the user’s job.
 **MUJTAHID:**  
 Shura in Islam is not a vote. It is *istishara* — seeking counsel from those with *‘ilm* and *hilm* (wisdom). The *mujtahid* (decision-maker) listens to all, then issues a *hukm*. Dissent must be recorded but does not block action.  
 Record the **dissent** from the Engineering Lead: “We will lose velocity building fraud alert first.” That becomes a *shart* (condition) for the decision: if velocity drops below X, revisit.  
 Now document the *shura* process in a log:  
 - Participants: CEO, Eng Lead, PM, User Researcher.  
 - Inputs: Outcome (reduce complaints), User JTBD (self-audit), Technical constraints (2 weeks vs 3 months).  
 - Weighted evidence: User research (2x weight), Engineering feasibility (1.5x), CEO outcome (1x).  
 - Decision: Squad *maqsad* = “Reduce fraud complaints by enabling self-audit via transaction history.”  
 - Dissent recorded: Eng Lead wants fraud alert; rationale noted. Condition: If after 4 weeks fraud complaints don’t drop, re-open shura.  
 This is *shura at scale* — not a committee of equals, but a structured consultation where the *wali al-amr* (Product Lead) holds final authority, bounded by the *maqsad* and *shurut*.
 ---
 *[End of Part 1 — Scenario, Discovery, Evidence, Shura. Continue to Part 2: Principle (Hukm), Protocol, Muhasaba.]*
@@ -0,0 +1,39 @@
 ## THE PRINCIPLE (HUKM)
 **HUKM:** We will organize our product teams into autonomous squads with embedded Shura circles, where each squad owns a full opportunity space and makes binding decisions through structured consultation, not hierarchy.
 **DALEEL:** Three evidence streams converge. First, continuous discovery interviews across 12 teams showed that cross-functional squads with decision authority ship 3x faster and produce higher user satisfaction than functionally siloed groups. Second, the prophetic model of Shura at Medina—where the community was organized into small, autonomous units (e.g., the *nuqaba'*) that consulted regularly and then acted—demonstrates that preserving community (Hifz al-Nasl) requires distributed decision-making, not central command. Third, our own A/B test of squad vs. functional organization in the payments domain revealed a 40% reduction in time-to-learning and a 22% increase in team Net Promoter Score.
 **MAQSAD:** Hifz al-Nasl (Preservation of Community) is served directly. Squad Shura preserves the community of makers, users, and stakeholders by ensuring that every decision emerges from local, authentic consultation rather than remote authority. It also preserves the product’s community of users: squads stay close to their user segment, preventing the alienation that comes from one-size-fits-all product decisions. Secondary maqasid: Hifz al-Aql (intellectual property and sound reasoning) through diverse input; Hifz al-Mal (efficient resource use) through faster iteration.
 **SHURUT:**
 - Each squad must include at least one product manager, one designer, and two to three engineers (cross-functional minimum).
 - Every squad holds a weekly Shura huddle (45 min max) where all members have equal voice; decisions are recorded and shared with a Guild-level Shura for coherence.
 - Squads must publish their opportunity solution trees and weekly Shura notes to a shared repository — transparency is a *shart* (condition) for autonomy.
 - No squad may ship a change that violates the product’s North Star metric or the company’s ethical framework (Maslaha check) without escalating to the Guild Shura.
 **MUNKATHIRAT:**
 - If a squad’s opportunity solution tree goes unvisited by any user interview for two consecutive sprints, the Shura circle is invalidated and must be reconvened with fresh evidence.
 - If the Guild Shura observes that two or more squads are solving overlapping problems without coordination, the squads must merge or re-scope; continued overlap nullifies the autonomy principle.
 - Any squad that fails to meet its OKR threshold for two quarters will be dissolved and its members redistributed — autonomy is conditional on outcome accountability.
 ---
 ## THE PROTOCOL
 **STEP 1: Map your current org to the Org Quadrant (this sprint).**  
 Draw four boxes: Functional (teams by skill), Cross-Functional (teams by feature), Squad (teams by opportunity space), Guild/Chapter (cross-squad communities). Plot every team you have. Identify which teams are pure functional and which are already squad-like. For each functional team, list the top three opportunity spaces they touch. This map is your baseline. Deliverable: a single A3 page with the quadrant and annotations.
 **STEP 2: Select one opportunity space and form a pilot squad (next sprint).**  
 Pick the opportunity space with the highest user pain and the clearest JTBD (Jobs-to-be-Done). Pull one PM, one designer, two engineers from existing functional teams. Give them a single OKR: “Improve [metric] by X% in 8 weeks.” Declare them autonomous: they do not need VP approval for any decision that stays within their opportunity tree. They must, however, hold a Shura huddle every Wednesday at 10 AM sharp. No exceptions.
 **STEP 3: Run the pilot for 8 weeks, then run a Muhasaba retrospective.**  
 The pilot squad ships at least one experiment per week. The Guild Shura (composed of all squad leads) reviews the pilot’s opportunity solution tree biweekly. At week 8, answer: “Did the squad preserve community? Did it ship faster? Did users feel heard?” If the pilot clears all three Shurut (cross-functional composition, weekly Shura, transparent notes, no North Star violation), scale to a second squad. If any Munkathirat fire (e.g., no user interviews for two sprints), dissolve and try a different opportunity space.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **What did we actually fear when we gave a squad full autonomy, and how much of that fear was rooted in evidence versus ego?**
 This question cuts to the heart of Hifz al-Nasl. Most leaders resist Squad Shura not because it fails empirically, but because it requires surrendering control. The community cannot be preserved by a single guardian; it must be preserved by a thousand small, responsible shuras. If your retrospective reveals that your hesitation was about authority, not outcomes, then the principle isn’t broken — your heart is. Fix that first.
@@ -0,0 +1,8 @@
 30%, the teach loop is viable.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where is your product currently acting more like a *sadaqah ‘adiyah* (one-time charity) than a *sadaqah jariyah* (ongoing charity)?**  
 Be honest: list every feature that dies when you stop paying attention. Then ask yourself: *If I died tomorrow, would this product continue to benefit people without me?* If the answer is no, you have not built a legacy — you have built a job. The challenge is not to add more features, but to design the exit. A *Sadaqah Jariyah* product is one that makes its creators unnecessary. That is the ultimate measure of compound impact.
@@ -0,0 +1,59 @@
 $50/month have 6x lifetime value. Users who refer three friends have 2x retention. But what’s the *compound interest* on impact? Measure net promoter score (NPS) for “trust that this product serves my long-term good.” That’s your leading indicator.
 Qualitative: Run a diary study. Ask 20 users to log every time they feel their money is “doing good” beyond themselves. Code the responses. Themes emerge: *“I want my savings to mean something after I’m gone,” “I’d pay a small fee if it went to a cause I believe in,” “I don’t trust the bank to do good—I want control.”*
 **MUJTAHID:**  
 *Daleel* hierarchy: We need evidence that this feature is *maslaha* (public benefit) and not *munkar* (harm).  
 1. **Qati al-Thubut, Zanni al-Dalala:** The hadith on sadaqah jariyah is authentic (qati al-thubut) but its application to product features is interpretive (zanni al-dalala). So we need *qiyas* (analogy).  
 2. **Qiyas:** Compare a digital product that automates charitable giving to a physical endowment (waqf). The `'illah` (effective cause) is *continuity of benefit*. If a waqf building generates rent for a school, a product feature that auto-distributes micro-donations from savings generates ongoing benefit.  
 3. **Istihsan (juristic preference):** Allow innovation in delivery mechanism as long as the maqsad (preservation of mal and din) is served.  
 4. **Maslaha Mursalah (unrestricted benefit):** This feature does not contradict any text; it aligns with the maqsad of preserving wealth (mal) by making it fructify in the akhirah.
 **Evidence Prompt Applied:**  
 What is the “interest rate” on product impact? Calculate **Impact ROI**:  
 ```
 Impact ROI = (Total benefit accrued to users over 10 years) / (Cost to build + maintain)
 ```
 Example: A $50k feature that enables 10,000 users to each give $100/year to charity for 10 years = $10M in sadaqah. Impact ROI = 200x. That’s compound.
 Measure generational impact: Track *second-degree referrals*—users whose parents used your feature. If a user sets up a legacy account, and their child later uses the same feature, that’s generational compound.
 **Synthesis:**  
 Evidence supports building a “Legacy Savings” module. Quantitative data shows users with long-term trust stay longer. Qualitative data shows desire for afterlife impact. Islamic daleel validates the mechanism as sadaqah jariyah via qiyas on waqf. The `'illah` is continuity. The maqsad is preservation of din and mal.
 ---
 ### 4. SHURA (CONSULTATION)
 **PRODUCT_LEAD:**  
 Call a cross-functional sync. Invite Engineering, Legal, Compliance, and Customer Support.  
 - **Engineering:** “Can we build a rule engine that lets users set recurring charitable allocations from savings? Yes, but we need API integration with Islamic charities.”  
 - **Legal/Compliance:** “Are there regulatory implications for ‘estate planning’ features? We need to avoid giving financial advice. Frame it as a ‘giving tool’ not a will.”  
 - **Customer Support:** “Users will call confused. We need clear onboarding and a fatwa verification badge.”  
 Interview three religious scholars (or Shari’ah advisors) separately. Ask: *“Is this a valid form of sadaqah jariyah? What conditions must we meet?”* One scholar says: “The user must intend sadaqah at the time of setting up. The charity must be reputable. The mechanism must not involve riba or gharar.”
 **MUJTAHID:**  
 *Shura* in Usul al-Fiqh is not a vote; it’s a consultation that uncovers blind spots. The Mujtahid must weigh input by *adalah* (integrity) and *khibra* (expertise).  
 - Weight the scholar’s input highest (expertise in Shari’ah).  
 - Weight engineering input second (feasibility).  
 - Weight legal input third (regulatory risk).  
 Record dissent. One compliance officer says: *“This blurs the line between product and philanthropy. We might be seen as a non-profit.”* The Mujtahid notes this as a *shubha* (doubt) to address via *sad al-dhara’i* (blocking the means to harm). Solution: Clear disclaimers that the feature is a tool, not a charitable institution.
 **Shura Prompt Applied:**  
 How do you consult? Schedule a 90-minute session. Open with the maqsad: *“We want to build a product that becomes sadaqah jariyah. What do we need to make it valid, trustworthy, and scalable?”*  
 - Read aloud the hadith on sadaqah jariyah.  
 - Show the qiyas to waqf.  
 - Ask each stakeholder: *“What could go wrong? What are we missing?”*  
 Close by summarizing three **shurut** (conditions) that emerged from shura:  
 1. User must make intention (niyyah) at setup.  
 2. Charity recipient must be verified.  
 3. No riba in the underlying savings product.
 **End of Part 1.**
@@ -0,0 +1,8 @@
 30%, the teach loop is viable.
 ---
 ## MUHASABA (RETROSPECTIVE)
 **Where is your product currently acting more like a *sadaqah ‘adiyah* (one-time charity) than a *sadaqah jariyah* (ongoing charity)?**  
 Be honest: list every feature that dies when you stop paying attention. Then ask yourself: *If I died tomorrow, would this product continue to benefit people without me?* If the answer is no, you have not built a legacy — you have built a job. The challenge is not to add more features, but to design the exit. A *Sadaqah Jariyah* product is one that makes its creators unnecessary. That is the ultimate measure of compound impact.
@@ -0,0 +1,798 @@
 %PDF-1.4
 %“Œ‹ž ReportLab Generated PDF document (opensource)
 1 0 obj
 <<
 /F1 2 0 R /F2 3 0 R /F3 4 0 R /F4 7 0 R /F5 10 0 R /F6 12 0 R 
  /F7 18 0 R /F8 21 0 R
 >>
 endobj
 2 0 obj
 <<
 /BaseFont /Helvetica /Encoding /WinAnsiEncoding /Name /F1 /Subtype /Type1 /Type /Font
 >>
 endobj
 3 0 obj
 <<
 /BaseFont /Helvetica-Bold /Encoding /WinAnsiEncoding /Name /F2 /Subtype /Type1 /Type /Font
 >>
 endobj
 4 0 obj
 <<
 /BaseFont /Helvetica-Oblique /Encoding /WinAnsiEncoding /Name /F3 /Subtype /Type1 /Type /Font
 >>
 endobj
 5 0 obj
 <<
 /Contents 50 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 6 0 obj
 <<
 /Contents 51 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 7 0 obj
 <<
 /BaseFont /Times-Italic /Encoding /WinAnsiEncoding /Name /F4 /Subtype /Type1 /Type /Font
 >>
 endobj
 8 0 obj
 <<
 /Contents 52 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 9 0 obj
 <<
 /Contents 53 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 10 0 obj
 <<
 /BaseFont /Times-Roman /Encoding /WinAnsiEncoding /Name /F5 /Subtype /Type1 /Type /Font
 >>
 endobj
 11 0 obj
 <<
 /Contents 54 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 12 0 obj
 <<
 /BaseFont /Times-Bold /Encoding /WinAnsiEncoding /Name /F6 /Subtype /Type1 /Type /Font
 >>
 endobj
 13 0 obj
 <<
 /Contents 55 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 14 0 obj
 <<
 /Contents 56 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 15 0 obj
 <<
 /Contents 57 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 16 0 obj
 <<
 /Contents 58 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 17 0 obj
 <<
 /Contents 59 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 18 0 obj
 <<
 /BaseFont /ZapfDingbats /Name /F7 /Subtype /Type1 /Type /Font
 >>
 endobj
 19 0 obj
 <<
 /Contents 60 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 20 0 obj
 <<
 /Contents 61 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 21 0 obj
 <<
 /BaseFont /Symbol /Name /F8 /Subtype /Type1 /Type /Font
 >>
 endobj
 22 0 obj
 <<
 /Contents 62 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 23 0 obj
 <<
 /Contents 63 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 24 0 obj
 <<
 /Contents 64 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 25 0 obj
 <<
 /Contents 65 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 26 0 obj
 <<
 /Contents 66 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 27 0 obj
 <<
 /Contents 67 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 28 0 obj
 <<
 /Contents 68 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 29 0 obj
 <<
 /Contents 69 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 30 0 obj
 <<
 /Contents 70 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 31 0 obj
 <<
 /Contents 71 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 32 0 obj
 <<
 /Contents 72 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 33 0 obj
 <<
 /Contents 73 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 34 0 obj
 <<
 /Contents 74 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 35 0 obj
 <<
 /Contents 75 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 36 0 obj
 <<
 /Contents 76 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 37 0 obj
 <<
 /Contents 77 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 38 0 obj
 <<
 /Contents 78 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 39 0 obj
 <<
 /Contents 79 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 40 0 obj
 <<
 /Contents 80 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 41 0 obj
 <<
 /Contents 81 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 42 0 obj
 <<
 /Contents 82 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 43 0 obj
 <<
 /Contents 83 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 44 0 obj
 <<
 /Contents 84 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 45 0 obj
 <<
 /Contents 85 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 46 0 obj
 <<
 /Contents 86 0 R /MediaBox [ 0 0 432 648 ] /Parent 49 0 R /Resources <<
 /Font 1 0 R /ProcSet [ /PDF /Text /ImageB /ImageC /ImageI ]
 >> /Rotate 0 /Trans <<
 >> 
  /Type /Page
 >>
 endobj
 47 0 obj
 <<
 /PageMode /UseNone /Pages 49 0 R /Type /Catalog
 >>
 endobj
 48 0 obj
 <<
 /Author (Jauhari Che Wan) /CreationDate (D:20260806151648+08'00') /Creator (\(unspecified\)) /Keywords () /ModDate (D:20260806151648+08'00') /Producer (ReportLab PDF Library - \(opensource\)) 
  /Subject (\(unspecified\)) /Title (The Digital Mujtahid: Product Thinking from First Principles) /Trapped /False
 >>
 endobj
 49 0 obj
 <<
 /Count 37 /Kids [ 5 0 R 6 0 R 8 0 R 9 0 R 11 0 R 13 0 R 14 0 R 15 0 R 16 0 R 17 0 R 
  19 0 R 20 0 R 22 0 R 23 0 R 24 0 R 25 0 R 26 0 R 27 0 R 28 0 R 29 0 R 
  30 0 R 31 0 R 32 0 R 33 0 R 34 0 R 35 0 R 36 0 R 37 0 R 38 0 R 39 0 R 
  40 0 R 41 0 R 42 0 R 43 0 R 44 0 R 45 0 R 46 0 R ] /Type /Pages
 >>
 endobj
 50 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 589
 >>
 stream
 GascB968f@&-1WM^LBtZg6jF:b8d&aVTHW<Urr=mMi)d.!SeN5keHT/aJr1_[,A4)X2jDRM?1[LC[R*$^pSls#m82`Y(0(f_+rt?%c.CEP(g]-kkH-IS??TIHE]@LVh->9JLc=.m9o_5\\[I&q$?Ztm&)Q6!U"<TBS0TeQ@rt:oRm@.Tsk&rMN0G7!q0*cp:Z$/%SL/'OJ.;1n:2"Eb[Ap90XR;qN;_J^D@<f29C4XOBRQMb4WEauM4-XUP=`S%UGXu.+c7-hbo'-F:]d"tEbkeL;Nan[U2"#"`Gnb-h>$rLhlgHgPrkB.l;5C2o)".@\Qp8>oA/>RW%ae'Ts;0-QAHkKmCnJBU7%#q7Q]qRWiY.TkdNu'7e6Z.Y(i@FlXeVkA=DQ\:gDe#_-+(9Ha/KbHP@)R4d@Z000ka-T<kt0__?#F0O;6k5,@"iq:>N@;3nBlhcZZ1N^\!1c40YphIB!M;qINk7QHTJ6/9*4``4'tY["rTIA1jGp"PkUM!2<&X^gSpMc[85C=GeD"/Rci7r<t(+2<i.DCeJ"o.`?84S5tXH^fMqC]EK,q7!tUH@tYDp]`GI%5#g0H2~>endstream
 endobj
 51 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 626
 >>
 stream
 Gat>S;/b/B&-1X4I`9"&RoD>T'-'5'.-`i)CbqM,ou/*mE>LsH6RVk]D478WL0l,KK"*o*;snH1Jc4NMpN@'$'lZ+PJ-h#rJ3t$&=MVTe*Ck5tFodWCp&Fa+qk\Kh"4t_YJ>+G95U'`?g;D/K+UeXdgLh)D+MPANmrmNaAB\j>jW)[QQ!=X7X:?7@QM#_"T,I]P%s(EnnIqgZ38stF6'9%/qT!?Z8H^U4-Sp"A(:Dp[MTNcf)6=X<hp^-@>N<?_(1+4H9[q6sGSh5%*!J1%]ctd1VKSu&"Y<HqQ-<7^!dgmf@DiC+D"@bOU>#,c:V"s^''o?>b7?omc"DjFD^hL"Gd/9jQo)CR1g(0@&s>R"UUKl-D9SsZ=kq<Q0lOJ5.M%gTll4t5,d\.8V68+*aIOkH)-H2lHJ2CRf5dM^46XG]W)r'miP@)S>]3fn;&Y_2GOj4j;WaMsFqT3/Ih.0_4iE^3L7:b1%PMIsG'RX0M9)51,jG@kRFd"C&)D/k+NAE'QkT^/'F&Yk1B!Ya[Tb]>UM(1;s$J=U#3<]4D:f8_358Qs"f_^!p6gInGfYcoXKkd^8p_j*l$.1!!lX*.nZ9,J/%bVYB.4462G3]*l6E][^uu4LA8\g~>endstream
 endobj
 52 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 296
 >>
 stream
 GarVH_+Fea'YNTZL0gs5BjN^>)D?^#SgmhJGk&'rdC!/DDKd]3]h+YU.$F(+aNU,46P/caY1l*Yn$$O4,iN&qMCZ1o*ZR8GK%qWeE`;ttj*ZWk`1S;%7E)[#OIA\94dIa!eu4\a-/9!u.SXiUmQ=tD8?JuTQ&/98JRUc0#KB>s22&aC[g<(,C&+c++Nf8@D5oTbDZ\3og%5B`<uA[A2"Z7NN`_(fj4*`<`seV(IKY.Y`H0Xk3;(aua4Q)+75V*2dREPCg5TtDmc"&T`D!fh1>Gu183-F!Jc,T#N`T<~>endstream
 endobj
 53 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 847
 >>
 stream
 Gatn%a_oie'LhclM?e6#V[J32k"UsU$">`FKk-AV,L[DI%>b9*maq21*mulC(taEDaX3j.0+Y$T;]tk/m5`Gl:*M[/TKjA_1SD0f6Z`FndD=#B]#WDCJ`X&hn]U2GkP>\"0#n7,*/=Q9/?G)Pk^bH!Cs\M9LjhY^9gARilY[b`4hT<b>g#V^fPV:V"?op-cc"[Hhs(blFnqd?#./Nm>/R,a,-PQa=)YJ&X3k=Mp:_mHFJZE$eWkL[_!&4+H*!T9$"%AH3""X%[Lf0$@S?6Yap]W)W+C_O%-GV]$C#=ers+UH=2X2\,u-O5]H.$#,3l;gE@KjQ_PB^=.\D2Lag.2u],o^NL8MpNBX&,o(MYGk=Mgo5'8^#dO$25=gDuPc.Oo@oVLgU(`Pk009+VhC<OI.P`)hSulhB@Ykg6ha#;.(_"na.),+ZjhE&:RYiX/UQDK*o"h4[Q+VA,KI(7@b<m__H+TeY4@R-a3%3,RXnc=F"+1Ep;sNbB`J0q_CcRECed(as!8<oh]):3r:IT+B2jl!WY,0Lj)cPJNe&(aZAV+$8X,fq$mmmT.fj;;$*hR+[+)^"^BI`H<Nf,Zh6AEQ0(0+j]s*+b*LW@Km4!WdGtjg:X8$hO!W"%\E&o#9C#H'cR7GP<B!GGacLekdnV.Noe/%W;L_2/Ei"4jprNpIKplXKZg[r>ph=l2**YnHXZ=`!Ic4bnK\a\HL:p5ddj`5I6#U>_/ha&?khi!94[OeS>5I9T@i<Dh]p(kqcjRDI%Ll$_g#Np1HKbe;pt>/PD!m"k9=5M2EHJ#Z:@Yc`)OD-$G%"L>2g8Qqm=G9M^G(5<V@t;i\]:W2&uMtIbXGJ~>endstream
 endobj
 54 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1420
 >>
 stream
 Gatm:>ArL\'RoMS37>OVWat*o+O&$/]Bs9nWmQdJmRSj79]?W03-K$u0[-`X@u!k^UICGOWmDCUSF:V@#__ssrgMF=IkK^9#6H0&AI0Ug&m.?7_t)sck&;\h2s.sKn2^KqrT]AH5n<"N0FlMfJg_)4;@TC$'[7a(pGRcf2d$(IG(7?>rKc[VQ_o#P&.!_+bd&K@$.b\;ZQt5I-F7DA4)5Nsm-;@_&-3)#k1Ch%;&IMd]Xo_&oN?7'o0tG/NV(ICV^jlm9.Y`9Z%QgNcO^.a_rUTA!@@$96lo"^<>tLZ&'KjHB<Ba:eNK;IPGOSq9\P%U(Pn7@7@e]pk#2=I1/A0ABI%ac(Qadi;;=7e+o5A>gOk#<c/:+)-RH3+DZ7-I@@D?N0(6aM=3?dJSNFganB^+niR;-EYSo*bQAbX\]>rIs$E,X=[O)5bcJHloPBkbBm:2=_WG<R\,`T*O#0S$G^/3"(MTN/=f<%J,3Ra:7$!'u=C2OG]E]&:V"go&G'9sNpZJ_To/OaefhH@&hDL2GY05R$41(?Qe%%'ZS:j4=pC*or36":[(nGeI-C%bSd8J"[1,`+[gJ#SZ"b,/Tm.o;$R]:dt(%sVt,icRY+`V*."9k@bXL4mP&;,eHP)b[q%H&Z/N]cFk%2N?.9U%_OElbq/=;2GQ!.:duF>,E7`E%I-O1KCQd>d`_XV`W#[`L3c-2%;'tHqmNW=?su]Kr1-j<33kU$06\8/bV@R\MG.+X]uMhTKsi)FG]//2tWZ:Bf[:2IT5IZpChZt<+tbTXH9J`'RnS/OLc1XT6n#`m09VoB`W]:DDCrK0=%so?s-f-'LP,W\S*j)NN]9GZ7Lf=Vo"r`f"]WV8BEua'+]<g46Gb;%'V<:R*8]W@R%>$>&HDbNpJJ;c\G'EIULr;G9.0g#[EF0m[N.3P3-pF#.NQ(YC+_Jmg=.;_NhK7o1eP62\(-VU;u4_DpW,0#%=$a/F#;;b9-7'ao((+*$`[M_kiu;&#L^1_"&,bDe_FGQ-IakOUnl*WPDW\j9GA$>9!^u1`6"AYrDo/NC@ik9NsH)ZrDnH6"OWNmG8"_a3Ik1<4Y4$Uk7auggWM;/2>N2DK0dA=47k=bF/Dp1<j^MS%WCNir-E,ZH9;Ijp9>+l:ru74,a0deuFS#>8H-1ZRa9mMEsb`oZRcoV)qKD<hgkK7#A?:;5Ed_]4\9RUR=1F3c<R?+2tG.J!0akrFpdhZ4>Qc_Pi)k:H59?1oR@M/h#N"Y#+rg*j$B)j8@m_>))"pU:<a')B\P/7FS9%`M@?Ya).[,(\V'NpmP]mpU@;+:%s20JN<JfA<+Ob/5Z.p1V5mCDalGI^;Xj:R8bpg^d![/1:E*n'&E2QP=VW1n<'&%*P]4!d7r.G5)!HXkb7aMD&T6&eB.kGQ/5ADS@\n_rrMoq,/O~>endstream
 endobj
 55 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1664
 >>
 stream
 Gatn%Dc>CM&B<W%;s[/e!S@A2,i":f/Td"7g@U8j^1$.nYnaA"84JcajP/RuE_)\l.*#!d`b)H^]A!5NZUuXc:D08LP3?aSYMU^lUf8rpaePBK90+_5h7qZkRIGuG<,DPp5DENlb:Aa8\MVU+d3ti5'Z&4\%W9^:9EjtPONOb+rl2SML>Bm%`>D6<nKc6g#lYnlEAB*Yg4/QPMQ'.A&\E;dIRHc?$%'VL76-[#.m!GuY,R]3),1KSQ6[PO/Ti@8kY+"?oPLd:6UJtr2I6l/C>hTL1G,SMdN\,/EV.r'A,%dJNm]bUA6JE-OKGF`f<?Q:/BpaH(u<p-Zd3toC-g"+PmBm)l"Ho@6_3^Q>)`uV29mAiB!LAFM+0pQK/7O9mYJ!hAS%13Z0\"t>1I_9i;0T4f#rAdbaZM+b!sf,C[/Y)F=BYlGDad-abNf>Wrs'`EbN4Oa0lNW="bKEY2rRFg6!1%iHkr>bJ*YLCF(E8b>.&j4]RJ<g>*b:\2]l!Ks;92X(97"O*35P!JGhu7$A&cnL0u(.*D%<oBgl8\=E+[%Z3CZ%R,<4SR&u\s1(6V4Zdr/08Q13%)@8]"Fd+c3;E_XU2<IuW9j&Kf9KF9I7nI[WtRPG[n9;-Od%(OP>9qK]RerPd&BA=hOVt:g*88-8&;iR"S0^9Ate\od')]VZorc0dRq'Xo10"C&V.-8J<)oL;u=A,j'nG]-hfb(G"cj*4g/5@6HV4Qlqm*MR"eW"mS;t=,<XM2<ZIISG@?ms`pY*K#rkA;]_QhEZLR.TRZM)VBgNHOj5EPjOB6I3m7ou`^I<4$hOA"jH<hWe*Nb:6Es-HE3GI(LC*6_.UX7gC:-%Nid!M0R5\rOlDFE)JPhI)A9S^'^>b.>det'fH*Ti5IHOMumW("V+$=;X4C+r'K72"g_fn)$IKA=_F5p$:ki(3(4R3.PLkX!\";'BgUksDo+j>bCkMZ)!acD.`p[Q.r_KB+-U8pa(*pVY*bLttZ6c!XAKhEF2O>8BQV_$)SZ=hJf\"?ED[NM8.eiTRX`O;ic,d&.qu[V!#mq*s8YL2W/ch\`T;$aF8%Kq[Qh\b`J9pVM[eq5.flhDWa,e!WrX026(7rU49/&Yq,!3Cq&3]S8>^1dRVUHe$]/Qs."3DM5-+Trdj(kc-?fE\,IsQT[dG;V]f7"U6p>XOit3/:9kKIuo:BI[+<<;*'EhA/j(+Qu+egCT#Tdn$t5hUU`!R(ZgqiF)n%9beaOI0<)e;XUJrT0m^[`?>J\C3_fog?4,;A7e"Xg2BB4?p.fr%65G1]UfQ;0SgSAj<aZ7*Fq?6C1$u*A<TW&>0Ve:q9nN\jF%:=8X5l_p:!aMnNTj;%'G2*$#3m0(Y3!?1+eNAUEo3h!Rbhd^#<f80mH?9_8$q>l.[H/$-!0Lp=Q=M(YN&3G+nhi_dW%IfXA-]'5(:VTrG_^JH2>S#F)s7-AqSPS^YkNn@.JrJ+dDWhef*tR#?QC[Im-;<hp">k?!inqji-TH[nFgV;<>cT@=CfP6*Q"Nc.d3HXMp]@`1^KGSFl*\QV]_Jo,d3M=9`[RT1`E%s!h`>P'"M3UEM/[h=4`0=`9\j.iO]-mXc.A:2(L/>NppWF(37Y.BbG`L0]/K3ii]7L;%daC&;iC&G!8:G)iJ<@sBcsUIq`h"Tfur'E~>endstream
 endobj
 56 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1816
 >>
 stream
 Gatm:mnXl_&H1J#@\i9735IMbq9A/GU4isBTRr?,?hiX:Fg>ntG-JYOe%bn=GSAfl8eKK;+HX"O1N2,sj-2V":?1f;-@.bI2t'[;1R^udm3Ooa>g`B.e\eH4P7^"r-\K\,pnN8J)6ZRiiNc3;l1[!Vq?\@rFE!j`6Q-TP*Ra!V9n)9][tqZP1)OJ7^Rlht,_F@+[$-LT.IFn=*e^.?+7SE@T@2"3krpJ]%*'ek<cmh.(=naM.ds2?,ekt=.TFd\KJ'0EDJ%$^l'.Tu(Mh>GG!i)gi>#m#)-$sEf2N%Z$$Med-cU=1CW](#5JjiMKh;KjEF(4[$1c^^kl.6ZVGoiaF+6_Zl`a&\.1>8-;6g;EIfW.<rtceldRaZulT6QY8A][E.hsP&="8CqM#nX\K(AL30VJfY4;1$-PnYOeb>=?6HL4pQHuRZ\UtZ%U#T-N)P=@U,Pn37OAO7%B!9PQ>=#40jP%n#$Z;^%;"gh7_=suaT(B,1^HMu,^Om.js67*ZE8)8'aJBOP-2:]QbmQr]`i(aAN;"k9%qUiT;ZalAZMVr&@P.,bZ/E2Gf/^2;NG2Ps?@>_8/F*uL<G:/_TBMY9-)!W'tnjkUR*]r,Do!hha-qbr(i5hsA]a2&1,%JN.r:-_P%YgHJ+:W*R6>r?D/.!j\3@1]-j$sB&'$kB9Le3LsPL.?%)d^:Vai4'nF)O6KIX$'^F*.s\/jB5TI=M%X(3N,#-LXkbiXU)i*TEhikVJD=l2q6T2bKEEkF.me0[HKB`+OT.?."flFO",ACakG!7siJu5EZ#k%5t:(gP(AWhn4X`ps94_9Mh0DXi(jfd1T\;70(,->53VtCDb@B)1uHZk\c(eBH^hT)>n:?+M92gB!_NNdQopa>dE"Z:=KP%r*IYRJ(ra#K."2l5!s7\d7ec29=ccm#ikrkNZ=R[?Cd]qSc&?&//u7S^Tu-`B;Wcn)g=3SIbP-M!AH%2TOagd3a7eb>jG<S'l^.pY#mHmc>QZC]7:Q'Xb*1'JiE+jR3oUUerRWd0:e0lL^i.3WH+SA"QooCN*Ob0MU4U[=u<+TV#O1M9E9VD]Pf0HQLqJ3^YbLLAigKb#a.82Qf\QIhUrqV^&1VUO8-7;GoDsi/pg++@=O2nhSK?OQ#<QH0Xs>$J#4)GXL0"cChkS<UJ&KG#+ia1Mai?0ZsnK5Z2(!+$p%UL`9^t$Q&=$H!l%jE7fGoII49U'<0"kJn8mKeaYk;;a>dZ&)DLG=!d#7'&c1E?fa]KfC+_$;b;O?mVQ_VGQF:8HV)5:t+K:pqh'=#K&4N>_TJ*CsUe3)qpiZ^1o6;%u5Iq=anXOB,n;ehI@Fpf<lnF-(@=Am0W')*aFgk*L2_?aLiX"KQ$M9Dt=A*(a*LahCIR((RIl?1\2>e'S$lFOX%.UVld5]/ohB/?Uara%[FC6DBi"jBU/i/2`#[DH%Y^E%P%7UP@Hu>s]^#;U)@Z^OTY+pp`j&E3XDspHI:1/%@(2eOe(M`f+90RdNW:pKo!*)HED^asUR1f9_:$$0)2AQ,f9Tui#-^a'CAE'#(XOoNJ=pi;"cb[%<@'oHDBHJs5f]-PJGpl*%D^p*Oh+Q4'2NEP,G%O\f(#Nk?ldfon))%#(#S7n9FQ'=qV![GLeS"r-C#(o)[t2q7YSko6P&H+;J6\#)!V.+=%+Q++jR33;/8q'3a5nF^b*h>V#<eMLPXoLI3j7p+g'`>5%^NYR_L[oeWT#paV!1P:n`9Y]RuUYT/j=^]1dT+L[b'S7\om&d$op,V:&3Ag?G)LOe3Z\(nbiW+"SB;;9H-.6m6Ht%87kd5^%rPuA&=]~>endstream
 endobj
 57 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1570
 >>
 stream
 Gatm:bAu>s&A70Vk-A"XQH\ilB.g/Gm#!`YmF^4b72Lc5,fCfJ"/$Crf5Cbe[$KfAPq?,k4\0NGh:'i?KOVTWn6T'^mrNf'SktSJ5,4niodKi,BDJT`=7)Q@^G1`Qm<*ejrls6%8D8#sS43C*8ngLVUl%3s1`bRYs)CC$GKTsX:Obaebp.iaQM.XnPT^WDO-2I?%ha3f\[t^4)0YRT]KYd_'";TLI<nb\NKOnI?Vr1XE*=/CQ+S=,R,\o_NiLeo&uq%9abeDPq>640X&\,3<_Uqc4f(`*8+W\F1XGJ)>g^M;s4@R:inbgFLFipI-%2g';dHu-'gmAHWF/A#)bpkL4E=s12s-3SWJc,'3*D6k"]Jt,9_-&_<[?JG-67qr%5R-A:'--FZpVP`c9c?b+)5\![);5o[rLuNga;'R0KU7eK5@d4CuBBVX:9-`Z3Ou18`rDarAR\jD?3g&$8i&V4N/m2O.>&iaR1\=NrgS5ZC1)(MX6KapgrPk\sNN1ia"&0dKj]C'E@P(^jC_5d=@;+[b?)4Vl284U-ttQ=p_Y\PZ`$]>CELP'LDm2O+OPdXVSRs`%Gl@%/!>3d)UMd3=/?))JCV4U$U\8AjO;q+l)>W=LaP#14L29Jj&teWIP]:a*#h<.l<L(BcT#IH3;;+.^W&dK3dE)/hqn<F\^CC4QI$oIEH1@2jdcql.!F'akh)?/3Ged@4QJVL3OPpIZK6?cRbpap$^)Mn+'6j2t(eF]<%hC1BBU4>8CD-_P_(:/f/7I$2d9(OK9qM;Y%rORpRP6ooEg?^!SO\N:(+\484,rAI1q'3fX%4Nq=q#iU"^.^@j_6RkEQA9r?((l=EgJ(oG2%Cgl!XOHB^;:2;#r#((,dh,)rTE(bp=UhZ;K)^8?GLhg';U8iGeOG-rW0Vno<gBBFsD:\2T3$@90m".i<I:/`Y3CB)RcOr`^K%"=!ZNo\R$a^e,L)7(<_^\H(/*WDB"W&]!R_q]Ae1Q4M5]]>-;_cn[B5q\Y4]`)H$RS6?5`H;!Ll-:r1m:V.,g#QMP`'s_`Ib'L1ffJ(e9Vf]\0fE%F]EgsEDpu.1TsmsP.q"r;.pik2o%@Uask4?$ZUDSBXl@a&-p+[iF)[\Dm3e#m`4?"72atBhY)$:65jaibpX;2VG@-TN37*%nuE:&?^a)AC<CsOKX]^O_gs'f;mgfBA4%?VX_DXPnG7OZf&c)fUs<h+G"kP<7fQJo6[)ilZrPn(>J:WlJDUjl3QK'8ZM!;>f@_KRqJs$^iVuS0h+oqaTnQaD%7ISS[;">+jAm1#pl>Kl[f1Cf,Q9[IP+X?aL&.MZ]*OT;UZGs%"mcH\=RmOf*`GOM0#]TIJ>sg);IOc&[qBaj;g.7mT0%N@pi01gVAeRtB@anC29i\LFJS]dAmr#Z'</=+"kpS%V)]kM9<9k1oohWUQj?%lOSb^a"2d#jDufr*pFu2dbf.tgrQ1ci\LRN)V8KZkbmKJ&,Ns1f$4-oO^!@)P6n&_&ajZ,M5JAhnK$4&?AVNJU!D2bT^uXQA.jdj!Bt.ZP4PLZI.k&!.eI*$@o"X4]H<KG'l<h)rV+^~>endstream
 endobj
 58 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1339
 >>
 stream
 Gatm9gMRrh&:O:SbbH/ZC$eo,^Bf""VZdtdNJ4/neH]i5,Ve;A1<Hr*I!pe*9:WM*JYKBM?'-puB/jO9@[PSN*58HXi-GFeG;7#B/CkAF/;(pFE4\)T4R%&Br'necI[sfVO4ec9\;*_S.Eh;cP+3+^"-[;Zbb,+=3/,<f=M41\^Cfnl;U!3=S!>NN,2IO^<a%a+ZePWpV;*/@ITJcsoitT]NQWMpoe[VT4=kA75^"#?4MT'dNsT&1Tf1i;#^`=J&f[dZWPN<,OA=+?Tj!4Z*ERBqLP'PMD`eT'OAjt9%\+-DL?7L6]*N/Y@\_:<+H[F:D1k54b>SUhg&U\Y$h*kcjn/ncSD4Ab_*)/[#d,4[6jD*>[W6X3!Oo[6pgjm>@\Vrt&d;\K_@[crU=tW0*Al8,R%nrD3W,rhF*K4V;_*MnX3)Q=L!REb94T+@LT&'i"E+ZTd:gjn>>[np'2jF$_+D/Q`oF4*(N*p);7PT1T8Lr)NT*hq6+4rCZ42^WGT,Ac8kUSJe[%Mb$j#hknd#aZDMZKBRk6RhA<R9c=@lfcL=A*%Q1[-^Me76,8/+;VNR3DTr/0i&TtQaqQMnMHipo;@/Uo@ZYb#1<-b>##e)^fdjm_2%]@f`N`8>?#$h*gV$*F+_Xc?oh80R4T4A\ks/PlC,TJS7Q`W'1)`TrV7dOL&;n+&ue8.,J0QGJOb7F@39IA*R2FXq5elIK1"1&X;6]aV'V\edo;C(U/4PDX`c-+ELjB[-EOJRKs"de+]2qhneZ3TbJTH-73b]LFPG;F*I$YZ-PK=Rm*I3i^4\I)JWUM>K=RrGA/1@SDLUfP3oVEODZo!gdi!7:>UMWkt)ciroj&[R'"_7Co@T.4S)ei@3tj.$]+W2Y^lhD7SA^!_+/J^ZAES:VBrsi'Gm;LGR!IF8T]54PjK,NuDFFIdCI@in)%(</eb/,q-j]Ku^D?Kgm!iH*mTL/SUAiid/"rV"#QhRMO`Bj4b61g>R^MZR!jhTP'D3871Jt1bBA*//4W%OR`?b'%?b,9*uB9hh2)$T^Sf$'T/uUo(cQ\K(SLgV1PWZQBl6JPKfiiQ#R*+e#e1p@8!_H+N9@])u=</')a]J':L/IOh93>*.)=9LDsZI&^L[B<@_V3n@W<-Md28?F3*hj(4=`O8R\TD?FNE"oEdB_T-\<>jWjWLZ_d1ZHF_X_D?PVp7$hcJE!MiM^Pd&d\F3>MRge4$S)r<'*GFrb[9QUr%26^]5,`6JKJeahIVhlTd#);rO8%-.i.Mj0FM-seD5aEs3,TSgqO=9H76MQc7IO@UapTD(_'g!YnQ.Oh^kUDuMN@DFnhTN]HR6PN?]?%XdJ~>endstream
 endobj
 59 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1451
 >>
 stream
 Gatn%D/\/e'SX<r='T,Ml3sXAlHM!>d_ssHA80N&"UZ(`BSj%JaJ'nWp@Rft8D0#1ckuis#IYjS4O61bO:3?U0BV-?"jr)[^&Q00"Z4M]7:&CB>8iOZ4MBG'l.I#(0A0UNQhInWfb&$V?/RLl%!iW+*bJSPB+b>Q@QrJk$QB&@nK7JpHVD)#-L"uUN;"AaE8BjRU6%g24:/Sr9O>fO8^on$ngUpImlq#"H4(`s1`#jm2oONl7\)2t/5s)1"T9*P`S^'DE$V>4N9saFf^JQbJ9O63I@d)7>F*(0"O<kHr;d@/1)"4K[NqD.\X<g6R2m,cJeRgKXm,_aT.oi1I`*)5=D31ZGbPs$h"J(n\Q5PhAZ]]A2c?Pg-)u^0VNEe-8b9E(0Trrb35$"!?g(RuCY_23c04-_oCq4q+#N5@*lauPLT@nJM_e>6mtEFA%O-eC\<Tjua`1Bu^V502q0"q#kB;)m1H;/qZ^9eHItdq%p1\pIfBA`<fFNGYJhTc&V$4d*URU5uol/B2S(k!uEubO]ACgjjM<E:LM>#MVpt1E"RNnS^)n?Sh=O4MqcpF*lVYZH2Y3/a&WsmnW\h$:DcdE!EcC!4V/,%qj!QicGC*gjQi^o.6V+mLPJNmqpV\8#/1.%K%Uji)b5(4&a^65MU`Pt?nLe8=V%;I:0b1(qK2$7GoaRi?!9(3!h(#7<(+J,R/OfCMK*VA"Mfm@;WHC.bT;ell@F^;+;"5pdE%i/,T;k?0NY,]HDD]+JBhB&o*W8H#'!@rE-hSD>7rOOWHr(o89+<bt:P.Dj4#[uiVX=h!p*aR/ucK:?kCACWd3V#M:F;`ripO/t+-+tR[mFTXZo<bt<-5T3L;.s\e\&OORBIT0/<XQZE&/jk%8FFUZnA,2EO7dq6S4l"Oiso^*n7F-U-W9!EgQT641cs&W<LKTu),2&3"<CWr?W0r@6@6'U[u;8T<*'Y.h5%e7b_?U4HEKMKClc4-n"fMKX4MD]g_d:u)XF48L:C/*536@Q9&_jg4]7*r0F8DjTT*&O#ikZrA=;@LRimMg@O4#39V@p!134a%O_HD*9N9T*YV"][Fm*0PKY=>79%<uKpt+7<(=A[V]/IJ96"4op_k>^COZBiQ6W+HM+I$s6[@oIu#c*oLD.Gfl<0s?%7;?(-nAccC_O::.JekYVMg@Z>af!*65hk7i[5K:&<?mUfW%-PsFp4Pp=cGpd4BED\%Bct,i!A(0'V##'qNR<Pbp,8:R7O0oG(D((XdN'OU<Guad-ns0[Y@,N0CbQ%Lk*%j6tn6t*7n*l]:u,26=iTiX4DPKXcnMADKQus'LZrJ>t;c$H'_KL<&9:Hjt7g`jNU#UL+4g6ai1),Vd7>&=0Rp#\\aXa@4I-Q\7cq>^`s<*FH5`%)%_Um4VKflenBn'C0<!\9X>FNmtWTs/a`2an/6<t<>;GkhU/c#DuKj$X;2H~>endstream
 endobj
 60 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1680
 >>
 stream
 Gatm;gN)%,&:O:Sm%`>s0YsfS2^c$]l,8S1.%P(m1ED8S8L,Rs!2(1jlam-CfjrmJR9$af%55>?c<6Zk.0TE5r@r3k?EE,`RK<q,>lp!W%-oik[6FD6ZG3_f2c_3[?cOh[YHHXoF<<+D.#GeeKF,Ic/M->,0EXq`SPN\m&_91WfAC#p_`MRecR*?u,-1pNPAD+,1reHfR)KAnLh:@kbqm<MPJlQB^J9=aqmmGBhr<e90C+NtY:lMD;LY)lMN:>C5Z]Cgq0ADCs&NXPA<nto1kPB#Mq8SJ)_6f#2/p%oq9Q7NH%C#6lu14&/acB[@,R,*bSX4FJ8[lmA^4_j"(O3TQ)t@oCOX&8ptW:8Rd%KA4b5[i<sRLoE:MA-$V:u/BpuSoLPkM8r+Da3nW$c21HX8W@*Q$#h/@TI"+tO\>r(Jsq9FL`?4&-_fQ%N9XCfnf!jO6^9GS;+XrYAq,eN/3$<\P"NVLGC6/,U%?mZ=?.tk%n:'mR;SQ81OgZS?"hJf@<5kD,j3SQA10$[gSji1'$6mRdZ=/\bJ?mOeRj.`h>$>W$U7>YAKP;?%h`Dt@ED([D^bZ_0Snm!\TE)$6=^#=:;Q&tdb<q*qe-c?AOmt_^BJH!;MrQ1iLhpH'\%_a`M'p:+?4?h>67+J?p^g88f='o(a2;G1XEiVV=[Up;.5rBS>[;\"aWc&6s9RHY>5_<!VcWmBYjTXr*=Fi33n=@BRi1qQ0Y2j8LB19uElg.`mO+?8=$<J)&>/GWgdnS(46:oAW_8Iu&^.(s4Ol[f+7F>dGPbcJ.5<l=#;2p(;P&@\]GUhl;NL`:"85ZM>_hBqpaP[5\j'!7Zh$QNo2$U8[I8B`$`bu%cV$dB!c`F+4a+cSFea-6GOuisb`[dEf@$OqbV9ge"qe]lC/=HU<hDXS=:FSW:K-L?Gg0O$@F@hf?a<Q:!\metooSe@-:D6JRI&#cTmBW2O;ejj/<aT1Hh)gMYop5'^Rh(.2?j>:>51C8(BpATNpb[F>I7U)W7E9,Hpd=]m5,o&GF7</=ks&?PMo)T+<,gciW]cO*cp@sB2omJU`2T$NATD$iqhH-)jc,mLd'CuP'qe0D--EEOi#D;pf;cj"%p!'u<hR">\oM\#<g8?\4guBu#0"B:ZOL.ON>eBO86bRg\<UM/+@moFDmrFocmNEo#;cdnOcPY]gLL+u]J^W"X)E]=jGf=Mm"\n**/B(i-<J2J<!@3mcI#Z;A[D1tQ>&6XNuf_tYG$=&TOBhKmM7b*1ot:[Koii$69"Dj,L]35(9pCVb_*ks9sI<=!n4^5M.>00?)P%5S8k12`C7GU[H:YrY?[@4LF$ou\:\.,hh0&,g@Yn)eMMFb`BO([Si+AZcE.2!0(Qt#^9;=J]'U)1.2k%1nZpp1i,iA4l5P*_<>u2-Cd*VGQ=\6,OojIbRXO)OW+u2F[c:%AW_rV(FefB/@tu\.&$^63?Q?Xd`9:_5d<7(MGGboS%PRHR/DgpE#qU>AnUQg6hiH\VD\>)X=`A&t6BidB.6`3^s6N"Jk=XbM-FZV)n,EYu3t)a>I_VF6H+9KYr(G)<E:XKT"Ifq2M[Cn\W5C#/F:A^m<0u3Q/!S%(hM"%FArl/Qrabj<pH&Go534pa3UWl!,ZlX<_hQ2S5+[73++O1BgWL*\f71KE\p.sC:P8U1&FWBPjDTb2XH`~>endstream
 endobj
 61 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1824
 >>
 stream
 Gatm:>u03G'RfGR\5K_4=L#$rI!;2r9*HeA$L)^UGT#j>4O)O=cA[t3rq\d%m"?^mMi\:%34A"!S9s\72k_)'8bepC6uQ]0l?tuj9!^N(K4mNV$Tailq"CG/1>rJeB[kkY7Jg^6r'o,&9B.;_V\;[X&M03s]1^U->NO0URXM$cmsP$H$uaIN`cu\e)FP6,K)8D-N2I>HqY2-CG+\Yl@N)KL=7=UTbTX:KmFgZl'>!MCrHNJ^q-nM&49'PJGI6Q/Z0s[/q+fp[3_JW*o9&W9l[;;qg`\Rds%/HpGdO@)GqLVNjr<lF,c_]7-g/HH(.RK8\c<#-)(0.#HpLeJ\It/Tq+iTE=1Eb3X,Ns[NUtp"@l>>:-I^nI:so]?'q;h1Lh:TNX+dRL['VFoh)@t'i*FN[a>T9N>TSY>),-J3n%#<uNBJtf%YAi.5Q\c"+U%qm9Nc/).dnc%8oIm3F&e&HP9_WO2m.RY=dcZ*:RauD)t1nm<2NW_MuLI<K4,bmT3%5*T53qkW^P<U1.g32>[-GP0b.!^'WQiM/(o.t[,/0$aUKuq>)Ku3b>bXl??g%][TXX!fR;8(K*4ET7;_-k=t=YXR-DWL=BhHAk,T;Pb*`TC[M[7Xk$8@l$.WG1P\b:*K4gHR4p>2@3o,tpLZg#2BK/V=TuL;a*YA3/f$sR@_;Z$(Wp7U5:bb]FN`JV\84ZjUqQ1@@bnj&sJ1T0B3QU1(UR\i&`hR5dnnXb3;.\EOgFGcO84TN/:a&l&8colF)&gX6U'^r"Fkm[1\E`QGg9*>,=g<%Q&*L))?sh7b/<B!fC\`FcD9*,K_b"$//Y@WD0`?]q"_0oa2eX(u;m%,3<`KOS6rfmZV]ff8i'HX3AmXWWM[Z3i$S.W<8-*ipkk)#(O?W9(C2<Aeo9@El0kX(I"kQWHX`q?H0I>>=b,/>L?RX)QeS))I:nn8lD%T6R)FV%FSH^/dS6$cFJJQ@T7-Dc:BD@V0%EH<3gmXBAehf734GeGH)/PH8JP8SOdBGhQ5+h?mBNV048_9<i$I`\(.ja!eN>3]U"kQ_=i2-KD]D0_%r*Q8la/..0F0CeZr\U4TV/<V/CRe9QSc^T8en,s_mA24>;m%B=DJ#Do4I%DGf<t!W)UFCVk'J/tB[SAT)lI_-^T:iV1?SSkdU99#QpT/?-BMbraLAG0j?4L,'e>og4+b]>q\@u85ksf)_!_J(\<^n6J]NMP)g#8a!D#maRB!ZBWj79!F*fC)rbOJ?(s`)/M#4R%3Ql2H4W_sS_l_H[<f(cKI2rm5hM-mJcC/<iGBDWr2r:3La89NMT()MEH>>i;U9;neQS^ccV<aWBX1.9D(T2*8o7tMeerjQ#H1"ik8q/088Mj0=j3RnEq.hBa>8U@#YC+5&(7Nhb!I9r'OKAW(1lgEAQ_ACNMt$[rN.>iad:bB).#jr_C]^o\\BMf`m3qBD<'XuEa+_>aBB?tJa<@d4V'Z/5rI,H)KKe4`s4"^m,]SYhGrDk!eG,nb?f"=I$tV-FO6OT(Ou]rcI3;EaNn4'?SF^QJ^m3%ITbZ*i[o;g@W%=\)3QK#?>Jlol;YUHoN'5g7G`,KHHM7_t-ZT/f/Y<#X3XXa$SQq\V?G*/!Ya)0f/*!]7:Z2@"!E7C#>n4H#ASj:'X_iAaf.oQ=Dq`aMbLL$4;&W%-&5&$.o^`e5Q\'+gYZ-5P.cXAL0[P$m`.:s4^Tps13p;9M4\Qjc:aU"H*\+3b`Qbl]eI\k^3N]jeJ)bjjOs99caYdiD05",#K,#Wq&')f#aBMEd$<5-b:=lN1@s6,!.-918jY><oX:V,/[5ri9X"(gX%oe2:q#~>endstream
 endobj
 62 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1536
 >>
 stream
 Gatm:bAQW*%,LY.\9%thNo+if94)?e\$n",ZcP\ABh&iW8gQJ`k3If.o;L+B6%G\HilVm&nsi(q"c%Q^jtiP/>U@b/F2@Mlah\GQ!0Z5YS"+nsXl%(Z`P@Mblh&R'b/3LafB,39[='\40=8jL%'5TSotg=;I%Nds0-l%8j"FqfF!g2$hU(`G5']K\[d1GUaG'T]mS+2d^)`Y(H?UOBcJ%a6p_VS#9Fje#,VOfb[455o+>Koq<3Tn*,E/^NT)T%sr:S.Rd5d.e:sdK;j&H*tVHe+<.H&arCW@:am)\Yiqf-+N9?sQ3/t']f'JCq:.N=so$"@&RY]g6hQ%fTH>0%GSU<:$:.F8a*+\/DFM5k(B>-O0&NP-Xi'51_Gmc(qT.'&KFI^^E2jhjU51<D#J@)<Zb%"aU;-qnk?5maPd.16J.?"8($q#X18pJ(l<L^uca7p[2/Rj]A605nat96cbM`oQCt5!_KM4B#E[/smsg5ihDFZ;OJE2bZ"/MO5*#P31JL+,44RQt?`B)[ICIo=>(+$=4lJZ`*"gA\dMJ/qq;ERmfJ+JluS,\R(^$6nLJ:"L^O.ksWlPR.E>(AC?2k,YYO>"N-;h,'Y7%AP)WEkJ)_9Wb%N?9Hq\_L+Nk!i?e#\.8eL,$`J`5U*^S@6;ESm(clhf,)D#-A\Hp7^V2(^7rG-i-f4%s^;&#N8e/]rqmQs)@?j`&C6I*a.3gi!HEpQZY8Sf^!hR\)``@sTjapCPWYJr<3S*$1Vd_REHA7\KP!jfXT<*]u8K;Ind<MXWifdK6W)t2T[r-+%!M%::Rj*P7?sN:Y46CL,E]lR=!C]1k]bZ2MUlrTK,b6hs(g/E?2>pSih]!;%=tgGQU/8dOj0U#<@>ZX[@Y%g-=\NV6CD-$[W7"BLUglDWF3L!qHrHohkfK(;P,CfIoA#s1JnKFMj@;MrEC)M:P4<)m+H-Jffp8*8_JNPP_99'G.)lQjNGN4l:H&CKHsQ=UVrd27:u5ULF*`:_s7>t=\USiE*YYs5O+0n*Dc8ilDea202;fgTP+HXG86XNsLd7cDd3rQ3B.+/AFYl\+adq`/o"Q1!+lrU1^HAg$nXHp1h!&lRbfkSY(ek'36,7Dl9lrk:YV52d77jPu"JRh^@$_!PUj4.a+Cr*J_=d1/2%,J2-s(N4kknQ4:@qI^gMt!qeIP(pg?-?(H@dmOD:**QR2-QQ><*FK]s?1qZ*-mJ+E&`Mb3,!?DC2LAnAFjP)3%gu##K;:7S&7OMX+;>CBolq`8)-qYA^.@KlfXo&;0B!V\<m]^[Sd.Q+*0ERp"B9mVh([odP0tIeqlZ\Src9TqS[gGjD`-"&:o3mdfU/@U(uhD(t517;J+tUJ'<5DP+bYg`$bU.Tf5/kbB"t<\P2mSKu4O8>e.\J5E@^>Qnk)-GLLTX_U4MX_O;uiPmREYqi;bXJ>m<'Z0$'(`S'o\^pDU3Cbl:MgT;L"4\\0)`nDZC*Tp_$;4=LahDN"D?R:eK2.^/LNYhY.2X-aNHF<QRIA?oj'Aup+5)8IcMe(1^5X-~>endstream
 endobj
 63 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1074
 >>
 stream
 Gat=(gMYb:%"7kOnBi[o7AH?K^(`.1[fn\ED<moLGo98>4gh(_jq?5CqB]]W:65N_/1g*BS2i^m+XnP0T,@$.$h/$C2_+nQJoqMH#ngA?"h3gN_sCpUfh_h)Bq8RjQeCp>EIs*8&]@NV;&U!D$hO6D=qVnGo*X&5@/YtDIjX+FR;>HAdo6H10f_9WS)OiE_)R?,#Xa^^@PKRMP\JpS;@k#C$:H;"9Y>V=/^,eMX)nRN95Q0/D4tcFIt&3Kh\p=+.YJ/P]k*'=r:&9gOTXMd=h55sNk-7&\VEjdIX<u%p9HHZF0O'?<5GmH?c8<_iun>,N*4("[8-kIr^1(#f=1cFoQp.T8];ZMg48N":nr-h+Dc!*>'H9')m#^0%29FspsXf]NU#<ldhq6XAIC)&U6Rki#>Tnnd%I0\2e[FqKl(6pDPoH]A@JkX?jqkg!'\tu^ZId?S.<A1g*s_1j,'eAUd^8t=C0)4$eb)I2Aj4gMrWNh^=UC#::UISeW"dSo@b<B@:s,-cbc+rh8jV$`^J3aWG5Fb^-MWg`N]-NMFme322kmWGl*<Z!%XfoH+4(=45q06McOuW+]iD@Q/GkR.7Ylp$p0XHOuH"[.&=4sqg(BrSQ2[h"Tu&tL398UZW'Eu.qP\TC1UQVg7&DLoHX_l-a!&YcY9h+7[Ko(QeJ#!p6)Wg@1WDN@O2<6)7A:@d9Sus[IL8rf\T8>W?PnTNIlWKqj*QX0(;^r?90iZO9uc^Nc=*P`/0EE.*bJDQt2uNG.bQ%T936n/1?f]RM8$5/6S-&739H;`3ZRu"jKI7a-!$7QR>02hRsgJ9L-pZ?jK>DD!7?g6B^n$%Fq^7"LWQI02io;(!OG!A3^SlfnP79le%82Q0_9=@!.C_AQpWhcBdU-Yk6aFC+k5GdO:]+cb4KbVKQ?a#OOP7gjY;T.ZlB&6.P=6-TTH(_-f+1)(4B4]A3T3"sOWm3q45H.oF-#X#`YdjE;4>:!rbA<W<-R/FI%iIl7)#rN3A)ET?hrUm#<!S^C$$>U7]7^!d)U\tO;eYmR2T'fJj<h`_V@Ru(@8#KnRe;d$p&?f>ej-N~>endstream
 endobj
 64 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1487
 >>
 stream
 Gatm9D/\E'&H88.0iD54<5dtm/+BCXj[H#g>qZQ:P>6L.liD%0f=p&u*<#Q$[5!M(.2St6%.)\0cTLe]1CRN7Zf[\j!:ORim[aIN@($1R3!%5Ei,3`.m:*gdZ5[:$g98tdp7k[^%^nUIF.)'8,Oe$T:+BX*pUh>F#kn-.Aq._b=8Vb;*S`dk`H6#hf+B1"FXJ464q$TDaGYZ^*1t2I&0F>]_7'I%h0Zrm#./<B1!auOT6=ir$pH*`'2dis5P\USX-\#e85?EDG/3*lmW_,2kirA-mh7*ULW+&5GR[B\p_.m-I#V9sVl2X1K:>d(3]GiM;YK<7!>UQb#o^El*&2DaEPNEbA%mA^TF+k!ITP&8e5KBu%U?oRcq1c6[6#$]$JW@o49##749^M']gQu:fC\e)j38Ug#LfU(o_.8?@=EJ+'H9.54uD$#EV+YlgBlWu@4.FSL#TkN7@qB!X;0Y_UaQlZD0W@Xr&4mG)BJDK5nLd1)@C+6MWr.s#*1X.7T`B$E!#dAPaFh<b3H!3/jXK0H3d1)VH*u1jsu+DrY<)?F^;$Wmbm-'V[g=S&+prT2+a]]>SSXrVQe_+/3?G?8sOP\^mC!!85%H?15(l2%[uj:0?W#$V;AJ08sP;S$Z`_STi/DZ\Y\c(1W6QG>H@KZER\q/$L`,mjTk';@YYR0Pc`XFgtJ!GL+VD2#[T00Saj)BJjulaM7T$!F'R%Pr0G(m!1fBB4:;6q@5:BrU<3YKRRq;cq[,:s>S7Mh3[j:kE_i\nV:lrgmIT!"/5'FhoDB#DT)WEU7G_hHH&`^0Fn[1Lq2uFd\]JD8&d)FjQ;8]doEi)q9SY:M\''3^Y$B"qY"_cV?BYe][@U_8W=37$R:jR&*1%#Ieb!KEr$$81@H\MoWF_4oMhRh`mMrb)7A6O;;&D5H]O*5Rk2oQ.?><2iQ3Hb7D+gW5<^7l(LJ'(h-DT\Rq*;e3<!7lWY5CfmOW/s>9,-L'/&:Tg+gbQ"5_O)VkIde`;FlI]#sU6?K+7L5jCeuh/>bt-_Q%[+fo/<+f,$bNCBFsOJ/*p'Cq:<Q)s</*=F;gP%o#hQGj^@7EBjBjq2a5%n'g#Im>o6Ss4@7;j$g)fDQ/=d_\3YHdqH)k.PB>?:>iB%P35oQXBn^jg@F)M4\P5bd77cDakq2+CA+G`X/uH6,]-@D2B':fZCoi@)F3E"<'iApLV7jSA4=='?gRs7($<+q^$/ts/@C,UNU6mTR2ZfIHD\@!&)PGc)o".?@R"Hj9>Z7j%bh-S^6>$"o"YVr>>kl_<p;GK(.'o[,+BIh'>'LiaAnjiVX\8''o1AFW9G0ple381)MXmpBanhSj"*PlSfuu@63>a*46k@:FbZ:RRlfT0]WeUtpX``Z-?+&#B04qVZ(lLh'$+gUA4&Vm,,_2N\*<0Rm=:>bG0J;<\JD,uZk]+Ze"+YK/>gh*7+LL251jHka_6LWYRjH2DHk`p1VOHt,/0(.JW#!Yf^p`9~>endstream
 endobj
 65 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1691
 >>
 stream
 Gatm:d8&Fg&:O"KbTg*'NU=YUO=EXkX&c^:[h)O'$L);8O5gDu)g9h)e$&5n[7N*/,1Ir:S9WYl1M>"'R?3/JL]0B;Lu-A?ebbHFLup^OUL6L]:\8Q(ioW\=13Eu2+R/=S8,L\,[j17`7Dgg8UFAXl!1#+g]8WHjKaG<U50^9ErmEt/'o$Y!8LE(O:6H`S-b(7O_f1opFT:&ZBh5",m#H>`ISA_)F*m9/gRB!QVp1JAL!6JMCrcs3,n%<>>A7EC3b'c,PV;c&2^Os2SnAR^$cg*UH+q8fA'TeEF94!P[.g\!<2_R)GOTh(k_s:T3N]Ydq%:.[N"st2p95m+X]6jPXHt1\/O[;5>ITC5?5sADd0+,EgJq`7/[X9&M3>CXk[X&+focqOQ]3t)eV^K98lMSeOgG5G*at8:p^nD?+mN8)1?T2%PI5,q>c*[")uLbgd:DrUkec"_^a3KD(O+L<9<q!h&iW9j7pUY0Z`oF$#G^D1)YtTJ+!f!]'3Tqf*%Z^C0g]jCoE3Q_+V&P;9G[O[,.1>!k&PqOE6+lm^ac7@7&<RlNNCnR58>K'CL2)<J6,O_15c)I/3u6&a)T;$F-68`$_`8ITmR0=(8XX,*>(D7N4?r\GX>JuqhGY<Z%G`PJ.)@[KIsF-%o+Ek^asq#.#\9/\J@oj6%joI[?;D?jFAA@]B[k"1uC+u7`qY('$oS#b/!I<D)T@Kk2$&NX>GW5Zl3>@C?:WEl7H!nWiD2)lMrq'=CVkBg1UqQ].12SJm4.2B(q/mWPlt%dD/M6aCWO*&9&)u.%&F%BfMb!<P,W21)jA.GC[I!jiXP&>^b+]W`[eF_H[1CYGTUQN-!C2*q<EVC@DqEdIc*!4+.OinMj;'`-Z`;i#N\<X\,I9X0\_@CAIgihEtOMUd\)#AA)aE!"g*ZXPKYNdf$+s0F=MZ[skk(*lQFi*1"<*r>^9irc>q5^aZGUBu=so=QK-CBGC.*GX*@heWkM&%H(#jA1_/DNhN38-SLi4,CddK7r9j&2=)$]kH%XQaej)j9!rXc!\_]6foar;Mk])o%GSNH)V`T/WlqNFJR9V_o&\NEHHk,Aq&1SAN>R\2ZRH&4^5&K>oj6r)rT]3\rJp[Afp@n\\+BVa]fSE'U>&,C8UKmCPtCa%O$KAhS`k7"nC,;3q1jm7A)R:YbNJJT:\3WBa"O&<pRgq)MZ02$i"C83qSmoB/B,MZ$LPZGlP(4jqK^ZK1a5:3E88$D3X.dQW!;mk!NF_=5qh+-Uc:r/[K3#jZ7,sGX)YL\CBQt6Up3Zm5j(bl6f3]J08!@X9!1]M%5qntWa%otO8=P#4*UOa.GCd+9"sF4nk6!fkj#dFRQ3HM4oP-%L3M)Ba3[;lE7Q4P$<\q\m<R)m6#Tb%Vbflj.8J4seS(1X=TXLNn"B+6"+pcj6OJ/06["3r$)cP?7f]McN%;9=Q.!+?U#`BFM:>,Z@_5"o[Xa\OFmG=A53R$&$k9A&?&up[OGhU!!uW2Z4?$'#Cj;jgs%m1P=N3qQd5-MDAs>mI+t!<'.PZ>(EZ6.glm;:a]OI@4@YOnf2d0C&!U<*6%`2rD:#FZX1q%hO%u]hJLk&VqVLTQ"El43aTQY4i0KuBF-Gq6f7^p7*W>'cfp@G:/5.["u*>a@,I5m_pK8HE;LKuYi6NHh>0`Bc@/9Ef6oU[ilk`<n9^%_mt_N3"~>endstream
 endobj
 66 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1759
 >>
 stream
 Gatm;>uTK;'RfGR\234im'%]5N8\=qKeUUMKbA%pOr))<@Y&C,P+4B-om7uFZjBACAi_UKCu):9cTP?Sd)RfcrlcjB:FVf?H/SL[0#7oe#jDeWdLY5!FDhf`if(h3F8X"*bEY*HFmf1A7fkmU59f<jK&5;W#N-',HlbZO#jG^9r!PRBfu*tT)oXN<0GAh/#"]YV+Zb\_5o9V/]KmMI%O6Z=P/tR$]o'YlGBl\*^Y\AEhfLiL>b:D<Hl9:54U:ZVhHB3]iTG[:5(nb#)'+D&8J4;"JR2M6\8<<F/U.bnW)[&:"cFsG>&F'GR.kX(1+)=EeTu[l!k$C:ZV"bkAm5=M^Iu.V*-rmpa4Bjq'MZD#f[m$&K>XGLm_rUL]j2O-LJKanTX:M`XgYIm\c@]r?\k_U2902SY\:Fm[cB:tpJUO<TD/NTVo^8u)-:JP)lfRhMSQT4,mCH%k%h,Qgq)2T]Ztf9Z4(u$hAsFF^=nKrkcAO%\&OK'R:J>RI1O4@+NZ]l\DtgAUrHjG>3t_[XGm-pk5FZdF:*ZY]lZT!=)oI5(n^Va;c?Dern4E2IT&'NE7_>J5&eRfa-<G>Ys(*S#@A'Tae3&:",goicn*WN*K?g[A7HV8%_k\mQ`q/:Ni)(1H8N@J\K!aDpf^K'Cs@$%B+/e]>L>c'fB<t,m!%p^C,AUs%jOnEY*f?5<_upJ4Nc2=QrWp.#_P,4;\M_h=4gTo=+rQrYjW$bROdNV=`>^ebR-:N_!2Z<)0;;NKW:tr7S?i=Wq_14Ng+nPi]M>HrLe;X/\;CL"reABf+oRKXJ3@N@4k#n/j_LN4G1$\,\4Q1F"mT%(aXan_>j;6W-gp+5fRR4?+UZMg/ZO.fOqrW4_M=_1g]44;2+DC'O+3'Xi4Ubhj?NjjnDO,lZDklA>I2p3E,8\?@QZdZtQQNM%'bK?Z':@)jHl7&k$#CiDZe]G7$WQ(k"^_U[%+A!(XerKX#IogZbq`_3GK%'="t')7)_b.5*:5NM;\1TG/g(-=hd019M49A-@coL4.iI[,B+LB_;$VQ*dic\6qc.f3FQikjZ6?@C\et`\`CLg4\(N7*.6F-g&HfT^N-SSs7lW<G[gD$5,kj;4Tci:loON=hACAd"ntQ0O/?>&Uqr2RZ_>e\ggIV0%e#@=&n+kcl,,fMsQ2G*)<,[Faf8LW>="kMY=#q(9\0;f;Mjj@pMPoQ_TJ\FE7-OAA>TU<uf7u0.i:,3O/\s%rXq4S!2->3hALY;ToYA-0O"K3jX6KSKDA[pAH6TFIG2dHp(0DPD>j:PR,'VAl#'G?`f\`#K/CZJRq11Q:Y\M7#f!L;8g0j-q7"]I"O53gu+6^(\Fj&k4eiK[b3`hV9*'A]Y.%'`=hU`?L\<p$T3Gn,q:.J:5_f1()j8J97]HqBo[LX</0#W.BL=RqW-\WrVFt4#jrc]T._Pc2^?7W4M/=u+90&E0,XU9dJ$2%\/@5VcXB>=7E`m00UcRTPa9gt^IZ`fD]#%j>_j.]..%4LCF6Lq!YV2S\.P_(,G&Tha^KB,lBm>$fd2T^)T`]Y'fBep=VV[EZ:U:YPgSdW;!7d2l;lJ2c?;?Q[AY!1G(4FRUX:\dY0<E9[_b232'$gkEldO;BQYXOVVY^MB<L]QL2@M_lapoe*1k%ohKssm'pD#p=`_#;A^-<Db5C.JGF'[XLb`W6QNJn,iL/:,]#5Z;P3$T#-FfsHHacCC[3BKAVMlIb!n;'q)NA#iC6qJ(@j_Br2(!Z)3agm`J%*Fp:B~>endstream
 endobj
 67 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1546
 >>
 stream
 Gatm:>u0KM'Rf.Ggm:X,ar9%1E.ZREkSCGWAQ9kO06ru<j*6GE'BUNRqWiK?Cr.OT-pf+#@dNX?Hd4eKbY9M*:D3Zh%FOj-/oD:o;OWl8%&4uj^<n%/Z^8#dai$E27cWo#0%s[GoIH)B]/39W5rt]]'OdnoHLiu<.%-1s5,[)k2#Gh<IZKIqh\g'/43XSL!1DboPf1[cSC$6hI\`@.8Moum/oF.C`*M4ET3i3W,@#&`GOLp+_D3XmS;bp4^86*Nr\fYsk@?'Mi<<f1?V$Gm/:6NEWXGs=D3V(/&i/(/)?-(Lm.X2JGWNbjlu09fQ8ZT\`2HYH@5[.=)HZg'9%$>4S/W-h*ID3a'Z;8t[mh4LX;&6#A1M9d,"1Z4T.C,T($33Kl;(cTAdq,qKigrU[n%TfXG*[B"boajjZWaC3V)nni@ui7f6]7#BG+*-KS&C(+P$1N>34)CM!//]RCP_'SGq#Q<H1[jrJR03JF&lo*ZS4SpW<UOi+qC$,W.n<I6cs<9A<o5bZ^Y8]_AgCZ=#>6b&O[#EX?P#5aP\YTH48ffgf(%9R:SoQo5!I9+=4hS=Q9B#9bGaNmJXT's-Q1p&ni/-'ssoH1&'5JK?>>)9Tr.LKY+/I+-X?cQjEn'0#Z/h[rC4Nn%5MmHOQK8d@TL<;LS)F.K4+2X\)e]=NL)qKtkiH:cS*-t3F[($30`?Qnj2q@l<Z/Ru6;at5,IEp88<ZrSC6I7R,oQ046kjBgk?DgfS4&Rn"N'Y:'#F:b,(de43oP,2;:*/#H52u41j+[U`slC';h%d?ITaSii%s/q::E8I;Ik.QI)Gg@?D7QHs="uYc4eoo00(-^;AfiIW^Kp(P(UJ0:o+11Y2ndVI0STgCgQr!ArDkA)BAsXkhNlLOIQqWPYj)gCNg7X`-n&iaWeC8^jKB(Lbi5@1sE'B1Lj(OIG*nf4[WDs&+nnOe6W5$\u>En.S;DW`iERsdH\uSPt*r+1"Y*:h`YE]o1f/]`W:ZIK[+DT;2d7+M2NV!Z8BR.,=JsZ7V#QTt0U?7I('$GoJK9sE,KX="=<aM.77UU)L%idlCWE;.KI-BBY3OmdpUEt.u7KY\H_bMSs%tgD^ilPT4X#qrHE4JD!8[_#1!XeqQWWkY_]*[SqPsA]'ZO!^+)eR.poA+W[hPT"iBV.q/_\t?pRV_*4Co.8GiN3tm&an^>AX970%jrGHqT1S;ZM(YPJ?pe/rX<]X90g7f0-tYpdS@N90W5N8N=%P`_9`Z&D9Yn)<:Is0!0euL-ut\9C;4d.4D*223*K,9::#/:%S,pJmcjW#X4cm,LT=>pP@0c(B@p^9qi`6r!\o0F9I66k5a0,OTKu5m24*0ITaortV8.>_o*$UCmX4p!o8Ndre[6gEg[T[>[P8>B'L4@;@+\#"JCnQ<4mih#C6V\Z\3k_]/DC9:D)hu&oHU;\4\tgWTjM2#(dq+D9&;]c+%%jbU-U\`!u+Fd21C-.`**ilCd>DFoEIPP_]4]r%WiP:ERL"NmDsWV/!SB3\8#m1)hda1HQ$6RDXlPTdFj"<GDpA~>endstream
 endobj
 68 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1269
 >>
 stream
 Gatm99lJcG&A@7.bgA"Y7:6$j/d8OT2SjR!DBkg@>\Ih^Z&qSBUuJ8dIV1'%:?'5.==iHfOuRhFoB+:GJrosUIk=iSb8eg2,D]gM.u;UrL&;Thj_*Js%QbWdaF_t$4l$N2ZX\pW!#LDfOMi)oQN88;0RJW92+/>Oq@<(7OMBu=IhD0pB!iu?jXL]t'FDG`_I]*O+@t]7VUPCq;$\W2T3oWKbW`=8IWG[b^YIpp^YO>/:>qt&]U!`Ngil4;pF;8g:ssJCL@W2iZ@_b<>nT.jG'/8IJgb0]5nlfA.QU_W%VGJ2eRs[j]Z9X0jl+-oLrT:)jrd;r:0,^!C'95T*44^p2UE=Ip4\,3$YcG<A)+DG)$[]\%M]?&)^IeMNHF`hE+Clik<c0h'X^b!S-*3Q?<MB1hhh`<-2[rhh?EDrLrt8KX`2[E*Q!6\)Zc9p@Kh,CC*+AuZu*%<dt9rV@!'G,m2Ud/)$,U!Kn8\U>2HdI66ooRiF&kdVM&U<6`E@PrbdeZ#h@o>1/>s)TY.'>I+(YR[*F;JBWP62);P@OU*`+!1dX4T5#4.FYuGC0nJqJ$f\u\!Mk+bbA$P(C@c(ik>!TZ(Zr6R7,hJdPW_u_?LYhf>iSFks$$8'[^Z@d9n#5(gD*&Gm(4&DI6=]l;@0mZKI!I!fHaNn8iXt,Uc'EJ"K$sY['bu`,$t[#HqkaD[q/;=INZ.OIY4\AZB0`K"GAQ&s;ooc)5IKK=\;L;]I?GrW1\Jj=op9/Re.hkiO`mC=b,3QJ8qMrl7*hZGkSd=VMak=VkJoTFngJo.NBOi&_N`h9\#O-<&hdY]"[6=\=ONU@(A.glWNq;FUc'Ci>V4JNFl^@Q%ON6,C2't"b)_FY8L-=>^_SeJq];ZTCK\3]-7C-Vkhc94%?`[iC2pNm-_"g(dkLL10>F,VD>%U.[Z6\g#.1OHC=9["P:YinX^FG9RK&I1U<c5n!U8k>]lu.2]q+C<?ZR:S.92JuBs;q!XF_inj!EC>-$;00?clf?1cuTZ>,dO#B-qH"&A@0WlU_"4ocfieNAq?P/7"=HV6j]%PAOt=7fNIt_iuX(,"]h8dV,oAU6uN40Q8Z3Lq&6iLFA`\V.iBCfM]UM+cTX8;pmgm4a/!(/X;&7jJcB/$];Z#d]k%oC/^3N7h=o.%$M:[kqR<]!?ES1Md@M?W+^]BS>Km%2mW8dU07C;N+b4XOrVo4M2@#kOCT"<5.?YIUIEjn%Ve;eX?mac%,VkK_NU8h#"K<3?l9JO#Jn70h^p?mpA~>endstream
 endobj
 69 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1400
 >>
 stream
 Gatn%;,?43&BE]('I2F,pV_eG8X#IL!j/EN"0N*B3f+Z:32pg04)6osI/=jE9qZSE"M02JerFBl1\2\M"FU+lm[DZ+B.9?%#`o&7!_DB@OKMu_*rS(PbtRKBe;JP2pndjhV1!s^bQU3#_I*G]fL&:hN:)9?_,7H209H/8l0ifkT4k`A'.<SA(p=Su_/V,r6m7E6GT8!V(qbqUEKn-,j?mT$S1F^a^4QnI)@:dE$#qlJ@<A9SaEUW<patd%Isq-G,<99XA74rJrcE_tGkIijIXi('/:h:;>akBaT0g,#E2-t#Au:>$?*K9'0#_.3%Y1:qF)n-ARDoBBBGqJ7A0eOS"/;^r$N#^(5TN0%75\>SJdZIX!+Z*H;Qt@9ic.J/3"o%OR'^P*h]Ce=*,a?Zl1OlFb,GTE0QgWEQVE,-jrHuJoth4#Ku5U!a;\?U`8+MY45O\l,J1%k\uQH5Rrj)]jOC_&=c@PT7Z^q/2mBhq0<\9s)8g'8I_22(%:Cn`^WkVi%%fts%lkr.V@3q`^F=')da2(hA<HN_ZElb.Y8.Q\%4rI%Ip(>@rkLe.F\UDM'oLZS3Z2MoWA3t]`f6]Q(F:n12H&#h(f6Mulc.:6qPBS\,JQ#829WF-n4Xo7?8\GoaJ;'_pfu)Qjcr"6.WT2[;c$Had=Y/??ZQ>)>&n46>H0[=%X.7d<B30^Zc+3ON91ikb_Cq`pT;FW>!l&W["jXY)QIU/2(uq("-uA1Gg0gNek@4:Q5U1>WHcEWo`WuF_mCY*R&[^Jr#Rp7j31eqC:G3;YOmQ;I.]Y[&+B\c,<D/fYm7/1E6!JnYZ7'"g=YJ\Blp;A0bq%/n%O%NFJXXC#s#%@Hb-]Q4,Z#e-,[ZqN"iS.<,pl_C"J:"gH#k.pua[cdncu+4B2,OrGZql>[=iL>gNG=Y;aY2eU0pannPG$D:8+EH&@%H2DpnU5Gq8>:Js]<e8nK]^6m?al_Z0>MQ:.7Zm`8TU=]dX/?>HjK]23=j$AYP9#\H:e!7#7H^]?fSLNF^,aM:.asod=,N<FAd4isjS>&>[,<:V6*jVf.8E#eh/%KJ9U1lZBp*tmsQT?C30Qs1i\S+j[*cBedcIjuj[X?)8)l*'o[;@;h$M*4OQ-lVc(G+;e'agp$ET>VXRu,>DK+u4DUFs10r@U_[$q>tEb98f^;p`0p.uZIF9@5hi-dh")f)5:ZRL`2&27pO_^N?27S#8'0?!Y5ff2p/fHN!c10jCg[I[bWZM_d-t5CFNjLX8]a?rcJA^_PFPpqGLd2&&[6.,ROP)^37i]2>=eIV/OlBuLJ*nf`1WK.Sac=MRtL?#P@i[g;XScUG`e[j>gjCt'!5,H<gkSr]e_Za)f<\r@J4('4rFFa`X<^qN$d95$bSM(l<3HW;[Xq@BK_(!c~>endstream
 endobj
 70 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1204
 >>
 stream
 Gat$u9lo&I'YO<E]VCpXC%4P7jbp#Sf55-RcEpFqQX1g*;+(Ng$iin#IXN"X`Rs]0@nDmgEj=9Q[kY#S(D!-L9D!['G>Bs4$12JbZRDU)TCgn+k3L:!;M9a@[$cB`QgnVtiJr/793-%s-3Y^]#Y6O!r_&EEP*j,Z(YX;2h7N1O56/D]ZcR4U3_?%I9Z@OF9Bh2:,2e"!3p_7g[&/'_W'p/*hJV=3=*pToQ1!k?@n(%Ij`,41,PoSsl&DN389MHjAIcX+[MSL8BI?D*NF#Mb`.<TU>cB?',<StRP/9$*f!OKW-IHteS@G;Zb=6/J\g<rJaS)(@\AaD'R^Q-mk`SFo,S!.Uk6IZ@9lGA#dBDTF$k-'u58uX>+5Ls,BoK%lD:r.R3X4CRe"1>b)>$O(8UV_VBlB!0fTJ*a)'H]Br2o7b@T<<N8fH$)+:I5qhqrA1_YGP4k/f[='!@]TL\0>1Q#;cs"\lI^:jAm0N-$>G%%QS\]4$I4l#g\/hJ@hZ/c<lODto>,%ZX%^OfrcJY+inu@"uQj'eF=,DnFpGM*4U+VRP&:[_[3-@3lH4oT#So.t,SZ50=5D?6tHWW*![gGUneJ_<rVkRa0LJ_ii<BL[J'4KT]>k5hH6:Eg#6ers/Bs#PYC2\(djs#`P]8BM(5!O!Ns@Pp0(k]`kLKOCM9$#^9)?%h^Gc[.'hK$d5*GT$@f2^u.O:1Jh^2X([^7X,5#XU^&Z\mF\kq3Or5(UcgQ!)T(I3r\D>N0CU,b&9#q*`X]jlnIr.[Cp3>1*7."`H`6-1X.U7;8\_Mf1lMLQn&OC'&S>/i`V?"[9H$Wek3L\9`d@s1SVu\f:QDqSFr1IGn\#r[UQ[MA=uuLIf&'#sT2tOqa$2LBm7[Zq0%R@XHXmIXJFc>S"E^C#Lj#0??K2<Y75#c0II5\kOmhNhbV:$5LVZJtc9[INIP<.m-g:$8oo3NA9KV`M`u(?LJRK9/"ATD>XC%jHT3[LTL%u^(4S4"="Y,3Q(9mC^RUC,_TYL:?"4^OVJc_u>_fWooT2tAKZ=`LT;7rH&38p^7VsLtNSp985cR?h3H>jKFmJA%XO-il'KR%j*fHJsh`m:DB9kS7+eBgSZL+XWh+.NrqU4ok+(Crme4uj[r>IuZudNacCqVFtGIDt#Y@*A;e)%1a^g3EJBUU>f.84/NK_B.lh]e/4l.Aj#?ZDF&j!QLc`*W~>endstream
 endobj
 71 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 335
 >>
 stream
 Gasc@9hPRC&-h(ire_N)<5CCIq-8u44]uGAo]2jN<?g7n(&u%4rFg'BiatcJb[fiZ9@,GmS[T'tQnY'CLlpOZ<`u524Jh>Dl6EP:C?>>@q<6\qHc_qp*,AH,,M4HEe6qja*5IN=hBI@jh3I"n.6O-j6#rO?;'`HN6F;KK'_`TKK/+.R%9K)W9PH2O0hAce;eX*Q"XDFeMTOkF&)7#mhr2Qac0t[E[$%\Jk[`(9f22f/CO95T'HSg\>.D8CMuF6Sk<j-9)Q`LUZel4`F4/&#N)2F(0<!H$H\/Q2,n_5dnr-PV6^co:G,Y4OJbAc&#6.\Jf.!"#WaEdQJ[P~>endstream
 endobj
 72 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1450
 >>
 stream
 Gatm:D/\/e&H:NnEPO9D)%oB&jOZ%RR[;Pl\tk1?@Xs#\QHg7]R8c`"Nq_j`Uh)QCf*2VO(m6,,GL,+:4Jsk=l'M3][KQAe_W_d;(-st`Q37Mif5R.lH[+/D%,A]RkV^]NbP%^oD?jso73N&uBE1mgTL_`>9VSHr;%2lA"R.j9IriXp;rHK"?D$q7krKq4oK;=JP*dO0]GL7)/d*oppQGN69Hh>,_<Fr&/G,TF#E;/\d#Vluc(T3ZL!2qb,5fmD,sQ[d_]q1['(<)Yh/G=r#]pN>pAP[sD[.TZ:a4enBB_pJ@TH$^nIdHnC7k1Y&-7\n"N-<1HOPL:QnV!+=R:JH+=(.snW(I<KX&pP"tKdc\O'em-st)d%,!Q1iC^<N5J*)c"?hI'I_:?g]:8HTr8u_V!\P1_KeV9)I77Fg%:mlri[pBB$0*'P6.b4/rdISPH]9udeo^H$?-f3cT3g@U)u5_r=5E",#L;U>=SPP>g+rr*CS#;o/PJ2HkuYgBjQOWTj)D5<g2j&bKl=pK*F_b=![3/I^`)/'!K2=C^eKLq2Qh^I4U8$5[Qk:,ju_4d9]ZNu<s$u=<EZ.W!F.&_aKpI616N'56>;q>p6^l/2<p;K0"qlWXKdaaQ!ApFmiA$9KS$ChE+l?J`p!tRDXfl\9An#20m@u\.SpaDc+k+l82CMGTkUtBi*7LtV-ld63SDM%GEc?B5"G!MjsmE[RRu[dV.`pLmCkim5Sa6sXAEqX"D_ERaAc:qV'0>d.Qf&89r:A@G0h=qY!#"8=fjRDa)K3\C,Y[aa5eY,RQLc:b.+PF<@hi1DceFDisKoJB;q[Y-:`Vcs2C>ro^D+hZ\st3Q?@5jCD-Vo93,5kan^Z^b_gR_Kg?P&d=>K/L<c*i!'Yi,,<bo`VDqnGraWp"iRF+5TmA879i$QQI,mpDH.)jQgBA(85bIca0:a>/"]>ru$W/ojI)":P`qOb9Kol+2*Rnt)bE!YT%0f&OX7;n_)dhrsioP13C@?f73o:g!4(;O&/fTKDD-`TlDag6;+s/cCXL.hYR=urRI#]8T<N7=bjZ1ktPC0F.[PlHh=c4TZ%nR>Tfrcm*phWg%1!]0NL$'u9eqFhSQ_oa0SP\r,fU:/$laAdb\S2&/U-5a?APGe\9Xu='/(utPd81sIHeXEJ&sc0\rP'<#k$675Z/p_;J>nbi@S6&7q1t<WCXO,hiL[\RR62cL=1fN\nQa=_R+E5DMod!CdgZc;?R\1,RTh2&PLV(n(TUONrG1>LV"h)SD88NF=T6W5Cj87N.e;JUhTr;g4>5%CUoW>I_`F'nn`;.#<:WH:S;%DqjfOe+"W>A*1gU"+^`BE"qQD;"l$hf,0mobQ]&.L"9Oe<?6K/Yid2ZAajGfgg>I^\MXg,.S?89c27*Jc8?M.4gdpLb@_pZ86iP!Q4.^G.c"4EF#m]C+l0*&l$IfY36pI"~>endstream
 endobj
 73 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1404
 >>
 stream
 Gatm:?#SIe&:F5UfLI5YBHBTjcn@Zt-]JMsUT&jZ(b!\j;S&7.@ua&0qY-O,7G=`!egLSmU.!k_m`b+E=](,BeUQ^=dAm_I^/^sAg6AD].&G07^"Jp'4#oK-bC_?L*q/.4nFBddToO(`XJ1!GVIU8>WM\?KP,p''8Zkj&o9D40Ac$BG*qq3e=M%\6BT5]?JE*F#P#NbfaCl`Z:Z(/,/?)#e<nUA6\G@f%Ic%g67'!XXhW`e6EQ:b9R/b"02cW;4DqS(6I`nPOdq@GF44aY9gidK"Q:ttki9N(/4Yq5Uo0C;nfJ-B2CtV=/9Rl!nOI9;OA7k/J0[ibVh5tWH\2)\&Fl8k;6rZt+p>1J<Q5Y0jAP$b!N=BuLrWm]3qIeD3qfd4TD[l1(Q%4PU!V_4jUhrEQk.226g)_SuOMVeSUT.Q`L6c$A1Tbct5A@+l+g4\65G!@M^%q9jc-,]7HEV6(]M+5Epcu!XKBkXjF(q]^`n<F/-(R-@&\\58lfR<@$Z+\@5.p_Dm7mYaB">6:^[p^sJG!1u2c,WRO<%Yo<-hV5^qB7er)Q9EGh-PN9S9m<*iaIc.r']N3_0WH)2#O*6D36k*7987)UAXg+$<D'1?o>7).&qb3J#?MP:0W]M_lY`Qg"k*B'X]5-/q%QT#7ho4\ld9-pcI1VH6Rj#SYXI*ej@"Y@!8uUaUtFL["IH7=pFTQ>?nsIC)\-@@rGuI-\<0M3lKu.U2lnL:0/_3crDuXmt7(h,q/,[VG*Ck:4X6`G0D27Z1:KHdNWp><u**hBGLMb2?>ff:;00"_:J?4pOlH#;,=cMuMSFXst]hSB!$\'[IT;(o1pr36HI!_W2tRmsq7((GYu?lb6$TD?r,g#7L$"hTKT#AOjP?o?:1.2`f95Z_>uEdr5oH41D++,DSA+LV+;t1e#/+0EtT8CUkobi'fKKe>1,kZkF0+kM3Ka'91LcAk8k.>sL$.]O0"j7+1JI)4^k:qKdHO-(RNkGYB$(fg5!mDhMSZf*o.[&1$>>k4T[dU1:31]/BqmEX80sr'V`,lOc7=QHRgSn[B"7`r<pfZcH*i?\@29<#VGNZF&b5co]Gtg_D^7kOMr+TY&7'.nhl:%MDt^qOC6)(ksoBMm?,qP^-qsJnbMoK;lgWcqe8rG82^ijG;UV>:uMh?t1"h-?Lj=M<2G*i&oM.r]TNMF(*mJJr*lfLA-"'23162KFPL9^p_&QC:9<mitrf$]C*+(fQ.?)-h[VPmBtEWOG5C$aTit9lZbUK'%mQig>UQSinFM]WUplN=6Z$B:[dJA/98Z<6SdcBhfIqSPnX,QS>6f!3UUq:kiu<3])sAe?d$e^f3WUi6oeHsK!U^^2[rBXD3!*m<2EQYWd'!2`>X/dBtiW)n;ksZ=WLQ`?'7t^!`S!bj8~>endstream
 endobj
 74 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 901
 >>
 stream
 GasambAQ&g&A7lj(+9M87DjqWBNa^G8C45Id6h+DkTq$J>$F[6aWW+6rqe;s9?lKp>;&0`Ap/>D%LN)Z]N.+ERfY3\3H,#<#'e9g.)*U^@e$rfXfTB+cBbARH5I1)%6O=k:*c?$Yl^U9+mn4S:5Fiu&FS^XgdCTaK`<=U.;#!q?:EH\.A;$QX]!8>!agg9<PTm+Q>-&E.01:l/oLp_,`7mR)A`_',cqh>SGf\'Xn:Hm]U?kpT'hD,?>G]'Zm7-C=!W@"8NPa98m+ne7$Jmi9@)fd!0&JaDP*?dR[VEf3_t"7jM92+jd\/H)1Jd!dudj0[2ZZ[CBJcnhg4I.Km2^Qg]%qKk'Rm4C.0U09-YhDna"AM.2YTk-<-E9h5O;JR9Yoc#[6!@GW_h\e1Wp1q[dZ%7>;]EAQCq8#ruU`dNCYNDCX]oQkIma@u5[oV2(c19b#g/0-:``SV>pOn"Ar/FM3AkAWEuYJkFldg"&Ek(^#fR.ENFai+*1-e7^)t\p(_SkH<b/"pTa\CoN8F-NH)uV'of%m#eN`(7L9WH?4HU[Pm4J:Rf&bc#H(:/5K=ppfb;04.sPRnACqV4bhT-NMbt8_U(98OBqT+'t-M"R^NX-a,-28"J2lWB9Oq$:&K\#k\W]Hiq'=[%nM_7r7>')O(;JIl/LuA<6WSG`aIoar8'uAP0'1F[QU$G``q?9ctF)%d@i^b^'J;tPee6hkWOPo\t1GBU^&Pn(>@lG\ZIEK%YJDiQE#bLX-!Nk`V:TqFIklhJtCUajTCg'A;#ItHdc[n_$cRM8MZ!5$S>h9"U0UPW]5rs?oKAX55#%W9lF7?V8q4>OfW]%Xs[I#=K_G[Fi_2f4$!HD;Xod@=Xl7_MX1,HX/t._0A)f(b1JIBe?c=i/H,].fmrG~>endstream
 endobj
 75 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1546
 >>
 stream
 Gatm;CN&5k&H%!l@Y*N8Vmu4a]p16>mZM>f,kpr--t&]UAD1W?9+FNR9n.SHPiRbi?JPU$!\)]1G;qZGbA[gX_u6iF'"o13lZ\kD8E1TXR)LnrV"=,7],1F:gtaA\g0_lBh63E^-[6^c$oj0^SAKq&dZR(`0[(q=adnK+r$RJREj'sZi8L4`_m9Z03KW/[bORXP0nQ<3(+7$ESu$G8P:<0G-$]A@,T_3WOb:ZkJ7T>\Ni+`1W)[-'<@-mbHq8_ap^*!l+%u589999F%L>#un`IIl,orY3*_PX!g.Hi]^Zah:0'Go2X\,q=`BF>ED%IB^02bOr/n3*,Kh(R;#9iLX6ph8B#]GA3[phX=6eA&5p>Q&5Nsjh+hnP@%:ZNkZPj'p,Z\pJT5?sh1rgbC2M_F+K:L?kHS/`P7(%=q8hQsM/hFjGafon]I0hYc#Q=P!&"3NcdH=E0\0i"[UZ(`G;k&n9kY=ORu\iTfdMH3&<8X+G$1<QVoVRg'i8F>:H=q9`u(RF.h5$`p=!bK_\Bj6p%>G5g/0KGjH=c1d$Z4$Ine##U%d#s^$8sYe*Z>NYonPh)QatamIa*,pb/Du@\;Q3klA^f42eT3KD:(8BT9=8"t9kL5k(/Y9)bW@g76P-5__W)2N/,6%W=t==NVNSqAXC%s4Ztq6#@Ja7L4M"U;JHS62Fh@2]YV$'fZ?BKXs/p4'#:t11D-\UjXgk.`,S1m0'Is[q9?.C*i'<Ni=u1\uWO8NPE@6^GX24PQU7<S9TI0JuAb]Q0^T,uE,c]l\<BH78l)^#MDQ$2U8<PifWl85+`8qWK]TET,<fR+S!)D2!ZV`dAHnT*o&Ps/_jBAH_-s;0hh(6BP/`;#ZLTH5N%KY\5o+QFr=7+sO!\#"oaHWR-6k_NPnP\./%L3Q"7K!'_?AUgu&fa6$pJOuSc,lo%cre-b2/^<M*dQ)mkRcl-I"#,R$aTrhT[@.\1_WM^4eVbEs0OK0"7UOI4dFGPr#S&GKcnREgmcmZ2j02j]%T,*+KC=-fH5BZ@Dr;2fNof4ht"ViK/i1ep=gK57uTXThVihn\@9s+Z%o.3K$.aT]@Q1OI="qhl"3nr7Fb!pK,+nI)3$6Rb@^C?eM(g?mYl+k!m0"i8tX!=)LT2lB!lB\D;A%C8okuVTLbfi>6GASW=*^?AYWhg^A&Jm9tPb?mM?=9=ZlI*hWWf\Q0t]ur-RJ;nUV\YQuUS`Z]5.)aS:sB(s'A;D7Ze&O.SY,I=43Vj7<-?m!u2Sl1=-oA4;Y/)>>[e9'`J\/d+_o1_l:?Q)h/pX"!C@1A]K-BZLO=M0)(O?`UW8+I`Na$.;98@$G(]P<\=^q:1hQ>D&5?'F'2=^?@L+fE?F.$&X>$<!:6?<)F0hA`R4T<b%8gBq"kEHU/T6a)7m3aLmS*"Y]iR"KJ(D;,a<'dOJqebBZ03a8ZB9(Oe-N*+,K<RMkU;+d'r>cL"9!^M'>'@&sb'f@.jH>dW3F%XM3'8X>@hQ6'[AdBW.?Cn#ttk%38sj6dNDI9!jZg=tckNS=JNV<CoI0E(tc,aR*~>endstream
 endobj
 76 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1807
 >>
 stream
 Gatm;9lJcU&A@7.bb]hf3/mW,ku&d$K=[u`"AtVG/h:rgY"`s$h5+-5fD!OQ8g4Fj@%ar9fciF4qqdf$j,iEu%fO_Z-$m1tfC)'6,?eq59S.puJ(#L?(QU5H.g99^"PNE-IMlL)a*328\7cofEE#c!#)LdWC`Pr)iPk7=Bm!4P?hs5Q#^h"HbAhHhAO28In9GSj_aP?hq>4m'3@-u6.:0bb.@a1FVd/*FXYAa#e?mb\>cfRM7TVtAJs-OjWZ`gsTQjcP=`gX!+N\(rm:l96&<1_IW@,6PcW1r^SWi2-ah8uFT;6-k:bNePliIA@^84Hj]1.]N<j\!c(p#!r-#p#9cB2JYK6a_XMThutPV)RT3@].tDeLpd\tonq%H6Q/PU!G%$328aX,M2NlH[o\&gfg.h1;Z5rYF<heB3tk@?=!Ycf>ZQI8@7eH:4q+KG@;2_d/2tHfj$sUj$E9)WesY.jTTA%L,q-Og6u=&dMk(F-O7'NNHL7Ois<CHWLkY)m(,&W12e)XoaVK;%KhZXgC%:Bm126VRfZKSCLrp^c[+L%PMT?%^NGiMM3_BM^6[MQ:C0F&e<^`7NCKQW[-k6;HXO-,MT7(Bd^?^gf?M54)p-WOJahI7^,;8$ao;:i:UYq?Yd7)WWPjhMRB91&f!_O8a6-h&<C0:A8)P3ROZu]-\'QF=r\3[A=2l"!r!_sT^I>@.i&1m<Zle]WiA?"R#Vjg@+4?16$58m[oSC3E[okm#%tMN9E;=]pc8dTEnn@49XKp_&#KITl^>%JCtC='kH2%L'G]eEV),,>L0C)Z5PECPs5]thI3#nCW`<EfA.b!u7f-@$m>=6i,5pX:H'-$R!ZT@X4@puX_`UT_F&,KD>?,ia<Hk)8>.sb'p>,:3d]E6Dm.#_be(un'r7AtaUfp>79N`HN$e7O96c6RN=-*#39Z$_<c5FY=STBpRK(t0$huZsP^im/XQ-qVm!W(B&U7_LEepng7\;\dC(&idd*JB*k@WuYlGE4]$F5<[Nq',I!p@@uDUVs#12X%W&@nB\;M%L8SOC68=&`nZ3.b6i<R.]oM4K#bP2Y@LhY`UWsYG1=sc<u!%%ZTq)eEmd!54=JQ^<eAq7qqU#TTe@:b],fO!%1=P'+MZOOlkLh<uaM4:$p/ALU3=\6*g]5>A4M7F^P;4"$3$o=ZfG.lbif6f^5IPnRK"89_>7nJfC52f=Srsjc\,Z[+QU$3JE7-F2O&.U3<btF%1Qf5fm?YUdNpb#2$Z]olf4;D5D1RXG%0>-Ima0$n<fhkAs,e(bljmle.nFqj#"/'@#T+%BNUsj:Bj+#`FVmaIGcHD<f;M_i>atG(#:tg0/;h%j,CsHU`W(#`Ma`0dq8@TkDAlUc2(f#NYq8Yt7VNaVi1I6m[HV>k*K.P7',>WbIJr,Rn$(Xl$ja^k5*mZWC03oLZ@ifien\Fc%q$2q\gm1ek+CEDT^3qK_pF`)#cTfm)kg.klbKZUakgSdC$+0Cj)l\c]pGk%<k59`pMqA1+k/*Kg;Rh#o=jm:9C,VE=.#Z>SEj!u9"c'e%2=:%f0(^Kb2MPD:+2MH2T,NjIN9$TRW&X.*VK??Fi\#"TTB59hgQ_J+qg-@>uCgOT88>fO$>*l7Oqep=b*]7BnC30H3f[?ET7.<jPSA&Z5OA$F+*HYF0mFL;oOrl<uC,__.L,UI^WjWf@a-BI9mG8)L0U<7CW7QIQF`$!^ik]adhnOCtj@RXj<i]TbmjX$A_!t>B8:=l]o$7F:?#E>ic+*`u[,hT:cJk'n"D"2g;Dl.qolo:B3ogZkGrbS2?>kI#?pjhi[~>endstream
 endobj
 77 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1685
 >>
 stream
 Gatm:gMYe)&:Ml+bX2atNMG^??,%)6m3""ojL/c0!Yi#[h.81#$;'X)rVE+ZFreb_lPPFoX9=A"cK1QPP>I4Q,lH46dIRN)H]_-fdUGd>*p'bR7;%NKT-*I7bkT(<.X1@O0`KfAY=Nj!dQ!)hF@KsV_,<c.T@1(j]\rZs>5UaGhg##[(uF^1/$(>..a$ZUhFC/-bfbZWhkqj@P\!_.B0:N<:_N6p0%doa.Zt-7><:E>%CK)M,TOls3Ed<L*7DgaWA@S<l?ZsRd%8!\9f=tF*Uu&N`>&^8OHiIQ,;uce+D0A"PSCXME6_oEJdKtRormR=gtHk@nt"8oU;^<aF(*%a=ORmuUa=tPh%?1rl,^'5Z]j7GH?-kg-\WMtj\"f(Bh;Z+P-MB1V=[B`89g1sb37_1.K1[9H'LQManb<#.?;Q0YMeNq7Q")qm%1B7_828/&9/rQ@EXM/0<$m&HUhP'X=gX>W#)HW;1BXO;saE-oE^io`W`eIDcJ1O's4RjqDAVk5s`@"c<I&FdWq"&00UD(*k7k=#ksX'l:SQ^O!jX"">D@+,b3hJSl(%'km^=+8sLI@DIK6JAn=Eo%cONk)o9fTE3._`Xp'=%c*VLlmRfgJ0th(0NK^su4$lq+C*QUOgUN(-.:EfYZX!mt,+d+/b4$A5fCrL&bUMGuUqB^FK=C=,S:3S'r;GpIq"3eMccrKLU!P7;]D,Ms7>BU\,BHg3BaHbK=:\FdEDY,Xp:u*oLiPlK6cpW7-WdK_1UId^R)_uaV$AY$M(bV,L=:E%?!H@Ee)d6<hN(:?.pYYeb]IQp"T;*@hAjt9Ds=[6Q[qeboMUR$bjm[Bb66E&GJ+%oV%'J$#3S\c3e%u$7'EgXi.:gW&??+fjJ9$LgcCI(#qSfAcD%<YPJMKWA?A<2r?VaT_31L<D&>JRdVku3e<o3hAXkYjWsL1a1//@*K39`@(P?Il+;S=8rIho%</.@>6!or&+,YY\I[>S\_9Ee=3e)smoUI8TQ;_bIjWG88b13/R*S'p)"Dq>i*efle=``.5iPjb4rfDFsNWdhlQKhNDDHE3D8]P#/iIpH8j6oXfp-(*@EV?`E!F:_DfhP<D8eQ;)0L3/pm:"pfkUD/#$3_u.!!L\3Sk&E2-trd[7'?m%Un_WZhX='s?6_(2".Yi;[-n6eQ4IlUG6J6Vjn!^\1?^(DW#se5@9fHqN8_Jgm+<7PN_a<trO7S`;]bs"2G0pZ]d]39XoZ_=pW?i_+)\1EH^Ohq.'r!t72a,pY-ErCP6Q&C'PUY$f*6X24hYc&k`'hO2gSsN7A`rQ>gaIKc)ITA+pRW)+cX>td*3Yg313!5bjUEKO5b1re/tSdLHs+MHT)UV$lAQam1kE,ORgc(>2U9%)r1IiR"foqo\d5"BX;:#1j3Fm*mjdA@'OL=U@3RWi%4k1K23+[EF.^9bic?uC:,*O9Bgop$tPBZ-/"_?Wae/CZIauReWO9cBg#95FD!Z/J0mijm<*pem@['DLRH'9QreQd]fo*9&p`Y>G02hBeS\@W&/+55FDLZ.MlNdhf>O("F<#S0lPNOU-nB)J+6Wbo"$3tVLgA\Jm5@Gai,gP%6p&WGA"L4/_2to]V/>sH6'`5rNhJTnn=N55HO:\;Y/d2MQ=lR2U9[HCe0W6MFOTLuF3s66Ik6UeT&2I/c0+,TmiKlOrrB\)[=J~>endstream
 endobj
 78 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1664
 >>
 stream
 Gatm:gMYb*&:O"K$rAM5/.tr!?h;i\>pS/]]u7b$pk>#IMmXh1,\=1Rlh??O40c,+?so*^Z6XI&Gim5<M($;Le6^Uekei)1I>fS3BelTb)g#e79B4-`T5V/FLAYHooXF;Z_uH20YDBXLi\1_&GXug-J>JDidl8CF4<hM3dGtO,Icp+U@!K/Y5JYuZ^DdRn$/Pnq0,tEM88o$Mqtm(^OLf9.h8aaVEuS9FrqbUNH^],\^>.O/geQ^%DSFn#cON'%pDo!8hbb5Mq@Ob*T/e!>mlcQF/Rgm:+7pf5f@7@QAED<g6S=^9SQO$>(R[+GOm(8=--\n\P%l3n<`1P$#r67X4*$d+/]I:NArWRngdN<jj^8W0>7YN6(["[6>,su+"O8S;QYWAOApQp&@:_p>U1L1QL!1<q7$YTbr`bXi_N(l!aF&1K%HH#l1GBTk"=Ila1rQ'pPNMY^G&1+/g,LRXa@I04O.&"QP9H$qEg="4=p3jWJWGhRU4E:%f4jLC_B:ij/P3fnpohV(5o:)q,\d4,Q`2k\8Wi/2CK2fkKQqQ9c;Gtr.1;cFX77"]j5%mOI[g6]WKI5s3PtIQCiL"6]l)/[^c#f$<\hHCYVd5W'PFrj5:n#,F1PEDIn17iT*63X;I.kJg5t2=MWpOAJ9$G7V7N*3.RgFUcoWIr_Qjp2J8VA"ZU3*WkdAU3B*!#!gA)^K=]la?(&4!?kgZVW)?(mP\t6A);D&8'!:(4Gi`/38_'"@X/`qjGdhTXVW`Vi]2b!8H_t+Is3M^L+%L*%(+]F\"ap-^%g6>iMNoAlE+r"87/9=[E3>[YZOf`Z>KW><5UI8!*pCR%H3AH8egKIZ,BMkUh;^kcT-(i?3:`Ts?-$Ar.:cgVe2Emt7.9*_E!&?b4H"-u0Q531AmG#*,\K95Oml,Gl2d^LD3:lg\VpDOQ@hL(8#Q'Z<p7ct<Yj4qW%TKJ/TEQa9X*Vri69R@U*"'a_XOY2Ap66YP&PJ887o_N_%LLK&%U.n0_^VF\(_>J&8nV+\Hs9)s#h3@0S@>eIOb+0IEScRVVMn1h,')rss%tJ+5g$2cC+=>5\3LlWFO@AGK,K448MP8aU?LeG]=*f4kLYXaB;7TH808nJZU3SHAm;=4['+Et*^qINXV\P?a8=W]q"F7nO59%"PN4!F#6!1Qi`dXXTPLl_8QV@s69[fBZ&hXe\)).V1M/e%#1^4]U=EdMSYLQYZ'Y>mUeBHWn<Cm8eIC$e*.&-*\'V_+K9:4hpt=5mKF5*/,H)^`L)"KG]MWp9M9U#^gEdoGE@r'K?Ku$J/U(Xl<$\6d$`2Ao,_J7=`?)u'mb+TAj]4tT59j7n],jGH=J2-fXF!&i7'E]><2@ppiD@=R!%?Wg(8H:FF'51+K;63fqm%PkT'LX>iR(mImpAEn@7WMC^A[gQ184\;*Wi_]gfBe)H@[g7P5aP#n^=?RX*oX"b2Z?V0uQ@f6sX;KWHci("n[Qh!&W.B]s3>2PP"_Mra7t-&B9MuQcM-3AYs^J!NUSKHe#B*-]^I")Y_1j&S]/(44p87O=Mb6\P5.l;LJN!.H.p>_KN"oc`>GkH$n\0XLQ>l/E9L*%aQjLp.*lkBQH3bFLlkL92W)dYdlkd?]u5(q3+UQQmJ!(P&lm<TV/;t;e2e+4(>TZXoj"A0=&9D1&~>endstream
 endobj
 79 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1606
 >>
 stream
 Gatn&>>s9I&;B$5/,CPlc5$[k/G\l!,Z&$<&7UlZXl<nS)VYq$))3&_EIRkXO^o)m,qc2OPY=Z;gXi?!2Z`aL$(<@tLu,%OFqIO^;S&Z3kRAuSU@\$%_jg)9fKGUH8Tu8+[(g57h?^^W69jt6E(j^,@A\V\G@<J*a=$`\NmdB\roJla`PhX.aU%@TdE%6M'AW<`5F<\s*Id`angTI/fWB.:&Q@V3qi9M3L7TJ`\u!7+g"5!3a!k<:j\K@]kr#M^\f9EA;$jR;<bb'L8QSdr[M![O+1/=Oe^EmRhY$U/]D9)f*lZCB6<1FUC.3:tW&-Q9\YYS=gPVdN7U*==,A*pT/'Fa*D-Kks<Jg%9W"i>UVR#(NK+6">6$e0m<^I,ACp5rDV(I,97$pkQoM@>RL%0IKT)oI2Du;A`_rl7SDD/cL^STCDY;f58f*c$N"[S:sUP?rPj6MH&?'G%\$6oqP//8Xd-C0H/OM>F_h6Ssre>A&m>WD9uCTpn=5RtgH50`/)$(+J^);A/IqAG$bg9S@37uT[^dYR8XSOY+b.q,@*9QkS653-f%-;jO(#t#X-DeZ0[_S5p7'R^-e%=L&G'M%.E$n!^)*DHI)[HC>KB(];umkJ%dXlNL*GQC[-p/J%*ZA,?YA-P+[E<7Jqd5%JK.9Y5IRo+A3V>J<UR(9,X=cdOoN1:KXHnG+Vij6ur7!lCHZU107=G=B.WhQkVa:T!2B`(c%s%.Bt@#.VE*f.`qh`WHIeX8hpk@,[TQ=dK!Hqqjg.?Pi0NNQ@K`X[$V"'hZU\5=(h;+nHM$*c>iVQsOhOoqn>Loh?CVe%(`GR!MJc(I6u@KihP62PX:f1'/Tn5eC;T<eo/B5=#'^7F@>og9(!Bd_.0-/;#!F2C[EpL8:Snh>G?jQG#.G]CcJY4I%WpcV"k="@^VmeBdfQJ0.>,d[Tu>XAXA;(`$Y27smm_Z_:u^-1O>:l%f7[p'0J<&A@\)Hs8F/oYLLEeJPZEndhnQ&*HdKY^=Qm<Lqpr9a?Q=aKmX5!*AViQ-L3FaINu&[q24lTCM,$$Bo-VDNqjHE#efYDq%&lFi35Af:.P'&u(%Y*>pNd)&-!hKB&NF<_LA,r/rKnueXo2,&.n='YilMT[c1*fE?qd&+m.hIG*UY^emtrBMTS%][$<(mYPi6m<iodrs7YQA[b[YI3H39Jm7Wf.19l2gW?pDKV^pGNoZ^+Wu8pPJclJf^Y\RQ.]\nf37g,*dA@5Fcoe<6?-WCf/L00DcY[=KfBlKjXQr(MbNU[FV%mIAjf`9`G\$jD_8aGGdVU"p\m?[^$oEV7c+SrKO^*;?;Isgms&rqEG^AR,\[E4@!Kie8a)-ZGEiI5WOKWpragG)CQ=12NJ>oGE2ID==9%Ns?3'ENl2-N,\I^i^Rb*:l-t1YV'S<\j3a0"X`iqV851UcCFG6PfRHmRDluO`!F2889rh3ehH_YFnNnJFa-S=MZ:SM41iQ(q.N91jVJ,&g;`3!5>iVn=WVUHW_QfiHHs,qj,nE$Z5fgec99B##Rl],P;Cbg6/Wo"R[1$ngX+6TtgUl50BRR&HmT&3?u4m90U1ipX(rmeEM&%-EU$%6\HX#elR^%i2E_iA%~>endstream
 endobj
 80 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1324
 >>
 stream
 Gatm:?#S^^'RfGR\1]A[<@<D4#Tk^pG$=T,1V4Z^<OEGmQc)I#*':R!1Aq$_:4P*OMA8I*"Ch9)gm`AF07tmj=S&)J!-^6o3+9ThQt='Z5n@R7i*gg%EjZc&qLMKTDsl)8p2+h7K5JJZ>o#ie&Ail]O\4i]_f,Sf"+S"=fe^j$ouk*Ii9ctX5]cgB*(5IUh/GFi`R#"h4qMM4?O074XR!+oXNO'f41L_!3o=Q\Nt@>@%6mVaRhZt=W`=pl_@k10DWtg'';bk2^&B]&*^_eoB>]T:@6N1>_HPOq,[(EbPZkW7K$N<JFul0\M@K`UBEK6<@Z.d,*Tm8(<^o%YDP]YLjanF5#$5at\:Tl*,8-Af?;V"XEIJ@q;Eqf%Eeajc=F@pV\[INrDefc*>WJJm+G&ejMRA.`'Ft2-QWdM=N$[2h>qh<nbHu9\lMuAMGp2G4B[8Om?t!&S_]*iiI0h6S!F]EQV-`O5ot%n7`Y*?]X=X[aSjSXd_lY(@HKC$7me#FDfVGqk<l,Sg'ck>8]Skj;4V].iHp)1V+,hnT3*;bKNcGSod<4`0(H$b<>`Fp7(2-=6o!d[.oNu:n-bo$Ti^C[We%'\DRgmX$Xqid0*pdO(@R1ajn?5?oXmneMa3=q3CiGp1k<nYZ6@RpnC6[>+Yc,hH:gl0hO!A/01P*N#^ci_*bD'Cn=\0+NLDR7PL>c964ifar?b+jqDoW7bUZ+b-U_VlCc/KicfKrP\Hm5iP4!d*QZ,'jXpR5<\4UK>QoBJ--9I83\&"`HGFT1Iim[fAgddmqK7%@OtL([NELKpVPF<[,lE,!H*O$"a72ep1pb%#RRmesQQ$Dgt!K%Z,::%QaERZlF572LhD#-IV^nNp-DGFY?Vn($/1bVG<N^`<p;Kt5(3LUdB*)QuVA=&`VUHEP[TNR<((hW)2VCoNUE:Nu[&4LIZk:#(PZC`=NHGd<QcEYYTskf;pN\MOVP1j;:b@J%hI4$R`YNg3(D\?.6$I\/mkRG]q"XZ65W-/'FFnCu:CJ(W<36l,.Kr=(j:i(T(hmADLoNaiq8c@p;7WL;_.[gu^5+/DYg8l9f[H7';U\d(:lacPX**ot-Hi1B7Fg__dq3gXo?-&k2_VnB0hFpXHLMHore@p1DO[B?1o4"lW%2&dS@T%Ps,6>O-FJWse6[7%D;:B]pC*4n+>,P+Ys?"2:;f_P1mSj-N(=tPkY9F%Y;O0k,Z9U6r3Olt5;Of&'pi<gKPe&ce!%#)&IHT@tY;At"_Bp*2ld^t7,(#S9F!3M'6@LmV^?cbn)[XU>/[-aVBo;(2!CSuF(*OS$)Fp1tI!AA4Cq#~>endstream
 endobj
 81 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 626
 >>
 stream
 Gaqcs6#W8I&;BTM/)IOjZjo!u5VJ6D28)tSdN[f$Mm^b]:;G`=-EHdjG7;)O&I)J5bVsI3Oi[<[o63D#pFU8),c!bRJ1O*>p*[S`S(GpHUeV/SfNn2rYmc+U&b:NPR2!33Th<.s&RYMe<?YF7o2i<FBQ$fF,D30[]8C*VWY@<@iI.lBN8HiXU;V=%RS&i6".j^*-$cZ"]MYZ8`KhgJ2cl0m8CbKhmVh4p/*XC]$r+QGQ?W4&5\=`T9p_h:Od@MimI95:-Uqg!c\28X4kVg-_k!M>bs,^!3&hG.2f29:a%4UI4^tU)8pIW/r2FJ"M^hZe"l9i^d(-KR@pf@-'*cljik!5VOrg<6#P)cg4RmaO7nuoijVC0_Cu5CY3.'FMnfsm$6G12X_g5#C(M0c`KkR!I[EFN0g*oo2puSZoXX]"*jbM7dfjN[X;W,&4D^$dU@o(^ZXWC',mE%\MQZ%,;?#\9>_8Ij+<MD+O<U&@oLaaH-FP`Q*QX!X;CpifODC5ZOSHcbT>T;'48fLWleOmL+?GG]QX1N"^SN8`'G=`NZ_O5eWGm]`V(js[O"*]uG=^%6d\ARS^?Wc.FX4gm8F:H9^_h(u:8@]Cfb4?oqrj<h,f_bsS&b%"~>endstream
 endobj
 82 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1392
 >>
 stream
 Gatm:>uTcA'Rf.Gg_jEl-[74m`p*,(Qd$"Vq8e/Um7bt6`E$GjD(A.4Jc>MZP+=j/C!$i0@hVMH3qqENO%d@,&$aa!#5FG!LG&dd&(qpnk_>1i_`0`f46T1hAfu6Vr]0u,IHA>i+FQ6,,AuEM_2hi[<.d""r<.]Pbl%gQ^ENKn/H:HUf5'@Kk=0\:+qf:k-GqM[+U4#+,`KMJ8.p^"Mk)s9bQ]0'pcpqL3\\p:n$u#?UKIWC7.M\fbDO,E]&*A[q$`0l(CMB*/7.D66\Ktk0AP?,T_N:R^;])9R^Vo36,mTO7c@Uo"`=$!<--H'nZmco*'Q*@H6eIV\7$9gK!7dRrc[4Q*L^AAc48)nfh)TN_bElV[V+&Kl8IH=$.:bq'5m*BL$&%$qBJ\)PH2lrg[jcAG'8!g4o0(r60c!H^GkDVG]DW?9]/Crrm=msTm;5^EJK?_"jT!KKe,KU$js-OCGa83W9o4WZeu:&=N:T81Ko`rOG!!1<kPH*&rOLgX$k8+iu5LAJd*jlUX*+M'k[8Hd^B-d?=J:7Q$+krE`6F9AdG)B$7Mj9iqV$F78n.MNp./"Kf!2G2K0"hF+rX!i:@B^.&9rp$s/9#r%S2nmW"D5pWsfh2^SEp["bchl<N>oKui$&n7X4L<d%+bEi'Q?#*Z.,@^HA<R(TiTY="a$V&]Ao2Hl*uA:-6gFg^l^^uSr)[u*beAr9HRQV?hB$glo4fLYl-d+gI7'!s\ud'I?;)LPVg2I\o\863)X"8oR.-qEdUUE8aQm*fU;TNF'97TFGF7P^9r%EI>^(()N_Bkc2Z&g(/5rD7I:cp)<nkRsZY8_?h5pIa(^I1Hu$/@+`'01sIr5a<+dak<W9:A0r,E$#XpR:R"YhMcMF'qb$]A`GdLLUb`aR>ut*Yp#;nm*??Im@EeV>sCn)$g@2Z;/bl+>!PgN']+;F:3,0U\FYHQ6Gr.%=@6^9VRi>T;p"!i;o$7.MWVo,T]A]Qq.OVV:SM1bD@-kFOsIpte)!6a2,o<B\Sa3*RGN:.J\QfDB-7,'7\C#l3*BJBBKP=^3RG<+?%fn7GM"Cl-@Oe'f)CWo*K)4Z3p50pEt\:eotK%='N@"7;:)S1@6FV*C45FuF6qTs+d4Y7+D+GkXVh3q#DV6:e,X*_)8_DNF5<PmCiMaG09,!OfedkVBhK\Pd'oD8gD-hMEdUPrM6`aEJI9l7$@%f"U+26iNk>I2FX\RocsW@3R:mP@T$a3ffB\\[Kh\E"GFB'U^Qm2J`>-=2&9mjCk844B:WCUuOeqRpa!QpR$im,jMgHcmd3X)p)1[.oZ+AArBosEE=)Va;O5T7[D<dY"5AF[LaI<sUW!74gQ;l6LFoOKbK^<dhPO#QuPI&C,fM''YrF4rl"V,t_B/TB3~>endstream
 endobj
 83 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1722
 >>
 stream
 Gat%"gN)%,'R\5.S<qGJ*K(L_\iEP]j#!=HRA<l\07JID845fX&cbOD^:npo;ASAkC$^f>n?V4bGL$=F:%0,!cb(TN]qUj3@u:q'XXVPiN)oE3HM)+KXLkgs)p;pG?,n&GT@r]IE<hh(i[@M:PY<;EeMOj1Ou]?Vnb3DprCs>"q"7D_mbaGWna&)(U'3ToodHEMb?7O%hnr&"aqe7@jkD6'PHO4#GF(^;SDo<)#9(;Qr5[&.r?^^$Wf"1:LdlfVUg$2jUPh$SjJ8_+WQ&WbXj`94F_f+e>#EqdjU$Q.bF-C5-s)S5mq#A;Jo8c_#g/FS.qp[#:eDs(MS'?/U^rG260jj&Dn"H1[ScI$J/h)./=fR"]%r6KP%Y3&`><7Q?8[FO2H7b&=eu/]8u(,Mn=;lFX[*U\Y.'Z0%M)f@UYPp!<%;U8aifHQTYV9Vdci;TK*h^\j(uimeeB^%ds7JZSiaM*"o,fN1jX69rqcKi-*9ca6-ijPZGA<$"OB:.hb1;<&\V2a\dQ71<7A,cKsJ8/h'$@692HJB8[DLh!1%]$X^r.N9l6j?+NKbaOhWb[[nY-fM5h5V=NmJ]aXd_F'@*a/[=Moi<*Mu0dTT`eocaPU8Li6pb#<*G@A/<Z$X\ak2hM0G1eALA`R5QJCo@EJW\jS.5i/W&kZ3:hiW9CKbA9i9<)0hR,b270N$mDKPErOc0qE[\)[Y[5*kgK(#0M'oHNV\^f],42_>gr5*u?;70Yh!_JF6[b&=2`R1>5-i_ku7HHf8>iWDC+???GfEK;+HiS$iq6b@UP>AokD2\[U/roZ;]304^'/SInWN!4Fc5ZK@O3a5u*9hPp0,'%Qc0YSHFA\SDqO4G1uBrM783cD^W+]B[?VA*AI/B8CT]TPW_JT\0V=<<e%oH=3i=lK.=flRW^1N(tBd'G=da/Ph>WEUIHSZj1lq6]GP/]<2=?)7c*.P/WjN6%:X#[MP0&T&VhkYT??cEpWG.P/9%L%MLBA8Y4s[N^:#"5DIja&+V7q4rO^PVS:<_O[$pD,Ye0+pqLM`:M0VJf?nsX-UEi`X&$3+D_C9R8Efn)a;kNgX2"@s6Y(m"a$!H7>3E&7N4:!%Q5sW*euKD&VR)A.eEKd0Sn$@paa'-@`?\WBCSe0@>T(><-da3bnDao35ELQC%<Lut.QOqthSPl#)/!XmY,Tj[#d]6ti5%V%nDP;F7BdLrJ2;on"j4/VO4b5pmgbjjIC?M#QfEq0K6<cF7?WDMc*-uL:Icu6JauFN3J[puWBT>&L(/LGeb7e5?S_JWP\cpD!Vk,'97dXZ+OiOf\rgK\&/qa7.:XXMEGIc+H$pM:crl9tYc>2qha)T*p$TBEZ$CS@W%'d%'cqQLN=4-DFk^jT$*/>THr>ZX[8>5pb2IlLB%smu7rR5i7[NGKb->C\*8h]N"JFo\WnSs:5!1>[)QYptl!mQBR@au?kk<iq5<l>(s1;`&TDiZGGkmn%c=Y8A1A5Ni59>@?(1E"!WnIORE.iJqFDQuoKVFIY89<`C(=K3W_uG?[6ODO6#93Lq7'faMKMIWfalZp17b)@(pYlF*__XLrA;Itg&<;`595!'#?2N"[$ug7V)=Sd1([QJlJ]bDL.Z*;o.CTZt^;;g;UW*_4-%@rdZW$J+'5K5>*Ydtne9e<<q<I$g."Hh!e:s$^hW^lp6_ZfSMBSh2[Ak^\A*e34#^rh__/OE631uhk8'h/8<&Cd'~>endstream
 endobj
 84 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1500
 >>
 stream
 Gatm:gJ[&k&:N^lqCuf;nKi>kp5.n:1H!']_#)-0i[@oe/K%,T-@\6MZ4dM1:$iW`.Q2:I0;hU<G!mMQ,6(ru7"=<?F:h@a;a.*m(^qkn:?VH0dpE&bllJiPXT';"h+'[hMl:h9LJa/O@uA_8Sn]2!a74tKPh^DRnp`+g_]AaXa6PP7#e"G&$5-m$hh*>9-<Wa?YM51+8s1<>0odkaMS_RGeE%JM=d3LNM"2i$m[dT?1K:j';U\Ak@7mgO(Re=P-uE0;m#$b%=t>g_X#W,WjG]Cp5?9;G.pL9LWJAc1*/)Ef*N%],<#51.&L140c"EhtUPuELYC+miaJ<P>8/<]gVDkl(5:Dbd#oE8`TB8aa"W=Pq.]M]5YQ`c#i.g8C(k3<?6'>!;*k*Xg`^**P"$EDnOEaVXq7m"QZa::D@_VQ!;kqmE/M-1H%:'"bP3smM<-,*/YuOm?K^j<:JZ#k>?)Y>CEn-`C[M/nGBWbL_QV'IDW(U_P<kA(=GQ_,A@8#-SiWb^m$Mgoc*STKMrnWHHehqC_MHTe*kr8MG`51P"=5QdD04/Wno&Ca!ETZk](M<1cm[ElmmV(b:f7EcAe`fAnKrnSc:_r,_Y/'uN[>&H0dW3#4I/0dl8K(@@M2sH:*F((9:`<ZUm=LO91esJAhZ=<P'g`]OGN9Q\_(%0L/s[G35F,6^h*0*BDo!`9>c0jkNhPPB0uFFi*N`#@iTDX]&r`H@"fSV,7;<1&(4HNC&e53J;Cg!Rn1j:t<`P(0'SV982H-j<\meA9)`L=:MUuH-nNnZf'9]ndFc`%.JlZrPH$h1aRNItb2>g8%(JI=,+T!9,gStm-dEh2`AB=GF&5BPGh'i(]`^1#q1`:KcS:GdRi-6g99N5>"CX+L<CZtWL/KQo%.,_jP*_pCqe,`TMYF2c*#\Lr`:@uJG*c#(Xh,1,Z0G(6ulY,NOHNO[9]9-g+P*4QrUIA!4!*L#9Q'P-5Kc/VK@Mj82^3L?PScp8?o>Zl&I##Vaoo0B&d)PD%m2,C;s)Ljn\(CHKl1OeRTJK#^M.6D7SKH8Z:,5R'F7^YaP-'FVh8H(HXDdFFKYSAKcYk5sjRAQC"1eU]=/seMZl0n3K$+\SbP*l3It/*_T5Ik:Q['r2p\R#`Nfs29jJ+F+c/dooae*:U";-dp<;kn?QnDQFoL)!ZS7.F$W9+]A]\bqUV`Zrhb*^*@NTZhb<caXlIrfo*Cib%ubo9].CG/=NV^6+4%drGq#O*QB'Wmod`r6-`K:>JALI)hYjC5Vg:rsJ8TW_0q/*8?c@MtN^A`0qs6#N1`oB-JY$^8&B<ij`>c2)]LXMc>g?=7/$K>I/YN?dWdJFI;cIH.GEr1nC[;lQ*8UoW4D$p$/qXP#SM^Re.uAp>UI_Of_D$5lh9f^2(_/2kmI64JQfqXri754q%mG]EsBM75RM]OhE+-DM+82Yg(U-#_JfZ]OU"`=!*3Hj:_M#=r?a;B(2\DX&r>R3_fH5F`qOqZZC$C4c~>endstream
 endobj
 85 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 1612
 >>
 stream
 Gat=*gMYb8&:O:SbY%ssOD'cN.*6lk@Q7,He>XAp9nB;T.rm(V9lfLSV.K>cHY+^(2OksV@+h@MEoqPjN'\HC-hMo;MWf(PB@e;\&M8&2iuk5\YOl^Xno1nlRIeEB8G;@okrr^s-c/#O1_,.01oG"*!3)^/.Z.gp8Vj":[/>]FDts1t!']10AiL_WEA3.qS\`2Z/r&D>J`+t@9qP__')N;pj)C-6YF]>nK=g6W>Dgb?_6`Ilrl0J+<I.HDOJJ@8)qWZ`mDq10Q*aPon6:V#'[f$WXYeN5<?L!;LcY,TdS^Fi7m8OYY@ofgW7Q4RoOogH=1X]udsu>jZ6[*3mEL`b4[pd#g=4OZa_`oWHD>4(NMYFoMWBu,:=U<+gH'ILf:jN<7:cRIY9&`IE2"OB(.V"h^O>s!cM=#YW#DEQ-2gh8B2n^dX`sF#:S__>D_'q_%<*fb;6FG5+qEnb>,Q.Al.2Ht_N$BG[<;]A1A^$s7)R[H-eF)@]mCMkW[qDo/`Fc3Z*QW\MH?T/02h1rPQ<?R^M9kip*bXOb"'`LU!!k<h%d%(<4#e_!-r3I?Y*82Ru&0%%LW(+L28#,'D*E>OjL"*2OlcH]O9K0^.!t[iS3>skr*ra2nqO:V_>/J"uWDK8i_P$Jdcq8-A-`oLN1cY_MY`DK/.2r85S8BIOC_#0aT2aN$fNb-pJDDniERX+,52W7>;GR`c=M@#q1BS0:s.s<$c<MGk$>+CW,u)[gGRl9"Z(<\n\SUbB-J\Wp+I'QeBn<Eq$$geoI@.$u[4eNpKCZl`tZ)M-q4''cScL!PNX4#FZ/h>e?9`]LQG]>cCKKS_XLeQ3JOb>F!7B+?lKh&!_0'.?.^#;7KOi_,?RuTJL*p/2R-a5HD>5):ljk$?hK*Dr&g'6&JRpd50a*Gu=LsOLeQ*S:NL$JMb_+;@J[[HPBA[kqb(md%(i)*gJ>],HOXqA5`L`3R+*^VAd_'LE*OrcP:lWf(T4I2Q1Anclc?k)/OmJ9Qa',eOVu-(?RA21><YIU0pJe11a;pAC@q]#Zsp#nm$LE?hN=Fd<i=ckl#6DN91B)@q^"W0CM]Pp$G>TQpoJK6$OaH$j9q]a-/s11TRAbAf^nHU(CfcS1_T7\pWNioLLX5)h+Ql;q'EB$r-4Q`hh;;1^Fbb=CsDbb,m?"CUT$_FY1bM"$]VD/^#08)o7BaF"ZWaZ#@E>->?8X&CY`ebbf_lF@l,LZs]m.G2$F491FO<)7OqU-'L1j)OdO?/]j!dJ81?4@#j1=GS^%H%kU6gb9h(sAU=+p#[k\bISopUT^CsLY[p'Yg3TT.9R%rhj,37aL>Ll\&5K)-kYC,"7b0=0i"!pY(TN-m<MM7C3&<p*[kCJnq9X_;cTId&nU/o7Cg-uS_$;$H+>UN=l)2[$[$6HZZeHukj)K;\Ra2V:o^6U#Lf]H0B6Jmidl4GA![EjGD(GBFj<QRL2JRZY*$mlf*K+Mi$.c.nVd&buX)icSU9n2drB@rC.-F%b.kB3IfI'-C9"0Tdd,7Tk%Dj.^,i^![+:hDiG9>lo<=O&RCs=OF0c>D#?2ql[D\0<?-6s"sEAHEU:iQ>94mgq"N-2tA.Np3)5%JT8><;QjHXmt?~>endstream
 endobj
 86 0 obj
 <<
 /Filter [ /ASCII85Decode /FlateDecode ] /Length 921
 >>
 stream
 GasJP9i'Ou&;KZN.n8e-&=D*iOpr4,W_u^e5heiCE&!2n@n>r4G1bs7GO0\W]8,fE^21RUbWDCmM""'TZ"sGY$FmaF5T(7TTU]sLI_aQEos1#Uep\_hl1>rK`a?4J1[$+),"c=Q#*og"C>n6)YmfV#r:q%a-Rd:<nt.<mY=UO?S)A:G,l!m?CE?E7i[N&q![OXGb-Q^k&]?lKjXgQQ"mFU6;4<V0_9o!/PP\,>;XGA/T4g&O^N_shTH(kfD_P$$j_JDBA&O`*+\Ol&Ye\,-9crD&_%4'kjT,%GWVY%kE8qdd`X>*Sd6+6jGg7a,()m(r&Ha*mijjji_f&D/(K&(odA[/m_SR,<mS'f7\8-<JIipkO,KS8'bbG=RSI*&<hc;"R4YgY$iAog698Dlt>+@CpXK_gXr*r39"48BL:;Y7YLp/9JAk*_/jcCY+MYh251%@7NIYZ-)s&2Qi;\fSdGH`%"L9g8/WEh:[-EQhT>(a."odiCZSLhW@8k%iIROuWPZDNiT_hle3_PpR&=ehC&GW5k.$iNiZBenAfh&7AJR<f<$EnQ%!8J=;PegP=i'uF&Xnl9i8Cnu#5ntEXI8kBEf>&'ZA=D)f]'8+mPc='JjBX.mkB_:XZiR\A4*1X7=fj)AL#4B-3"jWbCS_9XQhXh96f4`jsQ9e[0,Cl2I3Jk(2q,(n;;%@ctps$KRXu<tG<aPY/Y!u?th94*16(@HG?AhmA2\$mUeMn,HE(Vn.Qg-G<MhJRZZ>*PD:Zdc>B&ua()QC2d%,d3\6rer8^9osGad_d1WBEbZ0Y`cOD0:AoJ!D8J)%Kk^[KD.iNC#L7FmRB^?T=g(/"X"6b#p,S$tD=+^"0KRer"A7a<HH8=FGf`82uH<$0uAC2R@#@I>9JojkQ[^F=DM0rea6'#G7G#<rW/oif`!~>endstream
 endobj
 xref
 0 87
 0000000000 65535 f 
 0000000061 00000 n 
 0000000169 00000 n 
 0000000276 00000 n 
 0000000388 00000 n 
 0000000503 00000 n 
 0000000698 00000 n 
 0000000893 00000 n 
 0000001003 00000 n 
 0000001198 00000 n 
 0000001393 00000 n 
 0000001503 00000 n 
 0000001699 00000 n 
 0000001808 00000 n 
 0000002004 00000 n 
 0000002200 00000 n 
 0000002396 00000 n 
 0000002592 00000 n 
 0000002788 00000 n 
 0000002872 00000 n 
 0000003068 00000 n 
 0000003264 00000 n 
 0000003342 00000 n 
 0000003538 00000 n 
 0000003734 00000 n 
 0000003930 00000 n 
 0000004126 00000 n 
 0000004322 00000 n 
 0000004518 00000 n 
 0000004714 00000 n 
 0000004910 00000 n 
 0000005106 00000 n 
 0000005302 00000 n 
 0000005498 00000 n 
 0000005694 00000 n 
 0000005890 00000 n 
 0000006086 00000 n 
 0000006282 00000 n 
 0000006478 00000 n 
 0000006674 00000 n 
 0000006870 00000 n 
 0000007066 00000 n 
 0000007262 00000 n 
 0000007458 00000 n 
 0000007654 00000 n 
 0000007850 00000 n 
 0000008046 00000 n 
 0000008242 00000 n 
 0000008312 00000 n 
 0000008642 00000 n 
 0000008961 00000 n 
 0000009641 00000 n 
 0000010358 00000 n 
 0000010745 00000 n 
 0000011683 00000 n 
 0000013195 00000 n 
 0000014951 00000 n 
 0000016859 00000 n 
 0000018521 00000 n 
 0000019952 00000 n 
 0000021495 00000 n 
 0000023267 00000 n 
 0000025183 00000 n 
 0000026811 00000 n 
 0000027977 00000 n 
 0000029556 00000 n 
 0000031339 00000 n 
 0000033190 00000 n 
 0000034828 00000 n 
 0000036189 00000 n 
 0000037681 00000 n 
 0000038977 00000 n 
 0000039403 00000 n 
 0000040945 00000 n 
 0000042441 00000 n 
 0000043433 00000 n 
 0000045071 00000 n 
 0000046970 00000 n 
 0000048747 00000 n 
 0000050503 00000 n 
 0000052201 00000 n 
 0000053617 00000 n 
 0000054334 00000 n 
 0000055818 00000 n 
 0000057632 00000 n 
 0000059224 00000 n 
 0000060928 00000 n 
 trailer
 <<
 /ID 
 [<43449a1a04327378ce418c00206984f2><43449a1a04327378ce418c00206984f2>]
 % ReportLab generated PDF document -- digest (opensource)
 /Info 48 0 R
 /Root 47 0 R
 /Size 87
 >>
 startxref
 61940
 %%EOF