Fraud Case Analysis

A single module drives a multi-stage fraud detection pipeline. Flagged transactions are normalized, grouped into cases, enriched with external signals, analyzed for risk, and dispositioned – all through constraint-driven resolution.

1. 6 Constraints with priority + after – normalizeNeeded (100) fires first, then groupingNeeded (90), enrichmentNeeded (80), analysisNeeded (70), and humanReviewNeeded (65). The budgetEscalation (60) constraint competes with analysis – when budget runs out, remaining cases get escalated instead of analyzed.
2. 6 Resolvers with retry + custom keys – enrichCase uses key: enrich-${caseId} for dedup and retries with exponential backoff. Each resolver mutates facts to drive the next constraint.
3. PII detection – The normalize resolver runs local detectPII regex scanner on merchant names and memo fields, redacting SSNs, credit cards, and bank account numbers.
4. User-adjustable constraints – The risk threshold slider changes when humanReviewNeeded fires. The budget slider controls when budgetEscalation kicks in. Both re-evaluate constraints in real time.

What: A fraud detection pipeline that normalizes, groups, enriches, and analyzes flagged transactions through 6 prioritized constraints, 6 resolvers, 3 effects, and 9 derivations.

How: Constraints declare “when this is true, require that action.” Priority and after ordering sequence the pipeline. Resolvers fulfill requirements, mutating facts to trigger the next constraint. Effects log stage changes, PII detections, and budget warnings.

Why it works: Adding a new fraud rule is just another constraint definition. Competing constraints (analysis vs. escalation) handle edge cases declaratively. The DevTools panel shows every constraint evaluation, requirement, and state change in real time.