A reliable record of shipped product changes.
The Ethen Changelog is the future home for release notes tied to shipped product changes, documentation updates, Gateway improvements, local runtime notes, and workflow surfaces. Use this section to learn how shipped updates should be recorded once they are real. The strongest resources show what people can do in Ethen, how model choice changes the workflow, and what still needs review. A changelog only works when each entry maps to a real release instead of broad marketing claims.
A record of what actually changed.
A changelog should be a record, not a roadmap. It should help users understand what shipped, what changed, and where to learn more in docs or product pages. The point is not theory for its own sake. It is to help users who want a reliable history of product movement understand the workspace well enough to make better decisions about routing, local lanes, evidence, and approvals in daily work.
- Release notes should reflect shipped changes.
- Entries should include dates and versions only when real records exist.
- Product updates should link to relevant docs or product pages.
- Local, Gateway, Workflow, and Code updates should be specific to actual changes.
Changelog topic areas
The changelog can organize changes by product surface once updates are ready to publish. Good topic coverage should connect product surfaces to real workflow questions. Readers should come away knowing what problem a resource solves, what task it supports, and where to go next if they need deeper detail.
Workspace updates
Changes to the model console, workspace history, visible work, and navigation. A strong resource explains not just the idea, but the decision the reader can make after reading it.
Gateway updates
Changes to model routing, route visibility, fallback behavior where configured, and request history. A strong resource explains not just the idea, but the decision the reader can make after reading it.
Local model updates
Changes to local lane support, runtime direction, and open model workflows where supported. A strong resource explains not just the idea, but the decision the reader can make after reading it.
Workflow updates
Changes to workflow design, approvals, evidence, and reusable patterns. A strong resource explains not just the idea, but the decision the reader can make after reading it.
Docs updates
Changes to reference direction, guides, tutorials, and product documentation. A strong resource explains not just the idea, but the decision the reader can make after reading it.
Start here instead
Until release notes are published, these areas explain the current product direction. A useful starting point lowers confusion. It should help someone choose between a broad concept, a hands-on walkthrough, a reusable pattern, or a product-specific explanation without forcing them to guess.
Docs
Review technical reference direction and product concepts. That makes the next step clearer for someone who is still learning the workspace.
Status
Understand status visibility as a platform concept. That makes the next step clearer for someone who is still learning the workspace.
Products
Explore the current product surfaces. That makes the next step clearer for someone who is still learning the workspace.
Blog
Read product notes and essays when published. That makes the next step clearer for someone who is still learning the workspace.
Update paths
Changelog entries should make it easy to find the affected product or documentation area. Different formats carry different weight. Some pages should explain the operating idea, some should teach the steps, and some should preserve a reliable record people can return to later.
Code path
Updates to code workflows, review, and validation-aware planning. Use the format that fits the job instead of forcing every topic into the same shape.
Gateway path
Updates to model routing and request visibility. Use the format that fits the job instead of forcing every topic into the same shape.
Local path
Updates to local model direction and private lanes where supported. Use the format that fits the job instead of forcing every topic into the same shape.
Workflow path
Updates to approvals, evidence, reusable workflows, and run history. Use the format that fits the job instead of forcing every topic into the same shape.
Availability notes
The changelog should stay honest by publishing only real shipped updates. That honest boundary matters because trust grows when a resource page explains what belongs here today, what belongs here later, and what the public record does not support yet.
Shipped changes
Entries should reflect product changes that have actually shipped. That keeps the page useful without overstating what is already published.
No fake versions
Version numbers, release dates, and change IDs should come from real release records. That keeps the page useful without overstating what is already published.
Docs alignment
Release notes should link to docs when behavior needs explanation. That keeps the page useful without overstating what is already published.
Incident separation
Incidents and availability history belong in status materials when real data exists. That keeps the page useful without overstating what is already published.
Related products
Coding workspace updates when shipped. Visit the product surface when the concept needs a more direct example.
Model routing update area. Visit the product surface when the concept needs a more direct example.
Local lane update area. Visit the product surface when the concept needs a more direct example.
Workflow update area. Visit the product surface when the concept needs a more direct example.
Status visibility for model and workflow availability. Visit the product surface when the concept needs a more direct example.
Related resources
Documentation hub. Use it as the next step when you want a different learning format.
Product notes when published. Use it as the next step when you want a different learning format.
Routing concepts and documentation. Use it as the next step when you want a different learning format.
Workflow concepts and review paths. Use it as the next step when you want a different learning format.
Resource hub. Use it as the next step when you want a different learning format.
Frequently Asked Questions
Follow what actually ships.
Use Docs and product pages now, and return to the changelog for real Ethen release notes as shipped updates are published. Start with the format that matches your question, then move deeper once you understand how the work, the model lane, and the review path fit together.