# FrankenOverlap — RULEBOOK v1.0 Assessment Packet v6

**Repository:** `Dicklesworthstone/franken_overlap` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `063182c85d3f3679ef0923a3ce780e8443c9d388` (2026-09-04 01:34:15 -0400, [Git-observed, High]) · **Last push:** 2026-09-04T05:34:24Z — the pin IS the latest push (commit landed 9 seconds before the push timestamp) [External (GitHub API), High] · **Scope:** the pinned commit only. No tags, no releases at the pin [External, High]. *Cold-reader note: "v1" = first draft of this packet; there was no prior draft.*

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read); **[CI-observed]** (Tier 2) is unattainable for this repo (GitHub Actions deliberately disabled — see claim 7); **[Maintainer claim]** asserted in README/docs, not independently executed; **[External]** independent sources (the web search for this repo returned only the repo itself — absence of coverage is a finding); **[Inference]** analyst judgment, always labeled. Confidence: **High** (multiple converging sources or direct inspection) / **Medium** (single solid source, plausible) / **Low** (thin evidence, extrapolation).

**Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/franken_overlap-verify` (verified non-empty); history deepened (blobless) to 347 commits for the authorship sample only — the working tree stayed at the pin. Read: root `Cargo.toml`, all 6 crate manifests, `Cargo.lock`, `LICENSE` (verbatim), README, `CHANGELOG.md`, `AGENTS.md`, `VALIDATION.md`, `SECURITY.md`, `docs/EMPIRICAL_STATUS.md`, `docs/EMPIRICAL_EVIDENCE.md`, `COMPREHENSIVE_PLAN_FOR_FRANKEN_OVERLAP.md` (head), `ci/github-actions-disabled/ci.yml.disabled`, `scripts/ci-local.sh` (existence), `crates/fo-conformance/{src/lib.rs,tests/conformance.rs}`, `crates/franken-overlap/tests/public_api.rs`, `crates/fo-core/src/lib.rs` (API surface). Counted: `.rs` files/lines, `unsafe` occurrences (with context), `#[test]` attributes, Cargo.lock packages, docs lines, fixture files. Searched the web for independent coverage (none found). **Not done:** the workspace was never compiled, no test suite was run, no benchmark was executed or reproduced, no corpus was downloaded, the SEC/Gutenberg acquisition paths were not exercised. Assessment date: 2026-09-22.

---

## Hook

A 57,743-line [Counted, High], single-maintainer Rust engine for finding edited, fragmented, and reordered passages — whose README refuses to claim it beats anything until a checked-in evidence run proves it. The repository ships a full benchmark courtroom (paired bootstrap claim gates, natural-label adjudication, immutable evidence bundles, an "incomplete, not extrapolated" rule for over-budget baselines) and then pleads *not yet proven* in its own docs [Maintainer claim, High]. The catch is the mirror image of the virtue: eighteen days of silence, no CI anyone can observe, no release artifact, conformance contracts that run against five tiny fixture documents — and a license rider that bars OpenAI and Anthropic from even *analyzing* the code, in a project whose listed applications include training-data provenance [Code-verified (license text), High].

---

## TL;DR

- **What it is:** A from-scratch Rust workspace (6 crates, 57,743 first-party lines / 125 files [Counted, High]) for *textual provenance*: sparse positional overlap retrieval (128-bit rolling q-gram fingerprints, rightmost-minimum winnowing, shifted diagonal voting, monotone anchor chaining, bounded exact verification), plus a fielded BM25/lexical layer, an explainable hybrid fusion, a composite fragmented-source searcher, and an optional FrankenSciPy FFT dense route. Zero unsafe code under a workspace-level `forbid(unsafe_code)` [Counted, High].
- **Strongest evidence:** The claim-governance machinery is real code, not prose: `fo-evidence-suite` (one-command proof transaction), `fo-claim-gate` (preregistered paired-bootstrap claim verdicts of `supported`/`inconclusive`/`unsupported`), `fo-adjudicate` (natural-label adjudication), immutable Markdown/HTML evidence bundles, fail-closed `.foidx` v2 parsing with a corruption-rejection test, and a README/`docs/EMPIRICAL_STATUS.md` pair that explicitly disavows superiority claims [Code-verified + Maintainer claim, High].
- **Strongest doubts:** The central thesis — better edited-passage retrieval than BM25, Jaccard, SimHash, or exhaustive edit distance — has no checked-in evidence run: no `proof.json`, `suite-status.json`, or `RESULTS.md` exists in the tree [Verified absent, High]. GitHub Actions is deliberately disabled, so no third party can observe test greenness; validation is owner-local via `scripts/ci-local.sh` [Code-verified, High]. Conformance is 8 fixture-scale tests over 5 documents / 28 KB [Counted, High]. One human maintainer, 347 commits in 21 days, zero releases, 18 days quiet at assessment [Git-observed + External, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 4 — see §4.9). Substantive-but-unproven is the textbook Explore case: real implementation, real test contracts, an honest disavowal where the benchmark numbers would be. The methodology (evidence-gated claims) is worth tracking as an export; the engine itself is un-advanceable until the first checked-in evidence run lands.

---

## Quick Links

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

1. [Repository](https://github.com/Dicklesworthstone/franken_overlap)
2. [README](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/README.md)
3. [License (MIT with OpenAI/Anthropic rider)](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/LICENSE)
4. [Changelog](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/CHANGELOG.md)
5. [Empirical-status doc (the honesty anchor)](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/docs/EMPIRICAL_STATUS.md)
6. [Validation contract (local-only CI)](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/VALIDATION.md)
7. [Disabled GitHub Actions workflow](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/ci/github-actions-disabled/ci.yml.disabled) — "Disabled intentionally: this repository is validated on owner-controlled machines."
8. [Conformance contracts (fixture-scale)](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/crates/fo-conformance/tests/conformance.rs)
9. [Releases](https://github.com/Dicklesworthstone/franken_overlap/releases) — page exists; "There aren't any releases here" [Verified, High]
10. [PAN evaluation doc](https://github.com/Dicklesworthstone/franken_overlap/blob/063182c85d3f3679ef0923a3ce780e8443c9d388/docs/PAN_EVALUATION.md) — native PAN XML / PlagDet evaluation without Python or NumPy

---

## Did You Know

The word "unsafe" appears 18 times in this codebase — and not once for memory unsafety. Every occurrence is an error string like `"unsafe corpus path"` or `"unsafe corpus relative path"`: the project's path-traversal hardening. There are zero `unsafe` blocks in 57,743 lines; the workspace lints forbid `unsafe_code` in all six crates [Counted, High]. In FrankenOverlap, "unsafe" is a filesystem concept, not a language one.

---

## Franken-worthy next steps

1. **Run the first checked-in evidence-suite transaction and publish whatever verdict comes out.** The machinery (`fo-showcase` → `fo-evidence-suite` with a claim manifest) exists; what is missing is one completed run with pinned corpus receipts. *Done when:* `evidence-runs/` (or equivalent) is checked in with `proof.json`, `suite-status.json`, and `claims.json` containing explicit `supported`/`inconclusive`/`unsupported` verdicts — even if the verdict is "unsupported," because an honest negative is the strongest possible advertisement for the claim-gate machinery. *Falsifies:* the thesis that sparse overlap beats the baselines on edited-passage retrieval, if the gates return `unsupported`. [Inference, High — process proposal]
2. **Use PAN 2013 as the first external yardstick.** `fo-pan` already parses PAN XML and computes PAN's reference-evaluator metrics (macro/micro recall, precision, F1, granularity, PlagDet) natively in Rust with no Python/NumPy [Code-verified, High on existence]. The PAN13 text-alignment corpus is public (Zenodo archive linked in `docs/PAN_EVALUATION.md`). *Done when:* a checked-in run reports FrankenOverlap's PlagDet against the published PAN13 participant scores. *Falsifies:* the "competitive with published plagiarism-detection systems" implication, if the score lands far below the 2013 field. [Inference, High]
3. **Export the claim-gate pattern to the FrankenSuite's own QA.** The paired-bootstrap `fo-claim-gate` (preregistered claim manifests, per-query bootstrap CIs, verdicts that distinguish "global candidate-stream gains from broadly distributed per-query gains") is a stronger standard than generic benchmark guidance, and it was built precisely because this maintainer distrusts his own numbers. *Done when:* the `fo-claim-gate` schema is extracted as the program's benchmark-claim template and applied to one other FrankenSuite repo's headline numbers. [Inference, High — process proposal]
4. **Implement the FO-003 fuzz targets before claiming fail-closed parsing.** `docs/IMPLEMENTATION_BEADS.md` already lists "fuzz targets for `.foidx`, normalization, rolling q-grams, chaining, and verifier" as planned work [Maintainer claim, High]; the fail-closed index format is a load-bearing security claim (untrusted corpora are the use case), currently defended by one trailing-bytes test. *Done when:* `cargo fuzz` targets exist for the v2 index parser with a checked-in corpus and no-panic runs recorded. *Falsifies:* the fail-closed claim, if the fuzzer finds an accepting path for malformed input. [Inference, High]
5. **Bounded SEC-lineage pilot: one issuer, three years of 10-Ks, adjudicated gold.** `docs/EMPIRICAL_STATUS.md` names SEC filing lineage as the highest-value product direction [Maintainer claim, High]; the acquisition, sectioning, and lineage-graph code exists. *Done when:* a checked-in pilot over a single issuer's 10-K history reports reuse-detection precision/recall against human-adjudicated labels via `fo-adjudicate`. *Falsifies:* the "SEC lineage is the killer app" positioning, if boilerplate drowns the signal. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** finding *where a passage came from* after it has been edited, fragmented, or reordered is not what keyword search or vector search is built to answer. BM25 and embeddings answer "which documents discuss this topic"; plagiarism analysis, contract lineage, edition comparison, and OCR recovery need "which exact source spans survived, what changed, and what evidence supports the answer" [Maintainer claim, Medium]. The maintainer's bet is that a sparse positional-overlap portfolio — winnowed rare fingerprints, diagonal voting, anchor chaining, exact verification — beats both naive approaches (scanning every window with edit distance) and wrong-tool approaches (semantic similarity) on long edited-passage retrieval, with auditability that black-box systems don't provide [Maintainer claim, Medium].

**Who feels the pain:** plagiarism investigators, publishers and archives comparing editions, legal/compliance teams tracking contract and policy language across versions, anyone doing dataset deduplication or training-data provenance who needs *exact, reviewable* textual evidence rather than a similarity score [Inference, Medium].

**Why now:** the training-data provenance angle is newly load-bearing — dataset dedup and "what was my model trained on" are 2024–2026 problems, and the maintainer lists them explicitly [Maintainer claim, Medium]. The irony the packet returns to in §4.8: the license rider bars the AI labs most likely to need training-data provenance from using, benchmarking, or analyzing the code.

**Demand-side check (2026-09-22):** a web search for independent coverage of FrankenOverlap (production users, third-party reviews, downstream forks, citations) returned nothing beyond the repository itself, its own commits, and search-engine mirrors of its README [External, High within recall caveats]. Zero open issues, 3 forks, no releases [External, High]. Demand is therefore entirely maintainer-asserted; there is no observable user pull.

**Why a new engine, not a library on Lucene:** stated implicitly across the README and `docs/ALGORITHM.md` — Lucene is a general inverted index for keyword search; the differentiated unit here is the *passage-alignment portfolio* (winnow → vote → chain → verify) plus the evidence machinery around it, which no general search library ships [Maintainer claim, Medium]. The honest scope statement ("should not pretend to replace Lucene, Elasticsearch, or a vector database") is in the README itself [Maintainer claim, High].

**Adjacent context:** one entry in the solo-maintainer FrankenSuite program. Cross-ecosystem links are explicit in-repo: general FFT primitives are delegated upstream to FrankenSciPy (`fsci-fft`, optional, git-pinned to rev `2da83a7f`) per `AGENTS.md` invariant 10, and "GPU unsafe/FFI remains inside FrankenTorch's sanctioned boundary" per invariant 9 [Maintainer claim, High]. asupersync is absent from `Cargo.lock` — not a dependency here, evaluated-or-not unknown, but the "verify, never assume" check is clean: no asupersync relationship exists in this repo [Counted, High].

## 4.2 What it is — repo TL;DR

A 6-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]): `fo-core` (indexing, retrieval, alignment, storage, ranking evidence, metrics — 20,618 lines [Counted, High], the engine), `fo-cli` (19 CLI bins [Counted, High]: overlap, lexical, hybrid, batch, composite, multiview, planner, segment, SEC lineage, review workbench), `fo-corpus` (Gutenberg/SEC acquisition with SHA-256 manifests, sectioning), `fo-bench` (17 bench bins [Counted, High]: baselines, adjudication, claim gates, evidence suite, tuning, PAN evaluation), `fo-conformance` (behavioral/persistence/corruption contracts), and `franken-overlap` (public facade). Development velocity is extreme and human: 347 commits from 2026-08-14 through 2026-09-04 (~16.5/day), all authored by Jeff Emanuel across three email identities, with only 4 agent Co-Authored-By trailers in the full history [Git-observed, High] — the authorship is overwhelmingly hand-written, concentrating all design knowledge in one head.

One-line verdict: **the most honest unproven search engine in the program — a complete benchmark courtroom with no trial yet held, built by one person in three weeks, under a license that excludes the AI labs from the audience.** (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 6 workspace crates, 57,743 first-party Rust lines / 125 files | demonstrated | Fresh clone at pin; `Cargo.toml` members enumerated; line count over `crates/` | [Counted, High] |
| 2 | Zero unsafe code: workspace `unsafe_code = "forbid"` inherited by all 6 crates (`[lints] workspace = true` in each manifest) | demonstrated | Lint inheritance verified in all 6 manifests; full-tree `unsafe` grep returns 18 hits, all `"unsafe … path"` error strings, zero `unsafe` blocks | [Counted, High] |
| 3 | Default core has no C, C++, Python, BLAS, or GPU runtime dependency | demonstrated (for `fo-core` default features) | `fo-core` deps: rayon, serde, serde_json, thiserror, unicode-normalization, unicode-segmentation — all pure Rust. `cc` appears in `Cargo.lock` only via `aws-lc-sys`/`ring`/`blake3`/`cmake` pulled by non-core crates (e.g. `fo-corpus`'s reqwest TLS). The FrankenSciPy FFT path is opt-in (`frankenscipy` feature, git-pinned `fsci-fft`) | [Counted, High] |
| 4 | `fo-conformance` provides behavioral, persistence, and corruption contracts | partially demonstrated | `src/lib.rs` is 3 lines (a `CONFORMANCE_SCHEMA_VERSION` const); the real contracts are 8 tests in `tests/conformance.rs`: edited-passage ranking (2), partial reuse, Unicode normalization, unrelated-text negative, persistence roundtrip with score-equality to 1e-6, trailing-bytes corruption rejection, dense spectral exact peak. Fixture scale: 5 documents / 28 KB | [Code-verified, High] |
| 5 | Full evidence machinery exists: `fo-evidence-suite`, `fo-claim-gate`, `fo-adjudicate`, immutable Markdown/HTML bundles, "incomplete, not extrapolated" policy for over-budget baselines | demonstrated (existence); the completed run is aspirational | Bins and modules verified present in `fo-bench`; docs (`EVIDENCE_SUITE.md`, `PAIRED_CLAIM_GATES.md`, `GOLD_ADJUDICATION.md`, `EVIDENCE_BUNDLES.md`) read. No `proof.json` / `suite-status.json` / `RESULTS.md` anywhere in the tree | [Code-verified, High] |
| 6 | "Comparative advantage remains a hypothesis until a checked-in evidence suite demonstrates it" — the maintainer's own disavowal | demonstrated | README "Empirical status" section + `docs/EMPIRICAL_STATUS.md` verbatim: "this README does not claim that FrankenOverlap has already beaten BM25, exact search, Jaccard, SimHash, or exhaustive edit-distance retrieval by a particular AUPRC or wall-time margin" | [Maintainer claim, High] |
| 7 | No GitHub Actions; validation is owner-local via `scripts/ci-local.sh` | demonstrated | `ci/github-actions-disabled/ci.yml.disabled`: "Disabled intentionally: this repository is validated on owner-controlled machines." No `.github/` directory. Consequence: the [CI-observed] evidence tier is structurally unattainable; third parties cannot observe greenness | [Code-verified, High] |
| 8 | 173 `#[test]` attributes across the workspace; tests never executed in this assessment | demonstrated (existence); execution status unestablished | `grep -c` over `crates/`; `tests/` dirs in 5 of 6 crates (`fo-core` uses inline unit tests). Not compiled or run — toolchain is pinned `nightly-2026-08-31` and the workspace was not built | [Counted, High] |
| 9 | Optional FrankenSciPy FFT backend, commit-pinned | demonstrated | `fo-core/Cargo.toml`: `fsci-fft = { git = "https://github.com/Dicklesworthstone/frankenscipy", rev = "2da83a7f42280d517241d6d2874d4ba9ebc2484c", package = "fsci-fft", optional = true }`; present in `Cargo.lock`. AGENTS.md invariant 10 reserves general FFT primitives to FrankenSciPy | [Code-verified, High] |
| 10 | asupersync is not a dependency | demonstrated | Absent from `Cargo.lock` (250 packages searched); no reference in any manifest | [Counted, High] |
| 11 | Project Gutenberg and SEC 10-K acquisition with SHA-256 manifests, source URLs, byte ranges | demonstrated (code); execution unestablished | `fo-corpus` modules (`gutenberg.rs`, `sec_filings.rs`, `sec_facts.rs`, `sec_fact_analysis.rs`) + bins (`fo-collection`, `fo-sec-fetch`, `fo-section`) verified present; `docs/CORPUS_ACQUISITION.md` read. No downloaded corpora or manifests checked in; the acquisition paths were not executed | [Code-verified, High] |
| 12 | Native PAN XML evaluation (PlagDet, granularity) without Python/NumPy | demonstrated (code); no PAN13 run checked in | `fo-bench` `fo-pan` bin + `pan_metrics.rs` verified present; `docs/PAN_EVALUATION.md` documents PAN13 task semantics and links the Zenodo corpus archive. No detection outputs or scores in the tree | [Code-verified, High] |
| 13 | "Ultra-fast" framing retracted from README; GitHub repo description still carries it | demonstrated (drift) | Current README headline: "Explainable textual provenance, edited-passage retrieval, approximate alignment, and hybrid lexical search in safe Rust" [Verified, High]. A 37-day-old search-engine crawl of the README shows the earlier headline "Ultra-fast textual-overlap retrieval, approximate alignment, and source attribution in safe Rust" [External, Medium]. The GitHub API `description` field still reads "Ultra-fast sparse-spectral textual overlap detection and approximate alignment in safe Rust" [External, High] — the front-page marketing outlived the retraction | [Verified + External, Medium-High] |
| 14 | License rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use — including benchmarking, testing, analyzing, indexing, and training-data incorporation; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |
| 15 | Sole human maintainer; 347 commits in 21 days (2026-08-14 → 2026-09-04); only 4 agent Co-Authored-By trailers | demonstrated | Deepened history (blobless): 329 + 7 + 6 + 5 commits across three Jeff Emanuel identities = 347; `grep -ci co-authored-by` = 4 | [Git-observed, High] |
| 16 | No releases, no tags; 22 stars, 3 forks, 0 open issues; zero independent coverage | demonstrated | GitHub API 2026-09-22: 22 stars, 3 forks, 0 open issues, 0 releases; web search returned only the repo itself and its own commits [External, High within recall caveats] | [External, High] |
| 17 | `COMPREHENSIVE_PLAN_FOR_FRANKEN_OVERLAP.md` (15,387 bytes) describes a hardware-adaptive engine for "corpora ranging from one large document to multi-terabyte archives" with "profile-proven execution on high-core-count CPUs and Apple-Silicon GPUs" | aspirational (target-state planning doc, not current capability) | Plan doc read at pin; current code has no multi-terabyte indexing evidence, no GPU path (AGENTS.md invariant 9 reserves GPU FFI to FrankenTorch's boundary), and no checked-in scale benchmarks | [Maintainer claim, High] |

**What the inventory says in aggregate:** claims about *machinery* (claim gates, evidence bundles, fail-closed parsing, zero-unsafe posture) verify at High confidence against the code; claims about *outcomes* (beats baselines, works on real corpora, SEC acquisition in production) are either explicitly disavowed by the maintainer or have no checked-in artifact. The repo's honesty about this gap is its most verified property.

## 4.4 Codebase tour

**Workspace topology (6 members, [Counted, High]):** `fo-core`, `fo-cli`, `fo-corpus`, `fo-bench`, `fo-conformance`, `franken-overlap`.

**Dependency posture:** 250 packages in `Cargo.lock` [Counted, High]. The default `fo-core` tree is pure Rust (rayon for parallelism, serde/serde_json, thiserror, unicode-normalization, unicode-segmentation). C-linked crates (`cc` via `aws-lc-sys`/`ring`/`blake3`/`cmake`) enter only through non-core crates — principally `fo-corpus`'s `reqwest` (blocking, TLS) for SEC/Gutenberg downloads — so the README's "default core" qualifier is load-bearing and accurate [Code-verified, High]. The one cross-FrankenSuite dependency is the optional, git-rev-pinned `fsci-fft` from frankenscipy (claim 9); asupersync is absent (claim 10).

**Data flow, end to end (reconstructed from code, [Code-verified, Medium] — modules and APIs read, behavior not executed):**

- **Normalize — `fo-core/src/normalize.rs` + `provenance.rs`:** Unicode normalization (NFKC-family via `unicode-normalization`) with explicit punctuation/whitespace policies, plus provenance-preserving normalization that maps every normalized token back to original UTF-8 byte ranges — the load-bearing primitive for "exact evidence that can be highlighted" (span evaluation in original coordinates, used by `fo-pan`).
- **Fingerprint — `fingerprint.rs`, `winnow.rs`:** character/token q-grams hashed to 128-bit rolling fingerprints, rightmost-minimum winnowing selects rare features. The categorical doctrine is enforced structurally: token IDs are never correlated as numbers.
- **Index — `index.rs`, `storage_v2.rs`, `segmented.rs`:** defensive immutable `.foidx` format, v2 with checksums, document/position delta-varint posting lists, automatic v1/v2 loading; segmented indexes with append-only generations, stable 64-bit doc IDs, atomic tombstones, compaction. Fail-closed: malformed magic, unknown versions/flags, unsorted dictionaries, invalid postings, inconsistent doc frequencies, impossible sizes, and trailing bytes are rejected [Maintainer claim, High — `VALIDATION.md`; the trailing-bytes case has a conformance test].
- **Retrieve — `search.rs` (938 lines), `chain.rs`:** rare-first positional postings → two shifted diagonal grids for `corpus_position − query_position` votes (bin-boundary failure reduction) → monotone anchor chaining with drift/gap penalties → bounded exact verification (exact Myers bit-vector infix for short specimens; band-local semi-global DP with geometric widening for longer candidates; KMP linear exact fallback). Approximate candidates never bypass exact textual verification [Maintainer claim, High — AGENTS.md invariant 2; code structure consistent].
- **Composite — `composite.rs`:** groups passage hits by source document, selects non-overlapping blocks adding new specimen coverage, measures union coverage, detects reordered blocks — the fragmented/reordered-reuse story.
- **Lexical/hybrid — `lexical.rs` (1,405 lines), `hybrid.rs`, `multiview.rs`:** fielded BM25 + phrase + proximity; multi-view q-gram consensus (short/balanced/selective scales, cross-view agreement as a precision signal); explainable hybrid fusion with per-decision evidence in human-readable output.
- **Dense route — `spectral.rs`, `semantic.rs`:** below a configured work crossover, dense scan computes *exact positional equality* (not sketch correlation); above it, the optional FrankenSciPy path uses unit-circle phase-sketch FFT correlation with independently signed CountSketch channels so unequal categories cancel in expectation. The dense path is for unindexed text or all-offset scoring; sparse is the default for repeated queries.
- **Learning/deployment — `calibration.rs`, `ap_ranker.rs`, `active_learning.rs`, `review.rs`, `hybrid_profile.rs`, `grouped_metrics.rs`:** logistic calibration, query-grouped AUPRC (area under the precision–recall curve), AP-delta listwise ranking, active-learning review queues, append-only experiment ledger, atomic corpus-specific profile promotion — training, evaluation, claim support, and deployment promotion kept as separate operations.
- **Contracts — `contracts.rs` (1,762 lines), `contract_diff.rs` (1,487 lines), `domain*.rs`, `lineage.rs`:** the SEC/contract-intelligence layer — filing-item analysis, contract version portfolios, lineage graphs. The largest single-topic code mass in `fo-core`, which is notable: the "product" code (contracts/lineage) outweighs the core retrieval code it depends on.
- **CLI — `fo-cli` (19 bins [Counted, High]):** orchestration only per AGENTS.md (no duplicate matching logic — a stated invariant, spot-checked consistent [Code-verified, Low — not exhaustively verified]).
- **Corpus — `fo-corpus`:** Gutenberg + SEC 10-K/companyfacts acquisition with manifests (URLs, digests, byte ranges), sectioning strategies.
- **Bench — `fo-bench` (17 bins):** the courtroom — scenario generation (`fo-showcase`), real-corpus bench, exhaustive Levenshtein control, adjudication, claim gates, evidence suite, proof reports, PAN runner, hybrid tuning, group eval, active learning.
- **Facade — `franken-overlap`:** stable public API re-exporting the hybrid index builder/search (the README's Rust example) plus a 32-line public-API test and an `examples/basic.rs` end-to-end example (index one document, query a paraphrase, print scored hits) [Code-verified, High].

**Scale notes (per-crate first-party lines, [Counted, High]):** `fo-core` 20,618 (38 files); `fo-bench` 18,012 (38 files); `fo-cli` 10,833 (26 files); `fo-corpus` 8,031 (18 files); `fo-conformance` 183 (2 files); `franken-overlap` 66 (3 files). Two readings: the evaluation courtroom (`fo-bench`) is 87% the size of the engine it judges (`fo-core`) — the project's mass is split almost evenly between doing and proving. And within `fo-core`, the single largest files are domain-specific (`contracts.rs` 1,762, `contract_diff.rs` 1,487, `lexical.rs` 1,405) rather than the retrieval kernel — the application layer is growing faster than the engine it depends on, while the engine's core claim is unproven [Inference, Medium — a file-size observation, not a behavior measurement]. 173 `#[test]` attributes exist but were never executed in this assessment; with GitHub Actions disabled, no external party has an observable greenness signal either.

## 4.5 The maintainer's stated case

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

1. **Differentiated problem:** not "which documents discuss this topic" but "where did this passage come from, how much survived, what changed, was it fragmented or reordered, and what exact source evidence supports the answer" (README, verbatim structure) [Maintainer claim, High].
2. **The portfolio:** sparse indexed path (winnowed rare fingerprints → shifted diagonal votes → anchor chains → bounded exact verification), dense unindexed path (exact equality below crossover, phase-sketch FFT above), and an ordinary-search path (fielded BM25 + proximity → explainable hybrid fusion) [Maintainer claim, High].
3. **Categorical correctness as doctrine:** token/code-point/BPE IDs are categorical labels; the engine never correlates raw numeric magnitudes as similarity. The dense path's independently-signed CountSketch channels exist precisely so unequal categories cancel in expectation [Maintainer claim, Medium].
4. **Evidence-gated claims:** "Public speed or quality claims require a checked-in evidence bundle with corpus, query, commit, compiler, hardware, baseline, quality, span, latency, and uncertainty receipts. Until those conditions are met, superiority claims are hypotheses rather than project facts." (README, "Correctness and performance doctrine") [Maintainer claim, High].
5. **The disavowal — quoted and located precisely:** README "Empirical status" section: *"What `main` does **not** yet contain is a completed real-corpus evidence run with pinned corpus receipts and numerical results. Therefore this README does not claim that FrankenOverlap has already beaten BM25, exact search, Jaccard, SimHash, or exhaustive edit-distance retrieval by a particular AUPRC or wall-time margin."* And `docs/EMPIRICAL_STATUS.md`: *"FrankenOverlap is a substantial and testable specialized search system whose comparative advantage is plausible, but not yet empirically established in the repository."* [Maintainer claim, High]. There is no benchmark table to disavow — the disavowal is pre-emptive, which is the point.

**Benchmark reproduction cost:** there is no benchmark table in this packet — deliberately. The Rulebook requires maintainer-vs-independent number tables; here both columns are empty, and that emptiness is itself the central finding (§4.7.1). The cost of producing the *first* numbers is honest to state: checking out the pin, installing the pinned `nightly-2026-08-31` toolchain, downloading Gutenberg/SEC corpora (network + SEC identity declaration), generating showcase scenarios, and running `fo-evidence-suite` — a multi-hour, network-dependent procedure with no checked-in expected output to compare against [Inference, Medium]. The honest statement: there is currently nothing to reproduce.

---

## 4.6 Competitors

**Why the incumbents win today, in one paragraph:** nobody is waiting for this. General search is owned by Lucene/Elasticsearch (distributed, managed, free); commercial plagiarism detection is owned by Turnitin/iThenticate (institutional contracts, proprietary fingerprint corpora — the moat is distribution and data, not algorithms); semantic paraphrase is owned by embeddings; and the academic version of exactly this task (the PAN/CLEF text-alignment competitions — the repo's docs reference the PAN 2013 task) already published participant scores that FrankenOverlap has not measured itself against. The README correctly cedes the first three lanes and names the fourth's metric without entering the competition [Maintainer claim, High]. FrankenOverlap's only uncontested edge is its auditability apparatus (evidence-gated claims, paired bootstrap verdicts, exact-span provenance), which no competitor bothers with because no buyer currently demands it [Inference, Medium].

- **Lucene / Elasticsearch / OpenSearch:** own general full-text search (BM25, distributed, managed). Not passage-alignment tools; the README correctly declines to compete with them [Inference, Medium].
- **Turnitin / iThenticate (proprietary):** own the commercial plagiarism-detection lane with institutional contracts and proprietary fingerprint databases. FrankenOverlap's auditable-evidence angle is a theoretical wedge; Turnitin's moat is distribution and corpus, not algorithms [Inference, Medium].
- **Classic near-duplicate machinery — SimHash (Charikar 2002), MinHash, winnowing (Schleimer–Wilkerson–Aiken 2003), ssdeep/TLSH:** the algorithmic ancestors. Winnowing in particular is direct prior art for the fingerprinting stage; the repo's contribution is the portfolio around it (diagonal voting, chaining, verification, claim-gating), not the winnow itself [Inference, Medium].
- **PAN/CLEF text-alignment competitions:** the academic home of exactly this task — passage-level plagiarism detection scored by the PlagDet metric (PAN's combined precision/recall/granularity score, which the repo reimplements natively) — its docs reference the PAN 2013 task and link the public corpus archive. Published participant scores are the natural external yardstick the repo has not yet measured itself against [External, Medium — PAN is well-documented; only the 2013 reference is verified in-repo].
- **Bioinformatics sequence alignment (BLAST, minimap2-style seed-chain-extend):** the algorithmic ancestor of the anchor-chaining stage — rare seeds, diagonal chaining with gap penalties, exact extension — developed for DNA, where the alphabet is tiny and the corpora are enormous. FrankenOverlap's move is transplanting that architecture onto normalized human text with exact verification and claim-gating wrapped around it. Nobody in bioinformatics wants this lane (wrong alphabet, wrong problem), and nobody in text retrieval has productized it with auditability — which is why the lane reads as unoccupied rather than merely adjacent [Inference, Medium].
- **Vector databases / embedding retrieval:** own "pure semantic paraphrase," which the README explicitly cedes ("embeddings or another semantic retriever" is the natural first choice; FrankenOverlap's role is textual verification *after* semantic candidates) [Maintainer claim, High]. Correct scoping.
- **diff-match-patch / Myers / direct edit distance:** own the one-short-pair case; the README cedes it ("indexing is unnecessary") [Maintainer claim, High].
- **Unoccupied lane:** an open, safe-Rust, *evidence-gated* textual-provenance engine — edit-tolerant passage retrieval where every accepted match carries exact span evidence and every performance claim carries a checked-in proof bundle — has no direct occupant. Turnitin is closed, PAN systems were research prototypes, Lucene is the wrong tool [Inference, Medium]. Whether any buyer will pay for auditability over convenience is the unproven bet the whole project rests on.

## 4.7 Skeptic's take

*Citation convention: weaknesses are numbered 1–7 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 courtroom has held no trial.** Every load-bearing claim about the engine — beats BM25/Jaccard/SimHash/exhaustive edit distance on edited-passage retrieval — is explicitly a hypothesis. The evidence machinery is demonstrated; the evidence is absent. A benchmark harness without a benchmark result is a test lab, not a product, and the "substantial implementation" could be 57,743 lines of well-organized speculation [Inference, High].
2. **[HIGH] No CI anyone can observe.** GitHub Actions is deliberately disabled; validation runs on "owner-controlled machines" via `scripts/ci-local.sh` [Code-verified, High]. The 173 counted tests may be green, red, or stale — no third party can tell, and this assessment did not execute them. A project whose pitch is *auditability* with no observable audit trail is a structural contradiction [Inference, High].
3. **[HIGH] Bus factor 1, no release, 18 days quiet.** 347 commits in 21 days by one human, then silence from 2026-09-04 to the 2026-09-22 assessment; zero releases, zero tags, 22 stars, 3 forks [Git-observed + External, High]. The velocity that built it is the same single point of failure that can abandon it. There is no artifact a third party can evaluate *as the product* — only a repository to audit as a *process*.
4. **[MEDIUM] Conformance is fixture-scale.** Eight tests over five documents / 28 KB, with hand-tuned thresholds (`minimum_similarity: 0.24`, `combined_score > 0.45`) [Code-verified, High]. The "behavioral, persistence, and corruption contracts" label is accurate in kind but not in scale — nothing here exercises a real corpus, adversarial inputs beyond one appended byte, or the segmented/contract-lineage layers.
5. **[MEDIUM] Breadth before proof.** 52 docs (5,633 lines [Counted, High]), 19 CLI bins and 17 bench bins [Counted, High], and — the sharpest number in the packet — `fo-bench` at 18,012 lines versus `fo-core` at 20,618: the evaluation apparatus is 87% the size of the engine it has never evaluated. Meanwhile the largest files in `fo-core` are the contract-intelligence application layer, not the retrieval kernel. This is the classic mile-wide-inch-deep risk: every new surface is another unproven claim [Inference, Medium].
6. **[MEDIUM] The rider amputates the most plausible users.** Training-data provenance and dataset deduplication are listed applications [Maintainer claim, High] — and the rider bars OpenAI, Anthropic, their affiliates, and anyone acting for them from use, benchmarking, analysis, or training-data incorporation [Code-verified (license text), High]. The labs that most need "what was my model trained on" tooling may not touch it. The exclusion is targeted rather than total (non-restricted parties may still adopt), but it selects against the deepest-pocketed evaluators [Inference, Medium].
7. **[LOW] The front page still says "ultra-fast."** The README retracted "ultra-fast" (claim 13) — an honest edit — but the GitHub repo description, the first thing a visitor reads, still markets "Ultra-fast sparse-spectral textual overlap detection." Stale marketing on the landing page of a project whose brand is honesty [External, High].

**Bear-case steelman (strongest counter-case):** FrankenOverlap is a benchmark-harness project wearing an engine costume. Its most-used artifact will be the evaluation workbench (claim gates, adjudication, evidence bundles) — genuinely good methodology — while the engine itself remains an untested hypothesis that its own author won't assert. Turnitin owns plagiarism commercially, Lucene owns search, embeddings own paraphrase, and the README cedes all three lanes; the remaining lane (auditable passage provenance) has no demonstrated buyer. One maintainer, no CI signal, no release, 18 days of silence, and a license that forbids the AI labs from the training-data-provenance use case. The rational response is to extract the claim-gating methodology and wait for the evidence run that may never come. Its most likely end state is a frozen monument to how to *test* a search engine, without ever shipping one. [Inference, Medium — deliberately uncharitable; the counter-evidence is the build velocity and the pre-emptive honesty, both documented above.]

## 4.8 Maintenance & succession

**Bus factor: 1.** One human maintainer (Jeff Emanuel); all 347 commits in the full fetched history are his, across three email identities [Git-observed, High]. Only 4 commits carry agent Co-Authored-By trailers — this repo is overwhelmingly hand-written, which strengthens the "clean" authorship story relative to agent-heavy siblings but concentrates all knowledge in one head. No succession plan, no second committer, no foundation, no CONTRIBUTING.md governance beyond a 1 KB file, zero releases to fork from [Inference, Medium — absence of evidence across assessed materials; the no-release half is External, High]. If the maintainer stops, the project freezes at the last commit [Inference, High].

**License and governance (material):** the LICENSE is MIT plus the FrankenSuite OpenAI/Anthropic rider — **non-OSI** [Code-verified (license text), High]. The rider's exact scope, quoted: "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)." "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 "automatically and immediately terminates" the license. As strategy: the rider excludes exactly the two labs (plus their supply chains) best equipped to evaluate, adopt, or acquire textual-provenance tooling — and it excludes them from the *training-data provenance* application the README advertises. Whether that is principled leverage or self-sabotage depends on a theory of the maintainer's goals that the repo does not state; as an adoption ceiling it is unambiguous [Inference, Medium].

**Governance signals:** commit velocity (~16.5/day over 21 days) then an 18-day full stop with no explanation — the Rulebook's staleness rule cuts both ways here: it is evidence about governance (a sprint-and-pause cadence), not necessarily decay, but there is no roadmap note explaining the pause [Inference, Medium]. Minor doc-vs-config drift: `VALIDATION.md` describes "the moving latest Rust nightly toolchain declared in `rust-toolchain.toml`," but the file pins `nightly-2026-08-31` — a dated nightly, not a moving channel. The `FO_UPDATE_NIGHTLY=1` mode of `scripts/ci-local.sh` suggests the pin is advanced deliberately before merges/releases, so practice governs, not prose; but a reader expecting rustup to track latest will be surprised [Code-verified, High on the file contents; the workflow reading is Inference, Medium]. Review depth is zero by construction: a single committer means no pull-request review exists as a process, whatever the commit-message discipline suggests [Inference, High]. The disabled-CI decision is documented and deliberate (owner-controlled validation), which trades third-party observability for maintainer control — defensible for velocity, costly for trust [Inference, Medium]. `SECURITY.md` (1 KB) and `CONTRIBUTING.md` (1 KB) exist but are minimal.

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | TRL 4 | Core retrieval, verification, and claim-gating components are implemented and unit-tested at fixture scale — past TRL 3 (analytical proof-of-concept), because the components exist as running code with contracts, not just equations. Not TRL 5 (validation in a relevant environment), because no real-corpus evidence run exists and the comparative claim is explicitly unproven. [Inference, Medium] |
| Strategic relevance | 3/5 | Textual provenance (plagiarism, contract lineage, training-data dedup) is a real, agent-era-relevant problem; but the repo cedes search, paraphrase, and one-pair alignment to incumbents, narrowing the lane. [Inference, Medium] |
| Impact potential | 3/5 | If the evidence run lands, an open auditable provenance engine fills an unoccupied lane; the methodology export (claim gates) has independent value even if the engine fails. [Inference, Medium] |
| Implementation feasibility | 4/5 | It is already implemented: 57,743 lines, a stable facade crate, and a documented build path — adoption cost is integration and evidence, not construction. [Counted + Inference, Medium] |
| Time to mainstream | 2/5 | Needs the first evidence run, a release artifact, observable CI, and a second maintainer — none on a visible timeline; 18 days quiet. [Inference, Medium] |
| Collaboration potential | 2/5 | Bus factor 1, no CONTRIBUTING governance, and the rider excludes the AI labs most likely to collaborate on provenance tooling. [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. Rulebook assignment: *Explore* is the default for substantive-but-unproven; *Pilot* requires a release artifact plus a bounded real-workload fit — there are zero releases and no completed evidence run, so Pilot is out of reach; *Monitor* is for websites and plan-stage work, which undersells 57,743 lines of tested implementation. When in doubt, ring down: Explore, with the rider and the missing evidence run as the advancement blockers.

## 4.10 Wardley placement

- **Commodity surface** (high on the value chain, bought not built): BM25 ranking, q-gram fingerprinting/winnowing, Unicode normalization, SHA-256 manifests, bootstrap confidence intervals — established techniques, correctly treated as infrastructure. *What moves it:* the repo deleting its own reimplementations — the hand-rolled PAN evaluator (`pan_metrics.rs`, which duplicates a published reference evaluator) is the concrete candidate for replacement by an upstream crate.
- **Custom-built reimplementation** (the product): the passage-alignment portfolio — shifted diagonal voting, monotone anchor chaining with drift penalties, composite fragmented-source aggregation, multi-view q-gram consensus, bounded exact verification — plus the SEC/contract-intelligence application layer. *What moves it:* a checked-in `fo-evidence-suite` run moves it up (a `supported` claim-gate verdict is proven differentiation) or down (an `unsupported` verdict is falsification); continued silence moves it toward abandonment regardless of merit.
- **Genesis-stage novel elements:** the evidence-gating methodology — preregistered claim manifests, paired-bootstrap `supported`/`inconclusive`/`unsupported` verdicts, natural-label adjudication, immutable proof bundles, the "incomplete, not extrapolated" rule — built *before* any claim it could gate. *What moves it:* adoption as the FrankenSuite's benchmark-claim standard moves it to product; if it only ever gates its own unmade claims, it stays a curiosity.

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

**[Inference]** — everything in this section is analyst judgment.

**Base case (12 months):** the evidence run either lands or it doesn't, and that binary dominates. If it lands with `supported` verdicts on edited-passage retrieval, the repo graduates from "honest hypothesis" to "credible specialized tool" and the SEC-lineage pilot becomes fundable work; if it lands `unsupported`, the engine is pruned and the workbench survives as the artifact. If no run materializes, the 18-day silence extends into archival stillness — 22 stars do not sustain a one-maintainer project through a quiet winter.

**Bifurcation:** *Upside* requires three observables in sequence: (1) a checked-in `fo-evidence-suite` run with non-trivial `supported` verdicts; (2) a PAN13 PlagDet score competitive with published participant results — the first external validation; (3) a tagged release plus observable CI (or a documented reason CI stays local). Any one of these would justify re-ringing toward Pilot. *Decay* looks like: the pause continues, the nightly pins rot (`nightly-2026-08-31` ages, `fsci-fft` rev drifts from upstream), the GitHub description keeps saying "ultra-fast," and the repo becomes a well-documented hypothesis nobody runs.

**24 months:** either a niche-but-real tool in the plagiarism/lineage space with a second maintainer and a release line, or a frozen reference implementation mined for its claim-gating methodology. The middle path — perpetual "promising" without evidence — is unstable; honesty without results has a half-life.

**60 months:** the methodology export is the durable asset. Preregistered claim manifests with bootstrap verdicts and immutable proof bundles are a portable discipline that outlives any single engine; if the FrankenSuite adopts it as standard, this repo's legacy is process, not product. The engine itself, if validated, occupies a durable niche (auditable provenance is a regulatory-shaped demand); if not, it joins the archive of good ideas with no benchmark.

**Revisit triggers (concrete, observable):** (1) first checked-in evidence run with claim verdicts — re-ring candidate; (2) PAN13 PlagDet score published — first external validation; (3) first tagged release — Pilot prerequisite; (4) GitHub Actions re-enabled or a public CI signal — restores the [CI-observed] tier; (5) second human committer — bus-factor repair; (6) 90 more days of silence with no commits — decay confirmation, consider Monitor.

## 4.12 Limitations and open questions (mandatory)

**What was not done:** the workspace was never compiled (`cargo build`/`cargo check` not run — pinned toolchain `nightly-2026-08-31` not installed here); no test suite was executed (the 173 counted tests' pass/fail status is unestablished, and with CI disabled there is no external greenness signal either); no benchmark was run or reproduced; no Gutenberg/SEC corpus was downloaded and the acquisition paths were not exercised; the `fo-evidence-suite` was not executed; `fo-pan` was not run against PAN13; web search was the only external-validation attempt (recall caveats apply — non-indexed coverage such as private deployments would not appear).

**Open questions that would most change the verdict:**
1. Do the 173 tests pass at the pin? (A local `scripts/ci-local.sh quick` run answers this; greenness is currently asserted by no observable party.)
2. What does the first `fo-evidence-suite` run actually conclude — `supported`, `inconclusive`, or `unsupported` on the core edited-passage claim?
3. Has the SEC/Gutenberg acquisition code ever successfully run end-to-end, or is it untested against the live providers?
4. Why the 18-day silence — pause, pivot, or abandonment? (Only the maintainer can answer; the commit history gives no signal.)
5. Is the "ultra-fast" GitHub description stale oversight or a retained marketing claim the README no longer supports?
6. Would the maintainer accept a PR re-enabling GitHub Actions, or is local-only validation a permanent governance choice?

---

## The eight deepening questions

**1. Provenance.** The system records extensive provenance about *text*: provenance-preserving normalization maps every token to original UTF-8 byte ranges, index manifests retain source URLs, provider snapshots, SHA-256 digests, and exact parent byte ranges, and evidence bundles pin corpus, query, commit, compiler, and hardware receipts [Code-verified + Maintainer claim, High]. What it does not record is provenance about *itself*: no signed artifacts, no release attestations, no CI provenance (there is no CI), and the evidence bundles' "commit receipt" is only as trustworthy as the local machine that ran the suite. Making attestation portable would require exactly what §4.11's revisit triggers name: a release artifact with signed provenance (e.g. Sigstore-style signing of bundles) plus an observable build/test trail — the machinery for *what* to attest exists; the *who ran it, on what* half is entirely local-trust [Inference, High].

**2. The embeddable unit.** The smallest useful piece is `fo-core`'s sparse overlap pipeline as a library — `IndexBuilder`/`Index` plus `search` with the winnow→vote→chain→verify portfolio — or even narrower, the `normalize_with_provenance` + `winnow` + `chain_anchors` functions as composable primitives, all behind the `franken-overlap` facade crate [Code-verified, High on existence]. Adoption cost: a Cargo dependency on a 20,618-line crate with a nightly-only toolchain (`nightly-2026-08-31`), the MIT+rider license (non-OSI — legal review required, and AI-lab users excluded outright), and API instability (0.1.0, no stability commitments, facade is thin). The PAN evaluator (`pan_metrics` + `fo-pan`) is arguably the more adoptable unit: a self-contained, dependency-light correctness oracle for text-alignment work with no engine commitment [Inference, Medium].

**3. Unexercised option value.** The architecture holds several capabilities it hasn't used: the segmented index (append-only generations, tombstones, compaction) is built for growing corpora nobody has grown; the FrankenSciPy FFT path is wired behind a feature flag with no reported runs; the active-learning, calibration, and AP-delta ranking stack is a full learning-to-rank loop with no trained profile checked in; the contract/lineage layer (3,249 lines across `contracts.rs`/`contract_diff.rs`) is an application awaiting its first real filing. What unlocks them is the same single event: the first real-corpus evidence run, which would exercise segmentation at scale, justify tuning the ranker, and give the lineage layer real filings to chew on [Inference, Medium].

**4. Benchmark honesty.** There are no maintainer benchmark numbers to audit — the honesty story here is pre-emptive rather than retrospective. The numbers that *would* need to survive an independent rerun, if claimed, are: edited-passage AUPRC/Recall@k deltas vs. BM25/Jaccard/SimHash/exhaustive Levenshtein, p50/p95/p99 latencies, index build time/size, and break-even query counts — all listed as required bundle contents in `docs/EMPIRICAL_STATUS.md` [Maintainer claim, High]. The load-bearing thesis is the *quality* delta on long edited/fragmented/reordered passages, not speed: the "ultra-fast" framing was already retracted from the README, so speed claims are not load-bearing — retrieval-quality claims are. The methodology's own safeguards (identical candidate universes, query-grouped bootstrap CIs, "incomplete not extrapolated" for over-budget baselines, preregistered claim manifests) are designed to make the eventual numbers rerun-survivable; whether they are is untested [Inference, Medium].

**5. The governance path.** The credible route from one maintainer to an institution runs through the evidence run: a checked-in `supported` verdict is the only asset that converts this from a personal project into something a lab, publisher, or archive would adopt or fund — adopters follow proof, not promises. What breaks first if velocity decays is the nightly toolchain pin and the git-pinned `fsci-fft` rev (both rot without maintenance), followed by the SEC acquisition code (provider APIs drift), while the pure-Rust core (`fo-core` default deps) decays slowest [Inference, Medium]. The 18-day silence is the live experiment in this question; the answer is not yet in.

**6. The license as strategy.** The rider excludes OpenAI, Anthropic, their affiliates, and anyone acting for them — from use, benchmarking, testing, analyzing, indexing, and training-data incorporation — with automatic termination on breach [Code-verified (license text), High]. For a project advertising *training-data provenance* and *dataset deduplication* as applications, excluding the two labs that train the largest models is strategically perverse: it bars the evaluators with the strongest incentive to validate the tooling and the deepest pockets to fund it. It serves the mission only under a theory where the maintainer's goal is leverage or principle over adoption — a theory the repo never states. As sabotage-of-adoption it is unambiguous; as strategy it is inscrutable [Inference, Medium].

**7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is *provenance verification in agentic research pipelines*: an agent that drafts from sources (or is suspected of unattributed reuse) needs "which exact spans came from which source, with byte ranges" — embeddings can't supply that, Turnitin is closed and per-seat, and Lucene is the wrong primitive. FrankenOverlap's normalized-token→original-byte-range provenance plus exact verification is built for exactly this audit step. What has to become true first: the evidence run (agents shouldn't trust an unproven retriever), a stable API with language bindings (agents live in Python), and a service or WASM-embeddable form (the `fo-serve` bin exists — `SERVICE_API.md` documents it — but with no deployment evidence) [Inference, Medium].

**8. The kill test.** The single experiment that falsifies the core thesis: run the checked-in `fo-evidence-suite` on the Gutenberg showcase corpus and have `fo-claim-gate` return `unsupported` on the preregistered claim "FrankenOverlap sparse alignment beats fielded BM25 + phrase + proximity on edited-passage AUPRC." The maintainer built the guillotine himself — preregistered verdicts, bootstrap CIs, identical candidate universes — which is why the kill test is credible: it is the project's own machinery, and a negative result would be checked in, not buried [Inference, High]. The competitor move that kills it commercially: Turnitin or iThenticate shipping an auditable-evidence API, collapsing the one unoccupied lane into a feature of the incumbent [Inference, Low — speculative, but named as the commercial kill vector].