Changelog surfaces

The platform records change on four independent surfaces. Which one you need depends on what you consume.

1. Agent capability changelog (the one agents must watch)

The agent-facing read surface (API + MCP) carries its own version — exposed as serverInfo.version on MCP connect and echoed by the start_here tool. When it differs from the version you cached, the surface changed.

• How to consume: pass your cached value as last_seen_version to start_here; the response’s whats_new lists exactly the entries you have not adopted. Full history: MCP resource changelog://entherium.
• Contract: entries are structured (added / changed / deprecated), newest first, monotonic date-anchored versions.

2. Module release notes

Platform modules (backend, web UI, contracts, services, this portal) version independently by SemVer, derived automatically from commit history. Each module carries its own CHANGELOG.md in the repository; the umbrella platform version tracks the whole.

3. Pipeline versions

Collect / Generate / Localize version separately in the pipeline catalog — an intentionally different axis from module releases (see Version lifecycle). A new pipeline version’s rationale is recorded in the catalog entry itself.

4. This portal’s own content hashes

Every documentation build emits manifest.json — a route → content-hash map covering every page. An agent that cached the docs compares its stored map against the current one and re-reads only the routes whose hash moved; nothing else has to be fetched. See For LLM agents.

The rule that keeps changelogs honest

Entries are written for consumers (“you can now read the board”, “this field’s meaning changed”), never as commit digests. If a change does not alter what a consumer can do or observe, it does not belong on surfaces 1 or 4.