> ## Documentation Index
> Fetch the complete documentation index at: https://docs.buildbetter.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Publish release notes to a public board and embed a what's-new feed in your own product

A **changelog board** is a public feed of what you shipped. Entries are drafted, then published, and can be embedded directly in your product.

## Entries

Each entry carries a title, a slug, a body, labels, and a published date.

| Field            | Notes                                                 |
| ---------------- | ----------------------------------------------------- |
| **Title**        | Usually a version (`v0.3.2`) or a date (`2026-08-14`) |
| **Slug**         | URL segment, derived from the title                   |
| **Labels**       | `New`, `Improved`, `Fixed`                            |
| **Status**       | Draft until published                                 |
| **Published at** | The date shown to readers                             |

Entries are created and edited as drafts, then **published** as a separate step — so an entry can be written ahead of a release and go live when the release does.

<Tip>
  Label entries properly. Labels are how a reader skims for the one line that affects them instead of reading everything. An unlabelled changelog gets scanned once and then ignored.
</Tip>

## One Board or Several

Changelog boards are boards, so you can run more than one. Separate feeds per product line — a desktop app, a recorder, a mobile client — keep each audience's feed relevant. Each gets its own name and slug.

## Embedding the Feed

A changelog board can be embedded in your own application with a **public board key**. The embed gives you:

* A lightweight **what's-new badge** and release feed
* **Unread tracking**, so returning users see what's new since their last visit
* **Isolated styling**, so the widget doesn't inherit or fight your CSS

<Note>
  Unread tracking is what makes an embedded feed worth installing. A feed that shows the same entries to everyone forever gets dismissed once and never opened again.
</Note>

## Changelog as an Input, Too

Your published changelog is also a **source** BuildBetter reads:

* [Releases / Close the Loop](../Success/close-the-loop) ingests changelog entries alongside GitHub releases and RSS to build the shipped-feature catalog.
* [Knowledge Gaps](../Success/knowledge-gaps) checks those same releases against your documentation.

So writing a substantive entry does double duty: customers read it, and BuildBetter uses it to match shipped work back to requests and to find documentation that fell behind.

<Warning>
  Version-only entries — a number and nothing else — give both features nothing to work with. Knowledge Gaps will classify them `insufficient_evidence` and Close the Loop can't match them to a request. A sentence about what changed is the difference.
</Warning>

## Publishing vs Telling

Publishing an entry is a broadcast. It does not tell the customer who asked for that specific feature — see [Close the Loop](../Success/close-the-loop) for the individual follow-up.

## Next

<CardGroup cols={2}>
  <Card title="Portal Overview" icon="layout-grid" href="./overview">
    How boards fit together.
  </Card>

  <Card title="Knowledge Gaps" icon="book-open-check" href="../Success/knowledge-gaps">
    Finding docs your releases outran.
  </Card>
</CardGroup>