Overview

The Blue Drift Detector is an L2 tactical operations agent within the Epistemic Defense domain of the Prismatic Platform. This agent continuously monitors system state across all 90 umbrella applications for sub-threshold deviations that may indicate epistemic degradation, configuration tampering, or gradual quality erosion. As a core member of the Blue Team, it provides drift detection evidence that feeds into the team's unified defensive posture assessment.

Drift is the silent adversary of system integrity. Unlike acute failures that trigger immediate alerts, drift operates below detection thresholds -- small, incremental changes that individually seem benign but collectively degrade system behavior, security posture, or quality standards. The Blue Drift Detector is specifically designed to detect these sub-threshold changes by maintaining statistical models of expected system behavior and flagging deviations that exceed configurable sensitivity thresholds.

The agent addresses four distinct drift categories: behavioral drift (changes in how agents and systems behave), configuration drift (unauthorized or unintended changes to system parameters), dependency drift (version changes, deprecations, and vulnerability introductions in the dependency graph), and performance drift (gradual degradation in response times, throughput, and resource efficiency). Each category uses specialized detection algorithms tuned for its characteristic signal patterns.

Architecture

The Blue Drift Detector's architecture separates signal collection, statistical analysis, and evidence production into distinct processing stages, enabling independent evolution and testing of each concern.

Signal Collection Layer. The detector subscribes to telemetry events across the platform using namespace patterns that capture behavioral metrics, configuration state, dependency status, and performance measurements. Signals are ingested into a time-series buffer backed by ETS tables with configurable retention windows per signal type. The collection layer normalizes signal formats across different platform subsystems into a uniform internal representation.

Statistical Analysis Layer. The analysis layer applies statistical process control (SPC) methods to detect drift in collected signals. Two primary algorithms operate in parallel: CUSUM (Cumulative Sum) control charts for detecting sustained shifts in signal means, and EWMA (Exponentially Weighted Moving Average) for detecting both sudden and gradual changes with configurable sensitivity. Both algorithms maintain per-signal baseline models computed from historical data, with baselines updated periodically to accommodate legitimate system evolution.

Evidence Production Layer. When the analysis layer detects drift exceeding configured thresholds, the evidence production layer generates structured evidence packages formatted for consumption by the Blue Signal Aggregator and Blue Commander. Each evidence package includes the drift signal, its statistical significance, temporal context, source provenance, and confidence score.

defmodule PrismaticAgents.BlueDriftDetector do
  use GenServer

  @cusum_threshold 5.0
  @ewma_lambda 0.2
  @baseline_update_interval_ms :timer.hours(24)

  def check_drift(signal_type) do
    GenServer.call(__MODULE__, {:check, signal_type})
  end

  @impl true
  def handle_info({:telemetry_event, signal_type, measurement}, state) do
    baseline = get_baseline(signal_type, state)
    cusum_result = cusum_detect(measurement, baseline, @cusum_threshold)
    ewma_result = ewma_detect(measurement, baseline, @ewma_lambda)

    case {cusum_result, ewma_result} do
      {:drift_detected, _} -> produce_evidence(signal_type, :cusum, measurement, state)
      {_, :drift_detected} -> produce_evidence(signal_type, :ewma, measurement, state)
      _ -> {:noreply, update_statistics(state, signal_type, measurement)}
    end
  end

  defp produce_evidence(signal_type, method, measurement, state) do
    evidence = %{
      signal_type: signal_type,
      detection_method: method,
      measurement: measurement,
      baseline: get_baseline(signal_type, state),
      confidence: compute_confidence(method, measurement, state),
      timestamp: DateTime.utc_now(),
      provenance: __MODULE__
    }

    forward_to_aggregator(evidence)
    emit_telemetry(:drift_detected, evidence)
    {:noreply, record_detection(state, evidence)}
  end
end

Drift Detection Categories

Behavioral Drift

Behavioral drift detection monitors agent and system behavior patterns over time, identifying deviations from established baselines. This includes response time distributions, decision pattern changes, output characteristic shifts, and interaction pattern anomalies. The detector uses statistical process control methods with CUSUM and EWMA algorithms to identify subtle, sustained behavioral shifts that might escape point-in-time analysis.

Behavioral baselines are computed from 30-day rolling windows of agent telemetry. Deviations are measured in standard deviations from the baseline mean, with configurable sigma thresholds per agent category. L1-L2 authority agents use tighter thresholds (2-sigma) due to their critical role, while L4-L5 specialists use standard thresholds (3-sigma).

Configuration Drift

Configuration drift monitoring tracks all platform configuration state across the 90+ umbrella applications, detecting unauthorized or unintended changes to runtime parameters, environment variables, feature flags, and system settings. The detector maintains cryptographic hashes (SHA-256) of known-good configuration states and performs continuous comparison against the live system state.

Configuration changes that match approved change records are classified as legitimate and update the known-good baseline. Changes without corresponding approval records are flagged as potential unauthorized modifications and escalated for investigation.

Dependency Drift

Dependency drift analysis monitors the platform's dependency graph for version changes, deprecated package usage, security vulnerability introductions, and license compliance shifts. This extends to both direct dependencies (Hex packages, npm modules) and transitive dependency trees, providing early warning of supply chain risks.

The detector correlates dependency changes with the AIAD Agent Automated dependency scanner's vulnerability database, flagging dependency version changes that introduce known CVEs as high-severity drift events.

Performance Drift

Performance drift detection tracks system performance metrics against established baselines, identifying gradual degradation in response times, throughput, error rates, memory usage, and resource consumption. The detector distinguishes between natural load-driven variations and genuine performance regression using adaptive baseline algorithms that account for daily and weekly traffic patterns.

Performance baselines incorporate temporal patterns: weekday versus weekend traffic profiles, peak versus off-peak hours, and seasonal trends. Drift detection only triggers when performance deviates from the temporally-appropriate baseline, reducing false positives from normal traffic variation.

Detection Methodology

The Blue Drift Detector employs a multi-layered detection methodology grounded in NABLA Infinity axioms.

Method	Application	Sensitivity
CUSUM Control Charts	Behavioral and performance drift	Configurable sigma thresholds (2-3 sigma)
EWMA Analysis	All categories, emphasis on gradual shifts	Configurable lambda (0.1-0.3)
Cryptographic State Comparison	Configuration drift	Exact match (zero tolerance)
Dependency Graph Diffing	Dependency drift	Semantic versioning awareness
Time-Series Anomaly Detection	All categories	Adaptive baseline with temporal patterns
Cross-Domain Signal Correlation	Multi-category drift events	NABLA plurality enforcement

All detected drift signals are tagged with timestamps (enforcing the Time Decay axiom), source provenance (enforcing the Provenance Mandatory axiom), and confidence levels (supporting the Unknown Valid axiom when detection certainty is below threshold).

Core Capabilities

Sub-threshold behavioral drift detection using CUSUM and EWMA statistical process control algorithms to identify sustained shifts in agent behavior, response patterns, and decision outcomes that are individually below alerting thresholds but collectively indicate meaningful change
Zero-tolerance configuration monitoring through cryptographic state comparison that detects any configuration change, no matter how small, and classifies it as either authorized (matching change records) or potentially unauthorized (requiring investigation)
Supply chain drift analysis monitoring the full transitive dependency tree for version changes, vulnerability introductions, deprecation status changes, and license modifications that could affect platform security or compliance
Temporally-aware performance baseline management maintaining performance baselines that account for daily, weekly, and seasonal traffic patterns, enabling accurate drift detection that distinguishes genuine regression from normal load variation
Cross-category drift correlation forwarding drift evidence to the Blue Signal Aggregator for cross-domain correlation, enabling detection of coordinated drift patterns that span multiple categories
Automated drift evidence packaging producing structured evidence packages with statistical significance metrics, temporal context, and source provenance formatted for the Blue Team's evidence-based defensive assessment pipeline

Signal Flow

The Blue Drift Detector participates in the Color Team signal flow architecture through a five-stage pipeline.

Detection: Continuous monitoring produces raw drift signals across all four categories using parallel CUSUM and EWMA algorithms
Scoring: Each signal is scored for confidence, severity, and cross-category correlation potential based on statistical significance and temporal context
Aggregation: Scored signals are forwarded to the Blue Signal Aggregator for cross-domain correlation with signals from other Blue Team specialists
Synthesis: Correlated drift evidence flows to Purple Team for Red-Blue synthesis, enabling closure of the adversarial-defensive loop
Defense: Validated drift findings inform the Blue Team defensive posture assessment and may trigger targeted defensive hardening

Authority Level

L2 - Tactical Operations - Domain-specific tactical execution with cross-domain coordination capabilities. The Blue Drift Detector operates under the authority of the Blue Commander (L3) and coordinates findings with the broader Blue Team defensive posture.

Red Team Adversarial Relationship

The Blue Drift Detector specifically defends against Red Drift Inducer adversarial scenarios. The Red Team's drift induction simulations directly test the detector's sensitivity thresholds and response times, targeting each of the four drift categories with sub-threshold attack patterns designed to evade detection. This adversarial testing continuously calibrates the detector's sensitivity, ensuring robust drift detection under realistic attack conditions.

Detection gaps identified during Red Team exercises are tracked as mandatory remediation items. Each gap triggers a review of the affected detection algorithm's threshold settings and potentially leads to algorithm refinement or additional detection methods.

Coordination

Agent	Relationship	Purpose
blue-commander	Reporting Authority	Reports drift evidence for strategic defensive assessment
blue-signal-aggregator	Signal Correlation	Feeds drift detection evidence into cross-domain signal aggregation
blue-auth-sentinel	Complementary Detection	Shares authentication context that may explain behavioral drift patterns
red-drift-inducer	Adversarial Testing	Detection capabilities tested by Red Team drift induction attacks
purple-coordinator	Synthesis Consumer	Drift evidence flows to Purple for Red-Blue loop synthesis

Integration Points

Component	Relationship	Data Flow
NABLA Infinity	Epistemic framework	Axiom enforcement on all drift conclusions
Trinity Gate	Formal verification	Three-layer validation of drift claims before distribution
Quality Floor Guardian	Quality monitoring	Quality metric drift feeds into quality enforcement
Lean4	Formal methods	Drift invariant verification through formal theorem proving
Platform Telemetry	Primary data source	All four drift categories sourced from telemetry streams

Performance

Metric	Current	Target	Description
Detection latency	< 30s	< 60s	Time from drift onset to detection signal
False positive rate	< 5%	< 10%	Percentage of drift alerts that are benign
Category coverage	4/4	4/4	All drift categories actively monitored
Baseline freshness	< 24hr	< 48hr	Maximum age of behavioral/performance baselines
Red Team detection rate	> 88%	> 85%	Percentage of Red Team drift attacks detected
Evidence production latency	< 5s	< 10s	Time from detection to structured evidence package

Enforcement

The Blue Drift Detector operates under the NO MERCY, NO DOUBTS doctrine with Color Team operational security protocols. All drift detections must be evidence-based with verifiable provenance. Single-signal drift conclusions are blocked under NABLA Infinity Signal Plurality -- drift claims require corroboration from either multiple detection methods (CUSUM and EWMA agreement) or multiple observation windows before escalation. Drift detection reports undergo Trinity Gate validation before distribution to ensure structural consistency (detection algorithm correctly applied), logical consistency (drift conclusion follows from statistical evidence), and formal correctness (statistical methods produce valid results). Contradictions between expected and observed drift patterns are preserved and escalated to Purple for synthesis, never suppressed.

Blue Commander -- Strategic commander orchestrating Blue Team defensive posture
Blue Auth Sentinel -- Authentication boundary monitoring specialist
Blue Signal Aggregator -- Cross-domain signal correlation engine
Red Drift Inducer -- Adversarial drift simulation for detection testing
Color Teams -- Security team framework including Blue Team operations
Architecture Overview -- Platform architecture including defensive monitoring

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

blue-drift-detector

Overview

Architecture

Drift Detection Categories

Behavioral Drift

Configuration Drift

Dependency Drift

Performance Drift

Detection Methodology

Core Capabilities

Signal Flow

Authority Level

Red Team Adversarial Relationship

Coordination

Integration Points

Performance

Enforcement

Connect & Contribute

Agent Info

Agent Distribution

Agent Domains

Related Content

Color Teams

Doctrine

OSINT Sources

blue-drift-detector

Overview

Architecture

Drift Detection Categories

Behavioral Drift

Configuration Drift

Dependency Drift

Performance Drift

Detection Methodology

Core Capabilities

Signal Flow

Authority Level

Red Team Adversarial Relationship

Coordination

Integration Points

Performance

Enforcement

Related Resources

Connect & Contribute

Agent Info

Agent Distribution

Agent Domains

Related Content

Color Teams

Doctrine

OSINT Sources