Classifiers
A classifier is a check — one focused question Firetrail asks about every pull request. One classifier asks "is this PR doing several unrelated things at once?". Another asks "does anything test the behavior this PR changes?". Each one reads the diff, answers its question, and reports three things: a verdict, a risk level (from none up to critical), and its confidence in what it saw — always with the evidence to back it up.
The confident findings are what build the Future Debug Cost. Ten classifiers are built in, and they all run in parallel on every analysis. Here's each one, and why it earns its place.
The ten built-in classifiers
Multi-Intent
Is this PR really several PRs in a trench coat?
A PR that fixes a login bug and, while it is there, fixes a misaligned badge on the product page is two pieces of work sharing one review, one revert, and one line in the git history. If either causes trouble, you can't roll it back without losing the other. An "intent" here means the goal of a change, not the kind of file it touches: a feature implemented on two pages is one intent, and so is a backend change with the frontend that exposes it, or a check shipped with the CI job, the script and the docs it needed. It becomes two intents when unrelated work rides along — a refactor of a module the feature never needed, a dependency bump the fix didn't require, a second bug with its own root cause. Frontend and backend changing together, and refactoring mixed with implementation, have their own checks below.
Refactor + Implementation Mix
Is a cleanup tangled up with a behavior change?
Refactor-only PRs are easy to review ("does everything still behave the same?"). Behavior-change PRs are easy to review ("is the new behavior right?"). A PR that does both is hard to review, because every line makes you ask which kind of change is this? — and that's exactly where bugs hide. Firetrail defines "refactor" by intent: restructuring working code for its own sake. Moving or reshaping code because your feature required it is just implementation, and doesn't trigger this check.
Frontend/Backend Mix
Does this change cross the stack?
A PR touching both frontend and backend needs a reviewer comfortable in both worlds — or two reviewers. In practice it often gets one reviewer who's strong on one side and skims the other. This check flags the pattern so the skimmed half gets real attention.
Global Config Change
Could this change break production or the pipeline that ships to it?
Build tooling, Docker and deploy config, CI workflows, framework boot files,
database configuration — these files have a wide blast radius and usually thin
test coverage. A one-line change can take down a deploy. This check is about
operational risk, so harmless lookalikes don't trigger it: editing
.env.example or .gitignore is not a config risk, and Firetrail knows the
difference.
Package Update
Did the dependencies actually change?
Dependency bumps can pull in subtle breaking changes, and when they ride along
inside a feature PR they get almost no scrutiny. This check fires only when a
dependency truly changed — a version bump, an addition or removal, a lockfile
update. Editing the scripts section of package.json isn't a dependency
change, and doesn't trigger it.
Test Relevance
Does anything test what this PR changes?
Not "does the repo have tests" — does anything exercise the behavior this PR touches? Changed logic with no relevant test is the classic future debugging cost: the change works today, and nothing will catch the day it stops.
Meaningful Change Complexity
Is this a real logic change, and how demanding is it?
This check separates changes that alter behavior from changes that just move text around — and it acts as the gatekeeper for the rest of the score. Several risk patterns only count when the PR actually changes meaningful logic, which prevents Firetrail from punishing trivial bundles that merely look busy.
Cognitive Complexity
Will a human be able to follow this code in six months?
Deep nesting, long branchy functions, boolean conditions you have to diagram to understand — code like this works, but every future reader pays a tax on it, and future debugging happens exactly there. This check flags PRs that add hard-to-follow code; it stays quiet (or reads as a good sign) when a PR flattens complexity instead.
Intent Drift
Does the PR do things its description never mentions?
Every meaningful decision that ships undisclosed — a new endpoint, a validation, a permission change, a side effect — becomes an invisible decision: real behavior with no written trace of why. This check compares the diff against the PR's title and description and flags meaningful undisclosed work. It's fair about it: a terse but accurate title counts as disclosure, and the mechanical details of a described feature are never held against you. Its findings power the "said vs. did" view on the PR analysis page.
Triviality
Is this change big but harmless?
The one classifier that works in your favor: it subtracts points. A rename sweeping 40 files, a formatting pass, a file move — these look dramatic in a diff but change no behavior. Triviality recognizes them and discounts the score so size alone never reads as risk. In analytics it's badged as a false-positive reducer, so its "flags" are read correctly.
Confidence keeps the score honest
Every finding comes with a confidence level, and only findings above the confidence bar contribute points to the score or appear in the GitHub comment. Below-the-bar findings aren't hidden — you'll see them on the PR analysis view — they just don't get to move the number. Firetrail would rather show you an unsure observation than either bury it or bet the score on it.
Which classifiers run on your plan
Free and Starter plans run four of the ten: Multi-Intent, Refactor + Implementation Mix, Frontend/Backend Mix, and Triviality. Pro and Business run all ten. On limited plans the remaining checks appear as locked rows on each PR, so you can see what a full analysis would add. See Plans & billing.
Going further
- Watch how each classifier performs on your repository — including whether its flags predicted real bugs — in Classifier Analytics.
- Add checks of your own, in plain language, with custom classifiers.