Omniculus — Architecture Blueprint

Data flow

                 ┌────────────┐
  authorized →   │  INGEST    │  synthetic generator (default) + connectors
  sources        └─────┬──────┘  + public threat-intel feeds
                       │ events (labeled in lab)
                       ▼
                 ┌────────────┐
                 │   GRAPH    │  entity resolution → NetworkX knowledge graph
                 └─────┬──────┘  (the data-fusion core)
                       │ entities + observations
                       ▼
                 ┌────────────┐
                 │  DETECT    │  rules (Sigma-style) + statistical anomaly
                 └─────┬──────┘  + (roadmap) graph analytics + ML + game theory
                       │ explainable Alerts (rule + evidence + confidence)
                       ▼
                 ┌────────────┐
                 │ INVESTIGATE│  rank, route consequential alerts to a HUMAN
                 └─────┬──────┘  audit log; recommends only — acts on nothing
                       │ analyst dispositions
                       ▼
                 ┌────────────┐
                 │  FEEDBACK  │  retune thresholds; bounded + logged
                 └─────┬──────┘
                       │ updated config
                       └──────────────► back to DETECT (the vigilance loop)

Modules

ingest/

• synthetic.py — generates a benign behavioral baseline plus injected, ground-truth-labeled attack scenarios (brute_force, lateral_movement, c2_beacon). This is what makes the platform safe to develop on.
• connectors.py (roadmap) — adapters for real telemetry (network flow, endpoint/auth logs, cloud audit) and public feeds (MITRE ATT&CK, CVE/NVD, abuse.ch, MISP, OTX). Authorization-gated.

graph/

• model.py — entity typing / canonicalization (user, host, ip).
• knowledge_graph.py — a networkx.MultiDiGraph where nodes are entities and edges are observed events. Query helpers (edges_to, edges_from, out_degree_by_node, nodes_of_type) are the substrate detections build on.
• Why a graph: correlation, attack-path tracing, and "who touched what" questions are natural as graph queries and awkward as flat-log scans.
• Backend choice: NetworkX for research simplicity. Swappable for Neo4j at production scale (roadmap) — keep query helpers as the abstraction seam.

detect/

• alert.py — the Alert: rule, severity, confidence, entities, evidence, recommended action, and (lab-only) ground truth for evaluation.
• engine.py — runs all detections:
• brute_force — sliding-window failed-auth burst per (src, dst); severity escalates if a success follows.
• lateral_movement — a user authenticating to ≥ N distinct hosts.
• known_bad_contact — network contact with a threat-intel-listed IP.
• connection_anomaly — z-score outlier on outbound connection volume.
• Every detection returns evidence; nothing is a black box.

investigate/

• decision_support.py — ranks alerts by (severity, confidence), marks critical/high as requires human review, and records an audit trail. The DecisionSupport class has no method that executes a response. This is the architectural embodiment of human-in-the-loop.

feedback/

• learning.py — converts analyst dispositions (true/false positive) into bounded, logged threshold adjustments. Low precision on a rule raises its bar; this is the "learn to be more vigilant" loop, kept auditable.

Configuration

• config.py centralizes thresholds so the feedback loop has one place to retune and so behavior is inspectable.

Extension seams (where new work plugs in)

• New detection: add a _detect_* method to DetectionEngine returning Alerts with evidence.
• New data source: emit events in the ingest schema; the graph and detections are source-agnostic.
• New backend: implement the KnowledgeGraph query helpers over Neo4j.
• Correlation/alert dedup: sits between detect and investigate.