44 Technologies

Perex

The Prismatic Platform's production stack integrates 45+ carefully selected technologies into a unified architecture that serves intelligence analysis, security assessment, formal verification, and autonomous AI operations. From the BEAM virtual machine foundation through Phoenix LiveView interfaces to AI model integration and graph-native storage, every technology was chosen through rigorous evaluation against fault tolerance, developer productivity, and long-term maintainability.

This technology selection transforms platform capabilities into reliable, scalable infrastructure supporting 2.8M+ lines of code across 106 applications, delivering enterprise-grade performance with academic research rigor.

Key Technology Resources

45+ Technologies • 8 Architectural Layers • Zero Vendor Lock-in • Production-Tested

The platform combines proven open-source technologies with cutting-edge AI integration, creating a stack that prioritizes operational characteristics over feature richness. Each technology undergoes evaluation against three constraints: composition compatibility, fault tolerance requirements, and long-term maintainability.

Technology Stack Layers

Platform Statistics

• Total Technologies: 45+ production components
• Architectural Layers: 8 distinct technology layers
• Selection Philosophy: Operational characteristics first, features second
• Quality Standard: NO MERCY doctrine applied to all technology choices
• Integration Depth: Deep composition vs. loose assembly
• Open Source: GPL-3.0 licensing, zero vendor lock-in
• Platform Scale: 2.8M+ LOC, 106 applications supported

Quick Navigation

• Architecture Overview - System design and technology integration patterns
• Developer Portal - SDK and development toolchain access
• Platform Capabilities - Technical specifications and performance
• Applications Catalog - 625+ applications powered by this stack
• Agent System - 530 agents built on the technology foundation

Explore Platform

Want to Know More?

Dive deeper into specific technology layers, explore our architecture patterns, or review the development environment that leverages this comprehensive stack.

About Technologies: Selection Philosophy • Technology Layers • Conclusion

Abstract

The Prismatic Platform integrates 45 distinct technologies into a unified stack that serves intelligence analysis, security assessment, formal verification, and autonomous AI agent operations. This document provides a comprehensive survey of the technology landscape, organized by architectural layer, with emphasis on the selection rationale, integration patterns, and operational characteristics of each component.

Technology selection in a platform of this scale -- 93 OTP applications, 6,652 source files, approximately 2.8 million lines of code -- demands more than feature-list comparisons. Every technology must satisfy three constraints simultaneously: it must compose with the existing stack without impedance mismatch, it must operate reliably under the platform's fault tolerance requirements, and it must remain maintainable by a small team over multi-year timescales. These constraints eliminate a large number of otherwise capable tools and frameworks, producing a stack that favours proven, well-documented technologies over novel alternatives.

The stack is organized into eight layers, from the BEAM runtime at the foundation through the web platform, data persistence, AI integration, frontend rendering, security tooling, development infrastructure, and deployment operations. Each layer defines clear interfaces to adjacent layers, preventing tight coupling while enabling the deep integration that distinguishes Prismatic from loosely assembled tool collections.

Introduction

Selection Philosophy

The Prismatic Platform's technology choices reflect a pragmatic engineering philosophy: select for operational characteristics first, developer experience second, and feature richness third. A technology that is pleasant to use but unreliable under load, or feature-rich but poorly documented, will be rejected in favour of a simpler alternative that can be fully understood, monitored, and debugged in production.

This philosophy produces several observable patterns in the stack:

1. BEAM-native when possible: If a capability can be implemented as an Erlang/Elixir library running on the BEAM VM, that approach is preferred over introducing an external service. ETS replaces Redis for many caching scenarios. Phoenix PubSub replaces message brokers for intra-node event distribution. GenServer-based state machines replace external workflow engines.

2. Polyglot storage: No single database technology optimally serves all access patterns. PostgreSQL handles relational data and ACID transactions. ETS provides microsecond key-value lookups. Meilisearch powers full-text search with typo tolerance. KuzuDB models graph relationships. DuckDB handles analytical queries on columnar data. Each storage engine is accessed through the platform's unified storage adapter layer, so application code never couples to a specific backend.

3. AI as a tool, not a foundation: AI models (Claude, Ollama, OpenAI) are integrated as callable services with well-defined interfaces, not as load-bearing architectural components. If every AI endpoint became unavailable simultaneously, the platform's core intelligence analysis, storage, and web serving would continue operating. AI enhances; it does not define.

4. Formal verification as a peer: Lean 4 and SWI-Prolog are not afterthoughts or academic curiosities -- they are first-class components in the platform's epistemic pipeline, providing mathematical proof verification and logical reasoning that complement statistical AI inference.

Selection Criteria

Every technology in the stack was evaluated against five weighted criteria:

Technologies scoring below 70% aggregate are rejected. Technologies scoring above 85% are preferred candidates. The current stack represents the cumulative result of applying these criteria across four years of platform evolution.

Technology Layers

The complete stack is organized into eight architectural layers. Each layer depends only on layers below it; no upward or circular dependencies exist.

The following sections examine each layer in detail.

Core Runtime: Elixir, OTP, and the BEAM

The platform's foundation is the BEAM virtual machine -- the Erlang runtime system that has powered telecommunications infrastructure since 1986. On the BEAM, Erlang/OTP 27 provides the process model, supervision trees, and distribution protocols, while Elixir 1.19 provides the developer-facing language with modern syntax, metaprogramming, and the Mix build tool.

Why BEAM

The BEAM provides three properties that no other mainstream runtime offers simultaneously:

Preemptive scheduling of lightweight processes. The BEAM scheduler time-slices across millions of lightweight processes (not OS threads) with guaranteed fairness. A computationally expensive operation in one process cannot starve others. This is fundamental for a platform running 434+ AI agents, web connections, and background jobs concurrently.

Per-process garbage collection. Each BEAM process has its own heap. Garbage collection is per-process and concurrent -- collecting one process does not pause any other. This eliminates the stop-the-world GC pauses that plague JVM and V8-based systems under heavy load.

Fault isolation through process boundaries. A crash in one process does not corrupt another's memory. Combined with OTP supervisors that automatically restart failed processes, this produces systems that self-heal from transient failures without manual intervention.

OTP in Practice

The platform uses OTP's core abstractions extensively:

defmodule Prismatic.Perimeter.DiscoveryService do
  use GenServer

  @impl true
  def init(opts) do
    state = %{
      cache: :ets.new(:discovery_cache, [:set, :protected]),
      scan_interval: Keyword.get(opts, :scan_interval, :timer.minutes(15)),
      active_scans: %{}
    }

    schedule_periodic_scan(state.scan_interval)
    {:ok, state}
  end

  @impl true
  def handle_info(:periodic_scan, state) do
    {:ok, updated} = execute_scan_cycle(state)
    schedule_periodic_scan(state.scan_interval)
    {:noreply, updated}
  end

  defp schedule_periodic_scan(interval) do
    Process.send_after(self(), :periodic_scan, interval)
  end
end

Every stateful component in the platform follows this pattern: a GenServer process managed by a Supervisor, with ETS for fast reads and message passing for coordination. There are no global variables, no shared mutable state, and no thread-safety concerns.

Runtime Characteristics

Web Platform: Phoenix and LiveView

Phoenix 1.7 provides the HTTP layer, routing, and WebSocket infrastructure. Phoenix LiveView 0.20 extends this with server-rendered, real-time interactive interfaces that require zero custom JavaScript for the majority of UI interactions.

Real-Time Without Complexity

LiveView's model eliminates the traditional frontend/backend split for dashboard-style applications. The server maintains the UI state, computes DOM diffs, and pushes minimal patches over a persistent WebSocket connection. The client applies patches without full page reloads.

This architecture is ideal for the Prismatic Platform's monitoring dashboards, where data changes continuously and must propagate to all connected clients within milliseconds:

defmodule PrismaticWeb.Live.PerimeterDashboardLive do
  use PrismaticWeb, :live_view

  @impl true
  def mount(_params, _session, socket) do
    if connected?(socket) do
      Phoenix.PubSub.subscribe(Prismatic.PubSub, "perimeter:events")
    end

    {:ok, assign(socket, assets: [], rating: nil, last_scan: nil)}
  end

  @impl true
  def handle_info({:asset_discovered, asset}, socket) do
    {:noreply, update(socket, :assets, &[asset | &1])}
  end

  @impl true
  def handle_info({:rating_updated, rating}, socket) do
    {:noreply, assign(socket, rating: rating)}
  end
end

When the perimeter scanner discovers a new asset or updates a security rating, it broadcasts through Phoenix PubSub. Every connected LiveView receives the event and updates its DOM -- no polling, no REST calls, no client-side state management libraries.

Request Pipeline

Phoenix's Plug-based request pipeline provides composable middleware for authentication, rate limiting, CORS, and telemetry:

Request → Endpoint → Router → Pipeline (Plugs) → Controller/LiveView → Response
                                  │
                                  ├── APIAuth (JWT verification)
                                  ├── RateLimiter (sliding window)
                                  ├── RequestLogger (structured telemetry)
                                  └── CSRFProtection (form tokens)

The platform serves two Phoenix applications simultaneously: prismatic_web on port 4000 (LiveView dashboards) and prismatic_api on port 4004 (REST API with OpenAPI spec generation via OpenApiSpex).

Data Layer: Polyglot Persistence

The platform's data layer implements the polyglot persistence pattern -- using the best storage engine for each access pattern rather than forcing all data through a single database.

PostgreSQL -- Relational Core

PostgreSQL 16 serves as the primary relational store for all structured, transactional data. Accessed through Ecto (Elixir's database wrapper and query DSL), PostgreSQL handles user data, audit logs, security ratings, compliance assessments, and configuration state.

TimescaleDB extends PostgreSQL for time-series workloads -- particularly AI drift monitoring metrics that require efficient range queries and automatic data retention policies.

defmodule Prismatic.Perimeter.SecurityRating do
  use Ecto.Schema

  schema "security_ratings" do
    field :domain, :string
    field :grade, Ecto.Enum, values: [:A, :B, :C, :D, :F]
    field :score, :integer
    field :confidence, :float
    field :evidence, :map
    timestamps(type: :utc_datetime_usec)
  end
end

ETS -- In-Memory Speed

ETS (Erlang Term Storage) provides in-process, shared-nothing tables with microsecond read/write latency. The platform uses ETS extensively for caching, session state, and hot-path data that would suffer from the network round-trip overhead of an external cache:

ETS tables are owned by dedicated GenServer processes. If the owning process crashes and restarts, the table is recreated from the authoritative PostgreSQL source -- making ETS a performance optimization layer rather than a durability concern.

Redis -- External Caching and Queues

Redis handles caching scenarios that span multiple BEAM nodes (in clustered deployments) and provides the backing store for Oban job queues. While ETS serves single-node caching, Redis provides the shared state necessary for horizontal scaling.

Meilisearch -- Full-Text Search

Meilisearch powers the platform's search capabilities with typo-tolerant, faceted full-text search. Entity search, document discovery, and asset inventory filtering all route through Meilisearch, which indexes data pushed from PostgreSQL through the storage adapter layer.

KuzuDB -- Graph Analytics

KuzuDB provides embedded graph database capabilities for relationship-centric queries. Due diligence entity graphs, organizational ownership chains, and asset dependency maps are modeled as property graphs in KuzuDB, enabling traversal queries that would require expensive recursive CTEs in PostgreSQL.

AI and Intelligence Layer

The platform integrates three AI and formal reasoning systems, each serving a distinct role in the intelligence pipeline.

Claude (Anthropic)

Claude serves as the primary frontier AI model for code generation, complex analysis, and autonomous agent operations. The platform's 434 AIAD agents leverage Claude for reasoning-intensive tasks through the Claude Agent SDK, with session context management ensuring continuity across interactions.

Ollama -- Local AI

Ollama provides local AI inference with models running entirely on-premises. This addresses three requirements that cloud AI cannot: data sovereignty (sensitive intelligence data never leaves the local network), latency (sub-3-second responses without network round-trips), and availability (operates independently of external API availability).

The platform's Ollama integration supports automatic model selection based on task complexity and automatic fallback to cloud models when local inference quality is insufficient:

defmodule PrismaticOllama.Coordinator do
  @models %{
    fast: "qwen3-coder:7b",
    balanced: "deepseek-coder:6.7b",
    capable: "gpt-oss:20b"
  }

  def infer(prompt, opts \\ []) do
    tier = Keyword.get(opts, :tier, :balanced)
    model = Map.fetch!(@models, tier)

    case PrismaticOllama.Client.generate(model, prompt) do
      {:ok, result} -> {:ok, result}
      {:error, _} -> fallback_to_cloud(prompt, opts)
    end
  end
end

Lean 4 -- Formal Verification

Lean 4 is an interactive theorem prover and programming language used for formal verification of the platform's critical deduction chains. When the epistemic pipeline produces a high-confidence conclusion, Lean 4 can verify the logical structure of the reasoning chain through machine-checked proofs.

This is not a theoretical capability -- the platform maintains thousands of Lean 4 verification files in apps/prismatic_lean4/priv/deduction_verification/, each encoding a specific deduction that has been formally verified. The combination of statistical AI inference (Claude/Ollama) with formal mathematical proof (Lean 4) is a distinguishing architectural feature.

Frontend Stack

The frontend layer follows a server-first philosophy: LiveView handles interactivity on the server side, while the frontend technologies handle styling, component structure, and the minimal client-side behaviour that requires JavaScript execution.

TailwindCSS

TailwindCSS 3.4 provides utility-first CSS styling. Every visual element is styled through Tailwind utility classes -- no custom CSS files, no BEM naming conventions, no specificity wars. This constraint (enforced as a platform policy) ensures visual consistency and makes style changes grep-able:

<div class="bg-white dark:bg-gray-800 rounded-lg shadow-md p-6">
  <h3 class="text-lg font-semibold text-gray-900 dark:text-white">
    Security Rating
  </h3>
  <span class="inline-flex items-center px-3 py-1 rounded-full
               text-sm font-medium bg-green-100 text-green-800">
    Grade A
  </span>
</div>

Flowbite

Flowbite 2.3 extends TailwindCSS with pre-built UI components: modals, dropdowns, data tables, navigation bars, and charts. Using Flowbite's component library rather than building custom components reduces frontend development time while maintaining visual consistency across the platform's dashboards.

Alpine.js

Alpine.js handles the small subset of client-side interactivity that cannot be served by LiveView -- primarily dropdown toggle states, tooltip positioning, and animation triggers that must respond to user input without a server round-trip.

DevOps and Infrastructure

Docker

Docker provides development/production parity through containerized builds. The platform uses multi-stage Dockerfiles that separate compilation (with the full Elixir/Erlang toolchain) from the runtime image (Alpine Linux with only the compiled release), producing production images under 100 MB.

Fly.io

Fly.io hosts the platform's staging and production deployments. Fly.io's edge-native architecture maps well to Elixir releases -- the platform deploys as a single BEAM VM per region, with Fly.io handling TLS termination, load balancing, and geographic routing.

GitLab CI/CD

GitLab CI/CD orchestrates the platform's build pipeline: compilation with --warnings-as-errors, Credo static analysis, Dialyzer type checking, the full test suite, and deployment to Fly.io. The pipeline enforces the platform's quality gates -- a single warning, type error, or test failure blocks deployment.

Mix and Hex

Mix is Elixir's build tool, managing compilation, dependency resolution, test execution, and custom task definition. The platform defines 30+ custom Mix tasks for quality enforcement, benchmarking, code generation, and operational automation. Hex serves as the package registry, providing access to the Elixir ecosystem's 14,000+ packages.

Security Tooling

Security is enforced at multiple layers through specialized tools:

The security toolchain runs automatically on every commit through GitLab CI and pre-commit hooks. No code reaches the main branch without passing Sobelow (zero findings), Credo (strict mode, zero warnings), and Dialyzer (zero type violations).

Build and Development Tools

ExDoc

ExDoc generates the platform's 11,308 documentation files from inline @doc and @moduledoc attributes. Documentation is treated as a first-class artifact -- modules without documentation trigger compilation warnings that block deployment.

ExUnit

ExUnit is Elixir's built-in test framework, executing the platform's 5,864 test files. Tests run in parallel by default, with database sandboxing through Ecto's SQL sandbox for isolation. The platform uses property-based testing (StreamData) alongside example-based tests for critical business logic.

Zola

Zola generates the public-facing promotional site (the one you are reading now). Zola is a single-binary static site generator written in Rust, chosen for its compilation speed (sub-second builds for the entire site), zero runtime dependencies, and native Sass/SCSS compilation.

Git

Git provides version control with extensive platform-specific tooling. The platform's git-trees.sh script wraps git ls-tree for rapid codebase exploration (~80ms for 37,000+ files versus 500ms+ for find), and custom Git hooks enforce quality gates at commit, pre-push, and CI stages.

Conclusion

The Prismatic Platform's 45-technology stack is the product of deliberate engineering trade-offs, not feature accumulation. Each technology occupies a specific niche defined by its operational characteristics, integration profile, and long-term maintainability. The BEAM VM provides the fault-tolerant foundation. Phoenix and LiveView deliver real-time web interfaces without frontend framework complexity. Polyglot storage ensures each data access pattern uses an optimized engine. AI models augment human analysis without becoming single points of failure. Formal verification with Lean 4 provides mathematical certainty where statistical inference is insufficient.

The unifying principle across all eight layers is composability through well-defined interfaces. Storage adapters abstract persistence backends. The Plug pipeline composes HTTP middleware. PubSub decouples event producers from consumers. GenServer contracts define process communication. This interface discipline enables the platform to evolve individual technologies -- replacing Redis with a BEAM-native alternative, swapping Meilisearch for a different search engine, upgrading AI models -- without cascading changes through the codebase.

For detailed documentation on any individual technology, select from the catalog below or navigate directly to the technology detail pages linked throughout this overview.

Connect & Contribute

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

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