Veliose gathers the evidence of each software change once, drafts from it in three workflows, and publishes only what a person approves. This page follows one change through the platform.
Sources
Veliose works a release at a time: the pull requests merged between two GitHub releases, across every repository of the product. Each pull request names its Jira ticket by key, and Veliose reads the ticket’s description and acceptance criteria along with the pull request.
One change record
Pull requests that name the same ticket become one change. Its record holds the ticket and every pull request behind it, and each draft made from it keeps those sources. A reviewer sees exactly what a draft was written from.
Three workflows
Release notes
Each note is written in two versions at once. The internal version includes internal changes and their sources and goes to Confluence. The customer version leaves out internal changes and ticket links and goes to the team’s public site. The ticket, not the model, decides whether a note is a fix, a feature or a task.
Help-article updates
Veliose compares each change with the product’s published help articles and drafts a new article or an edit to the one that covers it. Publishing an edit refuses an article that changed after the draft was written.
Test scenarios
Plain-language manual test scenarios for each change, covering every pull request in it.
Every draft states only what its sources say, and describes the product for every team that uses it. Drafts are written with Anthropic’s Claude.
A person reviews every draft
Nothing is published from a pending draft. On the dashboard’s Review page, a reviewer sees each draft beside its pull requests and tickets and approves or rejects it. Release notes can also be split or merged. Each decision records who made it.
Publishing into the tools a team already uses
Destinations are adapters listed in one registry: Confluence and WordPress today. A product chooses a destination for each kind of output. Adding a destination, such as another help-center tool, is a registry entry and its publisher, with no change to the workflows.
A product is configuration
Onboarding a product means filling in its settings on the dashboard: its repositories, its Jira project, its destinations and the accounts it connects. A readiness checklist keeps Generate, Review and Publish closed until the product is set up.
How credentials are kept
Each product connects its own GitHub, Atlassian and WordPress accounts on the dashboard’s Connections page. Credentials are stored encrypted with AES-256-GCM, decrypted only inside the job that uses them, and never sent to the browser or written to a log. Who connected an account, approved a draft or reshaped a release note is kept in a record that can be added to but not changed.
See it running
The live demo shows a sample product’s changes as drafts, reviews and published pages.