# FrankenSQLite — Technical Due-Diligence Assessment

**The hook:** A 1,784,743-line, safe-Rust, clean-room SQLite reimplementation that replaced the single-writer lock with page-level MVCC — whose own README warns you its `PRAGMA key` silently does nothing.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read). **[CI-observed]** is Tier 2 (seen executing on live CI pages — attests the suite *runs*, not that it is green). **[Maintainer claim]** asserted in README/docs, not independently executed. **[External]** independent sources. **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

## TL;DR

FrankenSQLite is a genuine, large-scale clean-room reimplementation of SQLite 3.52.0 in safe Rust: 28 workspace crates, 1,784,743 lines of first-party Rust across 1,598 files [Verified, High], a real SQL parser → VDBE pipeline (200 counted opcodes; the planner crate exists but is not the primary hot path), pager/WAL/B-tree storage stack, page-level MVCC with `BEGIN CONCURRENT` and conservative page-granularity SSI (Serializable Snapshot Isolation) by default, seven extension crates (FTS5, JSON1, R-tree, ICU, session, misc, FTS3-helpers), a SQLite-compatible C ABI shim, an experimental WASM target, and 25,684 counted `#[test]` annotations [Verified, High]. It ships real releases — v0.4.4 on GitHub (2026-09-17), all 28 crate manifests at 0.4.4 [Verified, High], 31 release assets including per-platform tarballs and `SHA256SUMS.minisig` [Verified, High] — and it runs its storage I/O on **asupersync 0.5.0**, a real registry-published async runtime dependency, not a hand-rolled loop [Verified in Cargo.lock with checksum, High]. Its two signature bets are **concurrent writers** (the one thing SQLite structurally cannot do) and **RaptorQ erasure-coded durability** (the one thing SQLite does not attempt). But the README is unusually honest about both: the safe write-merge ladder is dormant/test-only and same-page conflicts abort-and-retry; the RaptorQ decoder is not wired to the compatibility WAL reader; and the packet's headline honesty exhibit is the encryption story — an XChaCha20-Poly1305 DEK/KEK design lives in `fsqlite-pager` but `PRAGMA key`/`rekey` are not dispatched, and because unrecognised PRAGMAs are silently ignored, `PRAGMA key` *returns success while leaving the database unencrypted* [Verified in README FAQ + troubleshooting, High]. **TRL 6. NODUS ring: Explore.** Strongest strength: the evidence discipline — a performance negative-results ledger, a strict parity-release threshold policy (100% declared-surface parity required, signed), machine-readable contracts, a differential oracle against bundled rusqlite, crash-recovery fault matrices, and a README that refuses numeric performance claims for current main. Strongest ceiling: bus factor 1 with an explicit no-outside-contributions policy, zero independent benchmarks/reviews/deployments found, a pinned dated-nightly toolchain, and the non-OSI MIT+OpenAI/Anthropic-rider license that withholds all rights — including benchmarking — from the two leading AI labs.

## Quick Links

- Repository: https://github.com/Dicklesworthstone/frankensqlite
- README: https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/README.md
- License (MIT + OpenAI/Anthropic rider, read verbatim): https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/LICENSE
- Changelog (v0.4.4 current, 2026-09-17): https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/CHANGELOG.md
- Releases: https://github.com/Dicklesworthstone/frankensqlite/releases
- v0.4.4 release: https://github.com/Dicklesworthstone/frankensqlite/releases/tag/v0.4.4
- SQLite version contract (targets 3.52.0): https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/docs/contracts/sqlite_version_contract.toml
- Supported surface matrix: https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/supported_surface_matrix.toml
- Parity release threshold policy (strict 100% declared-surface parity): https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/parity_release_threshold_policy.toml
- Caller-facing concurrency contract: https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/docs/concurrency-contract.md
- Performance negative-results ledger: https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/docs/progress/perf-negative-results.md
- Dependency upgrade log: https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/UPGRADE_LOG.md
- Verification Gates workflow (linked by the README CI badge; currently disabled — see §4.7): https://github.com/Dicklesworthstone/frankensqlite/blob/HEAD/.github/workflows/verification-gates.yml
- Open issue: lower-level MVCC API is not serializable on its own (#189): https://github.com/Dicklesworthstone/frankensqlite/issues/189
- Open issue: Windows `-shm` contents are process-local (#395): https://github.com/Dicklesworthstone/frankensqlite/issues/395

## Did you know?

The README's troubleshooting table warns that running `PRAGMA key = 'secret'` on FrankenSQLite **returns success while leaving the database completely unencrypted** — the XChaCha20-Poly1305 page-encryption design is implemented in `fsqlite-pager` (`encrypt.rs` verified in tree) but no `PRAGMA key`/`rekey` dispatch is wired into `Connection`, and because unrecognised PRAGMAs are silently ignored, the command reports no error. The maintainer lists "Expected behavior today — do not rely on FrankenSQLite for encryption at rest" [README FAQ + troubleshooting table, Verified High]. It is the rare project whose docs document its own security foot-gun.

## Franken-worthy next steps

These are research directions, not engineering tickets: each is novel, specific, falsifiable, and backed by rigor this project has already demonstrated.

1. **Wake the merge ladder under a red-team flag, or kill it.** The safe write-merge ladder (intent replay + structured page patches) exists as dormant, test-exercised code in `fsqlite-mvcc` with a documented safety ladder (`PRAGMA fsqlite.write_merge = SAFE | LAB_UNSAFE`; raw byte-range XOR merge explicitly forbidden) — a correctness problem most MVCC designs refuse to touch. Wire it into the live commit path behind a lab-only flag and run asupersync's deterministic lab reactor through a same-page write-conflict storm, comparing merged results byte-for-byte against serial execution, with the harness's DPOR schedule explorer (`dpor_enumerate_trace_classes` in `crates/fsqlite-harness/src/tla.rs`, verified in tree) enumerating interleavings. **Falsification:** any lost update, any merge the serial oracle disagrees with, or a merged-commit abort rate that makes the ladder slower than abort-and-retry — the ladder stays dormant, and the experiment is published either way. The DPOR + fault-matrix machinery already in the harness makes this the rare codebase that could attempt it honestly.
2. **Extract Page-SSI as a portable concurrency contract.** The conservative Cahill/Fekete rule applied at page granularity — with the dependency-tracking boundary drawn explicitly at the connection pipeline (and the lower-level `TransactionManager` API documented as *not* serializable on its own, #189) — is a clean, named, tested isolation artifact. Port the Page-SSI validator to a *different* page-structured store and publish the write-skew detection results. **Falsification:** if the SSI machinery cannot be decoupled from `fsqlite-mvcc`'s types within one focused workstream, it is engine scaffolding, not a portable contract — and the negative result is itself the finding.
3. **Write-time origin binding on the MVCC commit pipeline.** The commit path already mints a global `commit_seq` from an `AtomicU64`, publishes it to shared memory with `Release` ordering, and keeps commit evidence — the exact seam where origin attestation belongs. Per arXiv 2606.24322's machine-checked result (write-time origin binding is *necessary*; content/lineage defenses are malleable via origin laundering), bind each commit to (origin identity, policy version, input hash) in a hash-chained, signed commit log. **Falsification:** a red-team campaign attempts origin laundering (forged provenance, replayed commit records, log truncation); any successful laundering the log cannot detect kills the thesis.
4. **An independent rerun of the differential conformance suite.** The harness diffs FrankenSQLite against bundled rusqlite (0.40.1) with machine-readable parity contracts and a strict release policy requiring 100% declared-surface parity — but every number to date is maintainer-produced. **Falsification:** a third party runs the harness on quiet, pinned hardware and publishes the parity score; if the declared surface does not reproduce at the claimed parity, the 100% target is aspirational, not operational. This is the single cheapest experiment that would change this packet's ring.
5. **Crash-recovery as a published corpus.** The project already has power-loss fault matrices (whole/half/third-frame WAL cuts, checksum flips, tail zeroing), SIGKILL-at-chosen-commit-states tests, and bit-flip testing — but committed-row visibility, not `PRAGMA integrity_check`, is the asserted bar, and recovery behavior is maintainer-reported. Freeze the fault matrix as a versioned, machine-readable corpus with expected post-recovery contents, and run it against stock SQLite on the same harness. **Falsification:** any committed-row loss, or any recovery divergence stock SQLite survives and FrankenSQLite does not — published against both engines, no excuses.

---
## 4.1 Header

| Field | Value |
|---|---|
| Repository | https://github.com/Dicklesworthstone/frankensqlite |
| Pinned revision | `315bc0f17279b42c160f203e0d0ad53e3fa0d158` — 2026-09-22 10:12:06 -0400 (= 2026-09-22 14:12 UTC / 08:12 MDT) [Verified, High] |
| Assessment date | 2026-09-22 |
| Language / toolchain | Rust, edition 2024, pinned `nightly-2026-08-31` (`rust-toolchain.toml`) [Verified, High] |
| License | MIT License **with OpenAI/Anthropic Rider** — NOT OSI open source; full text read verbatim, rider scope quoted in §4.8 [Verified, High] |
| Scale | 28 workspace crates; 1,784,743 Rust lines / 1,598 files; 25,684 counted `#[test]` annotations; 5 fuzz targets [Verified, High] |
| Stars / forks | 226 stars / 45 forks (GitHub API, 2026-09-22) [External, High] |
| Releases / tags | GitHub releases incl. v0.4.4 (2026-09-17); all 28 crates at 0.4.4 in their `Cargo.toml` files [Verified, High]; crates.io publishes incl. untagged 0.4.0–0.4.3 [Maintainer claim, Medium — registry API returned 403 to this client, so crates.io contents not directly fetched] |
| Last push | 2026-09-22T14:55:06Z (API) — HEAD commit `315bc0f` is a 2026-09-22 commit [Verified, High] |
| Maintainer | Single: Dicklesworthstone (Jeffrey Emanuel, per LICENSE copyright); README: "I do not accept outside contributions" — bus factor 1 [Verified, High] |
| Inception | 2026-02-06 per CHANGELOG [Maintainer claim, High] |
| SQLite target | 3.52.0 per `docs/contracts/sqlite_version_contract.toml` [Verified, High] |
| Issue/bead IDs | `GH#…` = GitHub issues; `bd-…` = the repo's `.beads` issue tracker — both are the maintainer's own references, cited so a reader can look them up |

**Analyst method.** Fresh shallow clone of HEAD to `~/workspace/franken-research/frankensqlite-clone/`. Read: README (full, 187 KB), LICENSE (verbatim), CHANGELOG (version timeline), `rust-toolchain.toml`, workspace `Cargo.toml` (members, lints, asupersync pinning), `sqlite_version_contract.toml`, `supported_surface_matrix.toml`, `parity_release_threshold_policy.toml`, `docs/concurrency-contract.md` (existence), `docs/progress/perf-negative-results.md` (headers), root `UPGRADE_LOG.md`. Grep-verified: workspace members (28), Rust line/file counts per crate, `#[test]` count, `unsafe` census per crate (code lines vs comments/variable names), which crates inherit workspace lints, asupersync presence in `Cargo.lock` (name, version 0.5.0, registry source, checksum) and its use-sites (3,005 `asupersync::` references across 17 files in `fsqlite-core/src`, recursive count), `BEGIN CONCURRENT`/`BeginConcurrent` code presence, `encrypt.rs` in `fsqlite-pager`, `LOCK_TABLE_SHARDS = 64` and the `InProcessPageLockTable` fast-path/fallback design, `AtomicU64` commit_seq with `Release`-ordering stores, FTS3 virtual-table-module registration absence, README-vs-code drift (crate LOC tree listing, CI badge, CHANGELOG unreleased section), `baselines/` benchmark artifacts and their self-labeling, fuzz target count. Fetched and confirmed resolution of every Quick Link via HTTP status (one 404 found and replaced with the blob URL form). GitHub API: stars/forks, workflow states and recent runs, releases. Web-searched for independent coverage (benchmarks, reviews, production use). **Not done:** did not compile, run tests, start the CLI, execute any benchmark, run the harness, reproduce the differential oracle, or verify installer signatures/artifacts. Shallow clone only (no history; `legacy_sqlite_code/sqlite` submodule not fetched). crates.io API returned 403 to this client, so crates.io download counts and publish metadata were not independently fetched.

## 4.2 Executive verdict

FrankenSQLite is a **genuinely substantive, unusually self-critical clean-room Rust reimplementation of SQLite 3.52.0** [Inference, High] — not vaporware: a shallow clone of HEAD confirms 28 crates and 1,784,743 lines of first-party Rust [Verified, High], a real SQL parser → VDBE pipeline with 200 counted opcode variants (note: the planner crate exists but is *not* the primary `Connection` hot path — most work compiles directly through `fsqlite-vdbe::codegen` [Verified README admission + enum count, High]), pager/WAL/B-tree storage with byte-level SQLite file-format compatibility as the stated non-negotiable [Maintainer claim, Medium], a page-level MVCC engine with `BEGIN CONCURRENT` and conservative page-granularity SSI on by default [Verified code presence, High; isolation behavior Maintainer claim, Medium], 25,684 counted test annotations [Verified, High], and a real release cadence — v0.4.4 on GitHub 2026-09-17 with all 28 crates at 0.4.4 [Verified, High]. Its two signature bets are the ones SQLite structurally refuses: **concurrent writers** (page-level MVCC replacing the single-writer WAL lock) and **information-theoretic durability** (RaptorQ erasure coding) [Inference, High]. But the README grades both honestly: the safe write-merge ladder is dormant and same-page conflicts abort-and-retry today; RaptorQ repair-symbol generation exists on native WAL but the compatibility WAL reader never calls the decoder; and page encryption is implemented-but-unwired with the foot-gun documented [Verified disclaimers, High]. The engine's async I/O runs on **asupersync 0.5.0**, a genuine registry-published runtime dependency [Verified, High] — the sibling-constellation coupling is real here, not assumed. **NODUS: Explore. Wardley: clean-room SQLite core at early product (it ships releases), page-SSI concurrent writers at early custom-built, RaptorQ durability and the merge ladder at Genesis.** Its most durable contribution today may be the **verification machinery** — the parity contracts, strict release-threshold policy, negative-results ledger, differential oracle, and crash-recovery fault matrices — rather than either headline bet [Inference, Medium].

## 4.3 Claim inventory: demonstrated vs aspirational

Status values: *demonstrated* / *partially demonstrated* / *aspirational* / *disproven* / *stale*.

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1 | Page-level MVCC concurrent writers with `BEGIN CONCURRENT` and SSI by default | **Partially demonstrated** | [Verified code presence, High] + [Maintainer claim on behavior, Medium] — `fsqlite-mvcc` is 115,393 lines; `begin_concurrent.rs` (9,162), `lifecycle.rs` (12,510) exist; README gates "full concurrent-writer certification" on correctness gates; cross-process MVCC is partial (GH#329 open); the lower-level `TransactionManager` API is documented as non-serializable alone (#189) |
| 2 | 100% behavioral parity target with C SQLite 3.52.0 for the supported surface | **Aspirational** (explicitly a target) | [Maintainer claim, High] — the README and FAQ say "target"; the strict release policy *requires* 100% declared-surface parity before release, which makes the target a gate rather than a claim; no published parity scorecard found |
| 3 | RaptorQ / information-theoretic durability and self-healing storage | **Partially demonstrated** | [Verified code presence, High] + [Maintainer claim, Medium] — RaptorQ codecs and WAL repair routines exist; native file-backed connections generate `.wal-fec` repair symbols asynchronously; the compatibility WAL reader does not call the decoder (bd-1hi.11); automatic recovery not wired; README: "gated on end-to-end recovery evidence" |
| 4 | `unsafe` confined to `fsqlite-vfs` (mmap/shm) and `fsqlite-c-api` (FFI); engine in safe Rust | **Demonstrated** | [Verified, High] — 26 of 28 crates inherit workspace `unsafe_code = "forbid"`; the two exceptions declare local `[lints.rust] unsafe_code = "allow"` with comments; real `unsafe` blocks found only in vfs (41 blocks: mmap/shm/uring/atomics) and c-api (FFI boundary); all other `unsafe` hits are comments, doc strings, or identifiers (`unsafe_input`, `unsafe_block_gate`) |
| 5 | 28-member Cargo workspace | **Demonstrated** | [Verified, High] — `members` list in root `Cargo.toml` counts 28; README says 28 |
| 6 | Page-level encryption (XChaCha20-Poly1305 DEK/KEK, Argon2id) | **Aspirational** | [Verified disclaimers, High] — `encrypt.rs` exists in `fsqlite-pager`; FAQ: "It does not work yet. `PRAGMA key` and `PRAGMA rekey` are not implemented"; troubleshooting: silently-ignored PRAGMA returns success, "do not rely on FrankenSQLite for encryption at rest" |
| 7 | Async I/O on asupersync (not tokio) | **Demonstrated** | [Verified, High] — asupersync 0.5.0 in `Cargo.lock` with registry source + checksum; 3,005 `asupersync::` references across 17 files in `fsqlite-core/src` (recursive count); workspace dep `default-features = false`; "Async Integration (asupersync + Cx)" section in README |
| 8 | Cross-process MVCC via shared-memory coordination | **Partially demonstrated** | [Maintainer claim, Medium] — "Partial (shared-memory coordination, bounded by the measured harness scale)"; GH#329 open (public `Connection` MVCC authority stays process-local); Windows `-shm` contents are process-local heap, not a real mapping (#395) |
| 9 | Extensions live: FTS5, JSON1, R-tree, ICU, session, misc | **Partially demonstrated** | [Maintainer claim, Medium] — README: FTS5, JSON1 (`json_each`/`json_tree`), R-tree/geopoly, ICU, misc (`generate_series`) register in the live engine; FTS3/FTS4 helper-level only (no virtual-table module — no registration found in core); `dbstat`, `carray`, `dbpage` not implemented |
| 10 | Signed, installable native CLI artifacts (install.sh / install.ps1, minisign) | **Partially demonstrated** | [Verified asset existence, High; signature validity not checked] — v0.4.4 GitHub release carries 31 assets: per-platform tarballs (linux/darwin aarch64/x86_64), per-artifact `.sha256` files, `SHA256SUMS.minisig`, and a manifest JSON (GitHub API); installers and `--help` documented in README; v0.1.16–v0.1.17 and v0.2.0+ coverage per README (v0.1.18–v0.1.19 published no native signed sets) [Maintainer claim, Medium] |
| 11 | Experimental WASM target (`fsqlite-wasm` cdylib + npm package) | **Partially demonstrated** | [Maintainer claim + verified crate exists, Medium] — `fsqlite-wasm` is 4,146 lines; README: in-memory only, no OPFS/IndexedDB persistence yet; its CI workflow (`fsqlite-wasm-ci.yml`) is currently `disabled_manually` |
| 12 | No numeric performance result claimed for current main | **Demonstrated** (a disavowal, and it holds) | [Verified, High] — README "Performance Characteristics": "No numeric performance result is claimed for current `main`"; old matrices kept as diagnostic history in `perf-negative-results.md`; the async-migration timing discontinuity is documented as release-blocking |
| 13 | Project-structure listing: `fsqlite-types` "2,800+ LOC, 64 tests", `fsqlite-error` "578 LOC, 13 tests" | **Stale** | [Verified, High] — actual: fsqlite-types 28,471 lines / 16 files; fsqlite-error 1,760 lines; the tree-listing numbers are an order of magnitude off — docs lagging a fast tree |
| 14 | Safe write-merge ladder (intent replay + structured page patches) | **Aspirational** (dormant by design, stated) | [Verified disclaimers, High] — "design plus dormant implementation, not live commit behavior"; intent log not populated during writes; `PRAGMA fsqlite.write_merge` currently a validation switch; wiring tracked in bd-3d5y3 / bd-p4dcv |
| 15 | UTF-16le/be databases admitted for reads and writes | **Partially demonstrated** | [Maintainer claim, Medium] — README: admitted, but "UTF-16 support is newer than the long-verified UTF-8 surface"; mixed-encoding ATTACH rejected; parity verification deepest on UTF-8 |
| 16 | Full sqlite3-style CLI front-end | **Aspirational** (README corrects itself) | [Verified, High] — README "Current Implementation Status": `fsqlite-cli` is "currently a small shell and command runner, not yet a full sqlite3-style front-end" |

## 4.4 Architecture (reconstructed, not summarized)

[Verified from the clone; README diagrams treated as claims where noted]

**Crate topology (28 workspace members, root `Cargo.toml`):** `fsqlite-types` (28,471 lines — newtypes: PageNumber, TxnId, PageSize, opcodes, error codes), `fsqlite-error` (1,760), `fsqlite-vfs` (37,022 — Memory/Unix/Windows/uring backends, mmap/shm; the unsafe crate), `fsqlite-pager` (93,626 — page cache, journal modes, `encrypt.rs`), `fsqlite-wal` (54,231 — WAL frames, checkpoint modes, MVCC extensions), `fsqlite-mvcc` (115,393 — page lock table, siread table, `begin_concurrent.rs`, `lifecycle.rs`, dormant merge ladder, Silo-style epoch scaffold), `fsqlite-btree` (43,209 — cursors, page splits, freelist), `fsqlite-ast` (8,444), `fsqlite-parser` (24,401 — Pratt parser, 11,324-line `parser.rs`), `fsqlite-planner` (26,624 — exists and is substantial, but README admits it is *not* the primary `Connection` hot path: most work compiles directly through `fsqlite-vdbe::codegen`), `fsqlite-vdbe` (123,369 — 200 opcode variants counted in the `Opcode` enum in `fsqlite-types` (README: "190+"), numbered to match C SQLite; `codegen.rs` 57,901 lines, `engine.rs` 39,338, vectorized batch kernels dormant except `MakeRecord`), `fsqlite-func` (23,642 — built-in functions), seven `fsqlite-ext-*` crates (fts3 helpers 721 lines, fts5 27,134, icu 1,193, json 7,388, misc 2,934, rtree 3,722, session 4,783), `fsqlite-core` (533,317 — the integration monolith; `connection.rs` alone is 293,644 lines), `fsqlite` (62,113 — public facade), `fsqlite-cli` (4,599 — small shell), `fsqlite-harness` (296,053 — the verification apparatus: differential runner, parity dashboards, fault injection, durability matrix, SLO governor), `fsqlite-e2e` (245,714 — workload replay, benchmark execution), `fsqlite-observability` (5,047 — metrics), `fsqlite-c-api` (3,377 — the SQLite-compatible C ABI shim; the other unsafe crate), `fsqlite-wasm` (4,146 — experimental), `beads-doctor` (2,310 — beads DB health tool, asupersync-native).

**Data flow:** SQL text → `fsqlite-parser` (AST) → `fsqlite-vdbe::codegen` (hot path; planner not primary) → `VdbeEngine` executes opcodes → storage cursors into `fsqlite-btree` → `fsqlite-pager` (page cache, journal/WAL) → `fsqlite-vfs` (async I/O via asupersync `Cx`, blocking-pool staging, io_uring on Linux). Concurrent transactions: `BEGIN CONCURRENT` → `fsqlite-mvcc` page locks via `InProcessPageLockTable` — a lock-free fast path of lazily allocated atomic chunks for pages 1..=65536 plus a sharded fallback (`LOCK_TABLE_SHARDS = 64`, verified in `core_types.rs`; an optional `mvcc-flat-combining` feature routes the hot path through flat-combining shards) [Verified, High] — snapshot reads via `CommitSeq` comparisons against a version arena; commit goes through first-committer-wins base-drift detection plus page-SSI dangerous-structure validation, publishing `commit_seq` from a global `AtomicU64` with `Release`-ordering stores (verified in `cache_aligned.rs`) [Verified, High]. Region-tree lifetime model over asupersync root-region tasks; cancellation via asupersync obligations (Reserved → Committed/Aborted).

**Memory-safety posture** [Verified, High]: 26 of 28 crates inherit the workspace `[workspace.lints.rust] unsafe_code = "forbid"`. The two exceptions (`fsqlite-vfs`, `fsqlite-c-api`) carry local `[lints.rust] unsafe_code = "allow"` *with a comment explaining why* ("Cannot inherit workspace lints because workspace forbids unsafe_code"). Effective unsafe is confined to: vfs mmap/shm/uring/atomics (41 `unsafe {}` blocks, `unsafe impl Send/Sync` on `MmapBacking`, `unsafe fn` pointer constructors) and the c-api FFI boundary (`unsafe extern "C"` exports like `sqlite3_open`, `sqlite3_step`, raw-pointer callback plumbing). No `unsafe` in parser, planner, VDBE, pager, MVCC, WAL, btree, or extensions — the engine claim holds.

**Dependency posture:** asupersync 0.5.0 is a genuine runtime dependency — registry source, pinned checksum `f34b1a19ffd6b74570339a156912436335bb09c594c675c62ea164b19a1f2511`, `default-features = false`, used pervasively (3,005 references across 17 files in `fsqlite-core/src`) for the async storage path, the lab reactor for deterministic concurrency tests, and cancellation obligations. There is no tokio anywhere in `Cargo.lock` (zero matches) [Verified, High] — the "asupersync rather than tokio" claim is structural, not aspirational. It drags the franken-decision/franken-evidence/franken-kernel family with it (visible in the lock file). Also notable: `rusqlite 0.40.1` (bundled) is a workspace dependency — the differential oracle the harness diffs against. The sibling-constellation coupling the Rulebook asks about is **real and load-bearing here**: the storage engine's async runtime is the maintainer's own adjacent project, version-pinned, and the UPGRADE_LOG shows repeated asupersync bumps gated on scoped runtime checks.

**README-vs-code drift (governance signal):** the project-structure tree lists `fsqlite-types` at "2,800+ LOC, 64 tests" and `fsqlite-error` at "578 LOC, 13 tests" — actual counts are 28,471 lines and 1,760 lines, an order of magnitude off. The CHANGELOG's `[Unreleased]` section says "No changes yet" while HEAD (`315bc0f`, "feat(sdk): integrate persistent rebase history with confirmed delivery") is a post-v0.4.4 commit. The README CI badge links to `verification-gates.yml`, which is currently disabled on GitHub. Each instance is minor and the README self-corrects on the important claims — but the pattern is docs lagging a very fast-moving tree.

---
## 4.5 Benchmark and conformance audit

### Maintainer-produced numbers

| Workload | Number | Method controls | Would it survive independent rerun? |
|---|---|---|---|
| Any throughput/latency on current `main` | **None claimed** | n/a | n/a — the README states "No numeric performance result is claimed for current `main`." Historical matrices are kept as diagnostic history in `docs/progress/perf-negative-results.md`, explicitly "not release evidence" |
| Release gate (not a result) | Single-writer benchmarks within 3× of C SQLite | Stated as a *target* in the risk register | Not yet measured on the release matrix; cannot be cited as a result |
| SSI overhead | Unmeasured | "PostgreSQL's SSI results are prior art, not an estimate"; cost "remains part of this project's release benchmark matrix" | Explicitly unmeasured |
| Native RaptorQ repair pipeline | No fixed repair percentage or achieved multicast speedup claimed | README: "No fixed repair percentage or achieved multicast speedup is claimed" | Explicitly unclaimed |
| varint throughput | None | "No numeric varint throughput claim is made without a cited benchmark" | Explicitly unclaimed |

**The disavowal, quoted:** "No numeric performance result is claimed for current `main`." / "They remain diagnostic history in `docs/progress/perf-negative-results.md`, not release evidence." / "The intended data path and shipped size-optimized profile still require a citation-grade performance matrix; neither can be inferred from `release-perf` results." A packet must never cite a FrankenSQLite performance number as a result, because none is offered.

**What the in-tree artifacts actually are:** `baselines/` holds diagnostic history, and it labels itself as such — a hyperfine JSON and smoke report from February 2026 (with `git_sha: "local-dev"`), plus a `complete-matrix-v0.3.18-20260911/` run (11,558 measured samples, 108 canonical cells, measured 2026-09-11 on a Ryzen 7 5800X worker) whose own README says it used a benchmark-only repair patch, is "not a measurement of the unmodified published benchmark executable," and that "these performance samples do not establish database integrity or release acceptance" [Verified, High]. This is the negative-evidence discipline applied to the project's own numbers: the one detailed benchmark artifact in the tree disqualifies itself.

**Reproduction cost (honest):** the tree is a multi-hundred-MB checkout; builds on pinned `nightly-2026-08-31`; the harness is a 296,053-line apparatus with a differential oracle against bundled rusqlite; the sanctioned path runs through remote-execution (`rch`) workers per `.rch/config.toml`. An independent rerun needs the pinned nightly, the submodule'd C SQLite reference, and patience: expect hours.

### Conformance evidence

- **Differential oracle:** the harness diffs FrankenSQLite against bundled `rusqlite` 0.40.1 [Verified dependency, High]; conformance fixtures live in `crates/fsqlite-harness/conformance/` (referenced by the surface matrix); `conformance/slt/` at the root holds only a smoke file — the SLT corpus is ingested by the harness (`corpus_ingest.rs` handles `.slt`/`.sqllogictest`/`.test`) rather than checked in bulk [Verified, High].
- **Declared surface:** 100% behavioral parity *target* with C SQLite 3.52.0 for the supported surface, enforced by a strict release policy (`parity_release_threshold_policy.toml`): 100% declared-surface parity required, no threshold downgrades, no waived obligations, evidence fresh within 24h, signed policy payload [Verified, High]. The policy is a gate design, not a current scorecard — no published parity score was found.
- **Crash recovery:** power-loss fault matrix (whole/half/third-frame WAL cuts, checksum flips, tail zeroing), SIGKILL at chosen commit states, bit-flip testing — asserted bar is committed-row visibility, not `PRAGMA integrity_check` [Maintainer claim, Medium].
- **CI:** the public GitHub Actions surface is not a meaningful signal — see §4.7.

### Independent numbers

**None found.** Web search returns only the repository itself, maintainer-adjacent docs (a FrankenTerm integration-planning doc in the maintainer's `wezterm_automata` repo describing a ~826K-LOC ancestor — stale, maintainer-adjacent, not independent), and two forks (`mvanhorn`, `etafund`) [External, High within recall caveats]. No third-party benchmark, code review, or production deployment found. **Independent validation: zero.**

## 4.6 Comparison: who owns the lane

**The incumbent** is SQLite itself (public domain, the most deployed database engine on earth) — and its process model is the moat: single-writer serialization is a *feature* for SQLite's embedded use cases, not just a limitation [External, High]. **Why the incumbent wins today, in one paragraph:** switching an embedded store is a trust decision, and SQLite's trust comes from 24 years of testing — the README itself cites C SQLite's "~90,000+ lines of TCL" test scripts that "cannot be meaningfully ported" — plus a public-domain license with zero friction and ubiquity in every OS and language runtime; FrankenSQLite offers none of that yet — no independent review, no production deployments, pre-1.0 releases, a pinned nightly toolchain, and a license rider that legally excludes the two AI labs most likely to evaluate it. Nobody swaps the world's most boring-reliable database for a 0.4.4 single-maintainer rewrite on the promise of concurrency they may not need.

**Adjacent lanes (per the README's own comparison table):** **libsql** (Turso's C fork — owns the "SQLite with extensions and sync" lane; the README rates its concurrent writers "Partial (WAL extensions)"), **Limbo** (Rust, owns the async-io_uring lane, keeps single-writer *by design*), **DuckDB** (owns analytics; incompatible format), **rqlite/dqlite** (own the distributed-SQLite lane — Raft consensus replicates the single-writer model *across nodes* rather than parallelizing writers *within one file*, which is a different answer to a different question).

**The genuinely unoccupied lane [Inference, Medium]:** a *SQLite-file-compatible, serializable-concurrent-writer* embedded engine — for the workload that is stuck between "SQLite can't take my write concurrency" and "I don't want to operate Postgres": write-heavy edge and agent systems that need a local file, not a server. Nobody owns it: SQLite and Limbo serialize writers by design; libsql extends WAL but doesn't do MVCC SSI; rqlite/dqlite distribute the single-writer model instead of parallelizing it; DuckDB abandoned the file format. If page-level MVCC with true serializability works at parity, the lane is real — it is the one architectural bet in this packet that the incumbents have structurally declined to make. The RaptorQ durability bet is more crowded conceptually (erasure coding is standard in object stores) but unoccupied *inside* the SQLite file-format envelope.

## 4.7 Technical merit and adversarial review

**Strengths:**
1. **Evidence discipline without peer in this program's honesty dimension.** A performance *negative-results* ledger (ideas measured and rejected, with retry conditions), a strict signed parity-release policy (100% declared-surface parity, no waived obligations, 24h evidence freshness), machine-readable contracts (version, surface, parity score, taxonomy), a differential oracle against bundled rusqlite, crash-recovery fault matrices, and a README that publishes the sentence "No numeric performance result is claimed for current `main`" — then keeps the old numbers around labeled "not release evidence." The methodology-export lens fires hard here [Verified, High].
2. **The unsafe story is real and audited at the lint level.** 26 of 28 crates inherit workspace `forbid(unsafe_code)`; the two exceptions declare their override locally with explanatory comments; the census finds real unsafe only at the mmap/shm/FFI boundaries. For a 1.78M-line codebase, that is a coherent attack-surface story, not an assertion [Verified, High].
3. **Real release engineering.** v0.4.4 with all 28 crates at a uniform version on crates.io, signed native CLI artifacts with minisign verification and exact-version smoke tests in the installers, air-gapped/source-build controls, a documented release timeline back to 0.1.x — this is further along the product axis than most of the 44 repos [Verified, High].
4. **The SSI design is careful in the way that matters.** Page-granular conservative Cahill/Fekete, the dependency-tracking boundary drawn explicitly at the connection pipeline, the lower-level API documented as *not* serializable on its own (#189), the downgrade PRAGMA snapped at `BEGIN CONCURRENT`, the write-merge ladder deliberately left dormant with its own safety ladder rather than shipped half-working. This is concurrency engineering with the failure modes named [Verified design discipline, High; behavioral claims Maintainer claim, Medium].
5. **25,684 counted test annotations plus property-based, fault-injection, and deterministic-concurrency (asupersync lab reactor) testing.** Volume is not quality, but the *mix* is the right mix for a database: round-trip properties, crash matrices, differential oracles, DPOR-style interleaving tests [Verified volume, High].

**Weaknesses:**
1. **Bus factor 1 with an explicit no-contributions policy.** The README's "About Contributions" section declines outside contributions outright ("I do not accept outside contributions for any of my projects... I won't merge them directly"). Combined with a 293,644-line `connection.rs` monolith and a 1.78M-line tree, succession is not merely absent — it is refused [Verified, High].
2. **Zero independent validation of any kind.** No third-party benchmark, review, or deployment found. The README's benchmark honesty is admirable but also means the performance story is entirely prospective: "Single-writer benchmarks within 3× of C SQLite" is a *target*, SSI overhead is *unmeasured*, and the async migration introduced a documented release-blocking timing discontinuity [Verified/External, High].
3. **The public CI surface is hollow.** The README's CI badge links to `verification-gates.yml`, which GitHub reports as `disabled_manually`; its last completed runs (July 2026) all failed, and two August runs are stuck `queued`. The concurrent-platform-matrix has one run ever (cancelled), lint.yml one run (cancelled). Verification evidently happens elsewhere (rch remote workers, local harness runs), but a cold reader clicking the badge finds a dead workflow [CI-observed via API, High].
4. **The two headline bets are both gated, and the gates are far.** Concurrent writers: full certification gated on correctness gates; the merge ladder dormant; cross-process MVCC partial (GH#329); Windows shared memory process-local (#395). Durability: RaptorQ decoder not wired to the compat WAL reader; encryption unwired with a silent-success foot-gun. The README is honest about all of this, which is why the *thesis* is weaker than the *architecture* [Verified, High].
5. **Structural ceilings:** pinned `nightly-2026-08-31` toolchain, 293k-line `connection.rs` and 88k-line-class monoliths that belie the "layered crate" framing, planner not on the hot path (codegen is), no cluster story, WASM in-memory only, 5 fuzz targets at parser/lexer level (no storage-layer fuzzing found), docs chronically lagging the tree [Verified, High].
6. **The license is a strategic own-goal for the stated mission.** The rider withholds *all* rights — including benchmarking, testing, and analyzing — from OpenAI, Anthropic, affiliates, and anyone acting for them, with automatic termination and injunctive relief [Verified verbatim, High]. For a database engine whose adoption depends on evaluation by exactly the organizations building agent infrastructure, this is a hard ceiling, and it helps explain why independent validation is zero: no lab-adjacent third party can even benchmark it without lawyering the rider.

**Steelman of the bear case:** FrankenSQLite is a heroic answer to a question the market answers differently. SQLite's single-writer model is not a bug to most of its users — it is the price of the simplest durable thing that works, and the workloads that need concurrent writers already left embedded SQLite for Postgres, rqlite, or dqlite. The MVCC machinery is 115,393 lines of solution to a problem whose sufferers have alternatives with institutional governance and clean licenses. The RaptorQ bet is intellectually interesting and practically un-demanded: nobody's SQLite corruption story ends with "if only my WAL frames were fountain-coded." At 1.78M lines and bus factor 1 with contributions explicitly refused, the likely terminal state is a private research vehicle that never acquires a second maintainer — impressive, honest, and unadoptable. The verification methodology is the admirable part; methodologies don't get embedded in products.

**Hook audit (the packet grades its own hook):** "A 1,784,743-line, safe-Rust, clean-room SQLite reimplementation that replaced the single-writer lock with page-level MVCC — whose own README warns you its `PRAGMA key` silently does nothing." Line count verified by fresh-clone census; clean-room status is the maintainer's stated method (behavioral-spec-only reference to C source); MVCC verified as code presence with behavior as maintainer claim; the `PRAGMA key` silent-success warning is verified in the README's FAQ and troubleshooting table. No marketing adjectives, no un-gated numbers. The hook survives.

## 4.8 License and governance (material, not boilerplate)

**License text, read verbatim** [Verified, High]: `LICENSE` is the MIT License **with an "ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic)"** that is "part of the 'conditions' of this License" and "controls" in any conflict. Quoted scope: *"Restricted Parties" means OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative).* *"Notwithstanding any other provision of this License, no rights are granted to any Restricted Party."* Disclosure/hosting/distribution to them is forbidden. Crucially, *"use" includes, without limitation: copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, **benchmarking, testing, analyzing**, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems.* Breach terminates all permissions automatically; injunctive relief and attorneys' fees reserved to Jeffrey Emanuel (copyright holder, 2026). **Classification: NOT OSI open source** — named-party discrimination with a use-restriction covering even benchmarking and analysis. This is source-available with a targeted exclusion. (The workspace `Cargo.toml` is unusually candid about it: the `license-file` comment calls it "a restrictive custom license... NOT permissive MIT.")

**The rider as strategy:** defensively coherent (it prevents the two leading labs from absorbing the work into training corpora or evaluation harnesses without permission) and offensively self-sabotaging: the project's credible futures — embedded agent-memory store, evaluated database infrastructure — run through exactly the excluded parties and their downstream. The rider's breadth (even *benchmarking* is forbidden to Restricted Parties) chills the independent validation the project most needs, which helps explain the zero in §4.5. Adoption ceiling: hard.

**Governance:** owner-directed single maintainer; no outside contributions accepted by explicit policy ("I do not accept outside contributions for any of my projects... I won't merge them directly"); issues welcome, PRs at most "illustrate a proposed fix" for Claude/Codex to review; 405 total issues+PRs on GitHub, 31 open issues at assessment. Bus factor 1 [Verified, High]. **What breaks first if velocity decays:** review depth is already the binding constraint at this velocity; a slowdown strands 1.78M lines (including a 293k-line `connection.rs`) on a pinned dated nightly with a maintainer who has pre-declined successors — bit-rot within quarters.

---
## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness (TRL 1–9) | **6** | Real releases ship (v0.4.4, crates.io, signed CLI) and the engine runs — demonstrated in a relevant environment; the 5/6 boundary is honest either way (no operational deployment or independent validation keeps it from 7), and 6 is carried by the release artifacts, not by lab runs alone |
| Strategic relevance (1–5) | **3** | Serializable concurrent writers in the SQLite envelope is a real strategic gap; capped by rider, pre-1.0 state, and the incumbent's trust moat |
| Impact potential (1–5) | **3** (4 if page-SSI concurrent writers reach certified parity) | Embedded-DB market is entrenched; impact is methodological + niche unless the MVCC bet lands |
| Implementation feasibility (1–5) | **3** | The core is largely built; what remains (merge ladder wiring, RaptorQ recovery, parity certification, perf matrix) is bounded but real |
| Time to mainstream (1–5) | **1–2** | Years minimum: needs 1.0, independent validation, a second maintainer (currently refused), and a license change for broad adoption |
| Collaboration potential (1–5) | **1** | Source-available; rider blocks the two most likely AI-lab collaborators; contributions explicitly refused; bus factor 1 |

**Ring: Explore.** The ring rules are decisive: *Pilot* requires a release artifact plus a bounded, real workload fit — the release artifact exists (v0.4.4), but no bounded real workload fit is demonstrated (no deployments, no independent benchmark, performance matrix explicitly deferred); *Invest* requires independent validation plus governance (neither exists). Explore is the default for substantive-but-unproven, and FrankenSQLite — released but unvalidated — is the definition of it. Revisit triggers: first independent benchmark or deployment, parity certification completing, the deferred citation-grade performance matrix landing, a second maintainer (requires a policy change), any license-rider change.

## 4.10 Wardley placement

- **SQLite-protocol/file-format-compatible embedded serving:** Commodity — the format is standardized by SQLite's own documentation and SQLite owns it; FrankenSQLite adds no leverage here. It moves only if the format itself moves (it won't — stability is the format's value proposition).
- **Clean-room Rust SQLite core (parser/planner/VDBE/pager/WAL/B-tree):** Custom-built → early Product — it ships releases and installable artifacts, validated against oracles but not by third parties; moves to Product with independent validation + a 1.0.
- **Page-level MVCC with SSI concurrent writers:** Early Custom-built — the one architectural bet no incumbent makes in this envelope; moves right with certified parity + a published perf matrix, left into researchware if the gates never complete.
- **RaptorQ durability / ECS native mode + write-merge ladder:** Genesis — design plus partial implementation, gated on end-to-end evidence; moves right only when recovery is demonstrated, not generated.
- **Verification apparatus (parity contracts, threshold policy, negative-results ledger, differential oracle, fault matrices):** Custom-built — novel as a packaged discipline and the most transferable component; moves toward Product the moment a second project adopts it (see next step 4).

**The decoupling lens:** FrankenSQLite represents *logic-from-C* (memory safety as the stated motive) and advances *engine-from-single-writer* (concurrency as a property of the engine, not the deployment topology — the one decoupling its competitors refuse). It gestures at the next decoupling the program named — *memory-from-the-store* — only weakly: the commit pipeline's `commit_seq` evidence and the threat-ledger-like commit records are proto-provenance, but nothing here is yet a portable memory capsule. That third decoupling is available as a research direction (next step 3), not a current asset.

## 4.11 Trajectory (12 / 24 / 60 months) — [Inference]

- **12 months:** continued high-velocity single-maintainer work; probable 1.0 or continued 0.4.x/0.5.x releases; the deferred performance matrix either lands (making the throughput story quotable for the first time) or stays deferred; merge-ladder wiring and RaptorQ recovery stay gated on evidence; the pinned nightly ages and forces a re-pin cycle. Stays in Explore.
- **24 months:** bifurcation. **Upside:** an independent benchmark or deployment validates the core claims, parity certification completes against 3.52.0, and a bounded pilot (agent session store, edge device fleet) demonstrates the concurrent-writer fit — Pilot for narrow workloads. **Decay:** velocity slows with no successor (contributions are refused, not merely absent); the 1.78M-line tree on a dated nightly becomes unmaintainable; drifts to Monitor as a research artifact whose verification methodology outlives its product.
- **60 months:** binary. Either a niche-but-real artifact (the serializable-concurrent embedded SQLite for agent/edge workloads — a lane nobody else is building), or superseded: SQLite adds its own concurrency story, Limbo or libsql absorbs the "modern SQLite" conversation, and the general "Rust SQLite" lane consolidates. The verification methodology is the more likely survivor either way.

**Revisit triggers (concrete, observable):** first independent benchmark, review, or production deployment; completion of the 100%-declared-surface parity certification; publication of the citation-grade performance matrix; the merge ladder wired into the live commit path; a second human maintainer (requires a policy change); any change to the license rider; re-enablement and greening of the public verification-gates workflow.

## 4.12 Limitations and open questions (mandatory)

**Not done:** did not compile the workspace, run any test, start the CLI, execute the harness, run the differential oracle, reproduce any conformance claim, verify installer signatures, or fetch the `legacy_sqlite_code` submodule (shallow clone). crates.io API returned 403 to this client, so registry download counts and publish metadata were not independently verified. CI conclusions rest on the GitHub API (workflow states, run conclusions), not on reading full logs. Star/fork counts are a point-in-time API read. Web search for independent coverage carries the usual recall caveats.

**Open questions that would most change the verdict:** the actual declared-surface parity score today (the policy demands 100% but no scorecard is published); whether the performance matrix ever lands and what it shows; whether the merge ladder gets wired or stays dormant; whether RaptorQ recovery completes end-to-end; whether any enterprise has evaluated the rider's legal exposure; funding and succession intentions given the no-contributions policy; what the rch-based verification actually runs and whether its results are published anywhere.

## The eight deepening questions (one paragraph each)

1. **Provenance.** FrankenSQLite records almost nothing about *who produced* an artifact: WAL frames, pages, and RDB-style snapshots carry data and checksums but no producer attestation, and replication propagates bytes, not lineage — the closest thing to provenance is the MVCC commit pipeline's `commit_seq` (a global `AtomicU64` "commit clock" published to shared memory with `Release` ordering) plus the commit-evidence records the harness keeps [Verified structures exist, High; behavioral claims Maintainer claim, Medium]. Making attestation portable would require hash-chaining commit records, signing them with an operator key, and — per the machine-checked necessity result in arXiv 2606.24322 — binding origin *at write time* so provenance cannot be laundered after the fact; the current commit clock is an ordering device, not a tamper-evident log, so a hostile operator with disk access could rewrite history undetectably [Inference, Medium].

2. **The embeddable unit.** The smallest useful adoptable piece is `fsqlite` (the public facade, 62,113 lines) over `fsqlite-core`, or more surgically `fsqlite-parser` + `fsqlite-vdbe` for SQL execution without the storage stack — all published on crates.io at 0.4.4 [Maintainer claim on publishes, Medium; crate volumes Verified, High]. The adoption cost is steep in practice: the facade drags the asupersync runtime (with its franken-decision/evidence/kernel family), the toolchain is pinned to `nightly-2026-08-31`, the storage path assumes the 293k-line `connection.rs` integration surface, and the license rider follows every derivative — so embedding means vendoring a nightly-only, rider-encumbered, single-maintainer dependency with no LTS story [Verified, High].

3. **Unexercised option value.** The architecture holds at least four unused capabilities: the safe write-merge ladder (intent replay + structured page patches) is implemented and tested but dormant — one wiring decision away from the most interesting same-page concurrency story in the SQLite envelope; the RaptorQ codec pipeline generates repair symbols nobody reads back yet; the vectorized VDBE batch kernels (hash join, sort, aggregation) are a benchmarked library with no live call sites except `MakeRecord`; and the Silo-style epoch group-commit module is an unwired scaffold [Verified, High]. What unlocks them is, respectively, the bd-3d5y3/bd-p4dcv wiring work, the bd-1hi.11 decoder integration, a codegen decision to route hot operators through the batch kernels, and a commit-path redesign — all product decisions, none blocked on research [Inference, Medium].

4. **Benchmark honesty.** There are no maintainer numbers to audit — the README's "No numeric performance result is claimed for current `main`" is the whole story, and it is the strongest benchmark-honesty posture in the program: nothing is load-bearing because nothing is claimed [Verified, High]. What *would* be load-bearing for the thesis if claimed are exactly the numbers the project refuses to publish: single-writer throughput vs C SQLite (target: within 3×), SSI overhead vs plain SI, and concurrent-writer scaling vs core count — all explicitly deferred to the release matrix. The risk is inverted from the usual: the thesis is not resting on bad numbers, it is resting on *no* numbers, which means the concurrent-writer value proposition is currently an architectural argument, not a measured one [Inference, Medium].

5. **The governance path.** The credible route from one maintainer to an institution runs through a 1.0 release plus the parity certification completing: certified 100% declared-surface parity creates the trust artifact that lets a company depend on the engine, and a dependent company is the only plausible source of a second maintainer — but the maintainer has *pre-declined* contributions ("I won't merge them directly"), so the path requires a policy reversal, not just a release [Inference, Medium]. What breaks first if velocity decays is comprehension, then the tree: at this velocity the README already lags the code by an order of magnitude on crate sizes, and a slowdown without a successor strands 1.78M lines — including a 293,644-line `connection.rs` no one else understands — on a pinned dated nightly, with bit-rot setting in within quarters [Inference, High].

6. **The license as strategy.** The rider excludes exactly OpenAI, L.L.C., Anthropic, PBC, their affiliates, and anyone acting for, benefiting, or under the direction of them — and it defines "use" to include benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination and injunctive relief reserved to Jeffrey Emanuel [Verified verbatim, High]. As strategy it is coherent defensively (it prevents the two labs best positioned to absorb the work from doing so without permission) and self-sabotaging offensively: the project's most credible future is evaluated database infrastructure for the agent era, the excluded parties *are* the agent-infrastructure builders and evaluators, and the rider's breadth (even benchmarking is forbidden) chills the independent validation the project most needs — which helps explain why independent validation is zero [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick FrankenSQLite over SQLite or libsql is an agent system doing concurrent multi-agent writes into a single local embedded database — session logs, tool-call journals, shared scratch state — where SQLite's single-writer lock is the actual bottleneck and the workload needs serializable semantics, not just snapshot isolation [Inference, Medium]. The maintainer's own FrankenTerm is the natural first customer (its planning docs describe exactly this integration), but that is maintainer-adjacent, not validation. What would have to become true first: the parity certification completing (an agent store that corrupts data is worse than a slow one), the performance matrix landing (to know the concurrency actually pays), a 1.0 with a stability commitment, and — unavoidably — a license an agent-platform company can sign [Inference, Medium].

8. **The kill test.** The single event that would falsify the core thesis — "page-level MVCC serializable concurrent writers are worth building inside the SQLite envelope" — is a credible demonstration that the concurrency doesn't pay: the release performance matrix showing concurrent-writer throughput at or below serialized SQLite on realistic workloads (lock-table contention, SSI abort rates, and version-chain traversal eating the parallelism), which would leave the project as a slower, larger, single-maintainer SQLite with no reason to exist [Inference, Medium]. The experimental falsifications are nearly as decisive: the 100%-parity certification failing on the declared surface (proving the reimplementation can't hold the format contract it claims), or SQLite/libsql/Limbo shipping their own MVCC story and commoditizing the one unoccupied lane — either collapses the thesis to "interesting research vehicle" [Inference, Medium].

---

**Working notes:** clean shallow clone at `~/workspace/franken-research/frankensqlite-clone/` (HEAD `315bc0f`, 2026-09-22). No durable user-facing files created besides this assessment and its versioned intermediates. crates.io API returned 403 to this client; registry metadata not independently fetched.