> ## Documentation Index
> Fetch the complete documentation index at: https://tashfiq.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Scoring and Caps
> How Charter computes its public score, why hard caps exist, and what each score zone means.
Charter's score is intentionally simple enough to understand, stable enough to gate in CI, and strict enough to reflect real trust boundaries. Every number is reproducible from the same inputs — no hidden weights, no model inference.
## The formula
The complete scoring formula for Charter v1:
```text theme={null}
score = max(0, 100 − B×20 − H×10 − M×4 − L×1)
final = min(base, applicable_cap)
```
Where `B` = Blocker count, `H` = High count, `M` = Medium count, `L` = Low count. Caps apply after the base is computed.
## Severity weights
| Severity | Penalty | Typical meaning |
| ------------- | ------: | ----------------------------------------- |
| Blocker | −20 | The repo is unsafe to operate on as-is |
| High | −10 | Significant risk or missing control |
| Medium | −4 | Important hygiene or readiness gap |
| Low | −1 | Useful improvement, but not a major risk |
| Informational | 0 | Signal only; listed in output, not scored |
Informational findings ([`AE-CTX-006`](/rules/AE-CTX-006), [`AE-SUPPRESS-003`](/rules/AE-SUPPRESS-003)) are listed in `charter doctor` output and the HTML report, but contribute zero to the score. They are signals, not penalties — they surface patterns worth knowing without changing the gate result.
## Score zones
| Range | Zone | Gate status |
| --------- | ---------- | ----------------------------------------------------- |
| 🟢 80–100 | Ship-ready | Passes threshold 80 (standard) and 90 (strict) |
| 🟡 60–79 | Needs work | Passes threshold 60 (relaxed) only |
| 🔴 50–59 | Blocked | Active Blocker finding; fails all standard thresholds |
| 🔴 0–49 | Critical | Raw secret detected; fails all thresholds |
These zones are descriptive, not magical. A repo at 80 and a repo at 98 are both in the same top band, but the category breakdown still tells you where the remaining friction sits.
## Hard caps
Caps apply **after** the base calculation and cannot be overcome by passing other rules. A repo with no other findings but one raw secret scores exactly 49 regardless of how many other rules pass. The only way past a cap is to fix or validly suppress the finding that triggers it.
| Condition | Cap |
| -------------------------------------------------------------------------------------------- | ---: |
| Raw secret detected ([`AE-SEC-001`](/rules/AE-SEC-001) or [`AE-SEC-002`](/rules/AE-SEC-002)) | ≤ 49 |
| Any Blocker finding present | ≤ 59 |
Two consequences follow directly from this design:
* A secret finding always keeps the final score in the Critical zone until the secret is removed or validly suppressed
* Even one Blocker finding prevents a repo from appearing "ship-ready" — the cap holds the final score at 59 or below, regardless of how well everything else scores
Suppressed findings are excluded from the base score calculation and listed separately in output.
## Example calculation
**Given findings:** 1 Blocker, 2 High, 3 Medium, 1 Low
**Step 1 — base score:**
```
100 − (1×20) − (2×10) − (3×4) − (1×1)
= 100 − 20 − 20 − 12 − 1
= 47
```
**Step 2 — apply caps:**
* Secret cap: no raw secret detected, does not apply
* Blocker cap: 1 Blocker present → cap is 59
* Base score (47) is already below 59, so the cap does not further constrain
**Final score: 47 — Critical zone**
Even though the repo has no raw secrets, the combination of one Blocker and several other findings pushes the score below 50. The Blocker cap would only matter if the base score were above 59.
**If the Blocker is fixed:**
```
100 − (0×20) − (2×10) − (3×4) − (1×1)
= 100 − 0 − 20 − 12 − 1
= 67
```
No active Blocker → no cap applies. Final score: **67 — Needs work zone.**
## Why the formula is public
You can calculate your expected score change before fixing anything. If you fix one Blocker, your score improves by at most 20 points — but caps may still apply depending on what else is active. Run `charter doctor` and do the arithmetic before planning your remediation order.
Charter keeps the formula public for trust. Teams need to know:
* what will fail CI and why
* whether a score changed because of a new secret, a new MCP risk, or a lower-severity hygiene issue
* that a major-version upgrade is the only place where the formula can change
The score is meant to be explainable in a pull request, a CI log, or a security review — without hidden weighting or version-to-version drift.
## Why the formula is stable
Charter is a governance tool. If the score moved unpredictably between releases, teams could not rely on it for gating or trend tracking.
So v1 keeps two things stable:
* the severity penalties (`B×20`, `H×10`, `M×4`, `L×1`)
* the hard-cap semantics for secrets and blockers
New rules can be added in minor releases, but they enter through the same scoring model and the same severity ladder.
## What the score is not
The score is not measuring code quality, product quality, or developer talent — only repository readiness for agent-assisted work. The [Agent Readiness Model](/docs/concepts/agent-readiness-model) explains what that readiness means and why the model is structured around three axes.
## Next steps
The three axes the score measures and why readiness is a repo property.
How suppressed findings are excluded from the base score and audited.
The command that computes the score and emits findings.
All 18 rules and the severity each carries into the formula.