> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/agile-delivery-playbook/delivery-phases/alpha.md). # Alpha ### Purpose Alpha is used to test possible solutions and the riskiest assumptions. The goal is to learn which approach is most likely to work before building at scale. ### When to Use This Phase Use alpha when discovery has identified a valuable problem but there are still major uncertainties about the right solution, technical feasibility, user journey, data flow, operating model or assurance route. ### Primary Decision At the end of this phase, we should be able to answer: > Which solution option should move forward, and what evidence supports that decision? ### Core Questions * Which assumptions are most risky? * Which options should we test? * Can users complete the key journeys? * Can the technical approach work? * Can required data be accessed and shared safely? * What security or assurance barriers exist? * What should be built in beta? * What should be stopped or discarded? ### Key Activities * prototype creation * user testing * technical spikes * architecture options analysis * integration proof of concept * data feasibility testing * service design iteration * content design testing * accessibility review * security risk exploration * operating model design * beta backlog development ### Expected Outputs * tested prototypes * user testing findings * technical feasibility evidence * architecture recommendation * data feasibility assessment * security considerations * preferred option * beta backlog * beta roadmap * updated risks * commercial assumptions for beta ### Entry Criteria * discovery recommendation approved * alpha objectives defined * riskiest assumptions identified * team roles agreed * prototype tooling agreed * security constraints understood * commercial authority in place ### Exit Criteria * key assumptions tested * preferred approach selected * evidence supports the recommendation * beta scope is understood * major risks and constraints are recorded * technical approach is credible * customer decision is recorded ### Evidence to Capture * prototype links or screenshots * research findings * test results * architecture decision records * spike reports * accessibility notes * security notes * beta backlog * show and tell outputs * alpha recommendation report ### Commercial and Statement of Work Considerations * make clear that prototype work is not production build unless agreed * define which alpha outputs are deliverables * update assumptions for beta pricing and scope * identify any change from discovery expectations * prepare acceptance criteria for beta deliverables ### IP and Accelerator Considerations * use accelerators to build prototypes quickly * label prototype code appropriately * avoid accidentally transferring reusable components * record any reusable improvements created during alpha * confirm third-party or open-source components before wider use ### Security, Data and Assurance Considerations * do not expose real sensitive data in prototypes unless approved * review data flows early * identify likely threat model areas * confirm access control implications * identify security evidence needed for beta and live ### Common Risks * prototype mistaken for production service * testing too many options weakly * not testing the riskiest assumptions * user research gaps * technical spike results not documented * accessibility left too late * beta scope based on opinion rather than evidence ### Practical Checklist * Confirm alpha questions * Rank riskiest assumptions * Plan prototypes and spikes * Run user testing * Run technical feasibility tests * Review security and data implications * Compare options * Develop beta backlog and roadmap * Run alpha playback * Record proceed, stop or reshape decision