id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	focuses
65476	Introduce Knowledge custom post type	gziolo	gziolo	"= Summary =

Introduce the Knowledge concept: a `wp_knowledge` custom post type with a type taxonomy, a capability namespace, and a REST surface, providing a canonical store for author-facing and agent-facing site knowledge. Guidelines is the first feature built on it, giving site owners a place to capture content standards such as voice, tone, image guidance, and per-block rules.

This has been developed as an experiment in the Gutenberg plugin and is about to be proposed for merge in WordPress 7.1. More details coming up soon.

= Motivation =

Sites accumulate standards and context that today live outside WordPress in documents, wikis, and institutional knowledge. As plugins and integrations need persistent, structured knowledge about a site, each one tends to ship its own storage, permissions model, and REST surface. A shared core primitive prevents that fragmentation, the same way `wp_template`, `wp_block`, and `nav_menu_item` did in their domains.

The feature ships storage and access only. It includes no AI provider, model, retrieval algorithm, or memory architecture.

= Scope =

Proposed for this ticket:

* `wp_knowledge` post type, registered as internal (`public => false`, `publicly_queryable => false`), with revision support
* `wp_knowledge_type` taxonomy and a `wp_knowledge_types` registration filter
* Built-in types:
  * `guideline` – a standard such as voice, tone, or per-block rules, applied directly or loaded in the matching context
  * `memory` – durable context a user explicitly saved, such as preferences or stable facts
  * `note` – private freeform working text such as drafts and synced notes
* `*_knowledge` capability namespace and access policy (private, author-owned by default; administrators manage site-wide records)
* `/wp/v2/knowledge` REST routes

Out of scope for this ticket:

* Further built-in types, deferred and registerable by plugins in the meantime:
  * `skill` – a procedure that can load and apply a guideline, planned for 7.2 pending settled loading and discovery semantics
  * `plan` – task-scoped working state, 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
* The knowledge management ability (Abilities API), proposed for a later release
* Decay, consolidation, retrieval, and encryption at rest

= Access model =

Records are not exposed as a public index. Collection reads require authentication, per-item reads are capability-checked through `read_post`, and non-publishers may only create private records.

||= Role =||= Site-wide guideline records =||= Own private records =||= Others' private records =||= Manage global records =||
|| Subscriber || No || No || No || No ||
|| Contributor || Read where caps allow || CRUD || No || No ||
|| Author / Editor || Read where caps allow || CRUD || No || No ||
|| Administrator || Manage || Yes || Yes || Yes ||

Type and scope registration are code-level extension points. User roles control access to records, not the registration of types or scopes.


= Related =

* Gutenberg tracking issue: https://github.com/WordPress/gutenberg/issues/75171
* Type model discussion: https://github.com/WordPress/gutenberg/issues/77230
* Rename PR (Gutenberg): https://github.com/WordPress/gutenberg/pull/79149"	feature request	assigned	normal	7.1	Posts, Post Types	trunk	normal		has-patch has-unit-tests