Phase expectations

Score the service against the phase it is actually in. Do not import the next phase's bar, and do not excuse a later phase with Discovery-era evidence.

The panel's job is to judge the quality of the work for this phase. A team that should stop has not failed Discovery. A team that is already building has.

Discovery

Purpose: define the problem, the users, the policy boundaries, and the existing landscape. Decide whether to proceed, join another service, or stop.

In scope:

• Problem framing and the whole user journey, including waste in the current service.
• User groups and exploratory research into their context.
• Policy and organisational constraints, tested rather than repeated.
• Legacy systems, data ownership, and integration constraints at the level of understanding, not design.
• Team shape and a way of working that can still change direction.
• A real decision, including a decision to stop.

Out of scope, and not a reason to mark a point Not Met:

• Visual design, a component library, or a coded prototype.
• A target architecture, production infrastructure, or a versioned data schema.
• WCAG audits, performance KPIs, open-source publication, and operational runbooks.

Guardrail: penalise premature UI designs, code, or architecture commitments. Treat them as evidence the team has left the problem space. Production code in Discovery is a failed Discovery, not a head start. The technical assessor must say that this is premature architecture, that the team is still in the problem space, and that they should not write production code.

Stopping is a valid and often correct outcome. Do not reward a team for assuming an Alpha build.

Points the Discovery panel scores: 1, 2, 3, 6, 7, 9, 11, 13. Leave 4, 5, 8, 10, 12 and 14 unassessed.

Alpha

Purpose: test the riskiest hypotheses. Learn whether a service is worth building and which approach might work.

In scope:

• A hypothesis backlog and evidence of what was discarded.
• Concept testing with users, including people who are digitally excluded or vulnerable.
• Several throwaway prototypes, including a look at GOV.UK patterns and an early assisted-digital journey.
• Technical spikes, schema experiments, an architectural risk register, and a buy-versus-build rationale.
• A team that can move into a delivery-oriented Beta, and a decision log that shows they might still stop.

Out of scope, and not a reason to mark a point Not Met:

• Production hosting, a hardened pipeline, or a single design signed off as the Beta UI.
• A finished WCAG 2.2 AA audit, published KPIs, or a public live service.
• Full assisted-digital operations. Alpha must explore the route, not staff it.

Guardrail: penalise premature production infrastructure and single-design lock-in. Spikes must be disposable. A prototype that the team "might as well keep" is a lock-in.

Points the Alpha panel scores: 1, 2, 3, 4, 6, 7, 8, 9, 11. Point 5 is explored through assisted-digital prototypes but is not a hard gate until Beta. Leave 10, 12, 13 and 14 unassessed unless the team has made a commitment that creates a later risk. Record that commitment as a recommendation, not as a Live failure.

Beta

Purpose: run a real service end to end with real users, in private beta and then with a credible plan for public beta.

In scope:

• Working software across the whole journey the user must complete, including the non-digital parts of that journey.
• Private beta with enough real users to see drop-off, and a plan for public onboarding.
• Usability evidence, including people using assistive technology.
• An independent WCAG 2.2 AA audit.
• A KPI baseline: completion rate, user satisfaction, digital take-up, cost per transaction, plus step drop-off.
• ADRs, security scanning in CI/CD, a DPIA, rollback, open code, and common-platform decisions.
• Assisted digital as an operational route, not a research note.

Out of scope:

• Live operating maturity: rehearsed disaster recovery, a completed supplier exit, and a fully handed-over civil service team. Beta must show the design of these. Live must show they have been exercised. Do not fail Beta solely for lacking a year's operating history.

Guardrail: point 5 is an automatic Not Met if users of assistive technology were not in the research. Screen readers (JAWS, NVDA, and others), screen magnifiers, and speech input count. An audit PDF does not replace those sessions. A Design System claim does not either.

Points the Beta panel scores: all 14.

Live

Purpose: run the service, keep improving it, and hold the capability in the civil service.

In scope:

• Funded ongoing operation and a team that is not stranded on a supplier.
• A research cadence and a live feedback loop, tied to satisfaction and the other published measures.
• A design and content backlog driven by drop-off and contact-centre demand.
• Zero-downtime or otherwise safe deployment, live monitoring, incident runbooks, a tested disaster-recovery drill, and a contract exit strategy.
• Continuous improvement since the last assessment. A Live service that has not changed is stagnant.

Out of scope:

• Re-litigating Alpha prototypes, or demanding a fresh Discovery problem statement, unless the service's purpose has changed.

Guardrail: documents that were enough at Beta are not enough at Live. The panel should see drill records, incident history, published data, and named civil servants who can change the service.

Points the Live panel scores directly: 1, 3, 4, 5, 6, 7, 8, 9, 10, 14. Points 2, 11, 12 and 13 are not re-opened unless the service, the stack, or the contract has materially changed. If they have changed, assess the change. If they have not, record Not reassessed and do not fail the service for the absence of a fresh opinion.

Leakage checks

Before scoring, answer these. If the answer is yes, you are in the wrong phase's rubric.

Vocabulary

• Met and Not Met are the only point decisions in the report.
• Not assessed means the point is outside this phase. It is not a failure.
• Not reassessed means Live left an unchanged point on its previous evidence. It is not a failure.
• PASS and FAIL describe a single assessor's package. FAIL if any point they own is Not Met or a red line in their scope fired.
• Conditions block the next phase. Recommendations do not.