Middle Ground Musnad — Project Overview

Working Title

Musnad Middle Ground

Proposed public URL:

https://www.muslim.center/musnad-middle-ground


Project Purpose

Musnad Middle Ground is a structured repository of the aḥādīth cited, quoted, discussed, paraphrased, or otherwise used across Middle Ground content.

The goal is not simply to create a list of aḥādīth. The Musnad is intended to connect each canonical ḥadīth to the places where Middle Ground has used it over time.

A single ḥadīth might therefore connect to:

  • a khuṭbah;
  • a khāṭirah;
  • a class;
  • a Fajr Club talk;
  • a blog post;
  • a Q&A post;
  • a podcast episode;
  • a transcript;
  • another Middle Ground teaching resource.

The core relationship is:

canonical ḥadīth

source / citation information

Middle Ground usages

The same ḥadīth should exist once as a canonical entity, with multiple Middle Ground usages attached to it.


Primary Objectives

Musnad Middle Ground should eventually allow a visitor to answer questions such as:

  • What is the Arabic matn of this ḥadīth?
  • What is its English translation?
  • Who narrates it?
  • Where is it collected?
  • What ḥadīth number or book/chapter reference is associated with it?
  • What did Middle Ground originally cite?
  • Has that citation been independently verified?
  • Has the narration appeared in more than one collection?
  • In which Middle Ground khuṭbahs, classes, posts, or podcasts has it been used?
  • What related topics does it address?

The system should also support future semantic relationships between aḥādīth and other Middle Ground content, such as topic pages, Qurʾān references, scholar pages, and thematic knowledge clusters.


Core Publication Requirement

Every ḥadīth that is ultimately published in Musnad Middle Ground should be presented bilingually:

  1. the Arabic matn;
  2. directly beneath it, the English translation.

The canonical data model already supports:

"text": {
  "matn_ar": "...",
  "translation_en": "..."
}

However, these fields may remain incomplete during extraction, staging, review, or verification.

The stronger rule applies at publication time:

A normal public Musnad entry should not be considered publication-ready until both the Arabic matn and English translation are present.

Historical candidates may still exist internally with one or both fields missing, but the public page-generation phase must enforce the bilingual presentation requirement.


Existing Middle Ground Website Architecture

The architecture audit established that Middle Ground is currently a plain static site.

Key characteristics:

  • no framework;
  • no CMS;
  • no database;
  • no templating layer;
  • hand-authored static HTML;
  • Node-based helper/build scripts;
  • Pagefind for search;
  • Vercel for deployment;
  • filesystem-based routing;
  • existing validation and link-checking scripts.

The repository already follows a “filesystem as source of truth” model.

That led to the approved Musnad architecture:

musnad/
├── records/
│   ├── mm-h-0001.json
│   ├── mm-h-0002.json
│   └── ...
├── schema/
│   └── record.schema.json
├── scripts/
│   └── ...
├── staging/
│   └── ...
└── review/
    └── ...

musnad-middle-ground/
├── index.html
└── ...

The rendered HTML will eventually be generated from the structured Musnad data.

The HTML must never become the canonical database.


Canonical Ḥadīth Identity

Every canonical ḥadīth receives an immutable opaque ID:

mm-h-0001
mm-h-0002
mm-h-0003

The ID must not depend on:

  • collection;
  • ḥadīth number;
  • Arabic wording;
  • English translation;
  • slug;
  • topic;
  • current verification state.

This is important because citation information may later be corrected or expanded without changing the identity of the Musnad record.

Candidate IDs use a separate namespace:

mm-c-0001
mm-c-0002

A candidate is not a canonical ḥadīth merely because it has been detected.

Canonical mm-h-* IDs are assigned only when a human reviewer promotes a candidate into the Musnad.


Canonical Data Model

A canonical record is designed to represent several distinct layers of information.

Identity

{
  "id": "mm-h-0001",
  "status": "needs_review",
  "slug": "..."
}

Current allowed statuses:

  • needs_review
  • partial
  • verified

Canonical text

"text": {
  "matn_ar": "...",
  "translation_en": "..."
}

Narration information

Narrator information is structured so that the Companion-level narrator is not collapsed into a generic string containing transmission names.

The model distinguishes:

  • Companion narrator, when explicitly known;
  • transmission/isnād names as published by Middle Ground;
  • unknown narrator information.

The system must not infer missing narrator data.

Citation information

The most important distinction is between:

what Middle Ground published

and:

what later independent verification determined

The model therefore separates:

"citations": {
  "as_published": [],
  "verified": []
}

as_published preserves the historical citation exactly as Middle Ground presented it, including structured fields and raw citation text.

verified is reserved for independently checked source information.

A complete published citation does not automatically count as verified.

Middle Ground usages

Each canonical record may contain many usages:

"usages": [
  {
    "content_type": "...",
    "title": "...",
    "date": "...",
    "canonical_url": "...",
    "local_source_file": "...",
    "context": "...",
    "quoted_form": "full"
  }
]

Current quoted_form values:

  • full
  • partial
  • paraphrase
  • reference_only

Topics

"topics": []

Topics remain free-text at this stage.

No controlled taxonomy has yet been imposed.

Verification

Verification metadata remains distinct from extraction or review confidence.

The system tracks:

  • review state;
  • verification confidence;
  • conflicts;
  • notes;
  • reviewer;
  • review date.

A record may be human-reviewed yet still incomplete.

For example:

status = partial
review_state = reviewed

Verification Standard

The project deliberately distinguishes:

Citation completeness

A Middle Ground page may give:

  • collection;
  • number;
  • narrator;
  • direct source link.

This is useful extraction data.

But it remains:

citations.as_published

Independent verification

A record becomes truly verified only after a separate verification process confirms the citation independently.

Therefore:

“The original page cites this clearly” is not the same as “Musnad Middle Ground has independently verified this.”

This distinction is a central project guardrail.


Source Relationships

The verified-source model supports relationships such as:

  • primary
  • parallel
  • variant
  • similar_wording
  • abridged

These labels are representational only.

The software must not make scholarly judgments about parallel or variant narrations automatically.


Historical Extraction

The project includes a historical extraction system for finding aḥādīth already present in Middle Ground content.

The architecture has two layers:

deterministic discovery

conservative classification

staging

human review

Deterministic discovery

The extractor looks for broad signals such as:

  • قال رسول الله
  • قال النبي
  • رواه
  • ḥadīth collection names;
  • “the Prophet said”;
  • “narrated”;
  • “reported”;
  • Sunnah.com links;
  • Dorar links;
  • Arabic blockquotes;
  • isnād-like text.

These signals improve recall.

They do not determine that something is a ḥadīth.

Conservative classification

Candidate passages may be classified as:

  • prophetic_hadith
  • athar
  • quran
  • scholar_statement
  • other_quote
  • uncertain

The current classifier is deterministic and heuristic, not a scholarly authority.

classification = prophetic_hadith means:

this looks like a probable Prophetic ḥadīth occurrence worth reviewing.

It does not mean:

this narration has been independently identified and verified.


Historical Extraction Results So Far

The first full-corpus extraction scanned 38 content files.

It produced:

48 candidate passages

20 prophetic_hadith
15 uncertain
12 quran
1 scholar_statement
0 athar
0 other_quote

The extractor correctly handled several difficult historical cases, including:

  • fully cited bilingual aḥādīth;
  • Arabic/English blocks representing the same narration;
  • narrator information without collection information;
  • unattributed famous aḥādīth;
  • Qurʾān verses adjacent to ḥadīth material;
  • paraphrased narrations.

The extractor also found and corrected a false-positive problem caused by treating the ordinary word “Muslim” as a strong collection signal.


No-Invention Rule

Extraction must preserve what Middle Ground actually contains.

It must never silently supply:

  • a narrator;
  • a collector;
  • a collection;
  • a ḥadīth number;
  • a grading;
  • missing Arabic;
  • missing English;
  • a fuller matn;
  • an inferred isnād.

If the source does not provide something, the field stays unknown.

External scholarly identification happens later.


Staging Layer

Historical extraction does not write directly to:

musnad/records/

Instead it writes noncanonical candidates into:

musnad/staging/

Candidate IDs use the mm-c-* namespace.

Staging records preserve:

  • source file;
  • canonical URL;
  • page title;
  • page date;
  • source location;
  • detection context;
  • classification;
  • detection confidence;
  • Arabic text as published;
  • English text as published;
  • narrator information as published;
  • citation information as published;
  • quoted form;
  • possible relationships;
  • review notes.

The staging layer exists to support review, not publication.


Review and Promotion Workflow

The project is moving toward a human-review workflow with dispositions such as:

pending
dismissed
linked_existing
promoted_new
deferred

Dismissed

The candidate does not belong in the Musnad.

Examples:

  • Qurʾān;
  • scholar statement;
  • false positive;
  • duplicate local extraction.

Deferred

The candidate may belong in Musnad, but cannot yet be responsibly identified or linked.

Linked existing

The candidate is a new Middle Ground usage of an already-existing canonical ḥadīth.

The workflow should append a new usage to the existing mm-h-* record rather than create a duplicate canonical record.

The reviewer determines that the candidate represents a canonical ḥadīth not yet represented in the Musnad.

A new mm-h-* ID is allocated.

Promotion does not equal scholarly verification.

A newly promoted record should still begin as:

status = needs_review

with:

citations.verified = []

until independent source verification occurs.


Deduplication Principles

The same ḥadīth may appear:

  • with or without tashkīl;
  • with punctuation differences;
  • in different translations;
  • partially quoted;
  • paraphrased;
  • in different collections;
  • through different transmission routes.

The system therefore distinguishes between:

Strong deterministic evidence

Examples:

  • exact collection + number;
  • exact normalized Arabic wording.

These may be surfaced as strong match suggestions.

Fuzzy evidence

Examples:

  • partial text;
  • English similarity;
  • minor wording differences.

These remain suggestions only.

Scholarly relationship judgment

Examples:

  • parallel narration;
  • variant;
  • materially different wording;
  • different isnād.

These are never automatic.

Human judgment is required.


Qurʾān and Āthār Guardrails

The architecture audit showed that Middle Ground uses similar HTML markup for:

  • Qurʾān;
  • ḥadīth;
  • other quotations.

Therefore HTML structure alone cannot classify content.

The extractor explicitly guards against misclassifying Qurʾān verses as Prophetic aḥādīth.

It must also avoid treating:

  • statements of Companions;
  • Tābiʿūn;
  • imams;
  • mufassirūn;
  • later scholars;

as Prophetic aḥādīth unless the source explicitly attributes the statement to the Prophet ﷺ.


Public Musnad — Planned V1

The public Musnad has not yet been built.

The planned V1 includes:

Index

/musnad-middle-ground/

Individual ḥadīth pages

The immutable mm-h-* ID should form part of the public identity.

The exact route format is still to be finalized.

Possible forms include:

/musnad-middle-ground/mm-h-0001.html

or:

/musnad-middle-ground/mm-h-0001/<slug>.html

The slug must not be the canonical identity.

Public page content

Every published ḥadīth page should eventually include:

  1. Arabic matn;
  2. English translation directly underneath;
  3. narrator information;
  4. source/citation information;
  5. verification status or note where appropriate;
  6. all known Middle Ground usages;
  7. backlinks to those resources;
  8. relevant topics.

Records still marked needs_review should not be rendered publicly.

A future rule should ensure that normal public entries contain both Arabic and English text.


Search and Discovery

The site already uses Pagefind.

Musnad pages should eventually enter the existing search system automatically.

Search should support discovery by:

  • Arabic matn;
  • English translation;
  • narrator;
  • collection;
  • ḥadīth number;
  • topic;
  • Middle Ground usage.

The existing Pagefind architecture is preferred over creating a separate Musnad search backend.


Explicit Markup for New Middle Ground Content

Historical content requires AI-assisted or heuristic discovery because it was not authored with Musnad in mind.

New content should gradually become explicit.

A likely convention is:

data-musnad-id="mm-h-0001"

on an existing ḥadīth quotation block.

This would allow a future incremental ingestion process to know:

this quotation intentionally refers to this canonical Musnad record.

That moves the system from:

AI guessing

toward:

author-declared structured relationships

while preserving backward compatibility with older content.


Incremental Ingestion — Planned

After the historical corpus is established, the system should support processing only new or changed content.

Conceptually:

musnad ingest blog/new-post.html

The tool should:

  1. inspect the new resource;
  2. identify ḥadīth candidates;
  3. detect explicit data-musnad-id references where present;
  4. compare candidates to canonical records;
  5. append new usages;
  6. surface genuinely new narrations;
  7. flag ambiguous cases;
  8. avoid rescanning the whole site unnecessarily.

A periodic full audit may still be useful as reconciliation.


Git and Review Safety

Musnad writes should follow a branch/PR model rather than silently modifying production.

The repository already contains a precedent for:

scheduled script

branch

pull request

human review

merge

This pattern is preferred for Musnad automation.

Religious citation changes should not be deployed automatically.


Agentic Operation — Future Phase

The long-term goal is for Musnad tooling to be callable remotely through the existing Middle Ground agent stack:

Telegram

Hermes on NucBox

Qwen

Musnad tooling

Git branch / PR

Possible commands may eventually include:

/musnad status
/musnad audit
/musnad recent
/musnad add <url-or-file>
/musnad verify <id>

The agentic layer should operate stable deterministic infrastructure.

It should not reinvent the workflow on every run.

The machine may:

  • discover;
  • compare;
  • extract;
  • normalize;
  • propose;
  • generate reports;
  • prepare branches/PRs.

Human review should remain required for:

  • ambiguous ḥadīth identity;
  • citation conflicts;
  • variant/parallel judgments;
  • scholarly verification;
  • final publication approval.

Key Guardrails

1. Never silently correct Middle Ground history

What Middle Ground originally published must remain preserved.

2. Never invent missing religious metadata

Unknown means unknown.

3. Detection is not verification

A classifier identifying “probable ḥadīth” does not establish authenticity or source identity.

4. Promotion is not verification

Creating a canonical Musnad record does not mean its takhrīj has been independently checked.

5. Public publication has a higher bar than staging

Internal candidates may be incomplete.

Public Musnad entries should be review-ready, source-aware, and bilingual.

6. Do not auto-merge fuzzy matches

Similarity should produce suggestions, not silent merges.

7. Preserve provenance

Every candidate and usage should be traceable back to the Middle Ground resource where it appeared.

8. Human review remains authoritative

Automation assists scholarship; it does not replace it.


Project Phases

Phase 0 — Architecture Audit

Completed.

Established:

  • current Middle Ground architecture;
  • content patterns;
  • repository constraints;
  • proposed Musnad architecture.

Phase 1 — Canonical Data Model and Validator

Completed.

Established:

  • mm-h-* canonical IDs;
  • JSON schema;
  • validator;
  • structured citation model;
  • narrator model;
  • usage model;
  • verification model.

Phase 2 — Historical Candidate Extraction

Completed.

Established:

  • deterministic corpus discovery;
  • conservative classification;
  • staging records;
  • candidate provenance;
  • mm-c-* IDs;
  • regression tests;
  • canonical-write safety.

Phase 3 — Review, Matching, and Promotion

In progress / next active phase.

Goals:

  • persistent review state;
  • dismiss/defer/link/promote actions;
  • candidate-to-canonical matching;
  • canonical promotion workflow;
  • duplicate-usage prevention;
  • dry-run support;
  • reviewer identity.

Phase 4 — Scholarly Verification

Planned.

Goals will likely include:

  • independent source verification;
  • collector/collection confirmation;
  • number/book/chapter verification;
  • narrator confirmation;
  • variant/parallel relationship review;
  • citation conflict handling;
  • ensuring both Arabic and English are present for publication-ready records.

Phase 5 — Public Musnad Pages

Planned.

Goals:

  • Musnad index;
  • individual ḥadīth pages;
  • Arabic + English paired presentation;
  • usages/backlinks;
  • Pagefind integration;
  • sitemap integration;
  • structured metadata;
  • publication rules.

Phase 6 — Incremental Ingestion

Planned.

Goals:

  • new/changed content processing;
  • explicit Musnad markup support;
  • usage appending;
  • new-candidate detection.

Phase 7 — Workflow / CI Integration

Planned.

Goals:

  • appropriate automated checks;
  • PR-based review workflow;
  • periodic reconciliation.

Phase 8 — Hermes / Qwen / Telegram Integration

Planned.

Goals:

  • remote operation;
  • machine-readable Musnad commands;
  • agent-assisted review preparation;
  • no autonomous production publication.

Strategic Significance

Musnad Middle Ground is more than an archive of quotations.

It creates a durable semantic layer connecting:

ḥadīth

Middle Ground teaching

topics

Qurʾān

classes

khuṭbahs

podcasts

Over time this can become part of a broader Middle Ground knowledge graph.

For example, one ḥadīth could eventually surface:

  • every Middle Ground resource in which it was used;
  • related Qurʾān passages;
  • related topics;
  • related scholars;
  • related classes;
  • related podcast episodes.

This supports the broader Middle Ground strategy of preserving scarce scholarly work as durable source assets and then connecting later expressions of that work back to the source.


Current Project Boundary

At the present stage:

  • the canonical data model exists;
  • validation exists;
  • historical extraction exists;
  • 48 candidate passages have been staged;
  • 20 are currently classified as probable Prophetic aḥādīth;
  • no historical candidate has been automatically promoted;
  • scholarly verification has not yet begun;
  • public Musnad pages have not yet been generated.

The immediate next objective is:

establish a durable human-review workflow for deciding which candidates should be dismissed, linked to an existing canonical record, promoted as a new canonical record, or deferred.

Only after that review layer is stable should the project move into systematic scholarly verification and public page generation.