# FrankenNumPy — RULEBOOK v1.0 Assessment Packet v4

**Repository:** `Dicklesworthstone/franken_numpy` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `7de9ba73281017127e144671df1c2f4e4276f078` (2026-09-22 08:57:29 -0400, [Git-observed, High]) · **Last push:** 2026-09-22 (the pin is the latest push confirmed in this assessment) [External, High] · **Scope:** the pinned commit only. Tags `v0.3.0` and `v0.2.0` point at earlier commits, not the pin; the pin is the dev head on `main` [Git-observed, High]. Stars 23, forks 4 [External, High — GitHub API, 2026-09-22]. *Cold-reader note: "v4" below = the fourth draft of this packet (rewrite-loop round 4), not a software version.*

**Method (analyst):** shallow clone of HEAD checked out at the pin under `/tmp/fn-verify` (136 MB incl. `.git`); read: root `Cargo.toml`, all 11 crate manifests, `Cargo.lock` (spot), `LICENSE` (verbatim), full README (2,469 lines), `CHANGELOG.md` (1,177 lines), `UPGRADE_LOG.md`, `docs/KEEP_CLAIM_INCUMBENT_COVERAGE.md`, `docs/DIVERGENCES.md`, `docs/FUZZING.md` (digest), `pyproject.toml`, `fnp-runtime`'s `asupersync_integration` module, `fnp-conformance/src/raptorq_artifacts.rs` (imports only), sampled `unsafe` sites in `fnp-python/src/lib.rs`, `.beads/issues.jsonl` (2,846 rows). Counted: `.rs` files/lines (src-only and all), `#[test]` occurrences, fuzz targets, conformance binaries, bench files, unsafe sites (strict regex, comment-excluding), bead statuses. GitHub REST API: repo metadata, tags, releases, Actions workflow runs + per-job conclusions for the run at the pin, crates.io API (with UA) for all 11 crate names, PyPI for `frankennumpy`. **Not done:** nothing was compiled or executed (no Rust toolchain in this environment); no test suite was run; no benchmark was reproduced; no `git blame` authorship analysis (shallow clone); no independent reproduction of the 499/499 surface lock or RNG parity; review depth (PRs vs direct-to-main) unassessed. Assessment date: 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** (multiple converging sources or direct inspection) / **Medium** (single solid source, plausible) / **Low** (thin evidence, extrapolation).

---

## Hook

A 402,564-line "NumPy reimplementation" with a safe-Rust numeric core whose pip wheel declares `numpy>=2.3` as a runtime dependency — because its 100% API surface is substantially NumPy re-exported, not rebuilt — and whose README then prints the audit proving 97% of its own benchmark claims don't meet its own evidence contract. It is the most honest codebase in this program about what it hasn't proven, under a license that forbids the likeliest evaluators from checking.

---

## TL;DR

- **What it is:** A from-scratch Rust reimplementation of NumPy (~402.6k first-party source lines / 454 `.rs` files across 11 crates at the pin [Counted, High]) with a dual-mode (strict/hardened) runtime, a deterministic stride-calculus engine, differential conformance against a live NumPy oracle, and a PyO3 extension (`fnp_python`) that reaches 100% of `numpy.__all__` — partly via native Rust fast-paths, partly by identity-equal re-export of the live NumPy [Code-verified, High on the mechanism]. Single human maintainer plus an agent swarm (per the repo's own "Multi-Agent Development Process" docs [Maintainer claim, Medium — line-level authorship not measured in this assessment]).
- **Strongest evidence:** 8,716 `#[test]` functions counted exactly matching the README's 2026-09-20 figure [Counted, High]; 10 of 11 crates `#![forbid(unsafe_code)]` with zero counted unsafe sites, the 642 remaining sites confined to the PyO3 boundary in layout-checked buffer views [Counted, High]; a 67,641-line negative-evidence ledger [Counted, High]; a self-disavowing KEEP-claim audit (22/751 contract-grade [Maintainer claim, High — the doc exists and the numbers are printed]); 0 active rows in the divergence ledger [Code-verified, High]; 10 crates published on crates.io at 0.3.0 [External, High].
- **Strongest doubts:** CI is **red at the pin** — the latest run (head = pin) fails at the G1 `cargo clippy -- -D warnings` gate with G2–G9 all skipped, established 2026-09-22 via the Actions API [CI-observed, High], while the README badge still reads "G1 green"; the 100% API surface is substantially re-export rather than reimplementation and the wheel declares `numpy>=2.3` as a runtime dependency [Code-verified, High]; 729 of 751 kept performance claims predate the evidence contract and lack same-invocation incumbent ratios [Maintainer claim, High]; the license rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use *including benchmarking, testing, analyzing, and indexing* — killing independent validation and the agent-era evaluation story [Code-verified (license text), High]; bus factor 1; no PyPI release; crates.io downloads top out at 96 [External, High]; zero independent coverage [External, High within recall caveats].
- **NODUS ring: Explore** [Inference, Medium] (TRL 5 — see §4.9). Substantive, released on crates.io, but unproven in any production workload and unauditable-by-license for the likeliest evaluators. The evidence machinery (differential oracle harness, ledger-hygiene gates, KEEP-claim audit) is the most exportable artifact in the FrankenSuite; the software itself is Explore-with-a-ceiling until the rider moves — the rider is the single advancement blocker, priced into the feasibility and collaboration scores and wired to revisit trigger 3.

---

## Quick Links

Pin-relative links (`blob/7de9ba73281017127e144671df1c2f4e4276f078`); verified resolving 2026-09-22 [Verified, Medium]:

1. [Repository](https://github.com/Dicklesworthstone/franken_numpy)
2. [README](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/README.md)
3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/LICENSE)
4. [Changelog](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/CHANGELOG.md)
5. [Negative-evidence ledger](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/docs/NEGATIVE_EVIDENCE.md) — 67,641 lines at the pin
6. [KEEP-claim incumbent-coverage audit](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/docs/KEEP_CLAIM_INCUMBENT_COVERAGE.md) — 22/751 contract-grade
7. [Divergence ledger](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/docs/DIVERGENCES.md) — 0 active rows
8. [Fuzzing inventory](https://github.com/Dicklesworthstone/franken_numpy/blob/7de9ba73281017127e144671df1c2f4e4276f078/docs/FUZZING.md) — 7 crates, 30 targets
9. [CI workflow (8-gate topology)](https://github.com/Dicklesworthstone/franken_numpy/actions/workflows/ci.yml) — 6,342 runs; latest run at the pin (35730374809) failed at the G1 clippy gate
10. [Releases](https://github.com/Dicklesworthstone/franken_numpy/releases) — v0.3.0 (2026-09-12) and v0.2.0 (2026-07-11), both with zero attached assets
11. [crates.io: fnp-ufunc](https://crates.io/crates/fnp-ufunc) — representative of the 10 published crates (all 0.3.0; `fnp-conformance` is the one not published). *Note: the crates.io HTML page returned 404 to automated fetches on 2026-09-22 while the crates.io API returned 200 with full crate metadata — the crate exists; use the API or docs.rs if the page misbehaves: [docs.rs/fnp-ufunc](https://docs.rs/fnp-ufunc) verified 200.*

---

## Did You Know

The README's 2026-05-25 cross-engine benchmark table — the one where FrankenNumPy "wins" multiply, add, mean, sort, and std — was measured after the FrankenNumPy side of every row had been switched to pass straight through to NumPy, forty minutes before the table was published. It is NumPy timed against NumPy plus wrapper overhead, and the README says so explicitly: *"the sub-1.0 values are noise. The table is kept as the parity-era record; it is not a measurement of the FrankenNumPy engine."* The project keeps its own most flattering table on display as a museum of a measurement that proved nothing. [Maintainer claim, High — the disavowal is in the pinned README.]

---

## Franken-worthy next steps

1. **Publish `fnp-conformance` to crates.io — and test whether the harness generalizes.** The packet's §4.9 argues the differential-against-oracle harness is the durable artifact; it is the *only* workspace crate not published (404 on crates.io, verified 2026-09-22 [External, High]). The research question, not the release chore: port its fixture schema to a *second* implementation (a sibling FrankenSuite repo's numeric code, or an independent small array library) and report what breaks — a harness that only fits its home repo is repo tooling, not methodology. *Done when:* `fnp-conformance` is published at the workspace version and the fixture format has been run against a non-FrankenNumPy implementation with the breakage ledgered. [Inference, High — process proposal]
2. **Run the tier-3 severance experiment.** The three-tier attribute model (native Rust / PyO3 class / identity-equal numpy re-export) makes a falsifiable experiment possible: build a wheel with tier-3 re-exports severed and measure what fraction of `numpy.__all__` still resolves and what fraction of a real workload suite (e.g., the NumPy test suite's core subset) still passes. This quantifies reimplementation vs re-export — the packet's central qualification of the 100% claim — as a number instead of a table. *Done when:* the severance build runs and the resolved-surface fraction is recorded in the ledger with the same schema discipline as the KEEP claims. [Inference, High — process proposal]
3. **Measure the re-recordable share of the benchmark debt — with the project's own sampling method.** 729 of 751 KEEP claims lack same-invocation incumbent ratios (the project's own audit, 2026-07-31 [Maintainer claim, High]), and the audit's seeded hand-read of 30 estimated ~554 are re-recordable (predate the schema) vs ~169 needing fresh measurement. Re-run that hand-read at n=300 with Wilson intervals: the research question is what fraction of the debt is *schema* debt vs *measurement* debt, because the two need different work and the answer determines whether next-step-style re-recording is a month or a year. *Done when:* the n=300 classification is ledgered with confidence intervals, and the re-recordable subset is converted to the incumbent-win schema. [Inference, High — process proposal]
4. **Standardize `fnp-random-core` as a cross-language bit-exact stream.** The crate is 328 lines, `#![forbid(unsafe_code)]`, dependency-free, "no I/O, no entropy, no threads" by design [Code-verified, High], with witness fixtures pinning every RNG distribution's output. That is the shape of a portable protocol: bit-exact PCG64DXSM streams any language can implement. *Done when:* an independent implementation in a second language (pure-Python or C) reproduces the checked-in witness vectors bit-for-bit, and the vector format is documented as a versioned stream spec. [Inference, Medium — the crate's portability is verified; demand for the spec is not]
5. **Collapse the 48-binary conformance sprawl onto the asupersync task graph.** `fnp-conformance` already depends on asupersync in production (RaptorQ pipeline) and the README concedes the asupersync integration "orchestrates conformance pipelines" [Maintainer claim, High]; the optional-feature module in `fnp-runtime` is currently a type-name snapshot (decorative). Replace the ~27 one-shot phase2c evidence generators and the sequential gate script with a single cancellation-safe, telemetry-structured asupersync task graph. *Done when:* the CI gate topology runs as one asupersync-orchestrated job with per-gate cancellation and the e2e script delegates to it. [Inference, Medium — the dependency is verified; the refactor is proposed]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** NumPy is the bedrock of scientific Python and also "30 years of C and Cython carrying every memory bug that any of that code ever had" — buffer overruns in parsers, undefined behavior in edge cases, opaque stride semantics, and no machine-checkable compatibility contract [Maintainer claim, Medium — the README's "The Problem" section; the memory-safety framing is asserted, not measured here]. The stated bet: rebuild NumPy's behavior from scratch in safe Rust with (1) full behavioral compatibility — "not a subset, not 'inspired by'" — and (2) a tighter architecture: a deterministic shape/stride engine, a dual-mode strict/hardened runtime, and differential conformance against a real NumPy oracle on every CI run [Maintainer claim, Medium].

**Who feels the pain:** the README names seven audiences [Maintainer claim, Medium]: Rust applications wanting numerical arrays without unsafe C dependencies or BLAS linkage; reproducibility-critical pipelines (regulatory ML, scientific publication, financial backtesting) needing bit-exact RNG across machines; security-conscious systems reading untrusted `.npy`/`.npz` (NumPy's C parsers as attack surface); embedded Rust deployments; library authors wanting a differential-test oracle; researchers studying NumPy semantics; and NumPy users wanting a drop-in Python module with native hot paths.

**Why now:** the pitch is that Rust's ecosystem (nightly `core::simd`, `rayon` work-stealing, PyO3) is mature enough to attempt NumPy-parity performance without C, and that the differential-testing + evidence-ledger methodology can substitute for 30 years of battle-testing with machine-checkable contracts instead [Inference, Medium — the maintainer never states a "why now" explicitly; this is reconstructed from the architecture]. Whether the methodology actually substitutes for battle-testing is unproven — there are no production users, no PyPI release, and zero independent coverage [External, High within recall caveats].

**Demand-side check (2026-09-22):** a web search for independent coverage of FrankenNumPy (production users, third-party reviews, downstream forks, press) returned nothing beyond the repository itself, its indexed README/CHANGELOG/commits, and 4 forks [External, High within recall caveats]. crates.io downloads for the 10 published crates are 11–96 per crate (fnp-ndarray leads at 96) [External, High] — consistent with bot traffic and curious individuals, not adoption. The demand the project addresses is real in principle (memory-safe NumPy semantics for Rust is an unoccupied lane — §4.6 argues the vacancy is structural, not accidental: the incumbent Rust array crate deliberately does not target NumPy semantics), but there is no demand signal for *this implementation*.

**Why a rewrite, not a fork:** a fork of NumPy inherits the C/Cython attack surface and the opaque evolved semantics; only a clean room lets the maintainer re-derive every rule (the 324-pair promotion table is "exhaustively explicit", the stride engine owns all shape transforms) as small, readable, fully tested Rust functions — the codebase as "a legible specification of NumPy's actual behavior" [Maintainer claim, Medium]. The "What 'Clean-Room' Means Here" section is explicit: NumPy's C is read *for behavior* (inputs → outputs, edge cases, promotion rules, RNG state schemas) as a behavioral specification, new Rust is written against it, and the differential oracle is "the proof of behavioral equivalence; the source is not the artifact" [Maintainer claim, High on the stated doctrine]. Whether reading the C source for behavior and then writing behavior-identical Rust satisfies a strict clean-room definition is a legal judgment this packet does not make [Inference, High — flagged, not resolved].

**Adjacent context:** this is one entry in a larger solo-maintainer program — the "FrankenSuite" of clean-room Rust reimplementations — and per its own docs it is built by a multi-agent swarm: every change lands as a closed bead with the issue ID in the commit subject (2,838 closed beads at the pin [Counted, High]), with agent tooling (beads_rust triage, MCP agent mail, pre-commit static analysis, remote compilation fleet, cross-agent session search) documented in the README's "Multi-Agent Development Process" section [Maintainer claim, Medium — the tooling is documented as visible in-repo; line-level agent authorship was not measured in this assessment]. Unlike a source-only research tree, FrankenNumPy *depends* on asupersync in production: `fnp-conformance` uses its RaptorQ primitives (`EncodingPipeline`, `InactivationDecoder`, `SystematicParams`, `SymbolPool`) for the artifact-durability pipeline [Code-verified, High]. The program's thesis appears to be that foundational C infrastructure can be re-derived in Rust with machine-checked parity; FrankenNumPy is its most user-facing entry.

## 4.2 What it is — repo TL;DR

An 11-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing NumPy's behavior in Rust: dtype system with a 324-pair explicit promotion table (`fnp-dtype`), a deterministic stride/shape/broadcast calculus engine (`fnp-ndarray`), transfer/iteration semantics (`fnp-iter`), ufunc dispatch (`fnp-ufunc`, 93,179 all-rs lines — the largest engine crate), linear algebra in pure Rust (`fnp-linalg`), PCG64DXSM/MT19937/Philox/SFC64 RNG with bit-exact parity (`fnp-random` + dependency-free `fnp-random-core`), fail-closed NPY/NPZ I/O (`fnp-io`), a dual-mode strict/hardened runtime with a Bayesian decision engine and evidence ledger (`fnp-runtime`), a differential conformance harness with 48 binaries (`fnp-conformance`), and a PyO3 extension (`fnp-python`, 337,068 all-rs lines — tests, benches, and the 7.6 MB `src/lib.rs`) that exposes the full `numpy.__all__` surface through a three-tier model: native Rust fast-paths, native PyO3 classes, and identity-equal re-exports of the live NumPy [Code-verified, High on the structure; the tier claims are Maintainer claim, Medium — the mechanism is in code, the per-name tiering was not audited].

One-line verdict: **the most self-disclosing codebase assessed in this program's packets so far — the only one whose README prints its own evidence grade disavowing 97% of its benchmark claims [Inference, Medium — a comparative judgment over the packets completed to date, grounded in the in-packet evidence: the KEEP-claim audit, the 67k-line negative-evidence ledger, and the 0-row divergence ledger], shipping a NumPy symbiosis — not a replacement — under a license that forbids the likeliest evaluators from touching 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 as in the header.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 100% of `numpy.__all__` (499/499 vs the CI oracle, pinned `numpy<2.5` → 2.4.3) reachable as `fnp_python.<name>`, structurally locked by `fnp_python_covers_full_numpy_all`, which iterates the live `numpy.__all__` at runtime | partially demonstrated | The lock-in test exists in `crates/fnp-python/tests/conformance_remaining_top_level_attrs.rs` (iterates `np.__all__`, asserts reachability and `fnp.__all__ == np.__all__`) [Code-verified, High]; the 499/499 figure is a README count against the CI oracle [Maintainer claim, Medium]. The test was not executed in this assessment, and the guarantee is host-numpy-relative by construction (on numpy 2.3.x the oracle's `__all__` is 501 names) | [Code-verified + Maintainer claim, Medium] |
| 2 | 10 of 11 crates `#![forbid(unsafe_code)]`; numeric core holds zero hand-written `unsafe` | demonstrated | Strict regex census over all `.rs` files excluding comments: 0 unsafe sites in all crates except `fnp-python`; the 10 forbid gates (ufunc, runtime, random, random-core, ndarray, linalg, iter, dtype, io, conformance) verified present [Counted, High] |
| 3 | The 642 hand-written `unsafe` sites are confined to `fnp-python` and are layout-checked zero-copy buffer views | demonstrated (existence and confinement); the "layout-checked" qualifier holds on sampled sites | 642 strict-counted sites, all in `fnp-python` [Counted, High]. Sampled sites build `from_raw_parts` from an already-validated `PyBuffer::as_slice` pointer+len (redundant-by-construction), or from `repr(transparent)` cells under the GIL with explicit SAFETY comments and dtype-char guards [Code-verified, Medium — sampled, not exhaustive] |
| 4 | 8,716 `#[test]` functions (2026-09-20 count) across 11 crates | demonstrated | Counted with the README's own documented method (`rg -c '#\[test\]'` over `crates/*/src` and `crates/*/tests`): exactly 8,716, matching the README figure to the unit [Counted, High] |
| 5 | Bit-exact PCG64DXSM RNG parity for explicit seeds; no-seed constructors source OS entropy like NumPy | partially demonstrated | `fnp-random-core` (328 lines, forbid(unsafe), dependency-free, "no I/O, no entropy, no threads" [Code-verified, High]); witness-stability fixtures pin distribution outputs [Maintainer claim, Medium]; the README documents the no-seed contract change (`franken_numpy-iqo31`: fixed seed → fresh `SeedSequence` from OS entropy) [Maintainer claim, Medium]. Bit-exactness was not executed in this assessment | [Code-verified + Maintainer claim, Medium] |
| 6 | Deterministic stride calculus: a single engine (SCE) owns all shape/stride/broadcast decisions with five stated invariants | demonstrated (structure and invariants in code/docs; behavioral exhaustiveness not independently proven) | `fnp-ndarray` (2,079 src lines) owns `broadcast_shapes`, `element_count`, stride computation [Code-verified, High]; the five invariants (element-count conservation, deterministic stride-from-shape, symmetric/associative broadcast legality, single-`-1` inference, view byte-span containment) are documented in the README and enforced by tests [Maintainer claim, Medium] |
| 7 | Headline benchmark wins vs NumPy (f16 ops 10–183x, int GEMM 27–35x, sorts 12–66x, `isin` 134.5x, etc.) from the v0.2.0 campaign | aspirational | The README's own "Evidence grade (audited 2026-09-02)": of 28 headline ratios, **one** (`isin` 134.5x) is contract-grade; five are same-invocation ABBA rows with nulls; ~22 are stock `cargo bench` Criterion reads or prose timings with no null, no host field, no ELF hash [Maintainer claim, High]. The numbers are presented as a map of where native kernels exist, not as proven wins | [Maintainer claim, High] |
| 8 | Of 751 KEEP performance claims, 22 (2.9%) carry a same-invocation vs-incumbent ratio with a live incumbent arm | demonstrated | `docs/KEEP_CLAIM_INCUMBENT_COVERAGE.md` (fleet audit, 2026-07-31): 751 KEEP claims; 22 carry `**Legacy incumbent arm (same invocation):**` + `**Campaign result class:** incumbent-win` + A/A null; the 2026-07-26 contract postdates 723 of them, and a seeded hand-read of 30 of the 723 estimates ~554 do compare against a live NumPy arm but predate the schema [Maintainer claim, High — the audit is the project's own; its sampling math is reported, not re-derived] |
| 9 | RaptorQ durability: every conformance artifact protected by erasure-coded sidecars with scrub reports and decode proofs, enforced by the G8 gate | demonstrated (existence; recovery not executed) | `crates/fnp-conformance/src/raptorq_artifacts.rs` (1,761 lines) uses asupersync's `EncodingPipeline`, `InactivationDecoder`, `SystematicParams`, `SymbolPool` [Code-verified, High]; G8 gate script exists (`scripts/e2e/run_raptorq_gate.sh`) [Code-verified, Medium]; the README's "Why RaptorQ?" table argues the design vs SHA-only/par2/RAID [Maintainer claim, Medium]. Decode recovery was not executed | [Code-verified, Medium] |
| 10 | Threat model: 12 threat classes with assigned conformance suites and controls | demonstrated (existence; controls not executed) | README threat-model table (12 classes: malformed_shape, unsafe_cast_path, malicious_stride_alias, malformed_npy_npz, unknown_metadata_version, adversarial_fixture, rng_reproducibility_drift, linalg_shape_tolerance_abuse, linalg_backend_bridge_tampering, linalg_policy_unknown_metadata, corrupt_durable_artifact, policy_override_abuse) [Maintainer claim, High on existence] |
| 11 | CI: 8-gate topology (G1 fmt+lint … G8 durability), differential conformance against real NumPy on every CI run | partially demonstrated — and **red at the pin** | Workflow `ci.yml` defines the 8 gates with `needs:` chaining; 6,342 runs total [CI-observed, High]. **Greenness at the pin: RED (established 2026-09-22 via the Actions REST API)** — run 35730374809 (head = pin `7de9ba73`): G1 failed at `cargo clippy --workspace --all-targets -- -D warnings` (`cargo fmt --check` and `cargo check` passed); G2–G9 all skipped. The README badge's "G1 green" reflects the 2026-09-03 state (G1's first pass since 2026-02-26), not the pin | [CI-observed, High] |
| 12 | 30 fuzz targets across 7 fuzz crates; 261 curated seed-corpus files | demonstrated | 30 `fuzz_*.rs` files under `crates/*/fuzz/fuzz_targets/` [Counted, High]; `docs/FUZZING.md` re-verified the count 2026-09-03 with the same method [Maintainer claim, High]. Drift note: the conformance-crate section still says "27 fuzz targets" (the 2026-05-16 baseline); the Fuzzing section says 30 — minor README-vs-README drift [Code-verified, High] |
| 13 | 0 active rows in the divergence ledger (2026-05-22) | demonstrated | `docs/DIVERGENCES.md`: "**Active rows: 0** (as of 2026-05-22)" with resolved-rows provenance notes [Code-verified, High] |
| 14 | 10 of 11 crates published on crates.io at 0.3.0 (2026-09-12); `fnp-conformance` not published | demonstrated | crates.io API (2026-09-22): fnp-ufunc/ndarray/random/linalg/dtype/iter/io/runtime/python at 0.3.0, downloads 11–96; `fnp-conformance` → 404 [External, High] |
| 15 | The wheel requires NumPy: `pyproject.toml` declares `dependencies = ["numpy>=2.3"]`, `requires-python = ">=3.13"` | demonstrated | `pyproject.toml` read at pin [Code-verified, High]. The tier-3 re-export architecture *structurally* requires a live NumPy; the dependency is load-bearing, not incidental |
| 16 | Single human maintainer; multi-agent swarm development (2,838 closed beads at the pin) | demonstrated (bead count [Counted, High]); agent authorship share not measured [Not measured] | `.beads/issues.jsonl`: 2,846 rows, 2,838 closed [Counted, High]; README "Multi-Agent Development Process" documents the tooling (beads_rust, MCP agent mail, ubs, rch, CASS) [Maintainer claim, Medium]. Line-level agent authorship not measured (shallow clone); all visible commits authored by Dicklesworthstone [Git-observed, Low — shallow window only] |
| 17 | Negative-evidence ledger: 67,641 lines of recorded losses, no-ships, reverts | demonstrated | `wc -l docs/NEGATIVE_EVIDENCE.md` = 67,641 at the pin [Counted, High] |
| 18 | License rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use including benchmarking, testing, analyzing, indexing, and training-data incorporation; breach = automatic termination | demonstrated | LICENSE read verbatim at pin [Code-verified (license text), High] |

**What the inventory says in aggregate:** claims about *process* (test counts, unsafe containment, ledger sizes, fuzz targets, bead discipline, published crates) verify at High confidence and mostly to the exact unit; claims about *outcomes* (benchmark wins, 100% surface, bit-exact RNG) are either qualified by the maintainer's own evidence grading or depend on oracle runs this assessment did not execute. The single most load-bearing drift: CI red at the pin while the badge says G1 green.

## 4.4 Codebase tour

**Workspace topology (11 members, [Counted, High]):** `fnp-dtype`, `fnp-ndarray`, `fnp-iter`, `fnp-ufunc`, `fnp-linalg`, `fnp-random-core`, `fnp-random`, `fnp-io`, `fnp-conformance`, `fnp-runtime`, `fnp-python`. Source-only (excl. tests/benches/examples): **402,564 lines** [Counted, High] — matching the README's "402k-LOC workspace" figure in the `rch` tooling row to three digits, so the count is current. All-rs lines: 594,169 over 454 files [Counted, High].

**Dependency posture:** the numeric core is dependency-light by design. `fnp-random-core` is dependency-free (no I/O, no entropy, no threads, no allocation beyond caller-requested storage) [Code-verified, High]. The workspace's notable externals: `pyo3 0.28.3` (CPython bridge), `rayon 1.12.0` (unconditional — data parallelism with per-op `is_parallel_worth` size gates, so `add`/`sub`/`mul`/`div` stay serial as memory-bandwidth-bound), `getrandom 0.4.3` (OS entropy), `proptest`, `criterion`, `serde/serde_json`, and **`asupersync =0.5.0`** (pinned exact, default-features=false) [Code-verified, High]. The asupersync story, verified rather than assumed: `fnp-conformance` depends on it unconditionally and uses it for real — `raptorq_artifacts.rs` (1,761 lines) drives `EncodingPipeline`, `InactivationDecoder`/`ReceivedSymbol`, `SystematicParams`, `PoolConfig`/`SymbolPool`, `ObjectId`/`SymbolKind` for the RaptorQ sidecar/scrub/decode-proof pipeline [Code-verified, High]. In `fnp-runtime` it is an *optional* feature whose `asupersync_integration` module is a capability snapshot of four `std::any::type_name` references plus a test asserting the tag string — decorative, not load-bearing [Code-verified, High]. The README's own summary is accurate: "the asupersync integration … orchestrates conformance pipelines, not array computation" [Maintainer claim, High]. There is also an optional `frankentui` (`ftui 0.5.0`) feature for TUI observability dashboards [Code-verified, Medium].

**Data flow, end to end:**

- **Foundation — `fnp-dtype` (4,697 src lines):** the 324-pair dtype promotion table as a `const fn` match (no runtime allocation), `ArrayStorage` bridge, f16 via the `half` crate, complex dtypes. Zero unsafe [Counted, High].
- **Shape — `fnp-ndarray` (2,079 src lines):** the Stride Calculus Engine. `broadcast_shapes`, `element_count`, `contiguous_strides` as pure deterministic computations; the five documented invariants (count conservation, deterministic stride-from-shape, symmetric/associative broadcast legality, single-`-1` inference, view byte-span containment) are the non-negotiable contracts [Code-verified, High on structure; Maintainer claim, Medium on exhaustiveness].
- **Iteration — `fnp-iter` (4,030 src lines):** `Nditer`/`NditerStep` with planned iteration order, transfer semantics (copy vs view), alias-sensitive transitions rejected on invariant violation [Maintainer claim, Medium].
- **Compute — `fnp-ufunc` (83,745 src lines):** the engine room — ufunc dispatch, reductions with a contiguous-axis fast path (`reduce_sum_axis_contiguous`; the 2026-02-13 optimization that cut axis-reduction latency ~56% p50 [Maintainer claim, Medium]), Neumaier-compensated summation above 1M elements, FFT (Cooley–Tukey + Bluestein chirp-Z), polynomial families (Horner/Clenshaw), masked arrays, string ops. `#![forbid(unsafe_code)]` [Code-verified, High]. Parallelism is per-op gated: compute-heavy ops parallelize via rayon; memory-bandwidth-bound `add`/`sub`/`mul`/`div` deliberately stay serial [Maintainer claim, Medium].
- **Linalg — `fnp-linalg` (23,865 src lines):** pure-Rust decompositions (Householder QR, Golub–Kahan SVD, implicit-shifted-QR eig, Cholesky, LU), 2×2 closed-form fast paths, no BLAS/LAPACK linkage (documented limitation; optional BLAS is a Phase 3 candidate via ADR-001) [Code-verified, High on the no-BLAS claim — no blas-src/openblas in the dependency union; Maintainer claim, Medium on competitiveness].
- **RNG — `fnp-random-core` (328 src lines) + `fnp-random` (21,063 src lines):** the core holds deterministic state transforms only (SeedSequence, PCG64DXSM stepping); the outer crate adds distributions (Ziggurat normal/exponential, BTPE binomial, HRUA hypergeometric, PTRS Poisson, Lemire bounded ints — the NumPy algorithm ports [Maintainer claim, Medium]), `Generator`/`RandomState`/MT19937/Philox/SFC64, OS-entropy seeding via `getrandom`. A dedicated `no_std` CI workflow exists for the core ("Make Random Core no_std") even though the workspace as a whole is `std`-only by documented decision [Code-verified, Medium].
- **I/O — `fnp-io` (12,353 src lines):** NPY 1.0/2.0 + NPZ + DEFLATE parsers, bounded and fail-closed on hostile input, fuzzed by 7 targets with 261 corpus files; `NpyArrayBytes` as `Arc<[u8]>` for zero-copy sharing [Maintainer claim, Medium].
- **Runtime — `fnp-runtime` (1,672 src lines):** the dual-mode decision engine. Three actions (Allow / FullValidate / FailClosed) selected by a closed-form Bayesian posterior update against a fixed loss model (silent-corruption cost 100.0, false-rejection cost 125.0 — the asymmetry is the point: correctness over availability); every decision logged to an `EvidenceLedger`; overrides tracked as `OverrideAuditEvent`s [Maintainer claim, Medium — constants read in the README; the loss-model code path was not traced].
- **Conformance — `fnp-conformance` (67,168 src lines, 48 binaries [Counted, High]):** the quality backbone — oracle capture, differential runners, drift matrices, ledger-hygiene gates, API-coverage gate, RaptorQ sidecar/scrub/decode binaries, benchmark baselines, security/test-contract/workflow-scenario gates, plus ~27 one-shot phase2c evidence generators [Code-verified, High on the bin count; Maintainer claim, Medium on each binary's function]. Four test layers: differential (vs live NumPy), metamorphic (13+ algebraic identities), adversarial (fuzz + hostile inputs), witness stability (hard-coded RNG outputs) [Maintainer claim, Medium].
- **Python surface — `fnp-python` (181,564 src lines; the 7.6 MB `src/lib.rs` is the single largest file in the workspace):** no `build.rs` exists anywhere in the repo and the file carries hand-structured module docs with no codegen marker — it is hand/agent-written, not generated [Code-verified, High]. The three-tier attribute model. Tier 1: native `#[pyfunction]`s driving Rust engines with numpy fallback for unusual kwargs. Tier 2: 12 native PyO3 classes (`Generator`, `SeedSequence`, `Nditer`, `PCG64DXSM`, …) [Maintainer claim, Medium]. Tier 3: `m.add(name, &numpy.getattr(name))` — the actual NumPy object rebound, so `fnp_python.some_name is numpy.some_name` is literally `True` [Maintainer claim, Medium — the mechanism is described precisely and matches the re-export strategy]. This is the 100% surface trick, and it is load-bearing: the pip wheel declares `numpy>=2.3` as a runtime dependency [Code-verified, High].

**Unsafe arithmetic, stated explicitly:** 10 crates `forbid(unsafe_code)` + 1 crate (`fnp-python`) with no gate = **11**. Strict-counted unsafe sites: **642**, all in `fnp-python` [Counted, High]. Sampled sites are layout-checked buffer views (dtype-char guards, `PyBuffer::as_slice` validation before `from_raw_parts`) [Code-verified, Medium]. The README's "zero hand-written unsafe" for the 10 forbid crates reproduces exactly under independent recount [Counted, High].

## 4.5 The maintainer's stated case

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

1. **Surface parity as proof:** 100% of `numpy.__all__` (499/499 vs the CI oracle) reachable, structurally locked by a test that fails CI on regression [Maintainer claim, Medium — claim 1]. The lock iterates the live numpy, so it holds as numpy evolves.
2. **Safety:** memory safety via the 10/11 forbid posture and 642-site confinement [Counted, High for the census itself]; fail-closed I/O parsers for hostile `.npy`/`.npz` [Maintainer claim, Medium].
3. **Performance:** the v0.2.0 fast-path campaign (~1,230 landed `perf(...)` commits, June–July 2026 [Maintainer claim, Medium — shallow clone, not re-derived]) replacing numpy delegation with native safe-Rust `rayon`-parallel and `core::simd` kernels where NumPy leaves throughput on the table: no f16 ALU/BLAS, no integer BLAS, serial sorts, serial `cexp`. Headline ratios: f16 nan_to_num 91x, var/std 23–101x, int matmul 27–35x, bool sort 37.8x, i16 sort 66x, `isin` 134.5x, ASCII translate 183x [Maintainer claim, Medium].
4. **Rigor artifacts:** every optimization follows baseline → profile → single lever → conformance check → re-baseline → proof artifact (`artifacts/optimization/`); losses ledgered in the 67,641-line negative-evidence file [Maintainer claim, Medium; artifacts verified to exist].
5. **Determinism:** graded guarantees — bit-deterministic shape/stride/promotion, bit-exact RNG for explicit seeds, byte-deterministic `.npy` round-trips, SHA-256-stable conformance artifacts [Maintainer claim, Medium].

**The evidence grade — quoted, because it is the honest core of the packet:** the README's "Evidence grade (audited 2026-09-02)" states that of the 28 headline ratios, one (`isin` 134.5x) is contract-grade (incumbent-win, live NumPy in the same invocation, named host, ELF hash, dual A/A null), five are same-invocation ABBA rows with nulls — f16 matmul, int GEMM, batched int GEMM, bool sort, i16 sort, named in the README paragraph — and ~22 are stock `cargo bench` Criterion two-arm reads or prose timings with no null, no host field, no ELF hash — "Read the table as a map of where native kernels exist." The fleet KEEP-claim audit (2026-07-31) puts the number at 22/751 contract-grade (2.9%), with a seeded hand-read estimating ~554 of the remaining 729 do compare against a live NumPy arm but predate the 2026-07-26 schema [Maintainer claim, High]. Any downstream citation of the headline ratios as proven wins is misrepresenting the source [Maintainer claim, High — the grade is in the pinned README].

**Benchmark reproduction cost:** reproducing a headline ratio requires the ~136 MB checkout at the pin, the pinned `nightly-2026-08-31` toolchain (`rust-toolchain.toml`), a NumPy-bearing Python (the oracle; CI uses 3.12 + `numpy<2.5` → 2.4.3), and the checked-in procedure (`scripts/record_baselines.sh`-family / `run_cross_engine_benchmark` with `artifacts/contracts/cross_engine_benchmark_workloads_v1.yaml`); the environment-fingerprint rule means two baselines compare only when fingerprints match [Maintainer claim, Medium]. No independent reproduction is known to exist [External, High within recall caveats].

**What would survive an independent rerun:** the parity numbers (499/499 lock, 8,716 tests, 0-row divergence ledger — all re-countable from the tree) and the one contract-grade `isin` row; the other ~27 headline ratios would not, by the project's own grading [Inference, Medium].

---

## 4.6 Competitors

The incumbent wins on ubiquity, ecosystem, and the 30-year trust horizon; FrankenNumPy's only uncontested edge is its auditability apparatus (differential oracle harness, evidence ledgers, KEEP-claim audit, threat model) — which no competitor bothers with because no buyer currently pays for it [Inference, Medium].

- **NumPy itself (BSD-3, the incumbent):** 30 years of C/Cython, the universal dependency of scientific Python, GPU-adjacent via CuPy/JAX/PyTorch, SciPy built on it. Owns the lane by every measure [External, High]. The decisive structural fact: FrankenNumPy is not competing with NumPy — its wheel *requires* `numpy>=2.3` and its tier-3 surfaces *are* NumPy objects rebound under new names [Code-verified, High]. It is a symbiosis pitch (native fast-paths + hardened parsers + auditability, on top of NumPy), not a displacement pitch — the honest framing the README's audience table supports and the "drop-in replacement" reading contradicts [Inference, Medium].
- **`ndarray` (Rust):** the de-facto Rust N-D array crate, generic over element type and dimensionality, BLAS via `ndarray-linalg`, idiomatic Rust API designed from scratch [External, High]. Owns the "Rust-native numerics for Rust programmers" lane. It deliberately does *not* target NumPy semantics — which is exactly the lane FrankenNumPy claims, unoccupied [Inference, Medium].
- **`nalgebra`:** statically-sized linear algebra, strong in geometry/graphics/robotics [External, High]. Different abstraction; not a competitor for N-D array semantics [Inference, Medium].
- **`burn` / `candle`:** deep-learning tensor crates with autodiff and GPU backends; tensor semantics differ deliberately from NumPy [External, High]. Own the ML lane; FrankenNumPy's anti-goals explicitly cede GPU and autodiff [Maintainer claim, High].
- **`polars`:** Arrow-backed DataFrame engine [External, High]. Tabular, not numerical-array; ceded by the anti-goals [Maintainer claim, High].
- **Adjacent: `numpy`'s own trajectory.** NumPy 2.x modernized the C core; there is no public NumPy plan for a memory-safe rewrite of the core, and the project's "why a rewrite" case implicitly bets that stays true [Inference, Low]. But the incumbent is not standing still on the *performance* axis: NumPy 2.0 (June 2024) accelerated sorts via Intel x86-simd-sort and Google Highway — 10–17x on x86 sorts per Phoronix reporting — added macOS Accelerate linalg support, and 2.2+ improved free-threaded ufunc scaling [External, Medium — release notes and press coverage, 2026-09-22]. That narrows FrankenNumPy's "wins where NumPy leaves throughput on the table" story to the dtypes NumPy still doesn't accelerate (f16, integer BLAS, small/batched ops) — and note the packet's headline sort wins (bool sort 37.8x, i16 sort 66x) were measured against numpy 2.4.3, i.e. *already including* the x86-simd-sort acceleration, which is the one genuinely strong perf signal in the table even though the rows are non-contract [Inference, Medium]. If NumPy ever shipped a hardened-parser or formally-specified-semantics program, the differentiation would narrow to the Rust-embeddable story.
- **Unoccupied lane:** a memory-safe, NumPy-behavior-faithful array library for Rust with machine-checked parity evidence and a published threat model has no direct occupant — `ndarray` owns idiomatic Rust, the DL crates own GPU/autodiff, and nobody else targets "the answer NumPy would have given" as the success metric [Inference, Medium]. Whether any buyer will pay for auditability over ecosystem is the unproven bet the whole project rests on — and the rider bars the best-equipped evaluators (AI labs and their agents) from even analyzing the code [Inference, Medium].

## 4.7 Skeptic's take

*Citation convention: weaknesses are numbered 1–8 below; elsewhere in this packet "§4.7.N" means weakness N. The threat classes measure mortality; the NODUS ring (§4.9/§4.12) measures maturity — a project can carry FATAL wounds and still ring Explore, because the ring describes what the artifact is, not whether it survives. If only one FATAL could be fixed, it would be the rider (§4.7.1): §4.11's upside gates are ordered with rider removal first for exactly this reason.*

Weaknesses, threat-classed per the packet's own convention (each is substantive — capable of killing the project on its own):

1. **[FATAL] The license rider poisons the evaluation it needs most.** Barring OpenAI/Anthropic *and their affiliates and anyone acting for them* from use — where "use" is defined to include "benchmarking, testing, analyzing, indexing, or incorporating … into any … evaluation harness" — doesn't just block two companies; the "acting directly or indirectly for … or for the benefit of" prong creates legal uncertainty for any contributor near the AI supply chain, and it bars the exact parties with the resources to independently validate a 402k-line safety claim. A project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, High]. §4.8 adds the sharper turn: the rider's "analyzing" bar arguably covers this very assessment.
2. **[FATAL] The 100% is substantially re-export, and the wheel requires the incumbent.** `fnp_python.some_name is numpy.some_name` is literally `True` for tier-3 names; `pyproject.toml` declares `numpy>=2.3` as a runtime dependency [Code-verified, High]. The headline "100% of numpy.__all__" is true of the *surface* and misleading about the *engine* without the tier qualifier — the project's own tier-3 severance experiment (next step 2) is the honest way to quantify it, and it hasn't been run. A "NumPy reimplementation" that cannot function without NumPy installed is a compatibility layer with fast paths, not a reimplementation, for every workload that touches a tier-3 surface [Inference, High].
3. **[HIGH] CI is red at the pin on the lint gate while the badge says G1 green.** Run 35730374809 (head = pin, 2026-09-22): G1 failed at `cargo clippy --workspace --all-targets -- -D warnings`; G2–G9 skipped — so the 499/499 lock, the differential gates, and the ledger-hygiene gates did not execute at the assessed commit [CI-observed, High]. The README's CI section documents the 2026-09-03 recovery honestly (G1's first pass since February; ledger hygiene 100% resolved 2026-09-20), but the badge and the "G1 green" framing describe a commit that is not the pin — README-vs-CI drift at the exact commit a reader evaluates [Code-verified, High]. A project whose pitch is *auditability* failing its own lint gate at HEAD is a governance signal, not a typo.
4. **[HIGH] The benchmark ledger is 97% non-contract by its own audit.** 729 of 751 KEEP claims lack same-invocation incumbent ratios; the README's evidence grade admits ~22 of 28 headline ratios are stock bench reads [Maintainer claim, High]. The honesty is exemplary and the evidence is thin — both true at once. Until the re-recording campaign (next step 3) lands, the performance pillar is a map of kernels, not a result [Inference, Medium].
5. **[MEDIUM] One human, no PyPI, trivial registry traction.** Bus factor 1 (single git author in the visible window [Git-observed, Low — shallow clone]); the wheel builds locally via maturin but nothing is published to PyPI and no macOS/Windows wheels exist [Maintainer claim, High]; crates.io downloads peak at 96 (fnp-ndarray) [External, High]. The 2,838 closed beads are real process capital, but they are a solo diary until a second committer reads them [Inference, Medium].
6. **[MEDIUM] `UFuncArray` stores numerics as `f64` internally.** Values are `Vec<f64>` with an `IntegerSidecar` preserving exact integers through round-trips; ten integer binary ops recompute exactly on the sidecar, but "every other operation on such values rounds through f64" for i64/u64 above 2^53 [Maintainer claim, High — the Limitations section states this plainly]. Native i64/u64 arithmetic is a Phase 3 work-stream, i.e., the core numeric type has a known precision landmine the README discloses and the roadmap defers [Inference, Medium].
7. **[MEDIUM] Large dense matmul loses to OpenBLAS, by design.** Square GEMM above ~2000×2000 is slower than NumPy on OpenBLAS; there is no C BLAS linkage and the optional backend is Phase 3 (ADR-001) [Maintainer claim, Medium]. The wins are all where NumPy has no BLAS path (f16, integer, small/batched) — the project wins the races the incumbent doesn't run, which bounds the performance story to niches [Inference, Medium].
8. **[MEDIUM] The agent-swarm authorship is undocumented at line level.** The repo's own docs describe multi-agent development (beads, MCP mail, `rch` fleet, CASS) and recovery notes cite Claude session logs [Maintainer claim, Medium], but no `Co-Authored-By` census was possible in this assessment (shallow clone) and the "clean-room" doctrine section addresses source-reading, not authorship. For a project asserting clean-room status, the authorship provenance of 402k lines is an open question — parked in §4.13 [Inference, Medium].

**Bear-case steelman (strongest counter-case):** FrankenNumPy is a single-maintainer methodology-art project about *how* to re-derive infrastructure, not infrastructure. Its headline API number is achieved by re-exporting the incumbent it claims to reimplement, and its wheel cannot install without that incumbent; its benchmark table is 97% non-contract by its own audit; its CI is red at the assessed commit on the lint gate while the badge claims green; its license forbids the only entities resourced enough to validate it from even analyzing the code; it has no PyPI release, 96 downloads at best on crates.io, and zero independent users. The rational market response is to mine it for methodology (the differential harness, the ledger-hygiene gates, the KEEP-claim audit, the tiered surface model) and never deploy it. Its most likely end state is a frozen monument at the maintainer's next context switch — 402k lines of unauditable-by-license Rust that the best-equipped evaluators may not benchmark, analyze, or train on. [Inference, Medium — deliberately uncharitable; the counter-evidence is the September ledger-hygiene recovery (85→61→0 residual rows, G2 green locally) and the crates.io publication, both of which show the maintainer closing real gaps rather than coasting.]

## 4.8 Maintenance & succession

**Bus factor: 1.** One human maintainer (Jeffrey Emanuel); the visible commit window shows a single author [Git-observed, Low — shallow clone limits this to the pin]. No succession plan, no second committer, no foundation [Inference, Medium — absence of evidence across the assessed materials]. The closest thing to institutional knowledge transfer is the in-repo bead tracker (2,838 closed beads at the pin [Counted, High]) plus the evidence ledgers — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit. Review depth is unassessed: PRs-vs-direct-to-main and who reviews bead closures were not examined [Not verified] — parked as §4.13 open question 5.

**Agent authorship vs the "clean-room" posture.** The repo documents multi-agent development as a feature (README §"Multi-Agent Development Process": beads_rust, MCP agent mail, `ubs` pre-commit scanner, `rch` remote build fleet, CASS session search) and the ledger-recovery notes cite Claude session logs by name [Maintainer claim, Medium]. What is *not* documented is the line-level share: no Co-Authored-By census was possible here (shallow clone), and the "What 'Clean-Room' Means Here" section defines clean-room as a *source-reading* discipline (NumPy's C read for behavior, never translated line-by-line) without addressing *authorship* [Maintainer claim, High on the doctrine's content]. The epistemic point stands on its own: a clean-room assertion whose author bars benchmarking and analysis is an assertion no independent party may test [Inference, Medium].

**Maintenance load signals:** velocity is extreme — the CHANGELOG records 2,103 non-merge commits in the 2026-07-12 → 2026-09-11 window (~30/day) and 7,631 commits total since 2026-04-01 [Maintainer claim, Medium — shallow clone, not re-derived]; the pin itself is the latest push (2026-09-22) [External, High]. That cuts both ways: dedication, and a workload no successor inherits casually. The 2026-09-20 ledger-hygiene resolution (85 → 61 → 0 residual rows across three recovery passes, mining bead descriptions and retained session logs) shows the maintainer doing unglamorous repair work, not just landing features [Maintainer claim, High].

**License — the rider, scoped precisely (LICENSE read verbatim at pin):**

- **Restricted parties:** "OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative)." (quoted verbatim from the pinned LICENSE)
- **Grant:** "no rights are granted to any Restricted Party" — "any purported license … to any Restricted Party is null and void absent the express prior written permission of Jeffrey Emanuel."
- **Scope:** bars providing or permitting access to "the Software or any derivative work of the Software (as defined in applicable copyright law)" to or for a Restricted Party.
- **"Use" is defined expansively** — "For purposes of this rider, 'use' includes, without limitation: copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems." (quoted verbatim; emphasis on the evaluation-relevant terms is the packet's)
- **Rider precedence:** "part of the 'conditions' of this License. In the event of any conflict between this rider and any other portion of this License, this rider controls." Redistribution must include the rider "unmodified" — so it propagates into every downstream copy, including the crates.io artifacts.
- **Remedy:** breach "automatically and immediately terminates" the license; the author reserves injunctive/equitable relief and attorneys' fees; "Affiliate" = >50% voting control or power to direct management.
- **Classification:** non-OSI, source-available. Named-party discrimination fails OSD §5; the benchmarking/analysis/training bar fails OSD §6 [Inference, High — legal conclusion, not legal advice].

**Succession consequence:** even a willing acquirer inherits a license that shrinks the contributor and evaluator pool and propagates unmodified into every downstream copy; removing the rider requires the sole copyright holder's action — the same single point of failure as everything else [Inference, Medium]. The crates.io publication (10 crates, 2026-09-12) is a genuine succession-positive step — the artifacts now exist outside the maintainer's GitHub — but they carry the rider with them [External, High on the publication; Inference, Medium on the consequence].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 5** | Components validated in the relevant environment (differential conformance vs the live NumPy oracle, 8,716 tests, 0-row divergence ledger) and released on crates.io — but CI is red at the pin, no production deployment exists, and performance numbers are 97% non-contract by the project's own audit [Inference, Medium] |
| Strategic relevance | 4/5 | A memory-safe NumPy-semantics layer is central to the FrankenSuite infrastructure thesis and the lane is genuinely unoccupied; capped because the wheel structurally depends on NumPy itself [Inference, Medium] |
| Impact potential | 3/5 | A drop-in hardened NumPy surface with native fast-paths would matter to reproducibility-critical and security-conscious pipelines — if the PyPI release, the rider, and the benchmark debt ever clear [Inference, Medium] |
| Implementation feasibility | 3/5 | 402k lines, one maintainer, no release artifact for the Python module — but the Rust crates are published and the bead/ledger machinery is real process capital [Inference, Medium] |
| Time to mainstream | 2/5 | Years at best: rider removal, PyPI release, contract-grade benchmarks, and a second committer must all happen first, in that order — see trajectory triggers 1–4 for the observable flips; confidence Low because the ordering and the timelines are both inferred from bus-factor-1 priors, not measured [Inference, Low] |
| Collaboration potential | 2/5 | The rider bars the likeliest collaborators (AI labs and their agents) from even analyzing the code; bus factor 1; but crates.io publication and the documented agent workflow lower the mechanical bar [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven. FrankenNumPy is the textbook case: substantive (402,564 source lines, a 642-site unsafe census confined to the FFI boundary, 8,716 tests, a 67k-line failure ledger — all [Counted, High]) and unproven (no production users, no PyPI, CI red at the pin, 97% of performance claims non-contract by its own audit, zero independent coverage). It clears more of the Pilot checklist than a source-only tree would (real crates.io release artifacts, two tagged GitHub releases), but "a release artifact plus a bounded, real workload fit" is not met — there is no bounded real workload running it. "When in doubt, ring down" confirms Explore. The rider is the advancement blocker, priced into feasibility (3) and collaboration (2).

**Methodology fit (for the FrankenSuite):** adopt the patterns, not the package — the differential-against-oracle conformance harness, the ledger-hygiene gates (G2's machine-checkable `host=`/`worker=`/`harness=`/ELF-hash row contract), the KEEP-claim incumbent-coverage audit, and the negative-evidence ledger are directly importable into how the program evaluates the other 42 repositories. Do not depend on the software: the rider, the missing PyPI release, the red pin, and the non-contract benchmarks disqualify it as a dependency, benchmark target, or training-data source. The one crate the methodology-export needs — `fnp-conformance` — is the one crate not published; fixing that is next step 1 [Inference, High].

---

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — the `numpy.__all__` API surface and the NPY/NPZ formats.** Inherited standards; commodity by definition — surface coverage is table stakes, and the tier-3 re-export model concedes the point architecturally: the surface is NumPy's, served by NumPy. Moves right only if NumPy moves it: every `numpy.__all__` addition is a new name the structural lock-in test forces the project to absorb — which the re-export tier absorbs for free and the native tier must fund [Inference, Medium]. The commodity has a risk tail: NumPy 2.0 already cut the main-namespace object count ~10% and `numpy.lib` ~80% (2024 release notes [External, High]), and NumPy 2.5.0 (June 2026) expired a large batch of 2.0-era deprecations — each such restructuring is a reactive-absorption event for the lock-in test and a slow rot vector for the tier-3 binding underneath it [Inference, Medium].
- **Custom-built, approaching Product — the 402k-line reimplementation core** (`fnp-ufunc`, `fnp-linalg`, `fnp-random`, `fnp-io`, the stride engine). Custom-built on process rigor; product-adjacent for Rust consumers (10 crates on crates.io at 0.3.0) but not yet product for Python users (no PyPI, no wheels). Moves right with a PyPI release plus an independent benchmark; decommissions (becomes a monument) if the maintainer context-switches or NumPy absorbs the hardening narrative [Inference, Medium].
- **Custom-built, closest to Product — the differential-against-oracle conformance harness + ledger machinery.** The packet's own "real export" (§4.9): 8,716 tests, four test layers, ledger-hygiene gates, the KEEP-claim audit, 67k lines of negative evidence. It is the most *executed* component in the tree — but not yet packaged for external adoption (`fnp-conformance` is the unpublished crate). Moves right if published and adopted (next step 1); stays repo-local tooling, invisible outside the repo, while the rider blocks the likeliest adopters [Inference, Medium].
- **Genesis — the strict/hardened dual-mode runtime with Bayesian decision engine + evidence ledger, and RaptorQ durability artifacts for conformance.** No incumbent ships "be NumPy-compatible" and "fail closed with a logged posterior" as a first-class mode switch; nobody else erasure-codes their test artifacts with decode proofs. Moves right if the ledger becomes a reviewed, origin-bound provenance mechanism or the RaptorQ pattern is adopted by artifact-heavy projects; stagnates as a single-maintainer log format otherwise [Inference, Medium].

**Residual product gaps (what's missing / risky):**

1. **No PyPI release; no macOS/Windows wheels.** The Python module — the actual 100%-surface deliverable — has no distributable artifact; `pip install .` builds locally on Linux/CPython 3.13 only [Maintainer claim, High].
2. **CI red at the pin** (claim 11): G1 clippy failure, G2–G9 skipped — the differential, ledger-hygiene, and durability gates did not execute at the assessed commit [CI-observed, High].
3. **Benchmark debt:** 729/751 KEEP claims non-contract (claim 8); the re-recording campaign is defined but not run [Maintainer claim, High].
4. **`UFuncArray` f64 intermediary** for i64/u64 above 2^53 (see §4.7 weakness 6); native integer arithmetic is Phase 3 [Maintainer claim, High].
5. **Large dense GEMM vs OpenBLAS** — structurally slower above ~2000×2000 with no BLAS linkage; optional backend is Phase 3 (ADR-001) [Maintainer claim, Medium].
6. **The tier-3 surface is NumPy itself** — any NumPy behavioral change, packaging change, or license change propagates directly into `fnp_python`; the symbiosis is also a single point of upstream dependence [Inference, Medium].
7. **README-vs-CI drift** — the badge's "G1 green" describes 2026-09-03, not the pin; the conformance section's "27 fuzz targets" vs the Fuzzing section's 30 [Code-verified, High]. The project's own audit cadence is the mitigation; the drift rate vs. audit rate is unmeasured [Inference, Medium].
8. **Agent-authorship share unmeasured** — the clean-room doctrine addresses source-reading, not who wrote the 402k lines [Inference, Medium].

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

All horizons **[Inference]** — forecasts, not findings; confidence Low unless noted.

**12-month base case [Inference, Medium]:** velocity continues; the clippy gate goes green at a new pin — *if* the failure is a toolchain-lint surprise or a small set of new warnings (the specific lints were not retrieved in this assessment; see §4.13 open question 7), rather than a symptom of review-depth strain; the KEEP re-recording campaign starts but doesn't finish; no PyPI release; the rider stands. The methodology gets mined (ledger-hygiene gates appear in sibling repos); the software gets no production users. Ring: Explore, unchanged.

**24-month base case [Inference, Low]:** one of two shapes. Either the maintainer's program compounds — PyPI release, contract-grade benchmark majority, `fnp-conformance` published and adopted, rider narrowed — and the packet's checklist starts scoring above zero; or velocity decays after the parity arc completes and the tree enters maintenance drift (README drift compounding, CI bit-rot, the numpy-2.5+ `__all__` evolution forcing reactive tier-3 absorption). The base case leans toward the second shape on bus-factor-1 priors.

**60-month base case [Inference, Low]:** the software is either a niche artifact with a small hardened-parser/RNG-parity following or dormant — the abandonment end state in the §4.7 steelman. The methodology-export (differential-against-oracle conformance, ledger-hygiene gates, KEEP-claim audits, negative-evidence ledgers) is the durable survivor either way.

**Bifurcation — what the upside requires:** all four, in rough order: (a) the rider narrowed or removed (trigger 3) — without this nothing else matters for adoption or independent validation; (b) a PyPI release with wheels (trigger 1); (c) the KEEP re-recording campaign crossing contract-grade majority with G2 green in CI (triggers 2, 6); (d) a second human committer (trigger 4). The rider is the *necessary* condition, not merely first in a list: any three of the four **including the rider** moves the ring conversation to "can we pilot"; all four plus a bounded real workload fit is what actually meets the Pilot bar.

**Bifurcation — what decay looks like:** commit velocity falls off a cliff (trigger 9), CI goes red or silent, the README drifts past the project's own audit cadence, the tree freezes as a 402k-line monument with a numpy-version-pinned re-export tier slowly rotting underneath it. Decay is the default outcome for bus-factor-1 infrastructure without institutional capture — the base case, not the tail.

**Revisit triggers (observable, falsifiable):** check any of these; each names the exact observation that flips it:

1. **A PyPI release appears** — `pip index versions frankennumpy` non-empty with wheels for at least Linux/macOS. Flips the "no distributable Python artifact" judgment.
2. **KEEP-claim audit crosses 80% contract-grade** — `docs/KEEP_CLAIM_INCUMBENT_COVERAGE.md` re-run showing ≥600/751 with same-invocation incumbent ratios. Flips the benchmark pillar from map-of-kernels to results.
3. **Rider narrowed or removed** — LICENSE diff dropping the named-party restriction. Flips usability for restricted parties and contributor-pool risk. The advancement blocker for the Explore ceiling.
4. **Second human committer with merge rights** — bus factor > 1 on the contributor graph. Flips succession risk.
5. **G1–G9 green at a new pin** — the Actions run for the assessed commit shows all gates executed and passed. Flips the red-pin judgment (the current failure is a lint gate, so this is the cheapest trigger on the board).
6. **Independent benchmark or review published** — any third party reproducing or contesting the numbers. Flips "zero independent coverage."
7. **`fnp-conformance` published on crates.io and adopted externally** — the methodology-export trigger; flips "repo-local tooling."
8. **NumPy ships a memory-safe core or hardened-parser program** — the kill-test-adjacent competitor move: if the incumbent absorbs the safety narrative, the differentiation collapses to "Rust-embeddable NumPy semantics," and the Rust-embeddable story has to carry the whole pitch alone [Inference, Medium].
9. **Abandonment tripwire** — no commits for 60 days or the CI workflows disabled/archived: re-ring to Monitor and treat the tree as a retired artifact. The decay sensor the steelman's end state needs.

## 4.12 Verdict & NODUS ring

**NODUS ring: Explore.** The Rulebook's Explore rule is explicit: *the default for substantive-but-unproven*. FrankenNumPy is the textbook case: substantive (402,564 source lines, a 642-site unsafe census confined to the FFI boundary, 8,716 tests, a 67,641-line failure ledger, 10 crates on crates.io — all [Counted/External, High]) and unproven (no production users, no PyPI release, CI red at the pin, 97% of performance claims non-contract by its own audit, zero independent coverage, bus factor 1). The crates.io publication and the two tagged GitHub releases clear more of the Pilot checklist than a source-only tree would, but "a release artifact plus a bounded, real workload fit" is not met — the Python module has no distributable artifact and no bounded real workload runs the Rust crates. "When in doubt, ring down" confirms Explore rather than Pilot. The rider is already correctly instrumented as an **advancement blocker**: quoted as the adoption ceiling in §4.8, priced into the NODUS feasibility (3) and collaboration (2) scores, and wired to revisit trigger 3. The ring reads: **Explore — substantive, unproven, and currently un-advanceable past Explore while the rider stands** [Inference, Medium]. No Rulebook amendment; v1.0 stands.

**The one-paragraph case:** FrankenNumPy is a 402k-line bet that NumPy's behavior can be re-derived in safe Rust with machine-checked parity and published proof of every claim — and on process honesty it is winning that bet further than any peer: a 642-site unsafe census confined to the PyO3 boundary, 8,716 tests, a 67k-line ledger of its own failures, a KEEP-claim audit that disavows 97% of its own benchmark claims, and a divergence ledger sitting at zero rows. But the product case is hollow at the pin: the 100% API surface is substantially NumPy re-exported (the wheel requires `numpy>=2.3`), the speed numbers are non-contract by the project's own grading, CI is red at the pin on the lint gate while the badge says green, one human is the entire bus factor, and the license forbids the likeliest evaluators from even analyzing the code. Explore the methodology — especially the differential harness and the ledger-hygiene gates; the software stays behind the rider's ceiling until trigger 3 fires. [Inference, Medium — a recommendation plus a forecast, both the analyst's judgment.]

## 4.13 Limitations and open questions (analyst-facing)

**What was not done:** nothing was compiled or executed (no Rust toolchain in this environment); no test suite was run (so the 499/499 surface lock, the RNG bit-exactness, and the differential gates are mechanism-verified, not outcome-verified); no benchmark was reproduced; the full commit history was not pulled (shallow clone — bead/commit velocity figures are maintainer-reported; authorship analysis covers the pin window only); review depth (PRs-vs-direct-to-main, who reviews bead closures) unassessed; the G1 clippy failure's specific lints were not retrieved (Actions log download requires auth); per-name tier-1/2/3 attribution in `fnp_python` was not audited; the "12 PyO3 classes" figure was not independently counted; the KEEP audit's sampling math was reported, not re-derived.

**CI greenness at the pin: ESTABLISHED (2026-09-22)** — per-job conclusions fetched via the Actions REST API: run 35730374809 (head = pin `7de9ba73`): G1 failed at `cargo clippy --workspace --all-targets -- -D warnings` (`cargo fmt --check` and `cargo check` passed); G2–G9 (unit+property, differential, security, test contract, workflow forensics, performance budget, durability, wheel) all skipped. Greenness is red-on-lint, not unknown.

**Open questions that would most change the verdict, in order of load-bearing weight:**

1. **What fraction of `numpy.__all__` resolves through native Rust vs tier-3 re-export?** The tier model is documented but the per-name attribution is unaudited; the severance experiment (next step 2) would turn the packet's central qualification into a number. A high re-export share reframes the project as a compatibility layer, not a reimplementation.
2. **Does the rider bar this very assessment?** The license's "analyzing" prohibition arguably covers the FrankenSuite's evaluation activity. A legal reading either way changes whether the program may continue touching the repo at all.
3. **What fraction of the tree's lines are agent-written?** The repo documents multi-agent development but no line-level census exists; a `git blame` sample over full history would settle whether "clean-room" is a defensible label or a murky one.
4. **Would the 499/499 lock and the differential gates pass at the pin?** Mechanism-verified, outcome-unknown — and unknowable from CI, which never got past the lint gate at the assessed commit.
5. **What is the review depth?** PRs-vs-direct-to-main, who reviews bead closures, whether any of the 2,838 closed beads saw a second pair of eyes — unassessed; determines whether the bead tracker is institutional knowledge or a solo diary.
6. **Is there any production user or demand signal?** One real deployment would move the impact-potential score and the 24-month trajectory more than any code change. (Search 2026-09-22: none found.)
7. **What are the G1 clippy lints at the pin?** A new-lint-vs-new-code question: if the failure is a toolchain-lint surprise, the fix is trivial and trigger 5 is cheap; if it is new warnings in new code, it signals review-depth strain.
8. **Is there latent demand for NumPy semantics in Rust beyond this repo?** The demand-side check found no coverage *of FrankenNumPy*; the adjacent question — whether the Rust ecosystem (ndarray issue tracker, RFCs, embedded-ML teams) has asked for NumPy-faithful semantics — would size the unoccupied lane in §4.6 as structural vs accidental.

---

## Deepening questions — Rulebook §5's binding eight, one paragraph each

*§5→location mapping: Provenance ← the evidence ledger + RaptorQ sidecars (claims 9, 18); Embeddable unit ← `fnp-io` / `fnp-random-core`, sourced from the crate structure and the Limitations section; Unexercised option value ← asupersync orchestration, the `no_std` core workflow, optional RaptorQ-by-default; Benchmark honesty ← §4.5 plus the KEEP audit (claim 8); Governance path ← §4.8 plus §4.7 weakness 5 (bus factor); License as strategy ← §4.8 plus §4.7 weakness 1 (rider); Agent-era fit ← new; Kill test ← §4.7's bear-case steelman plus trajectory trigger 8.*

**1. Provenance.** The repo's provenance machinery is the evidence ledger plus the RaptorQ artifact pipeline: every runtime decision is logged with timestamp, mode, class, evidence terms, and action [Maintainer claim, Medium], and every conformance artifact is SHA-256-hashed with erasure-coded sidecars, scrub reports, and decode proofs that are machine-checkable [Code-verified, High on existence]. But the ledger records *decisions about compatibility*, not *who produced the code* — there is no author attestation anywhere in the chain, and the multi-agent development process (§4.8) means "who" is itself a swarm of human-plus-agent contributors [Inference, High]. Portable attestation would require hash-chained, signed, write-time-bound entries — the direction pointed to by recent machine-checked results on provenance (e.g., arXiv 2606.24322, June 2026), whose theorems show content/lineage defenses are malleable via origin laundering and write-time origin binding is *necessary* [External, Medium]. The quieter provenance layer is the benchmark discipline itself: contract-grade rows bind a number to a named host, an executing-ELF hash, and an invocation ID — a number that knows which binary produced it [Maintainer claim, Medium]. What nothing records is authorship: the §4.8 agent-authorship question (what share of 402k lines is agent-written) is entirely unaddressed by the machinery, which is the gap that matters most for the clean-room posture [Inference, High].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is `fnp-io`: a `#![forbid(unsafe_code)]`, bounded, fail-closed NPY/NPZ parser fuzzed by 7 targets with 261 curated corpus files — a hardened NumPy-format reader for any Rust program that ingests third-party `.npy` files, which is exactly the "security-conscious systems" audience the README names [Code-verified, High on the crate's properties; Maintainer claim, Medium on the fail-closed behavior]. The runner-up is `fnp-random-core`: 328 lines, dependency-free, no I/O, no entropy, no threads — a portable NumPy-compatible SeedSequence/PCG64DXSM core any language can port, with witness fixtures pinning the streams [Code-verified, High]. Adoption cost: both are on crates.io at 0.3.0, so the mechanical cost is one dependency line — but the license rider travels *unmodified* into every downstream copy by its own terms, so the legal cost is accepting the named-party restriction and its automatic-termination remedy into your own dependency tree [Inference, High]. The `fnp-python` extension, by contrast, is *not* an embeddable unit in the Rust sense: it requires CPython ≥3.13 and a live NumPy ≥2.3 [Code-verified, High].

**3. Unexercised option value.** Three capabilities the architecture holds but has not used. First, asupersync orchestration: the dependency is production load-bearing in the RaptorQ pipeline and the README concedes it "orchestrates conformance pipelines," yet the 8-gate CI topology still runs as a sequential shell-script chain plus ~27 one-shot phase2c binaries — a cancellation-safe, telemetry-structured task graph is designed-for but unbuilt [Code-verified, High on the current state; Inference, Medium that the graph is the natural next step]. Second, `no_std` portability: a dedicated CI workflow ("Make Random Core no_std") exists and `fnp-random-core` is already dependency-free and allocation-disciplined, but the workspace is `std`-only by documented decision and there are zero `#![no_std]` declarations — the core could ship to embedded targets while the workspace stays std [Code-verified, Medium]. Third, RaptorQ-by-default: the sidecar/scrub/decode-proof pipeline is built and gated (G8) but the durability story is conformance-artifact-scoped; making it the default for user-facing artifact bundles (saved models, reproducibility ledgers) would convert "survives bit-rot" from held option to load-bearing differentiator [Inference, Medium]. What unlocks each: the asupersync task-graph refactor (next step 5), a `no_std` feature flag on the core, and a default-on flag plus recovery demonstrated in CI for user artifacts [Inference, Medium].

**4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the project's own, and even those are mostly disavowed: the README's evidence grade (audited 2026-09-02) admits that of 28 headline ratios only `isin` 134.5x is contract-grade (same-invocation incumbent, named host, ELF hash, dual A/A null), five are same-invocation ABBA rows with nulls (f16 matmul, int GEMM, batched int GEMM, bool sort, i16 sort), and ~22 are stock `cargo bench` Criterion two-arm reads or prose timings with no null, no host, no ELF hash [Maintainer claim, High]. The fleet KEEP audit hardens the picture: 22 of 751 kept claims (2.9%) carry the incumbent-win contract; a seeded hand-read of 30 of the remaining 729 estimates ~554 do compare against a live NumPy arm but predate the 2026-07-26 schema — so the debt is substantially re-recordable rather than re-measurable, which is good news for next step 3 [Maintainer claim, High]. No independent reproduction is known [External, High within recall caveats]; reproduction costs a ~136 MB checkout, the pinned nightly toolchain, and a NumPy-bearing Python with matching environment fingerprints. Which numbers are load-bearing for the thesis? None of the perf ratios — they are disavowed by their author; the thesis actually rests on the parity evidence (the 499/499 structural lock, 8,716 tests, the 0-row divergence ledger), which is the honest foundation and the one an independent rerun could falsify [Inference, Medium]. The honesty audit extends to non-numeric claims: the "G1 green" badge is stale at the pin (claim 11), and the conformance section's "27 fuzz targets" predates the Fuzzing section's re-verified 30 — the project's audit cadence catches these, but at the pin two instances were live [Code-verified, High].

**5. The governance path.** The credible route from one maintainer to an institution runs through four gates in rough order: rider removal, a PyPI release with wheels, the KEEP re-recording campaign reaching contract-grade majority with G2 green in CI, a second human committer (trajectory triggers 3, 1, 2, 4). The starting position: no succession plan, no second committer, no foundation, no distributable Python artifact [Inference, Medium on the absences — the no-PyPI half is Maintainer claim, High]. The closest thing to institutional knowledge transfer is the in-repo bead tracker (2,838 closed beads at the pin [Counted, High]) plus the evidence ledgers — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit; review depth is unassessed [Not verified] and parked as §4.13 open question 5. What breaks first if velocity decays: the README audit cadence — the repo's own history shows badge and count drift within weeks of the pin — then CI bit-rot (the G1 clippy failure at the pin is either a one-line fix or the first symptom); the 60-day abandonment tripwire (trigger 9) is the observable sensor [Inference, Medium]. One scope correction the packet makes explicit: the crates.io publication (10 crates, 2026-09-12) is already a partial institutionalization — the artifacts exist outside the maintainer's GitHub — but they carry the rider unmodified, so publication without rider reform is distribution of the ceiling, not removal of it [Inference, High].

**6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates (>50% voting control or power to direct management); and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — barring "use" defined expansively (copying … benchmarking, testing, **analyzing, indexing** … incorporating into datasets, training corpora, evaluation harnesses, or pipelines for machine learning or other automated systems), with automatic termination on breach and a requirement that the rider propagate unmodified into every downstream copy [Code-verified (license text), High]. Does the exclusion serve or sabotage the stated mission? It sabotages adoption and evaluability: the entities with the resources to validate a 402k-line safety claim — and their agents — may not benchmark, test, analyze, or index the code, while the "acting for" prong creates legal uncertainty for any contributor near the AI supply chain; it is already priced as the Explore ceiling (feasibility 3, collaboration 2, trigger 3) [Inference, High]. What it arguably *serves* is a defensive intent — denying 402k lines of curated numerical code to rival training corpora — but that intent is unlabeled by the author and the cost is asymmetric: the project selects for adopters who cannot evaluate it, and a project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, Medium]. The remaining strategy point: the rider is a licensee-facing contract term — it binds users, not the author — so it neither creates nor answers any copyright question about the tree; its strategic function is access control, not clean-room hygiene [Inference, Medium].

**7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is the eval-harness workload: an agent team needing a deterministic, inspectable, NumPy-compatible fixture for tool-use evaluation — the differential-against-oracle conformance harness (8,716 tests, four layers, witness-stable RNG streams) is already the shape of an agent benchmark, and the fail-closed I/O parsers are the shape of a safe untrusted-input fixture [Inference, Medium]. What would have to become true first: a PyPI release (there is no distributable artifact to pin an eval to), contract-grade benchmarks (evals need numbers, not maps of kernels), and — the blocking irony — the rider narrowed or removed, because AI labs and their agents are currently barred by name from even *analyzing* the code: the target user is excluded by the license, and the recursion is noted (this packet is itself an agent-assisted assessment of agent-built code under an anti-agent-analysis rider) [Inference, Medium].

**8. The kill test.** The single experiment that would falsify the core thesis — that a clean-room Rust NumPy with machine-checked parity and published proof of every claim is a differentiable, adoptable artifact — is the one the project designed for itself: the tier-3 severance experiment (next step 2). If a wheel built with tier-3 re-exports severed resolves only a small fraction of `numpy.__all__` natively, the "100%" is substantially the incumbent rebound, and the reimplementation thesis fails by the project's own tier model — not by a critic's [Inference, Medium]. Two secondary falsifiers sit behind it: a competitor move (NumPy shipping a memory-safe core or hardened-parser program, trajectory trigger 8 — collapsing the differentiation to "Rust-embeddable NumPy semantics") and the abandonment tripwire (trigger 9: 60 days without commits or disabled CI re-rings to Monitor). The production checklist is the inverse of this test — what success requires, scored at the pin as a 10-item checklist with **0 of 10 fully met and 2 partially met**: PyPI release with wheels (unmet), KEEP contract-grade majority (unmet — 22/751), G1–G9 green at a pin (unmet — red on lint), `fnp-conformance` published and adopted (unmet), native i64/u64 arithmetic (unmet — Phase 3), large-GEMM parity or BLAS backend (unmet — Phase 3), signable license (unmet), bus factor > 1 (unmet). The two partials: crates.io publication of 10/11 crates (the Rust half of distribution exists) and the ledger-hygiene recovery to 100% with G2 green locally (the evidence machinery works — it just didn't run in CI at the pin) [Inference, Medium].