clearotron 0.3.2-beta.7 → 0.3.2-beta.9

package/driver/skills/{prelim-variants → clearance-variants}/transliteration-scripts.md

@@ -1,6 +1,6 @@
 # Transliteration scripts — reference
 
-Non-Latin scripts to consider when the jurisdiction scope is multi-region or worldwide. Generated by Claude directly during Step 5 of `prelim-variants`. Verification is a human step when transliterations produce hits.
+Non-Latin scripts to consider when the jurisdiction scope is multi-region or worldwide. Generated by Claude directly during Step 5 of `clearance-variants`. Verification is a human step when transliterations produce hits.
 
 ## When to generate
 
@@ -24,7 +24,7 @@ For specific country lists, the orchestrator passes the jurisdiction list throug
 - **Meaning example (a SET, never one guess — see the rule below):** "Lumengarde" → 永光 · 长明 · 恒光 (everyday "everlasting light" first, then literal/adjacent) — derive the set from the concept, do not template these characters
 - **When to use phonetic:** when the brand is itself a coined / non-translatable word (Nike, Aureon)
 - **When to use meaning:** when the brand has clear English semantic content (Apple, Lumengarde)
-- **Meaning = the everyday-word-first equivalence SET, never one technical guess** (this *supersedes* the earlier "specific concept only / drop the everyday word" rule). Generate the small deterministic SET of natural-language renderings of the concept, **common-usage first**, then technical, then adjacent — e.g. COLORA → CN **色彩, 颜色** (everyday "colour") · **色度** (technical "chromaticity") · **彩度 / 色相** (adjacent) — tagging each member's register (everyday | technical | adjacent). **Never drop the everyday word because it looks saturated.** A saturated everyday-word count is the signal to *narrow to the field*, not to abandon the word: the register layer scopes the saturated token to the matter's filed in-scope Nice classes (a structured class × region filter — the token stays the substring predicate; goods-vocabulary words are never ANDed into the search text) and enumerates that (see [`prelim-register` register-recipes.md](../prelim-register/register-recipes.md) saturated-field handling). The everyday word is exactly what local registrants file and what the reviewing lawyer searches, so a common word is never grounds to skip it — or to drop a live in-class hit behind it. (Dropping the everyday word dodges the saturation noise but discards the real conflict hiding in the crowd.)
+- **Meaning = the everyday-word-first equivalence SET, never one technical guess** (this *supersedes* the earlier "specific concept only / drop the everyday word" rule). Generate the small deterministic SET of natural-language renderings of the concept, **common-usage first**, then technical, then adjacent — e.g. COLORA → CN **色彩, 颜色** (everyday "colour") · **色度** (technical "chromaticity") · **彩度 / 色相** (adjacent) — tagging each member's register (everyday | technical | adjacent). **Never drop the everyday word because it looks saturated.** A saturated everyday-word count is the signal to *narrow to the field*, not to abandon the word: the register layer scopes the saturated token to the matter's filed in-scope Nice classes (a structured class × region filter — the token stays the substring predicate; goods-vocabulary words are never ANDed into the search text) and enumerates that (see [`clearance-register` register-recipes.md](../clearance-register/register-recipes.md) saturated-field handling). The everyday word is exactly what local registrants file and what the reviewing lawyer searches, so a common word is never grounds to skip it — or to drop a live in-class hit behind it. (Dropping the everyday word dodges the saturation noise but discards the real conflict hiding in the crowd.)
 - **Risk:** Chinese mark registrations sometimes file BOTH. Always generate both for high-tier matters
 - **Verification:** Claude generates plausibly but the reviewing lawyer or local counsel should confirm before any output reaches the client
 
@@ -88,7 +88,7 @@ For specific country lists, the orchestrator passes the jurisdiction list throug
 
 1. **One PHONETIC transliteration per script per mark element.** Don't generate exhaustive phonetic variant sets within a single script — pick the most likely. (Meaning translations are the exception — see 2b.)
 2. **For Chinese: generate phonetic AND meaning translations** for any mark with clear semantic content. One entry (phonetic only) for coined marks.
-2b. **Meaning translation = the everyday-word-first equivalence SET (it reverses the older "specific concept, drop the everyday word" rule).** Emit the small deterministic set common-usage first, then technical, then adjacent — one manifest row per member, each tagged with its register (everyday | technical | adjacent). **Never drop the everyday word for looking saturated:** saturation is handled downstream by class-scoped enumeration in the register layer ([register-recipes.md](../prelim-register/register-recipes.md)) — the token narrowed to the filed in-scope Nice classes, not by ANDing goods words into the query and not by abandoning the word. A common everyday word is never grounds to skip a meaning rendering or to drop a live in-class hit behind it.
+2b. **Meaning translation = the everyday-word-first equivalence SET (it reverses the older "specific concept, drop the everyday word" rule).** Emit the small deterministic set common-usage first, then technical, then adjacent — one manifest row per member, each tagged with its register (everyday | technical | adjacent). **Never drop the everyday word for looking saturated:** saturation is handled downstream by class-scoped enumeration in the register layer ([register-recipes.md](../clearance-register/register-recipes.md)) — the token narrowed to the filed in-scope Nice classes, not by ANDing goods words into the query and not by abandoning the word. A common everyday word is never grounds to skip a meaning rendering or to drop a live in-class hit behind it.
 3. **Tag the variant row** in the Variants table with the category `translit-<script>` (e.g. `translit-cjk-japanese`, `translit-arabic`) and a rationale explaining whether it's phonetic or meaning-based. **For Chinese the category token MUST carry the sense** — `translit-zh-meaning` for a meaning translation, `translit-zh-phonetic` for a phonetic one — because the downstream saturation / class-scoped-enumeration gates key on the `translit-*-meaning` tag; a meaning row tagged only `translit-zh` would silently skip the field-narrowing and revert to the old drop-on-saturation behaviour.
 4. **Flag for verification** by putting `✅` in the Variants table's `Verify?` column for every transliteration row. The downstream skill marks any HIT against these variants as needing reviewer sign-off before inclusion in the deliverable.
 5. **Every non-Latin row carries its ROMANISATION, on its own row** — `"romanization"` in the manifest's structured sibling, and the Latin form in parentheses in the prose row's rationale. This is not decoration: **half the registers we search hold a non-Latin filing ONLY under its transliteration and cannot answer the characters at all.** A row without one is a term that can be searched on some providers and on no others — and the one that refuses it is right to, because searching the characters there returns 0 with no error and reads as a clean. (A clearance run on 2026-07-29 compiled thirteen native-script terms with no romanisation; every one was refused and the transliteration axis produced no coverage.) Rules: plain ASCII letters and digits, syllable-separated by single spaces, no tone marks and no diacritics (华威豹 → `HUA WEI BAO`, ティキスラッシュ → `TIKI SURASSHU`, 티키 슬러시 → `TIKI SEULLEOSI`, Тики Слаш → `TIKI SLASH`); the romanisation goes on the row whose own value it romanises, never on a neighbour and never as a row of its own; and a value that is already Latin never gets one. The driver puts BOTH forms on the search entry and each provider expresses the one its index holds — you state the pair, you never choose which gets searched.
@@ -97,7 +97,7 @@ For specific country lists, the orchestrator passes the jurisdiction list throug
 
 Skip transliteration for:
 - Single-jurisdiction searches in a Latin-script country
-- Internal sanity-check / brainstorm runs (the standalone mode of `prelim-variants`)
+- Internal sanity-check / brainstorm runs (the standalone mode of `clearance-variants`)
 - Matters where the client explicitly excludes non-Latin markets
 
 When in doubt: generate them. Cost is one extra dozen rows in the variant manifest, but missing a Japanese katakana hit on a global launch is the kind of miss that gets noticed post-launch.
@@ -106,7 +106,7 @@ When in doubt: generate them. Cost is one extra dozen rows in the variant manife
 
 - Trade name vs trademark distinctions in non-Latin markets (handled by local counsel)
 - Honorific / corporate-suffix conventions (Pvt Ltd in India, AG in German, GmbH in German, K.K. in Japan)
-- Right-to-left text rendering for Arabic in the deliverable Excel — output handling is in `prelim-search`'s Excel writer
+- Right-to-left text rendering for Arabic in the deliverable Excel — output handling is in `clearance-search`'s Excel writer
 - Native-language semantic equivalents that aren't transliterations (e.g., the Chinese meaning SET 永光 · 长明 is a TRANSLATION, not a transliteration — but we include both under this file's umbrella for practical reasons)
 
 ## Open questions for the reviewing lawyer

package/driver/skills/frame-diff/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: frame-diff
-description: The omission detector for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator/driver** once the register sweeps have landed and before placement runs — do not call directly. Diffs the blind (frame-starved) re-derivation against what the run ACTUALLY scoped and searched, and emits structured reopen directives — one per variant / field / source omission worth acting on, each carrying the observation that should reopen it and a severity. The driver acts on the directives (a targeted supplemental sweep, then re-digest) and on the dominant-element gap (it can block a clean finding). The decision is the driver's; you supply the structured diff.
+description: The omission detector for the v3 preliminary trademark search workflow. **Invoked exclusively by the `clearance-search` orchestrator/driver** once the register sweeps have landed and before placement runs — do not call directly. Diffs the blind (frame-starved) re-derivation against what the run ACTUALLY scoped and searched, and emits structured reopen directives — one per variant / field / source omission worth acting on, each carrying the observation that should reopen it and a severity. The driver acts on the directives (a targeted supplemental sweep, then re-digest) and on the dominant-element gap (it can block a clean finding). The decision is the driver's; you supply the structured diff.
 ---
 
 ## Purpose

package/driver/skills/knockout-assess/SKILL.md

@@ -36,7 +36,7 @@ there is no other value: a band that needs sharpening is the band above it, stat
    This ordered an expectation sentence ("moderate volume of filings expected") and forbade a register
    conclusion, because this seat could not see the register lane. It can: the run's fetched records are
    passed to you when they exist. The replacement is RF-15 v3 in
-   `../prelim-search/firm-wide-reasoning.md` — estimation becomes one of three confirmation states once
+   `../clearance-search/firm-wide-reasoning.md` — estimation becomes one of three confirmation states once
    the register actually ran. Where it did not run, the estimate is still the honest answer and RF-15
    says so.
    *The number is kept and not reused* — see calibration rule 4 for why.
@@ -51,7 +51,7 @@ there is no other value: a band that needs sharpening is the band above it, stat
 2. **Crowded field = diluted risk, not amplified.** Many small, non-enforcing players means any one
    player's enforcement power is weaker — a crowded field typically caps at the middle band. The
    gating precondition, and what a crowd may and may not do to a band, are in
-   `../prelim-search/firm-wide-reasoning.md` → *Volume is not a risk multiplier*; read it there rather
+   `../clearance-search/firm-wide-reasoning.md` → *Volume is not a risk multiplier*; read it there rather
    than from a summary here.
    *(Its closing sentence — "the top bands are reserved for dominant, well-resourced,
    known-to-enforce rights holders" — is RETIRED. That is owner size and fame driving a band, which the
@@ -78,7 +78,7 @@ there is no other value: a band that needs sharpening is the band above it, stat
    This rule ordered the pending-register caveat on *every* summary, unconditionally. When the register
    ran and surfaced live filings, that sentence tells a client its ratings are common-law only while the
    same run holds the filings — which is what shipped. The replacement is RF-10 v3 in
-   `../prelim-search/firm-wide-reasoning.md`: when register analysis ran AND surfaced live filings, drop
+   `../clearance-search/firm-wide-reasoning.md`: when register analysis ran AND surfaced live filings, drop
    the caveat and cite the register evidence directly; otherwise it stands.
    *The number is kept and not reused.* `verify-knockout.mjs` and two other files address these rules by
    number, so renumbering would silently repoint five live references at the wrong rule.5. **Dispute-type notation only when the customer's framework defines it** (e.g. an A–E / dispute
@@ -122,9 +122,8 @@ each mark, and — when the register component is configured — two counts per
 identical to the name, and how many contain it. That is the whole evidence base. Everything below
 follows from writing only what it supports.
 
-1. **A survivor is never "clear".** A mark this screen did not knock out is *not knocked out at the
-   configured depth, and proceeds to clearance*. Never "clear", "clean", "no conflicts found", "clear
-   to proceed". The screen ending without a blocker is a result about the screen, not about the mark.
+1. **A survivor is never "clear".** Never "clear", "clean", "no conflicts found", "clear to proceed".
+   The screen ending without a blocker is a result about the screen, not about the mark.
 2. **An absence claim may not exceed what was searched.** Say where you looked and what came back
    empty there — "no exact-name energy drink was identified in the supplement and grocery
    marketplaces screened" is supportable; "there is no conflicting use" is not. `negatives[]` is
@@ -236,7 +235,11 @@ A note that restates a finding already on the page is not a note. Cut it.
 
 Each mark's report is delivered on its own, and `assessment` is the first thing its reader meets —
 before any table. Write it for a client who ordered this one name and nothing else: what the name is,
-what the landscape around it looks like, what drives the rating, what to do with that.
+what the landscape around it looks like, what drives the rating.
+
+**No recommendation, and no next step.** Never say what to do with the name, whether it advances, or
+what happens next — not under a heading of your own, and not as a closing line. The findings and the
+rating are the whole of this read; the report's own caveat says what the screen is.
 
 **It names THIS mark and no other.** A sibling's name here is another client's mark on this client's
 page. The cross-mark reading is `chunkSummary`, and it has its own page.

package/driver/skills/matter-frame/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: matter-frame
-description: Pre-flight reasoning step for trademark searches. Produces a structured matter-context.md naming the client + sector + customer base + channels of trade + materially-matters jurisdictions + off-field sectors + watchlist-owner seeds — before any search runs. Invoke at Phase 0 of prelim-search or a full clearance-search. The downstream workflow consumes this artifact at every step (variants generation, register sweep, placement inquiry, narrative refutation) so the matter's commercial context stops being implicit and starts being load-bearing.
+description: Pre-flight reasoning step for trademark searches. Produces a structured matter-context.md naming the client + sector + customer base + channels of trade + materially-matters jurisdictions + off-field sectors + watchlist-owner seeds — before any search runs. Invoke at Phase 0 of clearance-search or a full clearance-search. The downstream workflow consumes this artifact at every step (variants generation, register sweep, placement inquiry, narrative refutation) so the matter's commercial context stops being implicit and starts being load-bearing.
 ---
 
 ## Purpose
@@ -13,7 +13,7 @@ This is structured inquiry, not rule application. You are reasoning, not classif
 
 Phase 0 of any trademark search workflow, after the request has been parsed (mark, classes, manner of use, client, requester) and before variants generation. One Opus inline call, no tool budget, no spawned workers.
 
-Invoked from `prelim-search` (orchestrator) at Phase 0, before `prelim-variants`. Reusable by a future clearance-search at the equivalent step.
+Invoked from `clearance-search` (orchestrator) at Phase 0, before `clearance-variants`. Reusable by a future clearance-search at the equivalent step.
 
 ## Model
 
@@ -84,7 +84,7 @@ Two scopes live here, and the doctrine is **narrow at citation, never silently a
 - **Excluded.** Territories you considered and set aside — neither instructed, nor brand-signalled, nor a major on a worldwide matter — name each, the reason, and a **reopen trigger** (a right or signal pointing there surfaces). A hit effective ONLY outside the scope set is out of *citation* scope (drop it from findings); but a market the brand actually signals belongs in the SEARCH set, not here.
 - **Primary vs only.** If the instruction names territories of "primary" / "first" interest WITHOUT "only", treat the named ones as the citation core but **let the search lean wide** to the majors / brand-signalled markets (the "primary" wording signals more may matter), and **record the assumption** — a one-line `Scope assumption: <text>`. (A single clarifying question is acceptable instead; the recorded default never blocks the run.)
 - **Send the structured scope as FIELDS** (the downstream sweep + `frame-diff` consume it): `scope_jurisdictions` — the SEARCH set as short codes (EU / US / CN / CH …), including the majors / signalled markets when leaning wide and any `in-scope-by-reach` ones; `excluded_jurisdictions` when any were set aside; and `scope_basis` as `instructed | worldwide | inferred`, so synthesis knows whether a narrowing was disclosed. The driver renders the lines.
-- This set drives the per-jurisdiction sub-queries AND the major-jurisdiction floor in `prelim-register`; `frame-diff` checks it both ways (a citation outside the scope set = over-reach; a material market in the set left unsearched = under-coverage — disclosed + clamped, never a silent clean).
+- This set drives the per-jurisdiction sub-queries AND the major-jurisdiction floor in `clearance-register`; `frame-diff` checks it both ways (a citation outside the scope set = over-reach; a material market in the set left unsearched = under-coverage — disclosed + clamped, never a silent clean).
 
 *Worked illustrations:*
 *— Instructed "Switzerland and the EU, only" → search CH + the EUTM/EU layer (+ any Madrid designation reaching them); majors beyond (CN/JP/US/UK) are out of scope — an honored narrow instruction (`Scope basis: instructed`).*

package/driver/skills/narrative-refutation/SKILL.md

@@ -15,9 +15,9 @@ This is structured refutation, not approval. Your job is to find what's wrong, n
 
 ## When invoked
 
-Spawned between Step 4 synthesis (narrative composition) and Phase 3 delivery. Different session, clean context. Reads multiple inputs, writes one output. Phase 3 consumes the verdict — BLOCKING drives one corrective re-synthesis; the report is then **always delivered**, with any unresolved reviewer concerns surfaced to the reviewing lawyer as open questions (the driver never withholds — see `prelim-search` Phase 3).
+Spawned between Step 4 synthesis (narrative composition) and Phase 3 delivery. Different session, clean context. Reads multiple inputs, writes one output. Phase 3 consumes the verdict — BLOCKING drives one corrective re-synthesis; the report is then **always delivered**, with any unresolved reviewer concerns surfaced to the reviewing lawyer as open questions (the driver never withholds — see `clearance-search` Phase 3).
 
-The orchestrator (`prelim-search`) spawns this worker at the equivalent step. Reusable by a future clearance-search at the equivalent step.
+The orchestrator (`clearance-search`) spawns this worker at the equivalent step. Reusable by a future clearance-search at the equivalent step.
 
 ## Model
 
@@ -28,11 +28,11 @@ The driver dispatches this as a stage with its own context and a 900-second wall
 ## Inputs you receive
 
 - The orchestrator's narrative (the client-facing email body / report content, passed inline in the spawn task)
-- `matter-context.md` at `studio/prelim-search/<slug>/<date>/matter-context.md` (the strategic framing from `matter-frame`)
-- `register-findings.md` at `studio/prelim-search/<slug>/<date>/register-findings.md` (the digest output with the digest's own candidate ordering)
-- `common-law-findings.md` at `studio/prelim-search/<slug>/<date>/common-law-findings.md` (the common-law digest)
-- `placement-recommendations.md` at `studio/prelim-search/<slug>/<date>/placement-recommendations.md` (the per-candidate placements from `placement-inquiry`) and its structured mirror `placements.json` beside it (`{mark, owner, jurisdiction, records, tier, reason}` per candidate; the md carries the rulings tail)
-- `variant-manifest.md` at `studio/prelim-search/<slug>/<date>/variant-manifest.md` (for completeness checks if relevant)
+- `matter-context.md` at `studio/clearance-search/<slug>/<date>/matter-context.md` (the strategic framing from `matter-frame`)
+- `register-findings.md` at `studio/clearance-search/<slug>/<date>/register-findings.md` (the digest output with the digest's own candidate ordering)
+- `common-law-findings.md` at `studio/clearance-search/<slug>/<date>/common-law-findings.md` (the common-law digest)
+- `placement-recommendations.md` at `studio/clearance-search/<slug>/<date>/placement-recommendations.md` (the per-candidate placements from `placement-inquiry`) and its structured mirror `placements.json` beside it (`{mark, owner, jurisdiction, records, tier, reason}` per candidate; the md carries the rulings tail)
+- `variant-manifest.md` at `studio/clearance-search/<slug>/<date>/variant-manifest.md` (for completeness checks if relevant)
 
 ## Output — one call, not a file
 
@@ -119,7 +119,7 @@ and challenge it:
   element (or one materially like it) in a *comparable* situation — not a win on a different element, not a default
   against an obvious copycat. A risk-raising fact carrying no one-line "why this bears on this conflict", or opposed
   signals (e.g. enforcer **and** commercial partner) left listed in parallel rather than reconciled → **FLAG
-  (probative-grading)** — per `prelim-search/firm-wide-reasoning.md` (*Mitigation factors*), such facts adjust the practical read, they do not raise the level.
+  (probative-grading)** — per `clearance-search/firm-wide-reasoning.md` (*Mitigation factors*), such facts adjust the practical read, they do not raise the level.
 
 These are *questions you must be able to answer from the facts*, not consistency checks against the upstream
 files. If the headline cannot be defended against them, it blocks.
@@ -282,7 +282,7 @@ This is the check for what was *never searched* — the gap a narrative-vs-files
 
 For any candidate the narrative escalates above a "distinguished by its own distinctive matter" dominant-element read (a house mark / distinctive prefix):
 - What theory is doing the escalation? It must be a **consumer-confusion** theory (e.g. evidence of actual confusion).
-- If the escalation rests on optics / PR / partner-sensitivity / audience overlap / owner size alone, **FLAG (optics-escalation)** — per `prelim-search/firm-wide-reasoning.md` (*Elevation factors*) the legal level is the confusion read; PR/relationship factors annotate, they do not raise the level. Suggest: hold the distinguished read and move the concern to the PR/reputational annotation.
+- If the escalation rests on optics / PR / partner-sensitivity / audience overlap / owner size alone, **FLAG (optics-escalation)** — per `clearance-search/firm-wide-reasoning.md` (*Elevation factors*) the legal level is the confusion read; PR/relationship factors annotate, they do not raise the level. Suggest: hold the distinguished read and move the concern to the PR/reputational annotation.
 
 ### Variant-imagination audit (backstop — did the search even look for the obvious neighbours?)
 

package/driver/skills/placement-inquiry/SKILL.md

@@ -19,7 +19,7 @@ You read the **complete named band** the funnel handed up; the funnel decided *n
 
 ## When invoked
 
-After register-unit workers and common-law workers have returned their findings (Phase 2 Step 2B end), BEFORE the digest worker (`prelim-register` MODE B) spawns to tier candidates. One Opus call (inline by the orchestrator), reads matter-context.md + the complete named band (through the band tools) + the common-law findings.
+After register-unit workers and common-law workers have returned their findings (Phase 2 Step 2B end), BEFORE the digest worker (`clearance-register` MODE B) spawns to tier candidates. One Opus call (inline by the orchestrator), reads matter-context.md + the complete named band (through the band tools) + the common-law findings.
 
 ## Model
 
@@ -27,19 +27,19 @@ Inherits the orchestrator's tier when invoked inline. No `sessions_spawn` — th
 
 ## Inputs you receive
 
-- `matter-context.md` from `matter-frame` at `studio/prelim-search/<slug>/<date>/matter-context.md` (the strategic foundation — read it once, reference it throughout)
+- `matter-context.md` from `matter-frame` at `studio/clearance-search/<slug>/<date>/matter-context.md` (the strategic foundation — read it once, reference it throughout)
 - **The complete named band** — read through the **band tools** (every call lands in the run's reading audit; never slice band files with shell). `band_shape` first: the deterministic shape of the complete merged band — totals, mechanical similarity tiers, **THE FLOORS** (every live in-class identical/near-identical record, listed individually and unconditionally — **every floor row must come back on your form, by record id.** Either you place it, or you select it with `tier: "out-of-scope-filtered"` and one line in `reason` saying why it is not a candidate. Discussing a floor in your prose is NOT accounting for it: the row is what the driver can check, and a floor you leave off the form is recorded as unanswered whatever the prose says. This is the one duty with no cap — see **Length target**, which bounds the general band and not this), census, owner concentrations, crowd descriptors, blind spots. A floors-heavy shape is served in PARTS (the response labels itself part N/M and names the next call) — read every part; a partial shape is never the shape. Then `band_lookup` / `band_record` for the records your inquiry needs. This is the funnel's real output, lifted across the firewall:
   - **enumerated records** — every named record the funnel paged to completion, each carrying `record_id, mark_text, classes, status, owner_name, owner_country, application_date, registration_date, expiry_date, jurisdictions, screen_verdict` (+ `_query` provenance). Apply the relevance / off-field gate over **this complete set** (work through the shape's totals slice by slice) — nothing was pre-sampled, so your gate is the *only* gate.
   - **`incomplete` crowd descriptors** — a query the funnel could NOT enumerate (genuinely too large, provider cap, budget): `query, total_hits, fetched, reason`. These are NOT findings and NOT clean negatives — they are signals you must rule on (cleared / material-gap; see "Crowd-descriptor materiality" below). They ride along on matching lookups too, so a counted-only zone can never read as a clean.
   - The unit's compact prose digest (`register-units/<axis>.md`) still exists for the audit trail; the **band is the material you judge.** Where they disagree, the band wins — it is the complete record, the prose is a summary.
-- The common-law-findings file at `studio/prelim-search/<slug>/<date>/common-law-findings.md` (common-law candidate inventory)
+- The common-law-findings file at `studio/clearance-search/<slug>/<date>/common-law-findings.md` (common-law candidate inventory)
 - Any prior `placement-recommendations.md` from earlier rounds (for re-runs after a skeptic-flagged re-spawn)
 
 ## Output
 
 TWO files.
 
-**1. The markdown file** `studio/prelim-search/<slug>/<date>/placement-recommendations.md`. Use these section headings, in this order: **Band reconciliation** (the expectation-vs-band check), the four placement tiers (**Headline candidates**, **Sheet 2 / register watch**, **Watchlist annex**, **Out-of-scope / filtered**), **Disagreements / flags surfaced to downstream**, **Coverage rulings & open questions** (the per-crowd-descriptor cleared/material-gap rulings that feed synthesis `coverage_judgment`), and **Open questions for the client / reviewer** (genuine open judgment that ships).
+**1. The markdown file** `studio/clearance-search/<slug>/<date>/placement-recommendations.md`. Use these section headings, in this order: **Band reconciliation** (the expectation-vs-band check), the four placement tiers (**Headline candidates**, **Sheet 2 / register watch**, **Watchlist annex**, **Out-of-scope / filtered**), **Disagreements / flags surfaced to downstream**, **Coverage rulings & open questions** (the per-crowd-descriptor cleared/material-gap rulings that feed synthesis `coverage_judgment`), and **Open questions for the client / reviewer** (genuine open judgment that ships).
 
 **Section anchor — copy it verbatim.** Directly under the FIRST of the four placement-tier headings,
 emit this line exactly as written, on its own line:
@@ -55,7 +55,7 @@ no reader ever sees it.
 **Word the headings however reads best.** The anchor is the contract; the heading text is yours. The
 order above is still the order to write them in, but you will not be failed for choosing other words.
 
-**2. The structured mirror** `studio/prelim-search/<slug>/<date>/placements.json` — the four tier sections as data: `{"schema_version":1,"placements":[...]}`, ONE object per placed candidate, keys EXACTLY `{"mark","owner","jurisdiction","records","tier","reason"}` plus the optional `"borderline"`:
+**2. The structured mirror** `studio/clearance-search/<slug>/<date>/placements.json` — the four tier sections as data: `{"schema_version":1,"placements":[...]}`, ONE object per placed candidate, keys EXACTLY `{"mark","owner","jurisdiction","records","tier","reason"}` plus the optional `"borderline"`:
 
 - `mark` / `owner` — verbatim as in your md entry (downstream joins on mark + owner + jurisdiction)
 - `jurisdiction` — the office/territory; `""` where none applies

package/driver/stage-context.mjs

@@ -219,7 +219,7 @@ const UNDECLARED = {
 // because this list is a fact about gates rather than a convenience copy of `_driver/`.
 export const VALIDATOR_SIDECARS = {
   "matter-frame": ["instructed-scope.json", "stage-contracts.json"],
-  "prelim-variants": ["instructed-scope.json", "stage-contracts.json"],
+  "clearance-variants": ["instructed-scope.json", "stage-contracts.json"],
   "register-unit": ["instructed-scope.json", "register-plan.json"],
   "common-law": ["grid-spec.json", "profile.json"],
   // — the DRIVER'S copy of the placement form. Without it in the sandbox an experiment arm would

package/driver/stages-knockout.mjs

@@ -289,14 +289,14 @@ export const KO_STAGES = {
     // the guards that read `STAGES.skillReads` walk the clearance lane's table, not this one — so the
     // effective read is the `reads([...])` call in the message and nothing checks that the two agree.
     // They are edited together and the asymmetry is written down rather than left to be discovered.
-    skillReads: ["skills/knockout-assess/SKILL.md", "skills/prelim-search/firm-wide-reasoning.md"],
+    skillReads: ["skills/knockout-assess/SKILL.md", "skills/clearance-search/firm-wide-reasoning.md"],
     // out/validate are per-CHUNK; the merged knockout-findings.json is validated separately in code.
     out: (K, chunkNo) => K.assessChunk(chunkNo),
     validate: koValidators.knockoutAssessChunk,
     message: ({ K, chunkNo, chunkMarks, chunkTotal, framework, frameworkPath, probeNote }) => lines(
       // The deck path comes from ctx (attachKnockoutFramework resolves it once, on the fresh and the
       // resume path both) — never recomputed here, because "which deck" is one decision.
-      reads(["skills/knockout-assess/SKILL.md", frameworkPath, "skills/prelim-search/firm-wide-reasoning.md"].filter(Boolean)),
+      reads(["skills/knockout-assess/SKILL.md", frameworkPath, "skills/clearance-search/firm-wide-reasoning.md"].filter(Boolean)),
       `You are rating chunk ${chunkNo + 1}/${chunkTotal} of a KNOCKOUT batch — triage, not clearance.`,
       `Rate ONLY these marks (one entry each, names verbatim): ${chunkMarks.map((m) => m.name).join(" · ")}.`,
       `The batch plan (context framing, classes, priorities): ${K.plan}`,
@@ -518,7 +518,7 @@ export const KO_STAGES = {
     // DECLARATIVE ONLY on this lane, exactly as the assess stage records: nothing in koStage reads
     // `skillReads`, and the effective read is the `reads([...])` call in the message below. The two are
     // edited together and the asymmetry is written down rather than left to be discovered.
-    skillReads: ["skills/prelim-search/report-prose.md"],
+    skillReads: ["skills/clearance-search/report-prose.md"],
     out: (K) => K.review,
     validate: validateKnockoutReviewFile,
     // ── THE MESSAGE PROMISES A TABLE ONLY WHEN IT HAS ONE ──────────────────────────
@@ -531,7 +531,7 @@ export const KO_STAGES = {
     // exists to stop. The driver does not dispatch on an empty measurement; the branch is here because
     // "it cannot happen" is not a property a message should depend on.
     message: ({ K, evidenceLines = [], exclusionNote = "" }) => lines(
-      reads(["skills/prelim-search/report-prose.md"]),
+      reads(["skills/clearance-search/report-prose.md"]),
       `You are the REVIEWING PASS on a knockout screen. The batch is already rated and nothing about that rating is yours to change. Your job is the words.`,
       `THE RULE. A line a reader meets before opening anything carries no legal or engine vocabulary and no sentence longer than 25 words. Inside a fold the lawyer's words are allowed where a plain one would lose precision; on a default-visible line they are not. The reader here is the client of the lawyer who ordered this screen, and they read the same page.`,
       `The rated record: ${K.findings}. Read it — the lines named below are quoted from it and you are rewriting them in place.`,