leadbay_top_accounts_to_activate

WHAT LEADBAY SHOULD REMEMBER

You keep your own memory of how this user likes to work — tone, naming, formatting, what they ask you to skip. Leadbay does not store that and does not need to.

What Leadbay does need is anything that changes who it should find. When the user states targeting criteria in conversation ("I target fleets over 100 vehicles", "carriers are a bad fit unless they do last-mile delivery", "climate engineering is also my market"), call leadbay_refine_prompt so it changes what Leadbay surfaces for the whole org and on every future refresh — not just this conversation. When they say a specific lead is wrong for them, record the dislike rather than noting it.

Build me a top-<the user-supplied value if any; otherwise a sensible default. Source: Optional: how many accounts the plan should hold (default 50).> account-conquest plan — the accounts worth activating, ranked, each one carrying a strategic motif, a phone pitch and a three-step checklist. <if the user supplied this argument, render the short block derived from it; otherwise empty. Source: Optional: restrict the plan to a territory (e.g. 'Indre-et-Loire', 'Région Ouest'). Sets geography on the Discover lens. A country is not a territory — this workspace already covers exactly one country.>

This deliverable goes in front of a paying client, so the honesty of the numbers matters more than their completeness. Deliver the strongest plan the available data actually supports, and be explicit about what it doesn't.

DATA PROVENANCE — every number carries its source. This deliverable mixes four data sources with very different trust levels, and it is shown to a paying client. A figure whose origin is unstated reads as measured fact. Tag every number you emit with exactly one class:

Tag	Meaning	Where it comes from
[ERP]	measured in the client's own invoicing / management extract	the file the user attached, or a leadbay_get_lead_custom_fields read of a value imported from it
[LB]	returned by a leadbay_* tool THIS session	leadbay_pull_leads, leadbay_pull_followups, leadbay_bulk_qualify_leads, leadbay_enrich_titles, leadbay_scan_portfolio_signals, leadbay_account_history, leadbay_research_lead_by_id
[SIRENE]	the French public company registry	recherche-entreprises.api.gouv.fr — your own web tool, NOT Leadbay. Leadbay does not proxy the registry
[HYP]	a modelled assumption	the €/employee benchmark, the 35 % objective, the trade purchase mix, any Tier-1 threshold the client hasn't confirmed

Taint propagates. A derived figure inherits the weakest class of its inputs. cash = pot12 − ca12 where pot12 is [HYP] makes cash itself [HYP] — say so in the artefact's own caveat block, not only in chat. A client who mistakes a modelled cash figure for an audited one will build a sales plan on it.

Print the PROVENANCE LEDGER before you build anything, BEFORE writing artifact code or the final table. The block below is a shape, not a literal: keep the header, the field / class / source columns and the closing rule, but replace every <...> placeholder with the real field name, class and source — one row per field you actually emit. A ledger still showing <field name> has passed the ordering check while telling the reader nothing, which defeats its entire purpose.

PROVENANCE LEDGER
=================
field           class     source
<field name>    ERP       <file>:col "<column header>"
<field name>    LB        <tool that returned it>
<field name>    SIRENE    recherche-entreprises.api.gouv.fr
<field name>    HYP       <the formula + which input is assumed>
<field name>    OMITTED   <why it cannot be computed>
=================

An OMITTED row is the point of the ledger: it makes a gap visible instead of silently filled with a plausible guess. Never drop a field from the ledger just because you couldn't source it — render it as OMITTED with the reason.