# Merge Proposal: Guidelines built on Knowledge > [!question] Lingering Questions > - Is `wp_knowledge` the right long-term name, and are `guideline`/`memory`/`note` the right built-in slugs — what, specifically, needs to be settled before the July 15 Beta 1 freeze locks them in as compatibility commitments? > - Are the capability boundaries correct, especially Contributor-level read scope, given records default to private and non-publishers can only create private records? > - How will consuming tools handle staleness when core deliberately ships no decay or retrieval logic? > [!tip] Article Ideas > - "Core ships primitives, community builds intelligence" as a reusable open-source platform-governance pattern, using `wp_template`/`wp_block` and now `wp_knowledge` as the case-study lineage. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — same core-AI-primitive design space, different specific proposal (Abilities API vs. Knowledge CPT). > - [[3. Resources/Permanent Notes/An Unregistered Format Fragments Because Every Adopter Invents Their Own Name For It]] — a related but distinct fragmentation mechanism (missing identifier vs. missing shared storage primitive). > - [[3. Resources/MOCs/Open Source Governance MOC]] — core-owns-the-primitive as a governance precedent. > [!quote] Vocabulary > - **`wp_knowledge`** — the proposed core post type; a namespace, not a record type. Individual records are referred to by concrete type: `guideline`, `memory`, or `note`, the same way the `attachment` post type surfaces to users as "Media." > - **Guideline scope** — a `guideline` record at a reserved slug (e.g. `guideline-copy`) corresponding to a Settings → Guidelines section (Site, Copy, Images, Blocks); scopes are addressed by reserved slug rather than taxonomy term to avoid a second identity system. ## Metadata - Source: [[3. Resources/Readwise/Full Document Contents/Articles/Merge Proposal Guidelines built on Knowledge]] - Author: Make WordPress Core - URL: https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/ ## Author's thesis A merge proposal for WordPress 7.1 introduces `wp_knowledge`, a general-purpose core post type (with a `wp_knowledge_type` taxonomy, standard capabilities, native revisions, and REST access) as the canonical, core-owned home for author-facing and agent-facing content standards. Guidelines is the first feature built on it. Core deliberately ships only the storage primitive and its access policy — no AI provider, model, retrieval, or memory architecture — leaving the community to build the intelligent layer on top. ## Key arguments 1. **Fragmentation is the alternative being prevented**: without a shared primitive, every plugin that wants to store AI-context or content-standards data ships its own storage, permissions model, and REST surface — the same failure core has historically prevented with `wp_template`, `wp_block`, and `nav_menu_item`. 2. **The naming model separates namespace from record type**: "Knowledge" is the umbrella covering both procedural content (how work should be done) and declarative content (what is known); concrete records are named by type (`guideline`, `memory`, `note`), mirroring how `attachment` surfaces as "Media." 3. **Core draws a deliberate boundary at storage-plus-access-policy**, explicitly excluding decay, consolidation, retrieval, AI provider integration, or autonomous memory — those are left to the ecosystem. ## Claim atoms ### 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." Where/why: Purpose & goals section — the governance stance that draws the line between what core commits to long-term and what stays open for the ecosystem to compete on. ### 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." Where/why: the core argument for merging into core rather than leaving this to plugins; explicitly parallels the `wp_template`/`wp_block` precedent. ### 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." Where/why: the naming rationale, directly paralleled to `attachment` → Media in the WP Admin UI. ## Permanent candidates - **Shipping storage without bundled intelligence as an anti-capture governance move** (atom 1) — a genuine, reusable claim distinct from the existing consumer-neutral-primitives note (that one is about API shape, this one is about the storage/intelligence boundary). Promoted below. - **A shared core primitive prevents per-plugin storage fragmentation** (atom 2) — a distinct fragmentation mechanism from the vault's existing unregistered-format-fragmentation note (missing shared storage vs. missing identifier). Promoted below. - The namespace/type naming argument (atom 3) is a solid API-design point but narrower and more WordPress-specific than a cross-domain claim — not promoted separately. ## Processing checklist - [ ] Watch whether `skill`/`plan`/`artifact` slugs ship in 7.2 as proposed (ai#430) - [ ] Review capability boundaries and submit feedback before the July 15 7.1 Beta 1 name freeze - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — core-ships-primitives-community-builds-intelligence as a governance precedent - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — a core-level storage primitive purpose-built for agent-facing content standards