Architecture score explained

The 0–100 score is a review aid derived from the findings in one analysis run. It is not a benchmark of runtime speed, security, test coverage, or overall correctness.

The calculation

Each finding starts with a severity penalty: error 18, warning 7, info 2. Within a category, repeated findings of the same rule contribute penalty / √occurrence, so the second occurrence costs less than the first. Each category’s total deduction is capped at 100.

Default category weights are:

Category	Weight	Typical rules
Architecture	40%	Cycles, fan-in/out, dependency depth, boundaries.
Imports	25%	Duplicate imports, unused exports.
Components	20%	File length and JSX depth.
Complexity	15%	Approximate branch complexity.

The overall calculation is:

score = clamp(
  100
  - sum(category deduction × category weight / 100)
  - maintenance adjustment
  - critical adjustment,
  0, 100
)

The maintenance adjustment is min(5, max(0, finding count - 10) × 0.15). The critical adjustment is min(10, error count × 1.5). Intermediate deductions and the final score are rounded to two decimals.

Example: one architecture warning yields a category deduction of 7. At the default 40% weight, the weighted deduction is 2.8. With no other findings, both adjustments are zero, so the score is 97.2 (A+). The HTML report shows the same components in its score breakdown.

Grade bands

Grade	Score
A+	95–100
A	90–<95
B	80–<90
C	70–<80
D	55–<70
F	<55

A high grade with a small scanned scope can be misleading. The included Vite smoke example has one source module and scores 100 because it has no findings; it is not a comparative benchmark.

Change weighting deliberately

Put all four categories in .nklattice.json and make their values total exactly 100:

{
  "analysis": {
    "weights": {
      "architecture": 50,
      "imports": 20,
      "components": 20,
      "complexity": 10
    }
  }
}

An invalid total stops analysis. Changing weights changes the score for the same findings, not which rules run. Threshold changes can change both findings and score. See Architecture policy.

Compare two runs only when their source scope, scanner version, rule configuration, and weights are comparable. Use the finding list and changed files to decide what to fix; do not treat a small numeric increase as proof of improvement.