diff --git a/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md b/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md
index aab7bfb..13a6257 100644
--- a/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md
+++ b/docs/SELF_SERVE_AI_DISCOVERABILITY_CONCEPT.md
@@ -94,22 +94,47 @@ Umbrella aggregators and end-user platforms are **not** the same job. Architectu
 - **Lane A — umbrella submissions.** Write once into Data Axle, Localeze / TransUnion, and Foursquare’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, Apple, Bing, Yelp, 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 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. This is what we have to architect — not a shipped checklist.
+Umbrella-only leaves the Core 3 and Yelp 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** — Claim hub and richest Core 3 surface; usually the strongest owner-facing source of truth. Owner claims the listing and fixes NAP (and categories) in the GBP dashboard; we treat that claim as proof on other tickets.
-2. **Apple Business Connect** — Second Core 3 leg; place cards on Apple Maps and related Apple surfaces. Owner claims and corrects NAP / hours / categories in Business Connect (or via a partner that writes that API).
-3. **Bing Places** — Third Core 3 leg; feeds Bing local and Copilot-adjacent experiences. Owner claims in Bing Places and files corrections through Bing Places feedback / update flows with the same field / wrong / right / proof ticket.
-4. **Foursquare Places** — Umbrella **and** its own POI graph (Lane A + B). Prefer Placemaker `POST /places/{id}/suggest/edit`, or white-label the same path via Managed Users when we file on the owner’s behalf.
-5. **Yelp** — Strong consumer destination and historical source into maps / directories. Lane B: suggest-an-edit form with field, wrong value, right value, and GBP as proof.
-6. **Data Axle Local Listings** — Primary umbrella into many publishers (Lane A). Claim / submit via Data Axle Local Listings or Local Listings Premium so corrections propagate instead of hand-fixing every long-tail directory.
-7. **Localeze / TransUnion Digital Business Profile** — Second umbrella into 80–100+ publishers (Lane A). Claim once, verify the profile, then watch propagation rather than chasing each downstream site.
-8. **YP / Thryv** — Yellow-pages stack that is both source and sink for long-tail directories. Claim and correct through YP / Thryv listing management when the audit shows drift there.
-9. **Tripadvisor** — Vertical travel / food graph that assistants and maps sometimes cite. Claim and correct via Tripadvisor’s business tools when the genre makes that surface matter.
-10. **Facebook / Meta** — Own Pages graph; weak as a classic NAP aggregator. Claim the Page and fix info / address / hours there; usually lower weight than Core 3 + umbrellas for Presence.
-11. **MapQuest / HERE / in-car nav / long-tail directories** — Heavy aggregator consumers with weak owner claim surfaces. Prefer Lane A umbrella tickets; open a direct ticket only when a real correction form exists and the audit still shows a miss after umbrellas settle.
-12. **Dun & Bradstreet** — B2B firmographics, not consumer local discovery. Low priority unless a specific B2B recommendability path needs it.
-13. **CityGrid** — Legacy network. Only open a ticket if the audit actually surfaces a CityGrid-fed copy still stomping the claim.
-14. **Yext / Uberall / BrightLocal (and similar)** — Pipes, not aggregators. If the client already pays one, route corrections through that pipe into Lanes A and B instead of inventing a parallel write; do not treat the pipe as a Presence destination of its own.
+1. **Google Business Profile** (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** (Lane B — Core 3). Sign in to Apple Business Connect, 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** (Lane B — Core 3). Sign in at the Bing Places 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** (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 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** (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 reviews manually. Wait days to weeks. **Success:** the Yelp page shows the corrected field and stops contradicting the claim.
+
+6. **Data Axle Local Listings** (Lane A). Claim the business at the Data Axle Local Listings portal with a business email and / or ownership docs. Edit NAP (and hours) once in that central record. Wait for Data Axle’s verification and syndication batch — hours to ~two weeks for hard cases. **Success:** the Local Listings record matches the claim; long-tail / nav partners that consume Data Axle begin reflecting the update on their next pull.
+
+7. **Localeze / TransUnion Digital Business Profile** (Lane A). Claim at the TransUnion / Localeze 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** (Lane B, feeds long-tail). Claim via YP / Thryv 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** (Lane B — vertical). Claim via Tripadvisor for Business, open the field, submit the correction for review. Wait for their moderation. **Success:** the Tripadvisor listing matches the claim when travel / food recommendability cares about that surface.
+
+10. **Facebook / Meta** (Lane B — low weight). In Meta Business Suite, 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 / HERE / in-car nav / long-tail directories** (Lane A by default). There is usually **no** owner correction form. Path: file umbrella tickets (Data Axle, Localeze, Foursquare) 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** — 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** — Legacy. Only if the audit surfaces a CityGrid-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 / Uberall / BrightLocal (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 stale, Data Axle 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** — 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** — 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” links.
 
 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.