Attestation is not a fatwa

What an attestation is, precisely

keel's glossary states the model in one line: market facts are computed, Shariah classifications are attested, never inferred. Whether a token's core purpose is a haram sector, whether it is asset-backed 'ayn or a claim dayn, whether it pays a riba-like yield, what kind of contract the listing is — these are questions of fact-plus-scholarship about the world, and a human records each answer, with a source and a name, via keel assets attest.

The command's shape carries the governance: keel assets attest --asset --sector --backing --pays-yield --source --attested-by. The last two flags are required, because an unsourced claim is not evidence. The record is scoped — this product, on this venue — and the same model runs through the rails: the venue subscription (rail 14) and withdrawal capability (rail 17, expiring after seven days) are operator attestations the engine enforces, never judgements the engine makes.

What a fatwa is

A fatwa, by contrast, is a formal, reasoned ruling issued by a qualified scholar — a mufti — in answer to a question put to them. It carries the issuer's scholarly authority and accountability; councils and academies issue them at scale; and rulings can legitimately differ across schools and jurisdictions without any of them ceasing to be fatwas.

keel's fiqh basis is explicit about which side of this line it stands on. Its second paragraph: “What this document is not: a fatwa, or a claim that keel can produce one.” An attestation carries a recorder's name — that is accountability of authorship, not authority of scholarship. Confusing the two is not a small wording slip; it is the exact misunderstanding the boundary exists to prevent.

The boundary: where the ruling lives

The ruling lives in the attestation, never in the code. Two operators following different schools supply different attestations and get different answers from the same code — by design, as the repository's governance notes put it: rulings versus machinery. The engine is the machinery; you are the rulings.

This is why keel does not adjudicate. Where sources diverge — the knowledge base records identical retail FX ruled haram by one jurisdiction and halal by another (§66.6) — the disagreement is named, with both sides, never flattened into “scholars say.” Where a school question touches your trading, the answer you record is the one enforced, and the audit trail records exactly who said what.

The scholarly review that has not happened

The fiqh basis states its own review status plainly: no scholarly review of keel's fiqh basis has occurred — not by a named scholar, not by a council, not by anyone. The basis is one operator's reading of the cited sources — Ayub, the OIC/AAOIFI/IIFA materials, Mufti Faraz Adam's papers — extracted into a public knowledge base and mapped into code, published precisely so the reading can be audited and challenged. Until a review happens, the status is “not reviewed,” and the document says so in those words.

The status has a ratchet: it can move one way only — from not-reviewed to reviewed-with-a-named-scope, never to an approval with no scope attached. A review, should one ever happen, would be recorded as a dated addendum naming the reviewer, the scope, the findings, and what changed — versioned in git like everything else.

What a review would — and would not — cover

A review would be a review of the mapping from sources to code: whether each screen and rail axis faithfully reflects the section it cites (§28.4 for sector and the riba axis, §65.5/§67.2 for backing, §71.4a for the instrument shape, §65.4 for rail 17's qabd test), and whether the knowledge-base extractions are faithful to the texts they were taken from.

Just as important is what a reviewer would not be endorsing: not the trading strategy or its performance — the honest measured result is linked from the README's first screen and “is nothing anyone is asked to endorse”; not the prudential rails, which are risk discipline carrying no religious claim; not a ruling that crypto is tradable property, since the §71.1 non-ruling stands; not any operator's attestations, which carry their own sources and names; and not an endorsement of trading anything at all.

Why the boundary is the product

Closed screening tools ask you to trust their verdicts; keel publishes the machinery and the rulings it enforces, with their sources. That is not modesty branding — it is the mechanism. A ruling you can trace is a ruling you can check, challenge, and replace; a verdict you cannot trace is a bill you keep paying.

The boundary holds upstream too. Changing a classification for everyone is a PR of a different kind: the repository's contribution rules require a cited source and discussion before merge — a classification with no source behind it is not mergeable, however confident the author. Governance, not vibes, is what keeps an open compliance engine from becoming a rumor engine.

What the boundary buys you

Traceability, first. Every classification your deployment enforces resolves to a named record with a source — so when you ask “why did the engine refuse this asset?”, the answer is an audit-trail entry, not a shrug. The same holds in reverse: when your reading changes, you re-attest, and the engine's behaviour changes with your record — the causal arrow always points from your ruling to the machine's action, never the other way.

Neutrality, second. Because the project never issues rulings, keel the software can never become the de-facto mufti of record for your deployment — each operator remains responsible for their own attestations, and the honest weight of that responsibility is part of the design, not a disclaimer bolted on after the fact.

What the boundary is not

The boundary is not soft enforcement. Everything attested is enforced deterministically: every order intent passes through twenty-one un-overridable rails, and an asset without an attestation never trades — the machine's neutrality about rulings coexists with total firmness in executing them. Refusing to be the mufti does not make keel a lighter enforcement engine; it makes the enforcement attributable.

Nor is the boundary a hedge bolted on for liability. It is the mechanism that lets the engine be audited at all: because every enforced ruling resolves to a record with a source and a name, disagreement has a place to land — your own database — instead of a black box you can only take or leave. keel's own one-line pitch for reviewers says it plainly: classifications are attested, never inferred, and enforced deterministically. The first two clauses are the boundary; the third is the product.

How to disagree, honestly

The architecture already provides the route. Attest your own classification — keel assets attest with your --source and --attested-by writes to your database, your deployment follows your ruling, upstream stays neutral, and the audit trail records exactly who said what. Document exceptions where the screen allows them: only the history criterion can be waived today, never a Shariah one. And to change a classification for everyone, bring the source; that is the whole price of admission.