Why a language?

These are the objections people raise most often, with our current answers and where each answer runs out.

Isn't this a job for the operating system, or a library?

An operating-system sandbox constrains a running process. It cannot tell a reviewer which function in a diff gained network access, and it says nothing until the code runs. Jacquard puts that information on each function, in the diff, before anything runs. The checker infers every effect row, so a row cannot be incomplete: a signature that leaves out an effect is a type error. The runtime then refuses any effect you have not granted.

A library in an existing language can offer capabilities, but it cannot make every call path declare what it reaches, and nothing checks the declarations it does get. That guarantee needs the type checker.

The two approaches work together; Jacquard does not replace a sandbox. Grants are also coarse today: a grant covers a whole effect, net, not "the network, but only this host". Finer host authority is a recorded design decision, not an enforced boundary.

How is a handler different from dependency injection?

An injected dependency is the special case of a handler that resumes the program exactly once. A handler can also decline to resume, which aborts the rest of the computation cleanly, or resume many times, which forks the rest of the program to explore every outcome. That last case is why exact probabilistic inference and exhaustive testing are ordinary library code in Jacquard rather than separate tools. The second tour shows one policy run all three ways.

Models have never seen this language. How can they write it?

Jacquard is small enough to learn from one file. SKILL.md covers installing, writing, checking, running, testing and compiling, and every diagnostic carries a stable code, a cause and a next step that an agent can act on.

We have not measured this yet. No published result shows how often agents write correct Jacquard from SKILL.md alone, and the documentation-only onboarding exercise has not been tried by an unfamiliar developer. Until there is a number, treat this as a design goal.

Does it actually make review faster or more accurate?

That is the claim the project exists to test, and it is not yet tested. The readability benchmark has a protocol and synthetic harness evidence, but no results with human participants. The review tour shows the mechanism; it is not evidence that people review better with it.

What is new compared with Unison and Koka?

Most of the mechanisms are borrowed, deliberately:

From Unison: effects on function arrows and content-addressed definitions.
From Koka: effect rows and the handler discipline.
From Racket: hygiene for quoted code.
From Roslyn: full-fidelity syntax, so tools keep comments and layout.

What Jacquard adds is the connection between them. An inferred effect row is also the program's runtime authority: the runtime refuses anything the row requests that you have not granted. On top of that sit tools for reviewing generated code: semantic diffs that report changed authority, dry runs, and approval by canonical hash. The design lineage is recorded in docs/ast.md.