BAYAN
Client
- Self-directed
Project type
- Quranic Analysis Engine
What I did
- Next.js
- TypeScript
- Tailwind CSS
- Zustand
- Claude Code
Year
- 2026
BAYAN reads the Quranic text on three axes at once — linguistic, numeric and structural — and adds a layer existing tools don't have: a concept graph placed on the actual chronological order of revelation, where a claimed relationship between two concepts is either sourced to a named classical commentary or it is a measured statistical result, printed with the test that produced it.
- 01
Existing digital Quran tools stop at translation and root lookup. Nothing ties a word's position to when it entered the text, or lets a reader ask whether two concepts actually co-occur more than chance would predict.
- 02
The one prior attempt at a concept ontology for this text (corpus.quran.com) is static and atemporal — a fixed taxonomy with no way to verify a number without trusting the source, and licensed in a way that rules out building directly on top of it.
- 03
A root is not a concept. The root ج-ن-ن alone produces جَنَّة (paradise) and جِنّ (jinn) — anchoring a concept on the wrong linguistic unit silently produces a plausible, wrong graph, and nothing about a wrong graph looks wrong.
- 04
Any co-occurrence claim computed naively is a false-positive machine: verses vary from 1 to 128 words, so two frequent words "correlate" for no reason beyond both appearing in long verses.
- 01
The full corpus rebuilt from source into a positional index of roots and lemmas — every number on screen is recomputed at build time from raw text, never hand-entered, and a script audits the graph against that index on every build.
- 02
36 concepts anchored to the exact lemma or root that carries the sense, each shipping the caveat that names what the anchor does and doesn't cover — the جَنَّة/جِنّ ambiguity above is exactly what this layer exists to prevent.
- 03
A "discovered relations" layer built on real statistics, not a spreadsheet correlation: a null model that accounts for each verse's actual length, a Poisson significance test, and a Bonferroni correction across every pair tested — only 11 of 496 candidate pairs survive.
- 04
Chronology by order of revelation rather than page order, which is the axis that makes a question like "when did this concept enter the text, and does it cluster with another one" answerable at all.
- 05
Built as a close working pair with Claude Code: the model produced the code, the standing job was setting the constraints (data licensing, statistical rigor, what never ships without a source) and catching what a model's own confidence hides — including a bidi-mirrored `<` character that silently flipped a displayed probability's meaning, and a chronological-correlation feature that was cut after discovering it was measuring verse length, not meaning.
Tracing a concept through revelation order
Open a concept and its full chronology appears against the 114 chapters in revelation order rather than page order — which chapter introduces it, where it clusters, where it goes silent for decades.
Testing a hypothesis instead of assuming one
Ask whether "mankind" and "water" are linked in the text: the direct co-occurrence comes back at zero across 6,236 verses — a real, checkable negative — right next to صلاة/زكاة at a measured ×33, so the two are never confused.
Auditing a claim back to its source
Click any relationship and see either the named classical commentary behind it, or the exact verses, the p-value and the effect size behind it — nothing is shown as a fact that the interface can't also show you how to check.
36 concepts placed on a fixed radial layout — never a force simulation, so "the branch on the right" means the same thing on every reload. Solid lines are editorial relationships sourced to classical commentary; dashed lines are statistically discovered co-occurrences, drawn only where they survive the test on the right.
Wavvy
