Glass-Box Interpreter Workbench AI assurance for court interpretation — a working prototype
checking status…
Why this exists

Around 600 hearings a day in England & Wales run through an interpreter. Almost none are ever quality-checked.

Interpretation is a fair-trial right under Article 6. But the quality of what is actually said in court is nearly invisible: roughly 1% of bookings are spot-checked, whispered interpretation for defendants is effectively unassessable, and errors surface — if ever — years later, on appeal.

~190,000interpreter bookings a year across courts and tribunals
~1%of bookings quality-assessed — none of it covering whispered interpretation
−33%registered public-service interpreters since 2011, with strikes in 2025
18,500/yrbookings unfulfilled or sourced off-contract
“Interpreting services in the courts are not working efficiently and effectively… a significant risk to the administration of justice.”
House of Lords Public Services Committee, Lost in translation?, March 2025

The bet: AI as the auditor — never the interpreter

The Ministry of Justice has said, correctly, that live AI interpretation in courtrooms is not appropriate. This project takes the opposite corner of the same board: keep the human interpreter exactly where they are, and use AI to make their work checkable and supported — two surfaces on one pipeline.

1 · Post-hearing quality assurance

Take the recording of an interpreted hearing. Transcribe both languages, align each utterance with its rendition, and have an LLM judge flag omissions, additions, meaning changes and number errors — every flag reviewed by a human, every stage inspectable. What today is a 1% sample becomes 100% checkable.

2 · Live assist, private to the interpreter

A screen only the interpreter sees: a running transcript with numbers, dates, names and case terminology surfaced within the ~2-second window the interpreting research says is usable. Research shows this kind of support cuts interpreters’ number errors by roughly 70%. It never judges, never speaks, never appears in the courtroom.

What we will not build

No machine interpretation of proceedings. No live error-flagging while an interpreter works. No unreviewed AI output entering any record. These are design red lines, not roadmap items — they are what makes the rest defensible.

Why now

The Lords committee told the MoJ to publish a funded roadmap for AI interpreting tools. The new language-services contracts (from October 2026) contractually oblige suppliers to collaborate on AI. The MoJ is already piloting AI transcription in Crown Courts and AI translation in prisons. The policy window is open — what is missing is evidence, and this prototype is built to generate it.

Current state

Is the demo running right now?

Checking…

The demo environment is deliberately not always on. Cost discipline is part of the design: the load balancer and compute exist only while a demonstration is running, and every stand-up and tear-down happens through infrastructure-as-code — which is also what updates this page’s status, automatically, on every change. If it says live, it is; if it says offline, nothing is running and nothing is being spent.

What you see when it’s up

Live Assist console: rolling transcript, surfaced entities, latency meter
Live Assist — rolling transcript of a mock hearing with numbers, names and glossary terms surfaced; the latency meter shows real end-to-end lag against the 3-second ceiling from the interpreting literature.
QA report: WER comparison and judge scorecard vs seeded ground truth
QA report — provider word-error rates and the judge’s scorecard against a hearing with 18 deliberately seeded interpretation errors: recall, precision and false positives published, not hidden.
Glass-box drawer showing the judge stage's raw output
The glass box — every pipeline stage can be flipped open to its raw output, real latency and real cost. Nothing on screen is mocked.

Latest measured results (10-minute dual-mode mock hearing, synthetic audio, August 2026)

94%of 18 seeded interpretation errors caught by the judge (89% with exact error-type match)
74%precision — false positives are counted and shown, because a QA tool that cries wolf is worse than none
0.4smedian live-assist latency (max 2.5s) vs the 3s usability ceiling from controlled studies
~£0.50full QA pipeline cost per hearing at on-demand cloud prices
Architecture

One pipeline, two tempos — everything inside London

The same audio feeds two consumers: a live window for the interpreter (sub-second streaming) and a batch path for quality assurance (minutes, after the hearing). The judgement work never leaves the eu-west-2 (London) cloud region — enforced by infrastructure policy, not promises.

Post-hearing QA path

Hearing audiosynthetic fixtures today; DARTS-shaped tomorrow
Speech-to-text ×2hosted vs open-source, scored against each other
Alignsource ↔ rendition, per utterance
Translaterendition → English gloss
LLM judgeomission · addition · meaning · numbers, in-region
Human reviewerconfirms or dismisses every flag

Live assist path

Room audioreal-time pace
Streaming speech-to-textpartials in ~300ms
Entity surfacingnumbers · dates · names · glossary — no LLM in this path
Interpreter’s screenprivate; advisory only

What the evaluation harness measures

QuestionMethodLatest result
How accurate is transcription?Word-error rate vs scripted ground truth, per provider, per language8.5% (hosted) vs 12.5% (open-source) on the mock hearing
Does the judge find real errors?Recall against 18 seeded errors of known type and severity94% lenient · 89% strict
Does it invent errors?Precision + false-positive rate on deliberately clean utterances74% precision; 6 false positives — the current calibration frontier
Is live support usable?Measured end-to-end latency vs the 2–3s ceiling from interpreting studies0.4s median, 2.5s max

Findings the hard way

findingAutomatic language identification collapsed on code-switched courtroom audio — 44.5% word-error rate. Fixed by running one pass per language, which is legitimate: the language pair is always known from the booking. findingWhispered interpretation tolerates compression, so judging it needs different instructions than consecutive — a nuance a generic “AI checker” would miss. Both findings are exactly the kind of evidence a real procurement will need.

Deployment: a UK-region cloud account whose own permissions physically cannot create resources outside London, with an audit trail on from the first action and a monthly budget guardrail. The demo estate is destroyed and rebuilt from code routinely — the same posture we would recommend to HMCTS.

How it’s built

Principles that survive contact with a courtroom

Glass box, not black box

Every stage shows its raw output, real latency, real cost and real confidence. The transparency layer is the same evidence a public-sector assurance process needs — the demo and the audit artefact are one thing.

The human decides

AI proposes; a named person disposes. Judge flags become findings only when a reviewer confirms them. Nothing automated enters any record unreviewed.

Honest about limits

False positives are published. Failure modes are demonstrated on purpose. For languages where the technology isn’t good enough, the correct product behaviour is to decline and route to humans.

Sovereign by construction

Everything — including the judging model — runs inside the London cloud region, and the account’s own permission boundary makes leaving the region impossible rather than discouraged.

Evidence before scale

Every capability lands with a measurement: seeded ground truth, per-language error rates, judge precision/recall. If a change can’t be measured, it doesn’t ship.

Cost discipline as credibility

Idle cost is pennies; compute exists only while demonstrating. A tool proposing to save public money should visibly not waste it.

Also load-bearing: synthetic data only — no real court audio has ever entered this system; real recordings belong exclusively to a governed pilot with a data-protection impact assessment.

Where this goes

From working prototype to evidence-backed pilot

Done · July–August 2026

Research pack and working two-part demo

Domain research (contracts, Lords inquiry, tooling landscape); UK-region cloud foundation; the glass-box workbench; a 10-minute dual-mode mock hearing with 18 seeded errors; live assist within the research latency budget; the evaluation scorecard.

Now

Calibration and breadth

Drive judge false positives down with the scorecard as the yardstick; add specialist ASR vendors (including UK-based Speechmatics) to the A/B rig; automatic speaker separation; per-language capability tiers with an explicit “human only” gate — demonstrated on Kurdish Sorani, where no credible speech recognition exists.

Next

Reviewer workflow and the second and third workflows

Confirm/dismiss audit trail for QA reviewers; interpreter-facing preparation packs and glossary tooling; document translation with post-editing. Alongside: co-design with practising court interpreters and QA analysts — the people this must work for.

Then · with HMCTS

Discovery and a governed pilot

Service design with HMCTS and the Language Shop; a data-protection impact assessment; evaluation on consented, realistic recordings (mock trials first); published per-language results. The evaluation harness becomes the neutral test rig for a future market engagement.

Horizon · gated on evidence

Only what the evidence supports

Supervised AI translation for low-stakes administrative contexts — the MoJ’s own pilot territory — if and only if the measured evidence clears the bar. Live courtroom interpretation by machine is not on this roadmap.

Sources

The evidence this is built on

A selection of the primary sources behind the problem statement, the design red lines and the latency budget. The project’s full internal research pack (tooling landscape, domain briefing, temporal-architecture decision, novelty check) is available on request.

Policy & the state of the service

The science of interpreting with (and judging) machines