Title: Knowledge – Make WordPress Core

---

#  Tag Archives: Knowledge

 [  ](https://profiles.wordpress.org/gziolo/) [Greg Ziółkowski](https://profiles.wordpress.org/gziolo/)
7:46 am _on_ June 22, 2026     
Tags: [7.1 ( 13 )](https://make.wordpress.org/core/tag/7-1/),
guidelines, Knowledge, [merge-proposals ( 7 )](https://make.wordpress.org/core/tag/merge-proposals/)

# 󠀁[Merge Proposal: Guidelines built on Knowledge](https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/)󠁿

We propose merging Knowledge, a new `wp_knowledge` custom post typeCustom Post Type
WordPress can hold and display many different types of content. A single item of
such a content is generally called a post, although post is also a specific post
type. Custom Post Types gives your site the ability to have templated posts, to 
simplify the concept., into WordPress coreCore Core is the set of software required
to run WordPress. The Core Development Team builds WordPress. 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 taxonomyTaxonomy
A taxonomy is a way to group things together. In WordPress, some common taxonomies
are category, link, tag, or post format. [https://codex.wordpress.org/Taxonomies#Default_Taxonomies](https://codex.wordpress.org/Taxonomies#Default_Taxonomies).,
the existing roles and capabilitiescapability A **capability** is permission to 
perform one or more types of task. Checking if a user has a capability is performed
by the `current_user_can` function. Each user of a WordPress site might have some
permissions but not others, depending on their role. For example, users who have
the Author role usually have permission to edit their own posts (the “edit_posts”
capability), but not permission to edit other users’ posts (the “edit_others_posts”
capability)., native revisionsRevisions The WordPress revisions system stores a 
record of each saved draft or published update. The revision system allows you to
see what changes were made in each revision by dragging a slider (or using the Next/
Previous buttons). The display indicates what has changed in each revision., 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-blockBlock Block is the abstract term used to describe
units of markup that, composed together, form the content or layout of a webpage
using the WordPress editor. The idea combines concepts of what in the past may have
achieved with shortcodes, custom HTML, and embed discovery into a single consistent
API and user experience. rules.

The implementation is operational in the GutenbergGutenberg The Gutenberg project
is the new Editor Interface for WordPress. The editor improves the process and experience
of creating new content, making writing rich content much simpler. It uses ‘blocks’
to add richness rather than shortcodes, custom HTML etc. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new features
to your WordPress websites. WordPress plugins are written in the PHP programming
language and integrate seamlessly with WordPress. These can be free in the WordPress.
org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. 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 Adminadmin (and
super 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, capabilitycapability A **capability**
   is permission to perform one or more types of task. Checking if a user has a 
   capability is performed by the `current_user_can` function. Each user of a WordPress
   site might have some permissions but not others, depending on their role. For
   example, users who have the Author role usually have permission to edit their
   own posts (the “edit_posts” capability), but not permission to edit other users’
   posts (the “edit_others_posts” capability)., and REST models with one shared 
   foundation

## Non-goals

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 filterFilter
   Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks).
   They provide a way for functions to modify data of other functions. They are 
   the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated
   manner, and should never have side effects such as affecting global variables
   and output.
 * 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 UIUI User interface, and a read-only 
   registry route at `/wp/v2/knowledge/guideline-scopes`

The knowledge management ability, registered through the Abilities APIAPI An API
or Application Programming Interface is a software intermediary that allows programs
to interact with each other and share data in limited, clearly defined ways., 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:

    ```notranslate
    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 patchpatch A special text file that
describes changes to code, by identifying the files and lines which are added, removed,
and altered. It may also be referred to as a **diff**. A patch can be _applied_ 
to a codebase for testing.. 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 APIREST API The REST
   API is an acronym for the RESTful Application Program Interface (API) that uses
   HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an
   application (think “phone app” or “website”) can communicate with the data store(
   think “database” or “file system”) [https://developer.wordpress.org/rest-api/](https://developer.wordpress.org/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 blockerblocker A bug which is so severe that it blocks a release. surfaces.
The open question is narrower: is the API ready to stabilize for core? The names
freeze at WordPress 7.1 BetaBeta A pre-release of software that is given out to 
a large group of users to trial under real conditions. Beta versions have gone through
alpha testing in-house and are generally fairly close in look, feel and function
to the final product; however, design changes often occur as part of the process.
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 SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/).
The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/).

_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._

[#7-1](https://make.wordpress.org/core/tag/7-1/), [#guidelines](https://make.wordpress.org/core/tag/guidelines/),
[#knowledge](https://make.wordpress.org/core/tag/knowledge/), [#merge-proposals](https://make.wordpress.org/core/tag/merge-proposals/)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2026%2F06%2F22%2Fmerge-proposal-guidelines-built-on-knowledge%2F%23respond&locale=en_US)