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

package/driver/skills/{prelim-search → clearance-search}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: prelim-search
-description: Orchestrator for preliminary trademark search requests with register coverage. Invoke when a forwarded email asks for a preliminary trademark search (common-law and register layers, run in parallel). Coordinates `prelim-variants` → `prelim-common-law` + `prelim-register`, then synthesises into client-ready HTML email drafts plus unified audit-trail Excel deliverables for the reviewing lawyer to evaluate. The paid register vendor is whichever sits in the runtime tool surface (the neutral `register_*` surface — one vendor at a time, selected by REGISTER_PROVIDER); free EUIPO (`euipo_*`) and the case-law citation tools (`courtlistener__*` / `legaldatahunter__*`) sit alongside it for EU cross-checks and precedent grounding.
+name: clearance-search
+description: Orchestrator for preliminary trademark search requests with register coverage. Invoke when a forwarded email asks for a preliminary trademark search (common-law and register layers, run in parallel). Coordinates `clearance-variants` → `clearance-common-law` + `clearance-register`, then synthesises into client-ready HTML email drafts plus unified audit-trail Excel deliverables for the reviewing lawyer to evaluate. The paid register vendor is whichever sits in the runtime tool surface (the neutral `register_*` surface — one vendor at a time, selected by REGISTER_PROVIDER); free EUIPO (`euipo_*`) and the case-law citation tools (`courtlistener__*` / `legaldatahunter__*`) sit alongside it for EU cross-checks and precedent grounding.
 ---
 
 ## Contents
@@ -44,11 +44,11 @@ Top-level reusable judgment skills (the three new "touchpoints" — see Phase 2
 - `narrative-refutation` — runs as a **spawned isolated worker** at Phase 2 (between Step 4 synthesis and Phase 3): refutes the narrative against the underlying files; produces `senior-eye-review.md`. Its verdict drives the corrective pass before Phase 3. Reusable.
 
 Sub-skills used during the workflow:
-- `prelim-variants` — runs **inline** in this orchestrator session: shared strategy + variant
+- `clearance-variants` — runs **inline** in this orchestrator session: shared strategy + variant
   generation (produces the variant manifest, consumes `matter-context.md`). Cheap, no bulk payloads — stays in context.
-- `prelim-common-law` — runs as a **spawned isolated worker** (Phase 2 Step 2): Perplexity
+- `clearance-common-law` — runs as a **spawned isolated worker** (Phase 2 Step 2): Perplexity
   execution against the manifest (produces the common-law findings file with `developer_of_record` / `publisher_of_record` extracted per game-title finding).
-- `prelim-register` — runs as a **spawned isolated worker** (Phase 2 Step 2): register-search
+- `clearance-register` — runs as a **spawned isolated worker** (Phase 2 Step 2): register-search
   execution against the manifest; consumes `matter-context.md` for materially-matters jurisdictions in per-jurisdiction sub-queries; consumes `placement-recommendations.md` (MODE B digest) for per-candidate placements.
 
 The two gather workers run in their **own isolated sessions** so their raw search payloads
@@ -67,7 +67,7 @@ Your tool surface binds **one paid register vendor** plus free / citation tools
 - **Paid vendor = the register source of truth** (global coverage, phonetic). The tools are always `register_*`; the vendor behind them is whichever REGISTER_PROVIDER selects — **one vendor at a time** (gated via `agents.list[].tools.allow`, swapped by the operator). Record which one in the audit trail + the scope statement.
 - **EUIPO is one of the four register providers, not a cross-check alongside one.** When it is active
   it IS the register, covering the EU alone; every other territory is a disclosed deferred gap.
-  `prelim-register/providers/euipo.md` carries the detail.
+  `clearance-register/providers/euipo.md` carries the detail.
 - **Case-law tools (`courtlistener__*` / `legaldatahunter__*`) are a separate layer** — precedent grounding via the `case-law-citation` skill at Step 4.5, **not** register search.
   *(Tool-naming note: the double-underscore prefix is the MCP-bridge naming convention (`<server>__<tool>`) — see `providers/oauth-mcp-bridge/bridge.mjs`. Keep the names exactly as written; bare names without the prefix would not resolve at the tool layer.)*
 
@@ -77,8 +77,8 @@ The old "exactly one register provider; you will never see both" referred to the
 
 Model tiers are set **per stage by the deterministic driver** — `driver/stages.mjs` is the
 source of truth. Current tiers: register sweep axes (`primary-sweep` / `transliteration-numeric` /
-`incumbent-class`) = `sonnet` / adaptive; `saturation-probe` = `haiku` / off; `prelim-common-law` = `haiku` /
-low; register digest + `matter-frame` / `prelim-variants` / `placement-inquiry` / synthesis = `opus`; Step-2.6
+`incumbent-class`) = `sonnet` / adaptive; `saturation-probe` = `haiku` / off; `clearance-common-law` = `haiku` /
+low; register digest + `matter-frame` / `clearance-variants` / `placement-inquiry` / synthesis = `opus`; Step-2.6
 skeptic = `sonnet`; `narrative-refutation` = `opus`. Every stage runs under the
 **forwarding identity** (derived from the queue location); delivery is not an agent capability — it is
 the driver's outbox contract (`../../docs/DELIVERY.md`).
@@ -124,7 +124,7 @@ Three phases, all complete before a single reply is sent to the forwarder.
 3. Derive the run slug and open the run-dir from those fields — Phase 1 authors NO client prose. The report is written in Phase 2 synthesis (per [delivery-contract.md](delivery-contract.md)) and the client email is composed in CODE at Phase 3 (`composeEmailHtml`)
 
 **Phase 2 — Research and synthesis** (run by the deterministic driver; methodology in [phase2-execution.md](phase2-execution.md)):
-1. **Variants** — `prelim-variants` produces the variant manifest (consumes `matter-context.md` from Phase 0)
+1. **Variants** — `clearance-variants` produces the variant manifest (consumes `matter-context.md` from Phase 0)
 2. **Gather** — common-law + the applicable register units run as batched stages against the manifest
 3. **Touchpoint 2: placement-inquiry** — structured inquiry per candidate; produces `placement-recommendations.md` (each candidate placed headline / sheet-2 / watchlist / out-of-scope with reasoning)
 4. **Register digest** — combines the unit digests into `register-findings.md`; consumes `placement-recommendations.md`
@@ -141,16 +141,16 @@ Three phases, all complete before a single reply is sent to the forwarder.
 - Reply to forwarder
 - Cross-person deadline flag
 - Mark as read, log handoff, done message
-- Archive the run dir (move `studio/prelim-search/<slug>/<date>/` → `studio/prelim-search/archive/<YYYY-MM>/<slug>/<date>/`)
+- Archive the run dir (move `studio/clearance-search/<slug>/<date>/` → `studio/clearance-search/archive/<YYYY-MM>/<slug>/<date>/`)
 
 ## Tool call budget
 
 The orchestrator itself makes few direct tool calls. Most calls happen inside sub-skills under their own budgets:
 
-- `prelim-common-law`: **15** `perplexity_research` per workflow
+- `clearance-common-law`: **15** `perplexity_research` per workflow
   *(rationale: cost-based overflow protection against a looping worker — the API is usage-billed; a search-as-code grid call ≈ $0.06, prose follow-ups ≈ $0.01–0.15 each (measured 2026-06-10). Typical workflow uses 2–6 calls/mark; 15 leaves headroom for thinness re-spawns)*
-- `prelim-register`: **150** provider calls per workflow, across all marks
-  *(rationale: Corsearch billing-tier ceiling; calibrated against May runs which used 80–110 calls each. The per-mark hard constraints are tighter — see `prelim-register/SKILL.md` "Per-mark ceilings": 20 search / 40 detail-fetch / 5 phoneme / 10 image)*
+- `clearance-register`: **150** provider calls per workflow, across all marks
+  *(rationale: Corsearch billing-tier ceiling; calibrated against May runs which used 80–110 calls each. The per-mark hard constraints are tighter — see `clearance-register/SKILL.md` "Per-mark ceilings": 20 search / 40 detail-fetch / 5 phoneme / 10 image)*
 - This skill: file read/write and memory write — bounded by workflow steps. It builds no workbook and sends no mail: the driver does both at publish, in code.
 
 Cross-pollination dispatches add at most **10** calls split across the two sub-skills (Option D cap).
@@ -158,7 +158,7 @@ Cross-pollination dispatches add at most **10** calls split across the two sub-s
 
 ## HITL exception (shared across sub-skills)
 
-Trademark research queries within this workflow are **pre-approved** for `perplexity_research` (used by `prelim-common-law`) and the configured register provider plugin (used by `prelim-register`) provided they are properly sanitized:
+Trademark research queries within this workflow are **pre-approved** for `perplexity_research` (used by `clearance-common-law`) and the configured register provider plugin (used by `clearance-register`) provided they are properly sanitized:
 - **Include:** mark name, product type, relevant industry context
 - **Strip:** client identity, reference numbers, internal contact names
 - Mark names are not confidential (they are proposed marks, destined for public registries). Who is asking is confidential.
@@ -171,9 +171,9 @@ Trademark research queries within this workflow are **pre-approved** for `perple
 fails** — the driver retries the stage, then surfaces a failed run. A report is never delivered
 with a main layer missing (no "flagged gap" partial delivery).
 
-- **prelim-variants fails or returns empty manifest** → halt; cannot proceed without variants. Surface to user with diagnostic.
-- **prelim-common-law fails** (Perplexity unavailable after plugin retries + one worker retry, zero usable results) → the worker writes **no findings file** and reports the tool failure (see `prelim-common-law/SKILL.md` → *Failure protocol*). The driver re-runs the stage, then fails the run and surfaces it. Incomplete-but-ran coverage is NOT failure — that is honest `coverage-limited` / `deferred` ledger rows in a real findings file.
-- **prelim-register fails** → "fails" here means the register layer made **zero** successful provider tool calls (`register_search` / `register_record_fetch`) in your session. Verify by inspecting your own tool-use history before declaring this. If even ONE provider call returned a non-error result, the register layer DID execute and you MUST write a real `register-findings-<slug>-<date>.md` containing the hits you collected — even if coverage is incomplete relative to the variant manifest. Document the coverage gap inline (e.g. "12 of 25 planned sweeps executed; remaining skipped because <reason>") rather than declaring the entire layer "not executed". In the genuine zero-calls case: write **no findings file** and report the tool failure — the driver re-runs the stage, then fails the run and surfaces it.
+- **clearance-variants fails or returns empty manifest** → halt; cannot proceed without variants. Surface to user with diagnostic.
+- **clearance-common-law fails** (Perplexity unavailable after plugin retries + one worker retry, zero usable results) → the worker writes **no findings file** and reports the tool failure (see `clearance-common-law/SKILL.md` → *Failure protocol*). The driver re-runs the stage, then fails the run and surfaces it. Incomplete-but-ran coverage is NOT failure — that is honest `coverage-limited` / `deferred` ledger rows in a real findings file.
+- **clearance-register fails** → "fails" here means the register layer made **zero** successful provider tool calls (`register_search` / `register_record_fetch`) in your session. Verify by inspecting your own tool-use history before declaring this. If even ONE provider call returned a non-error result, the register layer DID execute and you MUST write a real `register-findings-<slug>-<date>.md` containing the hits you collected — even if coverage is incomplete relative to the variant manifest. Document the coverage gap inline (e.g. "12 of 25 planned sweeps executed; remaining skipped because <reason>") rather than declaring the entire layer "not executed". In the genuine zero-calls case: write **no findings file** and report the tool failure — the driver re-runs the stage, then fails the run and surfaces it.
 - **Both fail** → same as either: failed run, surfaced — never a template-only delivery.
 - **Stage re-run** (any stage; triggered by a missing/invalid output file, a non-`ok` result, or a detected embedded-fallback) → the driver re-runs that stage under a fresh session key (bounded retries), then writes a `.failed` sentinel and surfaces it if it still cannot produce a valid output. The failure taxonomy + file-truth gating live in `driver/gateway.mjs`.
 
@@ -181,13 +181,13 @@ with a main layer missing (no "flagged gap" partial delivery).
 
 The orchestrator works inside a **unique codenamed run-dir under the per-skill `studio/` tree** in the
 forwarding identity's workspace:
-`<workspacePrefix><agent>/studio/prelim-search/<slug>/<date>-<codename>/`, where `<codename>` is a random
+`<workspacePrefix><agent>/studio/clearance-search/<slug>/<date>-<codename>/`, where `<codename>` is a random
 `<adjective>-<noun>` you generate fresh for this run — pick both words freely, lowercase, one hyphen.
 The codename guarantees a **unique** dir even for repeated same-matter, same-day runs,
 so a prior run's files can never land in — or be mistaken for — this run's, and there is never any need
 to inspect or clean up a prior dir. (Slug derivation: see Phase 1.)
 
-> **Run-dir token.** The run-dir is written `studio/prelim-search/<slug>/<date>/…` throughout this skill
+> **Run-dir token.** The run-dir is written `studio/clearance-search/<slug>/<date>/…` throughout this skill
 > and in worker tasks; in that **run-dir path**, the `<date>` segment is your codenamed leaf
 > `<YYYY-MM-DD>-<codename>` (the matching archive path `archive/<YYYY-MM>/<slug>/<date>/` carries the same
 > codenamed leaf). Substitute it consistently in every run-dir path you write or hand to a worker.
@@ -197,8 +197,8 @@ to inspect or clean up a prior dir. (Slug derivation: see Phase 1.)
 On every invocation, before Phase 1:
 
 1. **Generate the run codename** — a random `<adjective>-<noun>` (lowercase, single hyphen; pick freshly, never reuse a prior run's). This fixes your run-dir leaf `<date>-<codename>` for the entire run.
-2. **Create the run-dir by WRITING into it.** The `write` tool creates parent dirs automatically, so your first write (the matter-context.md in step 3, then `register-units/<axis>.md` files as Phase 2 needs them) creates `studio/prelim-search/<slug>/<date>/`. The unique codename already guarantees a clean, collision-free dir, so there is **nothing to inspect** — do not `read` or list a directory to check or create it; track every file by its known path.
-3. **Run `matter-frame` inline** to produce `studio/prelim-search/<slug>/<date>/matter-context.md`. This is the strategic foundation — it names client + sector + customer base + materially-matters jurisdictions + off-field sectors + watchlist-owner seeds. Downstream (Phase 1 variants, Phase 2 register-unit per-jurisdiction sub-queries, Touchpoint 2 placement, Touchpoint 3 refutation) all consume this artifact. Read [matter-frame/SKILL.md](../matter-frame/SKILL.md) and execute it inline; it makes no tool calls and stays cheaply in context.
+2. **Create the run-dir by WRITING into it.** The `write` tool creates parent dirs automatically, so your first write (the matter-context.md in step 3, then `register-units/<axis>.md` files as Phase 2 needs them) creates `studio/clearance-search/<slug>/<date>/`. The unique codename already guarantees a clean, collision-free dir, so there is **nothing to inspect** — do not `read` or list a directory to check or create it; track every file by its known path.
+3. **Run `matter-frame` inline** to produce `studio/clearance-search/<slug>/<date>/matter-context.md`. This is the strategic foundation — it names client + sector + customer base + materially-matters jurisdictions + off-field sectors + watchlist-owner seeds. Downstream (Phase 1 variants, Phase 2 register-unit per-jurisdiction sub-queries, Touchpoint 2 placement, Touchpoint 3 refutation) all consume this artifact. Read [matter-frame/SKILL.md](../matter-frame/SKILL.md) and execute it inline; it makes no tool calls and stays cheaply in context.
 4. **Per-customer delivery is driven by the RESOLVED CUSTOMER PROFILE, not the sender domain.** The intake
    AI resolves which customer this is for and stamps `profileKey` on the job (email-loop §B3.2a); the driver
    freezes that profile into `_driver/profile.json`, and the deterministic publish code reads its `delivery`
@@ -208,7 +208,7 @@ On every invocation, before Phase 1:
    ([templates/email/generic.md](templates/email/generic.md)) and it is a RECORD of the retired
    per-customer body, not an instruction. What the profile still decides is the P&C flag, and it
    decides it through the bound profile, never `*@domain`.
-5. **Phase 3 archives this run** on successful delivery: the dated subdir is moved to `studio/prelim-search/archive/<YYYY-MM>/<slug>/<date>/`. A run that delivered but failed to archive is a workflow violation — Phase 3 (see [Phase 3](#phase-3--delivery--must-pattern)) handles the move.
+5. **Phase 3 archives this run** on successful delivery: the dated subdir is moved to `studio/clearance-search/archive/<YYYY-MM>/<slug>/<date>/`. A run that delivered but failed to archive is a workflow violation — Phase 3 (see [Phase 3](#phase-3--delivery--must-pattern)) handles the move.
 
 ## Phase 1 — Template
 
@@ -224,7 +224,7 @@ The report body is authored in Phase 2 synthesis against [delivery-contract.md](
 
 Phase 2 is **sequenced by the deterministic driver** (`driver/`); the step-by-step
 **methodology** lives in [phase2-execution.md](phase2-execution.md). It covers:
-- **Step 1** — variants (`prelim-variants` writes the variant manifest)
+- **Step 1** — variants (`clearance-variants` writes the variant manifest)
 - **Step 2** — gather (common-law + the applicable register units) → Touchpoint 2 placement-inquiry → register digest
 - **Step 2.6** — skeptic review (fresh-eyes audit before trust)
 - **Step 3** — cross-pollination (Option D, cap N=10)
@@ -245,7 +245,7 @@ The driver runs the delivery stage on **every** completed run — the search is
 2. Builds the audit workbook in CODE (`driver/publish/xlsx.mjs`, from the artifacts this workflow wrote) and publishes report + audit into the pool. Its sheets and columns are the code's, not a template's, and nothing here assembles or formats a workbook.
 3. Writes the self-contained delivery packet `_driver/delivery.json` (forwarder route, subject, original message id for reply threading, the full email HTML, optional WhatsApp line) + the outbox `delivered` event, and sets `status.sendPending`.
 4. The **integrator's courier** sends the packet **VERBATIM** (email threaded on the packet's `msgId`; WhatsApp ping only if the packet carries a binding) and confirms with the ops-MCP `mark_sent` — which writes the `.sent` guard and clears `sendPending`. The courier composes nothing and never invents a recipient.
-5. The **driver** archives the run-dir (`studio/prelim-search/<slug>/<date>/` → `archive/<YYYY-MM>/<slug>/<date>/`) and records the delivery. `senior-eye-review.md` travels in the published audit set, so the reviewing lawyer sees the refutation verdict regardless of CLEAR/CONDITIONAL.
+5. The **driver** archives the run-dir (`studio/clearance-search/<slug>/<date>/` → `archive/<YYYY-MM>/<slug>/<date>/`) and records the delivery. `senior-eye-review.md` travels in the published audit set, so the reviewing lawyer sees the refutation verdict regardless of CLEAR/CONDITIONAL.
 
 **Why the verdict always surfaces:** the dangerous failure mode is a wrongly-cleared confabulation that ships unread. The reviewing lawyer always sees the review (CLEAR / CONDITIONAL / BLOCKING) — on the audit notification, and, when concerns are unresolved, as the **Reviewer's open questions** section in the report itself — so the reviewer can decide whether the read was right. Never silently passed, never silently withheld.
 
@@ -308,7 +308,7 @@ The **Methodology** sheet carries: matter-context summary, search approach, plac
 **Detail-fetch coverage** (register search-depth floor — kept here, not in the Excel spec, because the Step 2.6 skeptic review depends on it) — rank the union of unique URIs returned across all register searches by signal strength, then detail-fetch as follows:
 
 1. **Identical-mark hits** — fetch all, no cap.
-2. **Near-exact (dominant-token-substring) in-class-live hits — fetch all, no cap (Slice A).** The mirror, at the orchestrator floor, of the unit-side [exact-in-class-live floor](../prelim-register/unit.md#exact-in-class-live-floor-primary-sweep-unit-owns-it). The **near-exact band** — where the **dominant element** (from the variant manifest) appears as a *substring* of `mark_text` (case-insensitive, after the `normalize()` strip in [status-rules.md](../prelim-register/status-rules.md), see the Identical-match normalisation shape) in a **filed target class** with **live** status, but is not an identical match (e.g. NORDWAVE NOVAPULSE, NOVAPULSE.com on dominant element NOVAPULSE) — is **enumerate-and-fetch, no top-N, no score gate**. This is the F-1/F-3 hole: the near-exact band otherwise falls into the Top-K sample (item 5) and a dangerous in-class-live conflict gets paged past the cliff. *Budget tie:* if the qualifying set exceeds the detail-fetch budget, the coverage unit is **`coverage-limited`** (reason: "exact-in-class-live substring set exceeded detail-fetch budget") — **never** silent truncation, **never** `confirmed-clean` (per B-1 / the Coverage-honesty rule). Slice A is **exhaustive** — distinct from the sample-with-disclosure Slice B below.
+2. **Near-exact (dominant-token-substring) in-class-live hits — fetch all, no cap (Slice A).** The mirror, at the orchestrator floor, of the unit-side [exact-in-class-live floor](../clearance-register/unit.md#exact-in-class-live-floor-primary-sweep-unit-owns-it). The **near-exact band** — where the **dominant element** (from the variant manifest) appears as a *substring* of `mark_text` (case-insensitive, after the `normalize()` strip in [status-rules.md](../clearance-register/status-rules.md), see the Identical-match normalisation shape) in a **filed target class** with **live** status, but is not an identical match (e.g. NORDWAVE NOVAPULSE, NOVAPULSE.com on dominant element NOVAPULSE) — is **enumerate-and-fetch, no top-N, no score gate**. This is the F-1/F-3 hole: the near-exact band otherwise falls into the Top-K sample (item 5) and a dangerous in-class-live conflict gets paged past the cliff. *Budget tie:* if the qualifying set exceeds the detail-fetch budget, the coverage unit is **`coverage-limited`** (reason: "exact-in-class-live substring set exceeded detail-fetch budget") — **never** silent truncation, **never** `confirmed-clean` (per B-1 / the Coverage-honesty rule). Slice A is **exhaustive** — distinct from the sample-with-disclosure Slice B below.
 3. **Phonetic-equivalent fringe — floor, sample-with-disclosure (Slice B).** Run the provider phonetic capability on the dominant token for the matter languages (provider-agnostic: `<provider>_expand_phoneme` then `match_mode: phonetic`; Clarivate uses native `match_mode: phonetic`). It **is a floor** — it MUST run for the dominant token in the filed class — but phonetic sets are unbounded, so it is **sample-with-disclosure**: where it cannot be fully worked, the coverage unit is **`coverage-limited`** (reason: "phonetic fringe sampled, not enumerated"), never `confirmed-clean`. Keep Slice A (exhaustive) and Slice B (sampled) **structurally distinct** — they have different correctness properties.
 4. **Watchlist-owner hits** — fetch all.
 5. **Top-K by relevance** — sample from each match-mode (exact / phrase / default) and across regions to ensure representative coverage. If the worker stops detail-fetching before ~25 URIs across all match-modes, the worker MUST answer in its digest audit: did the result set genuinely run out, or is this the empirical execution-tier truncation pattern (~10 URIs, no explanation)? The 25 figure is a tripwire-with-question, not a target — the Step 2.6 skeptic reads the worker's answer and re-spawns escalated to Opus if the answer is missing or unconvincing.
@@ -345,9 +345,9 @@ be audited without touching the engine.
 ## Checklist — before sending
 
 - [ ] Phase 1 HTML template is complete and formatted per [template-formatting.md](template-formatting.md)
-- [ ] Variant manifest produced by `prelim-variants` and validated
-- [ ] `prelim-common-law` produced its findings file with every dictated platform covered
-- [ ] `prelim-register` produced its findings file with funnel pattern executed
+- [ ] Variant manifest produced by `clearance-variants` and validated
+- [ ] `clearance-common-law` produced its findings file with every dictated platform covered
+- [ ] `clearance-register` produced its findings file with funnel pattern executed
 - [ ] Cross-pollination Option D triggers all evaluated; any executed cross-checks logged; cap-overflow noted if applicable
 - [ ] Scope statement paragraph is present in narrative (from variant manifest)
 - [ ] Every finding has a URL or register URI
@@ -355,7 +355,7 @@ be audited without touching the engine.
 - [ ] **Dominant-element spine applied:** findings ranked by dominant element + whole-mark confusion; no on-point identical / near-identical-in-class hit dropped; headline driven by top on-point conflicts (not a distinguished mark or unrelated-field noise)
 - [ ] **Proposed-mark registrability read present** (dominant element + spectrum + deceptive/offensive flag, or "plainly distinctive")
 - [ ] **File-truth precondition met:** `register-findings.md` was written under the run-dir and synthesis read from it (not inline / announce text)
-- [ ] **Delivery complete:** report + audit published to the pool; `_driver/delivery.json` + the outbox `delivered` event written (`sendPending` set — the courier sends verbatim and confirms via `mark_sent`); the driver archived the run-dir to `studio/prelim-search/archive/<YYYY-MM>/<slug>/<date>/` and recorded the delivery
+- [ ] **Delivery complete:** report + audit published to the pool; `_driver/delivery.json` + the outbox `delivered` event written (`sendPending` set — the courier sends verbatim and confirms via `mark_sent`); the driver archived the run-dir to `studio/clearance-search/archive/<YYYY-MM>/<slug>/<date>/` and recorded the delivery
 - [ ] **matter-context.md produced at Phase 0** with materially-matters jurisdictions, off-field sectors, watchlist-owner seeds; downstream workers received it as input
 - [ ] **placement-recommendations.md produced at Phase 2 Touchpoint 2** with every candidate placed at headline / sheet-2 / watchlist-annex / out-of-scope-filtered + written reasoning; consumed by digest worker
 - [ ] **senior-eye-review.md produced at Phase 2 Touchpoint 3** with verdict CLEAR / CONDITIONAL / BLOCKING; corrections applied before Phase 3 if CONDITIONAL; halt + surface if BLOCKING twice
@@ -389,7 +389,7 @@ Format — one line per phase + each major search category, marked ✅ (done),
    Customer template: <resolved template name> (email + Excel)
 ✅ PHASE 1 — TEMPLATE: HTML generated; email marked read
 ✅ PHASE 2 — RESEARCH:
-   Variants: N variants in manifest from prelim-variants
+   Variants: N variants in manifest from clearance-variants
    Common-law: X findings ([N]/[N] dictated platforms covered); developer_of_record on <N>/<M> game-titles
    Register: Y findings; Z detail-fetched from W total URIs
      Per-jurisdiction sub-queries: ✅ <count> on <named jurisdictions>
@@ -407,7 +407,7 @@ Format — one line per phase + each major search category, marked ✅ (done),
 ✅ PHASE 3 — DELIVERY (deterministic): checklist items completed
    Excel built ✓ at <archive-path>
    Published ✓ report + audit in the pool; delivery packet + outbox `delivered` event written (sendPending)
-   Run-dir archived ✓ from studio/prelim-search/<slug>/<date>/ → studio/prelim-search/archive/<YYYY-MM>/<slug>/<date>/
+   Run-dir archived ✓ from studio/clearance-search/<slug>/<date>/ → studio/clearance-search/archive/<YYYY-MM>/<slug>/<date>/
 
 key artifacts:
   - <absolute path to the xlsx produced in Phase 3> (the client deliverable)

package/driver/skills/{prelim-search → clearance-search}/delivery-contract.md

@@ -295,7 +295,7 @@ Same forgiving labelled-block markdown. Three sections:
 ← (no per-finding risk fields here — the audit is the factual record; the rating is the finding's band
 ←  word, per the framework in force, carried in findings.json and the curated report)
 - source: <provider record refs>
-- url: <record base host>/mark/<cc>/<number>   ← the composed record URL (Record-URL contract: the ACTIVE provider's base host from `prelim-register/providers/<name>.md` + `uri`); emit the full URL, never a bare /mark/… path and never a host belonging to a register this run did not search
+- url: <record base host>/mark/<cc>/<number>   ← the composed record URL (Record-URL contract: the ACTIVE provider's base host from `clearance-register/providers/<name>.md` + `uri`); emit the full URL, never a bare /mark/… path and never a host belonging to a register this run did not search
 - description: <one line>
 - key_factors: ELEVATION: …  MITIGATION: …
 - cross_ref: N/A

package/driver/skills/{prelim-search → clearance-search}/phase2-execution.md

@@ -1,6 +1,6 @@
 # Phase 2 — methodology (the deterministic driver runs the orchestration)
 
-> **The prelim-search pipeline is sequenced in code by the deterministic driver** (`driver/`,
+> **The clearance-search pipeline is sequenced in code by the deterministic driver** (`driver/`,
 > source of truth `stages.mjs`). The old LLM-orchestrator's `sessions_spawn`/`sessions_yield`/Wait-state/
 > `NO_REPLY` machinery has been removed — the driver runs each stage as one blocking engine turn and
 > joins the fan-out in code, so it cannot park. This file is the per-step **methodology**: the judgment each
@@ -26,7 +26,7 @@
 
 ## Step 1 — Variants
 
-`prelim-variants` produces `variant-manifest.md` (Elements table, Variants table, Watchlists) from the marks,
+`clearance-variants` produces `variant-manifest.md` (Elements table, Variants table, Watchlists) from the marks,
 classes, jurisdiction scope, product description, industry, and manner of use. The manifest must be well-formed
 (Elements populated; Variants has rows; Watchlists present); if empty or malformed the run halts — there is no
 usable strategy. The manifest drives the gather stage.
@@ -35,7 +35,7 @@ usable strategy. The manifest drives the gather stage.
 
 The driver runs the register search-axis units and the common-law worker as a batched gather fan-out, then
 placement-inquiry, then the register digest — each reading the shared manifest + `matter-context.md` from the
-run-dir at `studio/prelim-search/<slug>/<date>/`.
+run-dir at `studio/clearance-search/<slug>/<date>/`.
 
 ### Step 2A — The applicable register units
 
@@ -46,10 +46,10 @@ if its axis is empty, so running a non-applicable one is harmless):
 - `transliteration-numeric` — if the manifest has `translit-*` or numeric-substitution variants and the mark is not English-only.
 - `incumbent-class` — if the manifest has an `industry_incumbent_alert`.
 
-Each unit is given: the sub-skill + axis (`prelim-register` unit mode — see `prelim-register/unit.md`), the
+Each unit is given: the sub-skill + axis (`clearance-register` unit mode — see `clearance-register/unit.md`), the
 variant manifest path, the request context, the **active register provider** (see
 [SKILL.md → Register sources](SKILL.md#register-sources--the-vendor-is-the-source-of-truth-euipo-is-a-free-eu-cross-check)),
-the sub-budget and its output path (`register-units/<axis>.md`). `prelim-common-law` runs
+the sub-budget and its output path (`register-units/<axis>.md`). `clearance-common-law` runs
 alongside the units against the same manifest.
 
 ### Step 2C — Touchpoint 2: placement-inquiry
@@ -57,11 +57,11 @@ alongside the units against the same manifest.
 After the gather units complete, run `placement-inquiry` (read [skills/placement-inquiry/SKILL.md](../placement-inquiry/SKILL.md)).
 
 **Inputs**:
-- `studio/prelim-search/<slug>/<date>/matter-context.md` (the strategic anchor from Phase 0)
-- Each `studio/prelim-search/<slug>/<date>/register-units/<axis>.md` (raw candidate inventory per axis)
-- `studio/prelim-search/<slug>/<date>/common-law-findings.md` (common-law candidate inventory)
+- `studio/clearance-search/<slug>/<date>/matter-context.md` (the strategic anchor from Phase 0)
+- Each `studio/clearance-search/<slug>/<date>/register-units/<axis>.md` (raw candidate inventory per axis)
+- `studio/clearance-search/<slug>/<date>/common-law-findings.md` (common-law candidate inventory)
 
-**Output**: `studio/prelim-search/<slug>/<date>/placement-recommendations.md` with every surfaced candidate placed at `headline-candidate` / `sheet-2` / `watchlist-annex` / `out-of-scope-filtered`, each with the structured-inquiry trace and written reasoning. The "Disagreements / flags surfaced to downstream" section captures cases where the placement deviates from a strict reading of the candidate's class-match or differs from `matter-context`'s framing.
+**Output**: `studio/clearance-search/<slug>/<date>/placement-recommendations.md` with every surfaced candidate placed at `headline-candidate` / `sheet-2` / `watchlist-annex` / `out-of-scope-filtered`, each with the structured-inquiry trace and written reasoning. The "Disagreements / flags surfaced to downstream" section captures cases where the placement deviates from a strict reading of the candidate's class-match or differs from `matter-context`'s framing.
 
 `placement-recommendations.md` feeds the digest — the digest consumes the placements as informed reasoning, can override with its own counter-reasoning, and carries the per-candidate placements through to `register-findings.md`. Overrides MUST be recorded in the digest's audit trail with the counter-reasoning.
 
@@ -80,7 +80,7 @@ skipped step must be logged with its reason in the unit's digest audit.
 3. **Single-word coverage hunts** — for each element marked "demote to filter" in the manifest, one search with product/industry filters applied (limit=50). Minimum 1 per such element.
 4. **Wildcard reorders** — if the manifest lists word-order variants, at least one wildcard sweep per distinct ordering (e.g. `Elevate * game`, `game * Elevate`).
 5. **Numeric-substitution and transliteration sweeps** — execute every sweep marked ✅ (requires verification) in the variant manifest, UNLESS the manifest classifies the mark as English-only (single-language Recipe 1 pattern). Skipping any ✅ requires a stated reason in the unit's digest audit.
-6. **Material-jurisdiction sub-queries** — a **protected, non-yielding** line item, NOT folded into the sweep budget. Run one scoped sub-query per jurisdiction `matter-context` declares materially-matters (no top-N cap; the per-mark ceiling scales with the declared count — see `prelim-register/SKILL.md` → *Tool call budget* and Step 3). These outrank within-axis breadth: if budget is tight, an extra script group (step 5) yields and is logged `coverage-limited` — a material jurisdiction is never dropped to fund breadth, and a jurisdiction that genuinely can't run is logged `deferred`, never silent.
+6. **Material-jurisdiction sub-queries** — a **protected, non-yielding** line item, NOT folded into the sweep budget. Run one scoped sub-query per jurisdiction `matter-context` declares materially-matters (no top-N cap; the per-mark ceiling scales with the declared count — see `clearance-register/SKILL.md` → *Tool call budget* and Step 3). These outrank within-axis breadth: if budget is tight, an extra script group (step 5) yields and is logged `coverage-limited` — a material jurisdiction is never dropped to fund breadth, and a jurisdiction that genuinely can't run is logged `deferred`, never silent.
 
 **Expected breadth for saturated common-word patterns: ~20–25 register searches per mark, plus the ring-fenced per-jurisdiction allowance** — a guideline, not a quota; coverage of the manifest's axes *and* the declared material jurisdictions is what matters, not the raw count. A run that is thin **and** left ✅ sweeps or material-jurisdiction sub-queries unexecuted with no documented skip reason is incomplete; the skeptic (Step 2.6) flags it. A run that executed every axis and validly found little is complete.
 
@@ -128,7 +128,7 @@ Escalate only genuinely closeable gaps (a `deferred` row the table lists as CLOS
 **A saturated everyday-word translation IS recoverable — narrow it to the field by class (replaces the old
 re-run-the-specific-concept-rendering move).** When a unit digest records `translit-too-generic` (the
 saturation probe read an everyday-word-scale count on a meaning-translation variant — see
-[`prelim-register` unit.md](../prelim-register/unit.md)), that is a **cheap ∧ material ∧ recoverable** gap on a
+[`clearance-register` unit.md](../clearance-register/unit.md)), that is a **cheap ∧ material ∧ recoverable** gap on a
 *real* element, not a documented structural limit: a warm re-run that SCOPES the saturated meaning token to the
 filed in-scope Nice classes (a structured `nice-class:` × `region:` filter — the token kept as the substring
 predicate, **never** goods-vocabulary words ANDed into the search text) and enumerates it closes the gap. (This
@@ -179,7 +179,7 @@ is not a reason to skip it, and "the rule said so" is not an answer.
   jurisdiction `matter-context` named materially-matters? Is any `deferred` / `coverage-limited` row being
   narrated (or about to be narrated) as a clean negative? A material jurisdiction with no row, or a
   deferred row treated as clean, is a recall gap — flag it.
-- **Registrability flag:** did `prelim-variants` name the dominant element + give the proposed-mark
+- **Registrability flag:** did `clearance-variants` name the dominant element + give the proposed-mark
   distinctiveness read (spectrum + deceptive/offensive, or "plainly distinctive"), and is it carried
   into the deliverable?
 
@@ -213,8 +213,8 @@ Read both findings files. Apply four explicit rules tied to the staff lawyer's s
 | # | Trigger | Action | Owned by |
 |---|---|---|---|
 | 1 | Every common-law owner found | Check register for any trademark filings by that owner in target classes | **CODE (2026-07-10):** the driver's cross-check dispatcher mints an `xcheck-owner-*` plan entry per extracted owner from the "Similar listing(s) found" receipts and executes it deterministically (`_driver/register-xcheck.json` is the receipt); verify the receipt in synthesis |
-| 2 | Every register stealth-filer pattern (law firm as owner) | One common-law query for the underlying client's marketplace use | Dispatch to `prelim-common-law` |
-| 3 | Every watchlist-hit owner appearing in register but NOT in common-law | One common-law query for that owner's marketplace activity | Dispatch to `prelim-common-law` |
+| 2 | Every register stealth-filer pattern (law firm as owner) | One common-law query for the underlying client's marketplace use | Dispatch to `clearance-common-law` |
+| 3 | Every watchlist-hit owner appearing in register but NOT in common-law | One common-law query for that owner's marketplace activity | Dispatch to `clearance-common-law` |
 | 4 | Every common-law finding without a register tie | One register query for the entity name | **CODE (2026-07-10):** the same dispatcher mints an `xcheck-mark-*` contains entry per owner-less similar-listing mark; anything the receipts show over-cap or unparsed, dispatch via the register supplemental lane (`register_propose_supplemental`) |
 
 **All four triggers fire deterministically when their condition is met.** Triggers 1/4 are now code-fired
@@ -286,7 +286,7 @@ practical-likelihood question for this owner.
 
 **Reuse the register half; add the marketplace half.** The owner's portfolio under owner-name variants and
 the enforcement-appetite signals are already in hand from the register layer — owner aggregation across name
-variants and the owner-bound sweep (`prelim-register/digest.md` Steps 3–4) plus the prosecution-history and
+variants and the owner-bound sweep (`clearance-register/digest.md` Steps 3–4) plus the prosecution-history and
 revocability reads (`synthesis-rules.md`). This step adds what the register layer cannot see: the
 **marketplace** half — the owner's *own use of the term*, site, and socials.
 
@@ -300,7 +300,7 @@ revocability reads (`synthesis-rules.md`). This step adds what the register laye
 **Output:** a practical-likelihood statement in the finding's business read ("how likely is this owner to
 actually create a problem"), feeding the net rating. **Non-attributable research practice:** view an owner's
 profiles non-attributably, and when a finding rests on the owner's public social / web profiles, set the
-deliverable's `handling_note` (see `prelim-search/delivery-contract.md`) so the reviewer opens those links
+deliverable's `handling_note` (see `clearance-search/delivery-contract.md`) so the reviewer opens those links
 privately too.
 
 ## Step 4 — Joint synthesis
@@ -309,7 +309,7 @@ For **each finding** in the combined findings set (common-law + register, both l
 
 **Rank and select before you rate.** Apply the dominant-element spine first — [synthesis-rules.md](synthesis-rules.md) → "Conflict ranking & selection" — centred on the proposed mark's **dominant element** and gated by the consumer-confusion test ([risk-framework.md](risk-framework.md) → "The consumer confusion test — the governing gate"). The headline/overall risk is driven by the highest-ranked **on-point** conflicts (bare dominant element in the target field), not by a distinguished mark (e.g. a house-mark-prefixed filing) or by unrelated-field noise. Never let an on-point identical / near-identical-in-class hit drop out.
 
-**Source of truth (file-truth precondition).** Build every Findings row from `studio/prelim-search/<slug>/<date>/register-findings.md` and `studio/prelim-search/<slug>/<date>/common-law-findings.md`. Do **NOT** assemble the Findings sheet / Excel from inline digest output — if the register-findings file is not present the synthesis is not ready (the driver re-runs the digest). *(Prior-incident anchor: a run where the register layer found an identical-mark registration, but with no register-findings file written it never reached the deliverable — the deliverable is built from files, not inline payloads.)*
+**Source of truth (file-truth precondition).** Build every Findings row from `studio/clearance-search/<slug>/<date>/register-findings.md` and `studio/clearance-search/<slug>/<date>/common-law-findings.md`. Do **NOT** assemble the Findings sheet / Excel from inline digest output — if the register-findings file is not present the synthesis is not ready (the driver re-runs the digest). *(Prior-incident anchor: a run where the register layer found an identical-mark registration, but with no register-findings file written it never reached the deliverable — the deliverable is built from files, not inline payloads.)*
 
 Every assessment must be labeled: **Advisory — preliminary assessment for the reviewing lawyer.**
 
@@ -335,7 +335,7 @@ to ground, supply:
 
 The result is a **grounded profile** per finding (on-point authorities with court / date / one-line holding /
 stable id, or an explicit "no on-point precedent found"), optionally written to
-`studio/prelim-search/<slug>/<date>/case-law-findings.md`. Fold the grounded profiles into Key Factors + the
+`studio/clearance-search/<slug>/<date>/case-law-findings.md`. Fold the grounded profiles into Key Factors + the
 narrative. Do NOT ground every finding — it is cost-prohibitive and low-signal — but DO ground watchlist hits
 unless the digest's own evidence already grounds them concretely (e.g. opposition data pulled directly).
 

package/driver/skills/{prelim-search → clearance-search}/synthesis-rules.md

@@ -51,7 +51,7 @@ A negative is only as good as the search behind it. **Before writing any "clean"
 
 1. **the register coverage ledger — as DATA in your dispatch, not from the prose.** The driver composes the machine ledger (`register-coverage-ledger.json`) and the plan-execution receipt (`_driver/plan-execution.json`) into tables in the dispatch message itself: every axis, unit, status and reason, plus every dictated query that produced no band block. Those tables are the register answer — do **not** reconstruct the ledger by reading the `## Coverage ledger` prose in `register-findings.md`, and do not re-type their numbers into yours. (The same reconstruction one stage upstream burned 28,592 thinking tokens, 95% of that stage's emission, and still got the answer wrong.) The files are named in the dispatch and remain yours to read directly; the prose ledger is a rendering of the same data, and where they differ the machine ledger governs. **If the dispatch says no register record was composed this run, there is no table and the register layer has no driver-computed record at all — that is the absence of a record, never a clean register.**
 2. the `## Coverage ledger` section in `common-law-findings.md` (common-law platforms). **This one is read in ONE direction only.** That file is the common-law stage's own narrative, so nothing in it is proof a check ran: its ledger CONSTRAINS you — a unit recorded `coverage-limited` or `deferred` can never be written as a clean negative — and it LICENSES nothing, because a `confirmed-clean` row there is that stage's word about its own work. A clean common-law statement still needs a source you read and can cite, exactly like every other off-register fact.
-3. the variant manifest's **`### Scope ledger`** section (the variants-stage coverage statement, spanning the variant / field / source layers — see [prelim-variants/SKILL.md](../prelim-variants/SKILL.md#scope-ledger)).
+3. the variant manifest's **`### Scope ledger`** section (the variants-stage coverage statement, spanning the variant / field / source layers — see [clearance-variants/SKILL.md](../clearance-variants/SKILL.md#scope-ledger)).
 
 The first two inputs cover the register axes and the common-law platforms; the **`### Scope ledger`** section is the **third coverage input** and covers the **variants stage** across all three frame layers. A row recorded there as `dropped` is a **recall limitation** — the search never generated that axis / never searched that field or channel, so its absence of findings cannot be read as clean for it. The verdict MUST carry it the same way it carries a `coverage-limited` / `deferred` ledger row: a `dropped` `numeric-substitution` or `foreign-transliteration` variant means leet / cross-script conflicts in that lane are **unassessed**; a `dropped` field means an off-fielded sector's collisions are unassessed; a `dropped` source means that channel is unsearched — not absent.
 
@@ -109,8 +109,8 @@ Every row in the unified Findings sheet gets a `Source Layer` value:
 
 | Source Layer | Meaning |
 |---|---|
-| **Common-law** | Surfaced by `prelim-common-law` only. Marketplace presence, no register evidence. |
-| **Register** | Surfaced by `prelim-register` only. Filed protection, no visible marketplace use yet (or no marketplace evidence captured). |
+| **Common-law** | Surfaced by `clearance-common-law` only. Marketplace presence, no register evidence. |
+| **Register** | Surfaced by `clearance-register` only. Filed protection, no visible marketplace use yet (or no marketplace evidence captured). |
 | **Both** | Same entity / mark / owner surfaced on BOTH sides. Strongest evidence type. |
 | **Cross-pollination** | Surfaced by a deterministic cross-check (Option D Triggers 1-4) — not in either layer's primary first-pass. Audit-trail proof-of-work. |
 
@@ -208,7 +208,7 @@ For each material finding, document (in the Findings sheet's Key Factors column)
 4. **The BAND — reasoned through the framework in force.** Take the legal read (item 2) and the practical read (item 3) through the framework's own band definitions — its Legal position / Practical position / Potential outcomes per band, or its Level × Dispute Type matrix where it states one — and state the band **word**, verbatim from that framework. The two reads move the framework's *inputs*; its stated method yields the band, honouring any ceilings it states — a practical or optics factor never lifts the band past what the framework's method produces. A clear win with no material risk yields **no band** (not a rated conflict — Reasoning posture 4), and so does a conflict whose proprietor you could not identify on the record searched: with no party there is no legal read to take through the framework, so it is carried as an open item naming the identification step, never rated.
 5. **Elevation / mitigation factors observed** (if any) — tag each as bearing on the legal read or the business read (the factor lists live under *Firm-wide reasoning discipline* below).
 6. **Source-layer note:** which layer(s) surfaced this; whether cross-pollination ran for it
-7. **Client prior-use adjacency check:** examine the request form's "Manner of Use" and "Additional Information" fields for evidence of prior use of the proposed mark by the client. If found, apply the *client prior-use rule* (under Firm-wide reasoning discipline below; adjacency tiers — same/adjacent-goods/adjacent-industry/none) to weigh the applicant's prior-use defence on the **business** read. When same-goods or adjacent-goods prior use exists, headline-frame it in the narrative summary's scope statement (not just in the per-finding Key Factors). Example framing: "the applicant may own common-law rights in the mark for [its prior goods], or at least a right to continued use for those goods and highly similar ones." **When a senior conflict makes priority live, resolve the *filing* branch instead of punting it:** consume the applicant own-rights sweep (`prelim-register/digest.md` Step 4 — rows tagged `applicant_own_rights`) and state the client's own filing/footprint position as a **separate "client's own prior rights" note** (e.g. "no prior client filing predating [conflict] was found" or "the client holds earlier filing [X] covering [Y]"). This note is **never a conflict / Findings-sheet row, never gates or down-rates the conflict sweep, and never feeds the rating** — it surfaces as an own-rights note / `# Actions` line (per `delivery-contract.md`). The *internal / undocumented-use* branch is invisible to any external search, so leave it as a one-line client question, framed as such ("confirm any unregistered prior use of the mark by the client").
+7. **Client prior-use adjacency check:** examine the request form's "Manner of Use" and "Additional Information" fields for evidence of prior use of the proposed mark by the client. If found, apply the *client prior-use rule* (under Firm-wide reasoning discipline below; adjacency tiers — same/adjacent-goods/adjacent-industry/none) to weigh the applicant's prior-use defence on the **business** read. When same-goods or adjacent-goods prior use exists, headline-frame it in the narrative summary's scope statement (not just in the per-finding Key Factors). Example framing: "the applicant may own common-law rights in the mark for [its prior goods], or at least a right to continued use for those goods and highly similar ones." **When a senior conflict makes priority live, resolve the *filing* branch instead of punting it:** consume the applicant own-rights sweep (`clearance-register/digest.md` Step 4 — rows tagged `applicant_own_rights`) and state the client's own filing/footprint position as a **separate "client's own prior rights" note** (e.g. "no prior client filing predating [conflict] was found" or "the client holds earlier filing [X] covering [Y]"). This note is **never a conflict / Findings-sheet row, never gates or down-rates the conflict sweep, and never feeds the rating** — it surfaces as an own-rights note / `# Actions` line (per `delivery-contract.md`). The *internal / undocumented-use* branch is invisible to any external search, so leave it as a one-line client question, framed as such ("confirm any unregistered prior use of the mark by the client").
 8. **Impact / consequences (surfaced for the client to weigh — never moves the rating):** for each material finding, name the practical consequences *if* the rights-holder enforced — injunction scope, damages / account of profits, reputational harm, legal costs — and tie them to the client's actual use as the matter states it (a brand printed on physical stock already shipping vs. a removable app listing; the scale and reversibility of the use). State these as **information for the client's own risk-acceptance decision, not a conclusion we draw**: we often lack the client's internal exposure data, so name the *kind* of exposure honestly rather than quantifying what we cannot see. Impact is **client-specific** and **must never move the band** — the band is what the framework in force's method yields; it is surfaced *beside* the rating, in the narrative and the report, the way the PR / reputational note is (see Reasoning posture 4 and *PR / reputational risk* below). Where the matter gives no usable signal on the client's exposure, say so in one line rather than inventing it.
 
 Every assessment must be labeled:
@@ -384,13 +384,13 @@ one grounding `owner.registrations[]` entry with a real record URI — it is the
 mark known only from general knowledge — a famous one-keystroke neighbour with **no** fetched register record —
 is **never** emitted as a register finding (an empty/fabricated registration is rejected by the findings
 contract); it travels as a typed `context_notes[]` entry (`famous-neighbour-ungrounded`), exactly as
-`prelim-register/digest.md` (A1) dictates. A register finding with no grounding registration is an **orphan** —
+`clearance-register/digest.md` (A1) dictates. A register finding with no grounding registration is an **orphan** —
 the driver's grading tripwire flags it; the cure is to ground it in the fetched record or move it to a context
 note, never to ship it ungrounded.
 
 ## The record URL, and what to write when there is none
 
-The record-URL contract lives in `prelim-register/status-rules.md`. **The half you need is here** because
+The record-URL contract lives in `clearance-register/status-rules.md`. **The half you need is here** because
 you are the seat the validator refuses, and you do not open that file.
 
 - Where the provider publishes a per-record page, `source.resolved_link` carries the **full composed
@@ -654,4 +654,4 @@ Inconsistency between narrative and Findings sheet is a delivery failure — che
 
 ### Consistency contract — one record, one composed URL, everywhere
 
-Every owner/mark mention in the deliverable that corresponds to a **register finding** MUST resolve to the **same register record** as that finding's row in the structured deliverable — the narrative bullet, the Findings-sheet row, and any other surface all point at one record, never at divergent ones. The single shared link target is the **composed record URL** from the **record-URL contract** (see [prelim-register/status-rules.md → Record-URL contract](../prelim-register/status-rules.md#record-url-contract) and the digest's findings format): the configured provider record **base-host** + the record's `uri` (`/mark/<cc>/<number>`) path. There is **exactly one URL per record**, composed from `uri` — no separately-maintained link sets, no per-surface URL variants, and no URL drift between the narrative and the sheet. If the narrative names a register conflict, the URL behind that name is the same composed URL carried in that conflict's findings row; a mismatch is a consistency failure the `narrative-refutation` gate flags.
+Every owner/mark mention in the deliverable that corresponds to a **register finding** MUST resolve to the **same register record** as that finding's row in the structured deliverable — the narrative bullet, the Findings-sheet row, and any other surface all point at one record, never at divergent ones. The single shared link target is the **composed record URL** from the **record-URL contract** (see [clearance-register/status-rules.md → Record-URL contract](../clearance-register/status-rules.md#record-url-contract) and the digest's findings format): the configured provider record **base-host** + the record's `uri` (`/mark/<cc>/<number>`) path. There is **exactly one URL per record**, composed from `uri` — no separately-maintained link sets, no per-surface URL variants, and no URL drift between the narrative and the sheet. If the narrative names a register conflict, the URL behind that name is the same composed URL carried in that conflict's findings row; a mismatch is a consistency failure the `narrative-refutation` gate flags.

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

@@ -1,6 +1,6 @@
 ---
-name: prelim-variants
-description: Shared strategy + variant generation for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator** as the first stage of any v3 clearotron run — do not call directly. Classifies the proposed mark into one of six analytical archetypes, derives a risk theory from that classification, then generates the variant set whose axes are shaped by the archetype. Emits a markdown variant manifest consumed by both common-law (`prelim-common-law`) and register (`prelim-register`) execution skills.
+name: clearance-variants
+description: Shared strategy + variant generation for the v3 preliminary trademark search workflow. **Invoked exclusively by the `clearance-search` orchestrator** as the first stage of any v3 clearotron run — do not call directly. Classifies the proposed mark into one of six analytical archetypes, derives a risk theory from that classification, then generates the variant set whose axes are shaped by the archetype. Emits a markdown variant manifest consumed by both common-law (`clearance-common-law`) and register (`clearance-register`) execution skills.
 ---
 
 ## Contents
@@ -18,7 +18,7 @@ description: Shared strategy + variant generation for the v3 preliminary tradema
 
 ## Spawned session
 
-Invoked from `prelim-search` (orchestrator) as the first stage of any preliminary trademark review. Reads `task` containing: mark(s), class(es), jurisdiction scope, product description, optional industry context. Produces a single artifact — the **variant manifest** — written to the workspace for the downstream skills to consume.
+Invoked from `clearance-search` (orchestrator) as the first stage of any preliminary trademark review. Reads `task` containing: mark(s), class(es), jurisdiction scope, product description, optional industry context. Produces a single artifact — the **variant manifest** — written to the workspace for the downstream skills to consume.
 
 No tool calls. Pure analytical work.
 
@@ -27,7 +27,7 @@ Companion files:
 
 ## Trigger
 
-Called by `prelim-search` at the start of any clearotron run. Not invoked directly.
+Called by `clearance-search` at the start of any clearotron run. Not invoked directly.
 
 ## Model
 
@@ -37,7 +37,7 @@ Always Opus. Variant generation is the highest-value AI step in the pipeline —
 
 Zero `perplexity_research`, zero plugin calls. Pure thinking. Output is the variant manifest only.
 
-If an element triggers Step 2's famous-mark check, the manifest TAGS it for a famous-mark Perplexity call — the call itself happens in `prelim-common-law`.
+If an element triggers Step 2's famous-mark check, the manifest TAGS it for a famous-mark Perplexity call — the call itself happens in `clearance-common-law`.
 
 ## Core thesis — archetype-driven analysis
 
@@ -63,13 +63,13 @@ These are starting points. A mark can fit a primary archetype and pick up one or
 **Modifier semantics:**
 
 - A mark is **device-led** when the visual/logo is doing most of the brand work. If a wordmark version exists too, the verbal-element analysis runs as the primary archetype with `device-led` as a modifier.
-- A mark is **famous-element-masked** when any element matches a famous brand. The primary archetype reflects the mark's overall shape; the modifier triggers per-element famous-mark searches in `prelim-common-law`.
+- A mark is **famous-element-masked** when any element matches a famous brand. The primary archetype reflects the mark's overall shape; the modifier triggers per-element famous-mark searches in `clearance-common-law`.
 
 If a mark genuinely doesn't fit any archetype, document the reasoning and fall back to element decomposition + saturation analysis. Don't force-fit.
 
 ## Output — the variant manifest
 
-A single file inside the active run-dir: `studio/prelim-search/<slug>/<date>/variant-manifest.md`. Slug and date are passed in by the orchestrator (see [prelim-search/SKILL.md → Phase 1](../prelim-search/SKILL.md#phase-1--template)). Markdown by design. Consumed by both downstream skills.
+A single file inside the active run-dir: `studio/clearance-search/<slug>/<date>/variant-manifest.md`. Slug and date are passed in by the orchestrator (see [clearance-search/SKILL.md → Phase 1](../clearance-search/SKILL.md#phase-1--template)). Markdown by design. Consumed by both downstream skills.
 
 ### Format
 
@@ -204,7 +204,7 @@ N/A — single-mark request.
 - **Distinctiveness & registrability** names the **dominant element** (the spine the register sweep + synthesis ranking centre on) plus the advisory spectrum read and any obvious flags. The orchestrator surfaces it as a "Proposed-mark assessment" line in the narrative + an Excel header block; the register/common-law layers centre their searches on the dominant element.
 - **Element table** has stable columns. The contract is the header line.
 - **Variant table** uses `Category | Value | Rationale | Verify?`. Variant categories are shaped by archetype — which categories fire is the archetype's call, but a fired category is never *silently* omitted: the `### Scope ledger` section below records every category's disposition.
-- **The scope ledger** is MANDATORY and you send it as `scope_ledger` rows on the `record_prelim_variants` call — `{layer, item, status, reason, reopen_trigger}`. The driver renders the table (stable columns `Layer | Item | Status | Reason | Reopen trigger`) and writes `scope-ledger.json` from the same rows; you never lay out a table. It spans the FOUR scope layers an independent reviewer tests — `variant`, `field`, `source`, `jurisdiction` — so an omission in any of them is recorded, not just dropped variant categories. `Status` is exactly `applied` or `dropped`. Rows to include:
+- **The scope ledger** is MANDATORY and you send it as `scope_ledger` rows on the `record_clearance_variants` call — `{layer, item, status, reason, reopen_trigger}`. The driver renders the table (stable columns `Layer | Item | Status | Reason | Reopen trigger`) and writes `scope-ledger.json` from the same rows; you never lay out a table. It spans the FOUR scope layers an independent reviewer tests — `variant`, `field`, `source`, `jurisdiction` — so an omission in any of them is recorded, not just dropped variant categories. `Status` is exactly `applied` or `dropped`. Rows to include:
   - **variant** rows — one per variant category considered: `phonetic`, `foreign-transliteration`, `numeric-substitution`, `visual-substitution` (the space-split/join + typographic-neighbour mechanic; an upstream brief's "separator-spacing" maps here), `compound` (compound-token-split), `translation` (literal-meaning), and `plural-root` (the shortest morphological / drop-letter root of the dominant element — applied when the mark is a plural/compound, dropped with a reopen trigger when it is not). `numeric-substitution` and `foreign-transliteration` are matter-profile-driven; the row NAMES that decision either way.
   - **field** rows — each on-field boundary you keep (goods-overlap with the product) and each adjacent sector you push off-field, by goods-overlap reasoning (not class number alone).
   - **source** rows — each search channel you sweep and each you set aside (e.g. a developer ecosystem on a consumer-storefront sweep), by the product's real channel.
@@ -259,7 +259,7 @@ For EACH element:
 If ANY element triggers questions 2–4:
 
 - Set `famous_mark_flag: true` on that element
-- Add an entry to `famous_mark_calls_needed[]` so `prelim-common-law` fires a dedicated Perplexity query
+- Add an entry to `famous_mark_calls_needed[]` so `clearance-common-law` fires a dedicated Perplexity query
 - Set the **famous-element-masked modifier** on the mark's archetype
 
 **Dual-meaning rule:** when a term is BOTH descriptive AND a famous mark, treat it as the famous mark for risk purposes. Worked example: "Bloodguard Sabatons" → Sabatons is real armor terminology AND a Swedish metal band with gaming collaborations. Famous-mark search required.
@@ -275,7 +275,7 @@ For each element, classify volume baseline:
 
 **Saturation narrows the search; it never drops a variant.** These ratings tell the downstream register search how to *probe* a token (class-scope the in-scope slice and enumerate it) — post-funnel the register layer enumerates the dangerous band for the **distinctive anchor** and its forms; a **common** component (a stripped common word, not the distinctive anchor) it **counts**, not enumerates, handing that count up as dilution (a hyper-common word is dilution the lawyer uses, never a coverage gap). A `high` / `very-high` rating is **never** grounds to omit the element from the manifest, to collapse or skip its meaning / transliteration set, or to pre-judge its crowd clean. (See the Step-4 generation boundary.)
 
-**Industry-incumbent alert** (per element when applicable): non-target-industry incumbent owns the element. Capture owner pattern, primary industry, primary class set. Triggers parallel-class sweep in `prelim-register`.
+**Industry-incumbent alert** (per element when applicable): non-target-industry incumbent owns the element. Capture owner pattern, primary industry, primary class set. Triggers parallel-class sweep in `clearance-register`.
 
 **Dominant element + proposed-mark registrability read** (feeds the synthesis spine and the deliverable; the staff lawyer's "flag obvious issues"):
 
@@ -289,7 +289,7 @@ For each element, classify volume baseline:
 
 The variant categories are shaped by the archetype. Don't generate every category for every mark. Generate the categories the archetype calls for.
 
-**The generation boundary (read first — it governs every axis and every bound below).** This step's only question about any candidate form is: ***could a real conflict plausibly take this shape?*** Generate every form a real collision could take; the ONLY valid reason to drop a form is that a real conflict could **not** take it (ungrammatical, semantically broken, not market-realistic — a collision-plausibility call, which is yours to make). **Never drop a plausible form because the search would be crowded, saturated, or noisy, or because the term is common / descriptive / generic.** Noise is no longer yours to manage: the register funnel enumerates the dangerous band **class-scoped** and hands any residual crowd to judgment ([prelim-register register-recipes.md](../prelim-register/register-recipes.md)) — generating a noisy-but-plausible form is safe by construction. A *"would drown in noise" / "too saturated to be worth it" / "descriptive, so skip it"* reason on a **dropped** row is the boundary violation this step must never commit. Saturation is a signal to the downstream search to **narrow** (class-scope the token and enumerate); it is never a reason to drop a variant here.
+**The generation boundary (read first — it governs every axis and every bound below).** This step's only question about any candidate form is: ***could a real conflict plausibly take this shape?*** Generate every form a real collision could take; the ONLY valid reason to drop a form is that a real conflict could **not** take it (ungrammatical, semantically broken, not market-realistic — a collision-plausibility call, which is yours to make). **Never drop a plausible form because the search would be crowded, saturated, or noisy, or because the term is common / descriptive / generic.** Noise is no longer yours to manage: the register funnel enumerates the dangerous band **class-scoped** and hands any residual crowd to judgment ([clearance-register register-recipes.md](../clearance-register/register-recipes.md)) — generating a noisy-but-plausible form is safe by construction. A *"would drown in noise" / "too saturated to be worth it" / "descriptive, so skip it"* reason on a **dropped** row is the boundary violation this step must never commit. Saturation is a signal to the downstream search to **narrow** (class-scope the token and enumerate); it is never a reason to drop a variant here.
 
 **The FORM axis is now mechanically COMPLETE — you do not own form coverage.** The driver generates the *complete* form neighbourhood of the distinctive element(s) **deterministically, with no model in the loop** — every edit-1 spelling/sound/transposition, the phonetic-key vowel family (the SYRONA/SIRINA class), visual / homoglyph look-alikes, and cross-script transliterations — into `form-neighbourhood.json`, which the register funnel searches as the authoritative **form floor**. This exists because a *guessed* form set is never complete: for an anchor like `VELTRIS` a model thinks of `ZELTRIS` but not `MELTRIS` (the same single edit), and the vendor's own phonetic/fuzzy modes cannot reach a first-consonant swap either (live-verified on a production matter — the missed first-consonant-swap neighbour existed as 69 live records yet Corsearch's complete in-class phonetic band for the anchor excluded it). The machine closes that lottery. **So your FORM-axis job is JUDGMENT, not enumeration:**
 1. **Name the distinctive element + formative root precisely** (Step 3) — this is the *one* input the mechanical band seeds from; get the token right and the complete neighbourhood follows.
@@ -323,8 +323,8 @@ The `phonetic` / `visual-substitution` / `numeric-substitution` / typographic ro
 | Category | Notes |
 |---|---|
 | foreign-transliteration | Always for worldwide/multi-region scope. Coined-word archetype: prioritise. Slogan archetype: skip unless mark targets a non-English market. Scripts per [transliteration-scripts.md](transliteration-scripts.md). |
-| component-isolation | When `prelim-common-law` needs to isolate an element for platform-specific search. |
-| competitor-intel | Driven by Watchlist, NOT by variant table — handled in `prelim-register` Step 8.5. |
+| component-isolation | When `clearance-common-law` needs to isolate an element for platform-specific search. |
+| competitor-intel | Driven by Watchlist, NOT by variant table — handled in `clearance-register` Step 8.5. |
 
 **Phrase-substitution rules** (slogan archetype, primarily):
 
@@ -379,7 +379,7 @@ The phonetic axis catches *sound-alikes*. This axis catches *look-alikes* — an
 A mark with semantic content collides in a non-Latin market through the **word a local company would actually use to name that thing** — not only the technical dictionary term. So ask the **market-realistic question** — *"in this market, what would a real business call a `<concept>` product?"* — and generate the small deterministic **equivalence SET**, **everyday-usage first**, then technical, then adjacent, tagging each member's register (`everyday | technical | adjacent`). The everyday word is exactly what a local registrant files and what the reviewing lawyer reaches for.
 
 - **Never collapse the set to one technical guess** — one "precise/specific" rendering is the old single-guess miss. Generate the set.
-- **Never drop the everyday member because its count looks saturated or "descriptive"** — that is the Step-4 generation boundary violation. Saturation is narrowed downstream by class-scoped enumeration in the register layer ([transliteration-scripts.md](transliteration-scripts.md) · [register-recipes.md](../prelim-register/register-recipes.md)), never by abandoning the word here.
+- **Never drop the everyday member because its count looks saturated or "descriptive"** — that is the Step-4 generation boundary violation. Saturation is narrowed downstream by class-scoped enumeration in the register layer ([transliteration-scripts.md](transliteration-scripts.md) · [register-recipes.md](../clearance-register/register-recipes.md)), never by abandoning the word here.
 - Tag CJK meaning rows `translit-zh-meaning` (the downstream class-scope gate keys on the `-meaning` sense); flag `Verify? ✅`.
 - *Illustration of the principle (NOT a fixed list — derive the set from the concept):* COLORA → CN **色彩 / 颜色** (everyday "colour") → **色度** (technical "chromaticity") → **彩度 / 色相** (adjacent). What generalises is the market-realistic question above — to any market (a German `FARBE`-type everyday form; a "descriptive" compound the model would otherwise drop), not these characters. The full script reference is [transliteration-scripts.md](transliteration-scripts.md), now read alongside this skill.
 
@@ -403,7 +403,7 @@ Make `numeric-substitution` and `foreign-transliteration` explicitly profile-awa
 - **numeric-substitution (leet):** runs for coined-word / acronym anchors; drop for saturated common-word marks (no squatter incentive) — say which and why.
 - **foreign-transliteration:** runs for worldwide / multi-region scope or a non-Latin mark; drop for single-jurisdiction Latin scopes (per the transliteration rule above) — name the jurisdiction read that decided it.
 
-These rows ARE the variants-stage coverage statement — phrase each `reason` as a coverage record, not a tick. The driver writes `scope-ledger.json` from them directly; the blind frame-diff diffs it against an independent re-derivation; synthesis (in `prelim-search`) consumes it as the variants-stage coverage input.
+These rows ARE the variants-stage coverage statement — phrase each `reason` as a coverage record, not a tick. The driver writes `scope-ledger.json` from them directly; the blind frame-diff diffs it against an independent re-derivation; synthesis (in `clearance-search`) consumes it as the variants-stage coverage input.
 
 ### Step 5 — Watchlists (per-matter, configurable)
 
@@ -415,7 +415,7 @@ Per request, populate three lists:
 
 **Mandatory client-exclusion rule:** if the request identifies a client, DROP that company's name from ALL three lists before emitting the manifest. The client's own marks must not auto-flag as conflicts.
 
-Watchlists drive cross-pollination triggers and owner-bound register sweeps (Step 8.5 of [prelim-register/SKILL.md](../prelim-register/SKILL.md)).
+Watchlists drive cross-pollination triggers and owner-bound register sweeps (Step 8.5 of [clearance-register/SKILL.md](../clearance-register/SKILL.md)).
 
 **Structured sibling:** mirror the register-relevant watchlist into the structured model's
 `watchlist_owners` key — `aggressive_enforcers` ∪ `competitors` ∪ the matter frame's watchlist-owner
@@ -433,7 +433,7 @@ Multi-mark requests only. Surface shared themes:
 - Shared conceptual themes
 - Shared industry-incumbent alerts
 
-Used by `prelim-search` to flag cross-mark risks in synthesis.
+Used by `clearance-search` to flag cross-mark risks in synthesis.
 
 ## Match-mode decision tree (guidance for downstream skills)
 
@@ -449,7 +449,7 @@ Used by `prelim-search` to flag cross-mark risks in synthesis.
 | compound | direct search variations | `match_mode: default` |
 | family-pattern wildcard | not used | Lucene wildcards inside backticks |
 | phrase-substitution | direct search of substituted phrase | `match_mode: default` (NOT `exact`) |
-| competitor-intel / watchlist | focused web search | **Owner-bound search per Step 8.5 of [prelim-register/SKILL.md](../prelim-register/SKILL.md)** |
+| competitor-intel / watchlist | focused web search | **Owner-bound search per Step 8.5 of [clearance-register/SKILL.md](../clearance-register/SKILL.md)** |
 
 Downstream skills do NOT generate their own variants — the manifest is authoritative.