The feedback loop
1
Model flags a cluster
Graph and behavioral signals produce a candidate case, as described in Mule Graph Detection.
2
Analyst disposition
Every case an analyst closes — confirmed mule ring, false positive, or inconclusive — is captured as a labeled outcome, not just an audit-log entry.
3
Outcomes accumulate as training signal
Confirmed cases reinforce the patterns that correctly flagged them; false positives are just as valuable — they tell the model which patterns it’s over-weighting.
4
Backtesting before any model update ships
A candidate model update is run against historical labeled cases before it’s promoted — confirming it improves precision/recall on known outcomes, not just performing well on paper. See Backtesting below.
5
Promoted model informs future flags
Only after backtesting validates an improvement does the updated model start generating new candidate cases — closing the loop.
Backtesting
Before any model change is promoted to production, it’s evaluated against a held-out set of historically confirmed cases — both true positives (confirmed mule rings) and true negatives (accounts investigated and cleared). This catches two specific failure modes a naive “retrain and ship” process wouldn’t:Regression on known patterns
A model update that gets better at catching a new pattern but worse at catching previously well-detected ones — backtesting against the full historical case set catches this before it reaches production.
False-positive drift
A model that becomes more aggressive (catches more true positives) at the cost of a rising false-positive rate — analysts bear that cost directly in caseload, so this is tracked explicitly, not just accuracy in aggregate.
