Foundry - The Anti-Entropy Development Environment for Platforms and AI-Driven Engineering

For the past two years, I’ve been obsessed with a technical problem: **How do we effectively use LLMs to engineer, manage, and scale complex distributed systems without them collapsing into unmaintainable, hallucinated legacy code?**

If you’ve used AI coding assistants, you know the reality. They act like eager junior developers. You ask for a feature, and they start inventing new ways to mix concrete. They hallucinate, ignore your project’s architectural constraints, leads to fragile abstractions, and silently introduce massive technical debt.

To solve this, I realized we needed to fundamentally change the surface area the AI interacts with. I needed a declarative language where structure imparts determinism, because LLMs are designed for structured data and understand intent far better when following a constrained, predictable path.

This realization sparked a two-year research and engineering journey that spanned multiple languages, architectures, and paradigms. Today, I am thrilled to open-source the culmination of that journey: **Foundry**.

### The Two-Year Journey: From Rust to Go to Elixir

**Generation 1: The Rust Era (ArchitectLM/cascade)**

I started by building a high-performance, edge-compatible declarative workflow engine in Rust. It used a YAML DSL, WASM-based plugins for isolation, and Content-Addressed Storage (CAS) for immutable deployments. It was incredibly fast and safe. However, as the need for dynamic business rules grew, I hit a wall. Extending it required high entry threshold, complex integrations, and the boilerplate of maintaining a custom DSL became a bottleneck.

**Generation 2: The Go Era (Cascade Platform)**

To reduce code complexity, I pivoted to an “Application-as-Data” paradigm in Go. The idea was to stop reinvent backend entirely. The platform integrated heavy enterprise tools: Temporal for stateful workflows, SpiceDB for ReBAC authorization, and Flowable for business rules. While the architecture was incredibly powerful, the infrastructural complexity was overwhelming. Managing distributed caches, sagas, backpressure, and state machines across multiple external services is an ambitious task that takes years to perfect.

**The Epiphany: Elixir and the Ash Framework**

I needed something highly integrated, high-level, scalable and declarative out of the box. I needed a mature compiler, proper AST manipulation, and meta-programming to reduce complexity.

After testing LLM efficiency across various languages, **Elixir emerged as the clear winner.**

Elixir’s predictable structure, immutability, and OTP foundation natively solved the distributed system problems I was trying to wire together in Go. But the real magic was the **Ash Framework**. It shrinks the codebase drastically, requiring significantly fewer tokens to write and maintain, which is the holy grail for LLM context windows. It scales automatically, eliminating the need to manually orchestrate low-level abstractions.

### Enter Foundry: The Operating System for Complex Domains

**Foundry** is a governed development environment for complex domain platforms built on Elixir and Ash.

With Foundry, the paradigm shifts entirely. The AI doesn’t mix concrete anymore. It simply follow a gold standard, reaches into the Foundry library, pulls out a pre-cast, mathematically proven abstraction (like `ash_idempotency`, `ash_reactor` or `ash_state_machine`), and bolts it together. It also add some annotations to link with business intend that specification holds.

Foundry’s core philosophy is simple: **Your codebase is the spec, the spec is always true, and the copilot never loses context.**

#### 1. An Anti-Entropy System

The real competition in software engineering isn’t other tools; it’s the natural entropy of complex systems. Documentation drifts from code. Intent diverges from implementation.

Foundry fights entropy at every level:

- **The Spec-Kit** encodes business intent.

- **The Linter** makes that intent executable.

- **The System Map** makes architectural drift visible instantly.

- **Tests are displayed on the System Map** provides easier review.

- **The Copilot** operates strictly within these encoded constraints.

#### 2. AI That Understands Your Architecture

Unlike generic AI assistants that rely on file context and hallucinate dependencies and implicit relationships, Foundry’s Copilot uses structured retrieval over live DSL introspection and knows the entire compact map of the system. It knows your current stack and dependency versions, your project’s invariants, and your compliance obligations, it has references to a gold standard like `ash_hq` and `foundry_hq` before it generates a single line of code. Using AST-safe generation (via Igniter), it doesn’t just guess text, it safely modifies your system’s syntax tree in a safe way.

#### 3. Two Speeds: From Startup to Regulated Enterprise

Foundry adapts to your risk tolerance:

- **Execution-Led:** Minimal ceremony. Fast iteration. Auto-applied structural changes. The Copilot generates executable BDD scenarios directly from your PR descriptions. Reversibility is a first-class primitive, allowing you to semantically undo complex domain changes instantly.

- **Enterprise:** Full governance. Changes require proposals, ADRs (Architecture Decision Records), and compliance-linked flags. Scenarios and property tests are generated directly from regulatory and business requirements.

#### 4. The Living System Map

In traditional systems, architecture diagrams (C4, ERDs) are out of date the minute you commit code. Foundry generates a live, interactive System Map generated directly from the compiler’s metadata (using `spark_meta`). It extracts the resources, relationships, state machines, links, state machine lifecycles, authorization matrices and compliance tags, and renders an interactive graph. It has an “Engineer View” for the technical team and a “Domain View” for the business experts. If a developer removes a compliance tag, the map updates instantly. Drift is technically impossible because it is generated directly from the compiler.

It also provides a visual representation of code changes as well as full test tracing directly on the system map.

### Who is Foundry For?

Foundry is built for domains where rules matter enormously, where changing one rule cascades through the system, and where audit trails are mandatory.

If you are building platforms in **Healthcare, FinTech, Insurance, Legal Tech, Logistics, or EdTech**, Foundry provides the governance and architectural safety you need, without sacrificing development velocity.

### Why This Matters

Every engineering team maintaining a complex platform experiences the same pain: the original architect leaves, a new engineer adds a delete action, the compliance test is skipped, and six months later, you have a critical incident.

Foundry prevents this. It encodes institutional knowledge as executable constraints. The linter catches violations at the moment of introduction. The proposal model makes architectural changes visible. The Copilot operates strictly within these encoded constraints.

**Stop fighting entropy. Let your code be the spec.**

### Explore the Open-Source Ecosystem

Foundry is fully open-source and modular. Explore the repositories that was created for Foundry to build the future of AI-driven, spec-first engineering:

- **[Foundry Homepage](https://foundry.definitivespec.org/)** Learn and download a desktop application (Linux and macOS).

- **[Foundry Studio Demo](https://studio.cloud.foundry.definitivespec.org/)** Try a real project online.

- **[Foundry Library]( GitHub - FoundryStack/foundry: Foundry is the governed development environment for complex domain platforms. · GitHub ):** The core governed development environment.

- **[Foundry Studio]( GitHub - FoundryStack/foundry-studio · GitHub ):** The visual interface and living System Map.

- **[Spark Lint]( GitHub - FoundryStack/spark_lint: Lint rule runner for Elixir/Spark/Ash projects · GitHub ) & [Spark Meta]( GitHub - FoundryStack/spark_meta: Spark DSL walker and introspection library · GitHub ):** AST-aware linting and metadata extraction.

- **[Scenario Tracer]( GitHub - FoundryStack/scenario_tracer: ScenarioTracer wires together AST scanning, runtime trace collection, and report generation into a single Mix task abstraction · GitHub ) & [Ex Tracer]( GitHub - FoundryStack/ex_tracer: Scenario extraction primitives for Elixir test suites · GitHub ):** Executable specifications and deep observability.

- **[Phoenix LLM Chat]( GitHub - FoundryStack/phoenix_llm_chat: An extensible Phoenix LiveView chat component with streaming LLM support and session management · GitHub ):** The context-aware AI copilot interface.

- **[AshSDUI]( GitHub - FoundryStack/ash_sdui: Server-Driven UI for Phoenix LiveView applications backed by Ash resources · GitHub ):** Server-Driven UI for Phoenix LiveView applications backed by Ash resources.

- **[Demo Application]( GitHub - MaxSvargal/foundry-igaming: igaming fintech solution based on foundry · GitHub ):** Fintech solution based on foundry.

—

- **[Cascade on Rust]( GitHub - ArchitectLM/cascade: Sophisticated data-driven workflow orchestration · GitHub ):** Sophisticated data-driven workflow orchestration.

- **[Cascade on Golang]( GitHub - MaxSvargal/cascade-platform-go: Full-stack "Application-as-Data", "AI-first" development platform · GitHub ):** Full-stack “Application-as-Data” development platform.

- **[DefinitiveSpec](https://definitivespec.org/):** Definitive Development Methodology for Specification-Driven Development.

—

Check out the code, read the docs, and let me know what you think! I am looking for partners to evolve the project.

Join us on Discord DefinitiveSpec Community @maxsvargal

_P.S. The project is in the preview stage and is not ready for production yet, but I hope that we will bring it to perfection through iterative attempts at implementing real projects._