sigMAX Overview
sigMAX Overview
Section titled “sigMAX Overview”sigMAX is a proprietary platform for generating, assembling, validating and executing modular applications. Contracts describe the expected system; agreements record the produced artifacts; the runtime executes WebAssembly with explicit host capabilities.
There are two editions: Core, with Docker Compose on one host, and Pro, with Kubernetes and COS2000 executors in KubeVirt VMs.
Contract-first pipeline
Section titled “Contract-first pipeline”- Intent & constraints — application goals and operating requirements. Check scope and assumptions.
- Contracts — application, component and binary descriptions. Check interfaces, dependencies and allowed capabilities.
- Structured pseudo-code — validated executable logic. Check grammar, types, bounds and primitives.
- Compile & package — WASM artifacts and deployment inputs. Check compiler versions, digests and import compatibility.
- Agreements — produced-state records and evidence. Compare with the declared contracts.
- Runtime — application responses and operational signals. Inspect limits, errors and behavior.
The current Studio toolchain validates pseudo-code through a Rust parser and canonical AST, then generates C or MoonBit before WASM compilation. COS2000 also has its own Radjae compiler path to WASM. Their supported profiles and evidence must be checked individually; a shared file format does not prove runtime compatibility.
LLMs may propose contracts and pseudo-code. The deterministic claim applies to validated compilation steps with fixed inputs and toolchains, not to unrestricted prompt-to-application generation.
Contracts and agreements
Section titled “Contracts and agreements”| Level | Contract describes | Deployment relationship |
|---|---|---|
| Application | Components, dependencies, networks and operating constraints | Core single-host topology or Pro Kubernetes architecture |
| Component | A domain responsibility, interfaces and adapters | May map to containerized services and executor resources |
| Binary | WASM behavior, inputs, outputs, limits and permitted primitives | Must match the selected executor’s ABI and capabilities |
A contract is the declared target. An agreement records what the pipeline actually generated, compiled, packaged or observed. Drift detection compares the two; it does not replace functional tests or prove that a system is secure.
Core and Pro execution models
Section titled “Core and Pro execution models”Core · Docker Compose
Host + Config share one host. WASM runs in the containerized Rust runtime, without a dedicated execution environment or executor VM.
Wasmtime enforces bounded memory, execution budgets and explicit host functions inside that shared deployment boundary.
Pro · Kubernetes + KubeVirt
Kubernetes hosts the platform. COS2000 executes WASM in a KubeVirt VM, separating the executor OS from Host + Config.
COS2000 embeds WAMR for application services. Instance reuse and VM lifecycle are separate: Pro does not imply a fresh VM per request.
| Boundary | Meaning |
|---|---|
| WASM checks | Linear-memory bounds, valid imports and execution limits enforced by an engine |
| Instance policy | Whether guest memory and globals may survive between requests |
| Container | Packaging and process environment on the host kernel |
| VM | Separate guest OS for the Pro executor |
Read WASM execution boundaries for the security implications. Container packaging, fresh WASM instances and VM isolation must not be described as equivalent.
Host capabilities and service integration
Section titled “Host capabilities and service integration”WASM business logic uses declared primitives rather than directly opening a database connection or assuming arbitrary system access. The host supplies the implementation and enforces the applicable capability policy.
The Rust runtime contains service, storage, HTTP, identity, secret, event and cache primitives. Dapr supports service integration, while the storage service owns generated database operations. COS2000 has its own native primitive provider and compatibility profile.
Applications can combine PostgreSQL data, MinIO files, Redis cache, Traefik routing and TLS, Authentik identity, WireGuard access and monitoring. Studio also manages project history, generation jobs and frontend authoring. The platform capability catalog explains these services and their relationships; runtime integrations describes what business handlers can call.
The effective set of imports, limits and integrations must match the binary contract and the deployed executor version.
Components and coupling
Section titled “Components and coupling”A component defines a domain responsibility before choosing its deployment unit. Closely related behavior can use typed local interfaces; independent components can communicate through versioned HTTP APIs or declared events.
This distinction makes network dependencies, failures and ownership visible. Microservices remain a deployment tool, while contracts describe the application structure.
Operational evidence can include route metadata, OpenAPI documents, health checks, metrics, logs and generated agreements. See observability for the implemented surfaces rather than assuming that every edition includes the same monitoring stack.
Implementation status and access
Section titled “Implementation status and access”The inspected runtime sources implement Wasmtime execution, Studio and Docker Engine topology management. They do not include a verified Host + Config Compose distribution or the complete Pro KubeVirt deployment chain. COS2000 implements its executor services; cluster resources and integration remain external to that source tree.
sigMAX is not open source. Dependency licenses are separate from the licensing of Core and Pro. Studio is an interface, not an edition, and the former Enterprise name is superseded by Pro.