Should you use it?
The demo, yes — as an evaluator, it really does run the engine in your browser, and that is still rare.
01 · What it is
What this is, and why it matters
This brief is about a website, not a program — and that is the point. The FrankenMarkdown engine (the document renderer from the previous brief) has a marketing and demo site at franken-markdown.com: a single-page scroll narrative plus a two-pane playground where you type Markdown and get HTML and PDF back. source source It matters to this program because it is the engine's credibility surface — the place an evaluator goes to decide whether the engine's claims are real — and because it is a working experiment in verifiable marketing: a product page whose numbers are meant to re-derive from its own tree, rather than merely assert.
The site's central claim is also its central piece of engineering: the playground doesn't simulate the engine, it is the engine: the actual Rust core, compiled to WebAssembly, running in a module Web Worker off the main thread, with result bytes transferred zero-copy back to the page. Most "live demo" marketing is a screenshot with extra steps. This one is evidence, executable by any visitor.
Why does a website belong in a research program about Rust rewrites? Because the program's rulebook assigns web properties to the Monitor ring explicitly: support infrastructure for the credibility story, not advancement candidates. The verdict on this one was always going to be about the pattern, not the page. And the pattern has a twist: the self-audit machinery drifted from what it ships.
02 · Why build it
Why this shape, and why it almost works
The maintainer's stated rationale: renderer demos usually cheat. A canned screenshot, a server that renders for you, a JavaScript lookalike that is not the real engine. "None of that proves anything about the actual renderer." So the site is static (no backend, no analytics, no CDN scripts: zero external URLs in the tree), fully self-hosted, and the demo carries the real binary. Share links pack the document into the URL's # fragment (deflate-compressed, base64-encoded; a format the assessor proved by decoding a real share URL, not just reading the code), so sharing never touches a server, and the privacy property holds even if you distrust the operator.
Around the demo sits the credibility apparatus: a "Lab Notes · Honest scar tissue" strip confessing partial CommonMark coverage and the maintainer's own stale-deploy incidents; a cryptographic receipt for the engine artifact (SHA-256 and byte count, re-computable with sha256sum); a verify:live script that SHA-256-compares every production asset against the local tree. Content, not headers, so edge-cache staleness can't hide; and a 30-check headless end-to-end suite plus stress and browser smokes. For a marketing site, this is unusually serious plumbing.
The counter-argument, and it is the whole story of the brief: none of the verification runs on its own. There is no CI (continuous integration: automated checks that run on every change) in this repo. No .github directory at all; every suite is a manual bun run incantation. The README's testing table reads as a gate and is a set of manual commands. The Lab Notes strip is hand-maintained copy. And a self-audit apparatus with no automation behind it is a confession waiting to go stale.
03 · What was built
What the project actually built, and where the self-audit broke
What verifies is solid. The worker protocol is real: render-worker.js imports the versioned WASM build and speaks a documented protocol. The share format is exactly as documented: a 202-character payload decodes to the documented Markdown. Self-hosted fonts measure 88,660 bytes against the claimed "87 KB." The 0.3.5 artifact receipt re-derives exactly on SHA-256 and byte count. This is a site whose mechanics are checkable, and they check out.
What doesn't is currency. And the failure is poetic, because the component whose job is honesty is wrong about every version number it names. The Lab Notes strip says the page runs engine 0.3.5; the pinned tree wires in 0.4.2; production serves 0.4.1; npm installs 0.4.4; the engine's releases reach 0.4.5. The live page contradicts itself: its header strip says "Renderer v0.4.1 in this page" while its body copy still says 0.3.5. The README's deploy section is two engine bumps stale. source The "28-check" e2e suite has grown to 30 checks without the docs noticing.
Then the kill test, which the assessor ran rather than hypothesized. verify:live against production reports 8 stale assets, exit nonzero, and the live WASM wrapper and glue match no committed tree: production pairs the 0.4.2 binary with glue from a working tree that exists nowhere in the repo. Manual deploys mean the repository cannot regenerate production's bytes; there is no deploy provenance at all. Meanwhile the repo carries six versioned WASM trees (~23 of its 28 MB), five of them dead weight. And two different binaries both wear the 0.3.5 label, with no manifest saying which one production served. "Try it here, install it there" evaluates one engine and delivers another.
The uncomfortable summary: a billboard with excellent plumbing and no plumber on schedule. The verifiability story rots the moment the checks stop being run, and with no automation, "stop being run" is the default state.
04 · Where it stands
Where it stands
In our program's terms: TRL 8, NODUS ring Monitor. In plain English: it is a finished, deployed, live artifact. The demo works, the patterns work, and the plumbing is sharper than most teams' deploy verification. But it is support infrastructure, not an advancement candidate: there is nothing to pilot here, only something to learn from. Monitor is the rulebook's website bucket, and this earns it independently.
Technology readiness
13579
TRL 8 on a 1-to-9 scale.
NODUS ring
MonitorExplorePilotInvest
The program’s adoption ring for this project.
Verdict key
- NODUS ring
- Monitor: Websites, retired artifacts, and plan-stage work.
- TRL
- Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 8.
- CI
- Continuous integration: the project’s automated checks, run on every change.
- The pin
- The exact commit the assessment was pinned to. “At the pin” means as of that commit.
Evidence tiers
- Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
- Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
- Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
- Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
- Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.
What this verdict rests on. Tier labels are the assessment packet’s own annotations.
- Tier 1 · Verified: The playground really is the wasm engine (import graph and protocol inspected); a real share URL decoded; the 0.3.5 receipt re-derived on SHA-256 and byte count; the live site read; no CI in the repo (no
.githubdirectory at all). - Tier 3 · Maintainer claim: The wasm binary was never executed; the 30 e2e checks were never run.
- Tier 4 · External: No independent reproduction of anything on the page is known.
- Tier 5 · Inference: The Monitor ring: the program’s website bucket.
Should you learn from it?
Yes — the patterns, not the page.
verify:live (deploy verification by content-hash rather than header-poll, with the transitive closure of every referenced asset computed from the code), the fragment-share privacy architecture, the versioned-asset discipline, the Lab Notes strip as negative-evidence marketing. All of it is copy-paste adoptable at trivial cost. These are the patterns the program should import for presenting the other 43 repositories' results.
What would change the verdict, in order
- it stays in Monitor regardless (that's the bucket for websites), but the drift class is mechanically fixable, and each fix is observable: a scheduled workflow running the e2e suite and
verify:liveagainst production - the status strip generated from the wired WASM version at deploy time instead of hand-maintained
- a pruning policy for dead WASM trees
- a version manifest binding each binary to its engine commit.
05 · What it teaches
What this teaches about building with agents
The transferable lesson is about honesty as infrastructure, and it cuts two ways, both relevant to agent-built systems.
The positive half: make your claims executable. verify:live is exactly the kind of artifact the agent era rewards: a 67-line script that any human or agent can run to re-derive the site's deployment claims from scratch. An agent evaluating this engine doesn't have to trust the marketing; it can run the check. If you're building for a world where agents evaluate your work, "here is the script that proves it" beats "trust our landing page" every time. The site courts AI agents explicitly (an "Agent-First CLI" section, machine-readable capability endpoints), and the verifiability pattern is the one part of that pitch that actually delivers.
The negative half is the warning: a self-audit apparatus needs a sensor, not just a confession. The Lab Notes strip confesses weaknesses beautifully, and is two engine versions stale, because it's hand-written copy. The verification suites exist. Nothing runs them. The pattern this site demonstrates, against its own intentions, is that transparency content decays exactly like marketing content unless it is generated rather than written. For anyone directing agents: don't ask the agent to write the status strip. Ask it to build the script that generates the status strip from the artifacts, and fails the deploy when they disagree. A confession you have to remember to update is just marketing with a guilty conscience.
(The sharpest irony, disclosed plainly: the page courts AI agents as users while its license bars the two frontier labs, and anyone acting for them, from even analyzing the site's code. The likeliest agent-evaluators are named Restricted Parties.)