Tier 1
Human-reviewed
No deep systems integration. Every output is reviewed by a person before use.
Typical assuranceStandard IG review · Trust AI-use policy
Clinician-built healthcare technology
Healthcare AI should not simply be delivered to clinicians. It should be shaped by them.
Surgeon-led tools, built around real pathway friction — locally adaptable, tightly governed and accountable by design.
Explore01Clinician-led
02Bounded
03Validated
04Auditable
05Useful
02 Our position
AI can assist, coordinate, summarise and automate bounded tasks. Accountability does not move.
Local paceClinical control
03 Governance by design
Not bolted on later
The level of assurance follows what the tool does — not what it is called.
A simple interface can carry clinical consequence. A sophisticated model can remain low risk when its authority is tightly bounded and every output is reviewed.
Tier 2
Operationally integrated
Connects with EPR, booking, theatre or diagnostic systems to coordinate bounded workflow tasks.
Typical assuranceDPIA / IG per data flow · DCB0160 where outputs enter the record · Integration engineering
Tier 3
Clinically influential
Any function that informs a clinical decision, regardless of how simple the interface appears.
Typical assuranceDCB0129 / 0160 · Named CSO · Shadow-mode validation · DPIA / Caldicott · DTAC · MHRA SaMD assessment where applicable
Important
App-level classification is function-specific. One product may contain Tier 1, Tier 2 and Tier 3 functions; each function should be governed according to its data flows, integration and clinical influence.
05 Safe change
Local iteration, controlled release
Change quickly. Know exactly what changed.
01
Define the friction
02
Bound the task
03
Validate in shadow mode
04
Release with approval
05
Monitor, learn, version
Bespoke does not mean uncontrolled. Every iteration can have a clear owner, intended use, evidence threshold, audit trail and route to stop.
That is how local ownership and rapid learning coexist with strong clinical safety.
04 Current work
A growing portfolio. One philosophy.
Built for the friction that teams actually feel.
My Foot Care
Diabetic foot check-in
A patient photographs their foot and answers five questions. The model checks only that the photograph is usable — it can accept it or ask for a retake, and nothing else. Urgency is computed from the four symptom answers alone by a rule set you can read on screen; skin colour is captured only to help contextualise visible colour change. A second stage adds classification of the wound, and the difference between the two is visible in a case where quiet symptoms and a visible ulcer disagree.
- Photo usability only
- Four symptom rules
- Skin colour context
- Clinician review
Governance position
The photograph check is Tier 1 — it can only request a better photograph. The urgency band is Tier 3 despite being the simplest component in the tool, because it can influence care.
OpenDemo
CT Splicer
Orthopaedic surgical planning
CT Orthopaedic Surgical Planner
A surgeon-facing way to view, link and plan from CT. Linked multiplanar reconstruction and 3D, built for planning custom osteotomies and fracture fixation.
- DICOM-based workflow
- Linked multiplanar CT + 3D
- Surgeon-facing planning
- Research / planning status
Governance position
Research and planning only. If used to inform clinical planning it would require Tier 3 assurance and a device assessment.
OpenDemo
Bridge
Virtual fracture pathway
An emergency department referral arrives as free text. The model transcribes it into eleven structured fields, each of which the clinician can change. Allocation to a discharge, virtual or face-to-face pathway is then made by an ordered rule set encoding local protocol — not by learning from past consultant decisions, which record what was done rather than what should have been.
- Eleven editable fields
- Clinician confirmation
- Ordered local rules
- Visible allocation trace
Governance position
Extraction is Tier 1 with mandatory clinician confirmation. Allocation is Tier 3. Automated reading of the radiograph is not built and is a medical device from day one.
OpenDemo
Concord
Medicines reconciliation checking layer
Concord describes each medication source independently, then uses deterministic rules to compare drug, dose, formulation, frequency and status. It flags discrepancies with source quotations and provenance for named pharmacist review; it never writes back to the patient record.
- Source-by-source extraction
- Deterministic comparison
- Named pharmacist review
- Decision trace & audit log
Governance position
Synthetic prototype with writeback blocked by design. Any live use would be Tier 3 because discrepancy flags may influence medication decisions, requiring clinical safety cases, a named CSO, validation, DPIA / IG, DTAC and device assessment where applicable.
OpenDemo
06 Evidence
Measured, then re-measured
Evidence starts with a fixed test.
How these are evaluated
I evaluate these against synthetic documents with clinician-defined answers. The run is blind, against a fixed corpus that I re-measure whenever the model, the prompt or the rules change.
34 synthetic documents40 deliberately planted errors45 medicationsRun blind · answer key withheld
- Hallucinated findings
- 0
- Ungrounded findings
- 0
- Drug surfaced at all
- 45/45
- Blind recall against planted errors
- 90% 36/40
- Precision against my key
- 78.6%
How to read the misses
The four “misses” were not missed drugs: every drug was surfaced. They were differences in discrepancy labels, including two cases the engine declined to categorise because the source documents contradicted each other. Declining is the design working.
What the scorer caught
Precision is 78.6% against my incomplete key; most of the shortfall was real discrepancies I had not planted. Two initial hallucination flags were faults in my scorer around “MST 30mg” and Fostair. I fixed it and re-ran. Nothing was fabricated.
What it doesn’t establish
One model, one untuned run and synthetic documents. No real patient data and nothing tested prospectively. This is a measurement, not a validation.
The first thing this harness caught was a fault in its own safety metric.
Kernel Clinic
Outpatient consultation and letter
Dictate a consultation and the model drafts the letter, under instructions that forbid it from adding anything not dictated and require it to flag anything it was unsure of. Actions are then executed by ordinary code with guards: a follow-up is only created when an interval was actually stated, and surgery is only listed when the operation was named.
- Constrained letter draft
- Explicit uncertainty
- Guarded follow-up
- Clinician sign-off
Governance position
The draft is Tier 1 — nothing is signed, filed, booked or coded without the clinician. The flags the model raises about its own uncertainty are the interesting output, not the letter.
OpenDemo
Kernel Messenger
Patient messaging with visible safety layers
A patient-facing messaging prototype that answers from a small, visible corpus of synthetic Trust documents. Deterministic emergency patterns run before the model, confirmation is required before the simulated ambulance flow, and each message carries an inspectable decision trace.
- Sourced patient information
- Pre-model safety rules
- Confirm-first escalation
- Per-message decision trace
Governance position
Sourced information and draft replies remain human-reviewable. Any symptom triage, emergency escalation or action that could influence care would require Tier 3 assurance, validation and explicit clinical ownership.
OpenDemo
Kernel Trauma
Trauma referral and coordination
Type a referral and watch three things happen in order. An escalation guard runs first — eight patterns for open fracture, vascular compromise, compartment syndrome and the rest — and when it fires, the model is never called at all. Only if it stays quiet does the model extract observations, which a routing rule set then acts on.
- Pre-model escalation guard
- Bounded observation extraction
- Deterministic routing
- Simulated coordination
Governance position
The escalation guard is deterministic and pre-model, so nothing written in a referral can talk it out of firing. The pipeline, theatre and bed displays are a simulation and are labelled as such.
OpenDemo
AI Coordinator
Pathway coordination
Coordinates referrals, MDTs, beds, theatres and diagnostics; chases missing actions and makes pathway leakage visible before it becomes delay.
- Referrals & MDTs
- Beds, theatres & diagnostics
- Chasing missing actions
- Preventing pathway leakage
Governance position
Tier 2 for operational integration; Tier 3 wherever an output informs a clinical decision.
OpenDemo
IG Companion
Information governance checking layer
Turns safety, privacy and information governance obligations into checks a computer can run, so claims arrive as signed facts that a trust can verify independently.
- Published requirement citations
- Supplier claims as signed facts
- Public-key verification
- Open-source review
Governance position
Working software, not a live service. It does not replace accountable sign-off; it makes the evidence behind that sign-off easier to check.
OpenDemo
+
An extensible portfolio
More clinician-built tools will follow.
New tools start with a named pathway problem, a bounded purpose and a governance position — not a technology looking for somewhere to land.
07 Research
AI safety research · results added as runs land
Does the training that makes a model more capable also make it safer?
Two questions, run as experiments on a university cluster: whether capability brings a reason to preserve the world a model depends on, and whether a trained model can keep learning without losing what it knows. Results are published whichever way they go, including the ones that went against the prediction.
- A capable newcomer works out the right answer, then matches the group’s wrong one. A negative result.
- New facts entered a model’s weights without damaging it, then the loop forgot its own memories.
- Shuffling trained weights destroys the organisation and leaves the entropy untouched.
For clinical teams and hospital leaders
Bring us the pathway problem.
We will start with the people doing the work, define the smallest useful tool, and build the governance alongside it.
Contact details will be added before public go-live.