docs/maker-platform-strategy.md

@@ -298,6 +298,13 @@ Now that Medusa exists and the network federates over any storefront, *centering
 
 **Partner / consultant network.** Implementation consultants (community-embedded especially) onboard the **high-touch tail** without you becoming a services business, doubling as community-aligned distribution and mirroring the partner ecosystems that grew Shopify and Medusa — a second flywheel you *enable* (certification, partner referral fees, a directory) but don't *staff*. Guardrails: keep the product **genuinely self-serve for the median maker** (if makers *need* a consultant for a basic store, the product failed and partners are masking it), and structure partners as **referral/implementation partners, not white-label resellers**, so they don't become the relationship-owner and disintermediate you.
 
+**Partner compensation — a negotiated, tapering share of the maker's *earned* referral income.** A maker may opt to bring on a partner to stand up their storefront and onboard them onto the referral network, and pay for that help out of the upside it creates: the partner earns a **share of the referral income the maker earns *as a curator*** (the 10–12% Curated-By credits in "Referral economics" above) — not a fee on the maker's sales, and not a cut of the platform's spread. The natural shape is **front-loaded and tapering** — e.g. 100% of the maker's first $X in referral earnings to the partner, then a declining share as the maker's curation takes off — a *help-me-start, earn-out* deal, not a perpetual tax. The two negotiate and structure the schedule through **platform tooling**; the network stores the agreed terms and settles the split. This rides the same invariants as the rest of the money model, so it adds posture, not exposure:
+
+- **Out of the flow, principal on both sides.** The platform never routes the maker's money to the partner (that is custody / transmission — Appendix C.2's line); it independently *reduces* the maker's referral credit and *extends* the partner a credit or payout — two events, principal on each, never a conduit (the §7 referral-economics pattern).
+- **A fourth consumer of the one Phase-2 cashable rail.** The maker's referral credit is non-cashable (fee-offset); a partner who isn't itself a maker has no platform fees to offset, so — exactly like the verified taste-maker and the kit pure-supplier — it needs *cashable* payout over the same scoped Connect/mass-pay crossing Phase 2 already builds. (A partner who *is* a maker can take non-cashable wallet credit instead.) One more rider on that crossing, not new money plumbing; Phase 1 can accrue the partner's split as *pending* and pay it on rail launch.
+- **The negotiation tooling is the ledger pattern already required.** "Partner P takes schedule S of maker A's referral earnings, tiered by cumulative $" is **stateful settlement on a running total** — the same machinery as the wholesale volume tiers (Appendix C.5): the schedule is a stored term, settlement is cumulative (not per-order-independent), and the retroactive-vs-prospective question at a tier boundary is a term the two agree and the platform applies. Build the ledger for cumulative partner splits from the start.
+- **The curation-integrity guardrail still binds.** The partner shares the maker's *earned* income but gets **no say in *whom* the maker vouches for** — otherwise a partner would push the maker toward whatever converts, reintroducing the commission-corruption drift the whole referral design resists (§3; "Curated By This Maker"). Disclosure applies where a partner relationship would read to buyers as paid placement (FTC, §11). The deal is comp for *activation*, not influence over *taste*.
+
 ### Entity structure & trust positioning: non-profit, transparent, volunteer-built
 
 The org is a **true non-profit (501(c)(3) or equivalent), radically transparent (open books), engineered by volunteers with LLM-accelerated development, not raising money or selling equity.** This converts the trust position from a *promise* into a *guarantee*, and it's funded-viable for a reason that's thematically exact:
@@ -480,6 +487,8 @@ Per the decision above, this is a **parametric** model: the fee *rates* are desi
 - **Subscription.** Cold-start makers pay Starter (≈2–4% of captured GMV, no/low monthly); at scale they auto-graduate to Pro (flat **$29–49/mo**, 0%). The flat Pro fee is the *predictable* margin; the Starter percentage is cold-start-friendly but thin on low-GMV makers.
 - **Referral spread.** On a referred order, Maker B pays ≈15% and Maker A is credited 10–12%; the **spread (≈3–5%) is platform margin** (§7, "Referral economics"). But A's credit is a *non-cashable draw against A's own future platform fees* — so a referral credit is **foregone future fee revenue**, not free money. The model must net it: referral activity generates spread *and* erodes subscription/fee revenue as credits are drawn. Treat the credit as a cost line, not a wash.
 
+**A note on partner-network splits.** Where a maker pays a partner out of its earned referral income (§7, "Partner / consultant network"), the split **redistributes the maker's curator income, not the platform's spread** — the platform stays principal on both legs and its 3–5% margin is unchanged. So partner comp does not move the platform's break-even directly; it is **maker-borne activation cost, paid from the upside**, that lowers the friction of turning a maker into an *active referrer*. Model it as a driver of the referral-activation rate (and thus of the North Star, below), not as a platform cost line.
+
 **The cost base — three buckets** (the §4 / launch-prompt decomposition).
 
 1. **Network-service hosting.** The cross-tenant moat service is hosted *separately, always* (§7, "Hosting"); the per-maker storefront cost is largely the maker's own (their processor, their Medusa/Shopify). Mostly a fixed base with mild per-maker/per-order scaling. The §7 pilot (GCP Cloud Run + Cloud SQL, low tens of dollars/month) is the *floor* of this term — and the trap is mistaking that floor for the whole of it (below).