# FrankenEngine: a Rust runtime whose README is gated by its own evidence

> A research-grade Rust runtime for adversarial extension workloads, built on four rules: native-only core execution, deterministic replay, signed evidence for containment, and prose that cannot outrun its proof. The claim-to-proof gate is the part other projects could copy.

**Dicklesworthstone/franken_engine** — Native Rust runtime for adversarial extension workloads with deterministic replay, cryptographic decision receipts, and fleet-scale containment.

- Repository: https://github.com/Dicklesworthstone/franken_engine
- Stars: 31 · Forks: 3
- Language: Rust
- License: NOASSERTION
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dicklesworthstone-franken-engine

## No V8, JSC or QuickJS, and forbid(unsafe_code) at the core

The first constitutional rule is native-only core execution, and the stated reason is structural rather than ideological. Binding-led runtimes ship megabytes of upstream unsafe C++ or Zig that sit outside the information flow control and capability algebra the project relies on, so wrapping type-safe authority membranes around them is described as structurally lossy. The mechanism instead is that the lowering pipeline owns parser-to-scheduler semantics in Rust, with `#![forbid(unsafe_code)]` applied. Information flow control labels are computed at IR2, and capability checks gate every hostcall edge. The point is that authority decisions happen at points the project controls, not at a boundary where a third party library already holds memory it never gave up.

## Replay captures five artifacts and fails closed

The second rule addresses forensics. Streaming policy decisions made under wall clock pressure are not reproducible from a postmortem, so forensic causation breaks. The mechanism is a replay bundle that captures the IR3 program, the policy snapshot, the model snapshot, the evidence stream and a randomness transcript, and a coverage gate identified as `bd-2488a` that fails closed unless every high-severity decision in the declared inventory replays byte for byte. Failing closed is the load-bearing word: a missing or divergent replay does not degrade to a warning, it blocks. The rules then compose, since a containment action is both replay anchored and signed, so a counterfactual replay under a different policy snapshot reconstructs what would have happened and the reconstruction is itself signed evidence rather than a footnote.

## Every containment action is Ed25519 signed and chained

The third rule covers containment. An action taken without auditable evidence becomes indistinguishable from misconfiguration, and rolling it back leaves no record that it happened. Every evidence entry is therefore signed with Ed25519 using the originating runtime's key, and each entry chains a `prev_hash` field so a retroactive edit anywhere in the stream is detectable rather than invisible. The bundle that ships alongside carries a `run_manifest.json` holding a schema id, host facts, content hashes and operator verification commands. That last element is what makes the artifact checkable by someone who was not present: the commands to verify are recorded in the evidence rather than remembered by the operator.

## The README is gated, but continuous enforcement is not established

The fourth rule constrains the writing itself, because documentation drifts ahead of evidence faster than evidence is rebuilt and README claims become marketing. A matrix document drives the check: the gate compares this file against `docs/claim_to_proof_matrix_v1.json`, refuses prose whose actual wording state is stronger than the `allowed_state` recorded for that claim, and emits exact `downgrade_text` for the violation. Forbidden absolute-superiority terms include `guarantees`, `unbreakable`, `always`, `proves`, `category-defining` and faster-than claims of the form `>=Nx faster`, each of which requires backing artifacts. The honest caveat sits in the same section: the gate is described as invoked, while continuous CI enforcement and automatic re-execution of every producer are explicitly not established.

## Three qualifiers decide how you may read each claim

Every capability in the project is tagged with one of three qualifiers that carry binding meaning under the runtime charter. OBSERVED means revision bound artifacts and a verification command are linked, and is the strongest wording permitted, though reliance is limited to the artifact's stated revision, environment, inputs and recertification scope. TARGETED means a design goal or SLO is documented but observed proof is not linked yet, so it is a roadmap commitment rather than a current guarantee. HYPOTHESIS covers projected or optional behaviour that must not be read as shipped proof, and dependencies should not be built on it until it promotes. The May 2026 wave of work was largely promotion campaigns moving claims upward through those tiers, including a campaign that wired live proof bundles for every previously hypothesised README claim and shipped a no-mock acceptance drill that rejects fixtures outright. Another promotion controller closed six children at once, covering eligibility composition, a workload regime transfer guard, a promotion control contract, a no-mock replay drill, an operator runbook status item and demotion rollback with safe-mode replay receipts. A separate lane made mock artifacts fail the contract gate, so a simulated result can no longer stand in for a real one. Automation surfaces, by contrast, ship in an advisory-only mode: the shadow daemon cannot execute live mutations or production deployments until its adoption gates are verified green.

## A workspace of ten crates, and one patch block deliberately left out

The workspace lists ten members, including `franken-core`, `franken-engine`, `franken-extension-host`, `franken-metamorphic`, a control plane integration test crate, test support, and three derive crates for deterministic, fixed layout and related macros, all on edition 2024 with resolver 2 and shared dependencies limited to anyhow, thiserror, serde and serde_json. The most instructive part of the manifest is a comment explaining why there is no `[patch.crates-io]` block, removed on 2026-07-25 under `bd-h5cl7`. A patch had redirected a sibling crate to local fsqlite crates, where a patch level bump from 0.1.18 to 0.1.19 shipped a breaking sync to async API. Cargo's 0.x rules admitted the new version silently, 33 sync call sites met Futures, the default build went red, and seven of sixteen OBSERVED claims became unverifiable because their verification commands are default-feature builds. The comment also names the pattern as the same overreach an earlier decision record forbids for persistence policy, which is why the removal is documented rather than quietly reversed, and it warns against reintroducing a patch without reading the bead and a consistency script first.

## Prebuilt for two platforms, twenty six examples, two gaps

Installation offers prebuilt `frankenctl` binaries for Linux x86_64 and macOS Apple Silicon through GitHub Releases, installed with a checksum verified `curl | bash` script, and the bash installer falls back to a source build on other platforms. A PowerShell installer sits beside it at the repository root. The examples directory is numbered and topical, running from a hello world through signed decision receipts, replay demonstrations, capability typed checks, quarantine mesh, revocation gates, flight recorder and a non-exfiltration certificate, with two numbers absent from the sequence, which reads like deliberate removal rather than an unfinished plan. The tree also carries `proofs/`, `artifacts/`, `runbooks/`, `benchmarks/`, `fuzz/` and a `rust-toolchain.toml`, so the repository holds evidence, runbooks and fuzzing harnesses alongside the source rather than treating them as separate concerns. Versioning has one wrinkle worth checking: the workspace manifest still reads 0.1.0, while the current branch stages two crates at an unreleased 0.2.0 compatibility boundary without creating a tag, so a dependency on the compatibility boundary is a dependency on something not yet cut as a release.

## Conclusion

FrankenEngine fits teams that need replayable, auditable containment decisions and can accept research-grade software that its own documentation marks as partly hypothesis. Do not build production automation on the shadow daemon, since the project states it ships advisory-only, and check whether your platform has a prebuilt binary before budgeting time for a source build.

## FAQ

### What is a Frankenstein engine?

This repository has nothing to do with the phrase as a car engine. FrankenEngine is a Rust runtime for adversarial JavaScript and TypeScript extension workloads, licensed as MIT in its workspace manifest and published as v0.1.0.

### Does a Frankenstein engine increase horsepower?

No performance claim of that kind appears here. What the project measures is its own evidence: byte for byte replay of high-severity decisions, Ed25519 signed containment records, and a gate that rejects README wording stronger than the linked proof allows.

### Where is Frankenstein Engine Dynamics located?

The repository does not mention that company. What it records instead is platform support, with prebuilt frankenctl binaries for Linux x86_64 and macOS Apple Silicon and a source build fallback elsewhere.

## Sources

- [Official README](https://github.com/Dicklesworthstone/franken_engine#readme)
- [Project repository](https://github.com/Dicklesworthstone/franken_engine)
- [Release notes](https://github.com/Dicklesworthstone/franken_engine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dicklesworthstone-franken-engine