Source-linked AI summary
Muslim: A Deployed Arabic Voice AI Platform for Grounded Islamic Knowledge
Yahya Mohamed Elnawasany
TL;DR
Arabic voice assistants often provide poorly tuned Arabic and unsourced Islamic answers, motivating a platform for grounded, sourced Islamic knowledge. MUSLIM combines an Arabic voice pipeline with retrieval and released models; measured results include 98.4% recitation-validation accuracy and 0.9–1.7s estimated end-to-end voice latency. The paper also describes deployment limitations, including single-host voice availability and dialectal Arabic scope.
Problem
Commercial assistants handle Arabic poorly and answer Islamic questions from parametric memory rather than cited texts, while third-party cloud routing raises concerns for this domain.
Source: §1 · p. 1Method
Results
98.4% (122/124) recitation-validation accuracy was reported; estimated end-to-end voice latency is 0.9–1.7s, and retrieval succeeded for 100% of 30 held-out Islamic questions.
Source: §7.1 · p. 4, §7.2 · p. 5, §7.3 · p. 5Takeaways & Limitations
On 30 held-out Islamic questions, retrieval grounding added only ∼50ms mean latency over parametric-memory answers, supporting sourced responses without a meaningful latency cost in that test.
Source: §7.3 · p. 5The single GPU host can prevent conversations while the web tier remains available, and dialectal Arabic speakers may see elevated ASR error rates.
Source: Limitations · p. 5
Abstract
from arXiv · showhide
We present Muslim, a production Arabic voice AI platform serving grounded, sourced Islamic knowledge to real users. Beyond a real-time voice pipeline (NeMo Arabic ASR, an OpenAI-compatible LLM endpoint, self-hosted TTS) and a deterministic multi-source retrieval layer routed across six Model Context Protocol servers, we report three things a research prototype typically lacks. First, a released family of fine-tuned Arabic Islamic model artifacts: an efficient tool-routing LLM (Muslim-6B-PRO, 5.94B parameters) and a Modern Standard Arabic TTS model (Fasih-TTS-V1) that ranks 5th of 17 overall and 2nd of 11 open-weight systems on the community-voted Arabic TTS Arena for MSA. Second, an account and metering layer - a free per-account turn allowance, capacity-aware refusal, and email verification deferred to the point it actually matters - that turns an open demo into an operable, abuse-resistant product. Third, a three-layer observability stack (liveness, error reporting, product analytics) built specifically around the system's characteristic failure mode: a GPU-bound agent host going silent while the web tier keeps serving normally. We report real, measured latency and accuracy figures (98.4% recitation-validation accuracy on 124 cases; end-to-end voice latency of 0.9-1.7s) and discuss the concrete engineering trade-offs and limitations of running an Islamic-knowledge voice product in production.
1 Introduction
MUSLIM addresses gaps in Arabic voice assistance and sourced Islamic answers with a deployed system built around Arabic support, retrieval from verified sources, and operator-controlled compute. The paper reports contributions spanning the voice pipeline, released models, account and metering, observability, and measured evaluation.
1 Introduction
- The deployed system combines Arabic-specialized ASR, an configurable LLM endpoint, self-hosted TTS, and a six-server retrieval layer.The paper presents MUSLIM as a deployed system rather than a prototype.Source: §1 · p. 1
- The released model family includes fine-tuned Arabic Islamic artifacts, including an MSA TTS model ranked on a community leaderboard.Source: §1 · p. 1
- The account and metering layer combines a free rolling turn allowance, capacity-aware refusal, and deferred email verification.The paper says this layer was undocumented in prior Islamic-voice-AI work because prior work did not need to survive real traffic.Source: §1 · p. 1
- A three-layer observability design targets a specific failure mode of the deployed system.Source: §1 · p. 1
- The evaluation combines measured latency and accuracy with reliability evidence from an automated test suite.Source: §1 · p. 1
2 Related Work
Prior Arabic voice assistants, text reference sites, and recitation-validation research each leave gaps in sourced conversational access or deployable recitation feedback. MUSLIM combines real-time Arabic voice interaction, source-attributed retrieval, deterministic validation, and production operations in one platform.
2 Related Work
- Commercial assistants lack Arabic-specific speech tuning and source attribution for Islamic answers, while reference sites lack conversational voice and recitation feedback.Source: §2 · p. 1
- Prior Quranic recitation assessment primarily uses acoustic methods requiring Tajweed-aware models or large labeled-error corpora not yet available at production quality (Radford et al., 2023).MUSLIM instead validates normalized ASR text, trading acoustic-level Tajweed detection for a deployable deterministic pipeline without a training-data requirement.Source: §2 · p. 2
- MUSLIM applies retrieval-augmented generation (Lewis et al., 2020) to reference-addressable religious corpora, using deterministic direct lookup for specific verses or narrations.The paper reports no prior published system combining this with real-time Arabic voice interaction, recitation validation, and production account, metering, and observability layers.Source: §2 · p. 2
3 System Architecture
MUSLIM separates its browser, stateless voice agent, and knowledge services, with operator-controlled infrastructure for the Arabic-specific compute-heavy core. Its pipeline combines Arabic ASR, configurable LLM and TTS services, and retrieval across six MCP servers.
3 System Architecture
- The browser reaches a stateless voice agent through LiveKit, and the agent runs voice processing and dispatches tool calls to knowledge servers over MCP.Source: §3 · p. 2
3.1 Voice Pipeline
- Arabic FastConformer ASR is chosen for training on formal and religious Arabic, while preloaded VAD and preemptive generation address latency.The LLM endpoint and TTS are configurable; TTS defaults to a self-hosted model with a cloud fallback.Source: §3.1 · p. 2
3.2 Deployment: Two Coexisting Topologies
- The hybrid production topology places the web and account tier on managed services and the voice agent and GPU-dependent ASR/TTS on one operator-controlled host.This keeps the compute-heavy Arabic-specific core under operator control, but the website can remain available when no conversation is possible because the voice agent is down.Source: §3.2 · p. 2
3.3 Knowledge Retrieval: Six MCP Servers
- Six MCP servers provide knowledge retrieval, with three operator-controlled; Tafsir uses direct JSON lookup and Hadith retrieval is self-hosted across 50,000+ narrations in 17 collections.Quranic verse requests bypass LLM/TTS and stream authentic human recitation; the system does not synthesize Quranic audio with TTS.Source: §3.3 · p. 2, Table 1 · p. 3
4 Released Model Family
MUSLIM releases fine-tuned Arabic Islamic model artifacts, including an MSA TTS model and an efficient tool-routing LLM. The paper reports Fasih-TTS-V1’s community leaderboard standing, while noting that two released ASR checkpoints are not evaluated here.
4 Released Model Family
- The paper releases a family of fine-tuned Arabic Islamic model artifacts, with two primary artifacts summarized in Table 2.Both primary artifacts are used in production behind environment-switchable configuration; the live LLM is a larger general-purpose model, with Muslim-6B-PRO a path toward fully self-hosted inference.Source: §4 · p. 3, Table 2 · p. 3
- Fasih-TTS-V1 ranks 5th of 17 systems overall and 2nd of 11 open-weight systems on the Arabic TTS Arena for MSA.The reported snapshot is dated 2026-08-18 and covers 245 head-to-head MSA battles; the arena is continuously updated.Source: §4 · p. 3
- Two further released Arabic ASR checkpoints are not evaluated further in this paper.Source: §4 · p. 3
5 Accounts, Metering, and the Capacity Wall
Access to conversations is mediated through account entitlement and a token-minting route, with a free rolling allowance, deferred email verification, and a capacity check. The design combines hard turn enforcement with a fail-open capacity query.
Access control
- A single route concentrates access control: it checks session and entitlement, then either refuses for a typed reason or signs the allowance into an unforgeable participant token.The listed refusal reasons include sign-in, quota, verification, capacity, and agent-availability conditions.Source: §5 · pp. 3–4
Tiers
- The single allowance grants 30 turns per rolling 24-hour window, with the agent enforcing the token-signed limit even if database usage reports fail.Database usage is accumulated across sessions and counted by turn index so a retried report does not double-count.Source: §5 · p. 4
Deferred verification
- Email verification is required to refill the allowance, not to sign up, deferring the confirmation step until after a user’s first-use window.An unverified account is limited to one window’s turns.Source: §5 · p. 4
Capacity wall
- The token route checks the agent’s reported active-job count and refuses with a distinct reason when capacity is saturated.The check is fail-open: a capacity-query error allows requests through so a monitoring fault cannot itself take the product down.Source: §5 · p. 4
6 Observability
Because the GPU-bound agent can go silent while the web application remains responsive, the system monitors the agent through an external heartbeat and combines liveness with error reporting and product analytics.
Liveness
- An outward agent heartbeat lets an external judge detect staleness even when the web tier continues serving normally.The public health endpoint reports healthy, degraded, or down in both its body and HTTP status; degraded includes an agent alive but unregistered with the media layer.Source: §6 · p. 4
Error reporting and product analytics
- Error reporting captures web exceptions and agent-side failures swallowed to keep a conversation alive, while analytics tracks a small set of funnel events.Analytics counts a conversation as started only when a token is issued, and uses an internal identifier rather than email; the stack also avoids session replay and default PII capture.Source: §6 · p. 4
7 Evaluation
Evaluation reports validator accuracy, voice latency, retrieval success, and automated reliability evidence. The results include a validator measurement correction and operational limits on the test workflow.
7.1 Recitation Validator
- 98.4% (122/124) on the 124-case suite; 16.5% of Qur’an verses share an ambiguous normalized four-word opening, so the product asks for continuation rather than guessing.An earlier 99.2% figure came from an environment that silently skipped the fourth search layer; the released artifact removes this dependency class by using only the Python standard library.Source: §7.1 · pp. 4–5
7.2 Latency
- 0.9–1.7s is the estimated end-to-end latency from speech end to first audio response under typical conditions.Measured ASR mean latency is 235.5ms (RTF 0.025), and LLM first-token mean latency is 519.7ms.Source: §7.2 · p. 5
7.3 Retrieval Grounding
- 100% of 30 held-out Islamic-question queries retrieved successfully, with retrieval adding ∼50ms mean latency (786ms vs. 736ms).Source: §7.3 · p. 5
7.4 Reliability Evidence
- Over 1,000 automated tests cover the validator, retrieval tools, and account/metering logic, but the configured CI workflow is inactive pending private-repository billing resolution.The suite includes 889 Python and 119 Type-Script tests and runs on a pre-push git hook.Source: §7.4 · p. 5
Limitations
The paper identifies deployment, evaluation, and coverage boundaries, including single-host availability, dialectal Arabic performance, and the absence of a formal user study.
Availability
- The single GPU host makes conversations unavailable when it is offline, despite the web tier and account system remaining available independently.The authors consider this acceptable during beta, but not for a paying userbase without redundant capacity.Source: Limitations · p. 5
Language and user-study scope
- The ASR targets Modern Standard and Quranic Arabic, so dialectal speakers may see elevated error rates; evaluation includes no controlled study of learning outcomes or perceived response quality.Source: Limitations · p. 5
Retrieval and model-evaluation boundaries
- Questions outside the indexed Tafsir, Hadith, and metadata corpora fall back to parametric knowledge and may be inaccurate; formal faithfulness evaluation remains future work.The model card also lacks quantified benchmark results, and the reported live Arabic TTS Arena rank may shift.Source: Limitations · p. 5
Ethical Considerations
MUSLIM’s ethical safeguards make conversation capture depend on both operator and user consent, avoid session replay, and limit confident answers to verified retrieval domains.
Ethical Considerations
- Conversation capture requires both an operator-level switch and the user’s choice, with consent stored in the access token independently of usage metering.The token carries identity and consent together.Source: Ethical Considerations · p. 5
- No session replay is enabled, and product-analytics identity uses an internal identifier rather than an email address to protect sensitive religious inquiries.Source: Ethical Considerations · p. 5
- Retrieval paths are designed to decline or hedge outside covered domains rather than answer confidently from unverified parametric memory.Source: Ethical Considerations · p. 5