FrankenSuite research program · A shareable brief

FrankenMarkdown Deterministic Documents Without a Toolchain

A shareable brief from the FrankenSuite research program. Every claim below traces to the assessed repository; sources are linked at the end. Assessment pinned September 22, 2026.

Assessment pinned September 22, 2026 (the assessed commit)·~1,273 words·5 sections·Every claim traceable to a source
Six definitions. NODUS is the program’s four-ring verdict scale (Invest, Pilot, Explore, Monitor) assigned per assessment packet. TRL is technology readiness level, scored 1 to 9 per packet. CI is continuous integration: the project’s automated test runs. The pin is the exact commit the assessment froze on; every claim is evaluated at the pin, not at HEAD. The rider is the license clause withholding all rights, including benchmarking and analysis, from OpenAI, Anthropic, their affiliates, and anyone acting for them. Bus factor is how many people can leave before the project stalls; it is 1 for every repo here.

01 · What it is

What this software is, and why it matters

Everyone writes Markdown. Turning it into something that looks good, a web page or a PDF, is where the pain starts. Markdown itself is only the input format; for PDF you currently bolt on a second stack: Pandoc with a LaTeX distribution (hundreds of megabytes of toolchain), headless Chrome (arbitrary CSS, heavy and nondeterministic), or Typst, the modern fast typesetting system that is winning converts from LaTeX. For Markdown parsing alone, the Rust world already has excellent answers: pulldown-cmark (the fast, safe standard behind mdBook) and comrak.

It matters because documents are infrastructure: CI-generated reports, agent-generated artifacts, reproducible research. And byte-stability matters more than it sounds. If a document pipeline re-renders the same input and gets different bytes, you can't tell a real change from noise. Nobody in the incumbent lane offers that: Typst is not byte-stable by design, Pandoc/LaTeX is a toolchain, Chrome is nondeterministic.

The lane nobody owns is the combination: one embeddable, zero-dependency pipeline from Markdown to HTML and PDF, with byte-identical output every time. That's the pitch.

02 · Why build it

Why rewrite it in Rust?

The maintainer's case is architectural, and it is unusual. The engine library compiles with zero third-party dependencies (verified in the manifests, not asserted), and unsafe code is forbidden twice over (crate-root attribute plus workspace-wide lint). One typed theme model drives both HTML and PDF, so the two surfaces can't drift apart. Byte-stable renders come from SOURCE_DATE_EPOCH support and staged writes. The render core is WASM-first: no filesystem, no fontconfig, no thread or network assumptions, fonts carried as bytes, so the whole engine embeds in a browser via a byte-parity-gated WASM package. On top sits an agent-facing surface: machine-readable capability discovery, stable exit codes, a JSON-RPC MCP server, and a refusal to overwrite your inputs.

The engineering core: supply-chain surface reduced to nothing, memory-safety by compiler rule, and determinism as a designed property rather than a hope. In an era of dependency-tree breaches and AI-generated documents, "no dependencies, same bytes every time" is a legible pitch.

The counter-argument, and it is strong: parsing Markdown is a solved commodity. pulldown-cmark is fast, safe, and already everywhere; comrak is heavier but entrenched. For PDF, Typst is modern and growing fast with a real community, and Pandoc converts everything to everything. The one word in the product description that does the heavy lifting, "ultra-fast," has zero published head-to-head numbers behind it: no throughput figures, no pulldown-cmark comparison, anywhere in the repo. The internal measurement discipline is excellent, but every number is maintainer-generated. And "byte-stable documents" may be a thesis without a buyer: reproducible builds matter for binaries, and nobody has asked for byte-stable invoices.

03 · What was built

What the project actually built

This one ships. Version 0.4.5 is on GitHub with five-platform binaries and checksum sidecars, on crates.io, and on npm as a WASM package; there is a live demo site running the real engine in a Web Worker. The tree is 146,322 lines of Rust across three crates: the engine, a factored zero-dependency font subsystem (fmd-font: TrueType reading, kerning, subsetting, "pure std"), and fmd-math, the clean-room TeX math layout engine that is this suite's most upstreamed component. A 41,000-line PDF writer, Knuth-Plass line breaking, Liang hyphenation, hand-rolled DEFLATE and clean-room Brotli, syntax highlighting across a dozen-plus languages, EPUB output. All hand-rolled, all in-tree.

The two findings that matter are methodological, not typographic. First, claim-discipline: claims.tsv plus a gate script wires every README claim pattern to a machine-checkable capability key and a proof script. Marketing hygiene as CI (continuous integration: automated checks that run on every change): a discipline no incumbent practices. The README cannot drift from the code without failing a check. Second, determinism as mechanism: byte-repeat render gates, SOURCE_DATE_EPOCH, staged writes, a WASM byte-parity gate. That is the property the incumbents structurally don't offer, enforced by scripts.

And the project practices what it preaches. A July "deep review" found the "Knuth-Plass" line breaker was actually a dense quadratic algorithm. One 8,000-word paragraph took 13.5 seconds, and a hostile token hung past a minute. The fix implemented true TeX active-node deactivation: 13.5 seconds to 0.04 (the 330x figure is the maintainer's own before/after), with render-tree and PDF/HTML goldens byte-identical, rejected trials recorded in the commit. Structural honesty, not decorative.

Evidence · CI status

What the project’s own CI said at the pin

the pin = the commit the assessment was pinned to.

  • The README says conformance and determinism are "CI-enforced" — but the only GitHub Actions workflow is named "DISABLED" and hard-switched off, and the engineering doctrine says "never use GitHub Actions for any reason." The gates are real scripts, but "CI" is the maintainer's private build orchestration on his own hosts: unobservable externally.

The uncomfortable findings

Uncomfortable finding

"CI-enforced" currently means "the maintainer runs the scripts." The release pipeline lags the code: npm is at 0.4.4 while the engine is at 0.4.5, and the project's own flagship demo site serves engine 0.3.5. Two minor versions behind on its own billboard. PDF pagination and full PDF/UA accessibility are openly incomplete. CommonMark conformance is 578/652, tracked in the open but trailing the best clean-room parsers. And the license is MIT plus a rider withholding all rights (including benchmarking, testing, and analysis) from OpenAI and Anthropic and anyone acting for them: not open source, and a hard ceiling for a project whose MCP server is built to serve the agent ecosystem those two labs dominate. Independent validation: zero. No third-party benchmark, review, or production deployment anywhere.

04 · Where it stands

Where it stands

In our program's terms: TRL 7, NODUS ring Explore. In plain English: it is built and shipping: real releases, real packages, real demo. Further along the maturity ladder than most of the suite. But the "ultra-fast" word is unmeasured, the CI behind the gates is unobservable, adoption is 104 stars and 151 crates.io downloads with no production use found, there is one maintainer, and the license repels the largest potential collaborators. source source

Technology readiness

TRL 7 on a 1-to-9 scale.

NODUS ring

MonitorExplorePilotInvest

The program’s adoption ring for this project.

Verdict key

NODUS ring
Explore: The default for substantive-but-unproven work.
TRL
Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 7.
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

  1. Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
  2. Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
  3. Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
  4. Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
  5. 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: 146,322 lines of first-party Rust, a zero-dependency root, and forbid(unsafe) — all verified from a fresh clone.
  • Tier 3 · Maintainer claim: No test, fuzz target, or benchmark was executed; WASM parity and determinism rest on maintainer evidence.
  • Tier 4 · External: crates.io 0.4.5 and npm 0.4.4 read from the registries; zero independent benchmarks, reviews, or production deployments found.
  • Tier 5 · Inference: The Explore ring at TRL 7.

Should you use it?

Not yet for a document pipeline that matters.

Unbenchmarked against the incumbents, a one-person project, a license your lawyers will read twice, and a release pipeline that already lags its own code.

Should you learn from it?

Yes — twice.

The claim-discipline gate (every marketed capability bound to a proof) is a rigorous marketing-hygiene mechanism and it ports anywhere. The determinism machinery (byte-stable artifacts from a dependency-free core) is the seed of "reproducible documents" as infrastructure, and the incumbents aren't building it.

What would change the verdict, in order

  1. a published head-to-head benchmark against pulldown-cmark or comrak (converting "ultra-fast" from word to result: the single most fixable gap in the repo), the npm/release lag fixed, any independent benchmark or production deployment, a second maintainer, and any change to the license rider
  2. Every one of those items is observable from outside, which is exactly why the verdict is checkable — the gap to Pilot is a public to-do list
source source

05 · What it teaches

What this teaches about building with agents

The transferable lesson is the claim-discipline gate, and it is aimed directly at the agent era.

The problem it solves is new and getting worse: AI-generated code ships with AI-generated claims, and nobody checks either. READMEs written or polished by agents drift from what the code does within weeks; benchmarks are quoted without the conditions that produced them; "CI-enforced" means whatever the author remembers running. FrankenMarkdown's answer is to make the marketing machine-readable: every claim pattern in the README maps to a capability key the binary itself reports and a proof script that re-derives the number. source When the code changes, the claim either still verifies or the gate fails. Marketing becomes a test suite.

For anyone building with agents: don't review the agent's claims — wire them to proofs. An agent can write a benchmark table in seconds; it cannot fake a claim entry that a script re-derives on every run. And the corollary this project demonstrates is that its own "CI" wording went stale while its gate was real. An unwatched gate is marketing with extra steps.

Evidence

This page cites selected evidence. The full claim-by-claim audit is in the assessment packet.

Open a panel to see what each source evidences. Full claim-by-claim audit.

Full claim-by-claim audit with evidence tiers lives in the program's assessment packet.

The repositorygithub.com/Dicklesworthstone/franken_markdown
README

its README

CHANGELOG

CHANGELOG

check-claim-discipline.sh

LICENSE, and gate scripts (check-claim-discipline.sh

check-determinism.sh

check-determinism.sh

check-wasm-package.sh

check-wasm-package.sh) at the assessed commit

crates.io and npm registry reads (2026-09-22)

crates.io and npm registry reads (2026-09-22)

crates.io listingscrates.io listings

pulldown-cmark and comrak per their crates.io listings

READMEdocumented roles

Typst and Pandoc as described by their documented roles.