Skip to main content
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:
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

SeverityPenaltyTypical meaning
Blocker−20The repo is unsafe to operate on as-is
High−10Significant risk or missing control
Medium−4Important hygiene or readiness gap
Low−1Useful improvement, but not a major risk
Informational0Signal only; listed in output, not scored
Informational findings (AE-CTX-006, 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

RangeZoneGate status
🟢 80–100Ship-readyPasses threshold 80 (standard) and 90 (strict)
🟡 60–79Needs workPasses threshold 60 (relaxed) only
🔴 50–59BlockedActive Blocker finding; fails all standard thresholds
🔴 0–49CriticalRaw 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.
ConditionCap
Raw secret detected (AE-SEC-001 or 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 LowStep 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 zoneEven 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. It answers one narrower question: How ready is this repo for safe, verifiable use by coding agents? If you want the reasoning behind the model structure, continue to Agent Readiness Model.