Arckit Service Assessment

The 14-Point Service Standard

Section 1: Meeting Users' Needs

1. Understand users and their needs - Understand your users and their needs through research
2. Solve a whole problem for users - Work towards creating a service that solves a whole problem
3. Provide a joined up experience across all channels - Create a joined up experience across channels
4. Make the service simple to use - Build a service that's simple so people can succeed first time
5. Make sure everyone can use the service - Ensure accessibility including disabled people

Section 2: Providing a Good Service

6. Have a multidisciplinary team - Put in place a sustainable multidisciplinary team
7. Use agile ways of working - Create the service using agile, iterative ways of working
8. Iterate and improve frequently - Have capacity and flexibility to iterate frequently
9. Create a secure service which protects users' privacy - Ensure security and privacy protection
10. Define what success looks like and publish performance data - Use metrics to inform decisions

Section 3: Using the Right Technology

11. Choose the right tools and technology - Choose tools that enable efficient service delivery
12. Make new source code open - Make source code open and reusable under appropriate licences
13. Use and contribute to open standards, common components and patterns - Build on open standards
14. Operate a reliable service - Minimise downtime and have incident response plans

Process

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

Read the template (with user override support):

• First, check if .arckit/templates/service-assessment-prep-template.md exists in the project root
• If found: Read the user's customized template (user override takes precedence)
• If not found: Read .arckit/templates/service-assessment-prep-template.md (default)

Tip: Users can customize templates with $arckit-customize service-assessment

Step 1: Identify the target project

• Use the ArcKit Project Context (above) to find the project matching the user's input (by name or number)
• If no match, create a new project:
  1. Use Glob to list projects/*/ directories and find the highest NNN-* number (or start at 001 if none exist)
  2. Calculate the next number (zero-padded to 3 digits, e.g., 002)
  3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
  4. Use the Write tool to create projects/{NNN}-{slug}/README.md with the project name, ID, and date — the Write tool will create all parent directories automatically
  5. Also create projects/{NNN}-{slug}/external/README.md with a note to place external reference documents here
  6. Set PROJECT_ID = the 3-digit number, PROJECT_PATH = the new directory path

Step 2: Read existing artifacts from the project context

MANDATORY (warn if missing):

• PRIN (Architecture Principles, in projects/000-global/)
  • Extract: Technology standards, compliance requirements, governance constraints
  • If missing: warn user to run $arckit-principles first
• REQ (Requirements) in projects/{project-dir}/
  • Extract: User stories, acceptance criteria, NFRs, accessibility requirements
  • If missing: warn user to run $arckit-requirements first

RECOMMENDED (read if available, note if missing):

• STKE (Stakeholder Analysis) — user needs, personas, RACI
• RISK (Risk Register) — security risks, mitigation strategies
• PLAN (Project Plan) — phases, timeline, team structure
• SOBC (Business Case) — benefits, success metrics
• DATA (Data Model) — GDPR compliance, data governance
• DIAG (Architecture Diagrams) — C4, deployment
• DEVOPS (DevOps Strategy) — deployment, monitoring
• SECD (Secure by Design) — security assessment
• DPIA (DPIA) — privacy protection evidence
• HLDR / DLDR (Design Reviews) — high-level and detailed design reviews
• TRAC (Traceability Matrix)

OPTIONAL (read if available, skip silently if missing):

• TCOP (TCoP Assessment) — technology compliance
• AIPB (AI Playbook) — if AI components
• ATRS (ATRS record) — if algorithmic tools
• SOW (Statement of Work)
• EVAL (Evaluation Criteria)
• ANAL (Governance Analysis)
• WARD (Wardley Map) — strategic analysis
• RSCH / AWSR / AZUR — technology research

Step 2b: Read external documents and policies

• Read any external documents listed in the project context (external/ files) — extract previous assessment results, assessor feedback, action items, evidence gaps identified
• Read any enterprise standards in projects/000-global/external/ — extract enterprise service standards, previous GDS assessment reports, cross-project assessment benchmarks
• If no external docs exist but they would improve preparation, ask: "Do you have any previous GDS assessment reports or assessor feedback? I can read PDFs directly. Place them in projects/{project-dir}/external/ and re-run, or skip."
• Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

Step 3: Map Evidence to Service Standard Points

For each of the 14 Service Standard points, map evidence from ArcKit artifacts:

Point 1: Understand Users and Their Needs

Evidence Sources:

• ARC-*-STKE-*.md - User groups, needs, pain points, drivers
• ARC-*-REQ-*.md - User stories, personas, user journeys, acceptance criteria
• ARC-*-PLAN-*.md - User research activities planned/completed
• reviews/ARC-*-HLDR-*.md - User needs validation, usability considerations

Phase-Specific Evidence Requirements:

Alpha:

• ✅ User needs documented from research
• ✅ User groups and personas identified
• ✅ Prototype testing results with real users (critical)
• ✅ Evidence of research with diverse user groups
• ⚠️ Analytics data (optional for alpha)

Beta:

• ✅ Ongoing user research throughout beta
• ✅ Testing with diverse users including assistive technology users
• ✅ User research informing iterations
• ✅ Analytics data showing user behavior
• ✅ Evidence of continuous user engagement

Live:

• ✅ User satisfaction metrics being collected and published
• ✅ Continuous user research program
• ✅ User feedback informing service improvements
• ✅ Evidence of user needs evolving over time
• ✅ Analytics showing successful user outcomes

Point 2: Solve a Whole Problem for Users

Evidence Sources:

• ARC-*-REQ-*.md - End-to-end user journeys, functional requirements
• ARC-*-STKE-*.md - User goals, desired outcomes
• wardley-maps/ARC-*-WARD-*.md - Value chain, user needs to components mapping
• diagrams/ARC-*-DIAG-*.md - Service boundaries, external systems
• reviews/ARC-*-HLDR-*.md - Integration strategy, channel coverage

Phase-Specific Evidence Requirements:

Alpha:

• ✅ User journey maps showing end-to-end experience
• ✅ Problem definition beyond government touchpoints
• ✅ Understanding of user context before/after service interaction
• ✅ Identification of pain points in current experience

Beta:

• ✅ Service covers complete user journey
• ✅ Integration with other services/channels
• ✅ Assisted digital support for those who need it
• ✅ Clear service boundaries with rationale

Live:

• ✅ User completion rates demonstrating whole problem solved
• ✅ Monitoring of user drop-off points
• ✅ Evidence of service iterations based on completion data
• ✅ Cross-channel experience working seamlessly

Point 3: Provide a Joined Up Experience Across All Channels

Evidence Sources:

• ARC-*-REQ-*.md - Multi-channel requirements, integration points
• reviews/ARC-*-HLDR-*.md - Channel strategy, integration architecture
• diagrams/ - System integration diagrams
• ARC-*-DATA-*.md - Data consistency across channels

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Channels identified and mapped
• ✅ Integration strategy defined
• ✅ Consistent branding and messaging planned
• ✅ Understanding of user channel preferences

Beta:

• ✅ All channels implemented and working
• ✅ Data synchronized across channels
• ✅ Consistent user experience across channels
• ✅ Channel switching works seamlessly
• ✅ Testing completed across all channels

Live:

• ✅ Channel usage monitored and optimized
• ✅ User satisfaction high across all channels
• ✅ Continuous improvement of channel experience
• ✅ Evidence of users successfully switching channels

Point 4: Make the Service Simple to Use

Evidence Sources:

• ARC-*-REQ-*.md - Usability requirements, simplicity NFRs
• reviews/ARC-*-HLDR-*.md - UX design review, simplicity assessment
• ARC-*-PLAN-*.md - Usability testing activities

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Prototype usability testing conducted
• ✅ Design iterations based on user feedback
• ✅ Simple language and clear instructions
• ✅ Task completion rates in testing

Beta:

• ✅ Usability testing with diverse users
• ✅ Task completion >85% on first attempt
• ✅ Content design reviewed by GDS content designers
• ✅ Plain language, no jargon
• ✅ Forms and interactions simplified

Live:

• ✅ Task completion rates >90%
• ✅ User satisfaction scores high
• ✅ Low support ticket volume for "how to use"
• ✅ Continuous simplification based on user feedback

Point 5: Make Sure Everyone Can Use the Service

Evidence Sources:

• ARC-*-REQ-*.md - WCAG 2.1 AA requirements, accessibility NFRs
• ARC-*-SECD-*.md - Accessibility considerations
• reviews/ARC-*-HLDR-*.md - Accessibility design review
• reviews/ARC-*-DLDR-*.md - Assistive technology compatibility

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Accessibility considerations documented
• ✅ WCAG 2.1 AA compliance planned
• ✅ Testing with assistive technology planned
• ⚠️ Full accessibility audit not required at alpha

Beta:

• ✅ WCAG 2.1 AA audit completed and passed (critical)
• ✅ Testing with screen readers, voice control, magnification
• ✅ Testing with disabled users
• ✅ Accessibility statement published
• ✅ Alternative formats available

Live:

• ✅ Zero accessibility complaints/barriers
• ✅ Regular accessibility audits
• ✅ Continuous accessibility testing in development
• ✅ User research includes disabled users
• ✅ Accessibility champion in team

Point 6: Have a Multidisciplinary Team

Evidence Sources:

• ARC-*-STKE-*.md - RACI matrix, team roles
• ARC-*-PLAN-*.md - Team structure, roles, skills
• ARC-*-SOBC-*.md - Team costs, sustainability plan

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Team composition documented
• ✅ Key roles filled: Product Manager, User Researcher, Tech Lead, Designer, Delivery Manager
• ✅ Skills audit showing capability coverage
• ✅ Team co-located or good remote working practices

Beta:

• ✅ Team stable and sustainable
• ✅ All required skills represented
• ✅ Specialists available (accessibility, security, content, etc.)
• ✅ Team has autonomy to make decisions
• ✅ Career development for team members

Live:

• ✅ Team retention high
• ✅ Knowledge sharing and documentation
• ✅ Continuous learning culture
• ✅ Team satisfaction high
• ✅ Succession planning in place

Point 7: Use Agile Ways of Working

Evidence Sources:

• ARC-*-PLAN-*.md - GDS phases, sprint structure, agile ceremonies
• ARC-*-RISK-*.md - Iterative risk management
• reviews/ARC-*-HLDR-*.md, reviews/ARC-*-DLDR-*.md - Design iterations

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Agile ceremonies established (standups, retros, planning)
• ✅ Sprint cadence defined (typically 1-2 weeks)
• ✅ User stories and backlog maintained
• ✅ Iterative approach to prototyping

Beta:

• ✅ Mature agile practices
• ✅ Regular releases to production
• ✅ Retrospectives leading to improvements
• ✅ Team velocity tracked
• ✅ Continuous improvement culture

Live:

• ✅ Continuous deployment pipeline
• ✅ Regular feature releases based on user feedback
• ✅ DevOps maturity high
• ✅ Team adapting practices based on learning

Point 8: Iterate and Improve Frequently

Evidence Sources:

• reviews/ARC-*-HLDR-*.md, reviews/ARC-*-DLDR-*.md - Design iterations, review dates
• ARC-*-ANAL-*.md - Governance improvements over time
• ARC-*-PLAN-*.md - Iteration cycles, review gates
• ARC-*-REQ-*.md - Requirements evolution

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Prototype iterations documented
• ✅ Changes based on user feedback
• ✅ Multiple design options explored
• ✅ Learning log showing insights and pivots

Beta:

• ✅ Service iterations in production
• ✅ A/B testing or controlled rollouts
• ✅ Feature flags for experimentation
• ✅ Monitoring and feedback loops
• ✅ Regular releases (at least monthly)

Live:

• ✅ Continuous improvement demonstrated
• ✅ User feedback directly informing roadmap
• ✅ Metrics showing service improvements
• ✅ Innovation and experimentation ongoing

Point 9: Create a Secure Service Which Protects Users' Privacy

Evidence Sources:

• ARC-*-SECD-*.md - NCSC security principles, threat model
• ARC-*-DATA-*.md - GDPR compliance, data protection, PII handling
• ARC-*-ATRS-*.md - AI transparency and risk (if AI service)
• ARC-*-RISK-*.md - Security risks and mitigations
• ARC-*-REQ-*.md - Security and privacy NFRs
• ARC-*-TCOP-*.md - TCoP security points

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Threat model created
• ✅ Security risks identified and assessed
• ✅ GDPR compliance approach defined
• ✅ Data protection impact assessment (if needed)
• ✅ Privacy considerations documented

Beta:

• ✅ Security testing completed (pen test, vulnerability scanning)
• ✅ GDPR compliance implemented
• ✅ Privacy policy published
• ✅ Data retention policies defined
• ✅ Security monitoring in place
• ✅ Incident response plan documented

Live:

• ✅ Zero security breaches
• ✅ Regular security testing and audits
• ✅ Security monitoring and alerting
• ✅ Privacy complaints = 0
• ✅ Cyber Essentials Plus certification (or higher)

Point 10: Define What Success Looks Like and Publish Performance Data

Evidence Sources:

• ARC-*-REQ-*.md - KPIs, success metrics, NFRs
• ARC-*-SOBC-*.md - Benefits realization, success criteria, ROI
• ARC-*-PLAN-*.md - Milestones, success criteria per phase
• ARC-*-TCOP-*.md - Performance metrics approach

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Success metrics defined (user satisfaction, completion rates, cost per transaction)
• ✅ Baseline measurements identified
• ✅ Data collection approach planned
• ✅ KPIs aligned to user needs

Beta:

• ✅ Performance data being collected
• ✅ Dashboard showing key metrics
• ✅ Performance data published (at least internally)
• ✅ Metrics reviewed regularly by team
• ✅ Targets set for live service

Live:

• ✅ Performance data published on GOV.UK (critical)
• ✅ 4 mandatory KPIs published: cost per transaction, user satisfaction, completion rate, digital take-up
• ✅ Data updated regularly (at least quarterly)
• ✅ Performance trends showing improvement
• ✅ Metrics informing service improvements

Point 11: Choose the Right Tools and Technology

Evidence Sources:

• research/ - Technology research, proof of concepts
• wardley-maps/ - Build vs buy analysis, technology evolution
• ARC-*-TCOP-*.md - Technology choices justified (TCoP Point 11)
• reviews/ARC-*-HLDR-*.md - Technology stack, architecture decisions
• ARC-*-SOW-*.md - Vendor selection, procurement justification
• ARC-*-EVAL-*.md - Technology/vendor scoring

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Technology options explored
• ✅ Build vs buy analysis completed
• ✅ Technology spikes/proof of concepts conducted
• ✅ Technology choices justified against requirements
• ✅ Cost analysis for technology options

Beta:

• ✅ Technology choices working in production
• ✅ Technology scalable and fit for purpose
• ✅ Total cost of ownership understood
• ✅ Technology risks managed
• ✅ Team has skills for chosen technology

Live:

• ✅ Technology performing well at scale
• ✅ Technology costs optimized
• ✅ Technology debt managed
• ✅ Regular technology reviews
• ✅ Technology enabling rapid iteration

Point 12: Make New Source Code Open

Evidence Sources:

• reviews/ARC-*-HLDR-*.md - Open source approach, repository links
• ARC-*-TCOP-*.md - TCoP Point 12 (Open source code)
• ARC-*-REQ-*.md - Open source licensing requirements

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Open source approach decided
• ✅ Security and IP considerations addressed
• ✅ Code repository approach defined
• ⚠️ Code may not be public yet at alpha

Beta:

• ✅ Source code repository exists (GitHub/GitLab)
• ✅ Code published under appropriate license (MIT, Apache 2.0, etc.)
• ✅ Secrets and credentials not in source code
• ✅ README and documentation for developers
• ✅ Contribution guidelines if accepting contributions

Live:

• ✅ All new code public and open source
• ✅ Active repository with regular commits
• ✅ External contributions welcomed
• ✅ Code quality maintained
• ✅ Open source community engagement

Point 13: Use and Contribute to Open Standards, Common Components and Patterns

Evidence Sources:

• ARC-*-TCOP-*.md - TCoP Point 13 (Open standards)
• reviews/ARC-*-HLDR-*.md - GOV.UK Design System usage, API standards, common components
• ARC-*-REQ-*.md - Standards compliance requirements
• ARC-*-DATA-*.md - Data standards

Phase-Specific Evidence Requirements:

Alpha:

• ✅ GOV.UK Design System usage planned
• ✅ Common components identified (GOV.UK Notify, Pay, etc.)
• ✅ API standards considered (RESTful, OpenAPI)
• ✅ Data standards identified (if applicable)

Beta:

• ✅ GOV.UK Design System implemented
• ✅ Common components integrated (Notify, Pay, Verify, etc.)
• ✅ APIs follow government API standards
• ✅ Open standards used for data formats
• ✅ Contributing patterns back to community (if novel)

Live:

• ✅ Consistent use of GOV.UK patterns
• ✅ Common components working in production
• ✅ Contributing to open standards development
• ✅ Sharing patterns with other teams
• ✅ Standards compliance maintained

Point 14: Operate a Reliable Service

Evidence Sources:

• ARC-*-REQ-*.md - Availability/reliability NFRs, SLAs
• reviews/ARC-*-HLDR-*.md - Resilience architecture, failover, disaster recovery
• reviews/ARC-*-DLDR-*.md - Infrastructure resilience, monitoring
• ARC-*-RISK-*.md - Operational risks, incident response

Phase-Specific Evidence Requirements:

Alpha:

• ✅ Reliability requirements defined
• ✅ Uptime targets set
• ✅ High-level resilience approach planned
• ⚠️ Full operational procedures not needed at alpha

Beta:

• ✅ Service uptime meeting targets (typically 99.9%)
• ✅ Monitoring and alerting in place
• ✅ Incident response procedures documented
• ✅ On-call rota established
• ✅ Disaster recovery plan tested
• ✅ Load testing completed

Live:

• ✅ SLA consistently met (99.9%+ uptime)
• ✅ Incident response tested and working
• ✅ Post-incident reviews conducted
• ✅ Proactive monitoring preventing issues
• ✅ Capacity planning and scaling working
• ✅ Chaos engineering or resilience testing

Step 4: Phase-Appropriate Gap Analysis

Apply phase-appropriate criteria when assessing evidence:

Alpha Assessment - Focus on demonstrating viability:

• Lower bar for operational evidence (monitoring, performance data)
• Higher bar for user research and prototyping
• Critical: User testing, team composition, technology viability
• Optional: Full accessibility audit, published performance data

Beta Assessment - Focus on demonstrating production readiness:

• Higher bar for everything
• Critical: Working service, security testing, accessibility compliance, performance monitoring
• All 14 points must be addressed substantively
• Evidence of service working end-to-end

Live Assessment - Focus on demonstrating continuous improvement:

• Highest bar, operational excellence expected
• Critical: Published performance data, user satisfaction, continuous improvement
• Evidence of service evolution based on user feedback
• Operational maturity demonstrated

Step 5: Generate RAG Ratings

For each Service Standard point, assign a RAG rating based on evidence found:

🟢 Green (Ready):

• All critical evidence found for this phase
• Evidence is comprehensive and high quality
• No significant gaps
• Team ready to discuss this point confidently

🟡 Amber (Partial):

• Some evidence found but gaps remain
• Evidence exists but may lack detail or breadth
• Minor gaps that can be addressed quickly (1-2 weeks)
• Would likely receive "Amber" rating from assessment panel

🔴 Red (Not Ready):

• Critical evidence missing
• Significant gaps that require substantial work (3+ weeks)
• Would likely receive "Red" rating and fail this point
• Must be addressed before booking assessment

Overall Readiness Rating:

• 🟢 Green (Ready): 12+ points Green, max 2 Amber, 0 Red
• 🟡 Amber (Nearly Ready): 10+ points Green/Amber, max 2 Red
• 🔴 Red (Not Ready): More than 2 Red points or fewer than 10 Green/Amber

Step 6: Generate Recommendations

For each gap identified, generate specific, actionable recommendations:

Priority Levels:

• Critical: Must complete before assessment (affects Red rating)
• High: Should complete before assessment (affects Amber rating)
• Medium: Nice to have, strengthens case (improves confidence)

Recommendation Format:

Priority: [Critical/High/Medium]
Point: [Service Standard point number]
Action: [Specific action to take]
Timeline: [Estimated time to complete]
Who: [Suggested role/person]
Evidence to create: [What artifact/documentation will this produce]

Step 7: Generate Assessment Day Guidance

Provide practical guidance for the assessment day:

Documentation to Prepare (share with panel 1 week before):

• List specific ArcKit artifacts to share
• Suggest additional materials needed (prototypes, demos, research findings)
• Recommend format for sharing (links, documents, slide deck limits)

Who Should Attend:

• Core team members required (Product Manager, User Researcher, Tech Lead, Delivery Manager)
• Phase-specific additions (e.g., Accessibility specialist for beta)
• Suggested role assignments during assessment

Show and Tell Structure (4-hour assessment timeline):

• 0:00-0:15: Introductions and context
• 0:15-1:00: User research and needs
• 1:00-1:45: Service demo/prototype walkthrough
• 1:45-2:30: Technical architecture and security
• 2:30-3:00: Team and ways of working
• 3:00-3:45: Q&A on Service Standard points
• 3:45-4:00: Panel deliberation

Tips for Assessment Day:

• Show real work, not polished presentations
• Have doers present their work
• Be honest about unknowns
• Explain problem-solving approach
• Demonstrate user-centered thinking
• Show iteration and learning

Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the SVCASS per-type checks pass. Fix any failures before proceeding.

Step 8: Write Assessment Preparation Report

Generate a comprehensive markdown report saved to:

projects/{project-dir}/ARC-{PROJECT_ID}-SVCASS-v1.0.md

Example: projects/001-nhs-appointment/ARC-001-SVCASS-v1.0.md

Report Structure

# GDS Service Assessment Preparation Report

**Project**: [Project Name from ArcKit artifacts]
**Assessment Phase**: [Alpha/Beta/Live]
**Assessment Date**: [If provided, else "Not yet scheduled"]
**Report Generated**: [Current date]
**ArcKit Version**: {ARCKIT_VERSION}

---

## Executive Summary

**Overall Readiness**: 🟢 Green / 🟡 Amber / 🔴 Red

**Readiness Score**: X/14 points ready

**Breakdown**:
- 🟢 Green: X points
- 🟡 Amber: X points
- 🔴 Red: X points

**Summary**:
[2-3 paragraph summary of overall readiness, highlighting strengths and critical gaps]

**Critical Gaps** (Must address before assessment):
- [Gap 1 with Service Standard point number]
- [Gap 2 with Service Standard point number]
- [Gap 3 with Service Standard point number]

**Key Strengths**:
- [Strength 1]
- [Strength 2]
- [Strength 3]

**Recommended Timeline**:
- [X weeks/days until ready based on gap analysis]
- [If assessment date provided: "Assessment in X days - [Ready/Need to postpone]"]

---

## Service Standard Assessment (14 Points)

[For each of the 14 points, include the following detailed section]

### 1. Understand Users and Their Needs

**Status**: 🟢 Ready / 🟡 Partial / 🔴 Not Ready

**What This Point Means**:
[Brief 2-3 sentence explanation of what this Service Standard point requires]

**Why It Matters**:
[1-2 sentences on importance]

**Evidence Required for [Alpha/Beta/Live]**:
- [Evidence requirement 1 for this phase]
- [Evidence requirement 2 for this phase]
- [Evidence requirement 3 for this phase]

**Evidence Found in ArcKit Artifacts**:

✅ **ARC-*-STKE-*.md** (lines XX-YY)
   - [Specific evidence found]
   - [What this demonstrates]

✅ **ARC-*-REQ-*.md** (Section X: User Stories)
   - [Specific evidence found]
   - [What this demonstrates]

❌ **Missing**: [Specific gap 1]
❌ **Missing**: [Specific gap 2]
⚠️ **Weak**: [Evidence exists but lacks quality/detail]

**Gap Analysis**:
[2-3 sentences assessing completeness: what's strong, what's weak, what's missing]

**Readiness Rating**: 🟢 Green / 🟡 Amber / 🔴 Red

**Strengths**:
- [Strength 1]
- [Strength 2]

**Weaknesses**:
- [Weakness 1]
- [Weakness 2]

**Recommendations**:

1. **Critical**: [Action with specific details]
   - Timeline: [X days/weeks]
   - Owner: [Suggested role]
   - Evidence to create: [What this will produce]

2. **High**: [Action with specific details]
   - Timeline: [X days/weeks]
   - Owner: [Suggested role]
   - Evidence to create: [What this will produce]

3. **Medium**: [Action with specific details]
   - Timeline: [X days/weeks]
   - Owner: [Suggested role]
   - Evidence to create: [What this will produce]

**Assessment Day Guidance**:
- **Prepare**: [What to prepare for presenting this point]
- **Show**: [What to demonstrate/show]
- **Bring**: [Who should be ready to present]
- **Materials**: [Specific artifacts/demos to have ready]
- **Likely Questions**:
  - [Expected question 1]
  - [Expected question 2]

---

[Repeat above structure for all 14 Service Standard points]

---

## Evidence Inventory

**Complete Traceability**: Service Standard Point → ArcKit Artifacts

| Service Standard Point | ArcKit Artifacts | Status | Critical Gaps |
|------------------------|------------------|--------|---------------|
| 1. Understand users | ARC-*-STKE-*.md, ARC-*-REQ-*.md | 🟡 Partial | Prototype testing with users |
| 2. Solve whole problem | ARC-*-REQ-*.md, wardley-maps/ | 🟢 Complete | None |
| 3. Joined up experience | reviews/ARC-*-HLDR-*.md, diagrams/ | 🟡 Partial | Channel integration testing |
| 4. Simple to use | ARC-*-REQ-*.md, reviews/ARC-*-HLDR-*.md | 🟢 Complete | None |
| 5. Everyone can use | ARC-*-REQ-*.md, ARC-*-SECD-*.md | 🔴 Not Ready | WCAG 2.1 AA testing |
| 6. Multidisciplinary team | ARC-*-STKE-*.md, ARC-*-PLAN-*.md | 🟢 Complete | None |
| 7. Agile ways of working | ARC-*-PLAN-*.md | 🟢 Complete | None |
| 8. Iterate frequently | reviews/ARC-*-HLDR-*.md, reviews/ARC-*-DLDR-*.md | 🟡 Partial | Iteration log |
| 9. Secure and private | ARC-*-SECD-*.md, ARC-*-DATA-*.md | 🟢 Complete | None |
| 10. Success metrics | ARC-*-REQ-*.md, ARC-*-SOBC-*.md | 🟡 Partial | Performance dashboard |
| 11. Right tools | research/, wardley-maps/, ARC-*-TCOP-*.md | 🟢 Complete | None |
| 12. Open source | reviews/ARC-*-HLDR-*.md | 🔴 Not Ready | Public code repository |
| 13. Open standards | ARC-*-TCOP-*.md, reviews/ARC-*-HLDR-*.md | 🟢 Complete | None |
| 14. Reliable service | ARC-*-REQ-*.md, reviews/ARC-*-HLDR-*.md | 🟡 Partial | Load testing results |

**Summary**:
- ✅ Strong evidence: Points X, Y, Z
- ⚠️ Adequate but needs strengthening: Points A, B, C
- ❌ Critical gaps: Points D, E

---

## Assessment Preparation Checklist

### Critical Actions (Complete within 2 weeks)

Priority: Complete these before booking assessment - they address Red ratings

- [ ] **Action 1**: [Specific action]
  - Point: [Service Standard point number]
  - Timeline: [X days]
  - Owner: [Role]
  - Outcome: [What evidence this creates]

- [ ] **Action 2**: [Specific action]
  - Point: [Service Standard point number]
  - Timeline: [X days]
  - Owner: [Role]
  - Outcome: [What evidence this creates]

### High Priority Actions (Complete within 4 weeks)

Priority: Should complete to strengthen Amber points to Green

- [ ] **Action 3**: [Specific action]
  - Point: [Service Standard point number]
  - Timeline: [X days]
  - Owner: [Role]
  - Outcome: [What evidence this creates]

- [ ] **Action 4**: [Specific action]
  - Point: [Service Standard point number]
  - Timeline: [X days]
  - Owner: [Role]
  - Outcome: [What evidence this creates]

### Medium Priority Actions (Nice to Have)

Priority: Strengthens overall case but not blocking

- [ ] **Action 5**: [Specific action]
  - Point: [Service Standard point number]
  - Timeline: [X days]
  - Owner: [Role]
  - Outcome: [What evidence this creates]

---

## Assessment Day Preparation

### Timeline and Booking

**Current Readiness**:
[Assessment of whether ready to book now, or need to complete critical actions first]

**Recommended Booking Timeline**:
- Complete critical actions: [X weeks]
- Complete high priority actions: [X weeks]
- Buffer for preparation: 1 week
- **Ready to book after**: [Date if assessment date provided]

**How to Book**:
1. Contact GDS Central Digital & Data Office assessment team
2. Book 5 weeks in advance minimum
3. Assessments typically on Tuesday, Wednesday, or Thursday
4. Duration: 4 hours
5. Provide: Service name, department, phase, preferred dates

### Documentation to Share with Panel

**Send 1 week before assessment**:

Required documentation:
- [ ] Project overview (1-2 pages) - Use `ARC-*-PLAN-*.md` summary
- [ ] User research repository or summary - From `ARC-*-STKE-*.md` and user research findings
- [ ] Service architecture diagrams - From `diagrams/` directory
- [ ] Prototype/demo environment URL (if applicable)

Recommended documentation:
- [ ] Key ArcKit artifacts:
  - `ARC-*-STKE-*.md` - Stakeholders and user needs
  - `ARC-*-REQ-*.md` - Requirements and user stories
  - `reviews/ARC-*-HLDR-*.md` - Architecture decisions
  - `ARC-*-SECD-*.md` - Security approach
  - [List other relevant phase-specific artifacts]

Optional supplementary:
- [ ] Design history showing iterations
- [ ] Research findings (videos, playback slides)
- [ ] Technical documentation or developer docs
- [ ] Performance metrics dashboard (if available)

### Who Should Attend

**Core Team** (required):
- ✅ **Product Manager / Service Owner** - Overall service vision and decisions
- ✅ **Lead User Researcher** - User needs, research findings, testing
- ✅ **Technical Architect / Lead Developer** - Technology choices, architecture
- ✅ **Delivery Manager** - Agile practices, team dynamics

**Phase-Specific Additions**:

[For Alpha]:
- ✅ **Lead Designer** - Prototype design, user interface
- ✅ **Business Analyst** - Requirements, user stories

[For Beta]:
- ✅ **Accessibility Specialist** - WCAG compliance, assistive technology testing
- ✅ **Security Lead** - Security testing, threat model
- ✅ **Content Designer** - Content approach, plain English

[For Live]:
- ✅ **Operations/DevOps Lead** - Service reliability, monitoring
- ✅ **Performance Analyst** - Metrics, analytics, performance data

**Optional Attendees**:
- Senior Responsible Owner (for context, may not be there whole time)
- Business owner or policy lead
- Clinical safety officer (health services)
- Data protection officer (high PII services)

### Show and Tell Structure

**4-Hour Assessment Timeline**:

**0:00-0:15 - Introductions and Context**
- Team introductions (name, role, experience)
- Service overview (2 minutes)
- Project context and phase progress

**0:15-1:00 - User Research and Needs (Points 1, 2, 3, 4)**
- User Researcher presents:
  - Research findings and methodology
  - User needs and problem definition
  - Prototype/design testing results
  - How user needs inform service design
- Be ready to discuss: diversity of research participants, accessibility

**1:00-1:45 - Service Demonstration (Points 2, 3, 4, 5)**
- Show the service or prototype:
  - End-to-end user journey demonstration
  - Key features and functionality
  - Accessibility features
  - Multi-channel experience
- Use real examples and test data
- Show iterations based on feedback

**1:45-2:30 - Technical Architecture and Security (Points 9, 11, 12, 13, 14)**
- Tech Lead presents:
  - Architecture decisions and rationale
  - Technology choices (build vs buy)
  - Security and privacy approach
  - Open source strategy
  - Reliability and monitoring
- Use diagrams from ArcKit artifacts
- Explain trade-offs and decisions

**2:30-3:00 - Team and Ways of Working (Points 6, 7, 8, 10)**
- Delivery Manager presents:
  - Team composition and skills
  - Agile practices and ceremonies
  - Iteration approach and cadence
  - Success metrics and performance data
- Show real examples: sprint boards, retro actions

**3:00-3:45 - Open Q&A**
- Panel asks questions on any Service Standard points
- Team responds with evidence and examples
- Opportunity to address panel concerns
- Provide additional context as needed

**3:45-4:00 - Panel Deliberation**
- Team steps out
- Panel discusses and decides on ratings
- Panel may call team back for clarifications

### Tips for Success

**Do**:
- ✅ Show real work, not polished presentations (max 10 slides if any)
- ✅ Have people who did the work present it
- ✅ Be honest about what you don't know yet
- ✅ Explain your problem-solving approach
- ✅ Demonstrate iteration based on learning
- ✅ Show enthusiasm for user needs
- ✅ Provide evidence for claims
- ✅ Reference ArcKit artifacts by name

**Don't**:
- ❌ Over-prepare presentations (panel wants to see artifacts)
- ❌ Hide problems or pretend everything is perfect
- ❌ Use jargon or assume panel knows your context
- ❌ Let senior leaders dominate (panel wants to hear from doers)
- ❌ Argue with panel feedback
- ❌ Rush through - panel will interrupt with questions

**Materials to Have Ready**:
- Prototype or working service with test data loaded
- Laptops for team members to show their work
- Backup plan if demo breaks (screenshots, videos)
- Links to ArcKit artifacts and other documentation
- Research videos or clips (if appropriate)
- Architecture diagrams printed or on screen

---

## After the Assessment

### If You Pass (Green)

**Immediate Actions**:
- [ ] Celebrate with the team
- [ ] Share assessment report with stakeholders
- [ ] Plan for next phase
- [ ] Book next assessment (if moving to beta/live)

**Continuous Improvement**:
- [ ] Act on panel feedback and recommendations
- [ ] Continue user research and iteration
- [ ] Update ArcKit artifacts as service evolves
- [ ] Maintain Service Standard compliance

### If You Get Amber

**Understanding Amber**:
- Service can proceed to next phase
- Must fix amber issues within 3 months
- Progress tracked in "tracking amber evidence" document
- GDS assessment team will monitor progress

**Immediate Actions**:
- [ ] Create "tracking amber evidence" document
- [ ] Assign owners to each amber point
- [ ] Set deadlines for addressing amber issues (within 3 months)
- [ ] Schedule regular check-ins with GDS assessment team

**Tracking Amber Evidence**:
Create a public document (visible to assessment team) showing:
- Each amber point and the specific concern raised
- Actions taken to address the concern
- Evidence created (with links/dates)
- Status (not started, in progress, complete)
- Next assessment date

### If You Fail (Red)

**Understanding Red**:
- Service cannot proceed to next phase
- Must address red issues before reassessment
- Team remains in current phase
- Requires another full assessment

**Immediate Actions**:
- [ ] Review assessment report carefully with team
- [ ] Identify root causes of red ratings
- [ ] Create action plan to address each red point
- [ ] Re-run `$arckit-service-assessment` command weekly to track progress
- [ ] Book reassessment once red issues resolved (typically 3-6 months)

---

## Next Steps

### This Week

**Immediate actions** (within 7 days):
1. [Action 1 from critical list]
2. [Action 2 from critical list]
3. [Action 3 from critical list]

**Quick wins** (can complete in 1-2 days):
- [Quick win 1]
- [Quick win 2]

### Next 2 Weeks

**Priority actions** (complete before booking):
1. [Action from critical list]
2. [Action from critical list]
3. [Action from high priority list]

### Next 4 Weeks

**Strengthening actions** (improve Amber to Green):
1. [Action from high priority list]
2. [Action from high priority list]
3. [Action from medium priority list]

### Continuous Improvement

**Weekly**:
- [ ] Re-run `$arckit-service-assessment PHASE=[phase]` to track progress
- [ ] Update this report as evidence is gathered
- [ ] Review checklist and mark completed items
- [ ] Sprint planning includes Service Standard prep tasks

**Fortnightly**:
- [ ] Team review of assessment readiness
- [ ] Practice show and tell with colleagues
- [ ] Gather feedback on presentation approach

**Before Booking**:
- [ ] All critical actions complete
- [ ] At least 10/14 points rated Green or Amber
- [ ] Team confident and prepared
- [ ] Documentation ready to share
- [ ] Demo environment tested and working

---

## Resources

### GDS Service Standard Resources

**Official Guidance**:
- [Service Standard](https://www.gov.uk/service-manual/service-standard) - All 14 points explained
- [What happens at a service assessment](https://www.gov.uk/service-manual/service-assessments/how-service-assessments-work) - Assessment process
- [Book a service assessment](https://www.gov.uk/service-manual/service-assessments/book-a-service-assessment) - Booking information
- [Service Standard Reports](https://www.gov.uk/service-standard-reports) - Browse 450+ published assessment reports

**Phase-Specific Guidance**:
- [Alpha phase](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works) - What to do in alpha
- [Beta phase](https://www.gov.uk/service-manual/agile-delivery/how-the-beta-phase-works) - What to do in beta
- [Live phase](https://www.gov.uk/service-manual/agile-delivery/how-the-live-phase-works) - What to do when live

**Deep Dives by Service Standard Point**:
[Links to all 14 individual point pages on GOV.UK]

### Related ArcKit Commands

**Complementary Analysis**:
- `$arckit-analyze` - Comprehensive governance quality analysis
- `$arckit-traceability` - Requirements traceability matrix showing evidence chains

**Overlap with TCoP**:
- `$arckit-tcop` - Technology Code of Practice assessment (points 11, 13 overlap)

**Generate Missing Evidence**:
- `$arckit-requirements` - If user stories or NFRs weak
- `$arckit-hld-review` - If architecture decisions not documented
- `$arckit-secure` - If security assessment incomplete
- `$arckit-diagram` - If architecture diagrams missing
- `$arckit-wardley` - If technology strategy not clear

### Community Resources

**Blog Posts and Lessons Learned**:
- [Preparing for a GDS assessment](https://www.iterate.org.uk/10-things-to-remember-when-preparing-for-a-service-standard-assessment/)
- [What I learned as a user researcher](https://dwpdigital.blog.gov.uk/2020/08/17/what-ive-learned-about-gds-assessments-as-a-user-researcher/)
- [Service assessments: not Dragon's Den](https://medium.com/deloitte-uk-design-blog/service-assessments-no-longer-dragons-den-909b56c43593)

**Supplier Support** (G-Cloud):
- Search Digital Marketplace for "GDS assessment preparation" support services
- Many suppliers offer assessment prep workshops and mock assessments

---

## Appendix: Assessment Outcome Examples

### Example: Strong Alpha Pass (Green)

**Typical characteristics**:
- 12-14 points rated Green
- Excellent user research with diverse participants
- Working prototype tested extensively
- Clear technology choices with justification
- Strong multidisciplinary team
- Agile practices established and working well

**Panel feedback themes**:
- "Strong user research foundation"
- "Clear evidence of iteration based on feedback"
- "Team has right skills and working well together"
- "Technology choices well justified"

### Example: Alpha with Amber

**Typical characteristics**:
- 8-11 points Green, 3-5 Amber, 0-1 Red
- Good user research but gaps in diversity
- Prototype exists but limited testing
- Technology chosen but not fully tested
- Team in place but some skills gaps

**Common amber points**:
- Point 1: Need more diverse user research participants
- Point 5: Accessibility considerations identified but not tested
- Point 8: Iterations happening but not clearly documented
- Point 12: Open source approach decided but not yet implemented

**Panel feedback themes**:
- "Good start, needs more evidence of [X]"
- "Continue to build on [strength] and address [gap]"
- "By beta, we expect to see [specific improvement]"

### Example: Beta with Critical Issues (Red)

**Typical characteristics**:
- Major gaps in 2-3 points
- Often accessibility (Point 5) or performance data (Point 10)
- Service working but quality issues
- Security or privacy concerns

**Common red points**:
- Point 5: WCAG 2.1 AA testing not completed (critical for beta)
- Point 9: Security testing not done or serious vulnerabilities found
- Point 10: No performance data being collected
- Point 14: Service unreliable, frequent downtime

**Panel feedback themes**:
- "Cannot proceed to public beta until [critical issue] resolved"
- "This is essential for a beta service"
- "Team needs to prioritise [issue] immediately"

---

**Report Generated by**: ArcKit v{ARCKIT_VERSION} `$arckit-service-assessment` command

**Next Actions**:
1. Review this report with your team
2. Prioritize critical actions in your sprint planning
3. Re-run `$arckit-service-assessment PHASE=[phase]` weekly to track progress
4. Use checklist to track completion of preparation tasks

**Questions or Feedback**:
- Report issues: https://github.com/tractorjuice/arc-kit/issues
- Contribute improvements: PRs welcome
- Share your assessment experience: Help improve this command for others

---

*Good luck with your assessment! Remember: assessments are conversations about your service, not exams. Show your work, explain your thinking, and be open to feedback. The panel wants you to succeed.* 🚀

Operating Constraints

Tone and Approach:

• Supportive and constructive - you want the team to succeed
• Specific and actionable - avoid vague recommendations
• Realistic - don't overwhelm with too many actions
• Evidence-based - always reference specific artifacts and line numbers
• Phase-appropriate - adjust expectations based on alpha/beta/live

Quality Standards:

• Every gap must have a specific recommendation
• Every recommendation must have an owner, timeline, and outcome
• RAG ratings must be justified with evidence (or lack thereof)
• Assessment day guidance must be practical and specific
• Report must be comprehensive but scannable

Important Notes:

• This is a preparation tool, not the actual assessment
• Panel will make final decisions based on their expert judgment
• This command helps teams gather evidence and present it effectively
• Re-run weekly to track progress as evidence is gathered
• Assessment outcomes can't be guaranteed, but preparation increases success rate significantly

Example Usage

$arckit-service-assessment PHASE=alpha DATE=2025-12-15

Generates: projects/001-nhs-appointment/ARC-001-SVCASS-v1.0.md

$arckit-service-assessment PHASE=beta

Generates: projects/002-payment-gateway/ARC-002-SVCASS-v1.0.md

Success Indicators

This command succeeds when:

• Team feels confident and prepared for assessment
• All 14 Service Standard points have clear evidence or action plans
• Critical gaps identified and addressed before booking
• Team can present their work clearly on assessment day
• Assessment preparation time reduced from weeks to days
• Higher pass rates for teams using this tool

Transform ArcKit documentation into Service Standard compliance evidence. Demonstrate governance excellence. ✨

Important Notes

• Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji