Whose need?
Name the user group, service owner, operational owner, current process and baseline.
Delivery method · evidence confirmed per project
Government and public-service teams
Digital delivery that can be scoped, tested and handed over.
We frame technology work around a defined service need, accountable owners and reviewable evidence. A proof of concept is used to answer a decision—not to create the appearance of production readiness.
222 Technology does not claim a government deployment, government supplier status, Smart LAB listing or approval, security accreditation, independent certification or a pre-approved deployment model on this page.
Company-level delivery scope
Start with the service outcome, then select the technology.
The engagement may combine several capabilities. Each is linked to the fuller company capability statement, including its evidence limits.
01
Applied AI, knowledge & document systems
Assist defined retrieval, drafting, extraction, classification or review tasks with source, evaluation and human-oversight controls.
02
Custom digital services & platforms
Build public or staff journeys around service rules, permissions, accessibility and operating ownership.
03
Workflow, data & decision support
Make hand-offs, evidence, exceptions and operational measures visible without displacing accountable policy decisions.
04
Systems integration & production engineering
Connect approved systems and prepare releases, observability, resilience, support and technical handover.
Questions that shape a credible public-service brief
What boundary?
Separate assistance and workflow from approvals, eligibility, identity, payments and official-record changes.
What evidence?
Agree representative cases, measures, reviewers, exceptions and a threshold for stopping or changing direction.
Who operates it?
Assign content, data, security, service-desk, supplier, change and risk-acceptance responsibilities.
Proof-of-concept method
A bounded test with a real decision at the end.
Duration and depth depend on data, integration, security and procurement constraints. A website cannot promise a standard timetable for every department or environment.
- 01Frame
Define the decision
Confirm the service need, owners, baseline, scope, data classification, assumptions, test evidence and stop conditions.
- Approved brief
- Risk and assumption log
- Evaluation plan
- 02Test
Build the smallest useful proof
Use synthetic, redacted or expressly approved examples in an isolated environment; record results, defects and unsupported cases.
- Reviewable prototype
- Versioned results
- Issue record
- 03Assure
Validate controls and fit
Where in scope, assess data flows, access, threats, accessibility, integration, user acceptance and operating responsibilities.
- Control decisions
- Test and UAT record
- Updated risks
- 04Decide
Handover the evidence
Document what was learned and decide whether to stop, adjust, procure or plan a separately governed production stage.
- PoC report
- Handover materials
- Decision record
Proceed
Evidence supports a defined next stage, with owners, controls, funding and procurement route still to be agreed.
Adjust
Potential value exists, but the need, sources, controls, workflow or evaluation requires another bounded test.
Stop
Evidence does not justify more work, the risk is disproportionate or no accountable operating model exists.
A successful PoC is evidence for a decision. It is not production acceptance, an award, an accreditation or permission to process live or classified information.
Project assurance
Make the service boundary and evidence visible.
The following areas are addressed to the level required by the agreed risk and scope. They are not represented as controls already implemented in an unspecified government environment.
| Review area | Evidence to define or produce | Current public status |
|---|---|---|
| Purpose & governance | Outcome, owners, decision boundary, acceptance criteria and escalation path | Delivery method only |
| Data & privacy | Data inventory, purpose, flow, access, location, retention, deletion and processor roles | Project-specific |
| Security | Threats, identity, privileges, secrets, dependencies, testing and incident route | Project-specific |
| AI governance, if used | Sources, models, providers, evaluation, human oversight, limitations and output handling | Project-specific |
| Accessibility | Target standard, semantic and keyboard checks, content review and assistive-technology testing | Project-specific |
| Hosting & integration | Architecture, interfaces, environments, locations, release, rollback and recovery decisions | Project-specific |
| Quality & acceptance | Traceable scenarios, results, defects, exceptions, UAT and residual risks | Project-specific |
| Operations & exit | Monitoring, support split, change, runbook, export, deletion and transition terms | Project-specific |
Official guidance used as a reference point
Referencing guidance does not establish compliance. The customer, legal advisers and accountable authorities determine the obligations and evidence applicable to a project.
DPO Ethical AI Framework
Principles, practices and assessment for responsible AI planning and implementation.
Open official sourcePCPD AI Model Framework
Risk, human oversight, data protection, supplier due diligence, testing and stakeholder communication.
Open official sourceDPO Digital Accessibility
Government website accessibility position and guidance on WCAG Level AA.
Open official sourceDelivery and procurement evidence
A dossier tied to the proposed work—not a generic badge wall.
The exact artefacts are created or completed for the approved scope. “Expected” below describes the delivery method, not a claim that a department has reviewed or accepted an existing document.
| Artefact | Expected content | Status |
|---|---|---|
| Service brief & scope | Need, users, baseline, boundaries, deliverables, exclusions, owners and acceptance | Per engagement |
| Architecture & data map | Components, providers, interfaces, flows, locations, access and responsibility split | Per engagement |
| Risk & decision record | Assumptions, policy questions, risks, mitigations, approvals and unresolved items | Per engagement |
| Test & UAT pack | Scenarios, methods, versioned results, defects, exceptions and sign-off route | Per engagement |
| Release & operations pack | Environment, deployment, rollback, backup, monitoring, runbook, support and training | If production is in scope |
| Commercial & exit schedule | Milestones, pricing basis, third-party cost, IP/licensing, change, export and transition | In agreed proposal/contract |
Proposed responsibility split
222 Technology, subject to contract
- Service and technical design
- Implementation and agreed integrations
- Architecture, test and operating documentation
- Issue, release and change records
- Training and handover within scope
Department or commissioning organisation
- Accountable service, data and content owners
- Policy, data classification and risk decisions
- Approved environments, access and source materials
- User acceptance reviewers and operational queues
- Procurement, legal approval and residual-risk acceptance
One possible external route
Smart LAB becomes relevant after a concrete solution and use case are defined.
The Smart Government Innovation LAB connects departments with the technology sector and supports proof-of-concept and technology testing. It is one possible matching route—not a company credential or a substitute for procurement.
Keep the routes distinct
Smart LAB I&T suppliers
Service needs and I&T solution proposals
The official form asks for a named solution, application and technology areas, use case, optional department fit and government reference, PoC setup time, supporting files and verified company/contact particulars.
Open official supplier routeSmart LAB AI catalogue
Off-the-shelf AI solution route
This route asks additional product-level questions such as deployment options, GPU, pricing, trial, hardware, presentation deck and video. Use it only where a real solution can answer those fields factually.
Open official AI routeGovernment procurement
Separate tender and supplier channels
A Smart LAB proposal is not a tender. e-Procurement, tendering, GLD lists and IT-product arrangements have their own requirements and official processes.
Open official procurement overviewBefore any Smart LAB proposal
- Freeze a concrete bilingual solution name, purpose and bounded use case.
- Match a current service need or explain the relevant public-service outcome.
- Confirm technology, deployment, data, trial timing and supporting evidence factually.
- Leave optional government references blank unless a real, authorised reference exists.
- Review public versus internal information, IP rights and the current declaration before submission.
- Have an authorised representative verify legal company and contact particulars.
No Smart LAB submission, listing, review, approval or matching outcome is claimed. Submission does not itself constitute endorsement, accreditation, an intention to tender or an award; the current official form and declaration must be checked at the time of submission.
Start with a service need
Turn it into a reviewable delivery brief.
Share the user group, current workflow, desired outcome, constraints and the decision a PoC should support. Do not send personal, classified or operationally sensitive data in the first message.