DeciFlow: An AI-Powered Real-Time Log Classification Decision Layer for Operations

Operations engineers stare at scrolling log screens, trying to find the few lines among thousands that actually deserve attention—a scenario nearly every SRE has lived through. DeciFlow attempts to change this process with an AI decision layer: not to replace operations staff, but to insert a structured classification step between raw logs and human judgment.

Why Add an AI Decision Layer to Logs

Traditional log platforms are already very mature in collection, indexing, and search. But when actually troubleshooting, the process often degrades into: search, grep, filter, then read events one by one, judge which ones matter based on experience, and finally take action.

In the project description, the DeciFlow author explicitly points out that the core pain point of this model is: too much manual reading, while the proportion of truly noteworthy anomalous events is extremely low.

DeciFlow's approach is to insert a classification layer into this process. Log files first go through DeciFlow, where the Laya or Jev decision engine classifies them into one of five categories—Normal, Warning, Error, Security, or Other—and returns category probabilities and confidence information, based on which operations staff prioritize suspicious or uncertain events.

The author emphasizes that the goal is not to replace operations staff, but to reduce the amount of raw data they need to inspect before deciding "where to look next."

SRE (Site Reliability Engineer) is an operations role originating from Google that emphasizes solving operational problems with software engineering methods, with the core goal of safeguarding system availability, latency, throughput, and other SLO metrics. Log analysis is one of the most time-consuming parts of an SRE's daily work: a medium-sized service can generate several GB to several TB of logs per day, of which the number of lines that truly indicate failures or security incidents is often less than one in ten thousand. This "extremely low signal-to-noise ratio" characteristic is precisely the fundamental reason DeciFlow tries to alleviate with a classification layer—freeing people from reading everything and handling only events marked by AI as suspicious or uncertain.

Confidence is a probability value output by a classification model, indicating how certain the model is about that prediction. For example, DeciFlow returning Security: 0.87 means the model believes the probability that the event belongs to the Security category is about 87%. It is important to note that high confidence does not equal high accuracy—a model may be overconfident about a certain type of event due to training data bias, which is exactly why DeciFlow insists on retaining human review.

Three Input Modes: From Pasting to Real-Time Monitoring

DeciFlow currently supports three log input methods. Paste mode allows directly pasting text for quick testing; Batch mode analyzes existing log files; Realtime mode tracks newly written events, including log rotation scenarios.

Multi-file and wildcard patterns are also supported, meaning logs do not need to be manually merged beforehand.

One noteworthy architectural feature is that DeciFlow nodes can monitor logs locally while sending inference requests to a remote shared Laya server. This means the machine storing the logs does not need a GPU or PyTorch installed, and the inference workload can be centrally deployed.

Dual-Backend Design of the Decision Engine

DeciFlow currently supports two backends. Laya is the default option, supports self-hosting, can run on CPU or CUDA, and offers high deployment flexibility. Jev is an alternative hosted decision API.

Taking Laya as an example, the architecture can have servers A, B, and C each running a DeciFlow instance, all pointing to one shared Laya inference server. This design of separating log processing from model inference is particularly practical for multi-node log monitoring scenarios—there is no need to deploy a complete inference environment on every log-source machine.

Separating the inference server from the application server is a common architectural pattern in ML engineering. Inference refers to the process in which a model performs forward computation on input data and outputs a result; this step usually requires a GPU or substantial CPU resources. Application logic such as log collection, UI display, and Action execution has very low compute requirements. After decoupling the two, the edge node or ordinary server where the logs reside only needs to run a lightweight DeciFlow client and send classification requests over the network to the centrally deployed Laya inference server. This design lowers the deployment threshold and also facilitates unified model upgrades and centralized monitoring of inference performance, at the cost of introducing network latency and dependence on inference server availability.

PyTorch is the mainstream deep learning framework open-sourced by Meta, and decision engines such as Laya are usually implemented based on such frameworks. Installing PyTorch on every log-source machine would significantly increase image size and operational complexity, so remote shared inference becomes the more economical choice.

Human-in-the-Loop: AI Classification Is Not the Final Conclusion

DeciFlow is designed to treat AI classification results as reference rather than truth. The system can flag predictions that require human review, and operations staff can view the original events and record corrections. Results can also be exported as JSON for subsequent processing.

This design choice is worth noting. The author explicitly states that high-confidence predictions can still be wrong, so the workflow must remain human-in-the-loop. In security monitoring and troubleshooting scenarios, the cost of misclassification can be high, and the human review mechanism is a pragmatic complement to AI capabilities.

Human-in-the-Loop (HITL) is a paradigm in AI system design that refers to retaining nodes for human intervention in automated decision-making processes, usually used in high-risk scenarios or when the model is uncertain. The difference between HITL and "fully automatic" is that the classifications, scores, or suggestions output by the system must be confirmed or corrected by humans before they can be turned into final actions, and the corrections can also serve as feedback data for subsequent model iteration. In fields such as security monitoring, medical diagnosis, and troubleshooting, the cost of false positives and false negatives can be far higher than the cost of human review, so HITL is almost standard. DeciFlow allows operations staff to view original events, record corrections, and export JSON, which in effect builds such a feedback loop.

From Classification to Action: Python Actions

Classification itself has value, but operations systems ultimately need to respond to the results. To this end, DeciFlow integrates Python Actions—an Action receives the JSON data of a successful decision and executes custom Python code.

For example, when the decision result is Security, it can trigger send_to_security_pipeline(result) to send the event to a security pipeline. Actions can also integrate with HTTP APIs, message brokers, databases, or notification systems.

These Actions have independent Python environments and dependency management and are positioned as lightweight—they do not attempt to replace persistent workflow systems or message queues, but instead serve as a bridge between AI decisions and operational actions.

Current Boundaries and Future Directions

DeciFlow currently uses only the choice decision type, that is, selecting one from preset categories. The complete workflow chain is: event -> select category -> return probability and confidence -> review or action.

The author reveals plans to add a score type for evaluation and scoring in the future, as well as a noul type for yes/no probability judgment (such as pass/fail quality checks). These expansion directions suggest the architectural intent of DeciFlow's generality—not limited to log classification, but also applicable to manufacturing quality inspection, risk assessment, event routing, operations telemetry, and other scenarios.

In the project description, the author writes that what truly interests him is not "AI for logs" itself, but placing a small, structured decision layer between input data and action systems. If this idea holds, DeciFlow is only one implementation of it, not the endpoint.

choice / score / noul are abstract divisions of output types in the decision engine. choice requires the model to select a unique answer from a set of preset categories, suitable for scenarios such as log classification and event routing; score outputs a continuous numerical value, suitable for tasks requiring quantified degrees such as quality scoring and risk assessment; noul (which can be understood as yes/no or pass/fail) outputs a binary probability, suitable for binary classification decisions such as quality checks and permission judgments. Abstracting these three types of decisions into a unified interface means that DeciFlow's Action layer and human-in-the-loop mechanism can reuse the same workflow, requiring only replacement of the underlying decision type. This is also why the author believes the architecture can go beyond log classification and extend to manufacturing quality inspection and event routing.

Deployment and Getting Started

DeciFlow uses containerized deployment, and the repository includes Docker instructions for the DeciFlow UI and Laya inference server. The typical process is to clone the repository, copy the environment variable file, start the Laya server, configure the engine endpoint in .env, and then start DeciFlow. The browser interface runs on port 4000 by default. The repository also includes sample logs, making it easy to test the classification workflow without connecting to a production system.

One-line Summary

DeciFlow inserts an AI classification layer between raw logs and human judgment, classifying events into five categories with confidence, while retaining human-in-the-loop and Python Actions response mechanisms.

Paragraph Summary

DeciFlow is an AI decision-layer project for operations scenarios. Its goal is not to replace SREs, but to insert a structured classification step between raw logs and human judgment. Logs are processed by the Laya or Jev decision engine and classified into Normal, Warning, Error, Security, and Other, with probabilities and confidence returned to help operations staff prioritize suspicious events. The system supports three input modes—Paste, Batch, and Realtime—as well as multi-file and wildcard patterns. Architecturally, log-source machines can run only a lightweight client and send inference requests to a remote shared Laya server, without needing a GPU or PyTorch. DeciFlow emphasizes that AI classification is reference rather than truth, retains human review and correction mechanisms, and connects decision results to security pipelines, HTTP APIs, or messaging systems through Python Actions. It currently supports only choice decisions, with plans to expand to score and noul types.