docs(maker-platform): close Tier-2 PR-FAQ gaps + evolve referral model (negotiable rewards, ranking-neutrality)

PR-FAQ (Tier-2 reviewer gaps):
- Shopify-copies-the-tool: first-class-not-hard framing + cuttle.xyz/LLM-tool
  integration headroom; 'tool is the wedge, network is the moat'
- featured maker's (B-side) consent + economics
- ballpark F (~$75-150k/yr) and the 'F is not the cloud bill' reliability core
- operational drop-time reliability (blast radius + funded core)

Referral-model evolution (PR-FAQ + memo, source-of-truth reconciled):
- platform spread stays FIXED (~3-5%, $-capped) — the network's referral
  revenue line, unchanged in §12
- Maker A's reward becomes NEGOTIABLE above the spread (flat/tiered/max-$ cap,
  renegotiable), floored at the spread; maker<->maker only
- per-relationship approval: B must approve being curated by A
- ranking-neutrality as a STRUCTURAL guarantee: platform ranks for conversion
  but never by referral economics, credible because its spread is constant
- non-maker taste-makers keep uniform, non-biddable rates (peer-respect
  counterweight absent)

Memo ports: §2 (first-class/cuttle), §7 Curated-By guardrails + Referral
economics + catalog-presence + taste-maker tier, §7 partner comp, §12 spread
+ Goodhart guardrails.

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

docs/maker-platform-pr-faq.md

@@ -263,23 +263,51 @@ standard is named as later work (§14 #2), not claimed as solved.
 
 **What is "Curated By This Maker," and how do referrals pay?**
 Each storefront carries a section where the maker features other *verified* makers'
-products they genuinely admire. When a buyer follows that link and buys, the
-referred maker (B) pays a **referral fee** (~15%, the Faire/Amazon Handmade
-convention) and the curating maker (A) is *independently* credited (~10–12%) — two
-separate events, so we're never a conduit moving money from B to A (which would be
-regulated money transmission). A's credit is **non-cashable**: it draws down A's own
-future platform fees, so the more you curate, the closer your bill gets to zero
-(§7, "Referral economics"). The spread (~3–5%) is our margin. It works at **n=2** —
-two makers are enough for it to be useful, which is rare for a network feature.
+products they genuinely admire — and **only with the featured maker's approval**: B opts in
+to being curated by A, per relationship, so no one is featured against their will. On a
+referred sale two things stack. **The platform's cut is fixed and never negotiated** — a
+**3–5% spread on the order** (it may scale with the sale and carry a $ cap), the network's
+one piece of referral revenue. **Everything above it is the makers' to set:** A and B define
+A's referral reward through platform tooling — a flat percentage, a tiered rate ("x% on
+orders over $y"), a max-$ cap — and can **renegotiate** it as the relationship evolves, with
+one floor, the platform spread. So B always pays *at least* the spread; if A and B set A's
+reward to zero, **no referral money changes hands and the platform still takes its spread.**
+The two legs stay independent — B pays on B's own invoice, A is *credited* separately — so
+the platform is never a conduit moving money B→A (which would be regulated money
+transmission). A's credit is **non-cashable** (it draws down A's own future platform fees,
+so curating well drives your bill toward zero). It works at **n=2** — two makers are enough
+for it to be useful, rare for a network feature (§7, "Referral economics").
 
 **Won't paid referrals just become advertising in disguise?**
-That's the central risk, and the guardrails are structural (§3, §7). Placement is
-**reputation-staked vouching**, never **pay-for-placement** (retail media): rates are
-**uniform and non-biddable** (you can't pay to rank higher), featuring is capped per
-maker, curation is visibly personal (name + face), and it's biased toward
-*complementary* makers, not direct rivals. The name itself — *verified merchant
-referral network*, not *retail media* — is a guardrail: the moment it starts
-selling slots, it's a self-evident lie.
+That's the central risk, and the guardrail is to separate **placement** from **economics**
+(§3, §7). *Placement* is **reputation-staked vouching, never pay-for-placement**: you cannot
+buy your way into a maker's curation, the platform never sells a slot, featuring is capped
+per maker, visibly personal (name + face), gated by the featured maker's approval, and
+biased toward *complementary* makers, not rivals. The *economics* (A's referral reward) are
+a private term A and B negotiate, floored at the platform's fixed spread — but because
+placement itself is non-biddable and the curator stakes their **own audience's trust**
+(feature junk for the money and your conversions and standing erode), a richer split can't
+buy a feature it didn't earn.
+
+The subtler version: among the items a maker curates, *the platform* decides which to
+surface to a given buyer — and we **do** use algorithms (personalization, popularity) to do
+it, because lifting conversions is the job. The guarantee is that **referral economics are
+never an input to that ranking** — and it's *structural*, not a pinky-swear: because the
+platform earns the **same fixed spread no matter which referred item sells**, it has **no
+incentive** to favor a higher-paying referral, so the ranking optimizes for the buyer's
+conversion, full stop. The name itself — *verified merchant referral network*, not *retail
+media* — is the backstop: the moment it starts selling slots, it's a self-evident lie.
+
+**If I'm the maker being *featured*, do I have a say — and am I just paying to be advertised?**
+Full say — on both the placement and the price. **Nobody features you without your
+approval:** being curated by a specific maker is **opt-in, per relationship** (A can feature
+B only if B agrees), and *buyer-identity* participation is a separate opt-in on top, never
+bundled. **You and the curator set the terms** (above) — you're not handed a rate, you agree
+to one, floored at the platform's fixed spread. And you're **not paying for an ad:** you pay only on an
+*actual referred sale* — incremental business you wouldn't otherwise have had — and the
+placement itself can't be bought (a curator features you only on genuine merit, their own
+audience-trust on the line, capped, name-and-face). Being featured is a *vouch you both
+agreed to*, not a slot — which is exactly why it's worth more than an ad.
 
 **Will you ever link a buyer to my Etsy/Amazon listing?**
 Never (§7; Appendix D). The network never routes a buyer *into* a walled garden —
@@ -379,6 +407,34 @@ structure a commission-optimized incumbent *cannot* copy without betraying its o
 customers (§7, "Why this is the defensible core": Shopify won't build cross-merchant
 shared identity because its DTC merchants would experience it as theft).
 
+**What if Shopify just adds native drops and pre-orders — doesn't the tool wedge evaporate?**
+The answer depends on splitting two things both loosely called "the storefront" (§1, §3,
+§7). The **commodity surface** — cart, catalog, checkout, customer accounts — we
+deliberately *don't* build; we rent it ("build the 20%, rent the 80%," on a headless
+backend like Medusa, or federate over the maker's existing Shopify). The
+**commitment-commerce engine** — scheduled drops, raffle/queue allocation, deposits, clubs,
+made-to-order — is the part we *do* build, and the honest claim isn't that it's *hard*: it's
+that **no continuous (non-campaign) platform treats it as a first-class citizen.** Outside the
+Kickstarter-likes the table-stakes simply aren't covered first-class anywhere, so makers bolt
+the cadence onto tools that treat it as an afterthought. Being its first-class home is also the
+on-ramp to something nobody else is positioned for — wiring in the emerging generative/LLM
+maker tools (e.g. **cuttle.xyz**) that campaign platforms and stock storefronts have no reason
+to integrate, *because* they never made the cadence first-class. (It carries real
+financial/delivery liability too — taking money before delivery — which the
+out-of-the-money-flow architecture handles; but the claim is **first-class + integration
+headroom**, not difficulty.)
+
+But here's the part the doc won't dodge: **the tool is the wedge, not the moat.** The memo
+is explicit that storefront hosting isn't durably defensible — Medusa makes it cheap for
+everyone, and federation means a maker doesn't even *need* our storefront to be in the
+network (§7). The tool earns the cold-start (a real business at zero network liquidity) and
+gets makers in the door; the **durable** moat is the layer Shopify structurally *won't*
+build — the cross-maker **verified-provenance + reputation-staked curation network**, which
+its own DTC merchants would experience as theft (§3, §7, "the defensible core"). So if
+Shopify shipped excellent drops tomorrow it would neutralize a *convenience*, not the moat
+— the reason a maker stays is the network it can't copy without becoming a different
+company.
+
 **What's the architecture, in one breath?**
 Two layers, kept strictly separate (§7, "Storefront architecture"):
 - **Storefront layer (per maker)** — either our white-label storefront (built on
@@ -411,6 +467,24 @@ core (network service, ledger, verification) must be **funded, documented, and m
 than one person deep** — not bus-factor-one. The fragile-perception risk with
 professional makers is real and is something discovery explicitly tests (§8).
 
+**What happens to *my* drop if the platform goes down at 9am Saturday?**
+The honest answer has an architectural half and a staffing half. **Architecturally, the
+blast radius is small for most makers:** you are merchant of record on *your own* processor,
+and if you federate your existing Shopify store your drop and checkout run on *Shopify's*
+infrastructure — so if our cross-tenant network service is down, what degrades is *network
+features* (Curated-By, the buyer feed, the agent feed), **not your ability to take the
+order.** The sale doesn't ride on the moat layer. **Operationally,** for a maker on our
+white-label storefront the drop *does* run on our infrastructure — which is exactly why
+network-service uptime, the money-adjacent ledger, and verification are the **funded,
+documented, more-than-one-deep reliability core** (§12), explicitly *not* volunteer
+best-effort and *not* bus-factor-one. Drops are spiky by nature, and "a storefront falling
+over *during* a drop is the worst possible moment for maker trust" (§7, Hosting) — so the
+spike is designed for (autoscaling infrastructure, load-checked before a real drop), and
+the on-call reliability of those pieces is a **budget line, not a hope.** What the doc won't
+pretend: this is the single point of failure §4 names, so the reliability core is bound with
+structure (funded + redundant), and the fragile-*perception* risk with professional makers
+is something discovery explicitly tests (§8).
+
 **Who decides what "verified" means — and who watches the watchers?**
 Two answers, by time horizon (memo §14 #1 — direction set, mechanics deliberately
 deferred):
@@ -550,9 +624,22 @@ break-even is driven by keeping F lean (the LLM-deflated-cost bet) and by makers
 *graduating and referring*, not merely by adding low-GMV makers; (2) there's also a
 *ceiling* — earn too much, too commercially, and a non-profit risks **UBIT**
 (Unrelated Business Income Tax) or its exemption. An illustrative pass (explicitly
-*shape, not validated values*) puts break-even around **~150–300 makers**, well past
-the **dozen-maker** validation gate — and naming that gap is the point. The numbers
-are variables because n=2 can't calibrate them yet.
+*shape, not validated values*, §12) puts the fixed reliability floor at **F ≈
+$75–150k/yr** — funded core ops + the fee/wallet ledger + the verification audit +
+hosting — and break-even around **~150–300 makers**, where the revenue mix has flipped from thin
+Starter percentages to Pro flat fees + referral spread (≈$170k/yr at ~200 makers under
+those midpoints), well past the **dozen-maker** validation gate — and naming that gap is the
+point.
+
+The number a CFO will press on is F, so the doc is blunt about it: **F is not the cloud
+bill.** The seductive error is to model F as the pilot's tens-of-dollars-a-month GCP
+invoice; the honest F is dominated by **compensated, documented, more-than-one-deep
+ownership** of the reliability core — network-service uptime, the money-adjacent ledger,
+the verification audit — none of which can be best-effort. Under-modeling F is exactly how
+an org clears break-even *on paper* and still dies of bus-factor (§4). The
+LLM-deflated-cost bet is that F can be kept **lean, not that it's near-zero** — and the
+numbers stay variables because n=2 can't calibrate per-maker GMV, churn, or graduation rate
+yet.
 
 **How will you know if it's working?**
 One **North Star: the share of GMV that is cross-maker-referred** (§12). It's near-