Primitives are controlled capabilities exposed by the runtime to WASM modules.

They are the explicit host API used by generated or authored WASM code when it needs to interact with the sigMAX runtime.

Instead of allowing a WASM module to access the host system directly, sigMAX exposes a catalog of named imports under the runtime namespace. Each primitive represents one capability: reading input, writing a response, emitting observability events, validating data, calling an allowed service, or working with bounded runtime state.

Primitives define the API between a WASM module and runtime services. This API boundary is distinct from infrastructure isolation.

Availability and enforcement depend on the selected runtime and executor version. The family catalog below details the surface.

In Core, Host and Config share one Docker Compose host and WASM executes in a container without dedicated execution isolation. In Pro, the COS2000 executor runs in a KubeVirt VM under Kubernetes. A primitive API does not, by itself, create the VM boundary.

The Rust host and COS2000 native provider implement the host side of the ABI for their respective execution paths. The executor must expose a compatible import and transport interface; do not assume that every import supported by one engine is automatically supported by another.

The runtime owns the host side of the ABI.

A WASM module does not receive direct access to files, sockets, environment variables, system clocks or secrets. It receives imports registered by the runtime. Those imports read and write WASM linear memory, validate input sizes, translate runtime state into typed values, and return compact error codes when an operation is not allowed or cannot be completed.

Family	Purpose
📥 Input	Read route parameters, headers, request objects and JSON payloads prepared by the runtime.
↩️ Response	Set status, add headers and commit the response body.
🧱 Object output	Build structured output with typed fields, arrays and null values.
📄 Documents	Build DocIR documents rendered as HTML, Markdown or bounded PDF.
⚠️ Errors	Raise runtime or validation errors in a consistent representation.
📡 Observability	Emit logs, trace markers and metrics from inside the WASM execution.
🛡️ Capabilities	Check whether the current route can use a named runtime capability.
🔎 Regex and JSON	Perform bounded text matching, removal and JSON path extraction without exposing a general host library surface.
🔐 Crypto and encoding	Compute hashes and encode or decode data with bounded input and output sizes.
⏱️ Time and random	Produce timestamps, formatted dates, UUIDs or bytes through runtime-controlled helpers.
🌐 HTTP and invocation	Call allowed targets or typed service bindings through runtime policy.
🔑 Secrets	Use approved secret references without exposing raw host secret management.
🪪 Identity	Read a trusted subject, tenant, roles, permissions and selected claims.
✅ Schemas	Validate bounded values against declared contract schemas.
📦 Files and blobs	Read, write, inspect and delete objects through declared storage bindings.
📨 Events	Publish JSON or typed events to a configured topic.
⚡ Cache	Read, write, delete or atomically increment temporary values with TTL and quotas.
🗃️ State	Read or write values scoped to the current request.
🔢 Business data	Use checked arithmetic, fixed-point decimals, bounded strings, UTF-8 and bytes.
🔄 Formats	Parse or build CSV rows, inspect bounded XML, and compress/decompress gzip or Zstd buffers.

The platform capability catalog connects these primitives to application services. Runtime integrations explains cache lifetimes, event publication, trusted identity and host-owned secrets.

Some primitives are always part of the runtime surface, but sensitive operations are guarded by capabilities.

For example, a route can be allowed to extract JSON fields, call an HTTP target, generate random bytes, use a secret reference, or invoke another service. If the current route does not declare the required capability, the primitive returns a denied error instead of performing the operation.

This keeps generated code honest: the code can only do what the contract and effective runtime context allow.

Primitives are intentionally bounded.

The runtime validates pointer ranges, buffer sizes, string lengths, body sizes, header counts, regex input sizes, JSON payload sizes, secret reference lengths and random byte lengths before completing host work. When the caller provides an invalid argument, an unsupported operation, a missing value or a too-small output buffer, the primitive returns a stable error code.

This matters because primitives define the declared bridge between module code and runtime services.

External calls are governed by runtime policy. Some signed-contract policies can allow broader outbound HTTP access, so the effective policy must be inspected before claiming that all targets are restricted to a fixed allowlist.

HTTP and typed service invocation primitives are routed through runtime policy:

• targets must be allowed by name or by policy;
• methods and paths are checked;
• request and response sizes are bounded;
• JSON bodies are validated before sending;
• typed service calls are decoded and encoded through known type definitions;
• unsupported binding kinds fail explicitly.

Both editions use explicit runtime capabilities. The deployment differs: Core keeps execution in the container stack, while Pro places COS2000 in a VM. Infrastructure integrations and permitted targets must be described by the deployed configuration and contracts.

A primitive should be small, named and auditable.

It should expose one runtime capability, return predictable errors, respect the current route capabilities, and avoid hiding infrastructure behavior inside generated code.