Forensis

The people who do this are fraud investigators. North Quay, the case shown here, is one I wrote to test the product, so it's fictional, though it starts the way a practitioner's real case did. Two invoices for the same week of work arrive seven minutes apart, ₹48.6 lakh and then ₹84.6 lakh (about $58,000 and $101,000), the same digits swapped. A manager overrides the duplicate warning and the higher one is paid. It could be a correction, a clerical slip, a glitch or fraud, and the investigator has to show which.

Their tools stop at the flag. Detection tools are good at flagging a payment like this one; the investigation that follows is slow, manual work. The explanations are tracked by hand, the first plausible story tends to stick, all the more when a summary hands it over, and most of the reasoning lives in notes and slides, ending up as "a ppt or a word doc", in one practitioner's words. None of the tools on the market records what was ruled out, or why, so when someone challenges the finding or reopens the case, the team rebuilds the reasoning from the start.

The reasoning layer, a language model working inside fixed permission rules, reads the case files and turns them into evidence pinned to its source. It proposes every plausible explanation, the innocent ones included, sets each piece of evidence against each one, and names the check that would tell two explanations apart. Rhea, the investigator, spends her time on those checks instead of rereading the file, and Arjun, the investigation lead, signs the explanation that survives, with every rejected one and its reason already attached.

The cost is room: four dead ends sit on screen every time the matrix opens. In return, the investigation lead signs with every rejection in view, and whoever reopens the case later sees why each one lost without redoing the work.

My first idea, a model that predicts how a fraud would route around a fix, didn't survive them. Fixes depend on what each client will adopt, and patterns pooled across cases lose what decided each one.

Interviews with 5 practitioners came first, two of them full interviews. They talked me out of my first idea, a model that predicts how a fraud would route around a fix, because fixes depend on what each client will adopt and patterns pooled across cases lose what decided each one. The job every case shares, explaining one anomaly properly, became the brief.

Desk research covered ACFE, NIST on how AI fails, Heuer's Analysis of Competing Hypotheses and EY on showing the reasoning. Heuer's method, which sets every explanation against every piece of evidence, became the main screen.

A review of the tools on the market, Relativity aiR, Hummingbird, link-analysis tools and general chatbots, found that none of them records what was ruled out, or why. So rejected explanations stay on screen beside their evidence.

Object-oriented UX then broke an investigation into eight core objects, from the source document to the signed finding. Every case I heard about had the same few parts: a document, what it shows, what someone claims, and the explanations competing to account for it, which a deck or a summary blurs into one story. Object-oriented UX usually stops at planning screens; in Forensis it also sets what the reasoning layer is allowed to touch.

Last, before the final screens, I tested the rules on their own against every situation the model allows, 87,380 of them. The first version broke its core rule in 77,540, and the repaired rules pass 9 of 9 tests.

North Quay is fictional, I wrote every output the reasoning layer shows, and nobody has used Forensis for real. The pilot would give two investigators one anonymised case, one with a chatbot and one with Forensis, and compare how long each takes to reach a finding, what each conclusion assumed, and how long a second person takes to check it.

The same object model should fit other anomaly work, perhaps an audit query or an insurance claim.