The limits of logs and alerts: judgment that stops at inference
Most security operations today run on logs and alerts. Logs, alerts, and events are all state information: a record that something happened at a particular moment. The problem is judgment. Logs and alerts alone do not confirm whether an event was a real threat, which path it followed, or how far the damage spread. Analysts and AI alike fall back on inference. Judgment built on inference inflates the false-positive workload, and the extra investigation it demands delays the response to real threats.
AI-driven security operations run on the same structure. No matter how refined the model is, any judgment is on shaky ground when the input data stops at logs and alerts. What is needed is context data that grounds AI judgment in actual activity and clear evidence instead of inference.
The reliability of AI-based security analysis and verdicts depends less on the model itself than on the context data that supplies evidence of actual activity and the grounds for judgment. This article starts with the limits of log- and alert-centered analysis. It then follows the data flow through the raw transaction/session, behavioral baseline, and explainability layers: what each contributes, and how they combine to make AI analysis and verdicts more reliable.
The cause logs and alerts cannot explain
Security information and event management (SIEM) is a platform that collects logs and events from the security appliances and systems across an organization, correlates them, and detects threats. The definition itself has an inherent limitation. The logs and events a SIEM collects show that something happened at a particular moment. On their own, they rarely explain the actual contents of the communication, the sequence of the attacker’s actions, or how far the damage spread.
This is where the problems begin once an analyst picks up the event. A single alert sends the analyst through firewall logs, IDS and IPS events, endpoint records, and other security appliances, one after another, to find the cause. Each system stores data in its own format, so stitching together the pieces that belong to one threat takes time, and by then the attacker may already have moved to the next stage.
Conventional security appliances record only the events that match a predefined scenario or detection rule. An unknown attack pattern, or insider activity that abuses legitimate protocols, may generate no log at all. After the fact, it is far harder to establish whether such activity occurred and how it unfolded. The events that do get recorded raise the opposite problem: they carry only limited information. Judging a threat on that basis inflates false positives, and analysts come to rely on additional manual investigation to confirm whether a threat is real. Without raw packet or session data on hand, verifying the actual activity and the attack path is harder still.
Log-centered analysis stops at recording what happened. For security AI to judge the cause and the impact of a threat, it needs a different kind of data, one that explains why the event happened.
What context data is: an overview of the three-layer structure
Context data gives AI-based security analysis and verdicts three things: evidence of actual activity, a reference for telling normal from abnormal, and a way to verify the grounds for a judgment. Logs show that an event occurred. Context data shows what activity actually took place, how far it departed from the normal range, and on what basis it can be judged a threat.
Quad Miners builds context data from full-packet collection and structures it in three layers: Raw Transaction/Session, Behavioral Baseline, and Explainability (XAI). The layers supply, respectively, evidence of actual activity, the degree of deviation from the normal range, and the basis for verifying an AI judgment. Each one raises the reliability of analysis and verdicts.
Each of the three layers plays an independent role, and together they form one data flow. The output of one layer forms the basis for the next layer’s judgment, so the more of these layers an organization captures together, the more accurate and reliable the verdict becomes.
Raw transaction/session data: evidence of actual activity
Logs record what happened. Raw transaction/session data provides evidence of how it unfolded. The difference becomes clear once a real threat is under investigation. Logs may show a large transfer from a specific IP, but only raw packets and sessions reveal the file, path, and destination.
This layer collects network traffic as full packets and reconstructs sessions, files, email, and content at L7, which yields definitive evidence of the activity that actually took place. It goes beyond recording traffic volume and connection details: it restores the files and the content itself that moved in the actual communication. An analyst can therefore confirm against the original data what actually moved at the moment of a suspicious event.
The Rebuild capability, or retrospective re-analysis of stored traffic, is also an important function of this layer. When a new indicator of compromise (IOC) emerges, re-analyzing stored packets and sessions can later confirm whether the threat was already active on the internal network. Evidence at the packet capture (PCAP) level provides the basis for reconstructing the attack path in incident response and forensic analysis. However, the amount of full-packet data retained and the retention period can vary with the deployment environment and system specifications, so the design should be based on the actual operating environment.
Behavioral baseline data: a benchmark for deviation from the norm
The behavioral baseline learns the normal communication pattern for each asset and each user, and it serves as the reference for judging whether activity has deviated and by how much. What sets it apart from fixed detection rules is that it catches activity that departs from the normal state even when no attack pattern has been defined in advance.
The layer identifies who each user and asset communicates with, and the network segments between them. It then judges the normal range and the degree of deviation against behavior patterns accumulated over time: traffic volume, connection times, protocols in use, session counts, and similar features. Consider a server that normally makes only small outbound connections during business hours. If it starts sending large volumes of data out in the early morning hours, rule-based detection may let it pass, but the behavioral baseline flags it as a deviation. The gap widens with threats that detection rules alone struggle to identify, such as anomalous insider activity and attacks that abuse legitimate protocols.
Behavioral baseline data compares current activity with the normal pattern learned over time and supplies the degree of deviation as evidence the AI can analyze and rule on. Once that deviation is quantified, AI moves beyond a binary normal-or-abnormal call to a finer judgment of how anomalous the activity is and how likely it is to be a threat. Used together with raw transaction/session data, it links actual activity to the degree of anomaly, and the verdict becomes more reliable still.
Explainability (XAI) data: the grounds for verifying an AI judgment
Explainability data is the context data that carries the detection and verdict grounds used to decide whether something is a threat. It also carries the key data that influenced the AI judgment and how much each feature contributed. With it, an analyst can verify whether a threat verdict is sound.
When the contribution of each feature to a threat verdict is visible, an analyst can tell whether the judgment rests on real threat evidence or on noise in the data. A detection result delivered without explanatory grounds makes that verification impossible, and the burden of handling false positives and validating the AI stays with the analyst.
Why context data sets the quality of AI security analysis
Input data quality matters as much as model performance for the accuracy of a security AI judgment. If only logs and summaries are fed into the model, false positives and hallucinations can recur in AI analysis as well. Logs and alerts alone rarely reveal the context of an attack, and a judgment made without context is a judgment short on grounds.
Three-layer context data — Raw Transaction/Session, Behavioral Baseline, and Explainability (XAI) — is the foundation for advancing AI analysis and security observability. What matters is whether data is fed into the AI in a form it can use as grounds for judgment. When the raw layer confirms the actual activity, the behavioral baseline puts a number on the direction and size of the deviation, and explainability makes the decision process traceable, the AI’s output becomes a verifiable judgment. It is no longer a suggestion an analyst must re-investigate every time.
An autonomous security operations platform that links detection, analysis, judgment, and response on one shared context runs on this same context data. Quad Miners’ differentiator is not an added AI feature, but a data architecture that can provide raw, behavioral, and explanatory data as direct input to AI analysis. Its real strength lies not in a better AI model, but in access to complete context data.
Context data brings four kinds of value to security AI analysis.
- More accurate judgment: raw transaction/session data and behavioral baseline data raise the quality of the input to AI analysis, which reduces false positives.
- Verifiability: explainability data lets an analyst check and verify the grounds and the process behind an AI judgment directly.
- Retrospective re-analysis of past traffic: applying a new IOC to stored raw packets and sessions surfaces dormant threats.
- Evidence preservation: raw data at the PCAP level serves as the technical grounds for incident response and forensic analysis.
The goal of this architecture is clear: closed-loop automation that runs from detection through analysis and judgment to response, or autonomous security operations. An operating model in which AI judges and responds on its own works only on trustworthy grounds for judgment, and three-layer context data supplies them.
A data architecture checklist to run before adopting security AI
When organizations evaluate AI-driven security operations, network detection and response (NDR), or SIEM platforms, feature checklists alone do not tell the whole story. The usual selection criteria still apply: compliance requirements, threat intelligence feed integration, machine-learning-based detection, and integration with security orchestration, automation, and response (SOAR). Compliance alone spans Korea’s Personal Information Protection Act, Japan’s Act on the Protection of Personal Information, HIPAA in the United States, the GDPR in the EU, PCI DSS, and others. One more criterion belongs beside them, from the data architecture side: how the organization obtains the data that forms the basis for judgment.
The checklist below maps the key questions from that data architecture perspective to the three layers of context data.
These items are not independent feature checks. They are parts of one connected data flow. Without a raw packet collection structure, the scope of retrospective re-analysis shrinks. Without a behavioral baseline, there is little basis for quantifying deviation. Without explainability, there is little basis for verifying an AI judgment. Confirming at the evaluation stage that these five items connect into a single data flow is the practical starting point for AI-driven security operations.
From collection to autonomous security operations: three products that implement three-layer context data
Three-layer context data is not a conceptual model. It exists only where a structure for collection, storage, and analysis is in place. The three Quad Miners products follow that order: they generate the three layers, connect them to the logs across the organization, and turn them into the basis for AI analysis and verdicts.
- Network Blackbox (NDR), generation: full-packet collection and retention with L7 reconstruction, the stage that produces the three layers of Raw Transaction/Session, Behavioral Baseline, and Explainability (XAI).
- QUADX (Context-Aware Next-Gen SIEM), connection: joins the context data generated there with logs and events across the organization into one flow, which extends the investigation to why an event happened.
- QUADxAI (roadmap), judgment: a context-data-centric, AI-driven security observability platform that uses the three layers as the grounds for AI analysis and verdicts, currently under development.
Attacks are automating at a pace that an operating model built on analysts investigating step by step cannot match. Security operations need to run from detection through analysis and judgment to response on one shared context. That requires AI that can judge on its own, and the grounds for that judgment are three-layer context data, not logs and alerts. Context data is what carries security operations from detection-centered work to autonomous security operations. The path from Network Blackbox through QUADX to QUADxAI is how those grounds have been put in place stage by stage.
Frequently asked questions
Q. What is security AI analysis based on context data?
It is an approach that judges the cause and the impact of a threat based on Raw Transaction/Session, Behavioral Baseline, and Explainability (XAI) data, rather than log and alert summaries. Quad Miners implements this structure through three-layer context data generated from full-packet collection.
Q. Why do security operations need explainability data?
Explainability data lets an analyst see directly the evidence and the process behind an AI threat judgment. Instead of trusting the AI blindly, the analyst verifies the judgment and decides whether to respond. When a detection result arrives without explainable grounds, handling false positives and validating the AI becomes harder, and the analyst’s burden of judgment can grow rather than shrink.
Q. Why should data architecture come first when an organization adopts security AI?
The quality of an AI security judgment is set by the quality and context of the data the model receives, not by the model alone. The review must therefore start with how the organization collects raw packets, learns behavioral baselines, and provides explainability. When the model receives only logs and summaries, false positives and judgment errors can recur in AI analysis as well.
