Minecraft anticheat guide
Axis Balance and Learned Aimbot Models Explained
How FairPlay's axis balance and learned-model aimbot checks compare yaw and pitch, read model episodes, and how staff should review them before any action.
How do axis balance and learned-model checks differ?
These six checks compare the two view axes against each other, or they hand a window of rotations to a learned model. The axis checks ask how yaw and pitch relate. The model checks ask whether a pattern resembles examples the server was trained on. Both produce an alert that describes a relationship, not an action.
The family covers Axis Magnitude, Yaw Pitch Average, Yaw Pitch Regression, Aimbot Factor, Machine Learning and Rotation Statistics. The first four are rule-based comparisons of the two axes. Machine Learning reads model episodes across time. Rotation Statistics combines two pitch and lattice experts with a vote over a window.
Keep the two halves separate in your review. An axis alert and a model alert come from different reasoning, and treating them as one finding hides that difference.
Which cheat behavior do the axis checks target?
The axis checks target a relationship between yaw and pitch that human hands do not usually produce. Axis Magnitude looks at cases where one axis carries most of the movement while the other moves in an opposing way. Yaw Pitch Average looks at the average behavior across a varied yaw trace. Yaw Pitch Regression fits a simple relationship and reads how well the pitch follows the yaw.
Aimbot Factor looks at rotation magnitude in buckets. It reads very large rotations and rotations whose magnitude sits in a range that is hard to produce by hand in a short time. Its reading depends on the magnitudes across a short run of recent samples, not on a single turn.
What does the learned-model side actually read?
Machine Learning does not read one turn. It reads episodes, meaning stretches of play where a model's output stays elevated. The family keeps short-term and long-term evidence and only treats a pattern as meaningful when it persists across the relevant span of play. A single high reading is not an episode.
Rotation Statistics runs two experts over a window of rotations and combines their votes. Its class notes describe a shadow mode that is used by default. Read that as a sign that its output is a signal for review, not something that acts on its own. Confirm the mode on your own server before you read its alerts as final.
Which legitimate play can match these patterns?
A player who uses a trackball, a gaming mouse with unusual settings or a controller-style input can produce yaw and pitch relationships that differ from the usual pattern. Players who only aim horizontally, such as those who spend a fight turning around a target, have unusual pitch behavior that the axis checks can read as imbalance.
Model episodes can rise during any unusual play, not only aiming. Heavy movement, unusual camera use during a build or a long fight with frequent repositioning can all produce a stretch that a model reads as unfamiliar. The model does not know what the player was doing unless you tell it through a review.
How should staff review a model or axis alert?
Read the alert in the order it was produced. For axis alerts, ask what the player's setup and style are, then check the window. For model alerts, check whether the episode persisted across the play, then check the recording. Only then should you combine the two.
The table below sets out the first check for each group.
| Check group | What the alert describes | First review step |
|---|---|---|
| Axis Magnitude and Yaw Pitch Average | One axis carrying the movement, or a skewed average | Ask about the player's setup and whether they aim mainly horizontally |
| Yaw Pitch Regression | A fit that describes pitch following yaw | Confirm the window contains real attack and movement, not idle turns |
| Aimbot Factor | Rotation magnitudes in an unusual range | Compare with the same fight in a recording |
| Machine Learning | A model episode that persisted across play | Check the episode span and what the player was doing during it |
| Rotation Statistics | A vote from two experts over a window | Confirm the mode the server runs in and read the output as a review signal |
What belongs in staging for learned checks?
Learned checks change when the model changes, and axis checks change when their windows and buffers change. Both need a fixed replay set before you touch them. For model work, keep the training and review records separate from production so the origin of every model is clear.
Never ship a model change on the strength of a single test run. Run the same replay set before and after, and record the alert counts for each family member.
What should a learned-model alert never be used for?
A model alert should not be the only basis for punishment, and it should not be published as proof. It is a prompt to review. The model cannot read a player's intent, cannot see hardware, and cannot tell a skilled unusual aim from an unusual cheat.
Keep your review notes with the model version and the episode span. Those two facts make a later review of the decision possible.
FAQ
What is an episode in the machine learning check?
An episode is a stretch of play where the model output stays elevated across the relevant span, not a single high reading. Review the span and what the player was doing during it.
Why does a horizontal-only aimer trigger axis alerts?
The axis checks compare yaw and pitch relationships. A player who rarely changes pitch has an unusual balance, which can read as imbalance even though the aim is ordinary.
Should the Rotation Statistics output be treated as final?
Not without confirming the mode the server runs in. Its class notes describe a default shadow mode, so treat its output as a review signal until you have checked the setting on your own server.