# 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/agile-delivery-playbook/delivery-phases/alpha.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.