Merge Proposal: Guidelines Built on Knowledge  🔗 **Source:** [Merge Proposal: Guidelines Built on Knowledge](https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/) > [!note]+ Document Notes > tags: [wordpress-core, custom-post-types, ai-content-tooling, rest-api, content-governance, open-source-governance] > author: Make WordPress Core > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/ > date created: 2026-06-22 00:00 > > # 🏷️ Title: Merge Proposal: Guidelines built on Knowledge > <!-- 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 - [Content Guidelines: a Gutenberg experiment](https://make.wordpress.org/ai/2026/02/03/content-guidelines-a-gutenberg-experiment/) - [Guidelines lands in Gutenberg 22.7](https://make.wordpress.org/ai/2026/03/23/guidelines-lands-in-gutenberg-22-7/) - [Consolidated design issue (gutenberg#77230)](https://github.com/WordPress/gutenberg/issues/77230) - [Core patch (wordpress-develop#12201)](https://github.com/WordPress/wordpress-develop/pull/12201) - [Trac #65476](https://core.trac.wordpress.org/ticket/65476) ## 📝 Summary - What happened: A merge proposal to bring a new `wp_knowledge` custom post type into WordPress core for the 7.1 release, with Guidelines as the first feature built on it. - Why it matters: It gives sites a canonical, core-owned place to store author-facing and agent-facing standards (voice, tone, image rules, per-block rules) instead of scattering them across plugins, documents, and wikis. - Key stakeholders: WordPress core contributors, plugin authors, AI tool builders, multi-author site owners, writers and editors. - Risks and tradeoffs: Names freeze at 7.1 Beta 1 (July 15), locking the post type, taxonomy, REST routes, capabilities, and type slugs as long-term compatibility commitments. The open question is whether the API is ready to stabilize. - Bottom line: Core ships a storage primitive plus access policy, not intelligence — no AI provider, model, retrieval, or memory architecture. The community decides what to build on it. ## 📖 Main Content - The proposal introduces Knowledge as a general primitive: a `wp_knowledge` post type with a `wp_knowledge_type` taxonomy, standard roles and capabilities, native revisions, and REST access. - Guidelines is the first consumer, giving site owners a first-class place to capture the standards that shape how content is written and edited. - The core argument is anti-fragmentation: without a shared primitive, every plugin ships its own storage, permissions model, and REST surface. Core has historically prevented exactly this with `wp_template`, `wp_block`, and `nav_menu_item`. - Naming rationale: "Knowledge" covers both procedural content (how work should be done) and declarative content (what is known), where "Guideline" fits prescriptive records but not memories or notes. Knowledge names the namespace; records are referred to by concrete type. The WP Admin feature stays "Guidelines," the same way the `attachment` post type surfaces as Media. - Three built-in types ship: `guideline` (a standard, pure source-of-truth text), `memory` (durable context explicitly saved/approved, private and author-owned), and `note` (private freeform working text; the default when no type is given). - Guideline scopes (Site, Copy, Images, Blocks) define the Settings → Guidelines sections; each scope is a `guideline` record at a reserved slug like `guideline-copy`. Scopes are addressed by reserved slug, not taxonomy term, to avoid duplicating identity into a second system. - Access model: records are not a public index, collection reads require authentication, per-item reads are capability-checked via `read_post`, non-publishers can only create `private` records, and new records default to private. - Contested/uncertain: the proposal explicitly states the naming and scope model are settled, but flags the narrower open question — is the API ready to stabilize for core? Feedback that would block stabilization is most useful in the next three weeks. ### 🗒️ Notes - The implementation is already operational in the Gutenberg plugin and exercised by production integrations; it grew from a February experiment, landed in Gutenberg 22.7 in March, then was consolidated and stabilized. - Non-goals are deliberately broad: no decay/consolidation/retrieval, no AI provider or model, no autonomous memory. Consuming tools accommodate staleness above the primitive. - Deferred built-in types: `skill` (planned 7.2, pending loading/discovery semantics, ai#430), `plan` (pending side-effect and lifecycle model), and `artifact` (explored separately). - What merges in 7.1: the `wp_knowledge` CPT with revisions, the `wp_knowledge_type` taxonomy plus `wp_knowledge_types` registration filter, built-in types `guideline`/`memory`/`note`, the `*_knowledge_item` capability namespace, generic `/wp/v2/knowledge` REST routes, and the Guidelines Settings page with a read-only `/wp/v2/knowledge/guideline-scopes` registry route. - Taxonomy terms are created lazily when a record is first saved with a given type — authoring a record can create its term. Revisions retained; autosave disabled (no editor session). - The knowledge management ability (via the Abilities API) is expected to follow in a later release. - Timeline: core patch open as wordpress-develop#12201, tracked in Trac #65476; names freeze at 7.1 Beta 1 on July 15. - Props to @aagam94, @artpi, @jason_the_adams, and @jorgefilipecosta. ## 📚 References - [Make WordPress Core post (primary)](https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/) - [Content Guidelines: a Gutenberg experiment](https://make.wordpress.org/ai/2026/02/03/content-guidelines-a-gutenberg-experiment/) - [Guidelines lands in Gutenberg 22.7](https://make.wordpress.org/ai/2026/03/23/guidelines-lands-in-gutenberg-22-7/) - [Consolidated design (gutenberg#77230)](https://github.com/WordPress/gutenberg/issues/77230) - [Access policy PR (gutenberg#78296)](https://github.com/WordPress/gutenberg/pull/78296) - [Rename to wp_knowledge namespace (gutenberg#79149)](https://github.com/WordPress/gutenberg/pull/79149) - [Migration follow-up (gutenberg#79263)](https://github.com/WordPress/gutenberg/pull/79263) - [Core patch (wordpress-develop#12201)](https://github.com/WordPress/wordpress-develop/pull/12201) - [Trac #65476](https://core.trac.wordpress.org/ticket/65476) - [Tracking issue (gutenberg#75171)](https://github.com/WordPress/gutenberg/issues/75171) - [skill type discussion (ai#430)](https://github.com/WordPress/ai/issues/430) ## 🗣️ Paraphrase - WordPress wants a shared, built-in place to keep a site's content standards so writers, plugins, and AI assistants all read from the same source instead of each reinventing storage. - The mechanism is a new internal post type called Knowledge, with three starter record kinds — guidelines, memories, and notes — and the user-facing Guidelines screen as the first thing built on it. - Core deliberately ships only the storage and the access rules, leaving any actual intelligence (ranking, decay, retrieval, AI models) to plugins. - The decisions are mostly locked; the remaining question is whether the API is solid enough to commit to long-term before names freeze at 7.1 Beta 1 on July 15. ## 📰 Newsletter - WordPress 7.1 has a notable proposal worth watching: a new `wp_knowledge` post type that gives your site one canonical home for content standards — voice, tone, image rules, per-block guidance — instead of burying them in a Google Doc nobody opens. - The clever framing: this is plumbing, not a robot. Core ships storage plus a clear access policy, and the community builds the smart parts (AI, retrieval, memory) on top. Same playbook that made `wp_template` and `wp_block` boring-in-a-good-way. - If you build plugins that stash AI context your own way, nothing breaks — but you can adopt the shared primitive to get revisions, capabilities, and REST for free. - Clock's ticking: names freeze July 15 at 7.1 Beta 1. If you have opinions on the slugs or capability boundaries, the next three weeks are when feedback can still move things. Drop comments on the post, the [tracking issue](https://github.com/WordPress/gutenberg/issues/75171), or #core-ai in Slack. ## ✅ Action Items #### DevRel - Developer advocacy: brief plugin authors on adopting `wp_knowledge` vs. keeping bespoke storage; prep a migration demo. - Education: write a quickstart showing how to register a custom type (e.g. `glossary`) and a custom scope via the filters. - Developer experience: document the `/wp/v2/knowledge` and `/wp/v2/knowledge/guideline-scopes` routes with examples before names freeze. - Developer marketing: explain the anti-fragmentation value prop in plain terms for the plugin ecosystem. - Community management: route stabilization-blocking feedback to comments, gutenberg#75171, and #core-ai within the three-week window. - Internal/external/cross-project: align Core, Core AI, and Gutenberg timelines around the July 15 freeze. #### OSPO - Policy & Governance: note the "core owns the primitive, community builds on it" decision-rights model as a reusable governance pattern. - License Compliance: confirm contributed code in wordpress-develop#12201 meets WP licensing. - Security Management: review the private-by-default and capability-checked access model; track encryption-at-rest as deferred hardening. - Software Inventory: record the new post type, taxonomy, and REST surfaces in the 7.1 feature inventory. - Developer Support: offer office hours during the feedback window. - Community Engagement: gather plugin-author input on whether built-in slugs are right. - Strategic Alignment: tie this to the broader AI tooling roadmap (skill/plan/artifact deferrals). #### Community - Maintainers: triage stabilization-blocking feedback before Beta 1. - Contributors: open good-first-issue tasks around test coverage for the controller and capability mapping. - Sponsors: not applicable to this source — the proposal does not discuss sponsorship. - Ecosystem: coordinate cross-plugin adoption to avoid re-fragmenting around `memory`/`note`. #### WordPress - Core: decide if the API is ready to stabilize for 7.1; freeze names at Beta 1 (July 15). - Core Performance: not applicable to this source — performance is not addressed beyond autosave being disabled. - Core AI: shepherd deferred `skill` (7.2), `plan`, and `artifact` types and the knowledge management ability. - Core Program Team: track Trac #65476 and the PR review cadence. - Documentation: document the capability namespace `*_knowledge_item` and the access matrix. - Accessibility: audit the Settings → Guidelines page for WCAG conformance (not covered in the proposal). - Meta: ensure `/wp/v2/knowledge` REST reliability. - Plugins: advise plugin reviewers on type/scope registration patterns. #### The WPCC - Programs: not applicable to this source — no funding or fellowship dimension is discussed. - Projects: governance clinic on the "namespace vs. concrete type" naming model could reuse this as a case study. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: the primitive is local-first storage with native revisions and standard capabilities, keeping site knowledge inside WordPress rather than external services. - Policies and covenants: the explicit "storage not intelligence" boundary acts as an anti-capture covenant against bundling a specific AI vendor into core. - Productized governance artifacts: the access matrix and scope registry function as governance artifacts; formalize them in the handbook. ## 🧪 Hypotheses - Providing a shared `wp_knowledge` primitive will reduce duplicated AI-context storage across plugins within two release cycles. - Sites that adopt Guidelines will show more consistent voice/tone across multi-author content than sites without it. - Naming the namespace "Knowledge" (vs. "Guidelines") will reduce future churn when `memory` and `note` consumers grow. - Private-by-default creation for non-publishers will prevent accidental exposure of author memories. - Deferring `skill`/`plan`/`artifact` rather than shipping them in 7.1 will lower the risk of locking in immature semantics. ### 📊 Methodology - Compare plugin storage patterns before and after 7.1 by surveying AI-context plugins for adoption of `wp_knowledge`. - A/B or cohort study of multi-author sites measuring content-consistency metrics with and without Guidelines. - Track Trac #65476 and REST route stability reports through Beta to assess API readiness. - Security review/pen test of the capability model against the published access matrix. ### ❓ Questions - Is `wp_knowledge` the right long-term name, and are `guideline`/`memory`/`note` the right built-in slugs? - Are the capability boundaries in the access model correct, especially Contributor read scope? - What, if anything, must be settled before these names become permanent compatibility commitments? - How will consuming tools handle staleness when core ships no decay or retrieval? ### 🔮 Future Research - Loading and discovery semantics for the deferred `skill` type (7.2). - A side-effect and lifecycle model for `plan`. - How scope applicability beyond the universal `site` scope should be defined. - Encryption-at-rest design that can land without changing the data model. ### 💡 Implications - Practice: writers and editors get an in-WordPress home for standards instead of external docs. - Policy: establishes a clear "core ships primitives, community builds intelligence" precedent for AI-adjacent features. - Security: a uniform capability and access model reduces per-plugin permission drift. - Education: training material can standardize around one storage surface. - Funding models: not applicable to this source — funding is not discussed. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ~13–15 (technical, long sentences with dense WordPress/REST terminology). #### 👀 Visual learners - Present: one access-model table mapping actors to permissions; an empty fenced code block placeholder for the `glossary` type example. - Improve: add an architecture diagram (post type → taxonomy → scopes → REST), and a before/after fragmentation visual. #### 🔊 Aural learners - Present: none. - Improve: a 3-minute audio summary or a #core-ai Slack recap. #### 🗣️ Verbal learners - Present: clear definitions of each built-in type and analogies (`attachment` → Media). - Improve: a glossary callout for primitive, scope, slug, capability namespace. #### 🧩 Kinesthetic learners - Present: a Testing section with concrete verification steps. - Improve: a reproducible local sandbox walkthrough enabling the Guidelines experiment. #### 🧠 Logical learners - Present: goals/non-goals lists, an access matrix, a timeline with a hard date. - Improve: a decision tree for "which type do I register?" and a state diagram for record visibility. #### 🧑‍🤝‍🧑 Social learners - Present: explicit call for feedback with three channels. - Improve: a scheduled community Q&A before the July 15 freeze. #### 🧘‍♀️ Solitary learners - Present: self-directed testing checklist. - Improve: a self-check quiz on the access model. #### 🌿 Naturalistic learners - Present: none. - Improve: lifecycle framing of knowledge records (create → revise → restore → stale). ### 📊 Accessibility Assessment #### Screen reader semantics - Present: heading structure and a data table with header cells in the source post. - Improve: ensure the access matrix has proper scope attributes and a caption. #### Keyboard navigation - Present: standard Make WordPress blog navigation. - Improve: verify Settings → Guidelines UI is fully keyboard reachable. #### Contrast and readability - Present: standard wordpress.org theme contrast. - Improve: confirm 4.5:1 on inline code and link styling. #### Text resizing and reflow - Present: responsive viewport meta. - Improve: verify the access table reflows at 200% zoom without clipping. #### Media and captions - Present: not applicable — no audio/video in the source. - Improve: if an audio recap is added, include a transcript. #### Forms and interactions - Present: comment form for feedback. - Improve: ensure the Guidelines Settings forms have labeled fields and inline validation. #### Standards reference - Map the access table and Settings forms to WCAG 2.2 AA (1.3.1, 2.1.1, 1.4.3, 1.4.10, 3.3.1). ### 🌍 DEIB Assessment #### Cultural breadth - Present: notes contributors live all over the world and discussions happen at all hours. - Improve: global examples of content-standard practices beyond English-language sites. #### Inclusive language - Present: neutral, technical tone; jargon mostly defined. - Improve: a plain-language summary for non-engineer site owners. #### Neurodiversity support - Present: consistent chunked structure with predictable headings. - Improve: more frequent subheadings in the longer prose sections. #### Representation - Present: contributor props credit four named reviewers. - Improve: surface a broader range of contributor voices in the feedback summary. #### Psychological safety - Present: respectful framing and an open, blocker-focused feedback invitation. - Improve: explicit reminder of the code of conduct on the feedback channels. ### ✅ Logical Validity #### Strong reasoning - Analogical: comparing Knowledge to `wp_template`/`wp_block`/`nav_menu_item` is a strong precedent argument — core has prevented fragmentation before, so it should here. Located in Purpose & goals. - Causal: "without a common primitive, every plugin ships its own storage, permissions, and REST surface" is a sound cause→effect claim for why fragmentation occurs. - Deductive: the naming argument (namespace vs. concrete type, `attachment`→Media) follows cleanly from the stated premise that Knowledge covers both procedural and declarative content. #### Fallacies - Possible appeal to precedent / weak analogy: the `wp_template` comparison assumes AI-context storage fragments the same way templating did; the domains differ. Fix: cite concrete evidence of current AI-storage fragmentation. - Assertion without shown evidence: "has been exercised by production integrations" is stated but unnamed. Fix: link the integrations or summarize results. #### Tone of voice - Measured, technical, and decision-oriented ("The naming and scope model are settled, so this proposal moves forward on that basis unless a blocker surfaces"). Confident but invites bounded feedback. ### 🛡️ DARVO Analysis - Deny: not applicable to this source — the proposal makes no denials of wrongdoing; the "No" FAQ answers (not AI-only, not a memory system) are scope clarifications, not defensive denials. - Attack: not applicable to this source — no accusers or critics are attacked. - Reverse victim/offender: not applicable to this source — there is no victim/offender dynamic in a technical merge proposal. ## 🎯 Conclusion - Bottom line: WordPress 7.1 proposes a `wp_knowledge` storage primitive with Guidelines as its first feature, giving sites one core-owned home for content standards while deliberately leaving AI intelligence to the ecosystem. - Next steps for readers: if you have a stake (plugin author, AI tool builder, multi-author site owner), review the slugs, capability boundaries, and API readiness, and submit blocker-level feedback in the next three weeks via the post comments, gutenberg#75171, or #core-ai — before names freeze at 7.1 Beta 1 on July 15. ## 🔄 Refactor Appendix — Merge Proposal: Guidelines built on Knowledge > 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] Core ships the primitive; community builds on it > [!quote] ID:rw_knowledge_primitive > "Core owns the primitive. The community decides what to build on it." **Context & use**: - Purpose & goals section. - Captures WordPress's governance stance: ship neutral storage, defer intelligence to the ecosystem. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Shared primitives prevent plugin fragmentation > [!quote] ID:rw_fragmentation > "Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface." **Context & use**: - Purpose & goals section; the core argument for merging into core. - Mirrors the `wp_template`/`wp_block` precedent. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Knowledge names the namespace, type names the record > [!quote] ID:rw_namespace > "Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note." **Context & use**: - Naming rationale; parallels `attachment`→Media. - Why "Knowledge" beats "Guidelines" as the umbrella term. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Neutral primitives are an anti-capture governance move **Claim** (one sentence, Courtney's voice): Shipping storage without bundled intelligence keeps a platform's core neutral and lets the ecosystem compete on the smart layer. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when the primitive is genuinely vendor-agnostic; breaks if core later favors one AI provider's retrieval model. **Links**: - [[WordPress core governance]] — because extends - [[Platform vs. ecosystem boundaries]] — because applies-in open-source platform design <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Watch whether `skill`/`plan`/`artifact` slugs ship in 7.2 as proposed — https://github.com/WordPress/ai/issues/430 #fleeting #inbox - [F2] Note the July 15 7.1 Beta 1 name-freeze deadline for any feedback. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Review wp_knowledge capability boundaries and post feedback before July 15 — #core-ai #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Merge Proposal Guidelines Built on Knowledge.md|Merge Proposal: Guidelines Built on Knowledge by make.wordpress.org]] ## Highlights - A single store of standards serves everyone who works on a site: writers and editors applying them by hand, plugins reading them, and AI assistants drawing on them too. Each of these needs the same thing, persistent and structured knowledge about the site, and today there is no shared place to keep it. Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. That is exactly the kind of fragmentation WordPress core has historically prevented, the same way `wp_template`, `wp_block`, and `nav_menu_item` prevented parallel solutions in their domains. Core owns the primitive. The community decides what to build on it. ([View Highlight](https://read.readwise.io/read/01kvqpq5v2yr8yeqmzdrjsenf5)) - Note: Core ships storage, ecosystem builds intelligence - Tags: atom/literature/h1 - This merge ships storage and access, not intelligence: no AI provider, no model, no retrieval algorithm, and no autonomous memory system. The specifics below are intentionally out of scope. They remain open topics, just not blockers: ([View Highlight](https://read.readwise.io/read/01kvqpq73j6g1eyt4vjh8hvgc6)) - Note: Storage-not-intelligence scope boundary - Tags: atom/literature/h2 ## Links - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — evidence-for: core should own structured storage and permissions while plugins and interfaces supply intelligence. - [[3. Resources/Permanent Notes/Retrieval Quality Is Set by the Unit of Knowledge Not the Retrieval Algorithm]] — applies-in: shared structured guidance improves retrieval by standardizing what gets stored.