docs(evidence): AI platform discovery vs recommendation analysis

User-facing copy constraint; keep ranges as ASCII hyphens.

README.md

@@ -1,28 +1,38 @@
-# geolocal.io — planning-rev2
+# geolocal.io — planning-selfserve-audit
 
-**Net-new planning branch** (2026-09-15 session). Not a clone of `main`. Do not merge main docs here.
+**Review surface branch** (from `planning-rev2` 2026-09-15 session lineage). Hot self-serve / remediation work 2026-10-01. Not a clone of `main`. Do not merge main docs here.
+
+**Start here for Ty review:** [`REVIEW.md`](REVIEW.md)
 
 ## Map (locked)
 
 | Path | Role |
 | :--- | :--- |
+| `REVIEW.md` | Review package (requirements, decisions, flags, branch map, checklist) |
 | `docs/BUSINESS_PLAN.md` | **Only** home for the business idea / strategy / GTM / wedge / workflow / MCP / packaging |
 | `docs/GLOSSARY.md` | Industry terms only |
 | `docs/product/genre-packs.md` | Layer A/B/C index (how we surface work to owners) |
 | `docs/product/genre-packs/` | Field SoT (`SOURCES.md`, `core3-field-map.md`) + genre notes (`salon.md`, `bakery.md`) |
 | `docs/evidence/` | Sourced research notes (cite URL) — not strategy |
+| `docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md` | Self-serve AI discoverability concept + phased plan (amend in place; one SoT) |
+| `docs/CONVENTIONS.md` | Anti-duplication docs rules (one-concept-one-file) |
+| `docs/writing-rules.md` | Outsider-first writing rules for strategy/research prose |
+| `docs/ALTERNATE_BUSINESS_PROPOSAL.md` | Alternate commercial thesis (ticket-set / warehouse); does not amend concept SoT |
+| `docs/research-brief.pdf` | PDF packaging of research brief / alternate proposal |
 
 ## Placement rules (agents must follow)
 
 1. Strategy / GTM / wedge / owner workflow / surfaces / MCP / distribution / packaging → **fold into** `docs/BUSINESS_PLAN.md`. Never spawn a sibling strategy file.
 2. New industry term → `docs/GLOSSARY.md`.
 3. Platform field / API / UI claim → open `SOURCES.md`, update field map. No invented matrices.
-4. External survey / report → `docs/evidence/<SOURCE>-<year>.md` with source URL. Link from the plan; don’t paste essays into the plan.
+4. External survey / report → `docs/evidence/<SOURCE>-<year>.md` with source URL. Link from the plan; don't paste essays into the plan.
 5. **No new `docs/*` top-level folder** unless Ty explicitly approves.
-6. Checkpoint log stays **inside** `BUSINESS_PLAN.md` (trim; don’t spawn `DECISIONS.md`).
-7. Two “layer” vocabularies — keep them distinct:
+6. Checkpoint log stays **inside** `BUSINESS_PLAN.md` (trim; don't spawn `DECISIONS.md`).
+7. Two "layer" vocabularies — keep them distinct:
    - **Layer A/B/C** = how we surface work (universal / genre / known-for) → `genre-packs.md`
    - **Beyond NAP** = shared basics → provider extras → provider stacks → section inside `BUSINESS_PLAN.md`
+8. Self-serve AI discoverability concept / phased plan → amend `docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md` only (see `docs/CONVENTIONS.md`). Do not spawn PLAN/CONCEPT twins.
+9. `docs/ALTERNATE_BUSINESS_PROPOSAL.md` is an explicit alternate thesis file already on this lineage; do not fold it into the concept SoT without Ty saying so.
 
 ## Process
 

REVIEW.md

@@ -0,0 +1,183 @@
+# Review package - planning-selfserve-audit
+
+**Repo:** Ty_Tech/geolocal-io  
+**Review branch:** `planning-selfserve-audit`  
+**Package commits:** `5ac84b6` (add REVIEW) · `1dfbbcd` (ASCII dashes) · tip = this branch HEAD  
+**Primary SoT:** [`docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md`](docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md)  
+**Strategy spine:** [`docs/BUSINESS_PLAN.md`](docs/BUSINESS_PLAN.md) §1 North Star  
+**Conventions:** [`docs/CONVENTIONS.md`](docs/CONVENTIONS.md) · [`docs/writing-rules.md`](docs/writing-rules.md)  
+**Parallel (non-SoT):** [`docs/ALTERNATE_BUSINESS_PROPOSAL.md`](docs/ALTERNATE_BUSINESS_PROPOSAL.md) · [`docs/research-brief.pdf`](docs/research-brief.pdf)  
+**Field / API evidence (Core 3):** [`docs/product/genre-packs/SOURCES.md`](docs/product/genre-packs/SOURCES.md)
+
+## Goal
+
+Make this branch review-ready so Ty can approve without re-litigating. Decisions and open flags live in-repo here. No product closures invented in this file: contradictions are **FLAG**ged for Ty.
+
+## SoT pointers
+
+| Layer | File | Owns |
+| :--- | :--- | :--- |
+| Product architecture | CONCEPT | Remediation stack, fan-out honesty, lanes, genre parents, phases |
+| Strategy / GTM / wedge | BUSINESS_PLAN | North Star intent, Discovery foundation / Core 3, owner workflow, MCP distribution |
+| Parallel thesis (non-SoT) | ALTERNATE + research-brief.pdf | Action-plan / warehouse framing; denser aggregator evidence |
+| Core 3 field/API only | SOURCES + core3-field-map | Do not treat as deep edit URL inventory for ranks 1-14 |
+
+Amend CONCEPT in place only. Evidence under `docs/evidence/`. No twin PLAN/NOTES/BRIEF beside CONCEPT. Do not merge or kill ALTERNATE. No force-push to `main`.
+
+## Requirements (what “done enough to review” means)
+
+- [ ] Mission readable without jargon: help owners get AI to recommend them; MCP = pipe not product; industry graph = Northstar, not v1
+- [ ] Scoreboard explicit: Presence + Recommendability
+- [ ] Problem = black box of NAP/category copies; claim once → correct outward
+- [ ] Solution still labeled architect-not-built: audit findings → correction tickets; held multi-platform verification as moat
+- [ ] Stakeholder verify / prove-the-shop-is-theirs treated as first-class pain (not optional)
+- [ ] Lane model present: Lane A umbrellas (Data Axle, Localeze, Foursquare) + Lane B per-platform majors
+- [ ] Every material claim either cited or marked BLOCKED / FLAG
+- [ ] No sibling PLAN/CONCEPT twins for the same subject (CONVENTIONS)
+
+## Research-backed requirements
+
+Musts already encoded in CONCEPT (morning 2026-10-01 commits). Do not weaken in review copy.
+
+- **Ticket shape (must):** field + wrong value + right value + proof URL (GBP / claimed truth). Same shape for Lane A and Lane B.
+- **Two lanes (must):** Lane A umbrellas (Data Axle, Localeze, Foursquare) stop feed regen; Lane B claim / suggest-edit on own-DB surfaces. Umbrella-only or platform-only both fail.
+- **One-click = ticket set (must):** not one syndication rewrite of the internet. Mint GBP-proof + Lane A + Lane B; re-audit = success check.
+- **Fan-out ceiling (must productize honesty):** Localeze claim-once → many publishers, partner cadence often ~30-90 days, no partner-acceptance guarantee; Google fast-path needs separate verify/sync inside their product; Data Axle hours to ~two weeks on hard cases; **no free public one-to-many SMB fan-out API**; Yext-class = paid pipe not destination; GBP does **not** outbound-syndicate NAP; Apple writes Apple ecosystem only.
+- **Held verification:** multi-platform verified status = moat; paid / fulfillment architecture, not free first-hour (align with BUSINESS_PLAN paid cleanup = fulfillment, not the product center).
+- **Presence score inputs (open):** Core 3 min-bar lives in BUSINESS_PLAN + genre-packs. CONCEPT still open on Yelp + aggregators in v1 Presence. **FLAG** before claiming “we check X.”
+- **V1 shell FLAG:** CONCEPT = interactive web first, revisit MCP ~3 months; BUSINESS_PLAN Owner MCP P0 parallel with web chat. Packaging must not pick a side. **FLAG for Ty.**
+
+## Decisions locked (do not re-litigate in review)
+
+1. Agent-era local SMB discoverability is the spine; MCP is implementation option, not the strategy product.
+2. Industry graph is longer-term Northstar, not v1.
+3. Single SoT file for self-serve AI discoverability = CONCEPT (amend in place).
+4. Presence + Recommendability as the two scored outcomes of the North Star intent.
+5. Two-lane remediation: umbrellas (A) + per-platform (B); ranked majors with owner remediation paths.
+6. Stakeholder verification before honest audit / warehouse overwrite is core pain and action-plan step A.
+7. Collaborator/chat-first process: write only on explicit amend/capture; no doc mill.
+
+## Remediations: resolve vs flag taxonomy
+
+| Class | Meaning | Reviewer action |
+| :--- | :--- | :--- |
+| **Resolve** | Owner (or product) can complete a concrete correction path with a known surface. Acceptance can be tracked. | Expect ticket shape: wrong value → right value → proof link → platform channel. |
+| **Flag** | Known gap, commercial unknown, or timing risk that blocks shipping a path. | Keep visible; do not invent a product decision to close it. |
+| **Hybrid (demoted)** | Earlier hybrid genre/parent framing - demoted to a flag unless CONCEPT re-elevates it. | Do not treat as locked architecture. |
+
+Lane A: Data Axle, Localeze/TransUnion, Foursquare. Lane B: GBP first as proof, then other ranked platforms (see CONCEPT 1-14).
+
+### Ranked stack 1-14 (status for review)
+
+Documented with owner workflows in CONCEPT (commits `20b1f9f` → `95cd0a1` → `967ba9a`). All are **architect-not-built** Resolve paths unless noted Flag.
+
+| Rank | Surface | Lane | Status |
+| :---: | :--- | :--- | :--- |
+| 1 | Google Business Profile | B (claim hub / Core 3) | Resolve path documented |
+| 2 | Apple Business Connect | B (Core 3) | Resolve path documented |
+| 3 | Bing Places | B (Core 3) | Resolve path documented |
+| 4 | Foursquare Places | A + B | Resolve path documented |
+| 5 | Yelp | B | Resolve path documented |
+| 6 | Data Axle Local Listings | A | Resolve path documented |
+| 7 | Localeze / TransUnion | A | Resolve path documented |
+| 8 | YP / Thryv | B (long-tail feeds) | Resolve path documented |
+| 9 | Tripadvisor | B (vertical) | Resolve path documented; **FLAG** thin for bakery/salon v1 genre gate |
+| 10 | Facebook / Meta | B (low weight) | Resolve path documented |
+| 11 | MapQuest / HERE / in-car / long-tail | A by default | Monitor after umbrellas; **FLAG** thin for v1 genre gate |
+| 12 | Dun & Bradstreet | Low for consumer local | Skip unless B2B; **FLAG** thin for v1 |
+| 13 | CityGrid | Legacy | Only if still stomping; **FLAG** thin for v1 |
+| 14 | Yext / Uberall / BrightLocal (pipes) | Route through existing paid pipe | Not destinations; score publishers not pipe brand |
+
+## Platform links / fan-out - confirm / flag
+
+Desk pass against CONCEPT hyperlinks and fan-out section (commit `967ba9a` / `44c2d6c`). No external re-research in this package.
+
+| Item | Verdict | Notes |
+| :--- | :--- | :--- |
+| Ranks 1-14 marketing-root hyperlinks in CONCEPT | **CONFIRM** | Canonical pages linked in SoT (`967ba9a`) |
+| Deep correction URLs / API per rank 1-14 | **FLAG** | SOURCES covers Core 3 field/API only; need second table for deep edit channels |
+| Localeze “80-100+” vs ALTERNATE “80-90+” | **SOFT FLAG** | Align publisher-count language across CONCEPT and ALTERNATE |
+| Localeze ~30-90d partner cadence + Google sync separate | **CONFIRM** | Encoded in CONCEPT fan-out section |
+| Data Axle timing / free vs Premium docs link | **CONFIRM** | Hours-~2 weeks hard cases; Premium docs linked |
+| Yext-class “often 200+” direct publisher APIs | **FLAG** | Cite evidence or soften number before locking |
+| Foursquare suggest/edit (`POST /places/{id}/suggest/edit`) | **CONFIRM** | In CONCEPT workflows |
+| No free public one-to-many fan-out API | **CONFIRM** | Product rule: one-click = ticket set |
+| GBP no outbound NAP syndicate; Apple ≠ rivals | **CONFIRM** | Architect rule in CONCEPT |
+
+### Platform link inventory (marketing roots in CONCEPT)
+
+| # | Label | URL in CONCEPT |
+| :---: | :--- | :--- |
+| 1 | Google Business Profile | https://business.google.com |
+| 2 | Apple Business Connect | https://business.apple.com |
+| 3 | Bing Places | https://www.bingplaces.com |
+| 4 | Foursquare | https://foursquare.com |
+| 5 | Yelp | https://www.yelp.com |
+| 6 | Data Axle Local Listings | https://www.data-axle.com/marketing-solutions/local-listings-management/ |
+| 6b | Local Listings Premium docs | https://local-listings-premium.data-axle.com/docs |
+| 7 | Localeze / TransUnion | https://neustarlocaleze.biz/ |
+| 8 | YP / Thryv | https://www.yellowpages.com |
+| 9 | Tripadvisor | https://www.tripadvisor.com |
+| 10 | Facebook / Meta Business | https://www.facebook.com/business |
+| 11 | MapQuest | https://www.mapquest.com |
+| 12 | Dun & Bradstreet | https://www.dnb.com |
+| 13 | CityGrid | https://www.citygrid.com |
+| 14 | Yext | https://www.yext.com |
+| 14b | Uberall | https://www.uberall.com |
+| 14c | BrightLocal | https://www.brightlocal.com |
+
+## Weak / contradictory - flag before Ty reviews
+
+1. **MCP vs web-first:** BUSINESS_PLAN §8 (Owner MCP P0 parallel) vs CONCEPT (interactive web first, MCP ~3 months). Do not pick a side in packaging. **FLAG for Ty.**
+2. **Rank vs regeneration:** FSQ/Yelp sit above Data Axle/Localeze in discoverability rank; that is not the same as regeneration-stop priority. Keep both frames labeled. **FLAG** if copy conflates them.
+3. **Thin verticals in 1-14:** Tripadvisor / MapQuest / D&B / CityGrid are thin for bakery/salon v1. Gate the 14-stack by genre for v1 packs. **FLAG.**
+4. **Held verification moat:** Do not sell as free checkup. How (OAuth / agency / ToS) is unproven. **FLAG.**
+5. **Marketing roots ≠ deep edit links:** Need a second table; SOURCES pattern is Core 3 only today. **FLAG.**
+6. **Localeze publisher count:** Align CONCEPT 80-100+ with ALTERNATE 80-90+. **SOFT FLAG.**
+7. **Yext 200+:** Cite or soften. **FLAG.**
+
+## Open decisions already listed in CONCEPT (do not invent closures)
+
+- First genre cluster pack(s) to ship
+- Web-only v1 vs also embed in a chat shell (see MCP FLAG above)
+- Presence providers for v1 (Core 3 ± Yelp ± aggregators)
+- How to measure Recommendability without overclaiming
+- Where “email on file” for verify comes from
+- Free vs paid; what never goes to a human vs escalation
+- Veterinary: healthcare/regulated vs own call (GBP Pets ~59 leaves)
+- v1 demand: ads/self-start only, intermediate-first, or both
+
+## Top review checklist
+
+1. Open CONCEPT first - baker/owner story include prove-you-own-it + black-box copies?
+2. Solution still “to architect,” not claimed shipped?
+3. Tickets: every audit finding → same ticket shape; GBP as proof?
+4. Moat: held multi-platform verified status?
+5. Genre parents match latest CONCEPT (destination workshop split, beauty ≠ healthcare, hybrid = flag)?
+6. ALTERNATE clearly non-SoT; action plan coherent with CONCEPT lanes?
+7. BUSINESS_PLAN §1 intent verbatim where North Star quoted?
+8. Evidence under `docs/evidence/` only for cited research?
+9. PDF vs ALTERNATE research section - match or note drift?
+10. No new sibling docs without announced path (CONVENTIONS)?
+11. Fan-out honesty visible (ticket set, not one rewrite)?
+12. MCP vs web-first contradiction left as FLAG (not silently resolved)?
+
+## Branch map
+
+| Branch | Tip (at package prep) | Role for this review |
+| :--- | :--- | :--- |
+| **`planning-selfserve-audit`** | `8337408` (+ this REVIEW commit) | **YES - review surface.** Self-serve concept SoT, remediation 1-14, fan-out, alternate proposal, writing rules. |
+| `planning-rev2` | `9efd554` | Background. Sep 15 SEO desk unslop; BUSINESS_PLAN / genre-packs / evidence lineage. Parent of hot branch. |
+| `main` | `2aa7a2c` | Historical. July strategy / SSP archive. Raw material only; not current SoT on this review. |
+| `ssp-refinement` | `a4cc4cd` | Historical. Conversational SSP UC-04/05 (July). Behind `main`; not current SoT. |
+| `review/ready` | (optional integrator scratch) | Earlier mechanical prep fork; prefer **this** branch (`planning-selfserve-audit`) as Ty review surface. |
+
+Do not mass-delete remote branches. Prefer documenting over force-rewriting history.
+
+## Out of scope for this review package
+
+Coding, production deploy, force-push `main`, SlabUploader work, expanding ALTERNATE/PDF without Ty naming paths, inventing Presence “we check X” lists, closing MCP vs web-first without Ty.
+
+## Research flags (Desk)
+
+Desk confirm/flag table is above. Remaining open research items for Ty (not closed here): deep edit URL table; Localeze count align; Yext 200+ cite-or-soften; genre-gated 14-stack for v1 packs.

docs/ALTERNATE_BUSINESS_PROPOSAL.md

@@ -0,0 +1,145 @@
+# Alternate business proposal: fix the warehouses that feed AI
+
+**Branch:** `planning-selfserve-audit`  
+**Status:** Working draft 2026-10-01 — action-plan-first rewrite  
+**Relationship to SoT:** Not a replacement for [`SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md`](./SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md). That file stays the product architecture SoT. Amend or kill when Ty locks or rejects this.
+
+---
+
+## The North Star
+
+From [`BUSINESS_PLAN.md`](./BUSINESS_PLAN.md) §1 (“North star (wording still open)”). **Verbatim:**
+
+> **Intent (stable):** Enable local businesses to be discovered and recommended by AI assistants.
+>
+> Still wordsmithing the exact sentence. The job does not change while the phrasing does.
+
+On this branch we score that intent as two outcomes:
+
+1. **Present and accurately represented** wherever a local business is discovered — including AI answers, Google, Apple, Bing, Yelp, and the directory copies underneath.
+2. **Recommendable** — if someone asks an AI for a business like yours nearby, would it pick you, and would it get the facts right?
+
+Longer-term destination in the concept SoT (not version one): an industry graph the industry can use. Version one earns that by making the two outcomes above true in today’s assistants, with the owner’s consent.
+
+PDF export of the RESEARCH BRIEF below: [`docs/research-brief.pdf`](./research-brief.pdf).
+
+---
+
+## RESEARCH BRIEF
+
+### The North Star
+
+From [`BUSINESS_PLAN.md`](./BUSINESS_PLAN.md) §1. **Verbatim:**
+
+> **Intent (stable):** Enable local businesses to be discovered and recommended by AI assistants.
+>
+> Still wordsmithing the exact sentence. The job does not change while the phrasing does.
+
+Scored here as: present and accurately represented wherever discovery happens; recommendable when someone asks an AI for a business like yours nearby. Industry graph = longer-term, not version one.
+
+---
+
+### 1. The bakery owner’s pain
+
+Picture a bakery owner who keeps losing easy customers. People show up after closing because the hours online are wrong. Others call a disconnected number and never call back. A few say they asked an assistant for a nearby bakery and got pointed somewhere else — or got her shop with the old phone number.
+
+She sits down on a Tuesday night to fix this. She updates Google — new phone, new weekend hours — and thinks customers will find the right info everywhere. They will not. The same details still sit wrong on Yelp, Bing, Apple Maps, and dozens of directories. When someone asks ChatGPT or Gemini “where’s a good bakery near me?”, the assistant often pulls from those scattered, outdated copies. Sometimes the shop never shows up. Sometimes it shows up with last year’s number. She never sees the miss.
+
+Fixing one listing is not the same as being findable and accurately described wherever people discover local businesses today — including when they ask AI.
+
+There is a second pain that shows up the moment she tries to do anything serious about it: **proving the shop is hers.** Before an honest audit or before anyone will let her overwrite warehouse data, someone has to verify she is the owner or authorized stakeholder — email code, phone ping, postcard, or login to Google. That step is easy to skip in a pitch deck and miserable in real life. She is already tired. She does not have an agency. She may not control the email on the old listing. If the action plan ignores that friction, it is not an action plan she can finish alone — and the stale copies keep winning.
+
+---
+
+### 2. Peel the onion — the root problem
+
+The industry still sells last year’s scoreboard: polish Google, collect reviews, push listings, score how “complete” your profile looks inside their software, track map rank. That can bring more Google calls. Almost none of those products answer: what do AI assistants actually say about my business — do they find me, recommend me, and get the facts right?
+
+Peel further. Wrong hours and phone numbers do not mainly come from one bad Yelp page. A handful of **business-data warehouses** collect and copy your facts into directories, maps, navigation apps, and the pools assistants read from:
+
+- [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) (formerly Infogroup)
+- [TransUnion Digital Business Profile / Localeze](https://neustarlocaleze.biz/)
+- [Foursquare Places](https://foursquare.com/products/business-listings/) (absorbed Factual in 2020)
+- Plus networks agencies buy as bundles: GPS Network, YP Network, Active Sync Plus ([BrightLocal’s aggregator list](https://www.brightlocal.com/learn/data-aggregators/))
+
+Vendors profit from the mess: paid “completeness” hubs, annual trusted-stamps, syndication subscriptions that degrade when you cancel. Updating Google or Yelp alone often fails because those warehouses keep shipping the old version downstream. Acxiom’s directory products retired end of 2019; Factual is not a separate claim surface anymore — don’t build around dead names.
+
+---
+
+### 3. Action plan — what we build
+
+**A. Stakeholder verify, then AI-assistant audit as the scoreboard.**  
+First, prove the person is allowed to act for the business (code to a known email, phone check, or linked Google ownership — whatever keeps impostors out without making a tired owner give up). Then ask the major assistants the questions a real customer would ask. Show them: did they find you, recommend you, get the facts right? That verified audit is why someone signs up — not a completeness score inside our software, not a map-rank tracker. Without the verify step, warehouse pushes and “fix my data” tickets are either blocked or unsafe.
+
+**B. Push verified facts into the root warehouses and the trusted sites — and track acceptance.**  
+
+| Warehouse / surface | What we do |
+| --- | --- |
+| Data Axle | Free claim/verify for roughly 1–10 locations; Premium / Submission API + teleresearch when scale or hard changes need it |
+| Localeze / TransUnion | Paid manage when required (~$99/year per location); treat Completeness as “fill the hub so partners trust the row,” not an AI audit |
+| Foursquare | Prefer **owner claim** (authoritative). Use Placemaker / partner APIs with **edit-status tracking** when we submit at scale — community votes alone are not owner authority |
+| Google, Apple, Bing, Yelp | Still correct the big sites people and machines trust; Google is useful proof and where many customers double-check after an AI suggestion |
+| BrightLocal-class reseller pipes | Optional scale lane — not the identity of the product |
+
+We do not stop at “submitted a form.” We track whether the warehouse accepted the update.
+
+**C. Respect sync clocks and trusted-freshness.**  
+When tools push through common pipes: Data Axle can move in real time; Foursquare often weekly (and one-way); Localeze often monthly. Localeze partners commonly publish in **30–90 days**. Trusted / managed stamps often last about **twelve months** — then freshness decays unless you renew or re-verify. We schedule for that, and we tell the owner the wait.
+
+**D. Re-ask AI after syncs; chase the upstream feed still poisoning copies.**  
+Same assistant questions again. Better findability and accuracy — or we did not earn the win. If one surface is still wrong, diagnose which warehouse is still feeding it and chase that source.
+
+**E. No cancel-hostage product.**  
+Owner keeps control of their truth. We are not a subscription that vanishes or corrupts listings when they leave (industry pattern documented when heavy syndication stops — see Whitespark’s Yext-cancel audit).
+
+**Why this is a business.** Owners already pay for Maps tools and listing packs that ignore the warehouse layer. Customers ask AI for local recommendations far more than a year ago. Almost nobody both fixes the root data companies and proves it by re-checking the assistants.
+
+---
+
+### Supporting research (named sources)
+
+**Data Axle.** Free Local Listings for about 1–10 locations (claim, phone-verify, unlimited updates marketed free). Ten-plus: Premium / Excel / Submission API; human teleresearch on hard changes; files can take hours to ~2 weeks; failed listings can sit ~90 days. Partners include search, directories, nav, virtual assistants; marketing now cites AI-driven search. ([Data Axle Local Listings](https://www.data-axle.com/marketing-solutions/local-listings-management/); [Yext × Data Axle](https://www.yext.com/integrations/publishers/data-axle) — real-time.)
+
+**Localeze / TransUnion.** ~$99/year per location (public SMB / BrightLocal writeups). 80–90+ distribution partners. Completeness Score = hub attribute fill-in for partner confidence — not a web/AI audit. Most partners process updates in **30–90 days**; Google sync can be minutes if linked. Cancel → they stop certifying owner-managed accuracy to partners. ([BrightLocal aggregators guide](https://www.brightlocal.com/learn/data-aggregators/); [Duda Localeze FAQ](https://support.duda.co/hc/en-us/articles/360060106534-Neustar-Localeze); [TransUnion LP](https://www.transunion.com/lp/digital-business-profiles).) Yext → Localeze cadence: **monthly**.
+
+**Foursquare Places.** Owner claim via Foursquare for Business. Community Placemaker suggest-edit needs votes before apply. Developer `suggest/edit` + status APIs (and Managed Users for higher-trust product edits). BrightLocal notes Places used by ChatGPT and powers apps like Uber / Nextdoor. Yext → Foursquare: **weekly**, one-way. ([Placemaker docs](https://docs.foursquare.com/data-products/docs/get-started-with-the-placemaker-tools); [suggest-edit API](https://docs.foursquare.com/fsq-developers-places/reference/place-suggest-edit); [BrightLocal](https://www.brightlocal.com/learn/data-aggregators/).)
+
+**BrightLocal.** Reseller into Data Axle, Localeze/Neustar, Foursquare, GPS Network, YP Network, Active Sync Plus (~15 credits per aggregator submission; Active Sync Plus higher). Campaigns often finish in ~7 business days; marketing promise that most go live/updated within ~38 days or free extras. Aggregator “trusted” window ~12 months. Not a root warehouse — a paid pipe.
+
+**Yext cancel pattern.** [Whitespark audit](https://whitespark.ca/blog/what-happens-when-you-cancel-yext/): large share of listings wrong or gone after cancel; Yext says it leaves data and does not “steal” listings — publishers still fall back to other feeds. Product implication: don’t build a hostage pipe.
+
+**Retired.** Acxiom directory/local-search products EOY 2019. Factual → Foursquare April 2020.
+
+**AI vs Maps (why the scoreboard must be AI).** BrightLocal Local AI Visibility: Maps mention ~66% vs AI surfaces ~32–38%. SOCi LVI 2026: ChatGPT recommends ~1.2% of brand locations vs ~35.9% in Google’s short list of three. Insites: assistants often misstate name/address/phone even when they “know” the shop; schema/llms.txt barely correlate. No clean published study that aggregator cleanup alone → +X% AI mentions — do not invent one. Sell measurable re-ask improvement.
+
+**Practitioner snapshots (r/localseo — observational, not replicated):** ~73% shops invisible to 4+ of 6 AI engines in a 50-business audit ([1slake5](https://www.reddit.com/r/localseo/comments/1slake5/)); GBP completeness call lifts are Maps-lane attributions with confounders; “Maps opt, AI flat” anecdotes exist ([1o08abp](https://www.reddit.com/r/localseo/comments/1o08abp/)).
+
+---
+
+### What we are not selling
+
+| Anti-pattern | Why |
+| --- | --- |
+| Completeness score as the product | Localeze hub fill-in ≠ what AI says |
+| Citation blast / cleanup-only as AI ROI | No clean published cleanup → AI-mention study |
+| Schema / llms.txt as the lever | Insites: barely correlates |
+| Hostage syndication | Cancel degradation (Whitespark); trusted stamp expiry |
+| Foursquare “60–70% of ChatGPT local” as fact | **UNVERIFIED** when phrased as “reports suggest” |
+| Dead umbrellas (Acxiom, standalone Factual) | Retired / merged |
+
+---
+
+### Open questions
+
+1. Promise: “Am I discoverable by AI?” vs “Does AI describe me correctly?”  
+2. Which assistants in v1?  
+3. How automated is accuracy vs owner compare-to-claim?  
+4. Localeze / Data Axle: pay inside product, refer, or use pipes the owner already has — without pretending free Localeze control exists?  
+5. Foursquare Managed Users in v1 or later?  
+6. Keep this file as GTM ladder beside the concept SoT, or merge later?
+
+---
+
+### Capture
+
+2026-10-01 — restructured action-plan-first (pain → warehouse root → plan) after aggregator-layer research. Concept SoT unchanged.

docs/BUSINESS_PLAN.md

@@ -1,6 +1,6 @@
 # geolocal.io — Business Plan (working draft)
 
-**Branch:** `planning-rev2`  
+**Branch:** `planning-selfserve-audit`  
 **Status:** In progress — conversation checkpoint, not final  
 **Purpose:** **Only** durable home for the business idea on this branch. Fold strategy here; do not spawn sibling strategy docs.
 

docs/CONVENTIONS.md

@@ -0,0 +1,61 @@
+# Docs conventions (anti-duplication)
+
+**Branch applicability:** whole repo; written on `planning-selfserve-audit` after repeated near-duplicate markdown sprawl.  
+**Scope:** `docs/**/*.md` (and any future top-level strategy markdown).
+
+These rules exist so agents and humans **do not** create sibling files like `…_PLAN.md` next to `…_CONCEPT.md` for the same subject.
+
+---
+
+## 1. One concept = one file
+
+Before creating **any** new markdown file under `docs/`:
+
+1. Search existing paths and titles for **similar names** or **overlapping topics**.
+2. If overlap exists → **update the existing file** (amend in place).
+3. Only create a new file when the topic is genuinely new and no current file owns it.
+
+## 2. Naming — one canonical name per topic
+
+- Pick a **single** canonical filename per subject and stick to it.
+- Do **not** create variants that differ mainly by role suffix, including but not limited to: `PLAN`, `CONCEPT`, `DRAFT`, `NOTES`, `OUTLINE`, `BRIEF`, `SPEC`, `V2`.
+- Bad: `SELF_SERVE_AI_DISCOVERABILITY_PLAN.md` + `SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md`.
+- Good: one `SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md` that holds both concept and phased plan.
+
+## 3. “Write a plan / concept / brief” means amend
+
+If a task says write a plan, concept, brief, or execution outline for something that **already has a file**, **amend that file**. Never add a sibling with a near-identical stem.
+
+Current example SoT: [`SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md`](./SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md).
+
+## 4. Deletes and consolidations
+
+- **Deleting** a docs file requires an **explicit** instruction (user or locked task).
+- Consolidations: **merge** unique content into the surviving file, **then** delete the duplicate(s). Do not leave two near-names “for later.”
+
+## 5. Announce path before create
+
+Every new docs file must be **announced with its exact path** before creation (in the working chat/call). If the announced path overlaps an existing topic, stop and amend instead.
+
+---
+
+## Quick checklist (agents)
+
+- [ ] Grepped / listed `docs/` for similar stems and topics  
+- [ ] Confirmed no PLAN/CONCEPT/DRAFT twin for the same subject  
+- [ ] Amending existing SoT when topic already exists  
+- [ ] Exact path announced before any `docs/` create  
+- [ ] Consolidation ends with a single surviving file  
+
+---
+
+## Automation note
+
+As of 2026-10-01 this repo has **no** Gitea Actions / `.gitea` / `.github` CI and only stock `.git/hooks/*.sample` files. Guardrails are **documented here** until CI or an active pre-commit hook is added. Prefer enforcing via this file + review rather than inventing hook infrastructure without a project standard.
+
+---
+
+## Capture
+
+Added after consolidating the self-serve AI discoverability PLAN+CONCEPT duplicate on `planning-selfserve-audit`.
+

docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md

@@ -0,0 +1,290 @@
+# How local businesses get AI to recommend them
+
+**Branch:** `planning-selfserve-audit` (from `planning-rev2`)  
+**Status:** Working draft from conversation on 2026-10-01; cluster cut revised after GBP mapping pressure test the same day  
+**Related:** [`BUSINESS_PLAN.md`](./BUSINESS_PLAN.md) · conventions in [`CONVENTIONS.md`](./CONVENTIONS.md)
+
+This is the single working doc for the self-serve “Am I discoverable by AI?” idea — both the *why* and the phased *how*. Revise this file in place. Do not add a sibling PLAN or CONCEPT file for the same subject.
+
+---
+
+## What we are trying to do
+
+The mission, stated plainly: **help local business owners get AI to recommend them.**
+
+That puts the owner talking to AI (or using a tool that talks to AI on their behalf) at the center. Scores, audits, and before/after proof are useful for selling and teaching — they are not the mission itself. We are not building another website where consumers browse listings, not rebuilding booking or shop software, and not defining ourselves as “an MCP company.”
+
+---
+
+## The problem we are solving
+
+Local businesses are entering an era where people ask assistants — ChatGPT, Claude, Gemini, Perplexity, and whatever comes next — for a plumber, a place to eat, or a surf rental near them. If those assistants cannot find or trust a business’s facts, the business simply does not get recommended.
+
+That **discoverability in the agent era** is the spine of the strategy. How assistants connect to tools and data is just plumbing. The pipe is not the product.
+
+Under that spine sits a quieter mess — a **big black box of confusion** — that most owners feel but cannot name.
+
+### The black box: a cloud of copies
+
+A local business is not a single record on the internet. It is a **cloud of copies**.
+
+Over years, real life moves. You change suite numbers. The town renumbers a road. The phone company swaps an area code. You get a new mobile for the shop. You update the website. Each of those changes is ordinary. What is not ordinary is what happens next.
+
+Every major place that stores local businesses keeps **its own copy** of your name, address, and phone — the boring facts people call **NAP** (name, address, phone). [Google Business Profile](https://business.google.com) has a copy. [Apple](https://business.apple.com) has a copy. [Bing](https://www.bingplaces.com) has a copy. [Yelp](https://www.yelp.com) has a copy. [Foursquare](https://foursquare.com)’s place graph has a copy. Underneath many of them, **data aggregators and syndicators** (companies such as [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) and [Localeze / TransUnion](https://neustarlocaleze.biz/)) hold yet another copy and push it out to directories, maps, navigation apps, and anything that buys “local listings” feeds.
+
+Nobody is paid to keep all of those copies honest with each other.
+
+So the copies **drift**. One still has the old area code. One still has the storefront you left three years ago. One has the right street but the wrong suite. Search engines and AI assistants do not magically know which copy is you today. They see a black box of conflicting facts and pick whatever their ranking and training happen to trust that week.
+
+When an owner finally **claims** [Google Business Profile](https://business.google.com) and fixes it, that is powerful — GBP is usually the strongest **claim surface** an owner can touch. But it is not the only voice. Syndicated feeds can still broadcast the old NAP. Those stale copies can show up in search results and in AI answers **alongside or even above** the listing the owner just cleaned up. From the owner’s chair it feels like: “I fixed it — why does the world still lie about me?”
+
+That is the problem in one line: **the owner cannot control what the world believes about their business**, because the world is not one database. It is a black box of unreconciled copies.
+
+### Opening the black box: claim once, correct outward
+
+We flip the direction of truth.
+
+Today, copies compete. The owner chases them. Tomorrow, the owner **declares one clean NAP** — a single claimed truth for who they are and how to reach them — and that declaration becomes the **source of truth**. The job of the system is then to **push corrections outward** into the aggregators and syndicated feeds, instead of letting those feeds quietly overwrite or outrank the claim.
+
+Think of it as three frames:
+
+```text
+  BEFORE                         CLAIM                          AFTER
+ ┌─────────────┐              ┌─────────────┐              ┌─────────────┐
+ │ five wrong  │              │  one clean  │              │ copies that │
+ │ copies of   │   ──────►    │  NAP the    │   ──────►    │ match the   │
+ │ the same    │              │  owner just │              │ claim —     │
+ │ business    │              │  declared   │              │ pushed out  │
+ └─────────────┘              └─────────────┘              └─────────────┘
+   (the black box)              (source of truth)            (reconciled world)
+```
+
+**Frame one — left.** The black box: several disagreeing copies ([Google](https://business.google.com), [Apple](https://business.apple.com), [Bing](https://www.bingplaces.com), [Yelp](https://www.yelp.com), [Foursquare](https://foursquare.com), and whatever else still carries an old feed). The owner did not ask for five versions of themselves. The market produced them.
+
+**Frame two — middle.** The claim: one clean NAP the owner stands behind. That is the only version we treat as authoritative for *this* business. Fixing GBP still matters — it is often the best place to start the claim — but the point is the **declared truth**, not loyalty to any one logo.
+
+**Frame three — right.** Corrections flowing out. The system’s job is to make the other copies **match the claim**, including the ugly middle layer most owners never see: **syndication**. Aggregators and platforms that feed directories and assistants — [Yelp](https://www.yelp.com), [Bing](https://www.bingplaces.com), [Foursquare](https://foursquare.com), and the rest — routinely **stomp on** a small business’s source of truth with stale hours, old phone numbers, and leftover addresses. If you only polish the claim surface and ignore those copies, the black box regenerates overnight.
+
+Matching NAP is the floor — **presence** with consistent facts. **Recommendability** (would an assistant pick you for a real customer question in your genre) still needs categories, relevance, and the rest of this product story. Opening the black box is how we stop the floor from moving under the owner’s feet.
+
+Assistants answer from whatever they can find and trust. When five copies disagree, the assistant is guessing in the fog. When one claimed truth is pushed outward and the other copies are brought into line, the fog thins. Strategic bet in plain words: **stop competing with your own stale twins. Claim once. Correct outward.**
+
+### What we have to architect (not built yet)
+
+The direction above is the bet. Below is the **solution we still have to design and build** — not work already done.
+
+#### 1. Every audit finding becomes a correction ticket
+
+Today an owner who sees wrong hours on [Yelp](https://www.yelp.com), a dead phone on [Bing](https://www.bingplaces.com), and an old suite on [Foursquare](https://foursquare.com) has to decode three different “suggest an edit” paths. That is the chore we remove.
+
+For each platform that still shows stale or wrong data, the product turns the audit finding into a **correction ticket** with the same shape every time: which field is wrong, what value is showing, what the right value is, and a link to **[Google Business Profile](https://business.google.com)** (or the owner’s claimed truth) as proof. Then the owner files that platform’s own correction channel — [Yelp](https://www.yelp.com)’s suggest-an-edit page, [Foursquare](https://foursquare.com)’s suggest-edit API (`POST /places/{id}/suggest/edit`), [Bing Places](https://www.bingplaces.com) feedback, and the same pattern for others as we map them. Claim it is wrong. Show proof. Wait.
+
+Our side of the architecture: **mint that ticket automatically from the audit** — pre-filled, one click to file — instead of making the owner hunt which form goes where. The platforms still own their review queues. We own the translation from “your Presence score is broken here” into “here is the exact correction this platform will accept.”
+
+#### 2. Held verification across platforms is the moat
+
+Business verification is the tax. Every platform re-verifies **independently**. [Yelp](https://www.yelp.com) wants its documents. [Bing](https://www.bingplaces.com) wants its own proof of ownership. [Foursquare](https://foursquare.com) has its own checks. There is **no shared credential** and no way to say “I already proved this to Google.” Each review takes **days to weeks**, and without standing as a verified actor, corrections get slow-walked or quietly reverted when the next stale feed arrives.
+
+A white-label correction service that **holds verified status per platform** — and files on the owner’s behalf without re-uploading a lease five times — is what makes corrections **stick**. That held, multi-platform verified status is the **moat**: the audit finds the drift; the ticket files the fix; the held verification is why the fix does not get stomped again tomorrow.
+
+#### 3. Two lanes, then a ranked remediation stack
+
+Umbrella aggregators and end-user platforms are **not** the same job. Architecture needs **two lanes**:
+
+- **Lane A — umbrella submissions.** Write once into [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/), [Localeze / TransUnion](https://neustarlocaleze.biz/), and [Foursquare](https://foursquare.com)’s place graph so long-tail directories, libraries, and many nav / GPS consumers stop regenerating stale NAP.
+- **Lane B — per-platform tickets.** Claim or suggest-edit on [Google](https://business.google.com), [Apple](https://business.apple.com), [Bing](https://www.bingplaces.com), [Yelp](https://www.yelp.com), and other surfaces that keep their **own** databases and often prefer verified owner data over a feed.
+
+Umbrella-only leaves the Core 3 and [Yelp](https://www.yelp.com) wrong. Platform-only leaves the black box regenerating from Layer 1 feeds. Both lanes mint the same ticket shape (field, wrong value, right value, GBP or claimed truth as proof). Rank below is **most → least important** for small-business local discoverability and for how hard a miss should hit the Presence / audit score. Each item is an **owner-facing workflow we still have to architect** — not a label and not a shipped feature.
+
+1. **[Google Business Profile](https://business.google.com)** (Lane B — claim hub / Core 3). Sign in to the GBP dashboard for that location. Open the wrong field (hours, phone, address, category). Enter the correct value and save. Attach documents only when Google asks — typically for large moves, ownership disputes, or category jumps, not for a routine hours tweak. Wait for the listing to refresh (often minutes to a day). **Success:** Maps / Search show the new value, and that GBP URL becomes the proof link on every other ticket.
+
+2. **[Apple Business Connect](https://business.apple.com)** (Lane B — Core 3). Sign in to [Apple Business Connect](https://business.apple.com), find the place card, edit the field, submit. Apple may review and email if more proof is needed. Wait for the place card to update across Maps and related Apple surfaces. **Success:** Apple Maps shows the corrected hours / NAP matching the claim.
+
+3. **[Bing Places](https://www.bingplaces.com)** (Lane B — Core 3). Sign in at the [Bing Places](https://www.bingplaces.com) portal, open the listing, edit the field. Attach proof that matches GBP — utility bill or lease with the same business name and address when Bing asks for ownership evidence. Submit and wait for Bing’s review queue (often days). **Success:** Bing local (and Copilot-adjacent local answers that lean on Places) show the corrected value.
+
+4. **[Foursquare Places](https://foursquare.com)** (Lane A + B). Two paths, same outcome: (a) Placemaker suggest-edit — pick the place, choose the field, enter wrong vs right, submit; or (b) our white-label one-click that calls `POST /places/{id}/suggest/edit` pre-filled, with the GBP URL as the cited source. Wait for Placemaker / [Foursquare](https://foursquare.com) resolution (status via suggest-status). **Success:** the FSQ place record shows the new value (and downstream licensees that refresh from FSQ can follow).
+
+5. **[Yelp](https://www.yelp.com)** (Lane B). Open the business page → **Suggest an edit**. Pick the field, type the correction, add a short note citing the GBP listing as proof, submit. [Yelp](https://www.yelp.com) reviews manually. Wait days to weeks. **Success:** the [Yelp](https://www.yelp.com) page shows the corrected field and stops contradicting the claim.
+
+6. **[Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) Local Listings** (Lane A). Claim the business at the [Data Axle Local Listings](https://www.data-axle.com/marketing-solutions/local-listings-management/) portal with a business email and / or ownership docs. Edit NAP (and hours) once in that central record. Wait for [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/)’s verification and syndication batch (scale / API path: [Local Listings Premium docs](https://local-listings-premium.data-axle.com/docs)) — hours to ~two weeks for hard cases. **Success:** the Local Listings record matches the claim; long-tail / nav partners that consume [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) begin reflecting the update on their next pull.
+
+7. **[Localeze / TransUnion](https://neustarlocaleze.biz/) Digital Business Profile** (Lane A). Claim at the [TransUnion / Localeze](https://neustarlocaleze.biz/) portal, correct NAP once, complete their verification. Wait for push out to their 80–100+ publisher network (often weeks for some partners). **Success:** the claimed profile matches GBP; sample downstream publishers no longer show the stale twin.
+
+8. **[YP / Thryv](https://www.yellowpages.com)** (Lane B, feeds long-tail). Claim via [YP / Thryv](https://www.yellowpages.com) listing management, edit the wrong field, save. Wait for their network to refresh. **Success:** the YP listing matches the claim; long-tail sites fed by that stack stop showing the old value when they next sync.
+
+9. **[Tripadvisor](https://www.tripadvisor.com)** (Lane B — vertical). Claim via [Tripadvisor](https://www.tripadvisor.com) for Business, open the field, submit the correction for review. Wait for their moderation. **Success:** the [Tripadvisor](https://www.tripadvisor.com) listing matches the claim when travel / food recommendability cares about that surface.
+
+10. **[Facebook / Meta](https://www.facebook.com/business)** (Lane B — low weight). In [Meta Business Suite](https://www.facebook.com/business), open the Page → contact / location info, edit hours or phone, publish. Usually no separate proof upload for small edits. **Success:** the Page info card matches GBP; treat as secondary Presence, not Core 3.
+
+11. **[MapQuest](https://www.mapquest.com) / HERE / in-car nav / long-tail directories** (Lane A by default). There is usually **no** owner correction form. Path: file umbrella tickets ([Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/), [Localeze](https://neustarlocaleze.biz/), [Foursquare](https://foursquare.com)) and **monitor** those surfaces after syndication settles. Open a direct ticket only if a real claim URL exists and the miss survives umbrella propagation. **Success:** re-audit shows the nav / directory copy matches the claim without chasing each site by hand.
+
+12. **[Dun & Bradstreet](https://www.dnb.com)** — Low priority for consumer local. Skip unless a B2B path is in scope; if needed, update through D&B’s business profile tools with legal-entity proof. **Success:** firmographic record matches when that lane matters.
+
+13. **[CityGrid](https://www.citygrid.com)** — Legacy. Only if the audit surfaces a [CityGrid](https://www.citygrid.com)-fed copy still stomping the claim; then follow whatever claim / correction URL still exists, else rely on overlapping umbrellas. **Success:** that copy disappears or matches.
+
+14. **[Yext](https://www.yext.com) / [Uberall](https://www.uberall.com) / [BrightLocal](https://www.brightlocal.com) (pipes)** — Not destinations. If the owner already pays one, route the same tickets **through that pipe** into Lanes A and B instead of a parallel write. **Success:** the pipe’s dashboard shows the jobs filed and publishers reporting the new value — we still score Presence on the publishers, not on the pipe brand.
+
+#### Day in the life (workflow to architect)
+
+A muffin shop’s Tuesday hours are wrong on the public web. The owner runs our audit, sees three red rows (GBP already correct, [Foursquare](https://foursquare.com) stale, [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) still syndicating the old Tuesday close), and hits **one** “fix these” button.
+
+Three pre-filled things fire — not three scavenger hunts:
+
+1. **GBP** — if anything still drifts there, a deep link into the hours editor with Tuesday pre-filled to the claimed value; otherwise we skip and reuse the live GBP URL as proof.
+2. **[Foursquare](https://foursquare.com)** — a one-click Placemaker suggest-edit (`POST /places/{id}/suggest/edit`) with field = hours, wrong = old Tuesday, right = claimed Tuesday, source = GBP URL (white-label Managed User when we file for them).
+3. **[Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/)** — a Lane A claim / update ticket at Local Listings with the same NAP + hours payload so the umbrella stops stomping the claim on the next syndication cycle.
+
+The owner attaches proof once where a portal demands it, then waits on each queue. Re-audit later is the success check: Tuesday matches everywhere that mattered. That is the workflow to architect — audit → tickets → wait → prove — not a pile of unlabeled “go fix [Yelp](https://www.yelp.com)” links.
+
+
+#### 4. One-to-many fan-out — useful lane, not the whole backbone
+
+True one-to-many correction **exists**, but nothing is reliable enough to be the **only** spine of a one-click product. Research takeaways to architect around:
+
+**[Localeze / TransUnion](https://neustarlocaleze.biz/)** markets claim-once → **80–100+** publishers. In practice publishers decide *what* and *when* to show: many partners sit on a **monthly publish** cycle (**~30–90 days**); sync partners can be faster; [Localeze](https://neustarlocaleze.biz/) does **not** control partner acceptance. Fast Google updates via [Localeze](https://neustarlocaleze.biz/) require a **separate Google verify/sync** inside their product — not the feed alone. Some partners need extra OAuth (e.g. link [Facebook](https://www.facebook.com/business)). Distribution status reporting exists because fan-out is partial, not guaranteed.
+
+**[Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/)** Local Listings / [Local Listings Premium](https://local-listings-premium.data-axle.com/docs) is the same *shape*: one verified submit → search, directories, libraries, nav, assistants. Processing can be hours to ~two weeks when human verification kicks in. Publisher lists **overlap** [Localeze](https://neustarlocaleze.biz/) on many big names but are **not identical** (citation vendors still sell both). Treat them as complementary Lane A tickets, not duplicates.
+
+**Other fan-out:** Paid listing managers ([Yext](https://www.yext.com)-class — often 200+ *direct* publisher APIs with per-publisher status) are the strongest productized one-edit→many-majors path — route through them when the owner already pays (rank 14). **[Google Business Profile](https://business.google.com) does not syndicate NAP outbound** to Apple/[Yelp](https://www.yelp.com)/Bing. **[Apple Business Connect](https://business.apple.com)** writes the Apple ecosystem (and partner APIs *into* Apple), not rival platforms. [Foursquare Places](https://foursquare.com) suggest-edit updates FSQ’s graph (and later licensees), not a general directory blast.
+
+There is **no free public one-to-many fan-out API** an SMB can call to rewrite every major surface at once; [Localeze](https://neustarlocaleze.biz/) and [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) are sales- or portal-gated claim/submit products, and [Yext](https://www.yext.com)-class pipes are paid.
+
+**Ceiling:** One [Localeze](https://neustarlocaleze.biz/) (or [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/)) correction may move a **fraction** of consumer-visible surfaces in week one and more over 1–3 months; Core 3 claim surfaces often stay wrong without Lane B. So one-click means **one button that mints a ticket set** (GBP proof + Lane A umbrellas + Lane B majors) — not one submission that rewrites the internet.
+
+Longer term, the Northstar — the destination we aim at but do not build first — is an **industry graph**: a shared, structured map of local businesses that many products and assistants could use. That is not version one. Version one earns the right to that graph by helping owners see how AI sees them today and fix what is broken, with their consent.
+
+---
+
+## The product
+
+A self-service experience — first as an interactive website, and later possibly inside a business’s own chatbot using the same engine — where an owner can ask: **“Is my business discoverable by AI?”**
+
+The flow we are designing toward:
+
+Someone who claims the business starts the check. We verify they are actually a stakeholder — for example by sending a six-digit code to an email already on file for that business — so random people cannot run deep audits on someone else’s shop. Once verified, we run a check that goes further than the old local-SEO habit of matching name, address, and phone (often called NAP) across directories. We also look at **categories** (what kind of business the listing says it is — plumber versus restaurant versus hotel) and **relevance** (whether those facts would help an assistant pick this business for a real customer question).
+
+We then give the owner two scores, in plain language:
+
+**Presence** answers: are you on the map? Are you listed with the major providers, and do your categories line up consistently?
+
+**Recommendability** answers: if you are on the map, would an AI be likely to recommend you when someone asks about something in your genre?
+
+Finally we show what to fix, ranked so the owner can do it themselves, and let them re-check later. A human expert can be an escape hatch. It must not be required for the product to work — humans will not scale to every small business.
+
+Demand should mostly come from owners who start themselves (including from ads that send them to the tool), not from sales calls for every audit.
+
+---
+
+## How people will use it (channel reality, September 2026)
+
+We checked how major consumer chatbots behave with MCP as of late September / early October 2026. None of the big ones will automatically “handshake” with a random small business’s MCP server if nobody configured a connector. ChatGPT, Claude, consumer Gemini, Perplexity, Microsoft 365 Copilot, and similar products either need someone to add a connector or they only suggest connectors that are already in a curated directory. That is setup work — not something a typical shop owner gets for free by putting an MCP URL on the internet.
+
+Those same assistants can still open and read a normal web page as text. Reading a page is not the same as speaking MCP to a server.
+
+So for version one, the highest priority is an **interactive web app** the owner completes in a browser. Embedding the same engine in a business chatbot can come later. We should revisit MCP as a distribution pipe in about three months — not block the product on it now.
+
+---
+
+## How we label kinds of businesses
+
+A **taxonomy** here means the set of categories used to say what kind of business something is — plumber versus restaurant versus hotel — so listings, maps, and assistants know what queries it belongs to.
+
+There is no single industry-wide taxonomy that [Apple](https://business.apple.com), [Google](https://business.google.com), [Bing](https://www.bingplaces.com), [Yelp](https://www.yelp.com), and the listing aggregators all use. Each keeps its own list (or feeds someone else’s).
+
+**NAICS** (North American Industry Classification System) is the U.S. government’s statistical system for classifying businesses by what they produce. It is good for reports and some B2B software. It is not how someone searches “plumber near me” on a map. **SIC** is the older system NAICS replaced for federal stats.
+
+**[Google Business Profile](https://business.google.com)** has its own category IDs (often looking like `gcid:…`), available through Google’s Business Information API (`categories.list`, region US / language en). That official list is a **flat catalog of roughly 4,050 leaves** — not a hierarchy that matches our genre parents. Google does not publish a downloadable tree that says “these GCIDs belong under service-area trades.” A public September 2026 compilation of **4,053** US English GCID names (with third-party industry buckets used only for structure) is useful for research; those buckets are **not** Google’s official parents. We use GBP GCIDs as **outbound presence-check maps** and fix suggestions, not as our spine. In practice GBP is usually the **richest** owner-facing surface (categories, services, attributes, photos).
+
+**[Apple Maps / Business Connect](https://business.apple.com)** has its own primary category (one main label) plus optional extras; the public docs have been shifting as Apple folds Connect into a broader “Apple Business” offering. Owner-facing field labels are documented; partner API schemas are often gated. Mid richness versus GBP — good for place card truth, weaker 1:1 parity on things like GBP `serviceItems`.
+
+**[Bing Places for Business](https://www.bingplaces.com)** is Microsoft’s local listing surface (feeds Bing / Microsoft local experiences). Categories use Bing’s own IDs (`BPCategoryId` + name); owners can attach multiple categories with one primary. The trusted-partner API is certificate-gated, not a public crawl API — field maps on this branch already treat Bing as the **thinnest** of a “Core 3” with GBP and Apple (`docs/product/genre-packs/`). Bing still matters for Presence: wrong or missing Bing categories are a real “are you on the map?” miss, especially where Copilot / Microsoft surfaces lean on [Bing Places](https://www.bingplaces.com) data. Do not pretend Bing’s category tree equals Google’s.
+
+**[Yelp](https://www.yelp.com)** keeps its own hierarchy of category **aliases** (developer APIs expose the tree). [Yelp](https://www.yelp.com) is both a discovery surface consumers still use and a signal assistants and third parties often scrape or cite. Alias mismatch (e.g. cuisine or trade labels that do not line up with GBP) is a classic consistency failure. [Yelp](https://www.yelp.com) is not a map pin in the same way as GBP/Apple/Bing, but it belongs in outbound maps when we score “would an AI trust this entity’s type?”
+
+**Data aggregators / syndicators** sit underneath many of those surfaces. Companies such as **[Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/)** (local listings / formerly Infogroup-class syndication), **[Localeze / TransUnion](https://neustarlocaleze.biz/)** digital business profiles, **[Foursquare](https://foursquare.com)** Places (place graph / POI metadata), and similar players push NAP and rich fields out to search engines, directories, navigation apps, and assistants. Owners often never touch them directly — a “listing management” vendor or the platform itself does. For our product that means: Presence is not only “did you claim GBP?” It can also be “does the aggregator-fed copy of you disagree with the claim you just made?” Aggregators are **not** a ninth genre parent; they are a **distribution layer for facts**. Which aggregators we check in v1 (if any) is still open — but ignoring them entirely would understate how local data actually spreads.
+
+**schema.org’s LocalBusiness** types are an open vocabulary used widely on the web for structured data (the markup that helps search engines understand a page). That is the best spine for an AI-era product that also wants to publish clear web facts: owner-friendly genres inside our product, keyed to schema.org where they fit, optional NAICS when a statistical code helps, and **outbound maps** — translation tables — from our genres to [Google](https://business.google.com), [Apple](https://business.apple.com), [Bing](https://www.bingplaces.com), [Yelp](https://www.yelp.com), and (where useful) aggregator category codes when we check presence or suggest fixes.
+
+We should not treat any single platform or aggregator list as our internal source of truth. They drift and they disagree. Building those maps ourselves is normal; nobody publishes an official multi-way concordance. On this branch, genre-pack work already sketches a **Core 3** field map (GBP richest → Apple mid → Bing thinnest); extend that pattern to [Yelp](https://www.yelp.com) aliases and aggregator feeds only where Presence scoring needs them.
+
+This taxonomy approach is a **hypothesis** until we score real businesses and see where the maps break.
+
+---
+
+## Why one audit checklist is not enough
+
+A plumber who works out of a truck and a surfboard rental that serves tourists are both “local businesses,” but “are you on the map?” and “would AI recommend you?” mean different things for each. The product can keep one shared scoreboard — Presence and Recommendability — and change the **rubric** (what evidence counts and how heavily) by **genre cluster**.
+
+What actually splits the audits:
+
+Where the work happens (customer comes to you, you go to them, both, or a moving spot). What “place” means (a storefront with a public address, a service-area business that hides its address, a tourist landmark, or many locations). What decision data matters (menu, service list, booking, hours open right now, amenities). What kind of demand it is (emergency, same-day convenience, a planned night out, a trip, or B2B research). How trust shows up (reviews, photos, licenses). Seasonality. And whether the AI is helping a consumer or a business buyer.
+
+We are proposing **eight top-level clusters** plus one cross-cutting flag as a starting cut — also a hypothesis until real audits teach us to merge or split. A GBP category pressure test (flat GCID catalog + third-party industry buckets for structure only) pushed three corrections: split bring-to-shop trades away from service-area trades; narrow beauty away from medical; demote hybrid from a parent to a flag.
+
+**Service-area trades** (plumber, HVAC, cleaner, landscaper, pest control): the provider goes to the customer. Presence cares about looking like a real service-area listing rather than a fake storefront, having coherent service areas and categories; recommendability cares about matching the job type and the customer’s area, plus reliability signals. Do **not** put auto repair here.
+
+**Destination workshop** (auto repair, tire shop, furniture repair, shoe repair, and similar bring-the-item-in trades): the customer brings the asset to a shop with a public address. Presence is storefront-like (real pin, hours, specialty categories); recommendability is trade-like (job match, make/model or specialty, reliability). GBP catalogs Automotive separately from Construction & Trades / Home & Garden — that split supports this parent.
+
+**Storefront retail:** presence cares about address, hours, and category truth; recommendability cares about whether the assortment fits the ask and whether the shop is actually open.
+
+**Food service** (restaurants, cafés, bars, food trucks): presence cares about specific cuisine or format categories (not a vague “Restaurant”), hours, and a current menu; trucks also need “where are you today.” Recommendability cares about occasion (date night versus quick lunch), price and vibe signals, dietary clarity, and fresh reviews. Fine dining, quick service, and trucks are **parameters inside this cluster**, not separate products.
+
+**Professional / office services** (lawyer, accountant): less weight on “open right now,” more on specialty, credentials, and clear service language.
+
+**Beauty** (salon, barber, day spa, nails — formerly the non-medical slice of “home and personal care”): booking path and services on the presence side; skill match, portfolio, and outcome-themed trust on recommendability. Dentist, medical spa, and other clinical work belong under healthcare, not here.
+
+**Hospitality and tourism** (hotel, surf rental, tour): destination and amenity truth, seasonal hours, and conflicts between the business’s own facts and big travel sites; recommendability is trip-intent fit (“family,” “near the break,” pet-friendly) and seasonal availability. This stays a **rubric parent even though GBP will not hand it to us as one bucket** — lodging leaves (hotel, motel, B&B) group fairly cleanly; tourism activity scatters across Sports, Education, Arts, and related leaves. Our audits still need one trip-intent rubric.
+
+**Healthcare / regulated** (only if we take them on — including dentist and medical spa): higher bar for accurate categories and careful claims. **Veterinary** is an open decision: in the GBP research dump, pets/vets sit in a separate Pets neighborhood (~59 leaves), not inside Health & Medical — decide whether vets ride with healthcare/regulated or get their own call if they are in scope.
+
+**Hybrid / multi-mode is not a ninth parent.** It is a **cross-cutting flag** that can sit on any cluster (dine-in plus delivery on food service; showroom plus install on retail or destination workshop). Presence and recommendability apply the relevant mode slices; the query tells you which mode matters. Google encodes many of these as specific leaves (delivery restaurant, mobile caterer), not as a top-level grouping.
+
+For version one, start with **two** cluster packs that prove the split matters — service-area trades and food service. If the commercial wedge is tourist businesses, hospitality can swap in for food service as the second pack. Destination workshop is the natural pack when the wedge is auto repair (as in the older UC-01 example).
+
+---
+
+## How we build it (phases)
+
+**Phase 0 — Lock the promise.** One sentence an owner gets without jargon. Who we speak to first. What “recommendable” means in plain words. Confirm the first shell is the web app. Success: we can say the promise in one breath without naming MCP or any other pipe.
+
+**Phase 1 — Trust gate.** Claim the business, verify the stakeholder (email code first), keep data light, consent clear, and abuse limited. Success: only verified people reach the deep audit.
+
+**Phase 2 — Audit engine.** This is the product: Presence and Recommendability with a thin, explainable rubric and cluster-specific weights — not a black box. Success: running the same business twice gives roughly the same scores, and the owner understands why.
+
+**Phase 3 — Self-serve loop.** Results, a fix list, optional re-check, no mandatory human. Success: most people finish alone.
+
+**Phase 4 — Demand.** Light campaigns that send owners to start their own audit. Track start → verify → complete → recheck. Success: we know acquisition cost and completion rate well enough to improve.
+
+**Phase 5 — Toward the graph.** Only after audits produce structured facts owners consented to share that are worth composing into something bigger. The graph stays the Northstar; it does not gate version one.
+
+Ship in this order: promise and wedge, verify gate, presence score, recommendability score, results and fixes, recheck, then ads. Do not wait on the industry graph or on a single technical protocol.
+
+Version one is succeeding when an owner can finish alone, sees two clear scores with a real explanation, gets fixes they can do themselves, can re-check, and ads can point at the tool without a sales call on every lead.
+
+Once Phase 0 is clear, work can run in parallel streams: promise and wedge language; trust and verify; presence checks; recommendability rubric; the web (and later chat) shell; growth metrics; and only later, graph composition.
+
+---
+
+## How demand arrives (acquisition, not taxonomy)
+
+This section is about **who brings owners to the tool**, not about which genre parent an audit uses. Genre clusters (destination workshop, beauty, hybrid as a flag, and the rest) stay a product-rubric question. Demand is orthogonal.
+
+On `main`, distribution is framed as the hard part of local SaaS (`docs/gtm/channel-strategy.md`, echoed in `NORTH_STAR.md` and Canonical Strategy §10). The primary one-to-many wedge there is **tourism / destination intermediates** — tourism boards, DMOs, and visitor bureaus: one board contract unlocks many member endpoints, often funded by lodging-tax or visitor-experience budgets, upgrading board sites from weak link lists into structured destination surfaces (UC-02). A **parallel** path is self-serve SMBs in high-intent verticals. **Chambers of Commerce** show up as a secondary one-to-many path (CoC-branded portals, member-benefit framing). **Agencies and SEO consultants** are a partner layer that implements and sells — not the product center. **BBB (Better Business Bureau) does not appear anywhere on `main`** in that research pass; do not invent it into this SoT.
+
+Soft link only: a tourism-board wedge prefers shipping the **hospitality / tourism** pack; an intermediate still needs **category routing** across members, which uses taxonomy as wiring, not as the definition of our parents.
+
+This doc’s product flow already assumes many owners **start themselves** (including from ads). Main’s board-and-partner motion can **coexist** with that, but “ads / self-start only,” “intermediate-first,” or “both” is a real decision — not something the genre list answers.
+
+---
+
+## Decisions still open
+
+Ty still needs to lock: which cluster pack we ship first; whether version one is web-only or also embeds in a chatbot; which providers feed the Presence score (Core 3 GBP/Apple/Bing, plus [Yelp](https://www.yelp.com) and/or aggregators such as [Data Axle](https://www.data-axle.com/marketing-solutions/local-listings-management/) / [Localeze](https://neustarlocaleze.biz/) / [Foursquare](https://foursquare.com) — or claim-only first); how we measure Recommendability without overclaiming (simple heuristics versus live checks inside assistants); where the “email on file” for verification comes from; free versus paid; what never goes to a human versus when escalation is allowed; whether **veterinary** rides with healthcare/regulated or gets its own call if in scope (GBP research dump: separate Pets bucket, ~59 leaves, not folded into Health & Medical); and whether **v1 demand** is ads/self-start only, intermediate-first (tourism boards / chambers / partners), or both.
+
+---
+
+## What we are treating as hypotheses
+
+Until we score real businesses, treat these as educated bets, not finished truth: that eight top-level clusters plus a hybrid flag is the right split (including destination workshop separate from service-area trades, and beauty separate from healthcare); that schema.org plus outbound maps to [Google](https://business.google.com), [Apple](https://business.apple.com), [Bing](https://www.bingplaces.com), [Yelp](https://www.yelp.com), and selected aggregators is the right labeling spine — not any one platform’s leaf list as internal SoT; that two version-one packs are enough to prove cluster-specific rubrics; and that a web app beats an MCP-first distribution story for owners in the near term (revisit in about three months).
+
+Nothing in this doc is locked until Ty says so. Amend this file when decisions land — do not start a second near-named document.

docs/evidence/AI-PLATFORM-DISCOVERY-AND-RECOMMENDATION.md

@@ -0,0 +1,225 @@
+# AI platform discovery vs recommendation (US SMBs)
+
+**Branch:** `planning-selfserve-audit`  
+**Status:** Research analysis (evidence). Complements `docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md` and `docs/ALTERNATE_BUSINESS_PROPOSAL.md`. Not product SoT.  
+**As of:** 2026-10-01  
+**Scope:** How the top six AI chatbots (by popularity) find and then recommend local small businesses, and which listing or data providers matter for each step.
+
+---
+
+## 1. Discovery is the gate
+
+If an AI platform never discovers a business, none of the downstream recommendation mechanics matter.
+
+**Discovery** means the assistant can find a real entity that matches the user's place or service intent: a named business with enough location and category signal to appear as a candidate. Discovery answers: "What businesses even exist here for this need?"
+
+**Recommendation** means the assistant chooses, ranks, or endorses one or more of those candidates for the user. Recommendation answers: "Which of the discovered businesses should I suggest, and why?"
+
+These are sequential. Discovery comes first. A complete Google Business Profile, a strong Yelp page, or a clean Bing Places listing only help recommendation if the platform can retrieve the business in the first place. Optimizing reviews, photos, or "best of" language without a discovery path is wasted work for AI surfaces.
+
+### What happens after discovery
+
+Once a business is discovered, the assistant often needs more than a directory row. Downstream questions include hours, services, prices, whether they are open now, reputation, booking, and fit for the user's constraints. Those answers may come from:
+
+1. **The business website** (and structured data such as LocalBusiness schema), when the model browses or cites the open web.
+2. **Deeper pulls into provider data** (Maps place details, Yelp reviews and photos, partner place APIs, reservation feeds), when the platform has a licensed or native places graph.
+
+The same provider can matter for both steps (for example Yelp for discovery and for review-backed recommendation), but the product and SEO implications differ. Discovery is coverage and matchability. Recommendation is depth, trust signals, and action paths.
+
+---
+
+## 2. Top six AI platforms (popularity)
+
+Popularity ranking depends on the metric. Confirm and adjust if newer data differs.
+
+| Rank (working set) | Platform | Notes on popularity metrics |
+| --- | --- | --- |
+| 1 | ChatGPT | Leads most chatbot web-referral and web-visit share series (e.g. Statcounter Aug 2026 ~79% of that panel; other panels still put it first at lower share). |
+| 2 | Gemini | Clear second on referral and visit share; large Gemini app MAU. |
+| 3 | Perplexity | Often third on Statcounter-style referral share; lower on some visit-share panels. |
+| 4 | Copilot | Mid-pack on chatbot referral share; Bing/Microsoft distribution matters beyond pure chat share. |
+| 5 | Claude | Often third on web-visit share panels; lower on some referral panels. |
+| 6 | Meta AI | Tiny on chatbot referral charts, but very large MAU inside Facebook, Instagram, WhatsApp (reported ~1.2B). Included for US SMB discovery reach inside Meta apps. |
+
+**Metric caveat:** DeepSeek or Grok sometimes displace Copilot, Perplexity, or Meta AI on pure traffic charts. This document keeps the user's working six for US small-business recommendation surfaces. Label any ranking used in go-to-market copy with its metric and date.
+
+---
+
+## 3. Explicit split: discovery sources vs recommendation depth
+
+### Providers that mainly drive discovery (gate)
+
+| Provider | Role in discovery | Primary platforms affected |
+| --- | --- | --- |
+| Google Business Profile / Google Maps | First-party place graph for Gemini and Google AI Mode; also produces crawlable listing pages other AIs may browse. | Gemini (direct); others via web/Maps pages |
+| Yelp | Licensed local content into ChatGPT and Perplexity; strong review/directory discovery surface. | ChatGPT, Perplexity; also cited on some Google AI Mode queries |
+| Bing Places + Bing Search index | How businesses enter Microsoft local entities and pages Copilot/Bing retrieve. | Copilot; ChatGPT when search uses Bing |
+| Business website + structured data | Crawlable entity for Claude, Perplexity, ChatGPT, Gemini AI Overviews-style answers. | All six (especially Claude and AI Overviews-like cite paths) |
+| Facebook / Instagram business pages | Primary observed discovery graph for Meta AI inside Meta apps. | Meta AI |
+| Foursquare Places | Documented Places API partner for ChatGPT Search; also a syndicating place graph. | ChatGPT (partner); indirect elsewhere via syndication |
+| Apple Business (successor to Apple Business Connect) | Place cards for Maps / Siri / Spotlight. Weak as a direct pull for ChatGPT/Gemini/Claude/Perplexity. | Apple ecosystem; secondary for this six |
+
+### Providers that are upstream hygiene only (not AI destinations)
+
+| Provider | Role | Honesty label |
+| --- | --- | --- |
+| Localeze / TransUnion (ex-Neustar Localeze) | Feeds partner directories and some Apple/Bing-class destinations. | Indirect. No clean published study that aggregator cleanup alone produces a measured +X% AI mention rate. |
+| Data Axle | Same class: feeds directories / nav / partner lists. | Indirect. Stops stale twins regenerating onto long-tail sites AIs may later browse. |
+| SafeGraph | B2B POI / analytics. | Not an owner claim path for SMB AI recommend in current SoT. |
+| Yext (and similar publishers) | Pipes into Google, Apple, Bing, Yelp, Foursquare, etc. | Execution speed and consistency. Not a unique AI corpus. |
+
+**Call one-liner:** Rank for AI discovery: GBP/Maps + (for Copilot) Bing Places + Yelp/Foursquare (ChatGPT) + Meta pages (Meta AI) + the business website ≫ Localeze/Data Axle as indirect warehouses ≫ Yext-class pipes. Aggregators matter to stop regeneration, not because ChatGPT "reads Localeze."
+
+---
+
+## 4. Per-platform discovery map (then recommendation depth)
+
+For each of the six: how discovery typically works, then what supplies recommendation depth after the gate.
+
+### ChatGPT
+
+- **Discovery:** Web search via third-party providers (Bing is a named provider; others may be used). Location may be shared with trusted local-listing partners. Documented place partners include **Yelp** (reviews, photos, business details; actions such as reserve / waitlist / request a quote) and **Foursquare Places** (Places API powering ChatGPT Search). Partner business feeds support local actions (for example restaurant reservation specs).
+- **After discovery:** Deeper Yelp content, partner feeds, and crawlable pages (business site, niche directories, MapQuest-class listing domains in citation studies).
+- **Not proven:** A direct owner "Localeze → ChatGPT" pipe. Completeness Score on an aggregator is not proof of ChatGPT discovery.
+- **Evidence labels:** Primary (OpenAI/Yelp announcements, OpenAI conversion feed specs); practitioner/vendor (BrightLocal, Yext, Foundation). BrightLocal-style "**60–70% of ChatGPT local from Foursquare**" is **UNVERIFIED magnitude** (partnership real; share not OpenAI-documented).
+
+### Gemini (and Google AI Mode / AI Overviews context)
+
+- **Discovery:** Google Maps / Google Business Profile via documented **Grounding with Google Maps** (places, reviews, photos, addresses, hours). Search grounding supplies web context.
+- **After discovery:** Maps place detail and reviews for AI Mode; for AI Overviews-style answers, the **business website** often carries more citation weight than Maps URLs.
+- **Caution:** GBP is necessary for the Google local graph, **not sufficient** for AI recommendation share. BrightLocal Local AI Visibility: Maps mention roughly ~66% vs AI surfaces ~32–38% (directional). SOCi LVI 2026: ChatGPT recommended ~1.2% of brand locations vs ~35.9% appearing in Google's top-3 (vendor study; directional). Maps pack strength ≠ AI recommend rate.
+- **Evidence labels:** Primary (Gemini Maps grounding docs, Google blog); practitioner study (Steady Demand: AI Mode ~79.8% Maps/GBP citations on local-intent vs AI Overviews ~3.1% Maps/GBP and ~70.7% business sites).
+
+### Perplexity
+
+- **Discovery:** Live web citation mix plus **Yelp Fusion** license (maps, reviews, photos in local suggestions).
+- **After discovery:** Cited Yelp pages, Maps/listing pages, niche directories, TripAdvisor (hospitality), MapQuest-class domains in vendor citation studies.
+- **Evidence labels:** Primary partnership (Verge/Yelp 2024); vendor citation mixes (BrightLocal, Foundation, Yext Scout). Competitive sets can omit Google itself or owned sites depending on study design.
+
+### Copilot
+
+- **Discovery:** Public web answers ground through **Bing Search**. **Bing Places** is the owner path into Bing Maps / local listings that Bing can retrieve.
+- **After discovery:** Bing-indexed business pages, partner content Bing surfaces (including historical and ongoing Yelp relationships on Bing local in various forms).
+- **Evidence labels:** Primary (Microsoft Copilot web access → Bing Search; Bing Places help). Less quantified than Google/Yelp share studies.
+
+### Claude
+
+- **Discovery:** Official **web search** tool with citations and optional user location. **No** documented dedicated local Places partner database in Anthropic docs.
+- **After discovery:** Whatever the retrieval index returns: business site, directories, Wikipedia when present, news/"best of" lists.
+- **Evidence labels:** Primary (Anthropic web_search tool docs). Backend index provider sometimes reported as Brave in industry chatter; **not Anthropic-confirmed**.
+
+### Meta AI
+
+- **Discovery:** Practitioner observation and Meta-ecosystem logic point to **Facebook Business Pages**, **Instagram business profiles**, WhatsApp Business catalogs, and Meta recommendations/reviews as the primary local graph inside Meta apps. Meta transparency: public Meta content and interactions are used to develop AI at Meta.
+- **After discovery:** Meta-graph engagement, reviews, catalogs; thin Meta presence means weak Meta AI surfacing even if GBP is strong.
+- **Evidence labels:** Meta transparency (training/product data classes); practitioner GEO writeups (not Meta-published ranking recipes). Treat exact ranking weights as **UNVERIFIED**.
+
+---
+
+## 5. Ranked providers by practical impact on discovery (then recommend)
+
+Ordered for **getting discovered** by the six platforms above. Recommendation depth notes sit under each item.
+
+1. **Google Business Profile / Google Maps**  
+   - Discovery: Dominant first-party graph for Gemini; crawlable listing pages for others.  
+   - Recommendation: Reviews, hours, photos, categories; still not enough alone for AI recommend share (see §4 Gemini caution).  
+   - Evidence: Gemini Maps grounding (primary); Steady Demand; BrightLocal; SOCi LVI (vendor).
+
+2. **Yelp**  
+   - Discovery: Licensed into ChatGPT and Perplexity; frequently cited listing/review domain.  
+   - Recommendation: Review text, photos, ratings; in-chat actions on ChatGPT.  
+   - Evidence: Axios/Yelp–OpenAI 2026; Verge/Perplexity 2024; BrightLocal; Foundation (vendor).
+
+3. **Bing Places + Bing index**  
+   - Discovery: Gate for Copilot and for ChatGPT paths that use Bing.  
+   - Recommendation: Whatever Bing retrieves next (site pages, enriched local modules).  
+   - Evidence: Microsoft Copilot → Bing Search; Bing Places owner docs.
+
+4. **Business website (+ LocalBusiness-style structured data)**  
+   - Discovery: Entity presence in web indexes used by Claude, Perplexity, ChatGPT, Gemini Overviews-like flows.  
+   - Recommendation: Services, FAQs, pricing, proof; often the depth layer after a thin directory hit.  
+   - Evidence: Steady Demand (AI Overviews cite sites heavily); Yext citation research (vendor); BrightLocal.
+
+5. **Foursquare Places**  
+   - Discovery: Confirmed ChatGPT Search Places partner; syndicating graph into other apps/maps.  
+   - Recommendation: Place attributes via partner API (often invisible as a user-facing URL).  
+   - Evidence: Foursquare/ChatGPT partner announcements (primary/partner); BrightLocal aggregator matrix. Share % **UNVERIFIED**.
+
+6. **Facebook / Instagram business pages**  
+   - Discovery: Gate for Meta AI. Soft/secondary for the other five.  
+   - Recommendation: Meta reviews, posts, catalogs.  
+   - Evidence: Meta transparency + practitioner observation.
+
+7. **Apple Business / Apple Maps**  
+   - Discovery: Critical inside Apple (Maps, Siri, Spotlight). Weak documented direct discovery for the six chatbots.  
+   - Recommendation: Apple place card quality; Yelp historically supplies Apple Maps.  
+   - Evidence: Apple Business newsroom 2026; Axios (Yelp → Apple Maps).
+
+8. **Niche directories + MapQuest / TripAdvisor-class sites**  
+   - Discovery: Matter when models browse listing domains for "best X in city" and vertical queries.  
+   - Recommendation: Category-specific trust and UGC.  
+   - Evidence: Yext/Foundation citation tallies (vendor).
+
+9. **Localeze/TransUnion, Data Axle, SafeGraph, Yext**  
+   - Discovery: Indirect only (feed or sync into destinations above).  
+   - Recommendation: None as a named AI corpus.  
+   - Evidence: BrightLocal aggregator distribution tables; ALTERNATE/CONCEPT honesty flags. Do not invent aggregator → AI lift %.
+
+---
+
+## 6. Practical owner checklist (discovery first)
+
+1. **Be discoverable on the graph each assistant actually queries**
+   - Gemini: complete, accurate Google Business Profile.
+   - Copilot: Bing Places + pages Bing indexes (Bing Webmaster).
+   - ChatGPT: Yelp claim + Foursquare presence/partner path + Bing-visible site/listing.
+   - Perplexity: Yelp + crawlable site + clean listing pages.
+   - Claude: crawlable site and reputable third-party mentions (no Places API shortcut).
+   - Meta AI: Facebook and Instagram business profiles (and WhatsApp Business where relevant).
+
+2. **Only then deepen recommendation signals**
+   - Reviews and owner responses (Google, Yelp, Meta as applicable).
+   - Website pages that answer services, hours, service area, pricing, FAQs (with schema).
+   - Action paths where offered (reserve, quote, waitlist partners).
+
+3. **Use aggregators and publishers as hygiene**
+   - Localeze / Data Axle / Yext: keep name, address, and phone consistent so stale twins do not regenerate onto long-tail sites.
+   - Do not treat Completeness Score or aggregator paywalls as proof of AI discovery.
+   - Prove with **re-asking the assistants** on real local queries, not vendor scores alone.
+
+---
+
+## 7. Sources (selected)
+
+**Primary / official**
+
+- Google: [Grounding with Google Maps](https://ai.google.dev/gemini-api/docs/maps-grounding); [Maps grounding launch post](https://blog.google/innovation-and-ai/technology/developers-tools/grounding-google-maps-gemini-api/)
+- OpenAI: local services / restaurant reservation conversion feed specs on developers.openai.com; ChatGPT Search help (third-party search + location to trusted local providers)
+- Microsoft: Copilot public web access → Bing Search; Bing Places owner help
+- Anthropic: Claude web_search tool docs
+- Apple: [Apple Business announcement](https://www.apple.com/newsroom/2026/03/introducing-apple-business-a-new-all-in-one-platform-for-businesses-of-all-sizes/)
+- Yelp ↔ OpenAI: [Axios](https://www.axios.com/2026/07/23/yelp-reviews-chatgpt-geo-partnership); [Yelp blog](https://blog.yelp.com/news/yelp-chatgpt-integration/)
+- Yelp ↔ Perplexity: [The Verge](https://www.theverge.com/2024/3/12/24098728/perplexity-chatbot-yelp-suggestions-data-ai)
+
+**Practitioner / vendor (directional; label bias)**
+
+- Steady Demand: AI Overviews vs AI Mode local citation mix
+- BrightLocal: Local AI Visibility; AI search listing sources; aggregator distribution matrix
+- SOCi LVI 2026: ChatGPT vs Google top-3 location coverage (vendor)
+- Search Engine Journal: AI data sources table (Chris Green, Sep 2026)
+- Yext Scout / Foundation–AirOps Yelp citation studies
+- Repo SoT cross-check: `docs/ALTERNATE_BUSINESS_PROPOSAL.md`, `docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md` (SEO Desk synthesis 2026-10-01)
+
+**Popularity metrics**
+
+- Statcounter AI chatbot market share; First Page Sage / Momentic-style visit-share panels; MAU figures from company earnings (Meta AI, Gemini app, ChatGPT WAU). Prefer dated, metric-labeled cites in external copy.
+
+---
+
+## 8. Open flags
+
+- Re-verify top-six popularity quarterly; DeepSeek/Grok may displace a slot on traffic-only charts.
+- Re-verify Foursquare↔ChatGPT share claims only against OpenAI or Foursquare primary docs (magnitude currently UNVERIFIED).
+- No invented Localeze/Data Axle → AI mention lift.
+- Meta AI ranking recipe not published by Meta.
+- Claude search index provider not confirmed by Anthropic.

docs/writing-rules.md

@@ -0,0 +1,36 @@
+# Writing rules (outsider-first)
+
+**Branch:** `planning-selfserve-audit`  
+**Scope:** Strategy and research docs under `docs/` (especially commercial proposals and research briefs). Complements [`CONVENTIONS.md`](./CONVENTIONS.md) (anti-duplication); does not replace it.
+
+These rules exist so a reader with no industry background can follow the argument on the first pass.
+
+---
+
+## 1. No insider jargon without a plain clause
+
+On first use of a term a bakery owner would not know, explain it in one plain clause in the same sentence (or the next). Prefer ordinary words over acronyms. If you must use a short label later, introduce it once.
+
+Examples: say “Google’s short list of three at the top of many local searches” before “3-Pack”; say “name, address, and phone” before “NAP”; say “Google Business Profile” before “GBP.”
+
+## 2. Open every claim with the reader’s trigger
+
+Before any product action or “we build…”, show the problem the reader feels — lost customers, wrong hours, dead phone number, AI pointed somewhere else. Action comes after the trigger. Reference voice on this branch: commits `fa98bdb` (claims for zero-insider readers) and `b859f3e` (claim 1 opens with the owner’s trigger).
+
+## 3. Plain verbs, conversational prose
+
+Write like a clear friend who knows the subject. Complete sentences. No throat-clearing (“the sections below keep…”, “they are the receipts”), no slogan-as-mechanism, no AI-slop padding.
+
+## 4. Claims first, evidence underneath
+
+Lead with the argument the outsider needs. Put tables, studies, and source labels below as support. Label evidence: practitioner-reported, vendor, primary study, or UNVERIFIED. Cite or mark BLOCKED — do not invent numbers.
+
+## 5. One SoT per topic
+
+Amend the existing file for a topic. Do not create sibling PLAN/CONCEPT/BRIEF twins. See [`CONVENTIONS.md`](./CONVENTIONS.md).
+
+---
+
+## Capture
+
+Standing outsider-first rules recorded 2026-10-01 from corrected-voice passes on the research brief (`fa98bdb`, `b859f3e`).