02 — Technical Implementation Route

NMAI Core, NHS Clinical CUI, UK Model Handoff

Chapters 10 – 35 — The complete technical build route: components, API, decision states, stack, project structure, rules, CUI, LibreOffice, vLLM, Docker, model selection, and pilot.

Full Master Architecture PDF

Download the complete NHS Sovereign AI Replacement Architecture master record. The web pages provide section summaries; the PDF contains the full technical architecture.

Download PDF
In This Section
Purpose Core Components NMAI Core API Decision States Technical Stack Project Structure NHS Rule Configuration NHS Clinical CUI LibreOffice Integration vLLM Integration Docker Deployment Model Selection Pilot Measurement Deployment Stages
Purpose

This page summarises the technical implementation route for the NHS Sovereign AI Replacement Architecture.

The purpose is not to build another chatbot. The purpose is to prove a controlled route:

NHS input
NMAI Core
Decision state
Audit reference
Model only where permitted
Draft output
Human review

The architecture is designed so the NHS can pilot, test, audit, stop, replace, and scale the system without surrendering the workflow to a model-first dependency chain.

Core Components

The technical stack separates the workflow into distinct layers:

LayerFunction
NHS Clinical CUIControlled workflow interface for task selection, input capture, marker display, warnings, blocked states, and review states
NMAI CoreDeterministic input-conditioning kernel that controls whether model access is permitted
Ruleset layerNHS-approved marker rules, blocked states, warning states, review triggers, and escalation logic
Audit layerRecords decision state, model-access outcome, ruleset version, and audit reference
UK-controlled model endpointOptional post-conditioning execution module for permitted drafting, summarising, rewriting, restructuring, or formatting
Human review layerKeeps output draft, reviewable, correctable, and subject to NHS approval
Emergency stop and fallbackAllows generation to be disabled while condition-only or manual workflow continues
Core Principle
The model is only one component. It is not the system.
NMAI Core API Route

The implementation route uses a lightweight local or hosted API layer. Core endpoints:

EndpointPurposeModel call
POST /conditionInput conditioning onlyNo
POST /markersMarker detection onlyNo
POST /routeRouting decision onlyNo
POST /condition-and-generateControlled route with optional generationConditional
GET /healthService healthNo
GET /auditRestricted audit summaryNo
Key Insight
The important endpoint is not generation. The important endpoint is conditioning. Generation is conditional.
Decision States

NMAI Core creates a decision state before model handoff:

DecisionMeaningModel access
PermitTask may proceed to approved model routeAllowed
BlockInput must not reach the modelDenied
WarnCaution markers detectedConditional
ReviewHuman review required before model accessPaused
EscalateTask must move to specialist processDenied unless authorised
Fail closedControl failure occurredDenied

The system is designed to stop safely. A failure must not fall back to an external model.

Technical Stack

The prototype and pilot stack uses open-source or inspectable components:

ComponentRoute
API frameworkFastAPI
API serverUvicorn
Ruleset formatJSON
Audit formatJSONL append-only logs
Model servingvLLM
Reverse proxyNginx
Container routeDocker / Docker Compose
Office-layer integrationLibreOffice plugin route
Pilot interfaceNHS Clinical CUI first

The preferred pilot path is CUI-first. LibreOffice integration can operate as an office-layer replacement route, but the NHS Clinical CUI is the cleaner first pilot path because it avoids being blocked by locked desktop estates.

Project Folder Structure
nhs-sovereign-ai/
|-- nmai/
|   |-- engine.py          (NMAI Core deterministic conditioning)
|   |-- markers.py         (Marker detection module)
|   |-- rules.py           (Ruleset loader and validator)
|   |-- audit.py           (Audit trail writer)
|   +-- config.py          (Configuration loader)
|-- rules/
|   +-- nhs-rules.json     (NHS marker rules)
|-- api/
|   +-- main.py            (FastAPI service)
|-- audit/
|   +-- logs/              (JSONL append-only audit logs)
|-- model-gateway/
|   +-- handoff.py         (UK model endpoint handoff)
|-- vllm-server/
|   +-- Dockerfile
|-- nginx/
|   +-- nginx.conf         (Reverse proxy configuration)
|-- libreoffice/
|   +-- plugin/            (LibreOffice extension files)
|-- docker-compose.yml
|-- requirements.txt
|-- Dockerfile
+-- README.md
NHS Rule Configuration Layer

The rules file defines the deterministic boundary for all NHS AI workflow:

Rule CategoryDetection
Blocked identifiersNHS numbers, dates of birth, postcodes, names, addresses
Clinical high-risk termsDiagnosis, medication, treatment plans
Safeguarding markersAdult/child safeguarding, vulnerable person indicators
Legal / complaint markersLitigation, complaint, negligence, coroner
Governance markersCaldicott, IG breach, data subject request
Review-required markersTriggers mandatory human review
Decision statesPermit, block, warn, review, escalate, fail closed
Closed-Domain NHS Clinical CUI

The NHS Clinical CUI is a controlled workflow interface — not a gimmick chatbot.

Its functions:

  • Input capture: Receives NHS workflow input in structured form
  • Task selection: Presents approved task categories (rewrite, summarise, restructure, format, draft)
  • Marker display: Shows detected markers to the user
  • Warning display: Surfaces caution markers with explanation
  • Blocked state: Clearly prevents blocked tasks from proceeding
  • Human review state: Holds output for clinical review before release
  • Escalation route: Routes specialist tasks to appropriate teams
  • Output state: Displays conditioned output with audit reference
  • Audit reference display: Shows unique audit ID for every transaction

The CUI preserves context throughout the workflow. It does not allow open-ended chat that could drift off-domain.

LibreOffice Plugin Integration

The LibreOffice plugin provides office-layer integration:

  • Document check before export: Validates content against NHS rules
  • Document check before AI assistance: Routes content through NMAI Core conditioning
  • Python-UNO route: Uses LibreOffice's native Python bridge
  • Local API call: Communicates with NMAI Core service on local network
  • Blocked-state display: Clear warnings when content is blocked
  • Warning-state display: Surfaces caution markers with required actions
  • Output handling: Returns conditioned output back into the document
  • Local-only configuration: No external network required

Plugin workflow: User selects text or whole document → clicks plugin action → document text sent to NMAI → NMAI checks input → returns blocked, warning, review, or approved state → output returned to LibreOffice with audit reference.

vLLM Integration Route

vLLM serves as the post-conditioning execution module — not the primary system.

AspectRequirement
DeploymentUK-hosted only, internal-only endpoint
InputConditioned input package from NMAI Core only
Output handlingReturned as draft, subject to human review
Failure handlingSafe failure, no fallback to external model
SecurityNo direct access, reverse-proxy controlled
API compatibilityOpenAI-compatible API for model serving

Permitted model tasks:

Rewriting approved text, summarising permitted administrative content, restructuring meeting notes, formatting internal policy text, converting structured notes into draft documents, producing plain-English wording from approved source material.

Blocked/restricted tasks:

Direct clinical diagnosis, patient-specific medical advice, medication recommendations, unsupervised treatment planning, any task bypassing NMAI conditioning.

Docker Deployment

The full NHS stack deploys as a Docker Compose multi-container system:

ContainerRole
NMAI serviceDeterministic conditioning, rules, audit, API
vLLM serverPost-conditioning model execution (GPU required)
NginxReverse proxy, internal routing, access restriction

Key commands:

# Build and start all containers
docker-compose up --build -d

# Check running services
docker-compose ps

# View logs
docker-compose logs -f nmai

# Test NMAI conditioning endpoint
curl -X POST http://localhost:8000/condition \\
  -H "Content-Type: application/json" \\
  -d '{"text": "Summarise this meeting agenda"}'

# Stop stack
docker-compose down
Model Selection and Compliance

The model is not selected to replace ChatGPT. The model is selected only to execute bounded permitted tasks.

RequirementStandard
Task-fitModel capability matches approved task list
Version-controlledExact model version recorded and auditable
UK-hostableDeployable inside approved UK environment
Open-source / open-weightFull weight inspectability, no API dependency
AuditableModel name and version in every audit record
ReplaceableSwappable without redesigning the system
Input-controlledCannot receive raw input by default

Model selection checklist: Licence review → NHS use approval → No external API calls → Version lock → Capability boundary → Safety limits → NMAI Core compatibility → Hardware envelope check → Replacement and exit route confirmed.

Pilot Measurement

The pilot measures the full route, not model speed alone.

Productivity = (Time Saved) / (Total Route Cost)
Total Route Cost = NMAI conditioning time + model runtime + human review time + correction time + governance overhead
Measured FieldPurpose
Baseline manual task timeControl measurement
NMAI conditioning timeOverhead assessment
Blocked-task countSafety effectiveness
Warning-task countRisk detection rate
Review-task countHuman oversight burden
Permitted model handoff countAppropriate usage
Avoided model callsPrivacy protection
Model runtimeActual generation time
Human review timeGovernance overhead
Correction timeOutput quality measure
Final accepted/rejected outcomeOverall effectiveness
Key Principle
A fast model output is not a productivity gain if it increases review burden, correction burden, or governance risk. The sovereign route must demonstrate lower total cost of ownership.
Deployment Stages
StagePurpose
Local prototypeProve NMAI conditioning, ruleset logic, audit, and safe failure
Department pilotTest bounded workflow tasks using synthetic or approved non-identifying data
Trust pilotTest controlled operational deployment with governance oversight
Regional deploymentTest interoperability and wider operational scaling
National deploymentDeploy only after evidence, governance, cyber, procurement, and exit controls are approved
Core Rule at Every Stage
No NMAI Core decision, no model call.
← 01 Architecture Home 03 Governance →