The design-time gate

A core-banking system like iMAL or Temenos T24’s Islamic module books and executes a financial product. It does not, on its own, verify that the product’s terms are consistent with a named Shari’ah authority before booking: that check has traditionally been a human Dewan Pengawas Syariah (DSB) review, done once, upstream of configuration, with nothing downstream re-checking that what a batch job or a side letter later changed still matches what the board approved. That is the formation-versus-execution gap the invariant gateway page already names.

Deducible’s place in that picture is narrow and worth stating exactly: it is a design-time gate and an audit layer that sits in front of, or beside, a core-banking system. It is not a ledger, and it does not replace one. It holds no funds, settles nothing, and does not compete with iMAL’s or Temenos’s own product-processing engine. What it adds is a machine-checked, citation- bearing gate between “a Shari’ah board approved this product” and “this exact configuration is what got booked,” plus a portable artifact that carries the difference.

The hosted API

https://app.deducible.tech/api is the full-featured surface: rule modules, the compliance report, the invariant manifest export, and the agent stream. The discovery document is at GET /api/openapi.json, an OpenAPI 3.1 description of every route, including the SSE event types the agent stream emits.

The two simplest routes are already live and answer without a body:

$ curl -s https://app.deducible.tech/api/health
{"classes":26,"engine":"fiqhc 0.1.0","ok":true,"rules":["aaoifi","dsn-mui","hanafi","maliki","shafii","hanbali"]}

POST /api/verify is the same check deduce check runs, over HTTP, optionally against a named rule module. A consistent murabaha (the flagship instrument, cost-plus trust sale) still carries an advisory warning worth reading:

$ curl -s -X POST https://app.deducible.tech/api/verify -H 'content-type: application/json' \
    -d '{"source": "instrument Murabahah : murabahah { ... }"}'
{"consistent":true,"diagnostics":[{
  "code":"MAQASID-1","severity":"warning",
  "message":"murabaha can become tahayul al-murabaha 'ala al-riba (a circumvention of riba) where the markup merely tracks a prevailing interest rate. A scholar should confirm the buyer genuinely wanted the good and that the markup is a real trade profit, not interest by another name.",
  "citation":"cf. al-Shatibi, al-Muwafaqat; Ibn al-Qayyim, I'lam al-Muwaqqi'in (on the hiyal) [scholar-verify]"
}],"elapsed_us":301,"engine":"fiqhc 0.1.0","rules":null}

consistent: true is not the same claim as “nothing to review.” A warning never blocks the manifest export below, but it is exactly the kind of thing a design-time gate exists to surface rather than silently pass through. A refused spec looks the same shape, just with severity: "error" entries and consistent: false, e.g. a fixed-rate loan dressed as a diminishing partnership:

$ curl -s -X POST https://app.deducible.tech/api/verify -H 'content-type: application/json' \
    -d '{"source": "instrument FakeDiminishingPartnership : musharakah_mutanaqisah { ... }"}'
{"consistent":false,"diagnostics":[
  {"code":"RIBA-1","severity":"error","message":"capital is guaranteed to 'bank'; a guaranteed return of capital turns a partnership into an interest-bearing loan (riba)"},
  {"code":"RISK-1","severity":"error","message":"loss allocation is 'none'; a diminishing partnership must share loss proportional_to_ownership (no risk-sharing = no partnership)"},
  {"code":"RIBA-2","severity":"error","message":"rent is charged on principal/capital — that is interest on a loan, not rent on a living share"},
  {"code":"GHARAR-1","severity":"error","message":"buyout price '11000' is not derived from the independent oracle; a self-named or fixed price re-introduces gharar and can disguise a guaranteed return"},
  {"code":"INV-1","severity":"error","message":"required invariant 'loss_follows_capital' is not declared for this instrument class"},
  {"code":"INV-1","severity":"error","message":"required invariant 'price_attested' is not declared for this instrument class"},
  {"code":"MAQASID-2","severity":"warning","message":"…the rent's economic basis should be reviewed…"}
],"elapsed_us":290,"engine":"fiqhc 0.1.0","rules":null}

This is the identical negative control the edge worker’s README runs against its own bundled wasm build, and the two agree on every error code. The hosted API adds the MAQASID-2 warning the older wasm build does not yet surface: a small, named, honestly-reported gap between the two paths rather than a silent one.

Pass "rules": "aaoifi" (or dsn-mui | hanafi | maliki | shafii | hanbali) in the body to check against a named authority instead of the built-in universal core; the response’s own rules field echoes back which one ran, so a caller never has to track that state itself.

POST /api/report produces the same diagnostics formatted as a narrative fit for a human reviewer rather than a CI log: the shape a Dewan Pengawas Syariah packet is built from, not a separate verdict.

The invariant manifest: the hand-off artifact

POST /api/manifest is the export an institution actually integrates against. Given {source, rules?}, it re-runs the same check; if the spec is consistent, it returns the portable invariant manifest, the facts sema checked, serialised as ledger-agnostic {code, field, op, value, citation} constraints, independent of Solidity or any chain. If the spec is refused, it returns 409 with {"error": "refused", "diagnostics": [...]} instead: the manifest is never emitted for a contract the engine would not have checked, because a hand-off artifact for a refused spec is not something any downstream system should be able to act on.

That manifest, not a PDF of a board’s minutes and not a developer’s memory of what was discussed, is what a core-banking integration should configure against: either generate the product’s parameters from it directly, or validate the product’s actual booked configuration against it as a batch check. Either way, the manifest is the thing both sides, the Shari’ah gate and the core system, can point at and agree means the same fact.

Three surfaces, one engine, different trade-offs

Surface	Rule modules	Reachable without app.deducible.tech	Best for
Hosted API (app.deducible.tech/api)	yes, all six	no	the manifest hand-off, reports, the agent stream: the full integration
Edge worker (edge/ in deducibleweb)	no, native check only	yes	a fast single-instrument check with no dependency on the hosted service being up
Invariant gateway	reads a manifest already exported	yes, self-hosted	continuous re-checking of a booked product (/attest), the SupTech angle below

The edge worker is documented in its own edge/README.md: it wraps the same compiled deducible.wasm the in-browser Playground uses, behind POST /verify, with the same response shape the hosted API uses (consistent, diagnostics, elapsed_us, engine, rules: null). It is useful precisely where the hosted API is not the right dependency to take: a design-time check that needs to run at the edge, on a single spec, with no rule module selected. It is not a substitute for the manifest hand-off above; it answers “is this instrument consistent with the built-in core,” not “is it consistent with a named authority, exported as a hand-off artifact.”

SupTech: a supervisor’s view of the same gate

The invariant gateway, a small self-hosted service in the compiler repository, is the same idea from a supervisor’s seat rather than an institution’s. POST /enforce and POST /authorize answer the same consistency question the hosted API’s /verify does, but over a manifest already loaded locally; POST /attest narrows the formation- versus-execution gap by hash-chaining a product’s re-submitted configuration over time, so drift from an approved baseline is visible to whoever is watching, not silently absorbed into “the system said it was fine.” It checks consistency and issues no fatwa, exactly as every other surface here does.

What this is not

Read the epistemic boundary before integrating any of this into something real. Every surface above proves consistency with a rule module a human authored and cited. None of them establishes legitimacy, and none replaces the qualified scholar or Shari’ah board whose ratification the rule-modules ratification mechanism is built to make tamper-evident, not optional.