We propose merging Knowledge, a new wp_knowledge custom 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 core 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 taxonomy 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., the existing roles and capabilities 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 revisions 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-block 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 Gutenberg 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/ plugin 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/ or can be cost-based plugin from a third-party. and has been exercised by production integrations. It builds on the Guidelines experiment, proposed in February and landed in Gutenberg 22.7 in March, then shaped through community feedback into a consolidated design 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 (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, capability 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)
  • 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 Filters are one of the two types of 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 UI User interface, and a read-only registry route at /wp/v2/knowledge/guideline-scopes

The knowledge management ability, registered through the Abilities API 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:

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.

This matrix reflects the access policy from gutenberg#78296 and will be aligned exactly with the final core patch 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 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/
• 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.

Why core instead of a plugin? Because the main value is interoperability. A plugin can store its own knowledge records, but it cannot establish a shared convention for how other plugins, editorial tools, and AI integrations store, protect, revise, and expose that knowledge. Without a core primitive, every integration defines its own architecture and the records cannot reliably interoperate. The footprint stays intentionally small: a post type, taxonomy, capabilities, and REST routes that sit unused until something writes to them, with no public queries, no frontend behavior, and no AI processing by default.

Timeline

The core patch is open for review as wordpress-develop#12201, tracked in Trac #65476. It is backed by the Gutenberg work the feature grew from: the rename to the wp_knowledge namespace and the follow-up 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 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 Beta 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, and the #core-ai channel in WordPress Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

Props to @aagam94, @artpi, @jason_the_adams, and @jorgefilipecosta for review and feedback on this merge proposal.

#7-1, #guidelines, #knowledge, #merge-proposals