Compatible Operating System · WASM Execution Loader. COS2000 provides the WASM loading and execution role in the sigMAX constellation.

COS2000 is a minimalist x86-64 operating system used as the WebAssembly executor in the sigMAX Pro architecture. Written primarily in C with x86 assembly, it includes its own kernel, device drivers, network stack, HTTP services and execution tools. It boots directly in a virtual machine; it does not require a Linux distribution inside that VM.

For sigMAX Pro, KubeVirt manages the VM on Kubernetes. Inside it, COS2000 compiles or loads WASM modules, exposes application routes, performs permitted native operations and reports execution diagnostics. Host and Config remain separate services outside the executor VM.

Explore all runtime capabilities Explore sigMAX Pro

COS2000 combines a WASM engine with the sigMAX primitive catalog. A contract declares its inputs, outputs, allowed imports and resource bindings; the module uses those declared interfaces to perform useful work.

The primitive implementations are native freestanding C in COS2000. The compiler reuses the pinned sigMAX primitive catalog and ABI; it does not launch the Rust Host runtime inside the VM. A supported primitive still needs its allowed import and, where applicable, a valid binding or trusted resource.

The external adapters connect application logic to services outside the VM. For example, a handler can validate an order, invoke an inventory API, save a document through a blob adapter and notify an event endpoint. Each target is named in the contract and resolved by the executor’s binding configuration.

Blob adapters transfer raw bytes over HTTP(S), with a current limit of 1 MiB per object. Logical keys are checked before the host constructs the destination URL. blob.head currently obtains the size through a bounded GET because the transport does not expose response headers; it is not a metadata-only remote HEAD request.

Database access follows the same service boundary: configure an HTTP or invocation adapter for the relevant database-service endpoint. COS2000 does not embed PostgreSQL, an SQL driver, MinIO, Redis or a Dapr sidecar. Existing dapr_* binding names need an explicit COS2000 URL adapter; component and application names alone do not resolve a destination. The file storage and database service pages describe the wider sigMAX service implementations and their APIs.

HTTP bindings normally use fixed destinations. An explicit URL-argument mode can accept a request-supplied URL restricted by an origin allowlist. Redirect following is opt-in for bodyless GET/HEAD, limited to five hops, and rechecks every destination. HTTPS certificate verification remains enabled, and HTTPS-to-HTTP redirects are rejected.

The native cache supports get, set, delete and checked integer increments with TTL and quotas. Its namespace includes the binding, component and trusted tenant identifier when one is available. The inspected implementation permits up to 256 entries and 4 MiB of charged data across the executor. Cache contents disappear on reboot. They are neither a distributed cache nor durable database records.

state.* operations belong to the current request context. That context is renewed for every invocation, including when the WASM instance itself is reused. Temporary request state, shared cache and persistent external storage therefore have distinct lifetimes.

Cryptographic primitives include SHA hashes, HMAC and Ed25519/RSA-PSS signature verification. HMAC accesses a provisioned secret by logical reference without returning the secret bytes to WASM. The runtime can expose the authenticated controller certificate fingerprint as the request subject, or local for local execution. Tenant IDs, roles and claims require a trusted identity provider; their presence is not inferred from untrusted request fields.

Core deploys Host and Config together on one Docker Compose host, with WASM execution in the container and no dedicated execution isolation. Pro places the executor operating system inside a VM. The execution boundaries page explains the roles of WASM checks, containers and virtual machines.

Application listeners route requests to configured WASM exports. Kubernetes ingress and the platform’s reverse proxy remain deployment components outside COS2000; an outbound HTTP primitive is a service client, not an ingress controller.

The management API can list, upload, inspect, replace and delete modules and route configurations. Module metadata includes size, SHA-256 and validation state; retained binary, contract and pseudo-code artifacts can be retrieved separately. Configurations are uploaded disabled and explicitly enabled or disabled. A referenced module cannot be deleted, and enabled configurations must be disabled before deletion.

COS2000 can also pull a publication over HTTPS using a cos2000.sync/v1 manifest: at boot, periodically, or after an authenticated refresh notification. A configured origin can serve a node-specific manifest selected by MAC address or IPv4, with a shared manifest as the documented 404 fallback.

The pull path verifies artifact sizes and SHA-256 hashes, waits for active work to drain, prepares a candidate registry and activates it atomically. A failed publication preserves the previous modules, routes and enabled state. This is atomicity for one executor’s registry, not a cluster-wide rollout guarantee.

The VM retrieves published artifacts rather than cloning Git or running repository hooks. A controller or build pipeline produces and publishes those artifacts. The registry is held in RAM; synchronization or explicit upload restores its contents after reboot.

Default ports are configurable through identity provisioning.

Management paths under /v1/ are never forwarded through the application listener. A successful health probe reports liveness; module readiness and HTTPS identity provisioning have separate status.

Management HTTPS uses mutual TLS, certificate-chain validation and an exact fingerprint for the authorized controller. A separately provisioned collector can read /metrics without receiving management or execution permissions. Outbound synchronization has its own client identity, restricted to the configured origin. Ordinary outbound HTTP primitives do not transmit that identity or the controller’s credentials.

The integrated engine is WAMR, with distinct service and standalone paths.

An instance has one active borrower at a time. Traps and exhausted fuel discard the affected instance. These policies operate inside an existing VM; they do not create a VM for every request.

COS2000 can execute WASM requests on secondary CPU workers while CPU 0 manages networking, TLS, shared services and the console. Request-local native work such as hashing or JSON processing can run on workers. Shared resources retain their required serialization.

The scheduler offers direct execution, asynchronous suspension while waiting for I/O, cooperative fairness and a preemptive mode with eligible task migration. A waiting task keeps its exclusive WASM instance and private context; concurrency still consumes bounded task and instance-pool capacity. Without secondary workers, execution falls back to CPU 0.

Execution engine, scheduling and instance lifetime are separate settings. Optional optimized JIT and CPU acceleration depend on the build profile and instructions exposed to the guest. They do not imply the same throughput on every host or hypervisor.

The inspected execution profile sets four bounds:

The upload registry has its own larger acceptance bound; accepting an artifact does not mean it can execute.

Native operations have separate checks and budgets. Fuel is not elapsed time or CPU cycles: a network wait can consume time without consuming WASM instructions. Task deadlines, transport limits, native-call checks and pool admission complement the instruction budget. These software controls and the VM boundary serve different purposes.

COS2000 provides an x86-64 UEFI boot environment, memory and process management, a framebuffer console and USB input. Its network stack supplies Ethernet, ARP, IPv4, ICMP, TCP/UDP, DNS, DHCP and clock synchronization, with modern Virtio-net as the QEMU default. Network status and diagnostic commands expose addressing, link state and retained driver failures. These are OS facilities; WASM modules reach external resources through their declared primitives and bindings.

Boot configuration covers network addressing, DNS, clock synchronization, execution defaults, artifact synchronization and identity provisioning. Generated configuration is packaged in the boot image. Runtime shell changes do not automatically persist into the next boot.

The local console is trusted administration without a user-login model. Remote administration keeps its separate mTLS policy.

The COS2000-specific screen.print primitive can draw bounded UTF-8 text or individual pixels on the local console when explicitly allowed. This is local display output, separate from a service’s HTTP response or a browser frontend.

Published modules, routes, pseudo-code and contracts appear as read-only files under /ram. A separate /ram/files workspace supports a bounded set of editable text files and loses its contents at reboot. It does not replace application file storage or a persistent volume. Boot-image files and published registry artifacts cannot be modified by saving an Explorer draft.

The current implementation includes a local halt command. It begins immediately, cancels outstanding service work and waits up to five seconds for it to drain. If that phase cannot complete, shutdown is cancelled before device teardown and the shell remains available for diagnosis.

After this barrier, COS2000 stops the network and USB devices, attempts to stop secondary CPUs and requests firmware power-off through UEFI. A limited ACPI S5 fallback is available when the supported firmware data permits it; it is not a general AML interpreter. Once device teardown has begun, the path does not return to the shell. A failure to confirm CPU shutdown, or a firmware call that returns, leaves a diagnostic explaining that the machine is halted but still powered.

This is a guest operating-system operation, separate from KubeVirt’s VM lifecycle. It does not persist the RAM registry, cache or editable workspace, and it does not establish a Kubernetes graceful-termination integration.

The management HTTPS /metrics endpoint exports Prometheus measurements for requests, invocations, fuel, memory, instance pools and JIT compilation. Application and management journals give operational summaries; correlated diagnostics connect a request with its worker, WASM instance, native calls and network waits.

Application responses carry X-COS2000-Request-Id. An authorized controller can retrieve the retained timeline or request a diagnostic capture through /v1/diagnostics; the shell provides the same inspection family. Histories are bounded and in memory, with explicit indicators for dropped events or incomplete captures. A capture is not a stop-the-world snapshot or a source-level trace of every instruction.

In KubeVirt, each VM needs a distinct metrics target and stable labels. Combining VMs behind one load-balanced target would mix independent counter histories. COS2000 holds current counters; external Prometheus-compatible storage supplies history, dashboards and alerting.

These capabilities were checked against the sibling cos2000v2 source tree. Paths identify implementation evidence, not public download links.

Source paths by subsystem

Area	Source paths
OS and provisioning	README.md, docs/NETWORK.md, docs/CPU.md, docs/IDENTITY.md
Compiler and typed contracts	services/compiler_service.c, docs/PSEUDO_CODE.md
Primitive implementations	services/primitives.c, services/primitives_crypto.c, docs/PRIMITIVES.md
External resources and cache	services/primitives_external.c, services/PRIMITIVE_BINDINGS.md
Services and publication	services/api.c, services/sync.c, docs/SERVICES.md, docs/SYNC.md
Engine and scheduling	wasm/module.c, wasm/kernel/config.h, lib/workers.c, docs/ASYNC.md
Local tools	docs/PSEUDO_CODE.md, docs/EXPLORER.md, docs/WASM.md
Controlled shutdown	lib/power.c, lib/uefi_power.c, lib/acpi_power.c, lib/smp.c, services/server.c
Metrics and diagnostics	services/metrics.c, services/diagnostics.c, docs/METRICS.md, docs/DIAGNOSTICS.md

Continue with the capability catalog, sigMAX Pro or WASM execution boundaries.