sigMAX Overview

sigMAX Overview

sigMAXoverviewcontract-firstruntimeWebAssemblycontractsagreementsvalidation

sigMAX is a contract-first platform for generating, assembling, validating, and executing modular applications. It uses LLMs for architectural intent and structured contracts, then relies on deterministic generation and a controlled runtime to produce verifiable artifacts.

Core idea

Describe the intent. Generate the components. Prove what was produced.

Why sigMAX exists

Modern applications are often fragmented across services, APIs, infrastructure glue, generated code, and observability stacks. When AI-generated code enters that system, the risk is not only a local bug. The risk is generative drift: produced artifacts slowly diverge from the architecture, constraints, and security expectations that were declared at the beginning.

sigMAX addresses that drift by turning architecture into explicit contracts and checking the produced result against agreements.

Contract-first pipeline

Contracts

sigMAX uses three contract levels.

Level	Contract	Item	Scope	Purpose
1	Application Contract	Core: Docker Compose stack Enterprise: cloud native application	Application	Describes the full application architecture, services, networks, dependencies, exposure, and constraints.
2	Component Contract	OCI container	Autonomous Component	Describes one autonomous component, usually packaged as a standardized container.
3	Binary Contract	WASM module	Executable part	Describes a WASM executable, its interfaces, capabilities, execution constraints, and allowed primitives.

Agreements

Agreements describe what was actually produced after a contract has been processed. They are generated artifacts, usually JSON, and represent the effective system state: generated files, compiled binaries, exposed endpoints, packaged images, runtime capabilities, or validation evidence.

Contract

A contract is the declared target state. It says what should exist before generation or execution: architecture, components, binaries, capabilities, endpoints, limits, and security boundaries.

Agreement

An agreement is the effective produced state. It records what the pipeline actually generated, compiled, packaged, exposed, and validated.

Runtime model

The runtime executes WASM artifacts in a controlled environment. Components are containerized, portable, observable, and designed around explicit endpoints such as health checks, metrics, OpenAPI descriptions, and discovery metadata.

The runtime can expose controlled primitives, storage operations, and internal service communication while keeping host exposure narrow. Dapr can be used internally for component-to-component concerns without making every sidecar public on the host.

Runtime layer	Responsibility
Container	Packages the component, endpoints, runtime, binaries, metadata, and observability surfaces.
Rust runtime	Loads WASM modules, exposes controlled primitives, enforces execution boundaries, and emits runtime evidence.
WASM components	Execute generated business logic through explicit imports instead of uncontrolled native calls.

WebAssembly

sigMAX uses WebAssembly as the portable execution layer for generated business logic. The project does not treat generated code as arbitrary host code: logic is compiled into WASM modules and executed through the Rust runtime with declared imports, limits, and capabilities.

Execution boundary

A WASM module can only interact with the outside world through primitives exposed by the runtime. Storage, logging, routing, JSON processing, document generation, and metrics remain explicit runtime capabilities.

Why WASMWhat sigMAX adds

• portable execution target;
• sandboxed by default;
• reproducible binary artifacts;
• small deployment surface;
• clear contract between logic and runtime.

• Binary Contracts before compilation;
• Binary Agreements after generation;
• controlled runtime primitives;
• validation between expected and effective capabilities;
• component-level packaging and observability.

Standardized components

A sigMAX application is assembled from autonomous, standardized, independently deployable components. Each component is discoverable, versioned, observable, testable, and executed by a standardized Rust runtime.

The component carries its expected state and its effective state:

Artifact	Role
component.yaml	Component Contract describing expected APIs, routes, permissions, schemas, WASM capabilities, limits, and observability.
component.json	Component Agreement describing generated endpoints, loaded WASM modules, callable functions, runtime configuration, versions, hashes, and build metadata.
binary/*.yaml	Binary Contracts describing executable expectations.
binary/*.json	Binary Agreements describing effective executable artifacts.

Coupling modes

sigMAX distinguishes two coupling modes.

High couplingLow coupling

High coupling is used inside a functional domain or component. It favors low latency, strongly typed exchanges, explicit WASM interfaces, runtime primitives, and frequent internal calls.

Low coupling is used between independent components. It favors REST, JSON, OpenAPI, events, webhooks, independent deployment, versioning, resilience, and observable network boundaries.

Discoverability and observability

Components should expose explicit discovery and operational surfaces:

• .well-known metadata;
• OpenAPI descriptions;
• route and schema definitions;
• health endpoints;
• metrics;
• logs and traces;
• test artifacts.

Infrastructure model

The Application Contract can describe infrastructure expectations: networks, services, gateways, Dapr usage, storage, security boundaries, exposed ports, internal ports, and deployment constraints.

In sigMAX Enterprise, the infrastructure model targets a fully managed cloud native application. The platform can incorporate end-to-end network management: certificate generation, reverse proxy configuration, ingress controller rules, internal service routing, TLS termination, public/private exposure policies, and component discovery.

Default exposure model

Prefer a narrow public edge such as Traefik or Nginx in front of gateway/application components. Internal sidecars and services can listen inside the container network without being published on the host.

Enterprise managed network

The Enterprise edition manages the network boundary as part of the generated platform: certificates, reverse proxy, ingress controller, DNS or host routing, service-to-service paths, security headers, and runtime observability endpoints can all be derived from the Application Contract.

Design principles

GenerationRuntimeValidation

• Intent-driven architecture
• Contract-first artifacts
• Controlled pseudo-code
• Deterministic C/WASM generation
• Reproducible outputs

• WASM sandboxing
• Container isolation
• Explicit imports
• Declarative storage
• Internal Dapr integration

• Contract to Agreement comparison
• Drift detection
• Auditability
• Observability
• Portable OCI packaging

What LLMs can and cannot do

LLMs can help generate architecture, contracts, component descriptions, binary contracts, and controlled pseudo-code. They should not be treated as an unchecked source of arbitrary final runtime code. sigMAX keeps the boundary clear: the LLM describes structured intent and logic; deterministic tooling produces the executable artifacts.

✅ LLMs can do	⛔ LLMs cannot do
Interpret functional intent and constraints.	Bypass contracts, agreements, or validation.
Propose application structure, components, and boundaries.	Produce unchecked final runtime code directly.
Draft Application, Component, and Binary Contracts.	Grant themselves runtime capabilities or native access.
Generate controlled pseudo-code and documentation drafts.	Decide infrastructure exposure without declared constraints.
Help explain generated artifacts and validation results.	Replace deterministic compilation, packaging, and proof steps.

Open the tag index

https://sigmax.dev/docs/sigmax/