I've been working on DeciFlow, a tool for classifying operational logs in real time with AI-assisted decision models.
Instead of reading every log line manually, DeciFlow tries to answer a simpler first question:
What deserves my attention?
It classifies log events into:
- Normal
- Warning
- Error
- Security
- Other
and returns category probabilities and confidence information so that operators can focus on suspicious or uncertain events first.
call518
/
DeciFlow
AI-powered log decisions with numeric JSON results for automation. Custom criteria, batch and real-time analysis, and Python actions. Powered by Laya or Jev.
DeciFlow
Classify logs in real time with AI and spot error and security events at a glance.
DeciFlow groups log events into chunks and classifies each chunk as Normal, Warning, Error, Security, or Other with Laya or Jev. Scan a batch, follow new events, and focus your review with category probabilities and confidence instead of reading every line unaided Choose a domain profile and chunk size per source; compare category counts in a live chart and pause list updates to inspect individual results.
Currently, DeciFlow uses choice decisions only. Future updates are planned to
add score for evaluation and grading and noul for yes/no probabilities
such as pass/fail quality checks, with criteria and result views tailored to each use case.
DeciFlow runs on the node containing your logs, reads events, and displays results in a browser. The Laya server runs the decision model…
Why I built it
Traditional log platforms are very good at collecting, indexing, and searching logs.
But during an investigation, I still often end up doing something like this:
logs
↓
search / grep / filtering
↓
read many individual events
↓
decide what looks important
↓
take action
I wanted to experiment with inserting an AI-based decision layer into that workflow:
Log files
↓
DeciFlow
↓
Laya or Jev
↓
Normal / Warning / Error / Security / Other
↓
Human review
↓
Optional follow-up action
The goal is not to replace the operator.
The goal is to reduce the amount of raw data an operator has to inspect before deciding where to look next.
Batch analysis and real-time monitoring
DeciFlow currently supports three input modes.
Paste lets you paste text directly for quick testing.
Batch analyzes existing log files.
Realtime follows new events as they are written, including log rotation scenarios.
Multiple files and wildcard patterns can be used, so logs do not have to be manually merged before analysis.
For example, a DeciFlow node can monitor logs locally while sending inference requests to a shared Laya server running somewhere else.
That means the machines containing the logs do not necessarily need their own GPU or PyTorch installation.
The decision engine
DeciFlow can currently use two backends:
Laya is the default option and can be self-hosted.
Jev is an alternative hosted decision API.
With Laya, the architecture can look like this:
Server A ── DeciFlow ─┐
Server B ── DeciFlow ─┼──> Shared Laya Server
Server C ── DeciFlow ─┘
This separation was important to me because log processing and model inference do not always need to run on the same machine.
Laya can also run on CPU or CUDA depending on the deployment environment.
Human review still matters
AI classification is not treated as ground truth.
DeciFlow can identify predictions that need review, and an operator can inspect the original event and record a correction.
Results can also be exported as JSON for further processing.
This was an important design choice: a high-confidence prediction may still be wrong, so the workflow needs to keep a human in the loop.
From classification to action
Classification alone is useful, but operational systems eventually need to do something with the result.
DeciFlow therefore includes Python Actions.
An Action receives a successful decision as JSON and can execute custom Python code.
For example, an Action could eventually be used to:
if result["decision"] == "Security":
send_to_security_pipeline(result)
or integrate with an HTTP API, message broker, database, notification system, or another automation layer.
Actions have independently managed Python environments and dependencies.
They are intentionally lightweight: they are not intended to replace a durable workflow system or message queue, but they provide a bridge between AI decision → operational action.
Current scope
At the moment, DeciFlow primarily uses choice decisions for classification.
The current workflow is therefore:
event
↓
choose one category
↓
return probabilities/confidence
↓
review or action
I'm also interested in extending the same architecture beyond log classification.
Possible future decision types include numerical scoring and yes/no probability decisions, which could make the same approach useful for things such as:
manufacturing inspection
→ pass / fail
risk evaluation
→ score
event triage
→ route to team
operational telemetry
→ normal / abnormal
The interesting part for me is not specifically "AI for logs".
It is the idea of putting a small, structured decision layer between incoming data and the systems that act on it.
Running it
DeciFlow is containerized, and the repository includes Docker instructions for both the DeciFlow UI and Laya inference server.
A typical setup is:
git clone https://github.com/call518/DeciFlow.git
cd DeciFlow
test -f .env || cp .env.example .env
Start the Laya server, configure the engine endpoint in .env, and then start DeciFlow.
The browser UI is available on port 4000 by default.
The repository includes sample logs so the classification workflow can be tested without connecting it to a production system first.
Demo
Here is a short demo of the current UI and workflow:
Feedback
DeciFlow is still evolving, and I'm particularly interested in feedback from people working with:
system operations, observability, log analysis, security monitoring, SRE, and event-driven automation.
I'd be interested to hear where a decision layer like this would — or would not — fit into a real operational workflow.
GitHub:
Top comments (0)