# Ship Primitives Not Defaults for High-Legal-Risk Features ## Claim When a feature carries irreversible legal or trust risk, a platform should ship the underlying primitives and let downstream implementers own the default experience, rather than picking one default for everyone. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when downstream implementers (hosts, plugin authors) have real UX research capacity to assemble a good default from the primitives. - Breaks down when the ecosystem lacks that capacity — the primitives may never get assembled into a usable default for most sites, effectively vanishing the feature for anyone without a sophisticated host or plugin. - Specific to features where the risk lives in the default choice itself (e.g., collaborative editing sitting next to a live Publish button instead of inside a Google-Doc-style draft container), not to features where the risk is uniform regardless of who assembles the default. ## Evidence WordPress 7.1's release lead described a mid-release pivot away from shipping a default real-time-collaboration transport, after 7.0's more turbulent collaborative-editing push. Instead, core ships the underlying tools and leaves hosts or plugins to assemble them into a working default — deferring the decision of what "safe by default" looks like to whoever has the context to make it for their specific userbase. > [!quote] > what if core provided uh the tools, but then a host or plugin could just put them all together and make it work essentially ## Links - [[3. Resources/Permanent Notes/Primitive-First Design Absorbs Conflicting Feedback Without Scope Creep]] — because contrasts on the trigger condition; that note's primitive-first move responds to conflicting user feedback about a product feature, this one responds to a platform's own risk-tolerance decision about defaults, not to a demand conflict - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — because extends; both describe core choosing to ship a neutral primitive layer rather than a single opinionated interface - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — because applies-in; a specific case of a broader release-governance and risk-deferral pattern worth tracking across releases - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Joins WordPress core design decision notes. ## Tests / falsifiers - If a majority of WordPress hosts and popular plugins never actually assemble the collaborative-editing primitives into a shipped default within a year or two of 7.1, that supports the "breaks down without ecosystem capacity" scope condition — the feature effectively vanished rather than being safely deferred. - Compare this to a WordPress core feature that shipped a single default despite similar risk (if one exists) — if that default caused fewer real-world problems than the primitives-only approach predicted, the claim's risk premise needs revisiting. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/Why WordPress 7.1 Will Improve Your Workflow]] — Ann McCarthy's account of the collaborative-editing primitives-vs-default pivot.