# FrankenFS — Technical Due-Diligence Assessment

**The hook:** A 663,710-line, mountable, unsafe-forbidden ext4/btrfs reimplementation in Rust — whose own 20,556-line negative-evidence ledger downgrades its benchmark claims faster than any outside critic could.

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

## TL;DR

FrankenFS is a genuine, working, mountable clean-room reimplementation of ext4 and btrfs in safe Rust: 22 workspace members, 663,710 lines of first-party Rust across 421 files, a real FUSE mount path (vendored `fuser` 0.17.0, ABI 7.42), JBD2 journal attachment on the ext4 read-write CLI mount path, a btrfs full-transaction-commit serializer (~1,866 lines), block-level MVCC with a 5-variant merge-proof taxonomy and expected-loss conflict arbitration, and a hand-rolled RFC 6330 fountain-code self-healing subsystem (`ffs-repair`, 31,572 lines). Its most original contribution is the **evidence apparatus** — a 20,556-line negative-evidence ledger, a parity report that explicitly disavows its own 97/97 number as "not an executed-test result or a readiness score," and mounted scorecards that open with all-caps anti-hype warnings, including one that proves the project's best btrfs "win" was a transport illusion. **TRL 4 (aggregate: 5–6 for ext4 read/inspect/FUSE-read, 4 for ext4 RW, 3 for btrfs RW). NODUS ring: Explore.** Strongest strength: the self-falsifying evidence discipline — the May-2026 reality check found its own btrfs read-write was a *silent-data-loss facade* and published it; the August-2026 worker-scope audit admitted 166 published benchmark rows cannot prove which machine they ran on. Strongest ceiling: the governance compound — bus factor 1 with an explicit no-contributions policy, CI red on the main workflow at HEAD, and a non-OSI rider license — which caps adoption, contribution, and independent validation all at once.

## Quick Links

- Repository: https://github.com/Dicklesworthstone/frankenfs
- README: https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/README.md
- License (MIT + OpenAI/Anthropic rider, read verbatim): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/LICENSE
- Changelog (v0.2.0 tagged 2026-07-11; scope window ends 2026-08-19): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/CHANGELOG.md
- Feature parity tracking (97/97 declared-contract rows, explicitly self-limited): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/FEATURE_PARITY.md
- Negative evidence ledger (20,556 lines, incl. 2026-08-15 worker-scope re-scoping): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/docs/NEGATIVE_EVIDENCE.md
- Reality-check bridge writeup (2026-09-21/22 executed gates): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/docs/reality-check-bridge-writeup.md
- Mounted-kernel scorecard (ext4 vs Linux kernel): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/docs/MOUNTED_KERNEL_SCORECARD.md
- Btrfs scorecard (transport-confound analysis, sign-changed rows): https://github.com/Dicklesworthstone/frankenfs/blob/HEAD/docs/MOUNTED_BTRFS_SCORECARD.md
- Releases (v0.2.0, 2026-07-11 — the only tagged release): https://github.com/Dicklesworthstone/frankenfs/releases
- CI — main workflow (fmt/clippy/check/`cargo test --workspace`; failing at HEAD): https://github.com/Dicklesworthstone/frankenfs/actions/workflows/ci.yml
- CI — Artifact Gates (passing at HEAD): https://github.com/Dicklesworthstone/frankenfs/actions/workflows/artifact-gates.yml
- asupersync 0.5.0 (sibling structured-concurrency runtime; real dependency): https://github.com/Dicklesworthstone/asupersync
- Pinned HEAD commit: https://github.com/Dicklesworthstone/frankenfs/commit/49acf5d5a9b7d48d7d459e28bb5a32e8546900b6

## Did you know?

In August 2026 the project's own negative-evidence ledger published a "worker-scope" re-scoping: **166 banked KEEP rows quote a vs-incumbent benchmark ratio but name no host**, after the maintainer measured the *same cell* at `1.2693x` on one `rch` worker and `0.0093x` on another — a **13.6x swing with both A/A nulls passing** — because an A/A null controls within-invocation noise only and is blind to between-worker CPU, cache, and memory-bandwidth differences. The ledger now enforces a ratchet: that count of unattributed rows may only fall, and new rows must record their host. [Maintainer claim, Medium — the audit is the maintainer's own, but the confession is against interest; the ratchet mechanism is described in the tree.]

## Franken-worthy next steps

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

1. **Export the claim-gating apparatus as a standalone lint framework.** FrankenFS's `ParityReport::current()` execution binding, canonical-gate binding (seven gate commands that report `not_implemented` rather than pass), and the worker-scope preflight ratchet are a reusable method for keeping public claims honest under extreme velocity. **Falsification:** apply the machinery to a *second* codebase (e.g., a sibling FrankenSuite repo) with its own claim inventory, and publish the before/after claim-status table; if the apparatus cannot be decoupled from FrankenFS's fixture schema and bead tracker within one focused workstream, it is product scaffolding, not a method. The project's demonstrated willingness to let its own gates go red in public is the precondition almost no other codebase satisfies.
2. **Formalize the merge-proof commit protocol.** The `MergeProofMechanism` taxonomy (AppendOnly, RangeOverlay, BitmapOr, BitmapDelta, NoSameBlockMerge) with expected-loss policy selection is a genuine concurrency-control claim — mergeable same-block writes are resolved without aborting — but its correctness currently rests on tests and prose. **Falsification:** write a TLA+/Ivy spec of the block-level commit protocol and model-check it against adversarial interleavings; a single model-found write-loss that the Strict FCW boundary would have prevented kills the "merge-proof" label, and would confirm the taxonomy as engineering heuristic rather than result. The project's in-tree crash/replay artifact gates show the evidence culture to attempt this honestly.
3. **Adversarial durability review of the btrfs transaction commit.** The 1,866-line `btrfs_full_transaction_commit` is recently repaired durability code with a silent-data-loss history (May-2026 facade finding; August EINVAL/ENOSPC incidents). **Falsification:** a third-party (or independent agent harness) fault-injection campaign that power-fails the commit at N sampled phases and checks acked-write durability; any single lost-but-acked write refutes the "durable by default" claim and keeps btrfs RW at TRL 3. The maintainer's own history of publishing the facade finding is the reason such a campaign's negative result would be believed.
4. **The transport-confound isolation protocol.** The btrfs scorecard's discovery — a 3.2x swing from loop-vs-file transport alone — generalizes into a publishable method: symmetric transport arms (loop/loop, file/file, null-device) plus null-spread gating for userspace-FS benchmarking. **Falsification:** publish the protocol and apply it to a second FUSE filesystem (e.g., ext4fuse); if the protocol fails to attribute confounds there with the same clarity, it is a one-off observation, not a method. The project's existing comparator already has a `--fuse-transport loop` mode, so the machinery half-exists.

---
## 4.1 Header

| Field | Value |
|---|---|
| Repository | https://github.com/Dicklesworthstone/frankenfs |
| Pinned revision | `49acf5d5a9b7d48d7d459e28bb5a32e8546900b6` — 2026-09-22 10:50:19 -0400; commit message: `fix(repair): serialize and durably publish ownership lease mutations` [Verified, High] |
| Assessment date | 2026-09-22 |
| Language / toolchain | Rust, edition 2024, pinned `nightly-2026-08-31` (`rust-toolchain.toml`; the file's comments document why the pin exists: a 2026-07-21 lint promotion broke the build and rustup once swapped the toolchain mid-build) [Verified, High] |
| License | MIT License **with OpenAI/Anthropic Rider** — NOT OSI open source; full text read verbatim, rider scope quoted in §4.8 [Verified, High] |
| Scale | 22 workspace members (21 under `crates/` + `tools/ffs-ops`; `ffs-ext4`/`ffs-btrfs` retained as legacy extraction references); 421 Rust files, 663,710 lines (incl. comments, excl. vendored `vendor/fuser`) [Verified, High] |
| Stars / forks | 21 stars, 5 forks (GitHub API, 2026-09-22) [External, High] |
| Releases / tags | `v0.2.0` — the only tag and the only GitHub Release, 2026-07-11 ("first tagged release," cut to mark the solo performance-optimization campaign) [Verified via API + CHANGELOG, High]. Post-tag window is Unreleased; CHANGELOG's scope window ends 2026-08-19 — five weeks of HEAD commits are outside its coverage [Verified, High] |
| Last push | HEAD commit 2026-09-22 10:50:19 -0400; GitHub API `pushed_at` 2026-09-22T14:53:51Z [Verified/External, High] |
| Maintainer | Single: Jeffrey Emanuel, per LICENSE copyright; README §"About Contributions" states "I do not accept outside contributions for any of my projects" — bus factor 1 with an explicit no-merge policy [Verified, High] |
| Inception | 2026-02-09 per CHANGELOG [Maintainer claim, High] |
| CI state at HEAD | Main `CI` workflow (fmt/clippy/check/`cargo test --workspace`): **completed, failure** on the HEAD push (2026-09-22T14:53:54Z). `Artifact Gates` workflow: completed, success on the same push. 14,589 total runs across workflows [CI-observed via GitHub Actions API, High] |

**HEAD note.** The pinned commit's message — `fix(repair): serialize and durably publish ownership lease mutations` — is itself evidence: at HEAD, the project is still fixing *durability of the repair subsystem's own mutations*. The durability story is being written in the present tense, not the past. [Verified from git log, High]

**Analyst method.** Fresh shallow clone of HEAD to `~/workspace/.scratch/frankenfs-verify/` (4,644 files). Read: README (TL;DR, pillar table, design philosophy, contribution and license sections), LICENSE verbatim, CHANGELOG head + version timeline, `docs/NEGATIVE_EVIDENCE.md` (head + the 2026-08-15 worker-scope section), `docs/reality-check-bridge-writeup.md` (full), `docs/MOUNTED_KERNEL_SCORECARD.md` + `docs/MOUNTED_BTRFS_SCORECARD.md` (headers + warnings), `FEATURE_PARITY.md` head, `rust-toolchain.toml`, workspace `Cargo.toml` members + lints, all four workflow files (name + gate inventory). Grep-verified: workspace member count, Rust file/line counts, fuzz-target count (63), `benches/`-dir file count (173, matches README's 2026-09-08 inventory), `forbid(unsafe_code)` at every crate root, every `unsafe` occurrence in first-party crates classified (all comments/doc-strings/string literals; zero real unsafe), vendored `fuser` unsafe presence, `todo!`/`unimplemented!` (zero in production code; one `#[cfg(test)]`-only stub), `MergeProofMechanism` variants, `ConflictPolicy` variants, `btrfs_full_transaction_commit` existence + size (~1,866 lines), `--btrfs-rw-ephemeral-ok` flag, asupersync 0.5.0 as a real workspace dependency, `ffs-repair` in-house RFC 6330 implementation (no external `raptorq` crate). GitHub API: repo metadata, tags, releases, recent workflow-run conclusions. Web search for independent coverage (benchmarks, reviews, production use) — negative result. **Not done:** did not compile, run tests, execute the server/CLI, mount any image, reproduce any benchmark, or run any fuzz target; did not run the actions logs per-job (workflow-level conclusions only). Behavioral and performance claims below rest on the maintainer's own executed evidence (single-host, dated) plus the in-tree audit docs.

## 4.2 Executive verdict

FrankenFS is a **genuinely real, mountable, clean-room Rust reimplementation of ext4 and btrfs** [Inference, High] — not vaporware: a fresh shallow clone of HEAD confirms 22 workspace members and 663,710 lines of first-party Rust [Verified, High]; every crate root carries `#![forbid(unsafe_code)]` backed by a workspace-level `unsafe_code = "forbid"` lint [Verified, High]; the vendored `fuser` 0.17.0 transport (ABI 7.42) is explicitly outside the unsafe ban and contains real unsafe code, which the README states rather than hides [Verified, High]. Real capability exists where it matters most for an inspector/forensics story: ext4 read+write with JBD2 attachment on the CLI mount path, the btrfs durable-commit serializer (~1,866 lines) that the May-2026 reality check found was a *silent-data-loss facade* and that August-2026 commits repaired — the scorecard names the root causes: commit `839eb708` could not serialize its own leaves (fsync EINVAL, nothing persisted above ~18 MiB/transaction) and commits `241093de`/`9d64f4a1` let a failed ENOSPC write destroy data (`docs/MOUNTED_BTRFS_SCORECARD.md`) [Verified code exists, High; durability-correctness Maintainer claim, Medium], block-level MVCC with a 5-variant merge-proof taxonomy and expected-loss conflict arbitration [Verified enums, High], and an in-house RFC 6330 fountain-code self-healing subsystem (`ffs-repair`, 31,572 lines) [Verified, High]. The evidence apparatus is the project's most original artifact: a 20,556-line negative-evidence ledger, a parity report whose own 97/97 number is printed with a self-disavowal ("not an executed-test result or a readiness score"), mounted scorecards carrying all-caps anti-hype warnings, and the 2026-08-15 worker-scope re-scoping that admitted 166 published benchmark rows cannot prove which machine they ran on [Verified, High]. **But:** ext4 read-write is experimental ("use on data you can lose"; not production-ready for irreplaceable data, README) [Maintainer claim, High as a statement of limits]; btrfs read-write is guarded-experimental with a very recent history of durability breakage (EINVAL on fsync, data never persisted above ~18 MiB per transaction, ENOSPC destroying data — all August 2026) [Maintainer-admitted, High]; the main CI workflow is **red at HEAD** (completed failure, 2026-09-22) while Artifact Gates pass [CI-observed, High]; CHANGELOG coverage lags HEAD by five weeks [Verified, High]; and there is **zero independent validation** — no third-party benchmark, review, or production deployment found [External, High within recall]. The MIT+OpenAI/Anthropic-rider license withholds *all* rights — including benchmarking and analysis — from OpenAI, Anthropic, their affiliates, and anyone acting for them [Verified verbatim, High]: it is **not OSI open source**. The single most important ceiling is the governance compound: bus factor 1, an explicit no-contributions policy, and the rider together cap adoption, contribution, and independent validation all at once. **NODUS: Explore.** The defensible niche is a userspace laboratory for filesystem concurrency-control and repair-policy experiments on real on-disk formats — not a production filesystem [Inference, Medium].
## 4.3 Claim inventory: demonstrated vs aspirational

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

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1 | 22-member workspace (21 crates + `tools/ffs-ops`), strict DAG, edition 2024, pinned `nightly-2026-08-31` | **Demonstrated** | [Verified, High] — `Cargo.toml` members enumerated; `ffs-ext4`/`ffs-btrfs` explicitly commented as legacy extraction references |
| 2 | `#![forbid(unsafe_code)]` in all first-party crates | **Demonstrated** | [Verified, High] — every crate root carries the gate (incl. both bin crates); workspace lint `unsafe_code = "forbid"`. All `unsafe`-word hits in first-party code classified individually: comments, doc-strings, string literals. Zero real unsafe. Vendored `fuser` excluded and does contain unsafe (`channel.rs`, `io_uring.rs`, `ll/`, `mnt/`) |
| 3 | "97/97 feature rows" (`ParityReport::current()`) | **Stale-adjacent, explicitly self-limited** | [Verified, High] — README prints the badge and immediately adds: "that number is not an executed-test result or a readiness score." FEATURE_PARITY.md (2026-09-08/11/12 audits): counts are "legacy declared-contract counts"; execution binding covers nine mapped ext4 contracts; seven canonical gate commands all report `not_implemented` (no gate tests exist in any owning crate yet) |
| 4 | No `todo!()`/`unimplemented!()` in production code — and the ban is self-enforced | **Demonstrated** | [Verified, High] — strict repo-wide grep (any position, comments excluded): the single `unimplemented!` hit (`ffs-fuse` lib.rs:10033, "no test drives passthrough") sits inside a `#[cfg(test)] mod tests` stub; the only other hits are string literals in the harness's own `FUZZ_TARGET_HARD_EXIT_PATTERNS` list (`ffs-harness/src/fuzz_smoke.rs`), which *bans* `todo!`/`unimplemented!`/`panic!` in fuzz targets. Zero in non-test code |
| 5 | Real ext4 read+write, durable, kernel-validated; JBD2 chain attached on the CLI mount path | **Partially demonstrated** | [Maintainer claim, corroborated by in-repo reality checks, Medium] — May-2026 bridge reality check: "genuinely real, working ext4 filesystem... durable and validated against the kernel's own debugfs/dumpe2fs"; Sept-2026 writeup: JBD2 chain, RAID5/6 read reconstruction, fast-commit crash-image e2e "real and committed"; `fuse_e2e` 244 passed / 0 failed (2026-09-22). Not independently reproduced; the main CI workflow is red at HEAD |
| 6 | btrfs read-write, durable by default via `btrfs_full_transaction_commit` | **Partially demonstrated** — **with a recently-broken history** | [Verified code exists, High] — ~1,866-line commit fn in `ffs-core`; `--btrfs-rw-ephemeral-ok` flag controls commit strategy (ephemeral tree-log-only vs full durable commit). [Maintainer claim on correctness, Medium] — May-2026 reality check found btrfs RW was a **silent-data-loss facade** (mutations against an in-memory CoW tree, `outcome="applied"` logged, nothing persisted); August commits document the durable commit failing to serialize its own leaves (`839eb708`: fsync EINVAL, nothing persisted above ~18 MiB/transaction), ENOSPC destroying data, tree-log/overlay hazards. Active repair, not settled infrastructure |
| 7 | Block-level MVCC: version chains, snapshot isolation, 5 merge-proof mechanisms, 3 conflict policies, expected-loss arbitration | **Demonstrated (mechanism exists); benefit claims are aspirational** | [Verified, High] — `ffs-mvcc` (32,831 lines); `MergeProofMechanism::{NoSameBlockMerge, AppendOnly, RangeOverlay, BitmapOr, BitmapDelta}` and `ConflictPolicy::{Strict, SafeMerge(default), Adaptive}` verified in code. The 9.5×-lower-expected-loss figure is a *historical 120-writer benchmark* — the README itself says it "does not establish that benefit for mounted workloads" [Maintainer self-limit, High] |
| 8 | RaptorQ self-healing (RFC 6330), Bayesian durability autopilot, 4 refresh policies, mounted repair | **Partially demonstrated** | [Verified, High] — `ffs-repair` (31,572 lines): in-house fountain-code implementation (no external `raptorq` crate; `codec.rs`, `symbol.rs`, `recovery.rs`, `scrub.rs`, `autopilot.rs`); mounted background repair requires explicit `--background-repair --background-scrub-ledger <jsonl>`. Healing under real corruption not independently verified; refresh-policy percentage gains are "benchmark-artifact scoped" per README [Maintainer claim, Medium] |
| 9 | asupersync 0.5.0 structured concurrency (`Cx`, regions, LabRuntime) | **Partially demonstrated (as a dependency; properties aspirational)** | [Verified, High] — `asupersync = { version = "0.5.0" }` in workspace deps; real dep of `ffs-core`/`ffs`/`ffs-repair`. README admits: "Complete explicit-context propagation and worker scoping remain implementation gaps"; CLI/FUSE workers also use standard threads; ambient `Cx::current()` gaps documented. No explicit tokio ban found in workspace lints — the weaker verified fact is "no tokio dependency anywhere in workspace manifests" [Verified, High] |
| 10 | 63 fuzz targets, 173 bench files, 125 E2E scripts, 226 insta snapshots, 23 evidence-event types | **Demonstrated (as inventory counts); the README itself disavows what they prove** | [Verified, High] — 63 fuzz-target files and 173 `benches/`-dir files counted directly; README: "File and enum counts are not evidence that checks ran or passed." [High on counts, N/A on what they prove] |
| 11 | Executed gates at HEAD: fmt/clippy PASS; `cargo test --workspace` 9,424 passed / 12 failed (2026-09-21); `fuse_e2e` 244/0 (2026-09-22) | **Partially demonstrated (maintainer-executed, single-host) — and the CI page agrees main is red** | [Maintainer claim, Medium] — `docs/reality-check-bridge-writeup.md`: the 12 failures were all `ffs-harness` integrity-manifest staleness (fixture/golden digests, fuzz-smoke pins, module census) plus harness-vs-environment artifacts; "none of the twelve observed failures touch filesystem correctness." [CI-observed, High] — GitHub Actions API: main CI workflow **completed/failure** at HEAD (2026-09-22T14:53:54Z); Artifact Gates completed/success. Independent verdict: HEAD is CI-red, whatever the classification of the failures |
| 12 | "Not production-ready for irreplaceable data" | **Demonstrated (as a candid stated limit)** | [Verified, High] — README: readiness lanes (xfstests, soak/canary, performance.baseline, swarm.responsiveness) are "mid-evidence." "Use this on data you can lose." The honesty is the point |
| 13 | Perf claims: 2.03× metadata walk; 1.85×–3.43× read ratios; ~1.4× fragmented file; 1.16× cold sequential | **Partially demonstrated, heavily caveated — and largely unquotable as "FrankenFS today"** | [Maintainer claim, Medium] — verified present in the gauntlet scorecards (`docs/progress/perf-gauntlet-scorecard-cc.md:132` 2.03× metadata walk vs kernel find+stat; `docs/progress/perf-gauntlet-scorecard.md:99` read ratios; cc.md:371 fragmented-file ~1.4×; cc.md:313 cold sequential 1.16×). The project's own docs are the prosecution: only four ext4 rows (readdir+stat, parallel read, warm stat, create/delete storm) describe the current ELF; **"no figure below EXCEPT [those four] may be presented as 'FrankenFS today' until it is re-measured on a current ELF"**; the btrfs fsync "win" (0.449–0.463x) flips to a 1.49x **loss** when both arms run on loop devices — "a 3.2x swing from transport alone. Do not quote them as filesystem wins"; the 2026-08-15 worker-scope audit: **166 KEEP rows quote a ratio and name no host** (13.6x same-cell swing observed; ratchet may only fall). Measured with real discipline; comparable with almost nothing |
| 14 | Hand-rolled RFC 6330 codec rather than a library | **Demonstrated** | [Verified, High] — no `raptorq` crate in any workspace manifest; the codec is first-party (`symbol.rs`, `codec.rs`, `lrc.rs`). Brave choice; unreviewed fountain-code implementations are a correctness risk surface in themselves [Inference, Medium] |

## 4.4 Architecture (reconstructed, not summarized)

[Verified from the clone — `Cargo.toml` members, crate-root gates, targeted greps; README diagrams treated as claims where noted]

**Crate topology (22 workspace members):** `ffs-types`/`ffs-error` (newtypes, errno-mapped errors) → `ffs-ondisk` (pure parsers, no I/O — fuzz-friendly) → `ffs-block` (ARC/S3-FIFO cache, io engines) / `ffs-journal` (JBD2 replay, ext4 fast-commit, external-journal pairing) / `ffs-mvcc` (32,831 lines: version chains, snapshot isolation, the 5-variant merge-proof taxonomy, expected-loss `ConflictPolicy`) → `ffs-btree`, `ffs-alloc` (mballoc-style buddy allocator, Orlov spreading), `ffs-inode`/`ffs-dir` (htree, case-folding, CRC32C), `ffs-extent`, `ffs-xattr` → `ffs-btrfs` (tree/chunk mapping, tree-log replay, **in-memory CoW tree + serializer + the ~1,866-line `btrfs_full_transaction_commit`** in `ffs-core`) → `ffs-core` (126,013 lines — the largest *filesystem* crate: the OpenFs orchestrator, FsOps, staged/visible/durable epoch FSM, degradation/backpressure) → `ffs-fuse` (vendored-`fuser` adapter, ABI 7.42) / `ffs` facade → `ffs-repair` (31,572 lines: in-house RFC 6330 codec, ScrubDaemon, DurabilityAutopilot, repair-writeback serializer, ownership leases) → tooling (`ffs-cli` bin with mount/inspect/info/fsck/repair commands, `ffs-tui`, `ffs-harness` — 122 files / 208,434 lines, ~31% of the whole workspace and the largest crate overall — `tools/ffs-ops`). `ffs-ext4`/`ffs-btrfs` remain as legacy extraction references, explicitly off the runtime path. The dependency graph is a strict DAG [Verified from manifest comments + README, High].

**Data flow (read):** FUSE kernel request → vendored `fuser` (unsafe transport, outside the forbid boundary) → `ffs-fuse` adapter → per-request MVCC snapshot + backpressure admission (`ffs-core`) → flavor dispatch (ext4 extent/btree path vs btrfs tree/chunk mapping) → `ffs-block` cache → release snapshot. **Write:** allocation + extent/tree updates staged into the current MVCC transaction → commit with merge-proof/FCW conflict resolution under the adaptive expected-loss policy → JBD2 journal integration (ext4) or full-transaction commit (btrfs) → repair-symbol maintenance. Sync model: `flush` is non-durable; `fsync`/`fsyncdir` are the durability boundaries; kernel FUSE `writeback_cache` is opt-in only behind `--rw --writeback-cache` plus three accepted-artifact gates, a matching host/lane manifest, and a disarmed kill switch — the epoch state machine (`staged ≥ visible ≥ durable`) with six formal invariants (I1–I6) and a 12-scenario crash/replay artifact gate [README + code-structure, Medium on runtime behavior — not executed by analyst].

**Memory-safety posture** [Verified, High]: the workspace lint table sets `unsafe_code = "forbid"` and every crate root (lib and both bin targets) carries `#![forbid(unsafe_code)]`. The transport boundary is explicit and honest: vendored `fuser` is excluded from the workspace and contains real unsafe (`channel.rs`, `io_uring.rs`, `ll/`, `mnt/`). There is one `#![unsafe(no_mangle)]` mention in `ffs-cli` main.rs — but it appears inside a doc comment explaining why a symbol is *not* exported (verified: the comment says exporting "needs `#[unsafe(no_mangle)]` and this crate forbids unsafe," i.e., the design choice is documented, not an exception). Runtime soundness thus rests on the vendored transport plus the pinned dependency surface (asupersync 0.5.0, blake3, crc32c, rayon, serde, tracing) — all workspace-pinned exact versions [Verified, High].

**README-vs-code drift (governance signal):** the tree moves faster than the docs. CHANGELOG's scope window ends 2026-08-19 while HEAD is 2026-09-22 (five weeks uncovered). README still prints the 2026-09-08 inventory (63/173/125/226 — verified still accurate: 63 fuzz files, 173 `benches/` files counted). The README pillar table simultaneously says btrfs is "guarded experimental write" (comparison table) and "experimental but durable" (FAQ) — coherent with the `--btrfs-rw-ephemeral-ok` guard, but two different framings in one doc. None of this is concealment — the same README publishes the worker-scope re-scoping and the transport-confound analysis — but it confirms docs chronically trail a 5,000+-commit tree. [Verified, High]

**The ffs-harness question:** `ffs-harness` is 122 files / 208,434 lines — roughly a third of the workspace. The May-2026 audit's description (~80% meta-machinery: proof bundles, readiness labs, campaign brokers) is consistent with the file inventory. This is the methodology-export lens made physical: the evidence apparatus is larger than the filesystem subsystems it evidences. Whether that is rigor or bloat depends on whether the apparatus ever audits anything but itself — currently it does not. [Verified inventory, High; judgment Inference, Medium]
## 4.5 Benchmark and conformance audit

### Maintainer-produced numbers

| Workload | Claimed ratio (FrankenFS ÷ kernel) | Method controls | Would it survive an independent rerun? |
|---|---|---|---|
| Metadata walk vs kernel find+stat | **2.03×** | Pinned ELF `913c36a4…` (PGO `b30de364…`, x86-64-v3 attested), 2026-08-08, external-load gate | One of the four rows that describe HEAD; the most defensible number in the repo — but single-host, single-invocation, and the host itself is unattributed in the banked row |
| Parallel read | part of the 1.85×–3.43× read ratios | Same candidate, re-measured twice | Same caveat |
| Warm stat | "current" row | Same candidate | Same caveat |
| Create/delete storm | **current** (post `bd-pbyu0` fix — `bd-*` IDs are the project's in-repo `.beads` issue tracker; ELF `edbaeb4e…`) | Re-measured on the fixed candidate | The honest re-measurement — but taken before the 2026-08-17 write-path work |
| ext4 fsync/journal, parallel metadata, bulk durable write, xattr | various | ELFs `f44b3dc4…`/`bcf2bc80…` (Jul 30–Aug 5) | **No** — the scorecard itself forbids quoting them as "FrankenFS today": they predate the 2026-08-17 write-path work (`bd-fv9tc` took ext4 from 5.00 to 3.00 blocks per client fsync vs kernel's 4.00 — write amplification 1.250x → 0.750x), were taken under a leaked-inode accounting bug (`bd-bhh0i`/`bd-pbyu0`), and the binary they describe "no longer exists in the tree" |
| btrfs fsync/journal commit | **0.449–0.463x** ("2.2x faster", admitted twice, ELF `c9fb745f…`) | Both A/A nulls clear, 5 runs | **No — transport artifact.** With both arms on a loop device (`--fuse-transport loop`): **1.491904x** — 1.49x *slower*. "A 3.2x swing from transport alone… Do not quote them as filesystem wins" |
| btrfs parallel metadata writes | **0.798200x** (1.25x faster, sign changed from 1.930090x loss) | 288 pairs, both A/A nulls clear, three readings within 2.9% | Provisional: same file-transport asymmetry applies to every durability-bound row in the file; the scorecard flags this |
| btrfs per-inode extent cache (~28× uncompressed random read, `bd-n5w92`) | **~28×** uncompressed random read vs prior self | Byte-identical, conformance 100/0/2 | Self-vs-self improvement, not vs-kernel; the residual 1.47x on compressed is decompression-bound |
| Historical 120-writer MVCC benchmark | **9.5× lower expected loss** (SafeMerge vs Strict) | Historical | README explicitly disavows mounted relevance: "does not establish that benefit for mounted workloads" |

**What would survive an independent rerun:** the *methodological confessions*, not the numbers. The worker-scope re-scoping (166 host-less KEEP rows, 13.6x swing, ratchet that may only fall), the transport-isolation analysis, and the four-current-rows accounting are the numbers most likely to survive — because they are the maintainer's own published losses and controls, and the doctrine says nobody publishes losses they can't defend [Inference, Medium]. Every headline win carries at least one of: stale ELF, transport asymmetry, host unattribution, or single-host/single-invocation scope. The project's own doctrine: a row that does not name its host "is valid *on an unrecorded machine*, never as comparable to a row measured elsewhere."

**Reproduction cost (honest):** a ~4,644-file checkout; build on pinned `nightly-2026-08-31` (the toolchain file documents exactly why the pin exists); the sanctioned bench path is a bespoke remote-execution setup (`rch exec`) with external-load gates, PGO profiles, and per-row provenance manifests. The 2026-09-21 reality check's own method section notes it executed "locally (rch fail-open); single-host evidence, not a fleet claim." An independent rerun needs equivalent quiet hardware, the reference ext4/btrfs images, and the fixture manifests — expect days, not hours, before the first admitted row.

### Conformance evidence

- **Kernel-differential parser validation:** ext4/btrfs parsers validated against real images with the kernel's own `debugfs`/`dumpe2fs` as oracle (May-2026 bridge reality check) [Maintainer claim, Medium]; metamorphic proptests in-tree [Verified presence, High].
- **Canonical gate binding:** seven gate commands bound to the execution-evidence path on **2026-09-11** (FEATURE_PARITY.md) — but all seven report `not_implemented` (no gate tests exist in any owning crate yet); the binding itself is pinned by `canonical_gates::tests::catalog_commands_equal_the_spec_document`, and remaining gate coverage stays open in `bd-wh1xk` / `bd-lc132` [Verified, High]. The honesty: a cargo filter selecting zero tests is classified `not_implemented`, *never a pass*.
- **xfstests:** tracked as a readiness lane, "mid-evidence" — not a result, a lane [Maintainer claim, High as a stated limit].
- **Fuzzing:** 63 targets exist [Verified, High]; execution history ("run continuously") not verified by analyst.
- **ubs scan (2026-09-21 reality check):** 498 files scanned, **254 critical findings** (Sept-8 baseline: 244), 17,559 info, runner `partial` — from the reality-check writeup itself (`docs/reality-check-bridge-writeup.md`); "No clean scan claimed; criticals include sampled false positives" per the Sept-8 audit. For a project whose headline is memory safety, 254 unresolved criticals on a partial scan is a finding that cuts both ways — the scan exists (rare), and it is red (honest). [Maintainer claim, Medium]

### Independent numbers

**None found.** Web search returns only the repository itself, its docs/commit pages, and the maintainer's own profile README [External, High within recall caveats]. No third-party benchmark, code review, or production deployment. **Independent validation: zero.**

## 4.6 Comparison: who owns the lane

**The incumbents** are the Linux kernel's ext4 and btrfs — production filesystems with decades of hardening, xfstests matrices, syzkaller fuzzing, CVE-response processes, and every operating system as a distribution channel [External, High]. FrankenFS does not compete with them and says so ("use on data you can lose"). **Why the incumbent wins today, in one paragraph:** switching costs for a filesystem are dominated by trust in durability, not format support — kernel ext4/btrfs have crash-consistency proofs written in production outages, repair tooling (`e2fsck`, `btrfs check`) refined over decades, and a global operator base; FrankenFS has a 1,866-line btrfs transaction commit whose own author documented it silently losing data five months ago, a red CI workflow at HEAD, and no production deployment anywhere. Nobody mounts irreplaceable data on a FUSE binary whose README says not to.

**Adjacent lanes:** **ext4fuse/fuse-ext2** (userspace ext4 readers — ext4fuse's original design is read-only for safety [External, High]; one fork adds experimental RW — own the "just read it" lane); **Rust parser/viewer crates** (format parsers and viewers, not mounts); **debugfs/dumpe2fs** (own the forensics lane today, and they are the kernel's own tools). **ZFS/bcachefs** own the self-healing-integrated-filesystem lane at the kernel level; **dm-integrity/LUKS** own the corruption-detection lane FrankenFS's scrub partially overlaps.

**The genuinely unoccupied lane [Inference, Medium]:** a *userspace laboratory for filesystem concurrency-control and repair-policy experiments on real on-disk formats* — mount the actual ext4/btrfs images your production systems use, swap the commit protocol (MVCC merge proofs vs JBD2's global lock), inject corruption and watch a Bayesian autopilot respond, all debuggable with gdb/perf without rebooting. Nothing owns it: kernel filesystems can't be experimented on without rebooting; FUSE readers can't write; filesystem research prototypes (e.g., academic userspace FSs) don't speak production on-disk formats. FrankenFS's combination — real formats + experimental commit/repair layers + a self-falsifying evidence culture — is pointed exactly at the gap. But it is a *research-tool* lane, not a product lane, and the license rider plus the no-contributions policy cap how far even that lane can go.

## 4.7 Technical merit and adversarial review

**Strengths:**
1. **Evidence discipline without peer in this program.** The 20,556-line negative-evidence ledger, the parity report that disavows its own headline number, the worker-scope re-scoping that voluntarily devalued 166 published rows, the scorecard that proves its own best btrfs win was transport, and the 2026-09-21/22 reality checks that published "main is test-red" with the failing tests enumerated — this is the methodology-export lens made concrete: if the filesystem fails, the honesty apparatus survives as a transferable artifact [Verified, High].
2. **Real implementation volume in the right places.** 663,710 lines with the mass in the orchestrator, the harness, the MVCC engine (32,831 lines), and a 31,572-line repair subsystem; a ~1,866-line btrfs transaction commit; JBD2 attachment on the ext4 write path; RAID5/6 read reconstruction with parity evidence; fast-commit crash-image e2e — this is not scaffolding [Verified volume, High; behavioral correctness Maintainer claim, Medium].
3. **The merge-proof taxonomy and the repair autopilot are genuine ideas.** Five executable same-block merge mechanisms with an expected-loss policy selector (Strict/SafeMerge/Adaptive), and a Beta-posterior durability autopilot over a hand-rolled RFC 6330 codec with four refresh policies — genesis-stage, unreviewed, but real code with real structure, not slideware [Verified, High].
4. **The unsafe boundary is honest and enforced.** Workspace-level forbid, every crate root gated, the vendored transport explicitly outside the boundary with its unsafe code named, and design choices that *avoid* needing unsafe documented in comments (the `no_mangle` case) [Verified, High].
5. **The differential method demonstrably works.** The 2026-09-22 reality check ran the syscall-conformance differential against a *true* reference (live kernel-ext4 loop mount, not tmpfs) and it exposed a masked real defect — `open_unlink_fd_lifetime` returning ENOENT — which was fixed the same session: orphan-inode handling via `s_last_orphan`, FUSE OPEN/CREATE/RELEASE counting, mount-time orphan recovery. The harness found a real POSIX bug and the project fixed it in public [Maintainer claim, Medium].

**Weaknesses:**
1. **Bus factor 1 with an explicit no-contributions policy.** "I do not accept outside contributions for any of my projects" — adoption cannot flow back into governance; no second maintainer can emerge through the normal path; review depth of 663,710 lines at 5,000+ commits over six months (~25/day) rests on one human plus agent personas [Verified, High].
2. **The durable-write path is newly built and recently broken.** btrfs RW was a silent-data-loss *facade* in May 2026 (mutations logged `outcome="applied"`, nothing persisted); the August repair commits document the root causes at commit granularity — `839eb708`: the durable commit could not serialize its own leaves, so fsync returned EINVAL and nothing persisted above ~18 MiB/transaction; `241093de` and `9d64f4a1`: a write failing with ENOSPC destroyed the data it could not replace (`docs/MOUNTED_BTRFS_SCORECARD.md`, commit-cited). This is active durability repair, not hardened infrastructure — and durability is the one property a filesystem cannot be wrong about [Maintainer-admitted, High].
3. **Zero independent validation of any kind.** No third-party benchmark, no code review, no production deployment, no external contributor. The main CI workflow is red at HEAD (2026-09-22). The ubs scan reports 254 criticals on a partial run. "CI exists" is not "CI is green," and here CI is not green [Verified/CI-observed, High].
4. **The performance story is unquotable.** Of the ext4 rows, only four describe the current ELF; of the btrfs durability rows, the headline win is a transport artifact; of the 166+ banked KEEP rows, none can prove its host. The honest summary is "some current-ELF read wins on one host, write rows stale or confounded, most of the ledger unattributed" — a much weaker thesis than any single number suggests [Verified from the project's own docs, High].
5. **Structural ceilings are real:** FUSE round-trip latency vs kernel (no serious claim to compete), pinned nightly toolchain (rustc 1.99) with edition-2024-only APIs, `ffs-harness` at ~31% of the workspace (the evidence apparatus is bigger than parts of the filesystem), a hand-rolled RFC 6330 codec that is itself an unreviewed correctness surface, and the same-maintainer sibling runtime asupersync 0.5.0 with admitted context-propagation gaps [Verified, High] — its fit is unproven even inside the FrankenSuite (sibling FrankenRedis evaluated and rejected it as a runtime [External, Medium]).
6. **Docs chronically lag the tree.** CHANGELOG's scope window ends 2026-08-19 at a 2026-09-22 HEAD; the btrfs story is told as both "guarded experimental write" and "experimental but durable" in the same README; each instance is minor, but the pattern is the governance signal the Rulebook asks for [Verified, High].

**Steelman of the bear case:** FrankenFS is an extraordinarily well-documented answer to a question the market never asked. Nobody needs a userspace ext4/btrfs with experimental commit protocols: forensics already has debugfs, repair already has e2fsck and btrfs scrub, and anyone who needs a new filesystem design builds it in the kernel or on a clean-slate format — not by reimplementing two legacy formats to bolt MVCC onto them. The block-level merge proofs solve a concurrency problem (concurrent same-block writers) that real filesystem workloads barely exhibit, because the page cache and VFS already serialize most of it; the RaptorQ autopilot solves a corruption-detection problem that dm-integrity solves at the block layer with kernel maintenance. The 663,710 lines at bus factor 1, with a red CI at HEAD and a license that legally excludes the labs most likely to evaluate it, point to the likeliest terminal state: a personal laboratory whose extraordinary diary outlives its code. The negative-evidence ledger is admirable; ledgers don't mount filesystems.

**Hook audit (the packet grades its own hook):** "A 663,710-line, mountable, unsafe-forbidden ext4/btrfs reimplementation in Rust — whose own 20,556-line negative-evidence ledger downgrades its benchmark claims faster than any outside critic could." Line count (663,710, comments included), mountability (FUSE mount path + `ffs mount` CLI), unsafe posture (workspace forbid, zero real unsafe in first-party crates, vendored transport explicitly outside), and both formats are verified; the ledger line count (20,556 lines) is verified; "downgrades its benchmark claims" is verified by the worker-scope re-scoping (166 rows), the transport-confound analysis, and the four-current-rows accounting. No marketing adjectives; every number is a counted number. The hook survives.
## 4.8 License and governance (material, not boilerplate)

**License text, read verbatim** [Verified, High]: `LICENSE` is the MIT License **with an "ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic)"** that is "part of the 'conditions' of this License" and "controls" in any conflict. Quoted scope: *"Restricted Parties" means OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative).* *"Notwithstanding any other provision of this License, no rights are granted to any Restricted Party. Any purported license, sublicense, assignment, transfer, or other permission to any Restricted Party is null and void absent the express prior written permission of Jeffrey Emanuel."* Disclosure/access to them is forbidden. Crucially, *"use" includes, without limitation: copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems.* The rider applies to the Software and all Derivative Works, must be included unmodified in any distribution, and breach "automatically and immediately terminates" all permissions — with injunctive relief and attorneys' fees reserved to Jeffrey Emanuel (copyright holder, 2026). **Classification: NOT OSI open source** — named-party discrimination with a use-restriction covering even benchmarking and analysis. This is source-available with a targeted exclusion. (GitHub's license detection reports NOASSERTION for the repo, consistent with a non-standard license text.)

**The rider as strategy:** it serves a defensive mission (preventing the two leading labs from absorbing 663,710 lines of work into training corpora or evaluation harnesses without permission) but sabotages the project's most credible futures. An independent benchmark publisher cannot touch the code without lawyering the rider first — which helps explain why independent validation is zero. A forensics vendor evaluating the inspector story inherits the same exposure. The README discloses the rider in its License section ("MIT License (with OpenAI/Anthropic Rider)") and the top badge reads "MIT+OpenAI/Anthropic Rider" — unlike FrankenRedis, whose competitor table said plain "MIT," the FrankenFS badge is at least not hiding it. But the compound with the **no-contributions policy** ("I do not accept outside contributions for any of my projects") is the real ceiling: the rider blocks the labs, the policy blocks everyone else. The only permitted relationship with this codebase is to read it. Adoption ceiling: hard.

**Governance:** owner-directed single maintainer; no visible external contributors; the `.beads` issue tracker (2,859 closed / 45 open raw rows as of the 2026-05-18 CHANGELOG snapshot — itself stale) is the planning surface; commit velocity 5,000+ commits over ~6 months (~25/day; CHANGELOG accounts 3,448 through the 2026-05-18 cutoff plus 1,634 post-v0.2.0 through 2026-08-19, excluding the uncounted May–July performance campaign) with agent-persona commit conventions ("CrimsonFox (cc/opus)"). The 2026-09-21 reality check is both the strongest governance signal (a self-audit that published "main is test-red" with the failing tests enumerated) and the warning (integrity manifests drift silently because nothing runs the pins at commit time; a single JSON-formatting commit broke six harness targets). **What breaks first if velocity decays:** review depth is already the binding constraint — at this commit rate, one human cannot review 663,710 lines, so correctness already rests on the harness, not on review. If velocity decays without a successor, the pinned nightly ages, the harness rots (its pins are already the most breakage-prone part of the tree), and bit-rot sets in within quarters, not years. [Inference, High]

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness (TRL 1–9) | **4** (ext4 read/inspect/FUSE-read: 5–6; ext4 RW: 4; btrfs RW: 3) | Mounted, kernel-validated ext4 reads put the read lane at 5–6; experimental ext4 RW with a red CI at HEAD is a 4; btrfs RW with a silent-data-loss history repaired only months ago is a 3; the aggregate is the system, not the best lane |
| Strategic relevance (1–5) | **3** | Memory-safe userspace experimentation on real formats is a real strategic gap (forensics, FS research); capped by FUSE latency, single maintainer, and the rider |
| Impact potential (1–5) | **2** (4 for the methodology) | Drop-in value capped by experimental durability, no contributions, restrictive license; the *evidence discipline and MVCC/repair ideas* are the exportable impact |
| Implementation feasibility (1–5) | **2** as a product / **4** as a research tool | As an inspector/forensics tool and FS experiment lab: highly usable. As mounted production storage: no — "use on data you can lose" |
| Time to mainstream (1–5) | **1–2** | Would require governance, contributions, license normalization, independent validation, multi-year durability hardening — none on the roadmap; the roadmap is the maintainer's diary |
| Collaboration potential (1–5) | **1** | No-contributions policy + rider license + nightly toolchain + bus factor 1; issues and PRs are accepted only as illustrations the maintainer reimplements |

**Ring: Explore.** The ring rules are decisive: *Pilot* requires a release artifact plus a bounded real-workload fit. A tagged release exists (v0.2.0), and a bounded workload (forensic inspection, FS experiment lab) is conceivable — but HEAD's main CI workflow is failing, the maintainer's own readiness lanes are "mid-evidence," there is zero independent validation, and the no-contributions policy means no institution can adopt-and-improve. When in doubt, ring down. Explore is the default for substantive-but-unproven, and FrankenFS is its definition. Revisit triggers: main CI green at HEAD for a sustained window; a second tagged release covering the durability work; an independent benchmark, audit, or production deployment; any softening of the contributions policy.

## 4.10 Wardley placement

- **ext4/btrfs-compatible userspace read/mount/inspect:** Custom-built → early Product — the category "userspace ext4" is served by ext4fuse/fuse-ext2; FrankenFS's version is custom-built, validated against kernel tools, but pre-release in practice.
- **btrfs-compatible userspace read-write:** Custom-built, immature (TRL 3) — no commodity equivalent exists; the kernel is the incumbent and owns the lane outright.
- **Block-level MVCC with merge-proof conflict arbitration:** **Genesis → early custom-built** — no known equivalent in any production filesystem; moves right if the merge-proof protocol is formalized and adversarially validated (see next step 2), left into obscurity if the 9.5× figure never leaves the historical benchmark.
- **RaptorQ self-healing + Bayesian durability autopilot:** **Genesis** — fountain codes exist (RFC 6330), but this packaging (per-block-group symbols, Beta-posterior autopilot, four refresh policies, scrub-ledger evidence trail) has no known equivalent; moves right with an independent corruption campaign (the transport-confound isolation protocol of packet next step 4, applied as a corruption-injection protocol).
- **Evidence-ledger / self-falsifying claim apparatus:** Custom-built — novel as a published discipline and the most transferable component; moves toward Product the moment a second project adopts it (see next step 1).
- **asupersync structured-concurrency runtime as FS substrate:** Genesis — unproven outside the sibling suite; sibling FrankenRedis evaluated and rejected it as a runtime ("would be an architectural rewrite"), so its fit is not established even inside the FrankenSuite. Moves right only if the admitted `Cx`-propagation gaps close.

**The decoupling lens:** FrankenFS represents *format-from-kernel* (behavior extracted from ~205K lines of Linux v6.19 C, re-implemented in safe Rust — the reimplementation decoupling), advances *commit-protocol-from-filesystem* (MVCC merge proofs as a swappable concurrency layer rather than JBD2's global lock or btrfs's COW), and *repair-policy-from-scrub* (the Bayesian autopilot as a decision layer above raw redundancy). The deepest decoupling it gestures at is **evidence-from-claim**: the parity report, the worker-scope ratchet, and the transport-confound analysis are a mechanism for separating what a system *demonstrates* from what its README *declares* — and that mechanism is the component most likely to outlive the filesystem.

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

- **12 months:** continued single-maintainer velocity; btrfs durable-commit stabilizes or regresses again (the August history suggests at least one more durability incident before it settles); possible second tagged release; main CI presumably green again at some point (the Sept-22 redness is harness-integrity, not filesystem rot); more honest negative evidence; stays in Explore. The realistic ceiling is "best-in-class userspace ext4/btrfs inspector + FS experiment lab."
- **24 months:** bifurcation. **Upside:** a forensics vendor or FS researcher engages (the inspector story is the credible wedge — `ffs inspect` doesn't need durability), the merge-proof protocol gets formalized or the RaptorQ autopilot gets an independent corruption campaign, and the evidence apparatus is adopted by a second project — credible research tool with a niche, possibly a paper. **Decay:** velocity slows with no successor; the pinned nightly ages past usability; the 663,710-line tree with its 208,434-line harness becomes unmaintainable; drifts to Monitor as a research artifact whose diary outlives its code.
- **60 months:** binary. Either a niche-but-real artifact (the memory-safe, evidence-carrying inspector/experiment substrate — the "gdb for filesystems" lane, still unbuilt by anyone), or superseded in every lane it touches: kernel tools absorb the forensics need, bcachefs/ZFS absorb the self-healing conversation, and the general "safe systems" conversation moves to Rust-native clean-slate formats. The verification methodology is the more likely survivor either way.

**Revisit triggers (concrete, observable):** main CI workflow green at HEAD for a sustained window (not one run); a second tagged GitHub release that covers the btrfs durability work; any independent benchmark, security audit, or production/forensic deployment; a second human with merge rights (or any softening of the no-contributions policy); any change to the license rider; the `bd-wh1xk`/`bd-lc132` open beads closing (full parity execution binding); xfstests results published as a lane, not a hope.

## 4.12 Limitations and open questions (mandatory)

**Not done:** did not compile the workspace (a full `cargo test --workspace` is a multi-hour build on the pinned nightly), run any test, start the CLI, mount any image, execute a benchmark, or run any fuzz target — all behavioral and performance claims rest on maintainer-executed evidence (single-host, dated 2026-09-21/22) plus the in-tree audit docs. Shallow clone only (no history beyond HEAD). GitHub Actions conclusions are workflow-level (completed/failure, completed/success), not per-job; the specific failing CI jobs at HEAD were not enumerated. Star/fork counts from the GitHub API (live read, 2026-09-22). The legacy `legacy_ext4_and_btrfs_code/` kernel corpus is gitignored and was not inspected. Web search for independent coverage carries the usual recall caveats.

**Open questions that would most change the verdict:** which CI jobs fail at HEAD and why (harness-integrity vs real); upstream-Tcl-style pass/skip/fail counts for the syscall-conformance differential; whether the btrfs full-transaction commit survives an independent fault-injection campaign; whether any enterprise has evaluated the rider's legal exposure; funding and succession intentions of the maintainer; whether the 254-critical ubs scan converges or grows; what happens to the tree when the nightly-2026-08-31 pin ages out; whether the seven canonical gates ever get real tests (all currently `not_implemented`).

## The eight deepening questions (one paragraph each)

1. **Provenance.** A filesystem's artifacts are files and blocks, and FrankenFS records nothing about *who or what produced* any of them: images carry no producer attestation, repair symbols carry no origin, and the evidence schema's 23 event types describe *check outcomes*, not artifact lineage [Verified schema exists, High]. The one proto-provenance mechanism is the `--background-scrub-ledger <jsonl>` trail, which records corruption observations and repair decisions durably — but it is not tamper-evident by construction: a hostile operator with disk access could rewrite the durability story undetectably [Inference, Medium]. Making attestation portable would require signing evidence bundles and hash-chaining the scrub/repair trail at write time. The irony the project would appreciate: its honesty apparatus has no defense against a dishonest operator.

2. **The embeddable unit.** The smallest useful adoptable piece is the `ffs inspect`/`ffs info` path — `ffs-ondisk` (pure parsers, no I/O, fuzz-friendly) plus the CLI's JSON inspection output — which is a forensics/inspector tool needing no mount, no FUSE, no durability story at all [Maintainer claim on the commands, Medium; parser purity Verified, High]. The adoption cost is the whole workspace checkout (vendoring 421 files of nightly-only Rust), the rider license following every derivative, and the pinned nightly toolchain — but unlike the mount path, the inspector path inherits none of the durability risk, which is why it is the credible wedge. The MVCC and repair crates are the *interesting* embeddable units and the *wrong* ones to adopt today: they are the least settled code in the tree [Inference, Medium].

3. **Unexercised option value.** The architecture holds at least four unused capabilities: the pure-parser crates (`ffs-ondisk`) plus the golden-JSON conformance fixtures are one packaging step away from a **filesystem-image forensics library** with kernel-differential validation — a product the tree already 90% contains; the per-core FUSE transport is "wired in source" but its mounted correctness/speedup is unproven, an entire performance story sitting dark; the experimental `--experimental-sharded-*` paths and adaptive mount-runtime modes (`standard`/`managed`/`per-core`) are concurrency stories the default loop doesn't use; and the evidence-event schema (23 types) plus the claim-gating machinery is a general **honesty-as-a-service** harness currently aimed only at itself [Verified, High]. What unlocks them is, respectively, a stable-Rust inspector crate release, a mounted per-core evidence campaign, a decision on the adaptive modes' observable-behavior guarantees, and a documented decoupling of the harness from the bead tracker — all product decisions, none blocked on research [Inference, Medium].

4. **Benchmark honesty.** The numbers most likely to survive an independent rerun are the *adverse and methodological* ones — the 3.2x transport swing, the 13.6x worker swing, the 166 host-less rows, the four-current-rows accounting, the published "main is test-red" finding — because they are the maintainer's own published confessions with documented methodology, and nobody publishes confessions they can't defend [Inference, Medium]. The headline wins (2.03× metadata walk, 1.85×–3.43× read ratios, ~1.4× fragmented file, 1.16× cold sequential) have the strongest method of any numbers in the repo (pinned ELF, PGO attestation, external-load gates) but are load-bearing for the performance thesis *and* single-host, single-invocation, host-unattributed rows — so the thesis currently rests on numbers that the project's own doctrine says are "valid on an unrecorded machine, never comparable" [Verified doctrine, High]. The one number with genuine current-ELF standing is the create/delete storm re-measurement, and even it predates the 2026-08-17 write-path work.

5. **The governance path.** There is no credible route from one maintainer to an institution under the current policy set, and that is the finding: the no-contributions policy ("I do not accept outside contributions for any of my projects") explicitly forecloses the normal succession path (users → contributors → maintainers), and the rider legally excludes the labs most likely to fund or adopt the work [Verified, High]. The only credible path is a policy change the maintainer has pre-rejected, or a fork — and a fork inherits the rider, the nightly pin, and 663,710 lines with no second human who understands the dispatch chain. What breaks first if velocity decays is not the code but the harness: the 2026-09-21 reality check already found the integrity pins drifting silently because nothing runs them at commit time, so a slowdown doesn't stabilize the project — it strands the evidence apparatus first and the filesystem second [Inference, High].

6. **The license as strategy.** The rider excludes exactly OpenAI, L.L.C., Anthropic, PBC, their affiliates, and anyone acting for, benefiting, or under the direction of them — and it defines "use" to include benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination and injunctive relief reserved to Jeffrey Emanuel [Verified verbatim, High]. As strategy it is coherent defensively (it prevents the two labs best positioned to absorb the work from doing so without permission) and self-sabotaging offensively: the project's most credible wedge is the inspector/forensics story, whose buyers are enterprises and vendors that cannot tolerate a license whose "use" definition forbids *analyzing* the software, and the zero independent validation is partly explained by the rider itself — no third party can publish a benchmark without lawyering the exclusion first. Compounded with the no-contributions policy, the license doesn't just cap adoption; it caps the *evidence* the project needs to mature [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick FrankenFS over debugfs or e2fsck is an agent-driven forensics or filesystem-experiment loop: an agent that mounts an ext4/btrfs image, runs a scripted corruption/repair campaign, and needs machine-readable evidence bundles (the 23 event types, the JSONL scrub ledger) rather than human-readable tool output — the `ffs` CLI already emits JSON, and the harness already thinks in evidence events [Inference, Medium]. What would have to become true first: a stable-Rust build (agents can't be asked to install nightly-2026-08-31), a license an agent-platform company can sign (the rider currently forbids the labs from even *analyzing* the code), and the btrfs durability story settled (an agent that loses data it was told was durable is worse than no agent). The experiment-lab lane — agents testing commit protocols against real formats — is the deeper fit, but it needs the merge-proof protocol formalized before an agent can trust it [Inference, Medium].

8. **The kill test.** The single event that would falsify the core thesis — "a memory-safe userspace laboratory for real-format filesystem experiments is worth building" — is the kernel community or a funded project shipping the experiment surface natively: e.g., btrfs gaining a userspace transaction-injection test harness, or e2fsprogs shipping a scriptable, machine-readable inspection/repair API with evidence bundles, would commoditize FrankenFS's two credible wedges (inspector, experiment lab) with institutional maintenance and clean licenses, leaving the 663,710-line tree competing purely on implementation — a fight it cannot win at bus factor 1 with a red CI [Inference, Medium]. The experimental falsifications are nearly as decisive: an independent fault-injection campaign that finds a lost-but-acked write in the btrfs commit path (collapsing the durability claim), or a second FUSE filesystem adopting the transport-isolation protocol and showing the confound analysis doesn't generalize (collapsing the methodology claim) — either would take down one of the two pillars the packet's verdict stands on [Inference, Medium].

---

**Working notes:** clean shallow clone at `~/workspace/.scratch/frankenfs-verify/` (HEAD `49acf5d5a9b7d48d7d459e28bb5a32e8546900b6`, 2026-09-22 10:50:19 -0400). All Quick-Link URLs verified resolving (HTTP 200, 2026-09-22). GitHub Actions API: CI workflow completed/failure at HEAD, Artifact Gates completed/success, 14,589 total runs. No durable user-facing files created besides this assessment and its versioned intermediates.