Core concepts

A few ideas make the rest of the product easier to understand.

If a term in the docs feels unfamiliar, start here. These concepts show up across the hosted changelog, embedded widget, and automation APIs.

Use this page when product words are getting in the way

You do not need to memorize Chainlog vocabulary, but a few concepts make the rest of the product much easier to follow.

Best for new teams

Use this when a term like tenant, entry, context module, or runtime defaults feels too product-specific to infer safely.

Best before deeper setup work

This page is useful before identity rules, automation, or multi-surface publishing because those workflows reuse the same concepts.

The four things to know

These are the main building blocks you will see throughout the product.

Tenant: your Chainlog workspace. It owns your settings, entries, widget config, credentials, API keys, and domains.
Entry: a single update. It has a title, body, summary, visibility settings, and delivery metadata.
Widget: the embeddable runtime that renders entries as a launcher, panel, or inline surface inside your product.
Runtime defaults: widget settings you manage in Chainlog, such as mode, theme, position, launcher label, sizing, and max items.

Where updates can appear

The same entry can show up in more than one place depending on how you publish it.

Hosted surfaces

Public changelog pages, feed exports, and customer domains are best when you want a stable, linkable destination outside your product UI.

Embedded surfaces

Launcher, panel, and inline widget modes are best when updates should stay inside your app and inherit your auth state.

How visibility and targeting work

Who sees an update is a product rule, not a styling choice.

Entries can be public or require authenticated widget access depending on visibility rules.
JWT claims can narrow what a user sees through entitlements, internal access, and context module claims.
Entry metadata such as delivery type, change category, release status, platform, audience, and product area drive both filtering and downstream automation.
Tenant settings can choose defaults such as showAllUpdatesByDefault, but entry visibility still controls what a user is allowed to see.

Design implication

Keep frontend code thin. Put real audience decisions in entry metadata, JWT claims, and tenant settings so the hosted changelog, widget, feeds, APIs, and docs surfaces stay consistent.

How the workflow usually moves

Updates pass through a simple lifecycle even when the source systems or delivery surfaces differ.

Draft entries can be created manually, through AI draft generation, via schedules, or through server-side APIs.
Teams review and enrich the metadata so targeting and downstream automation stay consistent.
Published entries appear on the changelog, widget, feeds, docs surfaces, and webhook stream.
Publishing can also trigger audit logs, signing, and subscriber notifications when those features are enabled.