Defensive Data Design
🔗 **Source:** [Defensive Data Design](https://make.wordpress.org/core/2026/08/04/defensive-data-design/)
> [!note]+ Document Notes
> tags: [wordpress-core, ai-agent-safety, ux-defaults, data-design, product-design]
> author: Matt Mullenweg
> source: Make WordPress Core (make.wordpress.org)
> reference: https://make.wordpress.org/core/2026/08/04/defensive-data-design/
> date created: 2026-08-14 00:00
>
> > [!info] Generated analysis — not the author's words. Sections below are machine-written
> > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author.
> > Do not quote or attribute any other line to the named author.
>
> # 🏷️ Title: Defensive Data Design
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Not applicable to this source — the post contains no outbound links.
## 📝 Summary
- **What happened.** A short post on Make WordPress Core lays out design principles for making software defaults safer as AI agents take on more direct actions within WordPress (and software generally).
- **Why it matters.** As agentic AI tooling (including WordPress's own Core AI initiatives and the newly-launched official browser extension) gains the ability to act on a user's behalf, the cost of a wrong or destructive action rises. This post frames a defaults-first design philosophy: make safe actions easy and destructive actions hard.
- **Key stakeholders.** WordPress Core contributors/designers (implementers); end users and site owners (protected by safer defaults); AI agents/tooling built on top of WordPress (the actors these defaults are meant to constrain).
- **Risks and tradeoffs.** None stated explicitly — this is a principles list, not an implementation plan, so there's no discussion yet of tradeoffs (e.g., added friction for legitimate power users, or the engineering cost of implementing reversibility everywhere).
- **Bottom line.** A concise, actionable checklist for defensive UX/data design in an agent-driven future: reversible-by-default, hard-to-destroy, transparent, and plainly explained.
## 📖 Main Content
- The core framing question: "As we go into a world where agents will be doing more things, how can we make the defaults as safe (and secure) as possible?"
- Ten specific design principles follow, covering: reversibility (trash vs. delete, draft vs. publish), visibility of changes, legibility of underlying data, actionable/copyable error messages that explain *why* not just *what*, graceful failure that minimizes harm, treating all input as potentially hostile (not just unreliable), using available UI space to show information directly, and plain, natural (even fun) language throughout.
### 🗒️ Notes
- Not a transcript — a short principles post; dense notes without timestamp subheadings, per template.
- The list reads as a preemptive design response to agentic AI risk: several items (hard-to-delete, reversible, visible changes) specifically address the failure mode of an AI agent taking an unintended destructive action faster than a human would.
- One item stands out as AI-specific rather than general UX practice: "have a copy-to-clipboard next to [error messages], so people can put into search/AI/whatever" — an explicit acknowledgment that users now routinely hand error text to AI tools for help.
## 📚 References
- Not applicable to this source — no external references or citations in the post itself.
## 🗣️ Paraphrase
- The post asks how software defaults should change as AI agents take on more autonomous action, then answers with ten principles: make destructive actions harder than reversible ones, keep changes visible and undoable, make underlying data legible, write error messages that explain the reason and are easy to copy elsewhere (including into AI tools), fail in ways that limit harm, treat all input as potentially hostile, use available screen space to show information rather than hide it behind clicks, and keep language plain and human.
## 📰 Newsletter
- **Quick hit for WordPress Core watchers.** Matt Mullenweg posted a short but sharp design checklist for the agentic-AI era: trash should be easy, deleting should be hard; drafts should be easy, publishing should be hard; error messages should explain *why*, not just *what*, and should be copy-pasteable straight into an AI tool. It's a preview of the design thinking likely to shape how WordPress Core and the new AI-native browser extension handle agent-driven actions going forward.
## ✅ Action Items
#### DevRel
- Developer advocacy: N/A — this is an internal design-principles post, not a developer-facing announcement.
- Education: could inform guidance for plugin/theme developers building agent-facing features on defaults and reversibility.
- Developer experience: directly relevant — these principles could become review criteria for any WordPress feature that exposes actions to AI agents.
- Developer marketing: N/A.
- Community management: N/A.
- Internal/external/cross-project: N/A.
#### OSPO
- Policy & Governance: N/A.
- License Compliance: N/A.
- Security Management: directly relevant — "assume everything is not just unreliable, but actually hostile" is a security-by-design principle worth folding into any AI-agent-facing WordPress security guidance.
- Software Inventory: N/A.
- Developer Support: N/A.
- Community Engagement: N/A.
- Strategic Alignment: N/A.
#### Community
- Maintainers: relevant as a design-review lens for any Core feature touching agent-facing actions.
- Contributors: N/A.
- Sponsors: N/A.
- Ecosystem: N/A.
#### WordPress
- Core: directly relevant — this is a Core blog post proposing design principles likely to shape upcoming Core AI feature reviews.
- Core Performance: N/A.
- Core AI: directly relevant — the primary intended audience for these defaults.
- Core Program Team: N/A.
- Mobile: N/A.
- Playground: N/A.
- Community: N/A.
- Training: N/A.
- Marketing: N/A.
- Support: relevant — clearer, more actionable error messages (per the "why not just what" principle) could reduce support burden.
- Design: directly relevant — this is fundamentally a UX/design-systems post.
- Documentation: N/A.
- Photos: N/A.
- TV: N/A.
- Polyglots: N/A.
- Accessibility: tangentially relevant — plain language and legible data presentation overlap with accessibility goals.
- Meta: N/A.
- CLI: N/A.
- Hosting: N/A.
- Tide: N/A.
- Openverse: N/A.
- Themes: N/A.
- Plugins: relevant — plugin authors building agent-facing features should consider these defaults.
#### The WPOCC
- Programs: N/A.
- Projects: N/A.
- Funding experiments: N/A.
### FAIR
- Technical independence: N/A.
- Policies and covenants: N/A.
- Productized governance artifacts: N/A.
## 🧪 Hypotheses
- H1: WordPress features implementing these defensive-design defaults (harder-to-delete, reversible-by-default) will show measurably fewer support tickets related to accidental data loss than features that don't.
- H2: Error messages that explain "why" and include a copy-to-clipboard action will reduce time-to-resolution for AI-assisted troubleshooting compared to traditional error messages.
### 📊 Methodology
- H1: comparative support-ticket analysis across WordPress Core features before/after adopting reversible-by-default patterns.
- H2: user study timing troubleshooting tasks with and without copy-to-clipboard, explanation-inclusive error messages, using an AI assistant to resolve the error.
### ❓ Questions
- Which specific upcoming WordPress Core AI features will these principles apply to first, and will they be codified as formal review criteria?
- How do these defensive-design defaults interact with performance/complexity costs (e.g., is full reversibility always feasible at WordPress's scale)?
- Does "assume everything is hostile" extend to AI-generated content/actions themselves, or only to external network/data input?
### 🔮 Future Research
- Track whether these principles get formalized into an actual WordPress Core design-system document or PR review checklist.
- Compare WordPress's agent-safety defaults against other major CMS/platform approaches to agentic AI risk (e.g., how other publishing platforms handle AI-agent-initiated destructive actions).
### 💡 Implications
- **Practice:** plugin/theme developers building AI-agent-facing features should treat this list as a practical starting checklist.
- **Policy:** could inform a future formal WordPress Core guideline or handbook page on AI agent safety.
- **Security:** the "assume hostile" and "fail gracefully" principles are directly security-relevant as agentic actions become more common attack/failure surfaces.
- **Education:** useful teaching example for "defaults matter" in software design curricula.
- **Funding:** N/A.
### 🧠 Learning Styles Assessment
- **Reading level estimate:** approximately Flesch-Kincaid grade 8 (short, direct sentences and bullet points).
#### 👀 Visual learners
- Present: Not applicable to this source — plain text/bullet list, no diagrams.
- Improve: a visual before/after mockup contrasting a "destructive default" UI with a "defensive default" UI would help.
#### 🔊 Aural learners
- Present: none — text only.
- Improve: N/A for a short principles post.
#### 🗣️ Verbal learners
- Present: strong — each principle is stated as a clear, parallel-structured maxim.
- Improve: N/A, already well-suited to this learning style.
#### 🧩 Kinesthetic learners
- Present: none — no hands-on exercise.
- Improve: a companion checklist/audit template developers could apply to their own features.
#### 🧠 Logical learners
- Present: strong — clean bulleted list of discrete, testable principles.
- Improve: N/A, already well-organized.
#### 🧑🤝🧑 Social learners
- Present: Not applicable to this source — no discussion prompts or community framing.
- Improve: N/A.
#### 🧘♀️ Solitary learners
- Present: good — short, self-contained, quickly skimmable.
- Improve: N/A.
#### 🌿 Naturalistic learners
- Present: Not applicable to this source.
- Improve: N/A.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: standard paragraph/list markup (`<ul>`/`<li>`), which is good semantic structure for a list of principles.
- Improve: N/A from captured HTML.
#### Keyboard navigation
- Present: Not applicable to this source — static text, no interactive elements.
#### Contrast and readability
- Present: not assessable from captured HTML (no CSS).
#### Text resizing and reflow
- Present: not assessable from captured content.
#### Media and captions
- Present: Not applicable to this source — no media.
#### Forms and interactions
- Present: Not applicable to this source — no forms.
#### Standards reference
- No WCAG 2.2 AA gaps identifiable from the captured semantic HTML.
### 🌍 DEIB Assessment
#### Cultural breadth
- Not applicable to this source — a technical design-principles post with no cultural/regional scope.
#### Inclusive language
- Present: plain, direct, jargon-light language — consistent with the post's own "plain language, make it obvious, natural" principle.
#### Neurodiversity support
- Present: strong — short bulleted list, parallel structure, low cognitive load.
#### Representation
- Not applicable to this source.
#### Psychological safety
- Present: neutral, constructive tone throughout.
### ✅ Logical Validity
#### Strong reasoning
- **Practicing what it preaches:** the post itself follows its own stated principle of "plain language, make it obvious, natural" — the writing models the design philosophy it advocates. Location: throughout. This is a coherent, self-consistent piece of communication.
#### Fallacies
- None identified. This is a design-principles list, not an argument advancing a contestable claim — there's no persuasive/rhetorical structure to evaluate for fallacies.
#### Tone of voice
- Direct, practical, prescriptive — a working list of design maxims rather than a persuasive essay.
## 🛡️ DARVO Analysis
- Not applicable to this source. DARVO analysis applies to rhetoric defending against an accusation; this is a forward-looking design-principles post with no accusation, denial, or victim/offender framing present.
## 🎯 Conclusion
- **Bottom line:** a concise, well-organized checklist for making software defaults safer as AI agents gain more autonomous action within WordPress — reversibility, visibility, legibility, and plain language are the throughlines.
- **Practical next steps for readers:** WordPress plugin/theme developers building agent-facing features should treat this list as a starting design-review checklist; watch for whether Core formalizes these principles into an official guideline.
## 🔄 Refactor Appendix — Defensive Data Design
> Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4).
> Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't
> articulate in one line why a claim matters, drop it.
>
> Konik claim-header rules: present tense, declarative, ≤10 words when
> possible, searchable, unique, mirrors annotation focus if present.
>
> Atomicity: one declarative sentence per atom. "and"/"also" → split.
>
> Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms
### 📚 Literature Atoms (H3)
#### [H1] Deleting should be hard; trashing should be easy
> [!quote] ID:rw_wpdefensive_trash
> "Putting something in the trash should be easy; deleting should be very hard."
**Context & use**:
- Core design principle, first bullet of the list.
- Directly applicable to any WordPress feature exposing destructive actions to AI agents.
**Tags**: #xref
**Highlight**: [view highlight](readwise://)
<!-- atomicity: 1 idea ✓ -->
#### [H2] Error messages should explain why, and be copyable into AI tools
> [!quote] ID:rw_wpdefensive_errors
> "Error messages should be how you'd describe it to a friend. And have a copy-to-clipboard next to it, so people can put into search/AI/whatever."
**Context & use**:
- Acknowledges that users now routinely hand error text to AI assistants for troubleshooting.
- Practical, immediately actionable UX pattern.
**Tags**: #xref #articleseed
**Highlight**: [view highlight](readwise://)
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] Design defaults should assume hostile, not just unreliable, input
**Claim** (one sentence, Courtney's voice): As AI agents take more autonomous action inside software, defaults should assume that inputs and actions may be actively hostile, not merely unreliable, and should be built to fail gracefully and reversibly by default.
**Evidence pointer**: [[#H1]]
**Scope & conditions**: Applies broadly to any software exposing actions to AI agents, not just WordPress; less relevant for fully human-gated, low-autonomy interfaces.
**Links** (≥1 with annotation):
- [[AI agent safety]] — because extends
- [[WordPress Core AI]] — because applies-in Core feature design review
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Watch for whether these principles get formalized into an official WordPress Core handbook page or PR review checklist. #xref
### → Things 3 (max 2 actions)
- [ ] Note this checklist as a reference for reviewing any future WordPress agent-facing feature design — context: WordPress Core AI tracking #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/Defensive Data Design.md|Defensive Data Design by Matt Mullenweg]]
## Highlights
- As we go into a world where agents will be doing more things, how can we make the defaults as safe (and secure) as possible? Some points to consider: ([View Highlight](https://read.readwise.io/read/01m00656xe85aac47wvtvqgv1j))
- Note: Framing question for the whole post -- defaults-first design philosophy as AI agents gain autonomous action.
- Tags: atom/literature/h1