AML compliance platform

Overview

An AI agent reads the transaction history behind a money-laundering alert and returns a scored report ending in cleared or escalated. A compliance investigator signs it. A regulator may open that file two years later, and the name on it will be the investigator's, not the model's.

A seed-stage compliance platform brought me in to run discovery across the product, then design the first build phase. The brief asked for a faster correction loop but what I came back with was that speed wasn't the constraint.

Strategic Frame

The feedback loop already exists, but investigators had abandoned it for a spreadsheet.

Notes and flag corrections fed the model's evals, but nothing came back to the person who wrote them. The work moved into a shared Google Sheet that had become the case notes, the audit trail, and the client comms layer at once, none of which the model could read.

Three interviews and a heuristic pass on the live product landed on this: a correction an investigator can't point to later is worth less than no correction at all.

Two things discovery moved that weren't in the brief:

• Investigators read raw transactions first, flags last as a sanity check. The brief assumed narrative first.
• A verified fact is not a risk finding. A registry hit is a fact; it might produce a flag. The product rendered both identically. I made the distinction a first-class primitive and it carried through both phases.

Decision 1

Asking and changing are different actions, so I didn’t fit them in one chat box

A regular ol’ query answers and touches nothing. But a correction opens a chain: parse the input, propose a plan, rerun on approval, write to the log.

Investigators reach the co-pilot three ways. A persistent panel for work that starts with a question. A hover trigger on any block, pre-loading that block as context. And inline selection, so a correction attaches to the disputed sentence rather than the whole block, which is the difference between correcting a fact and reopening a conclusion.

The founder's reference was Cursor, and he was right about the mechanic. Plan, approve, execute. I kept that and dropped the rest, because Cursor edits a file you can revert privately. In Cursor the plan step is a convenience. Here it's what makes the correction admissible.

Decision 2

Correcting one fact can change five conclusions. That’s the moment where the AI stops and asks.

A correction to an occupation field moves through whatever the model concluded downstream, and the investigator can't see that reach from the sentence they're editing. The copilot proposes a reprocessing plan naming every block the correction touches. Nothing runs until the investigator approves the list.

The autonomy line isn't drawn at capability. Parsing unstructured input, asking a follow-up, calculating its own blast radius: automated. Writing to a file someone signs: never without approval.

Decision 3

The audit trail is a byproduct of correcting, not a second job.

Every correction writes a change card with undo, preserves the prior version, and lands in case history.

Undo looked wrong at first. A reversible audit trail sounds like a weaker record. The undo is itself a logged event, and making correction easy to reverse is what makes investigators willing to correct at all.

What I decided not to do

Rerunning the full investigation was the obvious build but it would have affected credibility.

Engineering surfaced the constraint I'd have designed straight past: the model's scores drift between runs on identical inputs. A correction that reruns everything hands back a report where the fix landed and four unrelated conclusions also moved, for no reason anyone can explain. So reruns scope to the blocks named in the plan.

The layout breaks below 768px and investigators run this in split-screen. I didn't solve it. It went into the handoff as a named, undesigned constraint, because a constraint you don't name gets read later as one you missed.

Only one investigator was available to interview, and she supervised the agent rather than working a client queue. I couldn't tell whether her reading order was the natural mental model or an adaptation to a broken interface. The correction surface works under both, and the open question is in the handoff.

Impact

The panel, the hover trigger, and the correction chain are live.

A correction parses, asks for approval, writes a note with undo, and queues a rerun scoped to named blocks. The plan card doesn't render yet, so approval happens in chat prose. Inline selection was designed and hasn't been built.

The handoff was annotated Figma covering both intents, the approval flow, layout at each breakpoint, the case history surface, and the co-pilot components.

The measure I set was whether corrections move out of the Google Sheet and into the product. That data doesn't exist yet, and I'd rather say so than not. What's true now is structural: notes, corrections, and the record of both have somewhere to live inside the case.