Per-class Tuning

What Per-Class Tuning Means in Practice

Per-class tuning means treating each weakness category as its own decision problem. Instead of forcing one universal threshold, practitioners adjust the scoring rule to match how evidence behaves for that specific flaw type, which improves precision where signals differ in quality.

This approach matters because different defect classes rarely produce equally reliable signals. A pattern that is highly predictive for one category may be weak, noisy, or even misleading for another, so a single global setting can overcall some classes while missing others.

Why Per-Class Tuning Exists

The core reason for per-class tuning is variation in signal-to-noise ratio. Some weakness types are easy to detect with a strong indicator, while others require a broader combination of weaker signals, so the decision rule should reflect the evidence profile of each class.

It is most useful when the classes are imbalanced or operationally different. For example, a rare but severe weakness may justify a lower threshold to improve recall, while a common low-signal category may need a stricter threshold to avoid flooding reviewers with false positives.

How Per-Class Tuning Changes Decisions

Per-class tuning can involve separate thresholds, different weights on evidence features, or class-specific decision rules. The practical effect is that the same underlying detector can behave differently depending on what kind of weakness it is evaluating.

That flexibility is valuable when the cost of error varies by category. A false negative in one class may be more damaging than a false positive in another, so the tuning choice should reflect the relative review burden, remediation cost, and confidence level needed for each class.

Well-tuned class-specific logic also makes evaluation more honest. Instead of reporting one aggregate score that hides poor performance on a hard class, teams can inspect which categories are underperforming and where the model or rule set needs refinement.

Where Per-Class Tuning Can Go Wrong

Per-class tuning creates its own maintenance burden because every class becomes a separate policy surface. If the thresholds drift without good measurement, the system can become inconsistent, with similar evidence producing different outcomes depending on how the class was defined.

It can also mask taxonomy problems. When classes are poorly defined, the tuning layer may appear to fix the issue even though the real problem is that the categories overlap, the labels are unstable, or the signal definition is not specific enough.

Risk and Threat Considerations

Per-class tuning can reduce blind spots, but it can also create inconsistent decisions if one class is tuned too aggressively or if the class boundaries are poorly defined. In practice, that means the same evidence may be treated very differently across categories, which can distort prioritization and review outcomes.

Failure mechanism: Weak label quality, class imbalance, or overfitting to one category can produce thresholds that look accurate in testing but behave unevenly in production, especially when the underlying signal distribution shifts.

Impact: Teams may miss real weaknesses in one class, overload analysts with false positives in another, or create a false sense of confidence because aggregate metrics hide class-level failure.

Practitioner Guidance

What to watch for: Use per-class tuning when classes have clearly different evidence patterns and error costs, not simply because a single model is underperforming. The key question is whether the category-specific rule improves decision quality in a way that is measurable and explainable.

Governance implication: Keep the class definitions stable and review the tuning logic whenever labels, data sources, or remediation priorities change. If the category schema is shifting, the tuning layer should be revisited rather than treated as a permanent fix.

Related resources from NHI Mgmt Group

• Per-CWE Tuning
• When should organisations replace a DLP platform instead of tuning it?
• What do teams get wrong about per-seat licensing in agentic environments?
• Should security teams prefer tenant-scoped sync over per-realm provisioning models?