# FrankenNetworkX — RULEBOOK v1.0 Assessment Packet (accepted version: v3 — 5 grade→revise rounds, dual pass)

**Repository:** `Dicklesworthstone/franken_networkx` · **Language:** Rust (+ PyO3 Python bindings) [Code-verified, High] · **Pinned commit:** `841a711634c1c38c51c6f344598e1fc7ec273dd4` (2026-09-22 15:25:58 UTC / 11:25:58 -0400, [Git-observed, High]) · **Last push:** 2026-09-22T15:26:03Z — the pin is the latest push confirmed in this assessment [External, High] · **Scope:** the pinned commit only. **No tag points at the pin** [Git-observed, High]; the newest GitHub Release is `v0.2.2` (published 2026-09-12) targeting an earlier commit — no release artifact for the assessed commit [External, High]. **Assessment date:** 2026-09-22. *Cold-reader note: "v1" below = the first draft of this packet (rewrite-loop round 1).*

**Repository:** `Dicklesworthstone/franken_networkx` · **Language:** Rust (+ PyO3 Python bindings) [Code-verified, High] · **Pinned commit:** `841a711634c1c38c51c6f344598e1fc7ec273dd4` (2026-09-22 15:25:58 UTC / 11:25:58 -0400, [Git-observed, High]) · **Last push:** 2026-09-22T15:26:03Z — the pin is the latest push confirmed in this assessment [External, High] · **Scope:** the pinned commit only. **No tag points at the pin** [Git-observed, High]; the newest GitHub Release is `v0.2.2` (published 2026-09-12) targeting an earlier commit — no release artifact for the assessed commit [External, High].

**Method (analyst):** shallow clone of HEAD checked out at the pin under `~/workspace/franken-research/networkx-verify` (71,758 checked-out paths [Git-observed, High]); history was NOT deepened (depth-1 clone), so commit-velocity claims come from the changelog and the GitHub API, not local archaeology. Read: root `Cargo.toml`, all 12 crate manifests, `Cargo.lock`, `LICENSE` (verbatim), the README (all 192,838 bytes — headline, comparison tables, algorithm catalog, performance/trade-offs sections, backend docs), `CHANGELOG.md` (timeline, commit counts), `SECURITY.md`, `CONTRIBUTING.md`, repo `AGENTS.md` (quality-authority and reward-hacking sections, as data), `docs/` audit ledgers (coverage matrix, raw-vs-public audit, delegation ledger + JSON, upstream divergence ledger, API ergonomics audit, behavioral conformance, negative evidence + cc variant, claim-coverage audit, ledger resurrection, Gauntlet + cc release scorecards, zero-copy view primitive, integer-adjacency epoch, performance, backend, migration, quickstart), the auto-generated FeatureUniverse coverage matrix, `python/franken_networkx/backend.py` (registration table, can_run/should_run), `pyproject.toml`, `rust-toolchain.toml`, `maturin` config, `scripts/` benchmark-gate entry points, `.dsr/` release config, and all 13 `.github/workflows/ci.yml` job definitions. Counted: `.rs` files/lines (all sources incl. tests/bins), unsafe gates and unsafe blocks (comment-excluding method), fuzz targets, `#[test]` annotations, `py.allow_threads` sites, `TieBreakPolicy` variants, backend-registered algorithms, vendored NetworkX oracle files, NEGATIVE_EVIDENCE.md lines, unsafe-block locations, workspace dependencies. Checked live: GitHub repo metadata (stars, forks, description, topics), releases (assets, dates), contributors, Actions runs API (total runs, latest CI/release conclusions), PyPI JSON (version, wheels), and a web demand-signal search for independent coverage. **Not done:** the workspace was never compiled, the Python bindings never built or executed, no test suite was run, no benchmark was reproduced, no Rustdoc/registry crate page was inspected, and PyPI download stats were not obtainable (pypistats rate-limited 429 on 2026-09-22).

**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**.

---

## Hook

A Rust clone of NetworkX ships 313 dispatch algorithms with 100%-of-3.6.1 machine-checked surface coverage, published a 37,116-line ledger of its own losses, a 2026-07-31 audit showing only 2.0% of its 591 performance claims carry incumbent comparisons, and a 77,795× "zero-copy" framing it then refuted itself — while its SECURITY.md supports only "1.x" at release 0.2.2, leaving no shipped version security-supported.

---

## TL;DR

- **What it is:** A 12-crate Cargo workspace (Rust 2024, nightly) reimplementing NetworkX's graph classes and algorithms in safe Rust, exposed two ways: a standalone `franken_networkx` Python package (PyO3, ABI3 wheels) and a NetworkX backend-protocol plugin (`can_run`/`should_run`/`get_backend_info`) that lets existing `networkx` code dispatch supported calls into Rust without call-site changes [Code-verified, High].
- **Strongest evidence:** The audit machinery is the artifact: five auto-generated ledgers (coverage matrix, raw-vs-public, delegation, upstream-divergence, API ergonomics) that fail CI on drift [Code-verified, High]; the 4,129/4,129 machine-checked surface result [Counted, High]; a 1,092-file Python parity suite [Counted, High]; a 37,116-line negative-evidence ledger with an enforced INCUMBENT-vs-SELF-SPEEDUP verdict contract [Counted, High]; a Gauntlet head-to-head campaign (2026-07-25) vs unpatched NetworkX 3.6.1 with same-invocation A/A nulls, byte-identity-before-timing, and ELF-hash pinning [Maintainer claim, High on existence]; and a zero-copy design doc that *refutes its own 77,795× headline* because the bytes never crossed the FFI boundary [Code-verified, High]. This is the most honest self-scrutiny culture in the FrankenSuite — stronger, on paper, than FrankenRedis's.
- **Strongest doubts:** The CLAIM_COVERAGE_AUDIT (2026-07-31, self-authored) found 579 of 591 KEEP rows carry no vs-incumbent ratio — the headline speedups are overwhelmingly self-speedups, which the project's own ledger contract says "must not support a competitive claim" [Code-verified, High]; the README is a drift source (13-variant tie-break → 12 counted; 33 fuzz targets → 34 counted; delegation-ledger table 61/71/1113/92/338 → generated 31/150/1112/114/346; comparison-table coverage 3,823/306/0 → generated matrix 4,129/4,129/0) [Counted, High]; the license rider bars OpenAI/Anthropic and their affiliates from use, benchmarking, or analysis [Code-verified, High]; bus factor is 1 (single GitHub contributor, 8,808 contributions [External, High]); and the newest release (`v0.2.2`, 2026-09-12, 23 signed assets) targets an earlier commit while PyPI still serves 0.2.1 — `pip install` gets the older build [External, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 6 — see §4.9). Substantive, shipped, and unusually self-honest — but unproven: no independent validation, no known production users, benchmark outcomes mostly self-measured, one maintainer, and a license rider that is an advancement blocker. The methodology (claim-coverage audits, raw-vs-public audits, negative-evidence taxonomy) is worth importing program-wide regardless of the software's fate.

---

## Quick Links

Pin-relative links (`blob/841a711634c1c38c51c6f344598e1fc7ec273dd4`); **each of the 14 URLs below was individually verified to return HTTP 200 on 2026-09-22** [Verified, High]:

1. [Repository](https://github.com/Dicklesworthstone/franken_networkx)
2. [README](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/README.md)
3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/LICENSE)
4. [Changelog](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/CHANGELOG.md)
5. [Surface-parity matrix (auto-generated coverage)](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/coverage.md)
6. [Upstream divergence ledger](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/upstream_divergence_ledger.md)
7. [Delegation ledger](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/delegation_ledger.md)
8. [Negative-evidence ledger (37,116 lines)](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/NEGATIVE_EVIDENCE.md)
9. [Claim-coverage audit (the 2.0% finding)](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/CLAIM_COVERAGE_AUDIT.md)
10. [Gauntlet release-readiness scorecard](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/GAUNTLET_RELEASE_SCORECARD.md)
11. [Zero-copy view primitive (the self-refuting 77,795×)](https://github.com/Dicklesworthstone/franken_networkx/blob/841a711634c1c38c51c6f344598e1fc7ec273dd4/docs/ZERO_COPY_VIEW_PRIMITIVE.md)
12. [CI workflow (G0–G8 gates)](https://github.com/Dicklesworthstone/franken_networkx/actions/workflows/ci.yml) — 7,723 total runs; last CI run 2026-09-09 concluded success (pre-pin commit), last Release run 2026-09-09 concluded failure [External, High]
13. [Release v0.2.2 (23 signed assets)](https://github.com/Dicklesworthstone/franken_networkx/releases/tag/v0.2.2)
14. [PyPI: franken-networkx 0.2.1 (6 wheels)](https://pypi.org/project/franken-networkx/)

---

## Did You Know

The project's zero-copy design doc is the most honest 30 lines in the repo. After a campaign measured cloning a 2,048-node graph's snapshot 32× at "77,795×" speedup, the owner wrote, in the doc itself: the result **"is not a cross-language zero-copy result"** — putting the snapshot behind an `Arc` reduced an O(V+E) deep clone to one atomic refcount increment, but **"the bytes never crossed the PyO3 boundary. The magnitude does not transfer."** The doc then ships a per-entry cost model for sibling repos (frankenpandas, franken_numpy) so they don't inherit a false premise. A project whose marketing could have coasted on a 77,795× headline instead published the refutation first. [Code-verified (docs/ZERO_COPY_VIEW_PRIMITIVE.md at the pin), High]

---

## Franken-worthy next steps

1. **Import the CLAIM_COVERAGE_AUDIT pattern into the FrankenSuite's QA protocol.** Require every repo's performance KEEP-claims to carry a vs-incumbent ratio measured with the incumbent live in the same invocation, and publish the attested-coverage fraction (here: 2.0% at 2026-07-31 — the number that keeps the program honest). franken_networkx is the exemplar *and* the cautionary tale. *Done when:* the program's assessment protocol gains a claim-coverage gate with a named owner and a reproduction script (`perf_ledger_preflight.py --audit` equivalent). [Inference, High — process proposal]
2. **Copy the raw-vs-public audit.** Their `scripts/raw_vs_public_audit.py` found 24 of 51 audited functions where the raw Rust kernel disagrees with NetworkX and only the Python wrapper restores parity ("wrapper-corrected") — machine-detected honesty about where the Rust isn't actually the parity owner. Run the same audit shape against every FrankenSuite project with a binding layer. *Done when:* a raw-vs-public audit script exists for at least one sibling repo with its own wrapper-corrected list published. [Inference, High]
3. **Treat the ComplexityWitness as a portable parity-attestation unit.** Every algorithm execution carries a reproducible length-prefixed Blake3 decision-path receipt; that is a machine-checkable claim of *which tie-breaks were taken*, separable from the library. Pilot it as the attestation format for cross-repo behavioral conformance (their e2e-cross-packet-golden workflow already gestures at cross-packet evidence). *Done when:* a second FrankenSuite repo emits and verifies a ComplexityWitness-style receipt. [Inference, Medium]
4. **Re-baseline the Gauntlet head-to-head at a new pin and publish the delta.** The honest incumbent-class numbers (clustering 36.1×, triangles 14.3×, dijkstra 7.6×, all with A/A nulls) date to 2026-07-25; the tree has moved two months and the README's headline "5×–250×" now leans on them. Until re-baselined, the README's performance framing is borrowing staleness. *Done when:* a same-protocol head-to-head runs at a post-pin commit and the README cites its date. [Inference, High]
5. **Extend the G0 doc-freshness gate to the README's own tables.** The auto-generated ledgers are machine-checked, but the README hand-tables (delegation counts 61/71/1113/92/338 → actual 31/150/1112/114/346; "13-variant" → 12; "33" fuzz targets → 34; 3,823/306/0 coverage → 4,129/4,129/0) drift anyway. The project already fails CI on ledger drift — the README's quoted numbers should be generated or gated, not hand-typed. *Done when:* the G0 gate fails when a README-quoted number disagrees with its generating ledger. [Inference, High]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** NetworkX is the canonical Python graph library — "rich, correct, comprehensive, and slow on anything that isn't toy-sized." Its pure-Python adjacency, Python-level inner loops, and per-call dict bookkeeping turn analytics over 10⁵–10⁶-node graphs into multi-minute affairs. Every existing "faster" alternative pays in compatibility: a different API, changed tie-break behavior, lost attribute fidelity, or dropped algorithm families [Maintainer claim, Medium — the speed gap is well-established externally; the framing of alternatives is the maintainer's]. The stated bet: port the algorithms to Rust, treat *observable behavior* (iteration order, exception classes, error wording, generator-vs-list return shapes, tie-break choices) as a hard contract, and measure every public path against the pinned reference — so existing NetworkX codebases get faster without rewriting [Maintainer claim, Medium].

**Who feels the pain:** anyone with an existing NetworkX codebase doing graph analytics at non-toy scale who cannot afford to rewrite against igraph/graph-tool or to debug silent tie-break drift [Inference, Medium].

**Why now:** NetworkX 3.x's backend-dispatch protocol (the hook this project plugs into) is mature; the Rust/PyO3/maturin stack makes ABI3 wheel distribution routine; and the maintainer's integer-adjacency epoch (CSR-style `Vec<Vec<usize>>` adjacency replacing String-keyed walks, measured at 12–16× on the kernels it touched) shows the substrate wins are real for the compute-heavy families [Maintainer claim, Medium on the epoch numbers].

**Why a port, not a wrapper:** stated explicitly in the README's "Why a Port, Not a Wrapper?" section — subclassing/Cython leaves nested Python dicts dominating memory and keeps the GIL held; wrapping a foreign Rust/C++ engine makes conversion the whole workload for short algorithms and loses attribute fidelity and tie-break behavior; rewriting with a Rust-idiomatic API forces users to rewrite and makes the behavioral oracle invisible [Maintainer claim, Medium]. The design target is stated as a target, "not a completed full-surface claim" — the README says so itself [Maintainer claim, High].

**Adjacent context:** one entry in the FrankenSuite solo-maintainer program. The program's thesis here is narrower and more interesting than "rewrite it in Rust": *behavioral parity is a measurable, ledger-enforceable property*, and the evidence machinery (coverage matrix, delegation ledger, divergence ledger, negative evidence, claim-coverage audit) is as much the product as the library. The cross-packet texture is visible: the zero-copy view doc names frankenpandas and franken_numpy as consumers, the e2e-cross-packet-golden workflow exists, LEDGER_RESURRECTION adopts a six-class verdict taxonomy "fleet-wide from frankenfs," and a commit message (6de8937d, 2026-07-08) describes hoisting an exact-integer network-simplex kernel for MTDT's "integer voice-leading optimal transport" [Code-verified/External, High on the artifacts' existence].

**Demand-side check (2026-09-22):** a web search for independent coverage of franken_networkx (production users, third-party reviews, downstream forks, benchmarks) returned nothing beyond the repository itself and two stale forks (marcoz93, referralconsequently) [External, High within recall caveats]. PyPI hosts 0.2.1 with 6 platform wheels [External, High]; download counts were unobtainable (pypistats 429). The demand exists in principle — NetworkX's slowness is the most-cited complaint about the most-downloaded graph library in Python (NVIDIA's technical blog cites 80M+ downloads/month as of Oct 2024 [External, Medium]) — but there is no observed adoption signal, and the 26-star / 4-fork footprint is consistent with a project still in the maintainer's own loop [Inference, Medium].

**Fixture currency (a structural risk):** the entire parity apparatus — coverage matrix, vendored oracle, Gauntlet campaign, parity suite — is pinned to NetworkX **3.6.1**, while PyPI served NetworkX **3.7** on 2026-09-22 [External, High]. The machine-checked 100% is therefore 100%-of-3.6.1; every upstream minor release re-opens the FeatureUniverse and the divergence ledger. Nuance: some June-2026 campaign rows benchmarked against "vendored NetworkX `3.7rc0.dev0`," so the project *can* test newer NetworkX — but the machine-gated coverage truth (the FeatureUniverse the 100% claim rests on) is pinned at 3.6.1 [Maintainer claim, High]. The ledgers fail CI on drift *within* the pin, but nothing in the assessed materials gates on upstream-version currency [Inference, Medium].

## 4.2 What it is — repo TL;DR

A 12-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing NetworkX's graph classes (`Graph`, `DiGraph`, `MultiGraph`, `MultiDiGraph`) and 25+ algorithm families in Rust 2024, with a PyO3 binding crate (`fnx-python`, abi3-py310, maturin) producing the `franken_networkx` Python package — 100,829 lines of Python across the package [Counted, High] — plus a NetworkX backend-protocol plugin (`backend.py`: `_SUPPORTED_ALGORITHMS` = 313 registered algorithms, `can_run`/`should_run`/`get_backend_info`) so `nx.shortest_path(G, 0, 7, backend="franken_networkx")` dispatches into Rust [Code-verified, High]. The headline mechanism is CGSE (Canonical Graph Semantics Engine, `fnx-cgse`): a 13-variant `TieBreakPolicy` enum pinned at the type level plus a `ComplexityWitness` that attaches a length-prefixed Blake3 decision-path receipt to every algorithm execution, making tie-break choices auditable rather than implicit [Code-verified, High]. Conformance is enforced by a vendored NetworkX oracle (`legacy_networkx_code/networkx`, 687 Python files [Counted, High]), a 1,092-file Python parity suite [Counted, High], 2,046 Rust `#[test]`s [Counted, High], 34 fuzz targets [Counted, High], and five auto-generated audit ledgers that fail CI on drift [Maintainer claim, High — the gating is asserted in the README and the G0 job exists in ci.yml; gate-failure behavior was not exercised]. Development velocity is extreme: the CHANGELOG reports 2,729 pre-release commits (2026-02-13 → 2026-05-17) plus 2,505 non-merge commits from post-`v0.2.0` (2026-06-21) through 2026-08-19, totaling 8,124 on main [Maintainer claim, Medium — changelog-reconstructed; the local history was not deepened to re-derive it]; the GitHub API credits a single contributor with 8,808 contributions [External, High]. Agent co-authorship in the 100 most recent commits (GitHub API, commit-message trailers): 8 carry agent Co-Authored-By trailers — 5 Claude-family, 3 Grok — i.e. ~8%, far below the 36% measured in the same program's FrankenRedis window [External, High on the trailer counts; line-level share unmeasured].

One-line verdict: **the most methodologically self-honest codebase in the FrankenSuite [Inference, Medium — the in-program evidence base is the 2.0% claim-coverage audit, the self-refuting zero-copy doc, and the ledger verdict contract; "most" is comparative over completed packets, not a measured ranking]** — 100% machine-checked surface coverage, a 13-variant tie-break engine, and a 37,116-line loss ledger — whose own audits show the performance story is 98% self-measured, under a license that forbids the best-equipped evaluators from analyzing it. (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was 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), Maintainer claim (README/docs), External (third party). **Status** is the Rulebook's audit verdict per claim.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 12 workspace crates, 278,003 first-party Rust lines / 82 `.rs` files; Python package 100,829 lines | demonstrated | Fresh clone; `Cargo.toml` members enumerated; line counts over `crates/` and `python/` (all sources incl. tests/bins — the 82-file / 278k-line ratio reflects very large single files, e.g. `fnx-algorithms/src/lib.rs` spans 53,975+ lines) | [Counted, High] |
| 2 | Unsafe posture: 11 crates `#![forbid(unsafe_code)]`, 1 crate `#![deny(unsafe_code)]` (`fnx-python`); exactly **2 unsafe blocks** in the entire workspace | demonstrated | Gate scan over all crate roots; `unsafe {`-block scan excluding comments — both blocks are in `InstanceDictGc` (`fnx-python/src/lib.rs` L2958, L3002): raw-pointer CPython GC dict-slot management (`*mut *mut pyo3::ffi::PyObject`, `Py_DECREF`), each behind `#[allow(unsafe_code)]`. Narrow FFI unsafe, documented by context | [Counted, High] |
| 3 | Machine-checked surface coverage: 4,129 strictly present / 0 partial / 0 missing applicable paths (100.0%) against pinned NetworkX 3.6.1 (SHA-256-fingerprinted oracle) | demonstrated | `docs/coverage.md` (auto-generated, "do not edit manually") — family-row sums re-added independently: present 4,129, partial 0, missing 0. Caveat: "present" = import/binding-kind/signature parity only, explicitly *not* native Rust ownership, performance, or behavioral conformance | [Counted, High] |
| 4 | 313 algorithms registered in the NetworkX backend dispatcher | demonstrated | `_SUPPORTED_ALGORITHMS` dict in `python/franken_networkx/backend.py` counted programmatically = 313 | [Counted, High] |
| 5 | CGSE: 13-variant `TieBreakPolicy` + per-call `ComplexityWitness` (length-prefixed Blake3 decision-path ledger) | demonstrated | Enum read in `fnx-cgse/src/lib.rs` — 13 variants counted (LexMin, LexMax, InsertionOrder, ReverseInsertionOrder, WeightThenLex, WeightThenInsertionOrder, LexThenWeight, DeterministicHash, DegreeMinThenLex, DegreeMaxThenLex, DfsPreorder, BfsLevelLex, EdgeKeyLex); the README's "13-variant" is correct and v1’s "12 counted" was the analyst's miscount | [Code-verified, High] |
| 6 | Integer-adjacency epoch completed: `Graph.adj_indices: Vec<Vec<usize>>`, `DiGraph.succ_indices/pred_indices: Vec<Vec<usize>>` | demonstrated | `fnx-classes/src/lib.rs` L103, `fnx-classes/src/digraph.rs` L198–199; consumers in `fnx-algorithms`. The 2026-06-06 epoch doc's "DiGraph: NO integer adjacency at all" is superseded by the code | [Code-verified, High] |
| 7 | Divergence ledger: 460 native-parity / 24 wrapper-patched / 181 intentionally-delegated / 1 raw-known-gap / 1 owner-acknowledged-limitation | demonstrated | `docs/upstream_divergence_ledger.md` (auto-generated). The 1+1 rows both concern `is_planar` (KNOWN GAP `br-isplanarbroken`: "still a necessary-only test"; limitation `br-r37-c1-n2md9`: girth-bound short-circuit before LR fallback). 181 functions openly delegate to NetworkX — the drop-in surface is substantially delegation-backed | [Counted, High] |
| 8 | Headline benchmarks are incumbent-class for one campaign: Gauntlet (2026-07-25), n=2000/m=8000 vs unpatched NetworkX 3.6.1, same-invocation A/A nulls, byte-identity before timing, ELF SHA-256 pinned — e.g. clustering 36.1146×, triangles 14.3397×, dijkstra_path 7.6077× (full table in §4.5) | demonstrated (as maintainer-run measurements; not independent) | `docs/GAUNTLET_RELEASE_SCORECARD.md`; the ledger verdict contract (`comparison_class=INCUMBENT`, `incumbent_same_invocation=true`, `decision_gate=median_ci`) is enforced by the pre-commit gate `scripts/perf_ledger_preflight.py` | [Maintainer claim, High] |
| 9 | Only 12 of 591 KEEP-claim rows (2.0%) carry a vs-incumbent ratio — 98% of performance claims were never measured against NetworkX | demonstrated | `docs/CLAIM_COVERAGE_AUDIT.md` (2026-07-31, self-authored, HEAD `629268633`): "Of **591** KEEP claim rows across the three active ledgers, **12** carry a vs-incumbent ratio measured with NetworkX live in the same invocation, and **579** do not." Also: 39/591 carry the in-process ELF SHA-256. Reproduces via `python3 scripts/perf_ledger_preflight.py --audit` | [Code-verified, High] |
| 10 | Negative-evidence ledger: 37,116 lines with an enforced INCUMBENT-vs-SELF-SPEEDUP verdict contract | demonstrated | `wc -l docs/NEGATIVE_EVIDENCE.md`; ledger contract quoted verbatim in §4.5. Self-speedups are classified `comparison_class=SELF-SPEEDUP`, `campaign_output=false` — "It is maintenance … It must not use a `WIN` heading or support a competitive claim." Plus `docs/LEDGER_RESURRECTION.md` (six-class taxonomy adopted fleet-wide from frankenfs; 1,044 entries re-adjudicated) | [Counted, High] |
| 11 | The 77,795× "zero-copy" headline is explicitly refuted by its own design doc | demonstrated | `docs/ZERO_COPY_VIEW_PRIMITIVE.md`: "it is not a cross-language zero-copy result… the bytes never crossed the PyO3 boundary. The magnitude does not transfer." | [Code-verified, High] |
| 12 | README drift (three instances, all vs auto-generated or counted truth) | demonstrated | (a) delegation table 61/71/1113/92/338 → generated JSON 31/150/1112/114/346; (b) comparison-table coverage "3,823 present / 306 partial" → generated matrix 4,129/4,129/0 (the README's own "4,129 … 100.0%" agrees with the matrix, so the comparison-table rows are the stale ones); (c) "1,088-file Python parity test suite" → 1,089 `.py` files (1,092 total) under `tests/python`. (False positives corrected in grading: v1 claimed "33 cargo-fuzz binaries" was drift — `fuzz/Cargo.toml` declares exactly 33 `[[bin]]` targets, the 34th file being a shared helper — and v1 claimed the README's "13-variant TieBreakPolicy" was stale — a recount at the pin finds exactly 13 variants, so the README was right and the analyst was wrong.) | [Counted, High] |
| 13 | asupersync 0.5.0 is present in `Cargo.lock` but is an **optional, non-default** feature of `fnx-runtime` | demonstrated | `fnx-runtime/Cargo.toml`: `asupersync = { version = ">=0.3.4, <0.6", optional = true, default-features = false }` behind `asupersync-integration`; the only usage is a `#[cfg(feature)]` bridge module with a "compile-time marker proving asupersync is wired into this crate" and deterministic-resume tests. Default builds do not link it | [Code-verified, High] |
| 14 | RaptorQ durability sidecars exist (`fnx-durability`) | demonstrated | `use raptorq::{Decoder, Encoder, …}` in `fnx-durability/src`; `RaptorQSidecar` struct; `raptorq` in the dependency union | [Code-verified, High] |
| 15 | An earlier GitHub description's "GPU parallelism" and "streaming" have zero code behind them | disproven (as product claims) | No `wgpu`/`cuda`/`vulkan`/`opencl` in any crate source or `Cargo.lock`; the only "streaming" hits are internal terminology (streaming Blake3 hasher, keyed-streaming ctor internals). Note: the live GitHub description has since been rewritten to the honest "Memory-safe clean-room Rust reimplementation of NetworkX with deterministic graph semantics, differential conformance, and RaptorQ-backed durability" — the aspiration text is stale | [Counted, High] on the absence; [External, High] on the description rewrite |
| 16 | Single human maintainer; 8,124 changelog-reconstructed commits on main; no succession | demonstrated | GitHub contributors API: exactly one contributor (Dicklesworthstone, 8,808 contributions). CHANGELOG: 2,729 pre-release + 2,505 window commits = 8,124 on main. No second committer, foundation, or succession plan anywhere in the assessed materials | [External, High] on the contributor count; [Maintainer claim, Medium] on the changelog totals |
| 17 | Releases exist: GitHub `v0.2.2` (2026-09-12, 23 signed assets incl. wheels, "DSR authority release"); PyPI serves 0.2.1 (6 ABI3 wheels) — PyPI lags one release | demonstrated | GitHub Releases API (v0.2.2, v0.2.0; asset list fetched); PyPI JSON (`franken-networkx` 0.2.1, 6 `cp310-abi3` wheels across linux x86_64/aarch64/musllinux, macOS x86_64/arm64, Windows x86_64). No tag points at the assessed pin — nothing ships the assessed tree | [External, High] |
| 18 | AGENTS.md declares GitHub Actions "permanently non-authoritative… must stay disabled" with DSR as the exclusive quality authority — but Actions is live: 7,723 runs, CI green 2026-09-09 | demonstrated | Repo `AGENTS.md` ("NEVER use GitHub Actions for this repository, for any reason") vs Actions REST API (total 7,723; latest CI #… on `1893284f` concluded success 2026-09-09; latest Release run concluded failure 2026-09-09). CI greenness at the pin is unestablished (pin is 13 days newer than the last CI run). `.dsr/repos.d/franken_networkx.yaml` exists; `v0.2.2` is labeled a DSR authority release | [Code-verified + External, High] |
| 19 | Vendored NetworkX oracle in-tree: `legacy_networkx_code/networkx`, 687 Python files | demonstrated | `find legacy_networkx_code -name '*.py' | wc -l` = 687; conformance tests compare against it per AGENTS.md ("Conformance tests compare … against the legacy NetworkX Python implementation") | [Counted, High] |
| 20 | GIL released on heavy paths: 744 `py.allow_threads` sites in `fnx-python/src/algorithms.rs` | demonstrated | Counted. Matches the README's "hundreds of `py.allow_threads(...)` sites" | [Counted, High] |

**What the inventory says in aggregate:** claims about *process and auditability* (coverage matrix, ledgers, unsafe census, tie-break engine, vendored oracle) verify at High confidence and are the project's real moat. Claims about *outcomes* (speedups) split: the Gauntlet campaign's incumbent-class numbers are methodologically strong but maintainer-run and two months stale; the broader "5×–250×" framing rests on a claim base the project's own audit grades 2.0% attested. The README drifts on every hand-typed number the auto-generated ledgers already know correctly — a governance liability in a project whose pitch is auditability.

## 4.4 Codebase tour

**Workspace topology (12 members, [Counted, High]):** `fnx-classes`, `fnx-views`, `fnx-dispatch`, `fnx-convert`, `fnx-algorithms`, `fnx-generators`, `fnx-readwrite`, `fnx-durability`, `fnx-conformance`, `fnx-runtime`, `fnx-cgse`, `fnx-python`.

**Where the 278,003 Rust lines live** (all `.rs` incl. tests/bins [Counted, High]):

| Crate | Lines | Files | Role in one line |
|---|---|---:|---|
| `fnx-algorithms` | 97,502 | 11 | the algorithm surface (lib.rs alone is 91,879 lines) |
| `fnx-python` | 94,239 | 21 | PyO3 bindings, GIL-release sites, GC integration |
| `fnx-conformance` | 27,032 | 34 | differential harness vs the vendored oracle |
| `fnx-classes` | 17,107 | 4 | the four graph classes + integer-adjacency substrate |
| `fnx-generators` | 15,100 | 2 | graph generators |
| `fnx-readwrite` | 10,504 | 2 | I/O formats (GML, GraphML, edgelist, JSON…) |
| `fnx-runtime` | 10,122 | 2 | runtime support types; the asupersync bridge lives here |
| `fnx-convert` | 2,209 | 1 | nx↔fnx conversion, bulk adjacency dumps |
| `fnx-dispatch` | 1,397 | 1 | algorithm dispatch/routing |
| `fnx-cgse` | 1,300 | 1 | tie-break policy + complexity witness |
| `fnx-durability` | 956 | 2 | RaptorQ sidecars, integrity scrub |
| `fnx-views` | 535 | 1 | subgraph/node/edge views |

Two structural notes: the Python package's 100,829 lines are dominated by a **generated 72,638-line `__init__.py` mega-module** (the `__all__` is assembled — a 772-name literal plus an extension — and the generated export-route appendix machine-gates the full 843-name surface with `--check` failing on drift) [Counted, High]; and the semantic core (`fnx-cgse`, 1,300 lines) is two orders of magnitude smaller than the algorithm mass it governs — the auditability apparatus is cheap, the ported surface is expensive [Inference, Medium].

**Dependency posture (fully inventoried, [Counted, High]):** 27 external crates. The meaningful ones: `pyo3 0.28.3` (abi3-py310) + `pyo3-log` (the entire Python surface); `rayon 1.10.0` (data parallelism — 21 `par_iter`/`par_bridge` sites in `fnx-algorithms` [Counted, High], so the parallelism story is rayon kernels + `py.allow_threads` GIL release, not GIL release alone); `indexmap`, `rustc-hash` (FxHashMap, the integer-adjacency substrate's hash map); `blake3` + `sha2` (witness receipts, ELF pinning); `raptorq` (durability sidecars); `serde`/`serde_json` (everywhere); `criterion` (benches), `proptest` (7 crates — property testing), `pprof` (profiling), `quick-xml` (GraphML parsing), `mt19937` + `mwmatching` (algorithm deps), `thiserror`, `tempfile`, `dhat` (optional heap profiling). **asupersync 0.5.0** is present in `Cargo.lock` but is an optional, non-default feature of `fnx-runtime` (claim 13) — default builds do not link it. No tokio in the hot path; no GPU crates; no TLS/web surface — this is a library, not a server, so the attack surface is the parsers and the FFI boundary.

**Data flow, end to end:**

- **Graph substrate — `fnx-classes`:** the four NetworkX classes re-derived with deterministic `IndexMap`-based, insertion-order-preserving adjacency. The integer-adjacency epoch (claim 6) is the key substrate story: hot kernels walk `Vec<Vec<usize>>` CSR-style adjacency (`adj_indices` on `Graph`, `succ_indices`/`pred_indices` on `DiGraph`) instead of String-keyed maps — the doc credits 12–16× wins on the kernels it touched (global_efficiency, distance measures, constraint) [Maintainer claim, Medium]. Edge attributes live in side tables (`CgseValue`: typed, serde-compatible, scalars+dicts only — a limitation the scorecard names as the root cause of the construction-substrate losses, needing CoW custom-dicts) [Maintainer claim, Medium].
- **Semantics engine — `fnx-cgse`:** `TieBreakPolicy` (13 variants) pins the tie-break at the type level; `ComplexityWitness` attaches a length-prefixed Blake3 decision-path receipt to each execution; a `CgsePolicyEngine` enforces strict-vs-hardened parsing with fail-closed defaults [Code-verified, High on existence].
- **Algorithms — `fnx-algorithms` (the giant; lib.rs is 91,879 lines [Counted, High]):** 25+ families ported to Rust, including a hand-maintained exact-integer `network_simplex_int` kernel hoisted to a first-class Rust API so sibling Rust consumers (e.g. MTDT's voice-leading) can use it without PyO3 [External, High — commit 6de8937d, 2026-07-08]. 744 `py.allow_threads` GIL-release sites in the binding layer [Counted, High].
- **Binding — `fnx-python` (deny-gated, the only crate allowed unsafe):** PyO3 classes mirroring the four graph types; the 2 counted unsafe blocks are `InstanceDictGc`'s CPython GC dict-slot pointer surgery — needed so Python-level `__dict__` attribute storage participates in CPython's garbage collector [Code-verified, High].
- **Dispatch — `fnx-dispatch` + `python/franken_networkx/backend.py`:** the NetworkX backend protocol (`can_run` rejects on signature mismatch, on `method=` overrides, and on custom `flow_func` callables the native kernels can't honor [Code-verified, High]); 313 registered algorithms [Counted, High].
- **Conversion — `fnx-convert`:** bulk native adjacency+attrs dump for `_fnx_to_nx` parity (the FFI marshaling path the README flags as the small-graph bottleneck) [Code-verified, High].
- **Durability — `fnx-durability`:** RaptorQ erasure-coded sidecars with decode-proof receipts [Code-verified, High]; `g8-raptorq` is a CI gate.
- **Conformance — `fnx-conformance` + `tests/`:** differential harness against the vendored oracle; `tests/conformance/DISCREPANCIES.md` reports "zero intentional divergences … for the scoped V1 API surface" as of the last run [Maintainer claim, Medium — run date not stated in the doc].
- **Runtime — `fnx-runtime`:** runtime support types; the asupersync bridge is feature-gated and inert by default (claim 13).

**The 91,879-line-lib.rs analog:** `fnx-algorithms/src/lib.rs` at 91,879 lines [Counted, High] is the reviewability cliff here — the algorithm surface concentrated in essentially one file, mirroring the bus-factor problem at the code level [Inference, Medium on the maintenance implication].

## 4.5 The maintainer's stated case

**The pitch, in the maintainer's own structure:**

1. **Observable behavior is the contract.** Iteration order, exception classes, error wording, generator-vs-list shapes — enforced by the 1,092-file parity suite, the Rust differential harness, and five auto-generated ledgers that fail CI on drift [Maintainer claim, Medium — the suite and ledgers exist and are counted; their enforcement was not executed].
2. **Complete measured surface.** The FeatureUniverse: 4,129/4,129 strictly present (100.0%), 0 partial, 0 missing, against SHA-256-fingerprinted NetworkX 3.6.1 [Counted, High — with the "present = signature parity only" caveat].
3. **Performance.** The README's trade-offs section frames "5×–250× speedups across graph analytics and algorithm traversal" while tabulating the losses honestly (e.g. `remove_node` 0.0037× at n=25.6k, `G[u][v]` 0.36×) [Maintainer claim, Medium — the framing is the maintainer's; the numbers are ledgered]. The Gauntlet head-to-head (2026-07-25) is the incumbent-class evidence — the full table, n=2000/m=8000 (n=300 for all-pairs rows) vs unpatched NetworkX 3.6.1, same-invocation A/A nulls, byte-identity before timing, ELF-hash pinning [Maintainer claim, High on the campaign's existence and protocol]:

| Workload | Ratio vs nx 3.6.1 | A/A null CI |
|---|---:|---|
| `clustering` (all nodes) | 36.1146× | 0.9970–1.0077 |
| `triangles` | 14.3397× | 0.9984–1.0242 |
| `dijkstra_path` (weighted) | 7.6077× | 0.9983–1.0016 |
| `single_source_shortest_path_length` | 5.5005× | 0.9985–1.0067 |
| `all_pairs_shortest_path_length` (n=300) | 4.5647× | 0.9927–1.0054 |
| `single_source_shortest_path` | 3.8952× | 0.9995–1.0015 |
| `all_pairs_dijkstra_path_length` (n=300) | 3.6658× | 0.9962–1.0026 |
| `subgraph(view)` edges | 3.5719× | 0.9512–1.0061 |
| `single_source_dijkstra_path_length` | 3.3325× | 0.9997–1.0152 |
| `dfs_tree` | 3.3439× | 0.9968–1.0113 |
| `bfs_tree` | 3.2403× | 0.9916–1.0005 |
| `single_pair_shortest_path` | 3.1614× | 0.9966–1.0005 |
| `pagerank` | 2.6361× | 0.9392–1.0055 |
| `to_scipy_sparse_array` | 2.4073× | 0.9916–1.0051 |
| `to_dict_of_lists` | 1.9662× | 0.9945–1.0010 |
| `bidirectional_dijkstra` | 1.8125× | 0.9952–1.0005 |
| `shortest_path` (weighted) | 1.7684× | 0.9947–1.0005 |
| `all_pairs_shortest_path` (n=300) | 1.7624× | 0.9870–1.0005 |
| `edges(data=True)` | 1.6085× | 0.9958–1.0011 |

These rows are the honest core of the performance story — and they are INCUMBENT-classified ledger rows, the same class the 2.0% audit counts, so they sit inside (not outside) the attested set [Inference, Medium — the audit's 12 attested rows were not individually enumerated, so the exact overlap is unconfirmed]. Everything outside this table should be read as self-speedup until the claim-coverage audit is re-run at a current pin.
4. **Deterministic semantics.** CGSE's 13-variant tie-break policy and per-call Blake3 decision-path receipts [Code-verified, High].
5. **Safety.** 11× forbid + 1× deny, 2 unsafe blocks total (claim 2) [Counted, High].
6. **Rigor artifacts.** The negative-evidence ledger (37,116 lines), the INCUMBENT/SELF-SPEEDUP verdict contract enforced by a pre-commit gate, the six-class LEDGER_RESURRECTION taxonomy (1,044 entries re-adjudicated), the claim-coverage audit, the raw-vs-public audit — a self-scrutiny stack with no peer in the program [Code-verified, High on existence].

**The disavowal-equivalent — the 2.0% audit, quoted and located precisely:** `docs/CLAIM_COVERAGE_AUDIT.md` (2026-07-31), verbatim: *"Of **591** KEEP claim rows across the three active ledgers, **12** carry a vs-incumbent ratio measured with NetworkX live in the same invocation, and **579** do not — **2.0%** attested coverage."* And: *"**39 of 591** carry the in-process loaded-ELF SHA-256; **552** do not."* This is the functional equivalent of FrankenRedis's benchmark disavowal — except it is sharper: the project forbids *itself* from citing self-speedups as wins (ledger contract: "It is maintenance, even when the source change ships; it must not use a `WIN` heading or support a competitive claim"), yet the README's "5×–250×" framing and the release scorecards' "DOMINATES" verdicts lean on the unattested base. Any downstream citation of the headline speedups that omits the 2.0% figure is misrepresenting the source [Code-verified, High — the audit is in the pinned tree].

**Benchmark reproduction cost:** reproducing the Gauntlet head-to-head requires the ~58 MB checkout (plus shallow `.git`), the pinned `nightly-2026-08-31` toolchain (`rust-toolchain.toml`), `maturin` + Python 3.10+, and unpatched NetworkX 3.6.1 in the same invocation per the ledger protocol (`scripts/run_benchmark_gate.sh`, `scripts/run_perf_baseline_matrix.py`, `scripts/run_perf_regression_gate.py`, `scripts/run_perf_slo_gate.py`; artifacts under `artifacts/perf/`) [Code-verified, Medium on the script inventory; cost is [Inference, Medium]]. No independent reproduction is known to exist [External, High within recall caveats].

---

## 4.6 Competitors

The incumbent wins on ecosystem ubiquity and zero-adoption-friction; franken_networkx's only uncontested edge is its auditability apparatus (tie-break pinning, decision-path receipts, five ledgers) — which no competitor bothers with because no buyer currently pays for it [Inference, Medium].

- **NetworkX itself (BSD-3, the oracle):** the incumbent by definition — every Python graph user already has it. Wins on API completeness (it *is* the API), ecosystem (tutorials, Stack Overflow, downstream packages), and zero install friction. Loses on speed: pure-Python adjacency and Python-level inner loops are exactly the gap franken_networkx prices [External, High].
- **rustworkx (Apache-2, IBM/Qiskit lineage):** the closest engineering analog — a Rust-backed graph library with a Python API, fast kernels, its own (non-NetworkX) API. Wins on maturity, institutional backing, and real adoption (quantum computing pipelines). Loses on the one thing franken_networkx sells: it is *not* NetworkX-shaped, so existing nx codebases can't adopt it without rewriting [External, High].
- **igraph (C core, python-igraph) and graph-tool (C++/Boost):** mature, fast, own APIs, integer-indexed vertices. The README's comparison table concedes they may beat fnx on raw throughput for single calls (PageRank on a huge graph) while losing on API shape and tie-break parity [Maintainer claim, Medium]. Own the "fast but different" lane [Inference, Medium].
- **nx-parallel (NetworkX's official parallel backend):** the incumbent's own answer to the speed complaint — parallelizes selected algorithms within the NetworkX API, with the NetworkX project's imprimatur and zero behavioral risk. This is the sharpest competitor: it contests the exact pitch ("my nx code, faster, no rewrite") without asking users to trust a third-party parity claim, and its coverage grows with every NetworkX release while franken_networkx's parity target stays pinned at 3.6.1. franken_networkx's counter is breadth (313 backend algorithms vs nx-parallel's selected set) and the determinism story nx-parallel doesn't tell [External, High on existence; the competitive overlap is Inference, Medium].
- **python-graphblas / GraphBLAS (SuiteSparse):** owns the sparse-linear-algebra formulation lane; different conceptual model, strong on massive graphs [External, Medium].
- **networkx-cuda / cugraph (RAPIDS, NVIDIA):** the GPU lane the repo description once claimed and the code never built — a real, occupied lane franken_networkx does not contest. NVIDIA's own technical blog describes a cuGraph NetworkX backend (co-developed with the NetworkX team) claiming up to 50–500× over NetworkX on CPU for PageRank/Louvain/betweenness [External, Medium — vendor benchmark claims, treat as Low for the numbers, High for the lane's occupancy]. Against that, franken_networkx's 2–36× CPU wins are a different sport.
- **Unoccupied lane:** a memory-safe, NetworkX-API-compatible library with machine-checked behavioral parity evidence, pinned tie-break semantics, and a published negative-evidence practice has no direct occupant — rustworkx is Rust but not nx-shaped; nx-parallel is nx-shaped but not a rewrite; igraph/graph-tool are fast but behaviorally divergent [Inference, Medium]. Whether any buyer pays for determinism-plus-auditability over raw throughput or over simply staying on NetworkX is the unproven bet the project rests on. **Stated plainly: no head-to-head benchmark against any of these competitors exists anywhere in the assessed materials** — every performance number in the repo is fnx-vs-NetworkX or fnx-vs-itself [Code-verified, High].

## 4.7 Skeptic's take

*Citation convention: weaknesses numbered 1–8; elsewhere "§4.7.N" means weakness N.*

1. **[FATAL] The performance story is 98% unattested by its own audit.** The claim-coverage audit (self-authored, 2026-07-31) grades the ledger base at 2.0% incumbent-attested; the project's own contract says self-speedups "must not support a competitive claim." The README's "5×–250×" framing and the scorecards' "DOMINATES" verdicts are therefore load-bearing on a base the project itself disqualifies. The Gauntlet campaign is the honest exception — and it is two months stale [Code-verified, High].
2. **[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 creates legal uncertainty for any contributor near the AI supply chain, 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]. The rider's "analyzing" bar arguably covers this very assessment.
3. **[HIGH] One human, no release artifact at the pin, PyPI lags.** Single contributor [External, High]; nothing tags the assessed commit [Git-observed, High]; `pip install franken-networkx` serves 0.2.1 while the GitHub release is 0.2.2 — the primary install path is a release behind [External, High]. Bus factor 1 plus a lagging distribution channel means every downstream claim rests on one person's continued weekends [Inference, High].
4. **[HIGH] The README is a drift source, and the project knows what good looks like.** Five counted drift instances (claim 12) in a project whose pitch is *auditability* — the auto-generated ledgers are machine-checked, but the hand-typed README tables quote stale numbers. The G0 doc-freshness gate checks the ledgers, not the README's quotations of them [Code-verified, High]. License-communication footnote: the README's shields badge (L9) advertises "License: MIT" linking to a LICENSE whose rider section this packet classifies non-OSI; the README has no license section disclosing the rider at all (unlike FrankenRedis's L2075–2077) [Code-verified, High].
5. **[MEDIUM] The drop-in surface is substantially delegation-backed.** 181 functions are documented as intentionally delegating to NetworkX; 24 more are wrapper-patched because the raw Rust kernel disagrees with nx. The 100% coverage figure is import/signature parity — the honest decomposition is 460 native-parity vs 181 delegated, and the delegated paths are NetworkX running under the hood, not a Rust win [Code-verified, High].
6. **[MEDIUM] The FFI boundary is the product's tax bracket.** The README's own trade-offs table: `G[u][v]` 0.36×, `MDG.get_edge_data` 0.027×, `remove_node` 0.0037× at 25.6k nodes — and the README states the crossover explicitly: "For very small graphs (< 100 nodes / single-shot analysis), the PyO3 marshaling cost can exceed the algorithm cost" [Maintainer claim, High]. For fine-grained mutation-heavy workloads — arguably the modal NetworkX usage [Inference, Medium] — franken_networkx is *slower* than the incumbent it replaces, and the mitigation roadmap (slot tombstoning, CoW custom-dicts, live keydict mirrors) is bead-tracked future work [Maintainer claim, High].
7. **[MEDIUM] Actions-vs-DSR governance split.** AGENTS.md declares GitHub Actions permanently non-authoritative and "must stay disabled"; the Actions API shows 7,723 runs with CI green four days before the v0.2.2 DSR release and a failed Release run on 2026-09-09. Either the quality-authority migration is incomplete or the documentation is aspirational — in a project selling process rigor, the process's own authority is ambiguous [Code-verified + External, High].
8. **[MEDIUM] Agent co-authorship is measured and modest — but the "clean-room" label still can't be tested.** 8 of the 100 most recent commits (8%) carry agent Co-Authored-By trailers — 5 Claude-family (Anthropic, a named Restricted Party), 3 Grok [External, High on the trailer counts; line-level share unmeasured]. That is far below FrankenRedis's 36% in the same program, which weakens the output-similarity worry here — but the rider's no-training clause cannot bind its own author either way, so the sound concern remains epistemic, not legal: a clean-room assertion that no independent party may benchmark or analyze is untestable [Inference, Medium].

**Bear-case steelman (strongest counter-case):** FrankenNetworkX is a single-maintainer measurement-art project about *how* to port infrastructure honestly, not infrastructure. Its own audit says 98% of its performance claims were never measured against the incumbent; its README cannot keep its own tie-break count straight; the drop-in surface is one-third delegation to the thing it claims to replace; the fine-grained mutation paths that define interactive NetworkX use are 3–270× *slower*; the license forbids the best-equipped evaluators from analyzing it; and the description once promised GPU parallelism and streaming with zero code behind either. The rational market response is to mine it for methodology (claim-coverage audits, raw-vs-public audits, negative-evidence taxonomies, tie-break pinning) and never deploy it. Its most likely end state is abandonment at the maintainer's next context switch — leaving 278k lines of unauditable-by-license Rust that PyPI serves a release behind. [Inference, Medium — deliberately uncharitable; the counter-evidence is the repair-and-measurement velocity in the changelog and the DSR-signed release discipline.]

## 4.8 Maintenance & succession

**Bus factor: 1.** One human contributor on the GitHub API (8,808 contributions) [External, High]. No succession plan, no second committer, no foundation, no release artifact at the pin to fork from cleanly (the v0.2.2 release targets the earlier commit — 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].

**Contribution policy:** CONTRIBUTING.md requires PR review for all submissions and points to an issue tracker URL that 404s (`github.com/doodlestein/franken_networkx/issues` — wrong org; the repo is `Dicklesworthstone/franken_networkx`) [Code-verified + External, High]. It mandates the `br`/`bv` task-triage tooling, `rch` remote compilation, and CGSE implementation for all new algorithms — a high, idiosyncratic bar for outside contributors [Maintainer claim, High]. **Security hygiene note:** SECURITY.md's supported-versions table lists `1.x.x` as supported and `< 1.0` as unsupported — but the project is at 0.2.2, so read literally *no released version* receives security updates. Either the table is aspirational boilerplate or the support window is empty; neither is stated [Code-verified, High].

**Commit velocity vs. review depth:** 8,124 changelog-reconstructed commits on main (2,729 pre-release + 2,505 post-`v0.2.0` through 2026-08-19) [Maintainer claim, Medium]; the local history was not deepened, so velocity was not re-derived locally. Agent co-authorship: 8% of the 100 most recent commits carry agent trailers (5 Claude-family, 3 Grok) per the GitHub API — measured, and far below FrankenRedis's 36% [External, High on the trailer counts; line-level share unmeasured].

**License and governance (material):** the LICENSE is "MIT License (with OpenAI/Anthropic Rider)," copyright 2026 Jeffrey Emanuel, read verbatim at the pin [Code-verified, High]. The rider defines "Restricted Parties" as 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 officers, directors, employees, contractors, agents, consultants, service providers, representatives). "No rights are granted to any Restricted Party"; any purported license to them "is null and void." "Use" is defined to include "copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems." Breach "automatically and immediately terminates" the license; the rider applies to all Derivative Works and must ship unmodified with any distribution. **OSI status: non-OSI** — the named-party use restriction violates OSD §5/§6 (no discrimination against persons, groups, or fields of endeavor) [Inference, High — a legal classification judgment, not a court ruling]. **Adoption ceiling:** any organization in the AI supply chain (and, via the "acting for" prong, arguably their contractors and evaluators) cannot touch it; the "analyzing"/"benchmarking" prongs arguably cover independent assessment itself — which is why this packet's independent-validation column is structurally empty [Inference, High]. The rider is the single largest advancement blocker: it doesn't just limit users, it limits *scrutiny*.

**Quality authority:** AGENTS.md names the Doodlestein Self-Releaser (DSR) as the exclusive quality/build/release authority and forbids citing GitHub Actions; `.dsr/repos.d/franken_networkx.yaml` exists; v0.2.2 is labeled a "DSR authority release" with 23 signed assets [Code-verified + External, High]. But Actions ran 7,723 times and CI was green 2026-09-09 — the migration from Actions to DSR is documented as complete and observed as incomplete [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | Justification (one line each) |
|---|---|---|
| Technology readiness | TRL 6 | Adjudicated 5-vs-6 in favor of 6: the "relevant environment" is not a lab mock — it is the incumbent's own pipeline, with the backend plugin executing live NetworkX workloads under same-invocation A/A controls, byte-identity checks, and ELF pinning. A prototype that demonstrates itself *inside* the incumbent's production API surface clears the bar even with the builder as the only observed operator [Inference, Medium on the level; High on the facts]. Signed GitHub release + PyPI wheels + differential conformance vs a vendored oracle support 6; no independent validation and no observed production use block 7. |
| Strategic relevance | 3/5 | Graph analytics is a durable workload and NetworkX's speed gap is real; but the rider structurally excludes the AI-lab-adjacent evaluators most likely to matter, capping relevance. |
| Impact potential | 3/5 | If the parity apparatus holds, it unlocks "existing nx codebases, faster, no rewrite" — a large latent surface; capped by FFI-bound workloads where it is slower and by single-maintainer risk. |
| Implementation feasibility | 4/5 | Already implemented and shippable (wheels, releases, docs); the remaining work is measurement honesty and governance, not invention. |
| Time to mainstream | 2/5 | No adoption signal, bus factor 1, rider blocks the most likely institutional adopters; mainstream requires a second maintainer and independent benchmarks — years, if ever. |
| Collaboration potential | 2/5 | The methodology (audits, ledgers, tie-break pinning) is highly collaborable; the software is not — rider excludes AI labs, bus factor 1, idiosyncratic tooling bar (br/bv/rch/CGSE mandate). |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven fits exactly: real releases, real conformance machinery, real differential testing — but no independent validation, no production users, benchmark outcomes mostly self-measured, one maintainer, and a license rider that is an advancement blocker rather than a ring qualifier. Pilot would require a bounded, *real* workload fit with observed use; none is evidenced. When in doubt, ring down.

## 4.10 Wardley placement

- **NetworkX API surface + the vendored oracle:** commodity — the API is the industry's shared vocabulary; the oracle is pinned open-source (and one minor version behind upstream 3.7, so the commodity itself is drifting) [Inference, High].
- **The Rust reimplementation (classes, algorithms, PyO3 bindings, backend plugin):** custom-built, product stage — a working re-derivation with releases, but single-supplier and unproven at scale [Inference, Medium].
- **The evidence machinery (CGSE tie-break pinning, ComplexityWitness receipts, five auto-generated ledgers, INCUMBENT/SELF-SPEEDUP verdict taxonomy, claim-coverage audit, raw-vs-public audit):** genesis-to-custom — novel as an integrated practice; no competitor operates it [Inference, Medium].
- **What would move each:** the reimplementation moves toward commodity if a second maintainer or institutional fork adopts it and independent benchmarks land; the evidence machinery moves toward product if even one sibling FrankenSuite repo (or an outside project) adopts the claim-coverage audit as a gate.
- **PyPI distribution (ABI3 wheels):** commodity channel — the standard Python distribution mechanism; its hygiene (currently one release behind GitHub) is a process signal, not a differentiator [External, High on the facts; Inference, High on the placement].
- **The DSR release pipeline (`.dsr/` config, DSRAgent orchestration, provenance-attested artifacts):** custom-built — a bespoke single-maintainer release ritual with signed evidence bundles; it would move toward product only if a second operator ran it [Inference, Medium].

## 4.11 Trajectory (12 / 24 / 60 months)

**[Inference — all of §4.11 is analyst judgment, confidence Medium unless noted.]**

- **12 months (base case):** the maintainer continues the measurement program; the Gauntlet head-to-head gets re-baselined at least once; the README drift instances get fixed or don't (the G0 gate still won't cover hand-typed tables); PyPI catches up to GitHub releases or doesn't; the project stays at bus factor 1 with 26→~100 stars and no production users. The rider stays, so no AI-lab-adjacent adoption.
- **24 months (bifurcation):** *Upside:* a second maintainer arrives (or a corporate sponsor funds one), the claim-coverage attestation crosses 50%, an independent benchmark reproduces the Gauntlet numbers, and the backend plugin lands in a real analytics pipeline — ring moves to Pilot. *Decay:* the maintainer context-switches (the suite-wide pattern: velocity is the only succession plan, and velocity is one person); the tree freezes with PyPI a release behind; the ledgers become the artifact and the library becomes abandonware. Decay is the base case for solo-maintainer infrastructure without a second committer — the honest prior.
- **60 months:** either a niche-but-real tool (the "deterministic NetworkX" for regulated pipelines that need auditability) or a methodology fossil mined for its audit patterns. The evidence machinery is the more likely survivor in both branches.
- **Revisit triggers:** (1) first independent benchmark reproducing any Gauntlet row; (2) a second maintainer with merge rights; (3) PyPI serving the current GitHub release (distribution hygiene); (4) the claim-coverage attested fraction crossing 25%; (5) any production deployment disclosed; (6) rider removal or narrowing; (7) a NetworkX minor/major release that breaks the 3.6.1-pinned parity surface.

## 4.12 Limitations and open questions

**Not done:** the workspace was never compiled; the PyO3 bindings were never built or executed; no test suite (Rust or Python) was run; no benchmark was reproduced; CI greenness at the pin is unestablished (last CI run 2026-09-09 predates the pin); PyPI download stats were unobtainable; no downstream users were contacted. Agent co-authorship was measured only at the commit-trailer level (8/100 recent commits); line-level share is unmeasured.

**Open questions that would most change the verdict:**
1. What fraction of the 591 KEEP claims is incumbent-attested *today* (the audit is 2026-07-31)? A re-run of `perf_ledger_preflight.py --audit` at the pin is the single highest-value measurement.
2. Does the backend plugin see any real-world use? (No signal found; absence of evidence with search-recall caveats.)
3. Is the "clean-room" label defensible given 8% agent co-authorship in the recent window? (Trailer counts measured; line-level share unmeasured.)
4. Would the maintainer accept a PR extending the G0 gate to README-quoted numbers? (Tests whether the drift is a priority or a blind spot.)
5. Does the rider's "analyzing" prong actually deter the independent benchmarking the project needs? (Legal judgment, not code.)
6. Why do the two auto-generated ledgers disagree on delegation's shape — the export-route appendix classifies 763 `__all__` rows with **0** NX_DELEGATED, while the divergence ledger counts **181** intentionally-delegated functions? Different denominators and detection rules (export-level runtime-route classification vs per-function wrapper-route analysis) likely explain it, but the definitions are not reconciled in the docs, and an auditor cannot tell which number to quote. [Code-verified, High on the numbers; the reconciliation is Inference, Medium.]

---

## The eight deepening questions

1. **Provenance.** Every algorithm execution carries a `ComplexityWitness` — a length-prefixed Blake3 decision-path receipt recording which tie-breaks were taken — and the perf ledger pins the loaded ELF SHA-256 of the benchmarking binary; provenance is therefore *execution-local and content-addressed*, the strongest in the program. Making it portable means standardizing the receipt schema (currently crate-internal) so a second repo can verify a witness without running the code — their e2e-cross-packet-golden workflow is the institutional seed of exactly that. [Mostly Code-verified, High; the portability path is Inference, Medium.]

2. **The embeddable unit.** The smallest adoptable piece is `fnx-cgse` (the tie-break policy + witness types, 1,300 lines, `#![forbid(unsafe_code)]`, deps essentially serde/sha2/blake3) or a single algorithm kernel like `network_simplex_int` — the latter was already hoisted to a first-class Rust API for a sibling consumer (MTDT) without the PyO3 dependency, which is the adoption pattern proven in-tree. Adoption cost: near-zero build pain (no unsafe, tiny dep tree), but the API-shape coupling is real — CGSE's value (deterministic tie-breaks) only pays if the consumer also adopts the parity discipline of recording and checking witnesses, and a lone kernel without the ledger machinery is just another implementation. The honest embeddable unit is therefore "kernel + witness schema," not "kernel." [Code-verified, High on the structure; the cost judgment is Inference, Medium.]

3. **Unexercised option value.** The asupersync bridge in `fnx-runtime` is the clearest unexercised option: an optional, non-default integration whose current surface is a compile-time marker and deterministic-resume tests — capability (agent-orchestrated checkpoint/resume) wired but unused by default builds. The ComplexityWitness receipts are a second: machine-readable attestation emitted but consumed only by the project's own gates. The fuzz corpus (34 targets) is a third: parser/algorithm-family harnesses that could become a differential oracle for *other* implementations. Unlocking each means promoting it from harness to interface. [Code-verified, High on existence; Inference, Medium on the unlock.]

4. **Benchmark honesty.** The Gauntlet head-to-head rows (clustering 36.11×, triangles 14.34×, dijkstra_path 7.61×, all with same-invocation A/A nulls and ELF pinning) would survive an independent rerun *of the protocol* — the methodology is the strongest in the suite — but the numbers themselves are two months stale and maintainer-run. The README's "5×–250×" framing and the scorecards' "DOMINATES" verdicts are load-bearing on the 2%-attested base and would not survive as stated. The losses table (0.0037× remove_node et al.) is the most trustworthy part of the performance story because it is adversarial to the thesis. [Code-verified, High.]

5. **The governance path.** The credible route from one maintainer to an institution runs through the DSR release authority (already the documented path), a second committer with merge rights, and PyPI/GitHub release parity — in that order. What breaks first if velocity decays: the hand-typed README tables (already drifting), then the parity suite's fixture currency against new NetworkX releases, then the benchmark ledgers' re-baselining cadence; the auto-generated ledgers are the last thing to rot because they fail CI on drift. [Inference, Medium.]

6. **The license as strategy.** The rider excludes OpenAI, Anthropic, their affiliates, and anyone acting for them — from use, benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination on breach. As strategy it is sabotage wearing the clothes of leverage: the project's moat is evidence, and the rider excludes the entities best equipped to produce independent evidence, while the "acting for" prong chills contractors and evaluators. It serves exactly one goal — denying named labs training/data value — at the cost of the mission (adoption, scrutiny, collaboration). [Code-verified, High on the scope; the strategy judgment is Inference, High.]

7. **Agent-era fit.** The concrete workload that would pick this over NetworkX: an agent running graph analytics inside a long-lived pipeline where iteration-order or tie-break drift is a silent correctness bug downstream — the README names this case explicitly (L1614). What has to become true first: the claim-coverage attestation must rise enough that the agent can trust the speedup numbers, the rider must not cover the agent's operator (it likely does for the major labs' agents), and the FFI-bound mutation paths must stop being slower than the incumbent for interactive use. Until then, the agent picks NetworkX and waits. [Inference, Medium.]

8. **The kill test.** Re-run `python3 scripts/perf_ledger_preflight.py --audit` at a current pin: if the incumbent-attested fraction is still in the low single digits *and* a same-protocol independent re-baseline of the Gauntlet rows fails to reproduce the wins (or shows the delegated/wrapper-patched paths dominating real pipelines), the core thesis — "a Rust port that is both behaviorally faithful and decisively faster" — is falsified as a product, leaving only the methodology. A cheaper kill test: measure what fraction of wall-clock time in five realistic nx pipelines is spent in the 181 delegated paths — if delegation dominates, the product is a slower NetworkX with a Rust logo. [Inference, Medium.]