Primitives
Primitives
Section titled “Primitives”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 small set 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.
What Primitives Do
Section titled “What Primitives Do”Primitives form the boundary between a sandboxed WASM module and the host runtime.
They are responsible for:
- read request inputs such as route parameters, headers, encoded objects and JSON payloads;
- build responses through status codes, headers and committed response bodies;
- construct ObjectIR-like output structures through typed fields, arrays and null values;
- raise runtime or validation errors in a predictable format;
- emit logs, traces and metrics;
- check whether the current route is allowed to use a capability;
- perform bounded helpers such as regex matching, JSON extraction, hashing, base64 encoding, time formatting and random value generation;
- execute allowed HTTP or service calls through runtime policy;
- read secrets only through approved references;
- read and write scoped runtime state.
They deliberately do not:
- open arbitrary files on the host;
- create raw sockets or free-form network connections;
- read environment variables directly;
- bypass route capability checks;
- expose raw secret stores to WASM code;
- grant native system calls or unrestricted host libraries.
Runtime Boundary
Section titled “Runtime Boundary”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.
Primitive Families
Section titled “Primitive Families”| 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. |
| ⚠️ 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. |
| 🗃️ State | Read or write scoped runtime state values by key. |
Capability Checks
Section titled “Capability Checks”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.
Bounded Operations
Section titled “Bounded Operations”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 sit at the only bridge between sandboxed code and the host runtime.
External Calls
Section titled “External Calls”External calls are not free-form network access.
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.
In Core, these primitives provide a controlled local runtime surface. In Enterprise deployments, the same model can be connected to managed infrastructure, ingress, private services and operational policies without changing the WASM module’s contract-first boundary.
Design Rule
Section titled “Design Rule”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.