FLUX AI

// OVERVIEW

Flux AI is the fifth application in the Flux Suite, providing NOC intelligence and automation across the entire platform. It operates as a standalone Docker service with its own web interface, API, and database — while maintaining live read access to the data stores of all other Flux apps.

Architecture at a Glance

// INSTALLATION

Quick Start

# Clone and start (Linux/macOS)
git clone https://github.com/your-org/flux-ai.git
cd flux-ai
cp .env.example .env
nano .env          # set passwords, Anthropic API key, Ollama URL
chmod +x start.sh && ./start.sh

# Windows
cp .env.example .env
notepad .env
start.bat

Default Ports

Environment Variables

# Required
ANTHROPIC_API_KEY=sk-ant-...           # Claude API key (for RCA, post-mortems)
OLLAMA_URL=http://ollama:11434         # Ollama endpoint (local LLM)
OLLAMA_MODEL=llama3.1:8b              # Model to use (8b fits on 8GB VRAM)

# Database
POSTGRES_PASSWORD=ChangeMe!
REDIS_PASSWORD=ChangeMe!

# Cross-app integration (read-only DB access)
NOTIFY_DB_URL=postgresql://user:pass@flux-notify-db:5432/notify
MONITOR_DB_URL=postgresql://user:pass@flux-monitor-db:5432/monitor
EVENT_DB_URL=postgresql://user:pass@flux-event-db:5432/event

# Optional
ANTHROPIC_MODEL=claude-sonnet-4-6     # Default Claude model
ANOMALY_LOOKBACK_DAYS=14              # Baseline window
NOISE_SUPPRESSION_ENABLED=true
PREDICTIVE_ALERT_HORIZON_HOURS=4

// AI PROVIDERS

Flux AI uses a dual-provider strategy to balance response speed, cost, and analytical depth. Both providers can be active simultaneously with intelligent routing based on task type.

// PROVIDER ROUTING

The routing engine assigns each task to the optimal AI provider based on complexity, latency requirements, and configured rules.

Custom Routing Rules

Override default routing via the Settings → AI Providers → Routing Rules panel, or via the API:

POST /api/ai/routing/rules
{
  "task": "triage",
  "provider": "claude",
  "condition": "severity == P1",
  "reason": "P1 incidents always use Claude for higher accuracy"
}

// AUTO-TRIAGE ENGINE

The triage engine processes every incoming alert from Flux Event and Flux Monitor within seconds, automatically assigning severity, identifying the affected service, and generating a human-readable summary.

Triage Pipeline

1. Alert ingestion — receives raw alert payload from Flux Event processor or Flux Monitor threshold breach
2. Context enrichment — pulls service topology, recent incidents, and metric baselines from cross-app DB connections
3. Severity scoring — AI assigns P1–P4 with confidence percentage based on impact assessment
4. Pattern matching — compares against 90-day incident history to identify recurring issues
5. Summary generation — produces a concise, actionable incident summary in plain English
6. Runbook linking — surfaces the top 3 matching runbooks from the runbook library
7. Notification routing — triggers Flux Notify with AI-enriched incident data

// NOC CHATBOT

The NOC chatbot provides a natural language interface over your live incident data, metric baselines, runbooks, and historical patterns. Ask questions in plain English — no query language required.

Example Queries

Context Window

The chatbot maintains a sliding context window including the last 20 conversation turns, all currently open incidents, recent anomaly signals, and your team's runbook library. This context is injected into every AI request, enabling coherent multi-turn conversations about ongoing incidents.

// ANOMALY DETECTION

Flux AI continuously monitors metrics from Flux Monitor and Flux Speed, building rolling baselines and surfacing statistically significant deviations before they become outages.

Detection Methods

Anomaly Score Levels

// ROOT CAUSE ANALYSIS

Flux AI's RCA engine guides engineers through structured investigation workflows, automatically correlating events across all Flux Suite applications to identify the origin of cascading failures.

RCA Process

When an RCA is initiated for an incident, Flux AI:

• Pulls the full event timeline from Flux Event for the affected service and its dependencies
• Correlates metric anomalies from Flux Monitor in a configurable time window before the incident
• Cross-references recent deploys, config changes, and maintenance windows from the audit log
• Runs causal chain analysis using the Claude API to identify the most likely root cause with evidence scoring
• Presents findings with a confidence score and supporting evidence for human review
• Feeds accepted root causes back into the pattern library for future triage improvement

// RUNBOOK SUGGESTIONS

The runbook engine maintains an indexed library of resolution procedures and automatically surfaces the most relevant runbooks for each active incident based on pattern matching against incident history.

Managing Runbooks

Runbooks are created and managed at Settings → Runbooks. Each runbook contains a title, description, service tags, symptom patterns, and numbered resolution steps. When a new incident is triaged, Flux AI scores all runbooks against the incident context and presents the top 3 matches with a confidence percentage.

Runbook API

# List all runbooks
GET /api/ai/runbooks

# Get suggestions for an incident
GET /api/ai/runbooks/suggest?incident_id=INC-4471

# Create a new runbook
POST /api/ai/runbooks
{
  "title": "PostgreSQL Replication Recovery",
  "service_tags": ["postgresql", "payments", "database"],
  "symptom_patterns": ["replication lag", "write amplification"],
  "steps": ["Check replica lag", "Identify blocking queries", "..."]
}

// POST-MORTEM DRAFTING

Flux AI automatically generates structured post-mortem documents from the incident thread timeline, metric data, and audit log entries. Drafts are created when an incident is marked Resolved and are available immediately for review and editing.

Draft Structure

• Summary — what happened, duration, and overall impact
• Impact assessment — affected services, user impact, estimated revenue impact
• Timeline — chronological event log pulled from Flux Notify thread and Flux Event audit trail
• Root cause — AI-identified root cause with evidence chain
• Contributing factors — secondary factors that amplified the incident
• What went well — detection time, response quality, tooling effectiveness
• Action items — AI-suggested preventive measures with assignee fields

// NOISE REDUCTION

Alert fatigue is one of the leading causes of NOC burnout. Flux AI's noise reduction engine intelligently suppresses low-signal alerts so on-call teams only receive actionable notifications.

Suppression Types

// AUTO-REMEDIATION

Flux AI can execute a library of safe self-healing actions, always with configurable human approval gates. Every action is logged in the audit trail with full rollback capability.

Available Actions

• Kubernetes: pod restart, deployment rollout restart, horizontal scale, rollback to previous revision
• Caching: Redis cache flush, CDN cache purge, application-level cache clear
• Database: kill long-running queries, connection pool reset, read replica failover
• Networking: DNS cache flush, routing table refresh, LB backend drain
• Application: circuit breaker trip, feature flag disable, rate limit increase

// CAPACITY FORECASTING

Flux AI analyzes historical metric trends from Flux Monitor and produces resource utilization forecasts with configurable alert horizons, enabling proactive scaling decisions before capacity limits are hit.

Monitored Resources

• CPU utilization per host, service, and cluster
• Memory utilization with leak detection trend analysis
• Disk usage with ingest rate modeling per database and volume
• Network bandwidth — ingress and egress per interface and VPC
• Application-layer: request rate, queue depth, active connections

Alert Horizons

// PREDICTIVE ALERTING

Beyond detecting anomalies in current metrics, Flux AI surfaces leading indicators — early warning signals that historically precede specific failure modes — allowing on-call engineers to act before users are impacted.

Leading Indicator Examples

// CROSS-APP INTELLIGENCE

Flux AI is the only Flux Suite application with read access to all other apps' databases. This cross-app view enables unified analysis that would be impossible from any single app.

Data Sources

// RBAC & PERMISSIONS

// REST API

All Flux AI features are accessible via REST API. Authentication uses the same three methods as the rest of the Flux Suite (JWT Bearer, X-API-Token, X-API-Key).

// ARCHITECTURE

Flux AI runs as a 4-container Docker Compose stack, with an optional Ollama container for local LLM inference. All containers share a dedicated flux-ai bridge network.