Confusion-Aware Explainable Alert Triage for Network Intrusion Detection

1. Introduction

Machine learning (ML) has become the dominant way to build network intrusion detection systems (IDS), and modern ML-based detectors report high overall detection performance [1,2]. Trained on labelled network traffic, such a detector classifies each flow as normal or as one of several attack types. In practice, these detectors feed a security operations centre (SOC), where the volume of alerts now outpaces what analysts can investigate, and alert fatigue is a recognized cause of missed detections and analyst burnout [8,9]. A high overall performance score does not, on its own, tell an overloaded analyst which alerts to trust and act on; for that, the analyst must understand each alert and judge how far to trust it, which is why explainable AI (XAI) has become central to modern IDS research [6].

Research on ML-based IDS has followed three broad directions. The first pursues higher detection performance: deep-learning models capture complex traffic patterns, ensemble methods combine several classifiers for robustness, and, because attack types are very uneven in number, a large body of work rebalances the under-represented attacks through resampling, synthetic oversampling, or cost-sensitive training [10,11,12,13,14]. These methods steadily raise the scores reported on standard benchmarks.

The second direction makes detectors interpretable, since an operator will not act on a decision they cannot understand. Post-hoc attribution methods such as SHAP (SHapley Additive exPlanations) and LIME (Local Interpretable Model-agnostic Explanations) assign each input feature a contribution to the model’s output and are now the standard tools for explaining IDS predictions [6,15,16,17]. The third direction studies how to divide work between the detector and the human: instead of acting on every prediction, a system can defer the uncertain ones to an analyst through a reject option or a learning-to-defer rule [21,22,23]. Each of these directions has advanced steadily, but largely on its own.

Despite this progress, three problems remain. First, detection performance is almost always reported as a single overall score that averages over all attack types at once. It therefore hides how the detector behaves on any individual type: the rare attacks that matter most are often the ones it detects least reliably, yet this weakness stays invisible in the aggregate. An analyst holding one alert has no way to read, from a headline number, how far to trust that particular label [3,4]. Second, the explanations produced for these detectors are seldom validated. A feature-attribution method tells the analyst which inputs influenced a decision, but not whether those inputs are genuinely responsible for it, and a feature can rank high merely because it correlates with the label; systematic reviews confirm that quantitative tests of explanation faithfulness remain rare [5,6,7]. Third, existing methods for routing alerts threshold a single confidence score. That score is poorly calibrated in exactly the attack types where the detector is weakest, so the alerts most in need of human review are the ones it misjudges, and these methods give the analyst no reliable account of what an uncertain alert most likely is [8,9]. In short, current systems report how well a detector does on average, but not how far to trust it for a given attack type, nor why, nor what to do with an uncertain alert.

This paper addresses these problems with a unified, reliability-centred approach to intrusion detection and triage. Our goal is to give an analyst, for each attack type, a trustworthy account of the detector’s behaviour, so that attention concentrates on the alerts where reliability is lowest while routine, reliable predictions are handled automatically.

The main contributions of this paper are summarized as follows:

1.

Reliability for each attack type. We show empirically that a detector’s reliability can be estimated for each attack type, that this estimate stays stable across training runs and transfers from validation to unseen test data, and that each attack type has a consistent “twin”, the attack it is most often confused with.

2.

Validated explanations. Building on SHAP-based attribution [15], we explain why the detector chose one attack type over its most likely alternative, and we test empirically that these explanations are faithful, that is, that the features they highlight are the ones the detector truly relies on.

3.

Reliability-driven triage. We propose a triage framework that extends selective classification and learning to defer [21,22] and the three-mode human-AI teaming of Baruwal Chhetri et al. [9]: it routes each alert, by its attack-type reliability, into automatic handling, analyst assistance, or escalation. We measure the escalation rate and the share of the detector’s errors it catches, estimate its cost with a standard cost model under illustrative parameters, and, for each escalated alert, produce a compact card designed to support the analyst’s decision. The framework is a proposed decision aid; validating its usefulness with analysts is left to future work.

The remainder of this paper is organized as follows. Section 2 reviews related work on ML-based IDS, explainability, and alert triage. Section 3 states the problem, the objectives, and the proposed framework. Section 4 presents the method, and Section 5 describes the datasets, models, and experimental setup. Section 6 presents the results. Section 7 discusses their implications and limitations, and Section 8 concludes.

2. Related Work

This section reviews three strands of prior work that our approach brings together: machine learning for intrusion detection, explainability for those detectors, and the selective-classification and alert-triage methods that decide when to involve a human. For each, we outline what it achieves and the gap that the corresponding contribution of this work fills.

2.1. Machine Learning for Intrusion Detection

Machine learning now underpins most intrusion detection, and its scope is surveyed in recent reviews [1,2]. Detectors range from classical classifiers to deep neural networks and ensemble models, and on standard benchmarks they report high overall detection performance.

A central obstacle to this performance is class imbalance: a few attack types dominate the traffic, while the rarest and often most dangerous attacks appear in very small numbers. Under these conditions, standard classifiers detect the rare attack types far less reliably than the aggregate score suggests [3]. To counter this, researchers have proposed evolutionary preprocessing [10], generative adversarial network (GAN)-based oversampling of rare attack types [11], dynamic ensembles that adapt to the class distribution during training [12], and, more recently, models that combine deep learning with data augmentation [13] or hybrid feature selection [14].

These methods raise detection scores, but they are all judged by aggregate metrics on a held-out test set, and reported figures shift with preprocessing choices, so results are hard to compare across studies [4]. More importantly, none returns a reliability estimate for each attack type that still holds once the detector is deployed on live traffic. When a detector labels an alert as a given attack, neither an overall performance score nor any of these methods tells the analyst how far to trust that specific label, or what the alert is more likely to be. This gap motivates our first contribution.

2.2. Explainability for Intrusion Detection

Because ML-based detectors are often black boxes, a large body of work explains their outputs after the fact. SHAP [15], grounded in cooperative game theory, assigns each input feature a contribution to the model’s decision and is the most common attribution method in this field. An early application integrated SHAP into a full detection pipeline that combines local and global explanations to relate feature values to different attack types in a form security experts can read [16]. A survey of explainable IDS methods identified SHAP and LIME as the leading techniques and noted the scarcity of explanation-evaluation metrics as a recurring weakness [6], and other work paired an ensemble classifier with LIME to produce human-readable explanations [17]. Explainable deep-learning detectors have since been reported for Internet of Things (IoT) traffic [18] and for ensemble architectures that keep detection performance while adding per-alert explanations [19], while reviews caution that attributions can be manipulated by adversaries [20] and that quantitative faithfulness is rarely measured [5].

A common limitation runs through this work: attribution describes what a model outputs but rarely tests whether the highlighted features are truly responsible for the decision. A feature ranked first by SHAP may only correlate with the label, so removing it can leave performance unchanged or even improve it. Where faithfulness is measured, it varies sharply across attribution methods [7], which shows that fidelity must be tested for a given model rather than assumed. Our second contribution takes up this gap with a feature-deletion faithfulness test that separates the features that genuinely drive a decision from those that only appear important.

2.3. Selective Classification and Alert Triage

Deciding which predictions to act on automatically and which to send to a human is studied in the selective-classification and learning-to-defer literatures. Geifman and El-Yaniv developed the reject option for neural classifiers, which controls a coverage-risk trade-off by thresholding softmax confidence with formal risk guarantees over the accepted predictions, evaluated on general image-classification benchmarks [21]. Mozannar and Sontag extended this to a learning-to-defer setting in which a single loss trains the classifier together with a rule that decides when to defer and accounts for the human reviewer’s error rate [22]. In security, a reject-option classifier deferred uncertain intrusion detection and prevention system (IDPS) signatures to human experts [23], and a reject-option detector flagged low-reliability predictions on supervisory control and data acquisition (SCADA) network traffic [24].

On the operational side, alert fatigue is a main cause of analyst burnout and missed detections. A systematic survey of alert prioritization catalogued the criteria used to rank alerts and the methods that apply them [8]. Ban et al. filtered security information and event management (SIEM) alerts with a cost-sensitive classifier that reduces the volume reaching an analyst while keeping the critical ones [25]; AlertPro re-ranked alerts with reinforcement learning on datasets of multi-step attacks [26]; and a human-AI teaming framework set out, in three modes, how to divide responsibility between automated classifiers and analysts [9].

Two concurrent 2026 studies come closest to our setting: Gombar [44] folds model confidence, SHAP-based explanation strength, and attack severity into a suspicious-flow priority score, and Le et al. [45] map calibrated detector outputs to a graded action ladder with conformal action sets, reporting, as we do below, that this gate does not outperform a strong simple selective baseline. Both explain and prioritize alerts, but neither grounds the decision in a calibrated per-attack-type reliability estimate or tests the faithfulness of its explanations.

These lines of work remain separate. Selective classifiers and reject-option detectors defer on a single confidence score, which is poorly calibrated for exactly the rare attack types where the detector is weakest, and the security applications above were evaluated on signatures, SCADA traffic, or alert streams rather than on standard multiclass network-intrusion benchmarks. SOC triage tools, in turn, rank alerts by severity or confidence but do not give the analyst a calibrated estimate of the likely true attack type. No existing method combines a reliability model for each attack type with a cost analysis of the triage policy it produces. Our third contribution provides this missing combination.

3. Problem Statement and Proposed Approach

The previous section shows steady progress on intrusion detection, explanation, and alert triage in the IDS literature. Yet a detector is still judged mainly by its aggregate performance score on standard network-intrusion datasets [1,2], which does not, on its own, establish how reliable the detector is for any individual attack type, why it confuses one attack with another, or on what basis some of its alerts should be handled automatically while others are reviewed by an analyst.

Each of these corresponds to a gap in the literature reviewed in Section 2. First, detection performance is reported as an aggregate that averages over all attack types, so whether a detector’s reliability can be characterized for each attack type, and whether that characterization is stable across training runs and transfers to unseen traffic, is not established; the rarest attacks, which matter most, are often the least reliably detected [3,4]. Second, the explanations attached to a detector are seldom validated, so whether the features an explanation highlights are the ones the detector truly relies on, its faithfulness, remains untested [5,6,7]. Third, methods that decide which alerts to handle automatically and which to escalate threshold a single confidence score, which is poorly calibrated in exactly the attack types where the detector is weakest, so whether per-attack-type reliability offers a sounder basis for that decision than confidence is an open question [8,9,21,22].

At present, no work establishes, for network intrusion detection, whether reliability can be characterized per attack type and shown to transfer, whether the accompanying explanations are faithful, and whether reliability provides a better basis than confidence for deciding what to automate or escalate. This gap leaves a security analyst without an objective, per-attack-type account of how far a detector can be trusted or of what an uncertain alert most likely is.

To answer these three questions, we pursue three empirical objectives, which map directly to this paper’s results and contributions:

1.

estimate, for each attack type, how far a detector’s prediction can be trusted, show that this estimate is stable across training runs and transfers from validation to unseen test data, and identify the attack each type is most often confused with (its twin);

2.

explain why the detector chose one attack type over its most likely alternative, and test empirically that the explanation is faithful, that is, that the features it highlights are the ones the detector truly relies on;

3.

route each alert by its attack-type reliability, rather than by a confidence score, into automatic handling, analyst assistance, or escalation; measure the escalation rate, the share of the detector’s errors it catches, and how this reliability-based routing compares with confidence-based routing; estimate the resulting cost with a standard cost model under illustrative parameters; and produce, for each escalated alert, a compact card designed to support the analyst’s decision.

Establishing these three points makes it possible to triage alerts by reliability rather than by confidence, and to give an analyst a per-attack-type account of a detector’s behaviour. We therefore propose a confusion-aware triage framework as a way to put these findings to use. The framework wraps any trained multiclass detector and turns its predictions into a per-attack-type reliability profile, an evidence profile of per-attack-type and per-alert explanations, and a triage policy. Its reliability profile and triage policy read only the detector’s predicted labels on a held-out validation fold, not its internal probabilities, so they apply to any classifier; the evidence profile requires feature-level access to the detector and is instantiated here with tree-based SHAP. The framework has three parts (Figure 1):

• a reliability profile, recording for each predicted class how often it is correct and what the alert most likely is when it is not (Section 4.2);
• an evidence profile, explaining why the detector chose one class over its nearest competitor and which feature groups genuinely support each class (Section 4.3);
• a triage policy, which uses the reliability profile to send each alert to automatic handling, analyst assistance, or escalation, and presents the evidence profile with the alerts it escalates (Section 4.4).

The framework is a proposed decision aid. Its components, the reliability profile, the evidence profile, and the triage policy, are evaluated empirically in this paper, but the framework’s usefulness to a working analyst has not been validated with human experts, which we leave to future work. Extending the evidence profile to non-tree detectors, using model-agnostic or deep-model SHAP variants, is likewise left to future work.

The next section describes the method used to establish each of these components.

4. Method

The method builds the proposed framework (Section 3) from a trained machine learning-based detector, in four parts: intrusion detection (Section 4.1), the reliability profile (Section 4.2), the evidence profile (Section 4.3), and the triage policy (Section 4.4).

4.1. Intrusion Detection

We treat intrusion detection as a multiclass classification problem. Each network flow is labelled as normal or as one of several attack types, and a trained detector assigns every flow a single predicted label. The framework does not depend on how this detector is built. We evaluate six detector families that span the common design choices: a rule-based baseline, a random forest [39], a support vector machine (SVM) [36], gradient-boosted trees (XGBoost) [37], a one-dimensional convolutional neural network (1D-CNN), and a long short-term memory (LSTM) network [38], with their training and hyperparameters given in Section 5. Each detector is trained and evaluated on a single stratified train, validation, and test split repeated over five random seeds, rather than by k-fold cross-validation: the validation fold is used for all tuning, early stopping, and model selection, and the test fold is scored once, after the configuration is frozen. All that the rest of this section requires is the detector’s predicted labels on a held-out validation fold, together with the ground-truth labels of that fold. Writing pred for the predicted class and true for the ground-truth class over the set of C classes (the attack types together with normal traffic), the detector’s behaviour on the validation fold is summarized by its confusion matrix, which the following subsections turn into a reliability profile (Section 4.2), an evidence profile (Section 4.3), and a triage policy (Section 4.4). All of these quantities are estimated on the validation fold, frozen, and then applied unchanged to the test fold, so no test label is used to build them.

4.2. Reliability for Each Attack Type

From the detector introduced in Section 4.1, the reliability of a predicted attack type c is the precision of the detector’s prediction,

$$\pi \left(c\right)=Pr(\mathrm{true}=c\mid \mathrm{pred}=c),$$

(1)

the diagonal of the detector’s confusion matrix once each row (indexed by the predicted attack type) is normalized to sum to one. The full row, the empirical posterior $Pr(\mathrm{true}\mid \mathrm{pred}=c)$, gives the distribution over what an alert labelled c actually is. It is counted from the validation fold, averaged over the five seeds, and each row sums to one over the C classes.

For each predicted class c we define its twint as the most likely true class other than c,

$$t=twin\left(c\right)=\underset{c^{\prime }\ne c}{arg\; max}Pr(\mathrm{true}=c^{\prime }\mid \mathrm{pred}=c),$$

(2)

read from the empirical posterior. The twin names the attack a prediction is most often confused with.

Because the reliability profile is estimated on validation and applied to test, we verify that it transfers. For each predicted class c we measure the total variation distance (TVD) between its validation and test posteriors,

$$\mathrm{TVD}\left(c\right)=\frac{1}{2}\sum _{c^{\prime }}|P_{\mathrm{val}}(c^{\prime }\mid c)-P_{\mathrm{test}}(c^{\prime }\mid c)|,$$

(3)

where 0 means the two folds agree exactly. A small TVD for every class indicates that a reliability profile built on validation still holds on unseen test traffic.

4.3. Validated Explanations

The reliability profile shows how often each prediction is correct; the evidence profile explains why. The tests in this subsection build it: they explain each decision, verify that the highlighted features are the ones the detector truly relies on, and flag feature groups that mislead.

Contrastive attribution.

For every attack type the routing policy (Section 4.4) does not fully automate, we explain why the detector chose the predicted class c over its twin t. Reliability and routing read only predicted labels and so apply to any detector; the contrastive explanation, by contrast, uses the tree-based detector, for which SHAP [15] attributes each class’s raw margin to the input features. The margin separating c and t is $m_c-m_t$, so the contribution of feature j to that decision is the contrastive attribution

$${\varphi }_j\left(c\right)-{\varphi }_j\left(t\right),$$

(4)

positive when feature j supports c, and negative when it supports the twin. Summed over features, these contributions additively decompose the margin $m_c-m_t$ the detector used, up to the classes’ base values, so the explanation is a decomposition of the decision rather than an approximation. We aggregate the per-feature contributions into semantic feature groups (Section 5.4) for readability.

Faithfulness test.

An attribution is useful only if the features it highlights are the ones the detector actually relies on. We test this with a non-circular feature-deletion protocol [41,42]: we rank features by their contrastive attribution on the validation fold, then, on the held-out test fold, permute the top $k=10$ ranked features and measure how far the c-versus-t margin collapses, comparing against permuting k random features as a control. Unlike remove-and-retrain benchmarks [43], we do not retrain after deletion, since our aim is the reliance of the fixed detector, not whether the information is available elsewhere. Ranking on one fold and testing on another avoids a test that would merely re-measure its own ranking. An explanation passes for a class when the top-k deletion collapses the margin by at least twice the random baseline, and we report the number of the five seeds in which it passes.

Importance versus usefulness.

Attribution explains a detector’s output; it does not reveal whether a feature helps its performance. To separate the two, we also compute the signed permutation importance [39,40] of each feature group g for each class c,

$$I(c,g)=F_1^{\left(c\right)}\left(\mathrm{intact}\right)-\mathbb{E}\left[F_1^{\left(c\right)}\left(\mathrm{group}g\mathrm{permuted}\right)\right],$$

(5)

measured on the test fold and averaged over seeds. A positive value means the class relies on the group; a negative value means the group is detrimental, its removal improves the class’s $F_1$. Comparing the sign of $I(c,g)$ with the (unsigned) global SHAP magnitude of the same group reveals cases where a feature the detector treats as important actually degrades its accuracy for a class.

4.4. Reliability-Driven Triage

The triage policy turns the reliability profile into an action for each alert, and attaches the evidence profile to the alerts it escalates.

Routing policy.

In the manner of selective classification and learning to defer [21,22], the reliability of each predicted attack type determines how its alerts are handled. With two thresholds ${\tau }_{\mathrm{lo}}$ and ${\tau }_{\mathrm{hi}}$,

$$action\left(c\right)=\left\{\begin{array}{cc}automate\hfill & \pi \left(c\right)\ge {\tau }_{\mathrm{hi}},\hfill \\ assist\hfill & {\tau }_{\mathrm{lo}}\le \pi \left(c\right)<{\tau }_{\mathrm{hi}},\hfill \\ escalate\hfill & \pi \left(c\right)<{\tau }_{\mathrm{lo}}.\hfill \end{array}\right.$$

(6)

Reliable classes are handled automatically, assisted classes are automated but carry an explanation, and unreliable classes are escalated to an analyst. We use ${\tau }_{\mathrm{lo}}=0.70$ and ${\tau }_{\mathrm{hi}}=0.95$ unless stated otherwise. Because $\pi \left(c\right)$ is estimated on validation, the routing decision is fixed before any test alert is seen; for error-coverage and operational metrics, assisted alerts count as automated. As a baseline, we compare this reliability-based routing against confidence-based routing, which applies the same three-way rule to the detector’s per-alert confidence (its maximum predicted probability) in place of the attack-type reliability $\pi \left(c\right)$.

Cost model.

To weigh analyst effort against missed attacks, we adopt the established intrusion-detection cost model [32,33,34], in which each outcome carries a cost. For N test alerts split into an automated set $\mathcal{A}$ and an escalated set $\mathcal{E}$, the mean cost per alert is

$$C={\displaystyle \frac{1}{N}}\left(\sum _{i\in \mathcal{A}}{\ell }_i+\left|\mathcal{E}\right|c_{\mathrm{rev}}\right),{\ell }_i=\left\{\begin{array}{cc}0\hfill & \mathrm{correct},\hfill \\ c_{\mathrm{fp}}\hfill & \mathrm{normal}\mathrm{flagged}\mathrm{as}\mathrm{attack},\hfill \\ c_{\mathrm{mis}}\hfill & \mathrm{attack}\mathrm{labelled}\mathrm{as}\mathrm{the}\mathrm{wrong}\mathrm{attack},\hfill \\ c_{\mathrm{fn}}\hfill & \mathrm{attack}\mathrm{labelled}\mathrm{as}\mathrm{normal},\hfill \end{array}\right.$$

(7)

where each escalated alert costs $c_{\mathrm{rev}}$ of analyst review time and is assumed resolved correctly. We use the illustrative weights $c_{\mathrm{rev}}=1$, $c_{\mathrm{fp}}=2$, $c_{\mathrm{mis}}=5$, $c_{\mathrm{fn}}=20$, which order the outcomes so that a missed attack is the most expensive, and we report the sensitivity of the result to the missed-attack cost $c_{\mathrm{fn}}$. The cost saving of a policy is the reduction in mean cost per alert relative to automating every alert.

Triage card.

The framework presents its decision for each predicted class as a compact triage card containing the assigned action, the class’s reliability, the empirical posterior over what the alert most likely is, the contrastive evidence that drove the prediction over its twin, the evidence arguing back for the twin, and any feature group found to be detrimental for the class. Fully automated classes are shown without explanation.

The next section specifies the datasets, detectors, and evaluation protocol used to compute and test all of the quantities defined above.

5. Experimental Settings

The method above rests on concrete choices of data, detectors, and evaluation protocol, specified in the following subsections.

5.1. Datasets

We evaluate on two public benchmarks. UNSW-NB15 [27,28] is our primary dataset: it labels each network flow as normal or as one of nine attack types (Analysis, Backdoor, DoS, Exploits, Fuzzers, Generic, Reconnaissance, Shellcode, and Worms), giving ten classes in all. We pool the two partitioned files, remove the row-identifier column, and drop exact duplicates ($94,928$ of $257,673$ pooled rows, $36.8\%$), which leaves $162,745$ unique records. The result is severely imbalanced: the normal class ($85,722$ records) outnumbers the rarest attack, Worms (171 records), by roughly 500 to 1, which is precisely the regime in which per-attack-type reliability matters. CIC-IDS2017 [29] is our second benchmark, built from an explicit set of dataset-quality criteria. It comprises roughly $2.8$ million flows from eight capture sessions, described by 77 CICFlowMeter features, whose labels we harmonize into nine classes (normal traffic plus DoS, DDoS, PortScan, BruteForce, WebAttack, Bot, Infiltration, and Heartbleed). We apply the same leakage guards as for UNSW-NB15, dropping socket identifiers and, by default, the destination port, whose service identity would otherwise let a model separate several attacks almost trivially, and take a stratified subsample of $403,913$ records (a $400,000$ cap with the rarest classes kept whole, e.g. Heartbleed with about 11). It is therefore severely imbalanced, like UNSW-NB15. On this dataset, recent detectors approach ceiling performance, so it serves as a near-saturated control on which the triage framework should find little to escalate.

5.2. Preprocessing and Validation

We use a single stratified $70/15/15$ train/validation/test split on each dataset’s class label, produced once and reused by every experiment. Every step that learns a value, the one-hot encoding vocabulary, the standardization statistics, and the imputation medians, is fitted on the training fold only and applied unchanged to validation and test; this train-only fitting is the safeguard against leakage. Categorical fields (protocol, service, state) are one-hot encoded with rare values bucketed; tree models use the features unscaled, while neural models are z-score standardized. Recurrent models additionally receive fixed-length sliding windows of consecutive flows. Class imbalance is handled with inverse-frequency class weights during training; any resampling is applied to the training fold only, so validation and test keep their natural class distribution.

5.3. Detectors and Training

The six detectors introduced in Section 4.1 are tuned against validation macro-F1: by grid search for the tree and SVM models, and by Bayesian optimization (Optuna with a tree-structured Parzen estimator sampler) for XGBoost (50 trials) and the neural models (30 trials each). The SVM uses a radial basis function (RBF) kernel. The search runs on a single seed, and the chosen configuration is then evaluated across all five seeds. Because the RBF-SVM does not scale to the full training pool, it is fitted on a stratified subsample of $30,000$ training records, with validation and test kept complete.

5.4. Feature Selection and Feature Groups

We reduce the feature set with a recursive feature-addition (RFA) selector, in the spirit of Hamed, Dara, and Kremer [30]: features are added one at a time, each kept when it improves validation macro-F1, and the process stops when further additions yield less than $0.001$ gain over a short patience window. This selects a compact set of fourteen features (RFA-14), which we use for the reliability and triage analysis. For the explanation analysis (Section 4.3), the UNSW-NB15 features are aggregated into five semantic groups: basic flow, content, timing, general-purpose, and connection-tracking, following the dataset’s feature taxonomy [27,31]. The 77 CIC-IDS2017 features map to the same groups, except that CICFlowMeter provides no connection-tracking features (host and service history), a difference that bears on the cross-dataset explanation analysis.

5.5. Evaluation Protocol

Only the validation set is used for tuning, early stopping, and model selection; the test set is evaluated exactly once per model, after all hyperparameters are frozen. Every model is trained with five seeds, and we report the mean and standard deviation across seeds. The reliability-based and confidence-based routing policies are compared with a paired Wilcoxon signed-rank test over the five seeds, with Holm–Bonferroni correction where several comparisons are made, following the protocol recommended for comparing classifiers [35]. We report accuracy together with macro-averaged precision, recall, and F1. Macro-F1 is the primary metric, since it weights every class equally, whereas accuracy, dominated by the common classes, can reward a detector that neglects the rarest attacks.

The next section presents the results obtained under this protocol, organized around the three objectives set out in Section 3.

6. Results

We report results on UNSW-NB15, our primary benchmark, and use CIC-IDS2017 as a near-saturated control (Section 5). Detection performance is reported first, then the three objectives, reliability, explanations, and triage, in turn. Unless stated otherwise, per-attack-type quantities are for the primary detector, XGBoost, and are averaged over the five seeds.

6.1. Detection Performance

All six detectors were trained and evaluated under the protocol of Section 5. Table 1 reports accuracy, macro-precision, macro-recall, and macro-F1 as mean and standard deviation over the five seeds, on both datasets. Macro-F1 is our primary metric.

On UNSW-NB15, XGBoost attains the highest macro-F1 (0.611), ahead of the random forest (0.534), with the LSTM (0.425), SVM (0.389), 1D-CNN (0.386), and rule-based baseline (0.360) lower; we carry XGBoost forward as the primary detector. Accuracy on its own would mislead here: the random forest scores marginally higher accuracy (0.808) than XGBoost (0.800), yet a markedly lower macro-F1 (0.534 against 0.611), because accuracy is dominated by the common classes and rewards a detector that neglects the rare attacks. This is why macro-F1, not accuracy, is the headline metric.

On CIC-IDS2017, the tree detectors are near ceiling (XGBoost macro-F1 0.970, random forest 0.965, both above 0.99 accuracy), which confirms CIC-IDS2017 as a near-saturated control: there is little per-attack-type unreliability to triage, which we return to in the triage results below.

The aggregate hides a wide spread across attack types. For XGBoost on UNSW-NB15, per-class F1 ranges from 0.10 on Analysis and 0.13 on Backdoor to 0.92 on Generic and 0.90 on Normal (Figure 2), and the same rare attacks are the hardest for every detector. A single macro-F1 therefore says little about how far an individual prediction can be trusted, which is what the next subsection quantifies.

6.2. Reliability for Each Attack Type

Reliability varies by attack type.

The reliability $\pi \left(c\right)$, the precision of a prediction, varies enormously across attack types (Table 2). A prediction of Generic or Normal is correct about $95\%$ and $96\%$ of the time, but a prediction of Analysis or Backdoor is correct only $8\%$ and $9\%$ of the time; DoS ($42\%$), Shellcode ($56\%$), Fuzzers ($58\%$), and Worms ($63\%$) lie in between, while Reconnaissance ($81\%$) and Exploits ($87\%$) are fairly reliable. The detector’s alerts are thus trustworthy for some attack types and almost meaningless for others, a distinction invisible in the macro-F1 of Section 6.1. These reliabilities are stable across training runs: the standard deviation of $\pi \left(c\right)$ is at most 0.006 for every attack type but the rarest, Worms (0.025).

Confidence is not reliability.

The detector’s own confidence does not reveal this. For the least reliable types, the mean predicted confidence far exceeds the reliability: Analysis is predicted with mean confidence 0.51 against a reliability of 0.08, Backdoor with 0.53 against 0.09, and Worms with 0.93 against 0.63 (Table 2, Figure 3). Only for the well-populated types (Normal, Exploits, Generic) does confidence track reliability. Thresholding a confidence score, as selective-classification baselines do, would therefore automate exactly the rare attacks the detector is least able to call.

Reliability transfers to unseen traffic.

The reliability profile is estimated on validation, and it transfers to the held-out test fold. The total variation distance between the validation and test posteriors is below 0.1 for every attack type (Table 2), with a mean of 0.032 and a support-weighted mean of 0.011; the largest gaps are for the two rarest routed types, Shellcode (0.072) and Worms (0.062). A reliability profile built on validation therefore still holds on unseen traffic.

Each attack type has a stable twin.

Each attack type has a consistent twin, the attack type a prediction is most often confused with. The twins are identical across all five seeds for the eight routed types: Analysis and Backdoor are mutual twins, and both DoS and Worms have Exploits as their twin (Figure 4). These twins are what the next section explains and what the triage card surfaces.

6.3. Validated Explanations

The contrastive attribution decomposes the decision.

For each routed attack type, the group-level contrastive attributions sum to the decision margin, up to the classes’ base values. For a prediction of Analysis over its twin Backdoor, for instance, the five group attributions sum to 2.30 against a measured margin of 2.26 (Figure 5), so the explanation accounts for the decision rather than approximating it.

The explanations are faithful.

The explanation passes the feature-deletion faithfulness test for seven of the eight routed attack types in all five seeds (Table 3): deleting the ten features the attribution ranks highest collapses the margin far more than deleting ten random features, by 13× (DoS) to 45× (Reconnaissance), and for Exploits, random deletion did not reduce the margin at all. Backdoor is the exception, where the top-ten deletion collapses the margin only about three times the random baseline and the test passes in three of the five seeds.

Importance is not usefulness.

The features the detector relies on most are not always the ones that improve its detection performance. Connection-tracking is the second most important feature group by global SHAP magnitude (mean $\left|\mathrm{SHAP}\right|$ 14.5, behind basic-flow at 48.6), so the detector leans on it; yet permuting it improves the F1 of Analysis ($I(c,g)=-0.196$) and Backdoor ($-0.105$), meaning the group is detrimental for exactly the two least reliable attack types (Figure 6). On CIC-IDS2017, where the same detector is reliable throughout, this disagreement does not recur.

6.4. Reliability-Driven Triage

Routing catches most errors at a modest escalation rate.

At the operating thresholds ${\tau }_{\mathrm{lo}}=0.70$ and ${\tau }_{\mathrm{hi}}=0.95$, the policy escalates $27.9\pm 0.1\%$ of alerts and catches $75.7\pm 0.2\%$ of the detector’s errors, a 47.8-point improvement over escalating the same fraction of alerts at random (Figure 7); the alerts it handles automatically carry a $6.8\%$ error rate. The pattern holds across all six detectors (Figure A1): the escalation rate tracks unreliability, from $17.9\%$ for the random forest to $53.5\%$ for the rule-based baseline, and each detector’s policy catches far more errors than random escalation of the same size.

Reliability is a sounder basis than confidence, though not a higher-coverage one.

Routing by reliability is not more accurate than routing by confidence. At the same $27.9\%$ workload, confidence-based routing catches $76.4\%$ of the errors against $75.7\%$ for reliability-based routing, a gap of under one point that is not statistically significant (paired Wilcoxon signed-rank over the five seeds, p=0.0625). The value of the reliability basis is not higher coverage but that it is defined per attack type and is calibrated, whereas the confidence score is not (Section 6.2). The reliability policy is therefore interpretable and auditable at the level of attack types, and it routes on the same quantity, $\pi \left(c\right)$, that the analyst is shown.

The policy lowers cost under illustrative weights.

Under the illustrative cost weights of Section 4.4, and at each detector’s cost-optimal threshold, the triage policy reduces the mean cost per alert relative to automating every alert by $26.7\%$ for XGBoost to $62.3\%$ for the rule-based baseline (Figure A2), and the saving stays positive across missed-attack cost ratios from 2 to 100. This cost-optimal threshold is a different operating point from the fixed ${\tau }_{\mathrm{lo}}=0.70$ used for the coverage results above (for XGBoost it escalates $13.9\%$ rather than $27.9\%$), and we keep the two separate.

The framework abstains on the near-saturated control.

On CIC-IDS2017, where the tree detectors are already reliable for every attack type (Section 6.1), the policy escalates nothing: both XGBoost and the random forest escalate $0.0\%$ of alerts (Figure 8). The framework thus abstains where there is no confusion to triage, and only the weaker CIC detectors, which retain some unreliable classes, escalate at all.

The triage card.

For each escalated alert, the framework assembles the computed quantities, the assigned action, the attack-type reliability, the posterior over the true attack type, the contrastive evidence for the prediction over its twin, and any detrimental feature group, into a compact triage card (Figure 9). The card is a proposed decision aid: we report the information it would present, and its usefulness to a working analyst is left to future evaluation.

7. Discussion

The results show that a detector’s aggregate score, even a macro-F1, says little about how far any single prediction can be trusted: on UNSW-NB15 the primary detector’s per-attack-type reliability ranges from almost worthless to almost certain (Section 6.2). The three findings that follow each answer one of the questions left open by the literature (Section 3), and together they turn a detector’s predictions into a per-attack-type account that an analyst can act on. We discuss each in turn, and then the limits of what has been shown.

7.1. Reliability for Each Attack Type

The reliability profile addresses the first gap, that detection is reported in aggregate and hides where a detector is untrustworthy. It shows that a detector’s confidence is not its reliability: on the rarest attacks the detector is both least reliable and most overconfident, so a confidence threshold, the basis of most selective-classification and learning-to-defer methods [21,22], would automate precisely the alerts that most need a human. Because the profile is estimated from predicted labels alone, stays stable across training runs, and transfers from validation to unseen traffic, it is usable in deployment rather than only in hindsight. It gives an analyst what a single score cannot: a calibrated, per-attack-type estimate of trust, together with the attack that a prediction is most likely confused with.

7.2. Validated Explanations

The evidence profile addresses the second gap, that explanations of intrusion-detection decisions are seldom checked. Two findings matter. First, the explanations are faithful for almost every routed attack type; faithfulness is rarely tested, and where it is, attribution methods often fall short [5,7]. The one exception, Backdoor, is also among the least reliably detected attack types, so the detector is hardest to explain exactly where it is hardest to trust. Second, the features a detector weights most heavily are not always the ones that strengthen its predictions: a feature group ranked important by SHAP can degrade an attack type’s F1. This separates two questions that explainability usually conflates, why the model decided and whether the decision is well founded, and it gives the analyst a signal of where the detector is being misled rather than informed.

7.3. Reliability-Driven Triage

The triage policy addresses the third gap, that alert-handling decisions rest on a single, poorly calibrated confidence score. Routing by attack-type reliability catches most of the detector’s errors at a modest escalation rate and, on the near-saturated control, escalates almost nothing, so the framework spends analyst attention only where the detector is actually unreliable. Routing by reliability is not, however, more accurate than routing by confidence at the same workload, which is consistent with the softmax confidence being a strong and often hard-to-beat baseline for selective prediction [21], and with a concurrent triage study that likewise reports no gain over a simple selective gate [45]. A small per-attack-type reliability profile matches a per-alert confidence score on error coverage: the same routing quality comes from an object that is calibrated, defined per attack type, and shown to the analyst, so the decision is interpretable and auditable where a raw confidence score is not. Under illustrative cost weights the policy also lowers the expected cost per alert, which suggests, but does not establish, an operational benefit; those figures are model outputs under assumed parameters, not measurements from a live centre.

7.4. Limitations

Several limits bound these claims. The framework is a proposed decision aid: we measure the information it would present to an analyst, not an analyst’s behaviour, and its usefulness in practice must be established in a study with security analysts, which we leave to future work. The cost and workload figures come from established models under illustrative parameters and a sensitivity analysis, not from a deployed system. The contrastive explanation is instantiated with tree-based SHAP on the primary detector; extending it to non-tree detectors with model-agnostic or deep-model variants remains to be done, although the reliability and routing components already apply to any classifier. Finally, the evaluation uses two public benchmarks under a single stratified split repeated over five seeds; wider datasets and live traffic would test how far the profile and the policy generalize.

8. Conclusion

Deciding how far to trust an individual alert is a per-attack-type judgement, and it is one that detection, explanation, and alert triage, pursued largely in isolation, have not equipped an analyst to make. We proposed a confusion-aware triage framework that unifies these three concerns: from a trained detector’s predictions it estimates the reliability of each attack type, validates the explanations of its decisions, and routes each alert by that reliability into automatic handling, analyst assistance, or escalation, presenting each escalated alert as a compact decision card. Evaluating the framework on two benchmarks with six detectors over five seeds, we found that per-attack-type reliability can be estimated, is stable across training runs, and transfers to unseen traffic; that the explanations are faithful for almost every routed attack type, while a feature’s importance to the model is not the same as its usefulness to it; and that routing by reliability catches most of the detector’s errors at a modest escalation rate and abstains where the detector is already reliable. Routing by reliability is not more accurate than routing by confidence at the same workload, but it routes on a calibrated, per-attack-type quantity that an analyst can read and audit, which a confidence score cannot provide. The framework is a proposal rather than a validated system: we measure the information it would present, together with its cost and analyst workload under illustrative models, but not its use by working analysts. Overall, our results indicate that a detector’s per-attack-type reliability can be estimated, validated, and turned into an interpretable triage decision, with the framework’s value to a working analyst left to establish in future work.