# franken_nlp — RULEBOOK v1.0 Assessment Packet v5

**Repository:** `Dicklesworthstone/franken_nlp` · **Language:** Rust (Edition 2024) [Code-verified, High] · **Pinned commit:** `30373ca0c7911784dd04865636eaf82f2f2dfab8` (2026-09-22 02:55:22 -0400 = 2026-09-22 06:55:22Z, [Git-observed, High]) · **Last push:** 2026-09-22T12:40:14Z [External (GitHub API), High] · **Scope:** the pinned commit (shallow clone, history deepened to 827 commits for authorship/velocity only; working tree at the pin) · **Stars/forks:** 6 / 2 [External, High] · **Created:** 2026-07-31 [External, High] · **Tags/releases:** none [External, High] · **License:** MIT + OpenAI/Anthropic Rider (non-OSI) [Code-verified (LICENSE read verbatim), High] · **Stage:** design review — the GitHub repo description says so verbatim [External, High].

**Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/franken_nlp-verify` (5,509 files); history deepened to 827 commits for velocity/authorship only. Read: `Cargo.toml`, `rust-toolchain.toml`, `LICENSE` (verbatim), README.md (full), WIRING.md (full), `COMPREHENSIVE_PLAN_FOR_FRANKEN_NLP.md` (TOC + §§1–3, sampled §§4–10), `CHANGELOG.md` (head), `SUITE.lock`, `docs/CLAIMS.json`, `docs/CLAIMS_ANNOTATIONS.md`, `docs/NEGATIVE_EVIDENCE.md`, `docs/DISCREPANCIES.md`, `docs/PERF_LEDGER.md` (schemas), `.beads/issues.jsonl` (counts), `scripts/check.sh` entrypoint surface, `scripts/check_claims.py`, `scripts/gen_tensor_census.py`, `tests/` inventory, `.github/workflows/ci.yml`. Counted: `.rs` files/lines, unsafe sites, test files with provisional markers, agent trailers. **Executed independently:** `gen_tensor_census.py --check-artifact` and `--self-test` (PASS), plus a live real-index replay against the pinned HuggingFace revision (PASS, see claim 4); `check_claims.py --check` (runs, reports FAIL on the pin's own tree — see §4.7). Verified resolving: all Quick Links. **Not done:** the crate was never compiled, no test suite was run, no model weights were downloaded (only the 16.5 KB index + 1 KB config), no inference was executed, no DSR checkpoint exists to observe, no contributor interviews.

**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/plan, not independently executed; **[External]** independent sources; **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

---

## Hook

A 116,321-line [Counted, High — whole tree including tests; 94,283 lines in `src/` alone], single-maintainer, pure-Rust NLP engine for exactly one 3B model — whose own README contains zero *measured* performance numbers on purpose ("no FrankenNLP performance number exists yet, because no kernel exists yet" [Maintainer claim, High]), whose claims linter runs and then fails on the project's own tree [Verified, High], and whose 324 KB design plan grades every one of its own sentences with an evidence vocabulary ([OBSERVED@pin], [REPORTED], [TARGETED]) [Code-verified, High]. This is the FrankenSuite's most honest unfinished project: an evidence system awaiting its engine — a design-stage repository that built the machinery for catching its own lies before it built the engine itself, and then let me verify the machinery actually works, including the parts where it currently fails.

## TL;DR

- **What it is:** A design-review-stage, pure-Rust, CPU-first local NLP toolbox (`fnlp` CLI + library) built around exactly one model — Nanbeige4.2-3B, a 22-layer × 2-pass looped transformer (44 effective layer executions, Apache-2.0 weights) — with a custom quantized artifact format (`.fnlpq`), a grammar-constrained task layer (schema-valid JSON by construction, source-grounded fields), and a crash-resumable corpus batch fabric [Maintainer claim, Medium — this is the disclosed 1.0 target contract; the README says so explicitly]. At the pin the tree holds 343 `.rs` files / 116,321 lines whole-tree (260 files / 94,283 lines in `src/`, the rest tests and harnesses) [Counted, High].
- **TRL: 2–3; NODUS ring: Monitor** [Inference, Medium — see §4.9]. The concept and analytical design are complete (TRL 2 satisfied in full); experimental evidence exists only for isolated arithmetic and dependency-census probes, never for any model-execution path (TRL 3 partial at best). Plan-stage work rings Monitor per the Rulebook, no exceptions for eloquent plans.
- **Strongest strength:** the evidence-governance machinery is real, executable, and self-biting: an inline evidence-state vocabulary across the 324 KB plan, machine-checkable `fnlp-claim` annotations, `CLAIMS.json` with every claim labeled `targeted`, ledger schemas with a pre-registered rejection, a claims linter that currently reports FAIL on the pin's own tree, and a tensor census I independently re-verified byte-for-byte against the live HuggingFace revision [all Verified/Code-verified, High].
- **Strongest ceiling:** nothing executes end to end. No kernel has run, no model weights are present, the `production` feature graph does not exist, the DSR build authority is BLOCKED, GitHub Actions is disabled, there are no tags or releases, and the bus factor is 1 *by stated policy* ("I do not accept outside contributions"). The project can currently prove its honesty to anyone; it cannot prove a build to anyone [Code-verified + Maintainer claim, High].

## Quick Links

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

1. [Repository](https://github.com/Dicklesworthstone/franken_nlp)
2. [README](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/README.md) — includes the "note on tense" and the disclosed current-executable-surface block
3. [Design plan (324 KB)](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/COMPREHENSIVE_PLAN_FOR_FRANKEN_NLP.md)
4. [License (MIT + OpenAI/Anthropic Rider)](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/LICENSE)
5. [WIRING.md — DSR authority BLOCKED](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/WIRING.md)
6. [CLAIMS.json — all claims `targeted`](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/docs/CLAIMS.json)
7. [Changelog](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/CHANGELOG.md)
8. [CI workflow (historical; inert — `on: {}`)](https://github.com/Dicklesworthstone/franken_nlp/blob/30373ca0c7911784dd04865636eaf82f2f2dfab8/.github/workflows/ci.yml)
9. [Nanbeige4.2-3B model card](https://huggingface.co/Nanbeige/Nanbeige4.2-3B) — the one model; card YAML declares `apache-2.0`
10. [Upstream llama.cpp Nanbeige4.2 support PR](https://github.com/ggml-org/llama.cpp/pull/25994) — the honest baseline; merged 2026-07-27, and its merge commit (`b77d646…`) is the plan's §10 baseline pin [External, High — verified via GitHub API]

## Did You Know

The README's Performance section contains zero *measured* performance numbers — by written policy. It states verbatim: *"Every number below is a provisional gate, **TARGETED rather than OBSERVED: no FrankenNLP performance number exists yet, because no kernel exists yet.**"* The section's only quantitative content is nine gate names (PG-0 through PG-8) and one explicitly hypothetical roofline table — 74/111/55/90 tok/s ceilings across host classes — labeled "context, not promises" [Maintainer claim, High — quoted from the pinned README]. A benchmark section that refuses to contain benchmarks, and says the refusal out loud, is the project's honesty thesis in one paragraph — and the packet's audit found no measured number anywhere in the repo that contradicts it.

## Franken-worthy next steps

1. **Extract the evidence grammar as the Suite's design-stage standard.** The `fnlp-claim` annotation scheme + `CLAIMS.json` + ledger schemas (`perf-ledger/v1`, `negative-evidence/v1`, `discrepancies/v1`) + `check_claims.py` is the most complete pre-execution honesty machinery assessed in this program — and it is the genuinely portable artifact here, not the engine. *Falsifiable:* lift the four files into one sibling design-stage repo and require `check_claims.py --check` green before its next design doc lands; if the sibling's authors won't adopt it, the grammar's portability claim dies. [Inference, Medium]
2. **Run the loop-1 draft experiment the plan left as a research card.** §2.4 admits loop-1 hidden states *could* draft tokens for speculative decoding but warns "merely accepting a loop-1 token on a confidence threshold is approximate decoding, not speculation" and gates it on an exact rejection sampler. *Falsifiable:* once `hf-bf16-eager` runs, project loop-1 states through `lm_head` on a fixed fixture set and measure exact acceptance rate against full two-loop verification; publish the acceptance curve — if it sits below the break-even for the ×2 loop cost, the card dies in the negative-evidence ledger as designed. [Inference, Medium]
3. **Make the claims linter a blocking gate instead of a reporter.** `check_claims.py --check` currently reports FAIL on the pin's own tree (an unannotated wording in `src/cli.rs`) with exit 0 — it observes, it does not gate. *Falsifiable:* wire it into `scripts/check.sh` with a nonzero exit on FAIL and fix the tree to green; if the tree cannot be brought green without weakening the annotation rules, the enforcement claim is aspirational. [Inference, High — the tool and the failure both verified]
4. **Publish the tensor-census replay as a standalone reproducibility recipe.** The census replays byte-identically against the live HuggingFace pinned revision (verified in this assessment: index/config hashes match, `--check` PASS, missing=0/mismatched=0/extra=0) — a third party can re-derive the entire 201-tensor, 4,169,800,704-parameter census from public data in seconds. *Falsifiable:* ship `gen_tensor_census.py --check` as a documented one-command replication; any future model-revision drift that breaks the replay invalidates the footprint claims mechanically, no argument required. [Inference, High — the replay was executed here]
5. **Stress-test the 44-deep KV admission budget before any kernel exists.** The 176 KiB/token KV (44 loop-layers × 4 KiB) is the model's unusual cost center, and "byte-certified admission" is the design's novel answer. *Falsifiable:* prototype the admission ledger against synthetic 44-deep KV shapes and require it to refuse an over-budget admission with exact byte accounting *before* the real engine needs it; if the ledger cannot be specified independently of the engine, it is not a mechanism, it is a wish. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** the workhorse NLP jobs — structured extraction from messy text, entity canonicalization, sentiment along domain dimensions, corpus-scale classification, PII redaction *before* text leaves the machine, RAG faithfulness judging — currently force a bad trade. Cloud LLM APIs charge per token, exfiltrate the submitted text to a provider, and rate-limit the corpus. SpaCy-class pipelines are fast and local but lack LLM-grade semantic reasoning. Running a local LLM through a general stack (Python + transformers, or a generic GGUF runtime) leaves model-specific CPU optimization and a complete NLP product layer on the table, then hands back free text that still needs parsing and validation [Maintainer claim, Medium — the framing; the trade is real, the sizing is not evidenced].

**Who feels the pain:** operators with sensitive corpora who cannot send text to a provider, and anyone running extraction/classification/redaction at corpus scale where per-token API pricing dominates [Inference, Medium].

**Why now:** Nanbeige4.2-3B's card reports unusually strong sub-4B results (63.6 SWE-Bench Verified, 87.4 GPQA-Diamond [External, High on card presence; the plan itself labels the numbers [REPORTED] and found a card self-conflict — HMMT-Feb-2026 reported as 82.8 in the table vs 82.1 in the attached eval display — and refuses to pick the better one), its weights are Apache-2.0 per the card YAML [External, High — `cardData.license: apache-2.0` confirmed via the HF API], and official upstream llama.cpp now supports its looped architecture (PR #25994, merged 2026-07-27 [External, High — verified via GitHub API, `merged_at` 2026-07-27T15:04:19Z]; v0.4.0 release notes credit #27730 [External, High on the note itself]). Notably, the PR's merge commit is `b77d646…` — the exact revision the plan's §10 G2 names as its comparison baseline pin, so the "tested official llama.cpp revision" the project promises to measure against is a real, verifiable commit, not a placeholder [Code-verified + External, High]. The timing matters: upstream support landed roughly eight weeks before this assessment and the card was last modified 2026-09-11 — the baseline is brand-new, the model is current, and as the README puts it, that gives the project "a real, maintained baseline to beat, and no excuse to pretend the baseline does not exist" [Maintainer claim, High]. The window is genuinely open; it is also genuinely narrow, because that same baseline improves monthly.

**Why a rewrite, not a wrapper:** the stated bet is specialization — one fixed model means every weight-side dimension is a compile-time constant (hidden 3072, 22 layers × 2 loops, vocab 166,144), the loop is scheduled explicitly rather than replayed through a generic graph, and the output contract (grammar-constrained, source-grounded) is enforced during decoding rather than validated after it. A general runtime cannot do any of these without paying a generality tax [Maintainer claim, Medium — coherent, untested].

**Demand-side check:** there are no users, no releases, no independent coverage of franken_nlp beyond the repository itself [External, High within recall caveats]. The sibling `franken_ocr` (328 stars [External, High]) is cited by the plan as having "proved this shape ships" — a Pure-Rust CPU-only OCR engine for a 3B VLM with custom int8 kernels [External, High on the description] — which is the closest thing to demand evidence: the same maintainer shipped the same shape before [Inference, Medium].

## 4.2 What it is — repo TL;DR

A single-crate Rust package (Edition 2024) with two binaries (`fnlp`, `franken_nlp`) over one library: 343 `.rs` files / 116,321 lines whole-tree at the pin (260 files / 94,283 lines in `src/`, the rest tests and harnesses) [Counted, High]. Around the code sits the actual substance of the repository at this stage: a 324 KB design plan with an inline evidence-state vocabulary, a 57 KB `AGENTS.md` operations manual, a Beads issue graph (196 issues, 49 open / 147 closed [Counted, High]), ledger-schema docs, and a claims linter. **"The proven template" — lineage as architecture.** Plan §4.1 is titled "Repository shape — single crate, two binaries (the proven template)": the repo shape is deliberately inherited from franken_whisper/franken_ocr ("the franken_whisper/franken_ocr single-model shape, corrected so a fresh public clone is not coupled to the maintainer's filesystem") [Maintainer claim, High — plan text]. The plan goes further: "the measured lessons from the frankensearch/franken_ocr kernel campaigns are inherited as doctrine, not re-litigated" — including the dispatch rule "measured-faster wins, hardware capability is not a routing decision," because franken_ocr's shipped kernels found LLVM autovec *faster* than forced SDOT/SMMLA on some M-series shapes [Maintainer claim, Medium — the claim is doctrine-by-inheritance, not measured here]. This is a one-model appliance shop running a playbook, not exploring a design space.

**The 57 KB operations manual.** `AGENTS.md` (56,858 bytes) is not a contributor guide in the usual sense — it is a swarm operating system: MCP Agent Mail coordination, bead-assignee locking so two agents never work the same issue (`br update <id> --assignee <agent>`), a claim-annotation grammar, and the DSR receipt workflow; WIRING.md adds the pane-discipline rules for parallel agents. Read as product, it is the maintainer's answer to bus factor 1: since no human team exists, the coordination machinery is written down so thoroughly that a swarm of agents — or a successor — can run the project from the docs. Whether agent swarms actually obey 57 KB of process docs is an open empirical question; but as an artifact it is the most complete solo-maintainer knowledge-transfer system in this program's packets [Inference, Medium].

The honest characterization, per the README's own "note on tense": the repository is the *specification and scaffolding* of a 1.0 target system, trued up in place as phase gates land. The executable surface today is `robot schema|health|backends`, `schema check|sample`, a provisional `convert` path, release-package scaffolding, and a `models derive` path that deliberately refuses; there is no `pull`, no inference, no task commands [Maintainer claim, High]. Git history: 827 commits, of which 583 landed on a single day (2026-07-31) [Git-observed, High] — a campaign burst, not sustained velocity — then sparse commits through the September code-first campaign.

One-line verdict: **the most rigorously self-annotated design-stage repository assessed in this program [Inference, Medium — comparative judgment over packets completed so far], whose engine has never executed and whose honesty machinery has.** (NODUS: Monitor — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim re-verified against the pinned commit on 2026-09-22 unless noted. Statuses: *demonstrated* / *partially demonstrated* / *aspirational* / *disproven* / *stale*.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | Single Rust crate (Edition 2024), two binaries (`fnlp` + `franken_nlp`); 343 `.rs` files / 116,321 lines whole-tree (260 / 94,283 in `src/`) | demonstrated | Fresh clone; `Cargo.toml` bins enumerated; line counts over tree and over `src/` | [Counted, High] |
| 2 | Zero `unsafe` blocks in `src/`; `unsafe_code` denied at crate roots (`lib.rs`, `main.rs`, `bin/fnlp.rs`) and via `[lints.rust]` | demonstrated | `grep -rn 'unsafe {'` → 0 hits; lint table read | [Counted, High] |
| 3 | "Unsafe: audited islands only" badge / design-philosophy permission for enumerated SIMD/mmap islands | aspirational (permission unused: there are no islands to audit at the pin) | Badge links to rust-secure-code/safety-dance; philosophy says enumerated modules *may* allow `unsafe_code` — none do | [Code-verified, High] on the gap |
| 4 | 201-tensor census: 4,169,800,704 params, byte-exact artifact `docs/truth-pack/tensor_census.json` | demonstrated | **Independently executed:** `gen_tensor_census.py --check-artifact` PASS; live replay against the pinned HF revision (`f56ec5a9…`) — downloaded `config.json` (1,019 B) and `model.safetensors.index.json` (16,519 B), both SHA-256 hashes matching the script's hardcoded pins, `--check` PASS with missing=0/mismatched=0/extra=0 | [Verified, High] |
| 5 | Nanbeige4.2-3B looped architecture: 22 physical layers × 2 passes, 44 KV slots, final RMSNorm after each pass; LoopSplit/mHC/depth-attention inactive at this checkpoint | demonstrated (as documented config fact; runtime behavior unexecuted) | Plan §2.3–2.4 with `[OBSERVED@pin]` labels; HF `modeling_nanbeige.py` documents the loop family; external analysis of the llama.cpp port confirms the executable graph is a plain looped llama stack (shared weights, `num_loops`-expanded layers) | [Maintainer claim + External, Medium] |
| 6 | Model card reports 63.6 SWE-Bench Verified / 87.4 GPQA-Diamond | demonstrated (presence on card); provenance is the card's own | Card table read live 2026-09-22; the plan labels these [REPORTED] and records a card self-conflict (HMMT 82.8 vs 82.1) without resolving it | [External, High] on presence; [Inference, Medium] that the numbers are trustworthy |
| 7 | Weights are Apache-2.0 | demonstrated | HF API `cardData.license = "apache-2.0"` at the pinned revision; no LICENSE file in the HF tree and top-level API `license: None` — the declaration lives in the card YAML frontmatter, which is what the plan cites | [External, High] |
| 8 | Official upstream llama.cpp supports Nanbeige4.2 (the honest baseline); the plan's §10 baseline pin `b77d646…` is that PR's merge commit | demonstrated | GitHub API: PR #25994 "[Model] Add support for Nanbeige4.2", state closed, `merged_at` 2026-07-27T15:04:19Z, `merge_commit_sha` `b77d646751d01c0962bc203b6809e9d94f7d50b7`; llama.cpp v0.4.0 release notes separately credit #27730 for nanbeige4.2-3B support | [External, High] |
| 9 | No measured performance numbers exist; every gate TARGETED; "no kernel exists yet" | demonstrated | README Performance section quoted verbatim; no contradicting measured number found in the assessed materials | [Maintainer claim, High] |
| 10 | Closed dependency universe: clap, serde/serde_json, sha2 + pinned FrankenSuite foundations | partially demonstrated | `Cargo.toml`: exactly those roots plus optional git deps (asupersync, frankentorch ×3, fsqlite ×2) — all pinned by rev, all recorded in `SUITE.lock` with plan-audited vs selected revs; `rust-toolchain.toml` pins nightly-2026-08-31 | [Code-verified, High] |
| 11 | asupersync is the execution foundation (scoped_cpu teams, spawn-sealed, no Rayon in release graph) | partially demonstrated | `cfg(feature = "asupersync-runtime")` gating in 7 src files; `SUITE.lock` records selected rev `362dc5b…` vs plan-audited `8eb4857…` with a reason string; G0 census probes target its API; but the default feature graph excludes it, the release graph doesn't exist yet, and "Rayon edge is dev-only" is a changelog assertion, not a verified build fact | [Code-verified, High] on wiring; [Maintainer claim, Medium] on the Rayon audit |
| 12 | frankentorch kernels consumed at the kernel level; fsqlite for metadata/job state | aspirational (frankentorch) / partially demonstrated (fsqlite) | frankentorch: declared as 3 optional deps, **zero** `src/` references — only `tests/dependency_policy.rs` mentions it. fsqlite: 6 `src/` files reference it behind `cfg(feature = "metadata-store")` | [Code-verified, High] |
| 13 | Grammar-constrained task layer: schema-valid-by-construction JSON, `verbatim` source-grounded fields, exact byte+scalar offsets | aspirational | `src/grammar/` exists (5,989 lines [Counted, Medium]); `fnlp schema check\|sample` is exposed per the README's current-surface block; but no decode path executes and no model is present — the construction guarantee is a design property, not an observed one | [Code-verified, Medium] on existence; [Maintainer claim, Low] on the guarantee |
| 14 | Current executable surface excludes inference: no `pull`, no task commands, `models derive` deliberately refuses | demonstrated | README "Current executable surface" block + FAQ "Is this production-ready today? No" | [Maintainer claim, High] |
| 15 | Evidence machinery: `fnlp-claim` annotations, CLAIMS.json (6 claims, all `targeted`, zero evidence digests), ledger schemas, NEGATIVE_EVIDENCE seeded with one pre-registered reserved entry | demonstrated (existence + my execution) | `check_claims.py --check` **executed 2026-09-22: runs, reports FAIL** on the pin's own tree (`src/cli.rs:26` — unannotated numeric/superlative wording) with exit 0; PERF_LEDGER/NEGATIVE_EVIDENCE/DISCREPANCIES are schema + (near-)empty (the NE seed `NE-AVX2-RAW-VPMADDUBSW-001` is a reserved "rejected by construction" entry, not a recorded loss) | [Verified, High] |
| 16 | DSR build authority BLOCKED; GitHub Actions disabled; CI workflow inert (`on: {}`) | demonstrated | WIRING.md verdict block quoted; workflow file read; repo Actions API returned `enabled=false` in the project's own 2026-07-31 audit (retained in WIRING.md); `/actions` page 404s | [Maintainer claim, High] |
| 17 | No outside contributions accepted (bus factor 1 by policy) | demonstrated | README "About Contributions" quoted verbatim: "I do not accept outside contributions for any of my projects" | [Maintainer claim, High] |
| 18 | License rider bars OpenAI/Anthropic et al. from use incl. benchmarking/analyzing/training; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |
| 19 | Numerics profiles: `hf-bf16-eager` owns HF-match claims; `diagnostic-f32` is structural-only (token flips are named fixtures); quantized profiles carry preregistered budgets, never inherited exactness | partially demonstrated | Plan §1.1.1 read in full; `src/native_engine/hf_bf16_eager/` + `diagnostic_f32.rs` + `strict_int8.rs`/`portable_int8.rs` exist with the documented semantics — but no profile has executed, so the cast-point contracts are specified, not observed | [Code-verified, High] on existence; [Maintainer claim, Medium] on the semantics |

**What the inventory says in aggregate:** claims about *process and documentation* (census, evidence machinery, license text, stage honesty, numerics-profile design) verify at High confidence — claim 4 is the strongest independent verification this assessment produced. Claims about *the engine* (tokenizer exactness, constrained decoding, kernels, batch fabric) are uniformly aspirational: 116,321 lines of code that no one has compiled or run as a system, by the maintainer's own account. There is no stale or disproven claim of note — which is itself a finding: at design stage, with every public sentence labeled `targeted`, there is almost nothing positioned to be disproven yet.

## 4.4 Codebase tour

**Package topology (single crate, [Code-verified, High]):** one `[package] franken_nlp 0.1.0`, `autobins = false`, two `[[bin]]` targets (`fnlp` ← `src/bin/fnlp.rs`, `franken_nlp` ← `src/main.rs`) over one library. Feature flags: `asupersync-runtime` (optional git dep), `asupersync-census` (test-internals census), `frankentorch-leaves` (ft-core, ft-kernel-cpu, ft-serialize), `metadata-store` (fsqlite, fsqlite-types). Default features: empty — the README states the default-empty graph "is not a production substitute" and the named `production` graph "has not landed" [Maintainer claim, High].

**Module topology by line count ([Counted, Medium] — `cat` over `src/` subtrees):** `native_engine/` 17,904 · `artifact/` (converter, `.fnlpq` format, release packaging) 14,067 · `grammar/` 5,989 · `batch/` 5,790 · `corpus/` 4,281 · `hosted/` 3,405 · `jobs/` 2,515 · plus `cli.rs`, `orchestrator.rs`, `text_cli`, `job_cli`, `local_io`, `diagnostic_f32`, `quant` surfaces. `native_engine/` holds the loop-scheduled core: `looprun.rs` (the 22×2 schedule), `hf_bf16_eager/` (the fidelity-oracle profile), `diagnostic_f32.rs` (structural oracle), `strict_int8.rs` / `portable_int8.rs` / `constrained_int8.rs` (quantized profiles), `quant_algebra.rs` (the i32-accumulator bound proofs from plan §2.6), `dispatch.rs` (ISA dispatch referencing `std::arch`), `batchsched/`, `decode/` (samplers), `lmhead/`, `kv.rs`, `rope.rs`, `nn.rs`, `tensor.rs`, `weights.rs`.

**Dependency posture:** exactly three commodity families — `clap 4.5` (derive), `serde`/`serde_json 1`, `sha2 0.10` — plus optional pinned git foundations: asupersync (`362dc5b…`, `tls-webpki-roots` feature — the one network path, `fnlp pull`), frankentorch ×3 (`523aaf8…`, declared but unreferenced in `src/`), frankensqlite ×2 (`5676cb9…`, referenced in 6 files behind `metadata-store`). No tokio, no rayon in the manifest at all [Code-verified, High]. The `SUITE.lock` (format 2) records plan-audited vs selected revs with reason strings — a machine-checked foundation-pin ledger no sibling packet has shown.

**`native_engine/` vs `hosted/` — the two execution surfaces.** `native_engine/` (17,904 lines) is the model core: the loop schedule, the fidelity profiles, the quantized kernels, dispatch. `src/hosted/` (+ `src/hosted.rs`, 3,405 lines) is the *process-owned execution surface* on asupersync: its module docstring reads "Explicit current-candidate INT8 execution on the process-owned runtime… Immutable weights are shared by Arc; native calls use the one configured blocking coordinator, real memory reservations, finite checkpoints and an actual-completion handoff" [Code-verified, High]. In other words, `native_engine` is the math and `hosted` is the runtime tenancy — the admission domain, memory ledger, and cancellation ownership the design philosophy demands. Both are unexecuted.

**`.fnlpq` — the artifact with an authority freeze.** Plan §5.2 specifies a custom on-disk format with an "authority freeze and invariant contract": staged immutable quantization recipes (`int8-mlp` → `int8-mlp-attn` → `int8-all` → int4 by measured allocation), each stage its own parity-gated content-addressed artifact, canonical serialization, and releases that either certify cross-OS/ISA digest identity or explicitly name the canonical publisher target with a narrower local-reproduction claim [Maintainer claim, Medium]. The converter (`src/artifact/`, 14,067 lines) is the largest subsystem after the engine — the project treats the weight pipeline as a first-class product surface, not a script.

**The numerics profiles — the fidelity ladder's load-bearing design.** Plan §1.1.1 (read in full) defines the vocabulary every fidelity claim must use, and it exists because the pinned HF implementation is "a bf16 program with explicit cast points": RMSNorm reduces in f32 and casts back, attention softmax runs in f32, RoPE tables are built in f32, final logits export as f32 [Maintainer claim, High — plan text with `[OBSERVED@pin]` labels]. Four profiles: `hf-bf16-eager` (the behavioral reference; owns "matches HF" claims), `diagnostic-f32` (bf16 widened once, then f32 throughout — the structural/bisect oracle; token flips vs bf16 are *named fixtures, not build failures*), `strict-quantized-vN` (versioned quantization algebra with preregistered logit/argmax/token/task budgets — never inherited exactness), and `fast-vN` (opt-in approximations with measured quality bounds). The code mirrors it: `src/native_engine/hf_bf16_eager/` ("deliberately the semantic, not performance, implementation… keeps activations and K/V in bf16 at the named cast boundaries" [Code-verified, High]), `diagnostic_f32.rs`, `strict_int8.rs`, `portable_int8.rs`. This is the subtlest design in the tree — it forbids the single most common ML-benchmark lie (comparing numbers across different numerical programs) by construction. It is also entirely unexecuted.

**G0 probes — what the ratification layer actually contains.** `tests/g0/` holds the Phase-0 executable probes: `probe10_avx2_exact.rs` proves scalar arithmetic bounds for the two required non-saturating AVX2 constructions (i64 reference dots vs low7/high-bit decompositions at K=10752, with the full-domain bound 176,160,768 stated in code — "deliberately cannot ratify AVX2 dispatch on the current host," per its own docstring [Code-verified, High]); `probe11` (the asupersync census target) emits `G0_CENSUS … RESULT=…` lines against the pinned asupersync rev so verdicts are observations; siblings cover the HTTPS matrix, seam/broker boundaries, tokenizer/template, the loop boundary, mask memory, reduction order, converter RSS, and an fs-crash matrix. These are lab exports with honest scope labels — the strongest pre-execution evidence class in the tree.

**The asupersync question (Rulebook §6 — verified, not assumed):** asupersync is an *evaluated, adopted-behind-a-feature* foundation, not the default runtime. Seven `src/` files reference it, all behind `#[cfg(feature = "asupersync-runtime")]`; the release default does not select it; a dedicated G0 census target (`tests/g0_asupersync_census.rs`, `required-features = ["asupersync-census"]`) probes its `Cx`/`Scope` constructors against the pinned rev. The CHANGELOG asserts its Rayon edge was audited as dev-only and the release graph excludes Rayon by dependency-policy gate — but with no production graph and no DSR run, that exclusion is a design rule, not an observed build fact [Code-verified, High on the wiring; Maintainer claim, Medium on the audit].

**Data flow (target state — the executed path does not exist):** `fnlp` CLI/library (sync, blocking) → ATELIER (task layer: extract/ner/resolve/sentiment/classify/judge/redact/summarize/keyphrases/answer/generate) → LEXICON (in-house SentencePiece BPE + chat-template builder) → STENCIL (schema/source languages → constrained-execution programs) → CONVEYOR (layer-major batch fabric, COW prefix/KV pages, NDJSON daemon, durable jobs) → OUROBOROS (the loop core: embed → 22 layers → RMSNorm → same 22 layers → RMSNorm → lm_head) → FOUNDRY (weight pipeline: pinned bf16 → staged immutable quant recipes → `.fnlpq` → split release assets) / ASSAY (L0–L5 parity ladder, task evals) [Maintainer claim, Medium — the README's "How it works" diagram; no path executes end to end].

**Test surface:** 58 test files under `tests/` [Counted, High], including `tests/g0/` ratification probes (AVX2 exactness bounds, HTTPS matrix, seam/broker probes, tokenizer/template, loop-boundary, mask-memory, reduction-order, converter-RSS, fs-crash-matrix). 20 of the 58 top-level test files contain `provisional`/`synthetic`/`placeholder`/`todo!`/`unimplemented!` markers [Counted, Medium] — the tree labels its own scaffolding. The pin commit's own message states: "Compilation, Rust tests, model inference and physical crash/DSR qualification were not run; controller validation remains pending under WIRING.md" [Git-observed, High].

**Unsafe arithmetic, stated explicitly:** 0 unsafe blocks in `src/`, `unsafe_code` denied at the three crate roots and in `[lints.rust]`. The "audited islands" are a design *permission* (README design philosophy: "only enumerated SIMD/mmap modules may allow `unsafe_code`"), not an observed state — at the pin there is nothing to audit. `src/native_engine/dispatch.rs` references `std::arch` for the future SIMD islands.

## 4.5 The maintainer's stated case

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

1. **The model is worth it:** Nanbeige4.2-3B's card reports 63.6 SWE-Bench Verified / 87.4 GPQA-Diamond with 3.149B non-embedding params, Apache-2.0 weights, 256K context, and a looped architecture (44 effective layer executions) that doubles the per-token logical weight traffic — the exact property a specialization play exploits [Maintainer claim, Medium — card numbers labeled [REPORTED] by the plan itself].
2. **The loop is the moat (B2):** the 22×2 schedule with per-`(layer, loop)` KV binding, two post-loop norm states, and loop-corrected cost models; quantization's benefit doubles because the stack is visited twice per token [Maintainer claim, Medium — coherent; the external llama.cpp analysis notes the executable graph is a plain looped llama stack, so the "moat" is really in the task layer, not the loop].
3. **Valid-by-construction output (B3/B4):** JSON-Schema compiles to a bounded automaton over a vocab byte-trie; `verbatim` fields are byte-exact source substrings; EOS only at accept states; untrusted bytes structurally cannot become control tokens [Maintainer claim, Low — no decode path executes].
4. **Corpus fabric (B5):** layer-major batching, COW prefix cache, NDJSON daemon, durable crash-resumable jobs with content-addressed semantic keys [Maintainer claim, Low — designed, not run].
5. **Evidence-native honesty (B6):** the eight-state evidence vocabulary, L0–L5 ladder, measured-not-assumed ISA dispatch, losing rows kept, disjoint calibration/test splits [Maintainer claim, Medium — the machinery exists and runs; the evidence it governs does not yet].

**Benchmark and conformance audit:** there is nothing to audit — and that is the audited finding.

| Number | Claimed by | Status |
|---|---|---|
| Any tok/s, latency, or throughput figure for `fnlp` | Maintainer | **None published.** README: "no FrankenNLP performance number exists yet, because no kernel exists yet" [Maintainer claim, High] |
| Hypothetical roofline ceilings (74/111/55/90 tok/s by host class at 3.7 GB/token) | Maintainer | Published as "context, not promises" — arithmetic, not measurement [Maintainer claim, High] |
| PG-0–PG-8 gates | Maintainer | All TARGETED; the measurement discipline (plan §10) is specified, unexecuted [Maintainer claim, High] |
| Independent benchmark of `fnlp` | Third party | **None exists; none can exist yet** (no executable artifact) [External, High within recall caveats] |
| Tensor-census replay (201 tensors, 4,169,800,704 params) | Maintainer | **Independently reproduced in this assessment**: live HF pinned-revision replay, `--check` PASS, 0 missing/mismatched/extra [Verified, High] |

The plan's §10 measurement discipline is unusually concrete for vapor: randomized paired A/B trials through thermal steady state, per-regime distributions (never best-of-N), thread/allocator/precision-fair comparison against "a Phase −1 tested post-support official `llama.cpp` revision (starting from support commit `b77d646…`)" [Maintainer claim, High — plan §10 G2] — and this assessment verified that pin is real: `b77d646751d01c0962bc203b6809e9d94f7d50b7` is the actual merge commit of upstream PR #25994 [External, High]. The named baseline is not a placeholder; it is a verifiable commit. And — the detail that most shows the author's honesty — a "nearest format peers" rule forbids the phrase "matched quantization": `fnlp`'s `int8-all` must be compared against llama.cpp's Q8_0 class, an approximate peer, never claimed as the same thing [Maintainer claim, High]. That rule makes the PG-3/PG-4 "meet/beat" gates *harder to pass*, not easier — the project is writing its own anti-marketing constraints before it has marketing. Losing rows are to be published. The thesis-critical comparison is the number the whole CPU-hyper-optimization bet rests on, and it is currently a sentence in a plan. **Reproduction cost:** currently infinite for performance (no executable artifact); trivial for the census (one Python script, seconds).

## 4.6 Competitors

The incumbent wins on existence; franken_nlp's only uncontested edge is a product layer no competitor has built — which is also unbuilt by franken_nlp [Inference, Medium].

**Why the incumbent wins today, in one paragraph:** a user who wants to run Nanbeige4.2-3B locally on 2026-09-22 can `ollama pull nanbeige/nanbeige4.2:3b-Q4_K_M`, or download a community GGUF, or build the author's `-b nanbeige42` llama.cpp branch, and be generating tokens within minutes — with a quantization zoo, server mode, and (in Ollama's case) a model library. `fnlp` at the same date cannot generate a single token; its Quick Start is `fnlp robot health` and a robot-schema command. The incumbent's moat is not performance but *convenience and existence*, and it widens every month the appliance stays unbuilt. franken_nlp's counter-thesis is that convenience is the wrong axis: nobody has productized grammar-guaranteed, source-grounded extraction with calibrated scoring and durable corpus jobs as a one-model appliance, and the people who need that (agents, document pipelines) would trade one-command ease for contractual output guarantees. That thesis is coherent and currently evidence-free [Inference, Medium].

- **llama.cpp (official upstream, ggml-org):** now supports Nanbeige4.2 natively (merged 2026-07-27 per community record; v0.4.0 release notes) [External, Medium–High]. It is the named honest baseline in the plan — a general CPU/GGUF inference runtime with server mode, quantization zoo, and a large contributor base. It owns the "run this model locally" lane completely. It has no NLP task layer, no grammar-guaranteed extraction, no durable corpus jobs [Inference, Medium].
- **SGLang / vLLM / Ollama (Nanbeige's own forks):** the model authors ship `-b nanbeige42` branches of llama.cpp, sglang, vllm, and ollama, plus a published `nanbeige/nanbeige4.2:3b-Q4_K_M` Ollama model [External, High — the card's own quickstart]. The authors are vertically integrating the serving lane themselves — which both validates the model's traction and means `fnlp`'s baseline is a moving, author-backed target [Inference, Medium]. Community GGUFs already exist too (e.g. `Andgihat/Nanbeige4.2-3B-GGUF`, whose card notes unmodified upstream llama.cpp fails with `unknown architecture 'nanbeige'` — a pre-support artifact) [External, Medium]. The ecosystem routes around the model; `fnlp` must beat convenience, not just latency.
- **Cloud LLM APIs:** the cost/privacy foil in the pitch; frontier models beat a 3B on hard extraction/judging accuracy — the README concedes this in Limitations [Maintainer claim, High].
- **spaCy-class pipelines:** the fast-local foil; right tool for POS/dependency/lemma slices, which the project explicitly declines to contest [Maintainer claim, High].
- **franken_ocr (sibling, 328 stars):** the same maintainer's shipped proof that "this shape ships" — pure-Rust, CPU-only, one-model appliance with custom int8 kernels [External, High on description]. Not a competitor; the closest thing to a demand signal and a lifecycle template (the plan traces its Baidu-model lifecycle as normative for Nanbeige) [Inference, Medium].
- **Unoccupied lane:** a one-model *NLP appliance* — grammar-guaranteed structured extraction with source-grounded fields, calibrated scoring surfaces, and crash-resumable corpus jobs over a local 3B — has no direct occupant. llama.cpp/Ollama are runtimes, not task products; spaCy is classical; cloud APIs are the anti-thesis [Inference, Medium]. Whether anyone will pay (in effort) for the appliance over "llama.cpp + DIY prompting" is the unproven bet — and the project plans to answer it with locked task scorecards rather than assertions, which is the right instrument, unbuilt.

## 4.7 Skeptic's take

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

**Strengths (substantive):**

1. **The evidence grammar is a real, portable artifact.** The plan's inline evidence-state vocabulary (`[OBSERVED@pin]`, `[REPORTED]`, `[EVIDENCED]`, `[PARTIAL]`, `[TARGETED]`, `[HYPOTHESIS]`), the `fnlp-claim` annotation scheme, `CLAIMS.json`, three ledger schemas, and `check_claims.py` compose a machine-checkable honesty system — executed by this assessment (census replay PASS; claims linter runs and self-reports FAIL). No sibling packet has shown this level of pre-execution governance [Inference, Medium — comparative].
2. **Stage-honesty is load-bearing, not decorative.** The README's note on tense, the disclosed current-executable-surface block, the zero-number Performance section, the FAQ's "Is this production-ready today? No," and commit messages that state what was *not* run — this is systematic anti-vaporware practice, and the audit found no contradicting sentence in the materials assessed [Code-verified, High].
3. **Model-dossier diligence is genuinely good.** The 201-tensor census (independently re-verified here), the `head_dim = 128` catch (the generic Llama fallback of 64 would silently build the wrong engine), the `<think>`-is-`special=false` catch (which breaks naive control-token filtering), and the refusal to resolve the card's own HMMT 82.8-vs-82.1 conflict in the favorable direction are the work of someone who reads the artifact before theorizing about it [Verified/Code-verified, High].
4. **Dependency discipline is machine-checked.** `SUITE.lock` (plan-audited vs selected revs with reason strings), the `dependency_policy` test, the Rayon-free release-graph rule, and the asupersync census probes constitute a supply-chain posture most shipped projects lack [Code-verified, High].

**Weaknesses (each substantive — capable of stranding the project alone):**

1. **[FATAL] Nothing executes end to end.** 116,321 lines, 58 test files, and the pin commit's own message says compilation and tests were not run. The engine's critical function — running the model — has zero executable evidence. Every strength above is about the *frame*; the *picture* is blank [Code-verified + Git-observed, High].
2. **[FATAL] The project cannot prove a build to anyone.** No `production` feature graph, DSR authority BLOCKED, GitHub Actions disabled, no tags, no releases, and the bus factor is 1 *by stated policy*. The honesty machinery proves the maintainer isn't lying; nothing proves the code builds [Code-verified + Maintainer claim, High].
3. **[HIGH] The loop-moat thesis is thinner than the plan's rhetoric.** The "one structural novelty" is, in every executable graph including upstream llama.cpp's, a plain looped llama stack — shared weights, `num_loops`-expanded layers, a loop-boundary norm. The genuinely novel HF extras (LoopSplit, mHC depth attention, n-gram embeddings) are *inactive* at this checkpoint, by the plan's own §2.4. The defensible moat is the task/product layer (B3–B5), not the loop [Maintainer claim + External, Medium].
4. **[HIGH] Process mass vs. engine mass.** The 324 KB plan, 57 KB AGENTS.md, six bets, eight-state evidence vocabulary, L0–L5 ladder, alien-artifact recommendation cards, idea-wizard records, and disposition tables are — today — the product. A design-stage project can die of its own governance weight: every hour spent grading sentences is an hour not spent landing Phase −1 [Inference, Medium].
5. **[MEDIUM] The claims linter bites its owner and nobody is home to fix it.** `check_claims.py --check` FAILS on the pin's own tree with exit 0 — it reports, it does not gate, and the violation sits in `src/cli.rs` at the assessed commit. Machinery that observes without enforcing is documentation with a shebang [Verified, Medium].
6. **[MEDIUM] The present-tense README is quotable out of context.** The note on tense is honest; the 55 KB of present-tense target description above it is quotable. The `fnlp-claim` HTML comments are machine annotations, not reader-facing warnings — and at the pin, exactly **one** such annotation exists in the README (line 1) [Counted, High]. The honesty relies on readers reading the note first [Inference, Medium].
7. **[MEDIUM] Commit history is a burst, not a cadence.** 583 of 827 commits landed on 2026-07-31; September shows a real but thin code-first campaign (25/40/2/18/9/8 per day 09-17→09-22). The August window is nearly empty. Velocity claims should be read as campaign pulses, and the next pulse is not scheduled in any artifact I read [Git-observed, High].
8. **[MEDIUM] The adversarial review grades its own homework.** The CHANGELOG records three review rounds — two internal, one external ("GPT Pro deep reasoning, 44 proposals"). The external round ran on an OpenAI model: output of a Restricted Party under the project's own rider, reviewing the rider-bound tree. There is no independent reviewer in the loop at any point: the maintainer, his agents, and a lab model he bars from analyzing the code. The reviews visibly improved the plan (the fork-only premise was corrected, the tensor arithmetic fixed), so this is not theater — but it is not independence either, and the packet's honesty claims should not be read as third-party validation [Maintainer claim, High on the rounds' occurrence; the independence assessment is Inference, Medium].

**Bear-case steelman (strongest counter-case):** franken_nlp is the FrankenSuite's most elaborate design document attached to its least-executed engine — 116K lines that have never compiled as a system, governed by the finest pre-execution honesty machinery in the program. The labeling scheme ("targeted") makes the project unfalsifiable in the short run: every miss is already labeled. The loop moat is a plain looped stack in every runtime that matters; the task-layer moat is unbuilt; the honest baseline (upstream llama.cpp) improves monthly. The maintainer refuses contributors by policy, the build authority is blocked, and the license bars the two AI labs most likely to evaluate it from even analyzing it. The rational market response is to adopt the evidence grammar, run the census script, and ignore the engine — which is exactly what this assessment did. The most likely end state is not failure but permanent design review: a beautiful spec that never meets a weight file. [Inference, Medium — deliberately uncharitable; the counter-evidence is the sibling franken_ocr, which did ship this shape, and the September campaign's real (if thin) pulse.]

## 4.8 Maintenance & succession

**Bus factor: 1 — by policy, not accident.** The README's "About Contributions" states verbatim: *"I do not accept outside contributions for any of my projects. I simply don't have the mental bandwidth to review anything… I'll have Claude or Codex review submissions via `gh` and independently decide whether and how to address them."* All 827 commits in the deepened history are authored by Jeff Emanuel/Dicklesworthstone; 8 of the last 200 carry `Co-Authored-By` trailers and 1 commit is authored by "YellowRaven (Claude)" [Git-observed, High]. Agent involvement is therefore *review and co-authorship*, disclosed in the contribution policy itself. No succession plan, no second committer, no foundation [Inference, Medium — absence across assessed materials].

**Maintenance load signals:** the Beads graph (196 issues, 49 open, 147 closed [Counted, High]) is the institutional memory; the CHANGELOG records three rounds of adversarial review (two internal, one external: "GPT Pro deep reasoning, 44 proposals"). The September code-first campaign is active but thin. Review depth is unassessed: with no merged outside PRs possible, "review" means the maintainer plus Claude/Codex via `gh` [Maintainer claim, Medium].

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

- **What it is:** "MIT License (with OpenAI/Anthropic Rider)", © 2026 Jeffrey Emanuel. In any conflict between the rider and the rest of the license, the rider controls.
- **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)."
- **Scope:** "no rights are granted to any Restricted Party" — and "use" is defined to include "copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, **benchmarking, testing, analyzing, indexing**, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems." Breach = automatic, immediate termination; injunctive relief and attorneys' fees provisions included. "Affiliate" = >50% voting control or power to direct management.
- **Third-party carve-out (same file):** the rider covers **only** the franken_nlp source code — "It does NOT cover any model weights or tokenizer data," which "remain licensed under Apache-2.0" as declared by the pinned model card. Every distributed artifact must carry the Apache-2.0 text, attribution, and modification notice.
- **OSI status:** **non-OSI.** A named-party use restriction with a field-of-use flavor (no benchmarking/analyzing/training) fails the Open Source Definition's non-discrimination clauses (§5, §6). Stated plainly: this is source-available with a targeted exclusion, not open source [Inference, High — license-text analysis, not legal advice]. A quiet, mechanical consequence: GitHub's own license classifier reports this repository as `other` / `NOASSERTION` [External, High] — the rider breaks automated license detection, so every downstream license scanner will flag or misclassify the tree. That is adoption friction no README badge ("MIT + Rider") can fix.
- **The rider as strategy (§6 lens):** the exclusion list names the two AI labs plus their supply chains. For a *local NLP appliance* whose users are end operators, the rider costs little direct adoption — but it bars the entities best equipped to independently validate the engine (benchmark it, analyze it) and it poisons the contributor well the project already closed by policy. The strategy reads less as commercial positioning than as personal boundary-setting by a solo maintainer — consistent with the no-contributions policy — but it sits in tension with the project's own history: the rider bars as licensee conduct what the project practiced as method. (The sibling FrankenRedis assessment in this program found the same pattern — Anthropic-model co-authorship under an anti-Anthropic rider — suggesting a Suite-wide posture: build with the labs' tools, bar the labs from the artifact.) [Code-verified (license text), High on the text; the strategy read is Inference, Medium]

## 4.9 NODUS factsheet

| Criterion | Score | Justification (one line) |
|---|---|---|
| Technology readiness | TRL 2–3 | Concept + analytical design complete (TRL 2 fully); experimental evidence limited to arithmetic/dependency probes, never a model-execution path (TRL 3 partial) [Inference, Medium] |
| Strategic relevance | 2/5 | The engine is pre-execution; the evidence-governance methodology is the strategically interesting artifact [Inference, Medium] |
| Impact potential | 2/5 | One-model NLP appliance is a niche; methodology export (evidence grammar, census replay) could travel Suite-wide [Inference, Medium] |
| Implementation feasibility | 2/5 | Phase −1/0 gates incomplete, production graph unwired, DSR authority blocked, bus factor 1 by policy [Code-verified/Maintainer claim, High] |
| Time to mainstream | 1/5 | No executable path exists; 12-month horizon requires Phase −1→3 gates landing, which needs a sustained campaign, not pulses [Inference, Medium] |
| Collaboration potential | 1/5 | No outside contributions by policy; rider bars AI-lab evaluators; no second maintainer path stated [Maintainer claim, High] |

**Ring: Monitor** [Inference, Medium]. The Rulebook is explicit: Monitor is for plan-stage work. A 116K-line scaffold does not promote a design review to Explore — Explore requires "substantive-but-unproven," and the substance here is documentation, not executed capability. When in doubt, ring down.

**Ring-transition triggers (what would move it):**

| Transition | Observable trigger |
|---|---|
| Monitor → Explore | First executed oracle-parity receipt: `hf-bf16-eager` token-identical to the pinned HF oracle over the L2 ladder, with a retained `PASS` DSR receipt |
| Explore → Pilot | PG-3/PG-4 gates passed against the pinned llama.cpp support commit with losing rows published, plus one independent replication of the PG-3 number |
| Monitor → permanent Monitor | Nightly-2026-08-31 pin bit-rots before first execution; or the DSR authority chain never unblocks |
| Any ring → downgrade | Measured PG-0/PG-1 numbers miss the roofline orientations by >2×, falsifying the loop-amplification arithmetic |

Until the first row's trigger fires, upgrading the ring would be grading the plan, not the project — and this packet's central thesis is that the two must never be confused.

## 4.10 Wardley placement

- **Commodity:** Rust toolchain, clap/serde/sha2, the Nanbeige4.2-3B weights themselves (Apache-2.0, third-party), upstream llama.cpp as baseline — all product/rental stage; the project consumes them correctly [Inference, Medium].
- **Custom-built (genesis → custom):** the one-model engine (OUROBOROS/CONVEYOR/STENCIL/ATELIER) — genesis: designed in detail, never executed. Moves toward custom with the first model-present parity run; toward product only with a release artifact and users.
- **Genesis (novel):** the evidence-governance machinery — inline evidence-state vocabulary, `fnlp-claim` annotations, ledger schemas, SUITE.lock, the BLOCKED-until-receipt DSR authority model. Nothing else in the Suite packages pre-execution honesty as an executable system. It moves toward product the moment a second project adopts the grammar (see next step 1).
- **What would move the engine:** a clean-SHA DSR receipt (custom), the first L2 ladder parity run against the pinned oracle (custom+), a tagged release with `.fnlpq` artifacts (product edge).
- **The external clock:** upstream llama.cpp improves monthly and the Nanbeige authors ship their own `-b nanbeige42` serving branches — the "real, maintained baseline" the README names gets faster and more convenient while `fnlp` is pre-execution. The project's window is the gap between the baseline's current convenience and the unoccupied appliance lane (§4.6); every month without a parity run narrows it [Inference, Medium].

## 4.11 Trajectory (12 / 24 / 60 months) — [Inference, all of it]

**Base case (12 mo):** the September code-first campaign lands Phase −1 (truth pack) and Phase 0 (G0 ratification probes) — the parts the maintainer is demonstrably good at — but the production graph, DSR receipt, and first model-present parity run slip; the repo remains the best-documented pre-execution project in the Suite. Ring stays Monitor.

**Bifurcation.** *Upside:* the maintainer replicates the franken_ocr lifecycle (immutable fetch → deterministic convert → digest-verified release, already traced as normative in the CHANGELOG); a clean DSR receipt unblocks the authority chain; the first `hf-bf16-eager` L2 run goes green and the loop-1 draft card gets its exact experiment. Then the packet's ring revisits to Explore on executed evidence, and the evidence grammar becomes the Suite's design-stage standard. *Decay:* the plan accretes (v5, v6…), the nightly-2026-08-31 pin bit-rots against newer toolchains, the 827-commit burst history becomes archaeology, and the next campaign pulse never comes — permanent design review, the bear case.

**The critical path in order (from the plan's own phase gates):** the immediate bottleneck is OQ-30 — the 44-execution oracle needs explicit trace hooks because the pinned HF implementation surfaces only the final loop's hidden states; without those hooks there is no oracle to be faithful to, so no parity run, so no int8 kernel validation, so no PG-0–PG-2 numbers, so no task layer qualification, so no PG-3/PG-4 baseline race. Everything downstream of the fidelity thesis queues behind a tracing detail. That is the single most leveraged fact about this project's schedule: the first domino is instrumentation, not optimization [Maintainer claim, High on the plan's gate ordering; the leverage read is Inference, Medium].

**Revisit triggers (concrete, observable):** (1) first clean-SHA DSR `PASS` receipt for `scripts/check.sh` on a named `production` graph; (2) first model-present parity run (any L-gate green against the pinned oracle); (3) first git tag / GitHub release; (4) `check_claims.py --check` green on the tree; (5) a second human committer or a stated succession plan; (6) any independent third-party execution (build, benchmark, or review) of the tree.

## 4.12 Limitations and open questions

**Not done:** the crate was never compiled; no test suite was executed (58 test files inventoried, not run); no model weights were downloaded (only the 16.5 KB safetensors index + 1 KB config for the census replay); no inference, kernel, or batch path was executed; the DSR/Beads/Mail wiring was read, not exercised; review depth (PRs vs direct-to-main) was not examined; the `fnlp-claim` linter's exact trigger rule for the `src/cli.rs:26` FAIL was not fully traced (the FAIL verdict itself was observed); web demand-signal search was limited to repo/model/baseline coverage.

**Open questions that would most change the verdict:**
1. Does the tree compile at the pin on the pinned nightly? (A `cargo check` at a clean SHA is the cheapest verdict-changer available.)
2. What is the exact `check_claims.py` trigger that FAILS on `src/cli.rs:26`, and is the rule sound or over-eager?
3. When the G0 probes run, do the AVX2 exactness bounds hold on real Zen 3 hardware (they are scalar proofs today)?
4. Does the pinned HF revision's `modeling_nanbeige.py` loop driver match the plan's §2.4 account line-for-line (the [EVIDENCED/OQ-3] clause)?
5. Is there any path — policy change, foundation, second maintainer — off bus-factor-1, or is the no-contributions stance permanent?
6. Will the DSR authority chain ever unblock, or does WIRING.md's BLOCKED become the project's permanent build story?

**Which of these would change the ring:** none of open questions 1–6 going well changes the ring (a compiling, lint-clean scaffold is still a scaffold) — only §4.11's revisit trigger (2), a model-present parity run, moves Monitor→Explore. Questions 5–6 going badly would cement Monitor as permanent. The ring is insensitive to everything except executed model evidence, which is exactly what the ring is supposed to measure.

## 4.13 The eight deepening questions

1. **Provenance.** The project records provenance obsessively at the *design* layer — every pinned observation is slated for line-backed, hash-bound truth-pack evidence, `SUITE.lock` binds foundation revs with reason strings, and the future release recipe demands SBOM/SLSA/project-signature bundles with GitHub immutable-release attestation. What it cannot yet produce is a single executed provenance receipt: the DSR checkpoint schema exists but WIRING.md reports BLOCKED (no `production` graph, no clean-SHA run), so nothing attests what built what. Making attestation portable means unblocking that chain — a clean SHA, a named graph, a retained `PASS|FAIL` receipt — plus solving the signing-key distribution the plan honestly flags (a signature and key fetched from one untrusted mirror prove nothing). Today provenance is a specified protocol, not an artifact. [Maintainer claim + Code-verified, High]

2. **The embeddable unit.** The smallest useful adoptable piece is not any engine component — it is the evidence grammar: `docs/CLAIMS_ANNOTATIONS.md` + `docs/CLAIMS.json` + the three ledger schemas + `scripts/check_claims.py`. Adoption cost is copying four paths and annotating public sentences with `fnlp-claim` comments; the linter then enforces the `targeted`/`evidenced` distinction mechanically. The runner-up is `scripts/gen_tensor_census.py`, a self-contained, hash-pinned model-census replay any project pinning an HF revision can reuse. Both are adoptable without the engine, the repo, or the maintainer — which is precisely why they are the project's most valuable outputs at this stage. [Inference, Medium]

3. **Unexercised option value.** The architecture holds several unexercised options: the asupersync census probes (OQ-35) verify an execution foundation the default graph never loads; the `metadata-store` durable-job surface is wired behind a feature but has no jobs; the trace-gated research cards (loop-1 draft decoding, AA-R1 resident research) are specified experiments awaiting an executable engine; and the batch fabric's one-process admission domain (ten engines, one memory ledger) is designed but untested. What unlocks them is the same single event: the first model-present execution, which converts specified options into testable ones. Until then they are options on an unbuilt underlying. [Inference, Medium]

4. **Benchmark honesty.** There are no numbers to audit — the honest answer is that the load-bearing quantitative claims are the *hypothetical* roofline orientations (3.7 GB/token → 55–111 tok/s across host classes), explicitly labeled "context, not promises," and the PG-0–PG-8 gate table, all TARGETED. Which would survive an independent rerun? The census replay would (it did — this assessment reran it). The roofline ceilings would survive only as arithmetic, not as measurements. The thesis-critical comparison — PG-3/PG-4 "meet/beat official llama.cpp" — is the number the whole CPU-hyper-optimization bet rests on, and it is currently a sentence in a plan. The project's own rule ("publish the rows where it wins") is the right standard, unsatisfied. [Verified + Maintainer claim, High]

5. **The governance path.** There is no credible route from one maintainer to an institution in any artifact I read — the contribution policy actively refuses the first step ("I do not accept outside contributions"), there is no succession plan, and the rider narrows the evaluator pool. If velocity decays, what breaks first is the toolchain pin (nightly-2026-08-31 will not stay buildable forever), then the campaign-pulse cadence (the August gap shows how easily a month goes quiet), then the Beads graph's freshness as a planning record. The honest version: this project is a solo practice sustained by one person's weekends, and its governance documentation is excellent precisely because it has to substitute for a team. [Inference, Medium]

6. **The license as strategy.** The rider excludes OpenAI, Anthropic, their affiliates, and anyone acting for them — from use, benchmarking, analyzing, indexing, and training-data incorporation, with automatic termination on breach. For the stated mission (a local NLP appliance for end operators), the exclusion costs little direct adoption but sabotages the *validation* mission: the two labs best equipped to benchmark or analyze the engine may not touch it, and the contributor pool was already closed by policy. The strategy reads less as commercial positioning than as personal boundary-setting by a solo maintainer — consistent with the no-contributions policy — but it sits in tension with the project's own history: adversarial review round 3 ran on GPT Pro, an OpenAI model. The rider bars as licensee conduct what the project practiced as method. [Code-verified (license text), High; the strategy read is Inference, Medium]

7. **Agent-era fit.** The concrete agent workload that would pick `fnlp` over llama.cpp is the document-processing agent: schema-guaranteed extraction with byte-exact source-grounded fields, calibrated classification with abstention, and crash-resumable corpus jobs — the "robot mode" NDJSON contract is explicitly designed for agents to pipe. One honest narrowing: llama.cpp already ships grammar-constrained generation (GBNF), so the grammar half of the appliance lane exists upstream — the unoccupied part is the *packaging* (durable jobs, calibration surfaces, source-grounding, locked scorecards), not the constraint mechanism. What has to become true first: Phase 5's locked task scorecards must show the 3B model is *good enough* at those tasks (the plan admits the card's agentic scores don't prove extraction quality), the constrained decoder must execute, and `fnlp eval` must let an agent qualify the artifact on its own corpus. Until then the agent-era answer is llama.cpp with GBNF grammars — the incumbent the plan refuses to pretend doesn't exist. [Inference, Medium]

8. **The kill test.** The single experiment: run the pinned HF oracle and `hf-bf16-eager` over the L2 ladder (all 44 layer executions + both post-loop norms) on oracle-reproducible prefixes — if greedy tokens diverge beyond the named tolerances, the fidelity thesis (B1/B2's foundation) dies and no kernel work can save it. The single competitor move: upstream llama.cpp (or Ollama) ships a first-class constrained-extraction + durable-corpus-job product layer — the one unoccupied lane (§4.6) closes, and the specialization bet loses its product wedge, leaving only the kernel race. The single event: the DSR authority chain never unblocks and the nightly pin bit-rots — the project becomes unbuildable even in principle, and Monitor becomes the permanent ring. [Inference, Medium]