Dashboard score methodology

How the Q1–Q12 audit is scored

Each factor has a stable ID and a versioned definition: assessed risk, eligible population, evidence sources, unit, normalization, scoring function, thresholds, applicability, and limitations. The table summarizes the current unified-quality.v1 catalog.

Contributions and factor scores

Every canonical finding or metric signal has one primary factor. A report may cross-reference the same evidence from another factor, but it cannot apply the same contribution twice. Synthetic findings derived from a metric also share the metric’s evidence identity.

The model converts each accepted contribution to bounded badness in [0, 1]. Its versioned definition supplies the transform, weight, thresholds, and risk caps:

factor_score = 10 × (1 - min(1, sum(weight × badness)))

The current model gives all twelve factors equal weight. Changing weights, normalization, or thresholds requires another model version and calibration decision. The exact report records model_version, basis digest, source and CPG revisions, capabilities, evidence ledger, and limitations.

Classic audit section scores

The classic report also retains a score for each Q section. Finding weights are summed as W, with repeated findings contributing progressively less, and the section score is calculated as:

section_score = 10 × exp(-0.3 × W)

Q10 calculates its initial coverage score separately:

coverage_score = 10 × (0.82 × method_coverage + 0.18 × line_coverage)

Risk modifiers for uncovered methods are then applied. The classic overall score correction is capped at overall_score_raw + 3.5. These values remain in the report to explain the classic audit and preserve compatibility. They do not replace the unified-quality.v1 factor scores or make an incomplete assessment eligible for scoring.

Missing evidence and overall score

Each factor is measured, partial, unavailable, or not_applicable. Unsupported facts, query failures, missing denominators, and incomplete CPG coverage remain explicit. They are not converted to zero or a neutral passing value.

The overall score is the weighted mean of applicable factor scores only when every required factor is complete and the report has no blocking limitation. Otherwise score_eligible=false and overall_score=null. In particular:

• Q10 can show structural testability, but runtime coverage remains a separate requirement when the selected project profile requires it;
• Q4 and Q5 structural proxies do not prove runtime throughput or capacity;
• Q12 docstring presence does not prove that documentation is correct or useful;
• an empty finding list does not repair a missing capability or stale CPG.

Legacy compatibility scores

Older reports may contain severity-weighted section scores, metric penalties, module_health, and a numeric overall_score. CodeGraph preserves these values with their original version, or labels them legacy-unversioned when no version was stored. Current consumers must not use them as the decision score for a versioned report. Re-scoring is allowed only from complete saved input evidence and produces a separate derived evaluation with provenance.

How the other components are scored

Compliance

The GOST R 56939 report assigns each process one status:

• full = 1;
• partial = 0.5;
• gap = 0;
• n_a is excluded from the denominator.

compliance_score = 100 × sum(process_value) / applicable_process_count

If no processes apply, the result is 0 rather than 100. Critical gaps remain separate evidence: equal percentages do not imply identical gap profiles.

Release

Release Gate runs the checks in the selected profile. Every check is either a blocker or a warning:

• any failed blocker → fail;
• no failed blocker, but at least one failed warning → warn;
• all checks pass → pass.

An unknown profile, a check error, or an authorization failure is fail-closed. In the default standard profile, critical findings are prohibited, high findings are limited to five, average cyclomatic complexity is limited to 15, and coverage must be at least 55%. The last two checks are warnings. The gost-56939, standard, and minimal profiles have different check sets, so always read the profile ID and individual check results with the status.

SCA

The SCA component uses dependency vulnerability counts by severity:

sca = clamp(1 - 0.15 × critical - 0.08 × high - 0.02 × medium, 0, 1)

Low and informational vulnerabilities do not enter this formula, but remain in the SCA report. This formula scores the persisted severity summary; it does not replace reachability analysis.

Quality

The default Quality weights are runtime coverage — 40%, documentation coverage — 20%, dead-code ratio — 20%, and complexity — 20%. The composite Health Score weights are audit — 30%, compliance — 25%, release — 20%, SCA — 15%, and quality — 10%.

complexity_norm = min(avg_complexity / 20, 1)
quality = 0.40 × runtime_line_coverage
        + 0.20 × documentation_coverage
        + 0.20 × (1 - dead_code_ratio)
        + 0.20 × (1 - complexity_norm)

All ratios are in the 0–1 range. If runtime line coverage is unavailable, its contribution is zero and the unavailability reason remains in score_breakdown.

Composite Health Score

The current score_formula_version is v1. The default formula is:

health_score = 100 × clamp(
  0.30 × audit/10
  + 0.25 × compliance/100
  + 0.20 × release
  + 0.15 × sca
  + 0.10 × quality,
  0, 1
)

Release maps pass to 1, warn to 0.5, and fail to 0. A deployment may override component weights, so the response’s score_breakdown is authoritative for a particular result.