# FrankenNode — RULEBOOK v1.0 Assessment Packet v3

**Repository:** `Dicklesworthstone/franken_node` · **Language:** Rust (edition 2024) [Code-verified, High] · **Pinned commit:** `08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4` (2026-09-22 01:23:51 -0400 / 05:23:51 UTC, [Git-observed, High]) · **Last push:** 2026-09-22T05:24:37Z, matching the pin window [External, High] · **Scope:** the pinned commit only, not HEAD. One tag, `v0.1.0`, points at an earlier commit `08e1edf11` (2026-05-29) — nothing tags the assessed commit; GitHub Release `v0.1.0` (published 2026-05-29, not draft/prerelease, 6 binary assets: macOS aarch64, Windows x86_64, Linux x86_64 tarballs/zips + `.sha256` files) targets that earlier tag commit — no release artifact for the assessed commit [External, High]. *Cold-reader note: "v1"/"v2" = earlier drafts of this packet from the rewrite loop; this document is v3, the final.*

**Method (analyst):** shallow clone checked out at the pin under `/tmp/fn_verify/fn` (25,065 files, verified non-empty); the working tree stayed at the pin. Read: root `Cargo.toml`, all workspace member manifests, `Cargo.lock`, `LICENSE` (verbatim), README.md (3,401 lines — honesty manifest, limitations, engine-split, performance, close-condition oracle sections), `docs/honesty_manifest.json` + `docs/honesty_manifest_evidence.json`, `docs/ENGINE_SPLIT_CONTRACT.md`, `CHANGELOG.md`, `.beads/issues.jsonl` (line count only), `dist.yml`, 4 CI workflow files, `docs/specs/section_10_15/bd-1xwz_contract.md`, `sdk/verifier/tests/{DISCREPANCIES,COVERAGE}.md`, module headers for replay/migration/vef/connector. Counted: `.rs` files/lines (src-only and src+tests), unsafe sites (comment/string-excluding scan), `#[test]` attributes, fuzz target files, `check_*.py` validators, asupersync feature-gate blocks. Ran: the repo's own `scripts/check_claims_manifest.py --check-honesty` against the live tree (9 ok, 0 drift). Queried: GitHub REST API for repo metadata, releases, tags, workflow runs (including per-run conclusions and runs filtered to the pin's head SHA), and the last 100 commits' authorship. Searched: web demand signal for independent coverage of the project. **Not done:** the workspace was never compiled (default features require the sibling `franken_engine` checkout, which was not performed), no binary was built, no test suite was executed, no benchmark was reproduced, the Ed25519 honesty-manifest signature was not cryptographically re-verified locally (no `cryptography` library in this environment; verification is enforced by the SDK conformance test in CI), CI job logs were not readable (GitHub logs API requires authentication), and full git history was not pulled (authorship analysis covers the last 100 commits via API only). 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 (absence of coverage reported with recall caveats); **[Inference]** analyst judgment, always labeled. Confidence: **High** (multiple converging sources or direct inspection) / **Medium** (single solid source, plausible) / **Low** (thin evidence, extrapolation).

---

## Hook

A 944,364-line [Counted, High], single-maintainer, zero-`unsafe` [Counted, High] Rust platform that wraps JavaScript/TypeScript execution in a trust apparatus — per-extension trust cards, revocation-freshness gates, signed decision receipts, deterministic incident replay — and then does something almost no project its size does: it ships a machine-checkable Honesty Manifest (Ed25519-signed census of its own headline claims, re-verifiable by an independent SDK, with a CI gate that fails on drift) [Code-verified, High], and its own close-condition oracle currently reads RED — the project's ship gate blocks itself at 69.82% Node compatibility against its own 95% floor [Code-verified, High]. The catch is threefold: the actual JS engine lives in a sibling repository this one cannot build without [Code-verified, High], the "deterministic incident replay" is a replay of a *recording*, not a re-execution [Maintainer claim, High], and the license names OpenAI and Anthropic as forbidden parties [Code-verified (license text), High]. It is the most self-scrutinizing pre-1.0 codebase assessed in this program to date [Inference, Medium — the in-packet evidence base is the signed honesty manifest re-verified live with 0 drift, the dual-oracle close condition, mutation-adequacy floors, and the README's volunteered RED verdicts; "most" is a comparative judgment over the packets completed so far, not a measured ranking] — and its own instruments say it is not ready.

---

## TL;DR

- **What it is:** A product-layer trust platform for JS/TS extension-heavy systems (944,364 first-party Rust lines / 491 files in the src tree at the pin [Counted, High]; 1,199,879 lines / 1,073 files including tests), built as three Cargo workspace members (`frankenengine-node`, `franken-security-macros`, `frankenengine-verifier-sdk`) on top of a sibling repository, `franken_engine`, that owns the actual runtime internals (VM, parser, interpreter) [Code-verified, High]. Pre-1.0, one human maintainer, ~20 commits/day in the sampled window [External, High].
- **Strongest evidence:** the honesty machinery actually runs: I executed `scripts/check_claims_manifest.py --check-honesty` against the pinned tree — 9 checks ok, 0 drifted, with live recounts (3,756 → 4,106 integration tests; 21,621 → 22,421 inline; 146/146 fuzz targets; 437 → 438 validators; 0 unsafe blocks) inside the manifest's tolerance bands [Verified, High]; zero real `unsafe` sites under `#![forbid(unsafe_code)]` in all three workspace members (independent comment/string-excluding scan: 4 candidates, all string literals) [Counted, High]; a 22-row threat model with explicit out-of-scope non-goals and per-threat regression anchors [Code-verified, High]; and a close-condition oracle with conjunctive L1/L2/release-policy gates that currently reads RED on its own corpus numbers [Maintainer claim, High].
- **Strongest doubts:** CI is red at the pin — all 8 push-triggered runs observed against the pin's head SHA concluded failure (README CLI drift, quick-example smoke, connector conformance, native migration validation, native product oracle), and the broader recent window is predominantly red [CI-observed, High]; the L1 product oracle sits at 69.82% (391/560) against the charter's ≥95% ship floor, and the README's own FAQ answers "Is this a drop-in replacement for Node or Bun?" with "No" [Code-verified, High]; the asupersync transport integration is real feature-gated code but no CI workflow has ever compiled the `asupersync-transport` feature [Code-verified, High]; default builds require the sibling `franken_engine` checkout, so a bare clone does not compile [Code-verified, High]; the license rider bars OpenAI/Anthropic and anyone acting for them from use including benchmarking, testing, and analyzing [Code-verified (license text), High]; bus factor 1 [External, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 4 — see §4.9). Substantive-but-unproven is the textbook Explore case; the rider is an advancement blocker (Explore-with-a-ceiling), not a ring qualifier. The honesty and evidence-governance machinery is the methodology exemplar worth tracking; the runtime itself is pre-ship by its own oracle's verdict.

---

## Quick Links

Pin-relative links (`blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4`); all verified resolving (HTTP 200) 2026-09-22 [Verified, High]:

1. [Repository](https://github.com/Dicklesworthstone/franken_node) — 30 stars, 3 forks (GitHub API, 2026-09-22)
2. [README](https://github.com/Dicklesworthstone/franken_node/blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4/README.md) — 3,401 lines
3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/franken_node/blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4/LICENSE)
4. [Honesty manifest (signed claim census)](https://github.com/Dicklesworthstone/franken_node/blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4/docs/honesty_manifest.json) — 7 claims, Ed25519-signed
5. [Engine-split contract](https://github.com/Dicklesworthstone/franken_node/blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4/docs/ENGINE_SPLIT_CONTRACT.md) — the franken_node/franken_engine boundary
6. [Compatibility corpus results](https://github.com/Dicklesworthstone/franken_node/blob/08447a0aa5ed016d5ff9abb5aa0d44e9f5061dc4/artifacts/13/compatibility_corpus_results.json) — 391/560, L1 oracle RED
7. [README CLI drift gate](https://github.com/Dicklesworthstone/franken_node/actions/workflows/readme-cli-drift-gate.yml) — red at the pin
8. [Compatibility corpus pass gate](https://github.com/Dicklesworthstone/franken_node/actions/workflows/compat-corpus-pass-gate.yml) — 81 runs observed
9. [Asupersync integration gate](https://github.com/Dicklesworthstone/franken_node/actions/workflows/asupersync-integration-gate.yml)
10. [Release pipeline (dist)](https://github.com/Dicklesworthstone/franken_node/actions/workflows/dist.yml) — pinned engine revision, cosign keyless signatures
11. [Releases](https://github.com/Dicklesworthstone/franken_node/releases) — v0.1.0 (2026-05-29), targets earlier commit, not the pin

---

## Did You Know

The honesty manifest's whole purpose is binding claims to evidence — yet its `generated_at` field reads `1970-01-01T00:00:00Z`, Unix epoch zero. The Ed25519 signature, the per-claim `evidence_digest` chain, and the `corpus_digest` are all structurally present, and the live `--check-honesty` run passes with 0 drift [Verified, High] — but the manifest cannot date its own attestation, so a verifier cannot distinguish a fresh attestation from a stale-but-still-valid one. The irony is architectural: this is the project whose runtime gates fail closed on stale revocation state ("revocation freshness gates fail closed when trust state is stale"), and whose README warns that raw counts are Goodhart-bait — and its own honesty artifact fails the project's own freshness philosophy. The cryptography is real; the timestamp is a placeholder. [Code-verified, High on the field value; the characterization is Inference, Medium.]

---

## Franken-worthy next steps

1. **Red-team the honesty census.** The manifest claims fail-closed drift detection with per-claim tolerances — but no one has adversarially tested it. Deliberately perturb the tree (add a test file, register a fuzz target, flip a census count) and confirm the `--check-honesty` gate fires; then try to evade it (a change that moves a headline number without tripping the census). *Falsifiable:* if an evasion succeeds, the "claims require re-verifiable evidence" pillar is weaker than advertised. *Done when:* a red-team report records attempted evasions and the gate's verdict on each. [Inference, High — research proposal]
2. **Compile the asupersync feature as a natural experiment in claimed-vs-exercised code.** Section 10.15's contracts are marked "Delivered" and `bd-1xwz` sets p95/p99 overhead budgets for asupersync integration on control-plane hot paths — yet no CI job has ever built `--features asupersync-transport`. Build it, run `asupersync_control_lane_integration`, and measure the budgets against reality. *Falsifiable:* if the feature doesn't compile, "Delivered" means "merged," not "exercised" — a finding about the whole spec-tracker vocabulary. *Done when:* a CI job builds the feature and the budget gate passes or fails on real numbers. [Inference, High]
3. **Apply the close-condition oracle retroactively to this repo's own merge history.** The L1/L2/release-policy conjunctive gate with its consistency-vs-ship mode distinction is a formalized merge-vs-ship separation — but it has never been tested against reality. Run the gates against the last 50 merges: which would the oracle have blocked, and which of those did the maintainer consider good? *Falsifiable:* if the oracle would have blocked merges the maintainer defends (or passed merges later reverted), the gate is miscalibrated — governance theater. *Done when:* a retroactive verdict table (merge × oracle verdict × maintainer's retrospective judgment) exists. [Inference, Medium]
4. **Bind the decision-receipt ledger to content hashes.** The ledger's signed, chained receipts cite evidence by reference; the runtime already does CAS read-time hash verification with chain-link recomputation for effect receipts (threat-model row, [Maintainer claim, Medium]). Extend that discipline to the ledger: every receipt's evidence refs become content hashes verified at read. *Falsifiable:* implement ledger v2 on one receipt class; if verification cost exceeds the hot-path budget contracts, the design is wrong for the hot path and belongs on the cold audit path. *Done when:* a design note scopes hash-chained, content-bound receipts with measured verification cost. [Inference, Medium]
5. **Catalog the deliberately-unsigned artifacts as a signing-economy study.** Rollback plans (`--emit-rollback`), `bench run` reports (SHA256 `provenance_hash`, explicitly not Ed25519-signed), and safe-mode state are unsigned by documented design decision — the README says *why* each time. Extract the rationale pattern: where does this project judge signatures not worth their cost? *Falsifiable:* apply the extracted criteria to three currently-signed artifacts; if the criteria would unsigned any of them, the signing policy is inconsistent. *Done when:* the signing-economy note exists and has been applied as a consistency check. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** Node and Bun made extension-heavy JS/TS development frictionless, but the security and operations layer never caught up: supply-chain scanners that flag after the fact, revocation checks that run after the risky action ships, incident reviews that cannot reproduce the original execution, permission models that gate file access but not extension behavior, and migration spreadsheets between runtimes [Maintainer claim, Medium — the README's TL;DR problem statement]. The maintainer's product charter (ratified v1.1, 2026-02-20) states the three-pillar bet: compatibility is table stakes (≥95% on a targeted corpus), trust-native operations are the differentiator (impossible-by-default capabilities incumbents cannot provide), and migration velocity is the growth engine (≥3x migration throughput/confidence vs baseline patterns) [Maintainer claim, Medium].

**Who feels the pain:** teams running extension-heavy JS/TS systems — build pipelines, plugin ecosystems, MCP-style agent tooling — where a compromised transitive dependency is a production incident, not a lint warning. The README's concrete scenario is a typosquat-plus-gradual-creep supply-chain attack with a 48-hour-delayed payload [Maintainer claim, Medium].

**Why now:** the extension/agent-tooling explosion (MCP servers, agent plugins) multiplied the attack surface of "install and run third-party JS" faster than runtime security models evolved; Deno proved a permission-gated runtime has a market, but no incumbent ships revocation-first execution, per-extension trust cards, or replayable incident forensics as a runtime contract [Inference, Medium]. This is not only the analyst's market read — it is the maintainer's own threat model: the 22-row model includes an "MCP mutation abuse" row (audience-bound capability chains, attenuated delegation, signed action receipts) with a regression anchor, meaning the project is already designing against the agent-operator threat. The "why now" is therefore grounded in-repo: the threat the timing argument invokes is one the project formally tracks [Code-verified, High on the threat-model row; the timing inference remains Inference, Medium].

**Demand-side check (2026-09-22):** a web search for independent coverage of franken_node (production users, third-party reviews, downstream adoption) returned nothing beyond the repository itself, one fork (`joyshmitz/franken_node`), and the maintainer's personal-site commit referencing it [External, High within recall caveats]. The installer and the v0.1.0 release exist, but there is no observable demand signal. Whether the "trust-native runtime" is a real category or a maintainer narrative is unproven — and the project's own close-condition oracle currently answers "not shippable" (L1 RED at 69.82% vs the 95% floor) [Code-verified, High].

**Why a product layer, not a runtime fork:** the engine-split is the architectural answer — JS/TS runtime internals (VM, parser, AST, interpreter, GC) live in the sibling `franken_engine`; franken_node owns compatibility capture, migration UX, the extension registry, and policy surfaces. The stated rationale: a third party can verify product-layer claims without auditing engine internals and vice versa [Maintainer claim, Medium].

## 4.2 What it is — repo TL;DR

A three-member Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]): `crates/franken-node` (package name `frankenengine-node` — note the repo/crate name mismatch), `crates/franken-security-macros`, and `sdk/verifier` (package `frankenengine-verifier-sdk`). The src tree holds 491 `.rs` files / 944,364 lines [Counted, High]; with tests, 1,073 files / 1,199,879 lines. Forty-plus modules under `crates/franken-node/src/` — the largest are `connector/` (141,026 lines, 78 files: the distributed trust fabric — lifecycle state machines, fencing, leases, CRDTs, quarantine, ecosystem registry), `security/` (109,317 lines: trust cards, threshold signatures, revocation, isolation backends), and `ops/` (82,225 lines: doctor, workspace pressure, compat corpus runs). The product: a policy-governed JS/TS runtime platform with a CLI (`franken-node`), where risky actions consult fresh trust state before executing, every decision emits a signed receipt chained into an evidence ledger, and high-severity incidents export as signed bundles replayable for forensics and policy counterfactuals. Development velocity is high: the last 100 commits span 2026-09-17 → 2026-09-22 (~20/day), 99 by Dicklesworthstone and 1 by github-actions[bot] [External, High]. The CHANGELOG's current window (2026-05-17 → 2026-08-19) records 1,303 non-merge commits [Maintainer claim, Medium]. The velocity number cuts both ways: ~20 commits/day from a single human means most commits cannot have received meaningful independent review — the bus factor and the review depth are the same fact viewed twice. And the CHANGELOG's documented window ends five weeks before the pin while commits continued at full pace: the project's narrative documentation is already lagging its own velocity, which is what the honesty census (machine-checked) is implicitly compensating for [Inference, Medium].

One-line verdict: **the most elaborately self-scrutinizing pre-1.0 codebase assessed in this program — signed honesty manifests, drift gates, a conjunctive close-condition oracle, mutation-adequacy floors — whose own instruments currently report that it is not shippable, 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. **Status** is the Rulebook's required audit verdict per claim.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | Zero `unsafe` code: `#![forbid(unsafe_code)]` in all three workspace member roots | demonstrated | Independent scan of all 491 src `.rs` files for `unsafe` constructs excluding comments/strings: 4 candidates, all string literals (`"incident id is unsafe: {reason}"` etc.); the project's own census recomputes 0 live | [Counted, High] |
| 2 | ~3,800 integration tests run by default `cargo test -p frankenengine-node` | demonstrated | `scripts/check_claims_manifest.py --check-honesty` executed live at the pin: census 3,756, live 4,106 — within the 3,000 bp tolerance band; 9 ok, 0 drifted. (My independent attribute grep gave 4,176 across wider dirs/forms — method difference, same order) | [Verified, High] |
| 3 | ~21,000 inline unit tests, compiled out of default `cargo test`, run on a dedicated inline lane | demonstrated | Live census 21,621, live recount 22,421 (my independent grep matched 22,421 exactly); the crate-level `#![cfg(any(not(test), franken_node_inline_tests))]` gate verified present in the README's description; `inline-lib-tests-gate.yml` exists with preflight + manual full-lane dispatch | [Verified + Code-verified, High] |
| 4 | 146 registered cargo-fuzz harnesses | demonstrated | `ls fuzz/fuzz_targets/ \| wc -l` = 146; census and live both 146 | [Counted, High] |
| 5 | ~437 validator scripts (`scripts/check_*.py`) | demonstrated | `ls scripts/check_*.py \| wc -l` = 438; census 437 — one-script delta, within tolerance; `--check-honesty` reports ok | [Counted, High] |
| 6 | Honesty manifest: 7 headline claims, per-source census, Ed25519-signed corpus digest, CI drift gate | demonstrated (signature cryptographically unverified locally) | `docs/honesty_manifest.json` + `docs/honesty_manifest_evidence.json` read at the pin; signature present (`signature` key); `--check-honesty` run live: 9 ok, 0 drift. Local Ed25519 verification skipped (no `cryptography` lib in this environment); the SDK conformance test `sdk/verifier/tests/honesty_manifest_recompute.rs` enforces it in CI [Maintainer claim, Medium on the in-CI enforcement] | [Code-verified, High on structure and live check; Medium on signature validity] |
| 7 | Compatibility corpus 69.82% (391/560) vs Node as spec; L1 oracle RED below the 95% floor | demonstrated | `artifacts/13/compatibility_corpus_results.json` recomputed: passed 189+46+156 = 391 of total 254+56+250 = 560 = 69.82%; README states L1 currently RED and "do not read a GREEN L1 from backfill artifacts" | [Counted + Maintainer claim, High] |
| 8 | Not a drop-in replacement for Node or Bun | demonstrated | README FAQ: "Is this a drop-in replacement for Node or Bun? No."; `child_process` native-eval aborts remain fail, not pass | [Maintainer claim, High] |
| 9 | `franken-node run` executes through the in-process franken-engine; the full host-effect "runtime-of-record" is still in active development | demonstrated | README Limitations, verbatim in substance: "do not yet rely on it as a complete drop-in for arbitrary host-effect workloads" | [Maintainer claim, High] |
| 10 | Incident replay is an integrity-verified replay of the *recorded* incident, not live re-execution | demonstrated | README Limitations: "deterministically re-derives the recorded decision sequence from the bundle and verifies it against the bundle's signed hash, failing closed on any mismatch. Live re-execution under the engine is part of the runtime-of-record work" | [Maintainer claim, High] |
| 11 | Migration autopilot: audit → rewrite → validate → rollout with deterministic stage artifacts; `migrate validate` is static+smoke (not lockstep); rollback plans are unsigned JSON | demonstrated (pipeline existence); behavior not executed | `crates/franken-node/src/migration/` (24,634 lines, 25 files: rewrite_transaction, verified_rewrite, rewrite_rollback, product_oracle, smoke_supervisor); README Migration Pipeline Stages documents all four stages and the unsigned-JSON rollback caveat | [Code-verified, High on existence; Maintainer claim, Medium on behavior] |
| 12 | Engine-split contract: runtime internals live in sibling `franken_engine`; duplicate-implementation CI gate; source builds require the sibling checkout | demonstrated | `docs/ENGINE_SPLIT_CONTRACT.md` read; `crates/franken-node/Cargo.toml` has `frankenengine-engine = { path = "../../../franken_engine/crates/franken-engine", optional = true }` wired into the `engine` feature, which is in `default = ["engine", "http-client", "external-commands"]`; CI workflows check out the sibling at the matching relative path; README Limitations: "Source builds require the sibling `franken_engine` repository to be checked out next to this one" | [Code-verified, High] |
| 13 | asupersync is an adopted, feature-gated fleet transport (not evaluated-and-rejected) | partially demonstrated | `asupersync = { version = "=0.5.0", optional = true }` behind `asupersync-transport = ["dep:asupersync"]`; real usage: `asupersync::Cx` in `AsupersyncFleetTransport` (`crates/franken-node/src/control_plane/fleet_transport.rs`, 4,675 lines, 9 feature-gated blocks); spec contracts in `docs/specs/section_10_15/` marked "Delivered"; integration test `asupersync_control_lane_integration.rs` requires the feature. **But:** no CI workflow compiles `--features asupersync-transport`, and the `asupersync-integration-gate.yml` validates a *sample* fixture plus a checked-in report — the feature build itself is unverified in CI | [Code-verified, High on existence; the CI gap is Code-verified, High] |
| 14 | Single-node fleet file-transport by default; multi-node coordination needs asupersync or an external transport | demonstrated | README Limitations: "Fleet CLI is file-transport by default (`live_control_plane=false`)"; "multi-node coordination requires the asupersync transport or a configured external transport" | [Maintainer claim, High] |
| 15 | v0.1.0 is the only GitHub Release (2026-05-29, 6 binary assets) and targets commit `08e1edf11`, not the pin | demonstrated | GitHub Releases API: 1 release, `v0.1.0`, 6 assets; tag `v0.1.0` → `08e1edf11f262693202d6466ba2392de9f3f3e4b`; pin = `08447a0a…`. No release artifact for the assessed commit | [External, High] |
| 16 | CI red at the pin: 8/8 push runs against the pin's head SHA failed | demonstrated (per-run conclusions; per-step causes unestablished) | GitHub Actions API filtered to `head_sha=08447a0a…`: 8 runs, 8 `failure` (README CLI Drift ×2, Quick Example Smoke ×2, connector-conformance ×2, Native migration validation, Native product oracle). Job-log download requires auth (403), so failure causes are unestablished, not assumed | [CI-observed, High] |
| 17 | Bus factor 1; ~20 commits/day; minimal agent co-authorship in the recent window | demonstrated (last-100-commit window) | GitHub API: last 100 commits span 2026-09-17 → 2026-09-22; 99 authored by Dicklesworthstone, 1 by github-actions[bot]; 1 commit message carries a Co-Authored-By trailer — a sharp contrast with the sibling frankenredis packet's 36% agent co-authorship, measured over a different window and method | [External, High on counts; Medium on the contrast] |
| 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 (see §4.8 for the quoted scope) | [Code-verified (license text), High] |
| 19 | Honesty manifest `generated_at` is `1970-01-01T00:00:00Z` (epoch zero) | demonstrated | `docs/honesty_manifest.json` read at the pin: `"generated_at": "1970-01-01T00:00:00Z"` — the manifest cannot date its own attestation | [Code-verified, High] |
| 20 | Threat model: 22 threat classes mapped to defenses with regression anchors, plus explicit out-of-scope non-goals | demonstrated | README Threat Model table read at the pin (22 rows + 4 out-of-scope bullets: network DoS, MAC, hardware attestation, app-source provenance) | [Code-verified, High] |

**What the inventory says in aggregate:** claims about *process and honesty machinery* (fuzzing, census, drift gates, threat model, limitations) verify at High confidence — this is the rare project whose README volunteers its own RED verdicts. Claims about *outcomes* (compatibility, migration throughput ≥3x per the charter, production readiness) are either explicitly disclaimed by the maintainer or untestable: the charter's ≥95% corpus floor and ≥3x migration velocity have no supporting evidence at the pin (corpus at 69.82%; no migration-throughput numbers found in the assessed materials) [Inference, Medium]. Claim 13 (asupersync) is the inventory's sharpest split: adopted in code, unverified in CI.

## 4.4 Codebase tour

**Workspace topology (3 members, [Counted, High]):** `crates/franken-node` (the platform; package name `frankenengine-node`), `crates/franken-security-macros` (proc macros), `sdk/verifier` (package `frankenengine-verifier-sdk` — the independent verification SDK: bundle/capsule/counterfactual/honesty-manifest verification, 7 modules + 12 test files incl. `DISCREPANCIES.md`, `COVERAGE.md`, `honesty_manifest_recompute.rs`).

**Module topology of `crates/franken-node/src/` (40+ modules, sizes [Counted, High]):** `connector/` 141,026 lines / 78 files — the distributed trust fabric (lifecycle state machine with a published transition diagram, cancellation protocol, fencing, lease coordination, CRDTs, quarantine store/promotion, ecosystem registry + reputation, VEF execution receipts, verifier SDK surface); `security/` 109,317 / 57 — trust cards, threshold (k-of-n) signatures, revocation freshness gates, MMR proofs, isolation backends (Bubblewrap), decision receipts, BPET evolution-risk scorer, DGIS contagion simulator; `ops/` 82,225 / 32 — doctor walkthrough, workspace-pressure policy, compat-corpus runs; `runtime/` 66,141 / 29 — the lane scheduler (4 logical lanes: ControlCritical > RemoteEffect > Maintenance > Background), effect receipts, hardware planner; `tools/` 56,451 / 44 — replay bundles, evidence-replay validator; `supply_chain/` 50,243 / 30 — project scanner, module-resolution graph, camouflage detector; `control_plane/` 42,623 / 21 — fleet transport (incl. the asupersync-gated `AsupersyncFleetTransport`), quarantine; `api/` 42,239 / 15 — control-plane API, MCP surface; `policy/` 38,704 / 20 — policy engine, perf-budget guards; `testing/` 27,838 / 4 — test-strategy harnesses; `migration/` 24,634 / 25 — the autopilot (audit, rewrite candidates, rewrite transactions, verified rewrites, rollback bundles, product oracle, smoke supervisor); `vef/` 22,226 / 12 — verifiable execution framework (proof generator/verifier/scheduler, receipt chains, evidence capsules); `observability/` 20,566 / 9; `sdk/` 15,467 / 3; `storage/` 14,298 / 8 — frankensqlite adapter; `remote/` 13,880 / 8 — remote capability operations; `repair/` 11,952 / 3; `federation/` 11,240 / 8; `perf/` 9,540 / 3; `dgis/` 9,303 / 10 — the contagion simulator; `atc/` 7,313 / 1 — adversarial trust calibration; `replay/` 7,109 / 3 — the time-travel engine (capture workflow traces, replay under sealed environment snapshots, byte-compare, structured divergence diagnostics); `registry/` 6,886 / 2 — the signed extension registry; `encoding/` 6,245 / 4 — canonical serializer; `verifier_economy/` 5,257 / 1.

**Dependency posture:** workspace deps include tokio (rt-multi-thread), serde, anyhow/thiserror, tracing, toml; notable absences vs. the domain: no V8/QuickJS bindings (native Rust execution per the engine-split — the actual JS engine is franken_engine's, path-depended, not vendored here), no node-bindgen. `Cargo.lock` holds 629 packages [Counted, High]; it contains `asupersync 0.5.0` (this repo's optional transport, pinned `=0.5.0`) alongside `asupersync 0.3.10` (also present in the lock graph). The lock also resolves the `frankenengine-engine` and `frankenengine-extension-host` path deps. Two hygiene notes: the repo's package name (`frankenengine-node`) does not match the repository name (`franken_node`) — a small discoverability wart [Code-verified, High]; and `docs/ENGINE_SPLIT_CONTRACT.md` says the repo "MUST consume engine crates from `/dp/franken_engine`" — the maintainer's local-machine absolute path — while the build actually uses the relative `../../../franken_engine` path dep that CI resolves by side-by-side checkout: doc-localism drift, minor [Code-verified, High].

**The trust card, dissected:** the project's central artifact is `TrustCard` (`crates/franken-node/src/supply_chain/trust_card.rs:854`, [Code-verified, High]) — 20+ fields: schema/card versioning with `previous_version_hash` (hash-chained card lineage), `ExtensionIdentity` + `PublisherIdentity`, `CertificationLevel`, `capability_declarations`, `behavioral_profile`, `revocation_status`, `provenance_summary` with `derivation_evidence` linking the card to verified upstream evidence, `reputation_score_basis_points` (u16) plus `reputation_trend`, `active_quarantine`, per-dependency trust summary, `audit_history`, `user_facing_risk_assessment`, persistent `camouflage_hints` (trajectory-gaming findings, `skip_serializing_if` for wire stability), and finally `card_hash` + `registry_signature`. The Debug impl redacts the hash and signature (`"[REDACTED]"`) — a small, telling operational-hygiene choice [Code-verified, High]. The card is versioned, chained, signed, and evidence-linked: the data structure *is* the trust thesis.

**The decoupling lens (Rulebook §6):** this project represents two decouplings. First, *trust/policy operations decoupled from JS execution internals* — the engine-split: franken_engine owns the VM, franken_node owns the trust contract, and the boundary is a checked-in contract plus a duplicate-implementation CI gate. Second, *evidence decoupled from the producing runtime* — the verifier SDK verifies receipts, bundles, and the honesty manifest with zero trust in the producer. Both decouplings are enforced by machinery (contract doc + gate; SDK + signature checks), not just asserted in prose [Inference, Medium].

**Data flow, end to end:** CLI (`cli.rs`, 35,531-line `main.rs`) → policy profile selection (strict/balanced/legacy-risky) → trust-card admission (supply_chain scanners, DGIS/BPET risk scoring) → revocation-freshness gating on risky actions → execution dispatched to the franken-engine binary (in-process for `franken-node run`; external Node/Bun paths rejected under profile-governed `run` because they cannot claim the containment contract) → every decision emits an Ed25519-signed receipt chained into the evidence ledger → incidents export as signed `.fnbundle` artifacts → `incident replay` re-derives the recorded decision sequence and verifies against the bundle hash (fail-closed) → `incident counterfactual` re-evaluates the recorded trace under an alternative policy. Fleet operations default to a local file-transport quarantine log; the asupersync transport (feature-gated) is the network control-lane path.

**The 35,531-line `main.rs`:** the binary entry point is a single 35,531-line file [Counted, High] — like FrankenRedis's 58,857-line `main.rs`, a reviewability cliff where CLI parsing, dispatch, and wiring meet, and the exact file where the trust apparatus meets the operator. No reviewer reads it whole; it is the bus-factor-1 bottleneck in file form [Inference, Medium].

## 4.5 The maintainer's stated case

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

1. **Trust-native operations as the differentiator:** revocation-first execution (risky actions consult fresh trust state before running), per-extension trust cards (provenance, behavior risk, audit history, camouflage assessment, revocation state), threshold k-of-n signatures, MMR proofs, audience-bound capability tokens, fork detection, epoch barriers [Maintainer claim, Medium — code exists per the module tour; behavior not executed].
2. **Deterministic compatibility:** lockstep verification against Node (the spec) plus Bun as a second reference, with signed divergence receipts; the L1 product oracle gates shipping at ≥95% corpus pass [Maintainer claim, Medium — the corpus number is verified (69.82%), the floor is stated, the gate is RED].
3. **Migration autopilot:** audit → rewrite → validate → rollout with deterministic stage artifacts; SARIF output for CI; unsigned JSON rollback plans [Maintainer claim, Medium].
4. **Incident replay and forensics:** signed bundles, integrity-verified replay, policy counterfactuals — explicitly *not* live re-execution [Maintainer claim, High — the limitation is stated plainly].
5. **Rigor artifacts:** the honesty manifest, 146 fuzz targets, mutation-adequacy floors (`mutants-gate.yml` enforces `MUTATION_SCORE_FLOOR_BP`), golden tests, the close-condition dual oracle [Code-verified, High for existence].
6. **Performance:** Criterion benches for trust-path primitives (Cuckoo revocation index, BLAKE3, replay-bundle gzip, trust-card canonical encode, proof-verifier gate, anti-entropy insert, threshold-sig verify) plus a `perf_wins` regression suite; hot-path budgets encoded as conformance assertions (`tests/hot_path_perf_budget_contract.rs`); the `bench run` CLI emits a SHA256 `provenance_hash` report — explicitly *not* an Ed25519-signed attestation [Maintainer claim, Medium]. **No "faster than Node/Bun" claims were found** — the only vs-incumbent numbers in the tree are synthetic fixtures for the bd-f5d campaign machinery (see table), which the README does not cite as results; the project's perf story is budgets and regression defense, not speedup ratios, which is more honest than the category norm [Inference, Medium].

**Benchmark reproduction cost:** a side-by-side `franken_engine` checkout (path dep), Rust stable toolchain, and the ~1.2M-line tree; benches run via `cargo bench -p frankenengine-node`. No independent reproduction is known [External, High within recall caveats]. The honest accounting: the benches measure the project's own primitives against their own budgets — there is no external incumbent number to beat, and the maintainer does not pretend otherwise.

**Benchmark audit table (Rulebook §4.5):**

| # | Number | Producer | Status | Would survive an independent rerun? |
|---|---|---|---|---|
| 1 | Criterion benches for trust-path primitives (Cuckoo revocation insert/lookup, BLAKE3 at hashing call sites, replay-bundle gzip round-trip, trust-card canonical encode/decode, VEF proof-verifier gate, anti-entropy insert, k-of-n Ed25519 verify) | Maintainer | Exists as `[[bench]]` targets. A real methodology doc exists: `docs/policy/benchmark_campaign_methodology.md` (bd-f5d) — 5 warm-up + 30 measured iterations per workload/runtime pair, 95% CI via 10k bootstrap resamples, winsorize at p1/p99, hermetic container with pinned digest, pinned Node/Bun/franken_node versions, fixed hardware profile, hash-addressable public datasets [Code-verified, High] | The methodology is specified to publication standard; the Criterion-bench controls (pinning, A/A nulls) are not tied to it in the assessed materials — treat the benches as un-audited, not disproven [Inference, Medium] |
| 2 | Public Node/Bun/franken_node benchmark *campaign* (10 workloads, 6 scored dimensions incl. compatibility correctness, containment/revocation latency, replay determinism, adversarial resilience; weighted composite score) | Maintainer (infrastructure); **no producer for the numbers** | Infrastructure delivered and self-verified PASS (`verification_summary.md`): campaign runner, report generator, verifier, methodology — **but the only results in the tree are fixtures**: `fixtures/benchmarks/campaign_results_{baseline,candidate}.json` reference franken_node "0.9.0" (no such release exists; the repo is at v0.1.0), the verifier calls them fixtures, and `check_benchmark_specs_package.py` speaks of `sample_package()` and `sample_overall_score: 0.9203`. The fixture data shows franken_node beating Node and Bun on every workload — it is synthetic test data for the campaign machinery, not a measurement. The README's benchmark table does not cite these numbers — correctly [Code-verified, High] | The machinery would survive a rerun; the numbers are sample data and would not — the distinction is load-bearing. A weighted composite score (compat 0.25 / perf 0.2 / adversarial 0.2 / …) on real data would let strong dimensions mask weak ones; on sample data it is a demo. One caveat the restraint doesn't erase: the fixtures are publication-ready comparison artifacts showing franken_node beating Node and Bun on every workload, and the only thing between sample data and a cited claim is maintainer discipline — a loaded gun the packet notes because the next assessment should check it hasn't been fired [Inference, Medium] |
| 3 | `perf_wins` consolidated suite "tracking historical wins to defend against regressions" | Maintainer | Exists per README benchmark table | Regression-defense, not a result — its value is as a ratchet, checkable in principle [Inference, Medium] |
| 4 | Hot-path perf budgets as conformance assertions (`tests/hot_path_perf_budget_contract.rs`, feature `policy-engine`): "a regression fails CI" | Maintainer | Test file referenced by README; not executed in this assessment | Budgets-as-tests is the honest form of a perf claim; greenness unestablished here [Maintainer claim, Medium] |
| 5 | `bench run` CLI reports with SHA256 `provenance_hash` | Maintainer | Explicitly *not* Ed25519-signed (README, twice) | Tamper-evident content hash, recomputable by a verifier — the modest claim is the credible one [Maintainer claim, High] |
| 6 | Real vs-Node/Bun campaign results | — | **None in the assessed materials** — the campaign infrastructure is "Delivered"/PASS with sample data only | N/A — the absence is the finding, and it rhymes with the asupersync case: "Delivered" means the machinery was built and self-verified, not that the measurement exists [Inference, Medium] |
| 7 | Independent benchmarks | — | **None known** [External, High within recall caveats] | — |

## 4.6 Competitors

The incumbent wins on ecosystem, operations knowledge, and the fact that it actually runs the world's JavaScript; franken_node's only uncontested edge is its evidence apparatus (honesty manifests, drift gates, close-condition oracles, signed decision receipts) — which no competitor bothers with because no buyer currently pays for it [Inference, Medium].

- **Node.js (OpenJS Foundation):** owns the runtime lane outright — ecosystem, LTS, operations knowledge, the spec itself (franken_node's L1 oracle *defines* Node as the compatibility spec). Recent `--permission`-model work shows the incumbent is aware of the trust direction [External, High on ownership; Medium on the permission-model reading]. franken_node cannot beat Node at being Node; its 69.82% corpus says so numerically.
- **Bun (Oven):** the velocity incumbent; franken_node treats Bun as a second lockstep reference, not the spec ("matching only Bun stays fail") [Maintainer claim, High]. Bun owns the "fast JS runtime" buyer perception [Inference, Medium].
- **Deno (Deno Land):** the closest philosophical competitor — permission-gated by default, supply-chain-aware, JSR provenance. Deno occupies "secure JS runtime" in buyer perception [Inference, Medium]. The differentiation is architectural, not just marketing: Deno's permissions are ambient-capability gates at the API boundary (can this code touch the network?), while franken_node's are revocation-freshness gates on *behavior* (is the trust state behind this action fresh? what does the extension's trajectory say?) plus replayable forensics — a different layer of the stack. But Deno ships a runtime people use, which dominates the comparison [Inference, Medium].
- **Socket.dev / supply-chain scanners:** own the "detect malicious npm packages" lane as a product category with real customers [External, Medium]. franken_node's trust-card + DGIS/BPET machinery is an in-runtime version of this; Socket's existence proves the demand is real and already served [Inference, Medium].
- **Sigstore / OpenSSF:** own the artifact-signing provenance lane (keyless signing, transparency logs) [External, High]. franken_node's registry signing and evidence ledger are adjacent, not competitive — and notably, the project's own release pipeline uses cosign keyless signatures (`.sigstore.json`) for binaries, i.e., it *consumes* the incumbent's solution for its own supply chain [Code-verified, High].
- **franken_engine (sibling):** not a competitor but the load-bearing dependency — franken_node's runtime-of-record is franken_engine's roadmap. Any franken_engine delay is franken_node delay [Inference, High].
- **Unoccupied lane:** a JS/TS runtime where trust operations (revocation freshness, per-extension risk cards, signed decision receipts, incident replay with counterfactuals) are part of the *runtime contract* rather than bolted-on scanners — no direct occupant [Inference, Medium]. Whether any buyer will pay for it before the corpus crosses 95% is the unproven bet the whole project rests on.

## 4.7 Skeptic's take

*Citation convention: weaknesses are numbered 1–9 below; elsewhere in this packet "§4.7.N" means weakness N.*

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

1. **[FATAL] The license rider poisons the well it drinks from.** Barring OpenAI/Anthropic *and their affiliates and anyone acting for them* from use, benchmarking, testing, analyzing, indexing, and training-data incorporation doesn't just block two companies — the "acting directly or indirectly for … or for the benefit of" prong creates legal uncertainty for any contributor near the AI supply chain, and the clause invites retaliatory scrutiny of the whole evidence project. A project whose moat is *evidence* forbidding evidence-gathering is self-negating [Inference, High]. §4.8 adds the sharper turn: the rider's "analyzing" bar arguably covers this very assessment.
2. **[FATAL] CI is red at the pin and the project's own oracle says not shippable.** 8/8 push runs against the pin failed (claim 16), the broader recent window is predominantly red, the L1 product oracle is RED at 69.82% vs the 95% floor, and the README's FAQ disclaims drop-in status. For a project whose pitch is *deterministic trust*, the observable state is: the gates don't pass and the product doesn't claim to work as a replacement [CI-observed + Code-verified, High].
3. **[HIGH] One human, no release artifact at the pin.** Bus factor 1 (claim 17); v0.1.0 exists but targets a May commit, not the assessed tree; CHANGELOG's documented window ends 2026-08-19, over a month before the pin — the project's own changelog is stale about its own recent work [Code-verified, High]. Every downstream claim rests on one person's continued output at ~20 commits/day.
4. **[HIGH] The engine it stands on is someone else's roadmap.** Default builds require the sibling `franken_engine`; the runtime-of-record (full host-effect API surface) is "still in active development under the engine-split program"; live re-execution of incidents is deferred to that work. franken_node is a product layer whose product depends on a second single-maintainer repo's unfinished runtime [Inference, High].
5. **[MEDIUM] The asupersync adoption is unverified where it matters.** Real feature-gated code, real `asupersync::Cx` usage, spec contracts marked "Delivered," perf budgets in `bd-1xwz` — and no CI job has ever compiled the feature. The one network control-lane transport is the one build configuration nobody runs. "Delivered" in the spec tracker means "merged," not "exercised" [Code-verified, High].
6. **[MEDIUM] The migration autopilot's headline pillar (≥3x velocity) has no number.** The charter promises ≥3x migration throughput/confidence; the assessed materials contain migration machinery (24k lines) but no measured throughput figure, and `migrate validate` is documented as static+smoke while behavioral comparison is a separate manual stage. The growth engine is unmeasured [Inference, Medium].
7. **[MEDIUM] The honesty machinery has a timestamp-shaped hole.** The signed manifest cannot date its own attestation (`generated_at` = epoch zero — claim 19); the validator census drifted by one script (437 → 438) without remark; and the local signature re-verification was unrunnable in this environment, leaving the Ed25519 claim resting on the in-CI SDK test. The apparatus is the best in the program and still has seams [Code-verified, High].
8. **[MEDIUM] Fleet is a file log wearing a control plane's clothes.** `live_control_plane=false` by default; quarantine/release/reconcile run over a local file-transport log needing "correct clock discipline"; multi-node needs the unverified asupersync feature or an external transport. The "fleet" story is single-node bookkeeping plus a network transport nobody CI-builds [Maintainer claim, High on the file-transport default; Inference, Medium on the characterization].

9. **[MEDIUM] The honesty machinery is itself Goodhart-bait — and the project knows the shape of the trap.** The README's "Effective coverage" section warns that a raw test *count* is Goodhart-bait and answers with mutation adequacy plus Wilson intervals. But the census optimizes *countable* things (test attributes, fuzz targets, validator scripts) — the exact class of metric the project warns about. Nothing in the assessed materials demonstrates that the drift gate measures claim *truth* rather than claim *countability*: a headline number could stay within tolerance while its meaning rots (the epoch-zero `generated_at` is a live instance — the manifest is "valid" and undated). The machinery is the best in the program; it is still a metric, and metrics get gamed, including by their authors [Inference, Medium].

**Bear-case steelman (strongest counter-case):** franken_node is a single-maintainer methodology project about *how to govern trust claims*, not a runtime. Its own oracle blocks shipping (L1 RED), its CI is red at the pin, its benchmarks measure its own primitives against its own budgets, its growth-engine metric (≥3x migration velocity) was never measured, its network transport was never compiled in CI, and its license forbids the entities best equipped to evaluate a 944k-line trust claim from even analyzing it. The rational market response is to mine it for governance patterns (honesty manifests, dual-oracle close conditions, mutation-adequacy floors) and never run it. Its most likely end state is abandonment at the maintainer's next context switch — leaving ~1.2M lines of evidence-governed Rust that the best-equipped evaluators may not benchmark, test, analyze, or index. [Inference, Medium — deliberately uncharitable; the counter-evidence is the sustained ~20/day commit velocity and the unusually thorough honesty apparatus.]

## 4.8 Maintenance & succession

**Bus factor: 1.** One human maintainer; 99 of the last 100 commits authored by Dicklesworthstone (1 by github-actions[bot]) over 2026-09-17 → 2026-09-22 [External, High]. No succession plan, no second committer, no foundation, no release artifact at the pin to fork from cleanly (the v0.1.0 release targets the May tag commit `08e1edf11` — a clean fork point for the released tree, but not for the assessed pin) [Inference, Medium — absence of evidence across the assessed materials; the no-release-at-pin half is External, High]. If the maintainer stops, the project freezes at whatever commit the stop happens on [Inference, High]. Unlike the sibling frankenredis packet's 36% agent co-authorship, this window shows 1% commit-message trailer co-authorship — the work is overwhelmingly single-human [External, Medium — trailer-based, 100-commit window].

**Agent authorship note:** the repo ships a 42,828-byte `AGENTS.md` governing AI coding agents (observed in the clone [Verified, High]), and several docs credit agent reviewers (e.g., `sdk/verifier/tests/DISCREPANCIES.md` lists "Reviewer: CrimsonCrane (Agent)"). Agent involvement is real but, unlike frankenredis, is not visible as mass co-authorship in the recent commit window. Line-level attribution was not performed [Not verified].

**Maintenance load signals:** ~20 commits/day sustained through the pin; the bead tracker holds 4,349 issues [Counted, High] — the closest thing to institutional knowledge transfer, living in-repo, which is good. Review depth is unassessed: PRs-vs-direct-to-main and who reviews bead closures were not examined [Not verified]. The 1,303-commit CHANGELOG window vs. the stale changelog tail (nothing documented after 2026-08-19) suggests documentation velocity already lags code velocity — a governance smell [Inference, Medium].

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

- **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 from the pinned LICENSE)
- **Grant:** "no rights are granted to any Restricted Party" without the author's "express prior written permission"; any purported license to a Restricted Party is "null and void."
- **Scope:** bars providing or permitting access to "the Software or any derivative work" to or for a Restricted Party.
- **"Use" is defined expansively** — "For purposes of this rider, 'use' includes, without limitation: 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 on the evaluation-relevant terms)
- **Remedy:** breach "automatically and immediately terminates" the permissions; the author reserves injunctive/equitable relief and attorneys' fees; "Affiliate" = >50% voting control or power to direct management/policies.
- **Distribution condition:** "any distribution of the Software or any Derivative Works must include this rider provision unmodified."
- **Classification:** non-OSI, source-available. The named-party discrimination fails Open Source Definition §5 (no discrimination against persons or groups) and the benchmarking/training/analysis bar fails OSD §6 (no discrimination against fields of endeavor) [Inference, High — legal conclusion, not legal advice]. Note the project's own honesty here: the root `Cargo.toml` deliberately uses `license = "LicenseRef-MIT-OpenAI-Anthropic-Rider"` with a comment explaining that declaring bare `license = "MIT"` "would misrepresent those terms" [Code-verified, High] — the non-OSI status is disclosed, not hidden.

**The recursion, confronted:** the rider's "analyzing" bar arguably covers this very assessment — and, read maximally aggressively, the "agent acting for" prong could sweep in any agent-assisted analysis of the code. The argument as stated skips its load-bearing premise: the rider restricts *who* may analyze — Restricted Parties and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" one — not analysis per se, and nothing establishes that the FrankenSuite analyst acts for or on behalf of OpenAI or Anthropic; the assessment is conducted for the program's own research [Inference, Medium — legal conclusion, not legal advice].

**Succession consequence:** even a willing acquirer inherits a license that shrinks the contributor and evaluator pool; removing the rider requires the sole copyright holder's action — the same single point of failure as everything else [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 4** | Lab-validated components (honesty census re-verified live, 146 fuzz targets, conformance harnesses, criterion benches) with zero production exposure, CI red at the pin, and the project's own close-condition oracle RED — component validation in lab, not system validation [Inference, Medium] |
| Strategic relevance | 3/5 | Trust-native JS/TS operations are central to the agent-tooling era the FrankenSuite cares about, but the rider blocks the program's own engagement with the software [Inference, Medium] |
| Impact potential | 2/5 | The evidence-linked trust-operations lane is genuinely unoccupied, but the charter's own pillars (≥95% corpus, ≥3x migration velocity) are unmet/unmeasured and no demand signal exists [Inference, Medium] |
| Implementation feasibility | 2/5 | 944k lines plus a mandatory sibling-repo checkout, one maintainer, no release artifact at the pin — any adopter inherits the whole tree plus the rider [Inference, Medium] |
| Time to mainstream | 2/5 | Years at best: L1 corpus 69.82% → 95%, rider disposition, 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) from even analyzing the code; bus factor 1 [Inference, Medium] |

**Ring: Explore** [Inference, Medium]. The Rulebook's default for substantive-but-unproven. The factsheet above is the scaffolding the ring stands on. The rider does not change the ring — it is recorded as the advancement blocker (§4.8) and 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 honesty manifest + drift-gate + verifier-SDK recompute loop, the dual-oracle close condition, the mutation-adequacy floor, and the threat-model-with-regression-anchors are directly importable into how the program evaluates the other 42 repositories. Do not depend on the software: the rider, the red CI, the RED oracle, and the missing release disqualify it as a dependency, benchmark target, or training-data source. If the program ever needs a trust story for JS tooling, Deno owns the shippable lane and Socket owns the scanning lane — franken_node owns only the evidence-governance pattern [Inference, High].

---

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — the JS/TS language surface and the Node API shape.** Inherited standards; commodity by definition — compatibility is table stakes, not differentiation. Moves right only if the spec owner moves it: Node API additions are exactly the mover — every new API is a new corpus campaign the lockstep harness must absorb before the L1 oracle can go GREEN [Inference, Medium].
- **Custom-built, pre-Product — the 944k-line trust platform** (trust cards, revocation gates, migration autopilot, incident replay, fleet quarantine). Custom-built on process rigor alone; not yet product (L1 oracle RED, no release at pin, CI red). Moves right with the corpus crossing 95% plus a tagged release plus an independent evaluation; decommissions (becomes a monument) if Deno or Node absorbs the trust-operations story first [Inference, Medium].
- **Custom-built, closest to Product — the honesty and evidence-governance machinery** (signed honesty manifest + census + drift gate + verifier-SDK recompute; dual-oracle close condition; mutation-adequacy floors; golden CLI tests). The packet's own "real export" (§4.9): the most *executed* component in the tree — used operationally in-repo on every push via 51 workflow files in the tree (50 enumerated by the Actions API). Moves right if extracted as a standalone claim-governance framework other projects can adopt; stays repo-local tooling, effectively invisible outside the repo, while the rider blocks the likeliest adopters [Inference, Medium].
- **Genesis — revocation-first execution + replayable incident forensics as a runtime contract.** No incumbent ships "consult fresh trust state before the risky action" and "export the incident as a signed, replayable, counterfactual-capable bundle" as first-class runtime behavior. Moves right if the counterfactual simulator graduates from recorded-trace re-evaluation (its current, honestly-labeled form) to live re-execution under the engine — the runtime-of-record work — or stagnates as single-maintainer machinery if velocity decays [Inference, Medium].
- **Genesis (unpressured) — the verifier economy.** A 5,257-line single-file economic layer for validation markets: no incumbent equivalent, but also no second participant and no documented workflow that touches it. Genesis without a selection pressure — it cannot move right until a second economic actor exists, which makes it the purest "unexercised option" on the map [Inference, Low].

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

1. **L1 corpus 69.82% vs 95% floor** — the charter's own table-stakes pillar, unmet by 25 points [Code-verified, High].
2. **Runtime-of-record incomplete** — full host-effect API surface still in development under the engine-split program; `child_process` native-eval aborts remain fail [Maintainer claim, High].
3. **Incident replay ≠ re-execution** — the counterfactual simulator re-evaluates the *recorded* trace under a different policy; the README labels the executor so "a synthetic re-evaluation is never mistaken for a live re-run" — honest, and a ceiling [Maintainer claim, High].
4. **Fleet is file-transport by default** — multi-node needs the never-CI-compiled asupersync feature or an external transport [Code-verified, High].
5. **CI red at the pin** — 8/8 observed runs failed; failure causes unestablished (logs need auth) [CI-observed, High].
6. **CHANGELOG stale** — documented window ends 2026-08-19, five weeks before the pin [Code-verified, High].
7. **Manifest timestamp hole** — `generated_at` = epoch zero (claim 19) [Code-verified, High].
8. **Legal overhang** — the rider's aggression invites the question it tries to preempt: a trust-evidence project whose author bars analysis is making assertions the best-equipped parties may not test [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]:** velocity continues at ~20/day; the L1 corpus climbs bead by bead but stays under 95% (25 points is a long grind); the asupersync feature either gets its first CI compile or stays "Delivered"-in-name; no tagged release at the assessed commit; the rider stands. The methodology gets mined (honesty manifests, close-condition oracles appear in sibling projects); the software gets no production users. Ring: Explore, unchanged. The nearest-term observable is the *next tag*: if the next release tag lands on a commit where L1 is GREEN at ≥95%, the close-condition discipline is real and the trajectory bends toward Pilot; if the next tag lands while L1 is still RED, the ship gate is weaker than documented and the "consistency vs ship" distinction is doing the heavy lifting — downgrade the oracle from governance to instrumentation in the next assessment.

**24-month base case [Inference, Low]:** one of two shapes. Either the program compounds — corpus crosses 95%, the runtime-of-record lands via franken_engine, a first tagged release ships with the dist pipeline's cosign-signed artifacts — and the packet's checklist starts scoring above zero; or velocity decays after the initial program arc completes and the tree enters maintenance drift (the CHANGELOG staleness is the early 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 with a small high-assurance following or dormant — the abandonment end state in the §4.7 steelman. The methodology-export (honesty manifests, dual-oracle close conditions, mutation-adequacy floors) is the durable survivor either way.

**Bifurcation — what the upside requires:** all four, in rough order: (a) the L1 corpus crosses the 95% floor with the oracle going GREEN (trigger 1); (b) the rider narrowed or removed (trigger 3) — without this nothing else matters for adoption by the likeliest evaluators; (c) a tagged release with a stability policy (trigger 2); (d) a second human committer (trigger 4). The rider is the *necessary* condition for adoption, not merely second in a list: corpus GREEN without rider disposition still leaves the software un-analyzable by AI labs and their agents.

**Bifurcation — what decay looks like:** commit velocity falls off a cliff (the observable sensor is trigger 7 below), CI workflows go red or silent, the honesty census starts drifting past its tolerance bands, and the tree freezes as a ~1.2M-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. **L1 product oracle goes GREEN** — `artifacts/oracle/l1_product_verdict.json` reads GREEN (corpus ≥95%). Flips the "not shippable by its own gate" judgment.
2. **A tagged release or GitHub Release pointing at the assessed commit appears** — `git for-each-ref refs/tags` / `gh release list` non-empty *at the assessed commit*. (v0.1.0 exists — released 2026-05-29 with binary assets — but targets the earlier tag commit `08e1edf11`, so this stays open.) Flips the "no artifact to evaluate" judgment.
3. **Rider narrowed or removed** — LICENSE diff dropping the named-party restriction. Flips usability for restricted parties and contributor-pool risk. This is the advancement blocker for the Explore ceiling.
4. **Second human committer with merge rights** — bus factor > 1 observable on the contributor graph. Flips succession risk.
5. **The `asupersync-transport` feature compiles in CI** — any workflow building `--features asupersync-transport` or running `asupersync_control_lane_integration`. Flips claim 13 from partially demonstrated to demonstrated.
6. **Independent benchmark, review, or production user** — any third party evaluating or deploying it. Flips "zero independent coverage."
7. **(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.
8. **A Node/Deno/Bun release ships a trust-operations equivalent** (revocation-first execution, per-extension trust cards, replayable incident bundles) — the kill-test: if incumbents absorb the trust story, franken_node's differentiation collapses to "evidence governance, but not a runtime" [Inference, Medium].

## 4.12 Verdict & NODUS ring

**NODUS ring: Explore.** franken_node is the textbook substantive-but-unproven case: substantive (944,364 src lines, zero unsafe, 146 fuzz targets, ~25k tests, a signed honesty manifest re-verified live with 0 drift, a 22-row threat model — all [Counted/Verified, High]) and unproven (no release artifact at the pin, CI red at the pin, L1 oracle RED at 69.82% vs its own 95% floor, bus factor 1, zero independent coverage, the charter's ≥3x migration-velocity pillar unmeasured). "When in doubt, ring down" does not apply — there is no doubt about the Explore floor; the doubt is about *evaluability by us*, which is not what the maturity scale measures. The rider is instrumented as an **advancement blocker**: quoted as the adoption ceiling in §4.8, priced into the NODUS feasibility (2) and collaboration (1) scores, and wired to revisit trigger 3. 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:** franken_node is a 944k-line bet that JS/TS extension security can be made a runtime contract — revocation-first execution, per-extension trust cards, signed decision receipts, deterministic incident replay — and on process grounds it is the most self-scrutinizing codebase assessed in this program: zero unsafe under forbid-lints, a machine-checkable honesty manifest, drift gates, a conjunctive close-condition oracle, mutation-adequacy floors. The closed loop the skeptic must name: every trust anchor in that apparatus — the manifest's signing key, the census script, the drift gate, the SDK conformance test — terminates at the same single human whose claims they attest. It is independent software, not an independent party. But the product case is hollow at the pin by the project's own instruments: its oracle says not shippable (L1 RED, 69.82%), its CI is red at the pin (8/8 observed runs failed), its network transport was never compiled in CI, one human is the entire bus factor, and the license forbids the likeliest evaluators from even analyzing the code. Explore the methodology; the software 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:** the workspace was never compiled (default features require the sibling `franken_engine` checkout, which was not performed); no binary was built; no test suite was executed (so the 3,756-test census, the quorum tests, and the asupersync integration test exist but their pass/fail was not independently established); no benchmark was reproduced; the Ed25519 honesty-manifest signature was not cryptographically re-verified locally (no `cryptography` library; enforced by the SDK conformance test in CI per the maintainer); CI job logs were not readable (GitHub logs API returned 403 without auth) so the pin's 8 failure causes are unestablished; full git history was not pulled (authorship covers the last 100 commits via API only); line-level agent-attribution was not performed. **CI greenness at the pin: ESTABLISHED as red** — per-run conclusions fetched via the Actions REST API for all 8 runs at `head_sha=08447a0a…`: 8 `failure`. GitHub Releases re-fetched 2026-09-22: one release, `v0.1.0` (published 2026-05-29, 6 binary assets), targeting the earlier tag commit — not the pin [External, High]. Demand-signal search performed 2026-09-22: no independent coverage beyond the repo, one fork, and the maintainer's personal site [External, High within recall caveats]. Quick-link resolution verified 2026-09-22 (11/11 HTTP 200).

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

1. **Why is CI red at the pin?** Per-run conclusions are established (8 failures); per-step causes are not (logs need auth). A formatting-gate failure (cf. the frankenredis packet's G1 fmt red) vs. a substantive test failure changes the reading completely.
2. **Does the rider bar this very assessment?** The license's "analyzing" prohibition arguably covers the FrankenSuite's evaluation activity. A legal reading either way changes whether the program may continue touching the repo at all.
3. **What fraction of the tree's lines are agent-written?** Commit-trailer analysis (1% in the recent window) measures commits touched, not authorship share — and the 42KB AGENTS.md plus agent-credited reviewers suggest deeper involvement. A `git blame` sample over full history would settle it.
4. **Is the Ed25519 honesty signature valid?** Structurally present and live-check passes, but cryptographic verification was not performed in this environment. One command with the `cryptography` library settles it.
5. **Does the asupersync transport actually work?** The feature has never been compiled in CI. Building `--features asupersync-transport` and running the control-lane integration test answers in an afternoon.
6. **Is there any production user or demand signal?** One real deployment would move impact potential and the 24-month trajectory more than any code change. (Search 2026-09-22: none found.)
7. **What is the review depth?** PRs-vs-direct-to-main, who reviews the 4,349 beads' closures — unassessed; determines whether the bead tracker is institutional knowledge or a solo diary [Not verified].

---

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

**1. Provenance.** The repo's provenance machinery is the decision-receipt + evidence-ledger system: every control-plane and runtime decision emits an Ed25519-signed receipt chained into the evidence ledger, with evidence references the verifier SDK can recompute without trusting the producer [Code-verified, High on the mechanism's existence; behavior not executed]. A second, quieter provenance layer is the benchmark and claim discipline itself: `bench run` reports carry a SHA256 `provenance_hash` over the report body (explicitly tamper-evident content hashing, *not* a signed attestation — the README says so), and the honesty manifest binds claim values to a signed census digest [Code-verified, High]. What nothing records is *who* produced an artifact at the code level — receipts attest to decisions, not to authorship — so provenance-of-code (the agent-attribution question, §4.13.3) is unaddressed by the machinery [Inference, High]. Portable attestation would require binding each receipt's evidence refs to content hashes verified at read time — the direction the runtime already takes for CAS effect receipts (read-time hash verification plus chain-link recomputation, per the threat model) — extended from the CAS subsystem to the ledger itself (the write-time origin-binding direction — cryptographically binding recorded provenance to its point of origin rather than to the point of recording; cf. arXiv 2606.24322 on provenance tampering through record-origin separation [External, Medium — cited as a research pointer, not verified by this packet]); plus a real `generated_at` on the honesty manifest, since an undated attestation cannot be fresh [Inference, Medium].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is `frankenengine-verifier-sdk`: bundle/capsule/counterfactual/honesty-manifest verification that runs outside the producing runtime, with its own conformance matrix (57/57 spec clauses per its COVERAGE.md) and a discrepancies log that currently records zero divergences [Code-verified, High on existence; the 100% figures are Maintainer claim, Medium]. Adoption cost: the SDK is a workspace path dependency, not a published registry artifact in the assessed materials, so the unit is vendored, not versioned — and it inherits the workspace's toolchain assumptions [Inference, Medium]. The trust-card and revocation machinery, by contrast, is *not* an embeddable unit: it is woven through the 109k-line `security/` module and the policy engine with no extraction story [Inference, Medium].

**3. Unexercised option value.** Three capabilities the architecture holds but has not used. First, the asupersync transport: 4,675 lines of feature-gated fleet control-lane code with perf-budget contracts (`bd-1xwz`: p95 ≤8–15% overhead on hot paths) that no CI job has ever compiled — the network plane is held in reserve behind a feature flag nobody turns on [Code-verified, High]. Second, the counterfactual simulator: currently a policy-threshold model re-evaluating the *recorded* decision trace — the honest, limited form — while the architecture (sealed environment snapshots, the time-travel engine's byte-compare replay) is shaped for live re-execution under the engine once the runtime-of-record lands [Maintainer claim, High on the current form; Inference, Medium on the trajectory]. Third, the verifier economy (`verifier_economy/`, 5,257 lines in one file): a whole economic layer for validation markets that is present but peripheral to every documented workflow [Code-verified, High on existence; Inference, Low on what unlocks it]. What unlocks each: a CI job that builds the asupersync feature, the franken_engine runtime-of-record maturing, and — for the economy — a second participant, which does not exist [Inference, Medium].

**4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the project's own census numbers — the honesty manifest's live re-verification (3,756→4,106 tests; 21,621→22,421 inline; 146/146 fuzz; 0 unsafe) is the rare benchmark-adjacent claim in this program that I *did* independently rerun, and it held within tolerance [Verified, High]. The Criterion benches (Cuckoo revocation, BLAKE3, replay gzip, trust-card canonical, proof-verifier gate, anti-entropy, threshold-sig) measure the project's own primitives against its own budgets — there is no external incumbent number, and the maintainer claims none, which makes them honest and narrow [Maintainer claim, Medium]. One refinement from the tree: the public Node/Bun/franken_node campaign *infrastructure* (bd-f5d) is delivered and self-verified — real methodology doc (warm-ups, 30 iterations, 95% bootstrap CI, hermetic pinned container), runner, report generator, weighted composite score — but its only results are synthetic fixtures referencing franken_node "0.9.0," a version that does not exist; the maintainer does not cite the fixture numbers as results, which is to their credit [Code-verified, High]. Which numbers are load-bearing for the thesis? Not the benches — the thesis rests on the corpus (69.82%, RED) and the unmeasured ≥3x migration-velocity pillar: the two numbers that would matter are the two that are missing or failing [Inference, Medium]. The honesty audit extends to non-numeric claims: `bench run` reports are SHA256-hashed, not signed, and the README says so twice; rollback plans are unsigned JSON, and the README says so; `migrate validate` is static+smoke, and the README says so. The project disclaims its own weak points in writing — the most benchmark-honest posture in the program, applied to numbers that don't yet support the pitch [Inference, Medium].

**5. The governance path.** The credible route from one maintainer to an institution runs through four gates: L1 corpus GREEN at the 95% floor (trigger 1), rider disposition (trigger 3), a tagged release with a stability policy (trigger 2), a second human committer (trigger 4). The starting position: no succession plan, no second committer, no foundation, no release artifact at the pin, a CHANGELOG whose documented window ends five weeks before the pin [Inference, Medium on the absences — the no-release half is External, High]. The closest thing to institutional knowledge transfer is the in-repo bead tracker (4,349 issues [Counted, High]) plus the evidence ledgers — process artifacts that outlive a maintainer, and the only onboarding story a successor would inherit; review depth (PRs-vs-direct-to-main, who reviews bead closures) is unassessed [Inference, High — this assessment did not examine PR/review metadata] and parked as §4.13 open question 7. What breaks first if velocity decays: the honesty census — the validator count already drifted 437→438 within tolerance, and the manifest's epoch-zero timestamp shows the attestation pipeline is maintained by hand; then CI bit-rot (already red); the 60-day abandonment tripwire (trigger 7) is the observable sensor [Inference, Medium]. The realistic institutional endpoints are a foundation home or a corporate adopter — both currently gated on rider disposition, 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 (>50% voting control or power to direct management/policies); and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — barring "use" defined expansively (copying … benchmarking, testing, **analyzing, indexing** … incorporating into datasets, training corpora, evaluation harnesses, or ML pipelines), with automatic termination on breach and a requirement that every distribution carry the rider unmodified [Code-verified (license text), High]. Does the exclusion serve or sabotage the stated mission? It sabotages adoption and evaluability: the entities with the resources to validate a 944k-line trust claim — and their agents — may not benchmark, test, analyze, or index the code, while the "acting for" prong creates legal uncertainty for any contributor near the AI supply chain; it is already priced as the Explore ceiling (feasibility 2, collaboration 1, trigger 3) [Inference, High]. What it arguably *serves* is a defensive intent — denying ~1.2M lines of curated trust-systems 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 moat is *evidence* forbidding evidence-gathering is self-negating [Inference, Medium]. The remaining strategy point: the rider is a licensee-facing contract term — it binds users, not the author — so its strategic function is access control, not provenance hygiene; and unlike some sibling packets' badge shorthand, this repo's `Cargo.toml` explicitly refuses to declare bare `license = "MIT"`, disclosing the non-OSI status in the manifest itself [Code-verified, High].

**7. Agent-era fit.** The concrete agent workload that would pick this over the incumbent is the agent-safety eval workload: a team needing a JS/TS execution environment where every risky action is gated on fresh trust state, every decision emits a signed receipt, and incidents export as replayable bundles with policy counterfactuals — the threat model's MCP-mutation-abuse row (audience-bound capability chains, attenuated delegation, signed action receipts) is already written for agent operators [Inference, Medium]. What would have to become true first: the L1 corpus crossing 95% (agents run real npm packages; 69.82% breaks them), the runtime-of-record landing (live re-execution, not just recorded-trace replay), and the rider narrowed or removed — the target user (AI labs and their agents) is currently barred by name from even *analyzing* the code [Inference, Medium]. The fit is real but presently blocked by the license aimed at its own likeliest users: the rider names the agent operators as Restricted Parties while the project's best adoption story is an agent workload — and the recursion is noted in §4.8 (this packet is itself an agent-assisted assessment of code written substantially by a human directing agents, under an anti-agent-analysis rider) [Inference, Medium].

**8. The kill test.** The single experiment that would falsify the core thesis — that trust operations can be made a JS/TS runtime contract worth adopting — is the one the project built for itself: the L1 product oracle. If the corpus stalls below the 95% floor indefinitely (or regresses), the charter's own table-stakes pillar fails by the project's own mechanism, not by a critic's [Inference, Medium]. Two secondary falsifiers sit behind it: a competitor move (Node shipping revocation-first execution, Deno shipping per-extension trust cards and replayable incident bundles, or Socket.dev shipping an in-runtime enforcement story — collapsing the differentiation to "evidence governance, but not a runtime," trajectory trigger 8) and the abandonment tripwire (trigger 7: 60 days without commits or disabled CI re-rings to Monitor). The production checklist is the inverse of this test — what success requires, scored at the pin as 0 of 8 fully met: L1 GREEN at ≥95%, tagged release at the assessed commit, asupersync feature compiled in CI, rider disposition, bus factor > 1, CI green at the pin, measured ≥3x migration velocity, independent evaluation. Zero are met; the closest is the honesty census, which is process, not product [Inference, Medium].