Preliminary Specification

This document describes the core concepts of the Elan8 DSL. The language is subject to change as we continue development. This is an invitation to collaborate, not a frozen contract.

Note: Full grammar (BNF/Pest/EBNF), complete keyword lists, formal semantics, and parser implementation details are not published at this time.

Elan8 DSL Specification

What is the Elan8 DSL?

The Elan8 DSL is a declarative Architecture-as-Code language that lets you define system architectures in a text-based, versionable format. It provides syntactic sugar over SysML v2 concepts, optimized for authoring UX first, with analysis capabilities built in.

The language is designed to be:

  • Human-readable: Write architecture like code, not like formal specifications
  • Git-friendly: Optimized for version control, diffs, and code reviews
  • Validatable: Architecture can be checked automatically, just like code
  • Multidisciplinary: Model software, electronics, and mechanical systems together

What the Elan8 DSL Does Not Try to Do

The Elan8 DSL is intentionally focused. It does not attempt to:

  • Replace system design or engineering judgment
  • Provide complete modeling of all system aspects
  • Generate code automatically (though this may come later)
  • Replace existing tools like PLM, CAD, or simulation software
  • Be a general-purpose programming language

Instead, it focuses on making architecture explicit, versionable, and checkable.

Core Concepts

The Elan8 DSL is built around a few key concepts:

Naming Convention

The DSL uses a simple but important naming convention:

  • Uppercase identifiers (PascalCase) define types — reusable definitions like part MotorController or interface Power24V
  • Lowercase identifiers (snake_case) define usage/instances — actual components in your system like part motor_controller: MotorController

This convention makes it immediately clear what's a type definition versus an instance, and helps the language distinguish between reusable definitions and concrete usage.

part

Structural decomposition — components, subsystems, modules

port

Interaction attachment points (directionless)

interface flow

Physical interaction (power, signals, data)

interface message

Discrete message exchange

across / through

Physical variables (voltage, current, etc.)

message

Packet / dataframe definitions

capability

Resource / suitability definitions

connect to

Bind ports via compatible interfaces

bind to

Deployment / assignment based on capabilities

A Minimal Example

Here's the power supply example from the screenshot above, showing how you define a component with internal parts and connections:

// Power Supply Unit - Converts 230V AC to DC rails
@doc "Power supply unit converting 230V AC to multiple DC voltage rails"
part PowerSupply {
    
    // 230V AC input port
    port ac_input: Power230V
    
    // DC output ports
    port power_3v3_out: Power3V3
    port power_5v_out: Power5V
    port power_12v_out: Power12V
    
    // Internal power conversion stages
    @doc "AC to DC conversion stage"
    part ACDCConverter {
        port ac_input: Power230V
        port dc_output: Power12V
    }
    
    @doc "3.3V voltage regulator"
    part VoltageRegulator3V3 {
        port input: Power12V
        port output: Power3V3
    }
    
    @doc "5V voltage regulator"
    part VoltageRegulator5V {
        port input: Power12V
        port output: Power5V
    }
    
    // Internal connections
    connect ac_input to ACDCConverter.ac_input
    connect ACDCConverter.dc_output to power_12v_out
    connect ACDCConverter.dc_output to VoltageRegulator3V3.input
    connect ACDCConverter.dc_output to VoltageRegulator5V.input
    connect VoltageRegulator3V3.output to power_3v3_out
    connect VoltageRegulator5V.output to power_5v_out
}

This example shows:

  • Component structure with multiple ports (ac_input, power_3v3_out, power_5v_out, power_12v_out)
  • Internal decomposition (PowerSupply contains ACDCConverter, VoltageRegulator3V3, and VoltageRegulator5V)
  • Explicit connections between ports, including branching (one output connected to multiple inputs)
  • Documentation annotations using @doc

This matches exactly what you see in the screenshot above — the code on the left renders as the block diagram on the right.

Visual Representation

The Elan8 IDE renders your DSL code as a visual block diagram. Here's how the power supply example looks when visualized:

Elan8 IDE showing DSL code editor with power_supply.dac file and visual block diagram representation side-by-side, demonstrating how code translates to diagrams

The diagram shows components as blocks, ports as connection points, and interfaces as colored lines. This visual representation helps you understand the architecture at a glance, while the DSL code remains the source of truth.

Design Principles

The Elan8 DSL is designed with specific principles in mind:

Text over diagrams

While visual diagrams are useful for understanding, the DSL prioritizes text-based definitions. Text is versionable, reviewable, and diffable. Diagrams are generated from text, not the other way around.

Explicit interfaces

Interfaces are first-class concepts. Every connection must specify what interface it uses. This makes dependencies explicit and checkable. You can't accidentally connect incompatible components.

Git-friendly diffs

The language syntax is designed to produce clean, readable diffs. Changes to architecture are as easy to review as changes to code. Architecture evolution becomes part of your Git history.

Architecture validation as part of CI

The DSL is designed to be validated automatically. Architecture checks can run in CI/CD pipelines, catching interface mismatches, missing connections, and constraint violations before they cause problems.

Want to Learn More?

This specification covers the core concepts of the Elan8 DSL. For more details about the product and how it works, see the Product page.

Elan8

Making architecture executable.

© 2026 Elan8. All rights reserved.