@@ -106,16 +106,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
       - name: Build + run libFuzzer
-        run: |
-          make vendor/sqlite3ext.h sqlite-predict.h
-          clang -std=c99 -g -O1 -fsanitize=fuzzer,address \
-            -DSQLITE_CORE -DSQLITE_PREDICT_STATIC -DSQLITE_STRICT_SUBTYPE=1 \
-            -Ivendor/ -I./ \
-            fuzz/fuzz_predict.c sqlite-predict.c predict-forecast.c \
-            predict-tabular.c predict-receipts.c predict-distill.c \
-            predict-student.c \
-            vendor/sha256.c vendor/sqlite3.c -o fuzz_predict -lm -lpthread -ldl
-          ./fuzz_predict -max_total_time=60 -max_len=512 fuzz/seeds
+        run: make fuzz
 
   windows:
     name: windows (mingw)
 
@@ -17,25 +17,37 @@ Source layout:
 | `sqlite-predict.c` | entry point, function registration, shared helpers (timestamp parse/format, ULID, options parsing, normal-quantile) |
 | `predict-forecast.c` | the `forecast()` and `detect_anomalies()` aggregates, `backtest()`, the expansion TVFs, the statistical models, the native forecast-student serving path, and the shared `collect_series()` helper |
 | `predict-tabular.c` | `predict()` vtab, the in-context k-NN model, and dispatch to a runtime backend for registered models |
-| `predict-receipts.c` | the model registry (`_predict_models`) and content hashing |
+| `predict-registry.c` | the model registry (`_predict_models`) and content hashing |
 | `predict-onnx.c` | ONNX runtime backend (opt-in build only); the only file that links onnxruntime |
 | `predict-student.c` | the native student **serving** runtime: blob (de)serialization and tree / forest / MLP inference (`predict0_tree_run`). The serve side of the train/serve boundary |
-| `predict-student.h` | the shared student-model **format**: the tree/forest/MLP structs and the runtime entry points both sides agree on (RFC §4.1.6) |
+| `predict-student.h` | the shared student-model **format**: the tree/forest/MLP structs and the runtime entry points both sides agree on (RFC §4.1.3) |
 | `predict-distill.c` | the **training** side: the CART / gradient-boosting / MLP trainers, the `distill_predict()` vtab, and the `distill_forecast()` vtab that fits the forecast student. Builds student blobs that `predict-student.c` serves |
 | `predict-internal.h` | shared types, contract constants, error codes, internal prototypes |
 | `vendor/sha256.c` | a self-contained FIPS 180-4 SHA-256 |
 
-## Operations are table-valued functions
-
-Each operation is an [eponymous virtual table module][tvf]. Arguments
-arrive as hidden columns (`query`, `horizon`, `options`), resolved in
-`xBestIndex` and consumed in `xFilter`, which does all the work and
-materializes result rows the cursor then walks. This is the same mechanism
-SQLite's own `generate_series` uses.
-
-`forecast()` and `detect_anomalies()` share `collect_series()`: prepare and
-validate the inner query (read-only, single statement), resolve or infer
-the time/value/group columns, and collect rows into per-series buffers.
+## Two calling conventions: aggregates and TVFs
+
+The series operations are plain SQL aggregate functions.
+`forecast(ts, value, horizon[, options])` and
+`detect_anomalies(ts, value[, options])` aggregate over the caller's own
+rows: each input row contributes one (ts, value) observation, each
+aggregate evaluation (one `GROUP BY` group, or the whole statement) is
+one series, and the result is a single JSON document. The
+`forecast_rows(doc)` and `anomaly_rows(doc)` table-valued functions
+expand that document back into typed rows.
+
+The query-shaped operations (`backtest()`, `predict()`,
+`distill_predict()`, `distill_forecast()`) are [eponymous virtual table
+modules][tvf] instead. Arguments arrive as hidden columns (a `query`
+string plus operation-specific columns such as `horizon` and `options`),
+resolved in `xBestIndex` and consumed in `xFilter`, which does all the
+work and materializes result rows the cursor then walks. This is the
+same mechanism SQLite's own `generate_series` uses.
+
+`collect_series()` (prepare and validate an inner query as read-only and
+single-statement, resolve or infer the time/value/group columns, collect
+rows into per-series buffers) now serves only `backtest()`, the one
+series operation that still takes a query string.
 
 ## Models
 
@@ -66,7 +78,7 @@ a complete registration for the vector case (in-context adds only `target`,
 which is a SQL column introspection can't see). An explicit `io_spec`
 overrides the derivation. Feature columns map positionally by default (apply
 column order); a `features` list switches to name-based mapping. All the JSON
-handling — reading the `io_spec`, building the derived one — goes through
+handling (reading the `io_spec`, building the derived one) goes through
 SQLite's JSON1 (`json_extract`/`json_each`/`json_object`), never a hand-rolled
 parser. Both cache one onnxruntime session per (weights, device,
 precision), run query rows in batches, and select the execution provider
@@ -87,20 +99,20 @@ teacher's accuracy is usually distillation to a small student.
 zero-dependency core. It fits a native student on a training signal,
 evaluates it on a held-out fraction, and writes the student into
 `_predict_models` as an inline BLOB (`runtime='tree'`, `kind='student'`). By
-default the signal is the `target` column of the training query — your
+default the signal is the `target` column of the training query: your
 labels, or a strong teacher's predictions computed offline and stored in that
 column, which is how a 30-second TabFM run becomes a microsecond student. A
 `teacher` argument names a registered `predict()` model, which `distill`
-re-runs over the rows (aligned by row number) to relabel them first — the way
+re-runs over the rows (aligned by row number) to relabel them first, the way
 to compress the in-context knn5 into a standalone tree.
 
 Three `student_kind`s exist. `'tree'` and `'gbt'` share the CART trainer;
 `'tree'` is a single depth-8 tree. `'gbt'` is a gradient-boosted forest of
 shallow trees, and it is the go-to when accuracy matters: it fits each tree to
 the loss
 gradient but sets each leaf to the **second-order (Newton) step**
-`Σg / (Σh + λ)` using the softmax Hessian — the same thing that lifts
-XGBoost above a vanilla gradient booster — with shrinkage (a small learning
+`Σg / (Σh + λ)` using the softmax Hessian (the same thing that lifts
+XGBoost above a vanilla gradient booster), with shrinkage (a small learning
 rate over many rounds) doing the regularizing. It is deterministic by
 construction: no bootstrap, no feature-sampling, no early-stopping split, so
 the student stays reproducible and exactly replayable. Given `proba` and
@@ -118,19 +130,19 @@ a `tree`-runtime model to the native runtime in the same file, which tells a
 single tree (`PSTREE` blob) from a forest (`PSGBT` blob) from a net (`PSMLP`
 blob) by magic and needs
 no onnxruntime. The blob formats are little-endian and normatively specified
-and versioned (RFC §4.1.6, `PSTREE01` / `PSGBT01` / `PSMLP01`), so a stored student stays
+and versioned (RFC §4.1.3, `PSTREE01` / `PSGBT01` / `PSMLP01`), so a stored student stays
 servable across upgrades, snapshots, and forks, and a serving-only module can
 execute a blob it never trained. They are rigorously bounds-checked on read,
 because the registry is
-writable by any SQL caller (RFC §6.2) — a hand-crafted blob is rejected,
+writable by any SQL caller (RFC §6.2): a hand-crafted blob is rejected,
 never crashed on. The student is native and deterministic, like the stat
 models.
 
 Forecasting has its own student. `distill_forecast()` (`predict-distill.c`)
 fits a regression MLP that maps an instance-normalized context window of `nfeat`
 recent values to `nquant` quantiles per horizon step, distilled from a teacher's
 forecasts over sliding windows. It is stored as a fourth student blob (`PSFCST`,
-RFC §4.1.6) and served not by `predict()` but by `forecast()`
+RFC §4.1.3) and served not by `predict()` but by `forecast()`
 (`predict-forecast.c`), which extracts the most recent window, normalizes it by
 its own mean and standard deviation (so one student serves series of any
 magnitude), applies the net, and de-normalizes. When the student carries a
@@ -152,12 +164,13 @@ fp16 inference is not bit-reproducible across machines (different hardware
 and kernels round differently). Cross-machine, cross-backend bit-equality
 is never claimed (see `benchmarks/notes.md`).
 
-## Deviations from the spec
+## Spec alignment
 
-The implementation surfaced amendments queued for the design spec: the
-`ts-stat`/`tabular-stat` model kinds, aggregate-form `forecast`/
-`detect_anomalies` as the one calling convention for series operations,
-the removal of receipts, and null option values meaning "key omitted."
-These are noted at the top of the files that introduce them.
+The design spec (RFC 0005) has been amended to match the implemented
+surface: the `ts-stat`/`tabular-stat` model kinds, the aggregate calling
+convention for `forecast` and `detect_anomalies`, null option values
+meaning "key omitted," and the removal of receipts (that design is
+preserved in the RFC's Appendix D). Section references in this document
+follow the amended numbering.
 
 [tvf]: https://www.sqlite.org/vtab.html#tabfunc2
@@ -37,7 +37,7 @@ prefix?=dist
 
 TARGET_LOADABLE=$(prefix)/predict0.$(LOADABLE_EXTENSION)
 
-OBJS=sqlite-predict.c predict-forecast.c predict-receipts.c predict-tabular.c predict-student.c predict-distill.c vendor/sha256.c
+OBJS=sqlite-predict.c predict-forecast.c predict-registry.c predict-tabular.c predict-student.c predict-distill.c vendor/sha256.c
 ONNX_OBJS=$(OBJS) predict-onnx.c
 
 # onnxruntime is a build+runtime dependency of the loadable-onnx variant
@@ -117,7 +117,7 @@ test-onnx: loadable-onnx
 
 # ASan+UBSan on the C soak driver (standalone executable: no DYLD
 # injection needed, macOS SIP strips it for system binaries anyway).
-# Covers every operation, receipts, replay, and the error paths.
+# Covers every operation and the error paths.
 test-asan: vendor/sqlite3ext.h sqlite-predict.h
 	mkdir -p $(prefix)
 	clang -std=c99 -g -O1 -fsanitize=address,undefined \
@@ -150,7 +150,7 @@ fuzz-build: vendor/sqlite3ext.h sqlite-predict.h
 	  -DSQLITE_CORE -DSQLITE_PREDICT_STATIC -DSQLITE_STRICT_SUBTYPE=1 \
 	  -Ivendor/ -I./ \
 	  fuzz/fuzz_predict.c $(OBJS) vendor/sqlite3.c \
-	  -o $(prefix)/fuzz_predict
+	  -o $(prefix)/fuzz_predict -lm -lpthread -ldl
 
 fuzz: fuzz-build
 	mkdir -p fuzz/corpus
@@ -194,14 +194,21 @@ soak-wasm: $(prefix) vendor/sqlite3ext.h sqlite-predict.h
 	  -sALLOW_MEMORY_GROWTH -sEXIT_RUNTIME=1 -sSTACK_SIZE=1048576 \
 	  tests/soak.c $(OBJS) vendor/sqlite3.c -o $(prefix)/soak.js
 
+# refresh the gitignored dev copies of the loadable inside the language
+# bindings, so their local test suites exercise the current build
+bindings-dev: loadable
+	cp $(prefix)/predict0.$(LOADABLE_EXTENSION) bindings/node/
+	cp $(prefix)/predict0.$(LOADABLE_EXTENSION) bindings/python/sqlite_predict/
+
 clean:
 	rm -rf $(prefix) sqlite-predict.h
 
 format:
 	clang-format -i sqlite-predict.c predict-*.c
 
 .PHONY: loadable loadable-onnx loadable-onnx-gpu amalgamation amalgamation-check python-src rust-src \
-  sync-version debug test test-loadable test-onnx test-asan-onnx clean format
+  sync-version debug test test-loadable test-onnx test-asan test-asan-onnx test-valgrind \
+  fuzz fuzz-build fuzz-docker soak soak-wasm bindings-dev clean format
 
 # stage the amalgamation + SQLite ext headers into the python package so it can
 # build a self-contained wheel (used by dev installs and the wheels workflow)
 
@@ -1,118 +1,74 @@
-# Releasing & claiming sqlite-predict
+# Releasing sqlite-predict
 
-Two separate jobs: **claim the names** (do this before any public mention, so
-nobody squats them) and **cut a release** (the functional launch). The generic
-`sqlite-predict` name is the one worth claiming everywhere; the everpure-scoped /
-prefixed packages are brand mirrors and lower urgency.
+Releases are tag-driven. Pushing a `v*` tag fires four workflows that
+build and publish everything; the manual part is syncing the version,
+committing, and tagging.
 
-Do everything under **org-owned accounts** (everpure / Pure Storage), never a
-personal login, so publishing survives people leaving.
-
----
-
-## Part 1 — Claim the names now
-
-Flat-namespace registries are first-come-first-served, so these three are the
-real squat risk. Each artifact below is already built and verified in this repo;
-you only need the account. Bump the version and re-run for later releases.
-
-### PyPI — `sqlite-predict`
+## Cut a release
 
-1. Create a PyPI account, then an API token (Account settings -> API tokens).
-2. Build (or reuse the built) sdist and upload:
+1. Sync every manifest to the new version:
 
    ```sh
-   make python-src
-   python -m build --sdist --outdir bindings/python/dist bindings/python
-   python -m twine upload -u __token__ -p pypi-XXXX \
-     bindings/python/dist/sqlite_predict-*.tar.gz
+   make sync-version V=0.0.2
    ```
 
-   The sdist claims the name and is installable (it compiles on the user's
-   machine). Compiler-free **wheels** come from the tag pipeline in Part 2.
+   This writes `VERSION` and syncs it into `bindings/rust/Cargo.toml`,
+   `bindings/python/pyproject.toml` (PEP 440 form, e.g. `0.0.1-alpha.5`
+   becomes `0.0.1a5`), `bindings/python/sqlite_predict/__init__.py`
+   (`__version__`), and `bindings/node/package.json` (including the
+   per-platform `optionalDependencies` pins). The C header derives its
+   version from `VERSION` at build time and needs no edit.
 
-### crates.io — `sqlite-predict`
+2. Commit the version bump.
 
-1. Log in to crates.io with the org GitHub account; create an API token.
-2. Publish (the crate compiles the amalgamation itself; fully functional on
-   install):
+3. Tag and push:
 
    ```sh
-   cargo login <token>
-   make rust-src
-   cargo publish --manifest-path bindings/rust/Cargo.toml --allow-dirty
+   git tag v0.0.2
+   git push && git push --tags
    ```
 
-   `--allow-dirty` is needed because `csrc/` is generated (git-ignored); it is
-   still included in the published crate via `Cargo.toml`'s `include`.
-
-### npm — `sqlite-predict` (unscoped)
-
-1. `npm login` as the org account.
-2. Publish the main package to claim the name:
-
-   ```sh
-   cd bindings/node && npm publish --access public
-   ```
+That is the whole procedure. Registry versions (PyPI, crates.io, npm)
+are immutable: if a publish job fails partway, fix the cause and cut a
+fresh version rather than re-tagging.
 
-   NOTE: this **claims the name but is not yet functional.** The package resolves
-   its binary from per-platform packages (`sqlite-predict-<platform>`) that must
-   be built and published by CI (not wired yet — see "Open follow-ups"). Claim
-   now; make it functional before you announce npm.
+## What the tag triggers
 
-### GitHub Releases — no account
+All four workflows in `.github/workflows/` fire on every `v*` tag push:
 
-Nothing to claim; the repo owns it. See Part 2.
+| Workflow | Publishes | Credentials |
+| --- | --- | --- |
+| `release.yml` | GitHub Release: prebuilt loadables for Linux, macOS, and Windows, the single-file amalgamation (`sqlite-predict.c`), and `SHA256SUMS`, with generated release notes | built-in `GITHUB_TOKEN` |
+| `wheels.yml` | Python wheels (manylinux and macOS, compiler-free `pip install sqlite-predict`) plus the sdist, to PyPI | trusted publishing (OIDC), no stored token |
+| `npm.yml` | the per-platform binary packages (`sqlite-predict-darwin-arm64`, `sqlite-predict-darwin-x64`, `sqlite-predict-linux-x64`, `sqlite-predict-linux-arm64`, `sqlite-predict-windows-x64`), then the main `sqlite-predict` package with `optionalDependencies` pinned to the same version | `NPM_TOKEN` repo secret |
+| `crate.yml` | the `sqlite-predict` crate to crates.io (the crate's `build.rs` compiles the bundled amalgamation on the user's machine) | `CARGO_REGISTRY_TOKEN` repo secret |
 
----
+`npm.yml` and `crate.yml` also support `workflow_dispatch` with an
+explicit version input, for re-running a single registry publish
+without a new tag.
 
-## Part 2 — Cut a release
+## One-time setup (already done, recorded for repo moves)
 
-Tagging drives everything else automatically (built-in `GITHUB_TOKEN`, no
-external secrets for the binaries):
+- **PyPI trusted publisher** on the `sqlite-predict` project: owner
+  `PureStorage-OpenConnect`, repository `sqlite-predict`, workflow
+  `wheels.yml`, environment `pypi`. A matching `pypi` GitHub
+  environment must exist (Settings, then Environments). If the repo
+  moves, update the trusted publisher's owner.
+- **`NPM_TOKEN`**: an npm automation token for the org account, stored
+  as a repo secret.
+- **`CARGO_REGISTRY_TOKEN`**: a crates.io API token for the org
+  account, stored as a repo secret.
 
-```sh
-git tag v0.0.1-alpha.1
-git push origin v0.0.1-alpha.1
-```
-
-- `release.yml` builds Linux/macOS/Windows loadables + the amalgamation
-  (`sqlite-predict.c`) + `SHA256SUMS` and publishes a GitHub Release.
-- `wheels.yml` builds the Python wheels + sdist and, once PyPI trusted
-  publishing is configured (below), uploads them so `pip install sqlite-predict`
-  is compiler-free.
-
-### PyPI trusted publishing (one-time, recommended over tokens)
-
-On PyPI -> the `sqlite-predict` project -> Publishing -> add a trusted publisher:
-
-| field | value |
-| --- | --- |
-| Owner | `PureStorage-OpenConnect` (or the everpure org, if the repo moves) |
-| Repository | `sqlite-predict` |
-| Workflow | `wheels.yml` |
-| Environment | `pypi` |
-
-Then create a `pypi` GitHub environment (Settings -> Environments). After that,
-a `v*` tag publishes wheels with no token stored in GitHub.
-
----
-
-## Part 3 — Brand mirrors (everpure)
-
-Lower urgency: `@everpure/*` on npm is already yours by scope, and the prefixed
-PyPI/crates names aren't the discoverable target. When ready, publish the same
-content under the branded names (`everpure-sqlite-predict` on PyPI/crates,
-`@everpure/sqlite-predict` on npm) as thin mirror packages. Ask and this can be
-wired into the release workflows.
+All registry accounts are org-owned (everpure / Pure Storage), never a
+personal login, so publishing survives people leaving.
 
----
+## Names claimed as of alpha.5
 
-## Open follow-ups (not blocking the name claims)
+The generic `sqlite-predict` name is claimed and functional on all
+three flat-namespace registries: PyPI, crates.io, and npm (the main
+package plus the five per-platform binary packages listed above).
+GitHub Releases need no claim; the repo owns them.
 
-- **npm per-platform binary packages** + a workflow to build/publish them, so
-  `npm install sqlite-predict` ships a working binary (today only the name is
-  claimable). Same pattern as the wheels.
-- **Windows/musl/arm wheel coverage** in `wheels.yml` (currently CPython
-  manylinux + macOS).
-- The brand mirror packages in Part 3.
+The everpure-branded mirror names (`everpure-sqlite-predict` on PyPI
+and crates.io, `@everpure/sqlite-predict` on npm) are unclaimed and low
+urgency; the npm scope already belongs to the org.
@@ -1,4 +1,4 @@
-# Security Policy
+# Security policy
 
 ## Reporting a vulnerability
 
@@ -39,7 +39,6 @@ particular attention:
   forecast horizons, and per-call work are bounded, and interrupts are
   honored between batches.
 
-Error messages do not echo input row values. Receipts are as sensitive as
-the queries they record.
+Error messages do not echo input row values.
 
 [ghsa]: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability
@@ -0,0 +1 @@
+aggopts1 and opts1 deliberately keep the removed "receipt":0 key: unknown option keys are fuzz fodder for the fail-loud options-rejection path.
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1 @@`
	`1`	`+aggopts1 and opts1 deliberately keep the removed "receipt":0 key: unknown option keys are fuzz fodder for the fail-loud options-rejection path.`