Module 05 · the fraud engine

Detect

One risk read over everything — images, documents, records — with a reason for every flag.

Here is where Priya’s claim gets interesting. The garage estimate lists a brand-new bumper. Her photos show a dent — but no bumper damage at all. Neither the document reader nor the image model can catch that alone. Detect reads the whole signal set — what Extract read, what Vision saw, what Verify proved — and catches the story that doesn’t add up. That fused view is the moat.

What we're going to build

Rules over the signal set

Risk rules are pack-supplied config, evaluated over typed signals — never hardcoded. The same engine scores motor claims, invoices, and KYC files, because it only ever speaks signals.

Three modes, one module

Images alone (manipulation, AI-generation, re-digitisation, reuse), documents alone (mismatches, tampering, inflation), or both fused. Clients buy the mode they need; the fused mode is what nobody else sells.

Image forensics

Tamper and AI-generation detection on photos — integrated models behind the gateway, with our calibration and our evidence format on top.

A score that explains itself

Out comes a score and a band — but every flag beneath it carries what was compared and the exact figures. "78, high" is useless in a dispute; "estimate lists front bumper replacement; photos show no front-bumper damage" is defensible.

Cross-case signals (Phase 3)

The same payee across twelve claims, the same photo in three. Ring detection needs the Entity/Link Graph — deliberately deferred until a product demands it and legal clears it.

The contract (platform — never changes)

In: the case’s signals (any subset). Out: pass/fail checks + a scored, banded risk signal with reasons. Sold per case scored.

What the pack supplies (per domain)

Rule set + weights · bands/thresholds vocabulary · which checks are enabled per mode.

For engineers & architectsimplementation notes

Rules are declarative expressions over the typed signal set (think: a constrained predicate language, versioned in the Pack Registry) — evaluated by a generic evaluator, never compiled into engine code.
A check’s output is itself a signal: {check, verdict, inputs: [signal refs + figures], weight} — the "reason" is the actual evidence chain, not a generated sentence.
Fused checks are just rules that reference signals from multiple producers (Vision + Extract + Verify) — no special fusion machinery; R2 makes the moat a one-liner.
Failure modes: missing inputs make a check not_evaluable (reported, never guessed); rule-version is pinned per case so disputed scores replay exactly.

Open questions — for the room

Rules engine: adopt one (and which), or write a minimal evaluator over signals?
The rules/ML mix for v1: start rules-heavy and earn ML with labels, or seed with models?
Who authors and signs off pack rules — us, the insurer, or co-owned during pilots?
Flag format: is our evidence structure enough for an IRDAI-defensible audit trail?

← PreviousVerify Next →Estimate

Mimir · the Modules intelligence engine — module 05 of 07 · all docs