Documentation.

Everything that ships with the engine: the canonical specification, per-package API references generated from the source on every build, the repository's audit trail, and a growing set of topic guides that explain the moving parts in narrative form.

Specification

The canonical source of truth.

SPEC.md is the document the engine, the static checker, and the bounded model checker all answer to. SPEC.async.md adds the composite statechart for fetched resources and conflicts. The per-repo copies have diverged: measured on 2026-08-02 they run 3333 lines against 3280, with the causl-core-ts copy missing §5.1 Amendments 5 to 7 and §5.7. Do not treat any copy as byte-identical to another.

SPEC.md

Core specification

The canonical engine spec: denotational semantics (Behavior a = GraphTime → a), the commit pipeline in §5, the worked end-to-end example in §10, and the race-class catalogue with the full enumerator/checker rules in §16.

Read SPEC.md
SPEC.async.md

Async resources & conflicts

The composite statechart that governs every async fetch (launch, version-stamp, abort, settle), together with the conflict-record registry, transaction-phase contract, and the rules that tie outcomes back to the graph.

Read SPEC.async.md
API reference

One page per package in the client repo.

Generated from the source on every build via TypeDoc. The symbol pages link straight back to the relevant SPEC sections wherever a behavior is normative.

Generated from the source on every build via TypeDoc. The client package was renamed to @causl/causl-wasm-ts on 2026-07-27; the generated URLs below still carry the pre-rename _causl_core module id.

@causl/causl-wasm-ts

The client: Behaviors, derivations, transactions, snapshot/hydrate, retention, explain.

View API
@causl/causl-wasm-ts/wasm

The engine subpath: preloadCauslWasm, createCauslWasmSync, and the bridge loader. Required since 0.5.0.

View API
@causl/react

React bindings: useCausl, useDispatch, useCauslFamily, MVU runner, SSR.

View API
@causl/formula

Spreadsheet patterns on top of the client: formulas, ranges, cycles.

View API
@causl/sync

Async resources and the conflict registry, composed as statecharts.

View API
@causl/devtools

Inspection primitives: explain materialisation, liveDerivation, snapshot, statechart.

View API
@causl/devtools-bridge

Redux DevTools Extension protocol bridge (zero-cost when the extension is absent).

View API
@causl/persistence

Persisted-input adapter with structured PersistenceError reporting.

View API
@causl/hypothesis

The hypothesis catalogue the bench harness checks its median-band invariants against.

View API
@causl/migration-check

Migration drift detector: flags unmigrated Jotai/MobX/Redux patterns in adopters.

View API
Enterprise

The causl-core-rs engine and the causl-wasm-ts client.

Causl ships an Enterprise-tier engine: the causl-core-rs core, written in Rust and compiled to WebAssembly, reached through causl-wasm-ts, a thin TypeScript client published as @causl/causl-wasm-ts. In that client the Rust engine is the unconditional engine (rust-ssot): there is no opt-in, no capability probe choosing between two engines, and no TypeScript fallback. The TypeScript engine lives separately in causl-core-ts, where it serves as the §12 conformance reference and the differential oracle (SPEC §18A).

enterprise

Enterprise overview Enterprise

The landing page for the Enterprise tier: the Rust→WASM engine (causl-core-rs, published as @causl/core-rs) behind the thin TypeScript client causl-wasm-ts. It is the only engine that client runs; the TypeScript engine in causl-core-ts is the §12 conformance reference (SPEC §18A).

Read the overview
integrating-causl-client

Integrating causl-wasm-ts Enterprise

How to adopt @causl/causl-wasm-ts: the private registry, the token, the one await preloadCauslWasm() at app init, and the §12 spine (input, derived, commit, read, subscribe) that the boot change leaves untouched.

Read the guide
two-engine-architecture

Two-engine architecture Enterprise

Why Causl keeps two conformant engines, the TypeScript one in causl-core-ts and the Rust→WASM causl-core-rs core, and how the shared public surface lets the Rust engine be the only engine in causl-wasm-ts while the TypeScript one stays the §12 conformance reference and the differential oracle (SPEC §18A).

Read the architecture
wasm-performance

WASM performance Enterprise

Where the Rust→WASM causl-core-rs engine actually stands against the TypeScript engine and against mobx, jotai and redux-rtk across the canonical scenario taxonomy: the measured cell-level result, the bottlenecks behind it, and the older claims the data refutes.

Read the numbers
Repository docs

Top-level files in causljs/causl-ts.

These four files travel with the source and are the right starting points for anyone evaluating, upgrading, or contributing to causl. Each causljs/* repo ships its own analogous trio (README, CHANGELOG, CONTRIBUTING) and the same pre-commit hook contract. See the cross-org topology section.

README.md

The why, what, and how

Why causl needs to exist, what it commits to, how it compares to the rest of the JavaScript state-management landscape, and the package map.

Read on GitHub
CHANGELOG.md

Per-wave shipped features

A wave-by-wave record of what has actually landed on main. Updated on every release; the source of truth for "what changed since I last upgraded".

Read on GitHub
CONTRIBUTING.md

How the eight commitments are enforced

The repo's contribution rules: branch model, PR template, how each of the eight commitments is enforced at the package boundary, in CI, and in code review, and the pre-commit hook setup that mirrors the full CI gate union locally (cargo-husky for Rust-side repos, plain Husky for the TS-side).

Read on GitHub
Topic guides

Narrative explanations for the moving parts.

Where the SPEC is normative and exhaustive, these guides walk through one concept at a time with diagrams and worked examples. Some cards below and further down this page name repositories that are not publicly hosted (causl-check, causl-org-srv, and the private Enterprise engine and client on git.opsite.ca), so I give the repo and path in the card label and leave those cards unlinked.

docs/semantics.md

Behavior denotational semantics walkthrough

A guided tour through Behavior a = GraphTime → a: why this shape makes glitch-freedom a theorem rather than a scheduler trick, and how derivations compose.

Read on GitHub
docs/lifecycle.md

Composite statechart with Mermaid diagrams

The single statechart that governs resource fetch, conflict status, transaction phases, and interaction modes, rendered inline so each transition has a name you can grep for.

Read on GitHub
docs/checker-coverage.md

What causl-check catches

A rule-by-rule mapping from each twelve-pass lint to the SPEC §16 race class it corresponds to, including which shapes are caught statically and which still require the enumerator.

Read on GitHub
docs/migration/RULE_CATALOGUE.md

Migration guide: Jotai / MobX / Redux → causl

The canonical mapping table from common patterns in the three most-migrated-from libraries to their causl equivalents, paired with the codemod rules in @causl/migration-check.

Read on GitHub
causl-check · docs/apalache-diff-report.md

Latest TLA+ differential run

The most recent CI output from the Apalache differential runner against the EPIC-7 TLA+ corpus, regenerated on every run of the bounded model checker. The Tier-3 S-row corpus (spec_s1.tla / spec_s2.tla / spec_s3.tla) covers the SPEC.async §9.1.1 rows.

causl-check · docs/rfcs/0001-adopter-race-classes.md

RFC 0001: adopter-defined race classes

The extension surface by which an adopter declares a custom race class without violating the closed §9.1 catalogue. Phase 2 shipped the loader + SARIF integration in causl-check.

causl-check · docs/rfcs/0002-federated-race-detection.md

RFC 0002: federated race detection

Race detection across multiple causljs/* repos in a single SARIF stream: the per-push fast check, the nightly cross-repo sweep, and the federated finding wire format.

Cross-org topology

One repo per concern.

Causl was split out of a single monorepo. Each repo owns one concern; the contribution flow, the CI gates, and the release cadences are independent. Three repos were renamed on 2026-07-27, and the old names are now redirects: causl-client became causl-wasm-ts, causl-wasm became causl-core-rs, and causl-ts-wasm-engine became causl-core-ts. The scheme is engines by substrate and clients by consumer language. The Rust engine and the client are Enterprise, so see the Enterprise docs for the two-engine architecture and the client API.

causljs/causl-ts

Open-source TypeScript engine + adapters

The public npmjs line, under the separate @causlts scope: @causlts/core, @causlts/react, @causlts/formula, @causlts/sync, @causlts/devtools, @causlts/devtools-bridge, @causlts/persistence, @causlts/hypothesis, @causlts/migration-check. This is a different product from the private client, not a mirror of it.

View on GitHub
causl-core-rs

Rust engine + consolidated bridge Enterprise

Formerly causl-wasm. Publishes @causl/core-rs to the private registry: engine-rs-core (pure-algorithm no_std + alloc) plus the single consolidated bridge cdylib that replaced the legacy serde and GC bridge pair. Exactly one bridge ships, gc-classic; gc-builtins was deleted because its imports could not bind on any host.

Read the architecture
causl-core-ts

TypeScript engine + differential oracle Enterprise

Formerly causl-ts-wasm-engine. It stays dual-engine and still defaults to js-ssot, and it is the differential oracle plus the benchmark host: causl-wasm-ts pins it by commit SHA and runs 5,000 differential trials per PR against it.

Read the architecture
causl-bench

Cross-library bench suite

Compares the client, the TypeScript engine, Jotai, RTK and MobX across the SPEC scenario taxonomy, one subprocess per cell with a fresh world per step. Output feeds the dashboard at /pages/benchmarks/.

View the dashboard
causl-check

Static analysis

causl-check (twelve-pass IR linter), causl-enumerate (SPEC §16.4 bounded enumerator), the Apalache differential runner, the Tier-3 Apalache S-row corpus, RFC 0001 (adopter race classes), and RFC 0002 (federated race detection).

causl-org-srv

Static dev server for this site

Small dev server used while iterating on the demos that ship with causljs/causl-org. Was previously vendored into causl-ts/tools/causl-org-srv/; lives standalone now.

Tools

The Rust crates in causl-check.

All three crates are CI gates, not runtimes. They read the TypeScript source, lower it to the IR, and reject programs that violate SPEC §16 before they reach production.

causl-check · tools/checker

causl-check

The static IR linter: twelve passes, one per race class, shipped as a Rust binary. The @causl/checker npm wrapper is not published, so run the binary from source.

causl-check · tools/enumerator

causl-enumerate

The SPEC §16.4 bounded model checker: full type surface, phased transitions with per-step events, an oracle, and Tier-1/2/3 bound presets.

causl-check · tools/enumerator/diff

Apalache differential runner

Re-runs the EPIC-7 TLA+ corpus through Apalache and diffs its output against the bounded enumerator: the safety net for the safety net.

The full source

The open-source TypeScript engine and the static-analysis tooling live under the causljs organisation on GitHub. The Rust engine (causl-core-rs), the client (causl-wasm-ts) and the conformance engine (causl-core-ts) are private and are hosted, with their package registry, on the Gitea host. Issues, PRs, and the complete eight-commitment audit trail are in whichever repo owns the concern.

View on GitHub