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 #4): 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, §13 #3): 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 #2), 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), 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.
 
@@ -296,7 +296,18 @@ 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
+
+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
 
@@ -344,6 +355,8 @@ Gate the real platform build on evidence, not enthusiasm:
 
 Two makers justify a thoughtful, portable data model. They do not justify a platform. Build the data layer and the vertical primitives now; gate everything else on the dozen.
 
+These gates are stated qualitatively here; §12 gives each a quantitative instrument (and a North Star) computed from the cross-merchant order history, so the dozen-maker gate can be *measured* rather than felt.
+
 ---
 
 ## 10. Trust & safety & maker accountability
@@ -369,7 +382,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 #3) 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** (§13 #2) 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.
 
@@ -458,17 +471,111 @@ Recap the §7 consent architecture, now read as the privacy-law posture.
 
 ---
 
-## 12. Open sections to develop (backlog)
+## 12. Sustainability economics & health metrics
 
-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. Concrete MVP scope, the build roadmap, and the data-model sketch are intentionally *not* tracked here: this is a **strategic memo, not a roadmap/rollout doc** — those belong in the implementation plan the strategy feeds, not in the strategy itself.) Rough priority order; the **recommended next session** is the sustainability economics & health metrics below (#2), with §10's open reputation-engine work (gathered in that section's last subsection) the other live thread.
+The memo is deep on architecture and silent on whether the architecture pays for itself. That silence is the dangerous kind: ventures rarely die of a bad money-flow diagram, they die of a cost base no one modeled. Two questions sit under "is this sustainable," and they are different questions. **Does the fee model cover the cost base, and at what scale?** — the unit-economics question. And **is the network actually working?** — the health/liquidity question that turns the §9 gates from enthusiasm-readings into instruments. Both rest on the same asset: the cross-merchant order history the network already holds to compute referrals (§7, "Storefront architecture & Shopify coexistence"), which is *uniquely* able to see across stores. The numbers here are deliberately left as variables — n = 2 can't calibrate them (§4) — because the contribution this section makes is the *model and the instruments*, not invented values. This whole section turns on OHM **value** (the metric must track *earned* value, not gamed volume) and **trust/recourse** (the trust guarantee is only as good as the funded reliability behind it); where it names one, the canonical RFC governs (top-of-file note).
 
-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.
+### "Non-profit" is not "needn't cover costs"
 
-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.
+The 501(c)(3)/volunteer/transparent structure (§7, "Entity structure & trust positioning") changes *who keeps any surplus* — no one; it cannot be distributed — but it does **not** change the arithmetic that revenue must meet cost or the org folds. Exemption is not exemption from a budget. The structure's funding-viability rested on one specific claim: the dominant historical cost center, engineering, has been deflated by LLMs (§7) — the entity and the opportunity are the same bet. But "deflated" is not "zero." The reliability core (network service, ledger, verification) needs *sustained* funding, not best-effort volunteer cadence (§4), and that floor is a real recurring cost the fee model must carry.
 
-3. **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.
+- **There is a ceiling as well as a floor — the §11 UBIT band.** The mirror of "must cover costs" is "must not look like a commercial marketplace wearing a non-profit badge." A 501(c)(3) earning platform and referral fees raises Unrelated Business Income Tax exposure unless that income is *substantially related* to the exempt purpose, and if commercial activity comes to *dominate*, the exemption itself is in jeopardy (§11, "Entity structure / UBIT"). So the sustainable target is a **narrow band**: enough fee revenue to fund the reliability core off bus-factor-one, framed as sustaining the exempt mission — not so much, or so commercially-shaped, that the org reads as a marketplace that incorporated as a charity. Cost-coverage and UBIT pull from opposite sides onto the same number.
+- **The discipline §7 names, applied to the numbers.** "Transfer the rigor you'd spend on fundraising onto volunteer sustainability" (§7) has a quantitative edge: a non-profit that cannot model its own break-even is already exhibiting the volunteer-org failure mode — dying of *sustaining*, not *building* (§4). Modeling it is the rigor; the model below is the minimum form of it.
 
-4. **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).
+### Unit economics — does the fee model cover the cost base?
+
+Per the decision above, this is a **parametric** model: the fee *rates* are design parameters fixed in §7 ("How the platform gets paid"); the volumes and costs are named variables, because the honest values don't exist yet (§8 discovery and the first dozen makers are what populate them).
+
+**Two revenue lines, both from §7.**
+
+- **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).
+2. **Verification labor.** The human cost of the trust gate — staff-verifying the seed/root set early, then the sampling audit, ring-detection, and revocation handling as peer verification scales (§7, "Verification"; §10). Scales with maker inflow and audit volume; the part that needs reliability cannot be best-effort.
+3. **Reliability core.** The funded floor that keeps buckets 1 and 2 *plus the ledger* off bus-factor-one (its own subsection below). This is the line item the cloud invoice does not show, and the one most likely to be under-modeled.
+
+**The break-even shape.** Let N be active makers, with per-maker net contribution m (subscription, plus referral spread, *minus* drawn credits, netted across the Starter/Pro mix), and a cost base C = F + v·N where F is the fixed reliability-and-base term and v the marginal per-maker cost (incremental verification + hosting). Break-even is the familiar fixed-cost-coverage form:
+
+```
+N* ≈ F / (m − v)
+```
+
+Two things fall out of the *shape*, no values required:
+
+- **This is a fixed-cost-coverage problem, not a margin problem.** Each maker contributes a small but positive m − v (mostly the subscription; the referral spread is thin and partly self-cancelling via credits). The question is therefore not "is a maker profitable" (yes, modestly) but "**how many modest contributions fund the reliability floor F**." That directly *reframes the §9 dozen-maker gate*: a dozen makers validates **demand**; break-even is a larger N governed by how lean F is kept (the §7 LLM-deflated-cost bet is precisely the bet that F is small) and how much per-maker margin the tier mix yields.
+- **N\* falls as makers *grow* and *refer*, not merely as they're *added*.** A network stuck on cold-start Starter percentages at low GMV barely moves m; break-even improves as makers graduate to flat Pro (margin firms up) and as referral activity lights (spread revenue). So the two levers that move N\* most are **F** (keep the reliability core lean — the §7 bet) and the **Starter→Pro graduation + referral-activation mix** (raise m). Adding low-GMV, non-referring makers moves break-even the least.
+
+**An illustrative pass — the *shape*, not validated numbers.** To see what the formula implies, fix the variables at plausible midpoints — average active-maker GMV `G` = $30k/yr, Starter take 3%, Pro $39/mo, referral spread 4% — and let the Pro-tier mix and referred share `ρ` mature as the network lights:
+
+| Makers `N` | on Pro | referred `ρ` | Pro fees | Starter % | Referral spread | **≈ revenue/yr** |
+|---|---|---|---|---|---|---|
+| 2 (pilot) | 0% | 0% | — | $1.8k | — | **$1.8k** |
+| 12 (§9 gate) | 10% | 5% | $0.6k | $9.2k | $0.7k | **$10.5k** |
+| 50 | 25% | 10% | $5.9k | $30k | $6.0k | **$42k** |
+| 200 (density) | 40% | 20% | $37k | $86k | $48k | **$172k** |
+| 1,000 | 50% | 25% | $234k | $337k | $300k | **$872k** |
+
+Two readings fall out, both reinforcing the parametric conclusions above. The revenue **mix flips with maturity** — ~90% thin Starter percentage at the §9 gate, but the Pro flat fee and the referral spread carry it by density and beyond (the *graduate-and-refer*, not merely *add*, point). And against a lean reliability floor `F` ≈ $75–150k/yr (the funded core ops + ledger + verification audit + hosting), break-even lands somewhere around **~150–300 makers** under these midpoints — **well past the dozen-maker §9 *demand* gate.** The dozen validates demand; sustainability is a later, larger N, and that gap is exactly the thing this section exists to name.
+
+**The honest caveat (memo voice).** These are the variables, not values: n = 2 cannot calibrate per-maker GMV, the referred-GMV share, churn, or graduation rate. Naming the model is the point — and the §9 gate should start **instrumenting** the inputs (per-maker GMV, referred share) so that break-even stops being unknown by the time the dozen-maker gate is cleared. The same order-history asset that powers the metrics below makes every one of these variables measurable per maker (§7) — the model and the instruments are the same build.
+
+### Network-health & liquidity metrics — instrumenting the §9 gates
+
+The §9 gates are all qualitative — *do makers refer you? is the pain consistent? do they have audiences? can you reach a dozen?* Those are the right questions, but the network's success is fundamentally a **liquidity** outcome (§4: curation fights liquidity, and the graveyard is full of platforms that had supply and no demand). Liquidity needs liquidity instruments.
+
+**North Star: the share of GMV that is cross-maker-referred.** This is the one number that is near-zero for a pile of disconnected storefronts and rises *only* as the referral network actually does work. A storefront-only success — a genuinely good commitment-commerce tool that never becomes a network — shows a **low North Star**, which is exactly the most-feared failure mode (a good tool that never lights the moat, §4/§5). It measures "the network is the product" (§7, "Business model") directly, in a single figure, in a way no vanity supply count can fake.
+
+**The leading indicators beneath it** — the funnel that *predicts* the North Star, earliest-first:
+
+- **Follower growth** — the §2 flow asset (drop-followers accumulating across makers, the embryonic cross-merchant identity graph). The leading-most signal: follows precede referred GMV by definition.
+- **Curated-By activation** — the share of verified makers who actually *vouch*, and the breadth of their curation. Referred GMV cannot exist without curators curating; a network rich in follows but where makers don't vouch is still dead.
+- **Drop sell-through** — the commitment-commerce engine's own vitality (do drops clear?). The tool-layer health the network rides on; a stalling engine starves the network upstream.
+- **Repeat-buyer rate, especially cross-maker repeat** — demand durability, and whether the buyer-side keystone (§13 #1; §8) is real. A buyer who returns *across* makers is the network effect made visible at the buyer level.
+
+**Mapped onto the §9 gates, making each quantitative:**
+
+- *"Do makers refer you?"* → Curated-By activation + referred-GMV share (the North Star itself).
+- *"Do target makers have audiences?"* → follower growth (and the §8 "an audience they'd bring" question, now a number).
+- *"Consistent pain / a dozen who want the same thing?"* → drop sell-through + Starter→Pro graduation rate.
+
+**The order-history asset computes all of this for free.** §7 already commits it: *"One asset, three uses — the same order history powers the referral ledger, the network-health metrics, and this reporting."* The cross-tenant vantage is the only place cross-maker-referred GMV and cross-maker repeat *can* be computed — no single-store tool sees across stores (which is itself moat-deepening, §7). So these metrics are not new instrumentation to fund; they fall out of the ledger the referral system already requires.
+
+**Goodhart caution — the metric must measure *earned* referral.** A North Star is a target, and a target invites gaming. The corrupt way to lift "cross-maker-referred GMV" is to *manufacture* referrals — pay for placement, juice the slots — which is precisely the retail-media drift §3 and §7 ("Curated By This Maker") exist to forbid. The North Star is only valid as a measure of **reputation-staked, earned** cross-referral; optimized the wrong way it rebuilds Etsy's pollution from the inside, through the dashboard. This is the OHM **value** point in metric form: the number must track real value to buyers and makers, not gamed volume — so pair the North Star with the §7 anti-corruption guardrails (uniform non-biddable rates, capped per-maker featuring, reputation on the line) rather than reading it naked.
+
+### Volunteer-sustainability economics — funding the critical core off bus-factor-one
+
+§4 names volunteer-core sustainability as **the single point of failure**, and §7 sharpens it: "the risk moved, it didn't vanish" — LLMs make a smaller core go further but do nothing for attrition or bus-factor. The economic question this section must answer is therefore not "what does it cost to *build*" but "**what must the fee model *fund* to keep the critical core reliable when any one volunteer leaves.**"
+
+Start from §7's own partition of what needs reliability versus what tolerates volunteer cadence:
+
+- **Must be funded (the reliability core).** *Network-service uptime* — drops are spiky and a storefront falling over *during a drop* is the worst possible moment for maker trust (§7, "Hosting"). The *fee/wallet ledger* — money-adjacent correctness: pending→cleared settlement, clawback, negative-balance handling (§7, "Referral economics"). And *verification* — the root set, sampling audit, ring-detection, and revocation that hold the trust guarantee, where a single polluted "verified" item breaks the guarantee for everyone downstream (§7; §10). None of these can be best-effort.
+- **Tolerates volunteer cadence.** Themes, storefront nice-to-haves, non-critical features (§7). These can wait on a volunteer's Saturday; the core above cannot.
+
+So the model's job is to fund *enough* of that reliability core that it **survives any single departure** — concretely, that the fixed term **F is not modeled as pure cloud cost.** The seductive error is to set F to the §7 pilot's tens-of-dollars-a-month GCP bill; the honest F also includes **compensated, documented, more-than-one-deep ownership** of network-service ops, the ledger, and the verification audit. Under-modeling F is exactly how an org clears break-even *on paper* and still dies of bus-factor — the volunteer-org killer §4 warns about, expressed as an accounting omission. "Bind with structure, not promises" (the spine) applied here means the reliability core is **funded, documented, and redundant by design** — not hoped for.
+
+- **The UBIT mirror is favorable here (§11).** Paying core maintainers from fee revenue is ordinary non-profit operation (reasonable compensation for exempt-purpose work), and funding the *mission's reliability* is far more defensibly "substantially related" to the exempt purpose than accumulating surplus would be. So the sustainability framing actually *helps* the §11 UBIT posture rather than straining it — fees fund the exempt-purpose reliability core, which is the cleanest story to tell counsel. (Still a flag for specialist nonprofit/tax counsel, per §11 — but a flag that points toward "related," not away.)
+- **This is the trust moat's operating budget — OHM *trust/recourse* made economic.** The buyer's trust guarantee (verification and the §10 accountability machinery) is only ever as strong as the funded reliability behind it; an under-funded verification audit is a trust promise the org *cannot keep*, and a ledger run on best-effort is recourse the org cannot honor. Sustainability economics is therefore not a separate concern bolted onto the moat — it *is* the moat's budget line. Defer to the relevant OHM RFCs for *trust*, *value*, and *recourse*; where a load-bearing one is undefined, defining it is itself OHM work (top-of-file note).
+
+### The through-line
+
+"Non-profit" raises the bar on cost discipline rather than lowering it: the org must cover a cost base whose **dominant term is the reliability floor under the trust moat**, fund it off bus-factor-one, and do so inside the §11 UBIT band (related, not dominant-commercial). The unit economics is a **fixed-cost-coverage** problem — `N* ≈ F / (m − v)` — governed by how lean the LLM-deflated core stays and by makers *graduating and referring*, not by per-maker margin or by adding low-GMV makers. The health metrics turn §9's qualitative gates into instruments around a single North Star — **the share of GMV that is cross-maker-referred** — fed by follower growth, Curated-By activation, drop sell-through, and cross-maker repeat, and they fall out of the §7 order-history asset for free. The numbers are still variables (n = 2 cannot calibrate them); the deliverable is the **model and the instruments**, so the §9 gate can start populating them. And the line a sustainable non-profit under-funds at its peril is the one the trust moat rests on — so bind it with structure: **the reliability core is funded, documented, and more than one person deep.**
+
+---
+
+## 13. 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. (Trust & safety, legal & compliance, and sustainability economics & health metrics were written up in prior sessions — now §10, §11, and §12 — and have left the backlog. Concrete MVP scope, the build roadmap, and the data-model sketch are intentionally *not* tracked here: this is a **strategic memo, not a roadmap/rollout doc** — those belong in the implementation plan the strategy feeds, not in the strategy itself.) Rough priority order; the **recommended next session** is the demand strategy below (#1) — the unvalidated keystone the whole thesis rests on — with §10's open reputation-engine work (gathered in that section's last subsection) the other live thread.
+
+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. (The §12 North Star — share of GMV that's cross-maker-referred — and its repeat-buyer leading indicator are the *instruments* for this; the *strategy* that moves them is still unwritten.)
+
+2. **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. (This is the §10 governance-appeal-path home and the body that would steward the §12 UBIT band.)
+
+3. **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).
 
 ---