{"slug": "healthcare-rag-test-the-claim-to-source-contract", "title": "Healthcare RAG: Test the Claim-to-Source Contract", "summary": "A developer proposes a \"claim-to-source contract\" for healthcare retrieval-augmented generation systems, arguing that a working citation link does not prove an answer's claims are supported by the cited passage. The design splits answers into independently checkable claims, retains evidence references and document fingerprints tied to ingestion runs, and stores page labels separately from printed page numbers. The schema and acceptance cases are presented as a proposed implementation for an educational healthcare knowledge product, not a clinical validation or deployed system.", "body_md": "A healthcare RAG answer can carry a working citation link and still fail review. The page exists, the passage loads and the answer sounds reasonable. Yet the passage may support only half the sentence, belong to an older edition or describe a different population. A link check cannot resolve those failures.\n\nBefore accepting a retrieval-augmented generation feature, specify a claim-to-source contract: what the product retains about each assertion, which checks it performs and what the user sees when a check fails. Treat that contract as a deliverable shared by ingestion, retrieval, answer rendering and review. The schema and acceptance cases below describe a proposed implementation for an educational healthcare knowledge product. They are not a clinical validation or a report of a deployed system.\n\nConsider a fictional learning assistant whose approved handbook describes how a training module is organized. A generated answer says that the module has an introductory lesson and an assessment. The cited passage describes the lesson but says nothing about assessment. Every component can appear healthy: ingestion succeeded, retrieval returned a relevant passage and the link opens the right page.\n\nThe unsupported addition is still visible to the learner.\n\nYour first acceptance rule should therefore operate on assertions, rather than on paragraphs that happen to end with a reference. Divide independently checkable statements into separate claims. Retain which passage supports each one, including any qualification needed to keep its meaning intact.\n\nDo not assume one sentence equals one claim. A sentence can combine a population, a benefit and a comparison. Conversely, one claim may require two passages read together. Let the representation support a set of evidence references and explain why that set is sufficient. A mechanical requirement for exactly one reference would force the content into the wrong shape.\n\nThe [ALCE research paper](https://arxiv.org/abs/2305.14627) evaluates fluency, correctness and citation quality as separate dimensions. That distinction is useful for an acceptance plan: polished output and correct links are insufficient evidence of supported claims. The practical design decision here is to retain those checks separately so an attractive answer cannot hide a failed evidence check.\n\nFor teams commissioning this work, the boundary between a prototype and an implementation should also appear in the statement of work. The [software product development scope](https://pharosproduction.com) should identify which evidence interactions are demonstrated and which are backed by working retrieval. A reviewer needs to know whether an opened passage was handpicked for the demo or selected by the system for that request.\n\nA source URL is a locator.\n\nIt is not enough to identify the exact material behind a saved answer. The same address can serve a corrected document tomorrow. A source record should distinguish the publisher's identifier, the retrieved version and the particular passage used in an answer.\n\nFor a document corpus, retain a content fingerprint with the ingestion run. Bind extracted passages to that fingerprint and to an extraction version. A new extraction can change reading order or table structure even when the original file has not changed. Without both identities, a reviewer may be comparing an old answer against new extracted text without realizing it.\n\nPage labels need similar care. A viewer's page index and the number printed on a book page can differ. Front matter can use a different numbering system. Store each independently and verify their mapping during ingestion. A fixed subtraction is appropriate only when the source actually has a verified fixed offset. Otherwise use an explicit page map, including pages without printed labels.\n\nThe passage should retain enough context to inspect its qualifications. Extracting a sentence while dropping a table heading can remove the population or unit that makes it meaningful. Preserve the relevant parent heading, table headers and footnotes with a reference to the original location. If extraction cannot capture the context, mark that passage for review before using it as answer evidence.\n\nHere is a compact record shape. Values are synthetic and the identifiers intentionally describe test fixtures. This is a data contract, not a ready-made clinical schema:\n\n```\n{\n  \"answer_id\": \"fixture-answer-01\",\n  \"answer_version\": 1,\n  \"corpus_snapshot_id\": \"fixture-corpus-a\",\n  \"policy_version\": \"education-only-v1\",\n  \"claims\": [{\n    \"claim_id\": \"c1\",\n    \"text\": \"The module contains an introductory lesson.\",\n    \"evidence_refs\": [\"p1\"],\n    \"support_status\": \"pending_review\"\n  }],\n  \"passages\": [{\n    \"passage_id\": \"p1\",\n    \"source_id\": \"fixture-handbook\",\n    \"source_version\": \"fixture-edition-a\",\n    \"content_fingerprint\": \"fixture-fingerprint-a\",\n    \"extraction_version\": \"fixture-extractor-a\",\n    \"source_class\": \"handbook\",\n    \"locator\": {\"viewer_page\": 9, \"printed_page\": \"3\"},\n    \"text\": \"This module begins with an introductory lesson.\"\n  }],\n  \"review\": null\n}\n```\n\nIn an implementation, validate the fingerprint's real algorithm and format; the fixture string above is only a readable stand-in. Likewise, a support label is a decision to justify. It does not become true because a generator emitted the field. Store the verifier or reviewer decision separately and bind it to the answer version it actually examined.\n\nDeterministic validation can establish whether referenced records exist, whether identifiers are unique and whether a page mapping resolves within the identified document. It can reject an answer with a dangling passage reference before the renderer builds a citation marker. Those are useful guarantees because they have precise failure conditions.\n\nThis Python function implements only the reference-integrity portion, assuming the record has already passed type and required-field validation:\n\n``` python\ndef reference_errors(record):\n    claims = record[\"claims\"]\n    passages = record[\"passages\"]\n    errors = set()\n    claim_ids = [c[\"claim_id\"] for c in claims]\n    passage_ids = [p[\"passage_id\"] for p in passages]\n    if len(set(claim_ids)) != len(claim_ids):\n        errors.add(\"duplicate_claim_id\")\n    if len(set(passage_ids)) != len(passage_ids):\n        errors.add(\"duplicate_passage_id\")\n    known = set(passage_ids)\n    for claim in claims:\n        refs = claim[\"evidence_refs\"]\n        if not refs:\n            errors.add(\"missing_evidence_ref\")\n        if any(ref not in known for ref in refs):\n            errors.add(\"dangling_evidence_ref\")\n    return sorted(errors)\n```\n\nI checked this function locally against the synthetic receipt and four mutations: a duplicated claim identifier, a duplicated passage identifier, an empty reference list and an unknown reference. The control returned an empty list; each mutation returned its corresponding error. Those five checks establish the illustrated reference behavior only. They do not verify source authenticity, passage meaning, access policy or page mapping. An empty claim list also needs a separate product rule if the caller expects an answer.\n\nString matching cannot establish that a clinical statement is justified. Exact copying can omit a negation immediately before the excerpt. A correct paraphrase can share few words with its source. Keep a distinct semantic review stage with a written rubric for support, contradiction and unresolved cases.\n\nFor the fictional fixture, a structural check should resolve `c1` to `p1`, confirm the passage belongs to the declared corpus snapshot and verify that its locator opens the intended source version. A semantic review should compare the claim with the complete passage context. Adding an assessment to the claim should fail that review while leaving the structural result unchanged.\n\nThis separation makes failures diagnosable. If the source cannot be opened, investigate source availability or access. If the wrong page opens, investigate the locator. If the correct page opens but does not support the claim, investigate generation or the support decision. Routing every problem into one hallucination counter discards information the team needs to repair it. Define the review unit before calculating any percentage. Citation completeness asks whether claims that need evidence have it. Support correctness asks whether the attached evidence supports those claims. A dashboard should name the denominator and preserve unresolved cases rather than silently removing them. Otherwise a system can improve its reported score by making difficult claims disappear from the evaluation set.\n\nA handbook explanation, a research finding and a regulatory record answer different questions. A product should preserve those source classes through extraction and rendering, instead of reducing them to interchangeable links. The reviewer must be able to tell what kind of evidence is attached before interpreting what it establishes.\n\nAn article about a device cannot stand in for a regulator's record of that device's status. A regulatory record cannot, by itself, support every claim about comparative effectiveness. In your source policy, define which class may support which assertion type and require review when an answer crosses that boundary. Keep jurisdiction and retrieval date visible where they affect interpretation.\n\nThis distinction appeared during Pharos Production's healthcare AI design work. Our published case reports that an audit found 6 of 7 demo citations wrong, including 4 invented citations. These were findings about our own mockups, not measurements of a deployed model. The response included verified source passages and separate presentation of handbook, research and regulatory evidence.\n\nThe [healthcare AI citation UX case study](https://pharosproduction.com/insights/healthcare/ai-citation-ux-aesthetic-medicine/?utm_source=devto&utm_medium=referral&utm_campaign=healthcare_citation_ux_20260926&utm_content=claim_source_contract) shows the source audit and illustrative screens behind those decisions, including the work still outstanding. Use it when reviewing an implementation proposal: compare the proposed evidence panel with the concrete design problems the case documents. The engagement remains in the design phase; external retrieval connectors shown in the demo are planned, not live.\n\nFor an engineering team, the next step is to turn a chosen source policy into fixtures. Create a claim that uses the right passage under the wrong source class. The acceptance result must expose that mismatch even if the text appears relevant. Source authority should survive a rendering refactor and a retrieval-provider change.\n\nA supported statement can still be inappropriate for the product's intended use. An educational assistant should not drift into patient-specific treatment instructions because a passage contains information that looks relevant. Keep the source-support decision separate from the policy decision governing what this product may present.\n\nThat separation needs visible states. A missing source, an unavailable source service and a request outside the product's permitted scope are different situations. The user needs a different explanation and next action for each. Internally, retaining separate reasons prevents the team from trying to fix a policy refusal by increasing the number of retrieved passages.\n\nThe FDA's January 29, 2026, guidance discusses enabling a healthcare professional to \"independently review the basis\" for recommendations. That phrase concerns one part of the US non-device clinical decision support criteria; a citation interface alone does not establish a product's regulatory classification. The [current FDA guidance](https://www.fda.gov/media/109618/download) is the source for that boundary, rather than a certification supplied by this design pattern.\n\nFor the proposed educational product, define a policy result alongside the support result. A fully supported explanation can proceed only when its use is allowed. An unresolved support decision should remain visibly unresolved. A denied use should select the intended boundary response even if retrieval found relevant material. Have the responsible domain owner approve that behavior before teams encode it in templates.\n\nThe priority between states also matters. Suppose retrieval times out on a request the product must not fulfill. Retrying the request automatically could produce prohibited output when the service recovers. Evaluate the intended-use boundary independently and avoid making an infrastructure error the only reason the answer was withheld.\n\nStart with a bounded corpus you are entitled to use and questions whose expected evidence can be inspected. Each fixture needs a reason it belongs in the suite, an expected user-visible outcome and an owner for disagreements. A collection of convenient questions without answerability labels will not reveal whether the product refuses too often.\n\nKeep synthetic examples visibly synthetic.\n\nUse neutral learning-content statements for plumbing tests so a malformed fixture cannot be mistaken for medical advice. Domain-specific acceptance cases need appropriately qualified review and controlled source material. Do not copy sensitive patient information into a shared test repository simply because a scenario would look more realistic.\n\nThe following matrix is a proposed starting point. Its rows represent different failure classes, not a measured test result or a completeness claim:\n\n| Fixture | Deliberate condition | Required observable result | \n|---|---|---|\n| Supported control | Approved learning claim with an exact supporting passage | Claim displays and its marker opens the correct version and location | \n| Unsupported addition | Add an assertion absent from the otherwise relevant passage | Added assertion is withheld or enters review; the supported part remains distinguishable | \n| Locator mismatch | Keep the passage text but point to another printed page | Citation validation fails; the interface does not present the location as verified | \n| Authority mismatch | Attach an assertion to a source class that cannot establish it | Source-policy failure is visible and retained in the receipt | \n| Source unavailable | Make the evidence service unavailable for the request | An availability state appears; no fabricated passage fills the gap | \n| Covered question missed | A gold passage exists but the retriever misses it | Evaluation records a retrieval miss rather than treating the refusal as success | \n| Intended-use boundary | Ask the educational product for a patient-specific directive | Approved boundary response appears, independent of source availability | \n| Changed source | Replace a source version behind a saved answer | The saved evidence remains identifiable and its review status is reconsidered | \n\nRun the supported control alongside negative cases. A system that suppresses every answer can pass many refusal tests while failing its main purpose. The covered-question fixture provides a second safeguard: the absence of retrieved evidence does not prove the absence of evidence in the corpus.\n\nFor each failure, check both the visible result and the retained record. A correct warning with a misleading success status in the receipt is still a defect. A correct internal rejection with an unsupported claim left on screen is also a defect. The acceptance oracle spans the service boundary and the rendered answer.\n\nComponent tests should prove that a claim marker opens its bound passage, rather than whichever passage happens to occupy the same array position. Reorder the evidence list while preserving its identifiers. The marker must still lead to the same evidence. This catches a simple implementation mistake with consequences that a visually unchanged snapshot may miss.\n\nAlso test the path back to the answer. After inspecting a passage, a reader should retain the context of the claim they were checking. If the interface opens a large document at its beginning, the citation may be technically reachable but practically difficult to review. Record that as a usability finding instead of converting it into an invented accuracy metric.\n\nUse representative intended users for that review. Ask them to locate the evidence, explain what it supports and identify a qualification. Observe where they mistake source provenance for review approval or assume a familiar publisher validates the whole answer. The product owner should decide what failure in that task blocks acceptance; a developer should not infer the threshold from a click-through rate.\n\nMobile layouts deserve the same evidence identity checks. A compact popover may omit the source edition that appears in a desktop rail. A downloaded or copied answer may lose the marker entirely. Specify which export formats preserve traceability, then verify them. If a format cannot preserve it, the exported artifact should make that limitation apparent to its reader.\n\nAccessibility belongs in the acceptance scope too. A visual connection drawn by color alone does not tell every reader which claim is selected. Give markers descriptive names, support keyboard navigation and verify focus behavior when an evidence panel opens and closes. These are proposed product requirements that need testing in the actual implementation.\n\nA review decision should refer to an answer version, its evidence versions and the policy under which it was accepted. Changing any of those inputs can invalidate the decision. Avoid a permanent approved flag attached only to the conversation, because later answers can inherit approval for content nobody reviewed.\n\nFor example, a reviewer accepts the synthetic lesson claim against edition A. An editor publishes edition B and moves the passage. Keep the old answer and its original evidence identity available under the applicable retention policy. Create a new review event for the changed source relationship. Do not silently rewrite the old receipt until it appears to describe edition B all along.\n\nSome changes require semantic review; others need narrower checks. A viewer-coordinate correction with unchanged passage content may need locator verification. A changed qualification requires reassessment of support. A new intended-use policy requires reassessment of permission even if the text is identical. Write these invalidation rules down so routine maintenance has predictable scope.\n\nThe same rule applies to model and retrieval changes. Passing the contract tests on a new configuration establishes only the tested behavior for that configuration and fixture set. Preserve the model identifier and relevant retrieval settings with the run. If a provider cannot guarantee identical future behavior behind an identifier, record that reproducibility limit rather than promising exact replay.\n\nMechanical checks are cheap to repeat once the representation is stable. Semantic review has a different cost and requires an agreed rubric. An automated verifier can help prioritize disagreements, but its output needs evaluation against the domain reviewers' judgments. Agreement on familiar examples does not establish reliability on unsupported, ambiguous or contradictory ones.\n\nAssign ownership at the point where a decision can become stuck. The ingestion owner resolves missing context. The product owner decides whether the intended user can complete the evidence task. The domain reviewer judges whether the claim is supported within its scope. Engineering preserves those decisions and makes the software follow them. One undifferentiated review queue makes these responsibilities harder to see. Set an unresolved-case policy before measuring performance. If reviewers disagree about whether a passage supports a claim, keep that uncertainty in the fixture metadata. It can be a useful test of the escalation route. Forcing consensus merely to obtain a tidy score removes the scenario that needs the clearest product behavior.\n\nMeasure operational burden as well as answer quality. Count cases awaiting review and record why they remain open. Track whether the evidence panel gives reviewers enough context to decide without searching an unrelated document store. Use those observations to improve the workflow; do not describe shorter handling time as proof of safer clinical decisions.\n\nAn auditable answer does not require copying every input into an unrestricted log. Decide which records belong in the evidence store, which belong in a restricted operational system and which should not be retained. The educational fixture can be public because it contains invented learning content. A real request may carry information that changes those decisions.\n\nGive the receipt stable references to protected records where appropriate. Apply access checks when the evidence panel resolves them. A citation should not become an alternate route around the permissions that protect the underlying document.\n\nTest this with an authorized reader and a reader who cannot access the same source; the second reader must not receive the passage through a cached answer.\n\nRetention also creates an acceptance edge case. If the supporting document is no longer available under the applicable policy, the product cannot honestly present the saved answer as fully inspectable. Preserve the reason for that limitation without inventing a replacement passage. The owner needs to decide whether the answer remains visible with a warning, becomes restricted or is removed through the established retention process.\n\nAgree on that behavior before promising reproducibility in a delivery contract. Exact replay may depend on source licenses, retained snapshots and provider behavior outside the application's control. A useful receipt states what can still be verified today and what was verified at the original review. Those are different claims, and a buyer should be able to distinguish them without investigating your storage architecture.\n\nFor a healthcare AI development proposal, request the schema, the source-version policy and the fixture matrix together. Require a sample answer receipt that can be followed from the rendered claim to its source passage. Ask for both a passing control and a failure that remains visible to the user. Those artifacts make an implementation scope concrete enough to inspect.\n\nThe packet should also name what has not been demonstrated. A clickable prototype, a working ingestion job and a tested retrieval path are different deliverables. Record which one exists, which sources it uses and who accepted its limits. That gives the buyer a basis for deciding what the next development milestone must prove.\n\nBefore commissioning the next phase, bring an authorized sample corpus, a representative learning task and a named review owner to the technical discussion. Use the case linked above to examine the discovery work, then use this contract to ask how the implementation will preserve it. A credible proposal should identify the first claim it will prove, the fixture that can break it and the person responsible for resolving the failure.\n\nDmytro Nasyrov. Photo supplied by the author.\n\n*Written by [Dmytro Nasyrov](https://pharosproduction.com/dmytro-nasyrov/) PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.*", "url": "https://wpnews.pro/news/healthcare-rag-test-the-claim-to-source-contract", "canonical_source": "https://dev.to/pharos_production/healthcare-rag-test-the-claim-to-source-contract-2036", "published_at": "2026-09-26 08:18:29+00:00", "updated_at": "2026-09-26 08:30:04.340089+00:00", "lang": "en", "topics": ["ai-research", "natural-language-processing", "ai-products", "ai-tools"], "entities": ["ALCE"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/healthcare-rag-test-the-claim-to-source-contract", "markdown": "https://wpnews.pro/news/healthcare-rag-test-the-claim-to-source-contract.md", "text": "https://wpnews.pro/news/healthcare-rag-test-the-claim-to-source-contract.txt", "jsonld": "https://wpnews.pro/news/healthcare-rag-test-the-claim-to-source-contract.jsonld"}}