Alpha evidence checklist
The architecture evidence for alpha, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
Prototype - testing with users
This section is an early prototype that we are testing with users. It may change a lot, and some of it may be wrong. Check with your solution design authority before relying on it, and tell us what works and what does not through the feedback link above.
Tick what you have, link to where it lives, and bring it to your solution design authority or assessment. Where you cannot meet a Must, record the approved exception .
Print this checklist
Artefacts
Must guardrails
GR-AI-02 Use approved AI services and tenancies - AI services chosen for the design, each confirmed as running in a Defra tenancy or under an approved agreementGR-AI-03 Keep a human accountable - Design of the human oversight and challenge route for decisions with significant effects, tested with users in prototypesGR-API-07 Secure every API - Authentication, authorisation, input validation and rate limiting designed for each APIGR-TECH-01 Look for something to reuse first - ADR recording the reuse options considered and why they did or did not fitGR-TECH-04 Assess SaaS before you adopt it - Security, data protection, data location, accessibility and single sign-on assessed before contractGR-DATA-06 Protect personal data by design - Draft DPIA, with data minimisation and retention designed inGR-FE-01 Meet WCAG 2.2 AA - Prototypes built with accessible components, and a plan for an accessibility audit and assistive technology testingGR-FE-02 Use the GOV.UK Design System - Prototypes built with the GOV.UK Design System, with departures recorded and researchedGR-FE-06 Support Welsh where required - Whether the Welsh Language Standards apply decided, and the service designed for translationGR-HOST-01 Use Defra's strategic delivery platform by default - The design runs on the Core Delivery Platform, or an exception has been requestedGR-IAM-01 Use the strategic customer identity services - Sign-in designed with Defra Customer Identity, and tested with usersGR-IAM-05 No secrets in code - Secret scanning on from the first commit, and secrets held in a managed store from the startGR-OPEN-01 Code in the open - Code public in a Defra GitHub organisation from the first commit, or a recorded reason for keeping a repository privateGR-SEC-01 Follow Secure by Design - Secure by Design activities for alpha completed, including security requirements in the backlogGR-SEC-02 Keep a current threat model - First threat model, created by the teamGR-SEC-03 Classify information - Controls in the design that match the classificationGR-SEC-09 Manage risk explicitly - Risks from controls that cannot be met recorded, with an ownerGR-DEV-02 All code in Defra source control - All code, including prototypes and infrastructure code written by suppliers, in a Defra-owned GitHub organisation from the first commit
Should guardrails
GR-AI-01 Consider AI first - ADR recording the AI options considered and why they were or were not usedGR-AI-05 Evaluate, monitor and threat model - Evaluation plan for accuracy, bias and safety, and AI-specific threats in the threat modelGR-AI-06 Talk to the TDA about novel use - Technical Design Authority review outcome recorded in the ADRGR-AI-07 Suppliers use AI coding assistants openly and safely - Supplier's agreed list of AI coding assistants and how each runs within Defra-approved terms, the review process for generated code, and disclosure in pull requests or delivery reportsGR-AI-08 Give agents the least privilege they need - Each agent's tools and permissions listed in the design, with a workload identity for the agentGR-AI-09 Get human approval for consequential actions - Agent actions classified, and the actions that need human approval identified in the designGR-AI-11 Defend agents against prompt injection - Threat model covering prompt injection through every input the agent readsGR-API-01 API first - API specification written before or alongside the user interfaceGR-API-02 Describe APIs with open specifications - Draft OpenAPI 3 or AsyncAPI documents for the interfaces you are prototypingGR-API-03 Follow government API standards - API design reviewed against the GDS API technical and data standardsGR-API-05 No integration through shared databases - Container diagram showing integration only through APIs, events or governed data productsGR-API-06 Use events for change notifications - Event and message definitions described in AsyncAPIGR-TECH-02 Buy commodity, build differentiating - Buy or build options appraisal in the ADR or business caseGR-TECH-03 Plan your exit before you enter - Draft exit plan for each new product, platform or significant supplierGR-TECH-05 Prefer open standards and portable technology - ADR noting the open standards used and how portable the choice isGR-DATA-01 Every data set has an owner - Each data set the service will create or hold identified, with a proposed information asset ownerGR-DATA-02 Use authoritative sources - Data flow diagram naming the authoritative source for each shared entity, and how any copies are refreshedGR-DATA-03 Use agreed data standards and identifiers - Data model using the agreed data standards and identifiersGR-DATA-04 Collect once, share safely - Journey design showing users are not asked for information Defra already holds, and data sharing agreements where requiredGR-DATA-10 Handle research data safely - The same for alpha research, with DPIA screening done for the research and any new research tool assessedGR-DATA-11 No real personal data in prototypes - Prototypes and research materials use made-up data, including data a participant types in during a sessionGR-DIG-01 Challenge paper and manual processes - Discovery findings showing paper, email and manual steps in the current process and how the new design removes or justifies each oneGR-DIG-02 Design across organisational boundaries - A map of the whole service, including the parts other teams and organisations deliver, and agreed hand-offs between themGR-DIG-03 Provide assisted digital and offline routes - Assisted digital and offline routes designed and tested with users who need themGR-FIELD-01 Choose devices that suit the job - User research on the working environment, and the device choice recorded in an ADRGR-FIELD-02 Design field tools to work offline - Field journeys tested with no connection, including sync after reconnecting and conflict handlingGR-FIELD-03 Manage and secure every device - Device management approach agreed for the devices the service will useGR-FE-03 Progressive enhancement - Core journeys tested with JavaScript turned offGR-FE-04 Consider forms platforms first - ADR noting whether the forms capability was consideredGR-FE-05 Design for low bandwidth and rural users - Page weight budget, save-progress design and testing on slow connectionsGR-FE-07 Tell users what is happening when things fail or are slow - Each dependency that can fail or be slow identified with the developers, and what users see in each case designed and tested in the prototypeGR-HOST-02 Public cloud first - Where the platform cannot be used, the hosting design uses a Defra-managed public cloud tenancyGR-HOST-04 Use managed services before self-managed - Hosting design listing the managed services usedGR-HOST-05 Consistent, disposable environments - Environments created from the same code, and how lower environments avoid real personal dataGR-HOST-06 Host data in the UK - Hosting design places every data store and backup in UK regionsGR-HOST-07 Design for the resilience the service needs - Recovery time and recovery point objectives agreed with the service owner, and a design that meets themGR-IAM-04 Separate authentication from authorisation - Authorisation rules written down and covered by automated testsGR-OPEN-02 Licence clearly - LICENCE file in every repository from the startGR-OPEN-03 Publish safely - Secret scanning and push protection on for every repository from the first commitGR-OPEN-04 Reuse and contribute back - Reuse and upstream contributions noted in ADRs and pull requestsGR-PROD-01 Fund and run products, not projects - A named, long-lived team responsible for the product, with a roadmap beyond the current funding periodGR-PROD-02 Name the product owner and service owner - Named product owner and service owner, recorded in the service catalogueGR-PROD-03 Contribute to platforms rather than working around them - Requests and contributions raised with platform teams, and ADRs where the team worked around a platformGR-SEC-08 Protect the supply chain - Security assessment of suppliers and third-party products in the designGR-DEV-01 Use the supported languages and frameworks - ADR recording the reason wherever the service uses a different stackGR-DEV-03 Protect the main branch - Main branch protected from the start, with changes through reviewed pull requestsGR-DEV-05 Automated testing at the right levels - Test results from the pipeline at each levelGR-DEV-07 Follow shared coding standards - Linting and formatting checks in the pipelineGR-DEV-08 Document as you go - README explaining what the service does and how to run, test and deploy it, with links to its ADRsGR-DEV-09 Record significant decisions as ADRs - ADR log in the repository or linked from its READMEGR-SUS-01 Consider sustainability in design decisions - Environmental impact recorded in ADRs for hosting and technology choicesGR-SUS-04 Keep data and pages lean - Data retention settings and page weight measurements
Could guardrails
Sign-off
Detail
Answer
Service
Completed by
Date
Solution design authority
Exceptions or departures (guardrail ids)
Read more on the alpha page .