docs/maker-platform-strategy.md

@@ -236,7 +236,7 @@ Two rules ride on the classification:
 - **Buyer transparency is the point.** Every item shows its provenance badge — the consumer-facing expression of the moat: not merely "this maker is verified," but "this *item* is original / partly original / a resale / not original (and contains these makers' work)." It is the precise anti-Etsy signal — you always know what you're buying — and it *appreciates* as AI-generated and drop-shipped fakes proliferate.
 - **Trust-surface eligibility keys off it, per item.** Only **original** and **original-+-(in-network)-components** items are surfaced as the maker's original work in Curated-By / buyer feed / agent feed. A **fellow-Maker resale** may surface *attributed to the true maker* (that *is* Curated-By). **Third-party resale never enters a trust surface** — surfacing it would launder non-original goods through a trusted face (the Etsy-pollution failure mode, from the inside). A composite that contains any non-original component is flagged as such wherever it appears.
 
-The hard, still-open part is the **line between making and reselling** — finishing, assembling, and kitting sit in between (the standard to write, §12 #8): purchased supplies don't taint "original," but assembling mostly-third-party parts isn't original either. Misclassifying a resale as "original" is a provenance lie → a verification-revocation trigger (trust & safety, §10). Self-attestation makes classifying cheap; the sampling audit plus buyer reporting make gaming it risky.
+The hard, still-open part is the **line between making and reselling** — finishing, assembling, and kitting sit in between (the standard to write, §12 #6): purchased supplies don't taint "original," but assembling mostly-third-party parts isn't original either. Misclassifying a resale as "original" is a provenance lie → a verification-revocation trigger (trust & safety, §10). Self-attestation makes classifying cheap; the sampling audit plus buyer reporting make gaming it risky.
 
 ### Non-maker referrers: the verified taste-maker tier (Phase 2)
 
@@ -268,7 +268,7 @@ A consumer surface (site/app + email) where buyers see followed makers' drops, "
 
 **The canonical catalog index lives in the network service — not a Medusa "mega-store."** Every maker's catalog (Shopify via Admin API, your Medusa storefronts via their API, anything else via adapters) is transformed into one normalized, verified index that powers Curated-By, the feed, and agents. A Medusa instance is a *storefront* (cart, checkout, one MoR, sellable inventory); the network catalog is a read-optimized *index* of products that live and sell elsewhere. Pouring all makers into one Medusa instance would make a thing shaped like a store that must never behave like one, and couple the neutral network to one engine. Keep each storefront as the system of record; the network holds a normalized verified *projection* — which also keeps Shopify and Medusa products *co-equal sources*, not Shopify imports into a competitor-shaped container.
 
-**Cross-merchant order transparency — the positive-sum twin of the money-flow "no."** Because the network already sees every maker's orders (it must, to compute referrals) and knows which products contain other makers' components (the catalog metadata layer), it can hand each maker something no single-store tool can: **visibility into every order that touches their work anywhere in the network** — their item sold inside another maker's kit, a referral they sent that converted, a component of theirs moving through a partner's store. This is the grocery **scan-based / Direct-Store-Delivery** pattern: the supplier sees the sell-through and knows when to restock or re-engage, *without being the store*. It costs the network nothing to give (it already holds the data), it is **uniquely the network's to give** (only the cross-tenant vantage sees across stores — which deepens the moat), and it stays firmly on the right side of the line: **transparency and coordination are free; custody is not** (the kit-supplier notification in Appendix C.2 is one instance). One asset, three uses — the same order history powers the referral ledger, the network-health metrics (§12 #4), and this reporting.
+**Cross-merchant order transparency — the positive-sum twin of the money-flow "no."** Because the network already sees every maker's orders (it must, to compute referrals) and knows which products contain other makers' components (the catalog metadata layer), it can hand each maker something no single-store tool can: **visibility into every order that touches their work anywhere in the network** — their item sold inside another maker's kit, a referral they sent that converted, a component of theirs moving through a partner's store. This is the grocery **scan-based / Direct-Store-Delivery** pattern: the supplier sees the sell-through and knows when to restock or re-engage, *without being the store*. It costs the network nothing to give (it already holds the data), it is **uniquely the network's to give** (only the cross-tenant vantage sees across stores — which deepens the moat), and it stays firmly on the right side of the line: **transparency and coordination are free; custody is not** (the kit-supplier notification in Appendix C.2 is one instance). One asset, three uses — the same order history powers the referral ledger, the network-health metrics (§12 #2), and this reporting.
 
 **Build the white-label storefront on a headless backend (Medusa recommended).** "Build the 20%, rent the 80%" in code: the headless backend (Medusa — Node/TS, modular, payment-agnostic, no per-order revenue share; alternatives Saleor, Vendure, Spree) supplies cart, catalog, orders, customers, fulfillment, BYO payment, and you add the commitment-commerce engine — **drops, pre-orders, clubs, raffle/queue — as custom backend modules.** Mental model: in Medusa, *modules are backend domain logic; the storefront is a separate frontend app* consuming the Store API. So **the storefront is not a module** — the commitment-commerce *features* are modules, the storefront is their client, and the network service above is neither (standalone). Multi-tenancy (one shared instance vs. per-maker instances) is decoupled from the moat because the network service is separate either way; for two pilots, a single instance + shared theme is plenty.
 
@@ -369,7 +369,7 @@ The **shape** below is settled; the **reputation engine itself is explicitly OHM
 
 ### Authority & appeal
 
-- **The inviter holds primary suspend/expel authority** over their own sub-graph — the person who vouched is the person best placed, and most motivated (their standing is on the line), to act. Layered on top: a **platform floor for active buyer harm** (the platform can act directly when buyers are being harmed, regardless of what an inviter does), and a **governance appeal path** (§12 #7) for the maker who believes a consequence was unjust. **Expulsion is the rare extreme**, reserved for active harm — the default consequence is loss of standing, above.
+- **The inviter holds primary suspend/expel authority** over their own sub-graph — the person who vouched is the person best placed, and most motivated (their standing is on the line), to act. Layered on top: a **platform floor for active buyer harm** (the platform can act directly when buyers are being harmed, regardless of what an inviter does), and a **governance appeal path** (§12 #5) for the maker who believes a consequence was unjust. **Expulsion is the rare extreme**, reserved for active harm — the default consequence is loss of standing, above.
 - **Provenance lies are trust violations.** Misclassifying a resale as "original" (§7 per-item provenance) is not a clerical error — it is a deception that pollutes the trust surfaces, and so it is a verification-revocation trigger handled by this machinery.
 - **The legal spine of the ghosting case is in §11.** Non-delivery isn't only a reputation event: the FTC 30-Day Rule (§11, "Consumer protection / FTC") is what a ghosting maker is *violating*, and the platform's compliance-by-design notice/refund UX is the buyer's first recourse *before* a chargeback against the maker's processor. Reputation consequence and legal recourse are two responses to the same act.
 
@@ -460,23 +460,19 @@ Recap the §7 consent architecture, now read as the privacy-law posture.
 
 ## 12. Open sections to develop (backlog)
 
-This memo is deep on the architectural/strategic axes (money flow, network mechanics, moat theory, consent) and thin on several operational ones that matter as much or more. The gaps cluster on the un-fun, operational side — which is usually where ventures actually die. Each below is a separate future session. Rough priority order; recommended next is #1.
+This memo is deep on the architectural/strategic axes (money flow, network mechanics, moat theory, consent) and thin on several operational ones that matter as much or more. The gaps cluster on the un-fun, operational side — which is usually where ventures actually die. Each below is a separate future session. (Trust & safety and legal & compliance were written up this session — now §10 and §11 — and have left the backlog.) Rough priority order; the **recommended next session** is finishing §10's open reputation-engine work (gathered in that section's last subsection), then #1 below.
 
-1. **Trust & safety / maker accountability — shape written up this session (now §10); reputation *engine* remains OHM-guided open work.** The settled shape — originating-edge invitation graph, reputation flowing *up* that edge (decayed, hop-capped), consequence = a low buyer-visible score + loss of network benefit rather than expulsion, inviter-held authority with a platform floor and a governance appeal path — is now **§10 (Trust & safety & maker accountability)**. What stays open is gathered in §10's last subsection and is the **recommended next session**: the OHM-guided reputation *engine* (scoring, coefficient/hop-cap values, standing accrual, display, benefit-gating thresholds, operationalizing *harm*/*recourse*), plus verification-revocation triggers/process, the buyer-harm/dispute framework, non-delivery handling out-of-flow (chargeback-via-maker-MoR + transparency, not guarantor), and false-report/collusion controls.
+1. **Demand strategy / buyer-side go-to-market — the keystone, currently only *admitted* as a risk.** The doc names "demand is the unvalidated keystone" repeatedly but never attempts a plan; everything concrete is supply-side. Needs: a crisp *buyer-side* value proposition (why a buyer shows up and comes back, stated as its own thing); a first-100 / first-1,000-buyers plan; a content/community/SEO posture for the buyer side; and a §8 extension that tests buyer demand, not just supply. Naming the risk ≠ grappling with it.
 
-2. **Demand strategy / buyer-side go-to-market — the keystone, currently only *admitted* as a risk.** The doc names "demand is the unvalidated keystone" repeatedly but never attempts a plan; everything concrete is supply-side. Needs: a crisp *buyer-side* value proposition (why a buyer shows up and comes back, stated as its own thing); a first-100 / first-1,000-buyers plan; a content/community/SEO posture for the buyer side; and a §8 extension that tests buyer demand, not just supply. Naming the risk ≠ grappling with it.
+2. **Sustainability economics & health metrics — there are no numbers anywhere.** "Non-profit" doesn't mean "needn't cover its costs." Needs: a back-of-envelope unit-economics model (does referral take + network subscription cover the network service + verification labor + hosting at N makers / X GMV?); and a North Star + network-health/liquidity metrics (% of GMV that's cross-maker-referred, follower growth, drop sell-through, repeat-buyer rate). The §9 gates are all qualitative.
 
-3. **Legal & compliance, consolidated — done this session (now §11).** The scattered legal points are consolidated in **§11 (Legal & compliance)**, with the out-of-money-flow stance framed as the legal strategy itself: MTL recap, the marketplace-facilitator sales-tax analysis (the centerpiece — two-part conjunctive test, the referral exclusion, the "indirectly collects" edge, the Phase-3 / split-payment-kit / Connect danger zones, and tax-calc as the storefront's job), the Connect-config legal posture (cross-ref §7), raffle/lottery (engineer out *consideration*), FTC / consumer-protection (affiliate disclosure, the pre-order 30-day rule, handmade-claim substantiation), privacy / DPAs, freedom-to-operate, the restored novelty finding, and the entity / UBIT flag.
+3. **Concrete MVP scope / build roadmap.** The phasing is *conceptual* (Phase 1/2/2+/3); there's no literal "v1 ships these features, in this order." Given volunteer capacity is the stated single point of failure, scope discipline is existential — define the minimum lovable build.
 
-4. **Sustainability economics & health metrics — there are no numbers anywhere.** "Non-profit" doesn't mean "needn't cover its costs." Needs: a back-of-envelope unit-economics model (does referral take + network subscription cover the network service + verification labor + hosting at N makers / X GMV?); and a North Star + network-health/liquidity metrics (% of GMV that's cross-maker-referred, follower growth, drop sell-through, repeat-buyer rate). The §9 gates are all qualitative.
+4. **The data model (sketch the entities).** Named as the load-bearing portable asset ("cheap now, expensive to retrofit") and referenced everywhere (canonical catalog index, variant/kit BOM, referral ledger, consent records, verification graph, follow graph) but never drawn. Deserves at least an entity diagram. (May already exist in prior schema work — if so, this is a pointer, not net-new.)
 
-5. **Concrete MVP scope / build roadmap.** The phasing is *conceptual* (Phase 1/2/2+/3); there's no literal "v1 ships these features, in this order." Given volunteer capacity is the stated single point of failure, scope discipline is existential — define the minimum lovable build.
+5. **Governance, concretely.** The non-profit's trust rests on governance that's been floated ("open governance / maker council") but never specified: who sets and changes verification standards, board/maker representation, and how disputes about *the network itself* resolve.
 
-6. **The data model (sketch the entities).** Named as the load-bearing portable asset ("cheap now, expensive to retrofit") and referenced everywhere (canonical catalog index, variant/kit BOM, referral ledger, consent records, verification graph, follow graph) but never drawn. Deserves at least an entity diagram. (May already exist in prior schema work — if so, this is a pointer, not net-new.)
-
-7. **Governance, concretely.** The non-profit's trust rests on governance that's been floated ("open governance / maker council") but never specified: who sets and changes verification standards, board/maker representation, and how disputes about *the network itself* resolve.
-
-8. **Hybrid makers — the making-vs-reselling line (standard).** *Direction set:* provenance attaches **per-item, not per-maker**, via a self-attested, buyer-facing catalog classification (Original / Original + components / Resale – fellow Maker / Resale – third-party), with trust-surface eligibility keyed to it — see §7 "Per-item provenance: the catalog's originality layer." *Still open:* the precise, **auditable line between making and reselling** — purchased supplies don't taint "original," but where exactly do finishing, assembling, and kitting fall? — plus the enforcement/audit hook (ties to #1 accountability) and the exact buyer-facing label wording. Interacts with the consignment/resale "avoid" fork (§7) and the no-walled-garden value rule (Appendix D).
+6. **Hybrid makers — the making-vs-reselling line (standard).** *Direction set:* provenance attaches **per-item, not per-maker**, via a self-attested, buyer-facing catalog classification (Original / Original + components / Resale – fellow Maker / Resale – third-party), with trust-surface eligibility keyed to it — see §7 "Per-item provenance: the catalog's originality layer." *Still open:* the precise, **auditable line between making and reselling** — purchased supplies don't taint "original," but where exactly do finishing, assembling, and kitting fall? — plus the enforcement/audit hook (ties to §10 accountability) and the exact buyer-facing label wording. Interacts with the consignment/resale "avoid" fork (§7) and the no-walled-garden value rule (Appendix D).
 
 ---