# FrankenTorch — RULEBOOK v1.0 Assessment Packet v2

**Repository:** `Dicklesworthstone/frankentorch` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `91cda6541a4402caff217f014e0535429dade9ac` (2026-09-22 09:06:42 -0400 = 13:06:42 UTC [Git-observed, High]; matches GitHub `pushed_at` 2026-09-22T13:07:04Z, so the pin is the latest push [External, High]) · **Last push:** 2026-09-22 [External, High] · **Scope:** the pinned commit only. No GitHub Releases; no tags on the default branch (CHANGELOG names only a snapshot tag `ft2-snapshot`, 2026-06-27) [External, High]. *Cold-reader note: "vN" below = drafts of this packet (rewrite-loop rounds); a "bead" is the repo's issue-tracker unit; "rch" is the maintainer's Remote Compilation Helper, which offloads cargo builds/tests to a fleet of remote workers.*


**Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/frankentorch-verify` (4,969 files, 155 MB, verified non-empty); history deepened (blobless) to 6,305 commits for the authorship sample — the working tree stayed at the pin. Read: root `Cargo.toml`, all 13 crate manifests, `Cargo.lock`, `LICENSE` (verbatim), README, AGENTS.md, `CHANGELOG.md`, both CI workflow files, `docs/NEGATIVE_EVIDENCE.md` (head + structure), `docs/RELEASE_READINESS_SCORECARD.md` (digest), `docs/UBS_POLICY.md` (digest), `docs/planning/PARITY-COVERAGE.md` (head), `EvidenceLedger` in ft-runtime, `ExecutionMode` in ft-core, the workspace lint table. Counted: `.rs` files/lines per crate (incl. ft-api/src/lib.rs at 173,166 lines), unsafe sites with a comment-stripping parser (116 sites across the two kernel crates), agent co-authorship trailers in the last 500 commits, full-history author distribution (6,305 commits), fixture files, conformance binaries, beads issues, fuzz targets (55), `#[test]` attributes (~6,160), `use asupersync::` paths (zero structured-concurrency runtime sites), benches/ inventory. Queried: GitHub REST API for stars/forks/releases/tags, Actions runs + per-job conclusions for the pin. Searched the web for independent coverage of FrankenTorch. **Not done:** the workspace was never compiled, nothing was executed, no test suite was run, no benchmark was reproduced; CI job logs are admin-restricted and were not read; the GH_TOKEN value embedded in one workflow file is redacted by this analyst's tooling and was not classified beyond its presence. Assessment date: 2026-09-22.

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

---

## Hook

A 513,616-line [Counted, High], single-maintainer, clean-room PyTorch reimplementation in Rust whose most quotable benchmark against PyTorch is a 1.006x lower confidence bound on one op — because its own evidence rules forbid it from quoting the other thirteen lanes [Maintainer claim, High]. It keeps a 42,708-line ledger of its failures [Counted, High], publicly retracted its own headline SDPA win as a layout artifact [Maintainer claim, High], and ships a Deterministic Autograd Contract — replayable gradient graphs with provenance-complete evidence — that PyTorch itself does not offer [Code-verified, High on existence]. The catch: 45% of recent commits are agent-co-authored [Git-observed, High], the license bars OpenAI and Anthropic from even *analyzing* the code [Code-verified (license text), High], and its flagship CI failed at the pin in under a minute [CI-observed, High].

---

## TL;DR

- **What it is:** A from-scratch Rust reimplementation of PyTorch's CPU eager-mode semantics (513,616 first-party lines / 754 files across 13 crates at the pin [Counted, High]), organized around the Deterministic Autograd Contract: replayable, seeded, provenance-logged gradient computation [Code-verified, High]. Single human maintainer (Jeffrey Emanuel) plus agent personas, under extreme-velocity development: 6,305 commits since 2026-02-13 [Git-observed, High].
- **Strongest evidence:** A 42,708-line negative-evidence ledger with a standing measurement-integrity gate (name the worker, name the harness, replicate before quoting — adopted 2026-08-15) [Counted + Maintainer claim, High]; the ledger's own verdict that exactly one of fourteen vs-PyTorch lanes is quotable [Maintainer claim, High]; the SDPA layout correction, where the maintainer publicly retracted a 2x win as a 3-D-vs-4-D layout artifact [Maintainer claim, High]; differential conformance against a PyTorch oracle with 33 fixture files and 11 forensic binaries [Counted, High]; 1,826 tracked beads issues [Counted, High].
- **Strongest doubts:** The performance thesis rests on a single quotable lane (`prelu_noshortcut`, 1.048–1.180 median) — every other lane is uncertified by the project's own rules [Maintainer claim, High]; the flagship `phase2c-reliability-gates` CI run against the pin failed in ~55 seconds [CI-observed, High]; no releases, no tags, bus factor 1 [External + Git-observed, High]; the rider bars the likeliest evaluators (AI labs and their agents) from using, benchmarking, or analyzing the code [Code-verified (license text), High]; the docs claim "unsafe forbidden" while the tree holds **116** counted unsafe sites under deny-gates with documented allows and SAFETY-invariant comments [Counted, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 4 — see §4.9). Substantive-but-unproven is the textbook Explore case; the methodology (measurement-integrity gates, forensic evidence ledgers, the allocator-gap diagnosis) is the exportable artifact, the software is currently un-advanceable while the rider stands.

---

## Quick Links

Pin-relative links (`blob/91cda6541a4402caff217f014e0535429dade9ac`). Every link below was individually fetched on 2026-09-22 and returned HTTP 200 [Verified, High]. No GitHub Releases page exists for this repo (API: empty); the workflows, changelog, license, README, and key docs were read at the pinned commit, not inferred.

1. [Repository](https://github.com/Dicklesworthstone/frankentorch)
2. [README](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/README.md)
3. [AGENTS.md (agent operating manual)](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/AGENTS.md)
4. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/LICENSE)
5. [Changelog](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/CHANGELOG.md)
6. [Negative-evidence ledger](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/docs/NEGATIVE_EVIDENCE.md) — 42,708 lines at the pin
7. [Release-readiness scorecard](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/docs/RELEASE_READINESS_SCORECARD.md) — dated 2026-06-22, three months before the pin
8. [Parity-coverage audit](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/docs/planning/PARITY-COVERAGE.md)
9. [UBS policy](https://github.com/Dicklesworthstone/frankentorch/blob/91cda6541a4402caff217f014e0535429dade9ac/docs/UBS_POLICY.md)
10. [phase2c reliability-gates CI](https://github.com/Dicklesworthstone/frankentorch/actions/workflows/phase2c_reliability_gates.yml) — run #35731363456 against the pin: failure in ~55s
11. [Dynamic int8 exact-parity CI](https://github.com/Dicklesworthstone/frankentorch/actions/workflows/dynamic_int8_exact.yml)

---

## Did You Know

On 2026-06-21 the maintainer publicly retracted his own headline SDPA win. The 3-D `[16,512,64]` gauntlet lane had FrankenTorch ~2x faster than PyTorch — then he discovered PyTorch *has* a fast f64 SDPA path, selected by layout: at identical FLOPs PyTorch runs 22.96 ms on 3-D but 4.53 ms on 4-D `[2,8,512,64]`, while FrankenTorch runs 9.78 ms vs PyTorch's 6.20 ms at 4-D — FrankenTorch 1.58x *slower*. The earlier "PyTorch CPU has no f64 flash" premise was declared wrong in the scorecard, the gauntlet lane was corrected to 4-D, and the win was struck from the quotable set. The retraction is recorded in the release-readiness scorecard under "SDPA layout correction" [Maintainer claim, High — from the project's own docs]. The deeper finding from the same campaign: on alloc-bound lanes the gap was never compute — giving FrankenTorch a caching allocator (measurement-only mimalloc) showed 40–73% of its time was the system allocator, and its pure-Rust compute went near-parity-to-winning on every lane [Maintainer claim, Medium].

---

## Franken-worthy next steps

1. **Adopt the standing measurement-integrity gate program-wide:** every repository assessment (and every performance claim the program publishes) should carry the frankentorch-banfj rules — name the worker, name the harness, quote both estimators, replicate before quoting a standing. This project is the exemplar, and its own history (the SDPA layout retraction, the median-estimator 33–51% ambient-load finding) is the justification. *Done when:* the four rules are written into the program's assessment protocol with a named owner. [Inference, High — process proposal]
2. **Extract the allocator-gap diagnosis as a first-class benchmark confound — and certify the second quotable lane:** FrankenTorch measured that PyTorch's caching allocator — not its MKL kernels — accounts for 40–73% of the gap on alloc-bound lanes. Any future Rust-vs-PyTorch benchmark that does not allocator-normalize is measuring allocator choice, not compute. *Done when:* the program's benchmark checklist requires a stated allocator for both arms and an allocator-normalized control row. [Inference, High]
3. **Treat the rider as a supply-chain screen:** any FrankenSuite dependency candidate with a named-party restriction fails intake automatically. FrankenTorch is the case that forces it — its likeliest users (AI labs running ML workloads) are named Restricted Parties. *Done when:* the intake rule is committed to the program's dependency policy. [Inference, High]
4. **Re-establish CI greenness at a new pin and publish the failing gate:** the first grading round established run #35731363456 (head = pin) failed in ~55 seconds — consistent with a G1 fmt/clippy failure, exact gate unestablished (job logs are admin-restricted). *Done when:* a phase2c run goes green at a new pin, or the failing gate is named with the log. [Inference, High]
5. **Mine the DAC evidence ledger as the methodology export:** the bounded, hash-stable EvidenceLedger (one entry per dispatched op, 32,768-entry soft cap, deterministic scheduler-replay property tests) is a provenance pattern no incumbent ML framework ships. *Done when:* the ledger schema is extracted as a standalone design doc the program can reference for agent-era auditability. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** PyTorch is a Python/C++ hybrid whose autograd is non-deterministic by default, whose memory safety rests on C++ rather than the type system, and whose gradient computation is an opaque process — when a training run produces wrong gradients, the evidence trail is whatever logging you remembered to add. The maintainer's stated bet is that a clean-room Rust reimplementation can deliver: memory safety without a GC, a Deterministic Autograd Contract (every gradient computation replayable, seeded, and evidence-logged), strict-vs-hardened compatibility modes, and differential conformance against PyTorch as the behavioral oracle [Maintainer claim, Medium].

**Who feels the pain:** teams that need reproducible ML — regulated industries, scientific computing, anyone debugging a divergent training run — where "the gradients differ between runs" is currently answered with `torch.use_deterministic_algorithms` (best-effort, per-op, no provenance) rather than a contract [Inference, Medium].

**Why now:** the Rust numerics ecosystem (portable SIMD, `rayon`, mature BLAS-alternative crates) is sufficient to attempt CPU-parity without MKL, and the agent era creates a new consumer: agents that train, fine-tune, and evaluate models need deterministic, auditable gradient computation as infrastructure, not as a debugging flag [Inference, Medium]. Whether that demand exists outside the maintainer's framing is unproven — 16 stars, no production users, no independent coverage [External, High within recall caveats]. The honest demand-side read: regulated-ML auditability (EU AI Act model documentation, financial-services model-risk rules) is the only visible buyer for "deterministic gradients with provenance" — and none of that demand has knocked on this repo's door [Inference, Low].

**Why a rewrite, not a binding:** stated implicitly across the docs — only a clean room lets the maintainer re-derive every operator with deterministic contracts and evidence ledgers; a binding to libtorch (à la tch-rs) inherits the C++ autograd's opacity [Inference, Medium — the maintainer never published a "why not a fork/binding" section, unlike the frankenredis README].

**Adjacent context:** one entry in the FrankenSuite program of clean-room Rust reimplementations. The maintainer's profile README cross-links the siblings: franken_whisper (92 stars), frankenmermaid (52), franken_numpy (17), frankenscipy (14), frankenjax (11) [External, High]. The program's thesis is that foundational C/C++/Python infrastructure can be re-derived in Rust with machine-checked parity; FrankenTorch is the ML-framework entry, and the most methodologically ambitious: it is the only one whose crown-jewel claim is about *process guarantees* (deterministic, evidence-complete autograd) rather than safety or speed alone.

## 4.2 What it is — repo TL;DR

A 13-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing PyTorch's CPU eager-mode tensor semantics in Rust: a small-dependency core (`ft-core`: dtypes, shapes, strides, errors — the README's "zero-dependency" claim is contradicted by its manifest: `half 2.7`, `num-complex 0.4.6` [Counted, High]), an operator-schema dispatcher with strict/hardened execution modes (`ft-dispatch`), hand-written CPU kernels with SIMD/GEMM fast paths (`ft-kernel-cpu`, 94,593 lines), a Metal GPU backend (`ft-kernel-metal`), a deterministic autograd tape engine (`ft-autograd`, 33,552 lines), and the higher-level `nn`/`optim`/`data` stacks — plus serialization with RaptorQ sidecars (`ft-serialize`, via `asupersync::raptorq`), a runtime evidence ledger (`ft-runtime`), and a differential conformance harness (`ft-conformance`, 11 forensic binaries). Development velocity is extreme: 6,305 commits since 2026-02-13 (~29/day) [Git-observed, High]. Authorship over the *full* history: 6,104 commits by Dicklesworthstone, 81 by Jeff/Jeffrey Emanuel (same person), and 120 under agent-persona author names (BoldFalcon 66, BlackThrush 20, cc 15, EmeraldPine 10, StormyBirch 6, rustickite 2, Gemini 1) [Git-observed, High] — bus factor 1, with the agent-persona commits reading as the maintainer's own automation fleet. The single largest file is `ft-api/src/lib.rs` (**173,166** lines [Counted, High] — the project's own AGENTS.md still quotes 167,287, a ~6,000-line doc lag [Counted, High]) — the public tensor API surface.

One-line verdict: **the most measurement-honest codebase assessed in this program to date [Inference, Medium — the in-packet evidence base is the 42,708-line negative-evidence ledger, the standing four-rule measurement gate, the public SDPA-layout retraction, and the one-quotable-lane verdict; "most" is a comparative judgment over the packets completed so far], making a drop-in-replacement claim its own ledger will not certify, under a license that forbids the most likely evaluators from touching it.** (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was verified against the pinned commit on 2026-09-22. Tier flavors as in the header legend.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 13 workspace crates, 513,616 first-party Rust lines / 754 files | demonstrated | Fresh clone; `Cargo.toml` members enumerated; line count over `crates/` | [Counted, High] |
| 2 | README says "12 Rust crates" | stale | README "Current State" vs the 13 members in root `Cargo.toml` — `ft-kernel-metal` joined without a README update | [Counted, High] |
| 3 | Unsafe: 11 crates `#![forbid(unsafe_code)]`, 2 `#![deny(unsafe_code)]` (ft-kernel-cpu, ft-kernel-metal); **116** unsafe sites in kernel src (78 blocks + 38 `unsafe impl`/`fn` items), counted with a comment-stripping parser | demonstrated | Crate-root attribute scan. Per file: ft-kernel-cpu/src/lib.rs 64, dynamic_int8_x86.rs 10; ft-kernel-metal compute.rs 14, presentation.rs 20, fused.rs 5, lib.rs 3. Workspace lints set `unsafe_code = "deny"`. Documented allows: whole-crate in ft-kernel-metal ("sanctioned unsafe boundary for Metal FFI"), `mod gemm` and `dynamic_int8_x86.rs` in ft-kernel-cpu | [Counted, High] |
| 4 | "Unsafe code: Forbidden" (AGENTS.md) / "enforces `unsafe_code = forbid` globally" (CHANGELOG) | stale (both) | AGENTS.md Toolchain section vs the deny gates + 116 counted sites + three documented allow scopes; CHANGELOG's "forbid" vs the workspace's actual "deny" | [Counted, High] |
| 5 | Deterministic Autograd Contract: seeded replayable scheduler, deterministic gradient accumulation, provenance-complete evidence | demonstrated (existence; determinism not independently executed) | `EvidenceLedger` (bounded 32,768-entry soft cap, per-op entries) in ft-runtime [Code-verified, High]; deterministic-seed and scheduler-replay property tests in ft-autograd [Code-verified, Medium — tests read, not run] | [Code-verified, High on existence] |
| 6 | Strict vs Hardened execution modes | demonstrated (existence; behavioral difference not executed) | `ExecutionMode::{Strict, Hardened}` in ft-core, threaded through dispatch decisions in ft-dispatch (e.g. fail-closed vs defensive-recovery arms) [Code-verified, High] | [Code-verified, High] |
| 7 | Differential conformance against PyTorch oracle: 33 fixture files, 11 forensic binaries, e2e matrix + forensic triage pipeline | demonstrated (machinery exists; oracle runs not executed here) | `crates/ft-conformance/{fixtures,src/bin}` enumerated; bins: run_differential_report, run_e2e_matrix, triage_forensics_failures, build_failure_forensics_index, check_reliability_budgets, run_raptorq_durability_pipeline, validate_phase2c_artifacts, emit_packet_sidecar, check_benchmark_regression, check_perf_slos, run_perf_slos [Counted, High] | [Counted, High] |
| 8 | PARITY-COVERAGE.md: "Overall CPU eager-mode coverage: 100%" (970+ torch.* functions, 155 nn modules, 14/14 optimizers, linalg/fft/special closed) | partially demonstrated | The API-surface inventory is documented per-category with gap-closure bead references [Maintainer claim, Medium]; semantic parity across dtypes/shapes/edge cases is asserted via the conformance harness, not established by an independent party, and the legacy PyTorch oracle mirror is absent from this checkout | [Maintainer claim, Medium] |
| 9 | Exactly one vs-PyTorch perf lane quotable: `prelu_noshortcut`, median 1.048–1.180, lowest confidence bound 1.006 | demonstrated (the ledger's own verdict) | NEGATIVE_EVIDENCE.md standing gate (adopted 2026-08-15): "One of fourteen lanes became quotable. Everything else remains uncertified." [Counted on the file's existence and the sentence; the numbers are the maintainer's] | [Maintainer claim, High] |
| 10 | SDPA 3-D win retracted as layout artifact (2026-06-21) | demonstrated | RELEASE_READINESS_SCORECARD.md "SDPA layout correction": PyTorch 22.96 ms at 3-D vs 4.53 ms at 4-D, FT 9.78 ms vs 6.20 ms = 1.58x slower; "the earlier 'PyTorch CPU has no f64 flash' premise was wrong" | [Maintainer claim, High] |
| 11 | Allocator-gap diagnosis: 40–73% of alloc-bound lane time is the system allocator; with a caching allocator FT is near-parity-to-winning | demonstrated (as the maintainer's finding) | Scorecard "RADICAL FINDING" 2026-06-21: fair-alloc rows `2W / 1L / 1N`; the default-off `fair-alloc` feature exists in-tree | [Maintainer claim, Medium] |
| 12 | RaptorQ durability: repair-symbol manifests, integrity scrub reports, decode-proof events for long-lived artifacts | demonstrated (machinery; recovery not executed here) | G7 gate in CI workflow; `run_raptorq_durability_pipeline` binary; `generate_raptorq_sidecar` in ft-serialize backed by `asupersync::raptorq::{SystematicEncoder, InactivationDecoder}` — a real erasure-coding implementation, not the `raptorq` crate (absent from Cargo.lock) [Code-verified, High] | [Code-verified, High] |
| 13 | asupersync is a real dependency (0.5.0 locked; Tokio has zero lockfile entries) but its *structured-concurrency runtime* is aspirational: zero `use asupersync::sync/task/runtime` or `Cx` sites in-tree; observed usage is `raptorq::*`, `types::*`, `util::*` only | qualified | Cargo.lock + full-tree `use asupersync::` census vs AGENTS.md "Async Runtime: asupersync (MANDATORY)" | [Counted, High] |
| 14 | NEGATIVE_EVIDENCE.md: 42,708 lines of recorded losses with verdicts | demonstrated | `wc -l` at pin | [Counted, High] |
| 15 | CI: phase2c-reliability-gates run #35731363456 at the pin concluded failure in ~55s | demonstrated (failure established; failing gate unestablished — job logs are admin-restricted) | Actions REST API, 2026-09-22. The 55-second duration is inconsistent with reaching G2 (workspace test build takes many minutes), consistent with a G1 fmt/clippy failure — stated as inference, not fact | [CI-observed, High] on failure; [Inference, Medium] on the gate |
| 16 | Single human maintainer; no releases, no tags on main; 16 stars / 7 forks | demonstrated | GitHub API 2026-09-22: 16 stars, 7 forks, 6 open issues; releases: none; tags: none; CHANGELOG names only the `ft2-snapshot` tag (2026-06-27) | [External, High] |
| 17 | 45% of the last 500 commits carry agent Co-Authored-By trailers (207 Claude Opus 5, 18 Claude, 1 Grok) | demonstrated | `git log -500` trailer count [Git-observed, High]; line-level share not measured | [Git-observed, High] |
| 18 | License rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use incl. benchmarking/testing/analyzing/training-data incorporation; breach = automatic termination |
| 19 | README calls ft-core a "zero-dependency tensor/value substrate" — its manifest declares `half 2.7` and `num-complex 0.4.6` as real dependencies | contradicted | README paragraph vs crates/ft-core/Cargo.toml `[dependencies]` | [Counted, High] |
| 20 | Fuzzing is real and broad: 56 fuzz targets (36 ft-kernel-cpu, 10 ft-api, 6 ft-serialize, 3 ft-core, 1 ft-dispatch) with a 13-entry seed corpus | demonstrated | fuzz/fuzz_targets/ listing + fuzz/corpus/ dirs; per-crate split recounted in the final verification round | [Counted, High] |
| 21 | Test density: ~6,160 `#[test]` attributes across crates (ft-api 2,682; ft-kernel-cpu 783; ft-nn 779; ft-conformance 550; ft-autograd 501) | demonstrated | per-crate attribute census | [Counted, High] |
| 22 | Full-history authorship (6,305 commits): 6,104 Dicklesworthstone + 81 Jeff/Jeffrey Emanuel (same person) + 120 commits under agent-persona author names (BoldFalcon 66, BlackThrush 20, cc 15, EmeraldPine 10, StormyBirch 6, rustickite 2, Gemini 1) — bus factor 1 | demonstrated | git log --format='%an' over all 6,305 commits | [Git-observed, High] |
| 23 | No Metal benchmark exists anywhere in the tree (benches/ live in ft-api, ft-autograd, ft-core, ft-data); the CPU h2h harness is `pytorch_gauntlet_bench.rs` | demonstrated | benches/ inventory | [Counted, High] | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |

**What the inventory says in aggregate:** claims about *process and self-scrutiny* (negative evidence, retractions, differential machinery, unsafe census posture) verify at High confidence; claims about *outcomes* (faster than PyTorch, 100% parity, drop-in replacement) are either self-disavowed by the ledger or rest on the maintainer's own harness. The unsafe story is the sharpest README-vs-code tension: the docs say "forbidden," the code says "deny with 116 annotated sites."

## 4.4 Codebase tour

**Workspace topology (13 members, [Counted, High]):** `ft-core`, `ft-dispatch`, `ft-kernel-cpu`, `ft-kernel-metal`, `ft-autograd`, `ft-device`, `ft-serialize`, `ft-api`, `ft-conformance`, `ft-runtime`, `ft-nn`, `ft-optim`, `ft-data`.

**Dependency posture:** asupersync 0.5.0 is a real, locked dependency — non-optional in `ft-serialize` (RaptorQ erasure coding, deterministic hashing), optional behind the `asupersync-integration` feature in `ft-runtime` [Code-verified, High]. **tokio: zero occurrences in `Cargo.lock`** — the AGENTS.md prohibition is corroborated by the lockfile [Code-verified, High]. But the *structured-concurrency runtime* is aspirational: a full-tree census finds zero `use asupersync::sync|task|runtime` or `Cx` sites — observed usage is `raptorq::*`, `types::*`, `util::*` only [Counted, High]. AGENTS.md says "Async Runtime: asupersync (MANDATORY)"; the tree shows no exercised structured-concurrency runtime — docs-vs-code drift, smaller than the unsafe one. Reproduction note: the maintainer's RCH fleet (8 Contabo VPS workers per AGENTS.md [Maintainer claim, Medium]) means full-suite reproduction costs real fleet money, not a laptop hour. The `raptorq` crate is absent; erasure coding comes from `asupersync::raptorq` [Code-verified, High]. Six crate packages were renamed for crates.io safety (`frankentorch-core`, etc.) while lib names stay `ft_*` [Maintainer claim, Medium — from AGENTS.md].

**Data flow, end to end:**

- **Session facade — `ft-api` (249,046 lines, 574 files [Counted, High]):** the public `FrankenTorchSession` API surface. The single `src/lib.rs` is **173,166** lines [Counted, High] — a reviewability fact on the scale of frankenredis's 58k-line main.rs, cubed. The project's own AGENTS.md quotes 167,287: docs-vs-code drift inside the repo's own census [Counted, High]. This is the op surface: every `torch.*` function re-derived.
- **Autograd — `ft-autograd` (33,552 lines [Counted, High]):** the deterministic tape engine. Gradient accumulation is ordered and seeded; the scheduler carries replay-determinism property tests (`prop_scheduler_replay_is_deterministic`, `composite_graph_gradient_is_deterministic` [Code-verified, Medium — tests read, not run]). AGENTS.md documents real parity bugs this machinery caught: `remainder` using a naive `floor` form instead of torch's fmod-based form, `pdist` using a cancelling matmul identity torch never uses — found when the metamorphic fuzz suite was finally run green (241/0) after sitting red and unnoticed [Maintainer claim, Medium].
- **Dispatch — `ft-dispatch` (9,752 lines [Counted, High]):** operator schema modeling and device/kernel routing, threaded with `ExecutionMode::Strict | Hardened` from `ft-core` — strict maximizes observable compatibility, hardened adds fail-closed guards and bounded defensive recovery [Code-verified, High on the enum and its dispatch arms; behavior not executed].
- **Kernels — `ft-kernel-cpu` (94,593 lines, 117 files [Counted, High]):** concrete CPU implementations. The unsafe concentration lives here: 57 counted sites in `lib.rs` (raw-pointer GEMM hot loops, `TilePtr` Send impls) under a crate-root `#![deny(unsafe_code)]` with a scoped `#![allow(unsafe_code)]` on `mod gemm`, plus `dynamic_int8_x86.rs` (8 sites: AVX-512 VNNI int8 paths, the pin's headline commit) [Counted, High]. The pin commit itself — "perf(int8): enable guarded AVX-512 VNNI path" — wires a native-tested int8 candidate into production dispatch with exact ties-to-even SIMD rounding [Git-observed, High].
- **Metal — `ft-kernel-metal` (3,774 lines [Counted, High]):** the sanctioned unsafe boundary for Metal FFI — whole-crate `#![allow(unsafe_code)]` (33 counted sites), documented as letting `#![deny(unsafe_code)]` consumers offload matmuls without touching unsafe themselves [Code-verified, High]. macOS-only by construction.
- **Serialize — `ft-serialize` (5,463 lines [Counted, High]):** deterministic state-dict and tensor interchange, plus the RaptorQ sidecar machinery (`generate_raptorq_sidecar`, `MAX_RAPTORQ_REPAIR_SYMBOLS`) [Code-verified, High].
- **Runtime — `ft-runtime` (649 lines [Counted, High]):** the DAC evidence structures — `EvidenceLedger` with its 32,768-entry soft cap (keep-first-anchor, retain-recent-half eviction, explicitly documented as a fixed memory leak for long-running inference) [Code-verified, High]. Feature-gated asupersync/frankentui integrations.
- **Higher stacks — `ft-nn` (38,471), `ft-optim` (14,299), `ft-data` (3,377) [Counted, High]:** modules, optimizers (SGD/Adam/AdamW per README; PARITY-COVERAGE claims 14/14 optimizers and 15/15 schedulers [Maintainer claim, Medium]), datasets.
- **Conformance — `ft-conformance` (53,303 lines, 21 files [Counted, High]):** the differential-against-PyTorch-oracle harness: 11 binaries (differential reports, e2e matrix, forensic triage, reliability budgets, RaptorQ pipeline, artifact validation, perf SLOs), 33 fixture files, and the phase2c packet artifacts. The legacy PyTorch oracle mirror (`legacy_pytorch_code/pytorch`) is **absent** from this checkout — the oracle is referenced, not vendored [Verified, High].

**The verification stack, read as one system:** conformance (11 binaries, 33 fixtures), fuzzing (55 targets, 13-entry corpus), tests (~6,160 `#[test]` attributes), property tests, and the UBS scanner form a single pipeline: generate evidence, fuzz the kernels, diff against the oracle, record the losses. It is the most complete *verification apparatus* this program has assessed on any repository — and it is also the reason the project's own performance claims are so thin: the apparatus is pointed at the code, and it keeps returning "not quotable" [Inference, High]. The apparatus is the product; the tensor library is its demo.

**Unsafe arithmetic, stated explicitly:** 11 crates `#![forbid(unsafe_code)]` + 2 `#![deny(unsafe_code)]` = 13, with three documented allow scopes (ft-kernel-metal whole-crate, ft-kernel-cpu `mod gemm`, ft-kernel-cpu `dynamic_int8_x86.rs`). **116** counted unsafe sites in `src/` (78 blocks + 38 items; comment-stripping parse [Counted, High]) — roughly double frankenredis's 61. The posture is "deny at the gate, allow at documented hot paths, annotate with SAFETY invariants" — sampled hot-path blocks (e.g. the LU-decomposition tile kernel) do carry `// SAFETY:` comments [Code-verified, High]. Defensible engineering, but it is **not** what the docs say: AGENTS.md says "Forbidden (`#![forbid(unsafe_code)]`)" and the CHANGELOG says "enforces `unsafe_code = "forbid"` globally" while the workspace lint table says `deny`. Both doc claims are stale [Counted, High].

## 4.5 The maintainer's stated case

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

1. **Absolute Parity Doctrine:** "not a partial rewrite" — a true drop-in replacement with complete feature overlap with upstream PyTorch observable behavior; no permanent scope cuts, no "minimal viable parity" standard; every temporary gap maps to explicit parity-closure beads plus conformance evidence [Maintainer claim, Medium — README]. PARITY-COVERAGE.md operationalizes it: 100% CPU eager-mode coverage — 970+ torch.* functions, 155 nn modules, 14/14 optimizers, 15/15 schedulers, linalg 31, fft 22, special 51 [Maintainer claim, Medium].
2. **Deterministic Autograd Contract:** replayable gradient graph execution with provenance-complete gradient evidence — "a core identity constraint, not a best-effort nice-to-have" [Maintainer claim, Medium — README]. The machinery: seeded deterministic scheduler, ordered gradient accumulation, per-op evidence ledger [Code-verified, High on existence].
3. **Strict/hardened mode split:** strict mode maximizes observable compatibility; hardened mode preserves the API contract while adding safety guards and fail-closed gates [Maintainer claim, Medium — README/AGENTS.md; enum and dispatch arms verified in code].
4. **Profile-proven performance:** the "extreme-software-optimization" discipline — baseline, one lever, conformance re-run, published delta artifacts; the optimization loop is mandatory per AGENTS.md [Maintainer claim, Medium].
5. **RaptorQ-everywhere:** self-healing durability of long-lived artifacts via repair-symbol sidecars, integrity scrubs, and decode-proof events [Maintainer claim, Medium; machinery verified in code and CI G7].

**The honesty apparatus — the part that survives scrutiny:** the maintainer's own standing gate (NEGATIVE_EVIDENCE.md, adopted 2026-08-15) states the quotable-vs-PyTorch position plainly: exactly one of fourteen lanes (`prelu_noshortcut`) is quotable — "Everything else remains uncertified" — and the ledger documents the rules that got there (name the worker, name the harness, quote both estimators, replicate before quoting) [Maintainer claim, High]. The scorecard goes further: it publishes the SDPA layout retraction and the allocator-gap finding that reframes the project's own losses. Any downstream citation of FrankenTorch performance numbers that does not pass through this gate is misrepresenting the source [Maintainer claim, High — the disavowal is in the project's own docs].

**Benchmark reproduction cost:** reproducing the h2h gauntlet requires the ~155 MB checkout at the pin, the pinned `nightly-2026-08-31` toolchain (`rust-toolchain.toml`), a local PyTorch install for the oracle arm (remote RCH workers lack torch — documented repeatedly in the scorecard [Maintainer claim, High]), and same-worker discipline for any quotable row. The `benchmarks/pytorch_baseline.json` baseline exists in-tree [Verified, High]. No independent reproduction is known [External, High within recall caveats].

---

## 4.6 Competitors

The incumbent wins on ecosystem, hardware coverage, and compiled-graph infrastructure; FrankenTorch's only uncontested edge is the Deterministic Autograd Contract plus its measurement-integrity apparatus — which no competitor bothers with because no buyer currently pays for it [Inference, Medium].

- **PyTorch (Meta; BSD-style):** the incumbent and the behavioral oracle. Owns the training lane outright: CUDA/ROCm/XPU coverage, `torch.compile` (TorchInductor/Triton), distributed (DDP/FSDP2), the entire model zoo, and every MLOps integration [External, High]. FrankenTorch is CPU-eager-only at the pin — no GPU beyond a macOS-only Metal backend, no compile story, no distributed — so the "Absolute Parity Doctrine" is scoped to a subset of what PyTorch *is* in 2026 [Inference, High]. `torch.use_deterministic_algorithms` exists but is best-effort per-op with no provenance story — the one contract gap FrankenTorch's DAC genuinely targets [External, Medium].
- **Burn (Rust, MIT/Apache-2.0):** the Rust-native deep learning framework — wgpu/CUDA backends, its own autodiff, no PyTorch API-compatibility goal [External, High]. Owns the "Rust ML framework" mindshare lane; its existence says a Rust tensor stack can attract a community, but it does not compete on PyTorch parity — different lane entirely [Inference, Medium].
- **candle (Hugging Face, MIT/Apache-2.0):** minimal ML framework in Rust, CPU/CUDA/Metal, focused on inference [External, High]. Owns the "run models in Rust" inference lane [Inference, Medium].
- **tch-rs (Rust bindings to libtorch):** PyTorch API in Rust by binding the real libtorch — full operator coverage for free, at the cost of the C++ dependency and zero memory-safety gain [External, High]. The honest "why not tch-rs" answer is the whole project: bindings inherit libtorch's opacity; only a clean room gets the DAC [Inference, Medium].
- **dfdx:** Rust autograd with compile-time shape checking — a type-level differentiator FrankenTorch does not attempt [External, Medium]. Niche-academic lane [Inference, Low].
- **JAX (Google):** the transform-based alternative (jit/grad/vmap) — and the sibling FrankenJAX's target. Relevant because the deterministic/reproducible-computation pitch overlaps JAX's functional-purity story [Inference, Medium].
- **Unoccupied lane:** a memory-safe, *deterministic-by-contract* PyTorch-compatible autograd engine with machine-checked parity evidence and a published measurement-integrity discipline has no direct occupant — and the ledger is the part no competitor can copy cheaply: Burn, candle, and dfdx ship no negative-evidence ledger, no forensic triage pipeline, no allocator-gap diagnosis. The moat is not the kernels (anyone can write GEMM); it is the two years of recorded losses that make the next claim trustworthy [Inference, Medium] — Burn/candle/dfdx don't do PyTorch API parity, tch-rs doesn't do memory safety or determinism contracts, PyTorch doesn't do provenance [Inference, Medium]. Whether any buyer will pay for determinism-plus-auditability over CUDA coverage is the unproven bet the whole project rests on.

## 4.7 Skeptic's take

*Citation convention: weaknesses are numbered 1–10 below; elsewhere in this packet "§4.7.N" means weakness N.*

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

1. **[FATAL] The license rider poisons the well it drinks from.** Barring OpenAI/Anthropic *and their affiliates and anyone acting for them* from use, benchmarking, analysis, indexing, and training-data incorporation doesn't just block two companies — for an ML-framework project, the named Restricted Parties *are* the likeliest evaluators, adopters, and contributors. The "acting directly or indirectly for … or for the benefit of" prong creates legal uncertainty for any contributor employed anywhere near the AI supply chain. A project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, High].
2. **[FATAL] One quotable lane, one human, no release.** The project's own ledger certifies exactly one of fourteen vs-PyTorch lanes as quotable [Maintainer claim, High]. Single maintainer (16 stars, 7 forks [External, High]), no releases, no tags on main, version 0.1.0. The flagship CI pipeline failed at the pin in ~55 seconds [CI-observed, High]. There is no artifact a third party can evaluate *as the pinned product* — only a repository to audit as a *process* [Inference, High].
3. **[HIGH] The "Absolute Parity Doctrine" is scoped to CPU eager mode.** No CUDA/ROCm, no `torch.compile`, no distributed — the Metal backend is macOS-only and the pin's headline commit is an x86_64 AVX-512 path. The doctrine's "no permanent scope cuts" language sits uneasily next to a tree that is, in practice, a CPU-eager subset [Inference, Medium].
4. **[HIGH] The allocator gap is structural, not a tuning detail.** The maintainer's own radical finding: 40–73% of alloc-bound lane time is the system allocator, and the fix (a caching allocator) ships as a default-off `fair-alloc` feature because adopting one is "a binary-level choice, orthogonal to the math-purity rule." Until a caching allocator is the default, every head-to-head number flatters PyTorch's allocator, not FrankenTorch's compute — and the honest default-off posture means the product, as shipped, carries the gap [Maintainer claim, High on the finding; Inference, Medium on the consequence].
5. **[MEDIUM] The docs are a drift source, and the project knows the pattern.** README says 12 crates (13 at pin); README says 12 crates (13 at pin) and calls ft-core "zero-dependency" (its manifest declares `half` + `num-complex`); AGENTS.md says unsafe is "Forbidden" (deny + **116** sites + 3 allow scopes) and quotes ft-api/src/lib.rs at 167,287 lines (173,166 at pin); CHANGELOG says "forbid globally" (workspace says `deny`); the release-readiness scorecard is dated 2026-06-22, three months before the pin. In a project whose pitch is *auditability*, doc drift is a structural liability [Counted, High].
6. **[MEDIUM] The 173,166-line `ft-api/src/lib.rs` is a reviewability cliff.** The entire public op surface in one file that the project's own UBS scanner skips (files over 50,000 lines; the hook says so out loud rather than passing silently — deliberate, but a green commit touching only ft-api means "nothing was examined"). The blind spot was scanned out-of-band once (frankentorch-0o6ai, closed) — a single historical scan, not a practice [Maintainer claim, Medium — from AGENTS.md].
7. **[MEDIUM] 45% agent co-authorship murkies the "clean-room" label.** 226 of the last 500 commits carry agent Co-Authored-By trailers — 225 of them Anthropic models, a named Restricted Party [Git-observed, High]. If models plausibly trained on PyTorch source wrote material parts of the tree, the question that matters is copyright's: output similarity, not tool purity; and the rider's no-training clause cannot bind its own author. The sound version of the concern is epistemic: a clean-room assertion that no independent party may benchmark or analyze is untestable [Inference, Medium].
8. **[MEDIUM] A literal GH_TOKEN in the CI workflow.** `dynamic_int8_exact.yml` sets a `GH_TOKEN` env var as a literal value (no `${{ secrets.* }}` reference — verified by line-shape inspection; the value itself is redacted by this analyst's tooling and unclassified) with `permissions: contents: write`, used to POST git blobs via the API. If that value is a live credential, it is baked into git history at the pin; either way, a secret-shaped literal in a workflow file is a hygiene finding the packet cannot clear from outside [Code-verified, Medium on presence; Inference, Low on exploitability — the value was not read].
9. **[MEDIUM] The oracle mirror is absent and the remote workers lack torch.** The legacy PyTorch oracle mirror is absent from this checkout, and the project's own scorecard documents that remote RCH workers lack a PyTorch install — so the "differential against oracle" arm of CI depends on a local-venv setup the packet never observed executing. The conformance machinery is verified to exist; its oracle arm is verified to be environment-sensitive [Code-verified + Maintainer claim, High].

10. **[LOW] The README's "zero-dependency" ft-core claim is false.** The manifest declares `half 2.7` and `num-complex 0.4.6` [Counted, High]. Trivial in substance (both are no_std-friendly numerics), but it joins the 12-vs-13 crate count and the stale lib.rs line figure as evidence that README claims are written once and never re-verified — the drift pattern that makes the "100% coverage" and "faster than PyTorch" claims unquotable without the ledger [Inference, Medium].

**Bear-case steelman (strongest counter-case):** FrankenTorch is a single-maintainer measurement-integrity performance-art project about *how* to benchmark ML frameworks, not an ML framework. Its own ledger certifies one quotable lane out of fourteen; its headline SDPA win was retracted by its author; the "Absolute Parity Doctrine" covers CPU eager mode while PyTorch's value is CUDA, compile, and distributed; the flagship CI failed at the pin in under a minute; and the license forbids the only entities with the resources to validate or adopt an ML stack from even analyzing the code. The rational market response is to mine it for methodology (the four-rule measurement gate, the forensic evidence pipeline, the allocator-gap diagnosis) and never train on it. Its most likely end state is abandonment at the maintainer's next context switch — leaving 513k lines of rider-encumbered Rust that the best-equipped evaluators may not benchmark, analyze, or train on. [Inference, Medium — deliberately uncharitable; the counter-evidence is the ledger's own existence, which is precisely what makes the project worth mining.]

## 4.8 Maintenance & succession

**Bus factor: 1.** Over all 6,305 commits: 6,104 by Dicklesworthstone, 81 by Jeff/Jeffrey Emanuel (the same person), 120 under agent-persona author names [Git-observed, High]. The last-500 window (483/17) agrees — the fleet is the maintainer's, not a community's. No succession plan, no second committer, no foundation, no release artifact to fork from cleanly [Inference, Medium — absence of evidence across the assessed materials]. If the maintainer stops, the project freezes at whatever commit the stop happens on [Inference, High].

**Agent authorship vs the "clean-room" posture.** The tree is materially agent-written: in the last 500 commits, 226 (45%) carry `Co-Authored-By` trailers — 207 Claude Opus 5, 18 Claude (all `@noreply@anthropic.com`), 1 Grok (`@noreply@x.ai`) [Git-observed, High]. No agent is ever the primary author in this window [Git-observed, High] — but co-authorship on nearly half of recent commits means agents are not marginal contributors. Three consequences: **(1)** the "clean-room" label is legally murky — *if* models plausibly trained on PyTorch source wrote material parts of the tree, the question that matters is copyright's: output similarity, not tool purity; the rider is a licensee-facing contract term that cannot bind its own author, so its no-training clause is legally inert as to the author's own conduct. What is real is the *irony* (the maintainer bars as licensee conduct what he practiced as author) and the *epistemic* point: a clean-room implementation whose author bars benchmarkers is making an assertion no independent party may test [all Inference, Medium — legal analysis, not legal advice]; **(2)** the rider's "analyzing" bar arguably covers this very assessment — Anthropic is a named Restricted Party and its models co-authored the assessed tree [Inference, Medium — legal conclusion, not legal advice]. The argument as stated skips its load-bearing premise: the rider restricts *who* may analyze — Restricted Parties and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" one — not analysis per se, and nothing establishes that the FrankenSuite analyst acts for or on behalf of Anthropic; the assessment is conducted for the program's own research. Read maximally aggressively, the "agent acting for" prong could sweep in any agent-assisted analysis — including this packet's own production, an agent-assisted assessment of agent-co-authored code under an anti-agent-analysis rider; **(3)** quantification limits: trailer counts measure commits touched, not lines written — full-tree line-level attribution (via `git blame` sampling over the complete 6,305-commit history) was not performed and is the open question in §4.13.

**Maintenance load signals:** extreme commit velocity (6,305 commits in ~7 months, ~29/day [Git-observed, High]) cuts both ways — dedication and a workload no successor inherits casually. The bead tracker (1,826 issues [Counted, High]) is the closest thing to institutional knowledge transfer, and it lives in-repo. Its type distribution — 853 task, 433 bug, 270 feature, 254 perf, 15 docs, 1 question [Counted, High] — shows the backlog is mostly *planned work* (47% tasks), not a defect graveyard: the tracker is the project plan, not its bug list [Inference, Medium]. Review depth is unassessed: PRs-vs-direct-to-main and who reviews bead closures were not examined [Not verified].

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

- **Restricted parties:** "OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, consultant, service provider, or representative)." (quoted verbatim from the pinned LICENSE; note this wording omits "contractor" and "agent" from the parenthetical, unlike the frankenredis variant)
- **Grant:** "no rights are granted to any Restricted Party" without "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 from the pinned LICENSE; emphasis added on the evaluation-relevant terms)
- **Remedy:** any breach "automatically and immediately terminates" the permissions; the author reserves injunctive/equitable relief and attorneys' fees.
- **Classification:** non-OSI, source-available. The named-party discrimination fails Open Source Definition §5 (no discrimination against persons or groups — named labs) and the benchmarking/training/analysis bar fails OSD §6 (no discrimination against fields of endeavor) [Inference, High — legal conclusion, not legal advice].

**Succession consequence:** even a willing acquirer inherits a license that shrinks the contributor and evaluator pool; removing the rider requires the sole copyright holder's action, which is the same single point of failure as everything else [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 4** | Lab-validated components (differential harness, 42,708-line negative-evidence ledger, DAC machinery verified in code) with zero production exposure, one quotable perf lane, no release artifact, and the flagship CI red at the pin — component validation in a lab (TRL 4); the red pin and absent oracle mirror block TRL 5's "relevant environment" claim [Inference, Medium] |
| Strategic relevance | 3/5 | A deterministic, memory-safe PyTorch-compatible autograd engine is central to the FrankenSuite infrastructure thesis, but the rider blocks the program's own engagement with the software [Inference, Medium] |
| Impact potential | 2/5 | The deterministic-autograd-plus-auditability lane is genuinely unoccupied, but no buyer signal exists and the "Absolute Parity" scope is CPU-eager-only [Inference, Medium] |
| Implementation feasibility | 2/5 | 513k lines, one maintainer, no release artifact — any adopter inherits the entire tree plus the rider [Inference, Medium] |
| Time to mainstream | 2/5 | Years at best: rider removal, a tagged release, green CI, and independent validation must all happen first, in that order [Inference, Low] |
| Collaboration potential | 1/5 | The rider bars the likeliest collaborators (AI labs and their agents) from even analyzing the code; bus factor 1 [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven; the factsheet above is the scaffolding the ring stands on. The rider does not change the ring — it is recorded as the advancement blocker (§4.8, trigger 3) and priced into feasibility (2) and collaboration (1): **Explore-with-a-ceiling**, currently un-advanceable past Explore while the rider stands.

**Priced move for the ledger:** extracting the EvidenceLedger schema as a standalone design doc costs one focused session with the maintainer's own tooling (the schema is already documented in ft-runtime); it is the cheapest export in this packet [Inference, Medium]. **Methodology fit (for the FrankenSuite):** adopt the patterns, not the package — the four-rule measurement-integrity gate, the forensic evidence pipeline (e2e matrix → triage → reliability budgets), the allocator-normalized benchmarking discipline, and the bead-tracked issue discipline are directly importable into how the program evaluates the other 42 repositories. Do not depend on the software: the rider, the missing releases, and the single quotable lane disqualify it as a dependency, benchmark target, or training-data source. If the program ever needs a Rust tensor stack, Burn dominates on community and backend coverage — and the rider disqualifies FrankenTorch regardless [Inference, High].

---

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — tensor semantics and CPU kernels.** dtypes, broadcasting, reductions, GEMM — mature, standardized knowledge; the parity surface is table stakes, not differentiation. Moves right only if the incumbent moves it: every PyTorch minor release with new operators or changed numerics is a new differential-probe campaign FrankenTorch must fund before the core can claim parity again [Inference, Medium].
- **Custom-built, approaching early Product — the 513k-line PyTorch re-derivation** (`ft-api` op surface, `ft-kernel-cpu`, `ft-nn`/`ft-optim`). Custom-built on process rigor alone; not yet product (no release, no independent validation, CI red at pin). Moves right with a tagged release plus an independent benchmark; decommissions (becomes a monument) if PyTorch ships a first-class determinism-and-provenance story or a funded Rust competitor takes the parity lane [Inference, Medium].
- **Custom-built, closest to Product — the differential-against-oracle conformance harness + forensic pipeline.** 11 binaries, 33 fixture files, e2e matrix → crash triage → reliability budgets → RaptorQ durability gates. The most *executed* component in the tree — used operationally in-repo, but not packaged for external adoption. Moves right if extracted as a standalone conformance framework other projects can adopt; stays repo-local tooling, effectively invisible outside the repo, while the rider blocks the likeliest adopters [Inference, Medium].
- **Genesis — the Deterministic Autograd Contract + the measurement-integrity gate.** No incumbent ships "replayable gradient graphs with provenance-complete evidence" or "name the worker, name the harness, quote both estimators" as first-class machinery. Moves right if the DAC evidence ledger becomes a reviewed, origin-bound provenance mechanism — the direction the agent-era auditability demand points — or stagnates as a single-maintainer log format if the maintainer context-switches [Inference, Medium].

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

1. **No CUDA/ROCm, no torch.compile, no distributed** — the parity doctrine is CPU-eager in practice. Any workload needing GPUs (beyond macOS Metal), compiled graphs, or multi-node training is excluded by the current tree [Inference, High].
2. **The allocator gap is default-on in the product:** the caching allocator is a default-off feature; the shipped default carries the 40–73% alloc-bound penalty the maintainer measured [Maintainer claim, High on the measurement; Inference, Medium on the product consequence].
3. **One quotable lane of fourteen** — the perf pillar is a ledger entry, not a result set [Maintainer claim, High].
4. **CI red at the pin** — the G1..G8 gate topology failed in ~55s; exact gate unestablished [CI-observed, High on failure].
5. **The 167k-line `ft-api/src/lib.rs`** — the UBS scanner skips it; one out-of-band scan exists [Maintainer claim, Medium].
6. **Doc drift as a standing risk** — 12-vs-13 crates, forbid-vs-deny, stale scorecard [Counted, High].
7. **The GH_TOKEN literal** in the int8 workflow with `contents: write` — unclassified value, unresolved hygiene question [Code-verified, Medium].
8. **Legal overhang on "clean room"** — 45% agent co-authorship; see §4.8 [Git-observed, High on the counts; Inference, Medium on the implication].

## 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 parity tail shortens bead by bead; the quotable-lane count grows from one to a handful as the four-rule gate certifies more lanes; no tagged release; the rider stands. The methodology gets mined (measurement gates, forensic pipelines appear in sibling projects); the software gets no production users. Ring: Explore, unchanged.

**24-month base case [Inference, Low]:** one of two shapes. Either the program compounds — a first tagged release, green CI at a pin, the allocator story resolved by default, an independent benchmark — and the packet's checklist (deepening question 8) starts scoring above zero; or velocity decays after the initial program arc completes and the tree enters maintenance drift (doc drift compounding, CI bit-rot). The base case leans toward the second shape on bus-factor-1 priors.

**60-month base case [Inference, Low]:** the software is either a niche artifact with a small determinism-focused following or dormant — the abandonment end state in the §4.7 steelman. The methodology-export (measurement-integrity gates, forensic evidence pipelines, allocator-normalized benchmarking, the DAC ledger schema) is the durable survivor either way.

**Bifurcation — what the upside requires:** all four, in rough order: (a) the rider narrowed or removed (trigger 3) — without this nothing else matters for adoption; (b) a tagged release with a stability policy (trigger 1); (c) green CI at the pin plus a second quotable-lane cohort (triggers 2, 6); (d) a second human committer (trigger 4). The rider is the *necessary* condition: 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 (the observable sensor is trigger 9 below), CI workflows go red or silent, doc drift compounds past the project's own audit cadence, and the tree freezes as a 513k-line monument. Decay is the default outcome for bus-factor-1 infrastructure without institutional capture — the base case, not the tail.

**Revisit triggers (observable, falsifiable):**

1. **A tagged release or GitHub Release appears** — `git for-each-ref refs/tags` / `gh release list` non-empty. Flips the "no artifact to evaluate" judgment.
2. **phase2c-reliability-gates goes green at a pin** — per-job conclusion success via the Actions API. Flips the CI-red finding.
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 observable on the contributor graph. Flips succession risk.
5. **A second quotable-lane cohort** — the ledger's "one of fourteen" sentence amended with newly certified lanes. Flips the perf-pillar judgment.
6. **Independent benchmark or review published** — any third party reproducing or contesting the numbers. Flips "zero independent coverage."
7. **Caching allocator on by default with the gap closed in CI** — the allocator finding graduates from diagnosis to product.
8. **PyTorch ships a first-class determinism-and-provenance story** (replayable gradient graphs with evidence) — the kill-test: if the incumbent absorbs the DAC story, FrankenTorch's differentiation collapses to "Rust, but without CUDA" [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.

## 4.12 Verdict & NODUS ring

**NODUS ring: Explore.** The Rulebook's Explore rule is explicit: *the default for substantive-but-unproven*. FrankenTorch is the textbook case: substantive (513,616 lines, a **116** unsafe sites under deny-gates, a 42,708-line negative-evidence ledger, an 11-binary forensic conformance pipeline — all [Counted, High]) and unproven (no release, no tags, one quotable perf lane, CI red at the pin, zero independent coverage, bus factor 1). The rider is instrumented as an **advancement blocker**: quoted as the adoption ceiling in §4.8, priced into the NODUS feasibility (2) and collaboration (1) scores, and wired to revisit trigger 3. The ring reads: **Explore — substantive, unproven, and currently un-advanceable past Explore while the rider stands** [Inference, Medium].

**The one-paragraph case:** FrankenTorch is a 513k-line bet that ML infrastructure can be re-derived in safe Rust with deterministic, evidence-complete autograd — and on process grounds it is winning that bet further than any peer: the ledger certifies exactly one quotable lane because its own rules forbid the other thirteen, the maintainer publicly retracted his own headline win as a layout artifact, and the allocator-gap diagnosis reframes the entire Rust-vs-PyTorch benchmark conversation. But the product case is hollow at the pin: one quotable lane, CI red in under a minute, one human as the entire bus factor, 45% agent co-authorship murkying the "clean-room" label, and a license that forbids the likeliest evaluators from even analyzing the code. Explore the methodology; the software stays behind the rider's ceiling until trigger 3 fires. [Inference, Medium — a recommendation plus a forecast, both the analyst's judgment.]

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

**What was not done:** the workspace was never compiled; nothing was executed; no test suite was run (so the differential conformance, the DAC replay properties, and the e2e matrix exist but their pass/fail at the pin is unknown); no benchmark was reproduced; the full 6,305-commit history was not line-attributed (authorship analysis covers trailer counts in the last 500 commits only). **CI status at the pin: ESTABLISHED 2026-09-22** — per the Actions REST API, run #35731363456 (phase2c-reliability-gates, head = pin) concluded failure after ~55 seconds; the exact failing gate is unestablished because job logs require admin rights. GitHub Releases/tags re-fetched 2026-09-22: none. Demand-signal search performed 2026-09-22: no independent coverage of FrankenTorch beyond the repository and the maintainer's profile README [External, High within recall caveats]. The GH_TOKEN literal in `dynamic_int8_exact.yml` was verified present (no `secrets.*` reference) but its value is redacted by this analyst's tooling and remains unclassified. Quick-link resolution verified 2026-09-22.

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

1. **Which gate failed at the pin, and is it still red?** The 55-second failure is consistent with G1 (fmt/clippy) but unestablished; a green re-run at a new pin would retire §4.7 weakness 2's sharpest edge.
2. **Does the rider bar this very assessment?** The license's "analyzing" prohibition arguably covers the FrankenSuite's evaluation activity — and Anthropic models co-authored 225 of the last 500 commits. A legal reading either way changes whether the program may continue touching the repo at all.
3. **What fraction of the tree's lines are agent-written?** Trailer counts (45% of recent commits) measure commits touched, not authorship share. A `git blame` sample over full history would settle whether "clean-room" is a defensible label or a murky one.
4. **Is the 100% CPU-eager parity claim semantically true?** API-surface inventory (970+ functions) is documented; behavioral equivalence across dtypes/shapes/edge cases rests on the maintainer's harness. An independent differential campaign is the falsifier.
5. **Is there any production user or demand signal?** One real deployment would move the impact-potential score and the 24-month trajectory more than any code change. (Search 2026-09-22: none found.)
6. **What is the review depth?** PRs-vs-direct-to-main, who reviews bead closures, whether any of the 1,826 beads saw a second pair of eyes — unassessed; determines whether the bead tracker is institutional knowledge or a solo diary [Not verified].
7. **Is the GH_TOKEN literal a live credential?** Unclassified; if live, it is baked into git history and needs rotation.

---

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

**1. Provenance.** The repo's provenance machinery is the DAC evidence ledger: a bounded 32,768-entry `EvidenceLedger` recording one entry per dispatched op (plus backward/policy/durability events) with unix-ms timestamps, explicitly designed with a keep-first-anchor/retain-recent-half eviction to bound the memory leak it would otherwise be for long-running inference [Code-verified, High]. It is an audit artifact for humans and replay tooling, not a tamper-evident attestation — entries are unsigned, unchained, and a hostile operator with process access could rewrite history undetectably [Inference, Medium]. Portable attestation would require hash-chained, signed, write-time-bound entries — the direction the agent-era auditability demand points. A quieter second provenance layer is the benchmark discipline itself: h2h rows are bound to named workers, ELF hashes, and same-host invocations [Maintainer claim, High]. What nothing records is *who* produced an artifact at the code level — the ledger logs op events, not authors — so provenance-of-code (the §4.8 agent-authorship question: 226 of 500 recent commits agent-co-authored) is entirely unaddressed by the machinery [Inference, High].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is `ft-core`: a *small*-dependency tensor/value substrate (dtypes, shapes, strides, error types — the README's "zero-dependency" label is contradicted by its manifest: `half 2.7`, `num-complex 0.4.6` [Counted, High]) plus the `ExecutionMode` strict/hardened contract — a tensor-metadata foundation a proxy, gateway, or forensic tool could vendor without owning autograd [Code-verified, Medium — crate structure and zero-dep claim verified; adoption ergonomics not tested]. Adoption cost: path-dependency vendoring (the README shows no registry-artifact path), inheriting the pinned nightly toolchain and the workspace lint/dependency assumptions [Inference, Medium]. The hand-rolled CPU kernels, by contrast, are *not* cleanly embeddable: the op surface lives in the 173,166-line `ft-api/src/lib.rs`, and the determinism story depends on the autograd scheduler's seeded replay — extracting kernels without the tape loses the contract that justifies the extraction [Inference, Medium].

**3. Unexercised option value.** Three capabilities the architecture holds but has not used. First, the Metal backend (`ft-kernel-metal`, 3,774 lines, the sanctioned unsafe FFI boundary) exists but the perf campaign is CPU-only — a GPU h2h lane against PyTorch/MPS is held, not run [Code-verified, High on existence; Inference, Medium on the lane]. Second, asupersync is a real dependency (0.5.0, locked) used for RaptorQ and deterministic hashing — but the structured-concurrency runtime (`Cx`, regions, cancel-correct channels) the AGENTS.md mandates has *zero exercised use sites* in-tree (feature-gated in ft-runtime but unexercised — full-tree `use asupersync::` census [Counted, High]); a fully async, cancel-safe training loop is architecturally available and unbuilt [Inference, Medium on the unbuilt usage]. Third, RaptorQ sidecars are wired through the G7 durability gate but apply to *artifacts*, not to model state at rest — extending the sidecar contract to checkpoints and state-dicts would convert "survives bit-rot" from a repo-hygiene feature into a load-bearing ML-durability differentiator [Inference, Medium]. What unlocks each: a Metal h2h campaign, an async training-loop consumer, and a checkpoint-sidecar default — all priced, none scheduled [Inference, Low].

**4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the maintainer's own, and even those are mostly uncertified: the standing gate (adopted 2026-08-15) certifies exactly one of fourteen vs-PyTorch lanes (`prelu_noshortcut`, six invocations, median point estimates 1.048–1.180, lowest confidence bound across quotable runs 1.006) — "Everything else remains uncertified" [Maintainer claim, High]. Which numbers are load-bearing for the thesis? The honest answer is that the thesis does not rest on beating PyTorch — it rests on the DAC and the parity evidence, and the ledger's one-quotable-lane verdict is the thesis working as designed: a project that forbids itself from quoting thirteen lanes is not hiding weakness, it is demonstrating the gate [Inference, Medium]. The dishonesty audit extends to non-numeric claims: the "100% CPU eager-mode coverage" is an API-surface inventory, not a semantic-parity proof — and the scorecard's own SDPA layout correction shows what happens when a number escapes the gate (it gets retracted). No independent reproduction is known [External, High within recall caveats]; reproduction costs the 155 MB checkout, the pinned nightly toolchain, a local PyTorch oracle install, and same-worker discipline.

**5. The governance path.** The credible route from one maintainer to an institution runs through four gates in rough order: rider removal, a tagged release, green CI at a pin plus a second quotable-lane cohort, a second human committer (trajectory triggers 3, 1, 2+5, 4). The starting position: no succession plan, no second committer, no foundation, no release artifact [Inference, Medium on the absences — the no-release half is External, High]. The closest thing to institutional knowledge transfer is the in-repo bead tracker (1,826 issues [Counted, High]) plus the evidence ledgers — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit; review depth (PRs-vs-direct-to-main, who reviews bead closures) is unassessed [Not verified] and is parked as §4.13 open question 6. What breaks first if velocity decays: the doc-audit cadence — the repo's own materials already show crate-count, safety-posture, and scorecard-staleness drift within weeks-to-months of the pin — then CI bit-rot; the 60-day abandonment tripwire (trigger 9) is the observable sensor [Inference, Medium]. Beyond the four gates, the realistic institutional endpoints are a foundation home or a corporate adopter — both currently gated on rider removal, which is why trigger 3 is the advancement blocker rather than a nicety [Inference, Low].

**6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates (>50% voting control, contract-or-ownership "control" definition); and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — barring "use" defined expansively (copying … benchmarking, testing, **analyzing, indexing** … incorporating into datasets, training corpora, evaluation harnesses, or pipelines for machine learning or other automated systems), with automatic termination on breach [Code-verified (license text), High]. Does the exclusion serve or sabotage the stated mission? For an ML framework it sabotages adoption structurally: the named Restricted Parties are not incidental evaluators but the core market — AI labs training models are the likeliest users of a PyTorch-compatible stack, and they may not benchmark, test, analyze, or even execute the code; the "acting for" prong creates legal uncertainty for any contributor near the AI supply chain; it is already priced as the Explore ceiling (feasibility 2, collaboration 1, trigger 3) [Inference, High]. What it arguably *serves* is a defensive intent — denying 513k lines of curated ML-systems code to rival training corpora — but that intent is unlabeled by the author and the cost is asymmetric: the project selects for adopters who cannot evaluate it, and a project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, Medium]. The remaining strategy point: 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 reproducible-training workload: an agent team fine-tuning models where gradient provenance must be auditable — the DAC's replayable, seeded, evidence-logged backward pass is the audit trail an agent-safety review would want, and the strict/hardened mode split gives a fail-closed posture for agent-generated edge-case inputs [Inference, Medium]. What would have to become true first: a tagged release (there is no artifact to pin a training run to), the rider narrowed or removed (AI labs and their agents are currently barred from even *analyzing* the code — the target user is excluded by name), and the allocator story resolved (the default-off caching allocator means the shipped product carries the measured 40–73% penalty) [Inference, Medium]. The fit is real but presently blocked by the license aimed at its own likeliest users: the rider names the agent operators as Restricted Parties while the project's best adoption story is an agent workload — and the recursion is noted in §4.8 (this packet is itself an agent-assisted assessment of agent-co-authored code under an anti-agent-analysis rider) [Inference, Medium].

**8. The kill test.** The single experiment that would falsify the core thesis — that a clean-room Rust PyTorch with a Deterministic Autograd Contract and machine-checked parity is a differentiable, adoptable artifact — is the one the project built for itself: the four-rule measurement gate applied to a second quotable-lane cohort. If the gate keeps certifying only `prelu_noshortcut` while the other thirteen lanes stay uncertified indefinitely, the performance pillar is falsified by the project's own mechanism, not by a critic [Inference, Medium]. Two secondary falsifiers sit behind it: a competitor move (PyTorch shipping a first-class determinism-and-provenance story — replayable gradient graphs with evidence — collapsing the differentiation to "Rust, but without CUDA", trajectory trigger 8) and the abandonment tripwire (trigger 9: 60 days without commits or disabled CI re-rings to Monitor). The production checklist is the inverse of this test — what success requires, scored at the pin as 0 of 8 fully met: tagged release or GitHub Release; green CI at a pin; a second quotable-lane cohort; the allocator gap closed by default; closed parity-tail gates with the oracle mirror vendored; a signable license; bus factor > 1; an independent benchmark. All eight are unambiguously unmet at the pin [Inference, Medium].