An application often needs more than a database: another API, a message topic, temporary shared data or authenticated user information. sigMAX exposes these operations as named host capabilities. The binary declares what it needs; the host resolves the actual service, credentials and policy.

This page describes the Rust runtime implementation. COS2000 has its own native provider and transport configuration; its supported operations must be matched explicitly when preparing a Pro deployment.

Outbound HTTP primitives support controlled calls with bounded requests and responses. Policy checks cover targets, methods, paths and headers, and the host applies request deadlines. A policy can use an allowlist or explicitly permit broader destinations, so the effective contract matters.

Typed service invocation goes through a logical binding. For example, an invoice handler can request a customer lookup by name; host configuration selects the receiving service and operation. Inputs and outputs are converted through declared types instead of handing infrastructure credentials to the module.

The Dapr client supports GET, POST, PUT, PATCH and DELETE. GET and DELETE inputs become scalar query parameters; the other supported verbs send JSON. See Dapr for the sidecar path and database storage for generated operations.

Handlers can publish either JSON or typed events. A binding maps the logical event name to a Dapr pub/sub component and physical topic. The host checks capabilities, resolves the binding and serializes typed payloads through the declared input type.

This enables a handler to emit an event such as an order being accepted while keeping broker names and addresses outside its WASM code. Event payloads are bounded to 1 MiB in the current Rust implementation, and publication attempts also have a per-request budget.

The publisher primitive does not provision a broker or define subscriptions, retries, ordering or delivery guarantees. Those belong to the selected Dapr component and consuming services.

The cache provides get, set, delete and integer increment operations. Set and increment require a positive TTL. The binding controls the maximum TTL, value size and namespace quota; the authenticated tenant identifier contributes to the namespace. Without a tenant identifier, the runtime uses a common fallback within that namespace.

The local backend also has a 64 MiB total bound. Redis uses atomic scripts for counter updates and quota accounting. The application Redis extent configures a private backend with bounded memory, append-only persistence and a noeviction policy; when full, writes can fail instead of displacing existing values. Studio’s orchestration Redis is a separate responsibility.

Cache entries can expire or be deleted, and the local backend is lost on restart. Keep authoritative records in database storage or file storage, and make cache misses a normal application path. A configured Redis backend reports connection failures rather than silently switching to a separate local cache.

Authorized handlers can read the subject and tenant identifier, test roles and permissions, and read selected string or integer claims. The Rust host obtains this context from the configured trusted authentication boundary; it does not treat arbitrary client-supplied headers as verified identity by default.

The Authentik integration combines frontend OIDC/PKCE and Traefik forward-auth. Trusted identity forwarding and access to the runtime must be configured together. See networking and identity for the implemented routing path.

The module can request HMAC-SHA-256 or HMAC-SHA-512 computation and verification using a logical secret reference. The host owns the key material; the primitive returns the result without copying the secret into WASM memory.

Signature primitives verify Ed25519 and RSA-PSS/SHA-256 signatures through approved public-key references. Hashing, Base64/Base64URL and random helpers serve separate purposes; encoding a value does not encrypt it.

These functions can support signed webhooks, integrity checks and token-related application logic. They do not imply a general signing service or a secret-export API.

The runtime also supplies checked integer and fixed-point decimal operations, bounded strings and bytes, UTF-8 normalization, regex, JSON access, CSV row parsing/building, XML helpers and gzip/Zstd compression. These helpers make common transformations available without granting native system access.

ObjectIR and DocIR provide structured API output and document generation. DocIR’s HTML, Markdown and bounded PDF renderers support report-like responses; they are not a browser engine for arbitrary HTML-to-PDF conversion.

All five layers must agree:

Missing bindings, denied capabilities, invalid types and exceeded bounds produce explicit errors.

Use the capability catalog to choose the service, then validate the operation against the actual runtime profile and generated API scenarios. Agreements record artifact and test evidence; they do not replace operating the target dependency.