Unslop: lock placement map; fold plan; evidence/

- README = map + anti-slop placement rules - BUSINESS_PLAN at docs/ (sole strategy SoT); absorb beyond-NAP - Fold owner workflow, surfaces, MCP distribution - research/ → evidence/; drop stub READMEs + LAYERS twin - Fix dead main ghosts; Desk = sole scribe
2026-09-15 20:11:59 +00:00
parent c884aa058a
commit 9efd554e11
11 changed files with 269 additions and 301 deletions
@@ -1,23 +1,32 @@
 # geolocal.io — planning-rev2
-**Net-new planning branch** from the 2026-09-15 SEO / POR session.  
+**Net-new planning branch** (2026-09-15 session). Not a clone of `main`. Do not merge main docs here.
 Not a clone of `main`. Do not merge main docs into this branch.
-## What’s here
+## Map (locked)
 | Path | Role |
 | :--- | :--- |
-| `docs/strategy/BUSINESS_PLAN.md` | Working plan / POR checkpoint |
+| `docs/BUSINESS_PLAN.md` | **Only** home for the business idea / strategy / GTM / wedge / workflow / MCP / packaging |
-| `docs/strategy/LAYERS-BEYOND-NAP.md` | Beyond NAP: extras + stacks; why owners care |
+| `docs/GLOSSARY.md` | Industry terms only |
-| `docs/GLOSSARY.md` | Running glossary (NAP, GBP, Core 3, …) |
+| `docs/product/genre-packs.md` | Layer A/B/C index (how we surface work to owners) |
-| `docs/product/genre-packs.md` | Layer A/B/C + pack index |
+| `docs/product/genre-packs/` | Field SoT (`SOURCES.md`, `core3-field-map.md`) + genre notes (`salon.md`, `bakery.md`) |
-| `docs/product/genre-packs/core3-field-map.md` | Sourced Core 3 field map |
+| `docs/evidence/` | Sourced research notes (cite URL) — not strategy |
-| `docs/product/genre-packs/SOURCES.md` | Official GBP / Apple / Bing URLs |
+
-| `docs/product/genre-packs/salon.md` | Salon pack (application notes) |
+## Placement rules (agents must follow)
-| `docs/product/genre-packs/bakery.md` | Bakery pack (application notes) |
+
 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.
 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:
   - **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`
 ## Process
- porbot scribes essence only; SEO & AEO Desk pressure-tests in chat
+- **SEO & AEO Desk** = sole scribe + conversation SME on this branch.
- Nothing locked until Ty says so
+- Essence of agreed direction only; mark provisional until Ty locks.
- Never invent Core 3 fields — use `SOURCES.md`
+- Nothing locked until Ty says so.
 - Never invent Core 3 fields — use `docs/product/genre-packs/SOURCES.md`.
@@ -0,0 +1,236 @@
 # geolocal.io — Business Plan (working draft)
 **Branch:** `planning-rev2`  
 **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.
 **How we work this file**
 - Checkpoint after solid decisions (or when a phrase must not be lost).
 - Prefer revising this over spawning parallel strategy docs.
 - Mark unknowns as open questions. Do not invent market numbers here.
 - Nothing is locked until Ty says so.
 - Scribe the **essence** of agreed direction. Do not promote open packaging into POR until it sticks.
 - **Scribe:** SEO & AEO Desk (sole).
 ---
 ## 1. North star (wording still open)
 **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.
 ---
 ## 2. What the company is
 Infrastructure — not a consumer destination.
 - Host structured business truth so AI assistants can discover, understand, and recommend local businesses (services and local retail with real-world presence).
 - Give the business a simple way to point at that truth (no servers for them to run).
 - Orchestrate booking / payment / related partners where needed; do not rebuild Calendly or Shopify.
 - Stay invisible to end consumers; win by being useful to agents and trustworthy to owners.
 **Not:** another Yelp/Google for human browsing attention.
 ---
 ## 3. Who we serve
 **Primary customer:** the business owner.
 By extension:
 - Someone in their organization acting for them
 - A partner they already trust (agency, SEO, chamber, tourism board)
 Partners are a **path to the owner**, not a different product.
 ---
 ## 4. How demand shows up (two moments)
 1. **Presence for other AIs** — When a consumer’s assistant asks for a local plumber / salon / store, structured geolocal data can be consulted and acted on.
 2. **Owner (or their AI) asks for help** — “How do we help our business be discovered by AI?” Invest in scenarios where the owner’s own AI can diagnose and set that up — not only human sales through agencies.
 Same north star; different moments of truth.
 ---
 ## 5. Wedge and flywheel (direction agreed)
 **Preferred wedge:** a free AI-visibility checkup.
 Why:
 - Shows immediate value / need
 - Builds critical mass
 - Small free actions amplify adoption
 **Long-term reputation bet:** become so useful and dense that AI systems default to checking geolocal for local-class queries — analogous to how they lean on Yelp or Foursquare today.
 **Strategic read:** free usefulness → coverage → agent trust → more local queries resolved via geolocal → more owners want in → denser graph.
 Evidence (category signal, not brand list): [`docs/evidence/SBE-TECH-USE-SURVEY-2026.md`](./evidence/SBE-TECH-USE-SURVEY-2026.md) — high AI tool use among SMBs; research/content dominate; local discovery gap; peer/WOM trust path.
 ---
 ## 6. Owner experience
 ### 6.1 Initial workflow (working direction)
 1. Arrive on an **outcome promise** (not plumbing)
 2. Tell us the business
 3. **Validation gate** — prove you represent the business
 4. Dual-scoreboard audit in owner language + ranked foundation gaps
 5. Short punch list (3–7 actions)
 6. Optional durable step (minimal owned geolocal record on free path)
 7. Return hook for re-check
 ### 6.2 Surfaces (working direction)
 - **V1:** `geolocal.io/getstarted` (or similar) with **inline AI chat** driving intake — not forms-first.
 - **Parallel from day one (design):** owner-agent → Owner MCP (same workflow).
 - Thin status page behind login can hold the scorecard later.
 - Web chat = on-ramp + control; agent-to-agent = scale + distribution.
 **Hard rule:** chat and MCP are **clients of one backend workflow** (verify → dual-score audit → punch list). If they diverge, we’ve built two products.
 ### 6.3 Entry / discoverability angles (working — capture, not all build now)
 Partner paths, search, owner’s own AI asking “how do we get discovered,” later marketplace listings — prioritize by trust (peers/WOM) and where the discovery question is asked.
 ### 6.4 Phase 1 conversation tone
 Speak **outcomes**, not plumbing. Example: “most recommended bakery on Whidbey Island for muffins.” Do not lead with MCP, endpoints, or `llms.txt`.
 ---
 ## 7. Scorecard and tiers
 ### 7.1 Owner-facing scorecard (working — not locked)
 Three top-line outcomes (wording TBD), each with plain “why not yet”:
 1. **AI knows you exist** — findable identity / NAP / listings  
 2. **AI knows what you do** — services, specialties, hours  
 3. **AI would recommend you** — trust + fit for a real job in a place  
 Not a 40-row SEO audit. Dual scoreboard: hygiene feeds rungs 1–2; recommendability is differentiation. How we *measure* “would recommend” (heuristics vs live assistant checks) stays open.
 ### 7.2 Discovery foundation + AI readiness
 **Two tiers, one product story** (owner language):
 1. **Discovery foundation** — Core listings + NAP/hours/category/contact consistency (internal: “2017”)
 2. **AI readiness** — known-for queries, scorecard, structured presence when ready (internal: “2027”)
 Measure both early; *fix* foundation first when broken. Skip invented hygiene if already clean.
 **Owner vocab:** Core listings; The Core 3 (GBP, Apple Business Connect, Bing Places).
 **Foundation bar** (brick-and-mortar local) — not reviews, photo perfection, or ranking #1:
 1. One clear identity — correct NAP; no competing duplicates  
 2. Claimed Core 3 (genre/market adds are separate)  
 3. Accurate hours  
 4. Right category + short plain “what you do”  
 5. Reachable — working phone and/or website/contact  
 6. Not contradictory — site vs Core 3 agree on name/place/hours  
 **Foundation sync (P1)** across Core 3: NAP + primary category + hours + website URL + short description + service-area/address mode. P2 (attributes, photos, menus, booking, secondary categories) is genre/known-for gated.
 ### 7.3 Surfacing work — Layer A / B / C
 Not one giant schema. **A** universal Discovery foundation → **B** thin genre pack → **C** known-for overlay. Scorecard first, then 3–7 actions max by impact.
 Index + packs: [`docs/product/genre-packs.md`](./product/genre-packs.md).
 ### 7.4 Beyond NAP — provider capability ladder
 *(Absorbed from former `LAYERS-BEYOND-NAP.md` — do not re-spawn that file.)*
 Distinct from Layer A/B/C (what work we show). This is what providers can hold:
 1. **Shared listing basics (Core 3)** — category, hours, website, description, service-area mode  
 2. **Provider listing extras** — GBP services/posts/actions/attrs; Apple Good to Know / hours types; Bing thinner  
 3. **Provider stacks** — Apple Stack (brand → Maps+Wallet/Pay, Showcases, Actions, Insights); Google = rich but fragmented listing + adjacent products  
 **Why owners care:** NAP = findable; extras = know what you do; stacks/actions = chosen and acted on.
 Field SoT: [`docs/product/genre-packs/core3-field-map.md`](./product/genre-packs/core3-field-map.md). Sources: [`SOURCES.md`](./product/genre-packs/SOURCES.md).
 **Later proof layer (not free first-hour):** platform KPI telemetry (e.g. Apple Insights). Show only what platforms return — never invent numbers. Fit = ongoing AI readiness / retention.
 ### 7.5 Validation gate (essence)
 Anyone using GeoLocal tools must pass a **business-representation check** first. Mechanism and free/silver/gold allotments stay open until COGS is real.
 ### 7.6 Free path after checkup (not locked)
 1. Ranked DIY punch list  
 2. Mint of a **minimal owned geolocal record** — densify does not wait for paid  
 Soft upsell: “comfortable DIY, or want GeoLocal to help?”
 **Bundles (free/silver/gold):** pinned open — capture value-prop angles first, then revisit.
 ### 7.7 Paid “help” vs product (not locked)
 - **Paid listing cleanup** = partner / agency **fulfillment**, not the product.  
 - **Product** = owned geolocal record + ongoing AI-readiness score (and later agent-facing presence).  
 Do not document GeoLocal as a local SEO shop with extra steps.
 ---
 ## 8. Distribution investment (working direction)
 **Invest in one portable Owner MCP** wired to the geolocal.io backend (same workflow as chat). Thin adapters/listings second — not five one-off apps.
 | Priority | Surface | Call |
 | :--- | :--- | :--- |
 | P0 | Owner MCP + web chat | Build / debug privately first |
 | P1 | GrokBot (dogfood) → Claude Connectors / ChatGPT plugins / Grok connectors | Thin listings on the **same** MCP |
 | P2 | Square OAuth (optional) | Only if it shortens verify/NAP — not a second product |
 | P3 | Square App Marketplace listing | **Defer** until free-checkup proof; marketplace onboarding without Partnerships contact was paused (2026) |
 **Debug sequence:** private/local MCP → Ty + GrokBot → harden auth/rate limits → public listings. Remote connectors need a public MCP URL when opened.
 **Anti-pattern:** separate “GeoLocal for Square / GPT / Claude” codebases.
 ---
 ## 9. Business plan audience (still open)
 Primary reader for v1 structure: internal / investors / partners — pick one first.
 ---
 ## 10. Inputs (not on this branch)
 `main` holds older planning (north star, canonical strategy, SSP use cases, etc.). Treat as **raw material only** — do not re-import into this branch. Resolve conflicts on purpose in this file when pulling an idea over.
 Evidence and field sources that *are* on this branch live under `docs/evidence/` and `docs/product/genre-packs/SOURCES.md`.
 ---
 ## 11. Checkpoint log (trim, don’t spawn)
 | When | What landed |
 | :--- | :--- |
 | 2026-09-15 | North star; owner-first; partner path; owner-AI “get discovered”; free checkup wedge; reputation flywheel |
 | 2026-09-15 | Dual scoreboard; Discovery foundation → AI readiness; Core 3 vocab; foundation six-point bar; P1 sync fields |
 | 2026-09-15 | Layer A/B/C; sourced Core 3 field map; salon/bakery application notes; Apple API names BLOCKED when gated |
 | 2026-09-15 | Validation gate essence; free DIY + minimal record; paid cleanup = fulfillment; bundles pinned open |
 | 2026-09-15 | Owner workflow + V1 chat + Owner MCP same backend; distribution: one MCP, thin AI adapters, defer Square Marketplace |
 | 2026-09-15 | Unslop: locked placement map; absorbed beyond-NAP into this file; evidence/ folder; Desk = sole scribe |
 ---
 ## Next conversation topics
 1. Wordsmith scorecard rungs + plain “why not yet” evidence  
 2. How to measure “would recommend” honestly  
 3. Primary reader for v1 of this plan  
 4. Offer / packaging after value-prop angles captured  
 5. First 3–5 Owner MCP tools (owner-facing)  
 6. 90-day proof: what “AI checks us” requires in coverage/quality  
@@ -16,3 +16,5 @@ Running definitions for industry terms used in geolocal.io planning.
 | **Apple Stack** | Owner-facing name for Apple Business brand/place-card capabilities above NAP: Brand logo/Style Guide, cover into Maps + Wallet/Pay, Showcases, Actions, Insights — a unified brand OS, not just a Maps pin. |
 | **Listings pack** | Per-provider capability model (what GBP / Apple / Bing can hold above NAP). Distinct from **genre pack** (what a salon vs bakery must prove). |
 | **Owner MCP** | GeoLocal’s Model Context Protocol server for owners (or their AIs): same verify → audit → punch list workflow as the web chat, exposed as tools. One server; thin adapters to Claude / ChatGPT / Grok / GrokBot. |
 | **Layer A / B / C** | How GeoLocal surfaces work: **A** universal Discovery foundation, **B** genre pack, **C** known-for. Distinct from the beyond-NAP provider capability ladder. |
@@ -1,3 +0,0 @@
 # docs (planning-rev2)
 Session planning docs only. See repo root `README.md`.
@@ -79,5 +79,5 @@ Sample is general SMB 2–99 (professional services, construction, tech, retail,
 ## Related POR
- `docs/strategy/BUSINESS_PLAN.md` — north star, wedge, owner workflow, tiers
+- `docs/BUSINESS_PLAN.md` — north star, wedge, owner workflow, tiers
 - Packaging free/silver/gold: **pinned open** until value-prop angles are fully captured
@@ -1,3 +0,0 @@
 # product
 Genre packs and Core 3 field map for this planning session. See `genre-packs.md`.
@@ -12,25 +12,21 @@
 **Core 3 coverage rule:** **GBP** is richest; Apple Business Connect mid; Bing Places thinnest. Pack actions: set on GBP; mirror on Apple/Bing where the field exists.
-## Sourced Core 3 map + deep examples (planning-rev2)
+**Not the same as “beyond NAP”:** A/B/C = *what work we show the owner*. Beyond-NAP (in `docs/BUSINESS_PLAN.md`) = *provider capability ladder* (basics → extras → stacks).
 ## Sourced Core 3 map + deep examples
 - [Core 3 sourced field map](./genre-packs/core3-field-map.md) — **SoT for fields** (no guessing)
 - [Core 3 source URLs](./genre-packs/SOURCES.md) — GBP / Apple / Bing links to reopen
 - [Salon](./genre-packs/salon.md) — genre application notes (illustrative only)
 - [Bakery](./genre-packs/bakery.md) — same
-## Earlier planned packs (from main / prior docs)
+## Later packs (not started on this branch)
- Auto repair (see [UC-01](./use-cases/uc-01-endpoint-auto-repair.md))
+Auto repair, beauty (reconcile with salon), home services, tourism activity, local retail — add only when we go deep; no placeholder shells.
 - Beauty (overlaps salon — reconcile later)
 - Home services
 - Tourism activity ([UC-02](./use-cases/uc-02-intermediate-tourism-board.md))
 - Local retail / general store ([UC-03](./use-cases/uc-03-local-retail-general-store.md))
 ## Why this matters
 Assistants evaluate helpfulness by whether the business answers the *right* questions for its category. Salon booking ≠ bakery known-for products.
-## Detail source
+Plan pointer: [`docs/BUSINESS_PLAN.md`](../BUSINESS_PLAN.md).
 Conversation checkpoint on `planning-rev2`; [BUSINESS_PLAN.md](../strategy/BUSINESS_PLAN.md); [Canonical Strategy](../strategy/CANONICAL_STRATEGY.md) §1a.
@@ -3,7 +3,7 @@
 Canonical links for Discovery foundation / field-map work. **Do not invent fields from memory — open these.**  
 If a link is dead or gated, mark **BLOCKED** in chat and in `core3-field-map.md`.
-Last updated: 2026-09-15 (porbot)
+Last updated: 2026-09-15 (SEO & AEO Desk)
 ---
@@ -1,213 +0,0 @@
 # geolocal.io — Business Plan (working draft)
 **Branch:** `planning-rev2`  
 **Status:** In progress — conversation checkpoint, not final  
 **Purpose:** One durable place for the clean plan. Existing docs on `main` are raw material; this file is what we iterate.
 **How we work this file**
 - Checkpoint here after every few solid decisions (or when a phrase must not be lost).
 - Prefer revising this over spawning parallel strategy docs.
 - Mark unknowns as open questions. Do not invent market numbers here.
 - Nothing is locked until Ty says so. Checkpoint working directions; revise freely as the conversation matures.
 - Scribe the **essence** of agreed direction. Do not promote open-discussion packaging/options into POR until they stick.
 ---
 ## 1. North star (wording still open)
 **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.
 ---
 ## 2. What the company is
 Infrastructure — not a consumer destination.
 - Host structured business truth so AI assistants can discover, understand, and recommend local businesses (services and local retail with real-world presence).
 - Give the business a simple way to point at that truth (no servers for them to run).
 - Orchestrate booking / payment / related partners where needed; do not rebuild Calendly or Shopify.
 - Stay invisible to end consumers; win by being useful to agents and trustworthy to owners.
 **Not:** another Yelp/Google for human browsing attention.
 ---
 ## 3. Who we serve
 **Primary customer:** the business owner.
 By extension:
 - Someone in their organization acting for them
 - A partner they already trust (agency, SEO, chamber, tourism board)
 Partners are a **path to the owner**, not a different product.
 ---
 ## 4. How demand shows up (two moments)
 1. **Presence for other AIs** — When a consumer’s assistant asks for a local plumber / salon / store, structured geolocal data can be consulted and acted on.
 2. **Owner (or their AI) asks for help** — Emerging path: “How do we help our business be discovered by AI?” Geolocal should invest in scenarios where the owner’s own AI can diagnose and set that up — not only human sales through agencies.
 Same north star; different moments of truth.
 ---
 ## 5. Wedge and flywheel (direction agreed)
 **Preferred wedge:** a free AI-visibility checkup (SSP audit).
 Why:
 - Shows immediate value / need
 - Builds critical mass
 - Small free actions amplify adoption
 **Long-term reputation bet:** become so useful and dense that AI systems default to checking geolocal for local-class queries — analogous to how they lean on Yelp or Foursquare today.
 **Strategic read (not pricing gimmick):** free usefulness → coverage → agent trust → more local queries resolved via geolocal → more owners want in → denser graph.
 ### Phase 1 owner conversation (working direction — not locked)
 Speak **outcomes**, not plumbing. Example: “most recommended bakery on Whidbey Island for muffins.” Do not lead with MCP, endpoints, or `llms.txt`.
 Phase 1 *fixes* usually look like classic local visibility hygiene (2017-style) before deeper 2027 agent work:
 - NAP (Name, Address, Phone) consistency
 - Hours alignment across platforms
 - Maps / GBP / Yelp (and similar) listing hygiene
 **Working nuance (2026-09-15):** foundation-first for *fixes*, not for *measurement*. The free audit’s scoreboard is AI recommendability in plain English (“would an assistant recommend you for this job in this place — and why not?”), not “GBP is 67% complete.” If 2017 hygiene is already solid, skip fake Google-fix busywork and go straight to agent gaps. Differentiation vs commodity local SEO lives in that scoreboard.
 ### Owner-facing scorecard (working direction — not locked)
 POR work: an intuitive scorecard a business owner understands. Top-level outcomes (wording TBD), not SEO jargon:
 1. **AI knows you exist** — findable identity / NAP / listings
 2. **AI knows what you do** — services, specialties, hours — enough to answer “what is this place?”
 3. **AI would recommend you** — enough trust + fit that an assistant would pick you for a real job in a place
 Keep to **three top-line outcomes**, each with plain “why not yet” underneath — not a 40-row SEO audit. Dual scoreboard still applies: hygiene work feeds rungs 1–2; recommendability is the differentiation line.
 **Agreed essence so far:** scorecard is owner-plain (exist / know what you do / would recommend), not a long SEO audit. How we *measure* “would recommend” (heuristics vs live assistant checks, free vs paid depth) is still open discussion — do not treat packaging ideas as POR until Ty says they stick.
 ### Discovery foundation + AI readiness (working direction — essence)
 **Two tiers, one product story** (owner language):
 1. **Discovery foundation** — Core listings + NAP/hours/category/contact consistency (internal: “2017”)
 2. **AI readiness** — known-for queries, exist / know what you do / would recommend, structured presence when ready (internal: “2027”)
 Measure both early; *fix* foundation first when broken.
 Owner vocab (use these terms going forward):
 - **Core listings** — main places customers (and AI) look the business up
 - **The Core 3** — GBP, Apple Business Connect, Bing Places
 Foundation bar (brick-and-mortar local) — not reviews, photo perfection, or ranking #1:
 1. One clear identity — correct NAP everywhere that matters; no competing duplicates
 2. Claimed Core 3 listings (genre/market adds are separate, not universal min-bar)
 3. Accurate hours (incl. obvious holiday/seasonal where relevant)
 4. Right category + short plain “what you do”
 5. Reachable — working phone and/or website/contact path
 6. Not contradictory — site vs Core 3 don’t disagree on name/place/hours
 Checked *on* the Core 3 (and the site). Prerequisite for 2027 work **when flaws exist**; skip invented hygiene if already clean.
 **Foundation sync (P1)** across Core 3: NAP + primary category + hours + website URL + short description + service-area/address mode. Phone lives in NAP but must match. P2 (attributes, photos, menus, booking, secondary categories) is genre/known-for gated — not universal min-bar.
 ### Surfacing work to owners (working direction — essence)
 **Later proof layer (working idea, not free first-hour):** platform KPI telemetry (e.g. Apple Insights — searches, place card views, Actions). Owner language: found you → tapped directions/call. Pair with GBP performance later. Show only what platforms return — never invent numbers. Fit = ongoing AI readiness / retention, not the initial free scorecard.
 Three layers (not one giant schema): **A** universal Discovery foundation → **B** thin genre pack → **C** known-for overlay. Scorecard first, then 3–7 actions max by impact.
 Deep example packs: [`docs/product/genre-packs/salon.md`](../product/genre-packs/salon.md), [`docs/product/genre-packs/bakery.md`](../product/genre-packs/bakery.md). Index: [`docs/product/genre-packs.md`](../product/genre-packs.md).
 ### Layers beyond NAP (working direction — essence)
 See [`LAYERS-BEYOND-NAP.md`](./LAYERS-BEYOND-NAP.md).
 1. **Shared listing basics (Core 3)** — category, hours, website, description, service-area mode  
 2. **Provider listing extras** — GBP services/posts/actions/attrs; Apple Good to Know / hours types; Bing thinner  
 3. **Provider stacks** — Apple Stack (brand → Maps+Wallet/Pay, Showcases, Actions); Google = rich but fragmented listing + adjacent products  
 **Why owners care:** NAP = findable; extras = know what you do; stacks/actions = chosen and acted on.
 ### Validation gate (working direction — essence)
 Anyone using GeoLocal tools must pass a **business-representation check** first (e.g. prove control of a contact channel tied to that business). Mechanism details and free/silver/gold allotments stay open until COGS is real — only the gate itself is directional essence so far.
 ### Free path after checkup (working direction — not locked)
 Free includes:
 1. Ranked DIY punch list the technical owner can execute (e.g. align hours across providers)
 2. Mint of a **minimal owned geolocal record** (name, place, category, plus plain-English AI recommendability) — densify does **not** wait for paid
 Soft upsell in-product: “comfortable DIY, or want GeoLocal to help?”
 ### Paid “help” vs product (working direction — not locked)
 - **Paid listing cleanup** (Maps / hours / NAP fixes done for the owner) = partner / agency **fulfillment**, not the product.
 - **Product** = the owned geolocal record + ongoing AI-readiness score (and later agent-facing presence).
 Do not document GeoLocal as a local SEO shop with extra steps.
 ---
 ## 6. Business plan audience (still open)
 Clarify what this document must optimize for first:
 - Internal clarity (founders / operators)
 - Investors
 - Partners / channels
 Can serve more than one later; pick the primary reader for v1 structure.
 ---
 ## 7. Source material (do not duplicate blindly)
 Treat as inputs, not competing sources of truth while this draft is live:
 - `NORTH_STAR.md`
 - `docs/strategy/CANONICAL_STRATEGY.md`
 - `docs/gtm/`, `docs/investors/`, `docs/product/`
 - `docs/archive/` — historical only
 If something here conflicts with `CANONICAL_STRATEGY.md`, resolve on purpose in a later pass — do not silently fork forever.
 ---
 ## 8. Checkpoint log
 | When | What landed |
 | :--- | :--- |
 | 2026-09-15 | North star intent; owner-first buyer; partners as extension; agent-mediated “get discovered” path; free checkup wedge; reputation / critical-mass flywheel; open question on free durable win vs diagnosis-only |
 | 2026-09-15 | Working direction (not locked): phase 1 = outcome language + local-hygiene foundation; free may include DIY punch list + minimal owned record; paid listing-fix as partner/agency fulfillment; product = record + AI-readiness score; porbot = repo scribe, Desk = conversation |
 | 2026-09-15 | Process: nothing locked yet — distill POR as we build; porbot scribes so key insights are not lost |
 | 2026-09-15 | Working nuance: 2017 hygiene usually first *fix* work; dual scoreboard from day one (hygiene + AI recommendability); skip forced hygiene phase if foundation already solid |
 | 2026-09-15 | Working direction: owner scorecard ladder — knows you exist / knows what you do / would recommend you (wording TBD); open whether v1 recommend = heuristic vs live assistant pings |
 | 2026-09-15 | Process note: scribe essence of agreed direction only — exploratory packaging stays out of POR until it sticks |
 | 2026-09-15 | Essence: validation gate before tool use (prove you represent the business); plan tier numbers still open |
 | 2026-09-15 | Essence: owner vocab Core listings / Core 3; 2017 foundation six-point bar checked on Core 3 + site |
 | 2026-09-15 | Essence: two tiers — Discovery foundation → AI readiness (owner names); measure both early, fix foundation first when broken |
 | 2026-09-15 | Essence: P1 foundation sync = NAP + category + hours + website + description + service-area mode; P2 genre/known-for gated |
 | 2026-09-15 | Essence: Layer A/B/C surfacing; deep pack shells for salon + bakery under docs/product/genre-packs/ |
 | 2026-09-15 | Salon + bakery packs: parent/child × Core 3 example field matrices checked in |
 | 2026-09-15 | Pack matrices: added Why it matters + sourced vs placeholder honesty after Desk Core 3 source check |
 | 2026-09-15 | Replaced guessed genre matrices with sourced Core 3 field map (core3-field-map.md); salon/bakery = application notes only |
 | 2026-09-15 | Apple Core 3 column = UI labels until Business Connect Location API v1.3 field list dumped; no invented Apple schema names |
 | 2026-09-15 | Apple column filled from Configure location attributes guide; still BLOCKED on API camelCase names + per-genre attribute enums |
 | 2026-09-15 | Punted Apple partner API schema rabbit hole; noted Insights-style KPIs as later proof/retention (SOURCES.md); still BLOCKED on per-genre attribute enums |
 ---
 ## Next conversation topics
 1. Wordsmith the three scorecard rungs; define plain “why not yet” evidence under each
 2. How to measure “would recommend” honestly (still open)
 3. Primary reader for v1 of this plan (internal / investors / partners)
 4. Offer / packaging detail (what free record includes vs what paid unlocks beyond fulfillment) — no invented numbers
 5. 90-day proof: what “reputable enough that AI checks us” requires in coverage and quality
 6. Owner MCP vs GeoLocal.io chat: same journey or separate surfaces (later layer; keep out of phase-1 owner talk)
@@ -1,51 +0,0 @@
 # Layers beyond NAP — why owners should care
 **Status:** working essence (2026-09-15 session) — not locked  
 **Audience:** GeoLocal POR / owner-language planning
 ---
 ## NAP is the floor
 **NAP** = Name, Address, Phone. Matching identity across Core listings is the floor. Without it, Maps and assistants can’t reliably find the business.
 ---
 ## Three layers above NAP
 ### 1. Shared listing basics (Core 3)
 Category, hours, website, short description, service-area/address mode — same *job* on **GBP**, **Apple Business Connect**, and **Bing Places**: what you are, when you’re open, how to reach you.
 Field SoT: [`../product/genre-packs/core3-field-map.md`](../product/genre-packs/core3-field-map.md).
 ### 2. Provider listing extras
 Platform-specific depth beyond the shared basics, e.g.:
 - **GBP:** services (`serviceItems`), products, posts, Place Actions, category-dynamic attributes, photos  
 - **Apple:** Good to Know, richer hours types (normal / service / temporary), About, Actions (as offered)  
 - **Bing:** thinner extras  
 This moves the owner from “they can find me” → “they know what I do.”
 ### 3. Provider brand / capability stacks
 Specialized capability above listing extras:
 - **Apple Stack (clearest unified OS):** Brand (logo, Style Guide) → place card that carries logo/cover into **Maps and Wallet/Pay**, Showcases, approved Actions, Insights  
 - **Google:** rich but **fragmented** — GBP listing extras + adjacent products (Brand profile, Merchant Center, Pay/Wallet console branding). Not one Apple-shaped brand OS  
 Sources: [`../product/genre-packs/SOURCES.md`](../product/genre-packs/SOURCES.md).
 ---
 ## Why business owners should care
 | Layer | Owner outcome |
 | :--- | :--- |
 | NAP | Findable — assistants and Maps can match you |
 | Shared basics + extras | Understandable — what you do, when, how to reach |
 | Stacks (esp. Apple Actions / Google Place Actions) | **Chosen and acted on** — directions, call, book, order |
 Discovery foundation → AI readiness is this ladder: exist → know what you do → recommend / act. NAP alone is not enough for “most recommended bakery for muffins.”
@@ -1,5 +0,0 @@
 # strategy
 Start with `BUSINESS_PLAN.md`.
 - [`LAYERS-BEYOND-NAP.md`](./LAYERS-BEYOND-NAP.md) — base / extras / stacks; why owners care
		`@@ -1,3 +0,0 @@`
			`# docs (planning-rev2)`

			Session planning docs only. See repo root `README.md`.
		`@@ -1,3 +0,0 @@`
			`# product`

			Genre packs and Core 3 field map for this planning session. See `genre-packs.md`.