Severity penalties
Each diagnostic finding carries a base penalty that reflects how serious it is. Errors hurt more than warnings, which hurt more than informational hints.| Severity | Base penalty |
|---|---|
| Error | 3.0 |
| Warning | 1.0 |
| Info | 0.25 |
Engine weights
Base penalties are multiplied by the weight of the engine that produced them. aislop uses an AI-slop-first weighting profile by default, so patterns left by AI coding agents have a much stronger impact on your score than generic formatting noise.| Engine | Default weight |
|---|---|
ai-slop | 2.5 |
security | 1.5 |
architecture | 1.0 |
code-quality | 0.8 |
lint | 0.6 |
format | 0.3 |
Style findings count for half
Rules that measure house style and maintainability —trivial-comment, narrative-comment, file-too-large, and function-too-long — still appear in your findings list, but they contribute only half their normal weighted penalty to the final score. This keeps your score driven by genuine slop (swallowed errors, dead code, hallucinated imports) rather than formatting preferences, without hiding style issues entirely.
Per-rule saturation cap
By default, a single rule can contribute at most 40 weighted penalty points to the total (maxPerRule: 40). If one noisy rule fires hundreds of times across your codebase, it cannot dominate the score and crowd out findings from other rule families. All matching findings still appear in the report — only the score contribution is capped.
Density normalization
The final score uses logarithmic scaling with issue-density normalization. Penalties are measured relative to the number of source files in the project:- A handful of issues in a large codebase do not tank the score unfairly.
- A single issue in an otherwise clean project stays proportional.
- The score remains meaningful regardless of whether you’re scanning a 10-file side project or a 2,000-file monorepo.
Score labels
| Score | Label | What it means |
|---|---|---|
| 75 – 100 | Healthy | The codebase is in good shape. AI-introduced patterns are minimal. |
| 50 – 74 | Needs Work | Meaningful issues are present. Prioritize AI Slop and Security findings. |
| 0 – 49 | Critical | Significant problems found. Use aislop fix to clear what’s mechanical, then hand off the rest to your agent. |
You can customize these thresholds in
.aislop/config.yml under scoring.thresholds.good (default: 75) and scoring.thresholds.ok (default: 50).Tuning your score
Guidance for adjusting scoring behavior
Guidance for adjusting scoring behavior
Prioritize AI output hygiene
Increase the
ai-slop weight (e.g. 3.0) if strict AI-output hygiene is your primary concern and you want AI-slop findings to dominate the score.Prioritize security
Increase the security weight if dependency vulnerabilities and runtime risks should be the primary driver of your score.Reduce noise on legacy codebases
Increase smoothing (default: 20) to reduce penalty spikes when scanning large codebases with accumulated technical debt. Higher smoothing makes gradual improvement feel more proportional.Allow repeated findings to punish more
Increase maxPerRule beyond 40 if you want a rule that fires hundreds of times to keep accumulating penalty beyond the default cap.De-emphasize style
Lower the lint and code-quality weights if you want the score to focus purely on AI-specific signals and security rather than general code hygiene.Set a CI gate
Use ci.failBelow to block merges when the score drops below a threshold:scoring: in your config file. See Configuration for the complete reference and example configs.