Releases & Evidence

The Release phase is where everything comes together. You package completed user stories into a versioned release, attach evidence that proves the work was done correctly, and produce documentation that auditors and stakeholders can review with confidence.

Audra Flow makes this process straightforward by automatically pulling together the traceability chain you have been building throughout Discovery, Definition, Design, and Delivery. Instead of manually assembling release notes and evidence, you get a structured, auditable package with a few clicks.

Creating a Release

A release in Audra Flow is a snapshot of completed work that is ready to go out the door. Here is how to create one.

Step-by-Step

1. Navigate to the Release phase in your project sidebar.
2. Click Create Release. Audra Flow will show you all user stories that have been completed since your last release.
3. Select the stories you want to include in this release. You can include all completed stories or pick a subset if you are doing a partial release.
4. Set a version number for the release. Audra Flow suggests the next version based on your versioning scheme, but you can override it.
5. Add release notes. Describe what is new, what changed, and anything users or stakeholders need to know. The AI can generate a draft of release notes from your included stories if you prefer a starting point.
6. Review the release summary. Audra Flow shows you a complete overview of what is included: stories, linked specifications, architecture decisions, and the goals each story traces back to.
7. Click Finalise Release. The release is locked and becomes part of your project's permanent record.

What Happens When You Finalise

Finalising a release does several things:

• The release becomes immutable. Its contents, evidence, and metadata cannot be changed after finalisation. This is critical for audit integrity.
• An evidence summary is generated automatically, pulling together the full traceability chain for every included story.
• The release is assigned a permanent version number and appears in your project's release history.
• All included stories are marked as released, so they will not appear as candidates for future releases.

Evidence Summaries

An evidence summary is the heart of an Audra Flow release. It is an automatically generated document that shows, for every story in the release, the complete chain of reasoning and artifacts that led to its creation.

What Gets Included

Each evidence summary contains the following for every included story:

Why Evidence Matters

Evidence summaries serve multiple audiences:

• Auditors can verify that every piece of delivered work traces back to a documented need and was reviewed before release.
• Stakeholders can see exactly how their goals are being addressed, story by story.
• Product teams can use the evidence trail to understand decisions made in previous releases when planning future work.
• Compliance teams get the documentation they need for regulatory requirements without anyone having to assemble it manually.

Version Management

Audra Flow uses a structured versioning scheme to keep your releases organised and easy to reference.

Versioning Scheme

Releases follow a major.minor.patch versioning pattern:

When you create a new release, Audra Flow looks at your previous releases and suggests the next version number. You can accept the suggestion or set your own version.

Release History

Your project's release history is available in the Release phase. It shows every release in chronological order with:

• Version number and release date.
• Number of stories included.
• A summary of what changed.
• Quick access to the full evidence summary.

Comparing Releases

You can compare any two releases to see what changed between them. The comparison view shows:

• New stories — stories that were added in the newer release.
• Specifications covered — which specifications gained new stories.
• Goal progress — how much closer the newer release brings you to your project goals.

This comparison is useful for stakeholder updates and sprint reviews, where you need to communicate progress clearly.

Audit Documentation

Audra Flow is designed to produce audit-ready documentation without additional effort. Every release automatically includes the information auditors typically need.

What Auditors and Stakeholders See

When an auditor or stakeholder reviews a release, they see:

• Full traceability — every story in the release links back through architecture, specifications, and goals. There are no orphaned stories with unclear origins.
• Acceptance criteria — each story has documented criteria for what “done” looks like.
• Change history — who created, edited, and approved each artifact, with timestamps.
• AI involvement — which artifacts were AI-generated and which were created manually, providing transparency into how the product was planned.
• Version lineage — the full history of releases, showing how the product has evolved over time.

Immutable Audit Trail

Once a release is finalised, its contents become immutable. This means:

• No one can alter the stories, evidence, or metadata after the fact.
• The audit trail is tamper-resistant — what was released is permanently recorded as it was at the moment of finalisation.
• If corrections are needed, they must be made in a new release, preserving the history of what was originally shipped.

This immutability is enforced at the application level and backed by the audit logging system described in the Security & RBAC documentation.

Deployment Tracking

After a release is finalised, you can track its deployment status to keep your team and stakeholders informed about where things stand.

Tracking Deployment Status

Each release in Audra Flow can be marked with a deployment status:

Updating the deployment status is a manual step — you or a team member marks the release as deployed once it is live. This keeps a record of when each release actually reached users.

Release History and Reporting

The release history gives you a timeline of your product's evolution. You can use it to:

• See how frequently you are shipping and whether your pace is accelerating or slowing.
• Identify which goals have been addressed across releases and which still need attention.
• Provide stakeholders with a clear, chronological record of product progress.

Tips for Effective Releases

Here are practical recommendations to get the most out of Audra Flow's release capabilities.

Attach Evidence Early

Do not wait until release day to think about evidence. As you work through the Design and Delivery phases, make sure your stories are linked to specifications and your architecture is linked to goals. The evidence summary is only as good as the connections you have built along the way.

Use the Traceability Graph

Before finalising a release, open the traceability graph and check for completeness. Look for:

• Unlinked stories — stories that do not trace back to a specification. These create gaps in your evidence chain.
• Uncovered goals — goals that have no stories in the release. If a goal was supposed to be addressed, make sure the relevant stories are included.
• Broken chains — stories that link to a specification, but that specification does not link to a goal. Fix these connections before finalising.

Write Meaningful Release Notes

Release notes are often the first thing stakeholders read. Keep them focused on outcomes rather than implementation details. Instead of “Implemented shopping cart component,” write “Users can now add items to their cart and review them before checkout.”

Keep Releases Small and Frequent

Smaller releases are easier to review, test, and deploy. They also produce cleaner evidence summaries because there is less to track. If a release starts to feel large, consider splitting it into two smaller releases.

Review Before Finalising

Once a release is finalised, it cannot be changed. Take a moment to review the included stories, verify the version number, and double-check the release notes. It is much easier to fix something before finalisation than to explain a correction in a subsequent release.

Next Steps

• Learn how to build the artifacts that go into your releases in the Design & Delivery guide.
• Understand how permissions control who can create and finalise releases in Security & RBAC.
• See how AI agents help throughout the process in the AI Service documentation.
• Return to the Quick Start guide if you need to set up your environment.