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 > ## 🧭 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, We propose merging Knowledge, a new `wp_knowledge` custom post type, into WordPress core for the 7.1 release, with Guidelines as the first feature built on it. Knowledge is a general primitive for storing author-facing and agent-facing site knowledge as standard WordPress content: a post type with a type taxonomy, the existing roles and capabilities, native revisions, and REST access. Guidelines uses it to give site owners a first-class place to capture the standards that shape how content is written and edited, such as voice, tone, image preferences, and per-block rules. The implementation is operational in the Gutenberg plugin and has been exercised by production integrations. It builds on the Guidelines experiment, [proposed](https://make.wordpress.org/ai/2026/02/03/content-guidelines-a-gutenberg-experiment/) in February and [landed in Gutenberg 22.7](https://make.wordpress.org/ai/2026/03/23/guidelines-lands-in-gutenberg-22-7/) in March, then shaped through community feedback into [a consolidated design](https://github.com/WordPress/gutenberg/issues/77230) and stabilized for core. #### Purpose & goals Most sites already have content standards, but they live outside WordPress in documents, wikis, and institutional knowledge. Guidelines gives them a canonical home inside WordPress, available where they matter: during writing and editing. 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. The name follows that intent. “Guideline” describes prescriptive records well but fits memories and working notes much less naturally, while “Knowledge” covers both procedural content (how work should be done) and declarative content (what is known). Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note. The user-facing feature in WP Admin remains Guidelines, the same way the `attachment` post type surfaces as Media at `/wp/v2/media`. The goals, concretely: * Provide a canonical storage primitive for author-facing and agent-facing site knowledge * Ship Guidelines as the first feature built on it, demonstrating the primitive in core * Replace fragmented plugin-specific storage, capability, and REST models with one shared foundation 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: * No decay, consolidation, or retrieval mechanism in core. Consuming tools accommodate staleness above the primitive. * Further built-in types are deferred and can be registered by plugins in the meantime: + `skill` – a procedure that can load and apply a guideline, is planned for 7.2 pending settled loading and discovery semantics ([ai#430](https://github.com/WordPress/ai/issues/430)) + `plan` – task-scoped working state for a multi-step task, pending a side-effect and lifecycle model + `artifact` – a reference to a versioned work product distinct from the freeform text covered by `note`, explored separately * Load applicability of scopes (when a scope’s guidance applies beyond the universal `site` scope) is left for its own discussion. * Session state and cross-site user preferences live above the primitive. * Encryption at rest is orthogonal hardening that can land later without changing the data model. #### What we propose to merge in 7.1 * The `wp_knowledge` custom post type with native revision support * The `wp_knowledge_type` taxonomy and the `wp_knowledge_types` registration filter * The built-in types `guideline`, `memory`, and `note` (defined below) * The `*_knowledge_item` capability namespace and the access model described below * The generic `/wp/v2/knowledge` REST routes for working with knowledge records like other post types * The Guidelines Settings page: per-scope `guideline` records, a filterable scope registry as the source of truth for the UI, and a read-only registry route at `/wp/v2/knowledge/guideline-scopes` The knowledge management ability, registered through the Abilities API, is expected to follow in a later release. #### Built-in types Each type is defined by what the record represents and how it is applied: * **`guideline`** – a standard, pure text that is the source of truth, such as voice, tone, image guidance, or per-block rules. A guideline does nothing on its own. It is there to be applied, either directly by an ability that pulls the text in or through a skill that loads it. The site-wide standards managed on the Settings page carry this type. * **`memory`** – durable context explicitly saved or approved for future use, such as user preferences, stable facts, and profile context. Records are private and author-owned. The explicit save-or-approve rule is deliberate: core ships a storage primitive, not a memory architecture. Decay, consolidation, and retrieval remain things to build on top. * **`note`** – private freeform working text, such as sticky notes, drafts, and notes synced from external tools. A record saved without a type falls back to `note`. Plugins register their own types through the same filter. A plugin might add a `glossary` type to keep domain terminology consistent across writers, editors, and any agent that reads it: | | | --- | | `function` `my_plugin_register_knowledge_types(` `array` `$types` `):` `array` `{``$types``[``'glossary'``] =` `array``(``'title'` `=> __(` `'Glossary'``,` `'my-plugin'` `),``);``return` `$types``;``}``add_filter(` `'wp_knowledge_types'``,` `'my_plugin_register_knowledge_types'` `);` | Core relies only on the semantics of the built-in slugs it ships. Plugin types are free to define their own behavior. #### Guideline scopes Guideline scopes define the sections shown in *Settings → Guidelines* and the reserved slugs used to address the corresponding `guideline` records. Core ships scopes such as Site, Copy, Images, and Blocks, each one a `guideline` record at a reserved slug like `guideline-copy`. Plugins register additional scopes through a filter, and the Settings page reads the registry through a read-only REST route at `/wp/v2/knowledge/guideline-scopes`. Scopes are not knowledge types. The `wp_knowledge_type` taxonomy answers what kind of record this is (`guideline`, `memory`, `note`). The scope registry answers where a guideline applies in the Guidelines UI. A scope is addressed by its reserved slug, not a taxonomy term, since a term per scope would attach to exactly one record and duplicate identity into a second system. #### Privacy, security, and access model Knowledge records are not exposed as a public index. The post type is registered as an internal storage primitive, not a front-end content type: it is not publicly queryable, and management flows through the Guidelines UI, REST, and registered programmatic surfaces rather than a native public post-type UI. Collection reads require authentication, per-item reads are capability-checked through `read_post`, and non-publishers can only create `private` records. New records default to private on creation. | **Actor** | **Site-wide guideline records** | **Own private records** | **Others’ private records** | **Publish / manage global records** | | --- | --- | --- | --- | --- | | Subscriber | No | No | No | No | | Contributor | Read where capabilities allow | Create, read, edit, delete | No | No | | Author / Editor | Read where capabilities allow | Create, read, edit, delete | No | No | | Administrator | Manage | Yes | Yes | Yes | This matrix reflects the access policy from [gutenberg#78296](https://github.com/WordPress/gutenberg/pull/78296) and will be aligned exactly with the final core patch. The built-in type set is defined in code through a filter, while the underlying taxonomy terms are created lazily when a record is first saved with a given type, so authoring a record can create its term. Revisions are retained, and autosave is disabled, since knowledge records have no editor session. #### Testing Enable the Guidelines experiment in Gutenberg and verify: * *Settings → Guidelines* renders its sections from the scope registry, and each scope can be edited, revised, and restored through the REST API * The scope registry route returns core scopes and plugin-registered scopes * A Contributor can create and read only their own private records, and a Subscriber cannot access the post type through REST * REST collection reads require authentication, and non-publishers cannot create published records * No knowledge records are exposed through front-end public queries Automated coverage for the controller, capability mapping, and type registry ships with the implementation and will be part of the core patch. #### FAQ **Is this an AI-only feature?** No. The storage primitive is already used for plain note-taking and draft syncing with no AI involved, and the Guidelines experience serves any multi-author site that wants consistent standards. AI tools are one consumer among several. **Does WordPress now have a “memory system”?** No. Core ships storage with a clear access policy. A `memory` record is a durable context a user explicitly saved, comparable to a private post. Anything resembling a memory architecture, including relevance ranking, decay, or consolidation, is left to plugins and integration layers by design. **What about existing plugins that store AI context their own way?** Nothing breaks. Plugins can keep their own storage or adopt the shared primitive to gain interoperability, revisions, and the capability model for free. #### Timeline The core patch is open for review as [wordpress-develop#12201](https://github.com/WordPress/wordpress-develop/pull/12201), tracked in [Trac #65476](https://core.trac.wordpress.org/ticket/65476). It is backed by the Gutenberg work the feature grew from: the [rename to the wp\_knowledge namespace](https://github.com/WordPress/gutenberg/pull/79149) and the [follow-up](https://github.com/WordPress/gutenberg/pull/79263) that migrates Guidelines to use the improved structure. The naming and scope model are settled, so this proposal moves forward on that basis unless a blocker surfaces. The open question is narrower: is the API ready to stabilize for core? The names freeze at WordPress 7.1 Beta 1 on **July 15**, when the post type, taxonomy, REST routes, capabilities, and type slugs become long-term compatibility commitments. Feedback that would block stabilizing for core is most useful in the next three weeks, while there is still room to act on it. #### Call for feedback The questions below are where input matters most before these decisions become core commitments: * Is `wp_knowledge` the right long-term name for the primitive, and are `guideline`, `memory`, and `note` the right built-in type slugs? * Are the capability boundaries in the access model correct? * Is anything missing that should be settled before these names become core compatibility commitments? The best places to respond are the comments below, the [tracking issue](https://github.com/WordPress/gutenberg/issues/75171), and the [#core-ai](https://wordpress.slack.com/archives/C08TJ8BPULS) channel in WordPress Slack. *Props to [@aagam94](https://profiles.wordpress.org/aagam94/), [@artpi](https://profiles.wordpress.org/artpi/), [@jason\_the\_adams](https://profiles.wordpress.org/jason_the_adams/), and [@jorgefilipecosta](https://profiles.wordpress.org/jorgefilipecosta/) for review and feedback on this merge proposal.*, Merge Proposal: Guidelines Built on Knowledge, make.wordpress.org, 01kvqp2kcgdhtpmxkf2y6s60ty.