A production-readiness audit
The application tested as a running service on a frozen baseline: every user workflow attempted and recorded, security checks, a load test and a maintainability review. Each finding came with its evidence.
How the UK's clinical study registry found out exactly what stood between its AI-built results platform and production, and is prioritising fixes to get feedback from researchers.
Remediation under way · researcher testing next
ISRCTN is the not-for-profit behind the UK's clinical study registry, which is recognised as a primary registry by the World Health Organization (WHO). New UK regulations for trials of medicines require sponsors to post their results within twelve months of a trial ending on a WHO registry. There is also new WHO guidance on the results that should be posted. ISRCTN is building a system that lets researchers post their results as easily as possible while meeting these requirements, providing transparency and enabling other researchers to use the data in further studies. The system enables results to be provided in a structured, checked form: results entered across twelve sections, PDF tables uploaded where online tables don’t fit the type of study or if its easier for researchers to provide accurate and complete data, the data entry checked online, and the results published on a stable public page linked from the registry.
ISRCTN had already built a working prototype version of the platform in house, using AI coding tools: accounts, the twelve sections, automated checks with AI-assisted warnings, an admin area and payments. It worked. The open question was whether it would work with real researchers and real data, because an application built quickly with AI can look finished while resting on foundations that will not hold in production. ISRCTN asked Brainqub3 to find out.
We froze the code at an agreed baseline, stood the application up in our own environment and tested it as a running service, not just as a codebase. We catalogued 76 user workflows across every role, from a visitor without an account to an administrator, and an AI agent recorded each attempt on video as proof of what happened. Alongside that ran security checks, a load test and a review of how maintainable the code is. Of the 73 workflows we could test, 50 did what they should. The verdict was clear: not yet ready for production, with 38 findings, 21 of them blocking it. ISRCTN received every finding, with its evidence and the tools to re-run the tests, in a single repository.
Offered a smaller rebuild or targeted fixes, ISRCTN chose to fix what it had, because a slimmed-down system would not meet the needs of researchers or WHO guidance. ISRCTN merged our findings with its own list into one remediation plan and gave every line a gate. What researchers need fixed before they touch the platform comes first, in a five-week phase called UAT-Light, together with the minimum security fixes. The rest is done while researchers at UK universities put it through its paces. Production follows, shaped by what the testing finds.
The application tested as a running service on a frozen baseline: every user workflow attempted and recorded, security checks, a load test and a maintainability review. Each finding came with its evidence.
ISRCTN's own remediation plan, gated line by line: what must be fixed before researchers test, what is fixed while they test, and what waits for production.
Every fix is made in our own environment with an automated test, verified against the check agreed for it in the plan, and run on a deployment set up like production. ISRCTN signs off each release before testers see it, and the fixes and the decisions behind them are documented, so ISRCTN has what it needs to run the platform.
“I really appreciate it. Really impressed by the thoroughness of your review.”Andrew Freeman, Chair, ISRCTN
Tell us where it is and we will tell you honestly what stands between it and production. Sometimes it is closer than you think.