EXP 007 — Which of your gate's rules need a model at all?

Pre-registered, not yet run. For every rule the eight plugins ship that meets the inclusion test (51 items excluded, listed; hunch's 1,011 spec rules sampled 30), how much could a deterministic checker decide on its own, before any model is asked? This record fixes stage 1, the census, before any census call is made: the rules, the translator's inputs and its output, the checks that can only lower its answer, the scorer, the controls and the bar that would refute the premise. Stage 2, the cascade with Jev, is pre-registered by a dated amendment before any paid Jev call. Measured — premise refuted, 7 Oct 2026: see the results.

The question

Take the rules that eight listed Jev plugins ship with their own code. For each rule, can a deterministic static checker (bce-engine 0.3.1, no model) decide it as written (expressible), decide a strict part of it and leave the rest to a model (partial), or decide no non-trivial part of it (not)? Per plugin, what share of its rules is expressible, and what is the median share across the plugins?

Stage 1 of 2 (census); stage 2 pre-registered by amendment before any paid Jev call.

Why ask it

In EXP 005 a model-free line linter written from the same seven architecture rules missed none of the 30 drift items, and Jev missed one, so its criterion against the better model-free baseline was refuted. Those rules were ones a static check can decide. (EXP 005: its better model-free baseline missed 0 of 30 drift items; results record sha256 7388556049b7639e2a251edcf3fb8feb782213b78e71a02cddb687f12b09dccd.)

If many of the rules a gate asks a model about are decidable by a static check, a gate could settle those first, for nothing, and ask the model only about the rest. EXP 007 first counts how many such rules the gates people actually ship contain.

The rules: eight plugins, pinned

Each plugin's own rule files, read at a pinned commit and vendored with the sha256 of every source file. An item is a rule of the primary stratum when its answer by itself gates, blocks, flags or denies an action or a change. Locators, triage, category, severity and kind classifiers, score-only dials that feed a combined decision, and templated questions with runtime placeholders are excluded and listed with their reasons. Allow-rules (fast paths, allowlists) are excluded: the bce vocabulary is forbid-only and an allow-rule is a different decision. One regex, one question, one prose line or one rubric entry is one rule.

• hunch (Kelbie/hunch at c2c680ed; MIT, Copyright (c) 2026 Kelbie): 8 rules in the primary stratum, 30 in the secondary sample, 0 items excluded with a reason
• jev-pref (doeixd/jev-pref at 9d77ea60; MIT, Copyright (c) 2026 jev-pref contributors): 4 rules in the primary stratum, 0 items excluded with a reason
• abide (coldteadotai/abide at ea6d0976; MIT, Copyright (c) 2026 Coldtea AI): 43 rules in the primary stratum, 0 items excluded with a reason
• limpet (noplan-inc/limpet at 7a841b00; MIT, Copyright (c) 2026 no plan inc.): 10 rules in the primary stratum, 0 items excluded with a reason
• jev-belay (valentynkit/jev-belay at ef719db7; MIT, Copyright (c) 2026 Valentyn Kit): 0 rules in the primary stratum, 4 items excluded with a reason
• jev-engineering (eugeniughelbur/jev-engineering at 82655a6d; MIT, Copyright (c) 2026 Eugeniu Ghelbur): 16 rules in the primary stratum, 23 items excluded with a reason
• pi-verdict (jesset/pi-verdict at 1b37e5f2; MIT, Copyright (c) 2026 Jesset): 41 rules in the primary stratum, 4 items excluded with a reason
• jev-axi (shiftynick/jev-axi at 044fae73; MIT, Copyright (c) 2026 Nicholas Underwood (shiftynick)): 23 rules in the primary stratum, 20 items excluded with a reason

145 rules in the primary stratum across 7 plugins; jev-belay has none that passes the inclusion test at the pin, so it has no share in the median. hunch's specification rules (rules/bips-spec.json, nips-spec.json, nuts-spec.json) are a secondary stratum: a seeded sample of 30 (seed 7007; the sampling code is committed in extract.mjs), reported separately and never in the median. Out of scope: DiffJury (no license); Blink (no public repository or license found); jev-guard (MIT, but not named by the council verdict; kept out to hold the council's 6 to 8 range (out of scope, not a finding)).

The translator is blind

Exactly: an opaque id (item-<first 12 hex of sha256("exp007-census-v1:" + ruleId)>, mapped back to the ruleId by the runner), the rule's verbatim text (the single text field pinned per plugin in selection.json), its input kind, its regex flags when it is a regex, the rule's match target and application condition as an 'Applies to' line where the source defines one (the context field, one factual sentence per source group plus the rule's own file globs, where a glob that names the rule's own plugin shows that name as <tool>), and the materialisation contract with the accepted constraint types (the whitelist) and one generic example each (contract.md; contract-module-graph.md for the positive controls); plus the pinned system prompt.

It never sees: Any case, any label, any plugin evaluation file, abide's own type field, another rule's class, or any result. Every other field of a source item is stored under withheld in the rule file and never rendered into a prompt. The prompt builder (protocol.mjs) reads exactly five fields of a rule, {ruleId, text, inputKind, flags, context}, and shows the ruleId only as the opaque id. A test hands it a rule whose other fields throw when read, and renders both prompts for every rule to show that no plugin name, no stratum or control word and no segment of the ruleId appears outside the rule's own text (six generic words of the fixed contract and system prompt are listed as exceptions).

One JSON object: {ruleId, class: expressible | partial | not, constraints: [bce constraint objects], coverage, residual (a yes/no question when the class is partial or not, otherwise empty), probes: {violating, compliant} (empty when the class is not), rationale of at most 80 words}.

The three classes, defined before any call:

• expressible: the constraints alone decide the rule as written on every input of its kind (no residual)
• partial: the constraints decide a strict, non-empty subset (e.g. the flagrant forms) and a residual question is required for the rest
• not: no whitelisted constraint decides any non-trivial part

What can only lower an answer

Mechanical checks, in code, in this order:

• the answer is one JSON object with a valid class, matching the output schema
• every constraint type is in the vocabulary
• bce validate passes on a blueprint holding the constraints
• for a regex rule with /i, the flags check: no forbiddenPattern carries an upper-case letter, literal or escaped, nor an escape the check cannot verify (an identity escape of a letter, \p, \P, \k) (the adapter lower-cases an /i rule's input, so such a letter could never match); g and d change no verdict; any other flag cannot be verified mechanically: an expressible answer (which by the schema has no residual) with any other flag (m, s, u, v, y) drops to not, and such a rule reaches partial only when the translator itself answers partial with a residual
• teeth passes through the adapter: every violating probe makes the constraints FAIL, the compliant probe makes them PASS, and each constraint alone makes at least one violating probe FAIL
• a pinned class cap from the rule's source group (pi-verdict's 8 write-only path rules: at most partial, because a line checker cannot join a tool's name to its path); an expressible answer, which by the schema has no residual, drops to not, so such a rule reaches partial only when the translator itself answers partial with a residual

The first failing check lowers the class once: expressible becomes partial if a residual was given, else not; partial becomes not. Each downgrade is recorded with the failing check. A pattern the engine's safe-compile guard refuses fails validation and is counted in a separate engine-limit category. An answer that is not a JSON object with a valid class, a timeout, a model id other than the pin, or any other harness failure is class error, counted as not (conservative) and listed.

A separate process on a different pinned model, no tools. Exactly what the prompt builder sends: the pinned system prompt; the same opaque id; the input kind; the 'Applies to' line (the rule's match target and application condition, where the source defines one); the regex flags (regex rules only); the rule's verbatim text; the translator's answer verbatim; a mechanical summary with schema, vocabulary, the checker's validation, teeth, the flags check (flagged rules only), the translator's class and the class after the checks; the flag-semantics sentence (flagged rules only); and the stated class to confirm or dispute. No case. It answers {ruleId, verdict: confirm | dispute, proposedClass, reason of at most 80 words}. Confirmed: the class after the mechanical checks. Disputed: the lower of that class and the proposed class (not < partial < expressible), so a dispute can only lower expressibility. Translator-adjudicator agreement is reported as Cohen's kappa over the three classes, with the number of rules it is computed on and the list of disputes: rules whose translator or adjudicator call ended in error are excluded; computed over all census rules including controls.

The checker and the adapter

bce-engine 0.3.1. The vocabulary is the constraint types bce-engine 0.3.1's evaluate() implements and grades statically on the pinned profile, derived from the installed engine source and cited by file and line in whitelist.json with the engine files' sha256. package.json and the lockfile pin 0.3.1 and are unchanged; any engine change is an operator decision. customPolicy is declared by 0.3.1's schema but evaluate() has no branch for it, so it enforces nothing; the adapter refuses it (and every other type outside the vocabulary) with a typed error.

• Plugin rules: forbiddenDependency, forbiddenFile, forbiddenPattern, forbiddenEgress.
• Positive controls: forbiddenDependency, requiredDependency, requiredComponent, forbiddenPath, forbiddenFile, forbiddenPattern.
• Not in the vocabulary: behavioralInvariant, requiredEvidence, minimumMetric, customPolicy.

Plugin rules run on the plugin-surface profile with the ast extractor, scanning .floor/** and src/**/*.ts for diff inputs and .floor/** otherwise, with minFiles equal to the files the engine resolves for the materialised input. The positive controls run as EXP 005 ran them: typescript-module-graph over src/**/*.ts. Scoring reuses EXP 005's contract (bce-contract.mjs: materialise, run, interpret), imported, not copied.

• diff: EXP 005's base tree after the patch, plus .floor/diff.patch (verbatim), .floor/added-lines.txt (the added lines with a +++ <path> header per changed file; the path without a b/ prefix or tab-separated date; deleted files contribute nothing) and .floor/added/<path> (each changed file's added lines alone, so a file-scoped rule can glob them).
• toolCall: .floor/tool-call.json (the hook input, pretty-printed) and .floor/command.txt (tool_input.command verbatim, else empty).
• stopTranscript: .floor/transcript.jsonl (one event per line) and .floor/final-message.txt.
• file: the document at .floor/files/<path>.
• An /i rule is graded case-insensitively by construction: its input's .floor files and, for a diff, its scanned post-patch sources are lower-cased before the checker runs (paths are not); judge and teeth both see the folded input.

judge() takes the rule's final class: expressible gives pass or fail from the engine; partial gives fail from the engine and otherwise abstains; not always abstains. A rule with an empty constraint set abstains. teeth(constraints, {violating, compliant}) passes only if every violating probe (one input or a list) makes the constraints FAIL, the compliant probe makes them PASS, and each constraint alone makes at least one violating probe FAIL, through the adapter and the real engine. A vacuous constraint fails teeth, alone or beside a real one. Every diff input is a patch against EXP 005's base tree (experiments/jev-gate/base), committed as EXP 005's scoring contract commits a tree (baseCommit; baseTree is its git tree id). Its file list, not its contents, is in the translator's contract, so probes add files. Base commit 2c55f16e20ccc27e60d5c53e25661acafb82133f, tree 957b5e10c099ef2c86bb4543a8560aba59290d62.

Controls

• EXP 005 rules.txt rules 2 to 8, verbatim (controls/positive.json): the EXP 005 blueprint enforces each of them with bce 0.3.1.
• Six semantic control rules, each needing the meaning or intent of the input (controls/negative.json), graded on the same path as the plugin rules.

Calibration bar. At least 6 of 7 positive controls final expressible or partial, and at most 1 of 6 negative controls final expressible. A miss is published and the census reported as "translator uncalibrated"; the run continues and nothing is silently re-run. Controls are outside every median.

What is measured

• expressibleShare: Per plugin: final expressible / rules in its primary stratum, with n.
• partialShare: Per plugin: final partial / rules in its primary stratum, reported beside the expressible share.
• headline: The median across plugins of the expressible share (strict). A plugin whose primary stratum is empty has no share: it is listed and not counted.
• preDisputeMedian: The same median computed on the classes after the mechanical checks and before the adjudicator, reported because disputes can only lower.
• sensitivity: The median with partial counted as 0.5; reported, not decisive.
• secondary: hunch's secondary sample: its class counts and expressible share, reported separately.
• agreement: Cohen's kappa between the translator's class after the mechanical checks and the adjudicator's class, over the three classes, with n and the dispute list: rules whose translator or adjudicator call ended in error are excluded; computed over all census rules including controls.
• abideComparison: For abide's rules, agreement of the final class with abide's own type field (lint ~ expressible, model ~ partial or not); unenforceable and deferred reported as they are. The type field is read only by this comparison. Caution: the presence and shape of a rule's "Applies to" line correlates with abide's own type (its model rules carry a "Checked ..." sentence, its lint rules a scope only, unenforceable and deferred rules none), so the translator can partly infer the type; the agreement is reported with that caveat.
• lists: Downgrades with their failing check, engine-limit rules, and errors, each listed by ruleId.
• breakdown: pi-verdict's command (bash), path and question rules, each with its own counts and expressible share, reported apart; not part of the median.

The census: 188 rules (145 primary, 30 secondary, 13 controls), two calls each, 376 calls.

The bar that would refute it

Median expressible share below 25%: the premise is refuted, stage 2 is cancelled, and the census is the result.

The council verdict adopted by the founder on 2026-09-30, quoted verbatim, line break included. The stage-2 criteria and negatives are stated now and bind the stage-2 amendment.

Kill criteria (pre-registered, published either way): median expressible share < 25% → premise refuted, census is the result;
  cascade adds false rejects > 2 pts over plugin-alone, or avoids < 20% of Jev calls → refuted.

Discriminating negatives: sham floor must collapse to Jev-alone; floor must abstain on ≥95% of non-expressible rules;
  lint-floor tie is published as "any deterministic floor works".

Every outcome is published, including "premise refuted" and "translator uncalibrated".

Calls, spend and the clock

• Translator claude-opus-5-5, adjudicator claude-sonnet-5, Claude Code 2.1.280, effort high, 1 attempt per call.
• A fresh empty temporary directory outside any repository (no CLAUDE.md in its ancestors), which is also the child's TMPDIR.
• Built from an allowlist: HOME, PATH, USER, LOGNAME, LANG, LC_*, SHELL, TERM and TMPDIR; nothing else (no CLAUDE_*, CLAUDECODE, ODIN_*, *_KEY, *_TOKEN or *_SECRET). No fallback model. API-billing environment variables are refused.
• The runner asserts that the result's modelUsage has exactly one key and that it equals the pin; otherwise the call is an error (charged its cost, class error, counted as not).
• Before any counted call, one practice call per model asks what experiment, repository, rule set, label or prior conversation is in its context; an answer naming a pinned term fails the canary and stops the run.
• Calls run under subscription auth. total_cost_usd is then an API-equivalent figure, and the $100 cap applies to that figure, not to cash (the convention of EXP 005 and EXP 006).
• The client's --bare mode is not used: it forces API-key authentication, which this setup does not use.

claude -p --model <pin> --effort high --tools "" --strict-mcp-config --setting-sources project --no-session-persistence --system-prompt-file <pinned prompt file> --output-format json

• A cap of $100 on every metered call of EXP 007, with a census ceiling of $40; ledger experiments/blueprint-floor/spend-ledger.jsonl.
• Every metered paid call of EXP 007 (census translator and adjudicator, labellers, Jev, probes, canaries, dry runs) appends one line to the ledger, in dollars to 7 decimal places.
• A call whose cost is unknown is charged its upper bound; there is never a $0 line; an unpaid round gets no line.
• The census runner refuses a call when the spend so far plus the reserve would exceed the $40 census ceiling; exceeding the $100 cap is an operator decision.
• Session sub-agent labour (implementers, refuters) is not metered per call; it is disclosed with token counts and never presented as $0.
• The unknown-cost bound is three times the largest observed cost per role, at least $0.5000000.
• This record was built with no model call and no paid call: spend $0.0000000, and no ledger line.
• No counted call before the merge time of the odin-rnd pull request that adds this file (gh pr view <n> -R odin-labs-ai/odin-rnd --json mergedAt, UTC), and only while the site serves this record byte for byte.
• Every counted-call runner refuses unless the pre-registration on disk has the sha256 frozen at run start, which must equal the one published.

Stage 1 calls no Jev model. Two Claude calls per rule, a translator and an independent adjudicator, are metered against the experiment's $100 cap.

The pre-registration's own wording of the same point, quoted verbatim from the plan:

"$0 / no model" in COUNCIL-VERDICT STAGE 1 and STEER S5 = no Jev and no paid call before the stage-1 prereg is live; the census translator + adjudicator are METERED model calls under the $100 cap (council's cost line counts them as agent labour).

What this does not establish

Bracketed ids such as [m01] refer to rows of the engine matrix, each run through the real checker in the repository's tests.

• The target language is bce-engine 0.3.1's static vocabulary and nothing more: four constraint types for plugin rules. A newer engine or a different checker may decide more.
• The adapter maps non-diff inputs to files (a tool call to JSON and command text, a transcript to JSON lines and a final message, a document to a file). That mapping is a choice we made; another mapping could change what is expressible.
• The checker parses every read file as TypeScript, the .floor files included [m01, m03, m07, m15]. forbiddenDependency fires where that text parses as code: import, require and import() in plain prose [m01], a final message [m03], a command [m07] and the removed lines of .floor/diff.patch [m15]; not inside comments or string literals [m13, m14], so never from transcript.jsonl or tool-call.json values [m05, m06] or a quoted shell argument [m08], and not after an apostrophe earlier on a prose line [m02]; a type-only import never fires [m12]. forbiddenEgress fires on fetch, http.request, request(), axios.get, new Client() and got with a literal host [m18, m19, m20, m21, m22, m23], in prose too [m27], not on curl, lookalike hosts, string literals or non-literal hosts [m24, m26, m28, m38], and takes no file scope [m27]. A constraint that should judge only what a change adds must be scoped to post-patch src/** or .floor/added/** [m16, m17]. For tool calls, transcripts and documents, forbiddenPattern and forbiddenFile remain the precise vocabulary.
• A partial floor still needs a model for its residual; expressible is the only class that removes the model for that rule.
• The translator is itself a model. The adjudicator and the mechanical checks guard it, but teeth is self-consistency (the translator writes both the constraint and its probes), not proof over every input.
• The dispute rule can only lower a class, which biases the census toward the kill criterion; the median before disputes is reported beside it.
• Some plugins have few rules (jev-pref has 4), so their shares move in large steps.
• Which items count as rules is our application of the pinned inclusion test. At the pin jev-belay has no rule that decides by itself (its four questions feed one combined decision), so its primary stratum is empty and the median runs over the other plugins.
• The positive controls are shown the module-graph contract (their materialisation differs), so a translator could tell them apart from plugin rules; the controls are outside every median.
• A line checker cannot join a tool's name to its path argument or resolve the working directory and real path, so pi-verdict's 8 write-only path rules are capped at partial mechanically: an expressible answer (no residual) drops to not, and they reach partial only when the translator answers partial with a residual. They can never be expressible, so the cap moves the partial-as-0.5 sensitivity figure, not the strict median; the adjudicator is told the condition in the rule's 'Applies to' line.
• The positive controls run on the module-graph path, so they do not calibrate the plugin-surface diff path the plugin rules take.
• Blinding hides names, not families: input kind and regex-versus-prose correlate with the plugin (limpet's rules are all stopTranscript; toolCall regexes come only from pi-verdict and jev-engineering), so a translator can guess a rule's family.
• One rule's verbatim text names its own plugin (abide/key-write-targets); the blindness check excludes a rule's own text, which is shown verbatim by design.
• The negative controls were written by the experimenters; the positive controls come from EXP 005, whose rules were written for bce.
• Case folding uses JavaScript's toLowerCase (Unicode default) and the source regexes are JavaScript /i (pi-verdict); the two fold a few special cases differently (e.g. the Turkish dotted I, the German sharp s), so a rare input could be matched by one and not the other.
• Each line is matched on its own, so a construct spread over several lines (a multi-line signature, a string split across lines) cannot be matched as one [m31].
• The checker matches one line at a time [m31], while the source regexes (and jev-engineering's re.search) run over the whole command; a multi-line command can be matched differently.
• jev-engineering's patterns are Python regular expressions and the checker compiles JavaScript ones; where the dialects differ, only the mechanical checks on the translator's own probes can catch it, and only when a probe exercises the difference.
• Probe patches can only add files, because the contract lists the base tree's files but not their contents.
• One translator model, one adjudicator model, one attempt per rule and one client version.
• Upstream plugin labels, where stage 2 uses them, are written by each plugin's authors and are not independent.
• pi-verdict's command rules and path rules are also reported apart; that breakdown does not change the median.
• The "Applies to" line's presence and shape correlate with abide's own type (model rules carry a "Checked ..." sentence, lint rules a scope only, unenforceable and deferred none); the abide comparison is reported with that caveat.

Sources

• awesome-jev-tools: The list the eight plugins were taken from.
• bce (blueprint-conformance/bce): The checker whose 0.3.1 release is the target vocabulary.
• bce-engine 0.3.1 on npm: The released package this repository pins.
• EXP 005, Jev as a fast gate: The experiment whose linter finding motivates this one, and whose base tree and controls are reused.

You've hit your monthly spend limit · raise it at claude.ai/settings/usage?from=cc_cli_limit_message · your weekly limit resets Oct 9 at 3am (Europe/Amsterdam)

Provenance

This page is rendered from preregistration.json, the committed record at experiments/blueprint-floor/preregistration.json, whose sha256 is ee56929ab38de831d618a41b9a2f359d814fc01849d273060e590669e94c9edb. The build publishes that file byte for byte, and a repository test re-renders this page from it and fails if they differ. A validator rebuilds every file fact in the record from the files on disk.

No census call has been made. The results, when they exist, will be judged against this record as published, and reported as they come out, including if the premise is refuted. Measured — premise refuted, 7 Oct 2026: see the results.