From 25c26592cb1b45ea9bd40cdd14d8ff3804409b9c Mon Sep 17 00:00:00 2001 From: Ben Stull Date: Mon, 15 Jun 2026 12:59:25 -0700 Subject: [PATCH] =?UTF-8?q?docs(maker-platform):=20flag=20the=20audit's=20?= =?UTF-8?q?unaddressed=20gaps=20as=20honest=20backlog=20items=20(memo=20?= =?UTF-8?q?=C2=A714=20+=20PR-FAQ)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Gap-analysis pass surfaced genuine, *unacknowledged* holes in both docs. Rather than invent legal/strategy positions, flag them as scoped open work in the memo's §14 backlog (matching its style) and acknowledge them in the PR-FAQ's 'what got left out' answer: - international tax & cross-border (EU VAT/OSS, deemed-supplier, PSD2/SCA, KYC/OFAC) — the US-only §11 has a real hole under a digital-heavy global beachhead - infosec & breach posture for the cross-tenant graph (belongs in the §12 funded reliability core) - content moderation beyond authenticity (third-party IP / DMCA) - verification *methodology* (the evidentiary act, treated as a primitive) - support/dispute operations as a funded F-term - competitive engagement vs creator-commerce tools (Gumroad/Payhip/Ko-fi/ Fourthwall/Lemon Squeezy) - plus lower-priority notes (cuttle substance, catalog-sync at scale, accessibility, certification mark, wind-down plan, team capacity) Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/maker-platform-pr-faq.md | 13 ++++++++++--- docs/maker-platform-strategy.md | 14 ++++++++++++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/docs/maker-platform-pr-faq.md b/docs/maker-platform-pr-faq.md index 13e0ea1..e22f6bb 100644 --- a/docs/maker-platform-pr-faq.md +++ b/docs/maker-platform-pr-faq.md @@ -785,7 +785,14 @@ cost. It's the hedge against the buyer feed's deliberate weakness at net-new rea The memo's full depth on trust-&-safety/accountability (§10), the complete legal/compliance analysis (§11), composite multi-maker kits (Appendix C), the beachhead-selection method and worked example — miniatures → dice → broad tabletop -(Appendix A), and the crowdfunding-incumbent landscape (Appendix B). A technical -reader who wants the real architecture should read the -[strategy memo](./maker-platform-strategy.md) directly — this document is the +(Appendix A), and the crowdfunding-incumbent landscape (Appendix B). Also **honestly +unfinished** and tracked as open work in the memo's backlog (§14): the **international +tax / cross-border** posture (the legal analysis is US-only today, under a digital-heavy +global beachhead), **information security & breach posture** for the cross-tenant graph, +**content moderation beyond authenticity** (third-party IP / DMCA), the **verification +*methodology*** (how a verifier actually confirms original work), **support/dispute +operations** as a funded function, and a head-to-head against the **creator-commerce +tools** (Gumroad/Payhip/Ko-fi/Fourthwall). A technical reader who wants the real +architecture — and the honest open edges — should read the +[strategy memo](./maker-platform-strategy.md) directly; this document is the elevator version, not a replacement. diff --git a/docs/maker-platform-strategy.md b/docs/maker-platform-strategy.md index c918eee..4447cac 100644 --- a/docs/maker-platform-strategy.md +++ b/docs/maker-platform-strategy.md @@ -650,6 +650,20 @@ This memo is deep on the architectural/strategic axes (money flow, network mecha 2. **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). +3. **International tax & cross-border operation (US-only today — flag for specialist counsel).** §11's analysis is entirely US (the *Wayfair* facilitator test, MTL, FTC). But the beachhead is **STL/digital-file-heavy and globally distributed** (UK/EU/AUS casters), so this is a *live* hole, not a someday: **EU/UK VAT on digital goods** (OSS/IOSS — VAT owed in the buyer's country from the first unit) and the EU **"deemed-supplier"** marketplace rule, which can pull a *facilitating* platform into VAT collection on logic that **does not mirror** the US "we fail prong 2" defense — so the out-of-flow stance does not automatically transfer abroad. Adjacent: **PSD2/SCA** on EU recurring club billing (the maker's processor must handle it; a "Standard account" doesn't discharge it), multi-currency display/settlement, and **KYC/AML/OFAC** onboarding for non-US makers/taste-makers on the Phase-2 cashable rail. *Direction: scope which jurisdictions Phase 1 actually serves, and put the VAT/deemed-supplier question to specialist cross-border counsel before international participants are first-class. Flag and verify — not legal advice.* + +4. **Information security & breach posture for the cross-tenant network service.** §7/§11 cover privacy *consent* thoroughly; neither covers *security*. The shared network service holds the single most attractive breach target in the design — **every maker's full order history + buyer PII + the cross-maker identity graph** — and for a *trust* brand a breach is existential, not merely costly. Still open: encryption at rest/in transit + key management, tenant-isolation and least-privilege access to the cross-tenant store, secrets handling, and an incident-response / breach-notification plan (state laws + the GDPR 72-hour clock). *Direction set here: infosec of the network service belongs in the §12 **funded reliability core** alongside the ledger and the verification audit — a trust-moat budget line, not a volunteer-cadence nice-to-have; the concrete controls are later work.* + +5. **Content moderation beyond authenticity (third-party IP / DMCA / prohibited goods).** Provenance verifies *handmade*, not *lawful to sell*. The minis/tabletop beachhead carries a heavy **third-party-IP/DMCA** load (fan-sculpts of others' IP; the Games Workshop takedown culture), plus counterfeit, regulated, and offensive-content surfaces — and the network *amplifies* whatever it surfaces (Curated-By, the buyer feed, the agent feed), so it inherits **amplification / contributory liability** distinct from "is it handmade." Still open: a DMCA §512 notice-and-takedown posture + designated agent, an IP-complaint / repeat-infringer policy, and the line between *verified original craft* and *originality of the depicted IP* (a verified maker can still infringe). Interacts with verification (§7) and accountability (§10). *Flag for counsel; design the takedown path before the agent feed amplifies at scale.* + +6. **Verification methodology — the evidentiary act (currently treated as a primitive).** §7 specifies the verification *graph* (rooted, staked, multi-vouch, sampling audit) and §10/#1 above defer the reputation *engine* — but **how a verifier actually establishes that a human makes original work** (what proof, what process, what staff and peers inspect) is neither specified nor flagged, and it is the literal foundation of the trust moat and the §11 FTC-substantiation claim — the hard adversarial core in an AI-fake world. Still open: the **provenance-documentation standard** (studio evidence, work-in-progress, live demo?), the staff seed-set method, and what a peer verifier must attest. *Name it as load-bearing open work, not a solved primitive.* + +7. **Support & dispute operations — the function and its cost.** §12 funds the reliability core (uptime, ledger, verification audit) but never a **support/ops function**: maker tickets (a broken sync at drop time), buyer-harm report intake, and the verification-revocation / appeal queues (§10). For a volunteer-built, money-adjacent, trust-critical platform this is a real recurring **F-term omission** and an operational-credibility question. *Still open: the support model, triage/SLAs for money-adjacent vs cosmetic issues, and its line in the §12 cost base.* + +8. **Competitive engagement: creator-commerce tools.** The "no continuous (non-campaign) platform treats commit-then-make as first-class" claim (§2) is load-bearing and currently engages only Etsy/Shopify/Patreon/Kickstarter/Gamefound. The sharper counter-examples a skeptic raises are the **creator-commerce tools** — Gumroad, Payhip, Ko-fi Shop, Fourthwall, Lemon Squeezy — several of which already do drops + memberships + digital delivery at low fees. *Still open: a head-to-head that substantiates "first-class, not covered" against these specifically — the likely cut being that each does the storefront/transaction but none does the cross-maker reputation-staked referral network (the moat), and most treat the cadence as features rather than the spine; verify the claim rather than assert it.* + +9. **Lower-priority flagged items (named, not yet developed).** (a) **cuttle.xyz / generative-tool integration** is cited as a differentiator (§2) without substance — develop what the integration is and why it's defensible, or demote it to a mere example. (b) **Catalog-sync reliability at scale** — N adapters against rented APIs (Shopify rate limits, webhook-delivery failure, deprecation cycles, reconciliation) is a chronic ops burden the moat surfaces depend on. (c) **Accessibility** (WCAG/ADA) for generated storefronts and the buyer feed — a compliance surface and an OHM-*dignity*-aligned one. (d) **Trademark / certification mark for "verified"** — a certification mark is the natural instrument to protect the badge from imitation (FTO/patent is covered in §11; this isn't). (e) **Platform wind-down plan** for the network asset — given volunteer-sustainability is the named #1 risk (§4), what becomes of the cross-maker graph, follows, buyer accounts, and outstanding wallet credits/payables if the org folds. (f) **Team / execution capacity** — the docs argue the model is *affordable*; named team/board/recruiting capacity is a separate, unaddressed question (arguably a roadmap/ops-doc concern more than a strategy one). + --- ## Appendix A — Choosing a beachhead vertical (and sequencing expansion)