Skip to content

Latest commit

ย 

History

13 Commits

Folders and files

NameName
Last commit message
Last commit date
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 

Repository files navigation

Averos

A deterministic platform for building and evolving applications from structured intent



โ The AI decides what should exist.

The engine decides how it gets built. โž




What is Averos ?

Averos is a deterministic execution and evolution layer between AI intent and production software.

It turns structured intent into reviewable, reproducible code โ€” providing a controlled path from what AI decides should exist to software that can actually be built, inspected, evolved, and maintained.

Unlike AI coding assistants that generate source code directly, Averos generates and evolves a structured application model โ€” making software construction reproducible, explainable, and incremental


๐Ÿ“– Introduction

Modern AI coding assistants generate code.

Averos generates software systems. It is designed specifically for long-lived business applications that evolve safely over time.

Instead of treating code as the source of truth, Instead of asking an LLM to produce thousands of lines of source code, Averos treats a structured application model as the source of truth.

AI produces the application model.

The deterministic Averos engine produces the application.

The result is software that is reproducible, explainable, and evolves safely through conversation.

Works with:

Provider Type
Claude Desktop MCP client
Any MCP-compatible client MCP
Anthropic API Cloud LLM
Google Gemini Cloud LLM
OpenAI Cloud LLM
Ollama Local LLM
LM Studio / LocalAI / vLLM Local LLM

๐Ÿš€ Try It Out

Assuming an application manifest has already been created (either using AI or averos designer).

npm install -g @averos/cli

1- Copy the ToDo application manifest to your working folder: todoapp-manifest.json

2- In your working folder, create the following file averos.config.json with the content below:

{
  "mode":           "resilient",
  "timeoutMs":      1800000,
  "maxAttempts":    1,
  "workspaceRoot":  "./generated-app",
  "manifestPath":   "../todoapp-manifest.json",
  "logsDir":        "./generated-app/averos-logs",
  "statePath":      "./generated-app/state.json",
  "checkpointPath": "./generated-app/checkpoints.json"
}

3- Verify the Plan:

averos plan --config=averos.config.json

4- Generate the application:

Use --verbose for detailed tracing.

averos run --config=averos.config.json --verbose

This application has 320 nodes so the generation time may exceed the configured timeout (30 minutes) depending on your machine configuration.

Upon timeout failure (timeout = 30 minutes), re-execute the command with --resume to resume from last checkpoint :

averos run --config=averos.config.json --verbose --resume

5- Explore your application:

Navigate to your application folder then build and serve:

cd generated-app/ToDoApp
npx ng serve 

Open your browser and navigate to : http://localhost:4200

Use admin/admin123 to log into your application (Dummy Auth)


๐Ÿ’ก Why Averos?

Most "AI coding" today works like this: you describe what you want, the model writes code, and if you want a change, you describe it again and hope the model doesn't quietly rewrite something you didn't ask it to touch. The prompt is the source of truth โ€” which means there is no source of truth. The prompt is the source of truth โ€” which means there is no durable, structured source of truth. Changes are difficult to reason about before execution, reproducibility is difficult to guarantee, and every revision risks becoming another round of code generation.

Averos exists to fix that. It inserts a deterministic execution and evolution layer between AI intent and your running codebase โ€” a structured, validated intermediate representation (the manifest) that the AI produces and everything downstream is built from. The AI still decides what should exist. Averos decides how it gets built โ€” and that half of the process is no longer a guess.

AI provides intelligence. Averos provides control.


The fundamental difference

Most AI coding tools generate source code directly.

That approach is fast, but often produces:

  • inconsistent architectures
  • non-reproducible outputs
  • difficult maintenance
  • vendor lock-in
  • unpredictable behavior

Averos takes a different approach.

Instead of generating source code directly, Averos generates and manages a structured Application Manifest (IR โ€” Intermediate Representation) that describes an application in a deterministic format.

The manifest is then:

  1. Validated
  2. Normalized
  3. Converted into an execution plan
  4. Executed through a deterministic DAG engine

The result is a system that combines Natural Language, AI Assistance, and Deterministic Engineering into a single workflow.

Conventional AI coding asks:

"What code should I generate?"

Prompt
  โ†“
AI
  โ†“
Code
  โ†“
Application

Averos asks:

"What software state should exist, and what deterministic operations are required to get there?"

Intent
  โ†“
AI
  โ†“
Application Manifest
  โ†“
Validation
  โ†“
Semantic Diff
  โ†“
Execution Plan
  โ†“
Deterministic Engine
  โ†“
Application

The AI is responsible for understanding intent and producing a structured representation.

The Averos engine is responsible for validating that representation, determining what changed, resolving dependencies, producing an execution plan, and applying the required transformations.

Why this matters

Challenge Conventional AI Coding Averos
Source of truth Prompts and generated code Structured application manifest
Architecture Implicit in generated code Explicit in the application model
Planning Left to the AI agent Explicit, dependency-aware execution plan
Determinism Model-dependent Deterministic execution engine
Validation Agent- or tool-dependent Structured manifest validation (structural, referential, constraint)
Change detection File- or code-level diffing Semantic manifest diff
Incremental evolution Regenerate or manually edit Apply only the required operations
Dependencies Inferred during generation Explicitly modeled and planned
Execution Agent-driven side effects Controlled execution through adapters
Failure handling Agent- or tool-dependent Checkpoints, state, resumable execution
Rollback / revisions Usually external to the AI workflow First-class application revisions
Explainability Inspect the generated code Inspect manifest โ†’ validation โ†’ diff โ†’ plan โ†’ execution
AI independence Often coupled to a specific agent or model LLM-agnostic architecture
MCP / agent integration Agent- or tool-dependent Native, governed AI interaction layer
Reproducibility Difficult to guarantee Core architectural objective

Three architectural principles make this possible:

  • The manifest is the contract, not the transcript. Because the AI's job ends at producing a validated manifest โ€” not at writing code โ€” the deterministic Averos engine can reproduce the same execution plan from the same defined state and engine configuration. You can hand the same manifest to Averos twice and get the same output twice. That's not true of prompt-to-code generation, no matter how good the model is.

  • Evolution is a diff, not a do-over. Change one field on one entity, and Averos recomputes only the affected nodes in the dependency graph and touches only what actually changed. In direct AI coding workflows, a requested change often becomes another round of code generation or agent-driven editing. Averos treats the application as a living graph rather than a disposable generation.

  • AI agents get a governed environment, not open access. Through @averos/mcp, an AI agent doesn't get raw file or shell access to your project โ€” it gets a bounded set of tools (update_ir, validate_ir, build_execution_plan, approve_plan) that force every change through validation and an approval gate before anything is written. The agent proposes. The engine plan. You control execution.

Averos is built on an adapter pattern, so this deterministic core isn't tied to one framework by design โ€” Angular schematics is the first production adapter, demonstrating the pipeline end to end, with the same execution model designed to extend to other stacks over time.

Built for software evolution:

Software is not generated once. It is continuously changed.

Averos is designed around software evolution, not just initial generation.

For example:

Initial application
        โ†“
"Add priority to tasks"
        โ†“
Manifest revision
        โ†“
Semantic diff
        โ†“
1 required operation
        โ†“
Deterministic execution
        โ†“
Updated application

The application is not regenerated from scratch. Its desired state changes, the difference is calculated, and only the necessary operations are executed.

This enables a software development model based on:

  • Reproducibility โ€” the same defined state can produce the same planned result.
  • Explainability โ€” every transformation can be inspected before execution.
  • Incremental evolution โ€” applications change through explicit revisions rather than uncontrolled regeneration.
  • Control โ€” AI proposes intent; the deterministic engine controls execution.
  • Recoverability โ€” execution state and checkpoints support failure recovery and resumption.
  • Extensibility โ€” execution is separated from the core engine through adapters.
  • AI independence โ€” the deterministic core does not depend on a particular LLM.

In one sentence

Averos is the deterministic execution and evolution layer between AI intent and production software.


๐Ÿ“œ Why a Manifest?

Because source code is difficult for AI to evolve safely.

Traditional AI

Prompt โ†’ Source Code โ†’ Manual fixes โ†’ Regenerate โ†’ Lose edits

Averos

Prompt โ†’ Application Manifest โ†’ Validation โ†’ Execution Plan โ†’ Generated Application
                                                                        โ†“
                                                             Incremental evolution

A manifest is:

Property Description
โœ… Deterministic Same manifest always produces the same output
โœ… Versionable Every revision is stored and retrievable
โœ… Diffable Changes are computed precisely โ€” only deltas execute
โœ… Reviewable Every planned operation is inspectable before execution
โœ… Rollbackable Any revision can be restored instantly
โœ… Executable The manifest is the direct input to the execution engine

The generated source code becomes a product of the manifestโ€”not the other way around.


๐Ÿ‘ฅ Who is Averos for?

Audience Use case
Enterprise software teams Repeatable, governed application generation
Internal tooling Rapid generation from structured specs
CRUD business applications Full stack from a single manifest
Low-code / no-code platforms AI-driven form and workflow generation
AI agents Structured tool-based application construction
CI/CD pipelines Deterministic generation in automated pipelines

๐Ÿš€ Quick Start

1. Install the CLI

npm install -g @averos/cli

2. Generate a manifest (two options)

Now there are two ways for generating application manifest:

๐ŸŸฆ Generate application manifest using AI
๐ŸŸฆ Generate application manifest using the Online Averos Designer ๐Ÿ› ๏ธ

Option A โ€” AI-generated manifest:

npm install -g @averos/ai

averos generate "Build a CRM with contacts and deals" \
  --output=/tmp/crm-manifest.json

Using Ollama (local LLM, averos.config.ollama.json):

Averos Config - averos.config.ollama.json

{
 "timeoutMs":      600000,
 "llmTimeoutMs":   600000,
 "llmProvider":   "ollama",
 "ollamaBaseUrl": "http://192.168.136.1:11434",
 "ollamaModel":   "qwen2.5-coder:7b",
 "maxAttempts":    5
}
averos generate "Build a CRM" \
    --output=/tmp/averos-application-manifest.json \
    --config=/averos.config.ollama.json

Option B โ€” Online Averos Designer:

Use the Averos Designer ๐Ÿ› ๏ธ to visually build your application manifest.

3. Preview the execution plan

averos plan /tmp/crm-manifest.json --workspace=/tmp/crm-app

4. Execute

# Dry-run โ€” no side effects
averos run /tmp/crm-manifest.json --workspace=/tmp/crm-app --dry-run

# Real execution
averos run /tmp/crm-manifest.json --workspace=/tmp/crm-app

Using a config file (averos.config.json):

Averos Config: averos.config.json

{
  "mode":           "resilient",
  "timeoutMs":      120000,
  "maxAttempts":    1,
  "workspaceRoot":  "/tmp/averos-applications/",
  "manifestPath":   "/tmp/averos-application-manifest.json",
  "statePath":      "/tmp/averos-applications/state.json",
  "checkpointPath": "/tmp/checkpoints.json",
  "logsDir":        "/tmp/averos-applications/averos-logs"
}
# Dry-run via config file
averos run --config=averos.config.json --dry-run
# Execute the application manifest via config file
averos run --config=averos.config.json

The application is generated at workspaceRoot.


โš™๏ธ Averos DAG Engine

A deterministic, compiler-style pipeline for generating averos applications from structured JSON manifests โ€” with LLM-assisted design, validation, dependency-ordered execution, and full resumability.


Four-Layer Pipeline

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  LAYER 1 โ€” INTENT                                   โ”‚
โ”‚  LLM or designer produces a JSON manifest           โ”‚
โ”‚  (natural language โ†’ structured application model)  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                     โ”‚ Manifest (JSON IR)
                     โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  LAYER 2 โ€” VALIDATION                               โ”‚
โ”‚  Schema compliance ยท referential integrity          โ”‚
โ”‚  Constraint checking ยท naming rules                 โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                     โ”‚ Validated Manifest
                     โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  LAYER 3 โ€” ORCHESTRATION                            โ”‚
โ”‚  Diff against current state ยท DAG construction      โ”‚
โ”‚  Topological sort ยท Execution plan                  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                     โ”‚ Approved Execution Plan
                     โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  LAYER 4 โ€” EXECUTION                                โ”‚
โ”‚  Execution Adapter ยท Checkpointing ยท State sync     โ”‚
โ”‚  Resumable ยท Idempotent ยท Dry-run safe              โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The LLM is powerful but unreliable. The execution engine is reliable but dumb. The validation and orchestration layers safely connect the two.

Core Idea

Traditional AI workflow:

Prompt โ†’ LLM โ†’ Source Code

Averos:

Prompt โ†’ AI โ†’ Application Manifest (IR)
                              โ†“
                  Deterministic DAG Execution
                              โ†“
                  Generated Application

The AI decides what should exist.

The engine decides how it gets built.


Example

User:

Build a task management application with:
- ToDo items
- Subtasks
- Priorities
- Authentication

AI generates a manifest. Averos then:

Validate Manifest โ†’ Normalize โ†’ Build Execution Plan โ†’ Execute DAG โ†’ Generated Application

The same manifest always produces the same result.


๐Ÿ“ Design Principles

The Application Manifest is the source of truth โ€” not source code, not prompts.

Principle Description
Deterministic Same manifest always produces the same application
Explainable Every step โ€” manifest, validation, plan, execution โ€” is inspectable
Incremental Only changed nodes are re-executed; existing work is preserved
Resumable Interrupted executions resume from the last checkpoint
Idempotent Running the same manifest twice produces no duplicate artifacts
AI-Friendly Designed for LLM-driven workflows and MCP tool interfaces
Adapter-Agnostic The engine is decoupled from any specific generation target

๐Ÿ“ฆ Public Packages

@averos/cli

Command-line interface for Averos.

npm install -g @averos/cli

Useful for:

  • CI/CD
  • Local development
  • Testing
  • Automation

Usage:

# Run averos
$> averos

Averos CLI v2.0.0

Usage:
  averos run   [<manifest>] [options]
  averos plan  [<manifest>] [options]
  averos status             [options]
  averos generate "<intent>" [options]

Commands:
  run       Execute a manifest against a workspace (real or dry-run)
  plan      Preview the execution plan without running anything
  status    Show the last build state for a workspace
  generate  Generate a manifest from natural language (requires @averos/ai)

Run options:
  --manifest=<path>          Manifest file path
  --mode=resilient|strict    Execution mode (default: resilient)
  --dry-run                  Preview commands without executing
  --resume                   Resume from last checkpoint on failure
  --timeout=<ms>             Per-session timeout in milliseconds
  --max-attempts=<n>         Retry attempts per node (default: 1)
  --tgz=<path>               Path to local @averos/workflow .tgz
                             (installs from npm registry when omitted)
  --development              development mode
  --averos-version=<semver>  Version string (required with --development)
  --logs-dir=<path>          Directory for per-node execution logs
                             (default: <workspace>/logs)

Plan options:
  --manifest=<path>          Manifest file path
  --json                     Output plan as JSON

Generate options:
  --run                      Execute the generated manifest immediately
  --output=<path>            Where to write the generated manifest
                             (default: averos-app.json)

Global options:
  --workspace=<path>         Workspace root (default: cwd)
  --config=<path>            Config file (default: averos.config.json)
  --verbose                  Debug output โ€” all node names, paths, timings

Examples:

  # Using a config file:
  averos run --config=/my/project/averos.config.json --dry-run

  # Real run from npm registry:
  averos run app.json --workspace=/tmp/myapp

  # Real run from local tgz:
  averos run app.json --workspace=/tmp/myapp \
    --tgz=./averos-lib-2.0.0.tgz \
    --averos-version=2.0.0

  # Dry-run:
  averos run app.json --workspace=/tmp/myapp --dry-run

  # Preview plan as JSON:
  averos plan app.json --workspace=/tmp/myapp --json

  # Show last build status:
  averos status --workspace=/tmp/myapp

Key :

averos plan generated-manifest.json --workspace=/tmp/gen-test app.json
averos run --config=averos-app-config.json

Commands:

  • averos run: Execute a manifest against a workspace
  • averos plan: Preview the execution plan without running
  • averos status: Show the last build state for a workspace
  • averos generate: Generate a manifest from natural language

Key Examples:

# Preview plan as JSON
averos plan app.json --workspace=/tmp/myapp --json

# Dry-run
averos run app.json --workspace=/tmp/myapp --dry-run

## Real run
averos run app.json --workspace=/tmp/myapp

# Run via config file
averos run --config=averos.config.json

# Show last build status
averos status --workspace=/tmp/myapp --verbose

# Generate manifest
averos generate "A CRM with contacts" --output=manifest.json

Config file (averos.config.json):

{
  "workspaceRoot":  "/tmp/my-application",
  "manifestPath":   "/tmp/my-manifest.json",
  "mode":           "resilient",
  "timeoutMs":      600000,
  "maxAttempts":    1,
  "logsDir":        "/tmp/my-application/logs"
}

๐Ÿ“™ See packages/cli/README.md for full reference


@averos/mcp

Model Context Protocol server โ€” exposes Averos as tools for Claude Desktop and any MCP-compatible AI client.

npm install -g @averos/mcp

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "averos": {
      "command": "node",
      "args": ["/path/to/node_modules/@averos/mcp/dist/index.js"],
      "env": {
        "AVEROS_SESSION_DIR": "/home/user/.averos/sessions"
      }
    }
  }
}

Available tools:

Tool Purpose
create_session Start a new design session
update_ir Edit the manifest (JSON Patch RFC 6902)
validate_ir Validate the manifest
build_execution_plan Build and preview the execution plan
approve_plan Approve or reject the plan
execute_plan Execute the approved plan
get_status Check session state
list_revisions View manifest revision history
rollback_revision Restore a previous manifest revision
diff_ir Compare manifest versions semantically

๐Ÿ“™ See packages/mcp/README.md for full reference


@averos/ai

LLM conversation and manifest generation layer.

# Full install including LLM generation
npm install -g @averos/cli @averos/ai

Provides:

  • Multi-turn conversations
  • Manifest generation
  • Manifest refinement
  • Validation-aware retries
  • LLM abstraction layer

Supported providers:

Provider Env variable Default model
Anthropic ANTHROPIC_API_KEY claude-sonnet-4-20250514
Google Gemini GEMINI_API_KEY gemini-2.0-flash
OpenAI OPENAI_API_KEY gpt-4o
Ollama โ€” qwen2.5-coder:7b
Local (LM Studio, vLLM...) โ€” configurable

Config for local Ollama:

{
  "llmProvider":   "ollama",
  "ollamaBaseUrl": "http://localhost:11434",
  "ollamaModel":   "qwen2.5-coder:7b",
  "llmTimeoutMs":  600000
}

Config for remote Ollama (LAN or VM host):

{
  "llmProvider":   "ollama",
  "ollamaBaseUrl": "http://192.168.1.50:11434",
  "ollamaModel":   "qwen2.5-coder:7b",
  "llmTimeoutMs":  600000
}

Example conversation:

User:   "Build a CRM with contacts and deals"
AI:     โ†’ Generates manifest

User:   "Add a priority field to deals"
AI:     โ†’ Updates manifest (surgical edit)

User:   "Add keycloak authentication"
AI:     โ†’ Updates manifest

User:   "Run it"
Averos: โ†’ Validates โ†’ Plans โ†’ Executes

Generate and execute:

# Generate manifest only
averos generate \
  "A project management app with Projects and Tasks. Tasks belong to Projects." \
  --output=/tmp/project-manifest.json \
  --workspace=/tmp/gen-run \

  # Generate and dry-run
averos generate \
  "A project management app with Projects and Tasks. Tasks belong to Projects." \
  --output=/tmp/project-manifest.json \
  --workspace=/tmp/gen-run \
  --run \
  --dry-run 

# Generate and execute
averos generate \
  "A project management app with Projects and Tasks. Tasks belong to Projects." \
  --output=/tmp/project-manifest.json \
  --workspace=/tmp/gen-run \
  --run 

๐Ÿ“™ See packages/ai/README.md for full reference


@averos/workflow

Workflow runtime and Angular Schematics adapter for the Averos execution platform.

Contains the complete library of Averos custom Angular schematics responsible for generating and updating application artifacts throughout the software lifecycle.

๐Ÿ“™ See packages/workflow/README.md for full reference


@averos/ui-platform

Reusable Angular UI components, layouts, themes and application building blocks designed to integrate seamlessly with Averos-generated applications.

Includes:

  • Forms
  • Tables
  • Form validators
  • Navigation
  • Authentication
  • Responsive layouts
  • Services
  • Configurations

๐Ÿ“™ See packages/ui-platform/README.md for full reference


โš™๏ธ Averos Core (internal)

The platform is internally powered by two deterministic engines:

  • Planning Engine
  • Execution Runtime

These are internal implementation details that power the public packages.

Planning Engine

The deterministic application planning engine.

Responsible for:

  • Manifest parsing and normalization
  • Structural, referential, and constraint validation
  • Dependency graph construction (DAG)
  • Topological sorting with deterministic tie-breaking
  • Execution plan generation

Example:

Manifest โ†’ Validator โ†’ Normalizer โ†’ DAG Builder โ†’ ExecutionPlan

Execution Runtime

Executes execution plans generated by the DAG engine.

Responsible for:

  • Dependency-ordered node scheduling
  • Adapter invocation with mutable workspace state
  • Per-node checkpointing for resumability
  • State persistence for incremental execution
  • Strict and resilient failure modes
  • Dry-run support (zero side effects)

Example:

ExecutionPlan โ†’ Scheduler โ†’ Adapter โ†’ Checkpoint โ†’ State โ†’ Generated Output

๐Ÿ—๏ธ Platform Architecture


โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚                    Entry Points                      โ”‚
โ”‚                                                      โ”‚
โ”‚     @averos/cli           @averos/mcp                โ”‚
โ”‚     (command line)        (MCP server / Claude       โ”‚
โ”‚                          Desktop / AI agents)        โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ 
			         โ”‚                  โ”‚
               โ–ผ                  โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚                   @averos/ai                         โ”‚
โ”‚         LLM Conversation + Manifest Generation       โ”‚
โ”‚   Anthropic ยท Gemini ยท OpenAI ยท Ollama ยท Local LLM   โ”‚
โ”‚													                             โ”‚
โ”‚				        AI Conversation Layer				           โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                           โ”‚  Application Manifest (JSON IR)
						               โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚              Planning Engine (core / internal)       โ”‚
โ”‚                                                      โ”‚
โ”‚  Parse โ†’ Validate โ†’ Normalize โ†’ Diff โ†’ DAG โ†’ Plan    โ”‚
โ”‚													                             โ”‚
โ”‚				        Validation & Planning 				         โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
                           โ”‚  Execution Plan
                           โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚             Execution Runtime (core / internal)      โ”‚
โ”‚                                                      โ”‚
โ”‚  Schedule โ†’ Execute โ†’ Checkpoint โ†’ Persist State     โ”‚
โ”‚													                             โ”‚
โ”‚				        Deterministic Runtime				           โ”‚  
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
						               โ”‚
						               โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚              ExecutionAdapter (pluggable)            โ”‚
โ”‚                                                      โ”‚
โ”‚  @averos/workflow  ยท  Custom adapters                โ”‚
โ”‚													                             โ”‚
โ”‚				      Execution Runtime Adapter			           โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
						               โ”‚
						               โ–ผ
              โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
              โ”‚  Generated Application  โ”‚
              โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

๐Ÿงฎ Deterministic by Design

Averos intentionally separates intent from execution:

Concern Owner
Understanding user intent LLM
Structural correctness Validator
Execution ordering DAG engine
Execution correctness Execution runtime
Side effects ExecutionAdapter

This separation provides:

  • Reproducibility โ€” same manifest, same result, always
  • Auditability โ€” every operation is logged and inspectable
  • Versionability โ€” manifests are diffable, rollbackable artifacts
  • Safety โ€” nothing executes before validation passes
  • Incremental evolution โ€” only changed nodes are re-executed

๐Ÿ”„ Revision-Based Development

Every application evolves through revisions.

Revision 1 โ†’ Revision 2 โ†’ Revision 3 โ†’ ...

Changes are represented as structured manifest updates.

This enables:

  • Diffing between any two revisions
  • Instant rollback to any previous state
  • Full audit trail of every change
  • Human approval before execution

๐Ÿค– AI-Native Workflow

Averos is designed around conversations that evolve an application over time.

Example:

User:    "Build a task management app"
AI:      Creates manifest โ†’ validates โ†’ shows plan
User:    "Looks good, proceed"
Averos:  Executes plan โ†’ generates application

User:    "Add a priority field to tasks"
AI:      Updates manifest (one field added)
Averos:  Diffs โ†’ 1 operation needed โ†’ executes only that

User:    " Actually a task has several task items"
AI:      Updates manifest (create task item and add a relationship with task)
Averos:  Diffs โ†’ 2 operation needed โ†’ executes only that

๐ŸŽฏ Design Goals

Goal Description
Deterministic Same manifest โ†’ same result, every time
Explainable Manifest ยท Validation ยท Plan ยท Execution โ€” Every step is visible
Incremental Applications evolve through revisions, not regeneration
AI-Friendly Designed specifically for modern LLM and MCP workflows
Engine-First The deterministic engine is the source of truth, not the LLM

๐Ÿšฆ Package Status

Package Status Description
@averos/cli โœ… Available Command-line interface
@averos/ai โœ… Available LLM manifest generation
@averos/mcp โœ… Available MCP server for AI clients
@averos/workflow โœ… Available Angular schematics adapter
@averos/ui-platform โœ… Available Reusable Angular UI components

๐Ÿ”ญ Vision

We believe software engineering will evolve from writing code to designing systems.

Humans describe intent. AI structures requirements. Deterministic engines guarantee correctness. Applications evolve through conversation.

The goal is not simply to generate code.

The goal is to make software construction reproducible, explainable, and evolvable.


๐Ÿ“™ Documentation

Full documentation: wiforge.com

Online Averos Designer: appbuilder.wiforge.com


โš–๏ธ License

Copyright ยฉ 2020-2026 Houssemeddine LAOUITI (Wiforge).

Released under the MIT License.


Built with โค๏ธ by the Wiforge team ยท

Contributors

Languages