docs/maker-platform-strategy.md

@@ -2,7 +2,7 @@
 
 A working memo distilling the thinking so far. It serves makers in general, but launches into one dense community first (the *beachhead*, §2/§5). The aim is to keep two doors open — a paid consultancy that's real today, and an option on a larger network play — without over-committing to the second before the evidence justifies it.
 
-> **Grounded in the Open Human Model.** Every principle in this memo — *trust, consent, reputation, harm, recourse, value, agency, dignity* — is meant to rest on the shared definitions in the [**Open Human Model (OHM)**](https://rfc.wiggleverse.org/p/ohm/c/default/), Wiggleverse's version-controlled dictionary for the words that systems acting on behalf of humans turn on. Where this memo and an OHM RFC disagree, **the RFC is canonical**; where a load-bearing concept here isn't yet defined in OHM, defining it is itself OHM work (not license to coin a local meaning). The reputation/trust model below is the first place this bites — see §10 backlog #1.
+> **Grounded in the Open Human Model.** Every principle in this memo — *trust, consent, reputation, harm, recourse, value, agency, dignity* — is meant to rest on the shared definitions in the [**Open Human Model (OHM)**](https://rfc.wiggleverse.org/p/ohm/c/default/), Wiggleverse's version-controlled dictionary for the words that systems acting on behalf of humans turn on. Where this memo and an OHM RFC disagree, **the RFC is canonical**; where a load-bearing concept here isn't yet defined in OHM, defining it is itself OHM work (not license to coin a local meaning). The reputation/trust model below is the first place this bites — see §10 (and §12 #1).
 
 ---
 
@@ -104,7 +104,7 @@ The white-label model enforces this: each storefront is the maker's brand on the
 
 If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — but it is a *dial, not a single choice*, and only one setting preserves the stance above. Two independent knobs decide who is merchant of record and who eats the risk:
 
-- **Charge type.** *Direct charges* keep the **maker** as MoR — disputes and chargebacks hit the maker's balance, the maker pays the processing fees. *Destination charges* and *separate-charges-and-transfers* make the **platform** MoR — your balance is auto-debited for disputes, and you are now indirectly collecting and transmitting the buyer's payment, i.e. a **marketplace facilitator** for sales-tax purposes (§10 #3).
+- **Charge type.** *Direct charges* keep the **maker** as MoR — disputes and chargebacks hit the maker's balance, the maker pays the processing fees. *Destination charges* and *separate-charges-and-transfers* make the **platform** MoR — your balance is auto-debited for disputes, and you are now indirectly collecting and transmitting the buyer's payment, i.e. a **marketplace facilitator** for sales-tax purposes (§11).
 - **Account type.** *Standard* accounts leave negative-balance and dispute liability with the maker. *Express/Custom* push it onto the **platform**, with Stripe holding reserves against *you* for connected-account shortfalls.
 
 The stance holds **only at Standard accounts + direct charges + `application_fee`**: the maker stays MoR, disputes stay on the maker's balance, you skim a fee without entering the flow. The trap is that Stripe's own marketplace tutorials default to *destination* charges (the canonical "marketplace" pattern), which silently flips every one of those properties — the payments-layer cousin of the "buy through their store" creep this memo warns about elsewhere. So **the Connect configuration is a legal-posture constraint, not an implementation detail.** The default money model remains the out-of-flow ACH/invoice fee below; Connect is reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts), and even there uses the arm's-length setting. *(Verify per account type and per state with a payments/SALT attorney before architecting. Not legal advice.)*
@@ -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, §10 backlog #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 backlog #1). 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 #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.
 
 ### 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 (§10 backlog #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 #4), 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.
 
@@ -346,11 +346,90 @@ Two makers justify a thoughtful, portable data model. They do not justify a plat
 
 ---
 
-## 10. Open sections to develop (backlog)
+## 10. Trust & safety & maker accountability (reserved)
+
+*Reserved for the trust-&-safety write-up — the next major section, and §11's sibling: the two operational sections the architectural body of the memo had only gestured at.* The **shape** of post-verification maker accountability was already settled (originating-edge invitation graph; reputation flowing *up* that edge, decayed per-hop and hop-capped; consequence = a low, buyer-visible reputation score + loss of all network benefit rather than expulsion; inviter-held suspend/expel authority with a platform floor for active buyer harm and a governance appeal path) — that shape, with the still-open items, lives in §12 #1. What remains is the **reputation engine itself**, which is explicitly **OHM-guided work** (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)): scoring, the decay-coefficient and hop-cap values, how good standing accrues, display, benefit-gating thresholds, and how *harm* and *recourse* are operationalized all turn on OHM concepts (**reputation, trust, harm, recourse, value, dignity**) — defer to the relevant RFCs and cite them, proposing them where undefined. Holding the §10 slot keeps the section numbering stable for that write-up.
+
+---
+
+## 11. Legal & compliance
+
+The memo's legal strategy is not a list of compliance chores bolted on at the end — **it is one architectural choice, viewed through a legal lens.** Staying out of the money flow (§7, "Money flow: stay out of it") was justified there as a financial-risk decision; its larger payoff is *legal*: a single structural fact — **the maker is merchant of record on the maker's own processor, and the network never touches buyer funds** — discharges obligations across three otherwise-separate regulatory categories at once. **No money transmission. No marketplace-facilitator tax duty. No merchant-of-record liability.** Where a competitor that sits in the flow must license, collect, remit, and indemnify, the network simply isn't the regulated party. The genuine open exposures are exactly the ones that *aren't* dissolved by the money-flow stance — and the discipline of this section is to separate the two: what the architecture already answers (recap, hold the line) from what it doesn't (engineer down, or flag for counsel).
+
+**Convention: flag and verify — not legal advice.** Everything below is the *engineering posture* — the structural choices that keep the regulatory surface small, and the questions worth putting to specialist counsel. It is not legal advice; each item names what to verify and with whom. Where a principle turns on a load-bearing concept — *consent, harm, recourse, value, dignity* — it defers to the [Open Human Model](https://rfc.wiggleverse.org/p/ohm/c/default/) per the top-of-file note (handbook §4.4): cite the RFC, don't coin a local meaning.
+
+### Money transmission (MTL) — recap from §7
+
+Out of the flow → **none.** Holding customer funds (escrow, a balance, a payout you control) triggers state-by-state money-transmitter licensing in the US — the single most expensive licensing regime a small org could wander into. The network never holds buyer funds: the maker is MoR on the maker's own processor, and the platform fee is billed in arrears via ACH/invoice (§7, "How the platform gets paid"), which is the network charging *its own customer for software*, not transmitting a third party's money.
+
+- **The cashable Phase-2 rail rents a licensed transmitter — it doesn't become one.** When cashable payouts arrive (maker wallet cash-out, kit pure-supplier settlement, taste-maker affiliate payout — §7), the money moves over a BaaS rail (Stripe Connect/Treasury, Dwolla, a mass-pay provider) whose operator *is* the licensed money transmitter. The network is a platform user of that rail, not the regulated transmitter — the "rent the licensed infra, don't build it" move applied to compliance.
+- **The non-cashable wallet is not stored value.** The fee-offset wallet (§7) credits a maker against *future platform fees* — a discount / accounts-receivable entry, not a balance the maker can withdraw or spend with third parties. It is therefore neither stored value, a prepaid-access instrument, nor transmittable money, and stays outside the MT and stored-value regimes by construction. **Cashing out is the deliberate crossing** that re-opens the door — which is precisely why it is gated to Phase 2 behind a rented transmitter, never a toggle. *(Verify the wallet's non-cashable design against your states' stored-value / prepaid-access definitions before launch.)*
+
+### Marketplace-facilitator sales tax — the centerpiece
+
+This is the high-consequence area the memo had entirely missing, and the one most likely to surprise. Post-*Wayfair*, every US state with a sales tax has enacted **marketplace-facilitator statutes** that can attach a *tax-collection-and-remittance duty* to a "marketplace facilitator" **even when it is not the merchant of record** — the whole point of these statutes was to make the platform, not thousands of small sellers, the collection point. So "the maker is MoR" does **not**, by itself, settle it; facilitator status turns on a separate test.
+
+**The two-part conjunctive test.** In most states (modeled on the SSUTA / MTC definition) you are a marketplace facilitator only if you do **both**: **(prong 1)** list, advertise, or otherwise facilitate the sale of a marketplace seller's products, **and** **(prong 2)** directly or indirectly **collect the payment** from the purchaser and transmit it to the seller. Both prongs are required — it is conjunctive, not "either."
+
+- **The referral-handoff model (§7, Model A) fails prong 2 — by design.** Checkout happens entirely on Maker B's own store and processor; the network passes a signed referral token, then bills B a fee and credits A — money on which the network is *principal* (its own fee revenue, its own credit), never buyer payment it collects and forwards. It arguably satisfies prong 1 (it facilitates discovery) but **cannot satisfy prong 2**, so it is not a facilitator. Many statutes reinforce this with an explicit **advertising-only / referral exclusion**: a person who merely advertises or lists products and refers purchasers to the seller, *without processing the payment*, is carved out by name. The referral network sits squarely inside that exclusion — which is *why* it is a referral network and not a checkout.
+- **The fragile edge is "indirectly collects payment."** Prong 2's "indirectly" is the word that does the damage: some statutes read it broadly enough to sweep in arrangements where the platform touches the payment flow even lightly (routing, splitting, holding briefly). The referral handoff is safe because it touches **zero** payment flow — but the margin of safety is "we never touch the money," not "we're small." The moment any feature lets the network touch buyer payment, the edge moves.
+- **Danger zones — where prong 2 attaches and facilitator status flips on:**
+  - **Phase-3 shared checkout (§7).** A unified cart where the *network* collects the buyer's payment and routes/splits it to makers directly collects payment — prong 2 satisfied, facilitator duty attaches. This is exactly the "much later, optional, opt-in" crossing the phasing reserves, and **it carries a sales-tax-collection obligation as a first-class consequence**, not an afterthought.
+  - **Split-payment kits (Appendix C, Model 3 — Connect destination charges).** One checkout auto-splitting to N connected accounts has the platform *indirectly collecting and transmitting* — facilitator. One more reason Model 3 is "avoid until you choose to be marketplace-of-record for kits."
+  - **Connect destination/separate charges or `application_fee` where the platform is MoR.** The §7 charge-type dial that flips MoR to the platform *also* flips facilitator status, because platform-MoR means the platform is indirectly collecting the buyer's payment. The Connect setting is, again, a legal-posture decision (next).
+- **Tax calculation belongs to the maker's storefront layer — never the network.** Sales-tax *calculation, collection, and remittance* is the MoR's job, and the MoR is the maker. Both storefront engines do it natively (Shopify Tax; Medusa's tax module) and both integrate the specialist engines (Avalara, TaxJar) for nexus-aware rates and filing. The network must **not** build tax-calc — doing so would quietly adopt the very duty the architecture declines, and would invite the argument that a thing computing sales tax across makers is behaving like a facilitator. The network computes *its own* fees; the storefront computes the buyer's tax. *(Confirm facilitator status per state with a SALT attorney before any feature that touches buyer payment — especially before Phase 3.)*
+
+### Stripe Connect configuration as legal posture — see §7
+
+The Connect configuration is the hinge on which MTL, facilitator status, *and* merchant-of-record liability all turn, and it is **already specified in §7** ("Money flow"): the stance holds **only at Standard accounts + direct charges + `application_fee`** — maker stays MoR, disputes stay on the maker's balance, the network skims a fee without entering the flow. Destination / separate-charges-and-transfers and Express/Custom accounts each flip one or more of those properties (MoR → platform, dispute liability → platform, indirectly-collecting → true → facilitator). This section only records *why* §7's setting is a legal constraint and not an implementation detail; the dial itself is governed there. **Do not re-decide it here — cross-reference and hold the line.**
+
+### Raffle / lottery — engineer out the consideration
+
+The raffle drop is the one primitive (§4) with direct **gambling-law** exposure. A lottery is three elements, **conjunctive: prize + chance + consideration.** Remove any one and it is not a lottery — so the design removes the controllable one.
+
+- **Free-entry allocation removes *consideration*.** The default raffle/queue mechanic allocates a *right to buy* a scarce drop by random draw, with **free entry** — no payment to enter the draw; the winner then purchases at the normal price like any other buyer. With no consideration paid for the *chance*, there is no lottery: it is allocation of limited inventory by lot, not a paid gamble (the same shape as a "no purchase necessary" sweepstakes — the chance must be free). The OHM frame is *fairness/dignity* in allocation: a transparent, equal-chance draw for scarce goods, not pay-to-play.
+- **Paid-entry raffle is off by default, pending per-state clearance.** A raffle where the buyer *pays to enter a draw for a prize* re-adds consideration and is a regulated raffle/lottery — generally unlawful for a commercial entity, lawful only for licensed nonprofits in some states, banned or tightly restricted (registration, caps, reporting) in others. It ships **disabled by default**, gated behind explicit per-state legal clearance. *Note the cross-current:* the 501(c)(3) entity (§7) may actually *open* charitable-raffle paths a commercial operator can't use — but that is a flag for counsel and a deliberate per-state opt-in, **not** a green light to turn paid raffles on. *(Verify per state — gambling / charitable-gaming law is among the most locally variable regimes there is.)*
+
+### Consumer protection / FTC
+
+Three distinct FTC-adjacent duties: two fall on the maker (the seller / MoR) with the platform easing compliance, one the platform's own architecture already discharges.
+
+- **Affiliate disclosure (maker's + referrer's duty; platform surfaces it).** The verified-taste-maker tier and any compensated curation must carry clear, conspicuous affiliate disclosure (FTC endorsement guides, 16 CFR 255) — already required by the §7 taste-maker guardrails. The platform's job is to **make disclosure automatic in the UX**: label a disclosed-affiliate pick distinctly from a maker's reputation-staked peer vouch (reciprocal/reputational, not cash-compensated), so the buyer can tell sincere vouch from paid referral. Honest labeling here is a moat property, not just a rule — the whole anti-retail-media stance depends on the buyer seeing the difference.
+- **The pre-order / 30-day delivery rule (maker's duty; platform UX eases it).** Commitment commerce *is* taking money before delivery, which squarely triggers the FTC **Mail, Internet, or Telephone Order Merchandise Rule** ("the 30-Day Rule"): the seller must ship within the stated time — or within 30 days if none is stated — and on delay must give the buyer notice and a right to cancel for a prompt refund. This is the **maker's** obligation (maker is seller / MoR), but the commitment-commerce engine is uniquely positioned to make compliance the path of least resistance: **require a stated fulfillment window** at drop/pre-order creation, surface it to the buyer at commit time, **prompt delay notices** when a window slips, and support one-click cancel/refund. Compliance-by-design as a product feature — the platform eases the duty without assuming it. (This is also the legal spine of the §12 #1 "verified maker collects pre-orders and ghosts" failure mode: the 30-Day Rule is what a ghosting maker *violates*, and the platform's notice/refund machinery is the buyer's first recourse before any chargeback.)
+- **Handmade-claim substantiation (platform architecture already answers it).** "Handmade," "original," "made by this person" are advertising claims subject to FTC substantiation; an unsubstantiated claim is a deceptive practice. The **per-item provenance system (§7) *is* the substantiation mechanism** — self-attested classification, audited by the sampling audit + buyer reporting, shown as a buyer-visible badge, with misclassification a verification-revocation trigger. The trust architecture the moat already requires doubles, exactly, as claim-substantiation infrastructure — a place where the product-defining feature and the compliance obligation are the same build. (OHM *value* / *dignity*: the truthfulness of "handmade" is a value claim about the maker's work, which is why it is load-bearing both legally and morally.)
+
+### Privacy
+
+Recap the §7 consent architecture, now read as the privacy-law posture.
+
+- **Two consent domains, two consent layers, source-of-truth in the maker's ESP.** Maker-originating marketing lives in the maker's ESP (authoritative); network-originating communication consent the network owns; the maker decides store participation and the buyer decides cross-network recognition (§7, "Customer ownership, consent & martech"). This separation isn't only good product design — it is what keeps each personal-data flow attributable to a lawful basis and a controller.
+- **DPAs.** Where the network processes personal data on a maker's behalf (catalog sync, ESP push, the dashboard cache, the buyer feed) it acts as a **processor** and needs **Data Processing Agreements** with makers, plus back-to-back DPAs with its own sub-processors (ESP, hosting, the Connect/BaaS rail). Stand the DPA chain up at onboarding, not after a buyer asks.
+- **Build to the strictest state law, not a 50-state matrix.** Rather than tracking divergent regimes feature-by-feature, build to the **strictest common denominator** — CCPA/CPRA plus the newer comprehensive state laws (and GDPR the moment EU buyers appear) — and apply it everywhere: real consent capture, access/deletion rights, opt-out of "sale/sharing." The cross-maker identity graph is the privacy-sensitive surface, and it is **opt-in by design** (§7) — so the architecture is *already* aligned with the strictest "no sharing without affirmative consent" reading, rather than retrofitting opt-outs onto a default-share. The OHM *consent* RFC is canonical for what "consent" must mean across these surfaces — cite it; don't re-derive a local definition.
+
+### Freedom-to-operate / patent
+
+- **Low-novelty mechanics → low patent-thicket risk.** The commitment-commerce primitives (scheduled drops, pre-orders/deposits, raffle-as-allocation, clubs/memberships, referral links, cross-merchant attribution) are widely practiced, decades-deep mechanics with abundant prior art. The novelty is in the *combination and positioning*, not in any patentable mechanism — so the risk of a blocking patent thicket over the core build is low.
+- **Do a basic FTO check anyway.** Before building a headline feature, run a basic freedom-to-operate search — particularly for anything resembling a specifically-patented method (one-click-style checkout flows, specific loyalty/attribution or pledge-management methods). Cheap insurance against the rare narrow patent; not a reason for alarm.
+- **Transparency doubles as defensive prior art.** The radically-transparent / open-books posture (§7 entity) means the design is *published as it is built* — which is **defensive publication**: dated prior art that makes it harder for anyone (including a well-funded incumbent) to later patent the combination and assert it against you. The transparency that serves the verification moat pays a second dividend in patent defense — one posture, two protections.
+
+### Novelty / competitive finding
+
+*(Restored — this finding didn't survive the generalization from the miniatures memo and belongs here.)* The honest competitive read: **the components all already exist** — cross-merchant inclusion (Shopify Collective, Carro), pre-order/drop tooling, affiliate/referral networks, verification badges, non-profit governance — but the **specific combination is novel and unproven**: verified per-item provenance + reputation-staked cross-maker referral + native commitment-commerce + non-profit/transparent governance, scoped to one dense vertical. **The moat is positioning and governance, not patents.** Do not expect IP to defend the position; expect the defense to be community standing, the rooted trust graph (§7 verification), the no-walled-garden value rule (Appendix D), and a 501(c)(3) structure a commission-optimized incumbent structurally cannot copy without betraying its own customers (§7, "Why this is the defensible core"). This is the same truth the spine states — *the components exist; the combination is novel but unproven* — carried into the legal lens: novelty here buys no monopoly, so the work is to make the *combination* hard to replicate by other means.
+
+### Entity structure / UBIT
+
+- **The 501(c)(3) path** (§7, "Entity structure & trust positioning"): a true non-profit that legally cannot be sold or distribute profits — which is what converts the anti-Etsy promise from a pledge into a structural guarantee. The legal work here is *formation*: exempt-purpose drafting, governance documents, state charitable registration.
+- **The UBIT tension — flag for nonprofit counsel.** A 501(c)(3) that earns **platform fees and referral fees** is earning income from a trade or business regularly carried on — which raises **Unrelated Business Income Tax (UBIT)**. The crux is whether that fee income is *substantially related* to the exempt purpose (e.g. sustaining independent makers / a charitable-educational mission) or is merely a commercial activity that happens to fund it. Get it wrong and the exposure ranges from UBIT liability on the fee revenue to — if commercial activity comes to *dominate* — jeopardy to the exemption itself. This is the **one place the non-profit choice creates legal complexity rather than dissolving it** (the mirror image of the money-flow stance, which dissolves complexity), and it is genuinely unsettled at this memo's altitude — so it is an early, explicit **flag for specialist nonprofit/tax counsel**, who may reshape the exempt-purpose framing, structure the fee-earning activity to stay "related," or recommend a taxable subsidiary for the commercial layer. Surface it in §8/§9 diligence rather than discovering it post-formation.
+
+**The through-line, restated.** The pattern of this whole section is one shape: **where the architecture stays out of the money flow, the legal burden largely dissolves** — MTL, marketplace-facilitator tax, and MoR liability are all discharged by the single choice that the maker, on the maker's own processor, is merchant of record. What remains are the exposures that *aren't* a money-flow question — and each gets handled in kind: **engineer it down** (consideration out of the raffle; compliance-by-design pre-order UX; provenance-as-substantiation; opt-in privacy aligned to the strictest law) or **flag it for counsel** (UBIT, paid-entry raffles, per-state facilitator confirmation before Phase 3). The legal strategy is not separate from the architecture — **it is the architecture, audited.** *Flag and verify — not legal advice.*
+
+---
+
+## 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.
 
-1. **Trust & safety / maker accountability (post-verification) — shape decided this session; reputation *engine* is OHM-guided work.** Verification is only an *entry* gate; the question is what happens when a maker behaves badly afterward. Commitment commerce makes this the signature failure mode — "verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, not an edge case — and the money-flow stance solved the *financial* exposure (maker is MoR) but not the *reputational* one, which is the one the moat rests on. **The shape we settled:**
+1. **Trust & safety / maker accountability (post-verification) — shape decided; §10 now reserves the section slot; reputation *engine* is OHM-guided work.** Verification is only an *entry* gate; the question is what happens when a maker behaves badly afterward. Commitment commerce makes this the signature failure mode — "verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, not an edge case — and the money-flow stance solved the *financial* exposure (maker is MoR) but not the *reputational* one, which is the one the moat rests on. **The shape we settled:**
    - **Originating edge.** Every maker enters by invitation = a vouch they make original art or craft, rooted in a staff-verified seed set — a permanent graph topology (the membership gate starts invitation-only and loosens over time, §7).
    - **Inviting doesn't pay** — the incentive is the commercial relationship, never a bounty (which would manufacture Sybil incentives).
    - **Reputation flows up the originating edge** — transitive but **decayed (a per-hop coefficient) and hop-capped**, so impact is strong next to the misbehavior (a prompt-to-act for whoever can act) and negligible by ~6 degrees out. Framed as **positive reinforcement** (earn/grow standing), not punishment.
@@ -361,7 +440,7 @@ This memo is deep on the architectural/strategic axes (money flow, network mecha
 
 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.
 
-3. **Legal & compliance, consolidated — especially marketplace-facilitator sales tax.** The scattered legal points (MTL, raffle/lottery, GDPR/CCPA, FTC disclosure) need one consolidated section, and **sales-tax / marketplace-facilitator nexus is entirely absent and high-consequence**: facilitator statutes can attach tax-collection duties to a "marketplace" even when you're not the merchant of record, and the trigger is often "facilitating the transaction" — which referrals, kits, and a Phase-3 shared checkout could implicate. The staying-out-of-the-flow stance feels like it should cover this but doesn't. Also restore the **freedom-to-operate / patent check** and the **"is this novel" competitive finding** (components exist, combination is novel-but-unproven) that didn't survive generalization.
+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.
 
 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.