Site content standards have long lived outside WordPress itself — in shared documents, wikis, or team memory — with no native place to store them where writers and editors actually work. A formal merge proposal from contributor Greg Ziółkowski, published on Make WordPress Core, would introduce a dedicated storage layer in WordPress 7.1, giving sites a structured, permission-controlled home for content knowledge directly inside the CMS.
The proposal centers on wp_knowledge, a new custom post type designed to store author-facing and agent-facing content records. It ships with a companion taxonomy, native revision support, and REST API access under /wp/v2/knowledge. Built on top of it is Guidelines, a new Settings page where administrators can record site-wide standards covering voice, tone, image preferences, and per-block editing rules. The feature has been live in the Gutenberg plugin since version 22.7, released in March 2026, and has been tested in production integrations.
Three record types are built into the system from launch, each serving a distinct purpose within the knowledge layer:
- guideline
- A site-wide standard in plain text — voice, tone, image rules, or per-block instructions — surfaced in the Guidelines Settings page and applied by tools or AI assistants that read it.
- memory
- Durable context explicitly saved or approved for reuse, such as user preferences or stable facts; records are private and author-owned.
- note
- Private freeform working text like sticky notes or drafts synced from external tools; the default type when no type is specified on save.
Plugins can register their own types through the wp_knowledge_types filter — a glossary type for domain terminology, for example — following the same pattern WordPress uses for templates, blocks, and navigation menus. The proposal frames wp_knowledge as a shared primitive that replaces the fragmented approach where every AI plugin or editorial tool ships its own storage, its own permissions model, and its own REST endpoints.
The access model keeps knowledge records off the public front end entirely. The post type is not publicly queryable, collection reads require authentication, and new records default to private. Contributors and Authors can create and manage only their own private records, while Administrators can manage site-wide guideline records and access others’ private records. Subscribers have no access at all.
The proposal is explicit about what is not included in 7.1. There is no AI provider, no retrieval algorithm, and no autonomous memory system. Additional knowledge types — including skill for procedure records, plan for multi-step task state, and artifact for versioned work products — are deferred to future releases or left to plugins. Encryption at rest, session state, and cross-site user preferences are also out of scope for this merge. What ships is the storage layer and the Guidelines UI, nothing more.
The proposal notes that AI tools are one consumer of the knowledge layer among several, not its primary audience. Plain note-taking, draft syncing, and multi-author editorial consistency are all use cases the feature addresses with no AI involvement. If approved, the merge would land a foundational piece of WordPress infrastructure that both human workflows and automated tools can build on — much as wp_block did for the reusable blocks ecosystem.
