@sellable/mcp 0.1.142 → 0.1.144

package/skills/create-campaign-v2/references/filter-leads.md

@@ -1,143 +1,134 @@
 # Filter Leads
 
-CampaignOffer state and the watch link are canonical. Disk artifacts are
-optional debug/UAT diagnostics, and normal customer runs should not expose local
-draft files. Resume, gating, and handoff read campaign state first. Filter design
-may use the live lead sample or optional debug sample, but the active rubric save
-is `save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign
-table exists`.
+CampaignOffer state, the watched app, and campaign-table rows are canonical for
+normal create-campaign-v2 runs. Do not read, write, link, or surface local
+markdown/json progress artifacts in customer runs. Debug artifacts belong only
+to explicit debug/UAT or the legacy validation harness, and they are never the
+source of truth after a campaign shell exists.
+
+The middle step is a lightweight lead-quality audit and decision gate. It should
+add fidelity to the source estimate, convert repeated false positives into
+production rubrics, and protect the user from replies they would not want to
+take. It should not re-run sourcing, create a second source plan, or build a
+large scoring framework.
+
+## Inputs
+
+Use only live campaign inputs supplied by the parent thread or scoped MCP tools:
+
+- `campaignId`
+- campaign revision or `campaignUpdatedAt`
+- campaign brief content
+- approved source decision and selected lead list/source state
+- `workflowTableId`
+- imported bounded review-batch rows, including row ids/hash when available
+- user's filter choice and any explicit exclusions or tradeoffs
+
+The filter may inspect campaign-table rows through scoped tools such as
+`get_rows_minimal({ tableId: workflowTableId })` or equivalent parent-thread
+payloads. If the campaign id, selected source/list id, table id, or review-batch
+row ids do not match the branch input, report `stale` or `blocked`.
 
-The middle step is a lightweight lane audit and decision gate. It should add
-fidelity to the find-leads estimate, not re-run sourcing or produce a large
-scoring framework.
+## Evaluation Data Scope
 
-The business goal is not "find people who might reply." It is "every reply the
-user gets should come from someone they would be excited to hear back from:
-inside the ICP, able to act, and with a realistic path to buying." A lead who may
-reply but cannot buy, lacks budget, sits at the wrong account type, is a
-vendor/competitor, or is on the wrong side of a marketplace is not a good lead.
+Do not write final filters that depend on fields visible only in a source
+provider preview card. Sales Nav cards, Prospeo rows, and Signals rows are
+sampling evidence, not the full data contract.
 
-The exact qualification gates are client- and offer-specific, but the standard
-does not change: anyone we reach out to, and anyone who replies, should be worth
-the user's time to talk to. Use the client's price point, buyer, channel,
-delivery constraints, market, and competitor landscape to define the concrete
-gates for that campaign.
+Production rubrics should describe what we will decide after normal enrichment
+and public research have run. For example:
 
-Source interest is not qualification. A lead who engaged with a post, appeared
-in a Signals search, recently posted on LinkedIn, or "showed interest" in the
-topic has only supplied discovery context. That context can justify the source
-lane, improve pass-rate confidence, or help message generation; it must not
-become a production filter or `leadScoringRubric` item. If the source lane was
-built from topical engagement, the filter should still ask: is this the right
-role, seniority, account type, budget band, market, and non-competitor?
+- Good: keep US-licensed MD/DO dermatologists; verify credentials from the
+  enriched LinkedIn profile, professional bio, state-license page, or another
+  public source.
+- Bad: exclude rows missing MD/DO on the preview card.
 
-Ability to pay must be considered for every campaign, but it is only a required
-filter/rubric when the client, offer, or price point makes affordability a real
-qualification risk. Do not force an enterprise-budget screen onto a low-cost B2C,
-creator, prosumer, or small-team offer. Do not use a loose consumer-style screen
-for an enterprise, services-heavy, implementation-heavy, or paid-pilot offer.
-When affordability is material, `lead-filter.md` must name the campaign-native
-proxy that proves the prospect can afford this specific offer at this specific
-price point. Do not dodge this gate because the exact budget is unknown; use a
-reasonable public proxy such as funding, headcount, revenue band, team maturity,
-current tool spend, practice size, location count, consumer purchasing power,
-job-to-be-done intensity, or buyer budget ownership. If affordability is material
-and no reliable proxy exists in the sample or through normal enrichment, set
-`Status: confirm-with-user` and ask for the budget proxy before moving to message
-generation.
+If a preview row lacks enough evidence to prove a required rule, mark it as
+needs enrichment or borderline pending verification in the summary. Do not turn
+preview-card missingness into a hard production exclusion unless the same field
+will remain missing after enrichment.
 
-Use price-point proportionality:
+## Outputs
 
-- inexpensive B2C / prosumer / creator offers: do not require an explicit
-  ability-to-pay rule unless affordability is central to the ICP; fit is usually
-  based on use case, audience, life context, or intent, not company budget
-- a few-hundred-dollar SMB or self-serve B2B offer: require evidence of an
-  active business, relevant workflow, and enough commercial seriousness to pay
-  hundreds, but do not require enterprise scale
-- mid-market / paid pilot / agency or implementation-supported offer: require a
-  team, operational pain, and a likely owner for the budget
-- enterprise / high-ACV offer: require enterprise or upper-mid-market account
-  fit, budget-owning seniority, department maturity, and buying-process plausibility
+For `Status: confirmed`, persist durable rubrics with:
 
-Inputs:
+```js
+save_rubrics({ campaignOfferId, leadScoringRubrics });
+```
 
-- `brief.md`
-- `lead-review.md`
-- `lead-sample.json`
+Return a concise parent-thread summary containing:
 
-Outputs:
+- filter status: `confirmed`, `confirm-with-user`, or `revise-find-leads`
+- strongest keep rules
+- strongest exclusion rules
+- expected pass-rate / yield impact
+- production rubric JSON when confirmed
+- whether `save_rubrics` succeeded
+- any blocker that prevents message review from joining
 
-- `lead-filter.md`
-- optional `rubric.json`
+Do not create local filter files, sidecar JSON, or progress notes in normal
+customer runs. If debug/UAT output is explicitly requested, label it as a
+diagnostic copy and keep live campaign state as the durable source.
 
-Core constraint:
+## Qualification Standard
 
-- Every accepted filter in `lead-filter.md` must be directly translatable into
-  the production `LeadScoringRubric` shape. If a filter cannot become a
-  runnable rubric criterion from available row data or public research, it is
-  not an accepted filter; convert it to an optional enrichment note, a user
-  tradeoff, or a lead-source revision reason.
+The business goal is not "find people who might reply." It is "every reply the
+user gets should come from someone they would be excited to hear back from:
+inside the ICP, able to act, and with a realistic path to buying."
 
-## Evaluation Data Scope
+The exact gates are client- and offer-specific, but the standard does not
+change: anyone we reach out to, and anyone who replies, should be worth the
+user's time to talk to. Use the client's price point, buyer, channel, delivery
+constraints, market, and competitor landscape to define concrete gates for this
+campaign.
 
-Do not write final filters that depend on the limited fields visible in the
-source-provider preview card. Sales Nav cards, Prospeo rows, and Signals rows
-are sampling evidence, not the full data contract.
+Source interest is not qualification. A lead who engaged with a post, appeared
+in a Signals search, recently posted on LinkedIn, or showed interest in a topic
+has supplied discovery context only. That context can justify the source lane,
+improve pass-rate confidence, or help message generation; it must not become a
+production rubric item by itself.
 
-Production rubrics should describe what we will decide after normal enrichment
-and public research have run. For example:
+## Ability To Pay
 
-- Good: "Keep US-licensed MD/DO dermatologists; verify credentials from the
-  enriched LinkedIn profile, professional bio, NPI/state-license page, or other
-  public source."
-- Bad: "Exclude rows missing MD/DO on the Sales Nav card."
+Ability to pay must be considered for every campaign, but it is only a required
+rubric when the client, offer, or price point makes affordability a real
+qualification risk.
 
-If a preview row lacks enough evidence to prove a required rule, mark it as
-`needs enrichment` or `borderline pending verification` in sample findings. Do
-not turn preview-card missingness into a hard production exclusion unless the
-same missing field will remain missing after enrichment.
-
-## Primary Goal
-
-Use the actual sample to answer:
-
-- was the Step 2 projected-good-fit estimate basically right or wrong
-- which leads clearly match the buyer hypothesis
-- which leads are noise
-- which repeated false positives must become explicit exclusions
-- whether filters are enough, or whether the source lane would make the
-  campaign miss if launched as-is
-- whether the filtered leads are worth sending to for this client's offer and
-  price point, using an economic-fit proxy only when affordability is material
-
-## Table-Stakes Qualification Gates
-
-Confirmed production filters should fail closed on buyer quality. The default
-confirmed filter set must explicitly include each table-stakes gate below, or
-`lead-filter.md` must state why a gate is irrelevant for this campaign:
-
-Customize the concrete threshold for each gate to the client and offer. For
-example, "can afford this" might mean nothing explicit for a low-cost B2C tool,
-an active business for a few-hundred-dollar SMB offer, enterprise headcount for
-one client, a funded seed-stage team for another, multi-location practice size
-for another, or existing tool spend for another. Do not hard-code Sellable's
-exact budget, geography, or title rules into unrelated campaigns; hard-code the
-principle that passing leads must be worth the customer's time.
-Do not hard-code Sellable's exact budget into the filter; translate affordability
-into the client's native buying proxy.
+Use price-point proportionality:
+
+- inexpensive B2C, prosumer, creator, or community offers: usually qualify by
+  use case, audience, life context, or intent; do not require an explicit
+  budget rule unless affordability is central to the ICP
+- few-hundred-dollar SMB or self-serve B2B offers: require an active business,
+  relevant workflow, and enough commercial seriousness to pay hundreds
+- mid-market, paid-pilot, agency, or implementation-supported offers: require a
+  team, operational pain, and a likely owner for the budget
+- enterprise or high-ACV offers: require upper-mid-market or enterprise account
+  fit, budget-owning seniority, department maturity, and buying-process
+  plausibility
+
+When affordability is material, name the campaign-native proxy that proves the
+prospect can afford this specific offer at this specific price point. Use a
+reasonable public proxy such as funding, headcount, revenue band, team maturity,
+current tool spend, practice size, location count, consumer purchasing power,
+job-to-be-done intensity, or buyer budget ownership. If no reliable proxy exists
+in the review batch or normal enrichment path, return `confirm-with-user` and
+ask the parent to get the budget proxy before message approval.
+
+## Table-Stakes Gates
+
+Confirmed production rubrics should fail closed on buyer quality. The confirmed
+filter set must cover each relevant gate below, or the summary must explain why
+the gate is irrelevant for this campaign:
 
 - right role / function: the person owns or directly influences the buyer
   problem; wrong-function leads fail even when they match the source topic
 - right seniority / authority: the person can approve, pilot, champion, or
-  materially influence adoption; junior ICs fail unless the brief explicitly
-  targets them
+  materially influence adoption; junior ICs fail unless the brief targets them
 - account and channel fit: the company is the right account type and its buyers
-  are reachable through the chosen channel, such as LinkedIn for LinkedIn
-  outbound campaigns
-- economic capacity / ability to buy, when material: the prospect has an
-  appropriate price-point proxy for the offer, such as active business status,
-  headcount, revenue, funding, team size, practice size, location count,
-  department maturity, existing tooling, or budget ownership
+  are reachable through the chosen channel
+- economic capacity / ability to buy, when material: the prospect has a
+  price-point-appropriate proxy for the offer
 - competitor / vendor / wrong-side exclusion: competitors, adjacent vendors,
   agencies/service providers, resellers, and marketplace-side conflicts fail
   unless the brief explicitly targets that group
@@ -147,83 +138,45 @@ into the client's native buying proxy.
 - active current-role safety: score the person's current role and company, not
   stale prior roles, advisor blurbs, investor bios, or old engagement context
 
-Do not replace these gates with a "shown interest" or "engaged with relevant
-content" rule. Interest can help find a warmer list, but it does not prove the
-lead is a buyer.
-
-## Standard Competitor / Vendor Exclusion
+## Competitor / Vendor Exclusion
 
 Every confirmed filter should include a competitor / vendor / wrong-side
-exclusion unless the brief and sample make it clearly irrelevant. This is a
-standard production safety rule, not an optional nice-to-have.
+exclusion unless the brief and review batch make it clearly irrelevant.
 
-Use this simple test:
+Use this test:
 
 - Would this company, product, service provider, agency, consultant, reseller,
   or marketplace participant appear on the same comparison page as the client?
 - Would they compete for the same customer budget, sell into the same buyer
   workflow, or sit on the wrong side of the marketplace?
-- Did the sample show adjacent companies that a client would likely reject only
-  after seeing the list?
+- Did the review batch show adjacent companies that the customer would likely
+  reject only after seeing the list?
 
 If yes, add an explicit exclude rule. Include named competitors from the brief,
-sample, or user context when available, plus the general category exclusion so
-new lookalike competitors are also blocked. If a competitor/vendor exclusion is
-omitted, `lead-filter.md` must say why it is not applicable.
-
-Treat this as part of the manual review loop. When the user or client sees a
-sample and says "these companies are not a fit," update the exclusion watchlist
-and filter draft before Step 4. Use `confirm-with-user` when the sample contains
-ambiguous adjacent vendors, competitors, agencies, marketplace-side conflicts,
-or reseller/consultant roles where excluding them would materially shrink the
-lane.
-
-## `lead-filter.md` Shape
-
-````md
-# Lead Filter
-
-Status: confirmed | confirm-with-user | revise-find-leads
-
-## Decision
-
-- continue | confirm with user | revise find-leads
-- one plain-English sentence saying why
-
-## Who We'll Keep
+review batch, or user context when available, plus the general category
+exclusion so new lookalike competitors are also blocked.
 
-- buyers we would be excited to get a reply from, including the role, authority,
-  account type, and price-point-appropriate commercial-fit signal that make the
-  reply worth taking
+## Marketplace Safety
 
-## Who We'll Exclude
+Two-sided marketplaces need an explicit wrong-side exclusion when the same
+public lead pool can contain both the intended buyer and a forbidden
+counterparty. If the campaign brief declares a marketplace, the filter must name
+the accepted side of market and the forbidden side of market.
 
-- people who may reply but are not worth sending to because they lack authority,
-  lack a plausible budget path when budget is material, sit at the wrong account
-  type, or are competitors/vendors/wrong-side marketplace participants
+Examples:
 
-## Sample False Positives
+- Demand-side buyer campaign: exclude supply-side contractors, contributors,
+  applicants, or providers even if they match topical signals.
+- Supply-side acquisition campaign: exclude demand-side buyers or employers when
+  they are not the outbound target.
 
-- ...
+If more than roughly 20% of the review batch appears to be the forbidden side,
+classify it as a list/source problem and return `revise-find-leads`; do not
+hide that problem behind narrow rubrics.
 
-## Optional Supporting Rule
+## Production Rubric Shape
 
-- omit this section unless exactly one supporting rule materially helps messaging or prioritization
-
-## Pass Rate
-
-- ...
-
-## Recommendation
-
-- proceed to generate message
-- or revise leads / revise filter
-
-## Implementation Details
-
-If `Status: confirmed`, include production rubrics. The `economic_capacity`
-example below applies when affordability is material; omit it for inexpensive
-B2C/prosumer/community offers where ability to pay is not a meaningful fit gate:
+Confirmed rubrics must use the production `LeadScoringRubric` fields exactly:
 
 ```json
 {
@@ -236,383 +189,104 @@ B2C/prosumer/community offers where ability to pay is not a meaningful fit gate:
       "isRequiredCheck": true,
       "allowPartialCredit": false,
       "strictMatching": false
-    },
-    {
-      "checkName": "company_fit",
-      "description": "Lead works at a company type validated by the sample.",
-      "criterion": "Yes if the current company matches the accepted account type from the brief and sample. No if the company is a vendor, agency, competitor, or structurally wrong account type.",
-      "reason": "The message thesis depends on this company context being true.",
-      "isRequiredCheck": true,
-      "allowPartialCredit": false,
-      "strictMatching": false
-    },
-    {
-      "checkName": "economic_capacity",
-      "description": "Prospect has a price-point-appropriate ability-to-pay proxy.",
-      "criterion": "Yes if public or enriched data shows the prospect is likely able to afford this specific offer using the campaign's chosen proxy, scaled to the price point. For low-cost B2C/prosumer offers, this may be personal fit and purchasing power. For a few-hundred-dollar SMB/self-serve offer, this may be an active business and relevant workflow. For paid-pilot, implementation-heavy, mid-market, or enterprise offers, this may require funding, revenue, headcount, department maturity, existing tool spend, location count, or budget-owner title. No if the prospect is structurally unable to buy at the offer's price point or missing the required proxy after enrichment.",
-      "reason": "Replies from accounts without a realistic budget path waste the user's time even when the person is warm or interested.",
-      "isRequiredCheck": true,
-      "allowPartialCredit": false,
-      "strictMatching": false
     }
   ]
 }
 ```
 
-If `Status: confirm-with-user` or `Status: revise-find-leads`, do not include
-production rubrics yet. Explain why the draft filter is not locked downstream.
-
-## Required Keep Rules
-
-- technical source rules, if different from the plain-English keep list
-
-## Required Exclude Rules
+Rules:
 
-- technical source rules, if different from the plain-English exclude list
-````
+- persist 2-5 rubric criteria total
+- default every rule to `isRequiredCheck: true`
+- allow at most one optional/non-required rule
+- do not duplicate two rules that restate the same keep/exclude idea
+- keep title / role fit explicit with concrete pass and fail title patterns
+- use `allowPartialCredit: false` for hard gates where ambiguity should fail
+- use `strictMatching: true` only for exact named-account or exact-token matching
+- write criteria that can be evaluated from campaign-table rows, enrichment, or
+  normal public research
+- keep source mechanics out of production rubrics: provider lane, recently
+  posted, first-send order, engagement source, priority cohort, and topical
+  interest can inform messaging or prioritization, but they are not ICP fit
 
-Rules:
+Recommended grouping:
 
-- `Decision` is mandatory and must appear before filter details
-- default to `Status: confirmed` when the source lane is viable and filters are
-  enough to protect the campaign
-- use `confirm-with-user` only when the lane is viable but there is a real
-  strategic tradeoff the user must choose before launch
-- use `revise-find-leads` only when filters would be so heavy, low-volume, or
-  thesis-distorting that launching from this lane would likely miss
-- always emit a readable draft filter, even when status is `confirm-with-user`
-  or `revise-find-leads`, so the user can inspect and edit the AI's definition
-  of a good fit
-- `Who We'll Keep` and `Who We'll Exclude` are mandatory user-facing sections
-- `Required Keep Rules` and `Required Exclude Rules` are allowed as technical
-  source sections, but should appear after `Implementation Details` if present
-- `Sample False Positives` must be grounded in observed sample leads
-- `Optional Supporting Rule` is allowed only when one rule clearly helps later
-  messaging or prioritization
-- never emit more than one optional/non-required rule
-- `Implementation Details` is mandatory for every status
-- `Implementation Details` must contain one fenced JSON object with
-  `leadScoringRubrics` only when `Status: confirmed`
-- non-confirmed filters are draft/user-review artifacts, not official Step 4
-  inputs
-- `leadScoringRubrics` must contain 2-5 production-shaped rubric items, not one
-  item per bullet
-- confirmed `leadScoringRubrics` must include an explicit ability-to-pay /
-  economic-capacity check when affordability is material to fit: a few-hundred-
-  dollar B2B offer, paid pilot, implementation-heavy sale, mid-market sale, or
-  enterprise/high-ACV motion. Do not require this check for inexpensive B2C,
-  prosumer, creator, community, or otherwise low-friction offers unless
-  affordability is central to the ICP. When present, the check must be
-  price-point-appropriate for the client and offer: commercial-seriousness based
-  for a few hundred dollars, budget-owner based for mid-market/enterprise. Do not
-  rely on role fit, company fit, or source engagement to imply this.
-- do not put source-path mechanics or send-priority hints into
-  `leadScoringRubrics`. Examples: recently posted on LinkedIn, came from a
-  Signals search, appeared in Sales Nav, was found by Prospeo, first-send wave,
-  priority cohort, engaged with selected posts, showed interest in the topic,
-  or matched a signal-discovery keyword. If that signal was already used in the
-  search, mention it in `Pass Rate` or `Recommendation`; if it helps messaging,
-  pass it to message generation as source context, not as a production rubric or
-  supporting fit rule.
-- do not put DNC or one-off relationship-safety notes into
-  `leadScoringRubrics` unless the sample shows that family is likely to leak at
-  meaningful volume and normal DNC/domain suppression will not catch it. Former
-  employers, existing customers, investors, partner lists, and "do not contact"
-  domains usually belong in `Recommendation` or a DNC note, not in ICP scoring.
-- confirmed `leadScoringRubrics` must protect sales quality, not just surface
-  similarity. They must cover the table-stakes qualification gates unless
-  `lead-filter.md` explicitly justifies why a gate is irrelevant:
-  - right role / function fit
-  - buyer seniority / authority
-  - account or company-type fit
-  - economic capacity / ability to buy, when material, using a campaign-native
-    proxy such as active business status, headcount, revenue, funding, practice
-    size, location count, patient volume, department maturity, existing tooling,
-    or budget-owner title
-  - geography / market, when relevant
-  - active-current-role safety
-  - hard exclusions for competitors, vendors, agencies, job seekers,
-    wrong-function leads, and wrong-side marketplace participants
-- confirmed `leadScoringRubrics` should include a competitor / vendor /
-  wrong-side exclusion by default. It can be bundled with account-fit only when
-  the criterion still names both the accepted account type and the excluded
-  competitor/vendor/wrong-side categories.
-- when one production rubric bundles multiple families, the criterion must say
-  exactly which buyer-quality gates it covers
-- if the filter cannot be compiled into 2-5 production rubric items, do not
-  confirm; return `confirm-with-user` or `revise-find-leads`
-- hide raw rubric flags from the top user-facing sections; keep
-  `isRequiredCheck`, `allowPartialCredit`, and `strictMatching` inside
-  `Implementation Details`
-
-## Rule Families To Preserve
-
-When relevant to the brief and sample, preserve these recurring families:
-
-- buyer role / seniority
-- wrong-function exclusions
-- company-type exclusions
-- economic capacity / ability-to-pay proxy
-- competitor / vendor / intermediary exclusions
-- geography
-- company size
-- active current-role status
+- buyer authority / role fit
+- company / industry / provider-lane fit
+- economic capacity / ability to buy, when material
+- geography / size / stage fit, when relevant
+- competitor / vendor / wrong-side / repeated false-positive exclusion
+- one optional buyer-quality qualifier, at most, only when it changes fit
+  scoring rather than send ordering
 
 ## Sample-Judging Method
 
 For each proposed rule:
 
-1. inspect matching and failing sample leads
-2. decide whether the rule removes real noise or blocks real buyers
-3. mark the rule as necessary, loosen, or remove
-4. record the resulting pass rate
+1. Inspect matching and failing review-batch rows.
+2. Decide whether the rule removes real noise or blocks real buyers.
+3. Mark the rule as necessary, loosen, or remove.
+4. Estimate the resulting pass rate and yield impact.
 
 Repeated false positives should become explicit exclude rules whenever the same
-pattern appears more than once in the sample.
+pattern appears more than once in the review batch. Preview-card missingness is
+not a hard production exclusion unless the same missing evidence will remain
+missing after normal enrichment/public research.
 
-## `rubric.json` Sidecar
+## Source Contradictions
 
-Only emit a sidecar when a downstream step needs a separate file. The same
-production-shaped items must always appear as fenced JSON in `lead-filter.md`
-under `## Implementation Details`, even when `rubric.json` is omitted.
+If review-batch evidence contradicts the approved source thesis, do not rewrite
+the campaign brief silently. Return one of these instead:
 
-Shape:
+- `confirm-with-user` when a viable alternative source or filter tradeoff needs
+  customer choice.
+- `revise-find-leads` when the selected lane is contaminated, too low-yield, or
+  aimed at the wrong buyer side.
 
-```json
-{
-  "leadScoringRubrics": [
-    {
-      "checkName": "role_fit",
-      "description": "Lead holds one of the validated buyer titles.",
-      "criterion": "Yes if the current title matches one of the accepted buyer titles. No if the title is a wrong-function, junior, advisory-only, or service-provider title.",
-      "reason": "The campaign only works when the recipient owns the buyer problem and can act on the offer.",
-      "isRequiredCheck": true,
-      "allowPartialCredit": false,
-      "strictMatching": false
-    }
-  ]
-}
-```
+Only the parent thread updates campaign brief/source state, and only after the
+user approves the change.
 
-Rules:
+## Provider-Lane Fit Density Anchors
 
-- derive every sidecar rule from `lead-filter.md`
-- default every rule to `isRequiredCheck: true`
-- allow at most one `isRequiredCheck: false` rule
-- do not add a rule that is not present in `lead-filter.md`
-- do not duplicate two rules that restate the same keep/exclude idea
-- use the production fields exactly: `checkName`, `description`, `criterion`,
-  `reason`, `isRequiredCheck`, `allowPartialCredit`, and `strictMatching`
-- prefer 2-5 rubric criteria total; do not map every keep/exclude bullet into
-  its own scoring row
-- include an explicit ability-to-pay criterion when affordability is material to
-  fit. It may be bundled with company size/stage only when the `checkName`,
-  `description`, and `criterion` still name the budget proxy directly.
-- production rubric criteria should be buyer-quality gates, not execution
-  metadata. Do not create rubric rows for provider source, recently-posted
-  priority, first-send ordering, or other search mechanics unless the user
-  explicitly asks to score that as part of ICP fit.
-- production rubric criteria should not become one-off DNC lists. Named-company
-  exclusions are appropriate when they represent a repeated false-positive
-  category, a true competitor class, or a material lane risk; otherwise preserve
-  them as DNC/suppression instructions outside the rubric JSON.
-- do not write "these rules are expressible as rubrics" as a substitute for the
-  actual 2-5 item draft
-- bundle repeated false positives into a single exclusion criterion when they
-  are the same kind of failure, for example vendors / competitors /
-  wrong-side providers
-- keep title / role fit as its own explicit criterion with concrete pass and
-  fail title patterns
-- use `allowPartialCredit: false` for hard gates where ambiguity should fail
-- use `strictMatching: true` only when the rule depends on exact named-account
-  or exact-token matching
+Use these as rough regression anchors, not hard pass/fail rules:
 
-Recommended rubric grouping:
+| Lane                                 | Typical FIT density | Archetype                                 |
+| ------------------------------------ | ------------------: | ----------------------------------------- |
+| Prospeo vertical SMB                 |              60-80% | vertical owner/operator lists             |
+| Sales Nav horizontal enterprise      |              40-55% | broad executive or department-owner lists |
+| Sales Nav dev tools / specific infra |              30-45% | SRE, platform, engineering infrastructure |
+| Signals overlay                      |              20-35% | topical engagement layered onto an ICP    |
 
-- buyer authority / role fit
-- company / industry / provider-lane fit
-- economic capacity / ability to buy, when material
-- geography / size / stage fit, when relevant
-- competitor / vendor / wrong-side / repeated false-positive exclusion
-- one optional buyer-quality qualifier, at most, only when it changes fit scoring
-  rather than send ordering
+Interpretation:
 
-Rubric-readiness checklist:
+- Density near the high end: source lane is probably fresh and viable.
+- Density below the band: inspect whether the filter is too tight or the lane is
+  approaching exhaustion.
+- Density dramatically below the band: likely source contamination, ICP drift,
+  or provider-side weakness; investigate before launch.
 
-- Can this rule be evaluated from `lead-sample.json`, provider row fields,
-  enrichment, or normal public research?
-- Does the criterion say both what passes and what fails?
-- Is the reason a business rationale, not a restatement of the criterion?
-- Would `save_rubrics` accept this without adding missing fields?
-- Would `evaluate-icp-fit-enriched` have enough prospect-side data or
-  Googleable facts to score it?
+## Decision Rules
 
-## Prohibited During Phase 84
+- Use `confirmed` when the source lane is viable and the rubrics are enough to
+  protect reply quality.
+- Use `confirm-with-user` when the lane is viable but there is a real strategic
+  tradeoff or missing business proxy the user must choose before message
+  approval.
+- Use `revise-find-leads` when filters would be so heavy, low-volume, or
+  thesis-distorting that launching from this lane would likely miss.
+- Do not save rubrics for `confirm-with-user` or `revise-find-leads`.
+- Do not loosen the filter just to preserve volume.
+- Do not make the filter so narrow that it contradicts the approved source
+  unless review-batch evidence clearly requires it.
+
+## Prohibited During Normal Create-Campaign
 
 - calling `check_rubric`
-- calling `save_rubrics`
-- using campaign-backed rubric tools
 - creating a second independent rubric design
-- blocking Phase 84 when only `rubric.json` fails and `lead-filter.md` is valid
-
-## Marketplace safety rail (two-sided archetypes)
-
-When brief §14 declares a marketplace with an explicit forbidden
-side-of-market (e.g. Skillsync forbids cold-outbound to supply-side
-GitHub contributors; the indexed pool is NEVER the outbound target),
-the lead-filter MUST include a forbidden-role exclude rule naming the
-supply-side title family.
-
-### Enforcement at filter-write time
-
-- `lead-filter.md` Required Exclude Rules MUST contain at least one
-  rule pattern-matching the forbidden side's title family (e.g.
-  "exclude 'Software Engineer' / 'Staff Engineer' / GitHub
-  contributor profile signal for Skillsync-like marketplaces").
-- If brief §14 declares the marketplace but the filter does NOT include
-  the forbidden-side exclude rule, surface this as a `revise-rubric`
-  precondition failure. Do NOT proceed to the commit gate.
-
-### Enforcement at validate-sample time
-
-- The Plan 85-02 validate-sample loop treats `>20% of sample rows
-matching the brief §14 forbidden side` as a **LIST problem** (not a
-  brief problem). Rationale: the sourced list is contaminated with
-  the wrong side of the marketplace; operator must re-source.
-- Detection signal: row title/profile matches the supply-side family
-  declared in brief §14, even if the title whitelist at §5 ICP
-  accidentally allows it.
-
-### Why this matters
-
-Marketplaces are the only B2B archetype where the same LinkedIn pool
-contains both the intended buyer and the forbidden counterparty. A
-marketplace operator who accidentally drafts InMail to a supply-side
-contributor has simultaneously:
-
-1. Violated their own TOS with that contributor (cold InMail for a
-   non-applied-to "hiring" pitch).
-2. Leaked their own product positioning (we target engineers,
-   implying we sell you as a vendor).
-3. Poisoned the cohort's recall rate for real demand-side buyers.
-
-A filter-spec safety rail catches the drift BEFORE Step 13 import.
-A validate-sample signal catches the drift if it still slips through.
-
-Plan 95-07 surfaced this residual on the Skillsync walkthrough; Plan
-95-08 ships the rail.
-
-## Post-Filter Signal Enrichment Pass (Sales Nav lane)
-
-After `lead-filter.md` lands and the Pass Rate is recorded, run a bounded
-signal-enrichment pass on FIT rows whose primary lane is Sales Nav and
-whose `lead-sample.json` entry has `recent_posts.length === 0` (the
-Sales Nav lane does not carry post data natively).
-
-This pass directly addresses the Earned-right + Read-as-1:1 substance
-filters in Phase 84. Without row-level post data, the generator has
-nothing to quote back, forcing either (a) category-level openers that
-trip Read-as-1:1, or (b) presumption-led openers that trip Earned-right.
-
-Contract:
-
-- **Scope:** only FIT rows (or the top K rows when FIT count > K).
-- **Budget cap K:** top 10 FIT rows by score. Do NOT enrich MAYBE or
-  REJECT rows in Phase 84 — they are not headed to messaging.
-- **Tool:** `mcp__sellable__fetch_linkedin_posts` (per-row call). If the
-  tool is unavailable in the current harness, skip the pass entirely
-  and document in Findings.
-- **Fetch:** the most recent 3-5 posts per row.
-- **Append to `lead-sample.json`:** each enriched row gets a
-  `recent_posts[]` array with `{ url, posted_at, excerpt }` entries
-  (200 char excerpt cap per post).
-- **Rows with zero public posts:** keep `recent_posts: []`. This is
-  valid data — the absence signals "quiet-profile row, use trigger or
-  peer-observation angle instead".
-- **Order of operations:** run AFTER `lead-filter.md` is written, BEFORE
-  `message-validation.md` starts drafting. The enriched
-  `lead-sample.json` is the input to the per-row signal extraction pass
-  in the generator.
-
-Findings update:
-
-- Record enrichment outcome at the bottom of `lead-filter.md` under a
-  new `## Signal Enrichment` heading: rows attempted, rows with posts,
-  rows with zero posts, tool failures.
-- If more than 50% of enriched rows have zero posts, flag the sample as
-  "low signal density" and recommend the generator's peer-observation
-  fallback angle with the Findings-surface warning.
-
-This pass does NOT apply to:
-
-- Signals-lane rows (already carry post data natively)
-- Prospeo-lane rows (messaging is usually event/job-post-led, post
-  data is secondary)
-- live-campaign mode (enrichment happens per-row during Research)
-
-## Brief-Validated Rewrite Authority
-
-When `lead-review.md` shows that the Phase-83 primary lead-source picked an
-UNVALIDATED lane (no source-material support) AND the alternative source
-yields ≥ 5× FIT leads in the same sample, `brief-validated.md` may rewrite
-exactly two Phase-83 brief sections:
-
-- §3 Campaign Thesis — update the source-hypothesis line to reflect the
-  higher-yielding lane as primary.
-- §12 Next Steps — update the first lead-search step to start on the
-  higher-yielding lane.
-
-Every rewrite must include an evidence citation block quoting
-`lead-review.md`:
-
-```md
-> Evidence (from lead-review.md):
->
-> - Signals sample: 2 rows, 0 FIT
-> - Sales Nav sample: 25 rows, 3 FIT + 7 MAYBE
-> - Primary-lane reversal: Sales Nav ≥ 5× Signals FIT yield in the same
->   preview.
-```
-
-All OTHER Phase-83 brief sections remain read-only during Phase-84. This
-authority is narrowly scoped to one specific failure mode — UNVALIDATED
-primary-source picks contradicted by real preview data. It is NOT a general
-brief-rewrite license. Do not use it to rewrite ICP, Buyer Pain, Offer
-Strategy, Social Proof, Differentiators, Message Thesis, or any other
-section. Those deltas continue to flow through `lead-filter.md` and
-`message-validation.md` as today.
-
-If the evidence is ambiguous (e.g. 2 FIT Signals vs 4 FIT Sales Nav — under
-5× ratio), DO NOT rewrite. Flag the weak preference in `lead-filter.md`
-§ Recommendation instead.
-
-## Provider-lane expected FIT density
-
-Observed during Phase 94 + Phase 95 UAT. Use as anchor for judging whether
-a lane is "lane exhausted" (see `references/step-13-import-leads.md`) or
-genuinely weak.
-
-| Lane                                       | Typical FIT density | Archetype examples                                           |
-| ------------------------------------------ | ------------------- | ------------------------------------------------------------ |
-| **Prospeo** (vertical SMB)                 | 60-80%              | Patientdesk (dental practice owners); vertical B2C-style SMB |
-| **Sales Nav** (horizontal enterprise)      | 40-55%              | Ambral (enterprise CS); Skillsync (eng-led companies)        |
-| **Sales Nav** (dev tools / specific infra) | 30-45%              | IncidentFox (SRE/Platform leaders at Series B-D SaaS)        |
-| **Signals** (overlay — warm-scored)        | 20-35%              | Overlay added to any lane; rate depends on topical density   |
-
-Interpretation:
+- reading or writing local markdown/json progress artifacts
+- inspecting the product database directly
+- queueing enrichment, filtering, or Generate Message cells
+- claiming filters are persisted before `save_rubrics` succeeds
 
-- **Density at the high end of the band** — fresh lane; import cap should
-  be aggressive (bump importLimit from 100 default to 200+ if needed).
-- **Density below the band** — either the filter is too tight OR the lane
-  is approaching exhaustion (most good rows already imported in prior runs).
-  Check dedup ratios to distinguish.
-- **Density dramatically below band** — likely a brief problem (ICP too
-  narrow) or a provider-side issue. Diagnose before reruning.
-
-Plan 95-05 Patientdesk observed ~70% FIT density on Prospeo (top of band).
-Plan 95-03 Ambral observed ~47% on Sales Nav horizontal enterprise (mid band).
-Plan 95-01 IncidentFox observed ~36% on Sales Nav dev-infra (mid-low band).
-Plan 94-07 Skillsync observed ~32% on Signals (mid band for overlay).
-
-Use these as regression anchors: a 10%+ drop from the archetype's
-historical density on a lane = investigate before escalating to operator.
+Workflow cell execution waits until filters are resolved, rubrics are saved when
+filters are enabled, and the user approves the message template/token rules.