FrankenSuite research program · A shareable brief

FrankenNode Trust Machinery for a Language That Assumed Trust

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,243 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 Node.js is, and why its trust model is thin

In 2009, Ryan Dahl released Node.js: JavaScript outside the browser, built on Chrome's V8 engine. It worked. One language across the whole stack, an event loop that handled thousands of connections at once, and npm, the largest package registry ever assembled. Node went on to run an enormous share of the world's servers and build pipelines.

The trade was visible from the start and rarely priced in. Node's default posture is permissive: any package you install can run arbitrary code the moment it lands. For years that was an acceptable background risk. Then the systems built on Node got extension-heavy: build plugins, editor extensions, MCP servers, agent tooling. The attack surface of "install and run third-party JavaScript" multiplied. The security tooling never caught up. Supply-chain scanners flag a compromised dependency after it has already executed. Revocation checks, where they exist, run after the risky action has shipped. Incident reviews try to reconstruct what happened from logs that were never designed for replay.

FrankenNode is a bet that the fix belongs in the runtime, not in a bolt-on scanner.

02 · Why build it

Why build it, and why in Rust

The maintainer, Jeffrey Emanuel, does not fork Node. A fork would inherit exactly the debts he wants to escape. Instead he builds a clean-room platform with an explicit split: the JavaScript execution internals live in a sibling repository (franken_engine), while franken_node owns the trust layer on top: compatibility capture, migration tooling, the extension registry, policy surfaces. The stated rationale is verifiability: a third party can audit the trust claims without auditing the engine internals, and vice versa.

His product charter, ratified February 2026, states the bet in three pillars. Compatibility is table stakes: at least 95% on a targeted corpus. Trust-native operations are the differentiator. Migration velocity is the growth engine, claimed at three times the baseline pattern. The trust-native pillar is the novel part: revocation-first execution, where a risky action consults fresh trust state before it runs; per-extension trust cards carrying provenance, behavior risk, audit history, and revocation state; threshold signatures and capability tokens; every decision emitting a signed receipt chained into an evidence ledger; high-severity incidents exportable as signed bundles that can be replayed and re-evaluated under alternative policies. The timing argument is a fair one: the agent-tooling explosion multiplied the exposed surface faster than runtime security models evolved, Deno showed a permission-gated runtime has a market, and no incumbent ships revocation-first execution plus replayable forensics as a runtime contract.

The counter-argument starts with the map. Node itself is the spec: the project's own compatibility oracle measures against Node, so franken_node cannot beat Node at being Node. It can only chase it. Deno already owns the "secure JS runtime" perception and actually ships. Socket.dev owns the "catch malicious packages" lane with real customers. And the category itself is unproven: the assessment found no demand signal for a trust-native runtime beyond the repository, and the charter's growth-engine pillar (three times the migration velocity) has no measured number anywhere in the tree.

03 · What was built

What the project actually built

The scale registers first: 944,364 lines of Rust source, zero unsafe code under forbid-lints in every workspace member, 146 fuzz harnesses, on the order of 25,000 tests, a 22-row threat model with explicit out-of-scope non-goals and regression anchors on each row. Roughly twenty commits a day from one human.

The evidence machinery is the real subject of this brief:

  • A machine-checkable Honesty Manifest. Seven headline claims bound to a live census, Ed25519-signed, re-verifiable by an independent verifier SDK, with a CI (continuous integration: automated checks that run on every change) gate that fails on drift. The assessment ran the project's own checker against the pinned tree: nine checks passed, zero drifted.
  • A close-condition oracle. Conjunctive gates across compatibility, release policy, and product readiness decide whether the project is shippable. It currently reads RED.
  • Trust cards as data structures. Versioned, hash-chained, signed, evidence-linked records of an extension's identity, provenance, behavioral profile, and revocation state. The Debug output redacts the card hash. Small hygiene, telling.

Evidence · CI status

What the project’s own CI said at the pin

the pin = the commit the assessment was pinned to.

  • The README's own FAQ asks "Is this a drop-in replacement for Node or Bun?" and answers "No." At the assessed commit, all eight CI runs had failed.
  • The asupersync network transport is real code with real performance-budget contracts, and no CI job has ever compiled it.

The uncomfortable findings

Uncomfortable finding

The compatibility corpus sits at 391 of 560 against Node: 69.82% versus the charter's 95% floor. A bare clone does not build without the sibling engine checkout. The advertised "deterministic incident replay" is honestly labeled as replay of a recording, not live re-execution; live re-execution is deferred. The benchmark campaign infrastructure is real: methodology doc, runner, report generator. Its only results are synthetic fixtures showing franken_node beating Node and Bun on every workload. source They are kept as test data for the machinery, and the only thing between sample data and a cited claim is maintainer discipline. A loaded gun the packet flags for the next assessment.

Uncomfortable finding

Two smaller tells are worth keeping. The signed honesty manifest's generated_at field reads 1970-01-01 (epoch zero), so the artifact built to prove freshness cannot date its own attestation. And the CLI's main.rs is a single 35,531-line file: the bus factor (the number of key contributors who could disappear before the project stalls) of one, rendered as code.

Uncomfortable finding

The license is MIT plus a rider naming OpenAI and Anthropic (and anyone acting for them) as forbidden parties, barred even from benchmarking, testing, or analyzing the code.

04 · Where it stands

Where it stands

In our program's terms: TRL 4, NODUS ring Explore. In plain English, the components are lab-validated. The census, the drift gates, the fuzz targets are real. But nothing has seen production, the project's own oracle says it is not shippable, and the license blocks the likeliest evaluators from touching it. Substantive but unproven, with a ceiling.

Technology readiness

TRL 4 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 4.
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: 944,364 source lines, zero unsafe, 146 fuzz targets, ~25k tests counted; the signed honesty manifest re-verified live with zero drift.
  • Tier 2 · CI-observed: CI red at the pin: all 8 runs at the pin concluded failure, per the Actions REST API.
  • Tier 3 · Maintainer claim: Nothing was compiled or executed; the L1 oracle’s 69.82% is maintainer-measured.
  • Tier 4 · External: Zero independent coverage.
  • Tier 5 · Inference: The Explore ring.

Should you use it?

No.

There is no release artifact at the assessed commit (the only release targets an earlier May commit), no independent validation, and one maintainer.

Should you learn from it?

Yes.

The export is the claim-governance machinery: a signed honesty manifest with a machine-checkable drift gate, an independent verifier SDK, a dual-oracle close condition, mutation-adequacy floors. Few software projects ship that kind of self-audit tooling, shipped or not.

What would change the verdict, in order

  1. the compatibility oracle going GREEN at 95%
  2. the rider narrowed or removed
  3. a tagged release at the assessed commit
  4. a second human committer.

Until then, the pattern is adopt the machinery, not the package.

05 · What it teaches

What this teaches about building with agents

The transferable lesson is a governance shape, not a code shape.

The honest move most projects never make is to write down the gate that can say no, then publish the no. FrankenNode's close-condition oracle does exactly that: a formalized merge-vs-ship separation, reading RED, with the RED printed in the project's own README. The honesty manifest extends the same idea to the project's own marketing: every headline number is bound to a census a stranger can recompute, with a gate that fails when the number drifts. Where agents generate claims at the same velocity they generate code, the discipline that matters is not "the agent wrote good code." It is "the tree can catch its own numbers rotting."

There is a hard limit to the lesson, and the packet names it. Every trust anchor in the apparatus (the manifest's signing key, the census script, the drift gate, the SDK test) terminates at the same single human whose claims they attest. It is independent software, not an independent party. The machinery is real. Self-governance is still governance by the governed. Use it to govern yourself, and don't mistake it for a second opinion.

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_node
luisllamas.esluisllamas.es

Node.js history (2009, Ryan Dahl, V8) per luisllamas.es.