Content
Understand the always-active Knowledge, Document Library, and Communications capabilities behind the Information surface.
Content
Use the stable Resource keys below when your App refers to Knowledge or controlled documents. Resolve links through Resource References, without importing a Content model. The result remains subject to publication, audience, and record authority; an App installation does not enable or grant these Core capabilities.
Available capabilities
Content is the Core-owned capability family behind the Shell's Information surface. It combines three always-active capabilities that share navigation and authorization foundations but keep different records and lifecycle rules.
| Capability | Owns | Stable Resource keys |
|---|---|---|
| Knowledge | Informal articles, locale revisions, taxonomy, audience, feedback, and governed Agent retrieval | knowledge.article |
| Document Library | Controlled documents, immutable versions, acknowledgements, holds, and retention | document.record, document.version |
| Communications | Boards and tenant-wide delivery through posts, banners, and popups | communication.board, communication.board_post, communication.banner, communication.popup |
Routes and access
The product surface is named Information even though the internal domains are Knowledge, Document Library, and Communications.
| Layer | Knowledge | Document Library | Communications |
|---|---|---|---|
| Reader route | /content/knowledge | /content/documents | /content/boards and delivery surfaces |
| Management route | /content/management/knowledge | /content/management/documents | /content/management/{boards,board-posts,banners,popups} |
| Operator route | Editorial state inside management | /content/operations/documents | Audience and receipt evidence on each delivery resource |
| Primary read permission | knowledge.article.read | document.record.read | One read permission per Communications Resource |
The Shell owns the /content/* layout and navigation context. Each domain owns
its API, models, Policies, lifecycle services, and resource-specific React
surfaces. Route middleware rejects an actor without the named tenant-wide
permission; the Policy and domain query then apply record visibility,
confidentiality, publication window, audience, or lifecycle rules.
Stable Resource keys let cross-cutting systems refer to content without naming a
Core model. Knowledge exposes citation-bearing, read-only Agent retrieval at
GET /api/knowledge/agent-search. Document Library can preserve links to an App
record through the standard Resource Reference envelope. Communications resolves
its audience and records delivery/read evidence without turning the audience
definition into another authorization scope.
Integration rules
Content is always-active Core functionality, not an App Package. Production App
code must not import App\Core\Knowledge, App\Core\DocumentLibrary,
App\Core\Communications, or their frontend source. An App crosses the boundary
through a stable Resource Reference, a Core-governed event or projection, or the
smallest app-neutral SDK capability.
The Content family is also different from installation content. Installation content is schema or seed data an App needs to become operational; Knowledge, Document Library, and Communications are product runtimes with their own records and lifecycle.
Generic Media and Attachment primitives store ordinary files, but controlled document binaries use the Document Library's staged scan, extraction, binding, and retention path. Likewise, Communications receipts are evidence about a delivered post, banner, or popup; they are not Notifications and do not share a notification row or lifecycle.
Frontend visibility never grants backend authority. Hiding a management route or action only changes the interface. The API middleware, Policy, tenant context, and resource-specific rules still decide every read and write.
Knowledge retrieval example
Knowledge's Agent search shows the layers working together. Its request follows this sequence:
KnowledgeAgentContributorpublishes one read-only tool namedknowledge.article.searchatGET /api/knowledge/agent-search.- The tool requires
knowledge.article.read; the API route carries the same middleware permission. - Governed retrieval considers only an available locale revision inside its publication window and applies the Article's audience rules.
- The result carries stable article and revision identity plus citation data; draft, expired, archived, or audience-excluded revisions are absent.
An App or Agent can therefore consume governed knowledge without importing the Article model or gaining access to authoring state. The stable API and Resource identity cross the boundary; publication and audience truth stay in Core.
Related
- Shell layout regions — where the Information routes live in the tenant Shell
- Permissions and roles — the tenant-wide authority checked before content access
- Resource References — refer to a content or App record without importing its model
- Handle events and jobs — consume governed changes without a direct package dependency