A public showcase of readiness tools, templates, and quality frameworks from Phoenix Ascend’s Canopy toolkit.
This repository offers a curated subset of the internal PXA-Canopy delivery system—designed to help teams validate, prepare, and elevate the quality of their software.
Canopy is Phoenix Ascend’s quality and readiness toolkit. It helps delivery teams assess “what ready looks like” through structured templates, validation rituals, and quality frameworks.
This showcase provides publicly available resources that reflect Canopy’s values: clarity, completeness, and confidence—whether preparing for launch, reviewing quality posture, or improving delivery standards.
| Tool | Description |
|---|---|
| Hi-Lo Gauge | Used to assess the Quality of a product version and where the team wishes to increase it to based on defined Quality criteria. |
| Sanity Check | Deployment Pre-Check for a given package. Should we release this thing? |
| Loading Dock | Visual aid when team plans to close packages and deploy packages. Indicates version # and success/fail of intent. Time is broken up by Weeks called Loading Docks. |
Canopy is guided by the RAIDS framework: five quality pillars that define what “high quality” means in a working software system.
- S1 - No Critical/High Vulnerability from Checkmark Scans for every release package deployed to .Mil
- S2 - Always use the latest stable versions of third party vendor dependencies
- S3 - Code Package Built is the same Code Package Released
- S4 - No Unauthorized use of a Product's Functionality
- S5 - Give Access to only those essentially vital to perform its Intended functions
- S6 - Never use technology that is no longer actively supported by the vendor
- D1 - Use near to real-time data essential to perform its Intended functions
- D2 - Only valid data points are used
- D3 - Provide accurate data so the customer can make the best business decision
- D4 - All data inputted goes through data transformation
- R1 - Existing functionality continues to work as new functionality is introduced
- R2 - Implementation Changes do not change functionality
- R3 - Defects are identified before the customer identifies them
- R4 - Existing functionality works as expected when it is needed
- I1 - Reliably Integrates with service dependencies
- I2 - New Functionality Integrates well with existing functionality
- I3 - Integrated Functionality does not degrade acceptable Performance
- I4 - Code Package Released is compatible with all Integrated needs
- A1 - Criteria defined by the customer and understood by Engineer
- A2 - New Functionality Changes work as agreed upon criteria
- A3 - Changes are Only made to provide value to the customer
- A4 - Technical debt is identified before changes are released
- Dev teams preparing for high-stakes releases
- QA analysts seeking lightweight coverage rituals
- Consultants onboarding quality-first workflows
These assets are used and refined inside Phoenix Ascend’s client delivery process. More tools, walkthroughs, and licensing information coming soon.
Canopy reflects our belief that quality isn’t just a gate—it’s a guide.
For updates or licensing inquiries, visit: 🌐 phoenixascend.com 📧 canopy@phoenixascend.com
🚀 Helping teams craft the right thing, at the right time, in the right way.