The Trust Receipt: a signed paper trail for every Islamic AI verification.

What a Trust Receipt is

A Trust Receipt is a JSON document issued by Tasfi Guard at the end of every verification call. It is the record of what happened: the verdict reached, the flags raised, the sources consulted, the boundary enforced. It is signed by the Tasfi verification key so that any party can confirm the receipt is authentic and unmodified.

The receipt is not a certificate of religious correctness. The boundary section says so explicitly. It is a certificate that verification happened: that a specific generated answer was checked against a specific approved source bundle under a specific policy, and that the result is documented and signed.

This is the paper trail. A Muslim builder can show it to their users. A pilot organization can show it to their scholar advisors. A technical stakeholder can use the receipt ID to verify the original at the Tasfi endpoint. The receipt does not replace scholarly review. It is the first layer of accountability that makes scholarly review tractable.

A complete Trust Receipt

{
  "receiptId": "rec_01abc123def456",
  "schemaVersion": "1.0",
  "issuedAt": "2026-05-16T12:00:00.000Z",
  "verdict": "pass",
  "flags": [],
  "sourceBundle": {
    "version": "1.0.0",
    "checksum": "sha256:a3f9b2c1...",
    "sources": [
      {
        "id": "tanzil-quran-v1",
        "license": "CC-BY-3.0",
        "checksum": "sha256:1a2b3c..."
      },
      {
        "id": "fawaz-bukhari-v1",
        "license": "Unlicense",
        "checksum": "sha256:4d5e6f..."
      }
    ]
  },
  "boundary": {
    "sahihOnly": true,
    "madhabs": ["hanafi", "maliki", "shafii", "hanbali"],
    "noFatwa": true,
    "noScholarReplacement": true,
    "cannedDemoOnlyPublic": true,
    "metadataOnlyAudit": true
  },
  "policy": {
    "madhab": null,
    "strictness": "standard"
  }
}

Field by field

receiptId

A globally unique identifier for this verification event. Store it with the answer it corresponds to. Use it to retrieve the original receipt from /v1/receipts/verify when you need to prove a verification event occurred.

schemaVersion

The version of the Trust Receipt schema. Tasfi will increment this when the schema changes in a non-backward-compatible way. Your integration should store this and handle schema evolution if you retain receipts long-term.

issuedAt

ISO 8601 UTC timestamp. The moment Guard completed verification and issued the receipt. Useful for audit logs and for matching receipts to model call logs by time range.

verdict

One of three values. pass: all claims verified within policy. warn: claims verified with caveats (for example, a madhab attribution that is correct but contested). fail: one or more claims failed verification. A fail verdict means the answer should not be shown to a Muslim user as-is.

flags

An array of flag objects, empty on a clean pass. Each flag has a type from the flag taxonomy (documented at /receipt), an evidence string explaining what the checker found, a severity (high, medium, or low), and an optional remediation suggestion when a correction exists.

sourceBundle

The exact source bundle consulted during this verification call: version, overall checksum, and a list of individual source IDs with their checksums. This is the cryptographic record of what was checked against what. If the source bundle changes between calls, the checksum will differ: receipts are tied to a specific bundle snapshot.

boundary

The policy constraints that governed this verification call. sahihOnly: the hadith product flow rejected anything below sahih grade. madhabs: the madhab scope in effect. noFatwa: Guard did not issue a ruling. noScholarReplacement: Guard is infrastructure, not a religious authority. cannedDemoOnlyPublic: the public endpoint is demonstration only. metadataOnlyAudit: the audit log records metadata, not submitted text.

policy

Runtime policy options supplied by the caller. madhab: the specific madhab scope requested (or null for all four). strictness: the strictness level applied.

How builders use the receipt

The receipt serves three audiences: the Muslim user, the scholar advisor, and the technical stakeholder.

For the Muslim user

Show a "Verified by Tasfi" badge on answers that passed verification, with a click-through to the receipt details. The user can see that the answer was checked, what sources were consulted, and what the boundary is. They do not need to trust the builder's word: they can read the receipt.

For the scholar advisor

A pilot organization integrating Tasfi Guard can give their scholar advisor access to the receipt log. The advisor can see every verification call, every flag raised, and every source consulted. This makes the scholar's review task tractable: instead of reading every AI answer in full, the scholar can focus on answers that raised flags or on the policy constraints that are in effect.

For the technical stakeholder

A CTO or a pilot program manager can use receipt IDs to audit the verification layer. They can confirm that every answer shown to users has a corresponding pass receipt, that the source bundle version was consistent across the period, and that the flag rate is within expected bounds.

Verifying a receipt is authentic

The receipt ID lets any party confirm the receipt is authentic. POST to /v1/receipts/verify with the receipt ID. The endpoint returns the original signed receipt. If the receipt does not exist or the signature does not match, the endpoint returns a rejection.

{ "receiptId": "rec_01abc123def456" }

// Response
{
  "valid": true,
  "receipt": { ... original receipt object ... }
}

This verification endpoint is public: no API key required. Any Muslim builder, scholar, or user can confirm a receipt is genuine without needing access to the Tasfi account that generated it.

What the receipt is not

The receipt is not a fatwa. The boundary section says so. Guard does not rule on novel questions that the approved source bundle does not address. The receipt does not certify that an answer is religiously correct for every Muslim in every context: madhab differences and scholarly disagreements that are both within the approved scope are not resolved by the receipt.

The receipt is also not a replacement for scholar review. It is the first layer: the mechanical verification that clears the path of known errors. The scholar review layer comes after. The receipt makes that review faster and more targeted by showing the scholar exactly what has already been checked.