DeciFlow

English | 한국어

Make fast AI decisions across diverse datasets and automate follow-up workflows your way.

Demo Video - YouTube

Installation and Configuration → INSTALL.md

Choose PyPI: pip or uv tool, Docker Compose with Git Clone, or Direct Processes with Git Clone. The installation guide covers prerequisites, engine connections, storage, authentication, startup, verification, and maintenance for each method.

Overview

DeciFlow turns text logs and structured conversation records into typed AI decisions, keeps the evidence available for human review, and can run Python Actions after classification. It reads local, SSH, and HDFS Sources and displays results in a browser. Existing files can be investigated in Batch mode; Realtime mode follows new log events.

The Laya server runs the decision model on the same host or a separate host. Jev is an alternative paid hosted inference API. DeciFlow reads the data and sends events to the selected engine. Laya is the default, with no automatic fallback to paid Jev. DeciFlow nodes connected to a shared Laya server need no local GPU or PyTorch. OAuth2-Proxy optionally provides Google sign-in and HTTPS.

Concepts

The workflow is Source → Criteria → optional Actions → Task → Results → Review. Batch Tasks run manually or on a schedule. Realtime Tasks monitor new events until stopped. Active runs retain their original settings when definitions are edited. DeciFlow does not create tickets automatically; follow-up behavior belongs to Actions.

Architecture

DeciFlow reads an event, applies the Task's Criteria through Laya or Jev, validates the response, and stores results and Action outcomes in SQLite. Source readers and inference share bounded concurrency. Multiple SSH Hosts produce unified results while retaining per-host collection status. The UI can reconnect to a run without repeating classification; Tasks continue when the browser is closed.

Definitions, run history, original inputs, decisions, and reviews persist in the data store. Checkpointed Batch and Realtime runs can resume after a server restart; paused runs remain paused. Recovery validates that the original files still match. See Task recovery and Result Storage for requirements and limits.

Capabilities

• Flexible decisions: combine category choices, probability-weighted scores, and yes/no probabilities. System profiles cover Normal, Warning, Error, Security, Other, urgency, and work-ticket probability.
• Evidence and review: inspect probabilities, Criteria, raw provider responses, format-validation failures, and human corrections. Export complete or reviewed results as JSON. Certain does not guarantee accuracy.
• Investigation and monitoring: Batch and Realtime Tasks, cron schedules, pause/resume, multi-host inputs, and durable history.
• Result exploration: charts, whole-run filters, cursor pagination, and shareable URLs. Decision filters affect result cards; other filters also update Overview. Display choices do not trigger new inference.
• Measured processing: run-level elapsed time, throughput, and latency percentiles. Filtering and pagination do not change run metrics.
• Controlled automation: Python Actions, recorded execution errors, reusable settings, reference checks, and confirmation for destructive maintenance.
• AI-assisted Criteria: draft or revise profiles with OpenAI after reviewing sample data. Authoring is separate from classification and incurs API charges; see Criteria.

Example Applications

Operational logs are the starting point: access logs, application failures, and system events. Bundled consultation examples also demonstrate decisions about inquiry type, handling status, follow-up ownership, urgency, and follow-up need.

Bundled sample names begin with Sample. The consultation Criteria are Korean; they do not verify current law. Samples demonstrate a workflow, not a measured accuracy guarantee. Traffic analysis, manufacturing decisions, and image inspection would require additional integrations and domain validation; image inspection also requires a vision model.

Limits and Data Handling

• File reads are incremental, but memory use still depends on active files and event size. Automatic multiline event-boundary detection is not implemented.
• Laya and Jev have request budgets and provider-specific limits. Truncated or invalid responses are rejected; inspect result warnings and response details.
• Wildcards select matching files, not just text logs. Binary/compressed files and both active and rotated copies can cause failures or duplicate analysis. Local read/UTF-8 failures stop the run; SSH reader failures are recorded per Source/Host.
• Realtime monitoring waits for complete lines. Rotation leftovers are marked incomplete; rapid rotation and copy-truncate/regrowth can lose events.
• Higher client concurrency does not guarantee greater inference throughput. Engine capacity and admission limits apply.
• Laya receives inputs on your selected server; Jev sends them to TypeSafe and incurs charges. Optional AI authoring sends reviewed samples to OpenAI. Result storage includes original inputs and Action outcomes. Protect data and backups; disk retention is not automatic.

See Sources, Usage, and Configuration for detailed behavior and limits.

Documentation

Laya · Jev