This FAQ is the interlinked reference manual for the Prismatic Platform — every question links to the glossary, to deeper architecture and capability pages, to the agent registry, and to the relevant doctrine policies. It is organized for non-linear reading: jump in by category, by direct anchor link (#q-platform, #q-nmnd, etc.), or by full-text search.

Abstract

The Prismatic Platform is an enterprise-grade AI-orchestrated intelligence and development infrastructure built on Elixir and the BEAM virtual machine. It comprises 92 umbrella applications, 552 autonomous AIAD agents, 121+ OSINT source integrations, and approximately 2.8 million lines of code, organized around the 3NL architecture and governed by 19 enforcement pillars. This FAQ consolidates the questions most frequently raised by developers, security professionals, intelligence analysts, M&A practitioners, and compliance officers evaluating or working with the platform.

The 57 answers below are organized into 11 thematic sections: platform overview, architecture and design, capabilities and features, development and workflow, quality and compliance, the 19-pillar doctrine, color-team security operations, due diligence workflows, integration and API, deployment and operations, and a glossary-and-conventions disambiguation. Every answer is self-contained but links to authoritative deeper material when readers want more depth. Where a Czech-language equivalent or context exists, it is signalled inline rather than duplicated as a parallel page.

How to read this FAQ · Each question carries a stable anchor (e.g. #q-3nl) for direct linking and citation. Answers begin with a one-line TL;DR, follow with the substantive explanation, and close with a Related line pointing to neighbouring questions, glossary entries, and feature pages. Doctrine references use the policy file paths under .aiad/policies/. Statistics are dynamic and computed by mix truth.report; occasional minor mismatches between the live count and the values cited here reflect the pace of platform evolution.

1. Platform Overview / Co je platforma

This section addresses foundational questions: what the platform is, what problem it solves, who it serves, what it is built on, and what "Generation 19" means.

1.1 What is the Prismatic Platform?

TL;DR · A single-runtime, Elixir/OTP intelligence-and-development infrastructure with 552 AIAD agents, 92 umbrella apps, 121+ OSINT sources, and a 19-pillar enforcement doctrine.

The Prismatic Platform is an AI-orchestrated intelligence, security, and development infrastructure implemented as an Elixir umbrella project. It comprises 92 OTP applications running on a single BEAM virtual machine, coordinated through supervision trees, PubSub event buses, and a pluggable storage adapter layer. The platform hosts 552 autonomous AI agents operating across 14 domains — from open-source intelligence gathering and external attack surface management to formal verification with Lean 4 theorem proofs.

At its core, the platform unifies capabilities that are typically fragmented across dozens of separate tools: OSINT data collection from 121+ sources, due diligence investigation workflows, security rating computation comparable to products like BitSight and SecurityScorecard, AI agent orchestration with epistemic quality controls, and a self-evolving quality infrastructure under the SEADF framework that has progressed through 19 generations of autonomous improvement. The entire system achieves microsecond inter-service latency without the operational complexity of distributed microservices, because all applications share the same Erlang runtime.

Deep dive · See /architecture/umbrella-apps/ for the application taxonomy, /registry/agents/ for the agent catalog, and /capabilities/aiad-standard/ for the AIAD framework specification.

Related · #q-problem · #q-audience · #q-elixir-choice · Glossary: AIAD · Architecture overview

1.2 What problem does the Prismatic Platform solve?

TL;DR · Consolidates dozens of fragmented intelligence, security, compliance, and development tools into one fault-tolerant, in-process runtime where data flows by direct function call rather than network API.

Intelligence, security, and compliance operations typically require teams to integrate dozens of specialised tools — threat intelligence feeds, OSINT databases, compliance assessment frameworks, security scanners, case management systems, and reporting platforms — each with its own data model, authentication scheme, and operational overhead. The Prismatic Platform consolidates these capabilities into a single, fault-tolerant runtime where data flows between subsystems through direct function calls and in-process message passing rather than network APIs.

This consolidation eliminates several categories of operational friction. Data enrichment that would require multiple API calls across separate services happens through parallel in-process queries. Security ratings that depend on asset discovery, vulnerability assessment, and compliance mapping are computed within a single supervision tree. Intelligence workflows that combine Czech registry data, global threat feeds, and sanctions screening share a unified entity model rather than requiring ETL pipelines between disconnected systems. The same runtime that performs OSINT enrichment also persists evidence into the event-sourced audit log and renders the LiveView dashboard the analyst is looking at — without crossing a network boundary.

The second class of problem the platform addresses is epistemic discipline. Most security and intelligence platforms produce findings with implicit confidence; Prismatic enforces explicit, traceable belief formation through the NABLA Infinity framework, the Trinity Gate verification barrier, and the QEVE quantified epistemic verification engine, so every conclusion can be audited back to its source signals.

1.3 Who is the Prismatic Platform designed for?

TL;DR · Four primary audiences — security teams, intelligence analysts, platform developers, and compliance officers — each with a dedicated landing page under /about/for-*/.

The platform serves four primary audiences, each with a tailored entry point:

Security teams use the Perimeter (EASM) module for external attack surface management, security ratings, and continuous compliance monitoring against frameworks like NIS2 and ZKB, and engage the color-team framework for adversarial-defensive simulation.
Intelligence analysts use the OSINT integration layer and due-diligence workflows to investigate entities across 121+ data sources, with particular depth in Czech government registries.
Developers working on the platform itself interact with the 552-agent ecosystem, the quality enforcement infrastructure, and the AIAD standard for defining new agents and commands.
Compliance officers use the automated compliance assessment engine to evaluate organizational posture against EU and Czech regulatory requirements, generating evidence-based reports with confidence scores and full provenance.

A fifth audience — executives and board members — is served by the executive portal with its own ROI calculator, board governance framework, and strategic risk assessment.

1.4 What programming languages and frameworks does the platform use?

TL;DR · Elixir on the BEAM, Phoenix for web, Ecto/PostgreSQL plus Meilisearch/KuzuDB/Redis/ETS for storage, Lean 4 for proofs, Claude+Ollama for AI, Tailwind/Flowbite for UI.

The primary implementation language is Elixir, running on the BEAM (Erlang Virtual Machine) with OTP (Open Telecom Platform) for fault tolerance and concurrency. Web interfaces are built with Phoenix Framework and LiveView for real-time server-rendered dashboards. The data layer uses PostgreSQL via Ecto as the primary relational store, ETS (Erlang Term Storage) for high-speed in-memory caching, Meilisearch for full-text search, KuzuDB for graph queries, and Redis for distributed caching and rate limiting. Formal verification uses Lean 4 for theorem proving. AI capabilities integrate Claude (Anthropic) for complex reasoning and local Ollama models (qwen3-coder, deepseek-coder, gpt-oss:20b) for low-latency inference. The front-end styling uses TailwindCSS with Flowbite components exclusively — custom CSS and inline styles are forbidden by the FLLM doctrine pillar.

A complete list of every technology in use is maintained at /technologies/, with 47 individual reference pages covering language tooling, web stack, storage, testing, DevOps, AI providers, and visualization libraries.

1.5 What does "Generation 19" mean?

TL;DR · A counter for measurable autonomous improvement cycles applied across the codebase — not a semantic version. Generation 19 reflects ongoing platform evolution under SEADF.

The platform tracks its evolutionary state using a generation counter. Each generation represents a measurable improvement cycle driven by autonomous evolution protocols coordinated by the SEADF framework and triggered through commands like /evolve, /auto, and /mycelialize. These protocols scan for quality improvements, detect code patterns that can be optimized, eliminate technical debt, and validate that the platform's fitness score (a composite metric covering quality, performance, and architectural health) improves or at least does not regress.

The platform has progressed from Generation 1 through Generation 19, achieving fitness scores in the 0.998–0.999 range — near the theoretical maximum. This is not a semantic version in the traditional sense; it reflects the cumulative effect of thousands of autonomous improvement cycles applied across the platform's 2.8 million lines of code. The current generation is reported by mix health.score and persisted in .claude/quality-dna/current-state.json for trend analysis.

2. Architecture and Design / Architektura a návrh

These questions cover the technical decisions underlying the platform's structure, runtime characteristics, and data architecture.

2.1 Why was Elixir/OTP chosen over other technology stacks?

TL;DR · Three requirements disqualify most runtimes: preemptive lightweight processes, per-process garbage collection with crash isolation, and hot code loading. BEAM/OTP is the only mature runtime that satisfies all three.

The choice is driven by three requirements that disqualify most runtime environments:

Preemptive scheduling. The BEAM scheduler provides preemptive scheduling across lightweight processes with sub-millisecond context switching, which is essential when 552 AI agents, LiveView dashboard connections, and background crawl jobs share the same runtime. Cooperatively-scheduled runtimes (Node.js, Python asyncio) cannot guarantee fair scheduling under load; thread-based runtimes (JVM, .NET) carry orders-of-magnitude higher per-task memory.
Crash isolation. Each Erlang process has its own heap and garbage-collects independently, meaning a crash in one process does not corrupt another's memory — OTP supervisors automatically restart failed processes according to configurable strategies, making the system self-healing at the process level.
Hot code loading. The BEAM supports hot code loading, enabling module replacement in a running system without dropping connections — directly relevant to the zero-downtime operations capability.

The platform also enforces a meta-rule to maintain idiomatic Elixir: "If the same solution could be written identically in Node.js, it is WRONG." This is documented in the platform's development module and enforced by Credo custom checks.

2.2 Why an umbrella project rather than microservices?

TL;DR · Microservice-like modularity (independent compilation, isolated tests, explicit deps) without microservice operational overhead — no service discovery, no network serialization, no container fleet, microsecond inter-app latency.

The umbrella structure provides microservice-like modularity — independent compilation, isolated testing, explicit dependency declarations enforced at compile time — without microservice operational overhead. There is no service discovery, no network serialization between components, no distributed tracing requirement, and no container orchestration complexity. All 92 applications share a single BEAM node, communicating through direct function calls and message passing with microsecond latency.

A failure in the Perimeter application's supervision tree does not propagate to the Web application's supervision tree because the top-level supervisor uses the :one_for_one restart strategy. This delivers fault isolation equivalent to separate services while maintaining the deployment simplicity of a monolith.

The trade-off is bounded: independent horizontal scaling per microservice is replaced by per-process scaling within the BEAM, and language polyglot is sacrificed (everything must run on the BEAM). For this platform's workload — high agent concurrency, shared in-memory state, frequent inter-app calls — the umbrella choice is dominant by an order of magnitude in latency and operational cost.

2.3 What is the 3NL (Three Nested Levels) architectural framework?

TL;DR · Strategic / Tactical / Operational layering enforced as a coupling rule: code at one level only calls into appropriate abstractions, never reaches into a deeper level's internals.

3NL is the architectural abstraction framework that organizes all platform components across three levels:

Level 1 (Strategic) encompasses public APIs, facade modules, and external interfaces — the surface that consumers interact with.
Level 2 (Tactical) covers inter-application coordination, pipeline orchestration, and agent messaging — the connective tissue between domains.
Level 3 (Operational) contains OTP process internals, ETS operations, and BEAM-level optimizations — the implementation details that consumers should never depend on.

The framework ensures that code at each level interacts only with appropriate abstractions. A LiveView controller at Level 1 calls a facade function at Level 1; it never reaches into a GenServer's internal state at Level 3. This is the first of the platform's 19 enforcement pillars, formalised as the "3NL" pillar in the doctrine catalog.

Related · #q-aiad · #q-doctrine-overview · Glossary: 3NL · Architectural pattern

2.4 What is the AIAD standard?

TL;DR · AIAD (AI-Agent Interface Definition) is the YAML-based machine-readable specification governing every agent, command, pipeline, policy, and adapter on the platform — 552 agents, 228 commands, all introspectable.

AIAD is the platform's specification format for defining agents, commands, pipelines, policies, and adapters. Every agent is defined in a YAML file under .aiad/agents/ with structured metadata including its name, domain classification, authority level (L1 through L5), available tools and capabilities, behavioural rules, input/output contracts, and compliance requirements with the NO MERCY / NO DOUBTS doctrine.

The standard enables machine-readable agent definitions that the platform's runtime can introspect, validate, and enforce. There are currently 552 AIAD-defined agents and 228 AIAD-defined commands across the platform. The AIAD auto-indexer (./.aiad/bin/aiad index) maintains a registry that keeps all agent and command metadata synchronized; the resulting catalog is exposed both at /registry/agents/ and /registry/commands/, and is queryable via the agent registry API.

The AIAD standard is vendor-neutral and polyglot — it does not assume a particular LLM vendor or a particular runtime. The current implementation runs on Elixir/BEAM, but the spec format would survive a re-implementation in another language.

2.5 How does the storage adapter architecture work?

TL;DR · A behaviour-based adapter pattern (PrismaticStorage.Adapter) that routes every read/write through a uniform interface; current adapters: ETS, Ecto/PostgreSQL, Meilisearch, KuzuDB, Redis.

The storage layer implements a behaviour-based adapter pattern through the PrismaticStorage.Adapter behaviour. All storage operations — store/3, fetch/2, delete/2, list/2 — route through this uniform interface regardless of the underlying backend. The platform currently implements five adapters:

Adapter	Use case	Latency	Persistence
ETS	In-memory caching, hot lookups	Microseconds	Process lifetime
Ecto/PostgreSQL	Relational data, ACID transactions	Milliseconds	Durable
Meilisearch	Full-text search, typo tolerance	Sub-50 ms	Durable index
KuzuDB	Graph queries (ownership, relationship)	Milliseconds	Durable
Redis	Distributed cache, rate limiting	Sub-ms (network)	Optional persist

Domain code never references a specific backend directly; it calls the adapter protocol, and the configuration determines which implementation handles the request. This makes it possible to swap storage backends without changing any domain logic. See the storage architecture deep dive and Academy: Storage Patterns for implementation walkthroughs.

2.6 How does supervision work in practice?

TL;DR · OTP supervision trees with :one_for_one strategies isolate failures; every GenServer has a defined restart policy; supervisor crash propagates to the application boundary, never further.

Each Prismatic umbrella application has its own supervision tree. The top-level Application module starts one or more supervisors, which in turn supervise GenServers, DynamicSupervisors, Tasks, and Registries. The most common restart strategies in use:

:one_for_one — only the failing child restarts. Used for siblings whose failures are independent.
:one_for_all — every sibling restarts when one fails. Used when children share state that becomes inconsistent on partial failure.
:rest_for_one — restart the failing child and every child started after it. Used for ordered initialization chains.

The platform standardizes on :one_for_one at the application top level so that a failure in one app's tree never propagates to another app. Within a tree, more aggressive strategies are used where consistency is paramount. For full background see Academy: OTP Fundamentals and Lab: Architecture Validation.

2.7 What is Phoenix PubSub used for?

TL;DR · A built-in distributed event bus connecting agents, LiveView processes, and the audit pipeline; same broadcast API works in single-node and clustered deployments.

Phoenix PubSub is the platform's in-process and inter-node event broadcast mechanism. Agents emit telemetry and domain events on named topics; LiveView processes subscribe to the topics they need to render in real time; the audit pipeline subscribes to all state-changing topics for event sourcing. The platform uses PubSub topics that combine a domain prefix and an entity identifier — for example, perimeter:scan:#{scan_id} — so subscribers can fan out by entity granularity without spamming unrelated processes.

PubSub also forms the substrate for /mycelialize cross-domain pattern propagation: when a pattern emerges in one domain, the relevant orchestrator broadcasts on a mycelium:emergence:#{pattern_id} topic, and other domains can subscribe to attempt local application.

Related · #q-supervision · #q-telemetry · Architecture: PubSub

2.8 How are PostgreSQL and KuzuDB combined?

TL;DR · PostgreSQL holds canonical entity records and transactional state; KuzuDB holds the relationship graph computed from those records. Updates flow Postgres → KuzuDB via change capture.

The platform combines PostgreSQL and KuzuDB in a hybrid relational-graph model. Postgres holds the canonical entity records — companies, persons, domains, emails, IPs — with their attributes, history, and transactional consistency. KuzuDB holds the relationship graph: ownership chains, director networks, address co-occurrence, infrastructure adjacency. Updates to canonical Postgres rows trigger relationship recomputation in KuzuDB through an event-sourced change-data-capture pipeline.

This split lets the platform serve two access patterns at appropriate speed: SQL aggregations and pivot tables run against Postgres, while traversal queries ("show me every Czech company sharing a director with target X within three hops") run against KuzuDB. The DD case-management workflow uses both: entity summary cards pull from Postgres, the visualization graph pulls from KuzuDB.

3. Capabilities and Features / Schopnosti a funkce

These questions cover the platform's intelligence gathering, security assessment, and AI orchestration capabilities.

3.1 What OSINT capabilities does the platform provide?

TL;DR · 121+ OSINT source adapters covering Czech registries, global threat feeds, sanctions lists, and crypto/blockchain — all behind a unified adapter interface with circuit-breaker fallback.

The platform integrates 121+ intelligence sources organized across multiple categories. Czech government registries include ARES (business register), Justice.cz (commercial register), RZP (trade licensing), the Insolvency Register, ČÚZK (land registry), CEDR (subsidies database), and ČNB (central bank data), among others — see /dd/czech-registries/ for the full list. Global intelligence sources include Shodan, Censys, VirusTotal, AbuseIPDB, GreyNoise, and specialized threat feeds. Sanctions screening covers OFAC SDN (US Treasury), the EU Consolidated Sanctions List, and UN Security Council sanctions with fuzzy entity matching.

All sources implement a standard adapter interface enabling hot-swapping, unified error handling, and circuit breaker protection. When a primary source fails, the system automatically falls to alternatives and then to cached data, maintaining continuous intelligence gathering even during multi-source outages. The full toolbox is browseable interactively at /hub/osint/ and exposed through the OSINT engines command.

Related · #q-ma-dd · #q-czech-registries · #q-easm · DD: OSINT Integration · Glossary: OSINT

3.2 What is the Perimeter (EASM) module?

TL;DR · Prismatic Perimeter is the platform's External Attack Surface Management capability — A–F security ratings on a 300-900 scale, automated asset discovery, and NIS2/ZKB compliance assessment. Comparable to BitSight and SecurityScorecard.

Prismatic Perimeter is the platform's External Attack Surface Management capability, designed to compete with commercial products like BitSight, Black Kite, and SecurityScorecard. It provides:

A–F security ratings computed on a 300–900 numeric scale, exposed via /api/v1/perimeter/rating.
Automated asset discovery across domains, IP addresses, TLS certificates, cloud resources, and exposed services — see /api/v1/perimeter/discover and Lab: EASM Discovery.
Compliance assessment against the NIS2 Directive (EU 2022/2555) and ZKB (Czech Cybersecurity Act 264/2025 Sb.), at /api/v1/perimeter/compliance.

Ratings are evidence-based with confidence levels attached to each finding. The module exposes a real-time LiveView dashboard at /perimeter with sub-pages for asset inventory, compliance assessment, and the advanced EASM view. For developer integration patterns, see Academy: EASM Development.

Related · #q-osint · #q-nis2-zkb · #q-nis2-zkb · Capabilities: EASM · Glossary: EASM

3.3 What are color teams and how do they operate?

TL;DR · Six adversarial-defensive teams (Gray, Red, Blue, Purple, White, Black) totalling 20 specialized agents; safety protocols enforce sandboxed synthetic data only.

The platform implements six color-coded security teams with 20 specialized agents (deep dive at /capabilities/color-teams/):

Team	Agents	Role	Mode
Gray	3	Boundary exploration, edge case discovery	Read-only
Red	4	Adversarial simulation, epistemic attack primitives	Sandboxed, synthetic data only
Blue	4	Defensive posture, evidence synthesis, drift detection	Active monitoring
Purple	4	Red-Blue feedback closure, regression-trap detection	Coordinator
White	3	Constructive verification, property-based testing, Lean 4 proofs	Verifier
Black	2	Abstract threat modelling, no executable content	Maximum isolation

The Red team's five epistemic attack primitives — truth distortion, confidence manipulation, signal poisoning, drift induction, and salience hijacking — execute exclusively in sandboxed environments with synthetic data only. The Black team operates under maximum isolation, producing abstract threat models without ever generating executable content. All teams operate under strict safety protocols: no real data, no network access for Red/Black operations, and automated ethics checks every 10–15 seconds.

The deeper team-level documentation lives at /teams/red/, /teams/blue/, /teams/purple/, /teams/gray/, /teams/white/, and /teams/black/. Color-team simulation experiments run at Lab: Color Team Simulation.

3.4 What is NABLA Infinity and the Trinity Gate?

TL;DR · NABLA Infinity (∇∞) is the platform's epistemic framework with seven non-negotiable axioms; the Trinity Gate is the three-layer validation barrier that every belief must pass before it can influence a decision.

NABLA Infinity is the platform's epistemic framework governing how beliefs are formed, validated, and propagated through the system. It enforces seven non-negotiable axioms:

Signal Plurality — minimum two independent signals for any belief.
Contradiction Evidence — both sides of conflicts must be preserved.
Absence Informative — missing signals are tracked as evidence.
Time Decay — mandatory timestamps on all data.
Unknown Valid — "I don't know" is an acceptable and honest response.
Source Independence — independent sources receive higher weight.
Provenance Mandatory — all beliefs must be traceable to their origin.

The Trinity Gate is a three-layer validation barrier that every belief must pass before influencing decisions:

Structural Consistency — graph-theoretic validation.
Logical Consistency — rule-based evaluation.
Formal Necessity — modal logic verification with optional Lean 4 proof.

If any gate fails, the operation is halted for review. Together, NABLA + Trinity power the QEVE (Quantified Epistemic Verification Engine) that translates AI-grade scores into legally defensible conclusions — see the QEVE deep dive.

3.5 How does the AI Drift detection system work?

TL;DR · The ai_drift application monitors AI-assisted decisions for statistical drift using Kolmogorov–Smirnov and Cramér–von Mises tests; alerts fire on distribution shift; a governance registry tracks every AI-influenced decision.

The AI Drift module (application ai_drift) monitors AI-assisted decisions for statistical drift from established baselines. It uses Kolmogorov–Smirnov and Cramér–von Mises statistical tests to detect when the distribution of AI outputs has shifted significantly from the baseline distribution. When drift is detected, the system generates alerts through configurable channels (webhooks, PubSub events, dashboard notifications), logs the drift event with full provenance, and can trigger automatic baseline recomputation.

The module includes a governance decision registry for tracking which AI-influenced decisions were made and their outcomes over time. This is particularly relevant for compliance contexts (e.g., the EU AI Act and NIS2 reporting) where organizations must demonstrate that AI systems are operating within expected parameters. Sub-threshold drift detection is studied in detail at Lab: Drift Detection.

3.6 Does the platform support M&A due diligence?

TL;DR · Yes — /ma-create, /ma-analyze, /ma-report are the M&A-specific commands; the Czech registry suite plus graph analysis plus triple verification is the differentiator over generic DD tools.

Yes. The platform's M&A intelligence capability automates significant parts of pre-LOI due diligence. The workflow runs from target identification through entity normalization, beneficial-ownership traversal in KuzuDB, sanctions screening, Czech registry deep dive (ARES, Justice.cz, ISIR, RZP, ČÚZK), risk scoring, and report generation. Commands /ma-create, /ma-analyze, /ma-report, and /ma-status drive the lifecycle; the /ma-dashboard command surfaces an interactive deal view.

Triple-verification methodology requires every finding to be corroborated across independent sources before it earns a place in the final report — this is the NABLA Signal Plurality axiom expressed at the workflow level. Risk scores are produced on a seven-dimensional rubric with A–F grades on a 300–900 numeric scale, mirroring the Perimeter approach.

3.7 What is the Academy and how does it relate to the platform?

TL;DR · /academy/ is the interactive learning system — 18 hands-on courses from "Getting Started" through formal verification and EASM development, each tied to working code in apps/prismatic_academy/.

The Academy is the platform's interactive learning system, implemented as a PrismaticAcademy.Topic behaviour under apps/prismatic_academy/ with content rendered through LiveView. It currently hosts 18 courses spanning Getting Started, Building Your First Autonomous Agent, The AIAD Standard Explained, Multi-Agent Orchestration Patterns, Decision Core Fundamentals, API Integration, Development Workflow & CI/CD, OTP Fundamentals, Storage Patterns, Building LiveView Dashboards, Color Team Security, DD Investigation Techniques, Quality Standards, Applying NABLA Infinity Axioms, Self-Evolving Agent Ecosystems, Formal Verification with Lean 4, Building EASM Features, and Monte Carlo Fundamentals.

Each topic interconnects with the glossary and the experimental Lab, so a reader can move from a definition in the glossary to a course in the Academy to an experiment in the Lab to the production code in apps/. The KNOW doctrine pillar requires this triad — glossary, Academy, Lab — for every significant module.

4. Development and Workflow / Vývoj a pracovní postup

These questions address how developers work with the platform, run tests, and contribute code.

4.1 How do I get started with the platform?

TL;DR · Clone, install Elixir 1.19+/OTP, just setup, just serve — production-grade dev server with quality gates and sub-250 ms page loads. Full path documented in /about/for-developers/.

The basic setup sequence is: clone the repository, install Elixir 1.19+ and Erlang/OTP, then run mix deps.get to fetch dependencies, mix compile to build the platform (approximately 45 seconds for a clean build), and mix test to execute the test suite. The platform requires PostgreSQL for persistent storage and optionally Redis and Meilisearch for full capabilities.

The repository ships a comprehensive justfile — preferred over raw mix commands. Key recipes:

just setup — complete environment setup.
just serve — development server (port 4000, sub-250 ms page load target per PERF doctrine).
just quality — full quality-gate enforcement (mandatory before commit).
just test — full test suite + coverage.
just deploy-validate staging — deploy + post-deploy validation.

For codebase exploration, the platform provides mix git_trees (or the faster shell script ./scripts/git-trees.sh) which operates approximately 100× faster than standard find commands on the 15,000+ file repository. Individual applications can be compiled and tested in isolation with mix test apps/prismatic_perimeter. The Academy: Getting Started course walks through the sequence interactively.

4.2 How do I create a new AIAD agent?

TL;DR · Drop a YAML file under .aiad/agents/, run ./.aiad/bin/aiad index, the runtime auto-registers it. Every agent must include the NMND compliance block.

Create a YAML file under .aiad/agents/ following the agent-spec schema. The file must define the agent's name, description, domain classification, authority level (L1–L5), available tools and capabilities, behavioural rules, input/output contracts, and NMND enforcement compliance block. After creating the file, run ./.aiad/bin/aiad index to update the agent registry. The platform will automatically discover and validate the new agent definition at the next boot. Every agent must include the mandatory enforcement block declaring compliance with the NO MERCY / NO DOUBTS doctrine.

The interactive Academy: First Agent course walks through this end-to-end with a concrete OSINT-collector example.

4.3 How do I add a new command to the platform?

TL;DR · Same AIAD pattern: YAML under .aiad/commands/, run the indexer, command becomes available globally. 228 commands currently registered.

Commands follow the same AIAD standard as agents. Create a YAML file under .aiad/commands/ following the command-spec schema, defining the command's name, syntax, description, parameters, execution logic, and authorization requirements. Run ./.aiad/bin/aiad index to register it. Commands can be invoked through the platform's command interface and are discoverable through the command registry at .claude/COMMAND_REGISTRY.md.

ℹ Note · Commands and skills are different concepts — see #q-skills-vs-commands for disambiguation. The 228-command registry counts AIAD commands; Claude Code skills are tracked separately.

Related · #q-create-agent · #q-skills-vs-commands · Glossary: Command

4.4 What is the testing strategy?

TL;DR · Multi-layer (unit + property + integration + E2E + performance benchmarks); 6,500+ test files under TACH doctrine; every bug fix requires a regression test under NMND.

The platform uses a multi-level testing approach with 6,500+ test files. Unit tests use ExUnit with the Arrange-Act-Assert pattern. Property-based testing discovers edge cases through random input generation. Integration tests run against real database instances rather than mocks. End-to-end tests validate complete workflows using Wallaby and Playwright across Phoenix LiveView. The test suite is organized into three phases: Phase 1 (Workflow/Step tests), Phase 2 (Storage/Web/Agent tests), and Phase 3 (E2E tests).

Every bug fix requires mandatory regression tests following a strict protocol: identify the root cause, create a test that fails with unfixed code, apply the fix, verify the test passes. Commits are blocked without compliance — this is the TACH and NMND doctrines acting in tandem. The --no-verify flag is forbidden.

4.5 How do quality gates work?

TL;DR · Pre-commit blocks 8 doctrine pillars; CI enforces 17. Quality Floor Guardian escalates from OPTIMAL → WARNING → CRITICAL → EMERGENCY when scores degrade.

Quality gates are automated pre-commit checks that all must pass before any code can be merged. The gate sequence includes: zero compilation warnings (enforced with --warnings-as-errors), Credo strict mode compliance (all checks must pass), Dialyzer type analysis (full PLT verification), test suite passage, coverage requirements, and zero Quality Debt Points.

The Quality Floor Guardian monitors these metrics continuously with four escalation levels:

Level	Range	Action
OPTIMAL	100%	Monitor only
WARNING	98-99%	Alert and investigate
CRITICAL	95-98%	Auto-evolution trigger
EMERGENCY	<95%	Block commits and escalate

The platform currently maintains a perfect 100/100 quality score across all quality domains with zero violations. See #q-doctrine-overview for the full pillar list, and mix health.score for the live metric.

4.6 What is /archer-supreme and when do I use it?

TL;DR · /archer-supreme is the strict-quality multi-agent orchestrator for impossible missions: parallel agent dispatch, mandatory health-aware checks, no --no-verify escape hatches, full context preservation.

ARCHER SUPREME is the platform's ultimate-authority orchestration command for missions that demand zero-error completion under strict quality enforcement. Invocations decompose the mission into 2–4 parallel investigation tracks, dispatch them as concurrent agent calls, synthesise the results, execute, and validate — all under mandatory doctrine compliance. Pre-mission and post-mission health checks are part of the protocol, so feature work is gated on system stability.

Use /archer-supreme when the mission is either large (multi-file, multi-app), high-risk (touches infrastructure or doctrine), or "impossible" (the user has framed it as so). For routine multi-step work, prefer the lighter-weight /mycelialize which favours emergent multi-agent coordination over strict enforcement.

4.7 What is /mycelialize?

TL;DR · /mycelialize is the default multi-agent orchestrator — biological-pattern-inspired emergence, network healing, cross-domain pattern propagation. Recommended for ~95% of tasks.

/mycelialize is the platform's recommended orchestration command for AI-assisted multi-agent work. It applies a biological mycelium metaphor: when a useful pattern emerges in one domain, the orchestrator detects it, broadcasts via PubSub, and other domains attempt local propagation. Variants include /mycelialize-living (live AST + introspection), /mycelialize-formal (Lean 4 + Prolog formalisation), and /mycelialize-enforced (QDP-strict mode).

The Lab: Mycelial Propagation experiment tracks success rates of cross-domain pattern transfer over time.

Related · #q-archer · #q-mycelialize · Lab: Mycelial Propagation

5. Quality and Compliance / Kvalita a soulad

These questions address the platform's quality-enforcement philosophy, compliance capabilities, and operational standards.

5.1 What does "NO MERCY, NO DOUBTS" mean in practice?

TL;DR · NMND = zero placeholders, zero stubs, zero TODOs in lib/; full investigation before action; evidence backing for every claim; --no-verify forbidden.

NO MERCY / NO DOUBTS is the platform's universal doctrine governing all development and operational decisions.

NO MERCY enforces zero tolerance for incomplete implementations, untested code, quality violations, stubs, mocks, placeholders, TODOs, or FIXMEs. Every line of code must be production-ready from the moment of creation. All quality gates must pass before any merge. Bug fixes without regression tests are rejected. The --no-verify flag is absolutely forbidden.

NO DOUBTS requires full investigation before action, decisive execution once a decision is made, evidence backing for every claim (through tests, benchmarks, or Lean 4 verification), and validated results with no unvalidated claims or unchecked outputs. Violations are classified from L1 (minor deviation, warning plus immediate correction) through L4 (doubt-compromised, rejection plus supreme review).

In practice: a developer writing a stub function will be blocked at pre-commit by the NMND grep-scan; a lib/ file containing TODO: will block the commit; a bug fix without a regression test will block the commit; an answer to a customer question that cannot be evidenced from the codebase or telemetry is treated as a doubt violation and rolled back.

5.2 What is the platform's quality score and how is it measured?

TL;DR · Composite over 13 domains, 100/100 target, computed dynamically by mix health.score and persisted in .claude/quality-dna/current-state.json — no hand-edited numbers (NCLB).

The platform maintains a 100/100 quality score measured across 13 domains: Dialyzer (type analysis), Credo (code quality), Compilation (zero warnings), DateTime Precision, Guard Functions, @impl Coverage, Memory Safety, Performance, Regression Prevention, Timing Patterns, TODO Management, Typespec Coverage, and Unsafe Map Access. Each domain must show zero violations for the score to remain at 100.

The Quality DNA system (.claude/quality-dna/current-state.json) persists quality metrics across development sessions, enabling trend analysis and regression detection over time. Counts are dynamic — the NCLB doctrine pillar forbids hardcoded values and requires every claim to be evidenced from the live codebase via mix truth.report and friends.

5.3 How does the platform handle NIS2 and ZKB compliance?

TL;DR · The Perimeter compliance engine maps controls to NIS2 (EU 2022/2555) and ZKB (Czech Cybersecurity Act 264/2025 Sb.); generates gap analysis, compliance scores, and remediation guidance.

⚠ Regulatory disclaimer · Compliance assessments produced by the platform are decision-support outputs, not legal advice. Final compliance certification requires sign-off from a qualified legal/compliance professional and is a customer responsibility.

The Perimeter compliance engine maps security controls to the requirements of the NIS2 Directive (EU 2022/2555) and the Czech Cybersecurity Act (ZKB 264/2025 Sb.). For each framework, the engine evaluates the target organization's security posture against the specified control requirements, generates gap analysis reports identifying areas of non-compliance, computes compliance scores with confidence levels, and produces remediation guidance.

Compliance assessments can be triggered programmatically through the Elixir API (PrismaticPerimeter.assess_compliance/2) or through the REST API and the LiveView dashboard at /perimeter/compliance. Continuous re-assessment runs on a schedule and emits PubSub events for any control whose status changes, enabling real-time compliance dashboards.

5.4 What audit and traceability features exist?

TL;DR · Immutable append-only audit log via prismatic_audit; event sourcing for critical subsystems; NABLA Provenance Mandatory axiom extends traceability into the epistemic layer.

The platform implements immutable, append-only audit logging through the prismatic_audit application. Every state-changing operation produces an audit record with full provenance — who performed the action, when, from what context, and with what parameters. The NABLA Provenance Mandatory axiom extends this to the epistemic layer: every belief formed by the system must be traceable to its source signals.

The combination of audit logging, event sourcing for critical subsystems, and epistemic provenance tracking provides a comprehensive traceability chain from raw intelligence signals through synthesized beliefs to the decisions and actions they inform. For audit-trail integration patterns see Capabilities: Telemetry Integration and the OTEL doctrine pillar.

5.5 What is the regression test protocol?

TL;DR · Identify root cause → write a failing test → apply fix → confirm pass. Mandatory under TACH + NMND. Bug fixes without regression tests are blocked by pre-commit.

The regression test protocol is non-bypassable. Every bug fix must include a regression test plus a validation report following this template:

Identify the root cause — not the symptom; the underlying defect.
Write a test that fails with the unfixed code, demonstrating the bug.
Apply the fix to make the test pass.
Verify the test passes and that no other tests regress.
Document the fix in commit message with Refs: to the originating issue (GITL doctrine).

The pre-commit hook inspects the commit set for the presence of new tests when files matching bug-fix patterns are touched; commits that look like fixes without accompanying tests are rejected. The full template lives in .aiad/policies/ under the regression doctrine.

6. Doctrine Pillars / Pilíře doktríny

The platform is governed by a 19-pillar enforcement doctrine. This section defines each pillar at a level appropriate for an external reader: what it forbids, what it requires, where it is enforced, and where to find authoritative policy text.

6.1 What is the 19-pillar doctrine?

TL;DR · A list of 19 acronym-named enforcement principles (3NL, NMND, NWB, FLLM, M5M, NCLB, TACH, ZERO, PERF, SEAL, DEPS, DOCS, OTEL, GITL, KNOW, RDME, NLLB, HYGIENE, CZE) — each backed by a policy file under .aiad/policies/, most enforced at pre-commit and/or CI.

The doctrine is the platform's universal enforcement layer. Each pillar is named by a short acronym and backed by a policy file under .aiad/policies/. The matrix below shows the full set:

Pillar	Full name	Pre-commit	CI	Note
3NL	Three-Nested-Loops Architecture	—	—	Architectural philosophy (#q-3nl)
NMND	No Mercy, No Doubts	✅ BLOCK	✅	#q-nmnd
NWB	No Way Back	—	✅	Permanent fixes, no backward-compat shims
FLLM	Flowbite LLM CSS Hygiene	advisory	✅	#q-fllm
M5M	Max 5 Minutes (granular execution)	advisory	✅	Tasks ≤ 5 min
NCLB	No Claim Left Behind	—	✅ BLOCK	Evidence-based stats
TACH	Total Assurance Comprehensive Hardened	✅ BLOCK	✅	#q-tach
ZERO	Zero Error Runtime Operations	✅ BLOCK	✅	#q-zero
PERF	Performance Engineering Runtime Fence	✅ BLOCK	✅	#q-perf
SEAL	Security Enforcement Absolute Lock	✅ BLOCK	✅	#q-seal
DEPS	Dependency Engineering Protection	✅ BLOCK	✅	mix.exs/mix.lock hygiene
DOCS	Documentation Standard	—	✅ BLOCK	@moduledoc + @doc + @spec required
OTEL	Observability Telemetry	—	✅	#q-telemetry
GITL	GitLab Integration & Traceability	—	✅	#q-gitl
KNOW	Knowledge Coverage	—	advisory	Glossary + Academy + Lab triad
RDME	README Required In Every App	✅ BLOCK	✅	Nested README scaffolding
NLLB	No Link Left Behind	—	✅	Broken-link scanner
HYGIENE	Repository Hygiene	✅ BLOCK	✅	No `.DS_Store`, build artifacts
CZE	Czech-Language Excellence	bash hook	—	#q-cze

8 pillars block at pre-commit (ZERO, SEAL, PERF, HYGIENE, NMND, TACH, DEPS, RDME); 17 pillars enforced in CI via mix check.doctrines (3NL is architectural philosophy; CZE is enforced via a separate bash hook). The full text of each policy lives at .aiad/policies/.

⚠ --no-verify is forbidden · Bypassing pre-commit hooks is a direct doctrine violation and is rejected by the policy. All 19 pillars are active for every commit, with no opt-out.

6.2 What is the NMND pillar in detail?

TL;DR · Detects TODO / FIXME / HACK / stub / placeholder patterns in lib/ code; blocks the commit with a hard error. No exemptions.

NMND (No Mercy, No Doubts) is the most-cited pillar of the doctrine and pairs with TACH and ZERO to form the production-readiness floor. It is enforced as a pre-commit grep scan over staged files: any of the patterns TODO, FIXME, HACK, XXX, pass, stub, placeholder appearing in lib/ code triggers an immediate block. Tests, scripts, and documentation are not in scope (those have their own pillars).

The pillar exists because every developer is tempted to leave "I'll come back to this later" markers — and on a 15,000-file codebase, "later" is the enemy of correctness. NMND treats half-implementations as worse than no implementation: the latter signals work-to-do, the former signals work-already-done.

Related · #q-nmnd-practice · #q-tach · #q-zero · Glossary: No Mercy, No Doubts

6.3 What is the ZERO pillar?

TL;DR · Detects 8 BEAM-specific runtime-failure anti-patterns: bare rescue, String.to_atom/1 on user input, unsafe binary_to_term/1, unsafe map dot in HEEx, blocking GenServer.call in async handlers, and similar.

ZERO (Zero Error Runtime Operations) prevents the BEAM-specific runtime failures that the type system cannot catch:

bare rescue — catches everything including system exits; specific exception lists required.
String.to_atom/1 on unbounded input — atom table is finite and not GC'd; whitelist-based atom creation required.
binary_to_term/1 without :safe opt — code-injection vector.
Unsafe map dot notation in HEEx — raises KeyError at render time.
Blocking GenServer.call from a handle_info/2 — deadlock pattern.
Etc. — full list in policy.

Marker comments (# ZERO:RESCUE_OK - reason) above an intentionally-defensive rescue exempt that line, so the pillar can be locally suspended for justified cases like the LiveView mount hardening pattern.

Related · #q-perf · #q-seal · #q-doctrine-overview

6.4 What is the SEAL pillar?

TL;DR · Three-layer defense (pre-commit grep + Mix task + AST analysis) covering 12 OWASP Top 10 vulnerabilities: SQL injection, code injection, command injection, open redirect, path traversal, mass assignment, hardcoded secrets, log leakage, unsafe deserialization, insecure randomness, SSRF.

SEAL (Security Enforcement Absolute Lock) is the platform's security-doctrine pillar. It detects 12 OWASP Top 10 categories through a three-layer defense:

Pre-commit grep — fast scan of staged files for obvious patterns (string interpolation in SQL, hardcoded API keys, Mix.shell with user input).
Mix task — mix seal.validate runs deeper checks against the full codebase.
AST analysis — mix credo plus custom Credo checks for context-sensitive issues.

The policy gives line-level guidance for false positives, and supports # SEAL:EXEMPT - reason markers for justified exceptions. See also the Capabilities: Compliance page and the broader security review skill.

Related · #q-zero · #q-perf · About: For Security · Capabilities: Compliance

6.5 What is the PERF pillar?

TL;DR · Detects N+1 queries, unbounded queries, string concatenation in loops, list-append in loops, blocking sync calls, inefficient empty checks. Sub-250 ms page-load fence.

PERF (Performance Engineering Runtime Fence) is the performance-discipline pillar. Static analysis at commit time detects:

N+1 query patterns in Ecto usage.
Unbounded queries missing limit/2.
String concatenation in loops (use interpolation or IO.iodata).
List append in loops (use prepend + reverse or Enum.into/2).
Blocking sync calls in GenServer.handle_call/3 without timeouts.
Inefficient empty checks (length(list) == 0 vs list == []).

Performance fences also enforce absolute limits: page load <250 ms, server render <100 ms, LiveView mount <150 ms, health check <10 ms. Misses are logged via OTEL and surfaced on the platform health dashboard.

Related · #q-zero · #q-telemetry · #q-quality-gates

6.6 What is the TACH pillar?

TL;DR · "Total Assurance Comprehensive Hardened" — every module needs unit tests, every pure function needs property-based tests, every cross-app boundary needs an integration test, every LiveView needs E2E.

TACH requires a four-layer test pyramid for every part of the platform. The pre-commit hook flags missing tests when source files in lib/ are added or modified without corresponding tests. The CI pipeline runs the full test suite (6,500+ files) and fails the pipeline if coverage drops below the configured floor.

Marker comments (# TACH:EXEMPT - reason) above a defmodule exempt that module, used sparingly for behaviour modules, runtime-only adapters, and modules whose coverage is delivered through their consumers' tests.

Related · #q-testing · #q-regression · #q-nmnd

6.7 What is the FLLM pillar?

TL;DR · "Flowbite LLM CSS Hygiene" — UI must use only Flowbite components and Tailwind utilities. Inline style= and custom CSS forbidden except via @apply with explicit markers.

FLLM enforces strict design-system compliance: every HTML/HEEx/LiveView/Zola template must use Flowbite components and Tailwind utility classes only. Inline styles, raw CSS, and ad-hoc class declarations are forbidden. The pillar exists because the platform integrates many AI-assisted UI generators, and each is tempted to invent its own CSS — FLLM forces convergence on a single well-tested design system.

Advisory in pre-commit, blocking in CI. Exemptions require  markers in HEEx or template files.

Related · #q-stack · #q-doctrine-overview

6.8 What is the GITL pillar?

TL;DR · GitLab Integration & Traceability. Conventional-commit prefixes (feat: / fix: / refactor: / etc.); every commit references a GitLab issue (Refs: #123, Closes #456); full traceability requirement → implementation → verification.

GITL requires:

Conventional-commit prefix on the commit subject (feat:, fix:, refactor:, perf:, build:, ci:, style:, test:, revert:, docs:, chore:).
GitLab issue reference in the body (Refs: #123 for in-flight, Closes #456 for completed).
Subject line ≤ 72 characters.
Co-author footer for AI-assisted commits.

The [skip-gitl] marker bypasses the GitLab-issue requirement for routine docs/cleanup commits. The pillar pairs with /gitlab-sync and /gitlab-mr for the full lifecycle.

Related · #q-doctrine-overview · Glossary: GitLab CI

6.9 What is the CZE pillar?

TL;DR · Czech-Language Excellence — governance docs in Czech (cs-CZ), code/tech identifiers in English. Bilingual structure for top-level docs.

CZE governs the bilingual nature of the platform's documentation. The rule:

Default language for prose, summaries, status updates, and section headings: Czech (cs-CZ).
Always English: code identifiers, Elixir/Phoenix idioms (defmodule, @moduledoc, etc.), package names, log severity tokens, conventional commit prefixes, technical terms with global meaning.
Bilingual governance docs: Czech headlines/rationale + English technical body for CLAUDE.md, AGENTS.md, AIAD policies, top-level READMEs.
Mirror the user: if a user writes in English, reply in English. User-supplied language directive in turn always wins.

The CZE pillar runs at Level 3 STRICT for P0 paths (CLAUDE.md, AGENTS.md, README.md, AGENT_REGISTRY.md), advisory for other governance docs. Bypass markers: [skip-cze] per commit,  per file, CZE_BYPASS=1 for emergency.

Related · #q-doctrine-overview · Glossary: 3NL

7. Color-Team Security Operations / Bezpečnostní operace barevných týmů

This section deep-dives into the color-team framework introduced in #q-color-teams.

7.1 What does the Red team actually do?

TL;DR · Adversarial simulation of epistemic attacks (truth distortion, confidence manipulation, signal poisoning, drift induction, salience hijacking) — sandboxed, synthetic data only, ethics-checked every 10–15 seconds.

The Red team consists of 4 specialized agents that simulate adversarial attacks against the platform's epistemic and decision-making layers. The five primitive attack patterns:

Truth distortion — inject signals that subtly bias the NABLA Signal Plurality computation.
Confidence manipulation — force confidence scores into ranges that bypass Trinity Gate thresholds.
Signal poisoning — submit malformed-but-plausible source data to test downstream resilience.
Drift induction — submit decision sequences calibrated to push AI Drift detection into false-negative territory.
Salience hijacking — attempt to dominate the agent's attention mechanism with crafted prompts.

All Red operations run in sandboxes with synthetic data only. The Red team has no network access during operations and is monitored by the Purple team for closure — every adversarial finding becomes a defensive test case.

Related · #q-color-teams · #q-blue-deep-dive · #q-purple-deep-dive · Teams: Red

7.2 What does the Blue team do?

TL;DR · Defensive posture: aggregate signals, detect drift, maintain evidence synthesis pipelines, surface anomalies to the Purple team for engagement.

The Blue team consists of 4 agents responsible for the defensive side of the color-team framework. Its responsibilities:

Signal aggregation — collect telemetry, alerts, and OSINT findings into the intelligence synthesis pipeline.
Drift detection — monitor behavioral, adversarial, configuration, and anomaly drift across all monitored systems.
Evidence synthesis — compose multi-source evidence into NABLA-compliant belief structures.
Anomaly escalation — surface unusual findings to the Purple team for engagement-loop closure.

Blue operates in active monitoring mode, distinct from Red's sandboxed mode. Its outputs feed the /perimeter LiveView dashboard and the DD case management workflow.

Related · #q-color-teams · #q-red-deep-dive · #q-purple-deep-dive · Teams: Blue

7.3 What does the Purple team do?

TL;DR · Synthesizes Red and Blue: every adversarial finding becomes a regression test; tracks closure rates, false-closure detection, and engagement metrics.

The Purple team (4 agents) operates as the orchestrator of the Red-Blue adversarial-defensive engagement loop. Its mission is to ensure that no Red finding is left without a Blue response, and no Blue defense is left without Red verification.

Concretely, the Purple team:

Tracks closure — every Red finding has a Blue response logged; every Blue defense has a Red verification.
Detects false closures — defensive responses that don't actually neutralize the attack pattern.
Manages regression traps — converts Red findings into permanent test cases under the TACH doctrine.
Reports synthesis — emits engagement metrics (closure rate, false-closure rate, regression-trap count) on a PubSub topic consumed by the executive security dashboard.

The Lab: Color Team Simulation experiment publishes weekly synthesis metrics.

7.4 What about Gray, White, and Black teams?

TL;DR · Gray explores boundaries (read-only), White constructs formal proofs (Lean 4 + property-based), Black does abstract threat modelling under maximum isolation (no executable content).

The remaining three color teams cover edges of the engagement spectrum:

Gray team (3 agents) — read-only boundary exploration and edge-case discovery. Gray operates without changing system state; it's the "what if?" team. Findings feed the Lab: Drift Detection pipeline.
White team (3 agents) — constructive verification through property-based testing and Lean 4 formal proofs. White is the team that produces the "yes, this invariant holds" proofs that ground the QEVE verification engine. See Academy: Formal Verification with Lean 4.
Black team (2 agents) — abstract threat modelling under maximum isolation. Black produces written threat models without ever generating executable code. Outputs feed Strategic Risk Assessment reports for board-level review.

⚠ Black-team isolation · Black operates in a network-isolated environment, generates only abstract documentation, and is reviewed by the Purple team before any output enters the broader platform. This is a deliberate safety choice for high-imagination, low-actionability threat work.

8. Due Diligence and Investigations / Due diligence a vyšetřování

This section covers the DD platform workflow and the Czech-registry integration depth.

8.1 How does case management work?

TL;DR · A cases/ directory per investigation with a structured layout (README.md, SOURCES.md, TIMELINE.md, EVIDENCE/), backed by event-sourced database persistence and a real-time dashboard.

The DD case-management workflow treats each investigation as a directory under cases/ with a stable layout. Every state transition (entity discovery, evidence ingestion, source addition, finding promotion) emits an event into the audit log. The real-time dashboard at /investigations lets analysts triage active cases, drill into the graph view, and export a final report. Triple-verification (NABLA Signal Plurality) governs evidence admission: a finding is not admitted into the report unless ≥2 independent sources corroborate it.

8.2 What Czech registries are integrated?

TL;DR · 30+ Czech sources including ARES, Justice.cz, ISIR (insolvency), RZP (trade licensing), ČÚZK (cadastre), CEDR (subsidies), ČNB (central bank), CzechPOI / DataKO, the Trade Register, and more.

The Czech registry integration is the platform's deepest country-specific intelligence stack. The 30+ integrated sources include:

ARES (business register / IČO lookup)
Justice.cz (commercial register, court files, sbírka listin)
ISIR (insolvency register)
RZP (trade licensing)
ČÚZK (cadastre / land registry)
CEDR (subsidies database)
ČNB (central bank data, sanctions)
DataKO / Datové schránky (electronic mailbox lookup)
VFZ ÚDHPSH (political-party financial reports)
OFAC SDN, EU Consolidated, UN Security Council (sanctions)

…plus specialized sources for regulated industries (SUKL for pharmaceuticals, Energetický regulační úřad for energy, etc.). Each source has its own adapter under apps/prismatic_osint_*/lib/ and emits typed entity records into the Postgres canonical store.

Related · #q-osint · #q-case-mgmt · DD: Czech Registries

8.3 How does graph analysis work in DD?

TL;DR · KuzuDB holds the entity-relationship graph; queries traverse ownership chains, director networks, address co-occurrences, and infrastructure adjacency; the result feeds the LiveView graph visualizer.

The DD graph analysis capability uses KuzuDB as the relationship-graph store and Cypher-compatible queries for traversal. Typical questions answered:

"Show every Czech company sharing a director with target X within three hops."
"Which entities share a registered address with the target's beneficial owner?"
"Which IP/domain assets are linked to the target through hosting, certificate co-occurrence, or DNS adjacency?"
"What sanctioned entities appear within four hops of the target's ownership graph?"

Results are visualized through a LiveView component integrated into the case dashboard. Graph updates flow from Postgres via change-data capture, so the graph is consistent with the canonical entity store within seconds of an update.

Related · #q-postgres-kuzu · #q-czech-registries · DD: Graph Analysis

8.4 How does the platform produce a DD report?

TL;DR · Findings → triple verification → NABLA-compliant belief synthesis → composite risk score → templated PDF/HTML report with full provenance trail.

The DD report-generation pipeline takes admitted findings and runs them through:

Triple verification — every finding corroborated across ≥2 independent sources, ideally 3+.
NABLA belief synthesis — assemble findings into NABLA-compliant belief structures with provenance, confidence, and time-decay.
Risk scoring — apply the seven-dimensional rubric (PEP exposure, sanctions, AML, reputational, political, operational, financial) to produce a composite A-F grade on a 300–900 scale.
Template rendering — instantiate a structured report (executive summary, findings, evidence, risk matrix, open items, monitoring schedule, changelog) into PDF or HTML via LiveView print mode.
Archive — package the case as a tar.gz with a SHA-256 manifest for forensic chain-of-custody.

The report can be regenerated incrementally as new evidence arrives, with each generation versioned in the changelog (semver) so reviewers can diff successive iterations.

Related · #q-case-mgmt · #q-graph-analysis · #q-ma-dd · DD: Methodology · DD: Risk Assessment

9. Integration and API / Integrace a API

These questions cover programmatic access to the platform from external systems.

9.1 What is the API surface?

TL;DR · Auto-introspecting REST gateway with OpenAPI 3.0 spec and Swagger UI; generic {app, action} dispatch; GraphQL (Absinthe) for typed reads; webhooks for events.

The REST gateway auto-generates its surface from @spec and @doc annotations across the platform's umbrella apps. Key entry points:

/api/v1/health — health check with component-level status, sub-10 ms response.
/api/v1/dispatch — generic {app, action} tuple dispatch with timeout.
/api/v1/perimeter/discover, /rating, /compliance — EASM endpoints.
/api/v1/agents — list/status of the 552 agents.
/api/v1/openapi — OpenAPI spec.
/api/v1/swagger — Swagger UI for browsing.

Authentication uses Bearer tokens with scope-based authorization; rate limiting per endpoint and per token is documented at /api/rate-limiting/. Errors follow a taxonomy with stable codes and HTTP semantics. Webhooks deliver real-time event notifications for security, quality, agents, and compliance topics.

A GraphQL endpoint (Absinthe + DataLoader + Phoenix subscriptions) covers typed-read use cases; the MCP endpoint exposes the same agent/command surface for Model Context Protocol consumers.

Related · #q-mcp · #q-webhooks · Academy: API Integration · API Reference

9.2 What is MCP and is it supported?

TL;DR · Model Context Protocol — Anthropic-defined standard for exposing tools/resources to LLM consumers. The platform exposes its agent catalog and command surface via MCP at /api/v1/mcp (currently feature-flagged).

The Model Context Protocol (MCP) is an open standard published by Anthropic for exposing tools, resources, and prompts to LLM-driven consumers (Claude, GPT, etc.). The Prismatic Platform exposes its 552-agent catalog and 228-command surface as MCP tools, plus a curated set of resources (glossary entries, capabilities pages, agent detail pages) for consumption by external LLM agents.

The MCP endpoint is currently feature-flagged (mcp_enabled = false in production), and is enabled selectively for partner integrations. The /mcp slash command and /mcp-service operate the local MCP server during development.

Related · #q-api · Glossary: MCP Service

9.3 How do webhooks work?

TL;DR · POST callbacks for security / quality / agent / compliance events. Configurable filters, retry on failure, signed HMAC for verification. Documented at /api/webhooks/.

Webhooks deliver event notifications to external systems via HTTP POST. Subscribers register a callback URL and a filter (event type, severity, entity scope); the platform delivers JSON-encoded events with HMAC-SHA256 signatures for verification. Failures are retried with exponential backoff up to a configurable max-attempts; permanent failures are logged and the subscription is auto-paused. Common subscription topics: perimeter.rating.changed, compliance.violation.detected, agent.status.changed, quality.score.degraded.

Related · #q-api · #q-telemetry · API: Webhooks

9.4 What is the Telemetry & OTEL pillar?

TL;DR · :telemetry library is mandatory for GenServer emit, controller logging, rescue logging, supervisor startup, external API calls. OTEL pillar enforces it.

The platform uses the :telemetry library as its observability substrate. Events are emitted from every significant action — agent dispatch, storage adapter call, DD pipeline step, LiveView mount — and consumed by metrics, alerting, and the LiveDashboard admin UI.

The OTEL doctrine pillar makes telemetry mandatory: every GenServer must emit lifecycle events, every controller/LiveView must log requests, every rescue block must log errors, every supervisor must log startup, every external API call must be instrumented. CI rejects commits that touch these surfaces without compliant instrumentation.

For consumers: telemetry events translate to Prometheus metrics, structured logs, and OpenTelemetry spans through configured handlers — the platform supports all three and ships sane defaults.

10. Deployment and Operations / Nasazení a provoz

10.1 What are the deployment requirements?

TL;DR · Single BEAM node OK for most installs; PostgreSQL required, Redis + Meilisearch recommended; Fly.io is the reference deployment target with just deploy-production.

A minimum-viable deployment runs on a single BEAM node with PostgreSQL for durable storage. For full capabilities, add Redis (distributed cache, rate limiting), Meilisearch (full-text search), and KuzuDB (graph queries). The reference deployment target is Fly.io with the just deploy-production recipe driving the three-phase production-validation doctrine (pre-deploy validate → deploy → post-deploy validate). Disk: ~5 GB for the build artifact, plus storage for OSINT cache and audit log. Memory: 2 GB minimum, 8 GB recommended for full agent fleet.

Related · #q-three-phase · Glossary: Deploy

10.2 What is the three-phase deployment doctrine?

TL;DR · Phase 1 pre-deploy validate (quality + doctrine + security), Phase 2 deploy + smoke test, Phase 3 post-deploy validate (health + functional + performance). Recovery via just production-recover.

Production deployments follow a strict three-phase sequence enforced by justfile recipes:

Phase 1: Pre-deploy validate — just pre-deploy-validate runs the full quality-gate matrix, doctrine compliance check, and security scan against the local working copy. Failures block deployment.
Phase 2: Deploy + smoke test — just deploy-production ships the artifact to the target and runs a fast 4-endpoint smoke test post-boot. If smoke fails, automatic rollback engages.
Phase 3: Post-deploy validate — just post-deploy-validate production runs health + functional + performance checks against live endpoints. Subsuites report on LiveView page-load times (must be <250 ms), API latencies, agent registry reachability, and compliance-engine availability.

If post-deploy validation fails, just production-recover rolls back to the previous release. The full doctrine lives in .aiad/policies/production-validation-doctrine.policy.md.

10.3 What is the recommended runtime configuration?

TL;DR · config/runtime.exs for prod env, fly.toml for Fly.io, env vars for secrets. Defaults are production-safe.

The platform follows the standard Phoenix configuration model: compile-time config in config/config.exs, environment-specific config in config/{dev,test,prod}.exs, and runtime config in config/runtime.exs (loaded at boot from environment variables for secrets). On Fly.io, fly.toml declares VM size, secrets injection, and health-check endpoints. The defaults are production-safe: SSL forced, secure cookies, SEAL pillar hardening, PERF pillar thresholds active.

For local development, copy .env.example to .env and fill in your Claude, Ollama, and database credentials. The just setup recipe handles the rest.

Related · #q-deployment · #q-three-phase · About: For Developers

11. Glossary and Conventions / Slovník a konvence

11.1 Where do I look up a term?

TL;DR · /glossary/ — 989 term files with cross-references, related_terms arrays, JSON-LD DefinedTerm structured data. Search box, category filter, sort options.

The platform glossary is organized into 7 categories (Architecture, Doctrine, Agent, Intelligence, Security, Epistemic, Technology) and contains ~989 entries. Each entry has structured front-matter with description, category, abbreviation, and a related_terms array driving the cross-link navigation. Pagination is 24/48/100 per page; search supports prefix and substring matching; sort by name, category, or related-term count.

ℹ Note · Earlier references to "225+ terms" reflected the count of defined canonical terms; the current count of ~989 includes alternate spellings, synonyms, and stub entries that point to canonical pages. Both numbers describe the same glossary.

Related · #q-platform · Glossary index · Registry

11.2 Slash commands vs Mix tasks vs skills — what's the difference?

TL;DR · Slash command = user-invocable AIAD operation (/<name>, 228 of them). Mix task = Elixir build/test/validation command (mix <name>). Skill = Claude Code extension. Orthogonal concepts.

These three are commonly confused. Disambiguation table:

Concept	Invocation	Source	Example	Count
Slash command	`/<name>` in Claude Code	`.claude/commands/`, `.aiad/commands/`	`/mycelialize "task"`	228
Mix task	`mix <name>` in shell	`lib/mix/tasks/<name>.ex`	`mix quality.gates`	100+
Skill	`/<skill-name>` (Claude-Code-specific)	`.claude/skills/`, plugins	`/loop`, `/schedule`	varies
AIAD command	subset of slash commands	`.aiad/commands/`	machine-readable spec	subset
Just recipe	`just <name>` in shell	`justfile`	`just deploy-production`	~50

Slash commands and Mix tasks live at different abstraction levels: slash commands are AI-orchestration entry points, while Mix tasks are direct Elixir tooling. They sometimes wrap each other (a slash command may call a Mix task internally), but the registries are tracked separately. Skills are a Claude Code feature for extending the CLI; they don't live in the platform repository.

Related · #q-create-command · #q-aiad · Registry: Commands · Glossary: Mix Task

11.3 Doctrine vs policy vs hook vs gate — how do they relate?

TL;DR · Doctrine = principle. Policy = enforcement spec for that principle. Hook = git automation script. Gate = CI checkpoint. One doctrine pillar typically has one policy file, one or more hooks, and one or more CI gates.

Disambiguation:

Doctrine — a philosophical principle governing platform behavior. Examples: NMND, NWB, ZERO. Formalised as one of the 19 pillars.
Policy — the explicit enforcement specification for a doctrine. Lives in .aiad/policies/<acronym>-*.policy.md. Defines the checks, the markers, the violations, the bypass rules.
Hook — a git-automation script under .githooks/pre-commit.d/<NN>-<name> that executes one or more policy checks at commit time. Multiple hooks stack to enforce multiple doctrines.
Gate — a validation checkpoint in the CI pipeline (typically via mix check.doctrines or a dedicated mix <pillar>.validate) that blocks deployment on failure. Gates execute after hooks, in stricter mode (some advisory hooks become blocking gates in CI).

Concrete example for the SEAL pillar:

Doctrine: SEAL = "Security Enforcement Absolute Lock"
Policy: .aiad/policies/seal-security-enforcement.policy.md
Hook: .githooks/pre-commit.d/30-seal-grep
Gates: mix seal.validate (CI), mix check.doctrines seal (CI), mix credo custom checks (CI)

Related · #q-doctrine-overview · #q-seal · #q-quality-gates

12. Still have a question? / Máte další otázku?

This FAQ aims to answer the most frequently raised questions, but no FAQ is complete. If your question is not covered:

Search the glossary — 989 term entries with cross-references.
Browse the Academy — 18 hands-on courses cover the major workflows in tutorial form.
Check the registry — every agent and command is catalogued with description, inputs, and authority level.
Read CLAUDE.md — the authoritative cross-reference document at the repository root.
Open an issue or contact the author — see "Connect & Contribute" below.

💬 Specific contexts · For executive / business questions, start at /executive/. For security work, start at /about/for-security/. For developer onboarding, start at /about/for-developers/ and /academy/getting-started/.

Conclusion and Further Reading / Závěr a další četba

This FAQ covers the most frequently encountered questions about the Prismatic Platform across 11 thematic sections and 57 questions. For deeper exploration of specific topics, consult:

Architecture — Technical deep-dive into OTP supervision trees, storage adapters, event sourcing, and the epistemic pipeline.
Applications and Apps — Complete catalog of the 92 umbrella applications with their domains and capabilities.
Agents — Documentation of the 552-agent ecosystem, authority levels, and AIAD specification.
OSINT Sources — Detailed reference for all 121+ intelligence source integrations.
Capabilities — Platform doctrines, quality enforcement mechanisms, and evolution protocols.
Teams — The six color-coded security teams with deep-dive descriptions.
Technologies — Technology stack reference covering Elixir, Phoenix, PostgreSQL, and all supporting systems.
Glossary — Definitions for ~989 platform terms including AIAD, 3NL, NABLA, OTP, and NMND.
Lab — 16 experimental sandboxes for platform research.
Philosophy — Intellectual sovereignty, epistemic integrity, and the GHL framework.

For questions not addressed here, the platform's CLAUDE.md file (located at the repository root) serves as the authoritative reference for all platform conventions, protocols, and standards.

FAQ content reflects the platform state as of 2026-05-03. Question count and technical details are updated to match the current codebase. Statistics (agent count, command count, app count) are dynamic and reported by mix truth.report.

Connect & Contribute / Kontakt a přispívání

Created by Tomáš Korcak (korczis) | Open Source under GHL — General Honest License

GitHub · GitLab · LinkedIn · Contact
Developer Portal · Architecture · Meet the Creator · Executive Overview

Frequently Asked Questions

No questions match your search