wiggleverse/wiggleverse-ecomm-content
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: flesh §10 into full Trust & safety & maker accountability section

Browse Source 
Promote backlog #1's settled shape into a full §10 (parallel to §11), leaving
only the OHM-guided reputation engine + adjacent frameworks as open work.

- §10 sections: the originating edge (trust topology); how reputation flows up
  the edge (decayed, hop-capped, positive-reinforcement framing); consequence =
  loss of standing not expulsion (transparency-as-enforcement, "gate the demand
  not the tool"); authority & appeal (inviter primary, platform floor for active
  harm, governance appeal path, provenance lies as trust violations, legal spine
  in §11); and a "Still open" subsection gathering the OHM-guided reputation
  engine, revocation triggers, dispute framework, out-of-flow non-delivery
  (not guarantor), and false-report/collusion controls.
- Backlog #1 reduced to a pointer to §10, flagging the open engine as the
  recommended next session.
- Re-pointed refs that targeted the old §12 #1 (top-of-file note, §11 ghosting
  cross-ref) to §10.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ben Stull
2026-06-15 05:52:15 -07:00
parent 2f4c3be578
commit ed4b6dbc60
1 changed files with 38 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/maker-platform-strategy.md
+38 -12
View File
@@ -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 (and §12 #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.
---
@@ -346,9 +346,42 @@ Two makers justify a thoughtful, portable data model. They do not justify a plat
---
## 10. Trust & safety & maker accountability (reserved)
## 10. Trust & safety & maker accountability
*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.
Verification (§7) is only an *entry* gate — it answers "is this a real maker of original work?" at the door. This section is the other half: **what happens when a verified maker behaves badly afterward.** Commitment commerce makes this the *signature* failure mode, not an edge case — "a verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, because the model takes money before delivery (§4). The money-flow stance solved the *financial* exposure (the maker is MoR, so the platform never holds the funds at risk — §7), but it did **nothing** for the *reputational* exposure — and the reputational one is the exact thing the moat rests on. A single polluted "verified" item breaks the guarantee for every buyer and every agent downstream.
The **shape** below is settled; the **reputation engine itself is explicitly OHM-guided work** (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)) and is gathered in the last subsection. This whole section turns on OHM concepts — **reputation, trust, harm, recourse, value, dignity** — so where it names one, the canonical RFC governs: cite it, propose it where undefined, don't coin a local meaning.
### The originating edge — the trust topology
- **Every maker enters by invitation, and the invitation *is* a vouch** that the invitee makes original art or craft — rooted in a staff-verified seed set (§7 verification). The invitation graph is a **permanent topology**: every maker traces back, by some chain of vouches, to a root the platform verified directly. (The membership gate starts invitation-only and loosens toward open signup over time — §7 — but the originating edge persists as graph structure even after the front door opens.)
- **Inviting doesn't pay.** The incentive to invite is the commercial relationship the network creates, **never a bounty** — a per-invite payout would manufacture exactly the Sybil/farming incentive the rooted graph exists to resist. You invite people whose work you'd stake your standing on, because that is what the edge means.
### How reputation flows along the edge
- **Reputation flows *up* the originating edge** — when a maker misbehaves, consequence propagates back toward whoever vouched for them — but **transitively, decayed (a per-hop coefficient), and hop-capped.** So the impact is **strong right next to the misbehavior** (a prompt-to-act for the inviter who actually can act) and **negligible by ~6 degrees out** (a distant root isn't punished for a great-great-invitee's fraud).
- **Framed as positive reinforcement, not punishment.** The primary direction is *earning and growing standing* by vouching well and making well; the up-the-edge consequence is the downside tail of that same mechanism, not a separate penalty system. Good vouching compounds standing; a bad vouch costs the voucher (this is the §7 verification "slashable stake," seen from the accountability side).
### Consequence: loss of standing, not expulsion
- **The consequence is a low, buyer-visible reputation score + loss of all network benefit** (Curated-By, the buyer feed, referrals, the agent feed) — **not expulsion.** The misbehaving maker **keeps the storefront and the tool** (they are a paying SaaS customer, and the tool was never the thing gated — "gate the demand, not the tool"), but **loses amplification** and **wears a score buyers can act on.** This is *transparency as enforcement*: rather than policing every maker centrally, the network makes standing legible and lets buyers route around bad actors — which keeps the trust surfaces clean *by construction*, since a low-standing maker has already fallen out of Curated-By / feed / agents.
- **This is a "member in bad standing," not the rejected model "a."** It is emphatically **not** flat "anyone can verify anyone" (§7 warns against that). At launch every storefront holder was *invited*, so even a maker in bad standing entered through the rooted graph — they are a member who lost standing, not an anonymous bad actor who slipped the gate.
### 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 #7) 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.
### Still open — the OHM-guided reputation engine (and adjacent frameworks)
The **shape** above is settled; the **system** that implements it is the open work, and it is OHM-guided by nature:
- **The reputation engine itself** — scoring, the decay-coefficient and hop-cap *values*, how good standing accrues over time, how the score is *displayed* to buyers, and the benefit-gating thresholds (what score loses Curated-By vs. the feed vs. agents) — all turn on operationalizing OHM **reputation, trust, harm, recourse, value, dignity**. Defer to the relevant RFCs; propose them where undefined (a load-bearing concept OHM hasn't defined is itself OHM work, not license to improvise — top-of-file note).
- **Verification-revocation triggers and process** — the concrete patterns that drop a maker's standing or revoke verification (non-delivery pattern, inauthentic/AI-generated goods passed as handmade, sustained non-response), and the process around each.
- **The buyer-harm / dispute framework** — how a buyer reports harm, how it's adjudicated, and the recourse on each side.
- **Non-delivery handling, given the platform is out of the flow** — the platform is **not a guarantor** (it holds no funds to refund from); the buyer's monetary recourse is a chargeback against the maker's own processor (maker is MoR), and the platform's contribution is *transparency* (the score, the public consequence) plus the §11 compliance UX — not an escrow it deliberately declined to hold.
- **False-report and collusion controls** — the abuse surface of the accountability system itself (weaponized reports, retaliatory low scores, collusion rings), instrumented from day one alongside the §7 verification ring-detection.
---
@@ -395,7 +428,7 @@ The raffle drop is the one primitive (§4) with direct **gambling-law** exposure
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.)
- **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 §10 "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
@@ -429,14 +462,7 @@ Recap the §7 consent architecture, now read as the privacy-law posture.
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; §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.
- **Consequence = a low, buyer-visible reputation score + loss of all network benefit (Curated-By, feed, referrals, agents) — not expulsion.** The maker keeps the storefront/tool, loses amplification, and wears a score buyers can act on (transparency as enforcement; keeps trust surfaces clean by construction). This is a *member in bad standing*, **not model "a"** — at launch every storefront holder was invited.
- **Inviter holds primary suspend/expel authority** over their sub-graph, with a **platform floor for active buyer harm** and a **governance appeal path** (#7); expulsion is the rare extreme. Misclassifying provenance is a trust violation (§7 per-item provenance).
**Still to flesh out — explicitly OHM-guided (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)):** the reputation *system* itself — scoring, the coefficient/hop-cap values, how good standing accrues, display, benefit-gating thresholds, and how *harm* and *recourse* are operationalized — turns on OHM concepts (**reputation, trust, harm, recourse, value, dignity**); defer to the relevant RFCs and cite them, proposing them where undefined. Also still open from the original scope: verification-revocation triggers/process (non-delivery pattern, inauthentic goods, non-response), the buyer-harm/dispute framework, non-delivery handling given you're out of the flow (chargeback-via-maker-MoR + transparency, not guarantor), and false-report/collusion controls.
1. **Trust & safety / maker accountability — shape written up this session (now §10); reputation *engine* remains OHM-guided open work.** The settled shape — originating-edge invitation graph, reputation flowing *up* that edge (decayed, hop-capped), consequence = a low buyer-visible score + loss of network benefit rather than expulsion, inviter-held authority with a platform floor and a governance appeal path — is now **§10 (Trust & safety & maker accountability)**. What stays open is gathered in §10's last subsection and is the **recommended next session**: the OHM-guided reputation *engine* (scoring, coefficient/hop-cap values, standing accrual, display, benefit-gating thresholds, operationalizing *harm*/*recourse*), plus verification-revocation triggers/process, the buyer-harm/dispute framework, non-delivery handling out-of-flow (chargeback-via-maker-MoR + transparency, not guarantor), and false-report/collusion controls.
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.