Work architected at Fifth9
Release Fabric.
Carry the work into use.
Turn a software change into a version a team can identify, examine and adopt. Connect the package, its checks and the decision to deploy, then observe what happened and keep a route back.
Current scope: Release tooling, recorded release history and an evolving operator console.
From change to use
One artifact.
Distinct decisions.
Keep the release identity with its evidence. Passing a check informs the decision to adopt; observing the deployed version closes a different question.
Detailed diagram and text
Conceptual release lifecycle
Identify
Describe the version, included components and exact artifact identities.
Examine
Check package consistency, provenance and the relevant user journey.
Decide
Review the result and approve, defer or return the candidate.
Deploy and observe
Confirm the version in use and examine its behaviour.
Revise or hold
Keep the findings attached to the candidate.
Recovery needs a known destination. Where a previous environment remains available, restore it and check it again. Keep the outcome for the next release.
A conceptual view of release responsibilities. Available tools support parts of this journey; the diagram does not certify a complete deployment.
Illustrative example
A healthy start.
A failed journey.
A candidate starts successfully, but a sign-in or chat check fails. Keep the candidate and its failure record distinct from the version people should use.
“It starts—but can people complete their task?”
- Identify the candidate. Keep its version and checks together.
- Inspect the failure. Decide whether to revise, hold or recover.
- Check the recovery. Confirm the restored version and repeat the relevant journey.
Technical reading
What makes a release traceable?
Artifact history, validation, deployment authority and operational behaviour answer different questions.
Artifact identity and package consistency
A release manifest describes the included images and configuration. Content digests identify particular image bytes; a tag alone can move. The release-cut workflow includes checks intended to keep the manifest, deployment configuration and selected component set consistent.
Historical release directories contain concrete application-image digests alongside unresolved substrate placeholders. They are useful release records, but their presence does not establish that every dependency is pinned or that every environment is reproducible. A declared signature reference also differs from a signature verified against the expected builder identity.
Provenance, startup and user journeys
Implemented tooling includes build-provenance verification, package validation and post-deployment checks. Provenance records where an artifact came from; it does not establish application correctness. Startup and health checks answer narrower questions than authenticated use.
Choose checks for the release being delivered. A background job and an interactive service need different execution checks. Record failures and deferred checks beside the result; evaluate the actual candidate rather than transferring a previous release’s verdict.
The console supports a decision
Console source includes workflow-status views, validation-result reading, release-cut dispatch and promotion logic. It presents information and requests work from the release workflow; it does not itself build or sign the artifacts.
The intended normal promotion path checks the validation result before dispatch. The implementation also includes an explicit override path. Release-identity checks and any override decision need to be examined together; a displayed verdict alone is not an unconditional adoption guarantee. Wider console and release-train plans have their own delivery stages.
Adoption and recovery are separate effects
Blue-green tooling works with two configured environments so traffic can be switched between them. The rollback script selects an available previous destination, requests a switch and normally reruns smoke checks. It refuses when no suitable previous destination is available; an explicit option can skip verification, so recovery must be judged by what actually ran.
A traffic switch does not necessarily undo data migrations, external effects or incompatible state. Recovery needs a usable prior environment and an applicable data plan. The inspected unit tests exercise state history and routing-configuration generation; they explicitly exclude the actual web-server reload effect. They are not a live rollback demonstration.
Source context and current scope
This case draws on the Conduir release repository, release-console implementation and release-cut and train documents inspected on 3 November 2026. Versioned manifests preserve historical release results; tools and tests show implemented mechanisms. The release-train document remains a draft, and console documentation and later code describe different stages.
No present deployment, registry signature or complete release journey was independently exercised for this page. The longer direction is to make the handoff from engineering evidence to operational use clearer and more dependable.
Continue the thread