Changelogs as Their Own Document Type, Not a Blog Category
Knowledge treats changelog entries as a first-class document type with their own filterable timeline, rather than a tag bolted onto regular articles.
There are two common ways documentation tools handle release notes: give them their own dedicated structure, or treat them as just another blog post with a "changelog" tag applied. Knowledge takes the first approach, and the distinction is worth understanding if you're deciding how to organize your own release notes.
What "its own document type" actually means
Changelog entries in Knowledge carry doc_type = 'changelog' — a genuine field-level distinction, not a category tag layered on top of an otherwise identical document. The public changelog route (/docs/[spaceSlug]/changelog) filters specifically on that field to build its timeline, and it goes through the exact same published-and-public visibility check every other public document read uses — changelog entries aren't a special case for access control, just for how they're organized and surfaced.
Filterable by tag, on top of the type
The changelog timeline supports filtering by ?tag=, so within your changelog specifically — separate from your regular articles — you can let readers narrow down to entries about a particular area: "show me only backend changes," or "show me only what changed in the mobile app." That's a filter scoped to release notes, not a filter that mixes your changelog in with your general blog content.
Why the distinction is worth caring about
A tagged-blog-post approach to changelogs means release notes compete for attention with your regular content in the same feed, and a reader specifically looking for "what changed recently" has to filter out everything else. A first-class document type means the changelog is its own dedicated surface from the start — readers who want release notes land somewhere built for exactly that, and readers of your general docs or blog content aren't seeing changelog entries mixed in unless they're looking for them.
Deciding how to use this for your own docs
If you're setting up a new space, use doc_type: 'changelog' for anything that's genuinely a release note — a specific, dated statement of what changed — rather than writing it as a regular article and tagging it after the fact. The tag-based filtering within the changelog view only works well if entries are consistently typed correctly from the start; retrofitting a large batch of miscategorized articles later is more work than typing them right the first time.