The Genairus Generative Domain Languages

A complete guide to how Chronos, Flux, Capacitor, Fusion, Smithy, and LikeC4 work together to define your entire software stack.

Overview
The Six Languages
How They Work Together
Integration Patterns
Complete Example: E-Commerce Checkout
Benefits
Getting Started
Incremental Adoption

Overview

Why Six Focused Languages Instead of One?

Each layer of modern software has fundamentally different concerns:

Requirements care about business outcomes, actors, and journeys
APIs care about operations, protocols, and contracts
Data cares about entities, relationships, and persistence
UIs care about components, layouts, and user interactions
Infrastructure cares about resources, deployments, and scaling
Architecture cares about system topology, service boundaries, and structural constraints

A single "do-everything" language would be bloated with concerns irrelevant to each layer. Six focused languages give you:

Precise semantics - Each language models exactly what it needs to model
Independent evolution - Languages can evolve without breaking each other
Optional integration - Use one, some, or all languages based on your needs
Clear boundaries - Explicit interfaces between layers prevent tight coupling

The Principle: Soft Integration

Every language works standalone. Cross-language references are always optional.

You can:

Use Chronos alone to generate requirements artifacts
Use Smithy alone to generate API clients and servers
Use Capacitor alone to generate database schemas
Use Flux alone to generate UI components
Use Fusion alone to generate infrastructure
Use LikeC4 alone to define and visualize your architecture

When you use them together, you get:

Type-safe cross-references
Automated consistency checking
End-to-end traceability
Complete artifact generation

The Six Languages

Layer	Language	Purpose	Generates
Requirements	Chronos	Define journeys, actors, outcomes	Jira tickets, Gherkin tests, Telemetry schemas, State diagrams
APIs	Smithy	Define services, operations	API servers, Client SDKs, OpenAPI specs, Documentation
Data	Capacitor	Define entities, relationships	Database schemas, Migrations, Type-safe repositories, SDKs
UIs	Flux	Define components, layouts	React, Vue, SwiftUI, Jetpack Compose, Flutter components
Infrastructure	Fusion	Define resources, deployments	Terraform, CloudFormation, Helm charts, CI/CD pipelines
Architecture	LikeC4	Define system topology, boundaries, relationships	Interactive diagrams, React/web components, MCP server for AI queries

Stack Visualization

╔═════════════════════════════════════════════╗
║          LikeC4 (Architecture)              ║  Diagrams, MCP, React components
╠═════════════════════════════════════════════╣
│          Chronos (Requirements)             │  Jira, Gherkin, Telemetry
├─────────────────────────────────────────────┤
│             Flux (User Interface)           │  React, SwiftUI, Compose
├─────────────────────────────────────────────┤
│             Smithy (API Contracts)          │  Servers, Clients, Docs
├─────────────────────────────────────────────┤
│           Capacitor (Data Models)           │  Schemas, Repos, SDKs
├─────────────────────────────────────────────┤
│          Fusion (Infrastructure)            │  Terraform, Helm, Pipelines
└─────────────────────────────────────────────┘

Note: LikeC4 is shown above the stack because it describes and constrains all layers—not as a runtime dependency, but as the structural definition that the other languages are validated against.

How They Work Together

1. Chronos → Everything

Chronos sits at the top of the stack, defining what needs to be built.

Chronos → Capacitor

// Chronos imports Capacitor entities
use com.acme.data.orders#Order

journey PlaceOrder {
    steps: [
        step CreateOrder {
            expectation: "Order entity created with status PENDING"
        }
    ]
}

Chronos → Smithy

// Chronos references Smithy operations
@operation("com.acme.api#PlaceOrder")
step CallPlaceOrderAPI {
    expectation: "PlaceOrder operation returns 201 Created"
}

Chronos → Flux

// Chronos references Flux components
@component("com.acme.ui#CheckoutForm")
step FillCheckoutForm {
    action: "User fills checkout form"
}

2. Smithy ↔ Capacitor

API operations reference data entities for request/response shapes.

Smithy references Capacitor:

use com.acme.data.orders#Order

operation PlaceOrder {
    input: PlaceOrderInput
    output: PlaceOrderOutput
}

structure PlaceOrderOutput {
    @required
    order: Order  // Capacitor entity
}

Benefit: Type-safe API contracts that match your data model.

3. Capacitor → Flux

UI components use generated SDKs from Capacitor schemas.

Capacitor defines entity:

entity Order {
    @required
    id: String

    total: Money
    status: OrderStatus
}

Flux uses generated SDK:

use com.acme.data.orders#Order

component OrderSummary {
    props: {
        order: Order  // Type-safe reference
    }

    layout: column {
        text("Order #${order.id}")
        text("Total: ${order.total}")
    }
}

Benefit: UI components automatically typed against your data model.

4. LikeC4 → Everything

LikeC4 is the architectural lens over the entire stack. It doesn't generate runtime artifacts—instead, it defines the structural model that all other languages are validated against.

LikeC4 models the system topology:

model {
  customer = person "Customer" {
    description "User of the system"
  }

  spa = component "Web SPA" {
    technology "React"  // Generated by Flux
    -> api "makes API calls to"
  }

  api = component "API Gateway" {
    technology "Node.js"  // Defined in Smithy
    -> orderService "routes order requests to"
    -> userService "routes user requests to"
  }

  orderService = component "Order Service" {
    technology "Node.js"  // Defined in Smithy + Capacitor
    #critical
    -> orderDB "stores order data in"
  }

  orderDB = database "Order Database" {
    technology "PostgreSQL"  // Schema from Capacitor
  }
}

views {
  view index {
    include *
  }

  view orderFlow {
    include customer, spa, api, orderService, orderDB
  }
}

What LikeC4 enables:

likec4 build → generates interactive diagrams (React components, static HTML)
Embeddable architecture views in wikis, dashboards, and docs
MCP server for AI agents to query: "Which services depend on orderDB?" → [orderService]
Structural validation: does the generated code respect the declared boundaries?

Benefit: Architecture stays current because it's version-controlled alongside the languages that generate the implementation. When you add a new service to Smithy and a new schema to Capacitor, you update the .c4 model in the same PR.

5. Everything → Fusion

Fusion deploys all generated artifacts.

Fusion references all layers:

service CheckoutService {
    // Deploy API (from Smithy)
    api: OrderAPI

    // Deploy database (from Capacitor)
    database: OrderDatabase

    // Deploy frontend (from Flux)
    frontend: CheckoutUI

    // Deploy telemetry (from Chronos)
    telemetry: OrderTelemetry
}

Benefit: Complete stack deployment from a single definition.

Integration Patterns

Pattern 1: Shared Actor Namespace

Define actors once, use everywhere.

Create common/actors.chronos or common/actors.capacitor:

namespace com.acme.common.actors

@description("A verified customer with active account")
actor Customer

@description("Internal customer service representative")
actor SupportAgent

Use in Chronos:

use com.acme.common.actors#Customer

journey PlaceOrder {
    actor: Customer
}

Use in Smithy:

use com.acme.common.actors#Customer

@auth([Customer])
operation GetMyOrders { /* ... */ }

Use in Flux:

use com.acme.common.actors#Customer

@restrictedTo(Customer)
component AccountSettings { /* ... */ }

Pattern 2: Chronos-Driven Development

Start with requirements, generate everything downstream.

Step 1: Define journey in Chronos

journey GuestCheckout {
    actor: Customer

    steps: [
        step ProvideShipping { /* ... */ },
        step ChoosePayment { /* ... */ },
        step PlaceOrder { /* ... */ }
    ]
}

Step 2: Generate artifacts

chronosc build

Outputs:

Jira epic + stories
Gherkin scenarios
State diagrams
OpenTelemetry event schemas

Step 3: Reference in other languages

Use generated insights to inform API, data, and UI design.

Pattern 3: API-First Development

Start with Smithy, reference in Capacitor and Flux.

Step 1: Define API in Smithy

operation CreateOrder {
    input: CreateOrderInput
    output: CreateOrderOutput
}

Step 2: Define entities in Capacitor

use com.acme.api#CreateOrderInput

entity Order {
    // Fields match CreateOrderInput
}

Step 3: Generate and consume

Flux components use generated TypeScript SDK from Smithy.

Pattern 4: Full-Stack Consistency

Use the ontology engine to detect cross-domain collisions.

Example collision: Order entity defined in both Capacitor and Smithy with different fields.

Ontology engine detects:

Warning: Shape collision detected
  - com.acme.data.orders#Order (Capacitor)
  - com.acme.api.orders#Order (Smithy)

Fields differ:
  - Capacitor has `shippingAddress` (required)
  - Smithy has `shippingAddress` (optional)

Recommendation: Align or namespace separately

Complete Example: E-Commerce Checkout

1. Define Requirements (Chronos)

requirements/checkout.chronos:

namespace com.acme.requirements.checkout

use com.acme.data.orders#Order
use com.acme.data.orders#OrderStatus

@kpi(metric: "CheckoutConversion", target: ">75%")
journey GuestCheckout {
    actor: Customer

    preconditions: [
        "Cart is not empty",
        "Actor is not logged in"
    ]

    steps: [
        step ProvideShipping {
            action: "Submits shipping address form"
            expectation: "System validates address"
            outcome: TransitionTo(ShippingValidated)
        },

        step ChoosePayment {
            action: "Selects payment method"
            expectation: "System validates payment details"
            telemetry: [PaymentMethodSelectedEvent]
        },

        step PlaceOrder {
            @slo(latency: "2s", p99: true)
            action: "Clicks 'Place Order'"
            expectation: "Order created with status PENDING"
            outcome: TransitionTo(OrderCreated)
            telemetry: [OrderPlacedEvent]
        }
    ]

    outcomes: {
        success: "Order exists with status PENDING",
        failure: "Cart unchanged, error displayed"
    }
}

Generates: Jira epic/stories, Gherkin scenarios, state diagram, OpenTelemetry schemas

2. Define API (Smithy)

api/orders.smithy:

namespace com.acme.api.orders

use com.acme.data.orders#Order

@http(method: "POST", uri: "/orders")
operation PlaceOrder {
    input: PlaceOrderInput
    output: PlaceOrderOutput
    errors: [
        InvalidAddressError,
        PaymentDeclinedError
    ]
}

structure PlaceOrderInput {
    @required
    shippingAddress: Address

    @required
    paymentMethod: PaymentMethod
}

structure PlaceOrderOutput {
    @required
    order: Order

    @required
    confirmationId: String
}

Generates: OpenAPI spec, TypeScript client, Java server, Python SDK, documentation

3. Define Data Model (Capacitor)

data/orders.capacitor:

namespace com.acme.data.orders

entity Order {
    @required @id
    id: String

    @required
    customerId: String

    @required
    items: List<OrderItem>

    total: Money
    status: OrderStatus

    createdAt: Timestamp
    updatedAt: Timestamp
}

shape OrderItem {
    @required
    sku: String

    @required
    quantity: Integer

    unitPrice: Money
}

enum OrderStatus {
    PENDING
    PAID
    SHIPPED
    CANCELLED
}

Generates: PostgreSQL schema + migrations, MongoDB schema, TypeScript SDK, Java JPA entities, Python SQLAlchemy models

4. Define UI (Flux)

ui/checkout.flux:

namespace com.acme.ui.checkout

use com.acme.data.orders#Order
use com.acme.api.orders#PlaceOrderInput

component CheckoutForm {
    state: {
        shippingAddress: Address,
        paymentMethod: PaymentMethod,
        isSubmitting: Boolean
    }

    @backend(operation: "com.acme.api.orders#PlaceOrder")
    async function submitOrder() {
        const input: PlaceOrderInput = {
            shippingAddress: this.state.shippingAddress,
            paymentMethod: this.state.paymentMethod
        }

        const result = await PlaceOrderAPI.call(input)
        // Navigate to confirmation
    }

    layout: column {
        ShippingAddressForm(
            value: state.shippingAddress,
            onChange: (addr) => setState({ shippingAddress: addr })
        )

        PaymentMethodForm(
            value: state.paymentMethod,
            onChange: (pm) => setState({ paymentMethod: pm })
        )

        button(
            text: "Place Order",
            onClick: submitOrder,
            disabled: state.isSubmitting,
            loading: state.isSubmitting
        )
    }
}

Generates: React components, SwiftUI views, Jetpack Compose components, Vue components

5. Define Infrastructure (Fusion)

infrastructure/checkout.fusion:

namespace com.acme.infra.checkout

service CheckoutService {
    runtime: node20

    api: {
        source: "../api",
        handler: "orders.PlaceOrder",
        cors: true
    }

    database: {
        provider: postgres,
        schema: "../data/orders.capacitor",
        migrations: auto
    }

    frontend: {
        source: "../ui/checkout",
        framework: react,
        ssr: true
    }

    telemetry: {
        provider: opentelemetry,
        schemas: "../requirements/checkout.chronos",
        exporters: [datadog, jaeger]
    }

    deployment: {
        provider: aws,
        region: us-east-1,
        environment: production
    }
}

Generates: Terraform modules, Helm charts, GitHub Actions workflows, Dockerfile, docker-compose.yml

Build All Layers

# Generate from all languages
chronosc build   # Jira, Gherkin, telemetry
smithy build     # API servers/clients
capacitor build  # Database schemas/SDKs
flux build       # UI components
fusion build     # Infrastructure code

# Deploy
fusion deploy --env=production

Benefits

1. Consistency Across Teams

Without Genairus:

PM writes requirements in Confluence
Designer creates mockups in Figma
Backend engineer defines API in OpenAPI
Frontend engineer creates components in React
Data engineer creates schema in SQL
SRE writes Terraform

Collision points: 6 handoffs, 6 opportunities for misalignment

With Genairus:

PM writes Chronos (or AI generates from conversation)
Engineer defines Smithy + Capacitor + Flux
SRE defines Fusion
All languages reference the same shapes

Collision points: 0 (validation enforces consistency)

2. Cost Efficiency

Reduce LLM Token Usage by 90%:

Instead of prompting an LLM with:

Jira epic (500 tokens)
Confluence requirements (800 tokens)
API documentation (1000 tokens)
Database schema (600 tokens)
Component mockups (400 tokens)

Total context: 3,300 tokens × 10 features = 33,000 tokens

You prompt with:

5 validated .chronos, .smithy, .capacitor, .flux, .fusion files

Total context: 3,000 tokens × 1 (reusable across features)

Savings: 90% reduction in repeated context

3. Velocity

From Idea to Deployment:

Phase	Without Genairus	With Genairus
Requirements	2 days (writing, review)	20 min (Chronos + generate)
API Design	1 day	10 min (Smithy + generate)
Database Schema	4 hours	5 min (Capacitor + generate)
UI Components	2 days	15 min (Flux + generate)
Infrastructure	1 day	10 min (Fusion + generate)
Total	6.5 days	60 minutes

Note: These times assume business logic is already understood. Genairus eliminates translation time, not thinking time.

4. Traceability

Every artifact traces to its source:

OrderPlacedEvent (OpenTelemetry)
  ↓ generated from
GuestCheckout.chronos (Requirements)
  ↓ references
Order entity in orders.capacitor (Data)
  ↓ used by
PlaceOrder operation in orders.smithy (API)
  ↓ called by
CheckoutForm in checkout.flux (UI)
  ↓ deployed by
CheckoutService in checkout.fusion (Infrastructure)

Change impact analysis: Modify Order entity → validation shows all affected journeys, APIs, and components.

5. Evolvability

Change: Add priority field to Order entity

Without Genairus: Manually update 12+ places:

Database schema
API input/output types
Client SDKs (TypeScript, Java, Python)
UI components
Documentation
Tests

With Genairus: Change once, regenerate everything:

# Edit orders.capacitor
entity Order {
    // ...
    priority: OrderPriority  // NEW FIELD
}

# Regenerate all downstream artifacts
capacitor build && smithy build && flux build && fusion build

All type errors surface immediately during validation.

Getting Started

Choose Your Entry Point

Start based on your pain point:

Pain Point	Start With	Then Add
Vague requirements	Chronos	Smithy → Capacitor → Flux → Fusion
API inconsistency	Smithy	Capacitor → Flux → Fusion
Database drift	Capacitor	Smithy → Flux → Fusion
UI component sprawl	Flux	Capacitor (for types) → Fusion
Infrastructure toil	Fusion	Capacitor → Smithy → Flux
Architecture drift	LikeC4	Add all other languages alongside it

Minimal Starter

Option 1: Requirements-First (Product-Led)

# macOS — Install Chronos CLI via Homebrew
brew tap genairus/tap && brew install chronos-cli

# Windows — Install via Scoop
# scoop bucket add genairus https://github.com/genairus/scoop-bucket
# scoop install genairus/chronos-cli

# Create first journey
mkdir requirements && cd requirements
# Write user-registration.chronos

# Generate artifacts
chronosc build

Option 2: API-First (Engineering-Led)

# macOS — Install Smithy CLI via Homebrew
brew tap smithy-lang/tap && brew install smithy-cli

# Windows — Install via Scoop
# scoop bucket add smithy-lang https://github.com/smithy-lang/scoop-bucket
# scoop install smithy-lang/smithy-cli

# Create first service
mkdir api && cd api
# Write orders.smithy

# Generate clients/servers
smithy build

Option 3: Data-First (Data Engineering-Led)

# macOS — Install Capacitor CLI via Homebrew
brew tap genairus/tap && brew install capacitor-cli

# Windows — Install via Scoop
# scoop bucket add genairus https://github.com/genairus/scoop-bucket
# scoop install genairus/capacitor-cli

# Create first entity
mkdir data && cd data
# Write orders.capacitor

# Generate schema + SDK
capacitor build

Option 4: Architecture-First (Architecture-Led)

# Install LikeC4 CLI (distributed via npm)
npm install -g @likec4/cli

# Create architecture model
mkdir architecture && cd architecture
# Write system.c4

# Generate diagrams and start dev server
likec4 serve