Verified, Not Just Retrieved: Grounding an Agentic Drafting System in Medical-Device Regulation

At Percisio we build Iris, an agentic system that drafts regulatory and quality-management documentation for medical-device manufacturers. It works from the EU Medical Device Regulation (MDR 2017/745), ISO 13485, and a growing library of supporting standards covering areas such as risk management, clinical investigation, and medical-device software.

In medical-device regulation, citations are part of the evidence. If a technical file attributes a requirement to the wrong clause—or cites a clause that doesn't actually support the claim—that's a compliance issue, not just a writing mistake.

That requirement shaped the design of Anchor, the retrieval and verification backend behind Iris. Our goal wasn't simply to retrieve relevant text, but to let the drafting system make citations the way an experienced regulatory professional would: this clause says this, and here's why it supports the claim.

Why plain RAG isn't enough

A typical retrieval-augmented generation (RAG) pipeline embeds a corpus, retrieves passages similar to a query, and provides them to a language model as context. That works well for many applications, but it leaves one important question unanswered: does the retrieved text actually support the claim the model is making?

Retrieval finds relevant evidence. It doesn't verify that the evidence has been interpreted correctly. A model can misread a clause, confuse it with a similar one elsewhere in the corpus, or attribute a statement to the wrong citation even when retrieval succeeded.

Regulatory documents make this harder because they aren't ordinary prose. They have a defined hierarchy: articles contain paragraphs, paragraphs contain lettered points, ISO standards nest multiple clause levels, and annexes have their own numbering.

That hierarchy is what gives a citation meaning. "Article 10(9)(a)" doesn't just identify some nearby text—it refers to a specific location in the regulation. Standard chunking approaches often break that structure apart. A retrieved chunk may discuss the right topic while no longer corresponding to the clause the citation claims to reference.

What Anchor adds

Anchor builds on standard retrieval with two additional stages: verification and provenance checking.

Structure-aware retrieval. We don't index arbitrary token windows. Instead, we parse each document according to its own numbering hierarchy, so every retrieved result is a real, addressable node: an article paragraph, an ISO sub-clause, or an annex section.

Retrieval combines dense semantic search with lexical search. Semantic retrieval finds conceptually related material, while lexical search captures the exact terminology that regulatory documents depend on. Using both reduces cases where semantically similar clauses are retrieved even though they describe different requirements.

Independent verification. Retrieval identifies candidate evidence; verification determines whether that evidence actually supports the claim.

Verification starts with the simplest case: does the cited clause explicitly contain the claimed statement? If not, the verifier checks whether the claim is genuinely entailed by the clause rather than merely related to it.

This verification step is independent of drafting. The model that generates a citation never validates its own work. Verification is implemented as a mandatory stage in the pipeline, not as a prompt asking the drafting model to double-check itself.

Provenance-aware verification. Regulatory corpora contain different kinds of material. Some clauses impose requirements, while others provide guidance, examples, or explanatory information.

We record whether each retrieved node is normative, explanatory, or informative. During verification, that information matters. A claim that asserts a regulatory obligation cannot be supported solely by informative guidance, even if the wording is similar.

In other words, we verify both that the cited text supports the claim and that the source has the authority to support that kind of claim.

Why the audit trail matters

Every verification step is logged: the claim, the evidence that was evaluated, and the verification result.

In many applications this kind of trace is primarily useful for debugging. In regulatory documentation it's part of the product itself. QA and regulatory teams, auditors, and notified bodies all need to understand why a statement appears in a technical file and what evidence supports it.

Building that trace into the system from the beginning is much more reliable than trying to reconstruct it afterwards.

A broader lesson

Anchor reflects a distinction we think is important for high-stakes AI systems.

Much of the recent work on RAG focuses on improving retrieval through better embeddings, chunking strategies, and reranking. Those improvements matter—we rely on many of them ourselves—but they only improve the quality of the candidate evidence.

They don't establish that the evidence actually supports the generated claim.

For us, grounding an agent means treating retrieval, document structure, and verification as separate architectural stages. Retrieval finds the evidence. Structure preserves what the citation refers to. Verification determines whether the claim is actually supported.

In a regulated domain, all three are necessary.