# FrankenRedis — RULEBOOK v1.0 Assessment Packet v6 **Repository:** `Dicklesworthstone/frankenredis` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `f78f64e4eea5d0ae7848d917e40aafaef1d60ce6` (2026-09-22 02:22:53 +0000, [Git-observed, High]) · **Last push:** 2026-09-22 (pin date; the pin is the latest push confirmed in this assessment) [Git-observed, High] · **Scope:** the pinned commit only, not HEAD. No tag points at the pin; annotated tag `v0.1.0` (created 2026-09-11) points at an earlier commit `c577c0ae` [Git-observed, High]; GitHub Release `v0.1.0` (published 2026-09-12, not draft/prerelease, 24 signed binary assets) targets that earlier tag commit — no release artifact for the assessed commit [External, High]. *Cold-reader note: "v2"/"v3"/"v4" below = earlier drafts of this packet (rewrite-loop rounds 2–4).* **Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/frankenredis-verify` (135,078 paths, verified non-empty); history deepened (blobless) to 449 commits for the authorship sample only — the working tree stayed at the pin. Read: root `Cargo.toml`, all 16 crate manifests, `Cargo.lock`, `LICENSE` (verbatim), README (disavowal, drift, sentinel/TLS sections), `CHANGELOG.md`, `.beads/issues.jsonl`, `docs/BENCH_METHODOLOGY.md` (digest), the grisu2 commit page (round 2). Counted: `.rs` files/lines, unsafe gates/sites (comment-excluding method), fuzz corpus, `argv` probes, `NEGATIVE_EVIDENCE.md` lines, workspace dependencies, agent co-authorship trailers. **Not done:** the workspace was never compiled, the server never executed, no test suite was run, no benchmark was reproduced. **v5 round re-verifications (2026-09-22):** per-job CI conclusions via the Actions REST `runs/{run_id}/jobs` endpoint for run #7679 (conformance gates, head = pin) and run #284 (Tcl lane, head = pin) — greenness at the pin is now *established* (red on both lanes), replacing the v4 "unestablished"; GitHub Releases re-fetched (v0.1.0 release found); fsync call sites read in `fr-persist`/`fr-runtime`; web demand-signal search (Valkey adoption data; independent coverage of FrankenRedis). Assessment date: 2026-09-22. **Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — with 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** (multiple converging sources or direct inspection) / **Medium** (single solid source, plausible) / **Low** (thin evidence, extrapolation). --- ## Hook A 542,716-line [Counted, High], single-maintainer, clean-room Redis rewrite in Rust that claims — with proof bundles on its optimization PRs to back the claim — that it is faster than Redis 7.2.4 on its chosen benchmarks [Maintainer claim, Medium], has no unsafe code outside exactly 61 counted sites [Counted, High], and ships a documented threat model (8 `ThreatClass` variants, a persisted ledger) — a hardening posture its parent project never published [Code-verified, High on existence; the Redis comparison is Inference, Medium]. The catch is threefold: its headline benchmarks carry a maintainer-written disavowal [Maintainer claim, High], its license names OpenAI and Anthropic as forbidden parties [Code-verified (license text), High], and its five-phase event loop is a planning library whose hot-path footprint is three validators plus a poll-timeout computation — the executed loop is a hand-written mio poll/dispatch loop [Maintainer claim, High]. The sharpest irony is saved for §4.8: the pinned commit itself was co-authored by an Anthropic model — a named Restricted Party under the rider. --- ## TL;DR - **What it is:** A from-scratch Rust reimplementation of Redis (~543k first-party lines / 377 files across 16 crates at the pin [Counted, High]), chasing byte-exact wire parity with Redis 7.2.4, not a fork. Single human maintainer (Jeffrey Emanuel) plus agent personas, under active development: CI run #7679 executed against the pinned commit itself [CI-observed, High]. - **Strongest evidence:** A 26,485-line negative-evidence log (every benchmark loss recorded with a verdict and artifact), a 499 MB / 127,571-file fuzz corpus, 5,041 counted differential probes against a vendored Redis 7.2.4 oracle, CI executing the full upstream Tcl suite (284 runs observed 2026-09-22) [all Counted/CI-observed, High], and unsafe code contained to 61 independently re-counted sites [Counted, High]. Self-scrutiny infrastructure is the best in the FrankenSuite. - **Strongest doubts:** The headline benchmark table is explicitly disavowed by its own README ("should be read as a contention-sandbox measurement, not a release claim" until a deferred re-baseline bead — *bead*: the repo's issue-tracker unit — runs) [Maintainer claim, High]; the license rider bars OpenAI/Anthropic and anyone acting for them from using, benchmarking, or even analyzing the code — killing any AI-company use case and possibly discouraging contributors [Inference, Medium]; there is one human maintainer and no bus factor; CI is red at the pin — conformance run #7679 failed at the `cargo fmt` gate (all substantive gates skipped) and the Tcl lane's scheduled run #284 failed at the verdict-verification step, both established 2026-09-22 via the Actions API [CI-observed, High]; cluster remains absent by explicit scope exclusion [Maintainer claim, High]; TLS transport is absent by decided scope exclusion (README L1662; bead `xzdbc`, closed WONTFIX 2026-05-25) [Maintainer claim, High]. - **NODUS ring: Explore** [Inference, Medium] (TRL 4–5 — see §4.9). Substantive-but-unproven is the textbook Explore case; the rider is an advancement blocker (Explore-with-a-ceiling), not a ring qualifier. The engineering rigor (adversarial self-audit, differential parity, proof-bundle culture) is worth tracking as a *methodology* exemplar for the FrankenSuite; the software itself is currently un-advanceable while the rider stands. --- ## Quick Links Pin-relative links (`blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6`); verified resolving 2026-09-22 [Verified, Medium]. **Re-verified in the v5 round (2026-09-22):** run counts refreshed via the Actions API — 7,679 live-conformance-gate runs (run #7679 against the pin, concluded failure at the G1 formatting gate) and 284 full-Tcl runs (scheduled run #284 against the pin, concluded failure at the verdict-verification step); stars 27 / forks 6 confirmed. Per-job conclusions are now established — see claims 6–7: 1. [Repository](https://github.com/Dicklesworthstone/frankenredis) 2. [README](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/README.md) 3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/LICENSE) 4. [Negative-evidence log](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/docs/NEGATIVE_EVIDENCE.md) — 26,485 lines at the pin 5. [Upgrade log](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/docs/planning/UPGRADE_LOG.md) 6. [Changelog](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/CHANGELOG.md) 7. [Benchmark methodology](https://github.com/Dicklesworthstone/frankenredis/blob/f78f64e4eea5d0ae7848d917e40aafaef1d60ce6/docs/BENCH_METHODOLOGY.md) 8. [Live conformance-gates CI](https://github.com/Dicklesworthstone/frankenredis/actions/workflows/live-conformance-gates.yml) — 7,679 runs; run #7679 against the pinned commit (red: G1 formatting gate) 9. [Full upstream Tcl CI](https://github.com/Dicklesworthstone/frankenredis/actions/workflows/upstream-redis-7.2.4-full.yml) — 284 runs observed 2026-09-22 (scheduled run #284 against the pin, verdict step failed) 10. [Grisu2/Ryū divergence commit](https://github.com/Dicklesworthstone/frankenredis/commit/39f166acb137d6e20c1a1ee80c5a5e7ce754b56a) — Co-Authored-By: Claude Opus 4.8 --- ## Did You Know The float-formatting story is the project in miniature. Redis's `%.17g` float rendering was replaced not with Rust's `ryu` crate but with a hand-rolled Grisu2 implementation — because the maintainer measured ryu/Grisu2 diverging on 0.2–0.3% of f64 values, and byte-exact parity is the whole point. The fix commit (`39f166a`, Co-Authored-By: Claude Opus 4.8) reports "0 divergences across 105k+ random f64 bit patterns × 7 seeds," and the commit page is itself a mini-paper: hypothesis, reproduction of the divergence class, fix, verification matrix. [Maintainer claim, Medium; commit independently verified to exist with that message.] The irony the packet returns to in §4.8: the co-author is an Anthropic model — and Anthropic is a named Restricted Party under the project's own license rider [Inference, High]. --- ## Franken-worthy next steps 1. **Import the negative-evidence pattern into the FrankenSuite's own QA:** require every repository assessment (and every performance claim we publish) to keep a `NEGATIVE_EVIDENCE.md`-style ledger of losses with verdicts and artifacts. FrankenRedis is the exemplar. *Done when:* the requirement is written into the program's assessment protocol with a named owner. [Inference, High — process proposal] 2. **Copy the proof-bundle discipline:** optimization PRs that ship with a SHA-pinned golden RESP transcript, paired/reversed hyperfine runs, and a keep/reject score gate (their `artifacts/optimization/*/PROOF.md`) are a stronger standard than generic "benchmark better" guidance. *Done when:* the PROOF.md schema is extracted and adopted as the program's optimization-evidence template. [Inference, High] 3. **Treat the license rider as a supply-chain screen:** any FrankenSuite dependency candidate with a named-party restriction fails intake automatically — write that rule down now, because FrankenRedis is the case that forces it. *Done when:* the intake rule is committed to the program's dependency policy. [Inference, High] 4. **Re-establish CI greenness after the formatting gate goes green at a new pin:** the v5 round fired the original done-when (per-job conclusions fetched via the Actions REST API on 2026-09-22 — run #7679 failed at the G1 `cargo fmt` gate with all substantive gates skipped; scheduled run #284 executed the Tcl suite but the verdict-verification step failed). *Done when:* per-job conclusions go green at a new pin, or the fmt gate passes and the substantive gates actually execute. [Inference, High] --- ## 4.1 Why it exists — the market problem **The problem, as the maintainer frames it:** Redis is C; C has memory-safety bugs; Redis's threading story is single-threaded-event-loop plus an increasingly complex module ecosystem; and the 2024–2025 license turbulence (Redis's move off BSD to SSPL/RSALv2 in March 2024, the Valkey fork, then Redis 8.0's AGPLv3 option in May 2025) left the "open Redis" lane fractured [External, High on the license history]. The maintainer's stated bet is that a clean-room Rust rewrite can deliver: memory safety without a GC, deterministic tail latency, and byte-exact compatibility with Redis 7.2.4 — the last BSD-licensed Redis — as a drop-in replacement [Maintainer claim, Medium]. **Who feels the pain:** anyone running Redis at scale who has been bitten by a memory-safety CVE, or who wants the BSD-licensed Redis 7.2.4 lineage to keep evolving without touching SSPL/RSAL-licensed code [Inference, Medium]. **Why now:** the Rust ecosystem (io_uring, SIMD intrinsics, `mimalloc`) is mature enough to attempt C-parity performance, and the license schism created a window where "a truly open Redis-compatible server" is a legible pitch [Inference, Medium]. Whether that window is real demand or maintainer narrative is unproven — there are no production users, no release artifact for the assessed commit (v0.1.0's signed release targets an earlier commit — claim 14), and zero independent coverage [External, High within recall caveats]. Note the tension the packet holds deliberately: §4.6's own Valkey facts (Linux Foundation governance, 700+ contributors, AWS ElastiCache default) suggest the "open Redis" window may already be closed — the maintainer has never publicly reconciled the pitch with Valkey's occupancy of the lane [Inference, Medium]. **Demand-side check (v5 round, 2026-09-22):** the "open Redis" window is real demand — and it is being filled by Valkey, not waiting for FrankenRedis. Industry survey data (Percona's September-2024 survey, cited in later reporting) puts ~75% of Redis users as testing, considering, or having already adopted Valkey as of mid-2024, with 83% of large enterprises having begun the transition or actively evaluating it [External, Medium — figures from Percona's survey, published in its press release "Valkey Emerges as Leading Open Source Alternative to Redis After Relicensing Row"; methodology not independently verified]. The managed-service layer has moved: AWS ElastiCache for Valkey went GA in October 2024, Google Cloud Memorystore and Oracle OCI Cache ship Valkey as a first-class option, and Valkey's own 2025 year-end review reports 346 active contributors over the year [External, High on the managed-service facts; Medium on the contributor count]. The window the maintainer's pitch assumes is therefore not hypothetical — it is occupied: the demand exists and Valkey is capturing it, which makes the maintainer's non-reconciliation a load-bearing silence rather than a footnote [Inference, Medium]. A web search for independent coverage of FrankenRedis itself (production users, third-party reviews, downstream forks) returned nothing beyond the repository on 2026-09-22 [External, High within recall caveats]. **Why a rewrite, not a fork:** stated explicitly in the README's "Why a rewrite of Redis, and why not a fork" section — a fork inherits C's memory-safety exposure and the upstream's architectural debts; only a clean room lets the maintainer re-derive every data structure with proofs of byte-exactness [Maintainer claim, Medium]. Whether the "clean room" label survives the agent-authorship finding in §4.8 is an open question — see there. **Adjacent context:** this is one entry in a larger solo-maintainer program — the "FrankenSuite" of clean-room Rust reimplementations. The upgrade log records asupersync as evaluated and rejected as an architectural rewrite on 2026-04-21/22 [Maintainer claim, Medium]; the README (L1660) adds that "the trait stubs in fr-runtime are empty," and asupersync is absent from `Cargo.lock` [Code-verified, High] — the rejection is corroborated by two primary sources, not just the log. The program's thesis appears to be that foundational C infrastructure can be re-derived in Rust with machine-checked parity; FrankenRedis is its flagship. ## 4.2 What it is — repo TL;DR A 16-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing a Redis 7.2.4-compatible server in Rust: RESP2/RESP3 protocol, a hand-rolled Lua 5.1 engine (31,799 lines in one file [Counted, High]), RDB/AOF persistence, replication, and a Sentinel implementation with failover — plus hardening features Redis lacks (a runtime threat ledger, hardened mode, RaptorQ forward-error-correction sidecars for RDB). Development velocity is extreme: 8,115 non-merge commits from 2026-02-13 through 2026-08-19 (~43/day) [Maintainer claim, Medium — the window is the August changelog's; pin-currency of the total was not re-derived]; the deepened local history shows 449 commits in the 2026-08-26 → pin window (~16/day) [Git-observed, High]. The honest comparison: the in-window rate is roughly a third of the changelog-period rate — a greater-than-half deceleration (the 449-window count may include merges, so the true non-merge rate is lower still), though ~16/day remains a high absolute cadence [Git-observed, High on the counts; the deceleration is arithmetic, not inference]. One-line verdict: **the most rigorously self-audited codebase assessed in this program to date [Inference, Medium — the in-packet evidence base is the 26,485-line negative-evidence ledger, SHA-pinned proof bundles per optimization PR, 5,041 differential probes, and the independently re-counted 61-site unsafe census; "most" is a comparative judgment over the packets completed so far, not a measured ranking], making production-grade claims it simultaneously disavows, under a license that forbids the most likely evaluators from touching it.** (NODUS: Explore — see §4.9.) ## 4.3 Repo facts (claim inventory) Every claim below was re-verified against the pinned commit on 2026-09-22. Tier flavors: Counted (I ran the count), Git-observed (git metadata), Code-verified (read the source), CI-observed (seen executing on CI pages — attests the suite *runs*, not that it is green), Maintainer claim (README/CHANGELOG/docs), External (third party). **Status** is the Rulebook's required audit verdict per claim. | # | Claim | Status | Evidence | Tier, Confidence | |---|-------|--------|----------|------------------| | 1 | 16 workspace crates, ~542,716 first-party Rust lines / 377 files | demonstrated | Fresh clone, `git rev-parse` = pin; `Cargo.toml` members enumerated; line count over `crates/` | [Counted, High] | | 2 | Unsafe gates: 12 crates `forbid(unsafe_code)`, 2 `deny(unsafe_code)` (fr-command, fr-runtime), 2 with no crate-root gate (fr-simd, fr-uring). 12+2+2 = 16 | demonstrated | Anchored `#![…]`-attribute scan excluding doc comments; fr-eventloop is the 16th crate and is forbid-gated | [Counted, High] | | 3 | Exactly 61 unsafe sites: 46 fr-simd + 5 fr-uring + 7 fr-command + 3 fr-runtime | demonstrated | Independent recount excluding deny-lint lines and comments; matches the README census table exactly | [Counted, High] | | 4 | 33 fuzz targets / 11,015 lines; corpus 127,571 files, 499 MB total, 127,559 nonzero | demonstrated | `find fuzz/corpus -type f \| wc -l`; `du -sb` | [Counted, High] | | 5 | 5,041 counted `argv` differential probes in fr-conformance | demonstrated (the README's 5,076 figure is stale) | `rg -c '"argv"'` over `crates/fr-conformance/` at the pin — exactly reproducible there; whole-tree gives 5,047 (six stray `"argv"` hits in `scripts/` and two server crates), so the 5,041 figure is the conformance-fixture count, not a whole-tree count. README L1332 dates its 5,076 count "counted from the JSON on disk at 2026-09-02" — the delta is a stale dated count, not a mystery | [Counted, High] | | 6 | Full upstream Redis 7.2.4 Tcl suite runs in CI (284 runs observed) | partially demonstrated | `upstream-redis-7.2.4-full.yml`, 284 runs observed. **Greenness at the pin: RED (established 2026-09-22 via the Actions REST `runs/{run_id}/jobs` endpoint, v5 round)** — scheduled run #284 (head = pin) executed the suite (~21 min) but the "Verify complete upstream suite verdict" step failed | [CI-observed, High] | | 7 | 7,679 live-conformance-gate runs; run #7679 executed against the pinned commit f78f64e | partially demonstrated | Workflow runs page + Actions API, 2026-09-22; #7679 confirmed against the pin. **Greenness at the pin: RED (established 2026-09-22, v5 round)** — run #7679 concluded failure at the G1 formatting gate (`cargo fmt`); all substantive gates G2–G7 were skipped, so the pin's gates were formatting-blocked, never executed | [CI-observed, High] | | 8 | Headline benchmarks: SET 1.333x, TTL SET 1.463x, INCR 1.255x, GET 1.029x vs Redis 7.2.4; XADD ~1.7x | aspirational (the pipelined table is explicitly disavowed pending re-baseline; whether the disavowal covers the XADD rows is ambiguous) | README `## Performance` table (pinned lines ~108–182): the pipelined table itself has no per-row CI column — per-row bootstrap 95% median CIs are published only for the adjacent XADD sub-table ([1.651, 1.770]; [1.727, 1.755]). See claim 9 for the disavowal and its scope ambiguity | [Maintainer claim, Medium] | | 9 | Those benchmarks are disavowed pending a deferred re-baseline bead (`vibu6`) | demonstrated | README verbatim: "should be read as a contention-sandbox measurement, not a release claim" | [Maintainer claim, High] | | 10 | Threat model: 8 `ThreatClass` variants; JSON-lines ledger flushed to disk; hardened mode | demonstrated (existence; behavior not executed) | `ThreatClass` enum counted in code; `flush_threat_ledger` call site in fr-server main loop; `fr_threat_ledger_v1` format | [Code-verified, High] | | 11 | Sentinel failover wired Sept 2–3 2026 (was O_DOWN-detection only) | demonstrated | CHANGELOG "Unreleased 2026-08-20..2026-09-03"; `failover_step` drives 7-variant `FailoverState` (incl. `None`) | [Maintainer claim + Code-verified, High] | | 12 | RaptorQ FEC: 434-line fr-fec crate, real `raptorq 1.8.1` dependency (locked in Cargo.lock), envelope implementation; README still says "planned (not implemented)" | demonstrated (code); the README line is stale | `Cargo.lock` + `fr-fec/src/lib.rs` read; CI shows RaptorQ wiring commits `5538901`/`32dfac4` and gate expansion `6b5f37a`. (v2 said "3.1.4" — wrong; the lockfile says 1.8.1.) | [Code-verified + CI-observed, High] | | 13 | NEGATIVE_EVIDENCE.md: 26,485 lines of recorded losses with verdicts | demonstrated | `wc -l` at pin | [Counted, High] | | 14 | Single human maintainer; version 0.1.0; no release artifact at the pin | demonstrated (with tag/release nuances) | GitHub API: 27 stars, 6 forks; `git for-each-ref`: tag `v0.1.0` (created 2026-09-11) points at an earlier commit `c577c0ae`, **not** the pin — nothing tags the assessed commit. **GitHub Releases re-fetched 2026-09-22 (v5 round): one release, `v0.1.0` (published 2026-09-12, not draft/prerelease), shipping 24 signed binary assets (aarch64/x86_64 × apple-darwin/linux-gnu tarballs, `.sha256` + `.minisig`, SHA256SUMS, manifest) — but it targets the earlier tag commit, so there is still no release artifact for the assessed commit** | [External, High] on stars/forks/release; [Git-observed, High] on the tag | | 15 | License rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use incl. benchmarking/training/analyzing; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] | | 16 | Sentinel peer-vote exchange is CLOSED (2026-09-03); quorum-2 e2e test exists; README claims it works | demonstrated (closure + test existence); test greenness at pin unestablished | `.beads/issues.jsonl`: `frankenredis-rc-sentinel-peer-votes-0evu4` closed 2026-09-03T05:17Z; `three_fr_sentinels_with_quorum_two_agree_elect_and_fail_over` in `crates/fr-server/tests/tcp_e2e_test.rs`; README Sentinel row claims quorum-2 failover works. v2's "remains open" trusted a stale CHANGELOG line over the beads DB — CHANGELOG-vs-beads drift the packet's own §4.7 framework should have caught | [Git-observed + Code-verified, High] | | 17 | TLS: config is parsed (`tls_port`, `parse_tls_bool` in fr-config), transport is absent (zero rustls/native-tls in Cargo.lock) — **and the absence is a decided scope exclusion, not a deferred feature** | demonstrated | `crates/fr-config/src/lib.rs` lines ~734–787, ~992, ~1110; `Cargo.lock` grep. README L1662 at the pin: "Wire-level TLS is not on this list on purpose: it was decided as a scope exclusion (bead `xzdbc`, closed WONTFIX on 2026-05-25) and stays delegated to the operational layer, as the Limitations section says." Bead `frankenredis-xzdbc`: closed 2026-05-25T05:13:37Z, close_reason `WONTFIX: Deliberate scope decision - TLS is transport-layer, not Redis protocol parity. Documented in README. Use stunnel/spiped/load-balancer for termination.` | [Code-verified, High] on state; [Maintainer claim, High] on the exclusion | | 18 | Agent co-authorship: 162 of the 449 most recent commits (36%) carry agent Co-Authored-By trailers — 158 Claude-family (@noreply@anthropic.com), 4 Grok (@noreply@x.ai); the pinned commit itself is Co-Authored-By: Claude | demonstrated (trailer counts in the deepened window); line-level share not measured | [Git-observed, High] on the counts; the clean-room implication is [Inference, Medium] — see §4.8 | **What the inventory says in aggregate:** claims about *process* (fuzzing, differential testing, CI execution, unsafe containment) verify at High confidence; claims about *outcomes* (faster than Redis, production-ready) are either disavowed by the maintainer or untestable by third parties. Two claims that v2 reported as results (6, 7) are downgraded to *partially demonstrated* because greenness was never established — and the v5 round now establishes it as **red at the pin** (conformance formatting-blocked, Tcl verdict-failed), which hardens §4.7.3 rather than blunting it. Run counts are not results. ## 4.4 Codebase tour **Workspace topology (16 members, [Counted, High]):** `fr-bench`, `fr-eventloop`, `fr-protocol`, `fr-command`, `fr-simd`, `fr-store`, `fr-expire`, `fr-persist`, `fr-repl`, `fr-config`, `fr-conformance`, `fr-runtime`, `fr-sentinel`, `fr-server`, `fr-fec`, `fr-uring`. **Dependency posture (the 30-second survey the Rulebook demands):** 20 external crates in the union over the 16 workspace manifests plus `fuzz/Cargo.toml` — arbitrary, criterion, foldhash, hdrhistogram, hex, icu_collator, icu_locale_core, indexmap, io-uring, libc, libfuzzer-sys, memchr, mimalloc, mio, proptest, raptorq, serde, serde_json, sha2, tikv-jemallocator [Counted, High on the union; the "declared across the workspace" framing is loose — `fuzz/` is its own `[workspace]`, not a member, and `memchr` is workspace-declared but unused]. Two notes: `memchr` is declared in `[workspace.dependencies]` but referenced by no crate and used in no source — workspace-dep drift [Code-verified, High]; and there is **no tokio** (confirms the sync-mio design), **no rustls/native-tls** (confirms claim 17's transport-absent), and **no asupersync** — the upgrade-log rejection is corroborated by the lockfile [Code-verified, High]. **Data flow, end to end:** - **Ingress — `fr-uring` (io_uring reactor) → `fr-eventloop` → `fr-server`:** the io_uring crate owns the syscall surface (5 unsafe sites, [Counted, High]). `fr-eventloop` (1,253 lines [Counted, High], `#![forbid(unsafe_code)]`) is the corrected story: it defines a five-phase model (`BeforeSleep → Poll → FileDispatch → TimeDispatch → AfterSleep`) chiefly as a *planning/validator library*. Per the README's own admission (L484 at the pin), the binary's event loop executes three things on the hot path — `validate_read_path` on every client read, `validate_accept_path` on every accept, and the active-expire cycle planner `plan_active_expire_cycle` (through `fr-runtime`) — and calls `plan_tick(0, 0, …)` only to obtain a poll timeout, because feeding the model the real counts was measured to add a per-iteration cost the server could not afford (bead `frankenredis-zw36c`). The "five-phase event loop" is therefore a design document with a test harness, not the executed loop — the README says so itself [Maintainer claim, High]. - **Protocol — `fr-protocol`:** RESP2/RESP3 parsing with explicit `max_bulk_len` / `max_array_len` / `max_recursion_depth` limits (DoS-hardening Redis's parser lacks), SIMD-accelerated scanning via `fr-simd` [Code-verified, High]. - **Dispatch — `fr-server` (58,857-line main.rs [Counted, High]) → `fr-runtime` → `fr-command` (88,545-line lib.rs [Counted, High]):** a front-classified dispatch floor (CHANGELOG Phase 15) skips generic argv parsing for hot commands; borrowed fast paths avoid re-deriving write gates the server already caches. `fr-command` and `fr-runtime` are the two `deny(unsafe_code)` crates — 7 and 3 unsafe sites respectively, each documented [Counted, High]. (The 58,857-line single-file `main.rs` is an extraordinary reviewability fact in its own right — see §4.7.) - **Storage — `fr-store` (86,243-line lib.rs [Counted, High]):** the heart. Redis data structures re-derived: intset/listpack/ziplist-compatible encodings, quicklist2 rebuilt from precomputed node totals, `BTreeMap`-backed zset ordering (code comments explicitly discuss the tradeoff vs Redis's skiplist rank-diff), positional SCAN cursors that survive `HDEL`/`SREM` reordering of the backing `IndexMap`/`IndexSet` [Code-verified, Medium — comments and cursor code read; behavior not executed], arena-packed small keys. The single largest design delta from Redis: everything is safe Rust except the 61 counted unsafe sites [Inference, Medium — an architectural judgment, not a counted claim]. - **Expiry — `fr-expire`:** active-expiry cycle planning (the `plan_active_expire_cycle` validator consumed from fr-eventloop) [Code-verified, High]. - **Persistence — `fr-persist` (14,300-line lib.rs [Counted, High]):** RDB encode/decode with type tags verified in code (`RDB_TYPE_SET_INTSET=11`, `RDB_TYPE_HASH_LISTPACK=16`, …), multi-part AOF (`appendonlydir`) load/write, and — the new arrival — optional RaptorQ sidecar files with corruption auto-healing (wired through fr-runtime; conformance gate expanded to all durability targets in CI commit `6b5f37a`) [Code-verified + CI-observed, High]. - **Replication — `fr-repl`; Sentinel — `fr-sentinel`:** Sentinel failover was rewired Sept 2–3: `failover_step` drives the 7-variant `FailoverState` (`None`, `WaitStart`, `SelectSlave`, `SendSlaveofNoone`, `WaitPromotion`, `ReconfSlaves`, `UpdateConfig` — [Code-verified, High]); end-to-end tests kill a primary and watch promotion unaided. Multi-sentinel quorum vote exchange is **closed** (bead `frankenredis-rc-sentinel-peer-votes-0evu4`, 2026-09-03) with a dedicated quorum-2 e2e test and README attestation — v2's "remains open" is corrected in claim 16. - **Scripting — inside `fr-command`:** `lua_eval.rs` (31,799 lines [Counted, High]) is a hand-rolled Lua 5.1 parser + bytecode VM, not mlua — because byte-exact parity with Redis 7.2.4's *modified* Lua 5.1 (53/54 cjson/API rows byte-exact, the `cjson` key-order diff WONTFIX — *WONTFIX: the maintainer's explicit won't-fix verdict* [Maintainer claim, Medium]) can't be delegated to an off-the-shelf interpreter. - **Conformance — `fr-conformance` (13,982-line lib.rs + 157 fixture-dir entries [Counted, High]):** differential probes against a vendored Redis 7.2.4 oracle; 5,041 counted `argv` cases (README says 5,076 — a stale 2026-09-02 count, claim 5). - **Bench — `fr-bench`:** the harness behind the disavowed numbers. **Unsafe arithmetic, stated explicitly:** 12 crates `forbid(unsafe_code)` + 2 `deny(unsafe_code)` (fr-command, fr-runtime) + 2 with no crate-root gate (fr-simd, fr-uring) = **16**. The 61 sites break down 46/5/7/3 across fr-simd/fr-uring/fr-command/fr-runtime — an independent recount at the pin reproduces the README's census exactly, so the census table is **not** drift. Two hygiene notes the README's "11 of 15 crates" line gets wrong: it predates fr-eventloop and fr-fec joining the workspace. And fr-simd, while ungated at the crate root, carries `#![deny(unsafe_op_in_unsafe_fn)]` and `#![deny(clippy::undocumented_unsafe_blocks)]` — the strictest unsafe *hygiene* in the tree even though its gate is weaker than `forbid` [Inference, Medium]. ## 4.5 The maintainer's stated case **The pitch, in the maintainer's own structure:** 1. **Parity as proof:** byte-exact wire compatibility with Redis 7.2.4, verified by ~5,041 differential probes, the full upstream Tcl suite in CI (284 runs), and a `parity_suite.py` at 175/179 at the Sept 2 reality check [Maintainer claim, Medium — the parity_suite figure is dated 2026-09-02; currency at the pin unaddressed]. 2. **Performance:** the README `## Performance` section (pinned ~L108–182) reports pipelined (pipeline depth 16) medians of per-round ratios: TTL SET 1.463x, SET 1.333x, INCR 1.255x, GET 1.029x vs Redis 7.2.4 — the pipelined table has no per-row CI column; the adjacent XADD sub-table (its own header, pinned L141–146) reports MAXLEN~ 1.668x (bootstrap 95% median CI [1.651, 1.770]) and LIMIT 100 1.733x ([1.727, 1.755]); plus a "Where FrankenRedis is behind Redis 7.2.4" losses table [Maintainer claim, Medium]. `docs/BENCH_METHODOLOGY.md` documents the bench discipline behind them — same host, verified-idle cores, A/A nulls 0.979–0.999, core pinning, ELF SHA-256 pinning [Maintainer claim, Medium] — the method the disavowal says still needs a quiet-host re-run. 3. **Safety:** memory safety via the 61-site unsafe census and 12+2 gate posture above [Counted, High for the census itself]. 4. **Rigor artifacts:** every optimization ships with a SHA-pinned golden RESP transcript and paired/reversed hyperfine runs under a keep/reject score gate (`artifacts/optimization/*/PROOF.md`); losses are ledgered in NEGATIVE_EVIDENCE.md [Maintainer claim, Medium; artifacts verified to exist]. 5. **Hardening beyond Redis:** threat model with 8 `ThreatClass`es, a JSON-lines threat ledger (`fr_threat_ledger_v1`) flushed to disk from the server loop in hardened mode, RaptorQ FEC sidecars for RDB, RESP parser limits [Code-verified, High for existence]. **The disavowal — quoted and located precisely:** immediately after the losses table, in the *same* paragraph as the ratcheted-matrix sentence (README L164–168 at the pin) — *ratcheted matrix: the project's stable-cell win/loss scorecard* — ("7 wins / 6 losses / 2 neutral … ratchet FAIL"), the README states verbatim: *"A controlled quiet-host re-baseline (bead `vibu6`) would be required before the pipelined table is quoted as a release number; that bead is currently **deferred**, so until it is un-defered the pipelined table should be read as a contention-sandbox measurement, not a release claim."* (Spelling "un-defered" sic — the repository's own.) "The pipelined table" is the 8-row `## Performance` table containing the 1.463x/1.333x/1.255x/1.029x wins. Whether the sentence also covers the adjacent XADD sub-table is **ambiguous**: the XADD rows sit under their own header (README L141 at the pin: "Current stream-dispatch measurements use the same live-incumbent contract:") in a separate 2-row table and are never called "pipelined" — the disavowal's spirit plausibly extends to them (same non-quiet host), but that is an inference, not text [Inference, Medium]. Whether the sentence covers the adjacent losses table (VmRSS 1.17x/2.3–2.9x rows, dated 2026-09-02) is likewise ambiguous — the sentence scopes itself to "the pipelined table" [Maintainer claim, High on the ambiguity]. Net: the maintainer forbids quoting the pipelined-table numbers as release numbers; XADD's status under the disavowal is an open inference. Any downstream citation that omits this sentence is misrepresenting the source [Maintainer claim, High — the disavowal is in the pinned README]. **Arithmetic check on the wins:** the table reports medians of per-round ratios with an in-invocation A/A null control on every row (nulls 0.979–0.999 — all within ~2% of 1.0), so the *direction* of the wins is internally controlled *within the sandbox*; what is disavowed is external validity (quiet-host re-baseline), not the arithmetic. **CI-column correction (v4):** the pinned 8-row pipelined table (README L116–123) carries no per-row confidence intervals — its columns are workload, pipeline depth, ops/s ratio, user instructions/op, CPU ns/op, and A/A null. Per-row bootstrap 95% median CIs appear only on the adjacent XADD sub-table ([1.651, 1.770]; [1.727, 1.755]). Any citation attributing confidence intervals to the pipelined rows is misattributing them [Verified against the pinned README, High]. **Benchmark reproduction cost:** reproducing the pipelined table requires the ~938 MB checkout at the pin (measured including the shallow `.git`), the pinned `nightly-2026-08-31` toolchain (`rust-toolchain.toml`), and a quiet, core-pinned host able to run the checked-in procedure (`scripts/record_baselines.sh`, then `scripts/benchmark_gate.sh` against `baselines/`); the full upstream Tcl conformance alone runs ~21–23 min at the pin (historical CI range across runs: 23m–1h5m) [Counted/CI-observed, Medium]. No independent reproduction is known to exist [External, High within recall caveats]. --- ## 4.6 Competitors The incumbent wins on ecosystem, operations knowledge, and managed offerings; FrankenRedis's only uncontested edge is its auditability apparatus (threat model, proof bundles, negative-evidence ledger) — which no competitor bothers with because no buyer currently pays for it [Inference, Medium]. - **Valkey (Linux Foundation, BSD-3 fork of Redis 7.2.4):** launched 2024-03-28 after the Redis license change; open governance under the Linux Foundation with major contributors including AWS (primary contributor), Google Cloud, Oracle, Ericsson, Snap, Alibaba, Huawei, Tencent, Percona, Aiven, and others, growing from 22 to 47 corporate participants with 700+ contributors and ~20.7k stars [External, High on governance/fork facts, Medium on the counts]. Valkey — not FrankenRedis — owns the "open Redis" lane by every observable measure: governance, contributors, managed-service defaults (AWS ElastiCache for Valkey GA October 2024; Google Cloud Memorystore and Oracle OCI Cache ship Valkey first-class), and now measured demand — ~75% of Redis users testing, considering, or having adopted Valkey as of mid-2024 (Percona's September-2024 survey), with 83% of large enterprises having begun the transition or actively evaluating it [External, Medium — figures from Percona's survey, published in its press release "Valkey Emerges as Leading Open Source Alternative to Redis After Relicensing Row"; methodology not independently verified]. FrankenRedis's BSD-lineage parity argument is aimed squarely at a lane Valkey already occupies — and the occupancy is now quantifiable, not just architectural [Inference, Medium]. - **Redis 8.0 (Redis Ltd.):** AGPLv3 added as a licensing option on 2025-05-01 (tri-license: AGPLv3/RSALv2/SSPLv1); vector sets introduced as the first new core data type in years; the former Redis Stack modules (JSON, TimeSeries, Query Engine) integrated into the server [External, High]. Commercial/managed lane ownership [Inference, Medium]. Note the irony: Redis's own AGPLv3 option partially defuses the "Redis isn't open" pitch FrankenRedis was born into. - **Dragonfly (C++, BSL 1.1):** maintainer describes it as a multi-threaded, shared-nothing, Redis/Memcached-compatible datastore and publishes throughput claims (up to 25x vs Redis) [Maintainer claim, Medium on architecture; the 25x is a vendor benchmark, treat as Low]. Owns the "faster Redis, same API" throughput lane in buyer perception [Inference, Medium] — directly contesting FrankenRedis's 1.0–1.7x sandbox wins with bigger claimed numbers and real users. - **Garnet (Microsoft Research):** a remote cache-store written in C#/.NET that speaks RESP, positioned on throughput and scalability with published performance claims [External, High on identity/architecture; performance claims are Maintainer claim, Medium]. It is a throughput competitor with institutional backing — not confined to a ".NET-embedded" niche. Garnet's existence says a from-scratch RESP server can get serious engineering attention; it does not say FrankenRedis's approach wins. - **Apache Kvrocks (Apache Software Foundation):** distributed NoSQL database on RocksDB, Redis-protocol compatible, aimed at SSD capacity and cost efficiency [Maintainer claim, Medium]. Owns the disk-backed/cost-per-GB lane [Inference, Medium] — a dimension FrankenRedis doesn't contest. - **KeyDB (BSD-3 Redis fork, backed by Snap Inc. since 2022):** multithreaded Redis fork with a smaller community than Valkey [External, Medium]. Relevant as the other "make Redis faster without rewriting" attempt; its modest traction *despite corporate backing* is a sharper cautionary data point for the whole category than v2's framing allowed [Inference, Medium]. - **Rust peers — the honest tiering:** - *rLightning* claims Rust + Tokio async I/O, sharded storage, 400+ commands, cluster/sentinel/streams/ACL/TLS/Lua [Maintainer claim, Medium — from its README, unverified]. Architecturally it is the *opposite* bet from FrankenRedis (async Tokio vs sync io_uring/mio); the two would not share a single design review [Inference, Medium]. - *nexrade-cache* claims Rust, Redis compatibility, ACL/TLS/Lua, WASM plugins, and an embeddable `nexrade-core` library [Maintainer claim, Medium]. The accurate statement is that a maintainer *describes* an embeddable/WASM wedge, which is a plausible unoccupied lane neither Redis nor FrankenRedis targets [Inference, Low]. - *feox-server* markets itself as a Redis-protocol-compatible drop-in on a thread-per-core, lock-free store with a 3.8M+ SET/s claim — but discloses missing sets, sorted sets, and Lua [Maintainer claim, Medium]. A narrower compatibility competitor, not an unqualified drop-in; its disclosed gaps are the honest version of FrankenRedis's open parity gates. - *redcon.rs* is a Redis-compatible server *framework/library* for Rust (tidwall lineage), not a Redis server at all [External, High]. Category error to list it as a server competitor; it belongs in "tooling." - **Unoccupied lane:** a memory-safe, *deterministic-latency* Redis with machine-checked parity evidence and a published threat model has no direct occupant — Dragonfly/Garnet chase throughput, Valkey chases openness, Kvrocks chases cost/GB [Inference, Medium]. Whether any buyer will pay for determinism-plus-auditability over throughput is the unproven bet the whole project rests on. ## 4.7 Skeptic's take *Citation convention: weaknesses are numbered 1–8 below; elsewhere in this packet "§4.7.N" means weakness N.* Weaknesses, threat-classed per the packet's own convention (each is substantive — capable of killing the project on its own): 1. **[FATAL] The license rider poisons the well it drinks from.** Barring OpenAI/Anthropic *and their affiliates and anyone acting for them* from use, benchmarking, analysis, indexing, and training-data incorporation doesn't just block two companies — the "acting directly or indirectly for … or for the benefit of" prong creates legal uncertainty for any contributor employed anywhere near the AI supply chain (the LICENSE does define "Affiliate" precisely as >50% voting control; the uncertainty lives in the "acting for" language, not the affiliate definition), and the clause invites retaliatory scrutiny of the "clean-room" claim itself. A project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, High]. §4.8 adds the sharper turn: the rider's "analyzing" bar arguably covers this very assessment. 2. **[FATAL] One human, no release artifact at the pin, disavowed benchmarks.** Single maintainer (27 stars, 6 forks [External, High]), version 0.1.0 with no release artifact at the pin (the `v0.1.0` tag points at an earlier commit, not the assessed tree; a signed-binary v0.1.0 GitHub Release published 2026-09-12 targets that earlier commit — claim 14), and the headline numbers carry a written disavowal. There is no artifact a third party can evaluate *as the pinned product* — only a repository to audit as a *process*. Bus factor 1 plus no release discipline at the assessed commit means every downstream claim rests on one person's continued weekends [Inference, High]. 3. **[HIGH] The reality-check ledger (2026-09-02) documents a project that was red across the board days before the pin — and the pin is still red.** Both CI workflows failed on every visible run (conformance at `cargo fmt` since March; the Tcl lane at `runtest --list-tests` on all 105 runs from a wrong working directory — no `report.json` had *ever* been produced); 12 of 5,145 tests failing; `parity_suite.py` 175/179; small-collection RSS 2–3x Redis; the threat ledger was an in-memory `Vec` nothing wrote; Sentinel answered NOGOODSLAVE — *NOGOODSLAVE: Sentinel's reply when no suitable replica exists for failover* — against healthy replicas. The September repair sprint is admirable, but the v5 round established via the Actions API (2026-09-22) that the pin itself is still red: conformance run #7679 failed at the G1 `cargo fmt` gate with all substantive gates skipped, and the Tcl lane's scheduled run #284 executed the suite but failed at the verdict-verification step [CI-observed, High]. Several repairs remain open beads [Maintainer claim, High — from the project's own CHANGELOG]. 4. **[MEDIUM] The README is a drift source, and the project knows it.** The Sept 2 audit found the README counting 13 crates (16 at pin), claiming "every component is `#![forbid(unsafe_code)]`" (false — 2 deny, 2 ungated), and describing fr-fec as "planned (not implemented)" while a 434-line RaptorQ implementation with a real dependency sat in the tree. The unsafe census (61) survived re-verification, but a README that drifts on crate count, safety posture, and feature existence — in a project whose pitch is *auditability* — is a structural liability, not a typo [Code-verified, High]. v3 adds two fresh drift instances to the ledger: the CHANGELOG's "peer-vote exchange remains open" trusted over the closed beads DB (claim 16), and `memchr` declared in `[workspace.dependencies]` but used nowhere. License-communication footnote (one cross-checker called it trivia; recorded as such): the README's shields badge (pinned L9) advertises "License: MIT" and links to the LICENSE — whose rider section this packet classifies non-OSI. The README's own License section (L2075–2077) does disclose "MIT License (with OpenAI/Anthropic Rider)" on the same page, so the badge is shorthand, not concealment [Code-verified (badge + license text), High]. 5. **[MEDIUM] The five-phase event loop is honest aspiration labeled as architecture.** The README admits the loop contributes three validators plus a `plan_tick(0, 0, …)` poll-timeout computation on the hot path while the real scheduling lives in a hand-written mio loop; the latency-determinism story (the project's second pillar after safety) therefore rests on a model that isn't executed. Deterministic latency is *claimed* in prose and *unimplemented* in the scheduler [Maintainer claim, High]. 6. **[MEDIUM] Parity is asymptotic and the tail is where drop-in replacement dies.** Open at the pin: the three keyspace parity gates, WAITAOF-without-appendonly, the RDB StreamSkeleton corpus test, INFO persistence/AOF fields, `ZRANDMEMBER` RESP3 doubles, and the cjson key-order WONTFIX. Each is small; collectively they are the long tail that has killed every "drop-in replacement" that came before [Maintainer claim, Medium]. 7. **[MEDIUM] The 58,857-line `main.rs` is a reviewability cliff.** The server's single-file entry point concentrates the dispatch floor, server loop, and wiring in one file that no reviewer reads whole — a maintenance cliff that mirrors the bus-factor problem, and the exact file where the hand-rolled Lua VM, threat ledger flush, and failover driver all meet [Inference, Medium]. 8. **[MEDIUM] Agent co-authorship murkies the "clean-room" label.** 36% of the 449 most recent commits carry agent Co-Authored-By trailers (claim 18) — 158 of them Claude-family models from Anthropic, a named Restricted Party. If models plausibly trained on Redis source wrote material parts of the tree, the clean-room label faces an output-similarity question (copyright's test is about the output, not the tools — see §4.8); the rider's no-training clause cannot bind its own author, so the sound version of the concern is epistemic, not legal: a clean-room assertion that no independent party may benchmark or analyze is untestable [Inference, Medium — full analysis in §4.8]. **Bear-case steelman (strongest counter-case):** FrankenRedis is a single-maintainer performance-art project about *how* to rewrite infrastructure, not infrastructure. The benchmarks are disavowed by their author; the license forbids the only entities with the resources to validate or adopt it from even benchmarking it (non-restricted parties may still fork it, rider and all — the exclusion is targeted, not total, which makes it worse: the project selects for adopters who can't evaluate it); Valkey already owns the open-Redis lane with 700+ contributors while this has one; Dragonfly and Garnet own the speed lane with real users; the README cannot keep its own crate count straight; and three weeks before the pin, both CI pipelines had never once gone green — and the v5 round confirmed they still hadn't at the pin. The rational market response is to mine it for methodology (proof bundles, negative-evidence ledgers, differential harnesses) and never deploy it. Its most likely end state is not acquisition or adoption but abandonment at the maintainer's next context switch — leaving 543k lines of unauditable-by-license Rust that the best-equipped evaluators may not benchmark, analyze, or train on. [Inference, Medium — this is a forecast, and it is deliberately uncharitable; the counter-evidence is the repair velocity documented in the September changelog — though the deepened window shows the rate running roughly one-third the August pace (§4.2), so "velocity" is no longer the accurate characterization.] ## 4.8 Maintenance & succession **Bus factor: 1.** One human maintainer (Jeffrey Emanuel); all 449 commits in the deepened window are authored by Dicklesworthstone/Jeffrey Emanuel (the same person) [Git-observed, High]. No succession plan, no second committer, no foundation, no release artifact at the pin to fork from cleanly (the v0.1.0 release targets the earlier tag commit `c577c0ae` — a clean fork point for the released tree, but not for the assessed pin) [Inference, Medium — absence of evidence across the assessed materials; the no-release-at-pin half is Git-observed, High]. If the maintainer stops, the project freezes at whatever commit the stop happens on [Inference, High]. **Agent authorship vs the "clean-room" posture — the new adversarial material.** The tree is materially agent-written: in the 449 most recent commits (2026-08-26 → pin), 162 (36%) carry `Co-Authored-By` trailers — 158 Claude-family (Claude Opus 5, Claude, Claude Fable 5.1, all `@noreply@anthropic.com`) and 4 Grok (`@noreply@x.ai`) [Git-observed, High]. No agent is ever the primary author in this window [Git-observed, High] — but co-authorship on more than a third of recent commits, including the celebrated Grisu2 commit and the pinned commit itself (`Co-Authored-By: Claude ` on `f78f64e`), means agents are not marginal contributors. Three consequences: **(1)** the "clean-room" label is legally murky — *if* models plausibly trained on Redis source wrote material parts of the tree, the question that matters is copyright's: output similarity, not tool purity. Clean-room is a doctrine about the *output* — independent creation defeats infringement where there is no substantial similarity of protected expression — not a doctrine about which tools touched the draft; and the rider is a licensee-facing contract term that cannot bind its own author, so its no-training clause is legally inert as to the author's own conduct: it neither creates nor answers any copyright question about the tree. What is real is the *irony* (the maintainer bars as licensee conduct what he practiced as author) and the *epistemic* point (§4.10.8): a clean-room implementation whose author bars benchmarkers is making an assertion no independent party may test. The actual open legal question — output similarity — is parked as §4.13 open question 3 (line-level attribution via `git blame` sampling) [all Inference, Medium — legal analysis, not legal advice]; **(2)** the rider's "analyzing" bar arguably covers this very assessment — Anthropic is a named Restricted Party, its model co-authored the assessed commit, and the packet you are reading is analysis of that code [Inference, Medium — legal conclusion, not legal advice]. The argument as stated skips its load-bearing premise: the rider restricts *who* may analyze — Restricted Parties and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" one — not analysis per se, and nothing establishes that the FrankenSuite analyst acts for or on behalf of Anthropic; the assessment is conducted for the program's own research, and using a model as a tool does not make the work product "for the benefit of" the lab. The recursion is worth confronting rather than leaving latent: read maximally aggressively, the "agent acting for" prong could sweep in any agent-assisted analysis — including this packet's own production, an agent-assisted assessment of agent-co-authored code under an anti-agent-analysis rider; **(3)** quantification limits: trailer counts measure commits touched, not lines written — full-tree line-level attribution (via `git blame` sampling over the complete ~8k-commit history) was not performed and is the open question in §4.13. **Maintenance load signals:** extreme commit velocity (8,115 non-merge commits in ~6 months per the August changelog [Maintainer claim, Medium], decelerating to ~16/day through the pin in the deepened sample — see §4.2) cuts both ways — it shows dedication and it shows a workload no successor inherits casually. The bead tracker (3,284 closed [Maintainer claim, Medium]) is the closest thing to institutional knowledge transfer, and it lives in-repo, which is good. Review depth is unassessed: PRs-vs-direct-to-main and who reviews bead closures were not examined [Not verified]. **License — the rider, scoped precisely (LICENSE read verbatim at pin):** - **Restricted parties:** "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)." (quoted verbatim from the pinned LICENSE) - **Grant:** "no rights are granted to any Restricted Party" without the author's "express prior written permission." - **Scope:** bars providing or permitting access to "the Software or any derivative works thereof" to or for a Restricted Party. - **"Use" is defined expansively** — "For purposes of this rider, '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." (quoted verbatim from the pinned LICENSE; emphasis added on the evaluation-relevant terms) - **Remedy:** any breach causes rights to "terminate automatically"; the author reserves injunctive/equitable relief and attorneys' fees. - **Classification:** non-OSI, source-available. The named-party discrimination fails Open Source Definition §5 (no discrimination against persons or groups — named labs) and the benchmarking/training/analysis bar fails OSD §6 (no discrimination against fields of endeavor) [Inference, High — legal conclusion, not legal advice]. **Succession consequence:** even a willing acquirer inherits a license that shrinks the contributor and evaluator pool; removing the rider requires the sole copyright holder's action, which is the same single point of failure as everything else [Inference, Medium]. ## 4.9 NODUS factsheet | Criterion | Score | One-line justification | |---|---|---| | Technology readiness | **TRL 4–5** | Lab-validated components (5,041 differential probes vs a vendored oracle, 499 MB fuzz corpus, CI executing) with zero production exposure, disavowed performance numbers, and both CI lanes red at the pin (established 2026-09-22) — the range, not a point, is honest: lab validation (TRL 4–5) holds, but the red pin blocks any claim of system-level validation in a relevant environment [Inference, Medium] | | Strategic relevance | 3/5 | A memory-safe Redis-compatible store is central to the FrankenSuite infrastructure thesis, but the rider blocks the program's own engagement with the software [Inference, Medium] | | Impact potential | 2/5 | The deterministic-latency-plus-auditability lane is genuinely unoccupied, but the demand the "open Redis" window represents is being captured by Valkey (§4.1's demand-side check) and no buyer signal exists for this implementation [Inference, Medium] | | Implementation feasibility | 2/5 | 543k lines, one maintainer, no release artifact at the pin — any adopter inherits the entire tree plus the rider [Inference, Medium] | | Time to mainstream | 2/5 | Years at best: rider removal, a tagged release, and independent validation must all happen first, in that order [Inference, Low] | | Collaboration potential | 1/5 | The rider bars the likeliest collaborators (AI labs and their agents) from even analyzing the code; bus factor 1 [Inference, Medium] | **Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven; the factsheet above is the scaffolding the ring stands on. The rider does not change the ring — it is recorded as the advancement blocker (§4.8, trigger 3) and priced into feasibility (2) and collaboration (1): **Explore-with-a-ceiling**, currently un-advanceable past Explore while the rider stands. No Rulebook amendment; v1.0 stands. **Methodology fit (for the FrankenSuite):** adopt the patterns, not the package — the negative-evidence ledger, proof-bundle PRs, differential-against-oracle conformance, and bead-tracked issue discipline are directly importable into how the program evaluates the other 43 repositories. Do not depend on the software: the rider, the missing releases, and the disavowed benchmarks disqualify it as a dependency, benchmark target, or training-data source. If the program ever needs a Redis-compatible store, Valkey dominates on every adoption criterion except auditability — and the rider disqualifies FrankenRedis regardless [Inference, High]. --- ## 4.10 Wardley placement Placing the *components*, not the repo: - **Commodity — the RESP2/RESP3 wire protocol and RDB/AOF formats.** Inherited standards; commodity by definition — byte-exactness is table stakes, not differentiation. Moves right only if the protocol owner moves it: a RESP revision (no RESP4 is on the table), or a wire-visible feature expansion by Redis/Valkey that forces the parity surface to grow — Redis 8.0's vector sets, the first new core data type in years, are exactly this kind of mover: every such addition is a new differential-probe campaign FrankenRedis must fund, and the differential harness must absorb it, before the core can claim parity again [Inference, Medium]. - **Custom-built, approaching early Product — the 543k-line Redis core re-derivation** (`fr-store`, `fr-command`, the Lua VM, replication). Custom-built on process rigor alone; not yet product (no release, no independent validation). Moves right with a tagged release plus an independent benchmark; decommissions (becomes a monument, not a product) if Valkey absorbs the memory-safety narrative or an incumbent ships the hardening story first [Inference, Medium]. - **Custom-built, closest to Product — the differential-against-oracle conformance harness + proof-bundle machinery.** The packet's own "real export" (§4.9): 5,041 argv probes against a vendored Redis 7.2.4 oracle, the full upstream Tcl suite executing in CI, SHA-pinned golden RESP transcripts and paired/reversed hyperfine runs per optimization PR. It is the most *executed* component in the tree — used operationally in-repo, but not yet packaged for external adoption. Moves right if extracted as a standalone conformance framework other projects can adopt; stays repo-local tooling, effectively invisible outside the repo, while the rider blocks the likeliest adopters [Inference, Medium]. - **Genesis — the strict/hardened split + persisted threat ledger (+ RaptorQ sidecars).** No incumbent ships "be byte-exact" and "fail closed and log the decision" as a first-class mode switch. Moves right if the ledger becomes a reviewed, origin-bound provenance mechanism — the direction arXiv 2606.24322 (June 2026), whose machine-checked theorems show content/lineage defenses are malleable via origin laundering and write-time origin binding is *necessary*, points to — or stagnates as a single-maintainer log format if the maintainer context-switches [Inference, Medium]. **Residual product gaps (what's missing / risky):** 1. **No Redis Cluster, no multi-master** — explicitly out of scope ("What FrankenRedis is not" [Maintainer claim, High]). Any workload needing horizontal scaling is excluded by design. 2. **TLS: config parsed, transport absent — by decided scope exclusion, not deferral** (claim 17). The README states at L1662, verbatim: *"Wire-level TLS is not on this list on purpose: it was decided as a scope exclusion (bead `xzdbc`, closed WONTFIX on 2026-05-25) and stays delegated to the operational layer, as the Limitations section says."* Bead `frankenredis-xzdbc` ("Wire-level TLS termination via rustls") closed 2026-05-25T05:13:37Z with close_reason: `WONTFIX: Deliberate scope decision - TLS is transport-layer, not Redis protocol parity. Documented in README. Use stunnel/spiped/load-balancer for termination.` The config surface (`tls_port`, `parse_tls_bool`, `CONFIG SET tls-*` handlers) exists to support operational-layer termination — stunnel/spiped/load-balancer — which is precisely what "stays delegated to the operational layer" means; the config evidence is *consistent* with the exclusion, not evidence of intent [Maintainer claim, High on the exclusion; Inference, Medium on the config's purpose]. Any deployment crossing a trust boundary therefore depends on the operator's TLS-termination story, and in-server TLS is not a roadmap item awaiting a second committer — it is a decision that would have to be reversed. 3. **Parity-tail gates open** (see §4.7 weakness 6): three keyspace gates, WAITAOF, StreamSkeleton RDB test, INFO AOF fields, RESP3 doubles — each a potential drop-in-replacement killer [Maintainer claim, Medium]. 4. **Sentinel: peer-vote exchange CLOSED 2026-09-03** (claim 16) — quorum-2 e2e test exists, README claims it works; v2's "remains open" was stale CHANGELOG trusted over the beads DB, a governance signal. Test greenness at the pin unestablished. Still open per the README: sentinel config files and notification/reconfig scripts [Maintainer claim, Medium]. 5. **Memory footprint** — 2–3x Redis RSS on small collections at the Sept 2 check [Maintainer claim, Medium]; the packed-encoding campaign (Phase 14) is the response, outcome unmeasured at the pin. 6. **README drift as a standing risk** — documented in §4.7 weakness 4; the project's own audit cadence (reality checks, readme-truth beads) is the mitigation, and its existence is a point in the project's favor, but the drift rate vs. audit rate is unmeasured [Inference, Medium]. 7. **The `vibu6` re-baseline may never un-defer** — if it doesn't, the headline numbers stay permanently in "contention-sandbox" status and the performance pillar never graduates from claim to evidence [Inference, Medium]. 8. **Legal overhang on "clean room"** — sharpened in v3: 36% of recent commits are agent-co-authored (claim 18), and the rider's aggression invites the question it tries to preempt — a clean-room implementation whose author bars benchmarkers is making an assertion no independent party may test [Inference, Medium]. ## 4.11 Trajectory (12 / 24 / 60 months) All horizons **[Inference]** — forecasts, not findings; confidence Low unless noted. **12-month base case [Inference, Medium]:** velocity continues at the current cadence; the parity tail shortens bead by bead; `vibu6` stays deferred and the performance numbers stay in contention-sandbox status; no tagged release at the assessed commit; the rider stands. The methodology gets mined (proof bundles, negative-evidence ledgers appear in sibling projects); the software gets no production users. Ring: Explore, unchanged. **24-month base case [Inference, Low]:** one of two shapes. Either the maintainer's program compounds — a first tagged release at a new pin, the TLS scope exclusion reversed, RaptorQ sidecars go default-on — and the packet's checklist (deepening question 8 below) starts scoring above zero; or velocity decays after the initial program arc completes and the tree enters maintenance drift (README drift compounding, CI bit-rot). The base case leans toward the second shape on bus-factor-1 priors. **60-month base case [Inference, Low]:** the software is either a niche artifact with a small hardened-mode following or dormant — the abandonment end state in the §4.7 steelman. The methodology-export (differential-against-oracle conformance, proof-bundle PRs, negative-evidence ledgers) is the durable survivor either way. **Bifurcation — what the upside requires:** all four, in rough order: (a) the rider narrowed or removed (trigger 3) — without this nothing else matters for adoption; (b) a tagged release with a stability policy (trigger 1); (c) the `vibu6` quiet-host re-baseline published and independently reproduced (triggers 2, 6); (d) a second human committer (trigger 4). The rider is the *necessary* condition, not merely first in a list: any three of the four **including the rider** moves the ring conversation to "can we pilot"; all four plus a bounded real workload fit is what actually meets the Pilot bar. That distinction — conversation vs. bar — resolves the earlier wording. **Bifurcation — what decay looks like:** commit velocity falls off a cliff (the observable sensor is trigger 9 below), CI workflows go red or silent, the README drifts past the project's own audit cadence, and the tree freezes as a 543k-line monument. Decay is the default outcome for bus-factor-1 infrastructure without institutional capture — the base case, not the tail. **Revisit triggers (observable, falsifiable):** check any of these; each names the exact observation that flips it: 1. **A tagged release or GitHub Release pointing at the assessed commit appears** — `git for-each-ref refs/tags` / `gh release list` non-empty *at the assessed commit*. (v0.1.0 exists — released 2026-09-12 with 24 signed binary assets — but targets the earlier tag commit `c577c0ae`, so this stays open.) Flips the "no artifact to evaluate" judgment. 2. **Bead `vibu6` un-deferred and re-baseline published** — the README's disavowal sentence removed or amended with quiet-host numbers. Flips the benchmark pillar from disavowed to testable. 3. **Rider narrowed or removed** — LICENSE diff dropping the named-party restriction. Flips usability for restricted parties and contributor-pool risk. This is the advancement blocker for the Explore ceiling. 4. **Second human committer with merge rights** — bus factor > 1 observable on the contributor graph. Flips succession risk. 5. **Cluster lands (a scope-gap closure) or the TLS scope exclusion is reversed (a decision reversal — bead `xzdbc`)** — two distinct events: cluster closing a genuine roadmap gap (multi-node sharding is explicitly out of scope today) vs TLS landing only if the maintainer reverses the 2026-05-25 WONTFIX. Either changes the deployment envelope. 6. **Independent benchmark or review published** — any third party reproducing or contesting the numbers. Flips "zero independent coverage." 7. **RaptorQ sidecars on by default with recovery demonstrated in CI** — the durability experiment graduates from optional to load-bearing. 8. **A Valkey/Redis/Dragonfly/Garnet release ships a hardened-mode equivalent** (threat ledger, parser limits, FEC) — the kill-test: if incumbents absorb the hardening story, FrankenRedis's differentiation collapses to "Rust, but slower to adopt" [Inference, Medium]. 9. **(v3 addition) Abandonment tripwire** — no commits for 60 days or the CI workflows disabled/archived: re-ring to Monitor and treat the tree as a retired artifact. This is the decay sensor the steelman's end state needs. ## 4.12 Verdict & NODUS ring **NODUS ring: Explore.** The packet's v2 defense of Monitor committed a category error — "nothing to pilot" rebuts *Pilot* (which requires a release artifact plus a bounded, real workload fit), not Explore. The Rulebook's Explore rule is explicit: *the default for substantive-but-unproven*. FrankenRedis is the textbook case: substantive (542,716 lines, a 61-site unsafe census, 5,041 differential probes, a 499 MB fuzz corpus — all [Counted, High]) and unproven (no release artifact at the pin, disavowed benchmarks, zero independent coverage, bus factor 1, both CI lanes red at the pin). "When in doubt, ring down" does not apply — there is no doubt about the Explore floor; the doubt is about *evaluability by us*, which is not what the maturity scale measures. The rider is already correctly instrumented as an **advancement blocker**: quoted as the adoption ceiling in §4.8, priced into the NODUS feasibility (2) and collaboration (1) scores, and wired to revisit trigger 3. The ring reads: **Explore — substantive, unproven, and currently un-advanceable past Explore while the rider stands** [Inference, Medium]. No Rulebook amendment; v1.0 stands. **The one-paragraph case:** FrankenRedis is a 543k-line bet that infrastructure can be re-derived in safe Rust with machine-checked parity and published proof of every claim — and on process grounds it is winning that bet further than any peer: 61 counted unsafe sites, a 499 MB fuzz corpus, ~5k differential probes, the full upstream Tcl suite executing in CI, and a 26k-line ledger of its own failures. But the product case is hollow at the pin: the speed numbers are disavowed by their author, both CI lanes are red at the pin (conformance formatting-blocked, Tcl verdict-failed — established 2026-09-22), one human is the entire bus factor, over a third of recent commits are agent-co-authored (which murkies the "clean-room" label), and the license forbids the likeliest evaluators from even analyzing the code. Explore the methodology; the software stays behind the rider's ceiling until trigger 3 fires. [Inference, Medium — a recommendation plus a forecast, both the analyst's judgment.] ## 4.13 Limitations and open questions (analyst-facing) **What was not done:** the workspace was never compiled; the server was never executed; no test suite was run (so the quorum-2 Sentinel e2e test exists but its pass/fail is unknown); no benchmark was reproduced; the full ~8k-commit history was not pulled (authorship analysis covers the 449-commit deepened window only). **CI greenness at the pin: ESTABLISHED in the v5 round (2026-09-22)** — per-job conclusions fetched via the Actions REST `repos/{owner}/{repo}/actions/runs/{run_id}/jobs` endpoint: run #7679 (conformance, head = pin) failed at the G1 `cargo fmt` gate with all substantive gates skipped; run #284 (Tcl, head = pin) executed the suite (~21 min) but the "Verify complete upstream suite verdict" step failed. Greenness is red, not unknown. GitHub Releases re-fetched 2026-09-22 (v5 round): one release, `v0.1.0` (published 2026-09-12, 24 signed binary assets), targeting the earlier tag commit — not the pin [External, High]. Demand-signal search performed 2026-09-22 (v5 round): Valkey adoption data found (see §4.1); no independent coverage of FrankenRedis itself beyond the repository [External, High within recall caveats]. Quick-link resolution re-verified 2026-09-22 in the v5 round. **Open questions that would most change the verdict, in order of load-bearing weight:** 1. **(Answered in the v5 round, 2026-09-22): Do the conformance gates and the Tcl lane pass at the pin?** No — both red: run #7679 failed at the G1 `cargo fmt` gate (substantive gates G2–G7 skipped), scheduled run #284 executed the suite but the verdict-verification step failed. This hardens §4.7 weakness 3 rather than blunting it. 2. **Does the rider bar this very assessment?** The license's "analyzing" prohibition arguably covers the FrankenSuite's evaluation activity — and the pinned commit was co-authored by an Anthropic model. A legal reading either way changes whether the program may continue touching the repo at all. 3. **What fraction of the tree's lines are agent-written?** Trailer counts (36% of recent commits) measure commits touched, not authorship share. A `git blame` sample over full history would settle whether "clean-room" is a defensible label or a murky one. 4. **Does the quorum-2 Sentinel e2e test pass?** Existence is verified; greenness would close the last HA gap on paper. 5. **Is there any production user or demand signal?** One real deployment would move the impact-potential score and the 24-month trajectory more than any code change. (v5 search 2026-09-22: none found.) 6. **(v5 addition) What is the review depth?** PRs-vs-direct-to-main, who reviews bead closures, whether any of the 3,284 closed beads saw a second pair of eyes — unassessed; determines whether the bead tracker is institutional knowledge or a solo diary [Not verified]. --- ## Deepening questions — Rulebook §5's binding eight, one paragraph each *§5→location mapping: Provenance ← the threat ledger's audit mechanics (built on claim 10); Embeddable unit ← new, sourced from the README's "Embedding `fr-*` crates" section (L1410 at pin); Unexercised option value ← three held capabilities (concurrency-as-optimization, the unexecuted five-phase model, optional RaptorQ); Benchmark honesty ← §4.5 plus the fsync honesty audit in Q4; Governance path ← §4.8 plus §4.7 weakness 2 (bus factor); License as strategy ← §4.8 plus §4.7 weakness 1 (rider); Agent-era fit ← new; Kill test ← §4.7's bear-case steelman plus trajectory trigger 8.* **1. Provenance.** The repo's provenance machinery is the threat ledger: a bounded 10,000-event window flushed as `fr_threat_ledger_v1` JSON lines from the server loop next to the AOF flush, written to `threat-ledger.jsonl` in hardened mode [Code-verified, High] — self-contained and replayable against the exact build that produced it, but an audit artifact for humans rather than a signal for machines (no SIEM ingests the bespoke sidecar natively), and not tamper-evident by construction: append-only in practice, yet a hostile operator with disk access could rewrite history undetectably [Inference, Medium]. Portable attestation would require hash-chained, signed, write-time-bound entries — the direction arXiv 2606.24322 (June 2026) points, whose machine-checked theorems show content/lineage defenses are malleable via origin laundering and write-time origin binding is *necessary* [External, Medium]. A quieter second provenance layer is the benchmark discipline itself: optimization PRs ship SHA-pinned golden RESP transcripts and ELF SHA-256-pinned binaries, so a number is bound to the exact build that produced it [Maintainer claim, Medium]. What nothing records is *who* produced an artifact — the ledger logs events, not authors — so provenance-of-code (the §4.8 agent-authorship question: 162 of 449 recent commits agent-co-authored) is entirely unaddressed by the machinery [Inference, High]. **2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is `fr-protocol`: RESP2/RESP3 parse and emit with CRLF-injection sanitization and configurable fail-closed limits (`max_bulk_len`, `max_array_len`, `max_recursion_depth`), documented in the README's "Embedding `fr-*` crates in your own project" section (pinned L1410) with a worked `parse_frame_with_config` example — a hardened RESP codec for proxies, gateways, or anywhere you need to speak RESP without owning a key/value store [Maintainer claim, Medium — section and example verified present at the pin]. The same section offers `fr-store` as a typed in-memory store (`Store::set`/`get`/`zadd`, with a trailing caller-supplied `now_ms` for expiry and LFU decay), `fr-persist` for RDB/AOF decode outside the server (accepting vendored Redis 7.2.4 files unmodified — the forensic-tooling wedge), and `fr-runtime`+`fr-config` for driving the runtime without owning a socket. Adoption cost: every README pattern is a relative `path` dependency, so the unit is vendored, not versioned — no registry-artifact path is shown in the assessed materials — and it inherits the workspace's toolchain and dependency assumptions (the pinned `nightly-2026-08-31` toolchain, the 20-crate external set including the `memchr` dead weight) [Inference, Medium]. The hand-rolled Lua 5.1 VM, by contrast, is *not* an embeddable unit: the 31,799-line parser+VM lives as a single file inside `fr-command`, not a separate crate [Code-verified, High] — which is also why the hand-roll decision (byte-exact parity with Redis 7.2.4's *modified* Lua 5.1, 53/54 rows byte-identical, the `cjson` key-order diff WONTFIX [Maintainer claim, Medium]) concentrates a maintenance cliff on one human: there is no extraction story. **3. Unexercised option value.** Three capabilities the architecture holds but has not used. First, concurrency: the August CHANGELOG documents a "shared-nothing reactor" (adjacent same-key write collapsing) and a front-classified dispatch floor — shared-nothing *techniques* adopted surgically inside a single-threaded execution model [Maintainer claim, Medium] — so threading is exercised as optimization, not architecture; a multi-threaded or shared-nothing data plane would multiply the parity surface (cross-thread ordering, per-shard expiry) that the differential harness must prove equivalent against the single-threaded 7.2.4 oracle, which is why it stays unbuilt [Inference, Medium]. Second, the five-phase event-loop model (`BeforeSleep → Poll → FileDispatch → TimeDispatch → AfterSleep`) exists as a 1,253-line planning/validator library whose hot-path footprint is three validators plus a `plan_tick(0, 0, …)` poll-timeout computation — the executor was never built behind the model, and the deterministic-latency story therefore rests on an unexecuted model [Maintainer claim, High]. Third, RaptorQ FEC sidecars are wired (434-line fr-fec crate, real `raptorq 1.8.1` dependency locked in Cargo.lock, conformance gate expanded to all durability targets in CI commit `6b5f37a`) but optional, and the README section still says "planned (not implemented)" [Code-verified + CI-observed, High]; flipping default-on would convert "survives bit-rot Redis can't" from held option to load-bearing differentiator. What unlocks each: an executed scheduler behind the five-phase model, a default-on flag plus recovery demonstrated in CI for the sidecars, and — for threading — a parity-harness extension nobody has priced [Inference, Medium]. **4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the maintainer's own, and even those are partly disavowed: the pipelined table (README L108–182 at the pin) reports medians of per-round ratios with an in-invocation A/A null control on every row (nulls 0.979–0.999, all within ~2% of 1.0), so the *direction* of the wins (TTL SET 1.463x, SET 1.333x, INCR 1.255x, GET 1.029x) is internally controlled *within the sandbox* — but the table carries no per-row confidence intervals (columns: workload, pipeline depth, ops/s ratio, user instructions/op, CPU ns/op, A/A null; README L116–123), and per-row bootstrap 95% median CIs appear only on the adjacent XADD sub-table ([1.651, 1.770]; [1.727, 1.755]), so any citation attributing CIs to the pipelined rows is misattributing them [Verified against the pinned README, High]. What is disavowed is external validity: the README's own sentence (L165–168) forbids quoting the pipelined table as release numbers until bead `vibu6` (currently deferred) runs a quiet-host re-baseline, and whether the disavowal covers the XADD rows is ambiguous — the XADD table has its own header and is never called "pipelined" [Inference, Medium]. No independent reproduction is known [External, High within recall caveats]; reproduction costs a ~938 MB checkout, the pinned nightly toolchain, and a quiet core-pinned host. Which numbers are load-bearing for the thesis? None of the perf ratios — they are disavowed by their author; the thesis actually rests on the parity evidence (5,041 differential probes, the Tcl lane), which is the honest foundation and the one an independent rerun could falsify [Inference, Medium]. The honesty audit extends to non-numeric claims: the AOF fsync guarantee (everysec/always/no per the README's feature table) rests on real machinery — `write_rdb_bytes_atomically` (temp file + rename + parent fsync, `crates/fr-persist/src/lib.rs` ~L7234), the AOF manifest writer (temp + rename + parent fsync before the manifest, ~L419), and the everysec rate-limit state (`aof_last_fsync_ms`, `crates/fr-runtime/src/lib.rs` L4695–4696, default `AppendFsyncMode::Everysec` at L5107) [Code-verified, High on the machinery's existence] — but the guarantee was never executed in this assessment: "guaranteed" is untested [Not executed]. **5. The governance path.** The credible route from one maintainer to an institution runs through four gates in rough order: rider removal, a tagged release, the `vibu6` re-baseline published, a second human committer (trajectory triggers 3, 1, 2, 4). The starting position: no succession plan, no second committer, no foundation, no release artifact at the pin [Inference, Medium on the absences — the no-release half is Git-observed, High]. The closest thing to institutional knowledge transfer is the in-repo bead tracker (3,284 closed beads per the August changelog [Maintainer claim, Medium]) plus the evidence ledgers — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit; review depth (PRs-vs-direct-to-main, who reviews bead closures) is unassessed [Not verified] and is parked as §4.13 open question 6. What breaks first if velocity decays: the README audit cadence — the repo's own reality-checks found crate-count and safety-posture drift within weeks of the pin — then CI bit-rot; the 60-day abandonment tripwire (trigger 9) is the observable sensor [Inference, Medium]. Two scope corrections from v5: cluster is explicitly out of scope ("What FrankenRedis is not" [Maintainer claim, High]), and TLS is a decided scope exclusion, not a deferred roadmap item (README L1662; bead `xzdbc`, WONTFIX 2026-05-25) — so the "second committer unlocks TLS" framing is wrong; the second-committer gate is for the parity-tail grind, releases, and review depth, and any deployment crossing a trust boundary relies on the operational layer's TLS-termination story (stunnel/spiped/load-balancer), not on in-server transport [Inference, High]. Beyond the four gates, the realistic institutional endpoints are a foundation home or a corporate adopter — both currently gated on rider removal, which is why trigger 3 is the advancement blocker rather than a nicety [Inference, Low]. **6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates (>50% voting control); and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — barring "use" defined expansively (copying … benchmarking, testing, **analyzing, indexing** … incorporating into datasets, training corpora, evaluation harnesses, or pipelines for machine learning or other automated systems), with automatic termination on breach [Code-verified (license text), High]. Does the exclusion serve or sabotage the stated mission? It sabotages adoption and evaluability: the entities with the resources to validate a 543k-line safety claim — and their agents — may not benchmark, test, analyze, or index the code, while the "acting for" prong creates legal uncertainty for any contributor near the AI supply chain; it is already priced as the Explore ceiling (feasibility 2, collaboration 1, trigger 3) [Inference, High]. What it arguably *serves* is a defensive intent — denying 543k lines of curated systems code to rival training corpora — but that intent is unlabeled by the author and the cost is asymmetric: the project selects for adopters who cannot evaluate it, and a project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, Medium]. The remaining strategy point, made explicit in §4.8's v4 edit: the rider is a licensee-facing contract term — it binds users, not the author — so it neither creates nor answers any copyright question about the tree; its strategic function is access control, not clean-room hygiene [Inference, Medium]. **7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is the eval-harness workload: an agent team needing a deterministic, inspectable, byte-exact Redis-compatible fixture for tool-use evaluation — the differential-against-oracle conformance harness (5,041 argv probes vs a vendored 7.2.4 oracle, SHA-pinned golden RESP transcripts per optimization) is already the shape of an agent benchmark, and the threat ledger's per-decision event log is the audit trail an agent-safety review would want [Inference, Medium]. What would have to become true first: a tagged release (there is no artifact to pin an eval to), the rider narrowed or removed (AI labs and their agents are currently barred from even *analyzing* the code — the target user is excluded by name), and a documented TLS-termination story for any workload crossing a trust boundary — in-server TLS transport is a decided scope exclusion (README L1662; bead `xzdbc`, closed WONTFIX 2026-05-25), so the prerequisite is operational-layer termination (stunnel/spiped/load-balancer), not a roadmap feature [Inference, Medium]. The fit is real but presently blocked by the license aimed at its own likeliest users: the rider names the agent operators as Restricted Parties while the project's best adoption story is an agent workload — and the recursion is noted in §4.8 (this packet is itself an agent-assisted assessment of agent-co-authored code under an anti-agent-analysis rider) [Inference, Medium]. **8. The kill test.** The single experiment that would falsify the core thesis — that a clean-room Rust Redis with machine-checked parity and a published threat model is a differentiable, adoptable artifact — is the one the project built for itself: the deferred `vibu6` quiet-host re-baseline. If it ever executes and the sandbox wins (1.463x/1.333x/1.255x/1.029x, XADD ~1.7x) fail to reproduce — ratios at or below 1.0 — the performance pillar is falsified by the project's own mechanism, not by a critic [Inference, Medium]. Two secondary falsifiers sit behind it: a competitor move (Valkey/Redis/Dragonfly/Garnet shipping a hardened-mode equivalent — threat ledger, parser limits, FEC sidecars — collapsing the differentiation to "Rust, but slower to adopt", trajectory trigger 8) and the abandonment tripwire (trigger 9: 60 days without commits or disabled CI re-rings to Monitor). The production checklist is the inverse of this test — what success requires, scored at the pin as 0 of 8 fully met and 1 partially met: tagged release or GitHub Release for the assessed commit (v0.1.0 exists — released 2026-09-12 with signed binaries — but targets the earlier tag commit, not the pin), un-deferred re-baseline, closed parity-tail gates with a green Tcl lane, documented operational-layer TLS-termination story (in-server TLS is a decided scope exclusion, bead `xzdbc` WONTFIX 2026-05-25), RSS at or below Redis, Sentinel HA greenness, a signable license, bus factor > 1. The single partial is Sentinel HA greenness: the peer-vote bead closed 2026-09-03 and the quorum-2 e2e test exists (claim 16) but its pass/fail at the pin is unestablished [Inference, Medium]; the other seven are unambiguously unmet at the pin.