Context
Companion follow-up to OpenConceptLab/ocl_issues#2520 (target-repo version alignment across algorithm paths).
A mapping project pins to ONE explicit target repo version. As of #2520's fix, concept identity for dedup is anchored to the project pin across all algorithm paths (target_repo, bridge_repo cascade, and fixed canonicals matching the project's target_repo). That handles the dedup correctly under the current state of the world, where no algorithm response carries per-result version info.
Future state this ticket covers
If/when an algorithm response carries a version slot that differs from the project pin — most plausible candidate is \$cascade returning a cascade_target_concept_url with an embedded version segment from how the bridge mapping was authored, or a custom external algorithm reporting which version of a target repo it was built against — oclmap must:
- Still key on the project pin for dedup (no silent identity split).
- Record the algorithm-claimed version on the Candidate or AlgorithmResponse so it's preserved for audit.
- Surface the divergence to the user in the candidate row (chip, info icon, hover-explain) — "Algorithm reports this concept from LOINC 2.79, project pinned to LOINC 2.81".
We do not want to silently drop conflicting version info — even if the current single-version model treats the result as belonging to the project's pin.
Implementation notes
- The relevant code path is src/components/map-projects/normalizers.js#L84-L110 (
resolveReference).
- Candidate/AlgorithmResponse schema would need to grow an optional `claimed_version` (or similar) field. Currently the algorithm response shape doesn't include version anywhere except implicitly via
target_repo_url on the project.
- UI surface most likely lives in Candidates.jsx and the quality-view per-candidate metadata.
Acceptance
- Schema (or convention) for representing an algorithm-claimed version on a Candidate.
- When a project pinned at version A receives a candidate claiming version B for the same canonical (url, code), the candidate still dedupes on the project pin (key matches other A-keyed candidates) but the row surfaces a visible "version divergence" indicator.
- Test coverage in normalizers / view-builder layer asserting (a) dedup still works, (b) the claimed version is preserved on the Candidate.
Out of scope
- Project-level multi-version mapping (oclmap is single-version today; this ticket just makes the current divergence-handling honest, it doesn't add multi-version support).
- Form-level "target_repo.version is required" validation — separate ticket.
Context
Companion follow-up to OpenConceptLab/ocl_issues#2520 (target-repo version alignment across algorithm paths).
A mapping project pins to ONE explicit target repo version. As of #2520's fix, concept identity for dedup is anchored to the project pin across all algorithm paths (
target_repo,bridge_repocascade, andfixedcanonicals matching the project's target_repo). That handles the dedup correctly under the current state of the world, where no algorithm response carries per-result version info.Future state this ticket covers
If/when an algorithm response carries a version slot that differs from the project pin — most plausible candidate is
\$cascadereturning acascade_target_concept_urlwith an embedded version segment from how the bridge mapping was authored, or a custom external algorithm reporting which version of a target repo it was built against — oclmap must:We do not want to silently drop conflicting version info — even if the current single-version model treats the result as belonging to the project's pin.
Implementation notes
resolveReference).target_repo_urlon the project.Acceptance
Out of scope