Color Teams

Overview

Color Teams implement epistemic security through adversarial-defensive synthesis. Six specialized teams -- Gray, Red, Blue, Purple, White, and Black -- work in coordination to ensure the platform's reasoning remains sound, its defenses hold under adversarial conditions, and its conclusions withstand formal verification. This is not traditional cybersecurity with firewalls and intrusion detection. This is epistemic security: protecting the integrity of the platform's belief formation, decision-making, and intelligence synthesis processes.

The Color Team architecture is modeled on military red-team/blue-team exercises but extends the concept to cover the full spectrum of epistemic operations. Gray Team explores boundary conditions. Red Team simulates adversarial attacks. Blue Team defends and monitors. Purple Team synthesizes Red and Blue findings into closed-loop improvements. White Team provides formal constructive verification. Black Team models theoretical worst-case threats in maximum isolation. Together, these six teams create a continuous adversarial-defensive cycle that hardens the platform against both known and novel threats.

The 20 agents across all six teams operate under strict AIAD specifications with tier-appropriate authority levels, mandatory safety protocols, and full NABLA Axioms compliance. Every finding, every simulation, every proof is traceable through the platform's provenance system and passes through the Trinity Gate verification pipeline.

Signal Flow Architecture

The Color Teams operate in a continuous signal flow cycle where findings from one team feed into the next, creating a closed-loop security posture that evolves with each iteration.

Gray (boundary seeds) --> Red (adversarial scenarios) --> Purple (synthesis)
                                     ^                         |       ^
                                     |                         v       |
                                Black (threat models)    Blue (defense) |
                                                              |        |
                                                              v        |
                                                        White (proofs) +

This signal flow is not sequential -- teams operate concurrently with asynchronous message passing. Gray findings may trigger immediate Red scenarios while previous Red findings are still being synthesized by Purple. The architecture leverages Elixir/OTP's concurrency model to maintain multiple overlapping security cycles simultaneously.

Gray Team -- Boundary Exploration

Agents: 3 | Classification: L3-L4 | Mode: Read-only exploration

Gray Team surfaces ambiguity without resolving it. Their mission is to identify specification gaps, edge cases, and affordance drift -- areas where the platform's behavior is undefined or ambiguous. Gray findings seed both Red Team attack scenarios and Blue Team monitoring priorities.

Gray Team Operations

All Gray operations enforce zero state changes. Gray agents have read-only access to platform state and cannot modify any system component. This constraint ensures that boundary exploration itself does not introduce new risks.

Red Team -- Adversarial Simulation

Agents: 4 | Classification: L2-L3 | Mode: Sandboxed simulation

Red Team simulates epistemic attacks using five adversarial primitives. All execution is sandboxed with synthetic data only -- no real data, no PII, no production state access. The Red Team exists to answer the question: "If an adversary targeted our reasoning processes, what would they attack and how?"

Five Adversarial Primitives

Red Team Safety Constraints

Blue Team -- Epistemic Defense

Agents: 4 | Classification: L2-L3 | Mode: Continuous monitoring

Blue Team maintains the platform's defensive posture through evidence synthesis, drift detection, and boundary monitoring. Blue agents produce structured evidence reports, not alerts. This distinction is critical: alerts are actionable only when contextually interpreted, while evidence reports provide the raw material for informed decision-making under the NABLA Axioms framework.

Blue Team Monitoring Domains

defmodule PrismaticDark.Blue.DriftDetector do
  @moduledoc """
  Multi-domain drift detection with configurable thresholds.
  Produces structured evidence for Blue Commander synthesis.
  """
  use GenServer

  @drift_threshold 0.05
  @check_interval :timer.seconds(30)

  @impl true
  def handle_info(:check_drift, state) do
    evidence =
      state.monitored_domains
      |> Enum.map(&detect_domain_drift/1)
      |> Enum.filter(fn {_domain, drift} -> drift > @drift_threshold end)
      |> Enum.map(&build_evidence_report/1)

    case evidence do
      [] ->
        {:noreply, state}

      findings ->
        PrismaticDark.Blue.Commander.report_evidence(findings)
        :telemetry.execute(
          [:color_team, :blue, :drift_detected],
          %{count: length(findings)},
          %{domains: Enum.map(findings, & &1.domain)}
        )
        {:noreply, %{state | last_findings: findings}}
    end
  end

  defp detect_domain_drift(domain) do
    baseline = PrismaticDark.Blue.Baseline.get(domain)
    current = PrismaticDark.Blue.Sampler.sample(domain)
    drift = PrismaticDark.Blue.Statistics.kl_divergence(baseline, current)
    {domain, drift}
  end
end

Purple Team -- Synthesis and Closure

Agents: 4 | Classification: L3-L4 | Mode: Analytical synthesis

Purple Team is the central hub for Red-Blue loop closure. It holds sole authority for closure state transitions -- the determination that a Red Team finding has been adequately addressed by Blue Team defenses. Purple's guiding principle: "Purple is the property of the system when it stops lying to itself."

Four Closure Conditions

A Red Team finding is considered closed only when all four conditions are simultaneously satisfied.

False closure detection is a critical Purple Team function. If any of the four conditions fails under re-testing, the finding is reopened with escalated priority. This prevents the common security failure mode where issues are "closed" on paper but not actually resolved.

White Team -- Constructive Verification

Agents: 3 | Classification: L3-L4 | Mode: Formal verification

White Team proves that systems hold through progressive verification methodology spanning five levels. White agents produce evidence artifacts, never modify targets. All output passes through the Trinity Gate.

Verification Levels

Black Team -- Theoretical Threat Modeling

Agents: 2 | Classification: L3 (MAXIMUM ISOLATION) | Mode: Abstract analysis only

Black Team operates in maximum isolation to model worst-case adversarial optimization. It produces abstract threat models only and never generates executable content. The Black domain answers: "What is the theoretically worst thing that could happen, and how would we know?"

Black Team Safety Protocols

Performance and Metrics

Commands

Integration

• Governed by NABLA Axioms for all epistemic operations and belief formation
• Verified through Trinity Gate for all White Team proof artifacts
• Organized under AIAD Standard with full specification coverage for all 20 agents
• Compliance enforced by AIAD Compliance with tier-appropriate authority boundaries
• Monitored by Real-Time Monitoring for team operation metrics
• Tracked by Telemetry Integration for cross-team signal flow performance
• Blue Team drift detection triggers Autonomous Self-Healing cycles
• Quality enforced by NO MERCY zero-tolerance standards across all teams
• Evidence standards enforced by NO DOUBTS for all findings and assessments
• Supports Intelligence Synthesis security validation for OSINT pipelines
• Quality Gates integrated into Purple Team deployment gates

Connect & Contribute

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

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