Retraction-Aware Biomedical RAG: An Event Crosswalk

Retraction-aware biomedical retrieval-augmented generation (RAG) requires a publication-status service that operates throughout the life of an evidence collection. Its unit of control should be a versioned event connecting an original work, a notice, source assertions, and downstream evidence objects. A searchable citation can exist while its eligibility for routine evidence synthesis changes. Notice-to-work links, visible publication types, and preservation of earlier versions provide the foundations for that distinction. (^[1]) (^[2]) (^[3])

The practical crosswalk joins Crossref and Retraction Watch, PubMed, and the publisher notice. Retraction Watch's downloadable dataset is updated once per working day, and its correction and expression-of-concern coverage is less comprehensive than its retraction coverage. Missing results therefore establish an unsuccessful lookup within a recorded scope, never a verified universal absence of status changes. PubMed distinguishes original articles from notices through publication types and linked-record relationships. (^[4]) (^[5])

A synthetic (Hypothetical Example) illustrates direction and provenance: a notice record contains two update-to retraction assertions about an original record, attributed in the fixture to publisher and retraction-watch. The original record contains corresponding updated-by assertions. The fixture uses invented identifiers and represents one event with two source assertions; it makes no claim about any real publication. The acceptance tests below normalize both directions and retain both assertions.

The recommended policy separates routine retrieval eligibility, restricted audit access, and human claim review. Quarantine retracted evidence from ordinary answers, assess corrections at the affected-claim level, and route concerns and reinstatements through explicit review. Preserve the provenance needed to identify dependent summaries and approve restoration. The National Information Standards Organization's (NISO) publication-status recommendations address machine-readable communication, while the National Institute of Standards and Technology (NIST) recommends ongoing verification of generative-AI sources and citations. Neither supplies a turnkey institutional disposition policy. (^[6]) (^[7])

The quantitative evidence supports caution without establishing a current-system failure rate: a primary study produced 6,510 quality reports, using a specific model and historical prompt design, and none mentioned the associated retractions or relevant errors. This report provides a reproducible identifier fixture and executable policy tests, but reports no measured sensitivity or provider-lag benchmark. Adoption should depend on tested synchronization, explicit unresolved cases, and accountable review, rather than model-only status detection. (^[8])

A biomedical evidence workflow can ingest a paper, embed its text, generate a cited answer, and incorporate that answer into a reviewed deliverable. Publication status can subsequently change. The original RAG architecture combines parametric model memory with retrieved nonparametric memory; updating a retrieval collection addresses the latter component. Accordingly, removing a document from a retriever should never be described as removing its information from model training or every previously generated output. (^[9])

The operational question is broader than whether a reference exists. It asks whether the exact version remains appropriate support for a particular claim, which notices affect it, and which downstream objects need reassessment. Provenance, meaning the recorded derivation and responsibility relationships among evidence objects, makes these questions tractable. The World Wide Web Consortium's PROV ontology explicitly represents derivations, revisions, and attribution to responsible agents. (^[10])

For IntuitionLabs' life-sciences readership, this report takes an adjacent advisory perspective: research informatics owns reliable ingestion, scientific librarians resolve bibliographic identity, medical affairs evaluates affected claims, and AI governance approves the operating policy. These are recommended responsibilities, not assertions that a particular organizational chart is mandatory. The emphasis is consistent with risk-based AI assessment, while regulatory applicability depends on the actual use. The US Food and Drug Administration's cited AI credibility document remains draft and nonbinding on its current page. (^[11])

This report examines post-ingestion change management, not a ranking of literature assistants. The public sources were accessed for this report on October 27, 2026. The distinction matters because publication recommendations already call for linked notices and archived versions, and automated systems need those relationships to reach beyond the source record into derived evidence. NISO's Communication of Retractions, Removals, and Expressions of Concern (CREC) explicitly addresses metadata transfer and display for automated processes. (^[1]) (^[3]) (^[6])

Preserve the original and notice as distinct objects

A digital object identifier (DOI) identifies a registered research object; a PubMed identifier (PMID) identifies a PubMed citation. Store the identifier namespace with its value. A notice may have its own DOI and PMID, and its publication type can differ from that of the original. The National Library of Medicine (NLM) assigns Retracted Publication to the original and Retraction Notice to the notice. A join that swaps those roles can suppress the explanatory notice while leaving the affected article eligible. (^[2])

Table 1 crosswalks the source fields into a proposed internal event model. The internal names are design recommendations, not a claim that providers share one schema.

Source or event	Original and notice identity	Relationship and provenance	Coverage or interpretation limit
Crossref production metadata	Keep original DOI and notice DOI separately.	Normalize notice update-to and original updated-by into the same directed event. Keep each source assertion. ([12]) ([13])	Absence of one property is insufficient; inspect both roles and retain lookup scope.
Retraction Watch comma-separated values (CSV) dataset	Map OriginalPaperDOI / OriginalPaperPubMedID and RetractionDOI / RetractionPubMedID separately.	Retain the database record ID and RetractionNature; distinguish retraction, correction, concern, and reinstatement. ([4])	Blank or unavailable DOI values mean no DOI was apparent on entry, not an unaffected article. ([14])
PubMed retraction	Original PMID carries Retracted Publication; notice PMID carries Retraction Notice.	Original RIN / RetractionIn points to the notice; notice ROF / RetractionOf points to the original. ([5]) ([2])	Publication types and linked-record fields complement each other.
PubMed concern and correction	Preserve both PMIDs when available.	ECI / ExpressionOfConcernIn points to the concern notice; ECF / ExpressionOfConcernFor points to the original. Correction uses EIN / ErratumIn and EFR / ErratumFor. ([15]) ([5])	NLM groups several correction categories as errata; the notice still needs interpretation. ([2])
Publisher Extensible Markup Language (XML) using JATS	Keep the current article and linked target distinct.	Journal Article Tag Suite (JATS) uses outward-facing links; a notice can use retracted-article for the original and retraction-forward for the reverse association. ([16])	Validate the relationship in context rather than applying a universal suffix rule.
Version and reinstatement evidence	Record the version identifier, notice, and affected work.	DataCite distinguishes sequential version relations from canonical-resource/version relations; Retraction Watch documents reinstatement cases with a shared original/replacement DOI. ([17]) ([18])	A shared DOI cannot by itself prove which text or claims were restored.

The crosswalk preserves direction before normalization. Provider-specific labels should survive alongside the internal event type so that a later mapping correction remains auditable. In particular, a concern and an erratum should not collapse into retraction merely because all are linked notices. The Committee on Publication Ethics (COPE) describes a concern as potentially interim or final, and the International Committee of Medical Journal Editors (ICMJE) distinguishes correction from retraction with republication. (^[19]) (^[3])

Treat a negative lookup as bounded evidence

A source adapter should return a lookup result and its scope separately from the work's disposition. Useful outcomes include matched event, successful lookup without a matching event, unresolved identity, incomplete response, and unavailable source. This proposed design follows directly from documented identifier gaps and uneven status coverage. Europe PMC's Article Status Monitor offers another identifier-based check, but an additional interface does not create independently complete ground truth. (^[14]) (^[20])

For PubMed discovery, hasretractionin retrieves articles with retraction links and hasretractionof retrieves notices. Its filter definitions also combine these with retracted publication[pt] and retraction notice[pt]. These are useful retrieval routes, not certificates that every relevant publication or newly issued notice has been indexed. Store the query and returned identifiers with the observation. (^[5])

Keep status vocabularies and decisions separate

Correction, expression of concern, retraction, and reinstatement need different handling. A correction can require a revised evidence version; a concern can remain unresolved; a reinstatement can involve a replacement under an existing identifier. The safe implementation preserves the publisher's exact language and the source's raw category before translating either into a local eligibility rule. (^[3]) (^[19]) (^[18])

Build an append-only event and assertion register

The recommended schema separates work, notice, event, source assertion, observation, and review decision. This supports a simple distinction: an event describes a publication change, an assertion records what a source says about it, and a decision determines how the organization will use affected evidence. PROV's distinction among entities, activities, and agents provides a suitable conceptual foundation. (^[10])

Record the following identity and evidence fields:

• Original identifiers: DOI, PMID, other supported namespaces, and identity-resolution method.
• Notice identifiers: distinct DOI, PMID, publisher URL, and unresolved candidates.
• Event identity: internal ID, normalized type, raw source type, and superseded-event links.
• Assertion provenance: retrieved service, asserted source, source record ID, and adapter version.
• Evidence snapshot: response location, raw payload hash, retrieval outcome, and content version.

These are proposed audit fields. Hashes establish payload identity for comparison; reviewers still need the underlying evidence and its context. Preserve an original-to-notice link even if content access changes. Findable, accessible, interoperable, and reusable (FAIR) principles explicitly favor accessible metadata when the underlying data are no longer available, as well as qualified references and provenance. (^[21])

Record time and decision fields separately:

• Notice time: publication date or timestamp, with precision and timezone if supplied.
• Source time: provider modification or indexing time, if exposed.
• Observation time: first observed by this system, plus the monitoring or backfill run ID.
• Verification time: last successful source verification, separate from failed attempts.
• Disposition: eligibility, affected claim IDs, reviewer, rationale, and approval time.
• Restoration: replacement evidence version, authorizing decision, and superseded restriction.

A DOI can remain the same while content changes, so identity alone is insufficient for version control. ICMJE recommends dated new versions and preservation of prior versions, while DataCite documents relationships for sequential versions and canonical resources. Store the text or permitted snapshot version used to support each claim. (^[3]) (^[17])

Synchronize changes without losing failures

Crossref's current Representational State Transfer (REST) application programming interface (API) documentation describes from-index-date as retrieving reindexed records, including changes from members, Crossref, and external sources. Its operational tips recommend also bounding the query with until-index-date for stable multipage retrieval. Use these fields to identify changed records, not as substitutes for notice publication dates or locally observed detection times. (^[22])

A recommended synchronization loop is:

• Capture bounds: persist the previous completed watermark and this run's upper bound.
• Allow overlap: replay a documented overlap interval and deduplicate observations.
• Stage pages: persist responses and cursor progress before deriving decisions.
• Normalize relationships: process notice-to-original and original-to-notice assertions.
• Commit atomically: advance the completed watermark only after durable processing.
• Reconcile periodically: compare indexed holdings with a fresh available dataset snapshot.

Use a working-day reconciliation schedule appropriate to Retraction Watch's documented refresh, plus risk-based checks before consequential evidence reuse. Do not promise that daily polling yields a daily completeness guarantee. Crossref's legacy Labs integration explicitly warns of out-of-date data; production monitoring should use the production service and current dataset. (^[4]) (^[12])

For throughput, inspect current response headers, respect service-specific concurrency, and back off after throttling. Crossref's newer rate-limit announcement distinguishes list and single-record requests, so a historical single-number limit is unsuitable as a universal configuration. NCBI's official developer guidance also recommends batching through its History mechanism. The acceptance suite below tests failure handling rather than hardcoding rates into illustrative code. (^[23]) (^[24])

Traverse dependencies beyond vector chunks

The recommended dependency graph follows source version to chunks, embeddings, retrieval snapshots, cached answers, extracted claims, and reviewed deliverables. Each edge should identify which source version was used. A corrected source then creates an impact set that a reviewer can inspect, rather than an instruction to invalidate every document with a similar title. This is an application of recorded derivation and revision relationships. (^[10])

Maintain explicit handling for each derivative:

• Chunks: exclude affected versions from ordinary retrieval through an enforced eligibility filter.
• Embeddings: retain restricted references where justified, or rebuild from approved text.
• Caches: expire or block answers dependent on restricted evidence versions.
• Claims: route directly supported claims to an evidence reviewer with their source passages.
• Deliverables: create an amendment task for the owner of the reviewed document.
• Audit search: preserve authorized discovery of original, notice, and decision history.

These are recommended controls rather than claims about a vendor's capabilities. Eligibility must be enforced by the retrieval application, and the returned citations must preserve the evidence version. NIST recommends verifying sources and citations during ongoing monitoring, while NISO addresses making publication status evident to automated processes. (^[7]) (^[6])

Approve the disposition at the right level

Table 2 proposes a lifecycle policy. Institutions should assign equivalent accountable roles according to their operating model; the table does not establish a universal regulatory requirement.

Observed state	Routine-answer action	Review owner and approval	Required decision evidence
Retraction confirmed	Exclude affected original/version from ordinary synthesis; preserve restricted audit retrieval.	Evidence owner assesses claims; authorized approver signs disposition.	Notice, original identity, affected dependencies, and rationale. Notice linkage is a publication-ethics recommendation. ([1])
Correction confirmed	Restrict affected claims or versions until scope is assessed; regenerate from accepted text.	Domain scientist reviews substance; document owner approves amendments.	Version comparison and claim-specific rationale, consistent with correction/version recommendations. ([3])
Expression of concern	Apply the declared precautionary rule, such as warning plus review or temporary restriction.	Scientific reviewer assesses suitability for the intended use.	Notice and unresolved questions. A concern can be interim or final. ([19])
Reinstatement or replacement	Keep restriction until the specific replacement/version and claims are reviewed.	Authorized reviewer approves restoration and downstream updates.	Link to prior event, publisher evidence, accepted version, and decision history. Shared identifiers need care. ([18]) ([17])
Missing identifier or conflicting status	Mark unresolved; restrict consequential use under local policy.	Librarian resolves identity; evidence owner adjudicates use.	All source assertions and failed match attempts. Missing DOI information has a bounded meaning. ([14])
Source/API failure	Preserve last verified state and expose stale or incomplete coverage.	Operations restores retrieval; governance approves any exception.	Attempt log, retained watermark, retry outcome, and review deadline. Service-aware batching remains appropriate. ([24])

The key distinction is between retaining a record and endorsing its use. Archival access can support research-integrity work or reproducibility while ordinary synthesis excludes the affected evidence. Preservation of prior versions and persistent metadata supports this separation. Historical answers also need their own amendment workflow; changing the retriever does not retroactively revise an exported report. (^[3]) (^[21])

For medicinal-product information uses, the European Medicines Agency's (EMA) AI reflection paper discusses human supervision and factual quality checks. That context supports accountable review, but does not turn this proposed lifecycle table into a binding rule for every biomedical chatbot. The actual clinical, scientific, or regulatory context should determine the review depth and responsible professional. (^[25])

Synthetic identifier fixture and expected relationships

The following (Hypothetical Example) uses urn:fixture:original and urn:fixture:notice as stand-ins in the adapter's DOI fields, with fixture-pmid-original and fixture-pmid-notice as stand-ins for PMIDs. These are deliberately synthetic test tokens, not registered DOIs or PubMed identifiers, and must not be submitted to live lookup services. No real publication, author, or publisher notice is represented.

The synthetic notice has two update-to assertions about the synthetic original, labeled publisher and retraction-watch for testing. Its invented Retraction Watch record token is fixture-rw-record. The synthetic original has corresponding updated-by assertions. The expected normalization result is one original/notice/type event retaining both assertions. Test direction and identity with these local records.

Run deterministic policy tests separately from network tests

The following standard-library Python fixture is executable as written. All identifiers and records are synthetic (Hypothetical Example) data. Its DOI and PMIDS fields contain the stand-in tokens described above; the reduced adapter records are for local policy tests only. The code demonstrates event deduplication, direction handling, and restriction policy. Production identity verification requires separate network contract tests.

from collections import defaultdict

ORIGINAL = "urn:fixture:original"
NOTICE = "urn:fixture:notice"
PMIDS = {ORIGINAL: "fixture-pmid-original", NOTICE: "fixture-pmid-notice"}


def events(record):
    """Input: verified, normalized adapter output, not a raw network response."""
    result = defaultdict(set)
    for relation in ("update-to", "updated-by"):
        for item in record.get(relation, []):
            if relation == "update-to":
                original, notice = item["DOI"], record["DOI"]
            else:
                original, notice = record["DOI"], item["DOI"]
            key = (original, notice, item["type"])
            result[key].add((item["source"], item.get("record-id")))
    return dict(result)


def disposition(kind, approved=False):
    if kind == "retraction":
        return "exclude"
    if kind in {"correction", "expression_of_concern"}:
        return "review"
    if kind == "reinstatement":
        return "eligible" if approved else "review"
    return "unknown"


def checkpoint(previous, candidate, complete):
    return candidate if complete else previous


def conflict(kinds):
    return len(set(kinds)) > 1


def lookup_scope(identified, complete):
    return "resolved" if identified and complete else "unknown"


sources = [{"type": "retraction", "source": source,
            "record-id": record_id}
           for source, record_id in
           [("publisher", None), ("retraction-watch", "fixture-rw-record")]]
notice = {"DOI": NOTICE, "update-to":
          [dict(item, DOI=ORIGINAL) for item in sources]}
original = {"DOI": ORIGINAL, "updated-by":
            [dict(item, DOI=NOTICE) for item in sources]}
expected = (ORIGINAL, NOTICE, "retraction")
assert events(notice) == events(original)
assert set(events(notice)) == {expected}
assert len(events(notice)[expected]) == 2
notice["update-to"].append(notice["update-to"][0])
assert len(events(notice)[expected]) == 2
assert events({"DOI": "urn:fixture:unresolved"}) == {}
assert events({}) == {}
assert lookup_scope(identified=False, complete=True) == "unknown"
assert lookup_scope(identified=True, complete=False) == "unknown"
assert conflict(["retraction", "expression_of_concern"])
assert not conflict(["retraction", "retraction"])
assert disposition("missing") == "unknown"
assert disposition("retraction") == "exclude"
assert disposition("correction") == "review"
assert disposition("expression_of_concern") == "review"
assert disposition("reinstatement") == "review"
assert disposition("reinstatement", approved=True) == "eligible"
assert checkpoint("old", "new", complete=False) == "old"
assert checkpoint("old", "new", complete=True) == "new"
print("All deterministic acceptance assertions passed")

This is an executable policy kernel, not a production synchronizer. Its approved parameter represents an authenticated review decision supplied by the surrounding system. Production adapters must normalize identifiers, preserve unmatched assertions, retain raw categories, and reject unsupported relationships. In particular, a reinstatement decision must attach to the relevant prior restriction and version, as shared-DOI replacement cases make clear. (^[18]) (^[17])

Table 3 extends the kernel into system acceptance tests. All test inputs are synthetic (Hypothetical Example) data; expected actions express the proposed policy.

Test input	Expected outcome	Observable acceptance evidence
Same synthetic notice/original/type from publisher and Retraction Watch	One event, both assertions retained.	Event key and assertion set match the synthetic fixture.
Original has only updated-by; notice has update-to	Both normalize to the same directed edge.	Original and notice remain distinct objects.
DOI absent, PMID present	Attempt a documented PMID join; keep unresolved if unverified.	Match method and source response retained.
Both identifiers absent	Create an unresolved record; title similarity remains a candidate.	No automatic eligible or merged status.
Source says concern while another says retraction	Preserve both; route conflict for adjudication.	No destructive overwrite by last response.
Duplicate payload replay	No extra event or extra assertion.	Stable keys and unchanged impact-set count.
API error or incomplete pagination	Completed watermark remains unchanged.	Retry log and explicit stale coverage.
Correction affecting a subset of claims	Review affected claims and preserve documented unaffected decisions.	Version comparison and reviewer rationale.
Reinstatement received	Remain restricted pending relevant approval.	Prior event, accepted version, and signed restoration link.
Cached answer cites restricted source	Block or expire dependent cache entry.	Query cannot serve the stale answer through an alternate path.
Approved summary depends on restricted claim	Open a tracked amendment task.	Owner, due date, outcome, and revised summary version.
Audit-role query for restricted original	Return original plus notice and history under access policy.	Routine-user query remains subject to eligibility filter.

Run network contract tests separately against saved payloads and controlled service responses. Bibliographic XML can express outward-facing relationships, and NLM's publisher documentation distinguishes concern-for links to the original; adapters should test those semantics explicitly. A local assertion passing is evidence about the tested implementation only, never proof of source completeness. (^[16]) (^[15])

What the published model experiment measures

The primary Learned Publishing paper selected 217 retracted or otherwise concerning high-profile studies and generated 30 quality evaluations per study, yielding 217 × 30 = 6,510 reports. It reports that none mentioned the articles' retractions or relevant errors. The experiment used combined title-and-abstract prompts, the model gpt-4o-mini-2024-07-18, and API submissions in September 2024. These details define the measured task. (^[8])

The result supports using authoritative status inputs rather than expecting an unassisted model to identify publication changes. It does not estimate the October 2026 failure rate of retrieval-enabled systems. The sample, model, prompts, date, and outcome definition differ from a deployment that explicitly queries status providers and enforces retrieval policy. No production retraction-aware RAG sensitivity estimate was measured in this report. (^[8])

Report coverage, duplication, and latency separately

The synthetic (Hypothetical Example) demonstrates relationship direction and duplicate provenance. Its two notice assertions concern the same invented original and notice, so the test expects one canonical event with both provenance records retained. This local example supplies no evidence about provider records or population-level performance.

For a local evaluation, publish these definitions with the evaluation export:

• Identifier match coverage: resolved source identifiers divided by input records, with the input unit fixed in advance.
• Duplicate-event ratio: redundant assertions divided by normalized source assertions, where redundant means assertions minus distinct canonical events.
• Unresolved cases: unmatched identities, ambiguous relationships, incomplete responses, and unresolved conflicts reported separately.
• Observed detection latency: first observed detection time minus notice publication time, only when comparable timestamps exist.
• Ground-truth sensitivity: detected eligible test events divided by all independently adjudicated eligible test events.

These are proposed measurement definitions. Count one target identifier per input record and report DOI and PMID strata separately, so resolving both identifiers cannot inflate the numerator. A dual-source event is not necessarily an erroneous duplicate in the provider: the redundancy can be valuable provenance. In this (Hypothetical Example), an adapter receiving the two synthetic source assertions from the fixture yields (2 minus 1) / 2 = 50% redundant assertions under the stated metric. That arithmetic describes the fixture, not a corpus-wide duplicate rate. (^[13])

Latency needs particular restraint. A date-only notice permits an interval or date-level calculation, not invented subday precision. A first encounter during a historical backfill measures backfill age as well as observation timing. Crossref index timestamps and PubMed modification dates are metadata-update fields; neither is a replacement for a locally recorded first observation. This report therefore publishes no provider-lag figure. (^[22]) (^[5])

A false-negative estimate requires an independently curated ground truth, declared sampling frame, retrieval date, and sample size. Querying a provider and then treating that same provider's results as the complete positive set cannot establish what it missed. Biomedical teams should stratify tests by identifiers, event category, notice age, and language, and report adjudication rules. NISO's machine-readable communication recommendations make interoperability relevant, without promising universal detection coverage. (^[6])

Make the audit export independently interpretable

The recommended export should permit another team to reconstruct the evidence state and the decision without querying a model for an explanation. Provenance models can represent derivation and responsible agents, while FAIR principles favor persistent metadata and qualified references. Retain enough structured evidence to distinguish a source correction from a local policy change. (^[10]) (^[21])

Include the following export groups:

• Identity group: original DOI/PMID, notice DOI/PMID, unresolved candidates, and match method.
• Source group: service, asserted source, Retraction Watch record ID, query, and retrieval result.
• Time group: notice date and precision, first observed time, last verified time, and completed watermark.
• Integrity group: raw payload hash, stored evidence location, adapter version, and policy version.
• Impact group: source version, chunk IDs, cached-answer IDs, claim IDs, and deliverable versions.
• Decision group: reviewer, disposition, rationale, approval, superseded decision, and restoration evidence.

Rights remain a separate control. NLM notes that PubMed abstracts may contain protected material, and Crossref requests citation of Retraction Watch metadata when used in published work. API access should not be translated into unrestricted full-text redistribution. Keep required source attribution and document the applicable rights for retained content and shared exports. (^[26]) (^[13])

Evaluate the operating process, not just the retriever

A mature rollout should demonstrate that an affected claim reaches the correct reviewer and that the approved amendment reaches its users. Teams can begin with the synthetic identifier fixture, additional synthetic edge cases, and simulated outages, then build an independently curated evaluation corpus. The publication-version recommendations support keeping prior versions while making the accepted version explicit. (^[3])

Policy thresholds should follow the intended use. A research-integrity search, an exploratory literature summary, and a reviewed medicinal-product document can require different access and approval rules. EMA's reflection paper discusses lifecycle monitoring and close human supervision in relevant medicinal-product contexts; FDA's cited credibility guidance is draft and context-specific. Neither should be presented as a blanket certification of a RAG implementation. (^[25]) (^[11])

Future improvements should make status relationships more explicit and portable, including notice identity, scope of change, and version links. JATS and DataCite already provide useful relationship structures, while CREC addresses communication to automated systems. The immediate priority is to preserve those structures through ingestion and downstream review, rather than flattening all changes into a title prefix or a Boolean flag. (^[16]) (^[17]) (^[6])

Retraction-aware biomedical RAG is a lifecycle control for evidence. The core implementation joins original works to notices, retains source-specific assertions, and derives routine retrieval eligibility through a documented review policy. PubMed's publication types, publisher notice links, and machine-readable relationship standards provide complementary inputs. Their differences are a reason to preserve provenance and direction, rather than forcing every source into a single unqualified status flag. (^[2]) (^[1]) (^[6])

The most useful initial deliverable is a small, reproducible operating contract: source adapters, an event register, a dependency map, and acceptance tests that expose missing identity, duplicate provenance, source failure, and restoration decisions. Prior versions and restricted audit records should remain interpretable even when routine use changes. Version-control guidance and persistent-metadata principles support that distinction. (^[3]) (^[21])

Implementation success should be judged through explicit local evidence: resolved identifiers, separately reported unresolved cases, reproducible event deduplication, complete synchronization runs, and documented claim review. The published model experiment motivates authoritative checks, but does not supply a current deployment benchmark. A system should report its measured coverage and limits, retain the evidence behind each decision, and make restoration as accountable as restriction. (^[8])