Enterprise Enterprise — the wasm engine & causl-client

Causl ships a pure-TypeScript engine (causl-ts) as the open-source floor and reference implementation. As an Enterprise feature it also ships a Rust→WebAssembly engine, causl-wasm, consumed through a thin TypeScript API, causl-client. Both engines expose the same public Graph surface — the seven canonical primitives plus the thirteen second-tier extensions (SPEC §12.1 + §12.2), the full contract the wasm core satisfies over FFI (SPEC §18A.4). In causl-client the wasm path is the unconditional production engine (rust-ssot default); the pure-TypeScript engine is retained as the §12 conformance reference. The promotion gate documented in SPEC §18A.7 has been met.

Enterprise

The wasm engine is now sync-from-consumer. The one unavoidable async — the WebAssembly compile — is split from synchronous construction (SPEC §18A.12, shipped): await preloadCauslWasm() compiles and caches the module once at app init, then createCauslWasmSync() builds a wasm Graph with zero await at the call site, so sync consumers (React render, xldatagrid) can use it directly. createCauslWasm() is retained as preload ∘ createCauslWasmSync. The --target nodejs server glue is already synchronous end-to-end and needs no preload; only the browser bundler target does.

Explicit engine choice stays available: createCauslWasm() / createCauslWasmSync() (the wasm engine) and the internal engine: 'js-ssot' opt. In causl-client (SPEC §18A.13) the default public engine is wasm — createCausl() routes to the wasm engine (rust-ssot default) — driven by complexity elimination, with perf accepted as immaterial. Per §18A.13.1 (2026-06-23) it is wasm-default with a TS capability-fallback, not strictly "wasm-only": the implicit createCausl() degrades loudly to the retained internal createCauslTs on a WasmGC-unavailable host, while explicit wasm still fails loud. Deleting createCauslTs outright is dropped from near-term scope.

causl-client

Integrating causl-client

Consume the wasm artefact through @causl/core/wasm in a TS/Node application — loadWasmBackend(), the construction seam, and the structured WasmBackendUnavailableError fallback chain back to the TS floor.

Read the guide

SPEC §18A

Two-engine architecture

The causl-ts floor versus the causl-wasm production engine: the §18A contract, the shared public Graph surface (the §12.1 canonical seven plus the §12.2 second tier), and why both implementations are byte-identical and conformant for all adopter code.

Read the contract

SPEC §18A.7

Wasm performance & the perf ceiling

What the wasm path costs — FFI marshalling overhead, the atomicity contract at the bridge boundary, and the §18A.7 performance ceiling against which promotion is measured (GO/RESOLVED).

Read the numbers

@causl/core/wasm

Wasm API reference

The TypeDoc-generated reference for the @causl/core/wasm exports — loadWasmBackend, detectBridge, WasmBackendUnavailableError, and the BridgeFeatures surface.

View API

These Enterprise features require a production Rust build and a Node target (SPEC §18A.2). The §18A.7 GO/NO-GO gate has been met (all five criteria GO, 2026-06-21), so in causl-client the wasm path is the unconditional production default (rust-ssot). The TypeScript engine is the retained unconditional floor — byte-identical to the wasm engine for all adopter code — kept as the §12 conformance reference and the implicit-path capability fallback (§18A.13.1), and the value-of-record in the fork, not the default.