WordPress 7.1 proposes Knowledge post type with built-in Guidelines feature

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

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
• 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 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, 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 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, and the #core-ai channel in WordPress Slack.

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

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