Appearance

Vertical discovery brief — Direct seller / independent distributor ​

SESSION INPUT RECEIVED 2026-08-14 — THE OWNER SUPPLIED THE AGENT OPERATING MODEL, AND IT FALSIFIED THE TWO LOAD-BEARING HYPOTHESES

The 2026-08-14 (morning) version of this brief was written with no direct-seller input at all and said so. That evidence gap is now partly closed: the owner supplied a detailed workflow brief describing how a Herbal Life agent actually operates (network structure, lead funnel, the Zoom session cadence, tooling). Corrections are marked ↺ CORRECTED below rather than silently rewritten, because the pattern in what the hypotheses got wrong is the finding: both major errors made the business smaller and quieter than it is. The brief guessed a solo reseller with no schedule and a purely warm funnel; the reality is a session-driven educator running a daily meeting cadence and paid social acquisition.

What this is NOT: a first-person distributor interview. The owner's brief is secondhand knowledge of a real operating model, and it is strong evidence for workflow questions. It is weak evidence for willingness-to-pay (§4.1) and for pain ranking in the merchant's own words (§1.3), both of which stay open. Status moves to 🟡 session complete; the owner flips the Status row when they judge the evidence sufficient, and check:release keeps refusing scope_frozen until then (QRS-475).

0 · Front matter ​

FieldValue
Industry keydirect_seller — see the naming note below. NOT herbalife. Already seeded in 20260808120000_v2_taxonomy.sql.
Archetypeexpertise ↺ CORRECTED — this brief said goods; the live taxonomy had already seeded expertise ("the card generates the enquiry, not the sale"), and the owner's brief confirms the schema: commerce completes off-platform, conversion is a conversation. See QRS-670.
Primitive compositionSeeded today: ['catalogue','party','recurrence','balance','fulfilment'] ↺ CORRECTED (this brief previously listed a different set that was never in the database). Proposed delta: ADD schedule — sessions are the core daily workflow (§1.4), and the seeded composition predates that knowledge. One-row migration, owner decision QRS-667.
User categories served1 solo owner (primary) · 2 enterprise — genuinely applies here, see §4.4 · 3 consumer (session participants, prospects)
ReleaseDesign in parallel now; implementation 26.0.2 at the earliest. It is not in 26.0.1 scope and must not enter it.
Status🟡 session complete — owner workflow brief received 2026-08-14; owner review outstanding
EvidenceOwner-authored agent workflow brief (2026-08-14, delivery log #30). Not a first-person distributor interview: willingness-to-pay and self-ranked pains remain open.

⚠ THE INDUSTRY KEY IS direct_seller, NOT herbalife, AND THIS IS NOT A STYLE PREFERENCE ​

Three independent reasons, any one of which is sufficient:

  1. It is a third-party trademark. "Herbalife" is a registered mark of Herbalife International. Shipping it as a database key means it appears in our schema, our API responses, our public URLs and our onboarding picker — asserting an affiliation we do not have. That is a legal exposure on the most public surface in the product, and it is free to avoid right now and expensive to unpick after the first thousand cards.
  2. It is the wrong scope, by a wide margin. The same business shape covers Amway, Oriflame, Modicare, Vestige, Tupperware, Avon and every future entrant. herbalife would force a second industry row per brand, each inheriting an identical composition — which is exactly the O(industries) growth the four-layer model exists to prevent (ADR-0020).
  3. This repo has swept generic-and-wrong naming out four times and every one was caught by a human reading a filename (cards, plans, primitives, templates — see CLAUDE.md's feature-scoped naming rule). This is the same error in the opposite direction: over-specific rather than over-generic. Renaming at the moment of introduction is one keystroke.

The brand is DATA, not an industry. A distributor's brand affiliation belongs on their own workspace/card record as content they enter — which is also the only place it can carry the disclaimer §5 requires.

1 · The business, in their words — answered 2026-08-14 from the owner's workflow brief ​

1.1 The shape of the business — confirmed, with one structural addition the hypotheses missed ​

The solo-owner hypothesis holds: an independent, relationship-driven, commission-based individual with no premises, no staff, no fixed hours, running the business from their phone. What the hypothesis missed entirely is that the agent is a node in a network, not an isolated merchant:

  • They registered through the brand's official process under an existing agent ("creating an ID under someone") and hold an official brand ID.
  • They work under a senior — called a coach, lead, senior, or upstream — who typically runs a team.
  • Coaches (often with medical or wellness backgrounds) run the education engine: regular wellness sessions the agent's prospects are invited into.

Design consequence: the agent's daily work is as much orchestrating participation in their upline's sessions as it is selling. A model that treats them as a standalone shopkeeper misses their actual day. Architecture consequence ↺ REVISED 2026-08-14 (owner decision: team is "along the way, not later"). Team COMMUNICATION is now in scope: a team roster (contacts with QR-Setu status and invite links), unified Groups serving both session audiences and chat rooms, and group conversations with an admins-only-post mode — which requires a group-rooms extension to the chat schema (today's conversations strictly pair a business with a consumer), logged as QRS-672. What stays with ADR-0022's member_owned tree exactly as §4.4 records: oversight — a team member's own customers, chats and volume are never visible to their upline through the communication module, and the team console + seat licensing remain the 26.1.0+ enterprise motion.

1.2 The brand's own channel — the §1.5 hypothesis CONFIRMED, and stronger than guessed ​

Purchases complete through the brand's official purchasing channel, delivered to the agent's or the customer's address per the official process; the agent earns commission per the brand's structure. The owner is explicit: QRSETU complements the official ecosystem and must not attempt to replace it.

  • ↺ CORRECTED (consequence): the previous capability mapping said "Take an order → orders, Take online payment → payments". Both are out of this vertical's loop. The commerce leg is off-platform; what the agent needs recorded is who bought what, when — the reorder-cycle substrate — which daily_sales-style manual records carry without an order pipeline or a payment provider. This also dissolves most of the taxonomy's own warning for this industry ("verify the payment aggregator's MLM position before enabling payments"): payments stay off at launch.

1.3 The pain, in the owner's words — sixteen points, four clusters ​

The owner enumerated sixteen operational pains. Ranked by the structure of the brief (self-ranking by a real agent is still open):

  1. Repetition — explaining the same information to every new prospect; re-typing product details; no single digital identity to hand over. "Repeating the same information again and again for every new person."
  2. Lead chaos — leads scattered across WhatsApp/Instagram/calls; manual registers (name, phone, source, status, conversation history, requirements, meeting participation, purchase interest, follow-up dates); enquiries from paid ads arriving into WhatsApp and getting buried: "Who contacted me → what they wanted → when I followed up → what I explained → whether they attended → whether they purchased → what next?"
  3. Meeting drudgery — the daily Zoom loop (§1.4): copy the meeting ID and passcode, forward the URL, send reminders, remember who was invited, track who attended, chase no-shows. Every day.
  4. Content scatter — product info spread across channels; educational YouTube links re-shared by hand; reusable promotional images with no organisation (the owner asks for tags explicitly); offline-session registration handled through Google Forms.

WhatsApp is the operating system for all of it — groups, broadcasts, status, coach comms, customer enquiries — which is precisely why important state gets buried in conversation scrollback.

1.4 The meeting workflow — the answer that mattered most ↺ CORRECTED ​

This brief previously said: "A schedule — No. No slots, no bookings. bookings is NOT in the composition." That is falsified in the strongest possible terms. The session cadence is the vertical's operational core:

  • ~90% of sessions are online, via Zoom, run by coaches; agents invite their prospects and customers in.
  • Daily yoga sessions exist where the Zoom link is shared only 10–15 minutes before start, through WhatsApp messages/groups/broadcasts — so every participant depends on a last-minute manual forward.
  • Offline sessions exist too, registered today through Google Forms.
  • The agent's repeated loop: receive meeting details from the coach → forward ID/passcode/URL to each invitee → send reminders → track who attended → follow up with absentees. The same thing, every day.

Two observations that shape the design:

  • The "link 10–15 minutes before" habit is a workaround, not a requirement. Links are shared late because a WhatsApp message goes stale the moment a meeting is rescheduled. A session record whose join screen fetches the current link at open (the same fetch-on-open shape the consumer OrderCode screen already uses for re-minted codes) dissolves the problem without any push infrastructure.
  • Recurring sessions are rules, not rows. "Yoga, daily, 7am" is one rule plus sparse exceptions — exactly the ADR-0016 reminders shape, with one inversion: reminders are user-owned; sessions are workspace-owned.

1.5 The funnel — §3.1's "entirely warm" hypothesis is HALF-CORRECTED ​

Agents run paid acquisition: Instagram ads, Facebook ads, YouTube ads, plus organic WhatsApp status and social content. What holds from the original hypothesis: nobody searches for a direct seller — there is still no discovery-by-browsing, so the consumer-marketplace exclusion (§3.1) stands. What changes: there is a real cold inbound stream (ad click → WhatsApp/DM enquiry) that today lands unstructured and gets missed. The capture question this raises is an architecture decision, not a design decision — see §3.1a and QRS-668.

1.6 Existing tools — confirmed ​

WhatsApp + notebook + spreadsheets/manual notes + Zoom + Google Forms + the brand's distributor portal. The brand portal is upstream supply only (confirmed): it serves the distributor's purchasing, not their customer-facing work. No customer-facing storefront collapse risk — the value hypothesis survives contact with the workflow.

1.7 Industry-specific verbs — confirmed and extended ​

reorder / refill (consumables on a monthly cycle) · join a session / attend · batch (a group of participants — the same word tutors and coaching institutes use) · follow up · coach / upline / downline / ID (network vocabulary) · join my team (recruitment — governance-gated, §5).

2 · Content types ​

Content typeNeeded?Shape / notes
PhotographsYesProduct shots, typically the brand's stock imagery. ⚠ Rights question for §5.
Reusable promo image libraryYes — NEW 2026-08-14The owner asks for stored, tagged, quickly-findable promotional images for statuses/ads. Maps to the asset primitive + the live media table (R2-backed); tags are net-new. QRS-669.
VideoYes — links, not uploadsEducational content lives on YouTube; the card and chat share links. No hosting cost, no upload pipeline. A card "video/education" section is already specified in the Public Setu Card Spec §3.3 and stays with that work.
A session scheduleYes ↺ CORRECTED — was "No"One-off and recurring sessions with join links (§1.4). The composition needs schedule added.
Before / after⚠ SPLIT 2026-08-14 (owner decision)PRIVATE before/after inside consumer-owned My Progress is IN (QRS-673) — the customer's own content, shared only via their grant. PUBLIC gallery on the card stays blocked behind the legal read + moderation: consent cannot unlock it, because the public form is an advertising-law exposure (the claim the image makes to viewers), not a privacy one (§5).
DocumentsMaybeBrand product fact sheets, FSSAI labels. Google-Forms offline registration is subsumed by the enquiry decision (§3.1a).
A published number that changesNoUnchanged: prices are stable and brand-set — no ADR-0027 rate-freshness problem.
Structured specsLightPack size, flavour, servings.
Long-form textYes"How this works", the distributor's own story — the About block carries the trust load in a warm channel.

The ADR-0019 D6 answer, updated: still no new block type in this slice — and two recorded candidates ​

The R1 card remains expressible with existing blocks. Two candidates now exist with genuine ≥2-industry cases, and both are deliberately deferred to the card's own spec rather than smuggled into this vertical:

  • A public "upcoming sessions" block — serves yoga_fitness (seeded with schedule, "batch timings"), tutor, and direct_seller. ⚠ Render the rule ("Daily · 7:00 am · Yoga"), never the next-occurrence countdown — a countdown is a render-time temporal gate, which every prior decision keeps away from the cached card (ADR-0025/0027). Needs a T9 field-reference widening and a public projection; that is schema work first.
  • A "video / education links" block — already in the Public Setu Card Spec's section floor ("Watch Anytime"); serves yoga, tutor, distributor.

The previously-recorded rejections stand: no per-visitor "reorder" block (breaks the edge cache), no "my team" block (needs ADR-0022's tree first).

3 · Acquisition and conversion ​

3.1 Cold discovery: "nobody searches" CONFIRMED — "entirely warm" ↺ CORRECTED ​

The marketplace exclusion stands: ItemFeed / VendorFeed / Browse serve a buyer who is looking, and this buyer still never is. Do not design a marketplace presence and do not count this vertical in marketplace inventory projections (QRS-490's premise error, still avoided).

But the funnel is not purely warm: agents buy Instagram/Facebook/YouTube ads and generate cold enquiries that arrive in WhatsApp and get buried (§1.5). The card is shared into conversations and pointed at by paid ads — which raises the capture question:

3.1a ⚠ THE ENQUIRY-CAPTURE DECISION — architecture-gated, do not send to Claude Design unresolved ​

The tension, stated honestly. On 2026-08-13 the product retired the enquiry/lead entity product-wide (QRS-650): "a buyer who scans a card MESSAGES, and that conversation IS the record" — the design's Enquiries.dc.html is banner-stamped SUPERSEDED, and ADR-0019 D7 commits the public card to carrying no visitor identifier of any kind. The owner's brief asks for exactly what was retired: "a dedicated Enquiry/Lead Form through the Setu Card" feeding a structured pipeline. Meanwhile the seeded taxonomy's own definition of this archetype reads "the card generates the enquiry, not the sale".

The honest reading: QRS-650 was decided in the Goods/marketplace context (a buyer at a stall's card), where chat-as-the-record is right. The Expertise context is different in kind: the visitor is cold, arrived from an ad, and will not create an account to ask a question — a signup wall in front of an ad click is the growth mechanic destroyed. Three options, argued in QRS-668, owner decision required:

  1. Chat-only (status quo). Zero new surface; the WhatsApp deep link remains the zero-friction path. Cost: reproduces the exact pain the owner described — the enquiry lands in WhatsApp and gets buried; QRSETU never sees it.
  2. An enquiry form block, scoped to the expertise archetype (direct_seller, real_estate, car_sales, tutor, electrician_plumber — the whole family lives on enquiries, so ADR-0019 D6's ≥2-industry bar is cleared several times over). A deliberate, consent-carrying form is not the passive tracking D7 bans, but it IS a public anonymous write path: it needs rate limiting, abuse handling, DPDP purpose/consent copy, and a moderation story. Partially reverses QRS-650 and must be recorded as such.
  3. Chat with a lowered sill for expertise cards (e.g. phone-first lightweight identity before first send). Touches the auth architecture (the phantom ADR-0018) — the most expensive option to get right.

Recommendation: option 2, scoped and fail-closed — an enquiry lands as a lead row (a party with source), notifies the agent, and the conversation still happens wherever the agent takes it. Option 1 is the honest fallback if the owner wants zero QRS-650 reversal in 26.0.2.

✅ DECIDED BY THE OWNER 2026-08-14: option 2. The enquiry form block ships, scoped to the expertise archetype, landing as a lead with source "card enquiry" — the partial QRS-650 reversal is now recorded fact, and the ADR that writes up the lead/party model must state the D7 boundary (a deliberate, consent-carrying form is not the passive tracking ADR-0019 D7 bans). The six-stage lead vocabulary was confirmed in the same message.

3.2–3.6 — unchanged, with one addition ​

Why they share: the card replaces the sales conversation they find uncomfortable (confirmed by the owner's framing: prospects browse without being pitched, and the agent stops re-explaining). Forwarding: customer → new customer, distinct from the §4.4 recruit path. Where the card replaces manual work: the re-typed product list, the reorder nudge, and now the session invite loop (§1.4). Referral path: structurally upline → downline, unchanged. CTA placement: post-action confirmation and the share sheet, never the hero.

4 · Monetization ​

  1. What would they pay for? ⚠ Still ask; do not model — willingness-to-pay remains unmeasured (the one evidence class the owner's brief cannot supply). Updated hypothesis: the daily-pain solver is now the sessions + follow-up loop, ahead of the reorder tracker: it is the workflow they repeat most and resent most.

  2. Which capability is the paywall? Candidate feature_codes: the sessions module above a free ceiling (e.g. one active batch free), the recurrence-backed reorder tracker, and campaign assets shared down a team. Named as codes, never as a tier word (ADR-0007).

  3. Transaction revenue: none. ↺ Sharpened from "weaker than a stall": the commerce leg is entirely off-platform (§1.2). Counting this vertical's GMV as commissionable would be an unforced error; its revenue is subscription only.

  4. ⚠ 4.4 THE SECOND BUYER IS REAL, AND IT IS THE BUSINESS OPPORTUNITY IN THIS VERTICAL ​

    Raising it unprompted per the standing instruction, and arguing it rather than pitching it.

    The motion: an upline with a downline of 30 buys and pays for their team's seats — better tooling for the team means more team volume, which is literally how the upline is compensated. So the buyer's incentive is already aligned with ours, without us building anything to align it. The owner's brief strengthens this: the coach already runs the sessions the whole downline attends, so the coach is the natural first buyer of the sessions module — one coach adopting it makes every downline agent a participant, and every participant a prospective merchant. That is the adoption loop the owner describes ("one agent → other agents discover → more registrations"), grounded in an artifact we actually build.

    Why this is nearly free architecturally: ADR-0022 already models it and already names this exact case. workspaces form a tree, seats license USERS not workspaces (QRS-397), and ownership_model distinguishes org_owned from member_owned. The MLM case is member_owned, and the distinction is the entire deal: a dealership owns its rep's card and revokes it when the rep leaves; an upline pays for the distributor's seat but the distributor owns their own card and keeps it — they are an independent business owner and that card is their brand. Collapsing the two into one organization_id either makes this vertical unservable or takes a distributor's business away when they change teams.

    The weakest link, stated: an upline is not a company. There is no procurement, no signed MSA, no finance department — and also no credit-checked entity. Payment failure and seat churn would be far higher than a dealership's, and a seat revoked mid-month strands a real business. Which existing decision this strains: ADR-0022's oversight rules. An upline is not an employer, so subtree oversight must NOT apply to member_owned descendants — an upline seeing their downline's customer list and chat history would be a privacy breach of a third party's business, and ADR-0022's "oversight applies only to org_owned descendants" is what already prevents it. That constraint must be re-read before anyone builds a team view.

    Sequencing: this is a 26.1.0+ conversation at the earliest. Recording it is free; building toward an unvalidated enterprise motion pre-launch is how the prototype acquired an Ad Manager.

  5. Store-compliance check: any upsell converts on web or email, never in-app (Apple 3.1.3(d), ADR-0002).

5 · Governance and verification — ⚠ THE HIGHEST-RISK VERTICAL EVALUATED SO FAR ​

Per ADR-0026, verification gates capabilities, never signup. For most industries the answer is "nothing required". It is not "nothing" here, and this section is the reason this brief was worth writing before any design work rather than after.

5.1 Two claim classes we would be the PUBLISHER of ​

  1. ⚠ INCOME AND EARNINGS CLAIMS. India's Consumer Protection (Direct Selling) Rules 2021 restrict income representations by direct sellers, and the FTC-style "typical results" problem is well documented globally. A distributor writing "earn ₹50,000 a month from home" on qrsetu.com/<their-slug> makes QRSETU the platform hosting that claim. This is not hypothetical: it is the single most common direct-selling marketing message that exists.
  2. ⚠ HEALTH AND THERAPEUTIC CLAIMS. These are food supplements under FSSAI. "Cures diabetes", "reverses PCOS", "lose 10kg in a month" on a card we render and cache at the edge is a regulatory exposure and a real-harm exposure at the same time. Before/after transformation imagery (§2) is the visual form of exactly this claim, which is why it is deferred rather than designed. NEW 2026-08-14: the same constraint now extends to session titles and descriptions — sessions are run by coaches with medical framing, and a hosted session titled "diabetes reversal workshop" is the same claim class in a new surface. Session copy must be held to the descriptive-never-therapeutic bar.

5.2 What follows, concretely ​

  • This is the first genuine user of compliance_profile / ad_restricted — the column ADR-0004 records as not existing (QRS-086) and the reason resolvePromo fails closed forever in R1. A direct-seller card must not carry a third-party ad, and it needs its own content constraints besides.
  • A required, non-removable disclaimer block is the likely answer for the card, plus the brand-affiliation line from §0. That is a config variant of an existing text block with a removable: false flag — worth checking whether the manifest schema can express "the merchant may not delete this block", because today it probably cannot.
  • NEW 2026-08-14 — the brand-affiliation display question. The owner's brief lists "Herbal Life ID / reference information where appropriate and legally permissible" as card content. That qualifier is doing a lot of work: most direct-selling brands (Herbalife included) have their own distributor marketing policies constraining what an agent may publish on third-party sites. The legal read below must cover the brand's policy exposure as well as the statutory one — an agent violating their brand's policy on our surface is churn and reputational risk.
  • Moderation and takedown must exist before this vertical is public. Under open self-serve the only current takedown mechanism is hand-written SQL against Prod (R2 in the release plan). A vertical whose native marketing form is a regulated claim cannot be the one that tests that.
  • ⚠ This needs a legal read, and the design must not route around the answer. Named here per the template's own instruction. Do not send the disclaimer wording to Claude Design — that is an architecture-and-legal-gated question, and CLAUDE.md forbids sending those as design prompts.

6 · Divergence seams (required at G0) ​

Updated 2026-08-14: the sessions workflow adds four seams the original table did not carry.

SeamDirect sellerVersus Ganapati
Camera / QR scanNot needed for the money loop. No Scan-to-collect: handover is in person between people who know each other.Ganapati's ScanCollect is load-bearing
Push⚠ Remote push DOES NOT EXIST in R1 by explicit decision (entitlement stripped, no token table — QRS-234). Session reminders are local notifications scheduled on acceptance, reusing the reminders NotificationPort machinery. A rescheduled session cannot push; the join screen fetches current state on open instead (§1.4).same constraint, newly load-bearing here
Local notification budgetNEW. iOS hard-caps 64 pending notifications per app. A daily recurring session naively scheduled a month out consumes half the budget for ONE batch. Schedule a short horizon and reconcile on open — the exact ADR-0016 budget/reconciler pattern, now shared between reminders and sessions.reminders-only today
Join-link deep linkNEW. "Join" opens the Zoom (or any) URL: Android/iOS hand off to the meeting app or browser; RNW opens a tab. Per-surface behaviour to verify, same class as expo-web-browser fidelity preview.not present
Device calendar↺ REVISED TWICE 2026-08-14 — final: NO OS-calendar integration of any kind (owner instruction: the user stays inside QR Setu). The in-app calendar on both halves plus local notifications is the whole scheduling experience; the earlier calendar-file-share concession is removed too. The seam disappears.not present
Storage / filesystemProduct photos + the tagged promo library (§2) — R2-backed media, credentials pending (QRS-306)same but heavier than guessed
ShareLoad-bearing. The whole channel is a shared link; now also session invitesmore important
ClipboardCard address copy; join-link copysame
Deep linksCard → app; session invite → join screenextended
OfflineSame as everywhere: NetInfo banner, already built. Join screen degrades to showing the stored linksame

7 · Proactive-value answer ​

⚠ This vertical has the strongest proactive-value answer of any evaluated, and the owner's brief added a second engine to it.

  • The reorder engine (unchanged): "Priya's last pack was 27 days ago. Message her." Consumables run a 25–30 day cycle and direct-selling compensation is volume-banded and resets every calendar month, so a reorder captured on the 29th is worth materially more than the same reorder on the 2nd. Intelligence source: the recurrence primitive (ADR-0016) plus the sale records. No new derivation engine.
  • The session engine (NEW): "Tonight's batch has 12 confirmed, 5 invited who have not responded." and, after: "3 people missed yesterday's session. Follow up." What makes it timely: sessions are dated facts with a hard start time, and the follow-up window (the owner is explicit) is the day after. Intelligence source: the session schedule and participation records — stored rows, never scores. With no data the surface is absent, not a placeholder.
  • ⚠ The anti-noise ceiling applies hardest here, twice over. A distributor nudged to chase 30 customers becomes a person sending 30 unwanted messages, and their customers churn. In-app action items, batched, never a push per customer — and never a per-participant nudge either: one card per session, not N.

8 · Part 2 — capability mapping (updated 2026-08-14 against the live schema) ​

⚠ The reuse score below is measured against what is live in migrations today, which the previous version of this table was not (QRS-670): party and schedule are seeded primitives with zero table substrate — lead, participant, batch member and attendee all lack a counterparty row to hang off, and no scheduling table of any kind exists.

Workflow (their words)Existing capabilityNew capability neededGeneralises to ≥2 other industries?
Show my products and pricesstore + setu_card (+ pricing_mode: on_enquiry, live)——
Hand over one link instead of re-explainingsetu_card——
Reply to customerschat (8 live tables; ⚠ writes stub-bound, no chat EF — known gap)——
Record who bought what, whendaily_sales-style manual record——
Know who is due to reorderreminders recurrence enginethin reorder_cycle config over itYes — pharmacy refills, dairy, salon top-ups. ≥3.
Run sessions and batches ↺ NEW—sessions module: schedule+recurrence+party, rule+exceptions shape (ADR-0016 mirror, workspace-owned), join link, fetch-on-openYes — yoga_fitness (seeded with schedule, "batch timings"), tutor, coaching/consultants. ≥3, comfortably. QRS-667
Invite, remind, see who attended ↺ NEWlocal-notification machinery (reminders)participation records + join-tap attendance (lite, honestly labelled)Yes — same family
Track prospects through stages ↺ NEW—lead pipeline over a new party substrate + stage vocabulary + follow-up dateYes — real_estate, car_sales, photographer. ≥3. QRS-668
Capture ad enquiries ↺ NEW—⚠ owner decision (§3.1a): form block vs chat-onlyYes — the whole expertise family
Find my promo images fast ↺ NEWmedia table + R2 presigner (live, credentials pending)tags + library UI (assets feature key already seeded)Yes — every industry reuses promo media. QRS-669
Share brand video with my teamcampaigns (ADR-0025)—Yes
Know where I stand this monthanalytics⚠ no live event writer yet (known, QRS-352)—
Coordinate with my team ↺ REVISED (owner decision 2026-08-14)chat (extended)team roster + unified Groups + group-room conversations (QRS-672) — a real chat-schema extension. Oversight, volume roll-ups and seats stay tree-gated (§4.4)Yes — salon, kirana, coaching-institute staff. ≥3.
Track and share progress ↺ REVISED (owner decision 2026-08-14)—consumer-owned My Progress (QRS-673): the CUSTOMER records, owns and shares via a revocable grant; agent-entered health fields stay out everywhereYes — yoga_fitness, dietitians/fitness coaches, tutors. ≥3.

Updated score (after the 2026-08-14 owner decisions): 6 of 14 workflows reuse an existing capability unchanged; 1 is a config variant of recurrence; 6 need genuinely new substrate (one party table, the meetings module, the group-rooms chat extension and consumer-owned progress between them); 1 is an owner decision still open (enquiry capture). The previous "7 of 10 unchanged" framing overstated reuse because it counted orders/payments rows this vertical does not use and did not know about the sessions workflow at all; the owner's correction rounds then pulled team communication and progress tracking into scope, so the new-substrate count is honest, not padded. The four-layer model still holds — every new piece generalises to ≥3 industries, so the cost lands in platform modules, not in this industry.

⚠ No new PRIMITIVE is proposed — schedule, party and asset are all already seeded; what is missing is their table substrate, which was always going to be built by their first consuming feature. No new block type is proposed in this slice (§2's two candidates are recorded and deferred to the card spec).

9 · Sign-off ​

Session held🟡 owner-authored workflow brief received 2026-08-14 — not a first-person distributor interview; willingness-to-pay (§4.1) and self-ranked pains (§1.3) remain open
Capability mapping complete✅ re-derived 2026-08-14 against live migrations (§8)
New primitives proposednone — schedule/party/asset are seeded; their substrate is feature work
New block types proposednone in this slice — two candidates recorded with D6 cases, deferred to the Public Setu Card Spec
Open decisions for the owner(1) Approve this brief (flip the Status row) — gates the release scope-freeze, not the design work. (2) Legal read, now narrowed (§5.2): disclaimer wording · brand-affiliation display policy · DPDP implementation duties for My Progress (QRS-673) · the PUBLIC before/after question — before any public direct-seller card. (3) Whether member_owned seat licensing is worth a 26.1.0 slot (§4.4). DECIDED 2026-08-14 by the owner: enquiry form block scoped to expertise, landing as a lead (QRS-668, §3.1a) · six-stage lead vocabulary with follow-up as a date · sessions module + schedule composition change (QRS-667) · Zoom bring-your-own-link built first, Connect designed now · in-app-only calendar (no OS hand-off, §6) · team roster + Groups + group chat along the way (QRS-672) · consumer-owned My Progress with private before/after (QRS-673) · the nine-item engagement layer committed to R1 of this work (QRS-674).
Tracker rows raisedQRS-665 · QRS-667 · QRS-668 · QRS-669 · QRS-670 · QRS-671 · QRS-672 · QRS-673