gdp-wired 0.2.0 → 0.4.0

package/README.md

@@ -2,12 +2,9 @@
 
 # gdp-wired
 
-Laws about stateful rules (budgets, caps, rate limits, access policies), proven in TypeScript by a small trusted
-kernel, with an untrusted prover that writes the proofs, an optional Lean twin that checks the kernel itself, and GPU
-searches that find counterexamples or the invariants a proof needs.
-
-You write the rule once with typed builders and state what must always hold. The library proves it by induction (or
-shows a real run that breaks it), and the same rule runs as an interpreter or ships as generated JavaScript.
+An automatic prover for stateful rules: budgets, caps, rate limits, workflows, access policies. You write the rule and
+the laws it must keep. gdp-wired proves them with no proof to write, shows a real run that breaks a law when it's false
+(found by searching on the GPU), has every proof checked again by Lean, and ships the rule as JavaScript.
 
 ```sh
 npm install gdp-wired   # or bun add gdp-wired; plain JavaScript with types, Node 20+, Bun or a browser
@@ -33,62 +30,76 @@ Forget the cap (`s.plus(c)`) and the kernel refuses the proof; a search from the
 and `examples/domains/` holds 92 rules from nine domains (finance, access control, public services, operations,
 protocols, commerce, supply chains, games, education), each checked three ways.
 
-## Scope: where it replaces Bend, and where it doesn't
+## Where it fits
 
-gdp-wired is meant to replace Bend where it matters in practice, not to be a language: laws about **stateful rules whose
-state is counters, totals, maps of counters and logs summed over time**, proven automatically, with the rule shipped as
-code. If the checker side finds new frontiers the scope may grow; until then:
+<img src="https://raw.githubusercontent.com/monotykamary/gdp-wired/main/static/venn.svg" alt="What Lean, Bend and gdp-wired each cover, and where they overlap" width="640" />
 
-| It expresses and proves | It does not (today) |
-| --- | --- |
-| Step machines over naturals: scalars, maps from naturals to naturals (one write per map per step), named step conditions, preconditions on params, assumptions per request | Lists, sets or strings as values: membership, subsets, equality of lists of names |
-| Invariants of the state and params, laws about every key of a map; step laws relating one step's before and after (`s'`, `M'[k]`: "only increases", "stays retired"), and k-step laws about k steps in a row ("two grants on one day add two", up to 16 steps) | Orderings over any number of steps ("a refund never follows a release", at any distance, needs a state flag), beyond progress |
-| Composition: rules side by side (`product`), taking turns (`interleave`), and one rule refining another (`refinement`: a forward simulation, the spec allowing every request it is sent), each built as a plain machine so every law above applies | Refinement where the spec needs more than one step per step of the implementation |
-| Laws about one key of a map at a time, or about scalars | Totals across a map's keys ("the sum of every client's holdings equals in-use") |
-| Histories: sums and queries over a log of requests, relations between them proven one record at a time, pruning | Unbounded recursion over data, quantifiers over sequences other than a machine's own history |
-| Decisions over facts: flags, one-of choices, optional facts, bounded naturals (`match` covers every case) | Datatypes beyond those encodings; division, modulo, reals |
-| Loops that halt by a rank or a tuple of ranks; folds over binary trees; progress laws ("some request makes this happen") | Arbitrary algorithms: there is no general recursion to prove things about |
-| Arithmetic: `+`, truncated `−`, `×` by a constant, `min`, `max`, `if`, products of two terms (proven by the kernel, less well by the prover) | Generated code for decisions alone (`compileJs` emits machines; a predicate emitter is planned) |
-
-Keep Bend where the specification is about **lists or sets of names** (resource scopes, capability subsets, normalization
-that must refine its input), where a proof needs **induction over data structures**, or where the shipped code must be
-the compiled proved source of an arbitrary algorithm. Use gdp-wired where the rule is a budget, a cap, a window, a
-workflow or a policy decision: it proves those without proof files, finds counterexample runs when they're false, and
-checks its own kernel in Lean.
-
-For a sense of the split: in one real codebase with 98 Bend laws and about 1,600 lines of hand proofs, the policy
-decisions, the compare-and-swap storage plans and the state/provider plans fit gdp-wired as it is (with names interned
-to numbers), and gdp-wired can prove more about storage than its Bend proofs state (no revision reuse across keys); the
-lifecycle machine's before/after laws are step laws (as in `release lifecycle` in `examples/`); the resource and authority checks, built on lists of names as
-sets, stay in Bend. `compare/` puts three rules side by side in gdp-wired, Bend and plain Lean, with line counts and
-check times.
-
-## What's trusted
+Lean proves anything you write the proof for. Bend runs programs that carry their proofs. gdp-wired proves one kind of
+claim, laws about stateful rules, with no proof to write, and hands every proof to Lean as a theorem. Where a proof needs
+more than it decides, the proof is Lean's: a function you define and prove there, which the rule then uses.
+[`docs/comparison.md`](docs/comparison.md) goes through each region, compares the three side by side, and measures them
+on the same rules.
+
+## What it proves
+
+All of these are proven automatically, and each proof is also a Lean theorem:
+
+- **Invariants**: a law that holds after every sequence of requests ("spend stays within the budget").
+- **Maps, sets and lists of names**: laws at every key ("no day passes its cap"), sets a request carries, conditions
+  about every key, lists kept in order (`examples/sets.ts`, `examples/lists.ts`).
+- **Step laws**: what one step does ("a balance only goes down", "a grant adds one"), and laws over several steps in a
+  row.
+- **Histories**: sums and queries over a log of requests, like a sliding-window rate limit.
+- **Orderings at any distance**: "a refund never follows a release", through ghost state that watches the rule.
+- **Liveness**: "every ticket issued is served", in every run that keeps sending the requests that help, including under
+  weak fairness (`examples/liveness.ts`).
+- **Refinement**: an implementation behaves like a simpler spec, step for step (`examples/composition.ts`).
+- **Functions**: division, remainder, and your own functions, known by their facts; a function defined in Lean brings
+  facts proven there (`examples/functions.ts`).
+- **Pure functions and two-run laws**: laws about what a function returns, and laws comparing two calls, like "the
+  secret never changes the answer". `examples/jev-fabric/` ports a Bend project's policy core and proves all 59 laws its
+  Bend proofs state.
+
+When a law is false, the GPU search finds a real run that breaks it. When a law needs an invariant nobody wrote, the GPU
+synthesizer finds one and the kernel proves it.
+
+**What it leaves to Lean or Bend.** Two things, and neither is a gap the next feature closes: proofs the prover would
+have to invent (induction over a recursive structure whose proof needs a lemma nobody stated, and arithmetic with
+products of unknowns beyond multiplying two known facts; integer arithmetic with induction or with products is
+undecidable), and shipping an arbitrary algorithm as its proved source (gdp-wired ships the rule as JavaScript; Bend
+compiles the proved source itself). The full list of what is and isn't in scope is in
+[`docs/comparison.md`](docs/comparison.md#gdp-wireds-scope-in-detail).
+
+## Why you can trust a proof
+
+A small kernel checks every proof; the prover that finds them is untrusted, and the kernel's twin in Lean is proven
+sound.
 
 | Part | Trusted? | What it does |
 | --- | --- | --- |
-| `kernel/kernel.ts`, `core/check.ts` | **Yes** | Turns a machine and its laws into goals and checks a proof tree for each: splits on linear atoms, a Fourier–Motzkin derivation at each leaf. Every rule (step machines with maps and flags, step laws and k-step laws, loops with ranks, progress, folds over trees) is a few moves of one small algebra of runs: conditions holding where a run is, a step taken from there, a conclusion read at the end or across the run. Histories become plain machines first. Refuses names a machine doesn't declare |
-| `kernel/prove.ts` | No | Grows the trees. If it's wrong, the kernel rejects the tree |
-| `lean-kernel/` | Optional | The kernel's twin in Lean 4.34.0, each rule proven sound (`Kern.sound`, `machine_sound`, `mmachine_sound`, `fmmachine_sound`, `loop_sound`, `fold_sound`, `progress_sound`, `steplaw_sound`, `kstep_sound`, `hmachine_sound`), axioms `propext`, `Classical.choice`, `Quot.sound` only. The exporter sends the kernel's real trees; tampered ones compute to false |
-| `search/`, `synth/`, `hw/` | No | GPU work: counterexample search over every short history, and invariant/rank synthesis. Every hit is replayed by the interpreter or proven by the kernel before it counts |
-| `core/dsl.ts`, `core/compose.ts`, the runtimes | No | The builders and combinators compile to the kernel's plain values; the interpreter and generated JavaScript are held to the reference evaluator by the conformance test, and the combinators to runs of their parts |
-
-How the untrusted parts are held to the trusted ones, automatically:
-
-- **Types**: the whole repo type-checks strictly (`noImplicitReturns`, `noFallthroughCasesInSwitch`,
-  `noUncheckedIndexedAccess`), and a type-aware lint denies warnings; every switch over term and condition operations is
-  exhaustive and ends in `unreachable()`, so a new operation fails to compile wherever it's missing.
-- **Conformance** (`core/conformance.test.ts`): random terms over every operation through every consumer (interpreter,
-  generated JS, the kernel on fixed values, the GPU search's u32 twin, the old symbolic prover) against the reference
-  evaluator, and the same cases through Lean's own `evalE` (`lean-kernel/conformance.ts`).
-- **Examples** (`examples/`): every law proven by the kernel and re-checked by Lean, every rule run at random through
-  both runtimes, and every broken variant broken by a real run (a refused proof alone could be the prover's weakness).
-- **Tampering and mutation** (`kernel/tamper.test.ts`, `kernel/refusals.test.ts`, `kernel/mutants.ts`): real proofs
-  broken structurally or offered for weakened goals that have a model must be rejected, every refusal the kernel makes is
-  exercised, and every one-operator mutation of `kernel.ts` and `check.ts` is run against the tests to find what they
-  don't notice: 239 of 261 mutants are caught, and the 22 left are equivalent (`kernel/MUTANTS.md`).
-- **Fuzz**: the kernel never accepts a refutation of something with a model (`kernel/kernel.test.ts`), and laws proven
-  over histories hold on every run (`kernel/history.test.ts`).
+| `kernel/kernel.ts`, `core/check.ts` | **Yes** | Turns a rule and its laws into goals, and checks a proof tree for each: case splits on linear facts, then a linear refutation at each leaf |
+| `kernel/prove.ts` | No | Finds the proof trees. If it's wrong, the kernel rejects the tree |
+| `lean-kernel/` | Optional | The kernel's twin in Lean 4.34.0, every rule proven sound there with the standard axioms only. The exporter sends the kernel's real trees; tampered ones compute to false |
+| `research/search/`, `research/synth/`, `research/hw/` | No | The GPU searches for breaking runs, and invariant and rank synthesis. Every hit is replayed or proven before it counts |
+| `core/dsl.ts`, `core/compose.ts`, the runtimes | No | The builders and combinators compile to the kernel's plain values; the runtimes are held to a reference evaluator |
+
+The untrusted parts are held to the trusted ones by the test suite:
+
+- **Builders**: every law, step law, flag, update and decision in the examples is run again on concrete runs, its
+  callback's answer computed by the builders' own arithmetic (each term carries its value beside its expression) against
+  what the interpreter makes of the expression that was proven (`rule.crossCheck`, `crossCheckDecision`). A builder that
+  writes a different expression than it means is caught, even where the kernel would still prove the law it wrote.
+- **Encodings**: `fun.compare(reference)` and `rule.compare({init, step})` run the rule against the code it describes,
+  on drawn and edge inputs (strings, decimals and choices as themselves), field by field.
+- **Types**: strict TypeScript and a lint that denies warnings; every switch over operations is exhaustive, so a new
+  operation fails to compile wherever it's missing.
+- **Conformance**: random terms through every evaluator (interpreter, generated JavaScript, the kernel, the GPU search,
+  Lean's own evaluator) against the reference one.
+- **Examples**: every law proven and re-checked in Lean, every rule run at random, every broken variant broken by a real
+  run.
+- **Tampering and mutation**: broken proofs must be rejected; every one-operator change to the kernel is run against the
+  tests, and the few that survive are equivalent (`kernel/MUTANTS.md`).
+- **Fuzz**: the kernel never accepts a refutation of something that has a model.
 
 ## Writing laws
 
@@ -133,16 +144,50 @@ const failsClosed = trial.decide('a missing fact means no trial', ({spent}) => s
   ({plan, spent, allowance}) => plan.match({free: () => spent.match({none: () => yes, some: s => allowance.match({none: () => yes, some: a => s.atLeast(a)})}), pro: () => yes}))
 ```
 
-- **Kinds**: `nat`, `upTo(k)`, `bool`, `oneOf(...)`, `maybe(kind)`; their assumptions (a bit is 0 or 1, a choice is in
-  range) go to the kernel by themselves, and `encodeInput`/`encodeParams` turn runtime values into the numbers the
-  machine reads.
+
+- **Kinds**: `nat`, `upTo(k)`, `bool`, `oneOf(...)`, `maybe(kind)`, `int`, `decimal(places)`, `str({like, maxLength})`;
+  their assumptions (a bit is 0 or 1, a choice is in range) go to the kernel by themselves, and
+  `encodeInput`/`encodeParams` turn runtime values into the numbers the machine reads.
+- **Integers and decimals**: `int` and `decimal(places)` inputs, `.ints({...})` and `.decimals(places, {...})` state;
+  `plus`, `minus`, `negate`, `times(k)` (k may be negative), `min`, `max`, `abs`, `isNegative`, comparisons with numbers
+  (a decimal's literals are scaled: `price.atMost(19.99)`). Each is two naturals underneath, so the kernel and the Lean
+  twin see nothing new; `rule.decode(state)` reads them back as numbers.
+- **Strings**: `str({like: ['*.internal'], maxLength: 64})`. A string is its interned name, its length and a bit per
+  declared pattern (Cedar's glob), all computed from the string itself when the input is encoded. `s.like(pattern)`,
+  `s.eq('admin')` (which carries the literal's length and pattern bits, so laws reason from either), `s.isEmpty`,
+  `s.length`; sets of strings are carried maps keyed by `s.id`.
 - **Arithmetic** over the naturals: `plus`, `minus` (truncated), `times(k)`, `mul` (a product of two terms), `min`,
   `max`, `when(cond, a, b)`, `count(cond)`; conditions `lt`, `atMost`, `eq`, `and`, `or`, `not`, `implies`.
+- **Sets and quantifiers**: `.carries(...)` for sets a request brings, `everyKey(k => ...)` (and `has`, `subsetOf`,
+  `disjointFrom`, `sameAs`) anywhere in a step or inside a law, `M.each(k => ...)` to write every key, and
+  `someKey(k => ..., witness?)` for "some key where", proven through a witness the prover finds or the one given.
+- **Functions** (`.fns({perMinute: divBy(60)})`, or `fn(arity, js, {facts, lean})` for your own): read like params that
+  take arguments, `perMinute(t)`; the kernel knows each only by its facts (`.facts(...)`, and a library function's
+  own), and the Lean export takes them as the hypothesis they are, proving them where the function has a Lean
+  definition. A function defined and proven in Lean is how a rule reaches past what the kernel decides: `examples/functions.ts`.
+- **Liveness** (`rule.leadsTo(name, {from, to, rank, helpful})`, `proveLeadsTo`): whenever `from` holds, `to` holds later in
+  every run that takes each helpful request infinitely often; proven by a rank no step raises while waiting and each
+  helpful request lowers in its region. `rank` may return several terms (compared in order) and `helpful` may be a list
+  of `{when, request}`; a request names only the inputs it fixes (`examples/liveness.ts`: batches, a history with a
+  query, a machine with sets).
+- **Pure functions** (`fun(name).inputs(...).returns(env => ({...}))`): each field of the result a term or a condition;
+  `f.law(name, given, then)` is a decision about the terms it returns and `f.run(values)` runs those terms compiled. A
+  decision assumes the functions' facts where it reads them.
+- **Two runs** (`r.relate(name, (a, b) => given, (a, b) => then)`, or `f.relate(...)` with both results): a decision
+  about two requests under the same params, for noninterference ("requests that differ only in a secret are decided
+  alike"); the second request's inputs show as `b.<input>` in a counterexample.
 - **Loops** (`loop(...)`): state, `while`, `body`, a `rank` (or a tuple of ranks) that must drop each turn.
-- **Composition** (`gdp-wired/compose`): `product(a, b)`, `interleave(a, b)` and `refinement(impl, spec, {relation, witness})`
+- **Lean** (`gdp-wired/lean`): `toLean([{id, machine, laws, stepLaws}, ...])` writes the proofs as a Lean file, and
+  `leanProject(file)` a Lake project with the twin, so `lake build` checks them. Each law comes as the twin's theorem and
+  as a plain statement over named variables, e.g. `theorem budget.law0 (h : SReach budget_machine ρ μ) : ρ «s» ≤
+  (ρ «b» + ρ «m»)`, for a Lean development to cite.
+- **Composition** (`gdp-wired/compose`): `product(a, b)`, `interleave(a, b)`, `refinement(impl, spec, {relation, witness, stutter})`,
+  `steps(spec, k)` (k spec steps as one, each skippable) and `ghost(m, {name: ever(...) | count(...) | total(m, map, name)})`
   build plain machines from machines (each side's state named `a_x`, `b_x`). A refinement's laws are the relation, proven
   by induction, and its step law says the spec allows the request `witness` sends it at each of the implementation's:
-  `examples/composition.ts` proves a meter that counts down refines one that counts up, and refuses two broken ones.
+  `examples/composition.ts` proves a meter that counts down refines one that counts up, and refuses two broken ones;
+  a two-phase meter refines it with stuttering; an escrow never refunds after a release (at any distance); and the
+  connection pool's in-use count is the total of every client's holdings.
 - **Running it**: `rule.interpreter()` is persistent (searches branch from any state); `rule.compiled()` is what an app
   ships: maps and the log updated in place, so a step costs the same however long the history. Both refuse params and
   inputs that aren't naturals below 2^53 and any value past 2^53 − 1, where the proofs over the naturals stop describing
@@ -154,33 +199,25 @@ On Modal CPUs (2 vCPU), generated JavaScript, the answers checked against the in
 
 | Machine | 1k | 10k | 100k | 1M |
 | --- | --- | --- | --- | --- |
-| Per-key caps (`perf/grant-scale.ts`), requests | 0.3 ms | 2.5 ms | 29 ms | 267 ms |
-| Window limit, pruned (`perf/window-scale.ts`), events | 0.8 ms | 3.1 ms | 16 ms | 136 ms |
+| Per-key caps (`research/perf/grant-scale.ts`), requests | 0.3 ms | 2.5 ms | 29 ms | 267 ms |
+| Window limit, pruned (`research/perf/window-scale.ts`), events | 0.8 ms | 3.1 ms | 16 ms | 136 ms |
 
 Pruned, the window limit holds about 35 records whatever the event count; unpruned, each request scans every record kept
 (76 ms at 10k events). The interpreter copies its maps each step (it's the reference, and searches branch from it):
 1.6 s for 10k requests of the caps rule.
 
-A brute-force enumeration of 2^31 worlds (`enum/`, `perf/bend-enum/`), the same predicate as Bend programs and as a
-Handwired word program: on an M2, Bend takes 985 ms sequential, 221 ms parallel and 153 ms on Metal (whole process,
-about 130 ms of it device setup); ours takes 33 ms warm on WebGPU, with about 115 ms of device setup first. On an NVIDIA
-L4 ours takes 5 ms warm; Bend's CUDA build compiled, but its GPU runs hung in our tests (its CPU builds ran: 109 ms
-parallel).
+Measured against Bend and Lean on the same three rules ([`compare/`](compare/README.md)), gdp-wired's proofs are one
+or two lines and check in 25–44 ms, against 74–117 lines of hand proof and 137–161 ms in Bend and 8–30 lines and
+488–571 ms in Lean. Running each tool's proved code over 100,000 requests (whole command, Modal, 2 CPUs):
 
-## Compared with Bend and Lean
+| | budget | caps | window |
+| --- | --- | --- | --- |
+| gdp-wired | 44 ms | 59 ms | 2.6 s |
+| Bend | 92 s | 75 s | over 300 s |
+| Lean | 8 ms | 205 ms | 8.7 s |
 
-`compare/` writes three rules (a budget, per-key caps, a sliding-window limit) in gdp-wired, in Bend 2 and in plain Lean
-4, each checked by its own tool on Modal, each also handed the same bug to reject. From `compare/README.md`:
-
-| | Rule lines | Law lines | Proof lines | Check (median, whole command) |
-| --- | --- | --- | --- | --- |
-| gdp-wired | 5–7 | 1–4 | 1–2 (`proveRule`) | 25–44 ms |
-| Bend 2 | 39–98 (25–50 of them proof evidence in the rule) | 5–26 | 74–117 | 137–161 ms (`--verdict` 167–178 ms) |
-| Lean 4 (by hand) | 4–15 | 1–4 | 8–30 | 488–571 ms |
-
-Most of each time is the tool's startup (17, 134 and 453 ms). gdp-wired's kernel trees for the same rules re-check in
-its Lean twin in 1.35 s. What each proves, what each ships at runtime, and where each is the better tool are in
-`compare/README.md`.
+The proved Bend and Lean rules keep lists and scan them; gdp-wired runs maps and a log (unpruned in this window rule).
+Lean, compiled natively, wins where the state stays small. Details in [`docs/comparison.md`](docs/comparison.md).
 
 ## Layout
 
@@ -188,23 +225,22 @@ its Lean twin in 1.35 s. What each proves, what each ships at runtime, and where
 | --- | --- |
 | `core/` | Machines, the interpreter and JS compiler, the builders, composition (`compose.ts`), the linear solver and its checker, Houdini invariants, models, the first Lean export |
 | `kernel/` | The trusted kernel and the untrusted prover, with soundness fuzz (`kernel.test.ts`, `history.test.ts`) |
-| `lean/`, `lean-kernel/` | Lean: the derivation checker `Cert.lean`, and the kernel's twin with its exported trees |
-| `search/`, `hw/`, `modal-gpu/` | Counterexample search on the GPU: a hand-written WGSL kernel, and the same through the Handwired fork's word stages |
-| `synth/` | Invariants and ranks found on the GPU, proven by the kernel |
-| `next/` | Guards synthesized from laws, relational laws (migrations, tenant isolation, through `core/compose.ts`), a ReBAC audit |
-| `sat/` | Bit-vector laws: bit-blasted, solved, LRAT-checked in TypeScript, optionally by Lean |
-| `enum/`, `perf/` | The enumeration, and the benchmarks |
-| `examples/` | The builders at work: `domains/` (92 rules across nine domains, each with laws and broken variants), `harness.ts` (the triple check), `readme.ts`, `budget.ts`, `composition.ts` |
+| `lean-kernel/` | The kernel's Lean twin, its soundness proofs, and the exported trees |
+| `examples/` | The builders at work: `domains/` (92 rules across nine domains, each with laws and broken variants), `harness.ts` (the triple check), `readme.ts`, `budget.ts`, `composition.ts`, `sets.ts`, `quantifiers.ts`, `functions.ts`, `lists.ts`, `sizes.ts`, `liveness.ts`, and `jev-fabric/` (a Bend project's 59 proven laws, ported) |
+| `docs/` | The comparison with Bend and Lean, and the full scope |
 | `compare/` | The same three rules in gdp-wired, Bend and plain Lean, checked and measured |
-| `spec.ts`, `gdp.ts`, `circuit.ts`, `laws.ts` | The audit path: gdp-ts predicates written once, as trusted provers per request and as a Handwired circuit that decides every (user, project) pair at once |
+| `research/` | Everything around the library ([`research/README.md`](research/README.md)): the GPU searches (`search/`, `hw/`, `modal-gpu/`), invariant and rank synthesis (`synth/`), relational laws and guard synthesis (`next/`), bit-vector laws (`sat/`), the enumeration and benchmarks (`enum/`, `gpu/`, `perf/`), the first Lean checker (`lean/`) and the first prototype, the audit path (`audit/`) |
 | `modal/` | Everything above as Modal jobs: `suite.json` is the regression suite |
+| `scripts/` | The package build, the smoke test of the packed tarball, the Lean library generator, the diagram |
 | `vendor/handwired` | [monotykamary/handwired](https://github.com/monotykamary/handwired), branch `u32-words`: Cheng Lou's Handwired with exact u32 word circuits and word stages in loop programs |
 | `vendor/gdp-ts` | [rauchg/gdp-ts](https://github.com/rauchg/gdp-ts) |
 
+The npm package is built from `core/`, `kernel/` and `lean-kernel/` alone; nothing in it imports `research/`.
+
 ## Running
 
 The npm package is the library: the builders (`gdp-wired`), the runtimes (`gdp-wired/machine`), composition
-(`gdp-wired/compose`), the kernel
+(`gdp-wired/compose`), the Lean export (`gdp-wired/lean`), the kernel
 (`gdp-wired/kernel`), the prover (`gdp-wired/prove`), the derivation checker and solver (`gdp-wired/check`,
 `gdp-wired/solver`). Everything else here (examples, comparisons, the Lean twin, the GPU searches) runs from a clone and
 needs [Bun](https://bun.sh); Lean 4.34.0 for `lean/` and `lean-kernel/`; a WebGPU runtime (Chrome, or Dawn's node
@@ -218,7 +254,7 @@ bun test core/compile.test.ts core/runtime.test.ts kernel/history.test.ts
 cd kernel && bun run-kernel.ts && bun test kernel.test.ts
 ```
 
-The whole suite (110 jobs, about 15 minutes of wall time) runs on [Modal](https://modal.com):
+The whole suite (122 jobs, about 20 minutes of wall time) runs on [Modal](https://modal.com):
 
 ```sh
 modal run modal/run.py --jobs modal/suite.json --out runs/modal/suite && sh modal/reap.sh

package/dist/core/compose.d.ts

@@ -1,5 +1,5 @@
 import { type C, type E, type Law, type Machine } from './machine.js';
-import type { StepLaw } from '../kernel/kernel.js';
+import { type StepLaw } from '../kernel/kernel.js';
 export declare const side: (m: Machine, prefix: "a_" | "b_", c: C) => C;
 export declare function product(a: Machine, b: Machine, opts?: {
     name?: string;
@@ -15,10 +15,24 @@ export declare function interleave(a: Machine, b: Machine, opts?: {
 export declare function refinement(impl: Machine, spec: Machine, opts: {
     relation: Law[];
     witness: Record<string, E>;
+    stutter?: C;
     name?: string;
 }): {
     machine: Machine;
     laws: Law[];
     stepLaws: StepLaw[];
 };
+export declare function refinementSides(impl: Machine, spec: Machine): {
+    impl: Machine;
+    spec: Machine;
+};
 export declare function agree(a: Machine): Law[];
+export declare function steps(m: Machine, k: number): Machine;
+export type Ghost = {
+    start: E;
+    step: E;
+};
+export declare function ghost(m: Machine, vars: Record<string, Ghost>): Machine;
+export declare const ever: (name: string, cond: C) => Ghost;
+export declare const count: (name: string, cond: C) => Ghost;
+export declare function total(m: Machine, map: string, name: string): Ghost;

package/dist/core/compose.js

@@ -3,18 +3,24 @@
 // is trusted: a proof is about the machine built, and the combinators are tested against runs of their parts.
 //   product(a, b)      both step on every request (their params and inputs shared by name)
 //   interleave(a, b)   one of them steps on each request, `turn` picking which
-//   refinement(impl, spec, {relation, witness})
+//   refinement(impl, spec, {relation, witness, stutter})
 //                      impl refines spec: the spec, sent the request `witness` names for each of impl's, always allows it,
-//                      and `relation` holds of the two states at every step (a forward simulation)
+//                      and `relation` holds of the two states at every step (a forward simulation); where `stutter`
+//                      holds, impl's step is one the spec doesn't see, and the spec stays
+//   ghost(m, vars)     state that watches the machine without changing it: what happened before ("ever", "count") and
+//                      totals across a map's keys ("total"), for laws about whole histories
+//   steps(m, k)        k steps of m as one: the spec of a refinement that takes several steps for one of impl's
 // Each side's state, maps and flags are renamed a_x and b_x; params and inputs keep their names.
 import { all, any, bit, not, same, unreachable, x } from "./machine.js";
+import { substC, substE } from "../kernel/kernel.js";
+import { nameQuantifiers } from "./dsl.js";
 function rename(e, prefix, m, inputs) {
     switch (e.op) {
         case 'var': return m.params.includes(e.name) ? e : m.inputs.includes(e.name) ? (inputs[e.name] ?? e) : x(`${prefix}${e.name}`);
         case 'const': return e;
         case 'mul': return { ...e, a: rename(e.a, prefix, m, inputs) };
         case 'if': return { op: 'if', c: renameC(e.c, prefix, m, inputs), then: rename(e.then, prefix, m, inputs), else: rename(e.else, prefix, m, inputs) };
-        case 'get': return { op: 'get', map: `${prefix}${e.map}`, key: rename(e.key, prefix, m, inputs) };
+        case 'get': return { op: 'get', map: m.inputMaps?.includes(e.map) ? e.map : `${prefix}${e.map}`, key: rename(e.key, prefix, m, inputs) };
         case 'add':
         case 'sub':
         case 'min':
@@ -30,6 +36,8 @@ function renameC(c, prefix, m, inputs) {
         return { op: 'not', x: renameC(c.x, prefix, m, inputs) };
     if (c.op === 'and' || c.op === 'or')
         return { op: c.op, xs: c.xs.map(y => renameC(y, prefix, m, inputs)) };
+    if (c.op === 'all')
+        return { op: 'all', key: `${prefix}${c.key}`, c: renameC(c.c, prefix, m, inputs) }; // the key renamed with its side
     return { ...c, a: rename(c.a, prefix, m, inputs), b: rename(c.b, prefix, m, inputs) };
 }
 // A condition (or law) of one side, read in the composed machine.
@@ -46,6 +54,8 @@ function renamed(m, p, inputs, stays) {
             flags: Object.fromEntries(Object.entries(m.step.flags ?? {}).map(([n, c]) => [`${p}${n}`, renameC(c, p, m, inputs)])),
             state: Object.fromEntries(Object.entries(m.step.state ?? {}).map(([n, e]) => [`${p}${n}`, keep(rename(e, p, m, inputs), x(`${p}${n}`))])),
             maps: Object.fromEntries(Object.entries(m.step.maps ?? {}).map(([n, w]) => {
+                if ('each' in w)
+                    return [`${p}${n}`, { each: `${p}${w.each}`, value: keep(rename(w.value, p, m, inputs), { op: 'get', map: `${p}${n}`, key: x(`${p}${w.each}`) }) }];
                 const key = rename(w.key, p, m, inputs);
                 return [`${p}${n}`, { key, value: keep(rename(w.value, p, m, inputs), { op: 'get', map: `${p}${n}`, key }) }];
             })),
@@ -57,6 +67,8 @@ const join = (a, b) => ({
     state: { ...a.state, ...b.state }, maps: { ...a.maps, ...b.maps },
     step: { flags: { ...a.step.flags, ...b.step.flags }, state: { ...a.step.state, ...b.step.state }, maps: { ...a.step.maps, ...b.step.maps } },
 });
+// The maps requests carry: shared by name, as inputs are.
+const carriedBy = (...ms) => { const names = [...new Set(ms.flatMap(m => m.inputMaps ?? []))]; return names.length ? { inputMaps: names } : {}; };
 const conj = (cs) => { const xs = cs.filter((c) => c !== undefined); return xs.length ? all(...xs) : undefined; };
 // a and b stepped by the same requests. `bInputs` rewrites what b sees (other tenants' requests as no-ops, say).
 export function product(a, b, opts = {}) {
@@ -66,7 +78,7 @@ export function product(a, b, opts = {}) {
         name: opts.name ?? `${a.name} | ${b.name}`,
         params: [...new Set([...a.params, ...b.params, ...(opts.params ?? [])])],
         inputs: [...new Set([...a.inputs, ...b.inputs, ...(opts.inputs ?? [])])],
-        ...join(A, B),
+        ...join(A, B), ...carriedBy(a, b),
         ...(assume ? { assume } : {}),
         ...(pre ? { pre } : {}),
     };
@@ -84,7 +96,7 @@ export function interleave(a, b, opts = {}) {
         name: opts.name ?? `${a.name} || ${b.name}`,
         params: [...new Set([...a.params, ...b.params])],
         inputs: [...new Set([...a.inputs, ...b.inputs, turn])],
-        ...join(A, B),
+        ...join(A, B), ...carriedBy(a, b),
         assume: all(bit(turn), ...(A.assume ? [any(not(isA), A.assume)] : []), ...(B.assume ? [any(not(isB), B.assume)] : [])),
         ...(pre ? { pre } : {}),
     };
@@ -98,13 +110,16 @@ export function interleave(a, b, opts = {}) {
 export function refinement(impl, spec, opts) {
     if (!spec.inputs.every(i => i in opts.witness))
         throw new Error(`refinement: name every input of ${spec.name} (${spec.inputs.join(', ')})`);
-    const A = renamed(impl, 'a_', {}), B = renamed(spec, 'b_', opts.witness);
-    const allowedBy = B.assume;
+    if ((spec.inputMaps ?? []).some(mp => !(impl.inputMaps ?? []).includes(mp)))
+        throw new Error(`refinement: a map ${spec.name}'s requests carry is one ${impl.name}'s carry too (shared by name)`);
+    const A = renamed(impl, 'a_', {}), B = renamed(spec, 'b_', opts.witness, opts.stutter);
+    // A step the spec doesn't see needs no request it allows.
+    const allowedBy = B.assume && opts.stutter ? any(opts.stutter, B.assume) : B.assume;
     const machine = {
         name: opts.name ?? `${impl.name} refines ${spec.name}`,
         params: [...new Set([...impl.params, ...spec.params])],
         inputs: impl.inputs,
-        ...join(A, B),
+        ...join(A, B), ...carriedBy(impl, spec),
         ...(A.assume ? { assume: A.assume } : {}),
         ...(impl.pre ? { pre: impl.pre } : {}),
     };
@@ -112,6 +127,16 @@ export function refinement(impl, spec, opts) {
     const stepLaws = allowedBy ? [{ name: `${spec.name} allows the request it is sent`, then: allowedBy }] : [];
     return { machine, laws, stepLaws };
 }
+// A refinement's two sides as machines in its composite's names (for lean-kernel/Refine.lean, which builds the composite
+// from them): the implementation's parts named a_x, the spec's b_x, the spec's inputs b_<input> (which the composite
+// never reads: the witness stands for them there).
+export function refinementSides(impl, spec) {
+    const named = (m, p, inputs, inputNames) => {
+        const R = renamed(m, p, inputs);
+        return { name: m.name, params: m.params, inputs: inputNames, state: R.state, maps: R.maps, step: R.step, ...(m.inputMaps?.length ? { inputMaps: m.inputMaps } : {}), ...(R.assume ? { assume: R.assume } : {}), ...(m.pre ? { pre: m.pre } : {}) };
+    };
+    return { impl: named(impl, 'a_', {}, impl.inputs), spec: named(spec, 'b_', Object.fromEntries(spec.inputs.map(i => [i, x(`b_${i}`)])), spec.inputs.map(i => `b_${i}`)) };
+}
 // "a and b agree" in a product of a machine with another of its shape: every scalar equal, every map equal at every key.
 export function agree(a) {
     return [
@@ -119,3 +144,102 @@ export function agree(a) {
         ...Object.keys(a.maps ?? {}).map(n => ({ name: `a.${n}[k] = b.${n}[k]`, holds: same({ op: 'get', map: `a_${n}`, key: x('k') }, { op: 'get', map: `b_${n}`, key: x('k') }), forall: 'k' })),
     ];
 }
+// --- several steps as one --------------------------------------------------------------------------------------------
+// k steps of m in a row as one step: the j-th request read as <input>@s<j> (j from 1), each step skipped where its input
+// skip@s<j> is 1. Each step reads the state the one before it left (its flags decided there, every map read over the
+// writes before), so several writes to one map become one write at every key, its key compared with theirs (which the
+// runtimes decide on breakpoints). Its assumption: each step not skipped is one m allows. As the spec of a refinement,
+// the witness names each step's request and when it is skipped.
+export function steps(m, k) {
+    if (!Number.isInteger(k) || k < 1)
+        throw new Error('steps: k is a whole number at least 1');
+    if (m.history || m.inputMaps?.length)
+        throw new Error(`steps: ${m.name} has a history or maps a request carries (not taken here)`);
+    const at = (name, j) => `${name}@s${j}`;
+    let vars = Object.fromEntries(Object.keys(m.state).map(n => [n, x(n)]));
+    let maps = Object.fromEntries(Object.keys(m.maps ?? {}).map(map => [map, (key) => ({ op: 'get', map, key })]));
+    const allowed = [], written = new Set();
+    for (let j = 1; j <= k; j++) {
+        const skip = same(x(at('skip', j)), { op: 'const', value: 1 });
+        const sub = { vars: { ...vars, ...Object.fromEntries(m.inputs.map(i => [i, x(at(i, j))])) }, maps, flags: {} };
+        for (const [f, c] of Object.entries(m.step.flags ?? {}))
+            sub.flags[f] = substC(c, sub);
+        if (m.assume)
+            allowed.push(any(skip, substC(m.assume, sub)));
+        const kept = (now, old) => ({ op: 'if', c: skip, then: old, else: now });
+        const nextVars = { ...vars };
+        for (const [n, e] of Object.entries(m.step.state ?? {}))
+            nextVars[n] = kept(substE(e, sub), vars[n]);
+        const nextMaps = { ...maps };
+        for (const [map, w] of Object.entries(m.step.maps ?? {})) {
+            written.add(map);
+            const old = maps[map];
+            if ('each' in w)
+                nextMaps[map] = (key) => kept(substE(w.value, { ...sub, vars: { ...sub.vars, [w.each]: key } }), old(key));
+            else {
+                const wk = substE(w.key, sub), wv = substE(w.value, sub);
+                nextMaps[map] = (key) => kept({ op: 'if', c: same(key, wk), then: wv, else: old(key) }, old(key));
+            }
+        }
+        vars = nextVars;
+        maps = nextMaps;
+    }
+    const each = 'k$steps';
+    return nameQuantifiers({
+        name: `${m.name}, ${k} steps at once`, params: m.params,
+        inputs: Array.from({ length: k }, (_, i) => [...m.inputs.map(n => at(n, i + 1)), at('skip', i + 1)]).flat(),
+        state: m.state, ...(m.maps ? { maps: m.maps } : {}),
+        step: {
+            state: Object.fromEntries(Object.keys(m.step.state ?? {}).map(n => [n, vars[n]])),
+            ...(written.size ? { maps: Object.fromEntries([...written].map(map => [map, { each, value: maps[map](x(each)) }])) } : {}),
+        },
+        assume: all(...Array.from({ length: k }, (_, i) => bit(at('skip', i + 1))), ...allowed),
+        ...(m.pre ? { pre: m.pre } : {}),
+    });
+}
+export function ghost(m, vars) {
+    const taken = [...m.params, ...m.inputs, ...Object.keys(m.state), ...Object.keys(m.maps ?? {}), ...Object.keys(m.step.flags ?? {})];
+    for (const name of Object.keys(vars))
+        if (taken.includes(name))
+            throw new Error(`ghost: ${name} is already a name of ${m.name}`);
+    if (m.history)
+        throw new Error(`${m.name}: ghosts go on a machine without a history (its sums are ghosts of that kind already)`);
+    return {
+        ...m,
+        state: { ...m.state, ...Object.fromEntries(Object.entries(vars).map(([n, g]) => [n, g.start])) },
+        step: { ...m.step, state: { ...m.step.state, ...Object.fromEntries(Object.entries(vars).map(([n, g]) => [n, g.step])) } },
+    };
+}
+// Whether `cond` has held at some step so far (read where the step reads: the state before, the request, the flags).
+export const ever = (name, cond) => ({ start: { op: 'const', value: 0 }, step: { op: 'if', c: cond, then: { op: 'const', value: 1 }, else: x(name) } });
+// How many steps so far `cond` held at.
+export const count = (name, cond) => ({ start: { op: 'const', value: 0 }, step: { op: 'add', a: x(name), b: { op: 'if', c: cond, then: { op: 'const', value: 1 }, else: { op: 'const', value: 0 } } } });
+// The total of a map over every key: the map must start at 0 everywhere (so finitely many keys are nonzero), and each
+// step writes one key, so the total moves by the value written less the value it replaces. That difference is pushed
+// through the written term where its shape gives it (old + d adds d; old ∸ d takes min(d, old); an if moves each way
+// by its branch's), so a proof needs no fact about the total beyond the law it is about; any other term falls back to
+// total ∸ old + new (exact, since the total is at least any one cell).
+export function total(m, map, name) {
+    if ((m.maps ?? {})[map] !== 0)
+        throw new Error(`total: ${map} must start at 0 at every key`);
+    const w = m.step.maps?.[map];
+    if (!w)
+        return { start: { op: 'const', value: 0 }, step: x(name) };
+    if ('each' in w)
+        throw new Error(`total: ${map} is written at every key at once, which no one step's difference describes`);
+    const old = { op: 'get', map, key: w.key }, t = x(name), same = (a) => JSON.stringify(a) === JSON.stringify(old);
+    const moved = (e) => {
+        if (same(e))
+            return t;
+        if (e.op === 'add' && same(e.a))
+            return { op: 'add', a: t, b: e.b };
+        if (e.op === 'add' && same(e.b))
+            return { op: 'add', a: t, b: e.a };
+        if (e.op === 'sub' && same(e.a))
+            return { op: 'sub', a: t, b: { op: 'min', a: e.b, b: old } };
+        if (e.op === 'if')
+            return { op: 'if', c: e.c, then: moved(e.then), else: moved(e.else) };
+        return { op: 'add', a: { op: 'sub', a: t, b: old }, b: e };
+    };
+    return { start: { op: 'const', value: 0 }, step: moved(w.value) };
+}