FrankenOverlap A Search Engine With a Courtroom and No Trial

01 · What it is

What the problem is, and why it matters

Keyword search answers one question: which documents are about this topic. A different question goes unanswered: where did this passage come from? Paste a paragraph into a search box and it will tell you the topic. It will not tell you the paragraph was lifted from a contract signed in 2021, edited in three places, chopped into pieces, and rearranged.

The second question matters in more places than you might think. Plagiarism investigators live on it. Publishers comparing editions of a book need it. Lawyers tracking how a clause evolved across contract versions need it. Archivists recovering scanned text with recognition errors need it. And in the last few years a new customer showed up: AI labs trying to answer "what was my model trained on," also known as training-data provenance. The academic version of this task has run for years as the PAN text-alignment competitions, scored by a metric called PlagDet that measures precision, recall, and how cleanly detected passages line up with the truth.

For all of this, today's tools are wrong tools used well. Keyword search (BM25) and embeddings answer "what's this about," not "which exact words survived." A similarity score is not evidence you can point at. FrankenOverlap's bet is that an engine returning exact source spans with a traceable chain of custody fills a lane that currently has no open occupant.

02 · Why build it

Why build it in Rust, from scratch

This is not a rewrite. There is no original product being ported. It is clean-room: no fork, no port, no inherited codebase. Jeffrey Emanuel, the solo developer behind the whole FrankenSuite, gives his reasons in the README and design docs. They come in three parts.

First, the problem is different. Lucene, Elasticsearch, and vector databases answer "which documents discuss this topic." Edited-passage retrieval needs "which exact source spans survived, what changed, and what evidence supports the answer." No general search library ships the alignment portfolio (fingerprinting, diagonal voting, anchor chaining, exact verification) that this task needs, so he built it.

Second, the safety posture fits the use case. The engine is built to take untrusted corpora (random documents, SEC filings, scanned archives), so its index format is fail-closed: malformed inputs get rejected rather than parsed. The workspace forbids unsafe code in all six crates.

Third, the auditability bet. The maintainer's wager is that exactness is not enough. Every match should carry its evidence, and every performance claim should carry its proof. So he built the proof machinery first.

The counter-argument comes from the README itself. General search is owned by Lucene and company. Commercial plagiarism detection is owned by Turnitin and iThenticate, whose moat is institutional contracts and proprietary databases, not algorithms. Semantic paraphrase is owned by embeddings. The README cedes all three lanes and declines to compete with any of them. What remains is a narrow unoccupied lane — auditable textual provenance — and nothing in the repository shows a buyer waiting in it. Twenty-two stars and three forks suggest there isn't one yet.

03 · What was built

What the project actually built

The raw facts: about 57,743 lines of Rust across six crates, written in 21 days (347 commits, mid-August to early September 2026), by one person, almost entirely by hand: only four commits in the history carry agent co-authorship trailers. The engine fingerprints text with 128-bit rolling fingerprints, keeps the rare ones (a technique called winnowing), votes along text diagonals to find candidate regions, chains the anchors together, and then verifies candidates with exact algorithms before accepting anything. A fielded BM25 keyword layer and an explainable hybrid fusion sit alongside it.

The codebase plays a joke on itself that is worth knowing. The word "unsafe" appears 18 times in 57,743 lines. Every occurrence is an error string like "unsafe corpus path," part of the path-traversal hardening. Zero unsafe blocks exist. In this project, "unsafe" is a filesystem concept, not a language one.

More interesting than the engine is the evidence machinery, which takes up nearly half the project's mass. A claim gate takes preregistered claim manifests and returns verdicts of supported, inconclusive, or unsupported, computed with paired bootstrap statistics. A natural-label adjudication module settles disagreements between label sources. An evidence suite emits immutable proof bundles: corpus, query, commit, compiler, hardware, baseline, quality, span, latency, and uncertainty receipts. The README's rule is explicit: no public speed or quality claim without a checked-in evidence bundle. Until those conditions are met, superiority claims are hypotheses, not project facts.

And the README says, in plain text, that the conditions have never been met: "this README does not claim that FrankenOverlap has already beaten BM25, exact search, Jaccard, SimHash, or exhaustive edit-distance retrieval by a particular margin." There is no benchmark table to disavow. The disavowal is pre-emptive, which is the point.

04 · Where it stands

Where it stands

In our program's terms: TRL 4, NODUS ring Explore. In plain English: the components exist as real code with real test contracts, but the core claim has never been tested against a real corpus, and the comparative advantage is explicitly a hypothesis.

What would change the verdict, in order

05 · What it teaches

What this teaches about building with agents

Here is the transferable lesson, and it is not about search at all.

This repository was built in 21 days by one person. The natural failure mode of that kind of velocity (human or agent-assisted) is confident claims with no basis: benchmarks that flatter, tables that drift. The maintainer's answer was to build the referee before playing the game: the claim gate, the evidence bundle, the adjudication module, and the README rule that nothing is a fact until the bundle exists. source He wrote the disavowal before he had anything to disavow.

Most projects discover they need evidence machinery after a claim blows up in public. FrankenOverlap installed the machinery before making a single claim. The lesson for anyone building with agents: do not wait for a false claim to build your claim-gating. Write the rules for what counts as proof first, in code, with gates that are allowed to say "unsupported." Then let the machinery judge your own work before anyone else does. The engine is unproven. The discipline of refusing to claim it works is already proven by example.