Applications

93 OTP umbrella applications forming the Prismatic Platform -- from core infrastructure and storage adapters through intelligence modules and autonomous evolution systems to production web interfaces. Each application is a self-contained OTP application with its own supervision tree, configuration, and test suite, communicating through well-defined public APIs following the 3NL architectural framework.

Abstract

The Prismatic Platform's application architecture follows the Elixir/OTP umbrella pattern, organizing 93 distinct OTP applications into a cohesive, fault-tolerant ecosystem. Each application owns its supervision tree, isolates its failure domain, and exposes functionality exclusively through a public facade module. This document catalogs the complete application landscape, explains the architectural rationale behind the umbrella structure, and provides guidance for understanding how applications compose into the platform's capabilities.

The umbrella approach delivers three critical properties that monolithic architectures cannot: independent deployability (applications can be compiled and tested in isolation), fault isolation (a crash in one application's supervision tree does not propagate to others), and clear dependency graphs (inter-application dependencies are explicit in mix.exs and enforced at compile time).

Introduction

The Umbrella Architecture Decision

The decision to structure Prismatic as an umbrella project rather than a monolith or microservice mesh reflects a deliberate architectural trade-off. Elixir umbrella projects provide the modularity benefits of microservices -- clear boundaries, independent testing, explicit dependencies -- without the operational complexity of distributed deployment, service discovery, and network-based inter-service communication.

Within a single BEAM VM, all 93 applications share the same Erlang distribution node. They communicate via direct function calls, message passing between named processes, and PubSub events -- all happening in-process with microsecond latency rather than the millisecond-scale overhead of HTTP or gRPC between separate services.

Architectural Principles

Every application in the umbrella adheres to these design constraints:

1. Single Responsibility: Each app owns exactly one domain. prismatic_auth handles authentication; prismatic_audit handles audit logging. No overlap.
2. Facade Pattern: External consumers access functionality through a single top-level module (e.g., PrismaticAuth, PrismaticPerimeter). Internal modules are implementation details.
3. OTP Compliance: Stateful applications define a supervision tree rooted in Application.start/2. Stateless libraries skip the application callback.
4. Explicit Dependencies: Every inter-app dependency is declared in mix.exs. Circular dependencies are forbidden and caught at compile time.
5. Independent Testability: mix test apps/prismatic_auth runs the auth test suite in isolation. No test should require another app's runtime state.

Scale Context

The 93 applications collectively comprise:

Application Taxonomy

Applications are organized into eight functional categories, each serving a distinct role in the platform's architecture.

Core Infrastructure

The foundation layer providing shared capabilities that all other applications depend on:

Core infrastructure applications have zero external dependencies beyond the Elixir standard library and are loaded first during the boot sequence.

Storage Layer

The storage subsystem implements a pluggable adapter architecture through the PrismaticStorage.Adapter behaviour, allowing transparent switching between storage backends:

# Storage adapter contract -- all backends implement this
defmodule PrismaticStorage.Adapter do
  @callback store(key :: binary(), value :: term(), opts :: keyword()) ::
              {:ok, term()} | {:error, term()}
  @callback fetch(key :: binary(), opts :: keyword()) ::
              {:ok, term()} | {:error, :not_found}
  @callback delete(key :: binary(), opts :: keyword()) ::
              :ok | {:error, term()}
  @callback list(prefix :: binary(), opts :: keyword()) ::
              {:ok, [term()]} | {:error, term()}
end

Intelligence & OSINT

Applications providing intelligence gathering, analysis, and synthesis capabilities:

Security & Compliance

Applications enforcing security policies, running adversarial simulations, and ensuring regulatory compliance:

AI & Agent Systems

Applications powering the platform's 434+ autonomous AI agents:

Web Interfaces

Phoenix-based web applications providing dashboards, APIs, and user interfaces:

Quality & Evolution

Applications driving the platform's autonomous quality enforcement and evolution:

Specialized Domains

Applications serving specific business or technical domains:

Inter-Application Communication

Applications communicate through four primary mechanisms, each suited to different interaction patterns:

1. Direct Function Calls (Synchronous)

The simplest and most common pattern. One application calls another's facade module:

# prismatic_web calling prismatic_perimeter
{:ok, rating} = PrismaticPerimeter.security_rating("example.com")

2. GenServer Calls/Casts (Process-Based)

For stateful interactions where the target application manages state through a GenServer:

# Requesting a cached result from the cache application
{:ok, result} = PrismaticCache.fetch("session:#{session_id}")

3. PubSub Events (Asynchronous)

For event-driven communication where multiple applications may react to the same event:

# Publishing an event from prismatic_audit
Phoenix.PubSub.broadcast(Prismatic.PubSub, "audit:events", {:audit_entry, entry})

# Subscribing in prismatic_compliance
Phoenix.PubSub.subscribe(Prismatic.PubSub, "audit:events")

4. Oban Jobs (Deferred)

For background processing and scheduled tasks using the Oban job processing library:

# Scheduling a crawl job from prismatic_crawler
%{url: "https://example.com", depth: 3}
|> PrismaticCrawler.Workers.CrawlWorker.new(schedule_in: 60)
|> Oban.insert()

Dependency Architecture

The dependency graph follows a strict layered architecture preventing circular dependencies:

Layer 4 (Web)        prismatic_web, prismatic_api, *_web apps
    ↓ depends on
Layer 3 (Domain)     prismatic_perimeter, prismatic_dd, prismatic_hawkeye, ai_drift
    ↓ depends on
Layer 2 (Services)   prismatic_agents, prismatic_osint_core, prismatic_auth
    ↓ depends on
Layer 1 (Core)       prismatic_core, prismatic_storage_core, prismatic_kernel
    ↓ depends on
Layer 0 (Runtime)    Elixir stdlib, OTP, BEAM VM

Enforcement: Circular dependencies are caught at compile time by mix compile. The platform's CI pipeline additionally verifies the dependency graph topology on every push.

Supervision Tree Architecture

Each OTP application defines a supervision tree that determines how its processes start, restart, and recover from failures:

# Typical application supervision tree
defmodule PrismaticPerimeter.Application do
  use Application

  @impl true
  def start(_type, _args) do
    children = [
      # Core services
      PrismaticPerimeter.Config,
      PrismaticPerimeter.RatingCache,
      # Worker pools
      {Task.Supervisor, name: PrismaticPerimeter.TaskSupervisor},
      # Scheduled jobs
      PrismaticPerimeter.Scheduler
    ]

    opts = [strategy: :one_for_one, name: PrismaticPerimeter.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

Restart Strategies Used Across the Platform:

Performance Characteristics

Build Performance

Runtime Performance

Development Workflow

Creating a New Application

# Generate new umbrella application
cd apps/
mix new prismatic_new_app --sup

# Add to umbrella deps in root mix.exs
# Add inter-app dependencies in apps/prismatic_new_app/mix.exs

Testing in Isolation

# Test single application
mix test apps/prismatic_perimeter

# Test with coverage
mix test apps/prismatic_perimeter --cover

# Run specific test file
mix test apps/prismatic_perimeter/test/prismatic/perimeter/security_rating_test.exs

Exploring the Application Landscape

# List all applications with file counts
mix git_trees apps

# Find files in specific application
mix git_trees list apps/prismatic_perimeter

# Application statistics
mix git_trees --type=ex | grep prismatic_perimeter

Security Considerations

Application Isolation

Each application runs within its own supervision tree, providing natural process-level isolation. The BEAM VM's process model ensures that:

• Memory isolation: Processes do not share heap memory; data is copied on message passing
• Failure isolation: A crashing process takes down only its supervisor subtree
• Scheduling fairness: The BEAM scheduler prevents any single application from starving others

Sensitive Applications

Applications handling sensitive data implement additional security measures:

• prismatic_auth: Credential storage uses Argon2 hashing; tokens have configurable TTL
• prismatic_dark: Operates in a sandboxed environment with no network access
• prismatic_suppression: Implements cryptographic erasure for GDPR right-to-erasure compliance
• prismatic_compliance: Maintains immutable audit trails with tamper detection

Dependency Security

All Hex dependencies are pinned to exact versions in mix.lock. The CI pipeline runs mix deps.audit to check for known vulnerabilities in the dependency tree.

Conclusion

Architectural Achievement

The 93-application umbrella architecture demonstrates that Elixir/OTP's process model scales to large, complex platforms without sacrificing modularity or fault tolerance. Each application maintains clear boundaries, independent testability, and explicit dependencies while benefiting from the shared BEAM runtime's efficiency.

Evolution Path

The application count has grown from the original 12 core applications to 93, guided by the principle that new domains deserve their own application when they introduce distinct state, failure modes, or deployment requirements. This organic growth, constrained by architectural rules, produces a system that is simultaneously large-scale and comprehensible.

Future Expansion

Planned application additions follow the platform's strategic roadmap:

• Quantum-safe cryptography application for post-quantum security
• Multi-region coordination for distributed deployment scenarios
• Advanced vision analysis for image and video intelligence capabilities

References

Internal Documentation

• Platform Architecture -- Architectural overview and design patterns
• Umbrella Architecture -- Detailed umbrella structure documentation
• Supervision Trees -- OTP supervision patterns
• Storage Adapters -- Storage layer architecture
• Agent Architecture -- AI agent system documentation

External Resources

• Elixir Umbrella Projects -- Official Elixir guide
• OTP Design Principles -- Erlang/OTP supervision and application design
• Phoenix Framework -- Web framework documentation

This document catalogs the complete application landscape of the Prismatic Platform as of 2026-02-06. Application counts and metrics are updated to reflect the current state of the platform.

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

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