Starting Point: A Promising AI Prototype Stuck Between Labs and Clinics
Meet CliniQ. It’s an explainable, multilingual clinical documentation AI for UK primary care. And it’s already more real than most projects Innovate UK sees.
CliniQ’s team trained it on 12,000 de-identified GP consultation transcripts. In the lab, it hit 89% clinical entity recognition accuracy. That’s solid TRL 4: component validation in a controlled environment.
But they didn’t stop there. They pushed it into sandboxed deployment at two GP practices for four weeks. Real clinicians. Real ambient noise. Real accents. The AI generated draft clinical notes from live voice-to-text transcriptions. Doctors reviewed and edited before signing. Results: 62% reduction in documentation time and a 94% edit-acceptance rate. That’s TRL 5: prototype validated in a relevant environment.
Here’s where founders make their first critical mistake - almost exactly what CliniQ’s team did.
They saw the Jan 2024 round of Smart Grants, which emphasised feasibility. They thought: “We have an early prototype. Feasibility rounds are for early-stage work. Perfect fit.”
Wrong.
Feasibility rounds are for TRL 3-4 projects - concepts at the proof-of-concept or lab-bench stage. They fund high-risk, high-potential ideas that need initial validation. CliniQ had already leapfrogged that by running real-world tests. Submitting a TRL 5 project into a feasibility round would have looked like overkill. The assessors would have asked: “If you’ve already proven it in GP clinics, what’s the technical risk you’re trying to reduce?”
That question alone can disqualify an application. Not because the work is weak, but because you’ve picked the wrong round for your TRL stage. The funder expects a certain risk profile. You don't want to bring a car to a bicycle race.
The team caught their mistake before they hit submit. They stepped back, mapped their TRL baseline properly, and realigned their strategy. Here’s what they did next.
The Audit That Uncovered the Right Round for TRL 5 to 6
CliniQ’s team conducted a systematic TRL diagnosis using UKRI’s official definitions. The key question: was this a lab experiment or a real-world prototype? Their sandbox deployment-where 2 GP practices used the AI for live note generation-clearly placed them at TRL 5 (component validation in relevant environment). This wasn’t TRL 4 because the clinical setting, ambient noise, and doctor feedback loops created genuine environmental variables. Nor was it TRL 6: no EMR integration, no multi-site scaling.
With TRL 5 confirmed, the round selection became clear. Experimental development rounds (e.g., Nov 2024-style competitions) explicitly target TRL 5-6 projects needing integration complexity and user validation. Feasibility rounds (TRL 3-4) would underfund CliniQ’s API integration work, while industrial research rounds emphasise de-risking novel components-not scaling a proven prototype.
Budget alignment confirmed the fit. CliniQ needed £680k: £320k in-kind (GP consortium time, NHS test beds) plus £100k seed from a healthtech VC. This matched the experimental development cap and the 55% match funding requirement for SMEs. An industrial research round would require only 30% match but fund at lower levels-forcing the team to strip critical integration work. The systematic audit proved that TRL diagnosis isn’t academic: it’s the difference between a fundable narrative and an automatic mismatch.
Rewriting the Application Around a TRL Journey - Not a Snapshot
Rather than leading with 'here’s our innovative technology,' the CliniQ application was rebuilt around a TRL journey: from TRL 5 to TRL 6 in 12 months. The story shifted from describing the prototype to detailing the systematic progression.
The project plan explicitly targets three technical barriers that define the next TRL leap:
- Integration with SystmOne API: The prototype currently runs as a standalone sandbox. Integrating with a live Electronic Medical Record (EMR) introduces latency and data security challenges. The mitigation? A parallel async processing architecture already tested in a simulated NHS environment.
- Multilingual modules (Welsh & Polish): The baseline model is English-only. Adding languages risks entity recognition bias and accuracy drops. The team will retrain on curated clinical corpora, with precision/recall targets (≥85% for Welsh, ≥80% for Polish) and a stop-go decision point.
- Clinical safety validation: Tools like the NHS England Digital Health Assessment Framework are required for deployment, but CliniQ must first demonstrate safety KPIs (e.g., ≤0.5% hallucination rate). The plan includes phased testing with real clinicians reviewing outputs.
Crucially, the application frames technical risk explicitly-not as a weakness, but as proof of genuine R&D. For example: 'Key technical risk: API latency in SystmOne integration-mitigated via parallel processing;' and 'Risk of bias amplification in multilingual queries-mitigated via stratified validation across 12 dialect groups.' This shows assessors the project is uncertain, novel, and experimental, not safe commercial scaling. The clear TRL narrative, combined with risk-awareness, makes CliniQ a compelling fit for an experimental development round-helping it stand out in a pool where many fail because they sound too optimistic.
Three Lingering Mistakes the Team Caught Before Submission
Even after a strong TRL diagnosis and a compelling narrative, the CliniQ team nearly undermined their application with three common oversights. Here’s what they caught-and how fixing each one tightened their case.
Mistake 1: Over-claiming ‘TRL 6’ because of the sandbox.
The sandbox deployment at 2 GP practices felt like a full prototype. But it wasn’t integrated with any EMR system, and only 2 sites were involved-far short of the “multiple” environments required for TRL 6. The team revised their baseline to TRL 5 and framed the project as targeting TRL 6 via SystmOne integration at 3+ sites. This honesty made their technical risk statement stronger, not weaker.
Mistake 2: Underestimating match funding rules for experimental development (55% for SMEs).
CliniQ’s £680K budget assumed a 30% SME match (typical for industrial research). But the project was experimental development, which demands 55%-£374K. The team scrambled to convert £150K of existing GP consortium time into formal in-kind contributions, plus secured a £100K seed commitment from a healthtech VC, hitting the threshold just in time.
Mistake 3: Omitting letters of intent from GP federations and the CCG MoU.
Early drafts described “commercialisation pathways” vaguely. The team replaced this with concrete evidence: 5 letters of intent from GP Federations expressing interest in piloting CliniQ post-project, and a signed MoU with a Clinical Commissioning Group for NHS evaluation. These documents turned vague claims into auditable commitments.
Correcting these three mistakes transformed CliniQ’s application from a promising narrative into an assessor-proof case, grounded in hard evidence and realistic risk management.
What Happened After Submission - And What It Teaches Every Smart Grant Applicant
The CliniQ team received a conditional funding offer from Innovate UK’s experimental development round. The conditions were minor but telling: provide finalised letters of intent from two more GP federations and clarify the data migration pathway for SystmOne integration. The core application-the TRL narrative, the risk acknowledgment, the match funding sources-was approved as submitted.
Three lessons from that outcome.
Lesson 1: TRL precision forces a clearer narrative.
Before the audit, the team described CliniQ as “a prototype ready for clinics.” That statement could mean TRL 4, TRL 5, or even TRL 6. The assessor’s uncertainty would have diluted the story. By pinning their baseline to TRL 5-component validation in a relevant environment-they gave the application a concrete spine. Every subsequent claim about the project’s goals (integration with live EMR, multi-language support, two additional practices) became a measurable step from TRL 5 to TRL 6. The competition round’s emphasis on experimental development, where system-level integration is the central risk, made CliniQ a textbook fit.
Lesson 2: Acknowledging technical risk made the project credible.
The application explicitly stated: “Key technical risk: API latency in SystmOne integration-mitigated via parallel async processing architecture (prototype built, tested in sandbox).” That sentence did more for the application’s credibility than any claim of guaranteed success. It signalled that the team understood the difference between a lab demo and a real deployment. In a competitive round where many applications sound “too optimistic” (Grantify’s warning), a frank admission of the hardest technical challenge-paired with a viable mitigation-stood out.
Lesson 3: The experimental development round was CliniQ’s match.
Had they applied to a feasibility-focused round (which favours TRL 3-4), the application would have seemed over-engineered-too much infrastructure, too little uncertainty. Had they applied to a later-stage Innovation Loan round, they would have needed revenue traction they didn’t yet have. The experimental development round, with its focus on TRL 5-6 projects that need to demonstrate system-level integration in a real environment, aligned perfectly with CliniQ’s next 12 months.
Three actionable principles for readers:
Diagnose your TRL before you choose your round. Use the UKRI definitions, not your intuition. The gap between TRL 4 and TRL 5 is precisely the difference between a lab test and a real-world deployment.
Name the technical risk that will define your project. The risk you acknowledge is the risk you appear ready to solve. It signals that you are not a naive founder but a credible innovator.
Match the round to the TRL step you need to take. Feasibility rounds for early validation, experimental development rounds for system integration. The round’s emphasis is a signal of what the assessors want to see.
CliniQ’s success was not about having the most innovative technology or the biggest letters of intent. It was about precision: knowing exactly where their prototype stood, exactly where it needed to go, and exactly which competition round would fund that journey.
