# Franken Native Capsule — RULEBOOK v1.0 Assessment Packet v6

**Repository:** `Dicklesworthstone/franken_native_capsule` · **Language:** Rust (edition 2024, pinned `nightly-2026-08-18` toolchain) [Code-verified, High] · **Pinned commit:** `7af57e2c43d42e77eff569b133b263c4e2a858f9` (2026-08-20 16:16:33 -0400 = 2026-08-20 20:16:33 UTC, [Git-observed, High]) · **Last push:** 2026-09-17T22:38:26Z per GitHub API, but both `main` and `master` point at the pin — no commit has moved the default branch since 2026-08-20 [External + Git-observed, High] · **Scope:** the pinned commit only, which is also HEAD (`git ls-remote` confirms the pin is the remote HEAD) [Git-observed, High]. No tags, no releases [External, High].

**Method (analyst):** shallow clone (`--depth 1`) of HEAD at the pin under `~/workspace/.scratch/franken_native_capsule-verify`; the history is a single squashed commit (`git rev-list --count HEAD` = 1), so there is no deeper history to sample. Read: root `Cargo.toml`, all 3 crate manifests, `Cargo.lock` (spot-checked), `rust-toolchain.toml`, README (56 lines, verbatim), AGENTS.md (38 lines, verbatim), and all 6 `.rs` files (2,851 lines) in full — the tree is small enough to read whole. Counted: `.rs` files/lines, `unsafe {` blocks, `#[test]` functions, `pub` API items, external dependency union. Ran `grep` sweeps for `asupersync`, audio/format strings, and license text. Fetched the GitHub repo API object (stars/forks/description/license/topics/branches/tags/releases) and verified all 11 quick links resolve (HTTP 200, checked 2026-09-22). **Not done:** the workspace was never compiled; no test was executed; no benchmark exists to reproduce; `franken_node`/`franken_engine` (the claimed upstream dependents) were not assessed; ADR-0010 (cited as the governing spec, at a local `/dp/franken_engine/...` path) was not read — it lives outside this repo. Assessment date: 2026-09-22.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — 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/AGENTS.md, not independently executed; **[External]** independent sources (GitHub API / web); **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

---

## Hook

franken_native_capsule is not an audio player. It is a 2,851-line [Counted, High] Rust trust boundary for executing JIT-compiled machine code inside a guard-paged W^X (write-xor-execute) sandbox — and the only machine code it will ever execute is **39 bytes of pre-audited x86-64** [Code-verified, High]. The repo is the separately owned native-code capsule for FrankenEngine (ADR-0010): an authority-free compiler worker that genuinely lowers a loop with Cranelift 0.134.2 and then *refuses its own output* unless it is byte-identical to a frozen, hash-pinned constant [Code-verified, High]; a validator that re-checks plan, compiler identity, receipt, seal, target, entrypoint, and authorization epochs before admission; and a runtime that maps the image RX-only between guard pages, calls exactly one System V entrypoint, then zeroes and unmaps it. It ships no license text, no CI, no releases [Verified/External, High] — and an explicit, admirable disavowal: this is "bring-up evidence only," not containment, not parity, not performance. The honest question the packet keeps returning to: a trust boundary that its own engine has not enabled is a design sketch wearing a sandbox's clothes.

---

## TL;DR

- **What it is:** A three-crate Cargo workspace (2,851 first-party Rust lines across 6 files [Counted, High]) implementing the native-code execution trust boundary for FrankenEngine per ADR-0010: a safe wire-type API crate, an authority-free Cranelift compiler worker that emits sealed address-free compilation objects (RCOs), and a runtime that validates, maps (RX-only, guard-paged, never RWX), invokes (one System V leaf ABI call site), and retires (zero + unmap) exactly one frozen fixed probe — a wrapping `u64 -> u64` sum-to-exclusive function. Linux x86-64-v3 only, behind an off-by-default feature.
- **Verdict:** TRL 3–4. NODUS ring: **Explore** (substantive-but-unproven; Explore-with-a-ceiling — the ceiling is the missing production path: no production plan/compilation-object schema v1 (the repo's "NRP/RCO v1" — neither acronym is expanded in-tree), no issuer signature verifier, no durable nonce store, no worker supervisor, and the README's own statement that FrankenEngine does not enable it).
- **Strongest strength:** Adversarial honesty as an engineering discipline — the README enumerates what the code is *not* (nine named non-capabilities), disavows containment and performance claims in writing, and the validator's admission gate is a byte-exact equality check against a 39-byte audited constant, the strongest form of "we only run what we audited." The unsafe surface is 13 counted `unsafe {}` blocks confined to two explicitly allow-listed modules, with the other two crates `#![forbid(unsafe_code)]` [Counted/Code-verified, High].
- **Strongest ceiling:** Nothing consumes it. The production dependency direction the README asserts (`franken_node -> franken_engine -> franken_native_capsule`) is unverifiable from this repo and, by the README's own admission, the capsule "is not enabled by FrankenEngine." One squashed commit, no CI, no license text, no releases, 2 stars, 0 forks, and no commit to the default branch in 33 days [all Verified/External, High]. A trust boundary with no trustor is a demo.

---

## Quick Links

Pin-relative links (`blob/7af57e2c43d42e77eff569b133b263c4e2a858f9`); all verified HTTP 200 on 2026-09-22 [Verified, High]:

1. [Repository](https://github.com/Dicklesworthstone/franken_native_capsule) — description: "Separately owned native-code capsule for FrankenEngine (ADR-0010)"; 2 stars, 0 forks
2. [README](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/README.md) — 56 lines; contains the bring-up disavowal
3. [AGENTS.md](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/AGENTS.md) — safety boundary, architecture rules, work discipline
4. [Workspace Cargo.toml](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/Cargo.toml) — 3 members, exact-pinned Cranelift 0.134.2 graph, `license = "MIT"` metadata, `repository` pointing at a nonexistent `franken-suite` org URL
5. [rust-toolchain.toml](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/rust-toolchain.toml) — `nightly-2026-08-18`
6. [Compiler worker](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/crates/franken-native-capsule-worker/src/lib.rs) — 520 lines; Cranelift lowering + frozen 39-byte allowlist gate
7. [Runtime](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/crates/frankenengine-native-capsule/src/lib.rs) — 413 lines; activate/execute/retire lifecycle
8. [Validator](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/crates/frankenengine-native-capsule/src/validator.rs) — 330 lines; the admission gate
9. [Executable memory](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/crates/frankenengine-native-capsule/src/platform/linux/executable_memory.rs) — 405 lines; guard-paged W^X lifecycle
10. [API wire types](https://github.com/Dicklesworthstone/franken_native_capsule/blob/7af57e2c43d42e77eff569b133b263c4e2a858f9/crates/frankenengine-native-capsule-api/src/lib.rs) — 1,143 lines; `#![forbid(unsafe_code)]`
11. [Repo API object](https://api.github.com/repos/Dicklesworthstone/franken_native_capsule) — stars/forks/tags/releases/branches/license fields

---

## Did You Know

The compiler worker genuinely compiles — and then doesn't trust the compiler. `compile_sum_to_exclusive_u64()` builds the sum loop with Cranelift's IR builder (`cranelift_codegen` + `cranelift_frontend`, opt=speed, x86-64-v3, non-PIC), but the emitted bytes are then passed through `validate_machine_code_allowlist`, which rejects them unless they are byte-identical to `FIXED_PROBE_MACHINE_CODE_V1`: a frozen, audited 39-byte array with a pinned SHA-256 (`FIXED_PROBE_CODE_SHA256`). The compiler identity itself is hashed into a string — `cranelift-codegen=0.134.2;cranelift-frontend=0.134.2;triple=x86_64-unknown-linux-gnu;target=x86-64-v3;opt=speed;pic=false;cfg-info=true` — and bound into every receipt. So the trust story is not "our compiler is correct"; it is "the only bytes we ever execute are these 39 we audited, and we re-prove it on every activation." [Code-verified, High]

---

## Franken-worthy next steps

1. **Export the frozen-hash admission pattern as the program's native-code execution template.** The validator's gate — the only admissible executable is byte-identical to a pre-audited constant, with SHA-256 binding plan → compiler identity → receipt → final image — is the strongest sandbox-admission discipline seen in the FrankenSuite: it sidesteps compiler-correctness proofs entirely by shrinking the trusted bytes to 39. Extract the admission checklist (plan hash, compiler-identity hash, seal, target, leaf-metadata, entrypoint, authorization window, byte budget) into a standalone pattern doc other repos can adopt. *Done when:* the checklist is a separate document with a named owner, and a second frozen operation (e.g., a `memcmp`-style probe) passes the same gate. [Inference, High — process proposal]
2. **Kill-test the validator with a mutation harness.** The core thesis — "no non-frozen payload can be admitted" — is falsifiable today: mutate the RCO (flip code bytes, swap entrypoints, forge receipts, replay nonces) and require 100% refusal, with a refusal-taxonomy ledger. The existing tests already exercise refusal, nonce replay, and under-budget activation; a systematic mutator turns the thesis into a standing experiment. *Done when:* N mutations run in CI with zero admissions and the ledger is committed. [Inference, High]
3. **Write the program's license-intake screen, using this repo as the forcing case.** The finding is not "add a LICENSE file" (hygiene); it is that a trust-boundary component cleared the program's own bar with *metadata-only* licensing — `license = "MIT"` in `Cargo.toml`, no text, GitHub detecting nothing — and no intake step caught it. Research direction: formalize the intake rule the FrankenSuite should have had — no dependency or assessment target clears intake without license *text* in-tree, with the SPDX identifier cross-checked against it — and back-apply it to all 44 repos as a drift screen. *Done when:* the intake rule is written into the program's dependency policy with a named owner, and the 44-repo screen reports how many others have metadata/text drift. [Inference, High]
4. **Make receipts portable attestations: add the missing issuer signature.** The receipt chain (plan → compile receipt → activation receipt → retirement receipt) is content-addressed and canonical-encoded — portable as data — but unsigned: the README admits there is no issuer signature verifier. Research direction: sign the RCO seal with a bring-up key, verify in `activate()`, and prove a hash-valid but signature-invalid RCO is refused. *Done when:* a tampered-but-hash-consistent RCO is refused for signature reasons, and the refusal is covered by a test. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The assigned description does not match the repo — this is the packet's load-bearing finding.** The run inventory describes this repo as "a cross-platform native Rust audio player: a local-first, offline audio playback engine with a native UI, focused on FLAC/MP3/WAV… WinUI 3, AppKit, GTK4… high-res DAC support, ReplayGain, gapless playback, crossfade, and FFmpeg integration… includes an example Asupersync integration" (~5 stars). None of that is in the pinned tree: a case-insensitive sweep of every `.rs`, `.toml`, and `.md` file finds zero occurrences of audio/flac/mp3/wav/dac/replaygain/gapless/crossfade/ffmpeg/winui/appkit/gtk, and zero occurrences of `asupersync` [Verified, High]. GitHub reports 2 stars, not ~5, and the repo's own description field reads "Separately owned native-code capsule for FrankenEngine (ADR-0010)" [External, High]. The audio-player description matches no `Dicklesworthstone` repository found by web search; the maintainer's audio-adjacent repos are `franken_whisper` (ASR orchestration) and `franken_tts` (TTS) — different lanes, different repos [External, Medium]. This packet therefore assesses the repo that exists, not the description that was assigned; the mismatch is recorded as an inventory-governance finding, not a repo defect.

**The problem, as the maintainer frames it:** FrankenEngine (a from-scratch JavaScript engine in the same program) needs a native-code execution mechanism — JIT-compiled or ahead-of-time machine code running inside the process — but that mechanism must not be owned by the engine's semantics, policy, or authority layers. The capsule is the "separately owned" trust boundary: it contains "no JavaScript parser, values, semantics, policy selection, replay policy, evidence-signing keys, or guest authority," and the production dependency direction is strictly `franken_node -> franken_engine -> franken_native_capsule` [Maintainer claim, Medium — the README asserts the direction; the two upstream repos were not assessed, so the direction is unverified].

**Who feels the pain:** whoever builds FrankenEngine's JIT/OSR/deoptimization path and needs somewhere to put machine code that isn't the engine's own process image — a classic V8-sandbox-shaped problem, scoped here to a from-scratch engine [Inference, Medium].

**Why now:** the README gives no market timing argument, and none is inferable — the repo is a single squashed commit from 2026-08-20 with no changelog, no roadmap doc, and no cited demand. The honest reading is that this is bring-up infrastructure for an internal program milestone (ADR-0010), not a response to external demand [Inference, Medium].

**Why a separate repo, not a module:** stated in the first line — "separately owned" is the point. Ownership separation is the trust boundary: the mechanism that maps executable memory must not share review, release, or authority with the guest code it will eventually run [Maintainer claim, Medium — architectural intent, corroborated by the crate structure].

## 4.2 What it is — repo TL;DR

A 3-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing FrankenEngine's ADR-0010 native-code capsule in 2,851 first-party Rust lines across 6 files [Counted, High]: `frankenengine-native-capsule-api` (safe, versioned wire types + fixed-probe NRP/RCO v0 schema, `#![forbid(unsafe_code)]`), `franken-native-capsule-worker` (authority-free Cranelift compiler worker emitting sealed, address-free RCOs — no absolute addresses; the validator requires zero relocations — `#![forbid(unsafe_code)]`), and `frankenengine-native-capsule` (structural validation, executable-image lifecycle, relocation rejection, Linux platform adapter, raw invocation — `#![deny(unsafe_code)]` at the root with two `#[allow(unsafe_code)]` modules). The only executable path is the opt-in `embedded-fixed-probe` feature: a deliberately closed Linux x86-64-v3 slice that compiles, seals, validates, maps (RX-only, guard-paged), invokes (one System V `u64 -> u64` call site), and retires (zero + unmap) a single frozen wrapping-sum probe. Ten tests [Counted, High]; no CI; no releases; one squashed commit.

One-line verdict: **the most honestly scoped 2,851 lines in the FrankenSuite — a trust boundary that disavows trust, shipping real W^X machinery and a frozen-hash admission gate for a production path (NRP/RCO v1) that does not exist and an engine (FrankenEngine) that does not enable it.** (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

Claims 1–12 audit the **assigned run-inventory description** against the repo (the mismatch finding). Claims 13–32 audit the **README/AGENTS.md claims** against the code. Tier flavors as in the header.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | This repo is a cross-platform native Rust audio player (FLAC/MP3/WAV, native UI) | **disproven** | Case-insensitive sweep of all `.rs`/`.toml`/`.md` at the pin: zero hits for audio/flac/mp3/wav/dac/gapless/crossfade/ffmpeg/winui/appkit/gtk | [Verified, High] |
| 2 | It includes an example asupersync integration | **disproven** | `grep -ri asupersync` over the whole tree: zero hits; no asupersync in any manifest or `Cargo.lock` | [Verified, High] |
| 3 | "~5 stars" | **disproven** (as a count) | GitHub API 2026-09-22: 2 stars, 0 forks | [External, High] |
| 4 | The FrankenSuite MIT + OpenAI/Anthropic rider applies here | **disproven** | No LICENSE file exists in the tree; no rider text anywhere; `license = "MIT"` appears only as workspace package metadata. The rider premise does not hold for this repo | [Verified, High] |
| 5 | 3 workspace crates, 2,851 first-party Rust lines / 6 files | demonstrated | `Cargo.toml` members enumerated; `find` + `wc -l` over `.rs` files excluding target/ | [Counted, High] |
| 6 | 10 tests | demonstrated | `grep -c '#[test]'` per file: 2 worker + 4 api + 2 runtime lib + 1 executable_memory + 1 validator = 10 | [Counted, High] |
| 7 | Pinned `nightly-2026-08-18` toolchain | demonstrated | `rust-toolchain.toml` read verbatim | [Code-verified, High] |
| 8 | No CI workflows | demonstrated | No `.github/` directory at the pin | [Verified, High] |
| 9 | No tags, no releases | demonstrated | GitHub API: `tags` = [], `releases` = [] | [External, High] |
| 10 | `main` and `master` both point at the pin; no default-branch commit since 2026-08-20 despite `pushed_at` 2026-09-17 | demonstrated | `git ls-remote` (pin = remote HEAD); API branch list; API `pushed_at`. The Sep-17 push did not move either branch — most likely a branch creation (`master`) at the same commit | [Git-observed + External, High] on the refs; [Inference, Medium] on the cause |
| 11 | Single squashed commit is the entire history | demonstrated | `git rev-list --count HEAD` = 1 ("docs(capsule): bound nonce replay domain precisely") | [Git-observed, High] |
| 12 | Workspace `repository` field points at `https://github.com/franken-suite/franken_native_capsule`, which 404s | demonstrated | `Cargo.toml` read; URL fetched → HTTP 404. Stale/wrong repository metadata | [Code-verified + Verified, High] |
| 13 | "Separately owned native-code mechanism for FrankenEngine"; contains no JS parser/values/semantics/policy/replay/keys/authority | demonstrated | No such code exists in the 6 files; crate structure matches the ownership claim | [Code-verified, High] |
| 14 | Production dependency direction `franken_node -> franken_engine -> franken_native_capsule` | aspirational | Asserted in README; the two upstream repos are outside this assessment — direction unverified and currently unrealized ("not enabled by FrankenEngine") | [Maintainer claim, Low] |
| 15 | API crate: "safe, versioned lifecycle wire types and a provisional fixed-probe NRP/RCO v0" with `#![forbid(unsafe_code)]` | demonstrated | 1,143-line lib.rs; wire-version negotiation, schema v0 types; forbid attribute at line 1 | [Code-verified, High] |
| 16 | "The broader production NRP/RCO v1 required by ADR-0010 is intentionally not claimed" | demonstrated (as disavowal) | README states it; the validator admits only the fixed v0 subset — corroborated by code | [Maintainer claim + Code-verified, High] |
| 17 | Runtime crate: "structural validation, executable-image lifecycle, relocation, platform adapters, and raw invocation" | partially demonstrated | Validation, lifecycle, raw invocation demonstrated; "relocation" is a validator *rejection* (relocations must be empty), not support; "platform adapters" plural is one adapter (Linux x86-64) | [Code-verified, High] |
| 18 | "First-party unsafe is permitted only in the exact ADR-0010 module allowlist" | partially demonstrated | 13 counted `unsafe {}` blocks, all inside the two `#[allow(unsafe_code)]` modules — but the AGENTS.md allowlist also names `process_sandbox`, `process_supervisor`, `unwind_registration` modules that **do not exist** in the tree. The allowlist is forward-looking, not descriptive | [Counted + Code-verified, High] |
| 19 | Worker: "authority-free compiler worker that emits sealed, address-free RCOs and never maps or executes them" (`#![forbid(unsafe_code)]`) | demonstrated | 520-line lib.rs; forbid at line 1; zero `mmap`/`mprotect`/`VirtualAlloc` occurrences in the worker; RCO sealing via SHA-256 | [Code-verified, High] |
| 20 | "The implementation follows …/ADR-0010-native-code-capsule-trust-boundary.md" | aspirational | The ADR path (`/dp/franken_engine/docs/adr/…`) is a local dev path outside this repo; not read, not verifiable from the pin | [Not verified, Low] |
| 21 | "The currently implemented fixed-probe path is bring-up evidence only: it is not JavaScript execution, is not enabled by FrankenEngine, and establishes no production containment or performance claim" | demonstrated (as disavowal) | README verbatim; corroborated: no JS, no FrankenEngine wiring in-tree, no benchmarks | [Maintainer claim, High] |
| 22 | The opt-in `embedded-fixed-probe` feature enables one deliberately closed Linux x86-64-v3 path | demonstrated | Optional dependency + `cfg(feature)` gating throughout; `host_supports_x86_64_v3` gate; off by default | [Code-verified, High] |
| 23 | The worker lowers "only the frozen wrapping sum-to-exclusive `u64 -> u64` plan with Cranelift 0.134.2 and returns an opaque compilation object" | demonstrated | `compile_sum_to_exclusive_u64()` genuinely lowers via `cranelift_codegen`/`cranelift_frontend` (opt=speed, x86-64-v3, non-PIC), then `validate_machine_code_allowlist` rejects output ≠ the frozen 39-byte `FIXED_PROBE_MACHINE_CODE_V1` | [Code-verified, High] |
| 24 | The runtime revalidates "the exact plan, compiler identity, receipt, RCO seal, target, leaf metadata, entrypoint, authorization window/profile/epochs, and page-rounded executable-byte budget" | demonstrated | `validate_fixed_probe` + `validate_activation_authorization` check every listed binding; exact-match on code bytes, compiler SHA, seal, epochs, windows | [Code-verified, High] |
| 25 | "Linux maps a dedicated guard-page-surrounded region `PROT_NONE -> RW -> RX`, never RWX" | demonstrated | `executable_memory.rs`: anonymous `mmap(PROT_NONE)` with guard pages, `mprotect` RW for population, RX for execution; no RWX anywhere | [Code-verified, High] |
| 26 | "The only raw call site admits the exact System V leaf ABI" | demonstrated | `raw_invoke.rs`: one `unsafe` call through a `unsafe extern "C" fn(u64) -> u64` transmute; the single `unsafe {}` in the file | [Code-verified, High] |
| 27 | "Input is bounded by the NRP before native entry" | demonstrated | `execute()` rejects `input > maximum_input` before `invoke_fixed_probe` | [Code-verified, High] |
| 28 | "Retirement removes execute, zeroes the complete middle mapping, unmaps it, and reports reclaimed bytes" | demonstrated | `retire()`: RX→RW transition, zeroing, `munmap`, `RetirementReceiptV1` with refunded bytes; `Drop` does best-effort revoke+zero+unmap | [Code-verified, High] |
| 29 | "Tests compare multiple native results with an independent wrapping oracle, inspect `/proc/self/maps` for RX-without-W, exercise refusal and nonce replay, and prove the retired address is no longer mapped" | demonstrated | `fixed_probe_is_correct_rx_only_bounded_and_retired` and `activation_refuses_mismatch_replay_and_underbudget` read verbatim; all four behaviors asserted | [Code-verified, High] |
| 30 | "It is not an IPC worker, issuer signature verifier, durable nonce store, process sandbox/supervisor, unwind or CFI registrar, JavaScript NRP lowering, deoptimizer, OSR path, or production router" | demonstrated | None of these exist in the tree (the api crate *declares* some vocabulary — budgets, profiles, epochs — but no mechanism) | [Code-verified, High] |
| 31 | "Elapsed/output limits are post-operation admission checks and the transient-memory field is not enforced without the missing external worker supervisor" | demonstrated (as self-reported gap) | README states it; no supervisor or enforcement code in-tree | [Maintainer claim, High] |
| 32 | AGENTS.md: "`cranelift-jit` is forbidden in production" | demonstrated | Zero hits for `cranelift-jit`/`cranelift_jit` across `Cargo.lock` and all manifests | [Code-verified, High] |

**What the inventory says in aggregate:** claims about *mechanism* (W^X lifecycle, frozen-hash admission, refusal behavior) verify at High confidence from a complete read of a small tree; claims about *context* (dependency direction, ADR conformance, engine adoption) are aspirational or unverifiable; and four claims from the run's assigned description (audio player, asupersync, ~5 stars, the AI-lab rider) are **disproven** — they describe a different repo, or no repo at all.

## 4.4 Codebase tour

**Workspace topology (3 members, [Counted, High]):** `frankenengine-native-capsule-api`, `frankenengine-native-capsule`, `franken-native-capsule-worker`.

**Dependency posture:** 19 external crates in the union over the 3 manifests (exact-pinned with `=` throughout the workspace table): 13 Cranelift crates (all `=0.134.2`) plus libc `=0.2.189`, postcard `=1.1.3`, serde `=1.0.229`, sha2 `=0.10.9`, target-lexicon `=0.13.5`, thiserror `=2.0.20` [Counted, High]. The workspace comment is explicit about intent: "Keep every published Cranelift crate in the selected backend graph as an exact direct constraint so dependency composition cannot silently mix patch releases and invalidate the audited compiler/machine-code identity." Notes: **no asupersync** (the brief's integration claim is disproven — §4.3 claim 2), **no cranelift-jit** (forbidden by AGENTS.md, corroborated), **no tokio** (no async surface at all), and the ordinary (feature-off) dependency graph is just libc/sha2/thiserror/postcard/serde — the 13-crate Cranelift graph enters only via the optional `embedded-fixed-probe` feature, exactly as the README promises [Code-verified, High].

**Data flow, end to end (the fixed-probe path):**

- **Plan — `frankenengine-native-capsule-api` (1,143 lines [Counted, High], `#![forbid(unsafe_code)]`):** versioned wire types. `FixedNativeRegionPlanV0` (schema version, target, operation, maximum input, semantics/lowering SHA-256 pins), `CompileAuthorizationV1` (authorization id, plan hash, target, execution profile, budgets, policy/security epochs, validity window, nonce), `SealedFixedProbeRcoV0` (payload + SHA-256 seal), `ActivationAuthorizationV1`, `ActivationReceiptV1`, `RetirementReceiptV1`. Two load-bearing details: every canonical hash and seal in the trust chain is computed over `postcard`'s deterministic encoding — postcard is the canonicalization the whole receipt chain stands on [Code-verified, High] — and the wire types carry enforced `MAX_*` bounds (`MAX_WIRE_MESSAGE_BYTES`, `MAX_RCO_CODE_BYTES`, `MAX_FIXED_PROBE_INPUT`, …), i.e., DoS-hardening at the type level [Code-verified, High]. The api crate's 4 tests cover exactly the trust-relevant surface: version negotiation, canonical wire round-trip with tamper/trailing-byte rejection, the RCO seal binding every payload byte, and plan validation rejecting unrecognized contracts [Code-verified, High]. Protocol version negotiation (`ProtocolHello`, wire major/minor) is declared but has no transport — the wire exists as types, not as a channel [Code-verified, High].
- **Compile — `franken-native-capsule-worker` (520 lines [Counted, High], `#![forbid(unsafe_code)]`):** `compile_fixed_region` validates the plan and authorization (epochs, windows, budgets), genuinely lowers the sum-to-exclusive loop with Cranelift (IR builder, opt=speed, x86-64-v3, non-PIC), then runs the allowlist gate: emitted bytes must equal the frozen 39-byte `FIXED_PROBE_MACHINE_CODE_V1`, whose SHA-256 is the pinned `FIXED_PROBE_CODE_SHA256`. It then seals the payload (SHA-256), binds compiler identity (`cranelift-codegen=0.134.2;…;target=x86-64-v3;opt=speed;pic=false;cfg-info=true`, hashed), and returns `FixedRegionCompilation` — plan + sealed RCO + receipt with transcript hash. It never maps or executes anything [Code-verified, High].
- **Validate — `frankenengine-native-capsule::validator` (330 lines [Counted, High]):** `validate_fixed_probe` re-checks the whole chain: plan validity, RCO seal, exact target (`LinuxX86_64V3`), exact operation (`SumToExclusiveU64`), payload plan-hash binding, compiler-identity match, code bytes == frozen constant, receipt↔RCO binding (plan/receipt/transcript SHA-256, resource estimates), then activation authorization (ids, nonces, epochs, validity window vs `now_unix_ns`, profile must be exactly `Jit/EmbeddedProcess/TrustedThroughput/None/non-Disabled`), then payload structure (no rodata, no relocations, exactly one entrypoint named `sum_to_exclusive_u64` at offset 0 with `U64ToU64` signature, leaf-only metadata, declared unsupported-classes match, unique in-bounds branch targets, resource accounting match). Fail-closed typed errors throughout [Code-verified, High].
- **Map/invoke — `platform::linux::executable_memory` (405 lines) + `arch::x86_64::raw_invoke` (40 lines):** anonymous `mmap(PROT_NONE)` sized for code + two guard pages; `mprotect` RW to populate; zero padding; `mprotect` RX; copy the validated bytes. `FixedProbeCapsule::activate` additionally gates on `host_supports_x86_64_v3()` (15 CPU features) and a caller-owned nonce registry (in-process replay guard — the README is explicit that the *durable* nonce store is a missing external prerequisite). `execute` enforces the NRP input ceiling, then the single raw call site transmutes the entry address to `unsafe extern "C" fn(u64) -> u64` and calls it — with a `NCC-SAFETY-X86-RAW-INVOKE-001` invariant block citing the linked test. `retire` revokes RX, zeroes the mapping, `munmap`s, and returns the reclaimed-byte receipt; `Drop` repeats the revoke/zero/unmap best-effort [Code-verified, High].

**Unsafe arithmetic, stated explicitly:** 2 crates `#![forbid(unsafe_code)]` (api, worker) + 1 crate `#![deny(unsafe_code)]` at the root with `#[allow(unsafe_code)]` on exactly two modules (`arch::x86_64::raw_invoke`, `platform::linux::executable_memory`) = **13 counted `unsafe {}` blocks** (12 in executable_memory, 1 in raw_invoke), plus one `unsafe extern "C" fn` type declaration (not a block). The AGENTS.md invariant-ID discipline verifies by count: exactly 13 `NCC-SAFETY-*` IDs appear across exactly the two allowlisted files — 13/13 against the 13 blocks — with `SAFETY:` adjacency spot-checked on the raw-invoke and mmap/mprotect sites [Counted + Code-verified, High]. The reviewability consequence is the point: the entire unsafe surface fits in two files (445 lines combined), so a reviewer can audit every memory-safety assumption in one sitting — the auditability the design promises is actually achievable at this scale [Inference, Medium]. The api crate's 1,143 lines and the worker's 520 lines contain zero unsafe — the unsafe surface is exactly the memory-mapping and call boundary, which is the correct shape for this design.

## 4.5 The maintainer's stated case

**The pitch, in the maintainer's own structure:**

1. **Separate ownership as the trust boundary:** the native-code mechanism lives in its own repo, contains no engine semantics or authority, and the dependency direction is strictly downstream — `franken_node -> franken_engine -> franken_native_capsule` [Maintainer claim, Medium — intent corroborated by structure; the direction itself unverified].
2. **Bring-up honesty:** the fixed probe is "bring-up evidence only" — not JavaScript execution, not enabled by FrankenEngine, establishing "no production containment or performance claim" [Maintainer claim, High — quoted verbatim from the README].
3. **Frozen-hash admission:** the only bytes ever executed are byte-identical to an audited constant; compiler identity, plan, receipt, and final image are all SHA-256-bound into receipts [Code-verified, High for the mechanism's existence]. The design accepts a hard operational consequence: any Cranelift codegen change (toolchain upgrade, flag drift) makes the worker fail closed — it refuses its own output rather than emitting different bytes — so compiler upgrades are breaking changes by design, not silent drift [Inference, Medium].
4. **W^X discipline:** guard-paged `PROT_NONE -> RW -> RX`, never RWX; retirement zeroes and unmaps; tests inspect `/proc/self/maps` [Code-verified, High for the mechanism; the tests were read, not executed].
5. **Bounded unsafety:** unsafe permitted only in the ADR-0010 allowlisted modules, each block carrying a stable invariant ID and linked test [Partially demonstrated — the allowlist names three modules that don't exist yet; §4.3 claim 18].

**The disavowal — quoted and located precisely:** the README's final section states verbatim: *"The currently implemented fixed-probe path is bring-up evidence only: it is not JavaScript execution, is not enabled by FrankenEngine, and establishes no production containment or performance claim."* And: *"elapsed/output limits are post-operation admission checks and the transient-memory field is not enforced without the missing external worker supervisor."* Any downstream citation that presents this repo as a sandbox, a JIT, or a performance story is misrepresenting the source [Maintainer claim, High — both sentences are in the pinned README].

**Benchmark reproduction cost:** there are no benchmarks to reproduce. Stated as the Rulebook's required table — maintainer-produced numbers: **none** (none claimed, none in-tree); independent numbers: **none** (nothing to reproduce). The README disavows performance claims in writing, so the honest evidence base is the test suite (10 tests, read but not executed here); executing it requires Linux x86-64 with the x86-64-v3 feature baseline and the pinned `nightly-2026-08-18` toolchain [Code-verified, High on requirements; Not executed].

## 4.6 Competitors

The lane is *sandboxed native-code execution for a from-scratch engine's JIT path*. Nobody buys this standalone; the "competitors" are the mechanisms real engines use. Why the incumbents win today, in one paragraph: **V8's sandbox wins by deployment** — a software-enforced in-process sandbox for JIT code shipping in every Chrome install, maintained by a dedicated team and battle-tested by real exploit pressure. Wasmtime wins the "don't run native code at all" adjacent lane with Wasm's validation story and a real ecosystem. The eBPF verifier wins the philosophical lane — it is the deployed proof that "admit only what you can prove" scales to millions of machines. Against all three, the capsule's honest position is: a finer-grained, better-instrumented admission story for exactly one 39-byte program, with no deployment, no attackers, and no second reviewer. The mechanism is not worse; it is unproven at every scale the incumbents have survived.

- **V8's sandbox:** the production reference for "run JIT'd code inside a process without letting it touch the process." V8's sandbox (software-enforced, in-process) is deployed in every Chrome install; it owns the lane by deployment [External, High]. FrankenEngine is not V8 and cannot borrow it — which is the entire reason this repo exists — but the comparison sets the bar: a trust boundary nobody's engine uses is a design doc with tests.
- **WebAssembly runtimes (wasmtime, V8's own Wasm):** the industry's answer to "run untrusted native-speed code in-process" is to not run native code at all — run Wasm through a validated compiler. Wasmtime's sandboxing story (capability-based WASI, Cranelift-backed) is the adjacent lane's incumbent [External, High]. The capsule's RCO-seal design is philosophically adjacent (sealed compilation objects ≈ validated modules), but Wasm has the ecosystem.
- **Native Client (retired):** the cautionary tale — a validator-plus-sandbox for native code that died when the platform moved on. Its lesson for this repo: sandbox mechanisms live or die by their host platform's commitment [External, Medium].
- **eBPF verifiers (Linux kernel):** the closest *deployed* analogue of the capsule's validator philosophy — a small, auditable verifier that admits only provably-safe programs, with the kernel refusing everything else. The eBPF verifier is the existence proof that "admit only what you can prove" scales [External, High]. The capsule's exact-match gate is eBPF-verifier philosophy taken to its degenerate limit: instead of proving properties of arbitrary code, admit exactly one audited blob.
- **Unoccupied lane:** a *separately owned*, hash-pinned, receipt-chained native-code capsule with an authority-free compiler worker, purpose-built as the trust boundary for a from-scratch JS engine — no direct occupant, because no other from-scratch engine program has published this decomposition [Inference, Medium]. Whether the lane is unoccupied or simply unneeded is the unproven bet: it is valuable if and only if FrankenEngine's JIT path actually routes through it.

## 4.7 Skeptic's take

Weaknesses, threat-classed (each is substantive — capable of killing the project on its own):

1. **[FATAL] No license text.** The workspace metadata declares `license = "MIT"`, but the tree contains no LICENSE file and GitHub's license detection reports none. The grant is a one-word assertion in `Cargo.toml`, not a document. For a trust-boundary component — whose entire value proposition is what other parties may rely on — the missing license is not paperwork; it is the difference between "adoptable" and "look but don't touch." No downstream license-intake process can clear it on metadata alone [Inference, Medium].
2. **[FATAL] Nothing consumes it.** The README's production dependency direction (`franken_node -> franken_engine -> franken_native_capsule`) is unverifiable from this repo, and the README itself says the capsule "is not enabled by FrankenEngine." A trust boundary with no trustor is a demo. If FrankenEngine's JIT path never routes through this crate, the repo's end state is a frozen monument to ADR-0010 [Inference, High].
3. **[HIGH] The security story depends on components that do not exist.** The durable nonce store, the issuer signature verifier, the worker supervisor, the process sandbox/supervisor, unwind/CFI registration — all named as missing, all load-bearing for any real threat model. The README is admirably honest about this ("the transient-memory field is not enforced without the missing external worker supervisor"), which raises credibility without changing the fact: the demonstrated artifact is the *least* security-critical slice (a fixed probe with no relocations, no rodata, one entrypoint), and everything that makes native code dangerous in production is someone else's future work [Inference, High].
4. **[MEDIUM] The platform story is one OS on one arch.** Linux x86-64-v3 only; the AGENTS.md unsafe-allowlist names `platform/*/{executable_memory,process_sandbox,process_supervisor,unwind_registration}` modules of which exactly one file exists. The "cross-platform native" framing from the run inventory is false for this repo (see §4.1), and even the repo's own forward-looking allowlist outruns its implementation [Code-verified, High].
5. **[MEDIUM] No verifiable development process.** One squashed commit, no CI, no releases, no contribution policy, no changelog. The `pushed_at` (2026-09-17) vs. HEAD (2026-08-20) anomaly — both branches pointing at the pin — is unexplained; the most likely cause (creating `master` at the same commit) is inference, not evidence. There is no process artifact a second party could audit [Inference, Medium].
6. **[MEDIUM] The validator's strength is also its ceiling.** The exact-match admission gate (`code == FIXED_PROBE_MACHINE_CODE_V1`) is the strongest possible refusal story and simultaneously a generality of zero: the mechanism cannot admit a second operation without becoming a different mechanism — every new operation needs a new audited constant and a code change, so the "allowlist" is an N=1 mechanism that does not scale to a real JIT workload. NRP/RCO v1 — the production schema the README says ADR-0010 requires — is "intentionally not claimed," which means the path from this demo to a real JIT boundary is not a roadmap, it is a rewrite of the validator [Inference, Medium].
7. **[MEDIUM] Stale repository metadata.** The workspace `repository` field points at `https://github.com/franken-suite/franken_native_capsule`, which 404s. A trust-boundary crate whose own package metadata points at a nonexistent home is a small thing that signals a large thing: nobody is doing release hygiene, because there are no releases [Code-verified, High].

**Bear-case steelman (strongest counter-case):** Franken Native Capsule is a 2,851-line demonstration that JITs a 39-byte sum function, refuses to run anything else, and is not used by the engine it was built for. Its security posture rests on a supervisor, a signature verifier, and a nonce store that do not exist; its license posture is a metadata string with no text; its platform posture is one OS and one microarchitecture; its development posture is a single squashed commit with no CI. The rational market response is to read it as what it says it is — "bring-up evidence only" — and never depend on it. Its most likely end state is abandonment at the next FrankenEngine milestone that routes around it, leaving a well-written, hash-pinned monument that proves 39 bytes can be executed safely. [Inference, Medium — deliberately uncharitable; the counter-evidence is the engineering quality of the slice that does exist.]

## 4.8 Maintenance & succession

**Bus factor: 1.** One human maintainer — Jeffrey Emanuel <jeff@jeffreyemanuel.com>, the commit author on the single squashed commit that is the entire history [Git-observed, High]. No succession plan, no second committer, no contribution policy, no foundation. If the maintainer stops, the project freezes at the pin — which, 33 days in, it already has [Inference, High].

**License — read verbatim (there is no text to quote):** the tree contains no LICENSE file [Verified, High]. The entire license posture of the repo is one line of workspace metadata: `license = "MIT"` in the root `Cargo.toml` [Code-verified, High]. GitHub's license detection reports `None` [External, High]. Classification: **declared-MIT, text-absent** — the SPDX identifier in package metadata is the grant statement, but there is no license text to delimit scope, and no downstream counsel can clear intake on metadata alone. The FrankenSuite's MIT+OpenAI/Anthropic rider — the named-party restriction barring OpenAI, Anthropic, affiliates, and their agents from use/benchmarking/analysis — **does not exist in this repo**: no rider text, no restricted-party language anywhere in the tree [Verified, High]. Strategic consequence: unlike its sibling FrankenRedis, this repo's license posture imposes no adoption ceiling on any party — the ceiling is the missing text itself, which is a fixable governance bug (next step 3), not a strategic exclusion. A concrete corollary for this program: this packet's own production — an agent-assisted assessment of the code — faced no license restriction, where the FrankenRedis packet had to confront the rider's "analyzing" bar in §4.8. The absence of a rider is not just a legal footnote; it determines whether the program's evaluation machinery may touch the repo at all [Inference, Medium].

**Succession consequence:** even a willing adopter inherits a repo whose governing spec (ADR-0010) lives at a local path outside the tree, whose release metadata points at a nonexistent org URL, and whose license grant is one metadata word. The fix list is small (LICENSE file, correct repository URL, CI) and the fact that it is unfixed 33 days in is the governance signal [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 3–4** | Component-level validation exists (the fixed-probe slice: Cranelift lowering, frozen-hash admission, W^X lifecycle, oracle-compared tests — all read, none executed here); the system it serves (NRP/RCO v1, engine integration) does not exist, and the README caps claims at "bring-up evidence only" [Inference, Medium] |
| Strategic relevance | 2/5 | The separately-owned-trust-boundary decomposition matters to the FrankenSuite's engine program, but this repo is a bring-up slice with no verified consumer — relevance is to the pattern, not the package [Inference, Medium] |
| Impact potential | 2/5 | If NRP/RCO v1 lands and FrankenEngine routes its JIT through the capsule, the impact is a real sandbox story for a from-scratch engine; today the impact is zero — the only admissible program computes a sum [Inference, Medium] |
| Implementation feasibility | 2/5 | The api crate is trivially adoptable (safe types, forbid(unsafe_code)); the mechanism is adoptable only inside FrankenEngine's ADR, on Linux x86-64-v3, without the missing supervisor/verifier/nonce-store [Inference, Medium] |
| Time to mainstream | 1/5 | No credible path without FrankenEngine adoption plus v1 plus the missing security controls — years if ever, dormant by default [Inference, Low] |
| Collaboration potential | 1/5 | Bus factor 1, single squashed commit, no contribution policy, no CI, ADR outside the repo; the license imposes no party exclusion, but there is no on-ramp [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven: the mechanism is real (2,851 lines of read-verified W^X and admission machinery, 13 counted unsafe blocks in two allowlisted modules, 10 tests) and unproven (no release artifact, no CI, no independent validation, no consumer, explicitly "not enabled by FrankenEngine"). This is **Explore-with-a-ceiling**: the ceiling is the missing production path (v1, supervisor, signature verifier, nonce store, engine adoption), recorded as advancement blockers and priced into feasibility (2), time-to-mainstream (1), and collaboration (1). It is not Monitor — it is not a website, a retired artifact (not archived; pushed 2026-09-17), or a plan-stage sketch: the code executes a real trust-boundary slice. No Rulebook amendment; v1.0 stands.

**Methodology fit (for the FrankenSuite):** adopt the patterns, not the package — the frozen-hash admission gate (byte-exact equality against an audited constant, with SHA-256 binding plan→compiler→receipt→image), the allowlisted-unsafe discipline (stable `NCC-SAFETY-*` invariant IDs with linked tests), and the bring-up disavowal convention (README sections that enumerate non-capabilities in writing) are directly importable into how the program builds and evaluates the other 43 repositories. Do not depend on the software: no license text, no releases, no CI, and no consumer disqualify it as a dependency.

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — the Cranelift compiler backend, libc `mmap`/`mprotect`, SHA-256.** Inherited infrastructure; commodity by definition. The workspace's exact-pinning (`=0.134.2` across 13 Cranelift crates) treats the compiler as a *pinned identity*, not a moving dependency — the audited-compiler-identity pattern. Moves right (toward commodity) only if Cranelift changes its x86-64-v3 codegen for the frozen probe (which the allowlist gate would catch as a refusal, not a silent drift) [Inference, Medium].
- **Custom-built, bring-up stage — the RCO seal + validator + receipt chain.** The trust-boundary mechanism itself: sealed compilation objects, structural validation, activation/retirement receipts. Custom-built on process rigor alone; not yet product (no v1, no consumer). Moves right with an NRP/RCO v1 validator that admits non-frozen payloads plus a first consumer (FrankenEngine wiring); decommissions (becomes a monument) if FrankenEngine's JIT path routes around it [Inference, Medium].
- **Custom-built, closest to reusable — the guard-paged W^X executable-memory lifecycle.** `PROT_NONE -> RW -> RX` with guard pages, retirement zeroing, `/proc/self/maps` test verification. The most *exercised* concept in the tree (the executable-memory unit test plus the feature-gated runtime tests that activate and retire — the api/worker/validator suites never touch mapped memory). Moves right if extracted as a standalone `executable-memory` crate other projects can adopt; stays repo-local while there is no release [Inference, Medium].
- **Genesis — "separately owned native-code mechanism" as a governance pattern.** No from-scratch engine program has published this decomposition: the authority-free compiler worker (emits sealed RCOs, never maps or executes) separated by repo boundary from the runtime that maps them. Moves right if FrankenEngine enables it and the pattern gets a second adopter; stagnates as a single-maintainer design sketch if the engine never wires it [Inference, Medium].

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

1. **No NRP/RCO v1** — "intentionally not claimed"; the production schema ADR-0010 requires does not exist [Maintainer claim, High].
2. **No issuer signature verifier** — receipts are hash-chained but unsigned [Code-verified, High].
3. **No durable nonce store** — the in-process `ActivationNonceRegistry` is explicitly not the control plane; replay protection across processes does not exist [Maintainer claim, High].
4. **No worker supervisor** — elapsed/output limits are post-operation admission checks; transient-memory budgets unenforced [Maintainer claim, High].
5. **No process sandbox/supervisor, unwind/CFI registration** — named as absent in the README; the AGENTS.md allowlist anticipates modules that don't exist [Code-verified, High].
6. **Single platform** — Linux x86-64-v3 only; no Windows/macOS/ARM story [Code-verified, High].
7. **No license text; wrong repository URL in metadata** — governance gaps, both fixable [Code-verified, High].
8. **The Sep-17 push that moved nothing** — unexplained; the decay sensor (trigger 8) starts here [Inference, Medium].

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

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

**12-month base case [Inference, Medium]:** the repo stays as-is or accrues small v1-adjacent commits; the fixed probe remains the only admissible program; FrankenEngine does not wire it in; no LICENSE, no CI, no release. The pattern (frozen-hash admission, allowlisted unsafe, bring-up disavowals) gets mined by sibling repos; the software gets no consumer. Ring: Explore, unchanged.

**24-month base case [Inference, Low]:** one of two shapes. Either FrankenEngine's JIT milestone forces the issue — NRP/RCO v1 validator, signature verifier, durable nonce store, and supervisor land, and the packet's checklist (deepening question 8) starts scoring above zero — or the tree is a frozen monument and the engine routes around it. The base case leans toward the monument on 33-days-no-commit priors and the README's own "not enabled" framing.

**60-month base case [Inference, Low]:** the software is either the trust boundary of a shipped FrankenEngine JIT (the upside, requiring everything in the bifurcation) or a dormant, well-written artifact. The methodology-export (frozen-hash admission, receipt chaining, the disavowal convention) is the durable survivor either way.

**Bifurcation — what the upside requires:** all five, in rough order: (a) NRP/RCO v1 implemented — the validator admits non-frozen payloads under the same receipt discipline; (b) the issuer signature verifier and durable nonce store land (triggers 2, 3); (c) the worker supervisor lands with enforced budgets; (d) FrankenEngine actually depends on the crate (its `Cargo.toml` references it); (e) a LICENSE file and CI (triggers 1, 6). Without (d) nothing else matters for adoption; (d) is the *necessary* condition, not merely one item on a list.

**Bifurcation — what decay looks like:** no commits for 60+ days (the sensor is trigger 8), the repo archived or left at the pin, FrankenEngine's JIT work happening elsewhere. Decay is the default outcome for bus-factor-1 bring-up infrastructure without a consumer — the base case, not the tail.

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

1. **A LICENSE file appears at root** — the license-API field flips from `None` to a detected license. Flips the "no grant text" judgment.
2. **NRP/RCO v1 lands** — the validator admits a non-frozen payload class, or the api crate's schema versions advance past v0. Flips the "generality of zero" judgment.
3. **Issuer signature verifier and/or durable nonce store land** — the README's missing-controls list shrinks. Flips the security-posture judgment.
4. **FrankenEngine depends on it** — `franken_engine`'s manifests reference `frankenengine-native-capsule`. Flips the "no trustor" judgment.
5. **CI appears** — a `.github/workflows` directory with executing workflows. Flips the "no verifiable process" judgment.
6. **Second human committer** — bus factor > 1 on the contributor graph. Flips succession risk.
7. **A second platform adapter lands** (Windows/macOS/ARM) — the platform story moves past one OS/arch.
8. **Abandonment tripwire** — no commits for 60 days (last commit 2026-08-20; last push 2026-09-17 moved no branch): re-ring to Monitor and treat the tree as a retired artifact.

## 4.12 Verdict & NODUS ring

**NODUS ring: Explore.** The repo is the textbook substantive-but-unproven case at small scale: substantive (2,851 lines of real trust-boundary machinery — a genuine Cranelift lowering pipeline, a byte-exact admission gate, a guard-paged W^X lifecycle, 13 counted unsafe blocks confined to two allowlisted modules, 10 tests — all read-verified at the pin) and unproven (no release artifact, no CI, no independent validation, no consumer, and the README's own "bring-up evidence only / not enabled by FrankenEngine" disavowal). "When in doubt, ring down" does not apply — there is no doubt about the Explore floor; the doubt is about *evaluability of the production story*, which is not what the maturity scale measures. The missing production path (v1, supervisor, signature verifier, nonce store, engine adoption) is instrumented as the **advancement ceiling**: priced into the NODUS feasibility (2), time-to-mainstream (1), and collaboration (1) scores, and wired to revisit triggers 2–4. The ring reads: **Explore — substantive, unproven, and currently un-advanceable past Explore while the README's own disavowal stands** [Inference, Medium]. No Rulebook amendment; v1.0 stands.

**The one-paragraph case:** Franken Native Capsule is a 2,851-line bet that the most dangerous part of a from-scratch JavaScript engine — executing machine code inside the process — can be separately owned, hash-pinned, and admitted one audited blob at a time — and on process grounds the slice that exists is exemplary: a real Cranelift lowering that must reproduce a frozen 39-byte constant byte-for-byte, a validator that re-checks every binding before admission, a W^X lifecycle with guard pages and retirement zeroing, and a README that disavows everything it has not built. But the product case is hollow at the pin: no license text, no CI, no releases, one squashed commit, nothing consumes it, the engine it was built for does not enable it, and every security control that would matter in production (supervisor, signature verifier, nonce store, sandbox) is a named absence. Explore the pattern — the frozen-hash admission gate, the receipt chaining, the disavowal convention; the software stays behind the ceiling until trigger 4 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:** the workspace was never compiled; no test was executed (so the `/proc/self/maps` W^X assertions and oracle comparisons are read, not run); no benchmark exists to reproduce; `franken_node` and `franken_engine` were not assessed (the dependency-direction claim is unverified); ADR-0010 was not read (it lives at a local `/dp/franken_engine/...` path outside this repo); the 2026-09-17 push event that moved no branch was not investigated via the Events API; `Cargo.lock` was spot-checked, not fully audited; the GitHub license field was read via API (reports `None`) but no legal review was performed. Quick-link resolution verified 2026-09-22 (all 200).

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

1. **Will FrankenEngine ever depend on it?** A single `Cargo.toml` reference in `franken_engine` would flip the "no trustor" judgment and the 24-month trajectory. This is the question the whole packet hinges on.
2. **Does the test suite pass?** Read, not run. A green `cargo test --features embedded-fixed-probe` on Linux x86-64-v3 would promote the W^X and oracle claims from code-verified to CI-observed; a red run would be a finding of the first order.
3. **What was the 2026-09-17 push?** It moved neither `main` nor `master`. If it was a force-push of identical content, nothing changes; if it touched refs that were then deleted, the history story is murkier than the single-commit surface suggests.
4. **Is there really no audio-player past?** The repo was born 2026-08-20 as a single squashed commit; a squash could conceal an earlier incarnation. The evidence against it (zero audio strings, capsule-shaped code from line 1, the commit message "docs(capsule)") is strong but the squash means it is not conclusive.
5. **What does ADR-0010 actually require?** The packet takes the README's word for the v1 scope. Reading the ADR would settle whether the missing-controls list is complete.
6. **Who is the second pair of eyes?** No review process is observable. If one exists (e.g., in another repo's PRs), the governance picture improves materially.

---

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

*§5→location mapping: Provenance ← the receipt chain (built on claims 23–24, 28); Embeddable unit ← the api crate's `forbid(unsafe_code)` posture (claim 15); Unexercised option value ← the v0/v1 schema gap (claim 16) plus the transport-less wire types; Benchmark honesty ← §4.5 (no benchmarks exist); Governance path ← §4.8 plus §4.7 weaknesses 2 and 5; License as strategy ← §4.8 (no LICENSE, no rider — claims 4, §4.3); Agent-era fit ← new; Kill test ← §4.7's bear-case steelman plus trajectory trigger 4.*

**1. Provenance.** The repo's provenance machinery is the receipt chain: the worker's `CompilationReceiptV1` binds plan SHA-256, compiler-identity SHA-256, code SHA-256, and a transcript hash; `activate()` mints an `ActivationReceiptV1` binding activation id → authorization id → RCO SHA-256 → final mapped-image SHA-256; `retire()` closes the loop with a `RetirementReceiptV1` binding activation id → final image hash → reclaimed bytes [Code-verified, High]. The chain is content-addressed and canonical-encoded, so it is portable *as data* — anyone holding the receipts can re-verify every binding offline. What it is not: tamper-evident against a hostile holder (hashes without signatures — the issuer signature verifier is explicitly absent, claim 30), and it records *what* was built, never *who* built it — the receipt structs carry authorization ids, hashes, profiles, budgets, and epochs, but no author, no key, no build-host attestation (field-enumerated at the pin) [Code-verified, High]. A quiet honesty detail: `measured_compile_elapsed_ns` is marked "receipt-only and never part of the RCO seal" — the designers distinguished what the seal covers from what it merely reports [Code-verified, High]. Portable attestation would require the missing signature verifier plus a signer identity; until then the receipts are an audit trail for the honest, not evidence against the dishonest [Inference, Medium].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is `frankenengine-native-capsule-api`: 1,143 lines of pure safe types (`#![forbid(unsafe_code)]`, zero unsafe) — versioned wire negotiation, the NRP/RCO v0 schema, authorization and receipt types, canonical-encoding helpers — with no platform code and no Cranelift in its graph [Code-verified, High]. A downstream project could vendor it as the schema vocabulary for its own sealed-compilation-object design. Adoption cost: there is no registry artifact (no crates.io publish, no release at all), so it is a path or vendored dependency; it inherits the edition-2024 / `nightly-2026-08-18` toolchain assumptions; and the broader production schema (v1) is "intentionally not claimed," so the vocabulary may churn under any future v1 [Inference, Medium].

**3. Unexercised option value.** Three capabilities the architecture holds but has not used. First, the api crate already declares the full v1 vocabulary — relocations, entrypoints, resource budgets, execution profiles, policy/security epochs, wire negotiation — while the validator admits only the frozen v0 subset; the schema is years ahead of the mechanism, and flipping the validator to admit parameterized payloads is where v1 begins [Code-verified, High]. Second, the wire types (`ProtocolHello`, version negotiation) describe a protocol with no transport — an IPC worker was explicitly deferred, so the capsule cannot yet serve a compiler process across a boundary, which is the shape production use would take [Maintainer claim, High]. Third, Cranelift is pinned as an exact 13-crate graph but exercised only to reproduce one frozen blob; the same worker shape could lower arbitrary audited plans once the allowlist becomes a property-checker rather than a byte-comparison [Inference, Medium]. What unlocks each: a v1 admission policy, a transport, and a verifier that proves properties instead of matching constants [Inference, Medium].

**4. Benchmark honesty.** There are no benchmarks to audit — none are claimed, none exist, and the README disavows performance claims in writing ("establishes no … performance claim") [Maintainer claim, High]. That absence is itself the honesty finding: in a program where sibling repos ship disavowed benchmark tables, this repo's refusal to publish numbers it cannot defend is the correct posture. Which numbers *would* be load-bearing for the thesis? Not throughput — the thesis is admission soundness, and its load-bearing evidence is the refusal behavior: every mutated/non-frozen RCO refused, every replayed nonce rejected, every retired mapping provably unmapped. Those are currently test-asserted (read, not executed here); the mutation-harness proposal in next step 2 is what would turn them from assertions into a standing experiment [Inference, Medium].

**5. The governance path.** The credible route from one maintainer to an institution runs through: a LICENSE file (trigger 1), CI (trigger 5), the repository-URL fix, a second human committer (trigger 6), and — the load-bearing one — FrankenEngine actually depending on the crate (trigger 4), which would convert the repo from a personal sketch into program infrastructure with a consumer-driven review bar [Inference, Medium]. The starting position: single squashed commit, no contribution policy, no review process observable, the governing ADR at a local path outside the repo. What breaks first if velocity decays: nothing breaks — that is the problem. With no consumer, no CI, and no release cadence, decay is silent; the 33-days-no-commit HEAD is already the decayed state, and the 60-day tripwire (trigger 8) exists precisely because no louder sensor is available [Inference, Medium].

**6. The license as strategy.** There is no rider to analyze — the brief's premise is disproven for this repo (§4.3 claim 4): no LICENSE file, no OpenAI/Anthropic language, no restricted-party terms anywhere; the entire posture is `license = "MIT"` in workspace metadata, which GitHub does not detect as a license [Verified, High]. Who is excluded? Nobody — which, against the FrankenSuite's rider-bearing siblings, makes this the most adoptable repo in the program on paper and the least adoptable in practice (nothing to adopt: no release, no registry artifact). Does the absence serve or sabotage the stated mission? It sabotages it quietly: a trust-boundary component whose grant is one metadata word cannot clear any downstream license intake, so the missing LICENSE file is a harder adoption blocker than a permissive-but-present license would be — and unlike a strategic rider, it buys nothing in return [Inference, Medium].

**7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is the *sandboxed tool-execution* workload: an agent runtime that JITs or loads native tool code and needs a trust boundary with sealed, hash-pinned admission and receipt-chained provenance — the capsule's RCO seal → validator → W^X map → retire lifecycle is already the shape of "run this untrusted blob exactly once, then prove the pages are gone" [Inference, Medium]. What would have to become true first: NRP/RCO v1 (admitting more than one frozen program), the issuer signature verifier (so the agent host can delegate trust), the worker supervisor (so budgets are enforced, not post-checked), and a transport (so the compiler worker can live in another process) — i.e., everything on the README's missing list, which is honest about the distance. The fit is real but presently blocked by the repo's own scope: today it can only ever execute 39 bytes of addition [Inference, Medium].

**8. The kill test.** The single experiment that would falsify the core thesis — that the capsule admits *only* the audited frozen probe — is the mutation harness from next step 2: present `validate_fixed_probe` with RCOs that are one byte off, one entrypoint renamed, one receipt field forged, one nonce replayed, and require total refusal. A single admission of a non-frozen payload kills the thesis by the project's own mechanism, not by a critic's argument [Inference, Medium]. Two secondary falsifiers sit behind it: FrankenEngine shipping a JIT path that does *not* route through this crate (trajectory trigger 4 permanently unmet — the "no trustor" end state), and the abandonment tripwire (trigger 8: 60 days without commits re-rings to Monitor). The production checklist is the inverse of this test — what success requires, scored at the pin as 0 of 5 met: NRP/RCO v1 validator, signature verifier + durable nonce store, worker supervisor, FrankenEngine dependency, LICENSE + CI. The score is 0 of 5, and the README agrees [Inference, Medium].