# FrankenMermaid — Technical Due-Diligence Assessment

**The hook:** A 258,093-line, provably zero-`unsafe` Rust Mermaid engine that renders the 2,000–10,000-node diagrams where mermaid-js throws `RangeError` — and ships a claim-coverage audit admitting 96.4% of its own performance claims carry no same-invocation incumbent ratio.

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

## TL;DR

FrankenMermaid is a genuine, large-scale clean-room Rust reimplementation of the Mermaid diagram pipeline: 9 crates, 258,093 lines of first-party Rust (338 files), 27 diagram types, 18 layout algorithms plus Auto (verified as 19 enum variants), and four render backends (SVG, terminal, Canvas2D, WASM) fed by one shared intermediate representation. The zero-`unsafe` claim is the strongest in this program — all 9 crate roots carry `#![forbid(unsafe_code)]` and a code-level census finds zero actual `unsafe` tokens (the 29 non-comment hits are XSS-filter test names about "unsafe URLs") [Verified, High]. The most distinctive engineering is the evidence machinery: a 726-row negative-evidence perf ledger with mandatory A/A nulls and ELF-SHA-256 provenance, a claim-coverage audit that self-reports "225 KEEP claims, 8 with a live incumbent ratio — 96.4% without", and a structural-equivalence oracle (not pixel diffs) for head-to-head claims against pinned mermaid-js. **TRL 6. NODUS ring: Explore** — v0.2.0 is tagged (2026-07-11, source-only) and the WASM demo is live at frankenmermaid.com, but there is zero independent validation, no crates.io/npm publication, no registry artifact, and the argued CI-snapshot workload fit is not evidenced by any user — so under the ring-down rule this stays in Explore, with the Pilot path spelled out in §4.9. Strongest strength: the adversarial evidence discipline — the repo publishes its losses, its rejected experiments, and an audit of its own unmeasured claims. Strongest ceiling: **bus factor 1 at extreme velocity** — one human, ~3,282 commits in ~7 months, on a pinned nightly; everything else (license, benchmarks, roadmap) becomes moot if the maintainer stops. (Claim-by-claim tiers in §4.3.)

## Quick Links

- Repository: https://github.com/Dicklesworthstone/frankenmermaid
- README: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/README.md
- Negative evidence ledger: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/docs/NEGATIVE_EVIDENCE.md
- Performance ledger: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/docs/PERF_LEDGER.md
- Claim coverage audit (the 96.4% number): https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/docs/CLAIM_COVERAGE_AUDIT.md
- FNX integration contract: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/docs/FNX_INTEGRATION.md
- Crates.io publishing plan: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/docs/CRATES_IO_PUBLISHING.md
- Head-to-head dominance evidence: https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/evidence/ledger/mermaid-js-head-to-head.toml
- Head-to-head harness sources (reproduction path): https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/scripts/headtohead/
- License (MIT + OpenAI/Anthropic rider, read verbatim): https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/LICENSE
- Changelog (scope window through 2026-08-19): https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/CHANGELOG.md
- Release v0.2.0 — "Performance campaign" (published 2026-07-11, no binary assets): https://github.com/Dicklesworthstone/frankenmermaid/releases/tag/v0.2.0
- CI / Actions (pages-build-deployment only — no test workflows): https://github.com/Dicklesworthstone/frankenmermaid/actions
- Quality gates (declared, `.ci/quality-gates.toml`): https://github.com/Dicklesworthstone/frankenmermaid/blob/HEAD/.ci/quality-gates.toml
- Live showcase (WASM demo, resolves and renders; site copy stale — advertises "15 algorithms / 24 families" vs 19/27 in the tree): https://frankenmermaid.com/
- Contributors (bus factor evidence): https://api.github.com/repos/Dicklesworthstone/frankenmermaid/contributors?per_page=100

## Did you know?

The codebase hard-codes that mermaid's `flowchart` announces itself to screen readers as `flowchart-v2` — because the team measured the pinned mermaid-js 11.15.0 bundle inside Chromium 151 and found six diagram families whose ARIA `roledescription` disagrees with their syntax keywords (`flowchart`→`flowchart-v2`, `state`→`stateDiagram`, `block-beta`→`block`, `packet-beta`→`packet`, `architecture-beta`→`architecture`, every C4 variant→`c4`). The doc comment in `crates/fm-core/src/lib.rs` warns that deriving the announcement from the parser's own spelling "would have produced six wrong announcements that no rendering test could see" [Verified in code, High].

## Franken-worthy next steps

These are research directions, not engineering tickets: each is novel, specific, falsifiable, and backed by rigor this project has already demonstrated.

1. **Differential-fuzz the determinism guarantee across platforms.** The "same input + same config → byte-identical SVG" claim rests on FNV-1a golden checksums and IEEE-754 discipline, all measured on the maintainer's machines. Run the 53-pair golden suite plus proptest determinism cases across x86_64/aarch64, Linux/macOS/Windows, and WASM, and publish the hash matrix. The known risks are real: rayon work-stealing schedules, the `mimalloc` global allocator, and one `std::collections::HashSet` (RandomState) sitting in the e-graph crossing path. **Falsification:** any platform-dependent hash divergence collapses "byte-identical everywhere" to "byte-identical on thinkstation1" — and either outcome is publishable because the A/A-null discipline already exists to run it honestly.
2. **Productize the crash corpus as a vendor-neutral stress benchmark.** The seven-workload 2,000–10,000-node corpus where mermaid-js throws `RangeError` is the project's sharpest demonstrated edge, but today it lives as maintainer-run harness output. Decouple the corpus + driver + `CANNOT`-vs-`DNF` taxonomy from frankenmermaid's pipeline and invite mermaid-cli, Kroki, d2, and Graphviz to run it. **Falsification:** if the harness cannot be decoupled from frankenmermaid's fixture schema within one focused workstream, it is product scaffolding, not a method; if any incumbent completes the corpus, the "renders what the incumbent cannot" moat dies and the packet's verdict must be revised.
3. **Learn the auto-selector and publish the fidelity/cost Pareto frontier.** The layout auto-selector's loss terms are hand-tuned, and the ledger already prices one such decision (bd-di7mt: matching mermaid's flowchart layout costs +12.7% full-pipeline instructions — REJECTED on the metric). The 10,095-revision corpus plus Chromium-measured reference geometry is a supervised dataset waiting to happen: train the selector, publish fidelity-vs-instructions Pareto curves, and keep the REJECT/KEEP ledger semantics for every learned term. ("bd-di7mt" — bead IDs are the repo's `.beads` issue-tracker identifiers.) **Falsification:** if the learned policy cannot beat the hand-tuned selector on held-out revisions at equal instruction cost, hand-tuning wins and the "learned layout" thesis fails — the ledger's do-not-retry predicates make this a clean experiment.
4. **Run a human-preference Turing test on layout quality.** The structural-equivalence oracle deliberately ignores visual differences the user sees (it is geometry-typed, pixel-free) — so the packet has no evidence that FrankenMermaid's Sugiyama output is *preferred* to mermaid-js on held-out diagrams. Take the 10,095-revision Chromium corpus, render held-out pairs from both engines, and run blind human preference judgments (diagram designers + general readers) plus a task-based variant (time to extract the same information). **Falsification:** if judges prefer mermaid-js at >chance, the "fidelity to the reference" story is a metric artifact and the renderer has a quality deficit no speedup can hide; if FrankenMermaid wins, layout quality becomes a second demonstrated edge alongside the crash table.
5. **Export the claim-coverage audit as a standalone method.** The CLAIM_COVERAGE_AUDIT.md machinery — counting KEEP claims, demanding the machine-readable `**Legacy incumbent arm (same invocation):**` marker, and publishing the 96.4%-without-incumbent-ratio number — is the most transferable artifact in the repo. **Falsification:** run the audit protocol against a sibling FrankenSuite repo's perf claims; if the marker contract cannot be applied to a second codebase within one focused workstream, it is project scaffolding, not a method.

---
## 4.1 Header

| Field | Value |
|---|---|
| Repository | https://github.com/Dicklesworthstone/frankenmermaid |
| Pinned revision | `5e153c1154f18e54d04c3569e5c350804faae14e` — 2026-09-21 14:11:48 UTC (local clone HEAD == `git ls-remote` HEAD) [Verified, High] |
| Assessment date | 2026-09-22 |
| Language / toolchain | Rust, edition 2024, pinned `nightly-2026-08-31` (`rust-toolchain.toml`, wasm32-unknown-unknown target listed) [Verified, High] |
| License | MIT License **with OpenAI/Anthropic Rider** — NOT OSI open source; full text read verbatim, rider scope quoted in §4.8 [Verified, High] |
| Scale | 9 workspace crates; 258,093 Rust lines / 338 files; 2,520 `#[test]` fns in crates; 53 golden mmd+svg pairs; 3 fuzz targets with corpora [Verified, High] |
| Stars / forks / watchers | 52 / 10 / 0 (GitHub repo page, fetched 2026-09-22) [External, High] |
| Releases / tags | 1 release, 1 tag: v0.2.0, published 2026-07-11, no binary assets [Verified, High] |
| Contributors | Dicklesworthstone (3,246 contributions) + `codex` (3; account type "User", non-human status not verified — [Inference, Medium]) — bus factor 1 [Contribution counts Verified via API, High; the humanity of the named account is Inference, High] |
| Created | 2026-02-11; ~3,282 commits [External, High] |
| Maintainer | Single: Dicklesworthstone (Jeffrey Emanuel, per LICENSE copyright) — bus factor 1 [Verified, High] |
| Inception | 2026-02-11 per GitHub repo creation date [External, High] |

**Analyst method.** Fresh shallow clone of HEAD to `~/workspace/.scratch/frankenmermaid-verify/` (local HEAD verified equal to remote HEAD via `git ls-remote`). Read: README (3107 lines, fully — headers plus all claim-bearing sections), LICENSE (verbatim), `docs/NEGATIVE_EVIDENCE.md` (headers + sampled rows), `docs/PERF_LEDGER.md` (headers + contract), `docs/CLAIM_COVERAGE_AUDIT.md` (fully), `docs/FNX_INTEGRATION.md` (headers), `docs/CRATES_IO_PUBLISHING.md` (headers), `evidence/ledger/mermaid-js-head-to-head.toml` (baseline/ratios sections), `.ci/quality-gates.toml` + `perf-baseline.json` (headers), `install.sh`, `build-wasm.sh` (headers). Grep-verified: workspace members, Rust line/file counts per crate, `#[test]` counts, `unsafe` census with code-vs-comment-vs-string classification of every hit, `LayoutAlgorithm` enum variants (19), `DiagramType` enum variants (28), `NodeShape` enum variants (52), `ArrowType` enum variants (47), `ThemePreset` variants (11), `HashMap`/`HashSet` usage vs the README's zero-usage claim, FNX/asupersync/franken-kernel dependency status in Cargo.toml + Cargo.lock, feature-flag defaults, canary rollout state machine, golden fixture counts, CGA/adapton/egraph/DOT-parser code presence and wiring, WASM bundle size on disk vs README claim. Fetched and confirmed resolution of every Quick Link; read the GitHub Actions page, releases page, release API object, contributors API, repo page, and the live frankenmermaid.com showcase. Web-searched for independent coverage (benchmarks, reviews, production use). **Not done:** did not compile the workspace, run any test, execute the CLI, reproduce any benchmark, run the head-to-head harness, or execute the WASM bundle — all behavioral and performance claims rest on maintainer evidence plus revision-bound documentation. Shallow clone only (no history). CI per-run pass/fail not applicable (no test workflows exist). The "15 layout algorithms" repo-description figure is reported as the GitHub repo description (stale vs HEAD).

## 4.2 Executive verdict

FrankenMermaid is a **genuinely substantive, unusually self-auditing clean-room Rust reimplementation of the Mermaid diagram pipeline** [Inference, High] — not vaporware: a shallow clone of HEAD confirms 9 crates and 258,093 lines of first-party Rust [Verified, High], 27 diagram types and 18+Auto layout algorithms as compiler-checked enums [Verified, High], four render backends as real crates (SVG, terminal, Canvas2D, WASM) [Verified, High], 2,520 unit tests (`#[test]` functions in crate source; integration tests under `tests/` counted separately by lines, not functions) plus 53 golden snapshot pairs plus 3 fuzz targets with checked-in corpora [Verified, High], a tagged v0.2.0 release [Verified, High], and a live, working WASM showcase at frankenmermaid.com [Verified resolving and interactive, High]. Its most original contribution is not any single algorithm but the **evidence apparatus**: a negative-evidence perf ledger with mandatory A/A nulls and ELF-SHA-256 provenance, a machine-readable contract for what counts as a vs-incumbent claim, and a published claim-coverage audit that reports 96.4% of its own KEEP claims lack a same-invocation incumbent ratio [Verified, High] — the methodology-export lens made concrete. **But the single most important ceiling is bus factor 1 at extreme velocity** [Verified, High]: one human maintainer, ~3,282 commits in ~7 months, on a pinned `nightly-2026-08-31`, with unobservable quality gates — if the maintainer stops, the 258,093-line tree rots within quarters regardless of how good the benchmarks are. Secondary ceilings: zero independent validation of any kind was found [External, High within recall]; the headline 871×-faster release claim is maintainer-measured with strong documented method but no independent rerun [Maintainer claim, Medium]; the README is internally inconsistent and chronically stale (15 vs 18+Auto algorithms, 23 vs 52 node shapes, 30 vs 47 arrow types, 10 vs 11 themes, ~114k vs 258k lines, 24-type detection vs 27 types) [Verified, High]; and the MIT+OpenAI/Anthropic-rider license withholds all rights — including benchmarking and analysis — from OpenAI, Anthropic, affiliates, and their agents [Verified, High]: **not OSI open source**, a hard adoption ceiling. **NODUS: Explore.** The argued workload fit (CI diagram snapshot testing, where determinism + terminal diffs + `validate --fail-on` would shine) is real as an argument but evidenced by no user, no deployment, and no registry artifact — the "release" is a source-only tag. Under the ring-down rule ("when in doubt, ring down, not up"), this is Explore: substantive but unproven. The Pilot path is concrete and is recorded as a revisit trigger in §4.11: crates.io/npm publication plus one real docs-team trial. Its most durable contribution may be the **claim-governance methodology** (KEEP/REJECT ledgers, the incumbent-arm contract, the coverage audit), not the renderer [Inference, Medium].

## 4.3 Claim inventory: demonstrated vs aspirational

Status values: *demonstrated* / *partially demonstrated* / *aspirational* / *disproven* / *stale*.

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1 | 18 layout algorithms plus Auto | **Demonstrated** (the number; the "15" figure elsewhere is stale) | [Verified, High] — `LayoutAlgorithm` enum has 19 variants (Auto + 18); a compiler-checked `layout_algorithm_rows()` pins one capability row per variant, and the README's generated layout table lists all 19 |
| 2 | "15 layout algorithms" (comparison tables, repo description, release notes, showcase site) | **Stale** | [Verified, High] — the generated tables and enum say 18+Auto; the hand-written comparison tables, the v0.2.0 release notes, the GitHub repo description, and frankenmermaid.com all still say 15 |
| 3 | 27 diagram types | **Demonstrated** | [Verified, High] — `DiagramType` enum has 28 variants (27 + `Unknown` default); the "24-type detection" crate-map line is stale |
| 4 | Zero unsafe code, `#![forbid(unsafe_code)]` in every crate | **Demonstrated** — the strongest unsafe posture in this program | [Verified, High] — all 9 crate roots carry the forbid gate; code-level census finds zero `unsafe` tokens (the 29 non-comment hits are test names/string literals about XSS "unsafe URLs"); the `#[global_allocator]` for mimalloc is safe-Rust by language rule, as the code comment notes |
| 5 | mermaid-js 11.15.0 throws `RangeError: Maximum call stack size exceeded` on all seven pinned 2,000–10,000-node workloads; frankenmermaid renders all seven | **Partially demonstrated** | [Maintainer claim with documented method, Medium] — crash table in README with per-workload timings (e.g. 10,000-node architecture: 10.80 ms vs `RangeError` after 57.8 s); honestly reports no speedup ratio for crash rows ("a figure derived from a wall-clock budget would be an invented number"); not independently reproduced |
| 6 | v0.2.0 headline: full pipeline median ≈871× faster than mermaid-js 11.15.0 (13-diagram corpus, range 230×–4,740×); wide-graph pipelines 63.7×–124× | **Partially demonstrated** — and load-bearing for the performance thesis | [Maintainer claim with strong documented method, Medium] — same-invocation pinned incumbent (bundle SHA-256 recorded), median + MAD gate, conservative min-estimator (≈800×), paired A/A nulls, sha256-identical-SVG requirement for kept levers; no independent rerun found |
| 7 | Deterministic output: same input + config → byte-identical SVG | **Partially demonstrated** | [Verified mechanism, High] + [Maintainer claim, Medium on cross-platform] — golden suite (53 mmd+svg pairs, FNV-1a checksum comparison), determinism property tests, BTreeMap/FxHash discipline, stable tie-breaking documented; **but** the README's "(fm-layout and fm-parser contain zero HashMap/HashSet usage)" is **disproven** — one `std::collections::HashSet` (RandomState) sits in `egraph_crossing.rs::collect_orderings` (used for dedup, not iteration, so likely benign, but the sentence is false) |
| 8 | Intent-aware parsing: best-effort recovery, fuzzy keyword matching, never panics on malformed input | **Partially demonstrated** | [Verified code-volume, High] + [Maintainer claim, Medium] — 45,434-line fm-parser with recovery strategies, Levenshtein fuzzy matching, dangling-edge placeholder nodes; 3 fuzz targets (`fuzz_detect`, `fuzz_parse`, `fuzz_pipeline`) with checked-in corpora; "never panics" is unprovable in general and unexecuted by analyst |
| 9 | Four render backends: SVG, terminal, Canvas2D, WASM | **Demonstrated** | [Verified, High] — four real crates; WASM bundle checked in at `pkg/`; live demo renders in-browser. The WebGPU-fallback claim is code-verified: `crates/fm-wasm/src/lib.rs:163` declares `const WEBGPU_RENDERER_IMPLEMENTED: bool = false;` with the `WebGpu` selection enum variant present — plumbed, falls back to Canvas2D, exactly as the README Limitations state |
| 10 | FNX graph intelligence: Phase 1 (undirected, advisory) live; Phase 2 (directed) in canary rollout | **Partially demonstrated** | [Verified mechanism, High] — `fnx-integration`/`fnx-experimental-directed` feature flags exist, `RolloutPhase` state machine in `fm-core/src/canary.rs` (`Disabled → Canary → Partial → Full`, `RolledBack`); FNX git dep pinned at `cb8bdb59`; **not** in default features (`default = []`) — the shipped binary is FNX-free, and FNX roughly doubles WASM size |
| 11 | WASM bundle ~1.05 MB raw / ~433 KB gzipped | **Stale** | [Verified, High] — the checked-in `pkg/frankenmermaid_bg.wasm` is 1,764,748 bytes (~1.68 MB) raw and 700,089 bytes gzipped; the README figure describes a default no-FNX build that the checked-in artifact does not match |
| 12 | 10 theme presets | **Stale** | [Verified, High] — `ThemePreset` has 11 variants (Blueprint, Corporate, Dark, Default, Forest, HighContrast, Mermaid, Monochrome, Neon, Neutral, Pastel) |
| 13 | 23 node shapes / 30 arrow variants | **Stale** | [Verified, High] — `NodeShape` has 52 variants (the documented 23-row shape table covers only the mermaid-syntax-addressable subset; the rest are measured-from-Chromium extended shapes like `NotchedRect`, `SmallCircle`, `DividedRect`); `ArrowType` has 47 variants |
| 14 | Crate map: ~114,000 total lines (fm-core ~15,600, fm-render-svg ~13,800, fm-cli ~19,900, …) | **Stale** | [Verified, High] — counted 258,093 Rust lines / 338 files (fm-core 27,146; fm-parser 45,434; fm-layout 51,661; fm-render-svg 47,685; fm-render-term 12,954; fm-render-canvas 24,502; fm-cli 43,117; fm-wasm 4,607; fm-regression-harness 987). Every crate is 1.7–7× its claimed size; the map describes an ancestor of the tree |
| 15 | Incremental layout (Adapton DCG + epoch IR + vEB index skips unchanged subgraphs) | **Partially demonstrated** | [Verified code presence, High] — `crates/fm-layout/src/adapton.rs` (616 lines), `fm-core/src/epoch.rs`; a 1,001-revision live-edit job over a 500-node flowchart completes in 0.956 s (mermaid-js DNF at the 600 s deadline) [Maintainer claim, Medium]; re-render skip behavior not executed by analyst |
| 16 | E-graph crossing minimization (egg-based equality saturation, budget guards + Sugiyama fallback) | **Partially demonstrated** | [Verified, High] — `egg = "0.11.0"` dependency, `crates/fm-layout/src/egraph_crossing.rs` with `collect_orderings`; budget/timeout guards claimed in README; quality-vs-cost effect unexecuted |
| 17 | Conformal Geometric Algebra rotor-based transforms for obstacle-aware edge routing | **Partially demonstrated** | [Verified, High] — `crates/fm-core/src/cga.rs` (3,426 lines, conformal model R_{3,1}, 16-blade multivectors, rotor slerp), wired via `crates/fm-layout/src/cga_routing.rs` (`CgaLineSegment`, `CgaPoint`, `CgaRect`); routing-quality claims unexecuted |
| 18 | DOT bridge parses Graphviz DOT into the shared IR | **Partially demonstrated** | [Verified, High] — `crates/fm-parser/src/dot_parser.rs` exists; README discloses it covers "the structural subset … rather than full Graphviz visual attribute passthrough" |
| 19 | Clean-room implementation (no mermaid-js code) | **Partially demonstrated** w.r.t. mermaid-js; lineage nuance documented | [Verified, High] on the vendored-corpus absence — `legacy_mermaid_code/` is gitignored and absent; but idiom-level copying was not audited, so "shares no code" is **partially demonstrated**, not proven. **However** AGENTS.md states the project goal was to "extract and harden diagram parsing/layout/rendering from FrankenTUI", and code comments say "Extracted from `format_gantt_axis_tick` unchanged" — the engine's design lineage is extraction from the sibling FrankenTUI's mermaid module, not an independent ground-up design. The FAQ's "shares no code with mermaid-js" is true but incomplete as a provenance statement |
| 20 | Crates.io / npm publication | **Aspirational** | [Verified, High] — `docs/CRATES_IO_PUBLISHING.md` is a plan (name availability verified 2026-04-15, publish order defined); nothing published on crates.io; README Limitations: "`@frankenmermaid/core` npm package is not on npm yet"; VSCode extension (`frankenmermaid-vscode` 0.1.0) exists in tree, marketplace publication unverified |
| 21 | Live showcase: 80+ interactive examples, determinism checker, presenter mode | **Partially demonstrated** | [Verified resolves + interactive, High] on https://frankenmermaid.com/ — live WASM lab renders; the "80+ examples" count and determinism-checker behavior are [Maintainer claim, Medium]; the site's own copy is stale ("15 layout algorithms", "24 families" vs 18+Auto / 27 types at HEAD) |

## 4.4 Architecture (reconstructed, not summarized)

[Verified from the clone; README diagrams treated as claims where noted]

**Crate topology (9 workspace members, `Cargo.toml`):** `fm-core` (27,146 lines — shared IR: `MermaidDiagramIr`, `DiagramType` (28 variants), `NodeShape` (52), `ArrowType` (47), `ThemePreset` (11), config, diagnostics, CGA primitives, evidence bundle types, `RolloutPhase` canary state machine, epoch handles), `fm-parser` (45,434 lines — type detection, Mermaid + DOT parsing, fuzzy keyword matching, error-recovery strategies, IR builder, string interning), `fm-layout` (51,661 lines — 19-variant `LayoutAlgorithm` enum, capability-aware auto-selector with loss terms, 4 cycle strategies, Sugiyama with Brandes-Köpf coordinates, e-graph crossing minimization, Adapton incremental DCG, CGA obstacle routing, FNX advisory adapter behind feature flags), `fm-render-svg` (47,685 lines — SVG document/element/path/text/defs model, 11 theme presets, gradients/shadows/glows/CSS animations, ARIA markup, source-span attributes), `fm-render-term` (12,954 lines — braille 2×4 / block 2×2 / half-block / cell-only modes, Unicode box-drawing, ASCII fallback, diff engine, minimap), `fm-render-canvas` (24,502 lines — Canvas2D with trait abstraction + mock context for tests; the GPU plan backend exists as `gpu_plan.rs` emitting instance buffers but rendering falls back to Canvas2D), `fm-wasm` (4,607 lines — wasm-bindgen API, `@frankenmermaid/core` surface, lens bindings, WebRenderer selection), `fm-cli` (43,117 lines — `frankenmermaid`/`fm-cli` binaries: render/parse/detect/validate/capabilities/diff/deck/interactive/watch/serve + `evidence` release-signoff binary; composition: `main.rs` 11,705 + `evidence.rs` 2,840 + `support_matrix.rs` 1,038 + `minimize.rs` 609, plus 20,466 lines of integration tests across 31 files in `tests/`), `fm-regression-harness` (987 lines — real-world corpus ingestion + HTML thumbnail report).

**Data flow:** text → `fm-cli` → `fm-parser` (detect → parse → recover → IR) → `fm-layout` (auto-select algorithm → cycle breaking → crossing minimization → coordinate assignment → edge routing, with the decision ledger — types defined in `fm-core`, constructed in `fm-layout`, surfaced via `fm-cli`) → render scene IR → one of `fm-render-svg` / `fm-render-term` / `fm-render-canvas` → output + evidence bundle (layout decisions, diagnostics, source spans). `fm-core` types flow through every stage; `fm-wasm` exposes parse/layout/render round-trip to JS.

**Memory-safety posture** [Verified, High]: all 9 crate roots `#![forbid(unsafe_code)]`; zero `unsafe` code tokens found across 258,093 lines (every remaining textual hit is a comment, doc string, or XSS-filter test name). The one place unsafe-adjacent machinery appears — the `mimalloc` global allocator in `fm-cli` — is safe Rust by language rule (`#[global_allocator]` on a `MiMalloc` static requires no `unsafe`), as the code comment itself explains. External unsafe surface is limited to dependencies (mimalloc, rayon, etc.), which is the standard and honest boundary.

**Dependency posture:** `fm-core` depends on **franken-kernel 0.3.9 from crates.io** (re-exported: `Budget`, `Cx`, `DecisionId`, `NoCaps`, `PolicyId`, `SchemaVersion`, `TraceId` — the shared FrankenSuite evidence/tracing kernel) [Verified, High]. **Asupersync: zero references in Cargo.lock** — not a dependency, not evaluated in-tree; the publishing doc notes franken-kernel's historical source was the asupersync repo (2026-04-21 crates.io migration), but the workspace consumes only the published crate [Verified, High]. FNX (`franken_networkx` git dep, pinned `cb8bdb59`) is **opt-in only** — `default = []` on both fm-layout and fm-cli, and the README states default builds are "FNX-free and crates.io-clean" [Verified, High]. Notable: `fm-render-svg` depends on `fm-layout` (not just `fm-core`) plus `serde_json` and `memchr` — the README's "Zero-dep SVG" workspace-layout note refers to no SVG-specific C libraries (generation is pure Rust), not to a literal zero-dependency crate.

**Concurrency:** `fm-cli` links `rayon` 1.12.0 for `render-batch` (whole-diagram pipelines concurrently); the per-diagram pipeline itself is single-threaded deterministic [Verified, High] — zero `rayon`/`par_iter`/`thread::spawn`/`scope` refs in fm-layout, a fact the codebase itself records in the bd-ryxg flake investigation ("REFUTED. fm-layout contains ZERO occurrences of rayon…", the four refuted hypotheses preserved as a doc comment so the next person doesn't re-run them) — with an epoch-based concurrent IR handle for incremental re-layout. Force layout uses Barnes-Hut; the 64-worker whole-job sweep shows 50.3% observed parallel efficiency [Maintainer claim, Medium].

**README-vs-code drift (governance signal):** the crate-map line counts describe an ancestor (~114k claimed vs 258k counted, every crate 1.7–7× stale); "15 algorithms" persists in hand-written tables, release notes, repo description, and the live site while generated tables and the enum say 18+Auto; "23 shapes / 30 arrows / 10 themes / 24-type detection" vs 52 / 47 / 11 / 27 in code; the checked-in WASM bundle (1.68 MB / 700 KB gz) vs the documented default build (1.05 MB / 433 KB gz); the "zero HashMap/HashSet in fm-layout" sentence vs one real `std::collections::HashSet` in the e-graph path; the "CI workflow per push" aggregator vs **no `.github/workflows` directory at all** (Actions shows only pages-build-deployment). None of this is concealed — the same README publishes its losses and its claim-coverage audit — but docs chronically lag a very fast-moving tree, and the CI-quality-gates story has a real hole: the gates are declared in `.ci/quality-gates.toml` but no workflow file consumes them.

## 4.5 Benchmark and conformance audit

### Maintainer-produced numbers

**Read the crash table first — it is the empirical anchor.** A crash is binary and the least gameable number in the packet: mermaid-js either throws `RangeError` on a 2,000–10,000-node workload or it doesn't, and the maintainer's README deliberately derives no ratio from the time budget. The ratios below follow; they are better-documented but interpretation-laden.

| Workload | FrankenMermaid ÷ mermaid-js 11.15.0 | Method controls | Would it survive independent rerun? |
|---|---|---|---|
| 7 large-graph workloads (2,000–10,000 nodes) | No ratio claimed — mermaid-js `RangeError` (crash), recorded as `CANNOT` | Crash reproduced per workload with wall times to failure (6.5 s–625.4 s) | The honest rows: a crash is not a timeout, and the README refuses to derive a ratio from a time budget |
| 1,001-revision live-edit job, 500-node flowchart | 0.956 s vs mermaid-js DNF at 600 s deadline | Recorded as `DNF-timeout`, no point ratio | Honest non-claim |
| 13-diagram corpus, full parse→layout→render-to-SVG pipeline | **≈871× median** (range 230×–4,740×; conservative min-estimator ≈800×; 5% MAD gate) | Pinned incumbent bundle (SHA-256 `70137e77…`) run live in the same invocation via Chromium; median + MAD gate; min-estimator | The best-documented number in the repo, but the corpus definition, harness scripts, and host (maintainer-side multi-worker hosts) are maintainer-side; an independent rerun needs the harness + pinned bundle + equivalent hardware — plausible but unattempted |
| 512-diagram certified job (10,635 nodes, 10,123 edges), 1 caller worker | **851.99×** [829.50×, 864.95× 95% effect CI — bootstrap confidence interval on the ratio]; 27.16 ms vs 23,143.40 ms | Same-invocation incumbent; 9 independent whole-job samples; same-ELF pre/post bracket; corrected A/A median-CI gate; all 512/512 structural-equivalence pass | Same caveat as the 871× row (corpus, harness, and host are maintainer-side; no independent rerun); the per-width table (1/16/64/128 workers: 852×/10,202×/27,420×/24,893×) is internally consistent |
| Wide-graph full pipelines | **63.7×–124×** (ledger: 83.43×/63.72×/124.05× on 8×16/12×24/16×32) | Same harness family, mermaid-js 11.12.0 via Chromium headless data-URL harness | Ledger row predates the 11.15.0 pin; version skew noted |
| 384-diagram shared-subgraph job | **17,060.38×** [16,581.25×, 17,414.95×]; 2.995 ms vs 51,101.9 ms | 384/384 structural-equivalence pass | Same caveat |
| Per-lever micro-wins (diamond nodes 2.53×, quadrant points 1.56–3.04×, barycenter 3.591×, …) | Various, all `maintenance-self-speedup` or `incumbent-win` classed | A/B **and** A/A null; instruction counts as arbiter for sub-noise levers; byte-identity proof where serialization is touched | The KEEP/REJECT ledger discipline is the strongest part; 225 KEEP rows counted 2026-07-30 |

**The load-bearing number and its caveat.** The 871× headline is the number a casual reader remembers. Its method is genuinely strong (pinned live incumbent, same invocation, MAD gate, min-estimator, A/A nulls). But three things bound it: (1) **no independent rerun exists** — zero third-party benchmarks found; (2) the comparison is **native batch Rust on server-class hardware vs a browser DOM renderer in Chromium** — the README's own numeric-campaign section is careful to compare "same-input, same-target" and to use structural equivalence rather than pixel equality, but a browser engine pays DOM/CSS/layout taxes the native pipeline never incurs, so the ratio measures *incumbent-in-browser vs challenger-native*, not layout-algorithm superiority; (3) the repo's own claim-coverage audit (2026-07-30) found **only 8 of 225 KEEP claims carried a live same-invocation incumbent ratio — 96.4% do not**, and at that snapshot only 1 section / 3 rows carried a cross-engine output-equivalence verdict (later closed per the 2026-07-31 update, which explicitly does *not* retroactively validate historical ratios). A packet must never cite the 871× without these three sentences attached.

**Reproduction cost (honest):** the tree is a modest checkout (no giant corpus); builds on pinned `nightly-2026-08-31`; the sanctioned bench path is the `rch exec` remote-worker setup on the maintainer's private remote-execution hosts (in-repo name: DSR) plus a pinned Chromium and the pinned mermaid-js 11.15.0 bundle (SHA-256 `70137e77…`). An independent rerun needs the head-to-head harness scripts (`scripts/headtohead/`), the corpus inputs (input SHA-256 `228414f8…` for the 512-job), and equivalent hardware. Expect hours of setup, not minutes — and the harness's DSR-host execution model (per the franken_markdown amendment convention: **[Verified mechanism, High] + [Maintainer claim, Medium] on execution**) means the CI quality gates themselves are not publicly observable.

### Conformance evidence

- **Golden snapshot suite:** 53 mmd+svg pairs under `crates/fm-cli/tests/golden/`; FNV-1a hash comparison in `golden_svg_test.rs`; layout goldens and deck goldens as separate harnesses [Verified, High].
- **Conformance corpus:** `crates/fm-cli/tests/frankentui_conformance_cases.json` pins ~26 fixtures across diagram families with expected IR structure + expected SVG markers, plus documented deliberate divergences from mermaid-js surfaced via the `Compatibility` diagnostic [Verified, High].
- **Structural-equivalence oracle:** the head-to-head harness checks 4 gating invariants (rendered-text token containment one-directional, node-ID set equality, cross-engine edge topology, per-engine topology vs input graph) with 5 mutation controls + 2 negative controls on its self-test; explicitly *not* a pixel diff ("a pixel diff would report a large distance between two correct renders") [Maintainer claim with documented method, Medium].
- **Determinism tests:** repeated-run equality + proptest over random graph shapes (up to 20 nodes × 5 directions), case count configurable in `.ci/quality-gates.toml` [Verified mechanism, High].
- **Fuzzing:** 3 targets (`fuzz_detect`, `fuzz_parse`, `fuzz_pipeline`) with checked-in corpora [Verified, High]; execution history not verified.
- **CI:** **no test workflows exist** — `.github/workflows/` is absent and the Actions page shows only `pages-build-deployment` runs (2,500+). The 11 declared quality gates in `.ci/quality-gates.toml` (golden_checksum, property_test, determinism, evidence_ledger, release_signoff, …) have no visible enforcement point. [Verified, High — and a governance finding]

### Independent numbers

**None found.** Web search returns only the repository itself, its forks/copies (ekoziol, dorucioclea, crystalfox8), the live demo, and one maintainer-adjacent analysis doc inside the frankenterm repo (`COMPREHENSIVE_ANALYSIS_OF_franken_mermaid.md` — written from the maintainer's own checkout, not independent). No third-party benchmark, code review, production deployment, or press found [External, High within recall caveats]. **Independent validation: zero.**

## 4.6 Comparison: who owns the lane

**The incumbent** is **mermaid-js** itself (11.x) — it owns the "diagrams-as-code default" lane outright through distribution, not quality [External, Medium]: it ships inside the platforms where the diagrams are written, which is a structural moat no benchmark table can breach. **Why the incumbent wins today, in one paragraph:** nobody chooses a diagram renderer on benchmark tables; they choose it because it's already inside their markdown pipeline, their docs platform renders it for free, and every contributor already knows the syntax. FrankenMermaid has none of that distribution — no npm package, no crates.io crates, no platform integrations found in the repo, docs, or site [Verified absent from inspected surfaces, Medium], a VSCode extension that exists only in-tree — and its license rider legally excludes the AI labs whose agent tooling would be the natural embedding vector. A docs team does not migrate off the default renderer for a 0.2.0 single-maintainer binary whose own site still advertises the wrong algorithm count.

**Adjacent lanes:** **mermaid-cli/mmdc** (owns the Node.js batch-render lane), **Kroki** (owns the self-hosted diagram-API lane, mermaid included), **Graphviz** (owns the algorithmic-graph-layout lane; `dot`'s Sugiyama is the reference implementation this project reimplements), **d2** (owns the "modern textual diagrams with a real layout engine" wedge, Terrastruct-backed — the closest peer on *implemented* differentiators: d2 actually ships its own layout engine and commercial support, while FrankenMermaid's layout engine is larger but unshipped-as-a-product), **PlantUML** (owns the enterprise-UML lane). **Rust peers:** `mermaid-rs`-style bindings are thin wrappers, not engines — there is no established "Rust Mermaid engine" incumbent, which is why this lane was open.

**The genuinely unoccupied lane [Inference, Medium]:** *deterministic, CI-native diagram rendering with terminal output* — byte-identical SVG snapshots for docs-as-code pipelines plus braille/block terminal rendering with a diff engine for SSH/CI contexts where no browser exists. Nobody owns it: mermaid-js cannot do terminal output at all and does not guarantee determinism; Kroki is server-side; d2 has no terminal surface. FrankenMermaid's golden suite + `validate --fail-on` + `diff` + terminal renderer is the only in-tree artifact pointed at that gap — but it is unvalidated by any real docs team, and the lane is small: it is a feature-sized wedge, not a market.

## 4.7 Technical merit and adversarial review

**Strengths:**
1. **Evidence discipline without peer in this program.** The negative-evidence ledger (KEEP/REJECT rows with A/A nulls, ELF-SHA-256 provenance, do-not-retry predicates), the PERF_LEDGER's machine-readable `incumbent-win` contract, and above all the CLAIM_COVERAGE_AUDIT — a self-audit that counts 225 KEEP claims and reports that 96.4% lack a live incumbent ratio, then documents the bd-4isi episode where the project proved *itself* was timing a partial render against mermaid's full one. This is the methodology-export lens made concrete: if the renderer fails, the claim-governance apparatus survives as a transferable artifact [Verified, High].
2. **Real implementation volume in the right places.** 258,093 lines with mass concentrated in the parser (45k), layout (52k), and SVG renderer (48k); a 3,426-line conformal-geometric-algebra module actually wired into edge routing; a real e-graph crossing minimizer on the `egg` crate; a 616-line Adapton incremental DCG; 2,520 unit tests; 53 golden pairs; 3 fuzz targets. This is not scaffolding [Verified volume, High; behavior Maintainer claim, Medium].
3. **The zero-unsafe posture is complete, not aspirational.** All 9 crates `#![forbid(unsafe_code)]`, zero unsafe tokens in 258k lines, and even the `mimalloc` global allocator is safe-Rust by language rule — with a code comment explaining exactly why it coexists with the forbid gate. No other packet in this program verified a cleaner unsafe census [Verified, High].
4. **Honesty about what numbers mean.** Crash rows recorded as `CANNOT` with no ratio derived; the DNF live-edit row carries no point ratio; the release notes demand sha256-identical SVG for kept levers; the audit explicitly refuses retroactive validation of historical ratios. The project repeatedly declines to claim numbers it could have claimed [Verified, High].
5. **The Chromium-measured fidelity details.** Node-shape geometry (notch-rect polygon points, fixed-radius start markers, divided-rect rule ratios) and ARIA roledescription spellings were measured against the pinned 11.15.0 bundle in Chromium rather than derived from the parser's own conventions — the kind of ground-truth anchoring that makes "compatible" mean something [Verified in code comments, High].

**Weaknesses:**
1. **Bus factor 1 at extreme velocity.** One human produced ~3,282 commits in ~7 months (~15/day); the only other contributor entry is `codex` with 3 commits (non-human status not verified — [Inference, Medium]). Review depth cannot match that rate, and the docs-vs-code drift catalogued in §4.4 is the visible symptom [Verified + Inference, High].
2. **Zero independent validation of any kind.** No third-party benchmark, no code review, no production deployment, no external contributor, no press. The 871× headline has never been reproduced by anyone but the maintainer [External, High within recall].
3. **The CI story has a hole.** Eleven quality gates are declared in `.ci/quality-gates.toml` and the README says "the aggregator surfaces a single pass/fail signal to the CI workflow per push" — but there is no `.github/workflows` directory and the Actions page shows only pages-build-deployment runs. Either the gates run on unobservable private infrastructure (the franken_markdown amendment convention applies) or the sentence is aspirational; either way, "CI-gated" is not publicly verifiable [Verified, High].
4. **Docs chronically lag the tree.** 15 vs 18+Auto algorithms, 23 vs 52 shapes, 30 vs 47 arrows, 10 vs 11 themes, 24 vs 27 types, ~114k vs 258k lines, a stale checked-in WASM bundle, a false "zero HashMap/HashSet" sentence, a repo description and live site advertising the old numbers. Each instance is minor; the pattern is the governance signal the Rulebook asks for [Verified, High].
5. **The license is a strategic own-goal for the stated mission.** The rider withholds *all* rights — including benchmarking, testing, and analyzing — from OpenAI, Anthropic, affiliates, and anyone acting for them. For a project whose natural embedding vector is AI-agent diagram tooling, legally excluding the frontier labs (and chilling any third party from publishing an independent benchmark) sabotages exactly the adoption path the technology would need [Verified, High].
6. **Structural ceilings are real:** pinned nightly toolchain, no crates.io/npm publication (both explicitly "not yet"), source-only release with no binary assets, FNX roughly doubling WASM size keeps the flagship intelligence feature out of the default build, WebGPU is a code-verified fallback-to-Canvas2D (`WEBGPU_RENDERER_IMPLEMENTED: bool = false`), and the 871× headline compares native batch Rust against a browser DOM renderer — an apples-to-Chromium comparison the packet must keep labeled as such [Verified, High].

**Steelman of the bear case:** FrankenMermaid is a monumentally over-engineered answer to a distribution problem. The diagram-rendering lane is owned by mermaid-js through embedding in every major platform, and nobody migrates off the default renderer because a 0.2.0 binary is faster in a benchmark its own author ran — especially when the "competitor" being beaten is a browser DOM engine doing CSS layout, and the comparison that matters (layout *quality*, judged by humans) is proxied by a structural-equivalence check that deliberately ignores the visual differences users actually see. The genuinely novel surfaces — terminal rendering, determinism guarantees — are feature-sized wedges, not markets; the CGA/Adapton/e-graph machinery is impressive mathematics in service of diagrams nobody was failing to render except at 10,000 nodes, a workload with approximately zero buyers. At bus factor 1 on a pinned nightly with no package publication, the most likely terminal state is a beautiful, honest, unreproduced benchmark suite attached to a renderer the ecosystem never adopts. The methodology is admirable; methodologies don't get starred into package managers.

**Hook audit (the packet grades its own hook):** "A 258,093-line, provably zero-`unsafe` Rust Mermaid engine that renders the 2,000–10,000-node diagrams where mermaid-js throws `RangeError` — and ships a claim-coverage audit admitting 96.4% of its own performance claims carry no same-invocation incumbent ratio." Line count (258,093, counted), zero-unsafe (census-verified), the `RangeError` crash table, and the 96.4% audit figure (225 KEEP, 8 with incumbent ratio) are all verified. "Provably" is defended by the forbid-gate census — and the defense is substantive, not vernacular: the claim is a syntactic property of the tree (the `unsafe` token does not appear outside comments/test names), and an exhaustive census of all 338 files genuinely proves a negative of that form. The load-bearing half is the compiler's: `#![forbid(unsafe_code)]` at every crate root means the compiler rejects `unsafe` introduced by macro expansion too, closing the hole a token census alone would leave. It is not formal proof of a semantic property like pipeline memory safety, which the hook does not claim. The hook survives.

## 4.8 License and governance (material, not boilerplate)

**License text, read verbatim** [Verified, High]: `LICENSE` is the MIT License **with an "ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic)"** that is "part of the 'conditions' of this License" and "controls" in any conflict. Quoted scope: *"Restricted Parties" means 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).* *"Notwithstanding any other provision of this License, no rights are granted to any Restricted Party."* Disclosure/hosting/distribution to them is forbidden. *"Use" includes, without limitation: copying, modifying, … 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 terminates all permissions automatically (with a destroy-all-copies clause); injunctive relief and attorneys' fees reserved to Jeffrey Emanuel (copyright holder, 2026); the rider must travel unmodified with any distribution. **Classification: NOT OSI open source** — named-party discrimination with a use-restriction covering even benchmarking and analysis. This is source-available with a targeted exclusion. Note the repo's own badge says "License: MIT (with AI Rider)" and the README License section names the rider — disclosure exists, though GitHub's own license detection reports "Other (NOASSERTION)".

**The rider as strategy:** it serves a defensive mission (preventing the two leading labs from absorbing the work into training corpora or evaluation harnesses without permission) but sabotages the project's most credible adoption vectors: agent-tooling diagram rendering (the excluded parties *are* the agent-platform builders), independent benchmarking (even *analyzing* is a withheld right, which chills the third-party reproduction the project most needs — and helps explain why independent validation is zero), and enterprise procurement (legal review of a named-party exclusion with a destroy-copies clause is a non-starter for most). Adoption ceiling: hard — and self-inflicted, since the excluded parties are also the most likely to have funded or acquired this work.

**Governance:** owner-directed single maintainer; no visible external contributors (the `codex` account's 3 commits; account type "User", bot status unverified); no CONTRIBUTING-mediated review visible in the shallow clone; commit velocity ~3,282 commits in ~7 months (~15/day) with agent-persona conventions (bead IDs, worker identities like `TanSparrow` in ledger rows); the `.beads` issue tracker is the planning surface — and it is active, not decorative: 1,125 beads in `.beads/beads.base.jsonl`, ~95 open / ~1,028 closed (≈91% close rate) [Verified, High]. The `.beads/` directory also carries corruption-recovery artifacts (`beads.db.corrupt-081547`, `beads.db-shm.schemabroken_*`) — the tracker database has been through surgery, visible in-tree and disclosed here as texture. **Distribution:** `install.sh` clones the git repo and builds from source (bootstrapping rustup if cargo is missing) — there is no binary distribution channel; the v0.2.0 "release" is a source-only tag [Verified, High]. Bus factor 1 [Inference, High]. **What breaks first if velocity decays:** the docs already lag the tree at full velocity; a slowdown without a successor strands 258k lines on a pinned nightly with nobody who understands the whole pipeline, and the unobservable quality gates become unverifiable — bit-rot within quarters, not years.

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness (TRL 1–9) | **6** | Prototype demonstrated in a relevant environment: tagged release, live public WASM demo, 2,520 tests + 53 golden pairs + fuzz targets — but no production deployment, no published package, no independent validation. (Why 6 and not 5: the prototype is public and live, not lab-only. Why not 7: no operational-environment demonstration by any user.) |
| Strategic relevance (1–5) | **3** | Deterministic CI-native diagram rendering is a real strategic gap; capped by the rider, pre-package state, and mermaid-js owning distribution |
| Impact potential (1–5) | **3** (4 if the terminal/diff CI surface becomes a category) | Diagram tooling is a feature-sized market; impact is methodological + niche unless the evidence apparatus is exported |
| Implementation feasibility (1–5) | **4** | The core is built and demonstrably works; what remains (packaging, publication, docs catch-up) is bounded and unglamorous |
| Time to mainstream (1–5) | **2** | Years minimum: needs crates.io/npm publication, independent validation, a second maintainer, and a license an enterprise can sign |
| Collaboration potential (1–5) | **2** | Source-available; rider blocks the two most likely AI-lab collaborators; bus factor 1; contribution bar is evidence-heavy |

**Ring: Explore.** Under the ring-down rule ("when in doubt, ring down, not up"), Explore is the honest ring for a substantive-but-unproven project: the release artifact is a source-only tag with no binaries and no registry publication, the CI-snapshot workload fit is argued rather than evidenced by any user, and independent validation is zero. *Pilot* becomes reachable on a concrete, observable path: (1) crates.io and/or npm publication, (2) one real docs-team or CI-pipeline trial of the golden-suite/diff surface, (3) any independent benchmark or review. Revisit triggers: publication; any independent benchmark, review, or production deployment; a second human maintainer with merge rights; any change to the license rider; the quality gates becoming publicly observable (workflow files or public CI runs); mermaid-js shipping a fix for the large-graph `RangeError`.

## 4.10 Wardley placement

Each placement names the observable event that would move the component — mechanisms, not hopes.

- **Mermaid-syntax diagram rendering:** Commodity — mermaid-js owns it through platform embedding; FrankenMermaid adds no leverage here. Moves nowhere: the only leftward event would be mermaid-js abandonment, which no evidence suggests.
- **Clean-room Rust Mermaid pipeline (parse/layout/render, 27 types, 18+Auto algorithms):** Custom-built → early Product — works in the maintainer's lab and on the public demo, pre-package, validated against oracles but not by third parties. **Moves right to Product on:** first crates.io or npm publication (observable registry artifact) *plus* one independent benchmark or review (observable third-party verdict). **Moves left on:** the nightly pin aging past compiler compatibility with no migration — the unmaintainability event.
- **Terminal rendering + diff engine + minimap:** Genesis → early Custom-built — no equivalent in any incumbent, which is why it sits left of the pipeline: novelty without a user. **Moves right to Product on:** one real docs-team CI trial with measured review-signal (the next-step-4 experiment, run by anyone). **Moves left into obscurity on:** twelve months with no external adoption — a Genesis component with no user after a year is a demo feature, and the packet would reclassify it as such.
- **Evidence apparatus (KEEP/REJECT ledgers, incumbent-arm contract, claim-coverage audit, A/A-null doctrine):** Custom-built — novel as a packaged discipline and the most transferable component. **Moves right toward Product on:** a second FrankenSuite repo adopting the incumbent-arm marker contract (observable in-tree, countable). **Moves left on:** the maintainer's own audit cadence lapsing — the 96.4% figure dates to 2026-07-30; if no second audit appears, the apparatus is a one-time performance, not a discipline. The deeper coinage — *verification-from-assertion*, separating "a number was published" from "a number was measured against the incumbent in the same invocation" — is aspirational today: the incumbent-arm contract is a markdown convention enforced by review, not a machine-checked proof [Inference, Medium].

**The decoupling lens:** FrankenMermaid represents *engine-from-runtime* (the same IR pipeline runs as CLI binary, Rust library, and WASM with no JS engine in the loop) and advances *layout-from-renderer* (one IR, four backends). It gestures at the next decoupling the program has been tracking — *verification-from-assertion*: the claim-coverage audit and incumbent-arm contract separate "a number was published" from "a number was measured against the incumbent in the same invocation", which is the beginning of portable, machine-checkable performance provenance.

## 4.11 Trajectory (12 / 24 / 60 months) — [Inference]

- **12 months:** continued high-velocity single-maintainer/agent work; probable crates.io publication of the fm-* crates (the plan and name availability are done; the FNX git-dep is the remaining blocker for a clean publish); docs catch-up or continued drift; the unobservable quality gates either become visible or remain a trust-me. Stays in Explore; publication alone doesn't reach Pilot without a real workload trial. No mainstream movement.
- **24 months:** bifurcation. **Upside:** an independent benchmark reproduces the head-to-head numbers, a docs-platform team trials the terminal-diff surface, a second maintainer appears — Pilot becomes real (the deterministic diagrams-for-CI niche). **Decay:** velocity slows with no successor; the nightly pin ages; the 258k-line tree becomes unmaintainable; drifts to Monitor as a research artifact whose methodology outlives its renderer.
- **60 months:** binary. Either a niche-but-real artifact (the deterministic, evidence-carrying diagram substrate embedded in docs tooling — a lane nobody else is building), or superseded: mermaid-js fixes its stack overflow, adds a headless batch mode, or a platform ships deterministic rendering natively, and the "Rust Mermaid" lane consolidates around whichever peer publishes first. The claim-governance methodology is the more likely survivor either way.

**Revisit triggers (concrete, observable):** first crates.io or npm publication; any independent benchmark, code review, or production deployment; a second human maintainer with merge rights; any change to the license rider; the quality gates becoming publicly observable (workflow files or public CI runs); mermaid-js shipping a fix for the large-graph `RangeError`.

## 4.12 Limitations and open questions (mandatory)

**Not done:** did not compile the workspace, run any test, execute the CLI, reproduce any benchmark, run the head-to-head harness, or execute the WASM bundle — all behavioral and performance claims rest on maintainer evidence plus revision-bound documentation. Shallow clone only (no history beyond HEAD). No test workflows exist, so CI greenness is not applicable. Star/fork counts from the GitHub repo page fetch, not a live API read (contributors were API-read). Enum-variant counts use body-pattern greps as a proxy (doc-comment lines inside enums were excluded by pattern; a miscount would be small). Web search for independent coverage carries the usual recall caveats. The "15 layout algorithms" repo-description figure is reported as the GitHub description text (stale vs HEAD), not as a code claim.

**Open questions that would most change the verdict:** whether any independent party can reproduce the 871× head-to-head on equivalent hardware; where the 11 declared quality gates actually execute (and whether they are green); whether the fnx-integration feature's advisory hints measurably improve layout quality (the canary's health criteria are defined but no results published); whether crates.io publication clears the FNX git-dep blocker; what the maintainer's succession/funding intentions are; whether any docs team has piloted the terminal-diff surface; whether the checked-in WASM bundle's size drift (1.68 MB vs 1.05 MB documented) reflects a stale artifact or a changed default build.

## The eight deepening questions (one paragraph each)

1. **Provenance.** FrankenMermaid records almost nothing about *who produced* a diagram artifact: rendered SVGs carry no producer attestation beyond optional source-span attributes and source-map files, and the evidence bundle (layout decisions, diagnostics) is descriptive, not signed — the one exception is the bench ledger's ELF-SHA-256 provenance, which binds a *measurement* to the exact binary that produced it but not the *diagram* to its author [Verified ledger mechanism, High]. Making attestation portable would require signing evidence bundles with an operator key and hash-chaining them to the input bytes; the current bundle is a JSON artifact with no tamper-evidence, so a hostile party could rewrite layout history undetectably [Inference, Medium]. The deeper provenance story is the code's own: AGENTS.md documents extraction from FrankenTUI's mermaid module, while the README's clean-room FAQ answers only the mermaid-js question — provenance of the *project* is better documented internally than provenance of its *outputs* [Verified, High].

2. **The embeddable unit.** The smallest useful adoptable piece is `fm-parser` (detection + recovery + IR builder, 45,434 lines) or the `fm-core` IR types alone (27,146 lines), which the README claims are usable as Rust libraries [Maintainer claim, Medium]. The adoption cost is steep in practice: no crate is published on crates.io (plan only, FNX git-dep is the blocker), the toolchain is pinned to `nightly-2026-08-31`, `fm-core` pulls the `franken-kernel` evidence kernel, and the license rider follows every derivative — so embedding means vendoring nightly-only, rider-encumbered source with no registry artifact [Verified, High]. The WASM bundle (`pkg/`, 1.68 MB checked in) is the most adoptable unit today, but it is size-mismatched relative to the documented build (1.05 MB documented; direction of the mismatch not verified — the checked-in bundle may simply be a different feature set) and has no npm distribution [Verified, High].

3. **Unexercised option value.** The architecture holds at least four unused capabilities: the `RolloutPhase` canary state machine generalizes beyond FNX to any risky feature rollout but is only wired to FNX; the `evidence` release-signoff binary implements a full gate-aggregation and override-authorization protocol that no CI workflow consumes; the GPU plan backend emits real instance buffers but rendering falls back to Canvas2D; and the lens system (bidirectional editor integration with source maps) is built but has no editor adoption [Verified, High]. What unlocks them is, respectively, a second feature behind the canary, a visible CI workflow that consumes the signoff protocol, completing the WebGPU renderer, and a VSCode-marketplace publication of the in-tree extension — all product decisions, none blocked on research [Inference, Medium].

4. **Benchmark honesty.** The numbers most likely to survive an independent rerun are the *adverse or humble* ones — the crash-table's refusal to derive ratios from timeouts, the DNF live-edit row with no point ratio, the 96.4%-without-incumbent-ratio audit, and the REJECT rows pricing failed levers — because they are the maintainer's own published losses and non-claims, and nobody publishes non-claims they can't defend [Inference, Medium]. The 871× headline has the strongest method (pinned live incumbent, same invocation, MAD gate, min-estimator, A/A nulls) but is load-bearing for the performance thesis *and* compares native batch Rust against a browser DOM renderer — so the thesis currently rests on a number whose interpretation ("faster at the same work") depends on accepting structural equivalence as "the same work", a judgment call the README documents but an independent rerun would have to re-litigate [Verified method, High; interpretation Inference, Medium].

5. **The governance path.** The credible route from one maintainer to an institution runs through publication: crates.io + npm artifacts create users, users file issues against real integrations, and a second maintainer emerges from the user base or from a docs-platform company that depends on the determinism story — there is no shortcut, because today there is no registry artifact to adopt and no contributor on-ramp beyond the tree [Inference, Medium]. What breaks first if velocity decays is the docs-code contract, then verifiability itself: at ~15 commits/day the README already describes an ancestor of the tree, so a slowdown without a successor doesn't stabilize the project — it strands 258,093 lines on a pinned nightly with unobservable quality gates, and bit-rot sets in within quarters [Inference, High].

6. **The license as strategy.** The rider excludes exactly OpenAI, L.L.C., Anthropic, PBC, their affiliates, and anyone acting for, benefiting, or under the direction of them — and it defines "use" to include benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination, a destroy-all-copies clause, and injunctive relief reserved to Jeffrey Emanuel [Verified verbatim, High]. As strategy it is coherent defensively (it prevents the two labs best positioned to absorb the work from doing so without permission) and self-sabotaging offensively: the project's most credible embedding vector is AI-agent diagram tooling, the excluded parties *are* the agent-tooling builders, and the rider's breadth (even analyzing is forbidden) chills the independent benchmarking the project most needs — no third party can publish a reproduction without lawyering the rider first, which helps explain why independent validation is zero [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick FrankenMermaid over mermaid-js is an agent loop generating architecture diagrams inside a sandbox or CI job with no browser: deterministic SVG snapshots (byte-identical for regression detection), terminal rendering for log-embedded previews, `validate --fail-on warning` as a lint gate, and a WASM bundle with no Node.js dependency — the full "diagrams as agent artifacts" loop no incumbent serves [Inference, Medium]. What would have to become true first: a published npm/crates.io artifact (agents `npm install`, they don't `cargo install --git`), an independent determinism audit across platforms (the HashSet-in-egraph finding shows why), and — unavoidably — a license an agent-platform company can actually sign [Inference, Medium].

8. **The kill test.** The single event that would falsify the core thesis — "a from-scratch Rust Mermaid engine is worth building" — is mermaid-js fixing the large-graph `RangeError` and shipping deterministic, headless batch rendering: that would commoditize FrankenMermaid's two sharpest demonstrated edges (renders what the incumbent cannot; deterministic output) and leave it competing purely on implementation quality, a fight it cannot win at bus factor 1 with no published package [Inference, Medium]. The experimental falsifications are nearly as decisive: an independent rerun of the head-to-head harness on equivalent hardware showing the 871× doesn't reproduce, or a platform-divergence in the golden suite (any OS/CPU-dependent hash) — either would collapse the two pillars (measured dominance, byte-identical determinism) the thesis stands on [Inference, Medium].

---

**Working notes:** clean shallow clone at `~/workspace/.scratch/frankenmermaid-verify/` (HEAD `5e153c1`, 2026-09-21 14:11:48 UTC; verified equal to `git ls-remote` HEAD). Line counts count all `.rs` lines including tests/comments (method stated so the README's unknown method can be compared). Enum-variant counts via body-pattern grep, doc-comment lines excluded. No durable user-facing files created besides this assessment and its versioned intermediates.

**Round 1 revision notes (v1→v2):** ring down Pilot→Explore per ring-down rule (both graders flagged the tension); single ceiling = bus factor 1; NEGATIVE_EVIDENCE row count corrected to 726 (was "2,000+"); codex bot-status labeled inference; unverified npm-downloads figure cut; bead-ID/DSR/effect-CI glosses added; fm-layout single-threaded claim code-verified (zero rayon refs; bd-ryxg refuted-hypothesis comment); WebGPU fallback code-verified (`WEBGPU_RENDERER_IMPLEMENTED: bool = false`, lib.rs:163); claim 19 softened to partially demonstrated; §4.5 restructured crash-first; next-step #4 replaced with human-preference Turing test; fm-cli composition breakdown added; decision-ledger emission point (fm-core→fm-layout→fm-cli) added; time-to-mainstream single-valued at 2; hook "provably" defense strengthened; Quick Links gained scripts/headtohead/ + showcase-staleness note; §4.10 "verification-from-assertion" labeled aspirational; d2 peer differentiator sharpened.

**Round 2 revision notes (v2→v3):** §4.10 hardened with observable movement mechanisms per component (right-move and left-move events, not hopes); hook audit gains the macro-expansion clause (`#![forbid(unsafe_code)]` closes the token-census hole); test-count method clarified (2,520 `#[test]` in crate source; integration tests counted by lines); 512-job row's "Same caveat" made self-contained; contributors row re-tiered (API verifies counts, not humanity).

**Round 3 revision notes (v3→v4):** Q2 "stale" → "size-mismatched" (mismatch direction unverified); weakness 6 "documented fallback" → code-verified wording; TRL row gains the why-6-not-5-or-7 clause.

**Round 4 revision notes (v4→v5):** §4.8 gains the bead census (1,125 beads, ~95 open / ~1,028 closed, ≈91% close rate) with the `.beads/` corruption-recovery artifacts disclosed, plus the install.sh distribution one-liner (source-only, builds from git).