clearotron 0.4.0 → 0.4.1-beta.0

package/driver/skills/clearance-search/phase2-execution.md

@@ -17,7 +17,7 @@
   - [Variant execution strategy (register layer)](#variant-execution-strategy-register-layer)
 - [Step 2.6 — Skeptic review](#step-26--skeptic-review-a-fresh-eyes-self-audit-before-you-trust-the-findings)
 - [Step 3 — Cross-pollination (Option D — deterministic cross-checks, cap N=10)](#step-3--cross-pollination-option-d--deterministic-cross-checks-cap-n10)
-- [Step 3.5 — Actual-use check (mandatory for Medium/High/Very High register hits)](#step-35--actual-use-check-mandatory-for-mediumhighvery-high-register-hits)
+- [Step 3.5 — Actual-use and enforcement check (mandatory for register hits rated medium risk or higher)](#step-35--actual-use-and-enforcement-check-mandatory-for-register-hits-rated-medium-risk-or-higher)
 - [Step 3.6 — Owner workup (mandatory for high-risk findings)](#step-36--owner-workup-mandatory-for-high-risk-findings)
 - [Step 4 — Joint synthesis](#step-4--joint-synthesis)
 - [Step 4.5 — Case-law grounding](#step-45--case-law-grounding)
@@ -78,7 +78,7 @@ skipped step must be logged with its reason in the unit's digest audit.
 1. **Macro probes** — one search per element of the compound + one for the full compound phrase (limit=10 each), to establish saturation levels. Minimum 3 searches. SKIP only if all elements are non-common-words (rare).
 2. **Compound-phrase sweeps** — the compound phrase across **three match-modes (exact, phrase, default)**, limit=100 per search. Minimum 3 searches. SKIP only if the phrase is a single word (then it's a single-word funnel, not compound).
 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`).
+4. **Wildcard reorders** — if the manifest lists word-order variants, at least one wildcard sweep per distinct ordering (e.g. `Raise * play`, `play * Raise`).
 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). 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.
 
@@ -230,9 +230,9 @@ Cap-overflow MUST be flagged in the deliverable audit trail with a specific reas
 
 Every cross-check (including "checked, found nothing") logged in the unified audit trail as proof-of-work. The collaborator value-add (vs assistant) is in this section: synthesis can be decisive ("HP uses, does not register → Level 2 B") rather than tentative ("recommend the staff lawyer check HP register").
 
-## Step 3.5 — Actual-use check (mandatory for register hits above the framework's lowest band)
+## Step 3.5 — Actual-use and enforcement check (mandatory for register hits rated medium risk or higher)
 
-Before synthesis, for **every register finding** advisory-rated **above the framework's lowest band**, run a marketplace check via `perplexity_research` to determine whether the registered mark is **actually being used in the marketplace within the scope of the current search** (i.e. for the goods/services and field this clearance targets).
+Before synthesis, for **every register finding** advisory-rated on a rung **the framework rates medium risk or higher** (the stage message names those rungs; a rung below that is not checked, on any client's ladder), run a marketplace check via `perplexity_research` to determine whether the registered mark is **actually being used in the marketplace within the scope of the current search** (i.e. for the goods/services and field this clearance targets). **The same query also asks for the owner's enforcement record:** whether the owner has opposed, disputed or sued over this mark or a similar one.
 
 Example: a JELLY register hit owned by Jellycat (a toy company) for Class 9 video game software — check whether Jellycat actually sells or markets video games under JELLY. If they don't (their commercial use is toys), note the filed-vs-used distinction in Key Factors and weigh it as a Stage-2 factor together with revocation-vulnerability — no automatic downgrade (see `synthesis-rules.md` → *Actual-use assessment results*).
 
@@ -244,6 +244,7 @@ Example: a JELLY register hit owned by Jellycat (a toy company) for Class 9 vide
 - If actual use in the relevant field is **not found** (despite the filing), do **NOT** automatically downgrade — weigh the lack of field use as a Stage-2 factor together with revocation-vulnerability (`synthesis-rules.md` → *Actual-use assessment results* / *Rule on downgrade quantum*), and note in Key Factors: "Register filing claims [field] but no marketplace use identified — filed-vs-used noted; weighed with revocability."
 - This check measures *use in the field*, not registry status: a renewal / re-registration / "Registered" status is administrative upkeep, not marketplace use, and does not satisfy the actual-use check or defeat a non-use mitigant (see `synthesis-rules.md` → "Administrative liveness is not market use").
 - Owner-portfolio-bound common-law checks already counted in this step count toward the Option D cap (Step 3).
+- **Enforcement the query finds is a lead, not a verified authority** (the ENFORCEMENT AUTHORITY rule in the stage message): it informs the enforcer meter with basis `inferred-from-signal`, and its URL is cited inline in the finding's prose. If the query finds no enforcement record, the enforcer is `low` with basis `inferred-from-signal`, and the finding says the search found none. The enforcer stays `unknown`, and nothing is claimed, only when the query could not run.
 
 **Output contract — ENFORCED by the driver (spec 11), not optional.** For every Composite 3+ finding whose
 mitigant or verdict turns on the **absence** of use (it says the mark is "not in actual use" / "unused" / has
@@ -360,7 +361,7 @@ the verdict** (the driver decides this in code):
 Runs **ONCE**, after all marks have completed Steps 2–4.5. Review findings across all marks and identify:
 
 1. **Shared findings:** a single entity/finding relevant to more than one proposed mark (e.g., "Prize Crate Retail" is relevant to both "PRIZE CRATE" and "CAVERN CRATES")
-2. **Pattern findings:** recurring themes across marks (e.g., "the 'loot' prefix is crowded across all gaming platforms")
+2. **Pattern findings:** recurring themes across marks (e.g., "the 'prize' prefix is crowded across all gaming platforms")
 3. **Compound risk:** where the combination of marks might amplify risk (e.g., using both "PRIZE CRATE" and "CAVERN CRATES" increases the chance of a dispute with Prize Crate Retail)
 
 For each cross-reference: note which marks are affected, describe the connection, flag any compounding risk. Cross-references appear in the narrative summary and as a note in the Findings sheet.

package/driver/skills/clearance-search/synthesis-rules.md

@@ -28,7 +28,7 @@ Across the synthesis, two postures are load-bearing:
 - [Per-finding synthesis structure](#per-finding-synthesis-structure)
 - [Cancelled / invalid marks — include if exact, no commentary](#cancelled--invalid-marks--include-if-exact-no-commentary)
 - [The mark itself — standing assessment (every run)](#the-mark-itself--standing-assessment-every-run)
-- [Filed-vs-used check — mandatory for findings above the lowest band](#filed-vs-used-check--mandatory-for-findings-above-the-lowest-band)
+- [Filed-vs-used check — mandatory for findings rated medium risk or higher](#filed-vs-used-check--mandatory-for-findings-rated-medium-risk-or-higher)
 - [Prosecution history — mandatory for identical-mark hits in relevant classes](#prosecution-history--mandatory-for-identical-mark-hits-in-relevant-classes)
 - [Revocability — mandatory assessment for register findings above the lowest band](#revocability--mandatory-assessment-for-register-findings-above-the-lowest-band)
 - [Verify-or-defer — procedure, deadlines, registry statistics](#verify-or-defer--procedure-deadlines-registry-statistics)
@@ -449,15 +449,15 @@ reviewing lawyer to assess), frames the report, and **never moves any band**.
   into a longer paragraph. Real PR / reputational **hits** still live in the PR / reputational section (see
   above); this block is the standing read, not the incident report.
 
-## Filed-vs-used check — mandatory for findings above the lowest band
+## Filed-vs-used check — mandatory for findings rated medium risk or higher
 
-For every register finding advisory-rated ABOVE the framework's lowest band, synthesis runs an actual-use marketplace check via `perplexity_research` (see `phase2-execution.md` Step 3.5), scoped to owner + mark + the goods/field, and **records the result inline**. Any finding whose mitigant turns on the *absence* of use (non-use revocation/cancellation, "not in actual use", "no marketplace use found", "owner's use unknown") MUST carry a `- **Use-check source:** <URL | "perplexity_research — no result">` line — the driver's `narrative` validator rejects the narrative otherwise (spec 11). A use-negative is sayable **only** when a search produced it; an inference from the owner's profile ("a music act → probably no game use") is **not** a searched result and must be either run or labelled an inference, never dressed as a clean negative.
+For every register finding advisory-rated on a rung the framework rates medium risk or higher, synthesis runs an actual-use marketplace check via `perplexity_research` (see `phase2-execution.md` Step 3.5, which also asks for the owner's enforcement record), scoped to owner + mark + the goods/field, and **records the result inline**. Any finding whose mitigant turns on the *absence* of use (non-use revocation/cancellation, "not in actual use", "no marketplace use found", "owner's use unknown") MUST carry a `- **Use-check source:** <URL | "perplexity_research — no result">` line — the driver's `narrative` validator rejects the narrative otherwise (spec 11). A use-negative is sayable **only** when a search produced it; an inference from the owner's profile ("a music act → probably no game use") is **not** a searched result and must be either run or labelled an inference, never dressed as a clean negative.
 
 ## Own-rights evidence — mandatory when reasoning relies on the client's house mark (spec-v3 A4)
 
 The same enforced contract applies to the client's OWN rights: if a finding's clearance reasoning relies on the client's house mark or franchise root ("the prefix is the client's own registered mark"), synthesis runs ONE own-portfolio check over the run's FROZEN register material — `band_lookup` with `owner:<the applicant/house-mark owner>` (plus `band_record` for any registration cited) — and the finding MUST end with a `- **Own-rights source:** <record URI(s) | "no applicant-owned registrations in the searched register material">` line — the driver's `narrative` validator rejects the narrative otherwise. **Know what the negative means:** the frozen material covers only this matter's dispatched slices (its classes, its mark texts), so an empty owner lookup is NEVER evidence the client's registrations do not exist — a house mark's registrations usually live in the client's home classes under mark text no slice covers. Never write "no registrations found" or any portfolio-wide register-negative: state the honest scoped negative, let the reasoning stand or fall without the crutch, and record the un-run owner query (owner + house root + its home classes/key jurisdictions) as an open Coverage/open-item row so the escalation lane can propose it through the supplemental mint — the same treatment as any instructed check the frozen material cannot answer. The affiliate-exclusion mandate governs *conflicts* (never flag the client against itself); it does **not** suppress this *supporting-evidence* check — those are different things.
 
-**The staff lawyer's rule:** Any use of a registered trademark that poses medium risk or higher (any band above the framework's lowest) is relevant. The actual-use check applies **after** the preliminary legal read is made — not before. The correct sequence is:
+**The staff lawyer's rule:** Any use of a registered trademark that poses medium risk or higher (any band the framework rates medium risk or higher, whatever its position on the ladder) is relevant. The actual-use check applies **after** the preliminary legal read is made — not before. The correct sequence is:
 
 1. **Stage 1 — Legal claim strength, net of merits defences:** Make the legal read as the probability the claim prevails, stated in plain likelihood words — the whole-mark confusion read, **net of the credible merits defences** named in the per-finding structure (descriptiveness / weak senior mark, the opponent's own undermining conduct, the client's fair-use defence, priority). Whether **our actual use meets theirs in the market** (real commercial / manner-of-use / channel overlap) IS part of this Stage-1 read — it is the goods-half of likelihood-of-confusion and it sets the read: our use being a descriptive / in-product label vs their standalone source-brand, or the two sitting in a genuinely different commercial field, is a merits reason the claim may not prevail → the **client-favoured read**. **The basis for "theirs" splits by right type:** a **registered** senior meets us on the mark and G&S **as registered** (read the specification; quote it when it decides the point) — never on the owner's current presentation; a **common-law** senior meets us on its **actual trade**. OUR side of the meeting stays our own actual/intended manner of use (per the request form) — that lever is untouched. What stays in Stage 2 is the *senior's enforcement reality* — is the mark actually used, revocable for non-use, will the owner bother, how the owner currently dresses or positions it in the market — **NOT** whether the uses meet. (Merits defences are claim-strength, not practical mitigation; they belong in the legal read.)
 2. **Stage 2 — Practical risk mitigation:** For every hit whose legal read reaches "more likely than not they'd win" or worse, apply the practical mitigants — actual use, revocation-vulnerability, owner enforcement appetite, coexistence. These are the **business read**. **Response availability is Stage 2 at most:** that a route exists — coexistence, consent, rebrand, a cancellation lever — never enters the Stage-1 Legal position; mitigation-availability speaks only through the framework's own **Practical position** words for the band it belongs to.

package/driver/skills/clearance-search/worked-examples.md

@@ -33,7 +33,7 @@ Notice across all three:
 - **The proposed mark's own distinctiveness is assessed *per field*** — and it drives how narrowly any
   third-party right can block (descriptive term → narrow rights → weak block).
 - **Family-of-marks / branded-context is a real mitigant** ("consumers will perceive EMBERSTRIKE as
-  an extension of the Breaker range"; "strong Blockvale branding").
+  an extension of the Strike range"; "strong Blockvale branding").
 - **Use / revocability / enforcement appetite carry the analysis** — a registration with no use, in
   insolvency, or outside the owner's core market is a different risk from an active enforcer.
 - **Executive summary is synthesised prose:** name the primary risk(s), the overall rating, and the
@@ -236,30 +236,30 @@ cannot be excluded.
   sufficient differences to avoid confusion.
 
 *Common-law use*
-- **Manageable** — "Solstrikers" is a game "coming soon" on Steam from indie developer Crobatspr.
+- **Manageable** — "Solstrikers" is a game "coming soon" on Steam from an indie developer.
 
 **Emberstrike — Manageable Risk**
 
-- 3,060 live FLAME/FLAME-formative filings internationally in the searched classes (640 claim gaming
-  software/hardware/online gaming); analysis focuses on FLAME and FLAME BR___ marks covering gaming.
-- 8,575 live BR(E)AKER(S)/BR(E)AK(E)-formative filings (2,317 claim gaming); analysis focuses on
-  BR(E)AKER(S) and F__ BR(E)AKER(S) marks covering gaming.
+- 3,060 live EMBER/EMBER-formative filings internationally in the searched classes (640 claim gaming
+  software/hardware/online gaming); analysis focuses on EMBER and EMBER ST___ marks covering gaming.
+- 8,575 live STRIKE(S)/STRIK(E)-formative filings (2,317 claim gaming); analysis focuses on
+  STRIKE(S) and E__ STRIKE(S) marks covering gaming.
 
 *Filings*
-- **Manageable** — Numerous FLAME/FLAMES marks claim gaming goods/services; most significant is
-  an international FLAMES portfolio owned by gambling company Euro Games Technology (no apparent current
+- **Manageable** — Numerous EMBER/EMBERS marks claim gaming goods/services; most significant is
+  an international EMBERS portfolio owned by a gambling company (no apparent current
   use).
-- **Manageable** — Numerous BREAKER marks claim gaming goods/services; none appears to have
-  objected to the client's ongoing use of ___ BREAKER for controllers.
+- **Manageable** — Numerous STRIKE marks claim gaming goods/services; none appears to have
+  objected to the client's ongoing use of ___ STRIKE for controllers.
 
 *Common-law use*
 - **Manageable** — EmberstrikeGaming: streamer/YouTube channel (205 videos, 405 subscribers)
   with a merch store that does not sell hardware/accessories.
-- **Manageable** — Flamebreak: a 2016 Steam game (444 "very positive" reviews) by Nimbly Games;
+- **Manageable** — Emberstruck: a 2016 Steam game (444 "very positive" reviews) by an indie studio;
   no game published in ~10 years.
-- **Not a rated conflict (clear win)** — A "Emberstrike Set" appears in several Zelda games; not monetised or
+- **Not a rated conflict (clear win)** — A "Emberstrike Set" appears in several games of a long-running adventure series; not monetised or
   prominent.
-- **Not a rated conflict (clear win)** — Remedy's co-op shooter "Firebreak" (1,914 "mixed" reviews on Steam).
+- **Not a rated conflict (clear win)** — A studio's co-op shooter "Firestrike" (1,914 "mixed" reviews on Steam).
 
 ---
 
@@ -292,7 +292,7 @@ manageable.
 - **Moderate (register risk; no obvious market overlap)** — a Canadian provincial lottery corporation owns an official Canadian
   registration for CHART YOUR COURSE (all goods/services) used descriptively for self-service lotteries.
   Legal risk, but low practical objection risk — no enforcement history, no commercial overlap with a
-  console tagline. A Canadian application would undoubtedly be blocked; consent from OLC the only route.
+  console tagline. A Canadian application would undoubtedly be blocked; consent from that corporation the only route.
 - **Moderate (register risk; no obvious market overlap)** — A sports broadcaster owns a US registration covering publication of
   physical-fitness games and instruction-sharing websites, for an inactive youth-fitness program. No
   obvious current use. Statement-of-use deadline 27 July 2026 — if not filed (which seems possible),
@@ -301,7 +301,7 @@ manageable.
   via games consoles (among much else), used for a tennis participation campaign and descriptively.
   Revocable for unused goods/services; low confusion with a console tagline; scope likely reducible
   away from gaming services if challenged.
-- **Manageable** — Polish telecom P4 ("Play") owns a Polish registration covering computer game
+- **Manageable** — A Polish telecom owns a Polish registration covering computer game
   software and console game programs; no specific gaming interest; minor use on its careers site;
   low confusion; scope likely reducible away from gaming goods if challenged.
 - **Manageable** — A games-accessory maker holds invalid/lapsed CHART YOUR COURSE filings
@@ -313,11 +313,11 @@ manageable.
 - **Manageable** — "Chart Your Course" platform for sharing love of video games; limited social
   presence.
 - **Manageable** — "Chart Your Course" 2025 mental-health-in-gaming fundraiser (£7,000 raised).
-- **Manageable** — "Chart Your Course" announced as a major update for the game Peak (~127k
+- **Manageable** — "Chart Your Course" announced as a major update for a popular co-op game (~127k
   "overwhelmingly positive" Steam reviews).
 - **Manageable** — "Charting Your Course" arcade-game subscription service.
 - **Not a rated conflict (clear win)** — A third-party Nebula console-streaming app uses "Chart Your Course" descriptively.
-- **Not a rated conflict (clear win)** — PC gaming companion app Wand has minor descriptive use.
+- **Not a rated conflict (clear win)** — A PC gaming companion app has minor descriptive use.
 - **Not a rated conflict (clear win)** — A "Chart Your Course" card-game app and a "Chart My Course" fitness app.
 
 ---
@@ -336,18 +336,18 @@ side-glance at **Classes 35 and 39** (retail pizza store / pizza delivery) and *
 
 ### Executive summary (per mark)
 
-- **PRIZE CRATE — manageable.** Closest entries: UK registrations for PRIZE CRATE (food, not pizza) and LOOT
-  CHEST (cardboard pizza boxes); confusion unlikely in a Blockvale pizza context, practical objection
+- **PRIZE CRATE — manageable.** Closest entries: UK registrations for PRIZE CRATE (food, not pizza) and PRIZE
+  TRUNK (cardboard pizza boxes); confusion unlikely in a Blockvale pizza context, practical objection
   unlikely. Heavy gaming use/registration of PRIZE CRATE but none an immediate obstacle. Note the term's
   specific (often negative) gaming meaning — a PR consideration before use.
 - **CAVERN CRATES — manageable.** Closest is a US application CAVERN CRATE (Class 30, candy); confusion
   unlikely in the Blockvale pizza context, and no obvious use of CAVERN CRATE for candy. Some "Cavern
   Crate" use in a prize-crate context — minor negative-association risk.
-- **COUCH CO-OP MEAL — manageable.** "Couch co-op" = multiple players sharing one screen/console.
+- **LOCAL CO-OP MEAL — manageable.** "Local co-op" = multiple players sharing one screen/console.
   Numerous supermarket CO(-)OP registrations cover pizza and gaming goods, but given the descriptive
-  gaming meaning of "couch co-op" and strong Blockvale branding, confusion is unlikely.
-- **THE HERO'S CHEST: ADVENTURE ESSENTIALS — manageable.**
-- **THE SLICE AND DICE COMBO — moderate (low end).** An international "pizza and board game" venue trend uses
+  gaming meaning of "local co-op" and strong Blockvale branding, confusion is unlikely.
+- **THE RANGER'S SATCHEL: QUEST ESSENTIALS — manageable.**
+- **THE SLICE AND DICE PLATTER — moderate (low end).** An international "pizza and board game" venue trend uses
   "Slice and Dice"-type names (mostly unregistered, low reputation). The moderate rating attaches to an
   Irish registration SLICE N DICE (individual owner) claiming *both* pizza and electronic gaming goods;
   no use found but within the non-use grace period — plausibly a pizza/board-game venture. Given the
@@ -364,38 +364,38 @@ side-glance at **Classes 35 and 39** (retail pizza store / pizza delivery) and *
 - *Potential negative association / PR:* prize crates are tied to "compulsion loop" game design,
   criticised as gambling-style "dark patterns" and increasingly regulated; using "Prize Crate" for a
   gaming-pizza promo could be read as normalising a criticised practice. (Blockvale's natural-chest
-  loot is non-monetised, not a gambling-style system.)
-- *Filings* — **Manageable**: Pence Technology (UK) owns PRIZE CRATE (Stylised) over broad food/beverage
+  prizes are non-monetised, not a gambling-style system.)
+- *Filings* — **Manageable**: A UK technology company owns PRIZE CRATE (Stylised) over broad food/beverage
   (not pizza); no obvious use; not revocable yet, but low practical objection risk (company inactive).
-  Prize Crate Retail (UK) owns LOOT CHEST & device over "cardboard pizza boxes" + broad goods; in
-  voluntary insolvency, no recent operations, low practical risk. Loot Crate (geek subscription boxes)
-  owns an international LOOT CRATE portfolio (apparel/paper/toys/retail), not food — no overlap. Numerous
-  third-party LOOT( )BOX gaming filings — none can block given the term's non-distinctiveness in gaming.
-  Pepsi owns LOOT / DORITO'S LOOT / EAT. DRINK. GET LOOT. over Class 30 foods (not pizza) — noted only
+  Prize Crate Retail (UK) owns PRIZE TRUNK & device over "cardboard pizza boxes" + broad goods; in
+  voluntary insolvency, no recent operations, low practical risk. Prize Case (geek subscription boxes)
+  owns an international PRIZE CASE portfolio (apparel/paper/toys/retail), not food — no overlap. Numerous
+  third-party PRIZE( )CRATE gaming filings — none can block given the term's non-distinctiveness in gaming.
+  Crunchmore Foods owns PRIZE / CRUNCHMORE'S PRIZE / EAT. DRINK. GET PRIZE. over Class 30 foods (not pizza) — noted only
   as a large food player; no confusion.
 - *Common-law* — **Manageable**: a virtual unboxing platform "Prize Crate"; "PRIZECRATE Game Store" (card/
-  tabletop games); "Loot Drink" gamer energy-drink powder.
+  tabletop games); "Prize Drink" gamer energy-drink powder.
 
-**THE SLICE AND DICE COMBO — Moderate (low end)**
+**THE SLICE AND DICE PLATTER — Moderate (low end)**
 - *Distinctiveness/context:* "slice"/"dice" are not very distinctive for pizza (knife actions; "slice"
   = pizza), reflected in 370 live SLICE/DICE filings claiming pizza in Class 30 — so analysis focuses on
   marks with both words or another element bringing them closer; "slice and dice" *is* distinctive for
   non-dice computer games; "dice" is not distinctive for board games.
-- *Filings* — **Moderate (low end; settleable overlap, or paper-only if unused)**: Conor Jordan (individual) owns an
+- *Filings* — **Moderate (low end; settleable overlap, or paper-only if unused)**: An individual owns an
   Irish SLICE N DICE registration with a detailed gaming list (Class 28) *and* detailed pizza list
   (Class 30) — notable for that specificity. No use found; an international "board game + pizza" café
   trend uses identical "Slice and Dice" branding, plausibly the intent here. Despite the Blockvale
   context, given the identical mark and highly specific pizza+gaming intersection, **Irish counsel
-  advice is recommended** (ideally with an example of the proposed use). Also **Manageable**: Wymac
-  (Australian gaming-machine maker) SLICE N DICE (AU/US) — vulnerable to cancellation for unused goods,
-  and in-venue machines don't overlap; Seneca (US casino) SLICE-N-DICE for a casino restaurant;
-  Ravensburger DICE AND SLICE for a physical pizza-themed strategy game.
+  advice is recommended** (ideally with an example of the proposed use). Also **Manageable**: an
+  Australian gaming-machine maker's SLICE N DICE (AU/US) — vulnerable to cancellation for unused goods,
+  and in-venue machines don't overlap; a US casino's SLICE-N-DICE for a casino restaurant;
+  a board-game publisher's DICE AND SLICE for a physical pizza-themed strategy game.
 - *Common-law* — **Manageable**: "Slice & Dice" tactical dice roguelike (App Store / Google Play /
   Steam, 1m+ downloads, 2020) — no pizza theme, "dice" refers to the mechanic; confusion unlikely in
   the Blockvale pizza context. Numerous "Slice and Dice"-type pizzerias/bars, some offering tabletop
   gaming — none with reputation enough to confuse. "Slice and Dice" is also the name of a third-party Blockvale mod.
 
-*(Full CAVERN CRATES, COUCH CO-OP MEAL and THE HERO'S CHEST analyses follow the same chain — owner →
+*(Full CAVERN CRATES, LOCAL CO-OP MEAL and THE RANGER'S SATCHEL analyses follow the same chain — owner →
 coverage + distinctiveness → use/revocability → overlap → enforcement → net, in a Blockvale-branded
 promotional context.)*
 
@@ -443,7 +443,7 @@ The crowded-field framing drives the whole mark: a register sweep returned rough
 
 **Aqua Dawn — Manageable Risk**
 
-A register sweep returned roughly 1,900 live DAWN / DAWN-formative filings internationally, but only a small fraction touch beverages or supplements, and the single dominant DAWN right sits in an unrelated cleaning-products field. Analysis focuses on DAWN and DAYBR___ marks with any Class 5/30/32 claim, and on the coffee-hybrid space the product actually occupies.
+A register sweep returned roughly 1,900 live DAWN / DAWN-formative filings internationally, but only a small fraction touch beverages or supplements, and the single dominant DAWN right sits in an unrelated cleaning-products field. Analysis focuses on DAWN and SOLSTR___ marks with any Class 5/30/32 claim, and on the coffee-hybrid space the product actually occupies.
 
 *Filings*
 - **Manageable** — Procter & Gamble owns the well-known DAWN house mark, but its registrations sit in Class 3 (dishwashing/cleaning) with no beverage or supplement claim located. Famous mark, but a different field entirely; the dilution-style theory a famous-mark owner might raise is remote against a AQUA-led beverage extension, and there is no goods overlap. Noted because the name is prominent, not because it obstructs.

package/driver/skills/clearance-variants/SKILL.md

@@ -74,11 +74,11 @@ A single file inside the active run-dir: `studio/clearance-search/<slug>/<date>/
 ### Format
 
 ```markdown
-# Variant manifest — Dawn: Legends of Lumengarde (2026-05-11)
+# Variant manifest — Dusk: Tales of Lumengarde (2026-05-11)
 
 ## Request
 
-- **Marks:** Dawn: Legends of Lumengarde
+- **Marks:** Dusk: Tales of Lumengarde
 - **Classes:** 9, 28, 41, 42
 - **Jurisdiction:** worldwide
 - **Industry:** gaming
@@ -89,34 +89,34 @@ A single file inside the active run-dir: `studio/clearance-search/<slug>/<date>/
 
 ## Scope statement
 
-Preliminary clearance for "Dawn: Legends of Lumengarde" as a game title, Classes 9/28/41/42, worldwide. Industry-incumbent parallel sweeps apply for LUMENGARDE (lighting electronics).
+Preliminary clearance for "Dusk: Tales of Lumengarde" as a game title, Classes 9/28/41/42, worldwide. Industry-incumbent parallel sweeps apply for LUMENGARDE (lighting electronics).
 
 ---
 
-## Mark: Dawn: Legends of Lumengarde
+## Mark: Dusk: Tales of Lumengarde
 
 ### Archetype
 
-- **Primary:** Descriptive compound (3-word title; LUMENGARDE distinctive, DAWN + LEGENDS common saturated commons in gaming)
+- **Primary:** Descriptive compound (3-word title; LUMENGARDE distinctive, DUSK + TALES common saturated commons in gaming)
 - **Modifiers:** None
 - **Boundary note:** LUMENGARDE alone would be a coined-word; the compound title shape places it under descriptive-compound. Coined-word axes (phonetic, transliteration, leet) still apply to LUMENGARDE element-solo.
 
 ### Distinctiveness & registrability (advisory — the staff lawyer to assess)
 
-- **Dominant element:** LUMENGARDE (DAWN + LEGENDS are common/descriptive — stripped). Search + conflict-ranking centre here.
+- **Dominant element:** LUMENGARDE (DUSK + TALES are common/descriptive — stripped). Search + conflict-ranking centre here.
 - **Spectrum:** distinctive (LUMENGARDE coined; the compound is arbitrary for gaming). No obvious absolute-grounds problem.
 - **Flags:** none — not descriptive/generic/laudatory/geographic for the goods; not deceptive or offensive.
 
 ### Risk theory
 
-LUMENGARDE is the distinctive anchor — risk concentrates on coined-word axes around that element (phonetic variants, leet, foreign transliteration) plus the Lumengarde Electronics lighting incumbent. DAWN and LEGENDS are saturated commons; risk there is the single-distinctive-word DAWN-alone or LEGENDS-alone filing in gaming, not crowded-field volume. Compound-phrase exact hit is low-probability but high-impact if it surfaces.
+LUMENGARDE is the distinctive anchor — risk concentrates on coined-word axes around that element (phonetic variants, leet, foreign transliteration) plus the Lumengarde Electronics lighting incumbent. DUSK and TALES are saturated commons; risk there is the single-distinctive-word DUSK-alone or TALES-alone filing in gaming, not crowded-field volume. Compound-phrase exact hit is low-probability but high-impact if it surfaces.
 
 ### Elements
 
 | Element | Role | Saturation | Famous-mark | Notes |
 |---|---|---|---|---|
-| DAWN | common-word | high | no | Morning / new beginning; fantasy / adventure |
-| LEGENDS | common-word | very-high | no | Myth / tale; epic / fantasy |
+| DUSK | common-word | high | no | Evening / sunset; fantasy / adventure |
+| TALES | common-word | very-high | no | Story / myth; epic / fantasy |
 | LUMENGARDE | distinctive | low | no | Industry incumbent: **Lumengarde Electronics Co.** (lighting / LED / semiconductors, classes 9 + 11) — triggers parallel sweep |
 
 ### Variants
@@ -140,10 +140,10 @@ silently narrows what was searched, and the deferred row is the honest outcome.
 
 | Category | Value | Rationale | Verify? |
 |---|---|---|---|
-| exact-phrase | Dawn: Legends of Lumengarde | full mark | |
+| exact-phrase | Dusk: Tales of Lumengarde | full mark | |
 | exact-element | LUMENGARDE | distinctive anchor — primary register vector | |
-| exact-element | DAWN | common element — single-word coverage hunt | |
-| exact-element | LEGENDS | common element — single-word coverage hunt | |
+| exact-element | DUSK | common element — single-word coverage hunt | |
+| exact-element | TALES | common element — single-word coverage hunt | |
 | plural-root | LEGEND | tokeniser superset | |
 | phonetic | EVERLITE | homophone, distinctive element | |
 | phonetic | EVRLIGHT | vowel drop | |
@@ -179,7 +179,7 @@ silently narrows what was searched, and the deferred row is the honest outcome.
 ### Watchlists
 
 - **Aggressive enforcers:** Nordwave, Foxglade Interactive
-- **Major brand owners:** Sony, Aureon, Nintendo, HP, Activision, Take-Two, EA
+- **Major brand owners:** Veltrona, Aureon, Pinecrest, Brightwick, Halloway, Duomark, Skyvault
 - **Competitors:** Epic Games, Valve, Unity, Riot Games
 
 ### Famous-mark Perplexity calls needed
@@ -188,7 +188,7 @@ None for this mark.
 
 ### Diligence notes
 
-LUMENGARDE carries coined-word axes (phonetic + transliteration) despite the descriptive-compound primary archetype. Industry-incumbent alert triggers a parallel-class 11 sweep. DAWN and LEGENDS are saturated commons — still generated as single-word vectors; their saturation tells the downstream register search to **narrow** (class-scope the token and enumerate), it is never a reason to skip the vector here or to pre-judge the crowd clean.
+LUMENGARDE carries coined-word axes (phonetic + transliteration) despite the descriptive-compound primary archetype. Industry-incumbent alert triggers a parallel-class 11 sweep. DUSK and TALES are saturated commons — still generated as single-word vectors; their saturation tells the downstream register search to **narrow** (class-scope the token and enumerate), it is never a reason to skip the vector here or to pre-judge the crowd clean.
 
 ---
 
@@ -227,7 +227,7 @@ Pick one **primary** archetype. Pick zero or more **modifiers**. Write a one-lin
 **Worked examples:**
 
 - "LUMENGARDE" (single mark) → Coined word. No modifier. Risk: phonetic, transliteration, leet, coined-word collisions.
-- "Dawn: Legends of Lumengarde" → Descriptive compound (DAWN + LEGENDS commons, LUMENGARDE distinctive anchor). No modifier. Risk concentrates on LUMENGARDE element + compound-phrase hit.
+- "Dusk: Tales of Lumengarde" → Descriptive compound (DUSK + TALES commons, LUMENGARDE distinctive anchor). No modifier. Risk concentrates on LUMENGARDE element + compound-phrase hit.
 - "CHART YOUR COURSE" → Slogan. No modifier. Risk: family patterns (CHART * COURSE, * YOUR COURSE, CHART YOUR *), verb swaps, slang.
 - "Bloodguard Sabatons" → Descriptive compound + famous-element-masked (Sabatons = Swedish metal band). Risk: per-element famous-mark search on Sabatons; descriptive-compound axes on the rest.
 - "RAIZ8" → Acronym/initialism (leet form of RAISE). Risk: letter-collision; expansion-form search on RAISE.
@@ -330,7 +330,7 @@ The `phonetic` / `visual-substitution` / `numeric-substitution` / typographic ro
 
 For multi-word marks where the structure carries meaning (slogans, descriptive compounds), substitute each stem-formative back into the phrase template:
 
-- "RAISE YOUR PLAY" → "ELEVATING YOUR GAME", "RAISE THE PLAY", "RAISING YOUR PLAY", etc.
+- "RAISE YOUR PLAY" → "LIFTING YOUR PLAY", "RAISE THE PLAY", "RAISING YOUR PLAY", etc.
 - "CHART YOUR COURSE" → "CHARTING YOUR COURSE", "CHART MY COURSE", "CHART THE COURSE", "PLOT YOUR COURSE" (verb swap)
 
 Drop ungrammatical or semantically broken strings. Default: generate liberally; macro-count probes filter.

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

@@ -54,10 +54,10 @@ A directive may carry a structured `remedy`:
 
 **A firing `variant` directive — severity `dominant-element` or `material` — MUST be dispatchable.** That means one of exactly two things:
 
-1. its `item` is *itself* a single mark-shaped search term (`TAKIS`, `AXIOS`, `CORAL MAGIC`), **or**
+1. its `item` is *itself* a single mark-shaped search term (`WAVA`, `ORBEXA`, `CORAL MAGIC`), **or**
 2. it carries `remedy.terms` naming the mark-shaped term(s) to search.
 
-A label-shaped `item` — more than 4 words, a parenthetical, an enumeration ("TAKIS (famous CPG snack, one-keystroke neighbour)", "Reverse-order WAVO composites (TROPICAL WAVO, ISLAND WAVO)") — is **never dispatched as a search term**: dispatched verbatim it is a nil search that comes back 0 and reads as a clean, which is worse than no search. So a firing `variant` directive whose item is a label **and which carries no remedy is a PARSE DEFECT** — the driver refuses the file and asks you to restate it, in this same turn, while restating is still free. Every term you put in `remedy.terms` is linted the same way: a remedy that is itself a label is refused exactly like the item was.
+A label-shaped `item` — more than 4 words, a parenthetical, an enumeration ("WAVA (famous CPG snack, one-keystroke neighbour)", "Reverse-order WAVO composites (TROPICAL WAVO, ISLAND WAVO)") — is **never dispatched as a search term**: dispatched verbatim it is a nil search that comes back 0 and reads as a clean, which is worse than no search. So a firing `variant` directive whose item is a label **and which carries no remedy is a PARSE DEFECT** — the driver refuses the file and asks you to restate it, in this same turn, while restating is still free. Every term you put in `remedy.terms` is linted the same way: a remedy that is itself a label is refused exactly like the item was.
 
 The refusal names **every** offending directive at once, and it arrives as the tool's answer to your call — in this turn, while restating is still free. Fix them **all** in one further call: the repair ladder counts attempts, not directives, so repairing only the first one loses the rest. A call replaces the stored diff, so send the whole thing again, not only the corrected directives.
 

package/driver/stage-context.mjs

@@ -123,6 +123,19 @@ export const TOOL_GROUP_EDGES = {
     { path: P.bandShapeMd, why: "band_shape serves band-shape.md (the readable shape, part-paged)" },
     { path: P.registerPositions, why: "the exact-identity projection the shape and the recall join read as one unit" },
     { path: join(P.runDir, "_records"), dir: true, why: "band_record serves the official registry records fetched into this run" },
+    // SEVENTH OCCURRENCE OF THIS TABLE'S OWN SUBJECT, and the arm written to prevent it could not see this
+    // one. `band_record` serves a body from `_records/` OR from this log, and at step 2 the real run served
+    // placement's reads from the log rather than from files. Undeclared, the sandbox copy held no bodies and
+    // every one of those reads failed — measured on five saved runs, where placement opened 31, 32, 2, 2 and
+    // 0 records: in the sandbox as shipped, all of them fail.
+    //
+    // WHY THE GENERIC ARM MISSED IT. That arm walked the servers for `driverDir(runDir, X)` and kept X only
+    // when it ended in `.json`; this file ends in `.jsonl`, so it was never in the population the arm
+    // checked. The filter stood in for telling a read from a write, since every file the servers write is
+    // `.jsonl` too. The walk now makes that distinction itself, at any extension (experiment-context.test.mjs,
+    // `driverFileUses`), so this file is held by the same rule as every other read.
+    { path: driverDir(P.runDir, "register-record-bodies.jsonl"),
+      why: "band_record serves a record body from this log when the run fetched it through the ledger rather than into _records/ (band-server.mjs recordLedgerPath); without it the sandbox's record reads all fail and the re-run sees less than the stage saw" },
   ],
   // ── conversion 11 — THE RECORD TOOL READS A DRIVER-WRITTEN SIDECAR, AND NOTHING DECLARED IT ───────
   //
@@ -200,7 +213,20 @@ const UNDECLARED = {
   // inline and names the `record_coverage` tool), the seat opens no coverage file, and the accumulator
   // the gate judges is declared on VALIDATOR_SIDECARS below. The brief's own read of that accumulator
   // is declared on DISPATCH_EXTRAS.
-  "register-digest": () => [],
+  // THE PROMPT NAMES A FILE THE SANDBOX DID NOT COPY, so a re-run of the digest differed from the real
+  // stage in one input the prompt names, invisibly: the stage passed. The digest's message ("MARK THE LIST")
+  // names the hit list and asks the model to mark lines on it, and `hit-list.mjs` reads those marks back.
+  // Absent from the copy, a marking the model sends lands nowhere and nothing refuses — measured on a bench
+  // plumbing run where the digest completed with owed 7 accounted 7 and the hit list was simply not there.
+  //
+  // DECLARED UNCONDITIONALLY, for the reason the digest's accounting stamp above is: `sandboxGaps` reports a
+  // gap only for something the CANONICAL run holds, so a run that never built a hit list contributes no gap,
+  // and one that built it and lost it in the copy refuses by name. Listing it costs nothing on the first and
+  // is the whole point on the second.
+  "register-digest": (P) => [
+    { path: P.registerHitList,
+      why: "the digest's own message names this file and asks the model to mark lines on it (hit-list.mjs reads the marks back); without it in the copy a marking lands nowhere and the stage passes having been given a different input than the real one" },
+  ],
   // The provider enforcement telemetry: the prompt names the path only when ctx.enforcerSignals is a
   // non-zero count (stages.mjs synthesis message). Undeclared on purpose — it is aim-attention only and
   // must never move a freshness stamp — but a sandbox without it hands a different prompt.

package/driver/stages.mjs

@@ -35,7 +35,7 @@ import { LINE_GROUNDS } from "./hit-list.mjs";   //  — the dictation reads the
 import { marketplaceScopeDirective } from "./jurisdiction-systems.mjs";
 import { MEANING_SEAT } from "./common-law-receipts.mjs";   // — the seat whose whole dispatch is the meaning sweep
 import { meaningSweepReceiptsInstruction } from "./connotation-search.mjs";   // M1 — ONE composer; this sentence was authored four times
-import { frameworkFor, workedExamplesFor } from "./framework.mjs"; import { methodDictation, inputsShape } from "./framework-method.mjs";
+import { frameworkFor, workedExamplesFor, materialBandPhrase } from "./framework.mjs"; import { methodDictation, inputsShape } from "./framework-method.mjs";
 import { requiredScriptsFor } from "./registration-scripts.mjs";   // item 21 — which scripts a territory registers marks in
 import { resolveTerritories, defaultJurisdictionsLine, narrowingOrderLine } from "./effective-scope.mjs";   // the ONE territory ladder (the geography stamp included) + the defaults-never-widen rule (2160)
 import { editRepairTail } from "./repair-contract.mjs";
@@ -1436,7 +1436,7 @@ export const STAGES = {
       },
       "mark — \"<the mark verbatim>\"": {
         class: "mechanical:pre-bound", tokens: ["variantmodel_mark_missing"],
-        why: "_driver/instructed-scope.json.marks holds it and stage-context.mjs:175 binds that file to this stage. variant-manifest-model.mjs:225-231 already concedes the field is not the model's: it is excluded from the term-shape gate because \"the stage is told to emit it VERBATIM, and it arrives from the job… a value this stage CANNOT restate\" [citation unverified]",
+        why: "_driver/instructed-scope.json.marks holds it and stage-context.mjs:175 TOOL_GROUP_EDGES binds that file to this stage. variant-manifest-model.mjs:225-231 parseVariantManifestModel already concedes the field is not the model's: it is excluded from the term-shape gate because \"the stage is told to emit it VERBATIM, and it arrives from the job… a value this stage CANNOT restate\" [citation unverified]",
       },
       "dominant_element — the distinctive anchor the sweep enumerates": {
         class: "judgment", tokens: ["variantmodel_dominant_element_missing"],
@@ -1516,7 +1516,7 @@ export const STAGES = {
       },
       "### Scope ledger rows — {Layer, Item, Status: applied|dropped, Reason, Reopen trigger} across variant / field / source / jurisdiction": {
         class: "judgment", tokens: [],
-        why: "defending an omission with the concrete observation that should reopen it is the whole judgment, and frame-diff diffs it against the blind re-derivation. The ROW SHAPE is mechanical — scope-ledger.mjs:123-126 parses the table into scope-ledger.json — and the jurisdiction rows are largely a re-carry of the matter frame's own Scope-jurisdictions line [citation unverified]",
+        why: "defending an omission with the concrete observation that should reopen it is the whole judgment, and frame-diff diffs it against the blind re-derivation. The ROW SHAPE is mechanical — scope-ledger.mjs:123-126 renderScopeLedgerJson parses the table into scope-ledger.json — and the jurisdiction rows are largely a re-carry of the matter frame's own Scope-jurisdictions line [citation unverified]",
       },
       "Prose variant-table category token — translit-<script>, and for Chinese translit-zh-meaning vs translit-zh-phonetic": {
         class: "judgment", tokens: [],
@@ -2372,7 +2372,7 @@ export const STAGES = {
       },
       "select — one record URI of the register candidate being placed": {
         class: "mechanical:code-extracted", tokens: [],
-        why: "buildSelectionIndex() in placement-form.mjs already holds every selectable record, built from _driver/register-positions.json plus the band shape's floors, and resolves any URI of a family to the canonical row. #850 M1: the model should return the 1-based index into that driver-written list; code resolves index→id. WHICH candidate to place stays judgment — the row existing at all is the judgment; only the pointing token is mechanical. NO VALIDATOR TOKEN speaks about it: an unresolved select is recorded on the form as `unresolved[]` (placement-union.mjs:134) and handed back in the next dispatch, never a fail. [citation unverified]",
+        why: "buildSelectionIndex() in placement-form.mjs already holds every selectable record, built from _driver/register-positions.json plus the band shape's floors, and resolves any URI of a family to the canonical row. #850 M1: the model should return the 1-based index into that driver-written list; code resolves index→id. WHICH candidate to place stays judgment — the row existing at all is the judgment; only the pointing token is mechanical. NO VALIDATOR TOKEN speaks about it: an unresolved select is recorded on the form as `unresolved[]` (placement-union.mjs:134 pushSelection) and handed back in the next dispatch, never a fail. [citation unverified]",
       },
       "seat rows for candidates the register does not hold — mark / owner / jurisdiction / records: [] written in full": {
         class: "judgment", tokens: ["placement_mark_missing", "placement_owner_missing", "placement_jurisdiction_invalid", "placement_records_invalid"],
@@ -2384,7 +2384,7 @@ export const STAGES = {
       },
       "the identifier half of each `cleared:` / `material-gap:` line — the axis, the named slice and its count": {
         class: "mechanical:code-extracted", tokens: [],
-        why: "The band's `incomplete` crowd descriptor carries query, total_hits, fetched and reason, and the driver already writes one coverage-form row per unaccounted crowd block with the qid, hit count and unaccounted classes/terms computed (coverage-form.mjs; digest.md:196-201). The MATERIALITY CALL is judgment and stays in the element above; the descriptor's identity and count are transcription of the driver's own numbers.",
+        why: "The band's `incomplete` crowd descriptor carries query, total_hits, fetched and reason, and the driver already writes one coverage-form row per unaccounted crowd block with the qid, hit count and unaccounted classes/terms computed (coverage-form.mjs; digest.md, 'Coverage ledger'). The MATERIALITY CALL is judgment and stays in the element above; the descriptor's identity and count are transcription of the driver's own numbers.",
       },
       "the md's four tier sections — one per-candidate entry restating that candidate's tier and reasoning": {
         class: "mechanical:code-rendered", tokens: ["missing", "too_short"],
@@ -2404,7 +2404,7 @@ export const STAGES = {
       },
       "retract: <row_id> — withdrawing a seat row already on the form": {
         class: "judgment", tokens: [],
-        why: "Whether a placed candidate should come off is a call only the model makes. The row_id it names is driver-assigned (shortId 'PS'/'PR', placement-form.mjs:205/273), so the HANDLE is code-assigned even though the act is judgment. [citation unverified]",
+        why: "Whether a placed candidate should come off is a call only the model makes. The row_id it names is driver-assigned (shortId 'PS'/'PR', placement-form.mjs:205 renderEntry/273), so the HANDLE is code-assigned even though the act is judgment. [citation unverified]",
       },
       "return payload — the absolute output path plus a 2-3 line summary": {
         class: "mechanical:pre-bound", tokens: [],
@@ -2490,7 +2490,7 @@ export const STAGES = {
       },
       "seat-added coverage rows — the decision to add one, and the axis it is filed under (expressed in the `unit` label)": {
         class: "judgment", tokens: ["coverage_form_axis_invalid"],
-        why: "The shipped code rules it judgment in its own words: 'THE AXIS IS PART OF THE JUDGMENT, and on a SEAT row it is the one identifier the seat still supplies' and normalizeAxis 'repair[s] formatting, never invent[s] an axis' (coverage-form.mjs:519-524). The driver cannot know which axis a coverage unit it never planned belongs under. [citation unverified]",
+        why: "The shipped code rules it judgment in its own words: 'THE AXIS IS PART OF THE JUDGMENT, and on a SEAT row it is the one identifier the seat still supplies' and normalizeAxis 'repair[s] formatting, never invent[s] an axis' (coverage-form.mjs:519-524 coverageFormRows). The driver cannot know which axis a coverage unit it never planned belongs under. [citation unverified]",
       },
       "the seat row's duplicate `axis` cell (the same token already typed as the leading segment of `unit`)": {
         class: "mechanical:code-extracted", tokens: ["coverage_form_axis_invalid"],
@@ -2502,7 +2502,7 @@ export const STAGES = {
       },
       "the compulsory dominant-element crowd row's `unit` cell — the dictated grammar `<axis> / dominant-element crowd (<N> members): <label>` and the bare integer N": {
         class: "mechanical:code-rendered", tokens: [],
-        why: "The driver computes the denominator: it groups screened-live dominant-element records by _driver/register-positions.json, counts the positions the digest did not individually end, verifies N and re-verifies after every rewrite (digest.md:132-164). The model is asked to retype a number the driver already checks it against — the frame_scope_missing loop restated. The RULING (why crowd membership ends this residual class) is judgment and lives in `reason`. No verify.mjs token: the reconciliation gate is a delivery block in pipeline.mjs, not this stage's validator.",
+        why: "The driver computes the denominator: it groups screened-live dominant-element records by _driver/register-positions.json, counts the positions the digest did not individually end, verifies N and re-verifies after every rewrite (digest.md, 'Dominant-element reconciliation'). The model is asked to retype a number the driver already checks it against — the frame_scope_missing loop restated. The RULING (why crowd membership ends this residual class) is judgment and lives in `reason`. No verify.mjs token: the reconciliation gate is a delivery block in pipeline.mjs, not this stage's validator.",
       },
       "rolled-up coverage judgment — `sufficient: <true|false>`": {
         class: "mechanical:code-extracted", tokens: [],
@@ -2542,7 +2542,7 @@ export const STAGES = {
       },
       "Audit trail — per-unit search/detail-fetch counts, per-jurisdiction `_query` attribution": {
         class: "mechanical:tool-written", tokens: [],
-        why: "CONVERTED (conversion 11): the driver renders the Audit trail table from the same artifacts as the Summary counts, plus `_query` which digest.md:388 says 'the driver stamps at merge' — carrying that forward was transcription of a driver stamp. The judgment half — flagging a unit that shortcut its axis — stays in the findings-prose element.",
+        why: "CONVERTED (conversion 11): the driver renders the Audit trail table from the same artifacts as the Summary counts, plus `_query` which digest.md says 'the driver stamps at merge' — carrying that forward was transcription of a driver stamp. The judgment half — flagging a unit that shortcut its axis — stays in the findings-prose element.",
       },
       "INSTRUCTED CHECKS — the answer to each requester ask the register owns": {
         class: "judgment", tokens: ["registerdigest_instructed_incomplete"],
@@ -2839,7 +2839,7 @@ export const STAGES = {
       // demands. Stating it only in skills/frame-diff/SKILL.md would leave this line inviting the exact
       // shape the parse throws on — enforcement without a matching invitation, which is how the
       // 2026-07-29 run raised four omissions nothing could search.
-      `A FIRING variant directive (severity dominant-element or material) MUST be dispatchable: either its "item" is ITSELF a single mark-shaped search term (TAKIS, AXIOS, CORAL MAGIC), or it carries remedy: {terms:["<mark-shaped term>", …], nice_classes:["<class>", …]} saying WHAT to search. A label — a parenthetical, an enumeration, more than about four words ("TAKIS (famous CPG snack, one-keystroke neighbour)") — dispatches as a nil search that reads CLEAN, so the driver REFUSES the file and asks you to restate it in-turn. Every offending directive is named at once: fix them ALL in one re-save. Never delete a directive or downgrade it to "minor" to get past this — a real omission must still be raised, it just has to say what the search IS.`,
+      `A FIRING variant directive (severity dominant-element or material) MUST be dispatchable: either its "item" is ITSELF a single mark-shaped search term (WAVA, ORBEXA, CORAL MAGIC), or it carries remedy: {terms:["<mark-shaped term>", …], nice_classes:["<class>", …]} saying WHAT to search. A label — a parenthetical, an enumeration, more than about four words ("WAVA (famous CPG snack, one-keystroke neighbour)") — dispatches as a nil search that reads CLEAN, so the driver REFUSES the file and asks you to restate it in-turn. Every offending directive is named at once: fix them ALL in one re-save. Never delete a directive or downgrade it to "minor" to get past this — a real omission must still be raised, it just has to say what the search IS.`,
       `field and source directives are NOT under that rule: an un-classed field directive and a source channel are disclosed rather than swept blind, which is a principled ending for those layers. A remedy is welcome on them whenever you know the exact re-search, and any remedy you supply is linted the same way wherever it rides.`,
       `Set dominant_element_gap true when the dominant element is not fully enumerated (the crowd not yet counted worldwide, a spine neighbour unsearched). The driver holds the dominant element and re-checks this against it — do not rely on it to hide a spine omission.`,
       //, third conversion — THE WRITE DICTATION AND BOTH PATHS ARE GONE. This dispatch used to end
@@ -3112,7 +3112,7 @@ export const STAGES = {
       // WS2 (spec 11) — ENFORCED, not advisory: validators.narrative HARD-REJECTS this file if a
       // use-dependent finding above the framework's lowest band asserts a use-negative without a searched
       // source line. So actually run the query.
-      `USE-CHECK (enforced): for EVERY finding whose mitigant/verdict turns on the ABSENCE of use (regardless of its band) ("not in actual use", "unused", "no marketplace use found", non-use revocation/cancellation as the mitigant, "owner's use unknown"), run ONE scoped \`perplexity_research\` query (owner + mark + the goods/field) and END that finding's actual-use line with a literal "- **Use-check source:** <result URL | "perplexity_research — no result">" line. Mirror the result into the matching # Actions item (the deferred "confirm the owner's use" becomes a stated result). NEVER assert a use-negative you did not search — an inference from the owner's profile is not a searched result. On a perplexity outage write "- **Use-check source:** perplexity_research — no result" and proceed (the run still delivers). ALSO populate that finding's use_check field in findings.json: {"source": "<the result URL | perplexity_research — no result>"} — the structured field is the authoritative cite the report renders from (the prose line is for narrative readability).`,
+      `USE-CHECK (enforced): run the scoped use check (phase2-execution.md Step 3.5) on EVERY finding banded ${(framework && materialBandPhrase(framework)) || "medium risk or higher"} — the rungs this framework rates medium risk or higher; a lower rung is not checked — and ask in the SAME query for the owner's enforcement record (oppositions, disputes or court actions over this mark or a similar one). After the search, use is "confirmed" or "not-confirmed", never "unknown". What the query finds about enforcement is a LEAD under ENFORCEMENT AUTHORITY below: enforcer basis "inferred-from-signal", its URL cited inline in that finding's prose; where it finds none, the enforcer is "low" with basis "inferred-from-signal" and the finding says the search found no enforcement record. ALSO, for EVERY finding whose mitigant/verdict turns on the ABSENCE of use (regardless of its band) ("not in actual use", "unused", "no marketplace use found", non-use revocation/cancellation as the mitigant, "owner's use unknown"), run ONE scoped \`perplexity_research\` query (owner + mark + the goods/field) and END that finding's actual-use line with a literal "- **Use-check source:** <result URL | "perplexity_research — no result">" line. Mirror the result into the matching # Actions item (the deferred "confirm the owner's use" becomes a stated result). NEVER assert a use-negative you did not search — an inference from the owner's profile is not a searched result. On a perplexity outage write "- **Use-check source:** perplexity_research — no result" and proceed (the run still delivers). ALSO populate that finding's use_check field in findings.json: {"source": "<the result URL | perplexity_research — no result>"} — the structured field is the authoritative cite the report renders from (the prose line is for narrative readability).`,
       // Spec-v3 A4 — ENFORCED the same way (validators.narrative): own-rights reliance needs its evidence.
       // PR-8 review fix: synthesis holds the FROZEN band, not the live register — and the band is class-
       // and mark-text-scoped to this matter's dispatched slices, so the client's OWN house-mark
@@ -3280,7 +3280,7 @@ export const STAGES = {
       // beside it is caught only if the prose form itself trips SCOPE_NUMBER_RE — which the narrative's
       // own phrasings routinely dodge. Prompt-only per §7; the fix is to stop authoring the duplicate.
       `COVERAGE PROSE (the lane that runs longest — hold it to the house budgets): the register coverage line a reader sees is COMPUTED from this run's own record and STAMPED BY CODE as front-matter (the proportion, the class states, the searched registers). Do NOT re-type its numbers anywhere in prose — not in a coverage[] note, not in the coverage_judgment reason, not in the narrative. Nothing catches the duplicate for you (the code-stamped line sits outside the prose checks precisely because ITS numbers are the authoritative ones), so a re-typed count does not disagree with the record — it silently drifts from it a redelivery later. Carry the SUBSTANCE and drop the number: "the remaining forms are non-Latin script" says the useful half; the code says how many. State each coverage fact ONCE, in ONE place — an area's state belongs in its coverage[] row, the sufficiency read belongs in coverage_judgment.reason, and neither is re-narrated in the other or in the findings. And say WHICH KIND of negative you hold every time: a source this run actually queried and got nothing from reads "searched — none found"; a source it did not reach reads "not searched this run" or "could not be searched — <the reason>". The same source must never wear both readings in one report.`,
-      `- use_check / own_rights: OPTIONAL per-finding objects; populate per the USE-CHECK / OWN-RIGHTS rules above. use_check = {"source","quality"}: source is the cite of record the report renders — MANDATORY (spec-48 A4, symmetric) for ANY ASSERTED use status (token "confirmed" OR "not-confirmed") on a finding banded ABOVE the framework's lowest band, not only use-negatives (the validator rejects an asserted use with no receipt: finding_use_check_missing); "unknown" needs none. quality: OPTIONAL, EXACTLY one of owner-site / independent / register-mirror — your read of what KIND of page the source is (the code re-derives its own classification and wins; a register mirror is never evidence of use). own_rights = {"source"} — MANDATORY for any own-rights-reliant finding.`,
+      `- use_check / own_rights: OPTIONAL per-finding objects; populate per the USE-CHECK / OWN-RIGHTS rules above. use_check = {"source","quality"}: source is the cite of record the report renders — MANDATORY (spec-48 A4, symmetric) for ANY ASSERTED use status (token "confirmed" OR "not-confirmed") on a finding banded ${(framework && materialBandPhrase(framework)) || "medium risk or higher"}, not only use-negatives (the validator rejects an asserted use with no receipt: finding_use_check_missing); "unknown" needs none. quality: OPTIONAL, EXACTLY one of owner-site / independent / register-mirror — your read of what KIND of page the source is (the code re-derives its own classification and wins; a register mirror is never evidence of use). own_rights = {"source"} — MANDATORY for any own-rights-reliant finding.`,
       // U3 (probative grading) — a risk-RAISING signal must say what it proves about THIS conflict.
       `- bears_on: a string, MANDATORY whenever this finding's enforcer meter is "high" (and good practice for any other risk-RAISING adjustment): one line on what the fact proves about THIS mark against THIS owner's rights on the disputed element — e.g. "owner has asserted <element> against comparable <goods>", NOT a bare "aggressive enforcer". A default win on a different element, or against an obvious copycat, does not count: if you cannot say why it bears on this confusion, the fact is annotation and the enforcer meter is not "high".`,
       // doc-35 T1 (authority grounding — fetch-before-cite, like use_check/own_rights): an enforcement AUTHORITY