Coverage

Overview #

The Coverage tab on a repository shows what Norma looked at during its most recent scan — your detected tech stack, the rulesets that ran, and which rules actually executed. It’s where you go when you want to know why something wasn’t caught.

Getting there #

Open any repository — click the Coverage tab in the top navigation alongside Overview and Issues.

What’s on the page #

The Coverage tab has three sections:

1. Detected stack profile #

A list of every language and framework Norma auto-detected in your repository. For each one you’ll see:

  • The technology name (e.g. TypeScript, React, FastAPI).
  • The signal we used to detect it — file count, manifest file name, or framework-specific marker.
  • The ruleset that gets applied because of it (e.g. TypeScript — links to the TypeScript ruleset).

Together these make up your repository’s Stack Profile — the bundle of rulesets that runs on every scan.

2. Rulesets running #

Every ruleset active for this repository, with:

  • A summary count — “53 rules from the Python ruleset”.
  • A link to the full ruleset documentation.
  • Per-impact-area breakdown — how many rules in this ruleset cover Security, Performance, Architecture, etc.

If a ruleset you’d expect is missing, it usually means the stack signal wasn’t strong enough to trigger it. Common fixes:

  • The relevant manifest file isn’t in the default location (e.g. package.json at a subfolder rather than the repo root).
  • The framework is referenced but not declared as a dependency.
  • The file count for that language is below the auto-discovery threshold.

3. Rule execution log (last scan) #

A row per rule that ran in the most recent scan:

Rule Status Files scanned Findings
py-sec-eval-exec ✅ Ran 47 0
py-perf-async-requests ✅ Ran 47 2
py-arch-assert-isinstance ⏭ Skipped (no matching files) 0 —

Statuses you might see:

  • ✅ Ran — the rule executed against your files.
  • ⏭ Skipped (no matching files) — the rule targets a file pattern your repo doesn’t have.
  • ❌ Failed — the rule errored during execution (rare; logs the trace ID for support).

Click any rule to jump straight to its entry in the ruleset documentation.

Why this tab matters #

You’ll mostly use the Issues tab and the Overview tab — they tell you what Norma found. The Coverage tab tells you what Norma looked at, which is the other half of the picture.

Use the Coverage tab when:

  • You’re suspicious that a known issue wasn’t flagged (“we have a SQL injection in this file — why didn’t Norma catch it?”). Coverage will show whether the relevant rule ran on that file.
  • You want to know which rulesets are active for a repository before running a scan — for example to estimate whether expanding the ruleset (by adding another language to the repo) will surface new issues.
  • You’re investigating why your Production Ready Score moved unexpectedly — Coverage shows whether a new ruleset was added or removed between scans.
  • You’re embedding Norma into a compliance or audit process — Coverage gives a defensible “this is exactly what we checked.”

What the Coverage tab is NOT #

  • Not a way to disable rules. Rule-level disabling isn’t available yet — see Rulesets overview — What rulesets don’t do.
  • Not a real-time view. Coverage reflects the last completed scan. While a new scan runs, the Coverage tab continues to show the previous scan’s coverage with a banner: “New scan in progress — coverage will update when it completes.”
  • Not editable. You can’t manually tell Norma to include or exclude a ruleset. The Stack Profile is auto-derived. To get a different ruleset to apply, change what’s in your code (e.g. add the framework as a dependency).

Frequently asked questions #

My stack uses Django but it’s not detected. Why?
Django isn’t in the July 2026 release. See Supported languages and frameworks for the coverage matrix.

Can I export the Coverage data?
Not in v1 of the UI. The data is available via the API; talk to support if you need it for audit purposes.

A rule ran on zero files. Did the scan fail?
No — that’s expected when a rule’s file pattern doesn’t match anything in your repo. For example, node-no-lint-config only runs if there’s a package.json; if your repo is Python-only it’ll skip with “⏭ Skipped (no matching files)”.

Why does my score change when nothing in my code changed?
Two reasons: (1) we shipped new rules in a release — the Coverage tab will show new rows. (2) Auto-discovery picked up a framework you didn’t have before. Compare Coverage between the two scans in the Execution History view to see what changed.

Related #

Was it helpful ?