Introduction
Introduction
Section titled “Introduction”sigMAX means Secure Integrated Generator of Modular Architecture with eXecution runtime. It connects application intent, explicit contracts, generated artifacts and runtime behavior so teams can inspect what they asked for and what was produced.
sigMAX is proprietary software with two editions: Core and Pro. The key distinction is where the platform runs and how WASM execution is separated from it.
Choose the deployment architecture
Section titled “Choose the deployment architecture”Single-host deployment
CoreDocker Compose
One shared host. Host, Config and WASM execution share the machine. Engine checks apply inside the container; there is no dedicated executor VM.
Cluster deployment
ProKubernetes + KubeVirt
A separate executor OS. COS2000 runs WASM inside a KubeVirt VM, separating the executor from Host and Config. This does not imply one VM per request.
Shared foundation · two proprietary editions
- Explicit contracts
- Generation & validation
- Agreements & drift detection
- WebAssembly execution
Engine checks ≠ VM isolation. Core enforces memory and capability checks inside its runtime; Pro adds a VM around COS2000. Read the execution boundaries for each layer’s limits.
From intent to an observable application
Section titled “From intent to an observable application”- Describe the intent. State the functional goal and operating constraints.
- Define contracts. Describe application topology, component responsibilities and binary interfaces.
- Generate controlled artifacts. Validate structured pseudo-code before deterministic compilation steps.
- Record agreements. Capture the files, binaries, interfaces and evidence actually produced.
- Compare and operate. Detect differences from the contracts and inspect runtime behavior.
LLM-assisted drafting can help with intent, contracts and pseudo-code. It does not make generation deterministic from the original prompt. Reproducibility concerns validated inputs, fixed toolchains and the deterministic steps that follow them.
Components before services
Section titled “Components before services”sigMAX uses a hexagonal architecture approach: a component represents a domain responsibility, with explicit inputs, outputs and adapters. A service or container is a deployment choice for that component.
This keeps application boundaries visible without requiring every function to become a network service. Calls inside a component and calls across services have different costs and failure modes; contracts make those choices inspectable.
| Concept | Role |
|---|---|
| Application Contract | Expected application structure and deployment constraints |
| Component Contract | A responsibility, its interfaces and permitted dependencies |
| Binary Contract | Executable behavior, inputs, outputs and allowed primitives |
| Agreement | Evidence of what was generated, compiled or observed |
| Drift detection | Comparison of expected and effective artifacts |
The component model, contracts and agreements develop these concepts.
Read by task
Section titled “Read by task”- Product architecture Understand the complete sigMAX model.
- Platform capabilities Explore implemented features.
- File storage Store files and project artifacts.
- Database storage Relational data and migrations.
- Networking & identity Reverse proxy, TLS, login and VPN.
- Runtime integrations APIs, events and cache.
- Studio interface Projects and frontend content.
- Core / Pro Choose an edition.
- Generation overview Understand compilation.
- Rust runtime Inspect the container runtime.
- COS2000 Inspect the VM executor.
- Primitives Permitted host operations.
- FrontMark Publish documentation.
- sigMAX constellation Explore the software family.
- Contact sigMAX Request access.
Architecture and implementation status
Section titled “Architecture and implementation status”These pages describe the Core/Pro product architecture and identify which mechanisms are present in the inspected source. The runtime repository currently contains Rust/Wasmtime execution and Docker Engine topology operations. COS2000 implements its WASM services; the complete Core Compose distribution and Pro Kubernetes/KubeVirt integration are not established by those repositories alone.
Read the beta status before relying on an installation procedure or release capability. Studio is the platform interface, not another edition; the former Enterprise name now points readers to Pro.