Thresholds

The final numeric risk score is mapped to a human-readable label using threshold boundaries. These thresholds determine which color-coded badge appears on each validated flow.

Default thresholds

The web app always uses these default thresholds.

CLI overrides

The CLI can apply different tier boundaries through a flat thresholds array in its --config file, for example:

{
  "thresholds": [
    { "max": 25,  "label": "Low" },
    { "max": 50,  "label": "Medium" },
    { "max": 75,  "label": "High" },
    { "max": 100, "label": "Critical" }
  ]
}

Rules

• There are exactly 4 tiers. They are positional: the first is the Low tier, then Medium, High and Critical. The labels are free text, so P4, P3, P2, P1 works.
• Each max is an integer from 0 to 100, strictly ascending, and the last one is 100. The first tier always starts at 0.
• Each label is a non-empty string of at most 32 characters (surrounding spaces are trimmed). Labels must be unique, ignoring case.

A config that breaks any rule is a configuration error: the CLI prints messages that name the offending entry, such as thresholds[3].max must be 100 (got 40), and exits with code 1 (tool error) instead of silently falling back to the defaults. Invalid weights are handled the same way (see Overview).

Thresholds move the floors

The score floors follow the tier starts, so a floor always produces the intended tier:

For example, with tiers 60 / 80 / 90 / 100:

• a private TCP/80 flow is floored to 61 for plaintext, plus the +10 penalty: 71, Medium;
• a Deny zone flow is floored to 81, High;
• any-to-any TCP/443 is floored to 91, Critical.

The +10 plaintext penalty stays a fixed 10 points.

How labels are used

The label derived from these thresholds appears in several places:

• Risk score badge on each validated flow, color-coded by severity.
• Bulk upload results table, enabling sorting and filtering by risk tier.
• Exported reports, where the label accompanies the numeric score.