sigMAX Pro
sigMAX Pro
Section titled “sigMAX Pro”Pro is the Kubernetes edition of sigMAX. COS2000 executes WebAssembly inside virtual machines managed by KubeVirt. This places the executor’s operating system behind a VM boundary, separate from the Host and Config services.
Pro and Core are the two proprietary sigMAX editions. They share contracts, generation and validation concepts; their deployment and execution architectures differ.
Explore the COS2000 executor Discuss a Pro deployment
Deployment model
Section titled “Deployment model”The diagram describes roles and boundaries. It does not prescribe one VM per request, one VM per module or automatic scaling behavior.
| Layer | Responsibility |
|---|---|
| Host + Config | Platform execution coordination and configuration |
| Kubernetes | Platform orchestration |
| KubeVirt | Virtual-machine lifecycle within Kubernetes |
| COS2000 | Executor operating system, module management and application services |
| WAMR | WebAssembly execution inside COS2000 |
What changes from Core
Section titled “What changes from Core”Core places Host, Config and containerized WASM execution on the same host. Pro moves the WASM executor into a COS2000 VM managed by KubeVirt.
| Criterion | Core | Pro |
|---|---|---|
| Deployment | Docker Compose, one host | Kubernetes |
| Execution environment | Containerized Rust runtime | COS2000 VM |
| Inspected WASM engine | Wasmtime | WAMR |
| Dedicated execution isolation | No executor VM | VM boundary around the executor |
| Operating requirements | Host and container operations | Cluster, virtualization and guest lifecycle operations |
| License | Proprietary | Proprietary |
A VM boundary does not replace module validation, capability checks, network policy or resource limits. In COS2000, HTTP services use WAMR inside the guest kernel. The standalone ring-3 interpreter is a separate execution path; it must not be confused with application-service execution.
The COS2000 execution service
Section titled “The COS2000 execution service”The executor implementation includes module validation, bounded memory, execution budgets and sigMAX host primitives. It separates management, application traffic, health checks and metrics. Management uses HTTPS with mutual TLS; the collector identity has a distinct metrics role.
COS2000 provides safe and performance instance policies. safe discards an instance after use; performance may preserve guest memory, globals and tables between requests. These policies do not start a new VM for each call.
The COS2000 reference explains the execution profile, interfaces, compatibility limits and artifact distribution.
Integration status
Section titled “Integration status”The platform capability catalog also covers databases, file storage, routing, identity, cache and monitoring. The Pro VM boundary does not replace these application services: COS2000 reaches permitted dependencies through its native provider and configured adapters. The COS2000 reference explains which operations are local to the guest and which require an external service.
The product architecture is Kubernetes + KubeVirt + COS2000. The inspected COS2000 source implements the executor, but its KubeVirt deployment and Kubernetes Service resources are external to that repository. The inspected sigMAX_runtime checkout does not contain the complete Host/Config-to-COS2000 integration or deployment manifests.
A working executor and a specified platform architecture do not, by themselves, demonstrate an end-to-end Pro release. Deployment manifests, component versions, networking, certificates and integration validation must accompany the delivered version.
Access and scope
Section titled “Access and scope”Contact the project for availability, packaging and licensing terms. This architecture does not imply an included SaaS service, a support SLA, audited tenant isolation, automatic high availability or a particular storage product.