FrankenEngine: A Native Rust Runtime That Treats Extension Code as an Adversary

The Problem: Extension Runtimes That Cannot Be Audited

FrankenEngine addresses a specific failure class: when you embed a JavaScript or TypeScript extension system, you usually pull in a binding to V8, JSC, or QuickJS. That binding brings megabytes of upstream C++ or Zig code that sits outside any capability or information-flow control (IFC) algebra you define. The README argues that retrofitting type-safe authority membranes around such bindings is structurally lossy. FrankenEngine's answer is to avoid bindings entirely. The core runtime is native Rust with `#![forbid(unsafe_code)]`, and it owns the pipeline from parser to scheduler. The target user is an engineer building a host that runs third-party extensions under adversarial conditions, where a malicious or buggy extension must not compromise the host, and where every high-impact decision must be reproducible after the fact.

Four Constitutional Rules and How They Compose

The project is organized around four rules, each tied to a failure class. First, native-only core execution: no V8/JSC/QuickJS bindings, with IFC labels computed at an intermediate representation called IR2, and capability checks gating every hostcall edge. Second, deterministic replay: the runtime captures the IR3 program, policy snapshot, model snapshot, evidence stream, and randomness transcript, so a high-severity decision can be replayed byte-for-byte. Third, signed evidence for containment: every evidence entry is Ed25519-signed with the originating runtime's key, and chained `prev_hash` fields make retroactive edits detectable. Fourth, claim-language constraints: a gate script checks the README's wording against a matrix, rejecting absolute-superiority terms like `guarantees` or `unbreakable` unless backing artifacts exist. These rules compose: a containment action is both replay-anchored and signed, so a counterfactual replay under a different policy snapshot produces signed evidence of what would have happened.

Getting It Running: Commands and Artifacts

The first published release is v0.1.0, dated 2026-05-29. Prebuilt `frankenctl` binaries ship for Linux x86_64 and macOS Apple Silicon via GitHub Releases, with a checksum-verified `curl | bash` installer (`install.sh`). On other platforms, the installer falls back to a source build. The README states that the standalone source/release build resolves only workspace and registry sources and requires no `/dp` sibling checkout. To verify claims, you run `./scripts/run_claim_to_proof_matrix_gate.sh ci`, which checks the README against `docs/claim_to_proof_matrix_v1.json`. The artifact bundle includes a `run_manifest.json` with schema id, host facts, content hashes, and operator-verification commands. Note that current `main` stages `frankenengine-core` and `frankenengine-engine` at an unreleased 0.2.0 compatibility boundary, so if you build from `main` you are not getting the tagged release.

The Claim-to-Proof Matrix: A Gate That Polices Its Own README

One of the most unusual features is the claim-to-proof matrix. The project maintains a JSON file (`docs/claim_to_proof_matrix_v1.json`) that assigns each claim a state: OBSERVED, TARGETED, or HYPOTHESIS. The gate script `run_claim_to_proof_matrix_gate.sh` fails if a README sentence uses wording stronger than the allowed state for that claim, and it emits exact `downgrade_text` for violations. For example, forbidden terms like `guarantees`, `proves`, or `>=Nx faster` require linked artifacts. This is a genuine mechanism, not a style guideline. The README itself is the test subject. The project claims that CI enforcement is not yet established, and automatic re-execution of every producer is not established either. So the gate works when you run it, but there is no proof it runs continuously.

Advisory-Only Automation and the Shadow Daemon

The README explicitly states that automation surfaces ship in advisory-only mode. The shadow daemon and related automations cannot execute live mutations or production deployments until adoption gates are verified green. This is a deliberate containment choice: even if the runtime is compromised, the daemon cannot take destructive action. The documentation points to `docs/SHADOW_DAEMON_PROOF_STATE.md` for the current proof state. This is a limitation if you expect turnkey automation, but it is also a honest boundary. The project is not pretending to be a product. The README says plainly: 'This is research-grade infrastructure, not a packaged product.'

What the Material Does Not Tell You

The README is dense with proof-bundle identifiers and wave names, but it is thin on operational details. There is no documentation of the actual API surface of `frankenctl`, no example of writing a policy, and no description of the extension API that a JavaScript workload would call. The repository layout suggests a `frankenengine-core` and `frankenengine-engine` split, but the README does not explain how they interact. The license is NOASSERTION, which means you cannot assume any rights to use, modify, or distribute the code. That is a legal red flag for adoption, though this is not legal advice. The last push is from May 2026 and the release is v0.1.0, so the project is young and the maintenance cadence is unknown.

Alternatives and the Core Difference

The obvious alternative is a binding-led runtime like Deno or Node.js with a sandbox such as `isolated-vm` or a WebAssembly-based runner like Wasmtime. The difference in approach is fundamental. Binding-led runtimes embed a mature JS engine and then wrap it with permissions. FrankenEngine rejects that model entirely, arguing that the engine's unsafe C++ code is outside the capability algebra. Wasmtime, for example, runs WebAssembly bytecode in a sandboxed environment, but it does not run JavaScript directly unless you compile JS to Wasm, which is a different execution model. FrankenEngine's approach is to implement the parser-to-scheduler semantics in Rust, so that IFC labels and capability checks are part of the core, not retrofitted. That is a meaningful architectural difference, but it also means FrankenEngine must reimplement a JavaScript runtime, which is a massive undertaking and likely explains why it is research-grade.

Maintenance and Upgrade Cost

The project is at v0.1.0, and the README notes that `main` stages an unreleased 0.2.0 compatibility boundary. That means the API is not stable, and upgrading from v0.1.0 to a future release may require changes. The CHANGELOG.md is described as the evidence trail, but the README does not summarize upgrade steps. The claim-to-proof matrix gate is a maintenance burden: every README change must be checked against the matrix, and the gate script must be run manually or wired into CI. The project itself admits that continuous CI enforcement is not established, so you would need to set that up yourself. The license being NOASSERTION is the biggest maintenance risk: you cannot plan for long-term use without clarity on your rights.

Editorial conclusion

Adopt FrankenEngine if you are building a policy-critical extension host where replayable decisions and signed containment evidence matter more than ecosystem maturity, and you are willing to treat the project as research-grade. Do not adopt it if you need production support, a stable API, or a license you can rely on, since the repository declares NOASSERTION. Before committing, verify the claim-to-proof matrix freshness, run the gate script yourself, and confirm that the v0.1.0 release artifacts match the documented checksums, because the project explicitly labels many promises as TARGETED or HYPOTHESIS rather than OBSERVED.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes