§ furqan-lint v1.0.0·al-Basirah · Honest by Construction

Code that promises more than it can deliver, refused at check time.

furqan-lint is a static checker for Python, Rust, and Go. It rejects function shapes whose signature is wider than what the body can honestly return. The discipline is syntactic, deterministic, runs in milliseconds with no model in the loop, and -- as of v1.0.0 -- attests its own release.

§ Thesis

A meaningful fraction of code-level "AI hallucination" has the same shape as a long-known software defect: a function declares it returns a complete answer about an input the program cannot fully process. furqan-lint makes that shape structurally rejectable on existing Python, Rust, and Go code -- no language migration required.

When a Python function returns Optional[X] and the caller silently narrows it to X, that is the structural equivalent of dropping the Incomplete arm of an Integrity | Incomplete union. The same shape appears as Result<T, E> in Rust and (T, error) in Go. Most checkers do not enforce this across language boundaries. furqan-lint does.

The core checks run on every file: D24 (all-paths-return), D11 (status-coverage), return_none_mismatch, and -- via furqan-lint diff -- additive_only across two versions of a module's public surface. Diagnostics name the rule violated, the producer, the consumer, and the minimal fix.

§ Install

One pip install, three languages, zero models.

# Python only, from a tag $ pip install "git+https://github.com/BayyinahEnterprise/furqan-lint.git@v1.0.0" # Add Rust + Go adapters $ pip install "furqan-lint[rust,go] @ git+https://github.com/BayyinahEnterprise/furqan-lint.git@v1.0.0" # Run the four core Python checks $ furqan-lint check src/your_module.py # Lint Rust and Go through the same CLI $ furqan-lint check src/lib.rs $ furqan-lint check pkg/main.go # Compare two versions of a module's public surface $ furqan-lint diff old.py new.py # Verify the installed wheel against the signed self-manifest (v1.0+) $ furqan-lint manifest verify-self
§ Checks

Four core checks. One adapter per language.

The same checker substrate runs on Python, Rust, and Go. Each check names a structural failure mode that has appeared in published incident reports and in the audit chain that backs this release.

D24 all-paths-return. Every control-flow path through a typed function reaches a return statement. Ships on Python, Rust, and Go.
D11 status-coverage. A may-fail union (Optional[X], Result<T, E>, (T, error)) returned by a callee must be propagated or explicitly handled by every caller. Ships on Python, Rust, and Go.
return_none_mismatch Closes the D24 return-None blind spot. A function declaring -> str that returns None on some path is flagged as a type mismatch.
additive_only Public-surface discipline. furqan-lint diff old new fires on any removed public name. Adding a public name is silent.
R3 (Rust) ring-close. Zero-return discipline on annotated Rust functions, derived from upstream Furqan check_ring_close.
ONNX suite Optional extras. D24-onnx, opset_compliance, D11-onnx (graph), numpy_divergence (runtime), score_validity (profile) for ML model artifacts.
Gate 11 Sigstore-CASM verifier. Additive-only public-surface contract cryptographically witnessed via Sigstore Rekor. The substrate the self-attestation rides on.
§ Verdicts

Four states, one of them clean.

The checker emits one of four verdicts per module. The first three carry diagnostics. Only PASS is silent.

PASS All applicable checks ran. Zero marads, zero advisories. The module is structurally honest at the level the checker sees.
MARAD At least one structural violation. Each marad names the check, the producer, the consumer, and the minimal fix.
ADVISORY Informational findings only. The module passes, but the checker has notes worth reading (used by ONNX profile checks).
PARSE ERROR The source could not be parsed. Reported with line and column. No check runs on a broken AST.
§ Self-attestation·v1.0+

The tool that catches drift in others' code attests its own.

v1.0.0 closes a canonical chain that started at G10.5 al-Mubin (v0.11.1) and ran through at-Tawbah, al-Hujurat, as-Saff, al-Mursalat, an-Naziat (v0.13.0), and Tasdiq al-Bayan (v0.14.0). The closing move: furqan-lint signs its own release with Sigstore via ambient OIDC, publishes the signed self-manifest as a Release asset, and exposes Relying-Party verification through a CLI subcommand.

The self-manifest pins the source list of 24 substrate modules (4 top-level checker substrate plus 20 gate11 substrate including two new self-attestation modules) and binds them with a Form A checker_set_hash. There are two of these: a universal hash over all checker substrate, and a self-attestation hash over the pinned-self subset. Both are published in SAFETY_INVARIANTS.md and verified at install time.

On the relying-party side, after pip install:

$ furqan-lint manifest verify-self # Optionally pin the version under test $ furqan-lint manifest verify-self --version 1.0.0 --expected-identity \ https://github.com/BayyinahEnterprise/furqan-lint/.github/workflows/release.yml@refs/tags/v1.0.0

A drift in any of the pinned source files, or a missing self-manifest, or an unexpected signer identity, surfaces as CASM-V-072 (self-attestation-failure) with one of three named sub-conditions: manifest-not-found, checker-set-hash-drift, or signature-verification-unexpected. The 732-test substrate (687 passing, 45 environment-gated) covers the verification path end-to-end.

Honest asymmetries. Self-attestation ships on the Python distribution. The Rust verifier substrate is part of the Python wheel rather than a separate crate; the Go self-attestation path is deferred. The published docs/gate11-symmetry.md row records both.

§ Foundations·built upon the Furqan language

furqan-lint is built upon the Furqan programming language.

The four checks that ship in furqan-lint (D24, D11, return_none_mismatch, additive_only) -- plus R3 on the Rust adapter -- are not bespoke heuristics. They are translations of compile-time primitives from Furqan, the research programming language whose multi-checker pipeline (bismillah scope, zahir/batin, mizan calibration, tanzil build ordering, ring-close, scan-incomplete, status-coverage, return-type-match, all-paths-return) defines the structural-honesty discipline.

The language gives the discipline; furqan-lint carries it into existing Python, Rust, and Go code -- no migration required. You do not need to install Furqan to use furqan-lint. The architecture-derivation paper is listed under Research below; the Furqan repository is linked for researchers who want the substrate directly.

§ Research

The corpus is open.

furqan-lint is the production surface of a published research program. The Munafiq Protocol names the failure mode RLHF and Constitutional AI do not address: a system can be Compliant without being Aligned. The Furqan language turns that protocol into compile-time checks, and furqan-lint carries those checks into Python, Rust, and Go. The cross-text empirical paper grounds both in measured structural properties of the source corpus, not in metaphor. Every paper carries a permanent Zenodo DOI and an auditable claim against a named null hypothesis.

furqan-lint white paper

furqan-lint: The Structural-Honesty Checks ruff and mypy Do Not Catch, Across Python, Rust, and Go (White Paper v1.0)

zenodo.org/records/20101580 · v1.0 · 2026-05-09 · Bilal Syed Arfeen (BayyinahEnterprise)

The defining paper for this site. Names the gap between ruff (style), mypy (declared types), conventional security tooling, and the four structural-honesty shapes furqan-lint catches: Optional collapse through propagation across narrowing return-type annotations, silently-removed public names across versions, zero-return ring-close on unannotated or dynamically constructed functions, and explicit return-None mismatch on functions declared with non-Optional return types. Introduces the five checks (D24, D11, R3, return_none_mismatch, additive_only), the three language adapters (Python via ast, Rust via tree-sitter, Go via a goast binary), the three-line CI integration story, a worked example, and the application-fit profile for technical decision-makers.

Layer 1 · The Protocol & Its Empirical Foundation

Detecting Performed Alignment in Artificial Systems: The Munafiq Protocol

10.5281/zenodo.19700420 · v2.1 · 2026-04-22 · Arfeen, Claude (Anthropic), Grok (xAI)

The protocol everything else inherits from. Names the failure mode RLHF, Constitutional AI, and helpfulness training do not address: a system can be Compliant (outputs the trainer rewards) without being Aligned (depth state matches surface presentation). Introduces the four-process taxonomy and the surface-depth verdict surface. Furqan’s nine compile-time checkers, Bayyinah’s document-scanner verdicts, and every downstream application in this corpus inherit their diagnostic vocabulary from this paper.

Cross-Text Computational Linguistics: Structural Properties of the Quran, Hadith Collections, and the Hebrew Bible Under TF-IDF Cosine Analysis

10.5281/zenodo.19961267 · v1.1 · 2026-05-01 · Arfeen, Ashraf, Claude Opus (Anthropic), Grok (xAI), Computer (Perplexity)

The empirical foundation. Applies a uniform computational pipeline (TF-IDF cosine, Fibonacci additive growth, Hurst R/S persistence, lag-20 autocorrelation) to five corpora across two language families. Three layers of structural difference are reported as measurements, not metaphor: Fibonacci additive semantic growth is a Classical Arabic compiled-text property shared by the Quran and all three hadith collections (p < 0.001) and absent in the Hebrew Bible (p = 0.44); long-range persistence by Hurst exponent distinguishes the Quran (H = 0.996, p = 0.003) from the hadith collections (H = 0.68 to 0.80, p >= 0.19); and the lag-20 autocorrelation sign-flip separates positive thematic continuity in the Quran (+0.53) from negative alternation in the Hebrew Bible (-0.42). The paper falsifies its own original Quran-specific Fibonacci hypothesis on contact with the hadith data, reconciles two pipelines that produced contradictory Hebrew Bible results, and reports five honest caveats. This is the measured structural ground from which Furqan’s type system and the Munafiq Protocol are derived.

Layer 2 · The Architecture

Furqan: A Programming Language with Structural Honesty, Calibrated Optimization, and Surface-Depth Type Verification Derived from Quranic Computational Architecture

10.5281/zenodo.19776584 · 2026-04-25 · Ashraf, Arfeen, Claude (Anthropic), Computer (Perplexity), Grok (xAI)

The defining paper for this site. A programming language whose type system, module architecture, and build constraints are derived from structural properties of the Quran. Where contemporary languages ask developers to write honest code as a behavioral expectation, Furqan makes structural honesty a property of the type system, so surface-depth divergence becomes a type error rather than a code-review concern.

Al-Khalifa: A Furqan-Based Super Agent Architecture for Structurally Honest Autonomous Project Stewardship

10.5281/zenodo.19776577 · 2026-04-25 · Arfeen, Claude (Anthropic), Computer (Perplexity), Grok (xAI). Additional contributors named on the DOI page.

Applies Furqan’s seven compile-time primitives as seven runtime constraints on an autonomous agent. Where AutoGPT, CrewAI, LangChain agents, and Devin decompose tasks but cannot verify whether they are building the right thing versus performing the appearance of building, Al-Khalifa is architected so the surface-depth gap is checked at every step of the agent’s stewardship loop.

Bilal: An Honest-Autonomous Large Language Model Architecture with Structural Truth Verification, Calibrated Generation, and Purpose-Hierarchy Training Objectives Derived from Quranic Computational Architecture

10.5281/zenodo.19776576 · 2026-04-25 · Arfeen, Claude (Anthropic), Computer (Perplexity), Grok (xAI)

A model architecture proposal that takes the Munafiq Protocol’s structural-honesty constraint and integrates it as a training objective rather than an external evaluation. The long-form answer to the question: what would an LLM look like if alignment were a property of the architecture, not a finetuning target.

Structured Revelation as Prompt Architecture

10.5281/zenodo.19744163 · 2026-04-24 · Arfeen, Claude (Anthropic), Grok (xAI)

The methodology paper. Demonstrates that gradual revelation, ring composition, lossless morphological compression, and the zahir / batin distinction function as prompt-engineering primitives in human-AI collaborative software development. Validated longitudinally against the development of Bayyinah v1.0.

The Fatiha Construct: A Seven-Step Recursive Session Protocol for Human-AI Collaborative Development Derived from Surah al-Fatiha

10.5281/zenodo.19746539 · 2026-04-25 · Arfeen, Claude (Anthropic), Grok (xAI)

The session-level companion to Structured Revelation. Each of the seven steps maps to a verse of Surah al-Fatiha with structural, not decorative, correspondence: a calibration check, an orientation check, a deadline-with-skip-rule, a memory-encoding step, and an over-specification guard against the failure mode the paper calls the Cow Episode.

Layer 3 · The Application

Bayyinah: Detecting Concealed Adversarial Content in Digital Documents. A White Paper Applying the Munafiq Protocol to the Input Layer

10.5281/zenodo.19745154 · 2026-04-24 · Arfeen, Claude (Anthropic), Grok (xAI)

The white paper that turns the protocol into a working scanner. Where the Munafiq Protocol diagnoses agents, Bayyinah diagnoses their inputs. Formalizes the relational definition: a document is Performed with respect to a rendering function and an ingestion function when the machine’s ingested content carries a payload the human reader’s rendered surface does not reveal.

Bayyinah as Input-Layer Defense in Artificial-System Safety Pipelines

10.5281/zenodo.19802455 · v1.1 · 2026-04-26 · Arfeen, Claude (Anthropic), Grok (xAI)

The deployment paper. Documents the design, implementation, and adversarial-gauntlet evaluation of Bayyinah as an input-layer defense in production AI pipelines. Twelve file formats, an honest miss list, and the discipline that comes from making every miss a published commitment.

Bayyinah al-Maal: Structural Honesty Verification for Financial Filings Using the Munafiq Protocol

10.5281/zenodo.19875931 · 2026-04-29 · Arfeen, Claude Opus (Anthropic), Grok (xAI), Computer (Perplexity)

The fourth substrate. Carries the Bayyinah architecture from document files to SEC filings (10-K, 10-Q, 8-K, DEF 14A) and on-chain cryptocurrency disclosures. The same divergence the document scanner detects between a rendered surface and an ingested substrate is reframed as the gap between a filing’s reported numbers and the economic reality they claim to represent, with detection operating by structural address on XBRL taxonomy elements and blockchain state.

Al-Mutaffifin: Structural Integrity Verification for Financial Governance Systems

10.5281/zenodo.19894724 · 2026-04-29 · Arfeen, Claude Opus (Anthropic), Grok (xAI), Computer (Perplexity)

The fifth substrate. Carries the Munafiq Protocol from filings to financial governance systems: the entity that controls the instruments of measurement and applies them asymmetrically. Introduces the structural signature differentiation framework, five mechanisms that distinguish honest-error structural patterns from directed-manipulation structural patterns without claiming to determine intent. Demonstrated end-to-end on the Lehman Brothers Repo 105 filings.

Bayyinah al-Khabir: A Theoretical Framework for Information-Layer Integrity Scanning Across National Broadcast Sources Using Performed-Alignment Diagnostics

10.5281/zenodo.19746298 · 2026-04-24 · Arfeen, Ashraf, Claude (Anthropic), Grok (xAI)

The horizon paper. Extends the Bayyinah architecture from documents to information sources: where Bayyinah detects performed alignment in a single document, al-Khabir detects performed alignment in a source’s reporting on a specific event measured against the cross-source evidence base across multiple national contexts. Currently theoretical; the protocol scaffolding is published so the implementation that follows can be measured against the framework, not against itself.