Content organises policies, briefs, articles and other knowledge as structured entries with publication and relationship information.
The policy that lives in a PDF three revisions out of date — here it is a living record: typed, versioned, published under your rules, and connected to the people and work it concerns. This manual covers the content entry, its lifecycle, and its wiring.
What you record
The content entry
| Field group | What it holds |
|---|---|
| Identity | Name, title, subtitle, description |
| Type & language | The content type (policy, brief, article, news — your types), the language |
| The body | The body itself and its format; the reading time and word count |
| Lifecycle | Status, version, published/scheduled/archived dates |
| Hierarchy | Parent content (chapters, sections), level, sort order; the anchor flag |
| Imagery | Thumbnail, hero, and the share image |
| Placement | The realm classification, the categories, the source attribution |
Version and status fields support the publication lifecycle: distinguish draft, review, published, scheduled and archived material. Establish the revision and retention workflow needed to preserve earlier approved text.
The hierarchy is the structure: entries nest (a handbook's chapters, a programme's briefs) with the parent/level/sort fields; the anchor flag marks the primary entry of a set. Knowledge gains a table of contents because it is held as structure, not as files.
The publishing rules
Each entry's publishing is governed by rules your operation defines — who may publish, under which workflow. The schedule is data: the news that goes live Friday is scheduled Friday, not pasted Friday.
The reader threads
Entries carry reader threads — the conversation and commentary attached to the knowledge, held on the record rather than scattered in replies.
The additional information
Typed enrichment blocks per entry: FAQs, specifications, references, comparison tables, testimonial blocks — the structured depth the platform renders appropriately and queries natively.
What you can do
- Author and version — the entry, its body, its status, per your publishing rules
- Structure — parents, levels, sort order; anchors for the primary entries
- Publish under governance — the workflow your operation defines
- Enrich — the additional-info blocks per type
- Relate — the wiring below
What it connects to
| Target | Examples |
|---|---|
| Categories & tags | The filing structure your operation maintains |
| Employees & accounts | The authors, the audience, the people the content concerns |
| Works & programmes | The briefs that govern the work |
| Media | The images and files the entry carries |
| Other content | The semantic links — references, prerequisites, translations, companions |
Where it feeds
Knowledge that is connected to its subjects becomes context: the policy applies-to the unit; the brief governs the programme; the FAQ answers the question the operator asked. The readings and the assistant draw on held, connected knowledge — the content platform story is the buyer page; this manual is the authoring surface.
The pattern note: same four-part structure — record, do, connect, feed. The content manual is where the versioning pattern shows: knowledge that changes as governed versions, and structure that makes retrieval-in-context possible.
Implementers migrate your existing knowledge into typed entries at adoption and configure the publishing workflows; consultants help structure the knowledge your operation actually governs by.
No record is an island
Every entry relates to its categories, its authors, the work it governs, the media it carries, the entries it references. Knowledge stops being storage and becomes a living index — connected to what it is about.
Review the record and its context before deciding what to do next.
Media → · Communication → · All manuals → · The Content platform page →
Check your work
For a policy revision, identify the entry and version, review the audience and publishing rules, and check the published result. Keep the previous approved text where required. A version field alone is not proof that every historical body has been retained.
Available screens and actions depend on your deployment and permissions. Use this manual alongside the configured workflow and the capability demonstration for your installation.