docs: promote partner network to its own §7 subsection; cash/terms stay off-network

Break the partner-compensation model out of the "Business model" subsection into
a dedicated §7 "Partner / consultant network: onboarding the high-touch tail"
subsection. Add the money-flow clarification: the referral-income split is the
only leg the network settles (principal-on-both-sides, out of flow); any upfront
cash, setup fee, retainer, milestone, or other agreement is a direct off-platform
deal between maker and partner — the network never takes custody (custody is the
line). Tooling may record an off-network term (coordination) but never moves it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/maker-platform-strategy.md

@@ -296,15 +296,19 @@ Now that Medusa exists and the network federates over any storefront, *centering
 
 **"Why not just point makers to Medusa Cloud?"** Because Medusa Cloud sells *hosted infrastructure to developers*; it doesn't give a maker a working drops-and-clubs storefront. You sell a **vertical, maker-ready commitment-commerce product** where Medusa is *invisible plumbing*. The entire gap between raw infrastructure and a working maker storefront is your product — pointing a maker to Medusa Cloud is like pointing them to AWS. Corollary: **don't position or price as a hosting company** ("Medusa Cloud + modules" drags you into competing on infra margins). Hosting is a cost you absorb; the vertical experience (and the network) is what you sell.
 
-**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 / consultant network: onboarding the high-touch tail
 
-**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:
+Implementation consultants (community-embedded especially) onboard the **high-touch tail** without the network 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, a directory, the referral-income share below) 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.
+
+**How partners are paid — 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 is the *one* partner-compensation leg the network touches, and it 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*.
 
+**Cash, payment terms, and any other agreement live *outside* the network — by the same money-flow rule.** The referral-income split above is the only money leg the network handles, precisely *because* it can be done principal-on-both-sides without entering the flow. Everything else a partner and maker might agree — an **upfront cash payment, a setup fee, a retainer or hourly, milestone payments, or any other lawful arrangement** — is a **direct business agreement between the two, settled off-platform**, exactly as a maker pays any other vendor it hires. The network neither processes nor takes custody of that money, because doing so would put it squarely back in the money flow it is built to stay out of (custody is the line — "Money flow: stay out of it"; Appendix C.2; the spine). So the division is clean: **the network settles the one leg it can keep out of the flow (the referral-income share, via the cashable rail), and stays entirely clear of every direct-cash leg, which the parties arrange and settle themselves.** The tooling may *record* an off-network term for the parties' own clarity (recording is coordination, which is free) — but it never *moves* that money.
+
 ### 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: