ML fusion

Two models, two different jobs

KaizoCore runs two machine-learning models alongside the deterministic rule engine, each answering a different question:

• A supervised classifier (XGBoost) trained on labeled bot vs. human behavioral features — speed variance, speed kurtosis, directional entropy, acceleration jerk, jerk variance, jerk autocorrelation — answers "does this look like the bots we've specifically seen before?"
• An unsupervised anomaly detector (Isolation Forest), trained exclusively on human data, answers a different question: "does this look unlike the humans we've seen before?" — catching novel automation patterns the supervised model was never trained on, at the cost of a fuzzier signal.

Both output into the same fusion formula: ml_bot_prob (the classifier's confidence) and if_anomaly_dev (the anomaly detector's deviation), each weighted conservatively and gated by data completeness.

Training data

The models are trained on a deliberately diverse mix:

• Real production ground truth — genuine customer decisions, the smallest but most valuable slice.
• A dedicated honeypot — a fake checkout page running the real collector script, hit by both real human testers and a 17-script adversarial bot suite (plain Playwright/Puppeteer/Selenium, several stealth-patched variants, a Bezier-curve mouse generator, raw HTTP replay, and more) covering a wide range of real automation techniques, not synthetic approximations of them.
• External human-baseline datasets — real desktop mouse dynamics (RDP-session capture, lab click-to-click tasks, real search-results-page browsing) to diversify what "normal" looks like beyond one customer's traffic.
• A large external bot dataset of real CAPTCHA-solving automation — stratified into training, not dumped in unweighted, so one dataset's quirks don't dominate the diversity the honeypot suite provides.

Specific hard cases — sophisticated Bezier-curve mouse generators in particular — are deliberately upweighted during training, so the loss function can't quietly ignore a small but important minority class in favor of easy, high-volume bot traffic.

Why Stage A, and what Stage B looks like

The 85% rules / 10% supervised / 5% unsupervised split is called Stage A deliberately — a conservative rollout weighting, not a permanent ceiling. The reasoning: a newly-trained model's real-world false-positive rate on live, unseen traffic is the thing that actually matters, and that can only be measured by running the model in production with a small, bounded blast radius if it's wrong. Promoting to a higher ML weight (Stage B/C) is a real, available option once a model's live track record — measured against real customer traffic, not just a held-out test set — earns it.

A concrete, measured result

The clearest evidence this approach works: a specific, hard bot class (sophisticated Bezier-curve mouse-movement generators, which produce synthetic mouse paths carefully engineered to look organic to naive feature checks) was found to evade an earlier hand-derived deterministic rule almost entirely. Retraining the ML model on an expanded, more diverse dataset — without touching that rule at all — raised detection of this specific bot class to 82.2%, at a 0.5% false-positive rate on real humans. That's the model doing something a hand-written rule struggled to: learning a subtler, higher-dimensional signature than any single engineered feature captures on its own.

Why fingerprints never enter this model

Every feature these models train on is behavioral — derived from mouse and keystroke dynamics, never from a static device fingerprint. This is the same invariant from Why KaizoCore enforced at the model-architecture level: even if a fingerprint were somehow a strong statistical predictor in a training set (because harvested fingerprints correlate with known bot infrastructure), building that correlation into the model would recreate exactly the trust-a-static-signal failure mode KaizoCore is built to avoid.