> 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/beta.md).

# Beta

### Purpose

Beta is where the preferred alpha approach is built and tested with real users. The goal is to develop a usable, secure and supportable service or product and prepare it for live operation.

### When to Use This Phase

Use beta when alpha evidence supports a preferred solution and the customer is ready to build, test and release usable increments with real users.

### Primary Decision

At the end of this phase, we should be able to answer:

> Is the service good enough, safe enough and operationally ready enough to move into live use?

### Core Questions

* What is the minimum viable service?
* Which users will access private beta?
* When can public or wider beta begin?
* What must be tested before live?
* What support model is needed?
* What metrics will show performance?
* What security and data evidence is required?
* What defects or risks block live release?

### Key Activities

* production-grade build
* private beta release
* public or wider beta release where appropriate
* user research with real users
* accessibility testing
* integration testing
* security testing
* performance testing
* service support design
* operational readiness planning
* release planning
* defect management
* documentation

### Expected Outputs

* working service or product
* release notes
* tested user journeys
* support model
* operational documentation
* security evidence
* performance evidence
* accessibility evidence
* service metrics
* live readiness assessment
* updated roadmap

### Entry Criteria

* alpha recommendation approved
* beta Statement of Work agreed
* backlog prioritised
* team mobilised
* environments available or planned
* security approach agreed
* acceptance model agreed

### Exit Criteria

* service works for intended users
* critical user journeys are tested
* security and assurance requirements are met or risk-accepted
* support model is ready
* monitoring is in place
* performance is acceptable
* live release decision is recorded

### Evidence to Capture

* completed backlog items
* test evidence
* user research findings
* defect log
* accessibility report
* security review
* deployment records
* monitoring evidence
* support readiness checklist
* live readiness report
* acceptance certificates

### Commercial and Statement of Work Considerations

* tie milestones to evidence and accepted deliverables
* use change control for material scope changes
* track customer dependencies that affect delivery
* maintain payment evidence
* ensure supplier deliverables support acceptance

### IP and Accelerator Considerations

* separate reusable components from customer-specific outputs where possible
* confirm ownership and licence of any foreground IP
* record open-source components
* avoid embedding restricted customer material into reusable assets
* update accelerator library only after IP review

### Security, Data and Assurance Considerations

* apply secure development practices
* manage secrets properly
* run vulnerability checks
* confirm access controls
* test data handling
* prepare security evidence
* confirm incident and support routes before live

### Common Risks

* beta treated as a full uncontrolled build
* private beta feedback ignored
* operational support designed too late
* security evidence delayed
* performance issues discovered at live gate
* scope expands without change control
* supplier tasks not integrated into release plan

### Practical Checklist

* Confirm beta scope and acceptance criteria
* Set up environments and repositories
* Build and test increments
* Run private beta with selected users
* Capture and prioritise feedback
* Run security, accessibility and performance checks
* Prepare support model
* Prepare live readiness evidence
* Run beta exit review
* Record live decision