01 · What it is
What this site is, and why it matters
frankensqlite.com is the official marketing and documentation website for FrankenSQLite, the Rust clean-room SQLite reimplementation. It is a Next.js 16 and React site in TypeScript: five routes, 28,784 lines of first-party code, and an ambitious docs-as-demo approach. There are 36 interactive visualization components: animated MVCC races, WAL lanes, RaptorQ healing diagrams, a B-tree explorer. Plus a 47-term jargon glossary, a 14-tool "Agent Flywheel" showcase, and per-route share images.
Its standout artifact is the spec-evolution viewer: a real 2.6 MB SQLite database holding the engine's 137-revision specification history, loaded in the visitor's browser via WebAssembly, with a custom diff engine that reconstructs how the spec changed patch by patch. It is browsable spec archaeology, and nothing else in this research program has anything like it.
It matters as a case study in a specific failure mode. The site is live, serving, and well-crafted. It is also, claim by claim, less honest than the engine's own README. The gap is directional. Every stale claim flatters the engine. This brief is about how that happens and what it costs.
02 · Why build it
Why build it this way?
The maintainer's stated problem: database project sites either explain internals poorly or treat docs as an afterthought. A from-scratch engine making novel claims about concurrency and durability needs a surface that can demonstrate behavior, not just assert it. Hence the visualizations, the interactive demos, the browser-based spec lab. Docs as demo rather than docs as brochure is a reasonable thesis, and the craft here is real: deferred loading with skeletons, accessibility passes on the visualizations, 158 tests across unit and end-to-end suites.
The counter-argument, which the site never quite confronts: a marketing site is also a claim surface, and this one holds its engine to a lower evidence standard than the engine holds itself. The engine's README disavows its own benchmarks, labels its headline features aspirational, documents its own encryption foot-gun, and requires every numeric claim to name its artifact. The site's copy systematically un-hedges all of it. Demonstration is the site's stated purpose; assertion is where it fails.
03 · What was built
What the project actually built
As a frontend artifact, the site is well above the "thrown-together project site" bar. The visualization suite is the bulk of the codebase. The spec-evolution viewer is a novel piece of work: a real, integrity-hashed 137-revision database reconstructed in-browser with its own tested patch engine. And there is real marketing candor in places. The comparison table grades its own product "Production Maturity: Early" against C SQLite's "20+ years," marks FrankenSQLite's analytical queries "Basic" against DuckDB's first-class support, and the FAQ says the engine is "under active development" and should be "evaluated carefully for production workloads." Most marketing sites do not publish their own losing rows.
Evidence · CI status
What the project’s own CI said at the pin
the pin = the commit the assessment was pinned to.
- !There is no CI (continuous integration: automated checks that run on every change), though the README lists pre-push checks.
The uncomfortable findings
Uncomfortable finding
The site's hero stats describe a "26-crate workspace" with "0 unsafe blocks — pure safe Rust throughout." The engine has 28 crates and 41 counted unsafe blocks. The engine's actual posture is good and accurately documented in its own README: unsafe is confined to the memory-mapping I/O layer and the C foreign-function boundary. The site chose the absolute version, which is the version that is wrong. The stale crate count appears in 14 files across the site, including the share images, which bake "26 crates" and "zero" into pixels.
Uncomfortable finding
Two flagship features are marketed as shipped while the engine README says they are "not yet reachable from the public API": self-healing storage ("No external backups needed") and page-level encryption, complete with copy-paste code examples. Three identifiers in the site's tutorials (fsqlite_current_csn(), PRAGMA fsqlite.key, PRAGMA fsqlite.repair_ratio) have zero occurrences anywhere in the engine. The flagship examples cannot run as written. The changelog's "up to 8x throughput improvement" descends from a benchmark family the engine's own methodology doc says not to cite for speed claims, and the site cites no artifact at all.
Uncomfortable finding
The sharpest detail: the drift is enforced by the site's own tests. The unit test suite asserts the 26-crate count, so correcting the stale claim to 28 would fail the website's own build. The drift is not just undocumented; it is load-bearing.
Uncomfortable finding
The governance around the site is thin. There is no LICENSE file. Default copyright applies, which means no license grant at all: a more restrictive posture than the engine's already-restrictive license. The changelog documents 17 of 29 commits; the 12-commit refresh that modernized the whole site is undocumented in it. Four stars, one maintainer, zero open issues.
04 · Where it stands
Where it stands
In our program's terms: NODUS ring Monitor. The rulebook is explicit that Monitor is the ring for websites, and a website does not become Pilot by being well-built. TRL 8 for the site as a website: it is live at frankensqlite.com, all five routes serving. source
Technology readiness
TRL 8 on a 1-to-9 scale.
NODUS ring
MonitorExplorePilotInvest
The program’s adoption ring for this project.
Verdict key
- NODUS ring
- Monitor: Websites, retired artifacts, and plan-stage work.
- TRL
- Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 8.
- CI
- Continuous integration: the project’s automated checks, run on every change.
- The pin
- The exact commit the assessment was pinned to. “At the pin” means as of that commit.
Evidence tiers
- Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
- Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
- Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
- Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
- Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.
What this verdict rests on. Tier labels are the assessment packet’s own annotations.
- Tier 1 · Verified: Live production website: all five routes HTTP 200.
- Tier 3 · Maintainer claim: The site was never built; the 158 counted tests are call sites, not results; the spec viewer was never run in a browser.
- Tier 5 · Inference: The Monitor ring at TRL 8: the program’s website bucket.
Should you use it?
As a demo gallery, yes.
The visualizations and the spec viewer are worth your time. As a source of facts about the engine, no. Cite the engine's README instead; it is the more accurate document, and it is current.
Should you learn from it?
Yes, in two specific ways.
The content model (every marketing claim living in one typed file) made the entire drift audit a single-file read; marketing claims should be this greppable. And the spec-evolution viewer is an exportable component: a second project's spec rendering in it unmodified would move it from experiment to tool.
What would change the verdict, in order
- the site's engine-facing claims generated from the engine itself at each release (crate count, unsafe posture, feature flags) so that adding a crate breaks the website build instead of relying on a human's memory
- A LICENSE file
- CI that runs the 158 tests
- The engine shipping the two features the site already claims
05 · What it teaches
What this teaches about building with agents
The transferable lesson is about claim sync, and the commit history tells it in miniature.
The site was built in a burst of 17 commits in early 2026, then sat untouched for six months, then got 12 commits on a single day in September 2026. During the silent six months, the engine gained two crates and kept its daily commit velocity. Nobody was watching the site. Hand-written marketing copy plus burst maintenance is a drift machine: the gap between the claims and the code compounds every month the copy is not regenerated, and every stale claim flatters the product, because nobody hand-writes copy that makes their project look worse.
The fix the assessment proposes is structural, not editorial. The engine already maintains machine-readable contracts: a version contract, a supported-surface matrix, a parity-score contract. The site should generate its engine facts from those at a recorded engine pin, the way API docs are generated from code. Generated claims cannot drift; hand-written claims always do. Any document about the code that is not generated from the code will be wrong within months. So generate it, or stop promising it. That rule applies far beyond marketing sites: it is the same rule that governs every README in every agent-assisted repository. source source