Overview #

The Production Ready Score is a single number from 0 to 100 that summarises how healthy your code is. Alongside it, a READY / NOT READY label tells you whether the repository has crossed the production-ready threshold. Both are derived from the same data — the score and the label are one signal, not two.

The score is deterministic. It’s computed only from the pattern-matching rulesets; findings from the AI-powered scanners are visible on the AI Findings tab but deliberately don’t contribute to the score, so the number stays repeatable scan to scan.

Where to see it #

Open any repository — the Overview tab. The header shows:

• The score ring (0–100) on the right.
• The NOT READY or READY chip on the left — derived from the score.
• The stack profile the repository is using (e.g. Platform Default Stack (fork)).
• A counter row: rulesets, rules, findings.

Below the header, six area cards break the score down across the functional areas.

How the score is computed #

The score reflects rule health, not finding volume. The same rule firing in one file is treated the same as that rule firing in fifty files — once a rule is broken, it’s broken; fixing one occurrence is the same lever as fixing all of them.

Per-area sub-score:

1. For each rule that ran in your repository, Norma looks at the worst finding of that rule:
   • No finding — the rule scores 100 (clean).
   • Worst finding is LOW — the rule scores 75.
   • Worst finding is MEDIUM — the rule scores 50.
   • Worst finding is HIGH — the rule scores 0 (failed).
2. The area sub-score is the average of every rule’s score in that area, rounded.
3. If an area has no rules configured for the detected stack, the area card shows “Not measured” rather than 0% or 100%.

The overall Production Ready Score is a weighted average of the six area sub-scores. Each area carries a weight that sums to 100 across the six. (You’ll see the area weight displayed under each area card — e.g. Security · w 30%, Performance · w 20%.)

Worked examples #

A few cases to anchor the formula:

• 7 rules in an area, 1 fires HIGH, the other 6 are clean. The area scores (6×100 + 1×0) / 7 = 86%.
• 7 rules in an area, 1 fires MEDIUM, the other 6 are clean. The area scores (6×100 + 1×50) / 7 ≈ 93%.
• Same rule fires in 50 different files vs. just 1 file — the area score is identical in both cases. Files don’t change the rule’s pass/fail state.
• An area has 0 rules configured for your stack. The area card shows Not measured — no number, no PASS/FAIL chip. It also doesn’t count toward the overall score’s weighted average.

READY / NOT READY #

The score determines a single binary label shown next to the ring:

• READY — the score is at or above the production-ready threshold. Your code is in a state worth shipping.
• NOT READY — the score is below the threshold. Look at the lowest-scoring area cards to see where to focus first.

The threshold is the same for every Norma customer in this release — it’s not configurable per workspace or per tier.

Area cards #

The Overview shows one card per area:

• Security — vulnerabilities and unsafe patterns.
• Performance — code that won’t survive load.
• Architecture — design and structure.
• Maintainability — readability, complexity, tests.
• Scalability — patterns that won’t survive growth.
• Manageability — operational concerns (logging, config, observability).

Each card shows:

• The area’s score (0–100), or Not measured if no rules apply.
• A status chip — PASS or FAIL.
• A breakdown of findings by severity (H/M/L with counts).
• The total issue count and the count of rules affected.
• The area’s weight in the overall score (e.g. w 20%).
• A progress bar showing the sub-score visually.

Click a card to filter the Issues tab to just that area.

What changes the score #

• Fixing an issue. When the last finding of a rule is resolved, that rule moves to 100. Area sub-score recalculates on the next scan; the overall score follows.
• A new rule shipping. If a release introduces a new rule and your code triggers it, that rule joins your area’s denominator with whatever severity it fires at.
• A rule retiring. If a rule is removed from a release, it leaves the denominator — area sub-scores can shift even though your code didn’t change.
• The detected stack changing. Adding a new framework to your repo may activate additional rulesets at the next scan. That can change which areas are measured and how many rules each area runs.

What to do when you’re NOT READY #

In order:

1. Open the area with the lowest score first. That’s where rule-fixes will move the overall score most.
2. Inside that area, fix HIGH findings before MEDIUM before LOW. A HIGH fix moves a rule from 0 → 100; a LOW fix moves it from 75 → 100 — bigger lever, more score recovered.
3. Re-run the scan. The label flips to READY the moment the score crosses the threshold.

For step-by-step issue-handling guidance, see Reading results.

Frequently asked questions #

My score went down but I didn’t change any code. What happened?
A rule was added or updated in the latest release and your code triggered it. Open the Coverage tab — newly-introduced rules appear in the rule execution log.

Can I disable a rule I don’t want to apply to my codebase?
Rule-level disabling isn’t available in the July release. It’s on the roadmap.

One area shows “Not measured” — is something broken?
No. That area has no rules configured for your detected stack. For example, if your repo is pure backend Python, the React-leaning rules in another area may not apply — so that area is “Not measured” rather than scored. It’s excluded from the overall weighted average.

Same rule fires in 50 files — does my score get punished 50 times?
No. The score is per-rule, not per-finding. Fifty findings of the same rule is the same as one finding of that rule. (The Issues tab still shows all 50 because seeing the spread tells you the size of the fix — but it doesn’t drive the score.)

Can I share my score outside the product?
Not in the July release. An embeddable Quality Certification Badge is on the roadmap for a later release.

Related #

• Reading results — the Issues tab in detail.
• AI Findings — the AI-powered scanners whose results deliberately don’t move the score.
• Coverage tab — see exactly which rules ran on your code.
• Scans overview — when scans run and what they produce.
• Glossary — definitions of every term used here.