Hermes Bot
19 lines
1.5 KiB
Markdown
19 lines
1.5 KiB
Markdown
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.]* |