Change Layer Docs
    Checking session...

    How Change Layer Works

    Change Layer is organized around a small set of related records and workflows. Once you understand how product structure, publishing, and integrations connect, the rest of the app becomes much easier to reason about.

    The content model

    NameTypeRequiredDescription
    TeamworkspaceYesOwns members, products, plan settings, API access, and workspace visibility.
    ProductcontainerYesRepresents one product or surface. A product can have changelog, release notes, and roadmap data.
    ChangelogfeedYesThe ordered list of product versions that readers browse on the hosted changelog page.
    VersionreleaseYesA release entry with a version number, release date, publish state, and grouped changes.
    ChangeentryYesAn individual item inside a version, such as a feature, improvement, or fix.

    What Change Layer is for

    Change Layer is meant to help teams manage the full loop around shipping product work:

    • planning what is coming next
    • documenting what shipped
    • communicating changes clearly
    • making product context available to developers and tools

    That is why the product spans roadmaps, release notes, changelogs, and developer-facing access patterns instead of focusing on only one publishing surface.

    How content becomes visible

    The product separates editing from publishing:

    1. Your team creates or updates a changelog.
    2. Versions are drafted manually or generated from GitHub activity.
    3. Changes are reviewed and reordered inside each version.
    4. The version is published.
    5. The changelog itself must also be published before public readers can see it.

    Visibility rules

    Published content is still not public if the team is private. Private teams require authenticated membership checks before the app returns changelog data.

    How users usually navigate the app

    • The dashboard is where users switch teams and open products.
    • Each product acts as the home for its changelog, release notes, roadmap, and future developer tooling.
    • The changelog page is where teams create versions, manage changes, and control publish state.
    • Management settings let teams adjust visibility, branding, and related metadata.

    Where the API fits

    Phase 1 public changelog reads are now available under /v1/public, while the app still reuses the existing internal API layer behind the scenes.

    • Public routes return published data for published products in public teams.
    • Internal app reads can still return richer data for signed-in team members.
    • The first public endpoints cover changelog feeds and single-version reads.

    AI and agent workflows

    Change Layer is increasingly being positioned as infrastructure for AI-assisted product work. As that direction expands, the goal is for MCP and CLI tooling to let agents and developers read product context, release history, and structured updates more naturally.

    This matters because agents are more useful when they can understand:

    • what a product is
    • what has already shipped
    • what is planned next
    • how teams describe changes for customers and internal stakeholders

    When to use which read pattern

    • Use a public changelog read when you want to render published updates in a website, widget, or embed.
    • Use a protected changelog read when you are building authenticated product screens or internal tools.
    • Use a filtered changelog read when you only need one version instead of the entire feed.