SaMD Evidence Architecture: Why GitHub Isn't Your Problem

By the time a software as a medical device team is preparing for a submission, audit, or major release, most of the evidence already exists. Requirements live in Jira. Code changes and reviews are tracked in GitHub. Test results populate the development workflow. Release decisions are scattered across tickets, reviews, approvals, and defect discussions. The problem isn't that engineers failed to generate evidence—it's that no one can coherently explain how it all connects when regulators ask. This week, as Greenlight Guru publishes a pointed analysis of SaMD compliance failures in development tools, and Quibim launches QP-Breast as Europe's first CE and UKCA-marked AI tool for breast cancer detection via MRI, the regulatory community is receiving a unified message: fragmented evidence architecture is the silent killer of SaMD approvals.

The Evidence Was There All Along—Just Not Where Auditors Can See It

Greenlight Guru's analysis is surgical in its precision. Most SaMD teams aren't lacking documentation discipline during development. They're failing to translate engineering workflow outputs into regulatory evidence structures. When an auditor or notified body asks to see traceability between a software requirement and its verification test results, pointing them to a GitHub commit history and a scattered trail of Jira tickets isn't compliance—it's wishful thinking. The tools your developers use daily weren't designed for ISO 13485 or IEC 62304 traceability requirements. They were built for velocity, iteration, and collaboration among engineers. The gap emerges when regulatory teams attempt to retrofit those outputs into a coherent design history file.

This isn't theoretical. Quibim's successful CE and UKCA marking for QP-Breast—a diagnostic AI tool analysing breast MRI images to detect suspected lesions—demonstrates what the other side of that gap looks like. As Europe and the UK's first such tool to market, QP-Breast passed scrutiny under both MDR and UKCA frameworks, which means the evidence architecture linking algorithm validation, clinical performance, risk management, and post-market surveillance was audit-ready from day one. The technical work happened in development environments. The regulatory work happened in ensuring every decision, test result, and change was traceable, versioned, and mapped to the intended use and risk profile. That's not a GitHub feature. That's quality management system integration.

The timing of these two stories isn't coincidental. As more SaMD products enter the regulatory pipeline—particularly AI-driven diagnostics under IVDR—the gap between 'we built it right' and 'we can prove we built it right' is widening. Development tools like Jira, GitHub, and CI/CD platforms are non-negotiable for modern software teams. But they don't generate the structured, traceable, auditable evidence that regulators expect to see. The evidence exists. It's just not packaged in a way that survives regulatory scrutiny.

What Quibim's Dual Marking Reveals About Evidence Expectations

QP-Breast's launch under both CE and UKCA marks is instructive. Securing regulatory approval in parallel across two regimes—EU MDR and UK UKCA—for a Class IIb AI diagnostic tool is not a matter of submitting the same dossier twice. It requires structured evidence that can be interrogated from multiple regulatory angles: clinical validation under IVDR, risk management under ISO 14971, software lifecycle under IEC 62304, and cybersecurity under the emerging expectations of both MHRA and notified bodies. The fact that Quibim achieved both marks simultaneously suggests their evidence architecture was designed to support cross-border interrogation from the outset, not retrofitted during submission prep.

This is where the Greenlight Guru analysis becomes actionable. The article doesn't advocate abandoning development tools or forcing engineers into unfamiliar QMS platforms during daily work. Instead, it advocates for building a continuous translation layer—automated where possible, structured always—that pulls evidence from development environments and maps it into regulatory constructs as it's generated. That means requirements in Jira must link to risk analyses, design inputs, verification protocols, and test evidence. Code reviews in GitHub must tie back to design outputs and software unit testing. Defect discussions must feed into risk re-evaluation and change control records. The evidence isn't created twice. It's contextualised once for engineering, and structured once for regulatory interrogation.

For SaMD teams targeting IVDR or MDR pathways, this is no longer optional. As we've noted in our analysis of IVDR CE marks for AI diagnostics, notified bodies are expecting clinical evaluation plans that tie directly to algorithm performance claims, which must trace back to design requirements, validation data sets, and risk controls. If your evidence architecture can't surface that chain of custody on demand, you're not ready for submission—even if every engineering deliverable is technically complete.

The Compliance Debt Hidden in Development Workflows

The real cost of fragmented evidence architecture isn't felt during development. It's felt during pre-submission reviews, when regulatory teams discover they can't answer basic traceability questions without manually reconstructing timelines from engineering tools. It's felt during audits, when notified body assessors ask to see evidence of design verification for a specific software requirement, and the answer involves screen-sharing three different platforms and walking through commit histories. And it's felt post-market, when a complaint triggers a CAPA investigation and no one can quickly determine which software modules, risk controls, and validation tests are in scope.

This is compliance debt—and like technical debt, it compounds. Early-stage SaMD teams often defer evidence structuring because they're focused on achieving technical milestones. By the time they're preparing for submission, the evidence base spans months or years of engineering work across disconnected systems. Retrofitting traceability at that stage is expensive, time-consuming, and error-prone. Worse, it delays market entry at the moment when speed matters most. Quibim's success suggests they didn't defer this work. They built evidence architecture in parallel with product development, ensuring that when the time came to compile clinical evaluation reports, risk management files, and technical documentation, the evidence was already structured, traceable, and defensible.

For teams still in early development, the lesson is clear: your GitHub repository and Jira board are valuable engineering assets, but they're not regulatory evidence systems. You need a deliberate strategy to bridge that gap—whether through automated integrations, structured metadata tagging, or periodic evidence extraction workflows. The alternative is discovering six weeks before your intended submission date that you can't prove basic design traceability without manual archaeology.

What This Means for Your Team

If you're a regulatory affairs lead supporting a SaMD product, audit your evidence architecture now—not during submission prep. Can you answer these questions in under 30 minutes: Which software requirements trace to which risk controls? Which verification tests cover which design outputs? Which code changes were part of which release, and what was the rationale for each? If the answer requires manually searching Jira tickets, GitHub commits, and Slack threads, your evidence architecture isn't ready for regulatory scrutiny. Build the translation layer now, while the evidence base is manageable, rather than attempting to reconstruct it under submission pressure.

For quality and operations teams, this is a systems design problem, not a documentation problem. The goal isn't to duplicate every engineering artefact into a separate QMS. It's to ensure that the evidence generated during development is structured, traceable, and mappable to regulatory requirements as it's created. That may mean integrating your development tools with your QMS, implementing structured tagging and metadata protocols, or building automated evidence extraction workflows. The specific solution matters less than the outcome: when an auditor or notified body asks a traceability question, your team should be able to surface a defensible answer in minutes, not days.

For startups and early-stage SaMD teams, Quibim's dual CE/UKCA launch is a benchmark. If a diagnostic AI tool analysing complex medical imaging can achieve parallel regulatory approval under two of the world's most rigorous frameworks, it's because the evidence architecture was designed to support that level of scrutiny from the start. That doesn't require enterprise-scale infrastructure or six-figure QMS platforms. It requires intentionality: a deliberate plan to structure evidence as it's generated, map it to regulatory constructs, and ensure traceability is maintained throughout the product lifecycle. The teams that build this capability early are the ones that move from development to market without compliance debt slowing them down.

Key Takeaways

• Most SaMD compliance failures stem from fragmented evidence architecture, not missing documentation—engineering artefacts exist but aren't structured for regulatory interrogation
• Quibim's successful CE and UKCA marking for QP-Breast demonstrates that audit-ready evidence architecture must be built in parallel with product development, not retrofitted during submission prep
• Development tools like Jira and GitHub are essential for engineering velocity but weren't designed for ISO 13485 or IEC 62304 traceability—teams need a deliberate translation layer to bridge the gap
• Compliance debt compounds when evidence structuring is deferred—by the time teams prepare for submission, reconstructing traceability across disconnected systems becomes expensive, time-consuming, and delays market entry
• Regulatory teams should audit evidence architecture early: if you can't trace requirements to risk controls, verification tests, and code changes in under 30 minutes, your system isn't ready for regulatory scrutiny

The evidence for SaMD compliance is almost always there. The question is whether it's structured in a way that regulators can interrogate, auditors can verify, and your team can defend under scrutiny. As more AI-driven diagnostics and software medical devices enter the pipeline under MDR, IVDR, and UKCA frameworks, the gap between 'we built it right' and 'we can prove we built it right' will only widen for teams that defer evidence architecture. Quibim's dual launch this week proves the benchmark is achievable. Greenlight Guru's analysis makes clear the cost of falling short. For SaMD teams, the time to close that gap is now—while the evidence base is still manageable, and before regulatory timelines become the bottleneck between development and market entry.