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

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

@@ -1,17 +1,17 @@
 ---
-name: prelim-common-law
-description: Common-law / marketplace execution for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator** — do not call directly. Reads the variant manifest produced by `prelim-variants` and runs structured Perplexity research across the DICTATED platform list (the task message's PLATFORMS block names the exact store domains for this customer; the gaming default is 6 stores) plus general web, social, e-commerce, and industry press. Produces a common-law findings file consumed by the orchestrator for synthesis and Excel assembly. Runs alongside `prelim-register`.
+name: clearance-common-law
+description: Common-law / marketplace execution for the v3 preliminary trademark search workflow. **Invoked exclusively by the `clearance-search` orchestrator** — do not call directly. Reads the variant manifest produced by `clearance-variants` and runs structured Perplexity research across the DICTATED platform list (the task message's PLATFORMS block names the exact store domains for this customer; the gaming default is 6 stores) plus general web, social, e-commerce, and industry press. Produces a common-law findings file consumed by the orchestrator for synthesis and Excel assembly. Runs alongside `clearance-register`.
 ---
 
 ## Spawned session
 
-Invoked from `prelim-search` (orchestrator) alongside `prelim-register`. Reads:
-- The variant manifest at `studio/prelim-search/<slug>/<date>/variant-manifest.md` (produced by `prelim-variants`)
+Invoked from `clearance-search` (orchestrator) alongside `clearance-register`. Reads:
+- The variant manifest at `studio/clearance-search/<slug>/<date>/variant-manifest.md` (produced by `clearance-variants`)
 - The request context (classes, jurisdiction scope, industry, manner of use)
 
 Writes:
-- A common-law findings file at `studio/prelim-search/<slug>/<date>/common-law-findings.md`
-- **The machine grid ledger** at `studio/prelim-search/<slug>/<date>/common-law-grid.json` — the grid
+- A common-law findings file at `studio/clearance-search/<slug>/<date>/common-law-findings.md`
+- **The machine grid ledger** at `studio/clearance-search/<slug>/<date>/common-law-grid.json` — the grid
   call's stdout JSON saved **verbatim** (a single stdout object, or a JSON array of the per-batch
   stdout objects in batch order when the grid is batched). Copy it exactly as the tool returned it —
   no reformatting, no re-typing, no judging. **The driver validates grid completeness from this file**
@@ -29,7 +29,7 @@ Companion files:
 
 ## Trigger
 
-Called by `prelim-search` after `prelim-variants` has produced the manifest. Runs alongside `prelim-register` against the same manifest. Not invoked directly by operators.
+Called by `clearance-search` after `clearance-variants` has produced the manifest. Runs alongside `clearance-register` against the same manifest. Not invoked directly by operators.
 
 ## Model
 
@@ -37,8 +37,8 @@ The model tier is set **by the deterministic driver** — `driver/stages.mjs` is
 source of truth (currently Haiku, low thinking). This worker is extraction, not open analysis: it
 fills templated Perplexity prompts from the manifest and transcribes what Perplexity returns into
 the fixed finding taxonomy. The creative variant/strategy work is already done upstream by
-`prelim-variants` (Opus), and the cross-cutting risk synthesis is the orchestrator's (Opus). If the
-orchestrator's skeptic review (prelim-search Step 2.6) finds this worker shortcut the manifest's
+`clearance-variants` (Opus), and the cross-cutting risk synthesis is the orchestrator's (Opus). If the
+orchestrator's skeptic review (clearance-search Step 2.6) finds this worker shortcut the manifest's
 coverage, it is re-spawned escalated to Opus.
 
 ## Tool call budget
@@ -61,7 +61,7 @@ the artifacts this stage writes, so there is nothing here to call and nothing to
 
 ## Search approval (HITL exception)
 
-The full HITL exception covering this workflow is declared **once** in the orchestrator at [prelim-search/SKILL.md](../prelim-search/SKILL.md#hitl-exception-shared-across-sub-skills). It is pre-approved at workflow trigger time when the requesting lawyer or a staff lawyer forwards the request email.
+The full HITL exception covering this workflow is declared **once** in the orchestrator at [clearance-search/SKILL.md](../clearance-search/SKILL.md#hitl-exception-shared-across-sub-skills). It is pre-approved at workflow trigger time when the requesting lawyer or a staff lawyer forwards the request email.
 
 Operative rules for this sub-skill (Perplexity-side):
 - **Include in queries:** mark name, product type, relevant industry context
@@ -105,14 +105,14 @@ so there is **no partial-delivery fallback**:
 
 ### Out of scope (register-layer concerns)
 
-- USPTO / WIPO / national trademark office database searches — handled by `prelim-register`
+- USPTO / WIPO / national trademark office database searches — handled by `clearance-register`
 - Class-specific register queries
 - Register statistics and filing volumes
 - Stealth-filing pattern analysis
 - Formal enforcement history analysis (organic mentions OK; targeted register-based enforcement search NOT)
 - Prior-art register-based analysis
 
-**Bleed rule:** if register information surfaces organically during a common-law search (e.g., a news article mentions a filing), note it briefly and flag it in the findings file's `Cross-checks suggested` section. Do not pursue it — the orchestrator hands such flags to `prelim-register` for cross-pollination.
+**Bleed rule:** if register information surfaces organically during a common-law search (e.g., a news article mentions a filing), note it briefly and flag it in the findings file's `Cross-checks suggested` section. Do not pursue it — the orchestrator hands such flags to `clearance-register` for cross-pollination.
 
 ## Output — common-law findings file
 
@@ -165,14 +165,14 @@ For game-title rows, the `developer_of_record` and `publisher_of_record` columns
 
 | Finding | Source / Platform | URL | Notes |
 |---|---|---|---|
-| "Raising Your Play" | HP marketing | https://... | HP uses tagline for gaming hardware; no register protection found (flagged for prelim-register cross-check) |
+| "Raising Your Play" | HP marketing | https://... | HP uses tagline for gaming hardware; no register protection found (flagged for clearance-register cross-check) |
 | 1,600+ "Dawn" titles on Steam | Steam | https://... | Crowded field — supportive evidence |
 
 ### Competitor intelligence
 
 | Finding | Source / Platform | URL | Notes |
 |---|---|---|---|
-| Sony "Pulse Elevate" portfolio | Sony products | https://... | Sony uses "Elevate" in audio products; flagged for prelim-register cross-check |
+| Sony "Pulse Elevate" portfolio | Sony products | https://... | Sony uses "Elevate" in audio products; flagged for clearance-register cross-check |
 | Foxglade "Borealis" console "Raise Your Play" tagline (prior usage) | Foxglade Interactive marketing | https://... | Client's own prior use — note as supportive |
 
 ### PR / reputational risk
@@ -356,7 +356,7 @@ forms (and the gap form) — this is what the driver's receipt gate counts:
 ### Coverage ledger (feeds synthesis coverage-honesty + skeptic audit)
 <!-- clearotron:section=coverage-ledger -->
 
-One row per planned coverage unit (each mandatory platform; the field-scoped general search; non-Latin / transliteration platform reach), with status + one-line reason. Same three statuses as the register side (see `prelim-register/SKILL.md` → *Coverage ledger*): `confirmed-clean` (ran to completion), `coverage-limited` (the search **ran and reached the platform** but could not be exhausted — thin data, non-Latin reach), `deferred` (planned but **not run, or the platform/tool could not be reached**). Per the keystone doctrine: a could-not-reach gap (a platform/tool that was unavailable) is `deferred`, never `coverage-limited` — the latter is a searched-but-unexhausted DATA limit. This is the structured form of the Open-verification-flags prose — a `coverage-limited` row is **not** a clean negative downstream.
+One row per planned coverage unit (each mandatory platform; the field-scoped general search; non-Latin / transliteration platform reach), with status + one-line reason. Same three statuses as the register side (see `clearance-register/SKILL.md` → *Coverage ledger*): `confirmed-clean` (ran to completion), `coverage-limited` (the search **ran and reached the platform** but could not be exhausted — thin data, non-Latin reach), `deferred` (planned but **not run, or the platform/tool could not be reached**). Per the keystone doctrine: a could-not-reach gap (a platform/tool that was unavailable) is `deferred`, never `coverage-limited` — the latter is a searched-but-unexhausted DATA limit. This is the structured form of the Open-verification-flags prose — a `coverage-limited` row is **not** a clean negative downstream.
 
 | Coverage unit | Status | Reason |
 |---|---|---|
@@ -364,7 +364,7 @@ One row per planned coverage unit (each mandatory platform; the field-scoped gen
 | field-scoped general search (collab / non-gaming goods) | confirmed-clean | run per matter scope |
 | non-Latin platform reach (translit variants) | coverage-limited | marketplace data thin for non-Latin scripts; absence not confirmed clean |
 
-### Cross-checks suggested (handed to orchestrator for prelim-register dispatch)
+### Cross-checks suggested (handed to orchestrator for clearance-register dispatch)
 
 | Trigger | Suggested cross-check |
 |---|---|
@@ -400,7 +400,7 @@ Four steps per mark.
 
 ### Step 1 — Read variant manifest
 
-Open `studio/prelim-search/<slug>/<date>/variant-manifest.md`. Parse:
+Open `studio/clearance-search/<slug>/<date>/variant-manifest.md`. Parse:
 - Request context: marks, classes, jurisdiction, industry, manner of use
 - Per-mark variant tables — these become the search terms in the Perplexity prompt
 - Watchlists — used for competitor intelligence framing
@@ -446,10 +446,10 @@ filling in:
 
 The tool returns the program's stdout JSON (`cells` + `extras` + `gaps`) and the program code as an
 audit receipt. **Trademark-register lookups stay out of scope** — the grid only searches
-marketplaces/web (the register layer is `prelim-register`'s).
+marketplaces/web (the register layer is `clearance-register`'s).
 
 **LEGACY path only (no `grid_spec_path` given) — immediately after the grid call(s): save the stdout
-JSON verbatim** to `studio/prelim-search/<slug>/<date>/common-law-grid.json` — one call → the stdout
+JSON verbatim** to `studio/clearance-search/<slug>/<date>/common-law-grid.json` — one call → the stdout
 object as-is; batched calls → a JSON array of the per-batch stdout objects, in batch order. This is a
 copy operation, not a writing task: the bytes the tool returned, unmodified. The deterministic driver
 validates the grid by exact join on this file (machine receipts) — the markdown Negative results
@@ -486,7 +486,7 @@ common word) does not. Then categorise each finding into one of:
 - **Competitor intelligence** — watchlist matches; existing partnerships major brands have in the space
 - **PR / reputational risk** — the meaning read of the mark AND its near-forms, scoped by the run's OWN dictated sweep: the fixed meaning / slang / gang / offensive / lookup shapes plus the matter frame's derived `Meaning angles:` queries (cultural origin/appropriation, charged history of the term or its imagery, category-specific controversy — as THIS matter's frame reasoned them). Never a generic sensitivities checklist — the scope IS the dictated sweep. NOT scored on legal-risk framework — separate category. **Every recorded query with results carries a ruling recorded through `record_dispositions`, whatever this section concludes** — reporting a loaded reading does not discharge the rest of the sweep (see the PR / reputational risk contract above). `None identified` is additionally a clean *receipt* ONLY when the meaning sweep ran — cite a `Connotation-search source:` line; the driver rejects an unsearched clean claim (`connotation_search_missing`) and refuses the turn while any ruling is unrecorded (the `connotation_call_*` family). A dictionary gloss is never a clearance.
 - **Negative results** — **one row for EVERY variant × platform grid cell** (the full grid accounting the driver's receipt gate counts), **plus rows for the field-scoped cells** (collab / non-gaming goods) when run. **Each row carries its receipt:** `No results` (the search returned nothing), `No similar listings (N candidates reviewed)` (returned N candidates, none prima facie similar), `Similar listing(s) found — see Findings (N candidates)` (the cell produced findings), or `not executed — coverage-limited (see ledger)` (the cell is in the grid's `gaps` — never a clean negative).
-- **Cross-checks suggested** — register-side checks the orchestrator should dispatch to `prelim-register` (every common-law owner found → ONE register check)
+- **Cross-checks suggested** — register-side checks the orchestrator should dispatch to `clearance-register` (every common-law owner found → ONE register check)
 
 **100% URL coverage is mandatory.** Every finding row must have a clickable URL. If a finding cannot be verified with a URL, mark it as an Open verification flag and note the source.
 
@@ -514,7 +514,7 @@ This requirement applies even when the model running this skill is at the Haiku
 
 ### Step 6 — Compile common-law findings file
 
-Assemble `studio/prelim-search/<slug>/<date>/common-law-findings.md` per the format above. Sections (in order):
+Assemble `studio/clearance-search/<slug>/<date>/common-law-findings.md` per the format above. Sections (in order):
 
 1. **Summary** — call counts, platform coverage, finding counts
 2. **Consumer-confusion risks** — gaming-industry overlap
@@ -545,6 +545,6 @@ Assemble `studio/prelim-search/<slug>/<date>/common-law-findings.md` per the for
 - [ ] Coverage ledger emitted — one row per planned coverage unit; non-Latin / thin-data reach logged `coverage-limited`, not silently clean
 - [ ] Cross-checks suggested section populated
 - [ ] Open verification flags listed (URL-404s, thin coverage, transliteration confirmations)
-- [ ] Common-law findings file written to `studio/prelim-search/<slug>/<date>/common-law-findings.md`
+- [ ] Common-law findings file written to `studio/clearance-search/<slug>/<date>/common-law-findings.md`
 - [ ] Perplexity budget under workflow cap (15 calls)
 - [ ] No client identity, reference numbers, or contact names in any submitted Perplexity prompt

package/driver/skills/{prelim-common-law → clearance-common-law}/perplexity-prompts.md

@@ -1,6 +1,6 @@
 # Perplexity prompts
 
-Templates for the `perplexity_research` calls in `prelim-common-law`. Prompts are **prescriptive, not exploratory** — they tell Perplexity exactly what to search for, where, and how to report.
+Templates for the `perplexity_research` calls in `clearance-common-law`. Prompts are **prescriptive, not exploratory** — they tell Perplexity exactly what to search for, where, and how to report.
 
 ## Depth routing (mandatory)
 

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

@@ -1,11 +1,11 @@
 ---
-name: prelim-register
-description: Register-side execution for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator** — do not call directly. Runs in one of two modes the orchestrator selects via the spawn task. **Unit mode (the FUNNEL — Layer A):** execute ONE register search axis (saturation / primary-sweep / transliteration-numeric / incumbent-class) against the variant manifest — ENUMERATE each named query to completion via `register_enumerate` (the completeness primitive that owns the page loop), describe saturation crowds as count-only incomplete descriptors, and write the COMPLETE NAMED BAND (`register-units/<axis>-band.json`) carrying every record with its status; the funnel decides NOTHING about relevance / sufficiency / prioritisation and never samples or self-accepts; only the raw character-noise pile dies in this session. **Digest mode (judgment — Layer B):** read the complete merged band through the band tools (`band_shape` / `band_lookup` / `band_record` — every call on the run's reading audit; never by slicing band files), run the cross-cutting judgment (relevance, identical-match + cross-class merchandising, owner aggregation, watchlists, stealth-filer + Option-D cross-checks, opposition), decide sufficiency, and hand the register-side findings back as typed rows — the driver renders the document the orchestrator synthesises from; the seat writes no file.
+name: clearance-register
+description: Register-side execution for the v3 preliminary trademark search workflow. **Invoked exclusively by the `clearance-search` orchestrator** — do not call directly. Runs in one of two modes the orchestrator selects via the spawn task. **Unit mode (the FUNNEL — Layer A):** execute ONE register search axis (saturation / primary-sweep / transliteration-numeric / incumbent-class) against the variant manifest — ENUMERATE each named query to completion via `register_enumerate` (the completeness primitive that owns the page loop), describe saturation crowds as count-only incomplete descriptors, and write the COMPLETE NAMED BAND (`register-units/<axis>-band.json`) carrying every record with its status; the funnel decides NOTHING about relevance / sufficiency / prioritisation and never samples or self-accepts; only the raw character-noise pile dies in this session. **Digest mode (judgment — Layer B):** read the complete merged band through the band tools (`band_shape` / `band_lookup` / `band_record` — every call on the run's reading audit; never by slicing band files), run the cross-cutting judgment (relevance, identical-match + cross-class merchandising, owner aggregation, watchlists, stealth-filer + Option-D cross-checks, opposition), decide sufficiency, and hand the register-side findings back as typed rows — the driver renders the document the orchestrator synthesises from; the seat writes no file.
 ---
 
 ## Spawned session
 
-Invoked from `prelim-search` (the orchestrator) as an **isolated depth-2 worker**, in one of two
+Invoked from `clearance-search` (the orchestrator) as an **isolated depth-2 worker**, in one of two
 modes. **This skill never spawns sub-agents** — the orchestrator owns all dispatch. (This is
 deliberate: the announce/completion chain supports one nesting level — `main → orchestrator →
 workers` — so every register worker is a flat depth-2 sibling of the common-law worker, not a nested
@@ -26,16 +26,16 @@ Two modes, chosen by the orchestrator and stated in the spawn `task`:
   band. The worker reads that COMPLETE band **through the band tools** (`band_shape` first, then
   `band_lookup` / `band_record` — every call lands in the reading audit; never by opening or slicing band
   files), performs all cross-cutting judgment (relevance, owner aggregation, opposition, Option-D),
-  DECIDES SUFFICIENCY, and writes `studio/prelim-search/<slug>/<date>/register-findings.md`.
+  DECIDES SUFFICIENCY, and writes `studio/clearance-search/<slug>/<date>/register-findings.md`.
 
-Reads (both modes): the variant manifest at `studio/prelim-search/<slug>/<date>/variant-manifest.md` (archetype + risk
-theory), the `matter-context.md` at `studio/prelim-search/<slug>/<date>/matter-context.md` (Phase 0 strategic anchor — names materially-matters jurisdictions, watchlist-owner seeds, off-field sectors), the request context, the active **provider**. The **watchlist-owner seeds are enrichment / additive-surfacing context, not a search or priority filter** — an in-class identical/near-identical incumbent surfaces on field-relevance alone whether or not its owner is named (see `digest.md` Step 5).
+Reads (both modes): the variant manifest at `studio/clearance-search/<slug>/<date>/variant-manifest.md` (archetype + risk
+theory), the `matter-context.md` at `studio/clearance-search/<slug>/<date>/matter-context.md` (Phase 0 strategic anchor — names materially-matters jurisdictions, watchlist-owner seeds, off-field sectors), the request context, the active **provider**. The **watchlist-owner seeds are enrichment / additive-surfacing context, not a search or priority filter** — an in-class identical/near-identical incumbent surfaces on field-relevance alone whether or not its owner is named (see `digest.md` Step 5).
 
-**Digest mode also reads**: `placement-recommendations.md` at `studio/prelim-search/<slug>/<date>/placement-recommendations.md` (Touchpoint 2 per-candidate placements — informs digest tiering), and its structured mirror `placements.json` beside it (one `{mark, owner, jurisdiction, records, tier, reason}` entry per candidate; when present, the authoritative per-candidate tier record — the md carries the rulings tail as prose).
+**Digest mode also reads**: `placement-recommendations.md` at `studio/clearance-search/<slug>/<date>/placement-recommendations.md` (Touchpoint 2 per-candidate placements — informs digest tiering), and its structured mirror `placements.json` beside it (one `{mark, owner, jurisdiction, records, tier, reason}` entry per candidate; when present, the authoritative per-candidate tier record — the md carries the rulings tail as prose).
 
 Writes:
-- Unit mode — TWO artifacts, both gate-checked, neither optional. `studio/prelim-search/<slug>/<date>/register-units/<axis>.md` is the stage's DECLARED OUTPUT: the driver fails the pass outright when it is absent, and the digest worker reads it as an input. `studio/prelim-search/<slug>/<date>/register-units/<axis>-band.json` is the COMPLETE named band — a JSON array of `enumerated` / `incomplete` blocks (see `unit.md` → *Named-band artifact*) — carrying every record and no clearance verdict. The md narrates and proves nothing on its own: an md narrating a completed sweep while the band its plan entries call for is missing is refused as `named_band_missing`. In plan mode `register_execute_plan` writes the band itself and you never hand-write its blocks.
-- Digest mode: `studio/prelim-search/<slug>/<date>/register-findings.md`. Coverage statuses are NOT a file you write: they ride the `record_coverage` tool into a driver-held record, and the driver renders the `## Coverage ledger` table and its JSON mirror from it (see *Coverage ledger* below and `digest.md` → *Coverage ledger*). Optional: `register-details/` snapshots inside the run-dir.
+- Unit mode — TWO artifacts, both gate-checked, neither optional. `studio/clearance-search/<slug>/<date>/register-units/<axis>.md` is the stage's DECLARED OUTPUT: the driver fails the pass outright when it is absent, and the digest worker reads it as an input. `studio/clearance-search/<slug>/<date>/register-units/<axis>-band.json` is the COMPLETE named band — a JSON array of `enumerated` / `incomplete` blocks (see `unit.md` → *Named-band artifact*) — carrying every record and no clearance verdict. The md narrates and proves nothing on its own: an md narrating a completed sweep while the band its plan entries call for is missing is refused as `named_band_missing`. In plan mode `register_execute_plan` writes the band itself and you never hand-write its blocks.
+- Digest mode: `studio/clearance-search/<slug>/<date>/register-findings.md`. Coverage statuses are NOT a file you write: they ride the `record_coverage` tool into a driver-held record, and the driver renders the `## Coverage ledger` table and its JSON mirror from it (see *Coverage ledger* below and `digest.md` → *Coverage ledger*). Optional: `register-details/` snapshots inside the run-dir.
 
 Returns to the orchestrator: your **final session message** — a 2–3 line summary (counts + the
 absolute path of the file you wrote). Keep raw character-noise records out of the message and out of any
@@ -50,7 +50,7 @@ Companion files:
 
 ## Trigger
 
-Called by `prelim-search` after `prelim-variants` has produced the manifest. The orchestrator spawns
+Called by `clearance-search` after `clearance-variants` has produced the manifest. The orchestrator spawns
 the unit-mode workers and the common-law worker together, then spawns the digest-mode worker once the
 unit digests exist. Not invoked directly by operators.
 

package/driver/skills/{prelim-register → clearance-register}/digest.md

@@ -1,4 +1,4 @@
-# prelim-register — MODE B (DIGEST)
+# clearance-register — MODE B (DIGEST)
 
 > Read `SKILL.md` first (the shared spine). This file is the DIGEST-mode procedure + the register-findings output format. **Do NOT read `unit.md`.**
 
@@ -470,7 +470,7 @@ for the same URI across fields or sources, OR an EUIPO cross-check disagrees wit
 owner identity, OR a portfolio-size signal (many filings clustering under a normalised owner) would
 materially change the enforcement-appetite read, do NOT silently pick one. Surface both readings in the
 findings row and set `Verify? ✅` with reason "owner-identity conflict — confirm before enforcement
-read." Owner identity drives enforcer-profiling (see `prelim-search/firm-wide-reasoning.md`, *Enforcer profiling*
+read." Owner identity drives enforcer-profiling (see `clearance-search/firm-wide-reasoning.md`, *Enforcer profiling*
 rule) — a wrong owner is a wrong risk read.
 
 ### Step 4 — Proactive competitor + aggressive-enforcer sweep

package/driver/skills/{prelim-register → clearance-register}/providers/README.md

@@ -10,7 +10,7 @@ This boundary is enforced by `test/provider-neutral-prose.test.mjs` — it fails
 
 ```bash
 # manual equivalent
-grep -rnE "corsearch_|clarivate_|signa_" ../../prelim-{register,variants,search}/*.md
+grep -rnE "corsearch_|clarivate_|signa_" ../../clearance-{register,variants,search}/*.md
 # should return zero hits OUTSIDE this providers/ directory
 ```
 

package/driver/skills/{prelim-register → clearance-register}/providers/clarivate.md

@@ -44,35 +44,37 @@ claimed. Booleans, parentheses and wildcards are parsed **inside `searchFields[]
 
 | `match_mode` | Field + value shape | Semantics | Probe |
 |---|---|---|---|
-| `default` | `WORD_MARK_SPECIFICATION` = `*TERM*` | **A TRUE CONTAINS** — the substring band | `*NIK*` = 806 |
-| `exact` | `EXACT_WORD_MARK_SPECIFICATION` = `TERM` | Full-string, case-insensitive, **punctuation-sensitive** (punctuation is stripped client-side for you) | `NIKE` = 34 on CH |
-| `wildcard` | `WORD_MARK_SPECIFICATION` = your pattern, untouched | `*` and `?` are native | `NIK*` = 128, `*NIKE` = 36, `NIK?` = 48 |
-| `starts_with` | `WORD_MARK_SPECIFICATION` = `TERM*` | prefix | `NIK*` = 128 |
-| `ends_with` | `WORD_MARK_SPECIFICATION` = `*TERM` | suffix | `*NIKE` = 36 |
+| `default` | `WORD_MARK_SPECIFICATION` = `*TERM*` | **A TRUE CONTAINS** — the substring band | `*TERM*` |
+| `exact` | `EXACT_WORD_MARK_SPECIFICATION` = `TERM` | Full-string, case-insensitive, **punctuation-sensitive** (punctuation is stripped client-side for you) | `TERM` |
+| `wildcard` | `WORD_MARK_SPECIFICATION` = your pattern, untouched | `*` and `?` are native | `TERM*`, `*TERM`, `TER?` |
+| `starts_with` | `WORD_MARK_SPECIFICATION` = `TERM*` | prefix | `TERM*` |
+| `ends_with` | `WORD_MARK_SPECIFICATION` = `*TERM` | suffix | `*TERM` |
 | `phonetic` | `PHONETIC_WORD_MARK_SPECIFICATION` = `TERM` | Native server-side sound-alike. Opaque — no variant list. | — |
 
 `contains` is accepted as an alias of `default` and produces the identical query. There is no separate
 "contains mode" to reach for any more.
 
-**Booleans are explicit and native.** `"NIKE OR ADIDAS"` = 38 = 34 + 4 exactly. `AND` works. `NOT` works
-(`"NIK* NOT NIKE"` = 94 = 128 − 34). Parentheses group. Regex is not supported (`/NIK./` = 0) despite
-what the field description hints.
+**Booleans are explicit and native**, and they are evaluated as real set operations rather than as text.
+An `OR` stack answers the union of its legs — on two names that share no marks that is the two totals
+added, and on names that overlap it is less, because nothing is counted twice. `AND` and `NOT` compose the
+same way. Parentheses group. Regex is not supported despite what the field description hints: a regex
+value matches nothing rather than erroring.
 
-**Multi-word terms work — pass them normally.** A bare space is an implicit *AND*
-(`*KESTREL BEVERAGE*` = `*KESTREL* AND *BEVERAGE*` = 75, and it is order-blind: `*CORAL PUP*` =
-`*PUP CORAL*` = 11), so the tool compiles your phrase to the **ADJ** adjacency operator instead —
-`*CORAL ADJ PUP*`, an ordered phrase match (11 hits; reversed = 0). You write the term the way a
+**Multi-word terms work — pass them normally.** A bare space is an implicit *AND*, and it is order-blind,
+so the tool compiles your phrase to the **ADJ** adjacency operator instead — an ordered phrase match,
+which matches only the order you write it in. You write the term the way a
 lawyer would say it; the tool does the translation. This applies to `default`/`contains`/`wildcard`/
 `starts_with`/`ends_with`/`phonetic` alike.
 
 Two things to know when you read the results:
 
 - **A multi-word `starts_with`/`ends_with` is not anchored.** No string anchor exists on this provider
-  (`BEGINS_WITH "ALPINE SPRING"` = 9 vs the phrase's 7), so it runs as a phrase-*contains* — a superset
-  of what you asked. Extra hits, never fewer. Screen them as usual.
+  (`BEGINS_WITH` on a multi-word value degrades to a per-token AND, which is a superset of the ordered
+  phrase), so it runs as a phrase-*contains* — a superset of what you asked. Extra hits, never fewer.
+  Screen them as usual.
 - **`exact` is still the tightest read** — `EXACT_WORD_MARK_SPECIFICATION` is an ordered whole-string
-  match ("KESTREL BEVERAGE" = 4, "BEVERAGE KESTREL" = 0). Use it when you want the mark itself, not the
-  neighbourhood.
+  match — the whole string as written, so the same words in another order are a different string. Use it
+  when you want the mark itself, not the neighbourhood.
 
 **A term you pass is never silently re-parsed.** Parentheses, or (outside `wildcard`) a stray `*`/`?`,
 are **REJECTED** with a plain-English error and the slice defers — there is no escape syntax for those.
@@ -80,9 +82,9 @@ An operator word *inside* a phrase is handled for you: "BLACK AND DECKER" goes o
 `*BLACK ADJ A?D ADJ DECKER*` (the `?` stops the parser reading AND as an operator). The one term that
 still defers is a bare two-letter operator word — `OR` alone has no interior character to wildcard.
 
-`names[]` (an OR-stack) becomes ONE value joined with explicit ` OR `. The safe width is **500 terms**
-(80/200/500 all fine; 1000 → HTTP 500 *"Document nesting depth (1001) exceeds the maximum allowed"*).
-`register_enumerate` chunks wider stacks for you at that bound.
+`names[]` (an OR-stack) becomes ONE value joined with explicit ` OR `. The safe width is **500 terms** —
+the bound is the JSON parser's document-nesting cap, which the register names in the refusal it answers a
+wider stack with. `register_enumerate` chunks wider stacks for you at that bound.
 
 ## Filters
 
@@ -99,8 +101,8 @@ still defers is a bare two-letter operator word — `OR` alone has no interior c
 
 ### Multi-class is ONE call — the fan-out is gone
 
-`INT_CLASS_NUMBER` value `"9 OR 28 OR 41 OR 42"` returns **18** — identical to the deduplicated union of
-four per-class calls (`"9,28,41,42"` also = 18). The old per-class fan-out and its `warnings[]` cost
+`INT_CLASS_NUMBER` value `"9 OR 28 OR 41 OR 42"` returns the deduplicated union of what four per-class
+calls returned — the comma form `"9,28,41,42"` is the same. The old per-class fan-out and its `warnings[]` cost
 breakdown have been **deleted from the core**. N classes cost one call; budget accordingly, and ignore
 any older guidance that told you to size a class fan-out.
 
@@ -113,8 +115,8 @@ becomes a `deferred` coverage row — it is never quietly dropped from the filte
 
 ### Owner search — resolve first, and never emit CONTAINS
 
-`APPLICANT_NAME` supports `EQUALS` (156 hits), `BEGINS_WITH` (159), wildcards (`"NIKE*"` with EQUALS =
-159, i.e. equivalent to BEGINS_WITH), and `OR`. **`CONTAINS` is a hard HTTP 400** —
+`APPLICANT_NAME` supports `EQUALS`, `BEGINS_WITH`, wildcards (a trailing `*` with EQUALS is equivalent to
+`BEGINS_WITH`), and `OR`. **`CONTAINS` is a hard HTTP 400** —
 *"Operator CONTAINS is not supported for search field APPLICANT_NAME"* — and is never emitted anywhere.
 
 This provider has something Corsearch does not: **`POST /resolution/company`** returns confidence-scored
@@ -125,13 +127,12 @@ a narrower one. The result carries an `owner_resolution` note; cite it when the
 
 ## Completeness, crowds and the ceiling
 
-`/search` has **no pagination** and needs none: it returns the whole guid set (128 guids for a count of
-128; 806 for 806). Past 30 000 it **fails loud**: HTTP 400 *"tooManyResults — The search returned 209012
-results. Maximum number of results is 30000."*
+`/search` has **no pagination** and needs none: it returns one guid for every hit the count reports, at
+any size below the ceiling. **The ceiling is 30 000**, and past it the search **fails loud** with a
+`tooManyResults` HTTP 400 naming that maximum and how many results the search reached.
 
 `register_enumerate` therefore probes `POST /count` first. `/count` is cheap, takes the same body, works
-at **any** magnitude, and returns per-office counts in one call
-(`{"counts":{"CH":34,"EM":60,"WO":7,"CN":14345,"GB":91,"US":138}}`).
+at **any** magnitude, and returns a `counts` object keyed by office code in one call.
 
 **A `tooManyResults` / over-ceiling band is `state:"incomplete"` — a CROWD DESCRIPTOR, never an error and
 never a clean negative.** It is dilution the lawyer reads. On this provider the crowd block also carries
@@ -156,7 +157,7 @@ identical-match is class-agnostic.
 
 ## Records — `register_record_fetch` / `register_batch_screen`
 
-`/text` takes **exactly 100 ids** per call (101+ → HTTP 400); the adapter chunks at 100. Response splits
+`/text` takes **exactly 100 ids** per call and refuses a longer list; the adapter chunks at 100. Response splits
 into `trademarks[]` and `nonTrademarks[]` (design-only / bookkeeping artefacts — generally skip, but
 sanity-check it if results look sparse).
 
@@ -205,16 +206,17 @@ silently omit the dimension.
 - **No regex** — wildcards and booleans cover the plan vocabulary.
 - **No cross-language single query** — run the variant manifest per script.
 - **No native-script search — send the ROMANISATION instead.** This index holds non-Latin marks by
-  their transliteration and does not hold the characters at all. `华威豹` answers **0**; its own
-  transliteration `HUA WEI BAO` answers **32**, and those 32 include 华威豹. Same for `小米` (0) vs
-  `XIAOMI` (57632). Universal — every non-Latin record sampled across CN/TW/JP/KR/TH/GR/UA/EG/SA/IL
+  their transliteration and does not hold the characters at all. A native-script term answers nothing;
+  its own transliteration answers records that carry those very characters. Universal — every non-Latin
+  record sampled across CN/TW/JP/KR/TH/GR/UA/EG/SA/IL
   carried a populated `markTransliteration`. A native term you send is REFUSED client-side (a 0 here
   would read as clean), so send the romanised form and say in the report that the register was
   searched by transliteration. Two rules that come with it:
   - use **contains, not `exact`** — the office writes its own spacing and trailing tokens, so
-    `exact` on a transliteration is a silent zero (GR 0/10, EG 0/7);
-  - the romanisation is **broader than the characters, not narrower** — it catches homophone
-    variants (`HUA WEI BAO` → 华威豹, 华味宝, 华为爆破), which is the shape most Chinese squatting takes.
+    `exact` on a transliteration can be a silent zero where the same term under contains answers;
+  - the romanisation is **broader than the characters, not narrower** — the search key is the
+    romanisation, so it returns every character set filed under that pronunciation and not only the one
+    you meant, which is the shape most Chinese squatting takes.
 
 Each of these, when it blocks a dictated slice, is a **`deferred` coverage row** — escalate and disclose.
 Never substitute a weaker query under the same heading.

package/driver/skills/{prelim-register → clearance-register}/providers/corsearch.md

@@ -22,17 +22,26 @@ Auth: `CORSEARCH_SESSION_KEY` environment variable, supplied from the deployment
 
 Corsearch's supremesearch API uses single-character prefixes on field names. All field values must be **backtick-quoted** (the plugin handles this).
 
-| Match mode | API prefix | Semantics | Hit volume (NIKE benchmark) |
+| Match mode | API prefix | Semantics | Budget as |
 |---|---|---|---|
-| `default` | (none) | Exact-token, case-insensitive — catches tokenisation splits and case variations | ~15,083 |
-| `exact` | `=` | Strictest — full-string match | ~3,014 |
-| `phrase` | `"` | Ordered phrase match | ~10,075 |
-| `starts_with` | `^` | Prefix | ~7,681 |
-| `ends_with` | `$` | Suffix | ~8,248 |
-| `phonetic` | `*` (or `P`) | Server-side phoneme match; extend with `phonetic_variants[]` | ~5,854 bare / ~6,022 with variants |
-| `fuzzy` | `~` | Approximate (diacritics, transliterations) | ~143,184 |
+| `default` | (none) | Exact-token, case-insensitive — catches tokenisation splits and case variations | a read |
+| `exact` | `=` | Strictest — full-string match | a read |
+| `phrase` | `"` | Ordered phrase match | a read |
+| `starts_with` | `^` | Prefix | a read |
+| `ends_with` | `$` | Suffix | a read |
+| `phonetic` | `*` (or `P`) | Server-side phoneme match; extend with `phonetic_variants[]` | a read |
+| `fuzzy` | `~` | Approximate (diacritics, transliterations) | **a crowd** |
 | `not` | `!` (or `-`) | Complement; useful in compound queries | — |
-| `must` | `&` | Force AND within same-field stacking | ~433 (NIKE + ADIDAS) |
+| `must` | `&` | Force AND within same-field stacking | a read |
+
+Two facts about size, and no more than two, because a mode's breadth is a fact about the mark you send and
+not about the mode: **`fuzzy` answers an order of magnitude wider than anything else here** — budget it as
+a crowd unless you have narrowed it another way — and **`must` and `exact` are the two narrowest**, which
+is what to reach for when a band has to be read rather than screened.
+
+No mode's results contain another's. A prefix and a suffix each hold marks the other does not, a
+sound-alike need not begin with your letters, and an intersection is not a subset of either half — so
+running the wider one does not cover the narrower one, and a leg you drop is a leg nobody searched.
 
 **Critical:** No explicit `AND` / `OR` keywords — those return HTTP 400. Composition is space-separated. Repeated fields = implicit OR. Use `must` prefix for AND within same field. Repeated `nice-class:` fields are therefore an implicit-OR union — `nice_classes:[9,28,41,42]` correctly scopes to *any of* those classes.
 
@@ -150,7 +159,7 @@ Capture VERBATIM in the register findings file's "Opposition history" section. D
 
 Corsearch supports phoneme expansion via `register_expand_phoneme`. Returns `{ base, aiVariants[] }`. Use the variants as `phonetic_variants[]` in `register_search` with `match_mode: "phonetic"`.
 
-Declared languages: `en_US` (~29 variants per word), `de_DE` (~29), `fr_FR` (~49). Other languages (`it_IT`, `es_ES`) are supported by the API but UNDECLARED here — treat them as a stated unknown, not as unavailable.
+Declared languages: `en_US`, `de_DE`, `fr_FR` — each returns a few dozen variants for a typical word. Other languages (`it_IT`, `es_ES`) are supported by the API but UNDECLARED here — treat them as a stated unknown, not as unavailable.
 
 **Usage pattern:** for multi-language jurisdictions, call expand-phoneme once per relevant language, concatenate `aiVariants[]`, pass to a single search call. Don't run multiple separate phonetic searches — costs more, returns largely overlapping results.
 
@@ -165,7 +174,7 @@ Only invoke for marks where `markFeature: "Figurative"` or `markFeature: "Stylis
 Be aware these capabilities are missing, so the skill doesn't promise them:
 
 - **POCA scoring** — not available through this adapter. Skill returns `null`
-- **Cross-language search within one query** — Corsearch doesn't support "search this mark in Japanese AND English in one query." Skill handles this by generating transliteration variants in `prelim-variants` and querying each separately.
+- **Cross-language search within one query** — Corsearch doesn't support "search this mark in Japanese AND English in one query." Skill handles this by generating transliteration variants in `clearance-variants` and querying each separately.
 - **Server-side stem-folding** — present but not configurable (the default match-mode tokenizer catches LEGEND ↔ LEGENDS). The variant manifest's `plural-root` category encodes this — search the root form to catch inflected forms.
 
 ## Provider-specific behaviour

package/driver/skills/{prelim-register → clearance-register}/providers/signa.md

@@ -125,8 +125,8 @@ difference is not a margin. On the same term:
 
 | request | national | regional | madrid |
 |---|---|---|---|
-| `filters.offices: ["inpi-fr"]` | 6898 | 0 | 0 |
-| `filters.jurisdictions: ["FR"]`, protection | 6898 | 10000+ | 2708 |
+| `filters.offices: ["inpi-fr"]` | yes | **none** | **none** |
+| `filters.jurisdictions: ["FR"]`, protection | yes | yes | yes |
 
 **So an EU trade mark that blocks use in France is now found**, and it never appears in the French
 register. Every covered territory reaches its Madrid layer this way and the EU members additionally reach
@@ -154,10 +154,10 @@ French national marks. On the same term:
 
 | what the executor sends | national | regional | Madrid |
 |---|---|---|---|
-| `filters.offices: ["inpi-fr"]` (the shape this doc used to describe) | 6898 | 0 | 0 |
-| `filters.jurisdictions: ["FR"]`, `territory_match: "protection"` | 6898 | 10000+ | 2708 |
+| `filters.offices: ["inpi-fr"]` (the shape this doc used to describe) | yes | **none** | **none** |
+| `filters.jurisdictions: ["FR"]`, `territory_match: "protection"` | yes | yes | yes |
 
-It is ONE call, not three. A territory under no regional register — Switzerland — returns regional 0 either
+It is ONE call, not three. A territory under no regional register — Switzerland — gains no regional rows either
 way and still reaches its Madrid layer, which is what shows `protection` adds a LAYER rather than just more
 rows.
 

package/driver/skills/{prelim-register → clearance-register}/register-recipes.md

@@ -26,7 +26,7 @@ sufficiency, and prioritisation. See [unit.md](unit.md).
 > match-mode, never "all classes". The ONLY all-class enumerate is the exact-IDENTICAL cross-class merch check
 > (`match_mode:exact`, `nice_classes:[25]`). `fuzzy` is never an enumerate mode.
 
-**Execution note:** `prelim-register` now runs as a worker that decomposes these axes into isolated
+**Execution note:** `clearance-register` now runs as a worker that decomposes these axes into isolated
 search **units** (saturation-probe / primary-sweep / transliteration-numeric / incumbent-class /
 merch-sweep), each executing one axis and writing its named-band array (`register-units/<axis>-band.json`).
 If you are a unit, run only your assigned axis from the recipe below; the judgment worker (Layer B) performs
@@ -190,7 +190,7 @@ For each transliteration variant in the manifest:
    → transliteration plausibility is a verification flag for the lawyer (Verify? ✅)
 ```
 
-**Important:** transliteration hits are NOT confirmed without senior-lawyer sign-off. Claude generates plausible transliterations but Korean/Arabic/etc native speakers must confirm. The `Verify? ✅` flag from `prelim-variants` carries through to the band so judgment surfaces it. The funnel does not decide a transliteration is wrong — it enumerates and passes the record with its flag.
+**Important:** transliteration hits are NOT confirmed without senior-lawyer sign-off. Claude generates plausible transliterations but Korean/Arabic/etc native speakers must confirm. The `Verify? ✅` flag from `clearance-variants` carries through to the band so judgment surfaces it. The funnel does not decide a transliteration is wrong — it enumerates and passes the record with its flag.
 
 **Breadth note (this recipe shares a unit with the per-jurisdiction named queries).** Both the script-group enumerations here and the material-jurisdiction named queries are owned by the `transliteration-numeric` unit, and **both are enumerated** — there is no "yield one to fund the other" sufficiency trade any more. `register_enumerate` owns each query's page loop; the unit runs every variant query the manifest declares. If a query genuinely cannot run (provider error), that surfaces as an `incomplete` block, not a silently-dropped sweep.
 
@@ -331,7 +331,7 @@ by goods **words**. The everyday-word saturation is the trigger to **scope the n
 class)** — never to drop the token, re-narrow it to a more specific concept, or swap it for the phonetic form. The
 saturated meaning token is enumerated like any other named slice; the lawyer reads it. (This is the register half
 of the variant-stage everyday-word-first rule — see
-[transliteration-scripts.md](../prelim-variants/transliteration-scripts.md): the everyday word is kept upstream,
+[transliteration-scripts.md](../clearance-variants/transliteration-scripts.md): the everyday word is kept upstream,
 class-scoped and enumerated here.) Reuse steps 1–2 above with the class-scoped meaning token as the `register_enumerate` predicate.
 
 **Expected output:** on a saturated field, the complete enumerated near-exact in-class band (live + dead with status) the ranker's top-N paging would have buried, plus the phonetic-fringe band — each as an `enumerated` block, or an `incomplete` descriptor where a slice was a genuine crowd. On a non-saturated field this recipe does not fire.

package/driver/skills/{prelim-register → clearance-register}/status-rules.md

@@ -1,6 +1,6 @@
 # Status rules — status classification, Madrid handling, non-Latin status strings
 
-Cross-referenced from [prelim-register/SKILL.md](SKILL.md) — the canonical entry point. The provider files and stealth-filer indicators link here for the status-classification rules; the orchestrator never reads this file directly.
+Cross-referenced from [clearance-register/SKILL.md](SKILL.md) — the canonical entry point. The provider files and stealth-filer indicators link here for the status-classification rules; the orchestrator never reads this file directly.
 
 > **Funnel vs judgment (read this first).** Under the two-layer split, the **funnel (Layer A) does NOT drop
 > records on status** — `register_enumerate` carries **every** record forward (live AND dead) **with its
@@ -226,7 +226,7 @@ For owner country:
 
 If after the full fallback chain the owner is still empty, set owner column to `(unknown — confirm)` and add to Open verification flags.
 
-**Owner-identity conflict.** If two fields in the chain (or an EUIPO cross-check vs the vendor record) yield *materially different* owner names for the same URI, do NOT silently pick the first — record both candidate names in the owner field and set `Verify? ✅` with reason "owner-identity conflict — confirm before enforcement read." Likewise, when a portfolio-size signal (many filings clustering under one normalised owner) would change the enforcement-appetite read, surface it. Owner identity drives enforcer-profiling (`prelim-search/firm-wide-reasoning.md`, *Enforcer profiling*) — a wrong owner is a wrong risk read.
+**Owner-identity conflict.** If two fields in the chain (or an EUIPO cross-check vs the vendor record) yield *materially different* owner names for the same URI, do NOT silently pick the first — record both candidate names in the owner field and set `Verify? ✅` with reason "owner-identity conflict — confirm before enforcement read." Likewise, when a portfolio-size signal (many filings clustering under one normalised owner) would change the enforcement-appetite read, surface it. Owner identity drives enforcer-profiling (`clearance-search/firm-wide-reasoning.md`, *Enforcer profiling*) — a wrong owner is a wrong risk read.
 
 ### USPTO extended country codes
 

package/driver/skills/{prelim-register → clearance-register}/stealth-filer-indicators.md

@@ -2,7 +2,7 @@
 
 Detect "law firm as owner" (i.e., the registered owner is a legal-services entity rather than the underlying client) via the following regex / substring patterns. Any match flags the row as a candidate stealth filing — surface this in the Findings sheet and feed it into Option D Trigger 2 (one common-law query for the underlying client's marketplace use).
 
-Canonical entry point: [prelim-register/SKILL.md](SKILL.md) lists this file and `status-rules.md` as siblings; this file references back to `status-rules.md` only for the owner-extraction fallback chain it depends on.
+Canonical entry point: [clearance-register/SKILL.md](SKILL.md) lists this file and `status-rules.md` as siblings; this file references back to `status-rules.md` only for the owner-extraction fallback chain it depends on.
 
 ## Indicator patterns
 

package/driver/skills/{prelim-register → clearance-register}/unit.md

@@ -1,4 +1,4 @@
-# prelim-register — MODE A (UNIT)
+# clearance-register — MODE A (UNIT)
 
 > Read `SKILL.md` first (the shared spine: Spawned session, Model, Provider, Tool call budget, the band-block coverage model, Failure fallback). This file is the UNIT-mode procedure only. **Do NOT read `digest.md`** — that is digest-mode judgment a unit must never run.
 
@@ -52,7 +52,7 @@ You were spawned to run exactly ONE axis named in your task. Read the manifest +
    - **off-field-drop on goods** — brand-json has no goods/services text; an in-scope-class live record is carried forward and the lawyer decides on its actual goods/services. (`screen_verdict` is enrichment for judgment, not a funnel drop authority.)
    - **sample or self-accept** — no top-N, no "narrow to tractable and stop", no per-jurisdiction 3-fetch ceiling, no switch-to-exact-standalone-as-enumeration. Those were funnel sufficiency calls; they are **deleted**. The tool enumerates or reports incomplete — there is no in-between for you to author.
 6. **Surface dead records WITH their status — no funnel date-cutoff.** Carry every record `register_enumerate` returns **with its `status`** (live / lapsed / expired / lapse-date in the record's dates). You do **NOT** apply a recency/date threshold and you do **NOT** drop dead-except-identical. **`recently-dead` is a STATUS for judgment**, not a funnel filter: whether a recently-lapsed near-identical matters (revival window, field history, non-use vulnerability) is the lawyer's call (Layer B), made on the status + lapse date you passed through. Volume is handled by the completeness contract (step 3): if the dead-inclusive named band is bounded, `register_enumerate` returns it `enumerated`; if it is a crowd, it returns `incomplete` → descriptor. You pass the fact; judgment weighs it. (The old D4 ≤5y date-cutoff drop is **removed** — it was a funnel-side judgment.)
-7. **Write the band artifact, then return.** Write `register-units/<axis>-band.json` (the named-band array, schema below) to `studio/prelim-search/<slug>/<date>/register-units/<axis>-band.json`, **before you return — returning without it is a failure** (the deterministic driver gates on this file: if it is missing after your turn it fails the stage and retries it under a fresh session key; a band that never lands as a file is lost work). Then **file your audit note by calling `record_unit_note`** — you do not write it, and the dispatch hands you no path for it: the driver renders it from your call. **The counts are not yours to type.** Queries enumerated, incomplete blocks and records carried forward are taken from the band you just wrote, so the note and the band cannot disagree; a note filed before the band exists is refused by name, because an account of a sweep that has not happened is not a short note but a wrong one. What you send is the half the band cannot say: `null_result` if this axis genuinely found nothing (refused against a band that carries records), and `note` — one short observation an auditor would want, in a lawyer's words. **The raw character-noise pile stays in this session** — what crosses the firewall is the **complete named band + crowd descriptors** (the `<axis>-band.json` array), NOT the raw rows. Do **not** apply a relevance gate, do **not** aggregate owners, do **not** decide sufficiency — those are judgment's job (Layer B).
+7. **Write the band artifact, then return.** Write `register-units/<axis>-band.json` (the named-band array, schema below) to `studio/clearance-search/<slug>/<date>/register-units/<axis>-band.json`, **before you return — returning without it is a failure** (the deterministic driver gates on this file: if it is missing after your turn it fails the stage and retries it under a fresh session key; a band that never lands as a file is lost work). Then **file your audit note by calling `record_unit_note`** — you do not write it, and the dispatch hands you no path for it: the driver renders it from your call. **The counts are not yours to type.** Queries enumerated, incomplete blocks and records carried forward are taken from the band you just wrote, so the note and the band cannot disagree; a note filed before the band exists is refused by name, because an account of a sweep that has not happened is not a short note but a wrong one. What you send is the half the band cannot say: `null_result` if this axis genuinely found nothing (refused against a band that carries records), and `note` — one short observation an auditor would want, in a lawyer's words. **The raw character-noise pile stays in this session** — what crosses the firewall is the **complete named band + crowd descriptors** (the `<axis>-band.json` array), NOT the raw rows. Do **not** apply a relevance gate, do **not** aggregate owners, do **not** decide sufficiency — those are judgment's job (Layer B).
 
 ## What else your grant carries, and why you do not call it