Jacquard.

The thesis.

Jacquard’s README states the bet directly: when most code is written by machines, the people reviewing it need the language to answer what a change can touch and how sure anyone can be about what it does. The project’s answer puts three things in the language rather than in comments or logs: the effects a function may perform, finite discrete uncertainty, and a program identity that survives renaming and reformatting.

A reviewer reads the signature to learn what a change can touch; the checker guarantees the signature is complete.

The effect row does double duty. A signature such as (Text) ->{Net, Console} Int tells a reviewer what the function may reach, and the inferred row of a runnable expression becomes the authority the runtime will ask for. Nothing outside the world is installed unless its grant appears on the command line, and code built at runtime with eval needs its own eval grant.

What it looks like.

multi effect Telemetry where {
  inventory-health : () -> Health
  payments-health : () -> Health
  error-spike? : () -> Bool
}

release-assessment : () ->{Telemetry} Assessment

-- Deterministic interpretation: production snapshot, fixture, or replay.
with-snapshot(inventory, payments, spike, body) =
  handle body() {
    | return value -> value
    | inventory-health() resume continue -> continue(inventory)
    | payments-health() resume continue -> continue(payments)
    | error-spike?() resume continue -> continue(spike)
  }

-- Probabilistic interpretation: uncertain telemetry becomes Dist choices.
with-risk-model(body) =
  handle body() {
    | return value -> value
    | inventory-health() resume continue ->
        continue(`op:sample`(health-dist(0.85, 0.10, 0.05)))
    ...
  }

Distinctive moves.

• Signatures as authority manifests. Effect rows are inferred and checked; the runtime installs a world handler only for an explicit --allow grant and refuses the rest, dynamically evaluated code included. The project describes this as language-level enforcement in a research runtime, not a replacement for an operating-system sandbox.
• Handlers as worlds. A handler may resume once, decline to resume, or resume many times. Resuming many times forks the rest of the program, which is how exact enumeration and likelihood weighting of Dist models, and Warp’s exhaustive mode, run as ordinary library code over the same program.
• Canonical identity. Definitions hash by canonical resolved structure, so comments, formatting, provenance and ordinary local or term names do not change identity. The hash covers every definition a function calls, so an edit to a callee changes the caller’s hash too. The project states that this identity says nothing about behavioural equivalence of different programs.
• Review tooling. jac diff compares two versions by canonical structure rather than text: it reports added and changed definitions, any change to their authority (for example authority {} becoming {Net}) and the dependents affected, and reports no semantic changes for a pure reformat. A signature that omits an effect its body performs is rejected (E0804), jac run --dry-run simulates the world effects and reports what the run would have done, and an approval can name the exact hash a reviewer read. jac relate reruns a program under schedule, secret or grant variation and reports any difference under a declared observation policy, and jac review run (on main, not yet in a release) compares two versions of an entry over declared cases with grouped differences and replayable witnesses.
• Warp. The built-in test framework runs the same property by seeded sampling or, over finite generators, exhaustively. fault.all resumes at every fault site with both outcomes, so a test covers every combination of failures within a budget, and results are cached by hash, so a test reruns only when its canonical code or a dependency changes.
• Governance as effects. Audit records and approvals are ordinary effects with canonical hash-chain carriers and approval handlers, so a governed workflow is checked and tested with the same machinery as any other program.

Maturity.

Tagged releases publish Linux x86-64 and macOS binaries, an installer and a release evidence pack. Its README calls Jacquard a research prototype rather than a production language and points to docs/release/0.3/LIMITS.md for the boundary. Core ships no real network adapter; its networking examples run against deterministic stubs, scripted responses, recorded traces or probability models, and a host integration can implement the same effects instead. Exhaustive checking and exact enumeration are bounded by explicit budgets: a uniform distribution enumerates at most 10,000 values, and larger models fall back to seeded sampling or likelihood weighting, with results labelled accordingly. The 0.3 release decision records 1,194 Alcotest/QCheck cases and 78 transcript tests at the jacquard-core-0.3.0 tag. Commits carry a single human author, who describes development as largely model-assisted; recent pull requests record Codex and Claude reviews of each change.

Agent tooling.

The project site, jacquardlang.org, serves an llms.txt index, a copy of SKILL.md and the error catalogue, along with a review tour that records each command’s output from the released binary. docs/SKILL.md states that it covers installing Jacquard and writing, checking, running, testing and compiling .jac programs without a repository checkout. AGENTS.md orients agents working on the implementation. Every diagnostic carries a stable code, a cause and a next step, catalogued in docs/errors.md, and the CLI emits them as JSON with --diagnostic-format json-v1. There is no MCP server and no model-call effect. External systems sit behind an experimental, versioned host protocol: the companion jbwinters/jacquard-host repository publishes Python, TypeScript and Go SDKs, plus a protocol-level Rust adapter, that call checked Jacquard functions and implement their declared effects as ordinary services.