FrankenSim.org The Marketing Site That Runs Its Math in Your Browser

01 · What it is

What this site is, and why it matters

Most project sites for deep systems are brochures: screenshots, typed statistics, performance claims you take on faith. FrankenSim.org is different in one specific way. source It ships 48 numerical kernels compiled to WebAssembly, so visitors execute the project's actual math in their browsers instead of reading about it: thirty lab demos across three tiers, ten end-to-end campaign showcases, and three flagship pipelines, all calling one shared worker that runs the compiled Rust off the main thread.

This matters because FrankenSim's entire pitch is evidence over assertion: "show, don't claim." A screenshot-based site would actively undermine it. The closest established pattern is DuckDB-WASM, which powers a small ecosystem of in-browser SQL playgrounds with no server behind them. FrankenSim's site applies the same idea to certified numerical kernels, which nobody else is doing as marketing.

02 · Why build it

Why build it this way?

The maintainer's stated case: the person deciding whether FrankenSim's "certified" language is real or marketing does not need another paragraph. They need to watch a kernel run. The site collapses time-to-first-witness to one page load, replacing a clone, a toolchain, and a build. And the wiring is in the tree: every demo component invokes the shared hook, 45 of the 48 engine exports are exercised by the fleet, and no demo fetches data from anywhere. There is no network path to fake with.

The counter-argument is in what the tree lacks. "The same bytes the native build runs" is the site's loudest claim, and it is unfalsifiable as shipped: no parent-repo commit hash, no build log, no reproducible-build attestation links the vendored 936 KB blob to any source. A visitor cannot distinguish the real kernels from lookalikes. And the parent project's README never mentions the site. The front door is not linked from the house.

03 · What was built

What the project actually built

A Next.js site in strict TypeScript (227 files, about 65,000 lines) with eleven routes. Every demo call routes through one module-level singleton Web Worker, with results posted back as zero-copy typed arrays. The performance architecture is documented in the repo's agent manual down to animation-frame budgets and WebGL context disposal. Around the demos: twenty bespoke visualizations for the hard concepts, a 1,082-line single source of truth for copy and content, and a 39 MB vendored issue-graph viewer carrying a 16 MB SQLite database of the project's issues.

Three findings matter. First, the mechanism claims all verify: all 43 demo components actually invoke the kernel-call function, not merely import the hook. Second, the scaffold fossils. The changelog's six entries all link to commits in the sibling asupersync_website project, package.json still names the package asupersync-website, and there is no LICENSE file anywhere despite the README's one-word "MIT." Third, staleness is admitted but uninstrumented: the README's own Limitations section confesses the stats scripts don't run at deploy time, the repo description still says "20 kernels" after the count doubled, and nothing has been committed in 32 days. source source source

04 · Where it stands

Where it stands

In the program's terms: TRL 8, NODUS ring Monitor. The Rulebook places websites in the Monitor ring, and this one's value is entirely derivative of the parent workspace.

What would change the verdict, in order

05 · What it teaches

What this teaches about building with agents

Agents are excellent at writing sentences and adequate at wiring mechanisms. This site has both, and the assessment's counts prove the wiring is real. But agents also generate provenance claims ("same bytes," "cannot be faked") that nothing in the artifact backs up, because prose is cheap and provenance is work.

The transferable lesson: provenance is a record, not a sentence. When your agents produce marketing copy about their own builds, gate the claim on the checkable anchor — a hash, a commit SHA, a build log — not on the sentence's confidence. The assessment packet recorded the anchor itself (the SHA-256 of the vendored blob) precisely so the claim can be falsified in one rebuild. That is the move to copy. Before an agent's "cannot be faked" ships, make it publish the one number that could prove it wrong.