# FrankenEngine — RULEBOOK v1.0 Assessment Packet v5

**Repository:** `Dicklesworthstone/franken_engine` · **Language:** Rust [Code-verified, High] · **License:** "MIT License (with OpenAI/Anthropic Rider)" — non-OSI, source-available [Code-verified (license text), High] · **Stars/forks:** 31 / 3 [External, High] · **Pinned commit:** `bff9a4da7059717335926b4bacdbb03d96408a7f` (2026-09-20 21:12:02 -0400, [Git-observed, High]) · **Last push:** 2026-09-21T01:29:53Z [External, High] · **Scope:** the pinned commit only, not HEAD. No tag points at the pin; annotated tag `v0.1.0` (created 2026-05-29) points at an earlier commit `0a4e9db4` [Git-observed, High]; GitHub Release `v0.1.0` (published 2026-05-29, not draft/prerelease, 6 assets: `frankenctl` binaries for aarch64-apple-darwin, x86_64-pc-windows-msvc, x86_64-unknown-linux-gnu + `.sha256` each) targets that earlier tag — no release artifact for the assessed commit [External, High].

**Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/franken_engine/engine` (7,739 paths, verified non-empty); history deepened (blobless) to 402 commits for the authorship sample only — the working tree stayed at the pin. Read: root `Cargo.toml`, all 10 crate manifests, `Cargo.lock` (asupersync edge), `LICENSE` (verbatim), README (all 2,543 lines: status legend, capability table, IFC/capability sections, surface inventory, benchmark/methodology sections), `docs/CLAIM_TO_PROOF_MATRIX_V1.md` + `claim_to_proof_matrix_v1.json` (28 claims, state distribution counted), `docs/RUNTIME_CHARTER.md` (§2, §7 sampled), `docs/ARCHITECTURE_OVERVIEW.md` (digest), `.beads/issues.jsonl` (open/closed counted), `crates/franken-engine/src/capability.rs` (RuntimeCapability enum read), `asupersync_leverage_adoption_gate.rs` + `asupersync_contract_matrix.rs` (headers), `crates/franken-core/src/control_plane.rs` (feature gates), IFC module file list, red-team scenario dir, benchmarks/ layout, `crates/dp/src/lib.rs` (header). Counted: `.rs` files/lines across crates, unsafe keyword sites (comment-excluding method), red-team scenarios, matrix claim states. GitHub API: repo metadata, stars/forks, releases, 23 workflows enumerated, per-job conclusions for native-runtime run #35550128941 (head = pin), 46 native-runtime runs scanned, main-safety/adversarial_fuzz/perf/red-team run histories. Web search for independent coverage. franken_node's `Cargo.toml` + `docs/ROADMAP.md` fetched to verify the substrate relationship. **Not done:** nothing was compiled, no test suite or gate script was executed, no benchmark reproduced, the pin's failing CI steps were not log-dived, line-level authorship attribution (git blame) was not performed, crates.io publication status of `frankenengine-*` packages was not checked. Assessment date: 2026-09-22.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — with flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read); **[CI-observed]** is Tier 2 (seen executing on live CI pages — attests the suite *runs*, not that it is green); **[Maintainer claim]** asserted in README/docs, not independently executed; **[External]** independent sources; **[Inference]** analyst judgment, always labeled. Confidence: **High** (multiple converging sources or direct inspection) / **Medium** (single solid source, plausible) / **Low** (thin evidence, extrapolation).

---

## Hook

A 3.5-million-line [Counted, High], single-maintainer, native Rust JavaScript runtime for adversarial extension workloads — built to run untrusted agent extensions under information-flow control, capability-typed authority, deterministic replay, and Ed25519-signed decision receipts — that is *structurally forbidden from claiming speed*: its own claim-to-proof gate pins throughput at TARGETED while a preserved dirty-worktree bundle the maintainer himself checked in records ~1,000× slower than Node [Code-verified + Maintainer claim, High], and whose license names OpenAI and Anthropic — the builders of the agent systems it targets — as forbidden parties barred from even analyzing the code [Code-verified (license text), High]. This is the infrastructure substrate under `franken_node` [External, High] — the suite's agent runtime — consumed as an optional path dependency behind an `engine` feature flag [Code-verified via franken_node's manifest, High]. Its most defensible artifact may not be the runtime at all but the machinery that refuses to let the README lie: a 28-claim JSON ledger that fails closed when a sentence's wording outruns its evidence [Code-verified, High].

---

## TL;DR

- **What it is:** A from-scratch Rust execution substrate for adversarial JS/TS extension workloads (~3.53M first-party lines / 2,679 `.rs` files across 10 crates at the pin [Counted, High]): hand-rolled parser, four-stage lowering pipeline (IR0→IR3), policy-routed baseline interpreter, IFC lattice + capability algebra enforced at IR2/hostcall edges, deterministic replay with sealed IR4 witnesses, and a signed evidence ledger with transparency log + Merkle Mountain Range (MMR) inclusion/consistency proofs. Single human maintainer (Jeff Emanuel), extreme velocity (~20 commits/day Sep 1–20, 96 on Sep 15 alone [Git-observed, High]).
- **Strongest evidence:** The methodology is the product. A binding claim-to-proof matrix (28 claims: 13 OBSERVED / 8 TARGETED / 7 HYPOTHESIS, each with an owning bead — *bead*: the repo's issue-tracker unit, `bd-<base36>` records in `.beads/issues.jsonl` — artifact path, and verification command [Counted, High]) that gates README wording in CI; zero `unsafe` in library code (the only `unsafe` blocks in the tree are adversarial negative tests trying to forge IFC labels via `transmute` [Code-verified, High]); a 4,537-record bead journal (3,911 closed, 626 open [Counted, High]); deterministic-replay and signed-receipt gates with `repro.lock` partners; and a README that *refuses its own performance claims* — the Node/Bun denominator stays TARGETED because the only measured bundle is a declared non-normative dirty-worktree artifact [Maintainer claim, High].
- **Strongest doubts:** The core CI lane is red at the pin — `native-runtime.yml` run #35550128941 (head = pin) failed all three jobs on test-execution steps, and all 46 recorded runs of the workflow (Sep 16–21) fail — it has never gone green [CI-observed, High]; `quality-gates.yml` and `perf_regression_gate.yml` have **zero runs ever**, and the red-team stability measurement workflow has zero runs [CI-observed, High]; the end-to-end capability-typed TS-to-IR contract — the headline security promise — is TARGETED by the maintainer's own matrix [Maintainer claim, High]; the runtime is candidly ~1,000× slower than Node on the only measured bundle [Maintainer claim, High]; full Test262 conformance is TARGETED with no corpus in-tree [Maintainer claim, High]; the license rider bars the AI labs (and their agents) that are the likeliest evaluators and adopters of an *agent-extension runtime* from even analyzing the code [Code-verified, High]; bus factor 1 [Git-observed, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 4–5 — see §4.9). Substantive-but-unproven is the textbook Explore case: the security machinery is real code with real gates, but there is no independent validation, no production deployment, the core lane is red at the pin, and the rider blocks the likeliest collaborators. Track the methodology (claim-to-proof gating, declassification receipts, e-process guardplane) as the export; the runtime itself is currently un-advanceable while the rider stands.

---

## Quick Links

Pin-relative links (`blob/bff9a4da7059717335926b4bacdbb03d96408a7f`); file existence verified in the pinned clone, workflows/releases verified via the GitHub API, all resolving 2026-09-22 [Verified, Medium]:

1. [Repository](https://github.com/Dicklesworthstone/franken_engine)
2. [README](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/README.md)
3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/LICENSE)
4. [Claim-to-proof matrix](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/docs/CLAIM_TO_PROOF_MATRIX_V1.md) — 28 claims, 13 OBSERVED / 8 TARGETED / 7 HYPOTHESIS at the pin
5. [Runtime charter](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/docs/RUNTIME_CHARTER.md) — the four constitutional rules
6. [Architecture overview](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/docs/ARCHITECTURE_OVERVIEW.md)
7. [Changelog (capability waves)](https://github.com/Dicklesworthstone/franken_engine/blob/bff9a4da7059717335926b4bacdbb03d96408a7f/CHANGELOG.md)
8. [Native Runtime CI](https://github.com/Dicklesworthstone/franken_engine/actions/workflows/native-runtime.yml) — 46 runs; run #35550128941 at the pin: all 3 jobs failed
9. [Main Safety CI](https://github.com/Dicklesworthstone/franken_engine/actions/workflows/main-safety.yml) — 440 runs; green at the pin
10. [v0.1.0 release](https://github.com/Dicklesworthstone/franken_engine/releases/tag/v0.1.0) — published 2026-05-29, 6 assets (`frankenctl` + sha256, 3 platforms); targets the earlier tag commit, not the pin
11. [franken_node ROADMAP (substrate relationship)](https://github.com/Dicklesworthstone/franken_node/blob/HEAD/docs/ROADMAP.md) — "FrankenEngine is the core substrate"

---

## Did You Know

The only `unsafe` blocks in the entire 3.5-million-line tree are attacks. `crates/franken-engine/tests/unsafe_code_prohibition_gate.rs:374` and `crates/franken-extension-host/tests/trusted_label_adversarial.rs:156` both do `unsafe { std::mem::transmute(...) }` — forging an IFC `Labeled<String>` — as *negative tests* proving the capability membrane catches label forgery. Every library crate carries `#![forbid(unsafe_code)]`, so the "Unsafe Forbidden" README badge is not a goal statement; it is a compile-time gate, and the sole exceptions are the tests that try to break it. [Code-verified, High]

---

## Franken-worthy next steps

1. **Import the claim-to-proof gate into the FrankenSuite's own assessment program.** `docs/claim_to_proof_matrix_v1.json` binds 28 public claims to owning beads, artifact paths, verification commands, and *freshness tiers* (`max_observed_freshness_days`) — and the gate script refuses README wording whose `actual_wording_state` exceeds its `allowed_state`, emitting exact downgrade text. FrankenEngine is the only repo in the suite that lints its own marketing in CI. *Done when:* the program adopts a claim matrix with wording-state gating for its own published packets, with a named owner. *Falsifiable:* three sibling repos carry matrices within 60 days, or the idea dies as overhead. [Inference, High — process proposal]
2. **Extract the declassification-receipt + transparency-log/MMR stack as a standalone signed-audit crate.** `declassification_pipeline.rs`, `transparency_log.rs`, `mmr_proof.rs`, and the Ed25519-signed, `prev_hash`-chained evidence entries are a portable "provenance of decisions" primitive that does not require the JS runtime — an agent-ops team could embed decision receipts without adopting 3.5M lines. *Done when:* the four modules compile as a `no_std`-compatible crate with the 17-scenario red-team corpus as its acceptance suite. *Falsifiable:* an external consumer (even franken_node) depends on the extracted crate, or extraction fails on hidden coupling. [Inference, Medium]
3. **Publish the e-process guardplane as an independent decision-theory artifact.** The Bayesian-posterior + e-process-boundary decision ladder (`allow / challenge / sandbox / suspend / terminate / quarantine`) is the most genesis-stage component in the tree — "testing by betting" (anytime-valid inference) applied to *runtime containment*, not papers. *Done when:* the guardplane modules plus the red-team scenario corpus ship as a standalone crate with a replay-anchored eval protocol a third party can run. *Falsifiable:* an independent red-team campaign reproduces the containment decisions from the sealed artifacts, or the ladder's thresholds prove un-calibrated. [Inference, Medium]
4. **Commission a second-party execution of the 13 OBSERVED matrix rows.** Every OBSERVED claim names a verification command and a `repro.lock` partner; none has been executed by anyone but the maintainer. *Done when:* an unrestricted party (the rider bars AI labs and their agents — the recursion is the point) runs the 13 verification commands at a pinned commit and publishes pass/fail. *Falsifiable:* ≥1 row fails, which would convert the matrix from methodology exemplar to marketing with extra steps. [Inference, High]
5. **Run the red-team v2 campaign the matrix already specifies — and publish the loss.** FE-CLAIM-011's exact v2 path (ten contract-declared scenarios under pinned FrankenEngine, Node, and Bun binaries, 100 receipt-bound stability/replay repetitions per pair, one-scenario zero-cell guard) is fully specified but has no current non-fixture campaign. *Done when:* the campaign executes and the verdict — whatever it is — is linked from the matrix. A published loss (Node/Bun containing as well) is more valuable than the current TARGETED: it would tell the program whether the containment thesis survives contact with incumbents. [Inference, High]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** Node and Bun are excellent general-purpose JavaScript runtimes, but extension-heavy agent systems and adversarial workloads need a different default posture — active containment, deterministic forensics, explicit runtime authority boundaries, and defensible claim language. Retrofitting any of those into a binding-led engine (V8/JSC/QuickJS bindings) is "structurally painful": the bindings ship megabytes of upstream unsafe C++/Zig *outside* any IFC/capability algebra, and retrofitting type-safe authority membranes around them is "structurally lossy" [Maintainer claim, Medium].

**Who feels the pain:** operators running untrusted third-party extensions — and, pointedly, *agent systems* that execute model-generated or marketplace-sourced JS/TS — where a malicious or buggy extension can exfiltrate env secrets, spawn processes, or pollute prototypes, and where post-incident forensics must reconstruct *why* a containment decision fired [Inference, Medium].

**Why now:** the agent-extension threat surface is new — coding agents that install and run untrusted extensions at machine speed did not exist as a workload class three years ago — and the runtime layer has not caught up: Node's permission model is opt-in and coarse, Deno's is the closest incumbent but is not built around deterministic replay or signed decision evidence [Inference, Medium]. Whether "adversarial extension workloads" is a real market or a maintainer narrative is unproven — there are no production users, no independent coverage, and the only downstream consumer is the sibling `franken_node` (itself pre-release) [External, High within recall caveats].

**Why a rewrite, not a wrapper:** stated explicitly in the README's constitutional rule #1 and `docs/RUNTIME_CHARTER.md` §2 — `rusty_v8` / `rquickjs` / equivalent binding-led core paths are *forbidden by charter*, because the IFC labels are computed at IR2 and capability checks gate every hostcall edge, and a binding-led core would place the actual execution outside that algebra [Maintainer claim, Medium]. The `docs/ARCHITECTURE_OVERVIEW.md` adds a dry corrective worth quoting: the historical "QuickJS" and "V8" lane names are compatibility labels — neither lane embeds those engines — and AOT/tiering modules "should not be read as machine-code execution" [Maintainer claim, High].

**Suite-substrate role:** this repo is infrastructure *for* the FrankenSuite. `franken_node`'s `docs/ROADMAP.md` states "FrankenEngine is the core substrate. `franken_node` is the runtime and compatibility surface built on top," and `franken_node`'s manifest declares `frankenengine-engine` and `frankenengine-extension-host` as optional path dependencies (`path = "../../../franken_engine/crates/franken-engine"`, i.e. the `/dp` sibling checkout) behind an `engine` feature flag [External, High]. FrankenEngine's own README addresses downstream consumers directly ("If you are a downstream consumer (`franken_node` or another sibling)") and documents pin-by-commit-SHA-plus-artifact-manifest as the consumption contract [Maintainer claim, High]. Assessing this packet in isolation would miss the point: its value proposition is partly as the containment substrate the sibling agent runtime stands on — and its ceilings (rider, red CI, TARGETED end-to-end contract) are therefore inherited ceilings for `franken_node`'s `engine` feature [Inference, High].

**Adjacent context:** one entry in the solo-maintainer FrankenSuite program. The design philosophy's rule #5 is "constitutional integration": reuse stronger sibling substrates rather than rebuilding them — `/dp/asupersync` control contracts, `/dp/frankensqlite` + `/dp/sqlmodel_rust` persistence, `/dp/fastapi_rust` service surfaces — with "parallel local replacements requir[ing] explicit approval" [Maintainer claim, High]. The asupersync relationship is verified in §4.4; it is the inverse of frankenredis's evaluated-and-rejected posture.

## 4.2 What it is — repo TL;DR

A 10-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing a native Rust JavaScript/TypeScript execution substrate: hand-rolled parser → four-stage lowering (IR0→IR3) → policy-routed baseline interpreter (`baseline_interpreter.rs`, 136,275 lines in `frankenengine-engine` alone [Counted, High]) → `execution_orchestrator.rs` for the extension path with capability, security-epoch, evidence, and containment controls → sealed IR4 witnesses. Around the core: a probabilistic guardplane (Bayesian posterior + e-process boundaries — sequential-testing thresholds from anytime-valid inference that bound the false-discovery rate over arbitrary stopping times — driving a six-rung decision ladder), deterministic replay over a declared high-severity inventory, Ed25519-signed evidence entries chained by `prev_hash` into a transparency log with MMR inclusion/consistency proofs, a red-team scenario corpus, a metamorphic testing crate, an extension-host crate, a secure-aggregation (`dp`) crate implementing Bonawitz et al. 2017, and 34 React/FRX compile scripts (FRX: the project's React-dialect compilation pipeline, 34 `run_frx_*.sh` scripts). Development velocity is extreme: 402 commits in the 2026-09-01 → pin window (~20/day; 96 on Sep 15) [Git-observed, High], all primary-authored by Jeff Emanuel with zero agent co-author trailers in the sample [Git-observed, High] — a sharp contrast with frankenredis's 36% agent co-authorship.

One-line verdict: **the most methodologically self-policing codebase assessed in this program to date [Inference, Medium — judged over the packets completed so far on the evidence of the claim-to-proof gate, the negative-performance candor, and the README's self-downgrades], shipping a real-but-incomplete containment substrate whose own ledger refuses to call it fast, secure end-to-end, or production-ready — under a license that forbids the likeliest evaluators from analyzing it.** (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was checked against the pinned commit on 2026-09-22. Tier flavors: Counted (I ran the count), Git-observed (git metadata), Code-verified (read the source), CI-observed (seen executing on CI pages — attests the suite *runs*, not that it is green), Maintainer claim (README/CHANGELOG/docs), External (third party). **Status** is the Rulebook's required audit verdict per claim.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 10 workspace crates, ~3.53M first-party Rust lines / 2,679 `.rs` files | demonstrated | Fresh clone, `git rev-parse` = pin; `Cargo.toml` members enumerated; line count over `crates/` | [Counted, High] |
| 2 | Zero `unsafe` in library code: `#![forbid(unsafe_code)]` on all lib crates; the only `unsafe` blocks tree-wide are two adversarial negative tests (`transmute`-forged IFC labels) | demonstrated | Comment-excluding `unsafe`-keyword scan over `crates/`; gate attributes read in crate roots | [Code-verified, High] |
| 3 | IFC lattice `Public < Internal < Confidential < Secret < TopSecret` with custom labels, join/meet laws, fail-closed flow policy, signed declassification receipts with timestamp bounds | demonstrated (existence; behavior not executed) | `ifc_artifacts.rs`: `Label` enum read — 5 built-ins + `Custom{name, level}`, manual `Ord` (the comment explains derived-`Ord` would mis-order `Custom` and break IFC invariants), join/meet via full `Ord` for commutativity; `is_flow_allowed_with_enforcement` read verbatim — explicit-deny → explicit-allow → declassification-route → lattice-legal (legacy mode only) → `Denied`; default mode is `AllowlistOnly`, fail-closed even for lattice-legal flows; `declassification_pipeline.rs`: `DeclassificationRequest` carries source/sink labels, extension id, code location, trace id, route id, decision-contract id, emergency flag, timestamp; `examples/live_ifc_declassification_example.rs` present | [Code-verified, High] |
| 4 | Capability algebra: 22-variant `RuntimeCapability` enum, canonical profiles (`FullCaps`, `EngineCoreCaps`, `PolicyCaps`, `RemoteCaps`, `ComputeOnlyCaps`) with set-inclusion subsumption and intersection attenuation; deserialization rejects smuggling | demonstrated (existence; behavior not executed) | `capability.rs` read verbatim (22 variants counted); README's algebra-law test names; `capability/` + `capability_token/` dirs present | [Code-verified, High] |
| 5 | End-to-end capability-typed TS-to-IR compile-time contract (ambient-authority rejection over *all* constructs) | aspirational | The maintainer's own matrix: FE-CLAIM-006 is `observed` for *selected hostcall/import edges* only; the end-to-end contract is `target` (CEI-C.2) | [Maintainer claim, High] |
| 6 | Deterministic replay over the declared high-severity inventory; `frankenctl compile` byte-identical, `run` identical modulo per-invocation signing authority | partially demonstrated | `run_replay_coverage_metric_gate.sh` + replay wrappers exist (188 `*_replay.sh`: 186 in `scripts/e2e`, 2 in `scripts/`); the `bd-2488a` coverage gate is described, not executed by this analyst | [Code-verified + Maintainer claim, Medium] |
| 7 | Signed decision receipts: Ed25519-signed entries, `prev_hash` chaining, transparency log + MMR inclusion/consistency proofs; TEE attestation | partially demonstrated (signing+log); aspirational (TEE) | `transparency_log.rs`, `mmr_proof.rs`, `run_rgc_signed_decision_receipt.sh` present; matrix FE-CLAIM-004 `observed`, FE-CLAIM-004-TEE `hypothesis` ("simulated by default — no hardware root of trust") | [Code-verified + Maintainer claim, High] |
| 8 | Throughput competitive with Node/Bun | disproven-as-claimed (the maintainer disavows it himself) | Matrix `PERFORMANCE` section: preserved June 2026 bundle records `0.000920x` Node / `0.000791x` Bun, declared "non-normative historical baseline… not the plan's weighted denominator contract"; FE-CLAIM-010 stays `target` | [Maintainer claim, High] |
| 9 | Red-team v2 compromise-rate comparison vs pinned Node/Bun | aspirational | Matrix FE-CLAIM-011 is `target`: "no current non-fixture v2 campaign plus passing verdict is preserved and linked" — the exact v2 path is fully specified but unexecuted | [Maintainer claim, High] |
| 10 | Fleet immune system / quarantine propagation convergence SLO | aspirational | Matrix FE-CLAIM-005 is `target`: "the published CI gate validates contract shape and source references without executing the harness or preserving measured percentiles" | [Maintainer claim, High] |
| 11 | Full Test262 conformance | aspirational | Matrix FE-CLAIM-TEST262 is `target`; README: "no Test262 `.js` files are in-tree… `full_suite_claim_allowed=false`" | [Maintainer claim, High] |
| 12 | The claim-to-proof matrix gates README wording (28 claims, owning beads, artifact + verification-command links, freshness tiers) | demonstrated | `docs/claim_to_proof_matrix_v1.json` parsed: 28 claims (13 observed / 8 target / 7 hypothesis); `actual_wording_state == allowed_state` on all 28 rows; gate script present | [Counted + Code-verified, High] |
| 13 | `franken_node` consumes FrankenEngine as its substrate | demonstrated | franken_node manifest: `frankenengine-engine` + `frankenengine-extension-host` as optional path deps behind the `engine` feature; ROADMAP: "FrankenEngine is the core substrate" | [External, High] |
| 14 | asupersync adopted as control-plane substrate (not rejected) | demonstrated | `frankenengine-engine` default-on `asupersync-integration` feature → published crates.io `franken-kernel`/`franken-decision`/`franken-evidence` 0.5.0 (in `Cargo.lock`); `control_plane.rs` feature-gated adapter; contract-matrix + leverage-adoption-gate modules (beads `bd-3nr.1.5.1`, `bd-3nr.1.7`) | [Code-verified, High] |
| 15 | Native Runtime CI green at the pin | disproven | Run #35550128941 (head = pin): all 3 jobs failed on test-execution steps; **all 46 recorded runs of the workflow fail — it has never gone green** (Sep 16–21) [CI-observed, High]. `quality-gates.yml` and `perf_regression_gate.yml` have 0 runs ever; the red-team repeated-trial measurement workflow has 0 runs; adversarial_fuzz failed at pin. `main-safety.yml` (440 runs) is green at the pin | [CI-observed, High] |
| 16 | `v0.1.0` release with prebuilt `frankenctl` binaries + checksum-verified installer | demonstrated (with the tag/release nuance) | GitHub API: release published 2026-05-29, 6 assets (3 platforms + sha256); `install.sh` present; tag `v0.1.0` → `0a4e9db4`, not the pin — no release artifact for the assessed commit | [External, High] on release; [Git-observed, High] on the tag |
| 17 | Single human maintainer; ~20 commits/day; 4,537-bead journal (3,911 closed / 626 open) | demonstrated | 402-commit blobless sample: 396 Jeff Emanuel + 4 bot commits, zero Co-Authored-By trailers; `.beads/issues.jsonl` counted | [Git-observed + Counted, High] |
| 18 | License rider bars OpenAI, Anthropic, affiliates, and anyone acting for them from use incl. benchmarking/testing/analyzing/indexing/training; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |
| 19 | README "Code Surface At A Glance" inventory (616 modules, 67 binaries, 1,654 tests, 292 gate scripts, 725 docs, ≈4,530 beads, 33 fuzz harnesses) | stale (additively, dated 2026-08-24) | Recount at pin: 627 top-level `.rs` / 619 `pub mod` (README: 616/619), 136,275-line baseline (README: ~132,181), 73 binaries (67), 1,709 test files (1,654), 295 gate scripts (292), 737 docs (725), 4,537 beads (≈4,530), 36 fuzz targets across three trees (README: 33 across two — the extension-host tree is unknown to the table), 188 replay wrappers (186 `scripts/e2e` + 2 `scripts/`). All deltas are growth or missing scope | [Counted, High] |

**What the inventory says in aggregate:** claims about *process and posture* (zero-unsafe, claim gating, bead discipline, candid TARGETED states) verify at High confidence; claims about *outcomes* (speed, end-to-end security, fleet behavior, conformance) are either disavowed by the maintainer's own matrix or unexecuted. The honest pattern is inverted from the usual: the marketing layer *under*-claims relative to the code, and the matrix is the instrument that enforces it. CI is the weak point — the core execution lane has never gone green in the observed window while the safety lane is green, and two named quality gates have never run at all.

## 4.4 Codebase tour

**Workspace topology (10 members, [Counted, High]):** `dp` (secure aggregation), `frankenengine-core` (0.2.0, the extracted/legacy core), `frankenengine-engine` (0.2.0, the current runtime), `frankenengine-extension-host` (0.1.0), `frankenengine-metamorphic`, `frankenengine-test-support`, `frankenengine-control-plane-integration-tests`, `franken-engine-deterministic-derive`, `franken-engine-deterministic-trait`, `franken-engine-fixed-layout-derive`. Directory names ≠ package names for the two runtime crates (a small but real discoverability tax). The 0.2.0 line on the two public runtime crates is an *unreleased* compatibility boundary — "it does not create a `v0.2.0` tag or release" [Maintainer claim, High].

**Dependency posture:** the external set is dominated by the sibling-substrate strategy — published crates.io artifacts of sibling repos rather than path deps: `franken-kernel`/`franken-decision`/`franken-evidence` 0.5.0 (the asupersync umbrella's crates, [Code-verified, High] via `Cargo.lock` with checksums), `sqlmodel`/`sqlmodel-core`/`sqlmodel-frankensqlite` (persistence), plus `serde`, `serde_json`, `sha2`, `rand`, `anyhow`, `thiserror` at the workspace root. The root `Cargo.toml` carries a remarkable scar: the `[patch.crates-io]` block was removed 2026-07-25 (bead `bd-h5cl7`) after it silently rewired a sibling's `fsqlite` from 0.1.18 to a breaking 0.1.19 and took the default build red — with 7 of 16 OBSERVED claims becoming unverifiable because their verification commands are default-feature builds. The comment block is a postmortem *in the manifest*, and it documents the project's real dependency doctrine: no patches, registry-pinned siblings, feature flags that genuinely remove surfaces (`--no-default-features` is a no-siblings build; the Parquet evidence-export path fails closed with a typed error rather than emitting a lesser artifact) [Code-verified, High].

**Data flow, end to end:**

- **Ingress — parser → IR0→IR1→IR2→IR3 (`lowering_pipeline.rs`, 44,616 lines [Counted, High]):** IFC labels are computed at IR2; capability checks gate every hostcall edge. The charter forbids binding-led core paths (`rusty_v8`/`rquickjs`) — the lowering pipeline owns parser-to-scheduler semantics in safe Rust [Maintainer claim, High].
- **Execution — two entry paths over one core:** public `HybridRouter` evaluation routes a prepared IR3 handle to the baseline interpreter; extension execution enters through `execution_orchestrator.rs`, which owns its own parse/lower, policy, budget, and witness lifecycle before invoking the same interpreter core. The orchestrator is not a downstream tier after baseline execution [Maintainer claim, High]. `baseline_interpreter.rs` (136,275 lines [Counted, High]) is the canonical execution path — "all optimized paths must prove equivalence against it" — exposing `baseline_deterministic_profile`, `baseline_throughput_profile`, and an `adaptive_profile_router`.
- **Security — IFC + capability, enforced in the pipeline:** the IFC lattice (`Public < Internal < Confidential < Secret < TopSecret`, custom labels via non-negative levels, join=max/meet=min) with `FlowPolicyEnforcement::is_flow_allowed*` variants. The full resolution order (read verbatim) is stricter than the README's summary suggests: explicit-deny → explicit-allow → declassification-route (obligation-producing, checked *before* lattice legality so a lattice-legal pair cannot bypass an explicit route) → lattice-legal → `Denied`. And the lattice legality step only runs in the legacy `LatticeOpen` mode — the default mode is `AllowlistOnly`, in which even a lattice-legal flow is `Denied` unless explicitly allowed or routed. The fail-closed posture is the default, not an option [Code-verified, High]; declassification mediated by signed receipts carrying authorizing capability witness, source/sink labels, content binding, and timestamp bounds. The code repays close reading: `ifc_artifacts.rs` implements `Ord` for `Label` manually because the derived `Ord` would order the `Custom` variant above `TopSecret` by discriminant and break IFC invariants, and `join`/`meet` compare via the full `Ord` (not raw levels) so the result is argument-order-independent — commutativity as a security property, with the rationale in comments [Code-verified, High]. The declassification pipeline goes further than the README's summary: `DeclassificationRequest` binds source/sink labels, extension id, code location, trace id, requested route id, authorizing decision-contract id, an emergency flag, and timestamp, and a separate cryptographic-transform release contract mints exact one-use ciphertext-release receipts that deliberately carry no plaintext or key bytes [Code-verified, High]. The e-process side has a code anchor too — and it repays reading. `martingale_decision_ledger.rs` (bd-cixqu.27.1, 978 lines [Code-verified, High]) implements a non-negative martingale tracked in fixed-point millionths of log-space: `log_m_{n+1} = log_m_n + log_likelihood_ratio_n`, the stopping rule `M_n >= 1/α` *derived* from the threshold rather than encoded by the caller, and the full trajectory stored so every intermediate state and the stopping verdict re-derive by replay. The header cites the literature it implements (Lai 1995, Tartakovsky 2014, Ramdas et al. 2020; Howard/Ramdas/Koolen/Grünwald "e-process" terminology; Ville's inequality for anytime validity under optional stopping), and `ln_ratio_millionths` is integer-only arithmetic precisely so security evidence never depends on platform `f64::ln` — determinism engineered at the math layer, not just the process layer. It is honest about its own boundary: "Non-goals for this bead" include "wiring into specific guardplane decisions," deferred to bead bd-cixqu.27.2 — which has itself landed as `eprocess_guardrail.rs`: the guardrail consumes the unified ledger and, when the martingale emits a Stop verdict, consults a fixed-point expected-loss matrix to decide which actions to block [Code-verified, High]. The six-rung ladder itself is literal code, not metaphor: `ESCALATION_LADDER: [&str; 6] = ["allow","challenge","sandbox","suspend","terminate","quarantine"]` in `agent_sandbox.rs`, with `action_severity` ordering and `AgentGuardplaneSummary` reporting the most severe guardplane-selected action mined from the run's evidence entries [Code-verified, High]. So the honest decomposition is: the anytime-valid *substrate* is demonstrated code with law tests; the *decision ladder* is demonstrated as a reporting/escalation ordering consumed by the orchestrator's containment action; and what the README presents as one guardplane is in fact a stack of beads with documented seams — which, for this project, is a feature: the seams are labeled, not hidden. The capability algebra is 22 `RuntimeCapability` variants with 5 canonical profiles partitioning authority into disjoint zones (`ComputeOnlyCaps` grants no side effects — the safe default for unknown extensions). Unknown hostcall tags map to no typed capability and are rejected [Code-verified, High for the enum and profiles; behavior not executed].
- **Decision — the guardplane:** Bayesian posterior updates cross e-process boundaries to drive the six-rung ladder `allow / challenge / sandbox / suspend / terminate / quarantine` (`bd-1ypps`; live example `examples/live_guardplane_decision_example.rs` present [Code-verified, High on existence]). Promotion/demotion runs through a promotion controller with rollback receipts (`bd-or2e1`).
- **Evidence — ledger → IR4 witness:** every evidence entry Ed25519-signed with the originating runtime's key, `prev_hash`-chained; the transparency log carries MMR inclusion/consistency proofs; artifact bundles ship `run_manifest.json` with schema id, host facts, content hashes, and operator-verification commands. Replay captures IR3 program, policy snapshot, model snapshot, evidence stream, and randomness transcript; the `bd-2488a` coverage gate fails closed unless every high-severity decision in the declared inventory replays byte-for-byte [Maintainer claim, High].
- **Extension/host boundary — `frankenengine-extension-host` + `native_addon_membrane.rs`:** the membrane around native addons; npm posture documented separately. The extension-host crate is a real boundary crate, not scaffolding: `host_effect_journal` + `host_io` (DNS/TCP/TLS effect supervision — the pin commit itself wires sealed-execution cancellation into in-flight network I/O), `process_spawn`, Ed25519 `decision_crypto`, `decision_binding`, and extension-manifest validation with capability grants (`WRITE_IMPLIES` rules, length bounds on manifest fields) [Code-verified, High on the module surface]. This is the crate `franken_node` consumes alongside the engine [External, High].
- **Adversarial surfaces — red-team corpus, metamorphic suite, fuzz:** `crates/franken-engine/tests/red_team_scenarios/` (scenario, manifest) pairs pinning expected containment verdicts (README tables 4 attack classes; bead `bd-cixqu.3.3` references a 17-scenario corpus); `frankenengine-metamorphic` crate; 36 fuzz-target files across three `fuzz/fuzz_targets` trees — 17 workspace-root, 16 `franken-engine`, 3 `franken-extension-host` — where the README's "33 across two trees" misses the extension-host tree entirely (another inventory-drift data point for §4.7 weakness 7) [Counted, High on the harness count].
- **The `dp` crate:** a self-contained Bonawitz-et-al.-2017 secure-aggregation implementation (`#![forbid(unsafe_code)]`) — the aggregator sees only sums, not individual contributions. Its presence in a JS-runtime workspace is unexplained by any README section read; it reads as shared suite infrastructure vendored into the workspace [Inference, Medium].

**The asupersync edge, verified (the Rulebook's mandatory question):** ADOPTED, not rejected — the inverse of frankenredis. `frankenengine-engine` ships `asupersync-integration` ON by default, pulling the published `franken-kernel`, `franken-decision`, `franken-evidence` 0.5.0 crates from crates.io (checksummed in `Cargo.lock`) [Code-verified, High]. `frankenengine-core` carries the same feature OFF by default, with `control_plane.rs` ("Narrow control-plane adapter surface for `/dp/asupersync` primitives") compiling the adapter in or out — no stubs, no simulation. The adoption was itself gated: `asupersync_contract_matrix.rs` (bead `bd-3nr.1.5.1`) validates four upstream surfaces (kernel context/budget/trace semantics, decision-evaluation linkage, evidence-ledger validity, frankenlab harness surface) into a replayable contract matrix, and `asupersync_leverage_adoption_gate.rs` (bead `bd-3nr.1.7`) renders a Stop/GoTargeted/GoBroader verdict. One wording drift: the README's design philosophy says "reuses… `/dp/asupersync` control contracts," which reads as a sibling-checkout dependency; the actual edge is the published registry crates from the same upstream repo — same trust root, different mechanism [Code-verified, High; the drift is phrasing, not substance].

## 4.5 Benchmark and conformance audit

**Maintainer-produced numbers.** There is effectively one table, and the maintainer refuses to let it be quoted:

| Number | Methodology doc | Controls | Would it survive a rerun? | Tier, Confidence |
|---|---|---|---|---|
| `0.000920x` Node / `0.000791x` Bun (unweighted admitted-case ratios: 16 and 13 cases) | `benchmarks/runtime_comparison/README.md` (the official comparison corpus: `frankenctl benchmark compare` + `comparative_node`/`comparative_bun` benches) + the preserved June 2026 bundle | Dirty worktree, asymmetric engine/reference lifecycles, `repro.lock` reproduces correctness not timing | The *ratio* is not the claim — the matrix declares the bundle "non-normative historical baseline, not the plan's weighted denominator contract" and keeps FE-CLAIM-010 at `target` | [Maintainer claim, High] |

The honest audit: **there are no performance claims to audit because the claim gate ate them.** The matrix's Performance Evidence section states the rule plainly — the real hot-path lane counts as observed internal evidence *only* when `scripts/run_real_hot_path_proof.sh smoke` emits `real_runtime_hot_paths` artifacts validated by the contract gate, and "that lane does not promote the Node/Bun denominator claim." Artifacts containing `hot_paths_simulation` or `MockCertificate` are fixture-only and the gate *rejects* them as backing evidence. The May 2026 wave notes celebrate a "no-mock acceptance drill (`bd-ly6hp.6`) that rejects fixtures" [Maintainer claim, High]. Note the tension the packet holds deliberately: an official comparison corpus *exists* (`benchmarks/runtime_comparison/` with `frankenctl benchmark compare`, `comparative_node`/`comparative_bun` benches, and an operator README) — the project built the track but the matrix still refuses to certify any lap time on it [Code-verified + Maintainer claim, High]. This is the negative image of a benchmark table: a project that built the machinery to disqualify its own numbers.

**Conformance numbers.** No Test262 corpus in-tree; the checked-in `es2020-normative` measurement is 3 vectors from `precomputed_observed_results`, not an executed corpus; `full_suite_claim_allowed=false` [Maintainer claim, High]. JS surface coverage is instead inventoried by `parser_gap_inventory.rs` / `lowering_gap_inventory.rs` (self-documenting gap lists — the honest version of a coverage number), plus a YouTube/BotGuard conformance test file with named blockers (typed arrays, Function constructor compilation, exception-through-native-error ordering) tracked as beads [Maintainer claim, Medium].

**Independent numbers.** None exist. A web search for third-party benchmarks, reviews, or production deployments of FrankenEngine returned nothing beyond the repository and sibling-repo references [External, High within recall caveats].

**Reproduction cost:** the ~115 MB GitHub-reported repo size (7,739 tracked paths in the shallow clone) plus the pinned toolchain; verification commands are per-claim shell scripts with `repro.lock` partners, several requiring sibling checkouts or external suites (tc39/test262 via `--suite-path`). No independent reproduction is known [External, High within recall caveats].

## 4.6 Comparison: who owns the lane

The incumbent wins on everything a buyer measures — speed, compatibility, ecosystem, operators who have paged on it at 3 AM. FrankenEngine's only uncontested edge is its auditability apparatus (claim-to-proof gating, signed declassification receipts, replay-anchored red-team corpus) — which no competitor bothers with because no buyer currently pays for it [Inference, Medium].

- **Node.js (OpenJS, the incumbent):** owns the extension-workload lane outright — npm, the debugger and profiler ecosystem, every hosting platform. Its permission model (`--permission`) is opt-in, coarse, and off by default; it offers no deterministic replay and no signed decision evidence [External, High on the ecosystem facts; Inference, Medium on the gap]. FrankenEngine's pitch is aimed at the workloads Node serves worst (adversarial extensions), not at replacing Node.
- **Deno:** the closest incumbent on posture — secure-by-default permissions, capability-ish flags. Deno owns "secure JS runtime" in buyer perception and has real users; it lacks replay-anchored forensics, Bayesian containment ladders, and claim-gated documentation [Inference, Medium]. Deno is the competitor FrankenEngine must answer and currently cannot on speed (Deno is V8-fast; FrankenEngine is ~1,000× slower than Node on its own historical bundle).
- **Bun:** owns the speed lane in buyer perception; the maintainer's own denominator work uses Bun as a reference. Not a security-posture competitor [Inference, Medium].
- **LLRT (AWS), Boa (Rust JS engine), QuickJS:** the embedding-adjacent lane. Boa is the honest Rust peer — a from-scratch JS engine in safe Rust — but it is an *engine*, not a containment substrate: no IFC, no capability algebra, no evidence ledger [External, Medium]. QuickJS is the "small embeddable" incumbent; the charter explicitly forbids binding-led paths, so QuickJS-as-library is a rejected design, not a competitor.
- **SES (Secure ECMAScript) / LavaMoat:** the membrane-model incumbents for extension containment *within* JS. They own the "contain untrusted code without asking anyone to adopt a new runtime" lane and have real deployments. FrankenEngine's bet is that membrane models inside a shared engine are "structurally lossy" — an assertion, not a measurement: no campaign in the assessed materials pits the capability algebra against SES/LavaMoat on the same corpus, and a bead-tracker search finds zero mentions of LavaMoat anywhere in the 4,537-record journal — no head-to-head is even planned [Code-verified via bead search, Medium]. Notably, the project's own `run_rgc_capability_typed_compile_time.sh` gate already asserts a comparative containment claim (FrankenEngine refuses attacks that Node and Bun allow), but only against *unhardened* Node/Bun — never against the hardened in-JS incumbents [Code-verified, High].
- **FrankenSuite siblings:** `franken_node` is the downstream consumer (optional `engine` feature), not a competitor. No other suite repo occupies the "native JS execution substrate" lane; this repo *is* the lane owner inside the suite [Inference, High].
- **Unoccupied lane:** a JS runtime whose *documentation is CI-gated against its evidence*, with signed, replay-anchored containment decisions and a finite, executable IFC/capability algebra — no occupant. Deno owns secure-defaults, SES owns in-JS membranes, nobody owns "the runtime that can prove what it decided and refuses to overclaim." Whether any buyer will trade 1,000× throughput for that auditability is the unproven bet the whole project rests on [Inference, Medium].

## 4.7 Skeptic's take

Weaknesses, each substantive — capable of killing the project on its own:

1. **[FATAL] The core CI lane has never gone green — 46 of 46 recorded runs fail — and two named quality gates have never run.** `native-runtime.yml` — the workflow that executes the native-core unit tests, execution-budget regressions, async-generator regressions, and reflection boundaries — failed all 3 jobs at the pin (run #35550128941, head = pin), and every one of its 46 recorded runs (Sep 16–21) concludes failure [CI-observed, High]. `quality-gates.yml` and `perf_regression_gate.yml` have zero runs *ever*; the red-team repeated-trial measurement workflow has zero runs [CI-observed, High]. The project's own README says native execution profiles are OBSERVED "exercised by the CLI smoke and the RGC execution-profile gate" (RGC: the project's `run_rgc_*` gate-script family; the acronym is never expanded in the assessed materials) — but the workflow named "Native Runtime" is red, and the perf gate the claim matrix's Performance Evidence section depends on has never executed. A methodology project whose flagship verification lanes don't run is selling process it doesn't practice on the critical path [Inference, High].
2. **[FATAL] The license rider bars the likeliest evaluators of an agent-extension runtime from analyzing it.** Barring OpenAI/Anthropic, affiliates, and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them from "use" — defined to include "benchmarking, testing, analyzing, indexing, or incorporating… into any dataset, training corpus, evaluation harness, or pipeline for machine learning" — doesn't just block two companies from a JS runtime. The target workload is *agent systems running untrusted extensions*; the entities that build agent systems at scale are named Restricted Parties. The rider excludes the demand side by name [Inference, High]. The "acting for" prong creates the same contributor-pool legal uncertainty documented in the frankenredis packet, and the recursion is live: this assessment is itself an agent-assisted analysis of the code [Inference, Medium].
3. **[HIGH] The end-to-end security promise is TARGETED by the project's own ledger.** FE-CLAIM-006's observed scope is "selected hostcall/import edges"; the compile-time TS-to-IR ambient-authority rejection over *all* constructs — the thing that would make the capability story load-bearing rather than illustrative — is TARGETED (CEI-C.2). The red-team corpus pins 17 scenarios on the shipped edges, which is real, but the membrane's completeness is an open bead, not a result [Maintainer claim, High]. A containment runtime whose containment boundary is admittedly partial is a research prototype wearing a runtime's clothes.
4. **[HIGH] It is ~1,000× slower than Node on the only measured bundle, with no path to competitiveness in evidence.** The `0.000920x`/`0.000791x` ratios are dirty-worktree, asymmetric-lifecycle, non-normative — but they are also the *only* cross-runtime numbers in the tree, and the honest reading is that throughput is not merely unmeasured but believed-bad: no optimization campaign with a weighted denominator contract exists, the perf regression gate has never run, and the AOT/tiering modules are "plans, guards, or provenance," not machine-code execution [Maintainer claim, High]. The security story has to carry the entire value proposition, because the performance story is a vacancy.
5. **[MEDIUM] 3.5M lines, one human, no release at the pin, bus factor 1.** The v0.1.0 release (May 2026) targets an earlier commit; the assessed tree has no artifact. 136,275-line single-file interpreter, 44,616-line lowering pipeline. The bead journal (3,911 closed) is the only institutional memory, and review depth (who reviews bead closures, PRs vs direct-to-main) is unassessed [Git-observed + Counted, High on the counts; Inference, Medium on the risk].
6. **[MEDIUM] The matrix is self-graded and self-executing.** The claim-to-proof gate is the project's best artifact and its most circular: the same maintainer authors the claims, writes the verification commands, runs them, and records the states. The 13 OBSERVED rows have never been executed by a second party; the freshness tiers (`max_observed_freshness_days`) bound staleness but not correctness. A gate the author holds the only key to is an honesty *signal*, not independent validation [Inference, High].
7. **[MEDIUM] README drift is structural, not incidental.** The "Code Surface At A Glance" table — the inventory the README uses to establish scale — is stale on every count one month after its verification date (2026-08-24): +11 modules, +4k interpreter lines, +6 binaries, +55 test files, +12 docs. Round-5 recounts added two more: the Fuzz Targets Catalogue's "33 across two trees" misses the extension-host crate's third fuzz tree (36 total), and the replay-wrapper count is 188, not the 186 implied by the e2e dir alone [Counted, High on the deltas; Inference, Medium on the assessment]. The project *knows* documentation drifts faster than evidence is rebuilt (constitutional rule #4 says so) and built a gate for claim wording — but the gate checks wording states, not inventory counts, so the drift vector it was built to close is only half-closed [Counted, High on the deltas; Inference, Medium on the assessment].
8. **[MEDIUM] The sibling-substrate strategy concentrates suite-wide risk.** Default-on dependencies on published `franken-kernel`/`franken-decision`/`franken-evidence` 0.5.0, `sqlmodel-frankensqlite`, frankentui surfaces — each a solo-maintainer repo under the same rider. The July `[patch.crates-io]` postmortem shows the failure mode is real: a sibling's patch-level bump silently broke this repo's default build and took 7 of 16 OBSERVED claims unverifiable with it. The engine inherits the bus factor and the rider of every sibling it integrates [Code-verified, High on the postmortem; Inference, Medium on the concentration].

**Bear-case steelman (strongest counter-case):** FrankenEngine is a single-maintainer methodology performance — 3.5 million lines of Rust proving that documentation *can* be gated against evidence, wrapped around a JS runtime that is a thousand times slower than Node, has never passed its own core CI lane in the observed window, admits its end-to-end security contract is aspirational, and is licensed to forbid analysis by the AI labs whose agent workloads are its stated reason to exist. Deno already owns secure-by-default with real users and V8 speed; SES/LavaMoat own in-JS containment without asking anyone to adopt a new runtime; Boa owns safe-Rust JS execution without the 3.5M-line apparatus. The rational market response is to copy the claim-to-proof gate JSON schema and never run the runtime. Its most likely end state is abandonment at the maintainer's next context switch — leaving a 3.5M-line monument whose 13 OBSERVED claims were never independently executed, and whose rider ensures the best-equipped evaluators may not check. [Inference, Medium — deliberately uncharitable; the counter-evidence is the repair-grade candor of the matrix itself, which no other repo in the suite exhibits.]

## 4.8 License and governance (material, not boilerplate)

**Bus factor: 1.** One human maintainer (Jeff Emanuel); 396 of 400 sampled commits primary-authored by him, 4 by bots, zero agent co-author trailers [Git-observed, High]. No succession plan, no second committer, no foundation, no release artifact at the pin [Inference, Medium — absence of evidence across the assessed materials; the no-release-at-pin half is Git-observed/External, High]. If the maintainer stops, the project freezes at whatever commit the stop happens on [Inference, High].

**Contribution posture:** `CONTRIBUTING.md` and `AGENTS.md` exist at the repo root (the latter is "binding" on AI coding agents per the README); the bead workflow (`.beads/issues.jsonl`, 4,537 records) is the unit of work and the durable journal. Review depth — PRs vs direct-to-main, who reviews bead closures — was not assessed [Not verified].

**Commit velocity vs review depth:** ~20 commits/day in the September window (96 on Sep 15) [Git-observed, High]. At that cadence, meaningful human review of each commit is implausible; the project's answer is gate-based (claim matrix, RGC gates, replay wrappers) rather than review-based — gates scale where reviewers don't, but only the gates that actually run count, and §4.7 weakness 1 names the ones that don't [Inference, Medium].

**License — the rider, scoped precisely (LICENSE read verbatim at pin):**

- **Header:** "MIT License (with OpenAI/Anthropic Rider)" — while the README's shields badge advertises "License: MIT" linking to the same file. The README's own text never spells out the rider in the sections read; the badge is shorthand, not concealment, but a cold reader clicking the badge expects OSI-MIT [Code-verified, High].
- **Restricted parties:** "OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative)." (quoted verbatim)
- **Grant:** "no rights are granted to any Restricted Party" without the author's "express prior written permission"; any purported license to a Restricted Party "null and void."
- **Scope:** bars providing or permitting access to "the Software or any derivative work" to or for a Restricted Party.
- **"Use" defined expansively:** "copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, **benchmarking, testing, analyzing, indexing**, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems." (quoted verbatim; emphasis added)
- **Viral rider clause:** "any distribution of the Software or any Derivative Works must include this rider provision unmodified" — the rider propagates by contract, not just by copyright.
- **Remedy:** breach "automatically and immediately terminates" the permissions; the author reserves injunctive/equitable relief and attorneys' fees.
- **Classification:** non-OSI, source-available. Named-party discrimination fails OSD §5; the benchmarking/analysis/training bar fails OSD §6 [Inference, High — legal conclusion, not legal advice]. GitHub's own API classifies the license as `NOASSERTION`/"Other" [External, High].

**Succession consequence:** even a willing acquirer inherits a license that shrinks the contributor and evaluator pool to exclude the AI sector; removing the rider requires the sole copyright holder's action — the same single point of failure as everything else [Inference, Medium]. The rider's viral-distribution clause means every downstream fork (including `franken_node`'s `engine` feature path) carries the exclusion forward.

**Governance note the packet will not let go of:** the project's own charter makes "claim-language that cannot exceed its evidence" a *constitutional rule*, and the matrix enforces it — yet the README badge says "License: MIT" for a non-OSI license, and the surface-inventory table is a month stale. The constitution binds prose about capabilities; it does not bind the badge or the counts. That is a precise, verifiable gap between the governance theory and its implementation [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 4–5** | Lab-validated components (IFC/capability algebras with law tests, replay gates, signed-receipt machinery, 33 fuzz harnesses) with zero production exposure, a red core CI lane at the pin, and the end-to-end security contract still TARGETED — the range is honest: component validation (TRL 4–5) holds, system-level validation in a relevant environment does not [Inference, Medium] |
| Strategic relevance | 4/5 | It is the containment substrate for `franken_node`'s agent runtime — the suite's agent story stands on it — but the rider blocks the program's own engagement with the software [Inference, Medium] |
| Impact potential | 2/5 | The claim-gated, replay-anchored containment lane is genuinely unoccupied, but the runtime is ~1,000× slower than Node on the only measured bundle and no buyer signal exists [Inference, Medium] |
| Implementation feasibility | 2/5 | 3.5M lines, one maintainer, no release artifact at the pin, red core CI — any adopter inherits the entire tree plus the rider [Inference, Medium] |
| Time to mainstream | 2/5 | Years at best: rider removal, green core CI, the red-team v2 campaign, a tagged release, and independent validation must all happen first [Inference, Low] |
| Collaboration potential | 1/5 | The rider bars the likeliest collaborators (AI labs and their agents — the named target workload's builders) from even analyzing the code; bus factor 1 [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven: substantive (3.5M lines, real IFC/capability algebras, a working claim gate, 4,537-bead journal — all [Counted/Code-verified, High]) and unproven (no independent validation, no production user, red core CI at the pin, TARGETED end-to-end contract). "When in doubt, ring down" does not apply — there is no doubt about the Explore floor. The rider is instrumented as the advancement blocker: quoted as the adoption ceiling in §4.8, priced into feasibility (2) and collaboration (1). **Explore-with-a-ceiling**, currently un-advanceable past Explore while the rider stands. No Rulebook amendment; v1.0 stands.

**Methodology fit (for the FrankenSuite):** adopt the patterns, not the package — the claim-to-proof matrix with wording-state gating and freshness tiers, the `repro.lock`-partnered verification commands, the no-mock acceptance drills, the self-downgrading performance candor, and the declassification-receipt/transparency-log design are directly importable into how the program evaluates the other 42 repositories. Do not depend on the software: the rider, the missing releases, the red core CI, and the disavowed throughput disqualify it as a dependency, benchmark target, or training-data source. If the program needs JS execution, Node/Bun dominate on every adoption criterion except auditability — and the rider disqualifies FrankenEngine regardless [Inference, High].

---

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — JS language semantics, Ed25519/SHA-2 primitives, the RESP-like CLI surface.** Inherited standards; reimplementation is table stakes, not differentiation. Moves right only if the language owner moves it: each new ECMAScript edition grows the parser/lowering gap inventory the project must fund before claiming coverage [Inference, Medium].
- **Custom-built, approaching early Product — the claim-to-proof matrix + gate.** The most *executed* component in the tree: 28 claims bound to beads, artifacts, verification commands, and freshness tiers, with a CI script that refuses overclaiming prose. It is operational in-repo but not packaged for external adoption. Moves right if extracted as a standalone claim-gating framework other projects (inside or outside the suite) can adopt; stays repo-local tooling while the rider blocks the likeliest adopters [Inference, Medium].
- **Custom-built, pre-Product — the 3.5M-line runtime core** (parser, lowering pipeline, baseline interpreter, orchestrator). Custom-built on process rigor alone; not yet product (no release at pin, red core CI, TARGETED end-to-end contract, ~1,000× slower than Node). Moves right with a tagged release plus a green core lane plus the red-team v2 campaign; decommissions into a monument if the maintainer context-switches [Inference, Medium].
- **Genesis — the e-process guardplane decision ladder.** "Testing by betting" (anytime-valid inference) applied to live containment decisions — allow/challenge/sandbox/suspend/terminate/quarantine driven by Bayesian posteriors crossing e-process boundaries — has no incumbent equivalent in the runtime space. Moves right if the ladder's calibration is published with replay-anchored evidence (the red-team v2 campaign is the vehicle); stagnates as a single-maintainer decision-theory experiment if the thresholds stay unpublished [Inference, Medium].
- **Genesis — signed declassification receipts with transparency log + MMR proofs.** No incumbent ships "every authority downgrade is a signed, hash-chained, inclusion-proven event" as a runtime primitive. Moves right if extracted as the standalone audit crate (§"next steps" #2) and adopted by a second consumer; stays a bespoke sidecar otherwise [Inference, Medium].

**Residual product gaps (what's missing / risky):**

1. **No green core CI lane** — `native-runtime.yml` red across the observed window; `quality-gates.yml` and `perf_regression_gate.yml` never run [CI-observed, High].
2. **End-to-end capability contract TARGETED** — selected edges only; the compile-time TS-to-IR guarantee over all ambient constructs is a roadmap item [Maintainer claim, High].
3. **Throughput vacancy** — ~1,000× slower than Node on the only measured bundle; no weighted denominator contract; AOT modules are plans, not machine code [Maintainer claim, High].
4. **Test262 conformance TARGETED** — no corpus in-tree; 3 checked-in vectors [Maintainer claim, High].
5. **TEE attestation HYPOTHESIS** — simulated by default; no hardware root of trust [Maintainer claim, High].
6. **Fleet immune system TARGETED** — harness exists; the CI gate checks shape, not measured convergence percentiles [Maintainer claim, High].
7. **Shadow daemon advisory-only** — no live mutations until adoption gates go green [Maintainer claim, High].
8. **README inventory drift** — surface table a month stale on every count [Counted, High].

## 4.11 Trajectory (12 / 24 / 60 months)

All horizons **[Inference]** — forecasts, not findings; confidence Low unless noted.

**12-month base case [Inference, Medium]:** velocity continues at ~20 commits/day; the parity/coverage tail shortens bead by bead; the claim matrix keeps the README honest; the core CI lane either goes green (a repair sprint like frankenredis's September) or stays red and becomes the standing governance scandal; no tagged release at a new pin; the rider stands. The methodology gets mined (the matrix schema appears in sibling repos); the runtime gets no production users. Ring: Explore, unchanged.

**24-month base case [Inference, Low]:** one of two shapes. Either the program compounds — green core CI, the red-team v2 campaign executed and linked, a tagged release, the end-to-end capability contract promoted to OBSERVED — and the packet's checklist (deepening question 8) starts scoring above zero; or velocity decays after the initial program arc and the tree enters maintenance drift (matrix freshness tiers start expiring claims faster than evidence is rebuilt — the gate's own `max_observed_freshness_days` becomes the decay sensor). The base case leans toward the second shape on bus-factor-1 priors.

**60-month base case [Inference, Low]:** the software is either a niche artifact (a small following among agent-ops teams that value signed containment evidence over throughput) or dormant — the abandonment end state in the §4.7 steelman. The methodology-export (claim-to-proof gating, declassification receipts, e-process containment) is the durable survivor either way.

**Bifurcation — what the upside requires:** all five, in rough order: (a) the rider narrowed or removed (trigger 3) — without this nothing else matters for adoption; (b) the core CI lane green with the quality/perf gates actually executing (trigger 1); (c) the red-team v2 campaign executed and linked (trigger 2); (d) a tagged release with a stability policy (trigger 4); (e) a second human committer (trigger 5). The rider is the *necessary* condition: any four of the five **including the rider** moves the ring conversation to "can we pilot"; all five plus a bounded real workload fit is what meets the Pilot bar.

**Bifurcation — what decay looks like:** commit velocity falls off a cliff (trigger 6), the matrix's freshness tiers expire OBSERVED rows faster than re-verification rebuilds them (the gate downgrades the README automatically — decay made visible by the project's own machinery), CI workflows go silent, and the tree freezes as a 3.5M-line monument. Decay is the default outcome for bus-factor-1 infrastructure without institutional capture — the base case, not the tail.

**Revisit triggers (observable, falsifiable):**

1. **`native-runtime.yml` green at a new pin, with `quality-gates.yml` and `perf_regression_gate.yml` showing runs** — the Actions workflows page non-red *at the assessed commit*. Flips the "core lane never green" judgment.
2. **Red-team v2 campaign executed and linked from the matrix** — FE-CLAIM-011 leaves `target` with a current non-fixture campaign plus passing (or failing — a published loss counts) linked Rust verdict. Flips the containment thesis from specified to tested.
3. **Rider narrowed or removed** — LICENSE diff dropping the named-party restriction. Flips usability for restricted parties and contributor-pool risk. The advancement blocker for the Explore ceiling.
4. **A tagged release or GitHub Release pointing at the assessed commit** — `git for-each-ref refs/tags` / release list non-empty *at the assessed commit*. (v0.1.0 exists — released 2026-05-29 with `frankenctl` binaries — but targets the earlier tag commit `0a4e9db4`, so this stays open.) Flips the "no artifact to evaluate" judgment.
5. **Second human committer with merge rights** — bus factor > 1 observable on the contributor graph. Flips succession risk.
6. **Abandonment tripwire** — no commits for 60 days or the CI workflows disabled/archived: re-ring to Monitor and treat the tree as a retired artifact. The decay sensor the steelman's end state needs.
7. **Independent execution of the 13 OBSERVED matrix rows published** — any third party running the linked verification commands at a pinned commit. Flips "zero independent validation."
8. **A Deno/Node/SES release ships claim-gated documentation or signed decision receipts** — the kill-test: if incumbents absorb the auditability story, FrankenEngine's differentiation collapses to "slower, but with a gate" [Inference, Medium].
9. **End-to-end capability-typed contract promoted to OBSERVED** — FE-CLAIM-006's CEI-C.2 resolved with the compile-time TS-to-IR rejection over all ambient constructs. Flips the partial-membrane judgment.

## 4.12 Verdict & NODUS ring

**NODUS ring: Explore.** Substantive-but-unproven is the textbook case: substantive (3.53M lines, real IFC/capability algebras with law tests, a working claim-to-proof gate, zero unsafe in lib code, a 4,537-record bead journal — all [Counted/Code-verified, High]) and unproven (no independent validation, no production user, the core CI lane red at the pin across all 46 recorded runs, the end-to-end security contract TARGETED by the maintainer's own ledger, throughput candidly ~1,000× off Node). The rider is instrumented as the advancement blocker: quoted as the adoption ceiling in §4.8, priced into feasibility (2) and collaboration (1). The ring reads: **Explore — substantive, unproven, and currently un-advanceable past Explore while the rider stands** [Inference, Medium]. No Rulebook amendment; v1.0 stands.

**The one-paragraph case:** FrankenEngine is a 3.5M-line bet that a JS runtime for adversarial extension workloads can be built in safe Rust with information-flow control, capability-typed authority, deterministic replay, and signed evidence for every containment decision — and on methodology grounds it is the most honest codebase assessed in this program: its own claim gate refuses to let the README call it fast, secure end-to-end, or fleet-ready, and its license, badge shorthand, and stale inventory table are the places the honesty apparatus doesn't reach. But the product case is hollow at the pin: the core CI lane has never gone green in the observed window, two named quality gates have never run, the end-to-end capability contract is TARGETED, throughput is a vacancy, one human is the entire bus factor, and the license forbids the AI labs whose agent workloads are its stated reason to exist from even analyzing the code. Explore the methodology — the claim-to-proof gate, the declassification receipts, the e-process guardplane; the runtime stays behind the rider's ceiling until trigger 3 fires. [Inference, Medium — a recommendation plus a forecast, both the analyst's judgment.]

## 4.13 Limitations and open questions (analyst-facing)

**What was not done:** nothing was compiled; no test suite, gate script, or verification command was executed (so every OBSERVED matrix row is existence-verified, not behavior-verified); no benchmark was reproduced; the pin's failing CI steps were not log-dived (the failure *mode* — compile vs test assertion — is unestablished); line-level authorship attribution (`git blame` sampling) was not performed; crates.io publication status of the `frankenengine-*` packages was not checked; review depth (PRs vs direct-to-main, bead-closure reviewers) was not assessed; the full LICENSE was read but not compared line-by-line against sibling repos' riders; the 28-claim matrix JSON was parsed (wording-state fields verified on all 28 rows) but not fully audited claim-by-claim against source spans.

**Open questions that would most change the verdict, in order of load-bearing weight:**

1. **Why is the core CI lane red, and what is the failure mode?** All 46 recorded `native-runtime.yml` runs fail with `main-safety.yml` green at the same commits. Round-4 evidence narrows it: in the pin run's `core` job, the failing steps are `cargo test`-style ("Run native-core unit tests," "Run public native-core execution budget regressions") with *no separate build step preceding them* — so a compile breakage cannot be ruled out. Run logs require auth (API: 403), the latest recorded run is the pin's own (2026-09-21, head = pin), and no green run exists after it. The answer still determines whether this is a one-sprint repair or a structural testing deficit. (Not log-dived.)
2. **Does the rider bar this very assessment?** The license's "analyzing" prohibition arguably covers the FrankenSuite's evaluation activity — and this packet is an agent-assisted analysis of the code. A legal reading either way changes whether the program may continue touching the repo at all.
3. **Would any of the 13 OBSERVED rows survive a second-party execution?** The matrix is self-graded; one independent run of the linked verification commands is the cheapest falsification available to the program.
4. **What does the red-team v2 campaign show?** The exact path is specified (ten scenarios, pinned Node/Bun binaries, 100 receipt-bound repetitions per pair). A published loss would be more informative than the current TARGETED.
5. **Is there any production user or demand signal beyond `franken_node`?** One real deployment would move impact potential and the 24-month trajectory more than any code change. (Search 2026-09-22: none found.)
6. **What is the review depth?** PRs-vs-direct-to-main, who reviews bead closures, whether any of the 3,911 closed beads saw a second pair of eyes — unassessed; determines whether the bead journal is institutional knowledge or a solo diary.
7. **Are the `frankenengine-*` crates published to crates.io, or vendored-only? — Answered in round 3: vendored-only.** The crates.io API returns "does not exist" for `frankenengine-engine`, `frankenengine-core`, and `frankenengine-extension-host` (2026-09-22) [External, High]. The embeddable units travel as path dependencies pinned by commit SHA per the README's downstream-consumer contract — which is why deepening question 2's extraction proposals describe the units as "vendored, not versioned."

---

## Deepening questions — Rulebook §5's binding eight, one paragraph each

*§5→location mapping: Provenance ← the evidence ledger + transparency log/MMR (claim 7); Embeddable unit ← new, sourced from the crate topology (§4.4) with the crates.io publication caveat (§4.13 Q7); Unexercised option value ← AOT/tiering modules, the WASM workflow, the shadow daemon, the fleet harness; Benchmark honesty ← §4.5; Governance path ← §4.8 plus §4.7 weakness 5; License as strategy ← §4.8 plus §4.7 weakness 2; Agent-era fit ← the extension-host crate + franken_node's `engine` feature; Kill test ← §4.7's bear-case steelman plus trajectory trigger 8.*

**1. Provenance.** The system records *what was decided and on what evidence*: every evidence entry is Ed25519-signed with the originating runtime's key and chained by `prev_hash`, the transparency log carries MMR inclusion/consistency proofs, artifact bundles ship `run_manifest.json` with schema id, host facts, content hashes, and operator-verification commands, and replay captures the IR3 program, policy snapshot, model snapshot, evidence stream, and randomness transcript — so a containment decision is reproducible from fixed artifacts and tampering with the log is detectable [Code-verified + Maintainer claim, High on the machinery's existence]. What it does not record is *who produced the code that decided* — provenance of artifacts, not of authorship — and the receipt format is bespoke (no SIEM or external verifier ingests `fr_threat_ledger`-style sidecars natively), so portability would require standardizing the receipt schema, hash-chaining it across runtime instances, and binding entries to write-time origin the way the arXiv-2606.24322 direction (write-time origin binding as necessary against origin laundering) points [Inference, Medium]. The quiet irony: the repo that best records *decision* provenance in the suite records nothing about *code* provenance beyond git — the agent-authorship question that haunts its sibling frankenredis is simply unasked here because the trailer sample shows no agent co-authors [Git-observed, High].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is the `capability.rs` algebra — 22 `RuntimeCapability` variants, five canonical profiles, set-inclusion subsumption and intersection attenuation, deserialization that rejects smuggling, all under `#![forbid(unsafe_code)]` in a single finite module with law tests: a typed authority vocabulary any Rust host could embed to partition its own hostcall surface [Code-verified, High]. The IFC lattice module is the second candidate (five labels, join/meet, fail-closed `FlowPolicy`) [Code-verified, High]. Adoption cost is currently dominated by packaging, not code: `frankenengine-*` packages are not on crates.io at all (API: "does not exist," checked 2026-09-22 [External, High]), the README's consumption contract is path-dep plus pinned commit SHA, and the workspace pins a nightly-grade toolchain with sibling-substrate features on by default — so the unit is vendored, not versioned, and inherits the dependency assumptions [Inference, Medium]. The declassification-receipt stack (§"next steps" #2) is the larger but more valuable extraction; the capability algebra is the one that could move in an afternoon.

**3. Unexercised option value.** Four held capabilities. First, AOT/tiering: modules exist that "emit plans, guards, or provenance" but "should not be read as machine-code execution" (ARCHITECTURE_OVERVIEW) — a compiler backend held as design, not execution; building it would multiply the behavior-equivalence surface the baseline interpreter must prove against [Maintainer claim, High]. Second, WASM: a `native-wasm.yml` workflow exists and is active, but no WASM-target claim appears in the matrix's OBSERVED rows — the target is wired, the evidence unlinked [CI-observed, Medium]. Third, the shadow daemon: eight `shadow_*.rs` modules ship in advisory-only mode, forbidden live mutations until adoption gates go green — a fleet-observation plane waiting for its actuation permit [Maintainer claim, High]. Fourth, the fleet immune system: the N-node harness, SLO declaration, and de-escalation primitives exist but the CI gate "validates contract shape and source references without executing the harness" — quarantine-propagation convergence is specified, unmeasured [Maintainer claim, High]. What unlocks each: an equivalence-proof campaign against the baseline interpreter for AOT, a linked WASM evidence bundle for the wasm lane, green adoption gates for the shadow daemon, and an executed N-node campaign with preserved percentiles for the fleet story [Inference, Medium].

**4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the ones the maintainer refuses to promote: the preserved June 2026 bundle's `0.000920x` Node / `0.000791x` Bun ratios are dirty-worktree, asymmetric-lifecycle, and declared "non-normative historical baseline" by the matrix — they would likely reproduce *as what they are* (a slow interpreter measured sloppily), which is precisely why FE-CLAIM-010 stays `target` [Maintainer claim, High]. No headline number is load-bearing for the thesis, because the thesis as gated is not "faster" but "contained, replayable, and honestly described" — the load-bearing evidence is the 13 OBSERVED matrix rows, and those are behavior claims (gates execute, receipts verify, replay is byte-identical), not ratios [Inference, Medium]. The honesty audit's sharpest finding is structural: the perf regression gate (`perf_regression_gate.yml`) has zero runs ever, so even the project's internal speed ratchet is unwired — throughput is not being *managed*, merely disclaimed [CI-observed, High]. Reproduction cost for the honest numbers is a checkout plus the pinned toolchain and the per-claim scripts with `repro.lock` partners; no independent reproduction is known [External, High within recall caveats].

**5. The governance path.** The credible route from one maintainer to an institution runs through five gates in rough order: rider removal, green core CI with the quality/perf gates executing, the red-team v2 campaign linked, a tagged release with a stability policy, a second human committer (trajectory triggers 3, 1, 2, 4, 5). The starting position: no succession plan, no second committer, no foundation, no release artifact at the pin [Inference, Medium on the absences — the no-release half is Git-observed/External, High]. The closest thing to institutional knowledge transfer is the in-repo bead journal (3,911 closed beads with reasons) plus the claim matrix — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit; review depth is unassessed and parked as §4.13 Q6. What breaks first if velocity decays: the matrix's own freshness tiers — `max_observed_freshness_days` will start auto-downgrading OBSERVED rows faster than re-verification rebuilds them, so the project's honesty machinery becomes its decay sensor, visible on the README itself [Inference, Medium]. Beyond the five gates, the realistic institutional endpoints are a foundation home or a corporate adopter for the agent-runtime story — both currently gated on rider removal, which is why trigger 3 is the advancement blocker rather than a nicety [Inference, Low].

**6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates; and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — barring "use" defined to include "benchmarking, testing, analyzing, indexing" and incorporation "into any dataset, training corpus, evaluation harness, or pipeline for machine learning," with automatic termination on breach and a viral clause requiring the rider in every distribution [Code-verified (license text), High]. Does the exclusion serve or sabotage the stated mission? It sabotages adoption and evaluability with unusual precision: the mission is *agent-extension containment*, and the excluded parties are the builders of the agent systems that would adopt it — the rider names the demand side [Inference, High]. What it arguably *serves* is a defensive intent — denying 3.5M lines of curated containment-machinery code to rival training corpora — but that intent is unlabeled by the author and the cost is asymmetric: the project selects for adopters who cannot evaluate it, and a project whose constitution is *evidence* forbidding evidence-gathering by the best-equipped evaluators is self-negating [Inference, Medium]. The remaining strategy point: the rider is a licensee-facing contract term — it binds users, not the author — so it neither creates nor answers any question about the tree's own construction; its strategic function is access control, and as access control it locks out exactly the users the architecture was built for [Inference, Medium].

**7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is the one the repo was built around: an agent platform executing untrusted third-party or model-generated extensions, where each extension runs under a `ComputeOnlyCaps`-default capability profile, every hostcall crosses a typed capability check, IFC labels track data sensitivity to sinks, the guardplane can suspend or quarantine a misbehaving extension mid-run, and every containment decision lands in the signed evidence ledger for post-incident replay — the extension-host crate plus `franken_node`'s `engine` feature flag is already this shape [Inference, Medium]. What would have to become true first: the end-to-end capability-typed contract promoted from TARGETED to OBSERVED (partial membranes don't contain), the core CI lane green (untrusted-code infrastructure cannot ship on a red test lane), a tagged release to pin the eval to — and the rider narrowed or removed, because the agent-platform operators are named Restricted Parties and may not even *analyze* the code today [Inference, Medium]. The fit is the most natural in the suite and the most blocked: the architecture's ideal customer is its license's forbidden party [Inference, High].

**8. The kill test.** The single experiment that would falsify the core thesis — that a native, capability-typed, replay-anchored JS runtime is a differentiable, adoptable containment substrate — is the one the project already specified for itself: the red-team v2 campaign (ten contract-declared scenarios under pinned FrankenEngine, Node, and Bun binaries, 100 receipt-bound stability/replay repetitions per pair, one-scenario zero-cell guard). If it ever executes and FrankenEngine's compromise rate is not better than Node-with-SES/LavaMoat or Deno's permission model on the same corpus, the containment pillar is falsified by the project's own mechanism, not by a critic [Inference, Medium]. Two secondary falsifiers sit behind it: an incumbent move (Deno or Node shipping claim-gated documentation or signed decision receipts — trajectory trigger 8 — collapsing the differentiation to "slower, but with a gate") and the abandonment tripwire (trigger 6: 60 days without commits re-rings to Monitor). The inverse checklist — what success requires — scores 0 of 9 fully met at the pin: green core CI with executing quality/perf gates, the v2 campaign linked, rider narrowed, tagged release at the assessed commit, second committer, independent OBSERVED-row execution, end-to-end contract promoted, TEE no longer simulated, fleet harness measured. The single partial is none — every item is unambiguously unmet, which is itself the finding [Inference, Medium].