# FrankenSim Website — RULEBOOK v1.0 Assessment Packet v8

**Repository:** `Dicklesworthstone/frankensim_website` · **Language:** TypeScript [GitHub API, High] · **Pinned commit:** `e179bafc123eb45bcd040b5a16a098b0125e4629` (2026-08-21 14:46:44 -0400, [Git-observed, High]) · **Last push:** default-branch HEAD is the pin (2026-08-21); GitHub API `pushed_at` reads 2026-09-04T02:32:10Z — a dangling push event (a since-deleted branch or force-pushed-away ref), since no 09-04 commit exists on `main` [Git-observed + External, High] · **Scope:** the pinned commit only, not HEAD. No tags, no GitHub Releases [External, High].

**Method (analyst):** shallow clone at the pin under `~/workspace/.scratch/fsw/repo` (227 tracked files [Counted, High]); history deepened to 35 commits (2026-07-09 → 2026-08-21) for authorship/velocity — all 35 authored by Jeffrey Emanuel <royalchinchillas@gmail.com> [Git-observed, High]. Read: README.md verbatim (198 lines), AGENTS.md, CHANGELOG.md, `package.json`, `public/fs-wasm/worker.js`, `lib/use-fs-wasm.ts`, `components/wasm-lab.tsx` (tier registries), all 43 demo-component filenames; grepped every demo component for `useFsWasm` usage; counted `fs_wasm.js` exports (48 functions + `engine()`); measured `fs_wasm_bg.wasm` at 935,556 bytes; counted 109 unique `fs-*` names in `lib/content.ts`'s atlas and 10 `e2eCampaigns` keys mapping to the 10 campaign components; fetched frankensim.org, /lab, /e2e, /beads as rendered text 2026-09-22; GitHub REST API for stars/forks/description/license/push dates/fork status; HTTP 200 confirmed for all Quick-Link URLs 2026-09-22. **Not done:** never ran `bun install`/`bun dev`/`bun run build`; never executed a WASM demo in a real browser (WebAssembly/WebGL behavior is README- and copy-claimed, not executed); never reproduced the wasm-bindgen build from the FrankenSim `fs-wasm` crate (that crate is not in this repo); no independent download/run of the site; the deployed commit behind frankensim.org is unknown (Vercel deploy provenance unestablished).

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

---

## Hook

A Next.js marketing site that ships 48 wasm-compiled numerical kernels as a 936 KB WebAssembly blob [Counted, High], so visitors execute the math in their browsers instead of reading about it. And the same repo's CHANGELOG documents a different project: all six entries link to `asupersync_website` commits, `package.json` is still named `asupersync-website`, and no LICENSE file exists anywhere despite the README's one-word "MIT." [all Code-verified, High].

## TL;DR

- **What it is:** The marketing + documentation site for FrankenSim (the parent Rust simulation workspace), live at frankensim.org [Verified, High]. Next.js 16 / React 19 / strict TypeScript / Tailwind v4 / Three.js, Bun-only toolchain. 227 tracked files, ~65.5k lines (47,298 TSX + 1,893 TS + 12,883 JS — the JS is mostly the vendored beads viewer's graph/viewer code, not the WASM glue) [Counted, High].
- **Strongest evidence:** The "live kernels" claim is structurally corroborated, not just asserted — all 43 demo components (30 Lab across three tiers + 10 E2E campaigns + 3 flagship pipelines) route through a single shared Web Worker (`lib/use-fs-wasm.ts`, module-level singleton), every component verified to actually invoke `call<…>(…)` (not merely import the hook), 45 of 48 exports exercised, and no `fetch(` anywhere in the demo fleet [Counted, High]; the /lab, /e2e, /beads routes all resolve live [Verified, High]; 6 frontier demos import Three.js exactly as claimed [Counted, High]; 20 concept-visualization components [Counted, High]; a candid Limitations section admits the deployed stats can go stale [Maintainer claim, High].
- **Strongest doubts:** The license is asserted, not granted — "MIT." appears as one word in the README and the footer says "MIT License," but there is **no LICENSE file** in the repo and the GitHub API `license` field is null, so the site's legal state is default copyright, not MIT [Code-verified + External, High]; the CHANGELOG is a fossil from the sibling `asupersync_website` project (six entries, all linking there) [Code-verified, High]; there is no CI at all [Code-verified, High]; the "same bytes the native build runs" claim has no hash linkage between the vendored `.wasm` and the parent repo's `fs-wasm` crate source [Code-verified, High]; the repo has been untouched for 32 days (pin 2026-08-21) [Git-observed, High].
- **NODUS ring: Monitor** [Inference, High] — the Rulebook's ring rules name websites as textbook Monitor. TRL 8 (deployed, serving — §4.9). Value is entirely derivative of the parent FrankenSim workspace.

---

## Quick Links

Pin-relative links (`blob/e179bafc123eb45bcd040b5a16a098b0125e4629`); every URL below returned HTTP 200 on 2026-09-22 [Verified, High].

1. [Repository](https://github.com/Dicklesworthstone/frankensim_website)
2. [README](https://github.com/Dicklesworthstone/frankensim_website/blob/e179bafc123eb45bcd040b5a16a098b0125e4629/README.md)
3. [Live site](https://frankensim.org) — serving 2026-09-22
4. [The Lab (30 live kernels)](https://frankensim.org/lab) — serving 2026-09-22
5. [E2E campaigns](https://frankensim.org/e2e) — serving 2026-09-22
6. [Beads project-graph viewer](https://frankensim.org/beads) — route resolves; analytics cards rendered empty-state strings in the text fetch (client-side SQLite WASM viewer; data rendering unestablished)
7. [Singleton worker + WASM hook](https://github.com/Dicklesworthstone/frankensim_website/blob/e179bafc123eb45bcd040b5a16a098b0125e4629/public/fs-wasm/worker.js)
8. [Parent workspace (FrankenSim)](https://github.com/Dicklesworthstone/frankensim) — the kernel this site markets; assessed separately
9. *No CI workflows exist in this repo — there is no Actions page to link.* [Code-verified, High]
10. *No LICENSE file exists — there is no license link to give.* [Code-verified, High]

---

## Did You Know

The site was scaffolded from the maintainer's *other* project site, not the FrankenSim workspace: `package.json` still names the package `asupersync-website`, and `CHANGELOG.md` (six entries, "newest first") opens with a 2026-03-16 framer-motion cursor fix and links every entry to `Dicklesworthstone/asupersync_website` commits — none of the six entries describes this repo. The GitHub API reports `fork: false`, so this is copy-paste lineage, not a fork; the fossils were simply never renamed. [Code-verified, High on the file contents; External, High on fork:false]

---

## Franken-worthy next steps

1. **Hash-link the "same bytes" claim.** The site's strongest pitch — demos run "the same bytes the native build runs" — is asserted with no checkable linkage. This packet records the anchor: SHA-256 of `public/fs-wasm/fs_wasm_bg.wasm` at the pin is `d4e3461ab091f8c8d1f78285f7d8214b5319166e423304a00404433710f46232` [Counted, High]. Rebuild `crates/fs-wasm` from the parent repo at its recorded source commit and compare. *Done when:* the rebuild hash matches (claim 3 verified) or doesn't (claim 3 drops to *disproven*). Falsifiable, and it applies FrankenSim's own Gauntlet ethos to its own evidence vehicle. [Inference, High — process proposal]
2. **Fork-fossil audit across the suite.** Grep every FrankenSuite marketing/site repo for `asupersync_website` remnants (package names, changelogs, comments, README links) — this packet found three in one repo without trying. *Done when:* a per-repo table of remnant counts is published; zero remnants everywhere falsifies the "one-off scaffold slip" theory. [Inference, High]
3. **Watermark the stats with the parent commit.** The README admits deployed stats can go stale (scripts need a local checkout). Change `compute-stats.mjs` to stamp the FrankenSim source commit SHA into `lib/content.ts` and render it ("computed from FrankenSim @ `abc123`, 2026-08-21") next to the hero numbers. *Done when:* the live site's watermark disagrees with the parent's HEAD in an observable way, turning staleness from an admitted risk into a visible metric. [Inference, High]
4. **Run the license-assertion audit suite-wide, starting here.** This packet found a README that asserts "MIT." with no LICENSE file and a null API license field. Generalize the check: for every FrankenSuite repo, compare the README/footer license assertion against the actual LICENSE file and the API `license` field. *Done when:* a per-repo table shows assertion-vs-grant-vs-API for all 44 repos; this repo either gains a LICENSE file (API field flips non-null) or the copy is corrected. The hypothesis it falsifies: "the website is the only repo where the license assertion and the license grant disagree." [Inference, High]
5. **Extract the beads viewer as a standalone artifact.** The 39 MB vendored SQLite issue-viewer (`public/beads/`, incl. 16 MB `beads.sqlite3`) is a whole second product inside a marketing site. Point it at a *different* FrankenSuite repo's beads DB (e.g. FrankenSQLite's) and see if it renders unmodified. *Done when:* it renders another project's graph, or the list of hardcoded FrankenSim assumptions that break is documented — either outcome is a finding about the viewer's generality. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** most project sites for deep systems are static marketing pages — they *claim* the system is fast, correct, and novel, but a reader leaves without ever seeing it do anything, and the impressive parts stay abstract [Maintainer claim, High — README "TL;DR"]. FrankenSim's pitch is unusually evidence-heavy (certified intervals, machine-checked proofs, an epistemic type system), so a screenshot-based site would actively undermine it: the credibility strategy *needs* the claims to be witnessable [Inference, Medium].

**Who feels the pain:** a technical evaluator deciding whether FrankenSim's "certified" language is real or marketing. The site converts that evaluator from a reader into a witness [Inference, Medium].

**Why now:** WebAssembly + wasm-bindgen make it feasible to compile real numerical Rust (not a reimplementation in JS) and run it in-browser off the main thread via a Web Worker — the exact substrate this site exploits [Code-verified, High on the mechanism; the "why now" timing is Inference, Low].

**Why not just link to the parent repo:** the parent is a ~109-crate Rust workspace whose claims require building and running; the site's job is to collapse the time-to-first-witness to one page load [Inference, Medium]. The wiring, however, is one-directional: the parent repo's README (133 KB, fetched 2026-09-22) contains zero mentions of frankensim.org and its GitHub `homepage` field is null — the "front door" is not linked from the house [External, High]. Standalone value is near zero — every route exists to serve the parent's credibility, but the parent does not currently return the favor.

## 4.2 What it is — repo TL;DR

A 227-file Next.js 16 (App Router, Turbopack) site [Counted, High] in strict TypeScript with Tailwind v4, framer-motion, Three.js, and a Bun-only toolchain (`bun.lock` present; `package.json` engines forbid npm) [Code-verified, High]. Eleven routes (the README's diagram lists ten; `/beads` is the eleventh) [Counted, High]. The payload: 30 Lab demos in three tiers (foundations 10, frontier 10, deep 10) + 10 certified E2E campaigns (10 editorial entries in `lib/content.ts`'s `e2eCampaigns`, keys mapping 1:1 to the 10 campaign components) + 3 flagship pipelines — **43 demo components, all 43 calling the shared `useFsWasm` hook** [Counted, High] — backed by one vendored WASM engine (`fs_wasm_bg.wasm`, 935,556 bytes) exposing 48 exported functions plus `engine()` [Counted, High], hosted in a module-level-singleton Web Worker [Code-verified, High]. Around it: 20 bespoke concept-visualization components, a 1,082-line single-source-of-truth `lib/content.ts`, two stats scripts that recompute hero numbers from a local FrankenSim checkout, and a 39 MB vendored beads issue-viewer (16 MB SQLite payload). Commit velocity is low and lumpy: 35 commits across 2026-07-09 → 2026-08-21, with a 30-day gap before the pin and nothing since [Git-observed, High].

One-line verdict: **a genuinely executable marketing site — its strongest claims are wired into the code, not the copy — carrying unacknowledged scaffold debt (wrong changelog, wrong package name, no license file) and a 32-day silence at the pin.** (NODUS: Monitor — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was re-verified against the pinned commit on 2026-09-22.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 30 Lab kernels + 10 E2E campaigns (badge: "lab-40 live Rust kernels") | demonstrated | `wasm-lab.tsx` registries: FOUNDATIONS 10, FRONTIER 10, DEEP 10; `campaign/` 10 components; imports match | [Counted, High] |
| 2 | Vendored WASM engine exposes 48 exported functions | demonstrated | `grep -o 'export function'` over `public/fs-wasm/fs_wasm.js` = 49 lines incl. `engine()`; 935,556-byte `fs_wasm_bg.wasm`, SHA-256 `d4e3461ab091f8c8d1f78285f7d8214b5319166e423304a00404433710f46232` | [Counted, High] |
| 3 | Demos are "the same bytes the native build runs"; "cannot be faked" | partially demonstrated | All 43 demo components import `useFsWasm` **and every one demonstrably invokes `call<…>("kernel", …)`** (zero components import-but-never-call); 45 of the 48 exports are exercised by the fleet, the 3 unexercised being `engine()` (called by the worker itself at init) plus `compensated_sum` and `orr_sommerfeld_max_growth`; no demo component calls `fetch(` — there is no network-data path to fake with [Counted, High]. **But** the Rust source is not in this repo, no hash links the `.wasm` to a parent-repo commit, and no demo was executed in a browser by the analyst | [Code-verified, High on the wiring; the same-bytes linkage is unestablished] |
| 4 | Six Lab demos render in WebGL via Three.js | demonstrated | Exactly 6 `frontier/*.tsx` files import `three` (ga-motor, lorenz, marching-cubes, sdf-raymarch, topopt, wave2d) | [Counted, High] |
| 5 | 20+ bespoke concept visualizations | demonstrated | `components/viz/` holds exactly 20 components (epistemic-colors, gluing-H⁰, obstruction-H¹, two-lane-executor, gauntlet, roofline, …), plus 3 more in `components/spec-explorer/` — "20+" is satisfied with room to spare | [Counted, High] |
| 6 | "109 fs-* crates" / live site "100+ crates" | partially demonstrated (parent-side claim) | README states 109; **109 unique `fs-*` names counted in `lib/content.ts`'s atlas** [Counted, High] — the number is internally consistent, last recomputed 2026-07-22 (commit `23be920`); hero copy deliberately floored to "100+"; currency against the parent repo unestablished — the scripts need `FRANKENSIM_DIR`, and the parent repo is out of this packet's scope | [Counted, High on internal consistency; Maintainer claim, Medium on currency] |
| 7 | Stats are "computed, not typed" / "self-maintaining" | partially demonstrated | `scripts/compute-stats.mjs` + `generate-atlas.mjs` exist with documented `FRANKENSIM_DIR` flow [Code-verified, High]; **but** they do not run at deploy time — the README's own Limitations section admits deployed numbers can go stale, so "cannot drift from reality" (Design philosophy §2) overclaims | [Code-verified, High] |
| 8 | frankensim.org serves the site; /lab, /e2e, /beads resolve | demonstrated | Live text fetch of all four URLs 2026-09-22; hero "v0.0.1 · 100+ crates · pure Rust"; /lab copy matches the 30-kernel claim; /e2e shows 10 campaigns | [Verified, High] |
| 9 | The site is MIT-licensed | **disproven** (as a legal fact) | README "## License\n\nMIT." and footer "MIT License" are text assertions; **no LICENSE file exists anywhere in the tree** and the GitHub API `license` field is `null` — there is no license grant, so the site is not open source under any OSI definition; default copyright applies | [Code-verified + External, High] |
| 10 | Repo description: "20 real Rust kernels compiled to WebAssembly" | stale | API `description` says 20; README/badge/live /lab all say 30–40 — the description lags a doubling of the demo count | [External, High] |
| 11 | Bun-only toolchain | demonstrated | `package.json`: `packageManager: bun@1.3.3`, engines "DO NOT USE NPM"; `bun.lock` present; README "Can I use npm? No." | [Code-verified, High] |
| 12 | No outside contributions accepted | demonstrated | README "About Contributions" states PRs will not be merged directly (author reviews via `gh` with Claude/Codex and decides independently) | [Maintainer claim, High] |
| 13 | CHANGELOG.md documents this repo's history | **disproven** | All 6 entries link to `Dicklesworthstone/asupersync_website` commits (newest 2026-03-16); none describes this repo; `package.json` name is still `asupersync-website`; API `fork: false` — copy-paste lineage, fossils never renamed | [Code-verified + External, High] |
| 14 | Singleton worker: one WASM instance per page | demonstrated | `lib/use-fs-wasm.ts`: module-level `worker` variable, `ensureWorker()` reuses it; comment "a page with ten demos shares one wasm instance" | [Code-verified, High] |
| 15 | No CI | demonstrated | No `.github/workflows/` directory at the pin; no Actions badges in README | [Code-verified, High] |
| 16 | 1,741-issue beads graph integrated at /beads | partially demonstrated | `public/beads/beads.sqlite3` (16 MB) + 39 MB viewer vendored [Counted, High]; /beads route resolves [Verified, High]; but the text fetch rendered empty-state analytics strings, so the live viewer rendering real data is unestablished (client-side SQLite WASM) | [Counted + Verified, High on existence; unestablished on live rendering] |
| 17 | `use-fs-wasm.ts` doc comment lists the exported kernels | stale | Comment enumerates ~16 kernel names; the actual glue exports 48 — the comment dates from the foundations-only era | [Code-verified, High] |
| 18 | Live /lab Tier III copy: "compiling FrankenSim's own async runtime to the browser" | aspirational (site-side; parent-side verification out of scope) | Present in live /lab copy [Verified, High on existence]; no asupersync/async runtime appears in this repo's dependencies [Code-verified, High] — whether the claim holds belongs to the frankensim packet | [Maintainer claim, Low] |

| 19 | Sitemap covers the site's routes | partially demonstrated | `app/sitemap.ts` lists 8 routes — but omits `/lab`, `/e2e`, and `/beads`, the three most distinctive interactive pages; `robots.ts` + OG/Twitter image routes exist, so SEO basics are present but the sitemap's coverage has a hole where the site's value lives | [Code-verified, High] |

**What the inventory says in aggregate:** mechanism claims verify at High confidence (the wiring is all in the tree); *legal and provenance* claims fail (license, changelog, description); *freshness* claims are the admitted weak point (stats scripts, 32-day silence). The packet's v1 draft under-read this badly: it described the README as claiming "40 (30 Lab + 10 E2E)" without verifying component counts, and it read "last push 2026-09-04" from the API while `main` HEAD is 2026-08-21 — the v2 packet re-verified every number from the clone [Inference, High — process note].

## 4.4 Codebase tour

**Topology (227 files [Counted, High]):** `app/` — 11 routes (`page, architecture, kernel, flagships, lab, e2e, epistemics, roadmap, glossary, getting-started, beads`) [Counted, High]; `components/wasm/` — the demo fleet (10 foundations + 10 frontier + 10 deep + 10 campaign + 3 flagship pipeline components = 43) [Counted, High]; `components/wasm-lab.tsx` — the /lab page with three explicit tier registries; `components/e2e-showcase.tsx` — the /e2e editorial layout; `components/viz/` — 20 concept visualizations; `components/spec-explorer/` — the crate-atlas browser; `lib/content.ts` (1,082 lines) — copy, nav, layers, campaigns, glossary, FAQ; `lib/use-fs-wasm.ts` — singleton worker hook; `public/fs-wasm/` — the engine (glue JS + 936 KB `.wasm` + `worker.js`); `public/beads/` — 39 MB vendored issue viewer; `scripts/` — the two stats scripts (657 lines of `.mjs`).

**Data flow, end to end:** page component → `useFsWasm().call(fn, ...args)` → module-singleton `Worker("/fs-wasm/worker.js")` → `import init, * as mod from "./fs_wasm.js"` → `mod[fn](...args)` on the compiled Rust → `Float64Array` results posted back zero-copy (`[result.buffer]` transfer) → canvas/SVG render [Code-verified, High]. Demo rules are documented in AGENTS.md (pause rAF off-screen via `useInView`, no `setState` in animation loops, DPR cap 2, dispose Three.js on unmount, shared scroll-gate freezes all demos while scrolling) — a real performance architecture, not vibes [Maintainer claim, High].

**Dependency posture:** 16 runtime deps, notably `next@16.1.6`, `react@19.2.4`, `three@0.185.1`, `framer-motion@12.33.0` [Code-verified, High]. Conspicuously absent: anything Franken-specific — no asupersync, no FrankenSQLite client, no workspace-internal packages; the only FrankenSim touchpoint is the vendored WASM blob and the `beads.sqlite3` payload [Code-verified, High]. `trustedDependencies: ["sharp", "unrs-resolver"]` — sharp isn't in `dependencies`, so this is inherited config drift from the asupersync scaffold (claim 13's family) [Inference, Medium].

**The beads anomaly:** `public/beads/` is a complete standalone issue-viewer app (own `index.html`, `viewer.js`, `wasm_loader.js`, `coi-serviceworker.js`, `vendor/`, `chunks/`) plus a 16 MB SQLite DB regenerated 2026-07-22 (commit `262e482`: "248 → 1,741 issues") [Git-observed + Counted, High]. At 39 MB it is ~89% of the 44 MB working tree (excluding `.git`) [Counted, High] and is served raw from `/beads` via Next.js static routing. Whether it still matches the parent's current issue count (1,741 was July) is unestablished — another staleness vector [Inference, Medium].

## 4.5 The maintainer's stated case

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

1. **Show, don't claim:** 40 real kernels run live in the browser (30 Lab + 10 E2E), "the same bytes the native build runs," "cannot be faked" because they are the compiled Rust, not JS reimplementations [Maintainer claim, Medium — the wiring is verified; execution was not observed by the analyst and no hash links the blob to parent source].
2. **Concept teaching:** 20+ bespoke visualizations for the hard ideas (epistemic colors, sheaf gluing H⁰/obstruction H¹, the Gauntlet, the two-lane executor) — the site as a pedagogical instrument, not a brochure [Maintainer claim, Medium — components verified to exist; pedagogical quality unjudged].
3. **Self-maintaining numbers:** crate/line/test counts computed from the FrankenSim source by script, "so the site cannot drift from reality" [Maintainer claim, Medium — directly contradicted by the Limitations section's admission that the scripts don't run at deploy time; the philosophy overclaims].
4. **Performance as a feature:** lazy-mounting, scroll-gated rAF, reduced-motion support, DPR caps [Maintainer claim, Medium — the machinery is in AGENTS.md and the code; runtime smoothness unmeasured]. The reduced-motion half is broadly implemented: 79 files reference `prefers-reduced-motion`/`useReducedMotion` [Counted, High] — the README comparison table's "Motion accessibility ✅ reduced-motion throughout" checks out at the code level.

**Benchmark and conformance audit:** the site publishes no *measured* benchmark results of its own demos — the only performance figures anywhere are parent-project *targets* quoted in the homepage copy (two-lane executor "targeting a bounded latency-to-cancel of ≤ 200 µs"; roofline targets "GEMM ≥ 75% of peak, SpMV ≥ 85% of STREAM, LBM ≥ 1.0 GLUP/s") [Verified, High — live homepage fetch 2026-09-22]. Targets are stated so they can be failed, which is honest framing, but a marketing site for a *numerics* project ships zero timing data about what its 48 kernels actually cost in WASM vs native. Reproduction cost of the core claim (live kernels) is one page load; reproduction cost of the *provenance* claim (same bytes) is a wasm-bindgen rebuild from the parent `fs-wasm` crate at the matching commit — a commit the site never names, so the cost is currently unbounded [Inference, High].

**What survives an independent rerun:** the component counts, the export census, the WASM byte size, the route list, the live-site fetches, the license/changelog/description findings — all re-derivable from the pin [Verified, High]. What would not: demo execution behavior (browser-dependent), the "same bytes" assertion (needs the parent source), the beads viewer's live data rendering (client-side WASM).

---

## 4.6 Competitors

The incumbent here is not another company — it is the **default project microsite**: a Next.js/Vite landing page with screenshots, an embedded video, and hand-typed stats. This site beats that default on exactly one axis — executability — and loses or ties on the axes the default optimizes for. It does ship SEO basics (a sitemap, robots, OG/Twitter image routes), but the sitemap omits `/lab`, `/e2e`, and `/beads` — the three pages that carry the site's distinctive value (claim 19) — and there is no freshness automation and no contribution funnel [Code-verified, High on the sitemap hole; Inference, Medium on the rest].

- **The default microsite (Vercel/Next.js templates, Docusaurus, Starlight):** owns the lane by sheer numbers. Wins on: deploy automation (stats that refresh in CI), content velocity (CMS/MDX), SEO, and a contribution funnel [Inference, High]. This site matches none of those — no CI, no CMS, contributions refused — because it is not competing for them; it is a credibility instrument.
- **Adjacent: live-demo project sites** — the pattern "run the real engine in the browser" is established and owned by database tools, not simulation projects: DuckDB-WASM powers a whole ecosystem of in-browser SQL playgrounds (e.g. the `cyyeh/duckdb-web` playground, the Duck-UI Show HN SQL IDE, the awesome-duckdb tool list) [External, Medium — web search 2026-09-22]. FrankenSim's site applies the pattern to *numerical kernels with certificates* — the closest occupant of "executable numerics marketing" is arguably the Julia/SciML ecosystem's Pluto notebooks, which are live but not marketed as evidence vehicles. FrankenSim's site applies the pattern to *numerical kernels with certificates* — the closest occupant of "executable numerics marketing" is arguably the Julia/SciML ecosystem's Pluto notebooks, which are live but not marketed as evidence vehicles.
- **The parent's own GitHub repo** (frankensim): the alternative evidence vehicle — README badges, CI pages, the beads viewer natively. The site's marginal value over the repo is the zero-install witness: no clone, no toolchain, no build [Inference, High]. Sharpener: the parent's 133 KB README never mentions frankensim.org and its `homepage` field is null [External, High] — the site markets the parent, but the parent does not link the site, which caps the site's discovery to direct navigation.
- **Unoccupied lane:** a *provenance-linked* executable site — one where each vendored WASM blob carries its source commit hash and a visitor can verify "same bytes" in one click. Nobody occupies it, including this site [Inference, Medium]. The gap between the site's rhetoric ("cannot be faked") and its mechanism (an unhash-linked blob) *is* the unoccupied lane.

## 4.7 Skeptic's take

1. **[HIGH] The license is theater.** "MIT." in the README, "MIT License" in the footer, zero license text in the repo, API `license: null`. For a project whose parent markets *proof-carrying* artifacts, the website cannot prove its own license. Any downstream user relying on the MIT assertion is relying on a sentence, not a grant [Code-verified + External, High].
2. **[HIGH] "Cannot be faked" cannot be checked.** The anti-fake claim rests on provenance the site never publishes: no parent-repo commit SHA, no build recipe output hash, no reproducible-build attestation for `fs_wasm_bg.wasm`. A visitor cannot distinguish "compiled from the real kernels" from "compiled from lookalike kernels" — the claim is unfalsifiable as shipped, which for an evidence-first project is the sharpest possible irony [Inference, High].
3. **[MEDIUM] The changelog is a fossil and the package name is wrong.** Six CHANGELOG entries, all about asupersync_website; `package.json` name `asupersync-website`; `trustedDependencies` listing `sharp`, which isn't a dependency. Three independent scaffold remnants in one repo say the site was assembled fast from the sibling template and never audited — exactly the drift pattern the site claims its architecture prevents [Code-verified, High].
4. **[MEDIUM] Staleness is admitted but uninstrumented.** The Limitations section confesses the stats scripts don't run at deploy time; the beads DB (1,741 issues, July) ships as a 16 MB binary; the repo description still says "20 kernels" after a doubling. The floored prose ("100+ crates") is the only anti-drift mechanism, and it works by degrading precision, not by maintaining truth [Code-verified, High].
5. **[MEDIUM] 32 days of silence at the pin.** Last default-branch commit 2026-08-21; 35 commits total; nothing between 07-22 and 08-21 either. Sibling repos in this program were characterized in the v1 draft as pushing on ~3-day cadences (not re-verified in this packet [External, Low]). A marketing site that goes quiet while its product ships is either finished or abandoned — and with no CI, no issues, and refused contributions, there is no signal distinguishing the two [Git-observed, High].
6. **[LOW] The doc comment lies about the engine.** `use-fs-wasm.ts`'s "Exported kernels" comment lists ~16 of 48 exports — a reader trusting the comment undercounts the engine by two-thirds. Small, but it is the same README-vs-code drift class the Rulebook treats as a governance signal [Code-verified, High].
7. **[LOW] No measured timings on a numerics marketing site.** The site publishes parent-project performance *targets* (≤200 µs cancel, GEMM ≥75% of peak) but zero measured results for its own 48 kernels — no WASM-vs-native overhead figure, no ms-per-demo. The omission is load-bearing: "show, don't claim" stops at the stopwatch [Verified, High on the absence of measured data; Inference, Medium on the significance].

**Bear-case steelman:** this is a beautiful static artifact of a July 2026 push that its author has already moved past. The kernels are real but unverifiable-as-shipped; the numbers on the live site are refreshed by hand-run scripts against a checkout nobody can see; the license grant doesn't exist; the changelog belongs to another repo; and the last commit is a month old while its parent project keeps shipping. Its rational fate is to slowly desynchronize from the parent — hero stats graying, beads DB aging, description already stale — until the next redesign, because every freshness mechanism requires the one maintainer to remember, locally, to run it. The site's own design philosophy ("the site cannot drift from reality") is already disproven by the site. [Inference, Medium — deliberately uncharitable; the counter-evidence is that the *mechanism* claims all verify, the AGENTS.md conventions are unusually thorough, and commit `89c0a9d` ("remove fabricated week windows; correct phase status") shows the author does self-correct in public.]

## 4.8 Maintenance & succession

**Bus factor: 1.** All 35 commits in the visible history (2026-07-09 → 2026-08-21) are authored by Jeffrey Emanuel <royalchinchillas@gmail.com> [Git-observed, High]; the footer copyright names Jeffrey Emanuel [Code-verified, High]. No succession plan, no second committer, no CI, 0 open issues, 1 fork, 8 stars [External, High]. If the maintainer stops, the site freezes — but unlike a library, a frozen marketing site *decays in place*: the vendored WASM keeps running (it's static), while every number around it goes stale. The failure mode is not breakage but quiet desynchronization — the exact failure the site's philosophy claims to prevent [Inference, High].

**Governance path:** there is none and the maintainer says so plainly — the refusal is reasoned (asymmetric risk-reward, velocity, sanity) and honest [Maintainer claim, High]. For a website this is defensible: the credible route from one maintainer to an institution is that the *parent* project institutionalizes and the site follows as its artifact. What breaks first if velocity decays: the computed-stats pipeline (needs a local checkout + a human run), then the beads DB refresh, then the WASM rebuild against new kernels — the Lab silently becomes a museum of the kernels as of August 2026 [Inference, Medium].

**The rider question (Rulebook §6):** this is the notable *absence* — among FrankenSuite repos, this one carries **no rider at all**, because it carries no license text at all. (Sibling packets in this program describe the FrankenSuite rider as MIT plus a non-OSI OpenAI/Anthropic/affiliates/agents exclusion — not independently re-verified from this repo [External, Medium].) Whether the omission here is deliberate (a marketing site wants maximum shareability) or accidental (the LICENSE file was never copied from the scaffold) is unestablished — the README's bare "MIT." suggests the author believes a grant exists [Inference, Medium].

**The asupersync question (Rulebook §6):** verified absent — no asupersync in `package.json`, no async-runtime dependency of any kind in this repo [Code-verified, High]. The scaffold *name* is asupersync's (`asupersync-website` in package.json, asupersync_website in CHANGELOG), but the dependency is not. The live /lab Tier III copy mentions "FrankenSim's own async runtime" compiled to the browser — a parent-project claim, out of this packet's scope (claim 18) [Maintainer claim, Low].

## 4.9 NODUS factsheet

| Criterion | Scale | Score + one-line justification |
|---|---|---|
| Technology readiness | TRL 1–9 | **8** — deployed and serving at frankensim.org with all routes resolving [Verified, High]; point off TRL 9 because demo execution was not observed by the analyst and the stats pipeline's freshness is admitted-stale |
| Strategic relevance | 1–5 | **3** — central to FrankenSim's "show, don't claim" credibility strategy, negligible outside the FrankenSuite [Inference, Medium] |
| Impact potential | 1–5 | **2** — 8 stars / 1 fork / 0 issues; as a *pattern* (provenance-linked live-kernel sites) moderate demonstration value to others [External + Inference, Medium] |
| Implementation feasibility | 1–5 | **5** — already built, deployed, and serving; the remaining work is hygiene (license file, changelog, description) [Verified, High] |
| Time to mainstream | 1–5 | **5 (shipped)** — the question is maintenance, not arrival; every freshness vector needs a human run [Inference, High] |
| Collaboration potential | 1–5 | **1** — contributions explicitly refused; 0 open issues; 1 fork [Maintainer claim + External, High] |

**Ring: Monitor** [Inference, High]. The Rulebook is explicit — "Monitor is for websites, retired artifacts, and plan-stage work" — and this is a website whose value is entirely derivative of the parent workspace. Nothing here warrants independent investment; the packet's job is to record the site's state so the *frankensim* assessment can cite its evidence vehicle accurately. Ring down, not up.

## 4.10 Wardley placement

- **The website form** (Next.js marketing/docs site): **Product / commodity** — every serious project ships one; Vercel templates have industrialized it. Moves only if the form itself becomes the product (it hasn't). [Inference, Medium]
- **The live-WASM-kernel demonstration** (48 real kernels, singleton worker, zero-copy Float64Array): **Custom-built, edging toward product** — the *pattern* (SQLite-WASM, DuckDB-WASM) is productized elsewhere, but *certified-numerics-as-marketing* is still custom. Moves toward product if the provenance-linking gap (claim 3) gets closed and copied. [Inference, Medium]
- **The vendored beads graph viewer** (16 MB SQLite + full viewer app inside a marketing site): **Genesis** — nobody else ships their issue tracker as a static SQLite artifact inside their homepage. Moves toward custom-built if next step 5 (point it at another repo's DB) succeeds. [Inference, Medium]
- **The anti-drift stats machinery** (compute-from-source scripts): **Custom-built** — hand-rolled, human-triggered; the commodity version is "CI regenerates and commits." Moves to product the day a scheduled job runs it. [Inference, Medium]

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

**[Inference — all of this section]**

**Base case (12 mo):** the site keeps serving; the WASM demos keep working (static blobs don't rot); the numbers gray — hero stats, beads DB, description drift further from the parent, which ships on. A visitor in 12 months sees an accurate *mechanism* wrapped in quietly stale *claims*. No intervention needed for it to survive; intervention needed for it to stay true.

**Bifurcation:** *Upside* — the maintainer closes the five next steps (hash-linked WASM, watermarked stats, real LICENSE, refreshed changelog/description, CI-run stats refresh), turning the site from "cannot be faked (trust me)" into "cannot be faked (check)." The provenance-linked executable site becomes the FrankenSuite's exportable pattern, and this repo is its reference implementation. *Decay* — the parent renames/restructures kernels, the vendored blob stops matching the docs, and the site becomes a museum: still impressive, increasingly fictional. The decay path is the default — every freshness vector currently requires a human to remember.

**24 months:** either the reference implementation (if upside) with 2–3 sibling sites copying the hash-linking pattern, or a visibly stale artifact the parent README quietly stops linking to.

**60 months:** websites don't get 60-month trajectories on their own merits; this one either became infrastructure for the suite's credibility story or was replaced in a redesign. The WASM demos, as static artifacts, will still run in 2031 — the first half-life fact in the packet: **the mechanism outlives the claims.**

**Revisit triggers:** (1) a LICENSE file appears at HEAD (closes the sharpest finding); (2) `fs_wasm_bg.wasm` is rebuilt/replaced (re-verify the export census + hash); (3) any commit after 2026-08-21 (breaks the silence narrative — check what moved); (4) the GitHub description changes from "20 kernels"; (5) a `.github/workflows/` directory appears (the anti-drift machinery becomes real); (6) the parent repo tags a release the site references.

## 4.12 Limitations and open questions

**Not done:** the site was never built (`bun install`/`bun run build` not run — Bun toolchain present on this machine was not exercised); no demo was executed in a real browser, so WebAssembly/WebGL behavior, load performance, and the "REANIMATING KERNELS" experience are unobserved; the wasm-bindgen rebuild from the parent `fs-wasm` crate was not attempted (crate not in this repo; parent commit unnamed); the beads viewer's live data rendering is unestablished (text fetch only); no mobile/overflow check; no accessibility audit; site traffic and visitor engagement are unobservable from outside (no analytics access); the parent FrankenSim workspace's claims are out of scope.

**Open questions that would most change the verdict:**
1. Does `fs_wasm_bg.wasm` at the pin reproduce byte-identically from the parent `fs-wasm` crate at a named commit? (Decides claim 3 — the packet's load-bearing provenance question. The anchor hash is recorded in claim 2: `d4e3461ab091f8c8d1f78285f7d8214b5319166e423304a00404433710f46232`.)
2. Is the LICENSE omission deliberate (shareability strategy) or accidental (scaffold debt)? (Decides whether §4.8's rider-absence is strategy or oversight.)
3. What was the 2026-09-04 push event, given `main` HEAD is 2026-08-21? (A deleted branch, a force-push, or API lag — the repo Events API returned no PushEvents in the visible window, so the event is pruned from view; minor, but the packet asserts the pin is latest.)
4. Does the live /beads viewer actually render the 1,741-issue graph, or does it fail on the SQLite WASM load? (Decides claim 16.)
5. Will the next parent-repo kernel addition trigger a WASM rebuild here, or does the Lab freeze at the August kernel set? (Decides the museum-vs-instrument trajectory.)
6. Which commit is actually deployed at frankensim.org? (Vercel deploy provenance is unestablished — the live /lab Tier III copy could be newer or older than the pin; without it, "the pin" and "the site" are two different artifacts.)

---

## The eight deepening questions (one paragraph each)

1. **Provenance.** The repo records almost nothing about what produced its artifacts: the vendored `fs_wasm_bg.wasm` carries no source-commit SHA, no build log, and no reproducible-build attestation — provenance is a README sentence ("built from the fs-wasm crate"), not a record [Code-verified, High]. The beads SQLite DB is slightly better (commit `262e482` names the regeneration, "248 → 1,741 issues") but still not content-addressed [Git-observed, High]. Making attestation portable would mean stamping the parent commit SHA and the wasm blob's SHA-256 into `lib/content.ts` at build time (next step 3) and publishing the wasm-bindgen command as a checked script rather than README prose — cheap, and it would convert the site's loudest claim into its most checkable one [Inference, High].

2. **The embeddable unit.** The smallest adoptable piece is `lib/use-fs-wasm.ts` (103 lines) + `public/fs-wasm/worker.js` (~40 lines): a ~140-line singleton-worker pattern that auto-exposes every wasm-bindgen export via `import *` with zero-copy `Float64Array` transfer [Counted, High]. Adoption cost is one hook, one worker file, and a wasm-bindgen output dir — no Next.js lock-in (the hook is React-only; the worker is framework-free). The second candidate is the beads viewer, but at 39 MB vendored with a hardcoded FrankenSim-flavored schema it is the opposite of embeddable today — next step 5 is the experiment that decides [Inference, Medium].

3. **Unexercised option value.** The architecture holds three unused capabilities: the stats scripts already compute from source but are never scheduled — a cron/CI trigger away from real self-maintenance [Code-verified, High]; 45 of the 48 exported functions are invoked by the 43 demo components (verified per-component: every component calls `call<…>(…)` at least once; no `fetch(` anywhere in the demo fleet, so no network-data fakery path exists) [Counted, High]; the 3 unexercised exports are `engine()` (invoked by the worker at init, not by demos), `compensated_sum` — the determinism story's own compensated-summation kernel, ironically undemoed — and `orr_sommerfeld_max_growth` [Counted, High]. A "kernel playground" route could expose all 48 generically [Inference, Medium]; and the `engine()` export suggests version introspection the site never displays — a build-info footer could show engine version + source SHA the moment provenance exists [Inference, Medium].

4. **Benchmark honesty.** The site publishes no measured benchmark results of its own demos — only parent-project *targets* (≤200 µs cancel latency, GEMM ≥ 75% of peak) quoted in homepage copy [Verified, High]. The load-bearing numbers are instead *counts* (40 kernels, 109 crates, 48 exports, 6 WebGL demos), and those all survived re-counting at the pin except the repo description's "20 kernels" (stale) and the doc comment's "~16 kernels" (stale) [Counted, High]. For a numerics project, the absence of a single measured millisecond figure anywhere on the marketing site is the dog that didn't bark — "show, don't claim" demonstrably stops at the stopwatch [Inference, Medium].

5. **The governance path.** There is no governance path and the maintainer explicitly rejects the premise: no outside contributions, PRs reviewed-by-proxy at most, bus factor 1, no CI, no issues [Maintainer claim + Code-verified, High]. The credible route to an institution runs through the *parent* — if FrankenSim institutionalizes, the site becomes its communications artifact and inherits governance. What breaks first if the maintainer's velocity decays is the freshness chain in a fixed order: computed stats (needs local checkout + human), beads DB refresh (needs regeneration commit), WASM rebuild (needs parent build + wasm-bindgen), and finally the copy itself — each layer freezing at a successively older date, with the static demos outliving them all [Inference, Medium].

6. **The license as strategy.** There is no rider here to analyze — there is no license text at all, which makes this the FrankenSuite's odd one out: sibling packets in this program describe the suite's standard rider as MIT plus a non-OSI OpenAI/Anthropic/affiliates/agents exclusion (not independently re-verified here [External, Medium]), while this marketing site carries a one-word "MIT." and a null API license field [Code-verified + External, High]. If deliberate, the omission is strategically coherent — a marketing site wants maximum shareability, and a named-party exclusion on the *brochure* would be self-sabotage. If accidental, it's the cheapest fix in the packet. Either way the current state is the worst of both: the *assertion* of MIT without the *grant* of MIT gives downstream users neither the rider's protections nor MIT's permissions — and strictly speaking the site is not open source at all [Inference, Medium].

7. **Agent-era fit.** An agent evaluating FrankenSim would use this site exactly as designed: load /lab, call a kernel through the page's own worker, and read the result — the site is already an agent-callable demo harness in waiting, since every kernel is one `postMessage({fn, args})` away and the worker protocol is 30 lines of readable code [Code-verified, High]. What would have to become true first: a machine-readable kernel manifest (names, signatures, units — the hook's doc comment lists 16 of 48 and is stale) and the provenance hash from question 1, so the agent can cite *which* code it ran. The site is one manifest file away from being the parent project's executable API docs [Inference, Medium].

8. **The kill test.** Rebuild `fs_wasm_bg.wasm` from the parent repo's `fs-wasm` crate at whatever commit the maintainer names as its source, and compare SHA-256 hashes: if they differ, the "same bytes the native build runs" claim — the sentence the entire site is built around — is falsified, and the packet's claim 3 drops to *disproven* [Inference, High]. Runner-up kill test: if the next parent-repo release adds or renames kernels and this repo's blob is not rebuilt within one release cycle, the Lab is a museum and the "live" framing is falsified by neglect rather than by bytes.

---

*Assessment v8 · 2026-09-22 · Pin `e179bafc123eb45bcd040b5a16a098b0125e4629` · Rulebook v1.0 · Analyst method: fresh shallow clone + live fetches; no build, no browser execution, no parent-repo inspection. v3 round-2 fixes: beads share of working tree corrected (39 MB ≈ 89% of 44 MB excl. .git), claim-2 title precision ("exported functions"), sibling-rider descriptions tier-labeled [External, Medium], Events API attempted for the 09-04 push anomaly (pruned, inconclusive), traffic/analytics added to Not-done; v4 round-3 fixes: 16 (not 17) runtime deps, ~3-day cadence claims re-tiered, Q3 examples replaced with grep-verified unreferenced exports (compensated_sum, orr_sommerfeld_max_growth), parent repo verified to never link frankensim.org; v5 round-4 fixes: Q2 line count corrected (~140 lines), claim-5 spec-explorer note, new claim 19 (sitemap omits /lab /e2e /beads), 4.6 SEO sentence refined; v6 round-5 fixes: claim-3 evidence hardened — every component verified to actually invoke call<…> (not just import the hook), 45/48 exports exercised, no fetch( in demos; Q3 rewritten on the counted numbers; v7 round-6 fixes: reduced-motion claim verified (79 files), adjacent DuckDB-WASM pattern grounded via web search; v8 round-7 fixes: SHA-256 of the WASM blob recorded in claim 2, next step 1, and 4.12 Q1 (anchor for the kill test).